<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/block, branch v5.4.68</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.68</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.68'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2020-09-17T11:47:53Z</updated>
<entry>
<title>rbd: require global CAP_SYS_ADMIN for mapping and unmapping</title>
<updated>2020-09-17T11:47:53Z</updated>
<author>
<name>Ilya Dryomov</name>
<email>idryomov@gmail.com</email>
</author>
<published>2020-09-03T11:24:11Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ea3d3bf85669195247ad6a522f4e4209695edca2'/>
<id>urn:sha1:ea3d3bf85669195247ad6a522f4e4209695edca2</id>
<content type='text'>
commit f44d04e696feaf13d192d942c4f14ad2e117065a upstream.

It turns out that currently we rely only on sysfs attribute
permissions:

  $ ll /sys/bus/rbd/{add*,remove*}
  --w------- 1 root root 4096 Sep  3 20:37 /sys/bus/rbd/add
  --w------- 1 root root 4096 Sep  3 20:37 /sys/bus/rbd/add_single_major
  --w------- 1 root root 4096 Sep  3 20:37 /sys/bus/rbd/remove
  --w------- 1 root root 4096 Sep  3 20:38 /sys/bus/rbd/remove_single_major

This means that images can be mapped and unmapped (i.e. block devices
can be created and deleted) by a UID 0 process even after it drops all
privileges or by any process with CAP_DAC_OVERRIDE in its user namespace
as long as UID 0 is mapped into that user namespace.

Be consistent with other virtual block devices (loop, nbd, dm, md, etc)
and require CAP_SYS_ADMIN in the initial user namespace for mapping and
unmapping, and also for dumping the configuration string and refreshing
the image header.

Cc: stable@vger.kernel.org
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Reviewed-by: Jeff Layton &lt;jlayton@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>nbd: restore default timeout when setting it to zero</title>
<updated>2020-09-09T17:12:22Z</updated>
<author>
<name>Hou Pu</name>
<email>houpu@bytedance.com</email>
</author>
<published>2020-08-10T12:00:44Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c756635246e9da7b6c6dcbc08b4519bdcb0d3475'/>
<id>urn:sha1:c756635246e9da7b6c6dcbc08b4519bdcb0d3475</id>
<content type='text'>
[ Upstream commit acb19e17c5134dd78668c429ecba5b481f038e6a ]

If we configured io timeout of nbd0 to 100s. Later after we
finished using it, we configured nbd0 again and set the io
timeout to 0. We expect it would timeout after 30 seconds
and keep retry. But in fact we could not change the timeout
when we set it to 0. the timeout is still the original 100s.

So change the timeout to default 30s when we set it to zero.
It also behaves same as commit 2da22da57348 ("nbd: fix zero
cmd timeout handling v2").

It becomes more important if we were reconfigure a nbd device
and the io timeout it set to zero. Because it could take 30s
to detect the new socket and thus io could be completed more
quickly compared to 100s.

Signed-off-by: Hou Pu &lt;houpu@bytedance.com&gt;
Reviewed-by: Josef Bacik &lt;josef@toxicpanda.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>block: loop: set discard granularity and alignment for block device backed loop</title>
<updated>2020-09-03T09:27:01Z</updated>
<author>
<name>Ming Lei</name>
<email>ming.lei@redhat.com</email>
</author>
<published>2020-08-17T10:01:30Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=db4542b6617b60810315fe72f40a623e73ee1b66'/>
<id>urn:sha1:db4542b6617b60810315fe72f40a623e73ee1b66</id>
<content type='text'>
commit bcb21c8cc9947286211327d663ace69f07d37a76 upstream.

In case of block device backend, if the backend supports write zeros, the
loop device will set queue flag of QUEUE_FLAG_DISCARD. However,
limits.discard_granularity isn't setup, and this way is wrong,
see the following description in Documentation/ABI/testing/sysfs-block:

	A discard_granularity of 0 means that the device does not support
	discard functionality.

Especially 9b15d109a6b2 ("block: improve discard bio alignment in
__blkdev_issue_discard()") starts to take q-&gt;limits.discard_granularity
for computing max discard sectors. And zero discard granularity may cause
kernel oops, or fail discard request even though the loop queue claims
discard support via QUEUE_FLAG_DISCARD.

Fix the issue by setup discard granularity and alignment.

Fixes: c52abf563049 ("loop: Better discard support for block devices")
Signed-off-by: Ming Lei &lt;ming.lei@redhat.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Acked-by: Coly Li &lt;colyli@suse.de&gt;
Cc: Hannes Reinecke &lt;hare@suse.com&gt;
Cc: Xiao Ni &lt;xni@redhat.com&gt;
Cc: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Cc: Evan Green &lt;evgreen@chromium.org&gt;
Cc: Gwendal Grignou &lt;gwendal@chromium.org&gt;
Cc: Chaitanya Kulkarni &lt;chaitanya.kulkarni@wdc.com&gt;
Cc: Andrzej Pietrasiewicz &lt;andrzej.p@collabora.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>null_blk: fix passing of REQ_FUA flag in null_handle_rq</title>
<updated>2020-09-03T09:26:55Z</updated>
<author>
<name>Hou Pu</name>
<email>houpu@bytedance.com</email>
</author>
<published>2020-08-21T08:34:42Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2fc8fa50ebeebeb42c5e4fb7655ec3a1296f262f'/>
<id>urn:sha1:2fc8fa50ebeebeb42c5e4fb7655ec3a1296f262f</id>
<content type='text'>
[ Upstream commit 2d62e6b038e729c3e4bfbfcfbd44800ef0883680 ]

REQ_FUA should be checked using rq-&gt;cmd_flags instead of req_op().

Fixes: deb78b419dfda ("nullb: emulate cache")
Signed-off-by: Hou Pu &lt;houpu@bytedance.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>block: virtio_blk: fix handling single range discard request</title>
<updated>2020-09-03T09:26:54Z</updated>
<author>
<name>Ming Lei</name>
<email>ming.lei@redhat.com</email>
</author>
<published>2020-08-17T09:52:40Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=effd3b89f7e588e31b9fd396abdc9e39cf21f1c6'/>
<id>urn:sha1:effd3b89f7e588e31b9fd396abdc9e39cf21f1c6</id>
<content type='text'>
[ Upstream commit af822aa68fbdf0a480a17462ed70232998127453 ]

1f23816b8eb8 ("virtio_blk: add discard and write zeroes support") starts
to support multi-range discard for virtio-blk. However, the virtio-blk
disk may report max discard segment as 1, at least that is exactly what
qemu is doing.

So far, block layer switches to normal request merge if max discard segment
limit is 1, and multiple bios can be merged to single segment. This way may
cause memory corruption in virtblk_setup_discard_write_zeroes().

Fix the issue by handling single max discard segment in straightforward
way.

Fixes: 1f23816b8eb8 ("virtio_blk: add discard and write zeroes support")
Signed-off-by: Ming Lei &lt;ming.lei@redhat.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Changpeng Liu &lt;changpeng.liu@intel.com&gt;
Cc: Daniel Verkamp &lt;dverkamp@chromium.org&gt;
Cc: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Cc: Stefan Hajnoczi &lt;stefanha@redhat.com&gt;
Cc: Stefano Garzarella &lt;sgarzare@redhat.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>loop: be paranoid on exit and prevent new additions / removals</title>
<updated>2020-08-19T06:15:59Z</updated>
<author>
<name>Luis Chamberlain</name>
<email>mcgrof@kernel.org</email>
</author>
<published>2020-06-19T20:47:27Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a6619810135b5365d1d4b83791a4e1f1464a0a41'/>
<id>urn:sha1:a6619810135b5365d1d4b83791a4e1f1464a0a41</id>
<content type='text'>
[ Upstream commit 200f93377220504c5e56754823e7adfea6037f1a ]

Be pedantic on removal as well and hold the mutex.
This should prevent uses of addition while we exit.

Signed-off-by: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Reviewed-by: Ming Lei &lt;ming.lei@redhat.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Revert "zram: convert remaining CLASS_ATTR() to CLASS_ATTR_RO()"</title>
<updated>2020-07-22T07:33:12Z</updated>
<author>
<name>Wade Mealing</name>
<email>wmealing@redhat.com</email>
</author>
<published>2020-06-17T11:49:47Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=72648019cd52488716891c2cbb096ad1023ab83e'/>
<id>urn:sha1:72648019cd52488716891c2cbb096ad1023ab83e</id>
<content type='text'>
commit 853eab68afc80f59f36bbdeb715e5c88c501e680 upstream.

Turns out that the permissions for 0400 really are what we want here,
otherwise any user can read from this file.

[fixed formatting, added changelog, and made attribute static - gregkh]

Reported-by: Wade Mealing &lt;wmealing@redhat.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Fixes: f40609d1591f ("zram: convert remaining CLASS_ATTR() to CLASS_ATTR_RO()")
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1847832
Reviewed-by: Steffen Maier &lt;maier@linux.ibm.com&gt;
Acked-by: Minchan Kim &lt;minchan@kernel.org&gt;
Link: https://lore.kernel.org/r/20200617114946.GA2131650@kroah.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>nbd: Fix memory leak in nbd_add_socket</title>
<updated>2020-07-16T06:16:40Z</updated>
<author>
<name>Zheng Bin</name>
<email>zhengbin13@huawei.com</email>
</author>
<published>2020-06-29T01:23:49Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2a4c5ff12f427b6046f025f138010f91002b99ea'/>
<id>urn:sha1:2a4c5ff12f427b6046f025f138010f91002b99ea</id>
<content type='text'>
[ Upstream commit 579dd91ab3a5446b148e7f179b6596b270dace46 ]

When adding first socket to nbd, if nsock's allocation failed, the data
structure member "config-&gt;socks" was reallocated, but the data structure
member "config-&gt;num_connections" was not updated. A memory leak will occur
then because the function "nbd_config_put" will free "config-&gt;socks" only
when "config-&gt;num_connections" is not zero.

Fixes: 03bf73c315ed ("nbd: prevent memory leak")
Reported-by: syzbot+934037347002901b8d2a@syzkaller.appspotmail.com
Signed-off-by: Zheng Bin &lt;zhengbin13@huawei.com&gt;
Reviewed-by: Eric Biggers &lt;ebiggers@google.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>virtio-blk: free vblk-vqs in error path of virtblk_probe()</title>
<updated>2020-07-09T07:37:54Z</updated>
<author>
<name>Hou Tao</name>
<email>houtao1@huawei.com</email>
</author>
<published>2020-06-15T04:14:59Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8964c93436ad95456f930e4994242da474ba8f7b'/>
<id>urn:sha1:8964c93436ad95456f930e4994242da474ba8f7b</id>
<content type='text'>
[ Upstream commit e7eea44eefbdd5f0345a0a8b80a3ca1c21030d06 ]

Else there will be memory leak if alloc_disk() fails.

Fixes: 6a27b656fc02 ("block: virtio-blk: support multi virt queues per virtio-blk device")
Signed-off-by: Hou Tao &lt;houtao1@huawei.com&gt;
Reviewed-by: Stefano Garzarella &lt;sgarzare@redhat.com&gt;
Reviewed-by: Ming Lei &lt;ming.lei@redhat.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>loop: replace kill_bdev with invalidate_bdev</title>
<updated>2020-06-30T19:36:52Z</updated>
<author>
<name>Zheng Bin</name>
<email>zhengbin13@huawei.com</email>
</author>
<published>2020-06-18T04:21:37Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=588ad2b29ea3d4fe95da5ae161b370b539e16382'/>
<id>urn:sha1:588ad2b29ea3d4fe95da5ae161b370b539e16382</id>
<content type='text'>
commit f4bd34b139a3fa2808c4205f12714c65e1548c6c upstream.

When a filesystem is mounted on a loop device and on a loop ioctl
LOOP_SET_STATUS64, because of kill_bdev, buffer_head mappings are getting
destroyed.
kill_bdev
  truncate_inode_pages
    truncate_inode_pages_range
      do_invalidatepage
        block_invalidatepage
          discard_buffer  --&gt;clear BH_Mapped flag

sb_bread
  __bread_gfp
  bh = __getblk_gfp
  --&gt;discard_buffer clear BH_Mapped flag
  __bread_slow
    submit_bh
      submit_bh_wbc
        BUG_ON(!buffer_mapped(bh))  --&gt; hit this BUG_ON

Fixes: 5db470e229e2 ("loop: drop caches if offset or block_size are changed")
Signed-off-by: Zheng Bin &lt;zhengbin13@huawei.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
