On Mon 16-06-25 20:33:28, Lorenzo Stoakes wrote:
> Update nearly all generic_file_mmap() and generic_file_readonly_mmap()
> callers to use generic_file_mmap_prepare() and
> generic_file_readonly_mmap_prepare() respectively.
>
> We update blkdev, 9p, afs, erofs, ext2, nfs, ntfs3, smb, ubifs and vbo
On Mon, 2025-06-16 at 21:41 +0100, Al Viro wrote:
> On Mon, Jun 16, 2025 at 08:33:19PM +0100, Lorenzo Stoakes wrote:
> > REVIEWER'S NOTES
> >
> >
> > I am basing this on the mm-new branch in Andrew's tree, so let me know if I
> > should rebase anything here. Given the mm bits touc
On Mon, Jun 16, 2025 at 10:08:03PM -0700, Christoph Hellwig wrote:
> On Mon, Jun 16, 2025 at 08:33:25PM +0100, Lorenzo Stoakes wrote:
> > STATIC int
> > -xfs_file_mmap(
> > - struct file *file,
> > - struct vm_area_struct *vma)
> > +xfs_file_mmap_prepare(
> > + struct vm_area_d
On Mon, 16 Jun 2025 20:33:19 +0100, Lorenzo Stoakes wrote:
> REVIEWER'S NOTES
>
>
> I am basing this on the mm-new branch in Andrew's tree, so let me know if I
> should rebase anything here. Given the mm bits touched I did think perhaps
> we should take it through the mm tree, how
On Tue, Jun 17, 2025 at 12:23:41PM +0200, Jan Kara wrote:
> On Mon 16-06-25 20:33:28, Lorenzo Stoakes wrote:
> > Update nearly all generic_file_mmap() and generic_file_readonly_mmap()
> > callers to use generic_file_mmap_prepare() and
> > generic_file_readonly_mmap_prepare() respectively.
> >
> >
On Tue, Jun 17, 2025 at 12:08:13PM +0200, Jan Kara wrote:
> On Tue 17-06-25 06:25:34, Lorenzo Stoakes wrote:
> > On Mon, Jun 16, 2025 at 10:11:28PM -0700, Christoph Hellwig wrote:
> > > On Mon, Jun 16, 2025 at 08:33:22PM +0100, Lorenzo Stoakes wrote:
> > > > Since commit c84bf6dd2b83 ("mm: introduc
On Tue, Jun 17, 2025 at 12:28:17PM +0200, Jan Kara wrote:
> On Mon 16-06-25 20:33:29, Lorenzo Stoakes wrote:
> > Since commit c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file
> > callback"), the f_op->mmap() hook has been deprecated in favour of
> > f_op->mmap_prepare().
> >
> > This callback
Lorenzo Stoakes wrote:
> This is preferred to the existing f_op->mmap() hook as it does require a
> VMA to be established yet,
Did you mean ".. doesn't require a VMA to be established yet, ..."
David
On Mon 16-06-25 20:33:21, Lorenzo Stoakes wrote:
> Since commit c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file
> callback"), the f_op->mmap() hook has been deprecated in favour of
> f_op->mmap_prepare().
>
> Therefore, update the check for file operations supporting mmap() by using
> the fi
On 6/16/25 21:33, Lorenzo Stoakes wrote:
> Since commit c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file
> callback"), the f_op->mmap() hook has been deprecated in favour of
> f_op->mmap_prepare().
>
> The generic mmap handlers are very simple, so we can very easily convert
> these in advance
On Tue, Jun 17, 2025 at 4:48 AM Lorenzo Stoakes wrote:
>
> Since commit c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file
> callback"), the f_op->mmap() hook has been deprecated in favour of
> f_op->mmap_prepare().
>
> This callback is invoked in the mmap() logic far earlier, so error handling
On Mon, Jun 16, 2025 at 08:33:29PM +0100, Lorenzo Stoakes wrote:
> Since commit c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file
> callback"), the f_op->mmap() hook has been deprecated in favour of
> f_op->mmap_prepare().
>
> This callback is invoked in the mmap() logic far earlier, so error
On 6/16/25 21:33, Lorenzo Stoakes wrote:
> The call_mmap() function violates the existing convention in
> include/linux/fs.h whereby invocations of virtual file system hooks is
> performed by functions prefixed with vfs_xxx().
>
> Correct this by renaming call_mmap() to vfs_mmap(). This also avoid
On 6/16/25 21:33, Lorenzo Stoakes wrote:
> Since commit c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file
> callback"), the f_op->mmap() hook has been deprecated in favour of
> f_op->mmap_prepare().
>
> Therefore, update the check for file operations supporting mmap() by using
> the file_has_v
On 6/16/25 2:33PM, Lorenzo Stoakes wrote:
Since commit c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file
callback"), the f_op->mmap() hook has been deprecated in favour of
f_op->mmap_prepare().
We have provided generic .mmap_prepare() equivalents, so update all file
systems that specify thes
On Tue, Jun 17, 2025 at 03:05:59PM +0100, David Howells wrote:
> Lorenzo Stoakes wrote:
>
> > This is preferred to the existing f_op->mmap() hook as it does require a
> > VMA to be established yet,
>
> Did you mean ".. doesn't require a VMA to be established yet, ..."
>
> David
>
Yeah apologies,
On Tue, Jun 17, 2025 at 09:45:32AM -0400, Jeff Layton wrote:
> On Mon, 2025-06-16 at 21:41 +0100, Al Viro wrote:
> > On Mon, Jun 16, 2025 at 08:33:19PM +0100, Lorenzo Stoakes wrote:
> > > REVIEWER'S NOTES
> > >
> > >
> > > I am basing this on the mm-new branch in Andrew's tree, so
On Mon 16-06-25 20:33:29, Lorenzo Stoakes wrote:
> Since commit c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file
> callback"), the f_op->mmap() hook has been deprecated in favour of
> f_op->mmap_prepare().
>
> This callback is invoked in the mmap() logic far earlier, so error handling
> can b
On Mon, Jun 16, 2025 at 04:11:11PM -0700, Andrew Morton wrote:
> On Mon, 16 Jun 2025 20:33:19 +0100 Lorenzo Stoakes
> wrote:
>
> > I am basing this on the mm-new branch in Andrew's tree, so let me know if I
> > should rebase anything here. Given the mm bits touched I did think perhaps
> > we sho
On Mon, Jun 16, 2025 at 09:26:54PM +0100, Matthew Wilcox wrote:
> On Mon, Jun 16, 2025 at 08:33:23PM +0100, Lorenzo Stoakes wrote:
> > fs/ext4/file.c | 2 +-
> > fs/xfs/xfs_file.c | 3 ++-
>
> Both of these already have the inode from the file ...
>
> > +static inline bool daxdev_mapping
On Mon 16-06-25 20:33:26, Lorenzo Stoakes wrote:
> Since commit c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file
> callback"), the f_op->mmap() hook has been deprecated in favour of
> f_op->mmap_prepare().
>
> The generic mmap handlers are very simple, so we can very easily convert
> these in
On Mon, Jun 16, 2025 at 08:33:25PM +0100, Lorenzo Stoakes wrote:
> STATIC int
> -xfs_file_mmap(
> - struct file *file,
> - struct vm_area_struct *vma)
> +xfs_file_mmap_prepare(
> + struct vm_area_desc *desc)
Please stick to the existing alignment for the declarations.
O
On Tue, Jun 17, 2025 at 06:25:34AM +0100, Lorenzo Stoakes wrote:
> > > Most notably, this updates the elf logic to allow for the ability to
> > > execute binaries on filesystems which have the .mmap_prepare hook, but
> > > additionally we update nested filesystems.
> >
> > Can you please give the f
On Mon, Jun 16, 2025 at 10:10:30PM -0700, Christoph Hellwig wrote:
> On Mon, Jun 16, 2025 at 08:33:20PM +0100, Lorenzo Stoakes wrote:
> > The call_mmap() function violates the existing convention in
> > include/linux/fs.h whereby invocations of virtual file system hooks is
> > performed by function
On Mon, Jun 16, 2025 at 08:33:20PM +0100, Lorenzo Stoakes wrote:
> The call_mmap() function violates the existing convention in
> include/linux/fs.h whereby invocations of virtual file system hooks is
> performed by functions prefixed with vfs_xxx().
>
> Correct this by renaming call_mmap() to vfs
On Mon 16-06-25 20:33:27, Lorenzo Stoakes wrote:
> Since commit c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file
> callback"), the f_op->mmap() hook has been deprecated in favour of
> f_op->mmap_prepare().
>
> We have provided generic .mmap_prepare() equivalents, so update all file
> systems
On Tue 17-06-25 06:25:34, Lorenzo Stoakes wrote:
> On Mon, Jun 16, 2025 at 10:11:28PM -0700, Christoph Hellwig wrote:
> > On Mon, Jun 16, 2025 at 08:33:22PM +0100, Lorenzo Stoakes wrote:
> > > Since commit c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file
> > > callback"), the f_op->mmap() hook
On Mon 16-06-25 20:33:24, Lorenzo Stoakes wrote:
> Since commit c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file
> callback"), the f_op->mmap() hook has been deprecated in favour of
> f_op->mmap_prepare().
>
> This callback is invoked in the mmap() logic far earlier, so error handling
> can b
On Mon, Jun 16, 2025 at 08:33:22PM +0100, Lorenzo Stoakes wrote:
> Since commit c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file
> callback"), the f_op->mmap() hook has been deprecated in favour of
> f_op->mmap_prepare().
>
> Additionally, commit bb666b7c2707 ("mm: add mmap_prepare() compatib
On Mon, 2025-06-16 at 20:33 +0100, Lorenzo Stoakes wrote:
> Since commit c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file
> callback"), the f_op->mmap() hook has been deprecated in favour of
> f_op->mmap_prepare().
>
> This callback is invoked in the mmap() logic far earlier, so error handlin
On 6/17/25 4:33 AM, Lorenzo Stoakes wrote:
> Since commit c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file
> callback"), the f_op->mmap() hook has been deprecated in favour of
> f_op->mmap_prepare().
>
> This callback is invoked in the mmap() logic far earlier, so error handling
> can be perf
On Mon, Jun 16, 2025 at 10:11:28PM -0700, Christoph Hellwig wrote:
> On Mon, Jun 16, 2025 at 08:33:22PM +0100, Lorenzo Stoakes wrote:
> > Since commit c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file
> > callback"), the f_op->mmap() hook has been deprecated in favour of
> > f_op->mmap_prepare(
On Mon, 2025-06-16 at 20:33 +0100, Lorenzo Stoakes wrote:
> Since commit c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file
> callback"), the f_op->mmap() hook has been deprecated in favour of
> f_op->mmap_prepare().
>
> We have provided generic .mmap_prepare() equivalents, so update all file
>
On Mon, 16 Jun 2025 20:33:19 +0100 Lorenzo Stoakes
wrote:
> I am basing this on the mm-new branch in Andrew's tree, so let me know if I
> should rebase anything here. Given the mm bits touched I did think perhaps
> we should take it through the mm tree, however it may be more sensible to
> take
On Thu, 19 Jun 2025 21:38:47 +0900,
Benjamin Berg wrote:
>
> On Thu, 2025-06-19 at 21:22 +0900, Hajime Tazaki wrote:
> >
> > On Thu, 19 Jun 2025 19:40:49 +0900,
> > Benjamin Berg wrote:
> > >
> > > On Thu, 2025-06-19 at 10:04 +0900, Hajime Tazaki wrote:
> > > > As userspace on UML/!MMU also ne
Thanks,
# this is a thread of my older series, v7 (current one is v9), tho
your comment is still valid so, thanks !
On Thu, 19 Jun 2025 20:43:06 +0900,
Benjamin Berg wrote:
>
> Hi,
>
> I am not sure that fxsaveq/fxrstorq is guaranteed to be sufficient. I
> don't think that catches some of the
On Thu, 2025-06-19 at 21:22 +0900, Hajime Tazaki wrote:
>
> On Thu, 19 Jun 2025 19:40:49 +0900,
> Benjamin Berg wrote:
> >
> > On Thu, 2025-06-19 at 10:04 +0900, Hajime Tazaki wrote:
> > > As userspace on UML/!MMU also need to configure %fs register when
> > > it is
> > > running to correctly acc
On Thu, 19 Jun 2025 19:40:49 +0900,
Benjamin Berg wrote:
>
> On Thu, 2025-06-19 at 10:04 +0900, Hajime Tazaki wrote:
> > As userspace on UML/!MMU also need to configure %fs register when it is
> > running to correctly access thread structure, host syscalls implemented
> > in os-Linux drivers may
Hello,
On Thu, 19 Jun 2025 19:36:04 +0900,
Benjamin Berg wrote:
> > +void arch_switch_to(struct task_struct *to)
> > +{
> > + /*
> > +* In !CONFIG_MMU, it doesn't ptrace thus,
> > +* The FS_BASE/GS_BASE registers are saved here.
> > +*/
> > + current_top_of_stack = task_top_of_s
Hi,
I am not sure that fxsaveq/fxrstorq is guaranteed to be sufficient. I
don't think that catches some of the newer AVX registers for example.
At the same time, dealing with all that properly could be rather
annoying. I don't really have a solution for that, normal UM does not
need to deal with
On Thu, 2025-06-19 at 10:04 +0900, Hajime Tazaki wrote:
> As userspace on UML/!MMU also need to configure %fs register when it is
> running to correctly access thread structure, host syscalls implemented
> in os-Linux drivers may be puzzled when they are called. Thus it has to
> configure %fs regi
Hi,
On Thu, 2025-06-19 at 10:04 +0900, Hajime Tazaki wrote:
> Since ptrace facility isn't used under !MMU of UML, there is different
> code path to invoke processes/threads; there are no external process
> used, and need to properly configure some of registers (fs segment
> register for TLS, etc)
42 matches
Mail list logo
