1. 09 Nov, 2009 12 commits
  2. 08 Nov, 2009 7 commits
  3. 07 Nov, 2009 17 commits
  4. 06 Nov, 2009 4 commits
    • Jeff Layton's avatar
      cifs: don't use CIFSGetSrvInodeNumber in is_path_accessible · f475f677
      Jeff Layton authored
      Because it's lighter weight, CIFS tries to use CIFSGetSrvInodeNumber to
      verify the accessibility of the root inode and then falls back to doing a
      full QPathInfo if that fails with -EOPNOTSUPP. I have at least a report
      of a server that returns NT_STATUS_INTERNAL_ERROR rather than something
      that translates to EOPNOTSUPP.
      
      Rather than trying to be clever with that call, just have
      is_path_accessible do a normal QPathInfo. That call is widely
      supported and it shouldn't increase the overhead significantly.
      
      Cc: Stable <stable@kernel.org>
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      f475f677
    • Jeff Layton's avatar
      cifs: clean up handling when server doesn't consistently support inode numbers · ec06aedd
      Jeff Layton authored
      It's possible that a server will return a valid FileID when we query the
      FILE_INTERNAL_INFO for the root inode, but then zeroed out inode numbers
      when we do a FindFile with an infolevel of
      SMB_FIND_FILE_ID_FULL_DIR_INFO.
      
      In this situation turn off querying for server inode numbers, generate a
      warning for the user and just generate an inode number using iunique.
      Once we generate any inode number with iunique we can no longer use any
      server inode numbers or we risk collisions, so ensure that we don't do
      that in cifs_get_inode_info either.
      
      Cc: Stable <stable@kernel.org>
      Reported-by: default avatarTimothy Normand Miller <theosib@gmail.com>
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      ec06aedd
    • Sean Cross's avatar
      rt2x00: Don't queue ieee80211 work after USB removal · 66f84d65
      Sean Cross authored
      This prevents the rt2x00 driver from queueing ieee80211 work after the  
      USB card has been removed, preventing a kernel panic.
      Signed-off-by: default avatarSean Cross <sean@chumby.com>
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      66f84d65
    • John W. Linville's avatar
      Revert "ipw2200: fix oops on missing firmware" · 143d40f3
      John W. Linville authored
      This reverts commit e6c5fc53.
      
      Based on this regression report:
      
      Date: Thu, 05 Nov 2009 15:59:16 +0100
      From: Holger Schurig <holgerschurig@gmail.com>
      To: linux-wireless@vger.kernel.org
      Subject: BUG: oops when "rmmod ipw2200"
      
      This happened on wireless-testing v2.6.32-rc6-41575-g5e68bfb. I
      modprobed ipw2200, put it into monitor mode, used tshark a while to
      monitor, then I stopped tshark, "ifconfig eth2 down" and finally
      "rmmod ipw2200", and voila:
      
      [  917.189620] ------------[ cut here ]------------
      [  917.189717] kernel BUG at net/wireless/core.c:543!
      [  917.189805] invalid opcode: 0000 [#1] PREEMPT SMP
      [  917.190002] last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:02:0d.0/firmware/0000:02:0d.0/loading
      [  917.190136] Modules linked in: lib80211_crypt_wep ipw2200(-) libipw lib80211 ath5k mac80211 ath cfg80211 psmouse uhci_hcd
      [  917.190680]
      [  917.190759] Pid: 1763, comm: rmmod Not tainted (2.6.32-rc6-wl #26) Amilo M1425
      [  917.190886] EIP: 0060:[<f8accf34>] EFLAGS: 00010202 CPU: 0
      [  917.190992] EIP is at wiphy_unregister+0xd3/0x175 [cfg80211]
      [  917.191083] EAX: f601d4c4 EBX: 00000000 ECX: 00000000 EDX: f79e8600
      [  917.191176] ESI: f601d400 EDI: f95b4350 EBP: f6009eb4 ESP: f6009e8c
      [  917.191269]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      [  917.191360] Process rmmod (pid: 1763, ti=f6008000 task=f79e8130 task.ti=f6008000)
      [  917.191486] Stack:
      [  917.191562]  f601d5a0 f601d484 f6460e98 f6009ea0 c01407ee f6009eb8 00000246 f64604c0
      [  917.191916] <0> f6460e5c f95b4350 f6009ec0 f94fd030 f6460e98 f6009edc f95a9d4f f787bc00
      [  917.192100] <0> f787bc58 f787bc00 f95b4350 f95b4350 f6009ee8 c0207fca f787bc58 f6009ef8
      [  917.192100] Call Trace:
      [  917.192100]  [<c01407ee>] ? trace_hardirqs_on+0xb/0xd
      [  917.192100]  [<f94fd030>] ? unregister_ieee80211+0xe/0x27 [libipw]
      [  917.192100]  [<f95a9d4f>] ? ipw_pci_remove+0x59/0x227 [ipw2200]
      [  917.192100]  [<c0207fca>] ? pci_device_remove+0x19/0x39
      [  917.192100]  [<c02b93a4>] ? __device_release_driver+0x59/0x9d
      [  917.192100]  [<c02b944f>] ? driver_detach+0x67/0x85
      [  917.192100]  [<c02b88d6>] ? bus_remove_driver+0x69/0x85
      [  917.192100]  [<c02b9878>] ? driver_unregister+0x4d/0x54
      [  917.192100]  [<c02081c3>] ? pci_unregister_driver+0x28/0x71
      [  917.192100]  [<f95a9cf4>] ? ipw_exit+0x1c/0x1e [ipw2200]
      [  917.192100]  [<c0148e2b>] ? sys_delete_module+0x192/0x1ef
      [  917.192100]  [<c0162cdb>] ? remove_vma+0x52/0x58
      [  917.192100]  [<c01028bb>] ? sysenter_exit+0xf/0x18
      [  917.192100]  [<c0102888>] ? sysenter_do_call+0x12/0x36
      [  917.192100] Code: 74 07 e8 81 bc 8c c7 eb c8 8d 55 e0 89 f8 e8 d6 6d 66 c7 8b 45 dc 31 d2 e8 81 cc 8c c7 8d 86 c4 00 00 00 39 86 c4 00 00 00 74 04 <0f> 0b eb fe 8b 45 dc 8d 5e 0c e8 5a cc 8c c7 8b 86 94 03 00 00
      [  917.192100] EIP: [<f8accf34>] wiphy_unregister+0xd3/0x175 [cfg80211] SS:ESP 0068:f6009e8c
      [  917.203718] ---[ end trace bcaaf449945a5100 ]---
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      143d40f3