All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Mike Marshall <hubcap@omnibond.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Christoph Hellwig <hch@lst.de>,
	Martin Brandenburg <martin@omnibond.com>
Subject: Re: side effect from "aio: don't zero entire aio_kiocb aio_get_req"
Date: Sat, 2 Feb 2019 09:35:28 -0700	[thread overview]
Message-ID: <25906140-c699-098f-13aa-fd721bd2e602@kernel.dk> (raw)
In-Reply-To: <CAOg9mSRrtYEw62We=qfYj3tEsscOZ-pGaQHw6BWadBEU6k8CMA@mail.gmail.com>

On 2/1/19 7:29 PM, Mike Marshall wrote:
> We've been working on our Orangefs page cache patch with blinders on,
> and last week I took our patch set which was based on 4.19-rc7
> and applied it to 5.0-rc3.
> 
> In the process I ran vanilla rc3, and rc3 plus an Orangefs related
> patch set that Christoph Hellwig sent in, through the
> suite of xfstests.
> 
> It turns out that a patch from one of Jens Axboe's patch sets
> that came, I think, in the 5.0 merge window triggered a BUG_ON in Orangefs'
> file.c. The particular patch is "aio: don't zero entire aio_kiocb aio_get_req".
> 
> This code is in Orangefs file.c in a couple of places:
> 
> BUG_ON(iocb->private);
> 
> Anywho... I can easily fix the Orangefs problem by removing the two
> BUG_ON statements, I've researched how they got there and they
> are vestigial, just the kind of thing that Linus hates :-).
> 
> The bigger question is that maybe there is other code in other filesystems
> that checks iocb->private without failing in a way that is as obvious
> as BUG_ON. I don't see any upstream code with grep other than a few
> lines in ext4/inode.c that might be affected.
> 
> As a test, I "fixed" the Orangefs problem with this:
> 
> [hubcap@vm1 linux]# git diff
> diff --git a/fs/aio.c b/fs/aio.c
> index b906ff70c90f..2605a4b1a3c9 100644
> --- a/fs/aio.c
> +++ b/fs/aio.c
> @@ -1020,6 +1020,7 @@ static inline struct aio_kiocb
> *aio_get_req(struct kioctx *ctx)
>         if (unlikely(!req))
>                 return NULL;
> 
> +       req->rw.private = NULL;
>         percpu_ref_get(&ctx->reqs);
>         req->ki_ctx = ctx;
>         INIT_LIST_HEAD(&req->ki_list);
> 
> So, the real fix for Orangefs is getting rid of the two BUG_ON lines,
> and I'll do that, I just wanted to bring this up in case it matters
> to anyone else...

Let's just bring it back, I think your patch is fine. I don't see
any other issues with this in a git grep, but better safe than sorry.

Care to send this as a properly formatted patch so it can get
included?

-- 
Jens Axboe


  reply	other threads:[~2019-02-02 16:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-02  2:29 side effect from "aio: don't zero entire aio_kiocb aio_get_req" Mike Marshall
2019-02-02 16:35 ` Jens Axboe [this message]
2019-02-02 16:36   ` Jens Axboe
2019-02-02 17:03     ` Mike Marshall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=25906140-c699-098f-13aa-fd721bd2e602@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=hubcap@omnibond.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=martin@omnibond.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.