Re: kernel 3.10 + applied bcache patches unable to handle kernel NULL pointer dereference

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This one was the working commit for 3.10:

>From 023d8db36affa2489a83052dbb7c969d0941f06f Mon Sep 17 00:00:00 2001
From: Kent Overstreet <koverstreet@xxxxxxxxxx>
Date: Wed, 26 Jun 2013 17:25:38 -0700
Subject: [PATCH 17/17] bcache: FUA fixes

Journal writes need to be marked FUA, not just REQ_FLUSH. And btree node
writes have... weird ordering requirements.

Signed-off-by: Kent Overstreet <koverstreet@xxxxxxxxxx>
---
 drivers/md/bcache/btree.c   |   19 +++++++++++++++++--
 drivers/md/bcache/journal.c |    2 +-
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/md/bcache/btree.c b/drivers/md/bcache/btree.c
index 09fb8a2..803af59 100644
--- a/drivers/md/bcache/btree.c
+++ b/drivers/md/bcache/btree.c
@@ -328,10 +328,25 @@ static void do_btree_node_write(struct btree *b)

        b->bio->bi_end_io       = btree_node_write_endio;
        b->bio->bi_private      = &b->io.cl;
-       b->bio->bi_rw   = REQ_META|WRITE_SYNC;
-       b->bio->bi_size = set_blocks(i, b->c) * block_bytes(b->c);
+       b->bio->bi_rw           = REQ_META|WRITE_SYNC|REQ_FUA;
+       b->bio->bi_size         = set_blocks(i, b->c) * block_bytes(b->c);
        bch_bio_map(b->bio, i);

+       /*
+        * If we're appending to a leaf node, we don't technically need
FUA -
+        * this write just needs to be persisted before the next journal
write,
+        * which will be marked FLUSH|FUA.
+        *
+        * Similarly if we're writing a new btree root - the pointer is
going to
+        * be in the next journal entry.
+        *
+        * But if we're writing a new btree node (that isn't a root) or
+        * appending to a non leaf btree node, we need either FUA or a flush
+        * when we write the parent with the new pointer. FUA is cheaper
than a
+        * flush, and writes appending to leaf nodes aren't blocking
anything so
+        * just make all btree node writes FUA to keep things sane.
+        */
+
        bkey_copy(&k.key, &b->key);
        SET_PTR_OFFSET(&k.key, 0, PTR_OFFSET(&k.key, 0) + bset_offset(b,
i));

diff --git a/drivers/md/bcache/journal.c b/drivers/md/bcache/journal.c
index 5ca2214..4b25066 100644
--- a/drivers/md/bcache/journal.c
+++ b/drivers/md/bcache/journal.c
@@ -620,7 +620,7 @@ static void journal_write_unlocked(struct closure *cl)
                bio_reset(bio);
                bio->bi_sector  = PTR_OFFSET(k, i);
                bio->bi_bdev    = ca->bdev;
-               bio->bi_rw      = REQ_WRITE|REQ_SYNC|REQ_META|REQ_FLUSH;
+               bio->bi_rw      =
REQ_WRITE|REQ_SYNC|REQ_META|REQ_FLUSH|REQ_FUA;
                bio->bi_size    = sectors << 9;

                bio->bi_end_io  = journal_write_endio;
-- 
1.7.10.4

Stefan

Am 12.07.2013 10:42, schrieb Stefan Priebe - Profihost AG:
> it's this one:
> -               bch_writeback_add(dc, bio_sectors(bio));
> +               bch_writeback_add(dc);
> 
> from cache: FUA fixes
> 
> Journal writes need to be marked FUA, not just REQ_FLUSH. And btree node
> writes have... weird ordering requirements.
> 
> in 3.10 bch_writeback_add still needs to arguments.
> 
> Stefan
> 
> Am 12.07.2013 10:38, schrieb Stefan Priebe - Profihost AG:
>> Does not seem to build:
>>   CC [M]  drivers/md/bcache/request.o
>> drivers/md/bcache/request.c: In function ‘request_write’:
>> drivers/md/bcache/request.c:1057: error: too few arguments to function
>> ‘bch_writeback_add’
>> make[3]: *** [drivers/md/bcache/request.o] Error 1
>> make[2]: *** [drivers/md/bcache] Error 2
>>
>> Am 12.07.2013 10:31, schrieb Stefan Priebe - Profihost AG:
>>> Am 12.07.2013 10:19, schrieb Kent Overstreet:
>>>> On Fri, Jul 12, 2013 at 08:11:45AM +0200, Stefan Priebe - Profihost AG wrote:
>>>>> Am 12.07.2013 03:40, schrieb Kent Overstreet:
>>>>>> On Thu, Jul 04, 2013 at 01:45:42PM +0200, Stefan Priebe - Profihost AG wrote:
>>>>>>> fix is this one: http://pastebin.com/raw.php?i=LBFJRvEt
>>>>>>
>>>>>> Oh I see, the patch that introduced this is an old version of the patch
>>>>>> - the bcache-for-3.11 had this fixed, and I forgot to update that
>>>>>> branch. Thanks, I'll apply it there.
>>>>>
>>>>> thanks - which commit id is the fix in? i can't find it.
>>>>
>>>> The patch that introduced it wasn't ever destined for 3.10 anyways, and
>>>> I just deleted the bcache/bcache-3.9 branches because they'd gotten out
>>>> of sync and weren't getting updated with bcache-dev/bcache-for-3.11.
>>>
>>> Thanks!
>>>
>>>> So just stick with bcache-for-3.10, I just backported all the important
>>>> bugfixes to it - I'll be sending that stuff to Greg K-H for 3.10.1 in
>>>> the next couple days too.
>>> Thanks!
>>>
>>> Stefan
>>>
--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM Kernel]     [Linux Filesystem Development]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux