1. 11 2月, 2014 1 次提交
  2. 08 2月, 2014 1 次提交
    • S
      block/null_blk: Fix completion processing from LIFO to FIFO · d7790b92
      Shlomo Pongratz 提交于
      The completion queue is implemented using lockless list.
      
      The llist_add is adds the events to the list head which is a push operation.
      The processing of the completion elements is done by disconnecting all the
      pushed elements and iterating over the disconnected list. The problem is
      that the processing is done in reverse order w.r.t order of the insertion
      i.e. LIFO processing. By reversing the disconnected list which is done in
      linear time the desired FIFO processing is achieved.
      Signed-off-by: NShlomo Pongratz <shlomop@mellanox.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      d7790b92
  3. 28 1月, 2014 4 次提交
  4. 24 1月, 2014 1 次提交
  5. 22 1月, 2014 9 次提交
  6. 17 1月, 2014 1 次提交
    • J
      floppy: bail out in open() if drive is not responding to block0 read · 7b7b68bb
      Jiri Kosina 提交于
      In case reading of block 0 during open() fails, it is not the right thing
      to let open() succeed.
      
      Fix this by introducing FD_OPEN_SHOULD_FAIL_BIT flag, and setting it in
      case the bio callback encounters an error while trying to read block 0.
      
      As a bonus, this works around certain broken userspace (blkid), which is
      not able to properly handle read()s returning IO errors. Hence be nice to
      those, and bail out during open() already; if block 0 is not readable,
      read()s are not going to provide any meaningful data anyway.
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      7b7b68bb
  7. 12 1月, 2014 1 次提交
  8. 04 1月, 2014 1 次提交
    • K
      xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v4). · 51c71a3b
      Konrad Rzeszutek Wilk 提交于
      The user has the option of disabling the platform driver:
      00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
      
      which is used to unplug the emulated drivers (IDE, Realtek 8169, etc)
      and allow the PV drivers to take over. If the user wishes
      to disable that they can set:
      
        xen_platform_pci=0
        (in the guest config file)
      
      or
        xen_emul_unplug=never
        (on the Linux command line)
      
      except it does not work properly. The PV drivers still try to
      load and since the Xen platform driver is not run - and it
      has not initialized the grant tables, most of the PV drivers
      stumble upon:
      
      input: Xen Virtual Keyboard as /devices/virtual/input/input5
      input: Xen Virtual Pointer as /devices/virtual/input/input6M
      ------------[ cut here ]------------
      kernel BUG at /home/konrad/ssd/konrad/linux/drivers/xen/grant-table.c:1206!
      invalid opcode: 0000 [#1] SMP
      Modules linked in: xen_kbdfront(+) xenfs xen_privcmd
      CPU: 6 PID: 1389 Comm: modprobe Not tainted 3.13.0-rc1upstream-00021-ga6c892b-dirty #1
      Hardware name: Xen HVM domU, BIOS 4.4-unstable 11/26/2013
      RIP: 0010:[<ffffffff813ddc40>]  [<ffffffff813ddc40>] get_free_entries+0x2e0/0x300
      Call Trace:
       [<ffffffff8150d9a3>] ? evdev_connect+0x1e3/0x240
       [<ffffffff813ddd0e>] gnttab_grant_foreign_access+0x2e/0x70
       [<ffffffffa0010081>] xenkbd_connect_backend+0x41/0x290 [xen_kbdfront]
       [<ffffffffa0010a12>] xenkbd_probe+0x2f2/0x324 [xen_kbdfront]
       [<ffffffff813e5757>] xenbus_dev_probe+0x77/0x130
       [<ffffffff813e7217>] xenbus_frontend_dev_probe+0x47/0x50
       [<ffffffff8145e9a9>] driver_probe_device+0x89/0x230
       [<ffffffff8145ebeb>] __driver_attach+0x9b/0xa0
       [<ffffffff8145eb50>] ? driver_probe_device+0x230/0x230
       [<ffffffff8145eb50>] ? driver_probe_device+0x230/0x230
       [<ffffffff8145cf1c>] bus_for_each_dev+0x8c/0xb0
       [<ffffffff8145e7d9>] driver_attach+0x19/0x20
       [<ffffffff8145e260>] bus_add_driver+0x1a0/0x220
       [<ffffffff8145f1ff>] driver_register+0x5f/0xf0
       [<ffffffff813e55c5>] xenbus_register_driver_common+0x15/0x20
       [<ffffffff813e76b3>] xenbus_register_frontend+0x23/0x40
       [<ffffffffa0015000>] ? 0xffffffffa0014fff
       [<ffffffffa001502b>] xenkbd_init+0x2b/0x1000 [xen_kbdfront]
       [<ffffffff81002049>] do_one_initcall+0x49/0x170
      
      .. snip..
      
      which is hardly nice. This patch fixes this by having each
      PV driver check for:
       - if running in PV, then it is fine to execute (as that is their
         native environment).
       - if running in HVM, check if user wanted 'xen_emul_unplug=never',
         in which case bail out and don't load any PV drivers.
       - if running in HVM, and if PCI device 5853:0001 (xen_platform_pci)
         does not exist, then bail out and not load PV drivers.
       - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=ide-disks',
         then bail out for all PV devices _except_ the block one.
         Ditto for the network one ('nics').
       - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=unnecessary'
         then load block PV driver, and also setup the legacy IDE paths.
         In (v3) make it actually load PV drivers.
      
      Reported-by: Sander Eikelenboom <linux@eikelenboom.it
      Reported-by: NAnthony PERARD <anthony.perard@citrix.com>
      Reported-and-Tested-by: NFabio Fantoni <fabio.fantoni@m2r.biz>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      [v2: Add extra logic to handle the myrid ways 'xen_emul_unplug'
      can be used per Ian and Stefano suggestion]
      [v3: Make the unnecessary case work properly]
      [v4: s/disks/ide-disks/ spotted by Fabio]
      Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Acked-by: Bjorn Helgaas <bhelgaas@google.com> [for PCI parts]
      CC: stable@vger.kernel.org
      51c71a3b
  9. 03 1月, 2014 1 次提交
  10. 01 1月, 2014 10 次提交
  11. 22 12月, 2013 2 次提交
  12. 19 12月, 2013 4 次提交
  13. 16 12月, 2013 1 次提交
  14. 04 12月, 2013 1 次提交
  15. 27 11月, 2013 2 次提交