Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: David Matlack <dmatlack@google.com>
To: sashiko-reviews@lists.linux.dev
Cc: kexec@lists.infradead.org, linux-mm@kvack.org,
	Alexander Graf <graf@amazon.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	Christian Brauner <brauner@kernel.org>,
	David Hildenbrand <david@kernel.org>,
	Hugh Dickins <hughd@google.com>, Jonathan Corbet <corbet@lwn.net>,
	"Liam R. Howlett" <liam@infradead.org>,
	Lorenzo Stoakes <ljs@kernel.org>, Michal Hocko <mhocko@suse.com>,
	Mike Rapoport <rppt@kernel.org>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Pratyush Yadav <pratyush@kernel.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Samiullah Khawaja <skhawaja@google.com>,
	Shuah Khan <skhan@linuxfoundation.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Vlastimil Babka <vbabka@kernel.org>
Subject: Re: [PATCH v2 09/10] mm/shmem_luo: Allow retrieving tmpfs files with O_RDONLY
Date: Wed, 28 Oct 2026 23:13:57 +0000	[thread overview]
Message-ID: <auKBtVmCS4jU8e_R@google.com> (raw)
In-Reply-To: <sashiko-outbox-183328@kernel.org>

On 2026-10-23 10:51 PM, sashiko-bot@kernel.org wrote:

> > +	ro_file = dentry_open(&file->f_path, flags, current_cred());
> > +	fput(file);
> > +	return ro_file;
> >  }
> >  
> >  static int shmem_luo_retrieve(struct liveupdate_file_op_args *args)
> 
> [Severity: Medium]
> When userspace retrieves a tmpfs file via LIVEUPDATE_SESSION_RETRIEVE_FD with
> O_RDONLY in arg->flags, does passing the raw flags variable to dentry_open()
> in shmem_luo_create_tmpfs_file() in mm/shmem_luo.c bypass the flag
> normalization performed by file_open_root() -> build_open_flags()?
> 
> In fs/open.c, build_open_flags() strips O_CLOEXEC and ensures O_DSYNC is set
> when __O_SYNC is present:
> 
>     u64 flags = how->flags;
>     u64 strip = O_CLOEXEC;
>     ...
>     flags &= ~strip;
>     ...
>     if (flags & __O_SYNC)
>         flags |= O_DSYNC;
> 
> Because dentry_open() -> alloc_empty_file() -> init_file() initializes
> ro_file->f_flags directly from the passed flags and do_dentry_open() only
> clears:
> 
>     f->f_flags &= ~(O_CREAT | O_EXCL | O_NOCTTY | O_TRUNC | __O_REGULAR);
>     f->f_iocb_flags = iocb_flags(f);
> 
> passing O_RDONLY | O_CLOEXEC in arg->flags leaves O_CLOEXEC in
> ro_file->f_flags (visible via fcntl(fd, F_GETFL) and /proc/<pid>/fdinfo/<fd>),
> and passing O_RDONLY | __O_SYNC without O_DSYNC leaves O_DSYNC and IOCB_DSYNC
> unset on ro_file.
> 
> Should dentry_open() be passed (file->f_flags & ~O_ACCMODE) | O_RDONLY instead
> of flags so that ro_file uses the normalized flags from file?

Yes. I will fix this in v3 to re-open the read-only file with the flags
that file_open_root() already normalized.


  reply	other threads:[~2026-10-28 23:14 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-22 22:50 [PATCH v2 00/10] liveupdate: Preserve tmpfs files across Live Update David Matlack
2026-10-22 22:50 ` [PATCH v2 01/10] liveupdate: Pass user argument to file preserve and retrieve David Matlack
2026-10-23 22:51   ` sashiko-bot
2026-10-22 22:50 ` [PATCH v2 02/10] selftests: liveupdate: Add tests for preserve and retrieve user argument David Matlack
2026-10-23 22:51   ` sashiko-bot
2026-10-22 22:50 ` [PATCH v2 03/10] liveupdate: Allow file handlers to mark retrieve failures as retryable David Matlack
2026-10-23 22:51   ` sashiko-bot
2026-10-22 22:50 ` [PATCH v2 04/10] mm: Rename memfd_luo to shmem_luo David Matlack
2026-10-23 22:51   ` sashiko-bot
2026-10-28 20:36   ` Pasha Tatashin
2026-10-22 22:50 ` [PATCH v2 05/10] liveupdate: Don't WARN if tracking a retrieved file fails David Matlack
2026-10-23 22:51   ` sashiko-bot
2026-10-28 20:36   ` Pasha Tatashin
2026-10-22 22:50 ` [PATCH v2 06/10] mm/shmem_luo: Don't make early retrieve failures permanent David Matlack
2026-10-23 22:51   ` sashiko-bot
2026-10-28 20:36   ` Pasha Tatashin
2026-10-22 22:50 ` [PATCH v2 07/10] mm/shmem_luo: Retrieve tmpfs files onto a tmpfs mount chosen by userspace David Matlack
2026-10-23 22:51   ` sashiko-bot
2026-10-27  5:04   ` kernel test robot
2026-10-27  5:38   ` kernel test robot
2026-10-28 22:02   ` Pasha Tatashin
2026-10-28 23:09     ` David Matlack
2026-10-29  0:04       ` Pasha Tatashin
2026-10-22 22:50 ` [PATCH v2 08/10] mm/shmem_luo: Allow preserving tmpfs files that are still linked David Matlack
2026-10-23 22:51   ` sashiko-bot
2026-10-28 23:22     ` David Matlack
2026-10-22 22:50 ` [PATCH v2 09/10] mm/shmem_luo: Allow retrieving tmpfs files with O_RDONLY David Matlack
2026-10-23 22:51   ` sashiko-bot
2026-10-28 23:13     ` David Matlack [this message]
     [not found] ` <20261022225035.377445-11-dmatlack@google.com>
2026-10-23 22:51   ` [PATCH v2 10/10] selftests/liveupdate: Add a test for preserving tmpfs files sashiko-bot

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=auKBtVmCS4jU8e_R@google.com \
    --to=dmatlack@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=brauner@kernel.org \
    --cc=corbet@lwn.net \
    --cc=david@kernel.org \
    --cc=graf@amazon.com \
    --cc=hughd@google.com \
    --cc=kexec@lists.infradead.org \
    --cc=liam@infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=pratyush@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=rppt@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=skhan@linuxfoundation.org \
    --cc=skhawaja@google.com \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    /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