gfs2.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Andreas Gruenbacher <agruenba@redhat.com>
Cc: gfs2@lists.linux.dev
Subject: Re: [PATCH 0/9] gfs2: Bugs in "Use GL_NOBLOCK flag for non-blocking lookups"
Date: Fri, 2 Feb 2024 04:34:38 +0000	[thread overview]
Message-ID: <20240202043438.GA871762@ZenIV> (raw)
In-Reply-To: <20240202042312.GY2087318@ZenIV>

On Fri, Feb 02, 2024 at 04:23:13AM +0000, Al Viro wrote:
> On Fri, Jan 19, 2024 at 10:20:47PM +0100, Andreas Gruenbacher wrote:
> > Hello,
> > 
> > Al Viro has reported issues with commit dd00aaeb3432 ("gfs2: Use
> > GL_NOBLOCK flag for non-blocking lookups"):
> > 
> > * First, parent can now be NULL and dereferencing it in
> >   gfs2_dir_check(d_inode(parent), &dentry->d_name, ip) isn't going to
> >   work;
> > 
> > * Second, gfs2_dir_check() can still sleep, which breaks LOOKUP_RCU
> >   mode.
> 
> Looks sane, but there's another piece of fun in gfs_permission():
>         gl = rcu_dereference_check(ip->i_gl, !may_not_block);
>         if (unlikely(!gl)) {
>                 /* inode is getting torn down, must be RCU mode */
>                 WARN_ON_ONCE(!may_not_block);
>                 return -ECHILD;
>         }
>         if (gfs2_glock_is_locked_by_me(ip->i_gl) == NULL) {
>                 int noblock = may_not_block ? GL_NOBLOCK : 0;
>                 error = gfs2_glock_nq_init(ip->i_gl, LM_ST_SHARED,
>                                            LM_FLAG_ANY | noblock, &i_gh);
>                 if (error)
>                         return error;
>         }
> 
> See the problem?  In RCU mode we carefully fetch ->i_gl and verify
> it's not NULL.  Then we proceed to dereference it again.
> 
> IOW, these ip->i_gl below ought to be replaced with gl, or you are
> risking a compiler fetching the sucker again and getting NULL this
> time around.

fix breakage in gfs2_permission()

"gfs2: Use GL_NOBLOCK flag for non-blocking lookups" has
reintroduced the bug fixed in "gfs2: fix an oops in
gfs2_permission" a while ago.  We still fetch ->i_gl carefully,
and check if it's NULL, but then we proceed to fetch it again.
If it became NULL in the meanwhile, we get trouble...

Trivial to fix, fortunately.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c
index 6bfc9383b7b8..d045562bf08f 100644
--- a/fs/gfs2/inode.c
+++ b/fs/gfs2/inode.c
@@ -1882,9 +1882,9 @@ int gfs2_permission(struct mnt_idmap *idmap, struct inode *inode,
 		WARN_ON_ONCE(!may_not_block);
 		return -ECHILD;
         }
-	if (gfs2_glock_is_locked_by_me(ip->i_gl) == NULL) {
+	if (gfs2_glock_is_locked_by_me(gl) == NULL) {
 		int noblock = may_not_block ? GL_NOBLOCK : 0;
-		error = gfs2_glock_nq_init(ip->i_gl, LM_ST_SHARED,
+		error = gfs2_glock_nq_init(gl, LM_ST_SHARED,
 					   LM_FLAG_ANY | noblock, &i_gh);
 		if (error)
 			return error;

  reply	other threads:[~2024-02-02  4:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-19 21:20 [PATCH 0/9] gfs2: Bugs in "Use GL_NOBLOCK flag for non-blocking lookups" Andreas Gruenbacher
2024-01-19 21:20 ` [PATCH 1/9] gfs2: Fix gfs2_drevalidate NULL pointer dereference Andreas Gruenbacher
2024-01-19 21:20 ` [PATCH 2/9] gfs2: Pass FGP flags to gfs2_getbuf Andreas Gruenbacher
2024-01-19 21:20 ` [PATCH 3/9] gfs2: Split gfs2_meta_read_async off from gfs2_meta_read Andreas Gruenbacher
2024-01-19 21:20 ` [PATCH 4/9] gfs2: Add FGP_NOWAIT support to gfs2_meta_read_async Andreas Gruenbacher
2024-01-19 21:20 ` [PATCH 5/9] gfs2: Pass FGP flags to gfs2_meta_{,inode_}buffer Andreas Gruenbacher
2024-01-19 21:20 ` [PATCH 6/9] gfs2: Pass FGP flags to gfs2_dirent_search Andreas Gruenbacher
2024-01-19 21:20 ` [PATCH 7/9] gfs2: Pass FGP flags to gfs2_dir_check Andreas Gruenbacher
2024-01-19 21:20 ` [PATCH 8/9] gfs2: Minor gfs2_drevalidate cleanup Andreas Gruenbacher
2024-01-19 21:20 ` [PATCH 9/9] gfs2: Fix LOOKUP_RCU support in gfs2_drevalidate Andreas Gruenbacher
2024-01-20  1:36 ` [PATCH 0/9] gfs2: Bugs in "Use GL_NOBLOCK flag for non-blocking lookups" Al Viro
2024-01-20  1:38   ` Al Viro
2024-01-22 12:52 ` Andrew Price
2024-02-02  4:23 ` Al Viro
2024-02-02  4:34   ` Al Viro [this message]
2024-02-02 16:32     ` Andreas Gruenbacher
2024-02-02  4:59   ` Al Viro
2024-02-02  5:02     ` Al Viro
2024-02-02 17:09     ` Andreas Gruenbacher

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=20240202043438.GA871762@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=agruenba@redhat.com \
    --cc=gfs2@lists.linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).