VirtualBox

Ticket #891: pre-2.6.23.2.patch

File pre-2.6.23.2.patch, 35.8 KB (added by Paweł Paprota, 17 years ago)

patch that has been added in build 8

  • kernel/lockdep.c

    From 3aa416b07f0adf01c090baab26fb70c35ec17623 Mon Sep 17 00:00:00 2001
    From: Gregory Haskins <ghaskins@novell.com>
    Date: Thu, 11 Oct 2007 22:11:11 +0200
    Subject: [PATCH] lockdep: fix mismatched lockdep_depth/curr_chain_hash
     It is possible for the current->curr_chain_key to become inconsistent with the
     current index if the chain fails to validate.  The end result is that future
     lock_acquire() operations may inadvertently fail to find a hit in the cache
     resulting in a new node being added to the graph for every acquire.
    
    Signed-off-by: Gregory Haskins <ghaskins@novell.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Cc: Chuck Ebbert <cebbert@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    
    ---
     kernel/lockdep.c |   10 +++++-----
     1 file changed, 5 insertions(+), 5 deletions(-)
    
    a b cache_hit:  
    15211521}
    15221522
    15231523static int validate_chain(struct task_struct *curr, struct lockdep_map *lock,
    1524                 struct held_lock *hlock, int chain_head)
     1524                struct held_lock *hlock, int chain_head, u64 chain_key)
    15251525{
    15261526        /*
    15271527         * Trylock needs to maintain the stack of held locks, but it
    static int validate_chain(struct task_st  
    15341534         * graph_lock for us)
    15351535         */
    15361536        if (!hlock->trylock && (hlock->check == 2) &&
    1537                         lookup_chain_cache(curr->curr_chain_key, hlock->class)) {
     1537                        lookup_chain_cache(chain_key, hlock->class)) {
    15381538                /*
    15391539                 * Check whether last held lock:
    15401540                 *
    static int validate_chain(struct task_st  
    15761576#else
    15771577static inline int validate_chain(struct task_struct *curr,
    15781578                struct lockdep_map *lock, struct held_lock *hlock,
    1579                 int chain_head)
     1579                int chain_head, u64 chain_key)
    15801580{
    15811581        return 1;
    15821582}
    static int __lock_acquire(struct lockdep  
    24502450                chain_head = 1;
    24512451        }
    24522452        chain_key = iterate_chain_key(chain_key, id);
    2453         curr->curr_chain_key = chain_key;
    24542453
    2455         if (!validate_chain(curr, lock, hlock, chain_head))
     2454        if (!validate_chain(curr, lock, hlock, chain_head, chain_key))
    24562455                return 0;
    24572456
     2457        curr->curr_chain_key = chain_key;
    24582458        curr->lockdep_depth++;
    24592459        check_chain_key(curr);
    24602460#ifdef CONFIG_DEBUG_LOCKDEP
  • arch/powerpc/math-emu/math.c

    From ba02946a903015840ef672ccc9dc8620a7e83de6 Mon Sep 17 00:00:00 2001
    From: Kumar Gala <galak@kernel.crashing.org>
    Date: Thu, 11 Oct 2007 17:07:34 -0500
    Subject: POWERPC: Fix handling of stfiwx math emulation
    
    From: Kumar Gala <galak@kernel.crashing.org>
    
    patch ba02946a903015840ef672ccc9dc8620a7e83de6 in mainline
    
    Its legal for the stfiwx instruction to have RA = 0 as part of its
    effective address calculation.  This is illegal for all other XE
    form instructions.
    
    Add code to compute the proper effective address for stfiwx if
    RA = 0 rather than treating it as illegal.
    
    Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    
    ---
     arch/powerpc/math-emu/math.c |   13 +++++++++----
     1 file changed, 9 insertions(+), 4 deletions(-)
    
    a b do_mathemu(struct pt_regs *regs)  
    407407
    408408        case XE:
    409409                idx = (insn >> 16) & 0x1f;
    410                 if (!idx)
    411                         goto illegal;
    412 
    413410                op0 = (void *)&current->thread.fpr[(insn >> 21) & 0x1f];
    414                 op1 = (void *)(regs->gpr[idx] + regs->gpr[(insn >> 11) & 0x1f]);
     411                if (!idx) {
     412                        if (((insn >> 1) & 0x3ff) == STFIWX)
     413                                op1 = (void *)(regs->gpr[(insn >> 11) & 0x1f]);
     414                        else
     415                                goto illegal;
     416                } else {
     417                        op1 = (void *)(regs->gpr[idx] + regs->gpr[(insn >> 11) & 0x1f]);
     418                }
     419
    415420                break;
    416421
    417422        case XEU:
  • net/mac80211/ieee80211.c

    From linville@tuxdriver.com  Wed Oct 31 07:42:39 2007
    From: "John W. Linville" <linville@tuxdriver.com>
    Date: Tue,  9 Oct 2007 22:46:35 -0400
    Subject: mac80211: filter locally-originated multicast frames
    To: stable@kernel.org
    Cc: "John W. Linville" <linville@tuxdriver.com>
    Message-ID: <1191984397477-git-send-email-linville@tuxdriver.com>
    
    
    From: John W. Linville <linville@tuxdriver.com>
    
    patch b331615722779b078822988843ddffd4eaec9f83 in mainline.
    
    In STA mode, the AP will echo our traffic.  This includes multicast
    traffic.
    
    Receiving these frames confuses some protocols and applications,
    notably IPv6 Duplicate Address Detection.
    
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
    Acked-by: Michael Wu <flamingice@sourmilk.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    
    ---
     net/mac80211/ieee80211.c |    5 +++--
     1 file changed, 3 insertions(+), 2 deletions(-)
    
    a b ieee80211_rx_h_data(struct ieee80211_txr  
    28362836                memcpy(dst, hdr->addr1, ETH_ALEN);
    28372837                memcpy(src, hdr->addr3, ETH_ALEN);
    28382838
    2839                 if (sdata->type != IEEE80211_IF_TYPE_STA) {
     2839                if (sdata->type != IEEE80211_IF_TYPE_STA ||
     2840                    (is_multicast_ether_addr(dst) &&
     2841                     !compare_ether_addr(src, dev->dev_addr)))
    28402842                        return TXRX_DROP;
    2841                 }
    28422843                break;
    28432844        case 0:
    28442845                /* DA SA BSSID */
  • drivers/net/wireless/libertas/11d.c

    From linville@tuxdriver.com  Wed Oct 31 07:47:33 2007
    From: "John W. Linville" <linville@tuxdriver.com>
    Date: Tue,  9 Oct 2007 22:46:37 -0400
    Subject: libertas: more endianness breakage
    To: stable@kernel.org
    Cc: Al Viro <viro@zeniv.linux.org.uk>, "John W. Linville" <linville@tuxdriver.com>, Al Viro <viro@ftp.linux.org.uk>
    Message-ID: <11919843974173-git-send-email-linville@tuxdriver.com>
    
    
    From: Al Viro <viro@ftp.linux.org.uk>
    
    based on patch 8362cd413e8116306fafbaf414f0419db0595142 in mainline.
    
    	domain->header.len is le16 and has just been assigned
    cpu_to_le16(arithmetical expression).  And all fields of adapter->logmsg
    are __le32; not a single 16-bit among them...
    	That's incremental to the previous one
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Dan Williams <dcbw@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    
    ---
     drivers/net/wireless/libertas/11d.c  |    2 +-
     drivers/net/wireless/libertas/wext.c |    8 ++++----
     2 files changed, 5 insertions(+), 5 deletions(-)
    
    a b int libertas_cmd_802_11d_domain_info(wla  
    562562                       nr_subband * sizeof(struct ieeetypes_subbandset));
    563563
    564564                cmd->size = cpu_to_le16(sizeof(pdomaininfo->action) +
    565                                              domain->header.len +
     565                                             le16_to_cpu(domain->header.len) +
    566566                                             sizeof(struct mrvlietypesheader) +
    567567                                             S_DS_GEN);
    568568        } else {
  • drivers/net/wireless/libertas/wext.c

    a b static struct iw_statistics *wlan_get_wi  
    973973        /* Quality by TX errors */
    974974        priv->wstats.discard.retries = priv->stats.tx_errors;
    975975
    976         tx_retries = le16_to_cpu(adapter->logmsg.retry);
     976        tx_retries = le32_to_cpu(adapter->logmsg.retry);
    977977
    978978        if (tx_retries > 75)
    979979                tx_qual = (90 - tx_retries) * POOR / 15;
    static struct iw_statistics *wlan_get_wi  
    989989                    (PERFECT - VERY_GOOD) / 50 + VERY_GOOD;
    990990        quality = min(quality, tx_qual);
    991991
    992         priv->wstats.discard.code = le16_to_cpu(adapter->logmsg.wepundecryptable);
    993         priv->wstats.discard.fragment = le16_to_cpu(adapter->logmsg.rxfrag);
     992        priv->wstats.discard.code = le32_to_cpu(adapter->logmsg.wepundecryptable);
     993        priv->wstats.discard.fragment = le32_to_cpu(adapter->logmsg.rxfrag);
    994994        priv->wstats.discard.retries = tx_retries;
    995         priv->wstats.discard.misc = le16_to_cpu(adapter->logmsg.ackfailure);
     995        priv->wstats.discard.misc = le32_to_cpu(adapter->logmsg.ackfailure);
    996996
    997997        /* Calculate quality */
    998998        priv->wstats.qual.qual = max(quality, (u32)100);
  • drivers/net/wireless/libertas/cmd.c

    From linville@tuxdriver.com  Wed Oct 31 07:43:56 2007
    From: "John W. Linville" <linville@tuxdriver.com>
    Date: Tue,  9 Oct 2007 22:46:36 -0400
    Subject: libertas: fix endianness breakage
    To: stable@kernel.org
    Cc: Al Viro <viro@zeniv.linux.org.uk>, "John W. Linville" <linville@tuxdriver.com>, Al Viro <viro@ftp.linux.org.uk>
    Message-ID: <11919843971952-git-send-email-linville@tuxdriver.com>
    
    
    From: Al Viro <viro@ftp.linux.org.uk>
    
    patch 5707708111ca6c4e9a1160acffdc98a98d95e462 in mainline.
    
    	wep->keytype[] is u8
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Dan Williams <dcbw@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    
    ---
     drivers/net/wireless/libertas/cmd.c |    6 ++----
     1 file changed, 2 insertions(+), 4 deletions(-)
    
    a b static int wlan_cmd_802_11_set_wep(wlan_  
    185185
    186186                        switch (pkey->len) {
    187187                        case KEY_LEN_WEP_40:
    188                                 wep->keytype[i] =
    189                                         cpu_to_le16(cmd_type_wep_40_bit);
     188                                wep->keytype[i] = cmd_type_wep_40_bit;
    190189                                memmove(&wep->keymaterial[i], pkey->key,
    191190                                        pkey->len);
    192191                                break;
    193192                        case KEY_LEN_WEP_104:
    194                                 wep->keytype[i] =
    195                                         cpu_to_le16(cmd_type_wep_104_bit);
     193                                wep->keytype[i] = cmd_type_wep_104_bit;
    196194                                memmove(&wep->keymaterial[i], pkey->key,
    197195                                        pkey->len);
    198196                                break;
  • drivers/char/drm/i915_irq.c

    From airlied@linux.ie  Wed Oct 31 08:00:29 2007
    From: Dave Airlie <airlied@linux.ie>
    Date: Tue, 16 Oct 2007 01:05:49 +0100 (IST)
    Subject: i915: fix vbl swap allocation size.
    To: stable@kernel.org
    Message-ID: <alpine.DEB.0.82.0710160104270.13104@skynet.skynet.ie>
    
    From: Dave Airlie <airlied@linux.ie>
    
    This is upstream as 54583bf4efda79388fc13163e35c016c8bc5de81
    
    Oops...
    
    Signed-off-by: Dave Airlie <airlied@linux.ie>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    
    ---
     drivers/char/drm/i915_irq.c |    2 +-
     1 file changed, 1 insertion(+), 1 deletion(-)
    
    a b int i915_vblank_swap(DRM_IOCTL_ARGS)  
    553553                return DRM_ERR(EBUSY);
    554554        }
    555555
    556         vbl_swap = drm_calloc(1, sizeof(vbl_swap), DRM_MEM_DRIVER);
     556        vbl_swap = drm_calloc(1, sizeof(*vbl_swap), DRM_MEM_DRIVER);
    557557
    558558        if (!vbl_swap) {
    559559                DRM_ERROR("Failed to allocate memory to queue swap\n");
  • drivers/hwmon/w83627hf.c

    From khali@linux-fr.org  Wed Oct 31 07:58:46 2007
    From: Jean Delvare <khali@linux-fr.org>
    Date: Mon, 15 Oct 2007 14:32:27 +0200
    Subject: hwmon/w83627hf: Fix setting fan min right after driver load
    To: stable@kernel.org
    Cc: "Mark M. Hoffman" <mhoffman@lightlink.com>
    Message-ID: <20071015143227.6548d45b@hyperion.delvare>
    
    From: Jean Delvare <khali@linux-fr.org>
    
    Already in Linus' tree:
    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c09c5184a26158da32801e89d5849d774605f0dd
    
    We need to read the fan clock dividers at initialization time,
    otherwise the code in store_fan_min() may use uninitialized values.
    That's pretty much the same bug and same fix as for the w83627ehf
    driver last month.
    
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    
    ---
     drivers/hwmon/w83627hf.c |   34 ++++++++++++++++++++++------------
     1 file changed, 22 insertions(+), 12 deletions(-)
    
    a b static int __devexit w83627hf_remove(str  
    391391
    392392static int w83627hf_read_value(struct w83627hf_data *data, u16 reg);
    393393static int w83627hf_write_value(struct w83627hf_data *data, u16 reg, u16 value);
     394static void w83627hf_update_fan_div(struct w83627hf_data *data);
    394395static struct w83627hf_data *w83627hf_update_device(struct device *dev);
    395396static void w83627hf_init_device(struct platform_device *pdev);
    396397
    static int __devinit w83627hf_probe(stru  
    12441245        data->fan_min[0] = w83627hf_read_value(data, W83781D_REG_FAN_MIN(1));
    12451246        data->fan_min[1] = w83627hf_read_value(data, W83781D_REG_FAN_MIN(2));
    12461247        data->fan_min[2] = w83627hf_read_value(data, W83781D_REG_FAN_MIN(3));
     1248        w83627hf_update_fan_div(data);
    12471249
    12481250        /* Register common device attributes */
    12491251        if ((err = sysfs_create_group(&dev->kobj, &w83627hf_group)))
    static void __devinit w83627hf_init_devi  
    15561558                            | 0x01);
    15571559}
    15581560
     1561static void w83627hf_update_fan_div(struct w83627hf_data *data)
     1562{
     1563        int reg;
     1564
     1565        reg = w83627hf_read_value(data, W83781D_REG_VID_FANDIV);
     1566        data->fan_div[0] = (reg >> 4) & 0x03;
     1567        data->fan_div[1] = (reg >> 6) & 0x03;
     1568        if (data->type != w83697hf) {
     1569                data->fan_div[2] = (w83627hf_read_value(data,
     1570                                       W83781D_REG_PIN) >> 6) & 0x03;
     1571        }
     1572        reg = w83627hf_read_value(data, W83781D_REG_VBAT);
     1573        data->fan_div[0] |= (reg >> 3) & 0x04;
     1574        data->fan_div[1] |= (reg >> 4) & 0x04;
     1575        if (data->type != w83697hf)
     1576                data->fan_div[2] |= (reg >> 5) & 0x04;
     1577}
     1578
    15591579static struct w83627hf_data *w83627hf_update_device(struct device *dev)
    15601580{
    15611581        struct w83627hf_data *data = dev_get_drvdata(dev);
    static struct w83627hf_data *w83627hf_up  
    16331653                          w83627hf_read_value(data, W83781D_REG_TEMP_HYST(3));
    16341654                }
    16351655
    1636                 i = w83627hf_read_value(data, W83781D_REG_VID_FANDIV);
    1637                 data->fan_div[0] = (i >> 4) & 0x03;
    1638                 data->fan_div[1] = (i >> 6) & 0x03;
    1639                 if (data->type != w83697hf) {
    1640                         data->fan_div[2] = (w83627hf_read_value(data,
    1641                                                W83781D_REG_PIN) >> 6) & 0x03;
    1642                 }
    1643                 i = w83627hf_read_value(data, W83781D_REG_VBAT);
    1644                 data->fan_div[0] |= (i >> 3) & 0x04;
    1645                 data->fan_div[1] |= (i >> 4) & 0x04;
    1646                 if (data->type != w83697hf)
    1647                         data->fan_div[2] |= (i >> 5) & 0x04;
     1656                w83627hf_update_fan_div(data);
     1657
    16481658                data->alarms =
    16491659                    w83627hf_read_value(data, W83781D_REG_ALARM1) |
    16501660                    (w83627hf_read_value(data, W83781D_REG_ALARM2) << 8) |
  • drivers/hwmon/w83627hf.c

    From khali@linux-fr.org  Wed Oct 31 07:59:11 2007
    From: Jean Delvare <khali@linux-fr.org>
    Date: Mon, 15 Oct 2007 15:02:42 +0200
    Subject: hwmon/w83627hf: Don't assume bank 0
    To: stable@kernel.org
    Cc: "Mark M. Hoffman" <mhoffman@lightlink.com>
    Message-ID: <20071015150242.643837b8@hyperion.delvare>
    
    From: Jean Delvare <khali@linux-fr.org>
    
    Already in Linus' tree:
    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d58df9cd788e6fb4962e1c8d5ba7b8b95d639a44
    
    The bank switching code assumes that the bank selector is set to 0
    when the driver is loaded. This might not be the case. This is exactly
    the same bug as was fixed in the w83627ehf driver two months ago:
    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0956895aa6f8dc6a33210967252fd7787652537d
    
    In practice, this bug was causing the sensor thermal types to be
    improperly reported for my W83627THF the first time I was loading the
    w83627hf driver. From the driver history, I'd say that it has been
    broken since September 2005 (when we stopped resetting the chip by
    default at driver load.)
    
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    
    ---
     drivers/hwmon/w83627hf.c |   44 ++++++++++++++++++++++----------------------
     1 file changed, 22 insertions(+), 22 deletions(-)
    
    a b static int __devexit w83627hf_remove(str  
    13351335}
    13361336
    13371337
     1338/* Registers 0x50-0x5f are banked */
     1339static inline void w83627hf_set_bank(struct w83627hf_data *data, u16 reg)
     1340{
     1341        if ((reg & 0x00f0) == 0x50) {
     1342                outb_p(W83781D_REG_BANK, data->addr + W83781D_ADDR_REG_OFFSET);
     1343                outb_p(reg >> 8, data->addr + W83781D_DATA_REG_OFFSET);
     1344        }
     1345}
     1346
     1347/* Not strictly necessary, but play it safe for now */
     1348static inline void w83627hf_reset_bank(struct w83627hf_data *data, u16 reg)
     1349{
     1350        if (reg & 0xff00) {
     1351                outb_p(W83781D_REG_BANK, data->addr + W83781D_ADDR_REG_OFFSET);
     1352                outb_p(0, data->addr + W83781D_DATA_REG_OFFSET);
     1353        }
     1354}
     1355
    13381356static int w83627hf_read_value(struct w83627hf_data *data, u16 reg)
    13391357{
    13401358        int res, word_sized;
    static int w83627hf_read_value(struct w8  
    13451363                  && (((reg & 0x00ff) == 0x50)
    13461364                   || ((reg & 0x00ff) == 0x53)
    13471365                   || ((reg & 0x00ff) == 0x55));
    1348         if (reg & 0xff00) {
    1349                 outb_p(W83781D_REG_BANK,
    1350                        data->addr + W83781D_ADDR_REG_OFFSET);
    1351                 outb_p(reg >> 8,
    1352                        data->addr + W83781D_DATA_REG_OFFSET);
    1353         }
     1366        w83627hf_set_bank(data, reg);
    13541367        outb_p(reg & 0xff, data->addr + W83781D_ADDR_REG_OFFSET);
    13551368        res = inb_p(data->addr + W83781D_DATA_REG_OFFSET);
    13561369        if (word_sized) {
    static int w83627hf_read_value(struct w8  
    13601373                    (res << 8) + inb_p(data->addr +
    13611374                                       W83781D_DATA_REG_OFFSET);
    13621375        }
    1363         if (reg & 0xff00) {
    1364                 outb_p(W83781D_REG_BANK,
    1365                        data->addr + W83781D_ADDR_REG_OFFSET);
    1366                 outb_p(0, data->addr + W83781D_DATA_REG_OFFSET);
    1367         }
     1376        w83627hf_reset_bank(data, reg);
    13681377        mutex_unlock(&data->lock);
    13691378        return res;
    13701379}
    static int w83627hf_write_value(struct w  
    14351444                   || ((reg & 0xff00) == 0x200))
    14361445                  && (((reg & 0x00ff) == 0x53)
    14371446                   || ((reg & 0x00ff) == 0x55));
    1438         if (reg & 0xff00) {
    1439                 outb_p(W83781D_REG_BANK,
    1440                        data->addr + W83781D_ADDR_REG_OFFSET);
    1441                 outb_p(reg >> 8,
    1442                        data->addr + W83781D_DATA_REG_OFFSET);
    1443         }
     1447        w83627hf_set_bank(data, reg);
    14441448        outb_p(reg & 0xff, data->addr + W83781D_ADDR_REG_OFFSET);
    14451449        if (word_sized) {
    14461450                outb_p(value >> 8,
    static int w83627hf_write_value(struct w  
    14501454        }
    14511455        outb_p(value & 0xff,
    14521456               data->addr + W83781D_DATA_REG_OFFSET);
    1453         if (reg & 0xff00) {
    1454                 outb_p(W83781D_REG_BANK,
    1455                        data->addr + W83781D_ADDR_REG_OFFSET);
    1456                 outb_p(0, data->addr + W83781D_DATA_REG_OFFSET);
    1457         }
     1457        w83627hf_reset_bank(data, reg);
    14581458        mutex_unlock(&data->lock);
    14591459        return 0;
    14601460}
  • drivers/hwmon/lm87.c

    From khali@linux-fr.org  Wed Oct 31 07:57:45 2007
    From: Jean Delvare <khali@linux-fr.org>
    Date: Mon, 15 Oct 2007 13:49:50 +0200
    Subject: hwmon/lm87: Fix a division by zero
    To: stable@kernel.org
    Cc: "Mark M. Hoffman" <mhoffman@lightlink.com>
    Message-ID: <20071015134950.15b1e97d@hyperion.delvare>
    
    From: Jean Delvare <khali@linux-fr.org>
    
    Already in Linus' tree:
    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b965d4b7f614522170af6a7e450be0333792ccd2
    
    Missing parentheses in the definition of FAN_FROM_REG cause a
    division by zero for a specific register value.
    
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Acked-by: Hans de Goede <j.w.r.degoede@hhs.nl>
    Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    
    ---
     drivers/hwmon/lm87.c |    2 +-
     1 file changed, 1 insertion(+), 1 deletion(-)
    
    a b static u8 LM87_REG_TEMP_LOW[3] = { 0x3A,  
    129129                                 (((val) < 0 ? (val)-500 : (val)+500) / 1000))
    130130
    131131#define FAN_FROM_REG(reg,div)   ((reg) == 255 || (reg) == 0 ? 0 : \
    132                                  1350000 + (reg)*(div) / 2) / ((reg)*(div))
     132                                 (1350000 + (reg)*(div) / 2) / ((reg)*(div)))
    133133#define FAN_TO_REG(val,div)     ((val)*(div) * 255 <= 1350000 ? 255 : \
    134134                                 (1350000 + (val)*(div) / 2) / ((val)*(div)))
    135135
  • drivers/hwmon/lm87.c

    From khali@linux-fr.org  Wed Oct 31 07:58:20 2007
    From: Jean Delvare <khali@linux-fr.org>
    Date: Mon, 15 Oct 2007 14:02:36 +0200
    Subject: hwmon/lm87: Disable VID when it should be
    To: stable@kernel.org
    Cc: "Mark M. Hoffman" <mhoffman@lightlink.com>
    Message-ID: <20071015140236.06b4d97a@hyperion.delvare>
    
    From: Jean Delvare <khali@linux-fr.org>
    
    Already in Linus' tree:
    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=889af3d5d9586db795a06c619e416b4baee11da8
    
    A stupid bit shifting bug caused the VID value to be always exported
    even when the hardware is configured for something different.
    
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    
    ---
     drivers/hwmon/lm87.c |    2 +-
     1 file changed, 1 insertion(+), 1 deletion(-)
    
    a b static u8 LM87_REG_TEMP_LOW[3] = { 0x3A,  
    145145#define CHAN_NO_FAN(nr)         (1 << (nr))
    146146#define CHAN_TEMP3              (1 << 2)
    147147#define CHAN_VCC_5V             (1 << 3)
    148 #define CHAN_NO_VID             (1 << 8)
     148#define CHAN_NO_VID             (1 << 7)
    149149
    150150/*
    151151 * Functions declaration
  • net/mac80211/ieee80211.c

    From linville@tuxdriver.com  Wed Oct 31 07:40:46 2007
    From: "John W. Linville" <linville@tuxdriver.com>
    Date: Tue,  9 Oct 2007 22:46:33 -0400
    Subject: Add get_unaligned to ieee80211_get_radiotap_len
    To: stable@kernel.org
    Cc: warmcat <andy@warmcat.com>, "John W. Linville" <linville@tuxdriver.com>
    Message-ID: <11919843974140-git-send-email-linville@tuxdriver.com>
    
    
    From: Andy Green <andy@warmcat.com>
    
    patch dfe6e81deaa79c85086c0cc8d85b229e444ab97f in mainline.
    
    ieee80211_get_radiotap_len() tries to dereference radiotap length without
    taking care that it is completely unaligned and get_unaligned()
    is required.
    
    Signed-off-by: Andy Green <andy@warmcat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    
    ---
     net/mac80211/ieee80211.c |    2 +-
     1 file changed, 1 insertion(+), 1 deletion(-)
    
    a b static int ieee80211_get_radiotap_len(st  
    350350        struct ieee80211_radiotap_header *hdr =
    351351                (struct ieee80211_radiotap_header *) skb->data;
    352352
    353         return le16_to_cpu(hdr->it_len);
     353        return le16_to_cpu(get_unaligned(&hdr->it_len));
    354354}
    355355
    356356#ifdef CONFIG_MAC80211_LOWTX_FRAME_DUMP
  • net/mac80211/ieee80211.c

    From linville@tuxdriver.com  Wed Oct 31 09:02:49 2007
    From: Andy Green <andy@warmcat.com>
    Date: Tue,  9 Oct 2007 22:46:34 -0400
    Subject: mac80211: Improve sanity checks on injected packets
    To: stable@kernel.org
    Cc: warmcat <andy@warmcat.com>, "John W. Linville" <linville@tuxdriver.com>
    Message-ID: <11919843971189-git-send-email-linville@tuxdriver.com>
    
    From: Andy Green <andy@warmcat.com>
    
    patch 9b8a74e3482f9fc077a88c13fa0ceca8feb0b772 in mainline.
    
    Michael Wu noticed that the skb length checking is not taken care of enough when
    a packet is presented on the Monitor interface for injection.
    
    This patch improves the sanity checking and removes fake offsets placed
    into the skb network and transport header.
    
    Signed-off-by: Andy Green <andy@warmcat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    
    ---
     net/mac80211/ieee80211.c |   48 +++++++++++++++++++++++++++--------------------
     1 file changed, 28 insertions(+), 20 deletions(-)
    
    a b int ieee80211_monitor_start_xmit(struct  
    16801680        struct ieee80211_tx_packet_data *pkt_data;
    16811681        struct ieee80211_radiotap_header *prthdr =
    16821682                (struct ieee80211_radiotap_header *)skb->data;
    1683         u16 len;
     1683        u16 len_rthdr;
    16841684
    1685         /*
    1686          * there must be a radiotap header at the
    1687          * start in this case
    1688          */
    1689         if (unlikely(prthdr->it_version)) {
    1690                 /* only version 0 is supported */
    1691                 dev_kfree_skb(skb);
    1692                 return NETDEV_TX_OK;
    1693         }
     1685        /* check for not even having the fixed radiotap header part */
     1686        if (unlikely(skb->len < sizeof(struct ieee80211_radiotap_header)))
     1687                goto fail; /* too short to be possibly valid */
     1688
     1689        /* is it a header version we can trust to find length from? */
     1690        if (unlikely(prthdr->it_version))
     1691                goto fail; /* only version 0 is supported */
     1692
     1693        /* then there must be a radiotap header with a length we can use */
     1694        len_rthdr = ieee80211_get_radiotap_len(skb);
     1695
     1696        /* does the skb contain enough to deliver on the alleged length? */
     1697        if (unlikely(skb->len < len_rthdr))
     1698                goto fail; /* skb too short for claimed rt header extent */
    16941699
    16951700        skb->dev = local->mdev;
    16961701
    16971702        pkt_data = (struct ieee80211_tx_packet_data *)skb->cb;
    16981703        memset(pkt_data, 0, sizeof(*pkt_data));
     1704        /* needed because we set skb device to master */
    16991705        pkt_data->ifindex = dev->ifindex;
     1706
    17001707        pkt_data->mgmt_iface = 0;
    17011708        pkt_data->do_not_encrypt = 1;
    17021709
    1703         /* above needed because we set skb device to master */
    1704 
    17051710        /*
    17061711         * fix up the pointers accounting for the radiotap
    17071712         * header still being in there.  We are being given
    17081713         * a precooked IEEE80211 header so no need for
    17091714         * normal processing
    17101715         */
    1711         len = le16_to_cpu(get_unaligned(&prthdr->it_len));
    1712         skb_set_mac_header(skb, len);
    1713         skb_set_network_header(skb, len + sizeof(struct ieee80211_hdr));
    1714         skb_set_transport_header(skb, len + sizeof(struct ieee80211_hdr));
    1715 
     1716        skb_set_mac_header(skb, len_rthdr);
    17161717        /*
    1717          * pass the radiotap header up to
    1718          * the next stage intact
     1718         * these are just fixed to the end of the rt area since we
     1719         * don't have any better information and at this point, nobody cares
    17191720         */
    1720         dev_queue_xmit(skb);
     1721        skb_set_network_header(skb, len_rthdr);
     1722        skb_set_transport_header(skb, len_rthdr);
    17211723
     1724        /* pass the radiotap header up to the next stage intact */
     1725        dev_queue_xmit(skb);
    17221726        return NETDEV_TX_OK;
     1727
     1728fail:
     1729        dev_kfree_skb(skb);
     1730        return NETDEV_TX_OK; /* meaning, we dealt with the skb */
    17231731}
    17241732
    17251733
  • mm/filemap.c

    From 5307cc1aa53850f017c8053db034cf950b670ac9 Mon Sep 17 00:00:00 2001
    From: Linus Torvalds <torvalds@woody.linux-foundation.org>
    Date: Wed, 31 Oct 2007 09:19:46 -0700
    Subject: Remove broken ptrace() special-case code from file mapping
    
    The kernel has for random historical reasons allowed ptrace() accesses
    to access (and insert) pages into the page cache above the size of the
    file.
    
    However, Nick broke that by mistake when doing the new fault handling in
    commit 54cb8821de07f2ffcd28c380ce9b93d5784b40d7 ("mm: merge populate and
    nopage into fault (fixes nonlinear)".  The breakage caused a hang with
    gdb when trying to access the invalid page.
    
    The ptrace "feature" really isn't worth resurrecting, since it really is
    wrong both from a portability _and_ from an internal page cache validity
    standpoint.  So this removes those old broken remnants, and fixes the
    ptrace() hang in the process.
    
    Noticed and bisected by Duane Griffin, who also supplied a test-case
    (quoth Nick: "Well that's probably the best bug report I've ever had,
    thanks Duane!").
    
    Cc: Duane Griffin <duaneg@dghda.com>
    Acked-by: Nick Piggin <npiggin@suse.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    
    ---
     mm/filemap.c |   13 ++-----------
     1 file changed, 2 insertions(+), 11 deletions(-)
    
    a b int filemap_fault(struct vm_area_struct  
    13121312
    13131313        size = (i_size_read(inode) + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
    13141314        if (vmf->pgoff >= size)
    1315                 goto outside_data_content;
     1315                return VM_FAULT_SIGBUS;
    13161316
    13171317        /* If we don't want any read-ahead, don't bother */
    13181318        if (VM_RandomReadHint(vma))
    retry_find:  
    13891389        if (unlikely(vmf->pgoff >= size)) {
    13901390                unlock_page(page);
    13911391                page_cache_release(page);
    1392                 goto outside_data_content;
     1392                return VM_FAULT_SIGBUS;
    13931393        }
    13941394
    13951395        /*
    retry_find:  
    14001400        vmf->page = page;
    14011401        return ret | VM_FAULT_LOCKED;
    14021402
    1403 outside_data_content:
    1404         /*
    1405          * An external ptracer can access pages that normally aren't
    1406          * accessible..
    1407          */
    1408         if (vma->vm_mm == current->mm)
    1409                 return VM_FAULT_SIGBUS;
    1410 
    1411         /* Fall through to the non-read-ahead case */
    14121403no_cached_page:
    14131404        /*
    14141405         * We're only likely to ever get here if MADV_RANDOM is in
  • arch/x86_64/mm/pageattr.c

    From 9a24d04a3c26c223f22493492c5c9085b8773d4a Mon Sep 17 00:00:00 2001
    From: Ingo Molnar <mingo@elte.hu>
    Date: Fri, 19 Oct 2007 12:19:26 +0200
    Subject: [PATCH] x86: fix global_flush_tlb() bug
    
    From: Ingo Molnar <mingo@elte.hu>
    
    patch 9a24d04a3c26c223f22493492c5c9085b8773d4a upstream
    
    While we were reviewing pageattr_32/64.c for unification,
    Thomas Gleixner noticed the following serious SMP bug in
    global_flush_tlb():
    
    	down_read(&init_mm.mmap_sem);
    	list_replace_init(&deferred_pages, &l);
    	up_read(&init_mm.mmap_sem);
    
    this is SMP-unsafe because list_replace_init() done on two CPUs in
    parallel can corrupt the list.
    
    This bug has been introduced about a year ago in the 64-bit tree:
    
           commit ea7322decb974a4a3e804f96a0201e893ff88ce3
           Author: Andi Kleen <ak@suse.de>
           Date:   Thu Dec 7 02:14:05 2006 +0100
    
           [PATCH] x86-64: Speed and clean up cache flushing in change_page_attr
    
                    down_read(&init_mm.mmap_sem);
            -       dpage = xchg(&deferred_pages, NULL);
            +       list_replace_init(&deferred_pages, &l);
                    up_read(&init_mm.mmap_sem);
    
    the xchg() based version was SMP-safe, but list_replace_init() is not.
    So this "cleanup" introduced a nasty bug.
    
    why this bug never become prominent is a mystery - it can probably be
    explained with the (still) relative obscurity of the x86_64 architecture.
    
    the safe fix for now is to write-lock init_mm.mmap_sem.
    
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Andi Kleen <ak@suse.de>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    
    ---
     arch/x86_64/mm/pageattr.c |    9 +++++++--
     1 file changed, 7 insertions(+), 2 deletions(-)
    
    a b void global_flush_tlb(void)  
    229229        struct page *pg, *next;
    230230        struct list_head l;
    231231
    232         down_read(&init_mm.mmap_sem);
     232        /*
     233         * Write-protect the semaphore, to exclude two contexts
     234         * doing a list_replace_init() call in parallel and to
     235         * exclude new additions to the deferred_pages list:
     236         */
     237        down_write(&init_mm.mmap_sem);
    233238        list_replace_init(&deferred_pages, &l);
    234         up_read(&init_mm.mmap_sem);
     239        up_write(&init_mm.mmap_sem);
    235240
    236241        flush_map(&l);
    237242
  • kernel/params.c

    From faf8c714f4508207a9c81cc94dafc76ed6680b44 Mon Sep 17 00:00:00 2001
    From: Dave Young <hidave.darkstar@gmail.com>
    Date: Thu, 18 Oct 2007 03:05:07 -0700
    Subject: param_sysfs_builtin memchr argument fix
    Message-ID: <4720EBA6.60803@redhat.com>
    
    From: Dave Young <hidave.darkstar@gmail.com>
    
    patch faf8c714f4508207a9c81cc94dafc76ed6680b44 in mainline.
    
    If memchr argument is longer than strlen(kp->name), there will be some
    weird result.
    
    It will casuse duplicate filenames in sysfs for the "nousb".  kernel
    warning messages are as bellow:
    
    sysfs: duplicate filename 'usbcore' can not be created
    WARNING: at fs/sysfs/dir.c:416 sysfs_add_one()
     [<c01c4750>] sysfs_add_one+0xa0/0xe0
     [<c01c4ab8>] create_dir+0x48/0xb0
     [<c01c4b69>] sysfs_create_dir+0x29/0x50
     [<c024e0fb>] create_dir+0x1b/0x50
     [<c024e3b6>] kobject_add+0x46/0x150
     [<c024e2da>] kobject_init+0x3a/0x80
     [<c053b880>] kernel_param_sysfs_setup+0x50/0xb0
     [<c053b9ce>] param_sysfs_builtin+0xee/0x130
     [<c053ba33>] param_sysfs_init+0x23/0x60
     [<c024d062>] __next_cpu+0x12/0x20
     [<c052aa30>] kernel_init+0x0/0xb0
     [<c052aa30>] kernel_init+0x0/0xb0
     [<c052a856>] do_initcalls+0x46/0x1e0
     [<c01bdb12>] create_proc_entry+0x52/0x90
     [<c0158d4c>] register_irq_proc+0x9c/0xc0
     [<c01bda94>] proc_mkdir_mode+0x34/0x50
     [<c052aa30>] kernel_init+0x0/0xb0
     [<c052aa92>] kernel_init+0x62/0xb0
     [<c0104f83>] kernel_thread_helper+0x7/0x14
     =======================
    kobject_add failed for usbcore with -EEXIST, don't try to register things with the same name in the same directory.
     [<c024e466>] kobject_add+0xf6/0x150
     [<c053b880>] kernel_param_sysfs_setup+0x50/0xb0
     [<c053b9ce>] param_sysfs_builtin+0xee/0x130
     [<c053ba33>] param_sysfs_init+0x23/0x60
     [<c024d062>] __next_cpu+0x12/0x20
     [<c052aa30>] kernel_init+0x0/0xb0
     [<c052aa30>] kernel_init+0x0/0xb0
     [<c052a856>] do_initcalls+0x46/0x1e0
     [<c01bdb12>] create_proc_entry+0x52/0x90
     [<c0158d4c>] register_irq_proc+0x9c/0xc0
     [<c01bda94>] proc_mkdir_mode+0x34/0x50
     [<c052aa30>] kernel_init+0x0/0xb0
     [<c052aa92>] kernel_init+0x62/0xb0
     [<c0104f83>] kernel_thread_helper+0x7/0x14
     =======================
    Module 'usbcore' failed to be added to sysfs, error number -17
    The system will be unstable now.
    
    Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
    Cc: Greg KH <greg@kroah.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Chuck Ebbert <cebbert@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    
    ---
     kernel/params.c |    8 +++++++-
     1 file changed, 7 insertions(+), 1 deletion(-)
    
    a b static void __init param_sysfs_builtin(v  
    595595
    596596        for (i=0; i < __stop___param - __start___param; i++) {
    597597                char *dot;
     598                size_t kplen;
    598599
    599600                kp = &__start___param[i];
     601                kplen = strlen(kp->name);
    600602
    601603                /* We do not handle args without periods. */
    602                 dot = memchr(kp->name, '.', MAX_KBUILD_MODNAME);
     604                if (kplen > MAX_KBUILD_MODNAME) {
     605                        DEBUGP("kernel parameter name is too long: %s\n", kp->name);
     606                        continue;
     607                }
     608                dot = memchr(kp->name, '.', kplen);
    603609                if (!dot) {
    604610                        DEBUGP("couldn't find period in %s\n", kp->name);
    605611                        continue;
  • fs/minix/itree_v1.c

    From f44ec6f3f89889a469773b1fd894f8fcc07c29cf Mon Sep 17 00:00:00 2001
    From: Eric Sandeen <sandeen@redhat.com>
    Date: Tue, 16 Oct 2007 23:27:15 -0700
    Subject: minixfs: limit minixfs printks on corrupted dir i_size (CVE-2006-6058)
    Message-ID: <47276102.30608@redhat.com>
    
    From: Eric Sandeen <sandeen@redhat.com>
    
    patch f44ec6f3f89889a469773b1fd894f8fcc07c29cf upstream.
    
    This attempts to address CVE-2006-6058
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6058
    
    first reported at http://projects.info-pull.com/mokb/MOKB-17-11-2006.html
    
    Essentially a corrupted minix dir inode reporting a very large
    i_size will loop for a very long time in minix_readdir, minix_find_entry,
    etc, because on EIO they just move on to try the next page.  This is
    under the BKL, printk-storming as well.  This can lock up the machine
    for a very long time.  Simply ratelimiting the printks gets things back
    under control.  Make the message a bit more informative while we're here.
    
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Cc: Bodo Eggert <7eggert@gmx.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    
    ---
     fs/minix/itree_v1.c |    9 +++++++--
     fs/minix/itree_v2.c |    9 +++++++--
     2 files changed, 14 insertions(+), 4 deletions(-)
    
    a b static inline block_t *i_data(struct ino  
    2323static int block_to_path(struct inode * inode, long block, int offsets[DEPTH])
    2424{
    2525        int n = 0;
     26        char b[BDEVNAME_SIZE];
    2627
    2728        if (block < 0) {
    28                 printk("minix_bmap: block<0\n");
     29                printk("MINIX-fs: block_to_path: block %ld < 0 on dev %s\n",
     30                        block, bdevname(inode->i_sb->s_bdev, b));
    2931        } else if (block >= (minix_sb(inode->i_sb)->s_max_size/BLOCK_SIZE)) {
    30                 printk("minix_bmap: block>big\n");
     32                if (printk_ratelimit())
     33                        printk("MINIX-fs: block_to_path: "
     34                               "block %ld too big on dev %s\n",
     35                                block, bdevname(inode->i_sb->s_bdev, b));
    3136        } else if (block < 7) {
    3237                offsets[n++] = block;
    3338        } else if ((block -= 7) < 512) {
  • fs/minix/itree_v2.c

    a b static inline block_t *i_data(struct ino  
    2323static int block_to_path(struct inode * inode, long block, int offsets[DEPTH])
    2424{
    2525        int n = 0;
     26        char b[BDEVNAME_SIZE];
    2627        struct super_block *sb = inode->i_sb;
    2728
    2829        if (block < 0) {
    29                 printk("minix_bmap: block<0\n");
     30                printk("MINIX-fs: block_to_path: block %ld < 0 on dev %s\n",
     31                        block, bdevname(sb->s_bdev, b));
    3032        } else if (block >= (minix_sb(inode->i_sb)->s_max_size/sb->s_blocksize)) {
    31                 printk("minix_bmap: block>big\n");
     33                if (printk_ratelimit())
     34                        printk("MINIX-fs: block_to_path: "
     35                               "block %ld too big on dev %s\n",
     36                                block, bdevname(sb->s_bdev, b));
    3237        } else if (block < 7) {
    3338                offsets[n++] = block;
    3439        } else if ((block -= 7) < 256) {
  • drivers/infiniband/core/uverbs_cmd.c

    From stable-bounces@linux.kernel.org Sun Oct 28 10:15:04 2007
    From: Roland Dreier <rdreier@cisco.com>
    Date: Sun, 28 Oct 2007 10:14:32 -0700
    Subject: IB/uverbs: Fix checking of userspace object ownership
    To: stable@kernel.org
    Message-ID: <ada7il7xitj.fsf@cisco.com>
    
    From: Roland Dreier <rolandd@cisco.com>
    
    Upstream as cbfb50e6e2e9c580848c0f51d37c24cdfb1cb704
    
    Commit 9ead190b ("IB/uverbs: Don't serialize with ib_uverbs_idr_mutex")
    rewrote how userspace objects are looked up in the uverbs module's
    idrs, and introduced a severe bug in the process: there is no checking
    that an operation is being performed by the right process any more.
    Fix this by adding the missing check of uobj->context in __idr_get_uobj().
    
    Apparently everyone is being very careful to only touch their own
    objects, because this bug was introduced in June 2006 in 2.6.18, and
    has gone undetected until now.
    
    Signed-off-by: Roland Dreier <rolandd@cisco.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    
    ---
     drivers/infiniband/core/uverbs_cmd.c |    8 ++++++--
     1 file changed, 6 insertions(+), 2 deletions(-)
    
    a b static struct ib_uobject *__idr_get_uobj  
    147147
    148148        spin_lock(&ib_uverbs_idr_lock);
    149149        uobj = idr_find(idr, id);
    150         if (uobj)
    151                 kref_get(&uobj->ref);
     150        if (uobj) {
     151                if (uobj->context == context)
     152                        kref_get(&uobj->ref);
     153                else
     154                        uobj = NULL;
     155        }
    152156        spin_unlock(&ib_uverbs_idr_lock);
    153157
    154158        return uobj;

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy