1. 27 7月, 2011 9 次提交
  2. 26 7月, 2011 12 次提交
  3. 22 7月, 2011 4 次提交
    • J
      [SCSI] fix crash in scsi_dispatch_cmd() · bfe159a5
      James Bottomley 提交于
      USB surprise removal of sr is triggering an oops in
      scsi_dispatch_command().  What seems to be happening is that USB is
      hanging on to a queue reference until the last close of the upper
      device, so the crash is caused by surprise remove of a mounted CD
      followed by attempted unmount.
      
      The problem is that USB doesn't issue its final commands as part of
      the SCSI teardown path, but on last close when the block queue is long
      gone.  The long term fix is probably to make sr do the teardown in the
      same way as sd (so remove all the lower bits on ejection, but keep the
      upper disk alive until last close of user space).  However, the
      current oops can be simply fixed by not allowing any commands to be
      sent to a dead queue.
      
      Cc: stable@kernel.org
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      bfe159a5
    • K
      [SCSI] sr: check_events() ignore GET_EVENT when TUR says otherwise · 79b9677d
      Kay Sievers 提交于
      Some broken devices indicates that media has changed on every
      GET_EVENT_STATUS_NOTIFICATION.  This translates into MEDIA_CHANGE
      uevent on every open() which lets udev run into a loop.
      
      Verify GET_EVENT result against TUR and if it generates spurious
      events for several times in a row, ignore the GET_EVENT events, and
      trust only the TUR status.
      
      This is the log of a USB stick with a (broken) fake CDROM drive:
      
       scsi 5:0:0:0: Direct-Access     SanDisk  U3 Cruzer Micro  8.02 PQ: 0 ANSI: 0 CCS
       sd 5:0:0:0: Attached scsi generic sg3 type 0
       scsi 5:0:0:1: CD-ROM            SanDisk  U3 Cruzer Micro  8.02 PQ: 0 ANSI: 0
       sd 5:0:0:0: [sdb] Attached SCSI removable disk
       sr2: scsi3-mmc drive: 48x/48x tray
       sr 5:0:0:1: Attached scsi CD-ROM sr2
       sr 5:0:0:1: Attached scsi generic sg4 type 5
       sr2: GET_EVENT and TUR disagree continuously, suppress GET_EVENT events
       sd 5:0:0:0: [sdb] 31777279 512-byte logical blocks: (16.2 GB/15.1 GiB)
       sd 5:0:0:0: [sdb] No Caching mode page present
       sd 5:0:0:0: [sdb] Assuming drive cache: write through
       sd 5:0:0:0: [sdb] No Caching mode page present
       sd 5:0:0:0: [sdb] Assuming drive cache: write through
       sdb: sdb1
      
      -tj: Updated to consider only spurious GET_EVENT events among
           different types of disagreement and allow using TUR for kernel
           event polling after GET_EVENT is ignored.
      
      Reported-By: Markus Rathgeb maggu2810@googlemail.com
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: stable@kernel.org	# >= v2.6.38, fixes udev busy looping w/ certain devices
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      79b9677d
    • E
      [SCSI] bnx2i: Fixed kernel panic due to illegal usage of sc->request->cpu · 0d83ab65
      Eddie Wai 提交于
      A kernel panic was observed when passing the sc->request->cpu = -1 to
      retrieve the per_cpu variable pointer:
       #0 [ffff880011203960] machine_kexec at ffffffff81022bc3
       #1 [ffff8800112039b0] crash_kexec at ffffffff81088630
       #2 [ffff880011203a80] __die at ffffffff8139ea20
       #3 [ffff880011203aa0] no_context at ffffffff8102f3a7
       #4 [ffff880011203ae0] __bad_area_nosemaphore at ffffffff8102f665
       #5 [ffff880011203ba0] retint_signal at ffffffff8139dd1f
       #6 [ffff880011203cc8] bnx2i_indicate_kcqe at ffffffffa03dc4f2
       #7 [ffff880011203da8] service_kcqes at ffffffffa03cb04f
       #8 [ffff880011203e68] cnic_service_bnx2x_kcq at ffffffffa03cb14a
       #9 [ffff880011203e88] cnic_service_bnx2x_bh at ffffffffa03cb1b3
      
      The problem lies in the slow path sg_io (and perhaps sg_scsi_ioctl) call to
      blk_get_request->get_request/wait->blk_alloc_request->blk_rq_init which
      re-initializes the request->cpu to -1.  There is no assignment for cpu from
      that to the request_fn call to low level drivers.
      
      When this happens, the sc->request->cpu will be using the init value of
      -1.  This will create a kernel panic when it hits bnx2i because the code
      refers it to get the per_cpu variables ptr.
      
      This change is to put in a guard against that and also for cases when
      bio affinity/queue completion to the same cpu is not enabled.  In those
      cases, the request->cpu will remain a -1 also.
      
      This bug was created from commit:  b5cf6b63
      
      For the case when the blk layer did not setup the request->cpu, bnx2i
      will complete the sc with the current CPU of the thread.
      Signed-off-by: NEddie Wai <eddie.wai@broadcom.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      0d83ab65
    • M
      cnic: Add VLAN ID as a parameter during netevent upcall · 415199f2
      Michael Chan 提交于
      The bnx2fc driver needs to handle netdev events on VLAN devices.
      Signed-off-by: NMichael Chan <mchan@broadcom.com>
      Reviewed-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      415199f2
  4. 21 7月, 2011 2 次提交
  5. 18 7月, 2011 1 次提交
  6. 04 7月, 2011 1 次提交
  7. 03 7月, 2011 11 次提交