On Sun, May 10, 2020 at 6:20 PM Bart Van Assche <bvanassche@xxxxxxx> wrote: > > On 2020-05-10 03:03, Alexander Potapenko wrote: > > Thanks for the explanation! > > The code has changed recently, and my patch does not apply anymore, > > yet the problem still persists. > > I ended up just calling null_handle_rq() at the end of > > null_process_cmd(), but we probably need a cleaner fix. > > Does this (totally untested) patch help? copy_to_nullb() guarantees that > it will write some data to the pages that it allocates but does not > guarantee yet that all data of the pages it allocates is initialized. No, this does not help. Apparently null_insert_page() is never called in this scenario. If I modify __page_cache_alloc() to allocate zero-initialized pages, the reports go away. This means there's no other uninitialized buffer that's copied to the page cache, the nullb driver just forgets to write anything to the page cache. > diff --git a/drivers/block/null_blk_main.c b/drivers/block/null_blk_main.c > index 8efd8778e209..06f5761fccb6 100644 > --- a/drivers/block/null_blk_main.c > +++ b/drivers/block/null_blk_main.c > @@ -848,7 +848,7 @@ static struct nullb_page *null_insert_page(struct > nullb *nullb, > > spin_unlock_irq(&nullb->lock); > > - t_page = null_alloc_page(GFP_NOIO); > + t_page = null_alloc_page(GFP_NOIO | __GFP_ZERO); > if (!t_page) > goto out_lock; > -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
