<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/md, branch v5.2</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v5.2</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v5.2'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2019-06-28T00:48:21Z</updated>
<entry>
<title>Merge tag 'for-5.2/dm-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm</title>
<updated>2019-06-28T00:48:21Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2019-06-28T00:48:21Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=65ee21eb633c644501185502d51831c4dee22c7b'/>
<id>urn:sha1:65ee21eb633c644501185502d51831c4dee22c7b</id>
<content type='text'>
Pull device mapper fixes from Mike Snitzer:

 - Fix incorrect uses of kstrndup and DM logging macros in DM's early
   init code.

 - Fix DM log-writes target's handling of super block sectors so updates
   are made in order through use of completion.

 - Fix DM core's argument splitting code to avoid undefined behaviour
   reported as a side-effect of UBSAN analysis on ppc64le.

 - Fix DM verity target to limit the amount of error messages that can
   result from a corrupt block being found.

* tag 'for-5.2/dm-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
  dm verity: use message limit for data block corruption message
  dm table: don't copy from a NULL pointer in realloc_argv()
  dm log writes: make sure super sector log updates are written in order
  dm init: remove trailing newline from calls to DMERR() and DMINFO()
  dm init: fix incorrect uses of kstrndup()
</content>
</entry>
<entry>
<title>dm verity: use message limit for data block corruption message</title>
<updated>2019-06-25T18:09:14Z</updated>
<author>
<name>Milan Broz</name>
<email>gmazyland@gmail.com</email>
</author>
<published>2019-06-20T11:00:19Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=2eba4e640b2c4161e31ae20090a53ee02a518657'/>
<id>urn:sha1:2eba4e640b2c4161e31ae20090a53ee02a518657</id>
<content type='text'>
DM verity should also use DMERR_LIMIT to limit repeat data block
corruption messages.

Signed-off-by: Milan Broz &lt;gmazyland@gmail.com&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
</content>
</entry>
<entry>
<title>dm table: don't copy from a NULL pointer in realloc_argv()</title>
<updated>2019-06-25T18:09:13Z</updated>
<author>
<name>Jerome Marchand</name>
<email>jmarchan@redhat.com</email>
</author>
<published>2019-06-12T16:22:26Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a0651926553cfe7992166432e418987760882652'/>
<id>urn:sha1:a0651926553cfe7992166432e418987760882652</id>
<content type='text'>
For the first call to realloc_argv() in dm_split_args(), old_argv is
NULL and size is zero. Then memcpy is called, with the NULL old_argv
as the source argument and a zero size argument. AFAIK, this is
undefined behavior and generates the following warning when compiled
with UBSAN on ppc64le:

In file included from ./arch/powerpc/include/asm/paca.h:19,
                 from ./arch/powerpc/include/asm/current.h:16,
                 from ./include/linux/sched.h:12,
                 from ./include/linux/kthread.h:6,
                 from drivers/md/dm-core.h:12,
                 from drivers/md/dm-table.c:8:
In function 'memcpy',
    inlined from 'realloc_argv' at drivers/md/dm-table.c:565:3,
    inlined from 'dm_split_args' at drivers/md/dm-table.c:588:9:
./include/linux/string.h:345:9: error: argument 2 null where non-null expected [-Werror=nonnull]
  return __builtin_memcpy(p, q, size);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/md/dm-table.c: In function 'dm_split_args':
./include/linux/string.h:345:9: note: in a call to built-in function '__builtin_memcpy'

Signed-off-by: Jerome Marchand &lt;jmarchan@redhat.com&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
</content>
</entry>
<entry>
<title>dm log writes: make sure super sector log updates are written in order</title>
<updated>2019-06-25T18:09:13Z</updated>
<author>
<name>zhangyi (F)</name>
<email>yi.zhang@huawei.com</email>
</author>
<published>2019-06-05T13:27:08Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=211ad4b733037f66f9be0a79eade3da7ab11cbb8'/>
<id>urn:sha1:211ad4b733037f66f9be0a79eade3da7ab11cbb8</id>
<content type='text'>
Currently, although we submit super bios in order (and super.nr_entries
is incremented by each logged entry), submit_bio() is async so each
super sector may not be written to log device in order and then the
final nr_entries may be smaller than it should be.

This problem can be reproduced by the xfstests generic/455 with ext4:

  QA output created by 455
 -Silence is golden
 +mark 'end' does not exist

Fix this by serializing submission of super sectors to make sure each
is written to the log disk in order.

Fixes: 0e9cebe724597 ("dm: add log writes target")
Cc: stable@vger.kernel.org
Signed-off-by: zhangyi (F) &lt;yi.zhang@huawei.com&gt;
Suggested-by: Josef Bacik &lt;josef@toxicpanda.com&gt;
Reviewed-by: Josef Bacik &lt;josef@toxicpanda.com&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
</content>
</entry>
<entry>
<title>dm init: remove trailing newline from calls to DMERR() and DMINFO()</title>
<updated>2019-06-25T17:43:09Z</updated>
<author>
<name>Stephen Boyd</name>
<email>swboyd@chromium.org</email>
</author>
<published>2019-06-05T01:27:29Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=10c9c8e7c09b4d32b31df1bd14673bd6dbfc50be'/>
<id>urn:sha1:10c9c8e7c09b4d32b31df1bd14673bd6dbfc50be</id>
<content type='text'>
These printing macros already add a trailing newline, so having another
one here just makes for blank lines when these prints are enabled.
Remove these needless newlines.

Fixes: 6bbc923dfcf5 ("dm: add support to directly boot to a mapped device")
Signed-off-by: Stephen Boyd &lt;swboyd@chromium.org&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
</content>
</entry>
<entry>
<title>dm init: fix incorrect uses of kstrndup()</title>
<updated>2019-06-25T17:34:52Z</updated>
<author>
<name>Gen Zhang</name>
<email>blackgod016574@gmail.com</email>
</author>
<published>2019-05-29T01:33:20Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=dec7e6494e1aea6bf676223da3429cd17ce0af79'/>
<id>urn:sha1:dec7e6494e1aea6bf676223da3429cd17ce0af79</id>
<content type='text'>
Fix 2 kstrndup() calls with incorrect argument order.

Fixes: 6bbc923dfcf5 ("dm: add support to directly boot to a mapped device")
Cc: stable@vger.kernel.org # v5.1
Signed-off-by: Gen Zhang &lt;blackgod016574@gmail.com&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
</content>
</entry>
<entry>
<title>md: fix for divide error in status_resync</title>
<updated>2019-06-18T15:02:25Z</updated>
<author>
<name>Mariusz Tkaczyk</name>
<email>mariusz.tkaczyk@intel.com</email>
</author>
<published>2019-06-13T14:11:41Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=9642fa73d073527b0cbc337cc17a47d545d82cd2'/>
<id>urn:sha1:9642fa73d073527b0cbc337cc17a47d545d82cd2</id>
<content type='text'>
Stopping external metadata arrays during resync/recovery causes
retries, loop of interrupting and starting reconstruction, until it
hit at good moment to stop completely. While these retries
curr_mark_cnt can be small- especially on HDD drives, so subtraction
result can be smaller than 0. However it is casted to uint without
checking. As a result of it the status bar in /proc/mdstat while stopping
is strange (it jumps between 0% and 99%).

The real problem occurs here after commit 72deb455b5ec ("block: remove
CONFIG_LBDAF"). Sector_div() macro has been changed, now the
divisor is casted to uint32. For db = -8 the divisior(db/32-1) becomes 0.

Check if db value can be really counted and replace these macro by
div64_u64() inline.

Signed-off-by: Mariusz Tkaczyk &lt;mariusz.tkaczyk@intel.com&gt;
Signed-off-by: Song Liu &lt;songliubraving@fb.com&gt;
</content>
</entry>
<entry>
<title>bcache: only set BCACHE_DEV_WB_RUNNING when cached device attached</title>
<updated>2019-06-13T09:09:15Z</updated>
<author>
<name>Coly Li</name>
<email>colyli@suse.de</email>
</author>
<published>2019-06-09T22:13:35Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=1f0ffa67349c56ea54c03ccfd1e073c990e7411e'/>
<id>urn:sha1:1f0ffa67349c56ea54c03ccfd1e073c990e7411e</id>
<content type='text'>
When people set a writeback percent via sysfs file,
  /sys/block/bcache&lt;N&gt;/bcache/writeback_percent
current code directly sets BCACHE_DEV_WB_RUNNING to dc-&gt;disk.flags
and schedules kworker dc-&gt;writeback_rate_update.

If there is no cache set attached to, the writeback kernel thread is
not running indeed, running dc-&gt;writeback_rate_update does not make
sense and may cause NULL pointer deference when reference cache set
pointer inside update_writeback_rate().

This patch checks whether the cache set point (dc-&gt;disk.c) is NULL in
sysfs interface handler, and only set BCACHE_DEV_WB_RUNNING and
schedule dc-&gt;writeback_rate_update when dc-&gt;disk.c is not NULL (it
means the cache device is attached to a cache set).

This problem might be introduced from initial bcache commit, but
commit 3fd47bfe55b0 ("bcache: stop dc-&gt;writeback_rate_update properly")
changes part of the original code piece, so I add 'Fixes: 3fd47bfe55b0'
to indicate from which commit this patch can be applied.

Fixes: 3fd47bfe55b0 ("bcache: stop dc-&gt;writeback_rate_update properly")
Reported-by: Bjørn Forsman &lt;bjorn.forsman@gmail.com&gt;
Signed-off-by: Coly Li &lt;colyli@suse.de&gt;
Reviewed-by: Bjørn Forsman &lt;bjorn.forsman@gmail.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>bcache: fix stack corruption by PRECEDING_KEY()</title>
<updated>2019-06-13T09:09:14Z</updated>
<author>
<name>Coly Li</name>
<email>colyli@suse.de</email>
</author>
<published>2019-06-09T22:13:34Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=31b90956b124240aa8c63250243ae1a53585c5e2'/>
<id>urn:sha1:31b90956b124240aa8c63250243ae1a53585c5e2</id>
<content type='text'>
Recently people report bcache code compiled with gcc9 is broken, one of
the buggy behavior I observe is that two adjacent 4KB I/Os should merge
into one but they don't. Finally it turns out to be a stack corruption
caused by macro PRECEDING_KEY().

See how PRECEDING_KEY() is defined in bset.h,
437 #define PRECEDING_KEY(_k)                                       \
438 ({                                                              \
439         struct bkey *_ret = NULL;                               \
440                                                                 \
441         if (KEY_INODE(_k) || KEY_OFFSET(_k)) {                  \
442                 _ret = &amp;KEY(KEY_INODE(_k), KEY_OFFSET(_k), 0);  \
443                                                                 \
444                 if (!_ret-&gt;low)                                 \
445                         _ret-&gt;high--;                           \
446                 _ret-&gt;low--;                                    \
447         }                                                       \
448                                                                 \
449         _ret;                                                   \
450 })

At line 442, _ret points to address of a on-stack variable combined by
KEY(), the life range of this on-stack variable is in line 442-446,
once _ret is returned to bch_btree_insert_key(), the returned address
points to an invalid stack address and this address is overwritten in
the following called bch_btree_iter_init(). Then argument 'search' of
bch_btree_iter_init() points to some address inside stackframe of
bch_btree_iter_init(), exact address depends on how the compiler
allocates stack space. Now the stack is corrupted.

Fixes: 0eacac22034c ("bcache: PRECEDING_KEY()")
Signed-off-by: Coly Li &lt;colyli@suse.de&gt;
Reviewed-by: Rolf Fokkens &lt;rolf@rolffokkens.nl&gt;
Reviewed-by: Pierre JUHEN &lt;pierre.juhen@orange.fr&gt;
Tested-by: Shenghui Wang &lt;shhuiw@foxmail.com&gt;
Tested-by: Pierre JUHEN &lt;pierre.juhen@orange.fr&gt;
Cc: Kent Overstreet &lt;kent.overstreet@gmail.com&gt;
Cc: Nix &lt;nix@esperi.org.uk&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 428</title>
<updated>2019-06-05T15:37:16Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2019-06-01T08:08:42Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=55716d26439f5c4008b0bcb7f17d1f7c0d8fbcfc'/>
<id>urn:sha1:55716d26439f5c4008b0bcb7f17d1f7c0d8fbcfc</id>
<content type='text'>
Based on 1 normalized pattern(s):

  this file is released under the gplv2

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 68 file(s).

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Armijn Hemel &lt;armijn@tjaldur.nl&gt;
Reviewed-by: Allison Randal &lt;allison@lohutok.net&gt;
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190531190114.292346262@linutronix.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
