<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/block, branch v3.16.40</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.16.40</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.16.40'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2017-02-23T03:54:35Z</updated>
<entry>
<title>nvme/pci: Don't free queues on error</title>
<updated>2017-02-23T03:54:35Z</updated>
<author>
<name>Keith Busch</name>
<email>keith.busch@intel.com</email>
</author>
<published>2016-11-15T20:56:26Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4f5af796101b0b79b3535a9b94bce7d3979dfd82'/>
<id>urn:sha1:4f5af796101b0b79b3535a9b94bce7d3979dfd82</id>
<content type='text'>
commit d48756228ee9161ac8836b346589a43fabdc9f3c upstream.

The nvme_remove function tears down all allocated resources in the correct
order, so no need to free queues on error during initialization. This
fixes possible use-after-free errors when queues are still associated
with a blk-mq hctx.

Reported-by: Scott Bauer &lt;scott.bauer@intel.com&gt;
Tested-by: Scott Bauer &lt;scott.bauer@intel.com&gt;
Signed-off-by: Keith Busch &lt;keith.busch@intel.com&gt;
Reviewed-by: Sagi Grimberg &lt;sagi@grimbeg.me&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
[bwh: Backported to 3.16:
 - Adjust filename, context
 - Only nvme_setup_io_queues() needs to be fixed]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>rbd: fix rbd map vs notify races</title>
<updated>2016-06-15T20:29:28Z</updated>
<author>
<name>Ilya Dryomov</name>
<email>idryomov@gmail.com</email>
</author>
<published>2016-04-15T14:22:16Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=80e4da2500457c054fd4ed8243b183bdec6bc6d6'/>
<id>urn:sha1:80e4da2500457c054fd4ed8243b183bdec6bc6d6</id>
<content type='text'>
commit 811c6688774613a78bfa020f64b570b73f6974c8 upstream.

A while ago, commit 9875201e1049 ("rbd: fix use-after free of
rbd_dev-&gt;disk") fixed rbd unmap vs notify race by introducing
an exported wrapper for flushing notifies and sticking it into
do_rbd_remove().

A similar problem exists on the rbd map path, though: the watch is
registered in rbd_dev_image_probe(), while the disk is set up quite
a few steps later, in rbd_dev_device_setup().  Nothing prevents
a notify from coming in and crashing on a NULL rbd_dev-&gt;disk:

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
    Call Trace:
     [&lt;ffffffffa0508344&gt;] rbd_watch_cb+0x34/0x180 [rbd]
     [&lt;ffffffffa04bd290&gt;] do_event_work+0x40/0xb0 [libceph]
     [&lt;ffffffff8109d5db&gt;] process_one_work+0x17b/0x470
     [&lt;ffffffff8109e3ab&gt;] worker_thread+0x11b/0x400
     [&lt;ffffffff8109e290&gt;] ? rescuer_thread+0x400/0x400
     [&lt;ffffffff810a5acf&gt;] kthread+0xcf/0xe0
     [&lt;ffffffff810b41b3&gt;] ? finish_task_switch+0x53/0x170
     [&lt;ffffffff810a5a00&gt;] ? kthread_create_on_node+0x140/0x140
     [&lt;ffffffff81645dd8&gt;] ret_from_fork+0x58/0x90
     [&lt;ffffffff810a5a00&gt;] ? kthread_create_on_node+0x140/0x140
    RIP  [&lt;ffffffffa050828a&gt;] rbd_dev_refresh+0xfa/0x180 [rbd]

If an error occurs during rbd map, we have to error out, potentially
tearing down a watch.  Just like on rbd unmap, notifies have to be
flushed, otherwise rbd_watch_cb() may end up trying to read in the
image header after rbd_dev_image_release() has run:

    Assertion failure in rbd_dev_header_info() at line 4722:

     rbd_assert(rbd_image_format_valid(rbd_dev-&gt;image_format));

    Call Trace:
     [&lt;ffffffff81cccee0&gt;] ? rbd_parent_request_create+0x150/0x150
     [&lt;ffffffff81cd4e59&gt;] rbd_dev_refresh+0x59/0x390
     [&lt;ffffffff81cd5229&gt;] rbd_watch_cb+0x69/0x290
     [&lt;ffffffff81fde9bf&gt;] do_event_work+0x10f/0x1c0
     [&lt;ffffffff81107799&gt;] process_one_work+0x689/0x1a80
     [&lt;ffffffff811076f7&gt;] ? process_one_work+0x5e7/0x1a80
     [&lt;ffffffff81132065&gt;] ? finish_task_switch+0x225/0x640
     [&lt;ffffffff81107110&gt;] ? pwq_dec_nr_in_flight+0x2b0/0x2b0
     [&lt;ffffffff81108c69&gt;] worker_thread+0xd9/0x1320
     [&lt;ffffffff81108b90&gt;] ? process_one_work+0x1a80/0x1a80
     [&lt;ffffffff8111b02d&gt;] kthread+0x21d/0x2e0
     [&lt;ffffffff8111ae10&gt;] ? kthread_stop+0x550/0x550
     [&lt;ffffffff82022802&gt;] ret_from_fork+0x22/0x40
     [&lt;ffffffff8111ae10&gt;] ? kthread_stop+0x550/0x550
    RIP  [&lt;ffffffff81ccd8f9&gt;] rbd_dev_header_info+0xa19/0x1e30

To fix this, a) check if RBD_DEV_FLAG_EXISTS is set before calling
revalidate_disk(), b) move ceph_osdc_flush_notifies() call into
rbd_dev_header_unwatch_sync() to cover rbd map error paths and c) turn
header read-in into a critical section.  The latter also happens to
take care of rbd map foo@bar vs rbd snap rm foo@bar race.

Fixes: http://tracker.ceph.com/issues/15490

Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Reviewed-by: Josh Durgin &lt;jdurgin@redhat.com&gt;
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>paride: make 'verbose' parameter an 'int' again</title>
<updated>2016-04-30T22:06:00Z</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2016-03-15T21:53:29Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=66435e4b0b4670e473e47c26ed2d9f8dfed0b554'/>
<id>urn:sha1:66435e4b0b4670e473e47c26ed2d9f8dfed0b554</id>
<content type='text'>
commit dec63a4dec2d6d01346fd5d96062e67c0636852b upstream.

gcc-6.0 found an ancient bug in the paride driver, which had a
"module_param(verbose, bool, 0);" since before 2.6.12, but actually uses
it to accept '0', '1' or '2' as arguments:

  drivers/block/paride/pd.c: In function 'pd_init_dev_parms':
  drivers/block/paride/pd.c:298:29: warning: comparison of constant '1' with boolean expression is always false [-Wbool-compare]
   #define DBMSG(msg) ((verbose&gt;1)?(msg):NULL)

In 2012, Rusty did a cleanup patch that also changed the type of the
variable to 'bool', which introduced what is now a gcc warning.

This changes the type back to 'int' and adapts the module_param() line
instead, so it should work as documented in case anyone ever cares about
running the ancient driver with debugging.

Fixes: 90ab5ee94171 ("module_param: make bool parameters really bool (drivers &amp; misc)")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Cc: Tim Waugh &lt;tim@cyberelk.net&gt;
Cc: Sudip Mukherjee &lt;sudipm.mukherjee@gmail.com&gt;
Cc: Jens Axboe &lt;axboe@fb.com&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>mtip32xx: Avoid issuing standby immediate cmd during FTL rebuild</title>
<updated>2016-04-30T22:05:53Z</updated>
<author>
<name>Asai Thambi SP</name>
<email>asamymuthupa@micron.com</email>
</author>
<published>2016-02-25T05:17:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2d09376eea66e240180bd3b11104fcd71fb269ee'/>
<id>urn:sha1:2d09376eea66e240180bd3b11104fcd71fb269ee</id>
<content type='text'>
commit d8a18d2d8f5de55666c6011ed175939d22c8e3d8 upstream.

Prevent standby immediate command from being issued in remove,
suspend and shutdown paths, while drive is in FTL rebuild process.

Signed-off-by: Selvan Mani &lt;smani@micron.com&gt;
Signed-off-by: Vignesh Gunasekaran &lt;vgunasekaran@micron.com&gt;
Signed-off-by: Asai Thambi S P &lt;asamymuthupa@micron.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>mtip32xx: Remove unwanted code from taskfile error handler</title>
<updated>2016-04-30T22:05:53Z</updated>
<author>
<name>Asai Thambi SP</name>
<email>asamymuthupa@micron.com</email>
</author>
<published>2016-02-25T05:16:21Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ed85f70549ad381071633514195f047c5f3799af'/>
<id>urn:sha1:ed85f70549ad381071633514195f047c5f3799af</id>
<content type='text'>
commit e35b94738a2f7caa12017f69ef385cb6b8028965 upstream.

Remove setting and clearing MTIP_PF_EH_ACTIVE_BIT flag in
mtip_handle_tfe() as they are redundant. Also avoid waking
up service thread from mtip_handle_tfe() because it is
already woken up in case of taskfile error.

Signed-off-by: Selvan Mani &lt;smani@micron.com&gt;
Signed-off-by: Rajesh Kumar Sambandam &lt;rsambandam@micron.com&gt;
Signed-off-by: Asai Thambi S P &lt;asamymuthupa@micron.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>mtip32xx: Fix broken service thread handling</title>
<updated>2016-04-30T22:05:52Z</updated>
<author>
<name>Asai Thambi SP</name>
<email>asamymuthupa@micron.com</email>
</author>
<published>2016-02-25T05:16:00Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4067ffd3e26988b915bc77704dc15cb5eb63213b'/>
<id>urn:sha1:4067ffd3e26988b915bc77704dc15cb5eb63213b</id>
<content type='text'>
commit cfc05bd31384c4898bf2437a4de5557f3cf9803a upstream.

Service thread does not detect the need for taskfile error hanlding. Fixed the
flag condition to process taskfile error.

Signed-off-by: Selvan Mani &lt;smani@micron.com&gt;
Signed-off-by: Asai Thambi S P &lt;asamymuthupa@micron.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>nbd: ratelimit error msgs after socket close</title>
<updated>2016-04-30T22:05:46Z</updated>
<author>
<name>Dan Streetman</name>
<email>dan.streetman@canonical.com</email>
</author>
<published>2016-01-14T18:42:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=dd37eba1a9f9b6eca4d993ca911d538e0b4374b0'/>
<id>urn:sha1:dd37eba1a9f9b6eca4d993ca911d538e0b4374b0</id>
<content type='text'>
commit da6ccaaa79caca4f38b540b651238f87215217a2 upstream.

Make the "Attempted send on closed socket" error messages generated in
nbd_request_handler() ratelimited.

When the nbd socket is shutdown, the nbd_request_handler() function emits
an error message for every request remaining in its queue.  If the queue
is large, this will spam a large amount of messages to the log.  There's
no need for a separate error message for each request, so this patch
ratelimits it.

In the specific case this was found, the system was virtual and the error
messages were logged to the serial port, which overwhelmed it.

Fixes: 4d48a542b427 ("nbd: fix I/O hang on disconnected nbds")
Signed-off-by: Dan Streetman &lt;dan.streetman@canonical.com&gt;
Signed-off-by: Markus Pargmann &lt;mpa@pengutronix.de&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>zram: try vmalloc() after kmalloc()</title>
<updated>2016-02-02T19:09:48Z</updated>
<author>
<name>Kyeongdon Kim</name>
<email>kyeongdon.kim@lge.com</email>
</author>
<published>2016-01-14T23:22:29Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=75b7953656c6e1599996f702c2fccff55d0a5fb1'/>
<id>urn:sha1:75b7953656c6e1599996f702c2fccff55d0a5fb1</id>
<content type='text'>
commit d913897abace843bba20249f3190167f7895e9c3 upstream.

When we're using LZ4 multi compression streams for zram swap, we found
out page allocation failure message in system running test.  That was
not only once, but a few(2 - 5 times per test).  Also, some failure
cases were continually occurring to try allocation order 3.

In order to make parallel compression private data, we should call
kzalloc() with order 2/3 in runtime(lzo/lz4).  But if there is no order
2/3 size memory to allocate in that time, page allocation fails.  This
patch makes to use vmalloc() as fallback of kmalloc(), this prevents
page alloc failure warning.

After using this, we never found warning message in running test, also
It could reduce process startup latency about 60-120ms in each case.

For reference a call trace :

    Binder_1: page allocation failure: order:3, mode:0x10c0d0
    CPU: 0 PID: 424 Comm: Binder_1 Tainted: GW 3.10.49-perf-g991d02b-dirty #20
    Call trace:
      dump_backtrace+0x0/0x270
      show_stack+0x10/0x1c
      dump_stack+0x1c/0x28
      warn_alloc_failed+0xfc/0x11c
      __alloc_pages_nodemask+0x724/0x7f0
      __get_free_pages+0x14/0x5c
      kmalloc_order_trace+0x38/0xd8
      zcomp_lz4_create+0x2c/0x38
      zcomp_strm_alloc+0x34/0x78
      zcomp_strm_multi_find+0x124/0x1ec
      zcomp_strm_find+0xc/0x18
      zram_bvec_rw+0x2fc/0x780
      zram_make_request+0x25c/0x2d4
      generic_make_request+0x80/0xbc
      submit_bio+0xa4/0x15c
      __swap_writepage+0x218/0x230
      swap_writepage+0x3c/0x4c
      shrink_page_list+0x51c/0x8d0
      shrink_inactive_list+0x3f8/0x60c
      shrink_lruvec+0x33c/0x4cc
      shrink_zone+0x3c/0x100
      try_to_free_pages+0x2b8/0x54c
      __alloc_pages_nodemask+0x514/0x7f0
      __get_free_pages+0x14/0x5c
      proc_info_read+0x50/0xe4
      vfs_read+0xa0/0x12c
      SyS_read+0x44/0x74
    DMA: 3397*4kB (MC) 26*8kB (RC) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB
         0*512kB 0*1024kB 0*2048kB 0*4096kB = 13796kB

[minchan@kernel.org: change vmalloc gfp and adding comment about gfp]
[sergey.senozhatsky@gmail.com: tweak comments and styles]
Signed-off-by: Kyeongdon Kim &lt;kyeongdon.kim@lge.com&gt;
Signed-off-by: Minchan Kim &lt;minchan@kernel.org&gt;
Acked-by: Sergey Senozhatsky &lt;sergey.senozhatsky@gmail.com&gt;
Sergey Senozhatsky &lt;sergey.senozhatsky.work@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
</entry>
<entry>
<title>zram/zcomp: use GFP_NOIO to allocate streams</title>
<updated>2016-02-02T19:09:47Z</updated>
<author>
<name>Sergey Senozhatsky</name>
<email>sergey.senozhatsky@gmail.com</email>
</author>
<published>2016-01-14T23:22:26Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3b1cecbc197b3ff81bd2471dc5595f69c5bed036'/>
<id>urn:sha1:3b1cecbc197b3ff81bd2471dc5595f69c5bed036</id>
<content type='text'>
commit 3d5fe03a3ea013060ebba2a811aeb0f23f56aefa upstream.

We can end up allocating a new compression stream with GFP_KERNEL from
within the IO path, which may result is nested (recursive) IO
operations.  That can introduce problems if the IO path in question is a
reclaimer, holding some locks that will deadlock nested IOs.

Allocate streams and working memory using GFP_NOIO flag, forbidding
recursive IO and FS operations.

An example:

  inconsistent {IN-RECLAIM_FS-W} -&gt; {RECLAIM_FS-ON-W} usage.
  git/20158 [HC0[0]:SC0[0]:HE1:SE1] takes:
   (jbd2_handle){+.+.?.}, at:  start_this_handle+0x4ca/0x555
  {IN-RECLAIM_FS-W} state was registered at:
     __lock_acquire+0x8da/0x117b
     lock_acquire+0x10c/0x1a7
     start_this_handle+0x52d/0x555
     jbd2__journal_start+0xb4/0x237
     __ext4_journal_start_sb+0x108/0x17e
     ext4_dirty_inode+0x32/0x61
     __mark_inode_dirty+0x16b/0x60c
     iput+0x11e/0x274
     __dentry_kill+0x148/0x1b8
     shrink_dentry_list+0x274/0x44a
     prune_dcache_sb+0x4a/0x55
     super_cache_scan+0xfc/0x176
     shrink_slab.part.14.constprop.25+0x2a2/0x4d3
     shrink_zone+0x74/0x140
     kswapd+0x6b7/0x930
     kthread+0x107/0x10f
     ret_from_fork+0x3f/0x70
  irq event stamp: 138297
  hardirqs last  enabled at (138297):  debug_check_no_locks_freed+0x113/0x12f
  hardirqs last disabled at (138296):  debug_check_no_locks_freed+0x33/0x12f
  softirqs last  enabled at (137818):  __do_softirq+0x2d3/0x3e9
  softirqs last disabled at (137813):  irq_exit+0x41/0x95

               other info that might help us debug this:
   Possible unsafe locking scenario:
         CPU0
         ----
    lock(jbd2_handle);
    &lt;Interrupt&gt;
      lock(jbd2_handle);

                *** DEADLOCK ***
  5 locks held by git/20158:
   #0:  (sb_writers#7){.+.+.+}, at: [&lt;ffffffff81155411&gt;] mnt_want_write+0x24/0x4b
   #1:  (&amp;type-&gt;i_mutex_dir_key#2/1){+.+.+.}, at: [&lt;ffffffff81145087&gt;] lock_rename+0xd9/0xe3
   #2:  (&amp;sb-&gt;s_type-&gt;i_mutex_key#11){+.+.+.}, at: [&lt;ffffffff8114f8e2&gt;] lock_two_nondirectories+0x3f/0x6b
   #3:  (&amp;sb-&gt;s_type-&gt;i_mutex_key#11/4){+.+.+.}, at: [&lt;ffffffff8114f909&gt;] lock_two_nondirectories+0x66/0x6b
   #4:  (jbd2_handle){+.+.?.}, at: [&lt;ffffffff811e31db&gt;] start_this_handle+0x4ca/0x555

               stack backtrace:
  CPU: 2 PID: 20158 Comm: git Not tainted 4.1.0-rc7-next-20150615-dbg-00016-g8bdf555-dirty #211
  Call Trace:
    dump_stack+0x4c/0x6e
    mark_lock+0x384/0x56d
    mark_held_locks+0x5f/0x76
    lockdep_trace_alloc+0xb2/0xb5
    kmem_cache_alloc_trace+0x32/0x1e2
    zcomp_strm_alloc+0x25/0x73 [zram]
    zcomp_strm_multi_find+0xe7/0x173 [zram]
    zcomp_strm_find+0xc/0xe [zram]
    zram_bvec_rw+0x2ca/0x7e0 [zram]
    zram_make_request+0x1fa/0x301 [zram]
    generic_make_request+0x9c/0xdb
    submit_bio+0xf7/0x120
    ext4_io_submit+0x2e/0x43
    ext4_bio_write_page+0x1b7/0x300
    mpage_submit_page+0x60/0x77
    mpage_map_and_submit_buffers+0x10f/0x21d
    ext4_writepages+0xc8c/0xe1b
    do_writepages+0x23/0x2c
    __filemap_fdatawrite_range+0x84/0x8b
    filemap_flush+0x1c/0x1e
    ext4_alloc_da_blocks+0xb8/0x117
    ext4_rename+0x132/0x6dc
    ? mark_held_locks+0x5f/0x76
    ext4_rename2+0x29/0x2b
    vfs_rename+0x540/0x636
    SyS_renameat2+0x359/0x44d
    SyS_rename+0x1e/0x20
    entry_SYSCALL_64_fastpath+0x12/0x6f

[minchan@kernel.org: add stable mark]
Signed-off-by: Sergey Senozhatsky &lt;sergey.senozhatsky@gmail.com&gt;
Acked-by: Minchan Kim &lt;minchan@kernel.org&gt;
Cc: Kyeongdon Kim &lt;kyeongdon.kim@lge.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
</entry>
<entry>
<title>xen-blkback: read from indirect descriptors only once</title>
<updated>2016-01-25T10:43:44Z</updated>
<author>
<name>Roger Pau Monné</name>
<email>roger.pau@citrix.com</email>
</author>
<published>2015-11-03T16:40:43Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b23f923eb548a5fcd3ddba5227b0364061dcf4f5'/>
<id>urn:sha1:b23f923eb548a5fcd3ddba5227b0364061dcf4f5</id>
<content type='text'>
commit 18779149101c0dd43ded43669ae2a92d21b6f9cb upstream.

Since indirect descriptors are in memory shared with the frontend, the
frontend could alter the first_sect and last_sect values after they have
been validated but before they are recorded in the request.  This may
result in I/O requests that overflow the foreign page, possibly
overwriting local pages when the I/O request is executed.

When parsing indirect descriptors, only read first_sect and last_sect
once.

This is part of XSA155.

Signed-off-by: Roger Pau Monné &lt;roger.pau@citrix.com&gt;
Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
[ luis: backported to 3.16:
  - Use ACCESS_ONCE instead of READ_ONCE
  - Use PAGE_SIZE instead of XEN_PAGE_SIZE ]
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
</entry>
</feed>
