linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mateusz Guzik <mjguzik@gmail.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: brauner@kernel.org, jack@suse.cz, linux-kernel@vger.kernel.org,
	 linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] vfs: avoid spurious dentry ref/unref cycle on open
Date: Wed, 7 Aug 2024 05:57:07 +0200	[thread overview]
Message-ID: <CAGudoHFJe0X-OD42cWrgTObq=G_AZnqCHWPPGawy0ur1b84HGw@mail.gmail.com> (raw)
In-Reply-To: <20240807033820.GS5334@ZenIV>

On Wed, Aug 7, 2024 at 5:38 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Tue, Aug 06, 2024 at 06:09:43PM +0200, Mateusz Guzik wrote:
>
> > It is supposed to indicate that both nd->path.mnt and nd->path.dentry
> > are no longer usable and must not even be looked at. Ideally code
> > which *does* look at them despite the flag (== there is a bug) traps.
> >
> > However, I did not find a handy macro or anything of the sort to
> > "poison" these pointers. Instead I found tons of NULL checks all over,
> > including in lookup clean up.
>
> Unless I'm misreading you, those existing NULLs have nothing to do with
> poisoning of any sort.  Or any kind of defensive programming, while we are
> at it.  Those are about the cleanups on failed transition from lazy mode;
> if we have already legitimized some of the references (i.e. bumped the
> refcounts there) by the time we'd run into a stale one, we need to drop
> the ones we'd grabbed on the way out.  And the easiest way to do that
> is to leave that until terminate_walk(), when we'll be out of RCU mode.
> The references that were *NOT* grabbed obviously should be left alone
> rather than dropped.  Which is where those NULL assignments come from.

Yes, this is my understanding of the code and part of my compliant. :)

Things just work(tm) as is with NULLified pointers, but this is error-prone.

I was looking for an equivalent of the following feature from $elsewhere:
/*
 * Trap accesses going through a pointer. Moreover if kasan is available trap
 * reading the pointer itself.
 *
 * Sample usage: you have a struct with numerous fields and by API contract
 * only some of them get populated, even if the implementation temporary writes
 * to them. You can use DEBUG_POISON_POINTER so that the consumer which should
 * no be looking at the field gets caught.
 *
 * DEBUG_POISON_POINTER(obj->ptr);
 * ....
 * if (obj->ptr != NULL) // traps with kasan, does not trap otherwise
 * ....
 * if (obj->ptr->field) // traps with and without kasan
 */
extern caddr_t poisoned_buf;
#define DEBUG_POISON_POINTER_VALUE poisoned_buf

#define DEBUG_POISON_POINTER(x) ({                              \
        x = (void *)(DEBUG_POISON_POINTER_VALUE);               \
        kasan_mark(&x, 0, sizeof(x), KASAN_GENERIC_REDZONE);    \
})

As a hypothetical suppose there is code executing some time after
vfs_open which looks at nd->path.dentry and by finding the pointer is
NULL it concludes the lookup did not work out.

If such code exists *and* the pointer is poisoned in the above sense
(notably merely branching on it with kasan already traps), then the
consumer will be caught immediately during coverage testing by
syzkaller.
If such code exists but the pointer is only nullified, one is only
going to find out the hard way when some functionality weirdly breaks.

Anyhow, this is really beyond the scope of the patch and I should not
have done the half-assed thing abandoned mid-effort. I'm going to get
back to this later(tm).

See the v2 which just gets to the point concerning eliding the extra ref trip.

-- 
Mateusz Guzik <mjguzik gmail.com>

  reply	other threads:[~2024-08-07  3:57 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-06 14:46 [PATCH] vfs: avoid spurious dentry ref/unref cycle on open Mateusz Guzik
2024-08-06 15:53 ` Al Viro
2024-08-06 16:09   ` Mateusz Guzik
2024-08-06 16:14     ` Mateusz Guzik
2024-08-07  3:38     ` Al Viro
2024-08-07  3:57       ` Mateusz Guzik [this message]
2024-08-07  5:32         ` Al Viro
2024-08-07  5:46           ` Mateusz Guzik
2024-08-07  6:23         ` Al Viro
2024-08-07  6:33           ` Al Viro
2024-08-07  6:40             ` Mateusz Guzik
2024-08-07  7:05               ` Al Viro
2024-08-07  7:22                 ` Mateusz Guzik
2024-08-07  7:52                   ` Al Viro
2024-08-07  7:59                     ` Mateusz Guzik
2024-08-07  9:50                       ` Mateusz Guzik
2024-08-07 12:43                         ` Al Viro
2024-08-07 20:38                           ` Al Viro
2024-08-20 11:38                             ` Mateusz Guzik
2024-08-22  0:33                               ` Al Viro
2024-08-22  0:34                                 ` [PATCH 1/3] don't duplicate vfs_open() in kernel_file_open() Al Viro
2024-08-22  7:53                                   ` Christian Brauner
2024-08-22  0:41                                 ` [PATCH 2/3] lift grabbing path into caller of do_dentry_open() Al Viro
2024-08-22  7:54                                   ` Christian Brauner
2024-08-22  0:41                                 ` [PATCH 3/3] avoid extra path_get/path_put cycle in path_openat() Al Viro
2024-08-22  9:31                                   ` Christian Brauner
2024-08-22 10:21                                   ` Mateusz Guzik
2025-02-17  8:03                                 ` [PATCH] vfs: avoid spurious dentry ref/unref cycle on open Mateusz Guzik
2024-08-08  6:26                           ` Mateusz Guzik
2024-08-06 22:51 ` Dave Chinner
2024-08-06 22:55   ` Mateusz Guzik
2024-08-07  2:56     ` Dave Chinner

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='CAGudoHFJe0X-OD42cWrgTObq=G_AZnqCHWPPGawy0ur1b84HGw@mail.gmail.com' \
    --to=mjguzik@gmail.com \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 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 NNTP newsgroup(s).