1. 04 2月, 2011 3 次提交
    • J
      USB SL811HS HCD: Fix memory leak in sl811h_urb_enqueue() · 2bd15f1f
      Jesper Juhl 提交于
      In drivers/usb/host/sl811-hcd.c::sl811h_urb_enqueue(), memory is allocated
      with kzalloc() and assigned to 'ep'. If we leave via the 'fail' label due
      to 'if (ep->maxpacket > H_MAXPACKET)', then 'ep' will go out of scope
      without having been assigned to anything, so we'll leak the memory we
      allocated.
      This patch fixes the leak by simply calling kfree(ep); before jumping to
      the 'fail' label.
      Signed-off-by: NJesper Juhl <jj@chaosbits.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      2bd15f1f
    • I
      USB: ti_usb: fix module removal · b14de385
      Ionut Nicu 提交于
      If usb_deregister() is called after usb_serial_deregister() when
      the device is plugged in, the following Oops occurs:
      
      [   95.337377] BUG: unable to handle kernel NULL pointer dereference at 00000010
      [   95.338236] IP: [<c0776b2d>] klist_put+0x12/0x62
      [   95.338356] *pdpt = 000000003001a001 *pde = 0000000000000000
      [   95.338356] Oops: 0000 [#1] SMP
      [   95.340499] last sysfs file: /sys/devices/pci0000:00/0000:00:1d.2/usb8/idVendor
      [   95.340499] Modules linked in: ti_usb_3410_5052(-) usbserial cpufreq_ondemand acpi_cpufreq mperf iptable_nat nf_nat iptable_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipv6 uinput arc4 ecb iwlagn iwlcore mac80211 cfg80211 microcode pcspkr acer_wmi joydev wmi sky2 [last unloaded: scsi_wait_scan]
      [   95.341908]
      [   95.341908] Pid: 1532, comm: modprobe Not tainted 2.6.37-rc7+ #6 Eiger                          /Aspire 5930
      [   95.341908] EIP: 0060:[<c0776b2d>] EFLAGS: 00010246 CPU: 0
      [   95.341908] EIP is at klist_put+0x12/0x62
      [   95.341908] EAX: 00000000 EBX: eedc0c84 ECX: c09c21b4 EDX: 00000001
      [   95.341908] ESI: 00000000 EDI: efaa0c1c EBP: f214fe2c ESP: f214fe1c
      [   95.341908]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      [   95.341908] Process modprobe (pid: 1532, ti=f214e000 task=efaaf080 task.ti=f214e000)
      [   95.341908] Stack:
      [   95.341908]  f214fe24 eedc0c84 efaaf080 efaa0c1c f214fe34 c0776ba8 f214fe5c c0776c76
      [   95.341908]  c09c21b4 c09c21b4 eedc0c84 efaaf080 00000000 c0634398 eafe2d1c f7b515f0
      [   95.341908]  f214fe6c c0631b5c eafe2d50 eafe2d1c f214fe7c c0631ba2 eafe2d1c eafe2c00
      [   95.341908] Call Trace:
      [   95.341908]  [<c0776ba8>] ? klist_del+0xd/0xf
      [   95.341908]  [<c0776c76>] ? klist_remove+0x48/0x74
      [   95.341908]  [<c0634398>] ? devres_release_all+0x49/0x51
      [   95.341908]  [<c0631b5c>] ? __device_release_driver+0x7b/0xa4
      [   95.341908]  [<c0631ba2>] ? device_release_driver+0x1d/0x28
      [   95.341908]  [<c06317c4>] ? bus_remove_device+0x92/0xa1
      [   95.341908]  [<c062f3d8>] ? device_del+0xf9/0x13e
      [   95.341908]  [<f7b06146>] ? usb_serial_disconnect+0xd9/0x116 [usbserial]
      [   95.341908]  [<c0681e3f>] ? usb_disable_interface+0x32/0x40
      [   95.341908]  [<c0683972>] ? usb_unbind_interface+0x48/0xfd
      [   95.341908]  [<c0631b43>] ? __device_release_driver+0x62/0xa4
      [   95.341908]  [<c06320b9>] ? driver_detach+0x62/0x81
      [   95.341908]  [<c0631a41>] ? bus_remove_driver+0x8f/0xae
      [   95.341908]  [<c063214c>] ? driver_unregister+0x50/0x57
      [   95.341908]  [<c0682f95>] ? usb_deregister+0x77/0x84
      [   95.341908]  [<f7b505b6>] ? ti_exit+0x26/0x28 [ti_usb_3410_5052]
      [   95.341908]  [<c046a307>] ? sys_delete_module+0x181/0x1de
      [   95.341908]  [<c04e2727>] ? path_put+0x1a/0x1d
      [   95.341908]  [<c047f4c5>] ? audit_syscall_entry+0x116/0x138
      [   95.341908]  [<c04094df>] ? sysenter_do_call+0x12/0x28
      [   95.341908] Code: 00 83 7d f0 00 74 09 85 f6 74 05 89 f0 ff 55 f0 8b 43 04 5a 5b 5e 5f 5d c3 55 89 e5 57 56 53 89 c3 83 ec 04 8b 30 83 e6 fe 89 f0 <8b> 7e 10 88 55 f0 e8 47 26 01 00 8a 55 f0 84 d2 74 17 f6 03 01
      [   95.341908] EIP: [<c0776b2d>] klist_put+0x12/0x62 SS:ESP 0068:f214fe1c
      [   95.341908] CR2: 0000000000000010
      [   95.342357] ---[ end trace 8124d00ad871ad18 ]---
      Signed-off-by: NIonut Nicu <ionut.nicu@mindbit.ro>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b14de385
    • B
      USB: io_edgeport: fix the reported firmware major and minor · 271c1150
      Bjørn Mork 提交于
      The major and minor number saved in the product_info structure
      were copied from the address instead of the data, causing an
      inconsistency in the reported versions during firmware loading:
      
       usb 4-1: firmware: requesting edgeport/down.fw
       /usr/src/linux/drivers/usb/serial/io_edgeport.c: downloading firmware version (930) 1.16.4
       [..]
       /usr/src/linux/drivers/usb/serial/io_edgeport.c: edge_startup - time 3 4328191260
       /usr/src/linux/drivers/usb/serial/io_edgeport.c:   FirmwareMajorVersion  0.0.4
      
      This can cause some confusion whether firmware loaded successfully
      or not.
      
      Cc: stable@kernel.org
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      271c1150
  2. 01 2月, 2011 11 次提交
  3. 31 1月, 2011 17 次提交
  4. 30 1月, 2011 1 次提交
  5. 29 1月, 2011 7 次提交
  6. 28 1月, 2011 1 次提交
    • B
      xfs: xfs_bmap_add_extent_delay_real should init br_startblock · 24446fc6
      bpm@sgi.com 提交于
      When filling in the middle of a previous delayed allocation in
      xfs_bmap_add_extent_delay_real, set br_startblock of the new delay
      extent to the right to nullstartblock instead of 0 before inserting
      the extent into the ifork (xfs_iext_insert), rather than setting
      br_startblock afterward.
      
      Adding the extent into the ifork with br_startblock=0 can lead to
      the extent being copied into the btree by xfs_bmap_extent_to_btree
      if we happen to convert from extents format to btree format before
      updating br_startblock with the correct value.  The unexpected
      addition of this delay extent to the btree can cause subsequent
      XFS_WANT_CORRUPTED_GOTO filesystem shutdown in several
      xfs_bmap_add_extent_delay_real cases where we are converting a delay
      extent to real and unexpectedly find an extent already inserted.
      For example:
      
      911         case BMAP_LEFT_FILLING:
      912                 /*
      913                  * Filling in the first part of a previous delayed allocation.
      914                  * The left neighbor is not contiguous.
      915                  */
      916                 trace_xfs_bmap_pre_update(ip, idx, state, _THIS_IP_);
      917                 xfs_bmbt_set_startoff(ep, new_endoff);
      918                 temp = PREV.br_blockcount - new->br_blockcount;
      919                 xfs_bmbt_set_blockcount(ep, temp);
      920                 xfs_iext_insert(ip, idx, 1, new, state);
      921                 ip->i_df.if_lastex = idx;
      922                 ip->i_d.di_nextents++;
      923                 if (cur == NULL)
      924                         rval = XFS_ILOG_CORE | XFS_ILOG_DEXT;
      925                 else {
      926                         rval = XFS_ILOG_CORE;
      927                         if ((error = xfs_bmbt_lookup_eq(cur, new->br_startoff,
      928                                         new->br_startblock, new->br_blockcount,
      929                                         &i)))
      930                                 goto done;
      931                         XFS_WANT_CORRUPTED_GOTO(i == 0, done);
      
      With the bogus extent in the btree we shutdown the filesystem at
      931.  The conversion from extents to btree format happens when the
      number of extents in the inode increases above ip->i_df.if_ext_max.
      xfs_bmap_extent_to_btree copies extents from the ifork into the
      btree, ignoring all delalloc extents which are denoted by
      br_startblock having some value of nullstartblock.
      
      SGI-PV: 1013221
      Signed-off-by: NBen Myers <bpm@sgi.com>
      Reviewed-by: NDave Chinner <dchinner@redhat.com>
      Signed-off-by: NAlex Elder <aelder@sgi.com>
      24446fc6