* Re: [PATCH v14 03/15] fat: Implement fileattr_get for case sensitivity
From: Chuck Lever @ 2026-05-20 15:12 UTC (permalink / raw)
To: Mark Brown
Cc: Alexander Viro, Christian Brauner, Jan Kara, linux-fsdevel,
linux-ext4, linux-xfs, linux-cifs, linux-nfs, linux-api,
linux-f2fs-devel, OGAWA Hirofumi, Namjae Jeon, Sungjong Seo,
Yuezhang Mo, almaz.alexandrovich, Viacheslav Dubeyko,
John Paul Adrian Glaubitz, frank.li, Theodore Tso, adilger.kernel,
Carlos Maiolino, Steve French, Paulo Alcantara, Ronnie Sahlberg,
Shyam Prasad N, Trond Myklebust, Anna Schumaker, Jaegeuk Kim,
Chao Yu, Hans de Goede, senozhatsky, Chuck Lever, Roland Mainz
In-Reply-To: <a366645c-364d-4588-8a15-4cd446f64366@sirena.org.uk>
On Wed, May 20, 2026, at 10:54 AM, Mark Brown wrote:
> On Wed, May 20, 2026 at 10:39:16AM -0400, Chuck Lever wrote:
>> On Wed, May 20, 2026, at 10:31 AM, Mark Brown wrote:
>> > On Thu, May 07, 2026 at 04:52:56AM -0400, Chuck Lever wrote:
>
>> > I'm seeing a regression in -next with the LTP statx04 test which bisects
>> > to this commit:
>
>> > tst_tmpdir.c:316: TINFO: Using /tmp/LTP_sta8hUyB4 as tmpdir (tmpfs
>> > filesystem)
>> > tst_device.c:98: TINFO: Found free device 0 '/dev/loop0'
>> > tst_test.c:2047: TINFO: LTP version: 20260130
>> > tst_test.c:2050: TINFO: Tested kernel: 7.1.0-rc4-next-20260520 #1 SMP
>> > PREEMPT @1779279361 aarch64
>
>> > ...
>
>> > tst_test.c:1985: TINFO: === Testing on vfat ===
>> > tst_test.c:1290: TINFO: Formatting /dev/loop0 with vfat opts='' extra
>> > opts=''
>> > tst_test.c:1302: TINFO: Mounting /dev/loop0 to
>> > /tmp/LTP_sta8hUyB4/mntpoint fstyp=vfat flags=0
>> > statx04.c:121: TFAIL: STATX_ATTR_COMPRESSED not supported
>> > statx04.c:121: TFAIL: STATX_ATTR_APPEND not supported
>> > statx04.c:121: TFAIL: STATX_ATTR_IMMUTABLE not supported
>> > statx04.c:121: TFAIL: STATX_ATTR_NODUMP not supported
>
>> At first blush, that does not seem like a plausible bisect
>> result. This commit shouldn't affect the behavior of tmpfs
>> in any way.
>
> It's not testing tmpfs (well, it does but that passed), as the log above
> shows it is making a vfat filesystem on a loop device backed by a file
> that happens to be in a tmpfs and then testing that. There's a bunch of
> filesystems covered in this manner:
>
> tst_test.c:1985: TINFO: === Testing on ext2 ===
> tst_test.c:1985: TINFO: === Testing on ext3 ===
> tst_test.c:1985: TINFO: === Testing on ext4 ===
> tst_test.c:1985: TINFO: === Testing on btrfs ===
> tst_test.c:1985: TINFO: === Testing on vfat ===
> tst_test.c:1985: TINFO: === Testing on tmpfs ===
OK. Is vfat the only failure in LTP statx04 ?
--
Chuck Lever
^ permalink raw reply
* Re: [PATCH v14 03/15] fat: Implement fileattr_get for case sensitivity
From: Mark Brown @ 2026-05-20 15:19 UTC (permalink / raw)
To: Chuck Lever
Cc: Alexander Viro, Christian Brauner, Jan Kara, linux-fsdevel,
linux-ext4, linux-xfs, linux-cifs, linux-nfs, linux-api,
linux-f2fs-devel, OGAWA Hirofumi, Namjae Jeon, Sungjong Seo,
Yuezhang Mo, almaz.alexandrovich, Viacheslav Dubeyko,
John Paul Adrian Glaubitz, frank.li, Theodore Tso, adilger.kernel,
Carlos Maiolino, Steve French, Paulo Alcantara, Ronnie Sahlberg,
Shyam Prasad N, Trond Myklebust, Anna Schumaker, Jaegeuk Kim,
Chao Yu, Hans de Goede, senozhatsky, Chuck Lever, Roland Mainz
In-Reply-To: <8b750b3f-4d73-41f3-84fb-6e387fd24168@app.fastmail.com>
[-- Attachment #1: Type: text/plain, Size: 801 bytes --]
On Wed, May 20, 2026 at 11:12:51AM -0400, Chuck Lever wrote:
> On Wed, May 20, 2026, at 10:54 AM, Mark Brown wrote:
> > It's not testing tmpfs (well, it does but that passed), as the log above
> > shows it is making a vfat filesystem on a loop device backed by a file
> > that happens to be in a tmpfs and then testing that. There's a bunch of
> > filesystems covered in this manner:
> OK. Is vfat the only failure in LTP statx04 ?
Yes, it's the only one showing as failing - there are four failures
correspoding to the four tests done for vfat. It's only testing a
subset of filesystems (a combination of what the test knows about and
what's available at runtime with the kernel and rootfs.
Like I say there's a full log available at:
https://lava.sirena.org.uk/scheduler/job/2778994#L6373
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v14 03/15] fat: Implement fileattr_get for case sensitivity
From: Chuck Lever @ 2026-05-20 16:58 UTC (permalink / raw)
To: Mark Brown
Cc: Alexander Viro, Christian Brauner, Jan Kara, linux-fsdevel,
linux-ext4, linux-xfs, linux-cifs, linux-nfs, linux-api,
linux-f2fs-devel, OGAWA Hirofumi, Namjae Jeon, Sungjong Seo,
Yuezhang Mo, almaz.alexandrovich, Viacheslav Dubeyko,
John Paul Adrian Glaubitz, frank.li, Theodore Tso, adilger.kernel,
Carlos Maiolino, Steve French, Paulo Alcantara, Ronnie Sahlberg,
Shyam Prasad N, Trond Myklebust, Anna Schumaker, Jaegeuk Kim,
Chao Yu, Hans de Goede, senozhatsky, Chuck Lever, Roland Mainz
In-Reply-To: <3a347b64-f91b-450f-b27d-26ea6810b960@sirena.org.uk>
On Wed, May 20, 2026, at 11:19 AM, Mark Brown wrote:
> On Wed, May 20, 2026 at 11:12:51AM -0400, Chuck Lever wrote:
>> On Wed, May 20, 2026, at 10:54 AM, Mark Brown wrote:
>
>> > It's not testing tmpfs (well, it does but that passed), as the log above
>> > shows it is making a vfat filesystem on a loop device backed by a file
>> > that happens to be in a tmpfs and then testing that. There's a bunch of
>> > filesystems covered in this manner:
>
>> OK. Is vfat the only failure in LTP statx04 ?
>
> Yes, it's the only one showing as failing - there are four failures
> correspoding to the four tests done for vfat.
03/15 adds .fileattr_get = fat_fileattr_get for both
fat_file_inode_operations and vfat_dir_inode_operations. LTP
opens a directory (SAFE_OPEN(TESTDIR, O_RDONLY|O_DIRECTORY)),
so FS_IOC_GETFLAGS on the dir now succeeds, and statx04
proceeds where it was previously skipped.
AFAICS, 03/15 did not change pre-existing kernel behavior of
stx_attributes_mask on vfat. It merely converted a "skipped"
LTP outcome into an "executed but failed" outcome.
Fix options:
* fat_getattr() could call generic_fill_statx_attr(inode, stat),
which advertises KSTAT_ATTR_VFS_FLAGS (IMMUTABLE + APPEND).
That clears 2 of 4 TFAILs but not COMPRESSED/NODUMP, which
FAT genuinely does not back.
* Set stat->attributes_mask |= KSTAT_ATTR_FS_IOC_FLAGS in
fat_getattr(). Honest only to the extent that FAT now exposes
some FS_*_FL bits via fileattr. This would silence the test
failures, but advertises capabilities (COMPRESSED, NODUMP)
FAT doesn't track.
* Admit the LTP statx04 test needs to be updated.
FS_IOC_GETFLAGS succeeding does not logically imply all four
FS_IOC_FLAGS-mapped STATX_ATTR_* bits are supported. The
test's gate is too coarse for filesystems that gained a
narrowly-scoped fileattr_get (just casefold/immutable). The
test's tag list pins it to filesystems that do support the
full set, but vfat was tacitly excluded by the prior ENOTTY.
The first option is the narrowest kernel-side change, and
matches what other minimal-fileattr filesystems do.
--
Chuck Lever
^ permalink raw reply
* Re: [PATCH v14 03/15] fat: Implement fileattr_get for case sensitivity
From: Mark Brown @ 2026-05-20 17:11 UTC (permalink / raw)
To: Chuck Lever
Cc: Alexander Viro, Christian Brauner, Jan Kara, linux-fsdevel,
linux-ext4, linux-xfs, linux-cifs, linux-nfs, linux-api,
linux-f2fs-devel, OGAWA Hirofumi, Namjae Jeon, Sungjong Seo,
Yuezhang Mo, almaz.alexandrovich, Viacheslav Dubeyko,
John Paul Adrian Glaubitz, frank.li, Theodore Tso, adilger.kernel,
Carlos Maiolino, Steve French, Paulo Alcantara, Ronnie Sahlberg,
Shyam Prasad N, Trond Myklebust, Anna Schumaker, Jaegeuk Kim,
Chao Yu, Hans de Goede, senozhatsky, Chuck Lever, Roland Mainz
In-Reply-To: <858d7233-1d9c-48f4-aa4f-c5a9f6e1f5dc@app.fastmail.com>
[-- Attachment #1: Type: text/plain, Size: 1953 bytes --]
On Wed, May 20, 2026 at 12:58:22PM -0400, Chuck Lever wrote:
> On Wed, May 20, 2026, at 11:19 AM, Mark Brown wrote:
> > Yes, it's the only one showing as failing - there are four failures
> > correspoding to the four tests done for vfat.
> 03/15 adds .fileattr_get = fat_fileattr_get for both
> fat_file_inode_operations and vfat_dir_inode_operations. LTP
> opens a directory (SAFE_OPEN(TESTDIR, O_RDONLY|O_DIRECTORY)),
> so FS_IOC_GETFLAGS on the dir now succeeds, and statx04
> proceeds where it was previously skipped.
> AFAICS, 03/15 did not change pre-existing kernel behavior of
> stx_attributes_mask on vfat. It merely converted a "skipped"
> LTP outcome into an "executed but failed" outcome.
Ah, that's an interesting issue with the way the test reports. LTP
could use nested reports a la TAP here so we're not just seeing the top
level failure from the test case in automation.
> Fix options:
> * fat_getattr() could call generic_fill_statx_attr(inode, stat),
> which advertises KSTAT_ATTR_VFS_FLAGS (IMMUTABLE + APPEND).
> That clears 2 of 4 TFAILs but not COMPRESSED/NODUMP, which
> FAT genuinely does not back.
...
> * Admit the LTP statx04 test needs to be updated.
> FS_IOC_GETFLAGS succeeding does not logically imply all four
> FS_IOC_FLAGS-mapped STATX_ATTR_* bits are supported. The
> test's gate is too coarse for filesystems that gained a
> narrowly-scoped fileattr_get (just casefold/immutable). The
> test's tag list pins it to filesystems that do support the
> full set, but vfat was tacitly excluded by the prior ENOTTY.
I think this is needed, it's hardly the first LTP test to make
unwarranted assumptions about the kernel APIs. I'll try to look into
it.
> The first option is the narrowest kernel-side change, and
> matches what other minimal-fileattr filesystems do.
That sounds like a good idea regardless of what we do with the test?
Thanks for looking into this so quickly and thoroughly.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v14 03/15] fat: Implement fileattr_get for case sensitivity
From: Chuck Lever @ 2026-05-20 17:30 UTC (permalink / raw)
To: Mark Brown
Cc: Alexander Viro, Christian Brauner, Jan Kara, linux-fsdevel,
linux-ext4, linux-xfs, linux-cifs, linux-nfs, linux-api,
linux-f2fs-devel, OGAWA Hirofumi, Namjae Jeon, Sungjong Seo,
Yuezhang Mo, almaz.alexandrovich, Viacheslav Dubeyko,
John Paul Adrian Glaubitz, frank.li, Theodore Tso, adilger.kernel,
Carlos Maiolino, Steve French, Paulo Alcantara, Ronnie Sahlberg,
Shyam Prasad N, Trond Myklebust, Anna Schumaker, Jaegeuk Kim,
Chao Yu, Hans de Goede, senozhatsky, Chuck Lever, Roland Mainz
In-Reply-To: <cdeaab82-06bf-47c1-8f6c-4e40dbec2344@sirena.org.uk>
On Wed, May 20, 2026, at 1:11 PM, Mark Brown wrote:
> On Wed, May 20, 2026 at 12:58:22PM -0400, Chuck Lever wrote:
>> The first option is the narrowest kernel-side change, and
>> matches what other minimal-fileattr filesystems do.
>
> That sounds like a good idea regardless of what we do with the test?
Yes, I have no objection to this approach, but it would be great to
hear from the vfat maintainers/contributors on this one before I
dig in.
--
Chuck Lever
^ permalink raw reply
* Re: [PATCH v2] f2fs: another way to set large folio by remembering inode number
From: Christoph Hellwig @ 2026-05-21 8:51 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Jaegeuk Kim, Christoph Hellwig, linux-kernel, linux-f2fs-devel,
Akilesh Kailash, linux-fsdevel, linux-mm, linux-api,
Christian Brauner
In-Reply-To: <ad_HwhzlNPUEKQi6@casper.infradead.org>
On Wed, Apr 15, 2026 at 06:15:46PM +0100, Matthew Wilcox wrote:
> On Wed, Apr 15, 2026 at 04:44:04PM +0000, Jaegeuk Kim wrote:
> > On 04/14, Christoph Hellwig wrote:
> > > Please add the relevant mailing lists when adding new user interfaces.
> > >
> > > And I'm not sure hacks working around the proper large folio
> > > implementation are something that should be merged upstream.
> >
> > Cc'ed linux-api and linux-fsdevel onto the patch thread with a proposal that
> > I'm not sure it's acceptable or not.
>
> You haven't sent a proposal. This is a reply to a reply to a reply of a
> patch. There's no justification for why f2fs is so special that it
> needs this. What the hell is going on? You know this is not the way to
> get code merged into Linux.
None of this got properly answers, and this broken interface now landed
in linux-next. IT is offloading a user.* xattr which is free-form
user data with semantics that are weird to say it very nicely.
All this was done against the advice in the mailing list discussion.
I think at some point we just need to stop taking f2fs updates likes
this.
^ permalink raw reply
* Re: [PATCH v6 0/4] OPENAT2_REGULAR flag support for openat2
From: Christian Brauner @ 2026-05-21 10:53 UTC (permalink / raw)
To: linux-fsdevel, Dorjoy Chowdhury
Cc: linux-kernel, linux-api, ceph-devel, gfs2, linux-nfs, linux-cifs,
v9fs, linux-kselftest, viro, jack, jlayton, chuck.lever,
alex.aring, arnd, adilger, mjguzik, smfrench, richard.henderson,
mattst88, linmag7, tsbogend, James.Bottomley, deller, davem,
andreas, idryomov, amarkuze, slava, agruenba, trondmy, anna,
sfrench, pc, ronniesahlberg, sprasad, tom, bharathsm, shuah,
miklos, hansg
In-Reply-To: <20260416-abgraben-seeweg-a44ce660957f@brauner>
On Thu, Apr 16, 2026 at 03:07:12PM +0200, Christian Brauner wrote:
> On Sat, 28 Mar 2026 23:22:21 +0600, Dorjoy Chowdhury wrote:
> > I came upon this "Ability to only open regular files" uapi feature suggestion
> > from https://uapi-group.org/kernel-features/#ability-to-only-open-regular-files
> > and thought it would be something I could do as a first patch and get to
> > know the kernel code a bit better.
> >
> > The following filesystems have been tested by building and booting the kernel
> > x86 bzImage in a Fedora 43 VM in QEMU. I have tested with OPENAT2_REGULAR that
> > regular files can be successfully opened and non-regular files (directory, fifo etc)
> > return -EFTYPE.
> > - btrfs
> > - NFS (loopback)
> > - SMB (loopback)
> >
> > [...]
>
> - I've added an explanation why OPENAT2_REGULAR is only needed for some
> ->atomic_open() implementers but not others. What I don't like is that
> we need all that custom handling in there but it's managable.
>
> - I dropped the topmost style conversions. They really don't belong
> there and if we switch to something better we should use (1 << <nr>).
>
> - I split the EFTYPE errno introduction into a separate patch.
So I've massaged this series a bit in that I moved OPENAT2_REGULAR into
the upper 64-bit and internally use a __O_REGULAR bit. After having
thought about it makes a lot more sense to move the openat2() only
features into the upper 32-bit for the uapi space. I also ported the
selftests to the TEST* framework to fit with Aleksa's recent rework.
^ permalink raw reply
* Re: [PATCH v6 0/4] OPENAT2_REGULAR flag support for openat2
From: Dorjoy Chowdhury @ 2026-05-21 15:49 UTC (permalink / raw)
To: Christian Brauner
Cc: linux-fsdevel, linux-kernel, linux-api, ceph-devel, gfs2,
linux-nfs, linux-cifs, v9fs, linux-kselftest, viro, jack, jlayton,
chuck.lever, alex.aring, arnd, adilger, mjguzik, smfrench,
richard.henderson, mattst88, linmag7, tsbogend, James.Bottomley,
deller, davem, andreas, idryomov, amarkuze, slava, agruenba,
trondmy, anna, sfrench, pc, ronniesahlberg, sprasad, tom,
bharathsm, shuah, miklos, hansg
In-Reply-To: <20260521-grube-leitfaden-0e5420c9bedc@brauner>
On Thu, May 21, 2026 at 4:54 PM Christian Brauner <brauner@kernel.org> wrote:
>
> On Thu, Apr 16, 2026 at 03:07:12PM +0200, Christian Brauner wrote:
> > On Sat, 28 Mar 2026 23:22:21 +0600, Dorjoy Chowdhury wrote:
> > > I came upon this "Ability to only open regular files" uapi feature suggestion
> > > from https://uapi-group.org/kernel-features/#ability-to-only-open-regular-files
> > > and thought it would be something I could do as a first patch and get to
> > > know the kernel code a bit better.
> > >
> > > The following filesystems have been tested by building and booting the kernel
> > > x86 bzImage in a Fedora 43 VM in QEMU. I have tested with OPENAT2_REGULAR that
> > > regular files can be successfully opened and non-regular files (directory, fifo etc)
> > > return -EFTYPE.
> > > - btrfs
> > > - NFS (loopback)
> > > - SMB (loopback)
> > >
> > > [...]
> >
> > - I've added an explanation why OPENAT2_REGULAR is only needed for some
> > ->atomic_open() implementers but not others. What I don't like is that
> > we need all that custom handling in there but it's managable.
> >
> > - I dropped the topmost style conversions. They really don't belong
> > there and if we switch to something better we should use (1 << <nr>).
> >
> > - I split the EFTYPE errno introduction into a separate patch.
>
> So I've massaged this series a bit in that I moved OPENAT2_REGULAR into
> the upper 64-bit and internally use a __O_REGULAR bit. After having
> thought about it makes a lot more sense to move the openat2() only
> features into the upper 32-bit for the uapi space. I also ported the
> selftests to the TEST* framework to fit with Aleksa's recent rework.
Thanks for fixing up!
Regards,
Dorjoy
^ permalink raw reply
* Re: [PATCH v2] f2fs: another way to set large folio by remembering inode number
From: Theodore Tso @ 2026-05-21 15:57 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Matthew Wilcox, Jaegeuk Kim, linux-kernel, linux-f2fs-devel,
Akilesh Kailash, linux-fsdevel, linux-mm, linux-api,
Christian Brauner
In-Reply-To: <ag7HfNryTmQ-bVIS@infradead.org>
On Thu, May 21, 2026 at 01:51:08AM -0700, Christoph Hellwig wrote:
> > You haven't sent a proposal. This is a reply to a reply to a reply of a
> > patch. There's no justification for why f2fs is so special that it
> > needs this. What the hell is going on? You know this is not the way to
> > get code merged into Linux.
>
> None of this got properly answers, and this broken interface now landed
> in linux-next. IT is offloading a user.* xattr which is free-form
> user data with semantics that are weird to say it very nicely.
>
> All this was done against the advice in the mailing list discussion.
So let me get this straight. This is a magic xattr interface which is
not even persisted in the file system, but instead sets a 32-bit
bitmask in the struct inode which disappears once the inode gets
flushed from the inode stack. And it uses a generic xattr name,
"user.fadvise".
There's no way in *hell* any other file system is likely to adopt such
a broken interface, so why didn't you just use an ioctl to set this
magic f2fs-specific flag?
> I think at some point we just need to stop taking f2fs updates likes
> this.
Well, that's ultiamtely up to Linus. I'll say that if I were Linus
(and I'm glad I'm not :-), and I saw this in a pull request, I'd
reject it out of hand. But whether it's worth making a huge fuss and
asking escalating this mess to Linus, we probably should get a bit
more community consensus before taking such a drastic step.
Christian, since you're one of the VFS maintaienrs, what's your
opinion about escalating this to Linus?
- Ted
^ permalink raw reply
* Re: [PATCH v2] f2fs: another way to set large folio by remembering inode number
From: Matthew Wilcox @ 2026-05-21 17:42 UTC (permalink / raw)
To: Theodore Tso
Cc: Christoph Hellwig, Jaegeuk Kim, linux-kernel, linux-f2fs-devel,
Akilesh Kailash, linux-fsdevel, linux-mm, linux-api,
Christian Brauner
In-Reply-To: <20260521155748.GA79343@macsyma-wired.lan>
On Thu, May 21, 2026 at 11:57:48AM -0400, Theodore Tso wrote:
> So let me get this straight. This is a magic xattr interface which is
> not even persisted in the file system, but instead sets a 32-bit
> bitmask in the struct inode which disappears once the inode gets
> flushed from the inode stack. And it uses a generic xattr name,
> "user.fadvise".
>
> There's no way in *hell* any other file system is likely to adopt such
> a broken interface, so why didn't you just use an ioctl to set this
> magic f2fs-specific flag?
I mean, yes, this API is horrendous. But it's just another example of
f2fs thinking it's somehow special and not just enabling large folios
like other filesystems do. This hurts everyone, not just people who use
f2fs.
^ permalink raw reply
* Re: [f2fs-dev] [PATCH v2] f2fs: another way to set large folio by remembering inode number
From: Jaegeuk Kim @ 2026-05-22 3:32 UTC (permalink / raw)
To: Theodore Tso
Cc: Christoph Hellwig, linux-api, linux-kernel, Matthew Wilcox,
linux-f2fs-devel, linux-mm, linux-fsdevel, Akilesh Kailash,
Christian Brauner
In-Reply-To: <20260521155748.GA79343@macsyma-wired.lan>
On 05/21, Theodore Tso wrote:
> On Thu, May 21, 2026 at 01:51:08AM -0700, Christoph Hellwig wrote:
> > > You haven't sent a proposal. This is a reply to a reply to a reply of a
> > > patch. There's no justification for why f2fs is so special that it
> > > needs this. What the hell is going on? You know this is not the way to
> > > get code merged into Linux.
> >
> > None of this got properly answers, and this broken interface now landed
> > in linux-next. IT is offloading a user.* xattr which is free-form
> > user data with semantics that are weird to say it very nicely.
> >
> > All this was done against the advice in the mailing list discussion.
>
> So let me get this straight. This is a magic xattr interface which is
> not even persisted in the file system, but instead sets a 32-bit
> bitmask in the struct inode which disappears once the inode gets
> flushed from the inode stack. And it uses a generic xattr name,
> "user.fadvise".
>
> There's no way in *hell* any other file system is likely to adopt such
> a broken interface, so why didn't you just use an ioctl to set this
> magic f2fs-specific flag?
I went this route because Android heavily restricts ioctl() permissions
and we needed broader access for this to work within the framework. It’s
definitely a pragmatic choice just to get it running in production.
If ioctl() is a right way for upstream, I'm happy to change this patch. By
the way, I really don't understand why all the messages are so offensive,
even without trying to understand the problem or guiding right directions.
>
> > I think at some point we just need to stop taking f2fs updates likes
> > this.
>
> Well, that's ultiamtely up to Linus. I'll say that if I were Linus
> (and I'm glad I'm not :-), and I saw this in a pull request, I'd
> reject it out of hand. But whether it's worth making a huge fuss and
> asking escalating this mess to Linus, we probably should get a bit
> more community consensus before taking such a drastic step.
Could I also raise a quick concern regarding the phrasing/wording used
in the communications?
>
> Christian, since you're one of the VFS maintaienrs, what's your
> opinion about escalating this to Linus?
>
> - Ted
>
>
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply
* Re: [f2fs-dev] [PATCH v2] f2fs: another way to set large folio by remembering inode number
From: Eric Biggers @ 2026-05-22 3:53 UTC (permalink / raw)
To: Jaegeuk Kim
Cc: Theodore Tso, Christoph Hellwig, linux-api, linux-kernel,
Matthew Wilcox, linux-f2fs-devel, linux-mm, linux-fsdevel,
Akilesh Kailash, Christian Brauner
In-Reply-To: <ag_OVwPF49LSZ7rz@google.com>
On Fri, May 22, 2026 at 03:32:39AM +0000, Jaegeuk Kim wrote:
> On 05/21, Theodore Tso wrote:
> > On Thu, May 21, 2026 at 01:51:08AM -0700, Christoph Hellwig wrote:
> > > > You haven't sent a proposal. This is a reply to a reply to a reply of a
> > > > patch. There's no justification for why f2fs is so special that it
> > > > needs this. What the hell is going on? You know this is not the way to
> > > > get code merged into Linux.
> > >
> > > None of this got properly answers, and this broken interface now landed
> > > in linux-next. IT is offloading a user.* xattr which is free-form
> > > user data with semantics that are weird to say it very nicely.
> > >
> > > All this was done against the advice in the mailing list discussion.
> >
> > So let me get this straight. This is a magic xattr interface which is
> > not even persisted in the file system, but instead sets a 32-bit
> > bitmask in the struct inode which disappears once the inode gets
> > flushed from the inode stack. And it uses a generic xattr name,
> > "user.fadvise".
> >
> > There's no way in *hell* any other file system is likely to adopt such
> > a broken interface, so why didn't you just use an ioctl to set this
> > magic f2fs-specific flag?
>
> I went this route because Android heavily restricts ioctl() permissions
> and we needed broader access for this to work within the framework.
It's straightforward (2 lines I think) to update Android's SELinux
policy to allow an ioctl in all domains. So that doesn't seem like a
reason to not use an ioctl. In fact this is actually a reason *to* use
an ioctl, as it shows that ioctls can be allowed/denied independently as
needed, whereas xattrs just use the file write permission.
- Eric
^ permalink raw reply
* Re: [PATCH v2] f2fs: another way to set large folio by remembering inode number
From: Jaegeuk Kim @ 2026-05-22 3:59 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Theodore Tso, Christoph Hellwig, linux-kernel, linux-f2fs-devel,
Akilesh Kailash, linux-fsdevel, linux-mm, linux-api,
Christian Brauner
In-Reply-To: <ag9D6_7dttbDGHZ6@casper.infradead.org>
On 05/21, Matthew Wilcox wrote:
> On Thu, May 21, 2026 at 11:57:48AM -0400, Theodore Tso wrote:
> > So let me get this straight. This is a magic xattr interface which is
> > not even persisted in the file system, but instead sets a 32-bit
> > bitmask in the struct inode which disappears once the inode gets
> > flushed from the inode stack. And it uses a generic xattr name,
> > "user.fadvise".
> >
> > There's no way in *hell* any other file system is likely to adopt such
> > a broken interface, so why didn't you just use an ioctl to set this
> > magic f2fs-specific flag?
>
> I mean, yes, this API is horrendous. But it's just another example of
> f2fs thinking it's somehow special and not just enabling large folios
> like other filesystems do. This hurts everyone, not just people who use
> f2fs.
From the production viewpoint, I raised a concern on setting large folio by
default, since that exhausts lots of high-order pages, which were needed for
essential system services and critical apps.
^ permalink raw reply
* Re: [f2fs-dev] [PATCH v2] f2fs: another way to set large folio by remembering inode number
From: Jaegeuk Kim @ 2026-05-22 4:02 UTC (permalink / raw)
To: Eric Biggers
Cc: Theodore Tso, linux-api, linux-kernel, Matthew Wilcox,
linux-f2fs-devel, Christoph Hellwig, linux-mm, linux-fsdevel,
Akilesh Kailash, Christian Brauner
In-Reply-To: <20260522035331.GE5937@quark>
On 05/21, Eric Biggers via Linux-f2fs-devel wrote:
> On Fri, May 22, 2026 at 03:32:39AM +0000, Jaegeuk Kim wrote:
> > On 05/21, Theodore Tso wrote:
> > > On Thu, May 21, 2026 at 01:51:08AM -0700, Christoph Hellwig wrote:
> > > > > You haven't sent a proposal. This is a reply to a reply to a reply of a
> > > > > patch. There's no justification for why f2fs is so special that it
> > > > > needs this. What the hell is going on? You know this is not the way to
> > > > > get code merged into Linux.
> > > >
> > > > None of this got properly answers, and this broken interface now landed
> > > > in linux-next. IT is offloading a user.* xattr which is free-form
> > > > user data with semantics that are weird to say it very nicely.
> > > >
> > > > All this was done against the advice in the mailing list discussion.
> > >
> > > So let me get this straight. This is a magic xattr interface which is
> > > not even persisted in the file system, but instead sets a 32-bit
> > > bitmask in the struct inode which disappears once the inode gets
> > > flushed from the inode stack. And it uses a generic xattr name,
> > > "user.fadvise".
> > >
> > > There's no way in *hell* any other file system is likely to adopt such
> > > a broken interface, so why didn't you just use an ioctl to set this
> > > magic f2fs-specific flag?
> >
> > I went this route because Android heavily restricts ioctl() permissions
> > and we needed broader access for this to work within the framework.
>
> It's straightforward (2 lines I think) to update Android's SELinux
> policy to allow an ioctl in all domains. So that doesn't seem like a
> reason to not use an ioctl. In fact this is actually a reason *to* use
> an ioctl, as it shows that ioctls can be allowed/denied independently as
> needed, whereas xattrs just use the file write permission.
Ok, that's also great news to me.
>
> - Eric
>
>
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply
* Re: [PATCH v2] f2fs: another way to set large folio by remembering inode number
From: Christian Brauner @ 2026-05-22 9:59 UTC (permalink / raw)
To: Theodore Tso
Cc: Christoph Hellwig, Matthew Wilcox, Jaegeuk Kim, linux-kernel,
linux-f2fs-devel, Akilesh Kailash, linux-fsdevel, linux-mm,
linux-api, Christian Brauner
In-Reply-To: <20260521155748.GA79343@macsyma-wired.lan>
On 2026-05-21 11:57 -0400, Theodore Tso wrote:
> On Thu, May 21, 2026 at 01:51:08AM -0700, Christoph Hellwig wrote:
> > > You haven't sent a proposal. This is a reply to a reply to a reply of a
> > > patch. There's no justification for why f2fs is so special that it
> > > needs this. What the hell is going on? You know this is not the way to
> > > get code merged into Linux.
> >
> > None of this got properly answers, and this broken interface now landed
> > in linux-next. IT is offloading a user.* xattr which is free-form
> > user data with semantics that are weird to say it very nicely.
> >
> > All this was done against the advice in the mailing list discussion.
>
> So let me get this straight. This is a magic xattr interface which is
> not even persisted in the file system, but instead sets a 32-bit
> bitmask in the struct inode which disappears once the inode gets
> flushed from the inode stack. And it uses a generic xattr name,
> "user.fadvise".
>
> There's no way in *hell* any other file system is likely to adopt such
> a broken interface, so why didn't you just use an ioctl to set this
> magic f2fs-specific flag?
>
> > I think at some point we just need to stop taking f2fs updates likes
> > this.
>
> Well, that's ultiamtely up to Linus. I'll say that if I were Linus
> (and I'm glad I'm not :-), and I saw this in a pull request, I'd
> reject it out of hand. But whether it's worth making a huge fuss and
> asking escalating this mess to Linus, we probably should get a bit
> more community consensus before taking such a drastic step.
>
> Christian, since you're one of the VFS maintaienrs, what's your
> opinion about escalating this to Linus?
I think we don't need to involve Linus.
The interface as is is broken. Using xattrs for this makes no sense
whatsoever.
^ permalink raw reply
* Re: [f2fs-dev] [PATCH v2] f2fs: another way to set large folio by remembering inode number
From: Christian Brauner @ 2026-05-22 10:01 UTC (permalink / raw)
To: Eric Biggers
Cc: Jaegeuk Kim, Theodore Tso, Christoph Hellwig, linux-api,
linux-kernel, Matthew Wilcox, linux-f2fs-devel, linux-mm,
linux-fsdevel, Akilesh Kailash, Christian Brauner
In-Reply-To: <20260522035331.GE5937@quark>
On 2026-05-21 22:53 -0500, Eric Biggers wrote:
> On Fri, May 22, 2026 at 03:32:39AM +0000, Jaegeuk Kim wrote:
> > On 05/21, Theodore Tso wrote:
> > > On Thu, May 21, 2026 at 01:51:08AM -0700, Christoph Hellwig wrote:
> > > > > You haven't sent a proposal. This is a reply to a reply to a reply of a
> > > > > patch. There's no justification for why f2fs is so special that it
> > > > > needs this. What the hell is going on? You know this is not the way to
> > > > > get code merged into Linux.
> > > >
> > > > None of this got properly answers, and this broken interface now landed
> > > > in linux-next. IT is offloading a user.* xattr which is free-form
> > > > user data with semantics that are weird to say it very nicely.
> > > >
> > > > All this was done against the advice in the mailing list discussion.
> > >
> > > So let me get this straight. This is a magic xattr interface which is
> > > not even persisted in the file system, but instead sets a 32-bit
> > > bitmask in the struct inode which disappears once the inode gets
> > > flushed from the inode stack. And it uses a generic xattr name,
> > > "user.fadvise".
> > >
> > > There's no way in *hell* any other file system is likely to adopt such
> > > a broken interface, so why didn't you just use an ioctl to set this
> > > magic f2fs-specific flag?
> >
> > I went this route because Android heavily restricts ioctl() permissions
> > and we needed broader access for this to work within the framework.
>
> It's straightforward (2 lines I think) to update Android's SELinux
> policy to allow an ioctl in all domains. So that doesn't seem like a
> reason to not use an ioctl. In fact this is actually a reason *to* use
> an ioctl, as it shows that ioctls can be allowed/denied independently as
> needed, whereas xattrs just use the file write permission.
Thank you, I very much agree.
^ permalink raw reply
* Re: [PATCH v2] f2fs: another way to set large folio by remembering inode number
From: Matthew Wilcox @ 2026-05-22 12:55 UTC (permalink / raw)
To: Jaegeuk Kim
Cc: Theodore Tso, Christoph Hellwig, linux-kernel, linux-f2fs-devel,
Akilesh Kailash, linux-fsdevel, linux-mm, linux-api,
Christian Brauner
In-Reply-To: <ag_UsW_OrlXD9dWX@google.com>
On Fri, May 22, 2026 at 03:59:45AM +0000, Jaegeuk Kim wrote:
> On 05/21, Matthew Wilcox wrote:
> > On Thu, May 21, 2026 at 11:57:48AM -0400, Theodore Tso wrote:
> > > So let me get this straight. This is a magic xattr interface which is
> > > not even persisted in the file system, but instead sets a 32-bit
> > > bitmask in the struct inode which disappears once the inode gets
> > > flushed from the inode stack. And it uses a generic xattr name,
> > > "user.fadvise".
> > >
> > > There's no way in *hell* any other file system is likely to adopt such
> > > a broken interface, so why didn't you just use an ioctl to set this
> > > magic f2fs-specific flag?
> >
> > I mean, yes, this API is horrendous. But it's just another example of
> > f2fs thinking it's somehow special and not just enabling large folios
> > like other filesystems do. This hurts everyone, not just people who use
> > f2fs.
>
> >From the production viewpoint, I raised a concern on setting large folio by
> default, since that exhausts lots of high-order pages, which were needed for
> essential system services and critical apps.
Random fears or actual data?
^ permalink raw reply
* Re: [f2fs-dev] [PATCH v2] f2fs: another way to set large folio by remembering inode number
From: Jaegeuk Kim @ 2026-05-22 14:04 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Theodore Tso, linux-api, linux-kernel, linux-f2fs-devel,
Christoph Hellwig, linux-mm, linux-fsdevel, Akilesh Kailash,
Christian Brauner
In-Reply-To: <ahBSXyOi9b1jxNkX@casper.infradead.org>
On 05/22, Matthew Wilcox wrote:
> On Fri, May 22, 2026 at 03:59:45AM +0000, Jaegeuk Kim wrote:
> > On 05/21, Matthew Wilcox wrote:
> > > On Thu, May 21, 2026 at 11:57:48AM -0400, Theodore Tso wrote:
> > > > So let me get this straight. This is a magic xattr interface which is
> > > > not even persisted in the file system, but instead sets a 32-bit
> > > > bitmask in the struct inode which disappears once the inode gets
> > > > flushed from the inode stack. And it uses a generic xattr name,
> > > > "user.fadvise".
> > > >
> > > > There's no way in *hell* any other file system is likely to adopt such
> > > > a broken interface, so why didn't you just use an ioctl to set this
> > > > magic f2fs-specific flag?
> > >
> > > I mean, yes, this API is horrendous. But it's just another example of
> > > f2fs thinking it's somehow special and not just enabling large folios
> > > like other filesystems do. This hurts everyone, not just people who use
> > > f2fs.
> >
> > >From the production viewpoint, I raised a concern on setting large folio by
> > default, since that exhausts lots of high-order pages, which were needed for
> > essential system services and critical apps.
>
> Random fears or actual data?
This was a quick buddyinfo right after booting the device.
Before:
Node 0, zone Normal 22684 42284 28704 16901 9515 4566 1854 673 181 36 758
After disabling EROFS large folio:
Node 0, zone Normal 8486 4732 2175 1161 697 272 82 19 3 1 856
>
>
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply
* Re: [f2fs-dev] [PATCH v2] f2fs: another way to set large folio by remembering inode number
From: Theodore Tso @ 2026-05-22 14:11 UTC (permalink / raw)
To: Jaegeuk Kim
Cc: Christoph Hellwig, linux-api, linux-kernel, Matthew Wilcox,
linux-f2fs-devel, linux-mm, linux-fsdevel, Akilesh Kailash,
Christian Brauner
In-Reply-To: <ag_OVwPF49LSZ7rz@google.com>
On Fri, May 22, 2026 at 03:32:39AM +0000, Jaegeuk Kim wrote:
> I went this route because Android heavily restricts ioctl() permissions
> and we needed broader access for this to work within the framework. It’s
> definitely a pragmatic choice just to get it running in production.
>
> If ioctl() is a right way for upstream, I'm happy to change this patch. By
> the way, I really don't understand why all the messages are so offensive,
> even without trying to understand the problem or guiding right directions.
The reason why some people were getting annoyed was because as a Linux
file system maintainer, there was an assumption that you would
understand that extended attributes --- especially in the user.*
namespace --- have an intended use case of storing a user-chosen small
piece of metadata that would be stored in the file system.
Hijacking user.fadvise such that it no longer persistent stores an
extended attribute for one specific file system --- such that if a
hypothetical user application might decide to store a piece of
application data in the extended attribute named "fadvise" would do
something completely different on a single mainline file system is in
such poor taste that I would have *hoped* that any Linux file system
maintainer would know that this a Really Bad Thing, such that if
someone in your development community suggested such an idea, you
would reject it.
And then, when people complained that it was a bad idea, and you
decided to put in the f2fs branch, such that it would show up in
linux-next, and there was no way for other file system developers to
object (short of appealing to Linus) --- well, that's basically you
taking advantage of your file system maintainer privileges. And this
is why I started proposing whether we needed to appeal this to Linus
so he could make the call to reject something that the community had
already told you was in terrible, terrible taste.
As far as trying to understand why you were doing this --- I have to
turn that question around. Why didn't *you* explain why you needed to
do this thing? I went through the e-mail history, and I couldn't find
an explanation of why you decided to do this thing.
Perhaps we need to add an explanation the Documentation directory
explaining what the intended use of the extended attribute case, and
perhaps referencing past cases were people tried to use this to bypass
the linux-api review process (f2fs's user.fadvise is not the first
time someone has tried to do this) thing), so that automated review
bots like Sashiko can explain why it's in such terrible taste to patch
authors, perhaps we need to do this. Up until now, I think the
assumption is that file system maintainers would know something this
self-evident, and if not, if it was pointed out, they wouldn't try to
force such an ill-advised interface to Linus.
- Ted
P.S. As an exmaple of how I hanlded a somewhat similar scenario in
the past, my employer's cluster file system needed
FALLOC_FL_NO_HIDE_STALE to save $$$$ in TCO storage costs. But the
concern was this would be an attractive nuisance for enterprise distro
users, who would see the massive performance increase, not realize
that this would leak stale data, which could result in user PII being
exposed, thus making life hard for Enterprise Linux's reputation.
(This wasn't an issue at $WORK because we enrypt all data at rest, and
the cluster file system daemon was a privileged server who (a) knew
what it was doing, and (b) only it would have access to set
FALLOC_FL_NO_HIDE_STALE.)
I disclosed *why* $WORK needed such a thing (it made a huge difference
to storage TCO costss for Google's Cluster Filesystem), and after
discussion and negotiation, we came to a compromise which involved my
keeping the (very small) patch out of tree, but reserving the code
point upstream to avoid future bitfield collisions. They key here was
that I *knew* it was controversial, and I understood what problems it
might cause in the rest of the ecosystem. That's part of the job of a
maintainer, and it's also why a company might want to hire a
maintainer. They can represent the needs of multiple stakeholders ---
the upstream community, upstream users and the greater Linux
ecosystem, as well as their employer.
^ permalink raw reply
* Re: [f2fs-dev] [PATCH v2] f2fs: another way to set large folio by remembering inode number
From: Jaegeuk Kim @ 2026-05-22 17:08 UTC (permalink / raw)
To: Theodore Tso
Cc: linux-api, linux-kernel, Matthew Wilcox, linux-f2fs-devel,
Christoph Hellwig, linux-mm, linux-fsdevel, Akilesh Kailash,
Christian Brauner
In-Reply-To: <20260522141115.GA8258@macsyma-wired.lan>
On 05/22, Theodore Tso wrote:
> On Fri, May 22, 2026 at 03:32:39AM +0000, Jaegeuk Kim wrote:
> > I went this route because Android heavily restricts ioctl() permissions
> > and we needed broader access for this to work within the framework. It’s
> > definitely a pragmatic choice just to get it running in production.
> >
> > If ioctl() is a right way for upstream, I'm happy to change this patch. By
> > the way, I really don't understand why all the messages are so offensive,
> > even without trying to understand the problem or guiding right directions.
>
> The reason why some people were getting annoyed was because as a Linux
> file system maintainer, there was an assumption that you would
> understand that extended attributes --- especially in the user.*
> namespace --- have an intended use case of storing a user-chosen small
> piece of metadata that would be stored in the file system.
>
> Hijacking user.fadvise such that it no longer persistent stores an
> extended attribute for one specific file system --- such that if a
> hypothetical user application might decide to store a piece of
> application data in the extended attribute named "fadvise" would do
> something completely different on a single mainline file system is in
> such poor taste that I would have *hoped* that any Linux file system
> maintainer would know that this a Really Bad Thing, such that if
> someone in your development community suggested such an idea, you
> would reject it.
Thank you for the explanation. It seems I made a wrong assumption on the
usage of "user." prefix where each filesystem can support in different
ways.
>
> And then, when people complained that it was a bad idea, and you
> decided to put in the f2fs branch, such that it would show up in
> linux-next, and there was no way for other file system developers to
> object (short of appealing to Linus) --- well, that's basically you
> taking advantage of your file system maintainer privileges. And this
> is why I started proposing whether we needed to appeal this to Linus
> so he could make the call to reject something that the community had
> already told you was in terrible, terrible taste.
To be fair, I hadn't queued it in linux-next for weeks since the first
post, and was waiting for more feedbacks. If I was able to hear "user."
is a generic prefix used for all filesystems and use ioctl from the beginning,
I'd just drop and be able to start arguing with security folks back. Since
my employer is funding for production mainly, not much upstream work, I
couldn't sit and wait for the response for months. :(
>
> As far as trying to understand why you were doing this --- I have to
> turn that question around. Why didn't *you* explain why you needed to
> do this thing? I went through the e-mail history, and I couldn't find
> an explanation of why you decided to do this thing.
I shared some motivation when replying to Darrick's feedback [1], but yes,
it was not enough for all heads-up. The problem started that some speicific
application needs as many high-order pages as possible mostly for reads. So,
I thought we can turn on large folio on the specific files per hints. One way
for the hints was using immutable bit, but it turned out it's very hard to
manage disabling the bit whenever deleting the files. Along with limited
ioctl() and requiring inode eviction to manage large folio activation, I had
to implement this path.
[1] https://lore.kernel.org/lkml/aeA5C8byIpXWla7f@google.com/
>
> Perhaps we need to add an explanation the Documentation directory
> explaining what the intended use of the extended attribute case, and
> perhaps referencing past cases were people tried to use this to bypass
> the linux-api review process (f2fs's user.fadvise is not the first
> time someone has tried to do this) thing), so that automated review
> bots like Sashiko can explain why it's in such terrible taste to patch
> authors, perhaps we need to do this. Up until now, I think the
> assumption is that file system maintainers would know something this
> self-evident, and if not, if it was pointed out, they wouldn't try to
> force such an ill-advised interface to Linus.
I believe this helps a lot to all newbies like me.
I really appreciate your feedback.
>
> - Ted
>
> P.S. As an exmaple of how I hanlded a somewhat similar scenario in
> the past, my employer's cluster file system needed
> FALLOC_FL_NO_HIDE_STALE to save $$$$ in TCO storage costs. But the
> concern was this would be an attractive nuisance for enterprise distro
> users, who would see the massive performance increase, not realize
> that this would leak stale data, which could result in user PII being
> exposed, thus making life hard for Enterprise Linux's reputation.
> (This wasn't an issue at $WORK because we enrypt all data at rest, and
> the cluster file system daemon was a privileged server who (a) knew
> what it was doing, and (b) only it would have access to set
> FALLOC_FL_NO_HIDE_STALE.)
>
> I disclosed *why* $WORK needed such a thing (it made a huge difference
> to storage TCO costss for Google's Cluster Filesystem), and after
> discussion and negotiation, we came to a compromise which involved my
> keeping the (very small) patch out of tree, but reserving the code
> point upstream to avoid future bitfield collisions. They key here was
> that I *knew* it was controversial, and I understood what problems it
> might cause in the rest of the ecosystem. That's part of the job of a
> maintainer, and it's also why a company might want to hire a
> maintainer. They can represent the needs of multiple stakeholders ---
> the upstream community, upstream users and the greater Linux
> ecosystem, as well as their employer.
>
>
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply
* Re: [f2fs-dev] [PATCH v2] f2fs: another way to set large folio by remembering inode number
From: Theodore Tso @ 2026-05-22 22:41 UTC (permalink / raw)
To: Jaegeuk Kim
Cc: linux-api, linux-kernel, Matthew Wilcox, linux-f2fs-devel,
Christoph Hellwig, linux-mm, linux-fsdevel, Akilesh Kailash,
Christian Brauner
In-Reply-To: <ahCNmWbcd_2lAJyk@google.com>
On Fri, May 22, 2026 at 05:08:41PM +0000, Jaegeuk Kim wrote:
>
> Thank you for the explanation. It seems I made a wrong assumption on the
> usage of "user." prefix where each filesystem can support in different
> ways.
The "user." prefix is used by all userspace applications that wish to
store extended attributes. For example, user.mime_type,
user.xdg.origin_url, user.charset, user.appache_handler, etc
For more information, see:
https://www.freedesktop.org/wiki/CommonExtendedAttribute
https://wiki.archlinux.org/title/Extended_attributes
I certainly assumed this was common knowledge across all file system
maintainers, but this was apparently not true in your case. I don't
know how this could be the case given that f2fs implements extended
attributes, and I would have thought you would have known that when
testing that feature.
> I shared some motivation when replying to Darrick's feedback [1], but yes,
> it was not enough for all heads-up. The problem started that some speicific
> application needs as many high-order pages as possible mostly for reads. So,
> I thought we can turn on large folio on the specific files per hints. One way
> for the hints was using immutable bit, but it turned out it's very hard to
> manage disabling the bit whenever deleting the files. Along with limited
> ioctl() and requiring inode eviction to manage large folio activation, I had
> to implement this path.
>
> [1] https://lore.kernel.org/lkml/aeA5C8byIpXWla7f@google.com/
Actually, you still haven't explained your use case, at least, not
well enough for me to understand what you are trying to do.
So an application wants a particular file to use as many high-order
pages as possible. Why? What sort of guarantees do you need to
provide? What happens if they can't be provided? What happens if a
possibly malicious, or at least gready, application uses this
interface to grab a lot of high-order pages?
From your patch:
1. setxattr(file, "user.fadvise", &value, sizeof(unsigned int), 0)
-> register the inode number for large folio
2. chmod(0400, file)
-> make Read-Only
3. open()
-> f2fs_iget() with large folio
4. open(WRITE), mkwrite on mmap, chmod(WRITE)
-> return error
5. iput() and open()
-> goto #3
6. unlink
-> deregister the inode number
Why should making the file read-only matter? And when you say
"derigster the inode number", why should this be related to deleting
the inode?
This is an interface which seems to be very specific to your use case.
What if those requirements change over time? What if you want pull in
a file without making it be read-only? And what if you want to
release the large-order pages without deleting the file?
- Ted
^ permalink raw reply
* [PATCH v2 1/6] sched: Update get_task_comm() comment
From: André Almeida @ 2026-05-24 22:38 UTC (permalink / raw)
To: Peter Zijlstra, Juri Lelli, Vincent Guittot, Steven Rostedt,
Christian Brauner, Kees Cook, Shuah Khan, willy,
mathieu.desnoyers, David Laight, Linus Torvalds, akpm,
Yafang Shao, andrii.nakryiko, arnaldo.melo, Petr Mladek
Cc: linux-kernel, kernel-dev, linux-mm, linux-api, Bhupesh,
André Almeida
In-Reply-To: <20260524-tonyk-long_name-v2-0-332f6bd041c4@igalia.com>
Since commit 3a3f61ce5e0b ("exec: Make sure task->comm is always
NUL-terminated"), __set_task_comm() no longer uses strscpy_pad(). Update
the stale comment accordingly.
Co-developed-by: Bhupesh <bhupesh@igalia.com>
Signed-off-by: Bhupesh <bhupesh@igalia.com>
Signed-off-by: André Almeida <andrealmeid@igalia.com>
---
include/linux/sched.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 368c7b4d7cb5..60d004a49a27 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2005,7 +2005,7 @@ extern void __set_task_comm(struct task_struct *tsk, const char *from, bool exec
* User space can randomly change their names anyway, so locking for readers
* doesn't make sense. For writers, locking is probably necessary, as a race
* condition could lead to long-term mixed results.
- * The strscpy_pad() in __set_task_comm() can ensure that the task comm is
+ * The logic inside __set_task_comm() ensures that the task comm is
* always NUL-terminated and zero-padded. Therefore the race condition between
* reader and writer is not an issue.
*
--
2.54.0
^ permalink raw reply related
* [PATCH v2 0/6] sched: Add support for long task name
From: André Almeida @ 2026-05-24 22:38 UTC (permalink / raw)
To: Peter Zijlstra, Juri Lelli, Vincent Guittot, Steven Rostedt,
Christian Brauner, Kees Cook, Shuah Khan, willy,
mathieu.desnoyers, David Laight, Linus Torvalds, akpm,
Yafang Shao, andrii.nakryiko, arnaldo.melo, Petr Mladek
Cc: linux-kernel, kernel-dev, linux-mm, linux-api, Bhupesh,
André Almeida
* Use case
When debugging and tracing complex programs with hundreds of threads, 16
long thread names are not enough anymore. cmd_line can show a lot of
characters, but it's not affected by pthread_setname_np() or
prctl(PR_SET_NAME), so let's give the same love kthreads got with commit
6b59808bfe48 ("workqueue: Show the latest workqueue name in
/proc/PID/{comm,stat,status}"). This work creates a new
PR_{SET,GET}_EXT_NAME that supports 64 byte long names.
* Patchset
Patch 1 is just a minor comment update.
Patch 2 and 3 do some prep work in order to avoid buffer overflows around
the kernel, now that current->comm is bigger. It also make sure that if
the destination buffer is smaller than TASK_COMM_EXT_LEN, it will
be NUL-terminated.
Patch 4 sets current->comm length to TASK_COMM_EXT_LEN and take care of
making sure that current userspace APIs gets only TASK_COMM_LEN.
Patch 5 creates new prctl() to set and get all the TASK_COMM_EXT_LEN bytes.
Patch 6 adapts the existing selftest for this new interface.
* Testing
selftests/prctl/set-process-name.c survives this patchset, and it was extended
to the new interface. Care was taken to make sure the old interfaces still
return 16 bytes, to avoid buffer overflow.
This patchset also survived some basic trace-cmd tests, but any advise or
how to stress even more all those string copies is very welcomed.
* Changes
Since v1:
- Replace new strtostr() with strscpy()
- Don't replace memcpy in tools/
- Link to v1: https://patch.msgid.link/20260517-tonyk-long_name-v1-0-3c282eaa91e2@igalia.com
Since Bhupesh's v8:
- Truncate userspace return to 16 bytes for old interfaces (PR_GET_NAME,
/proc/PID/comm/)
- Replace __cstr_array_copy() with new strtostr()
- Add new interface prctl(PR_{SET,GET}_EXT_NAME)
- Adapt selftest to this patchset
- https://lore.kernel.org/lkml/20250821102152.323367-1-bhupesh@igalia.com/
---
André Almeida (6):
sched: Update get_task_comm() comment
treewide: Get rid of get_task_comm()
treewide: Replace memcpy(..., current->comm) with strscpy()
sched: Extend task command name to 64 bytes
prctl: Add support for long user thread names
selftests: prctl: Add test for long thread names
drivers/connector/cn_proc.c | 2 +-
drivers/dma-buf/sw_sync.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_eviction_fence.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 2 +-
drivers/gpu/drm/lima/lima_ctx.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_gem.c | 2 +-
drivers/gpu/drm/panthor/panthor_gem.c | 2 +-
drivers/gpu/drm/panthor/panthor_sched.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 2 +-
drivers/hwtracing/stm/core.c | 2 +-
drivers/tty/tty_audit.c | 2 +-
fs/binfmt_elf.c | 2 +-
fs/binfmt_elf_fdpic.c | 2 +-
fs/proc/array.c | 2 +-
include/linux/coredump.h | 2 +-
include/linux/sched.h | 24 ++-------------
include/linux/tracepoint.h | 4 +--
include/trace/events/block.h | 10 +++---
include/trace/events/coredump.h | 2 +-
include/trace/events/f2fs.h | 4 +--
include/trace/events/oom.h | 2 +-
include/trace/events/osnoise.h | 2 +-
include/trace/events/sched.h | 10 +++---
include/trace/events/signal.h | 2 +-
include/trace/events/task.h | 4 +--
include/uapi/linux/prctl.h | 3 ++
kernel/audit.c | 6 ++--
kernel/auditsc.c | 6 ++--
kernel/printk/nbcon.c | 2 +-
kernel/printk/printk.c | 4 +--
kernel/sys.c | 23 +++++++++++---
net/bluetooth/hci_sock.c | 2 +-
net/netfilter/nf_tables_api.c | 4 ++-
security/integrity/integrity_audit.c | 3 +-
security/ipe/audit.c | 3 +-
security/landlock/domain.c | 2 +-
security/lsm_audit.c | 7 +++--
tools/testing/selftests/prctl/set-process-name.c | 36 ++++++++++++++++++++++
42 files changed, 124 insertions(+), 81 deletions(-)
---
base-commit: 5d6919055dec134de3c40167a490f33c74c12581
change-id: 20260516-tonyk-long_name-b9f345aeb041
Best regards,
--
André Almeida <andrealmeid@igalia.com>
^ permalink raw reply
* [PATCH v2 2/6] treewide: Get rid of get_task_comm()
From: André Almeida @ 2026-05-24 22:38 UTC (permalink / raw)
To: Peter Zijlstra, Juri Lelli, Vincent Guittot, Steven Rostedt,
Christian Brauner, Kees Cook, Shuah Khan, willy,
mathieu.desnoyers, David Laight, Linus Torvalds, akpm,
Yafang Shao, andrii.nakryiko, arnaldo.melo, Petr Mladek
Cc: linux-kernel, kernel-dev, linux-mm, linux-api, Bhupesh,
André Almeida
In-Reply-To: <20260524-tonyk-long_name-v2-0-332f6bd041c4@igalia.com>
Since commit 4cc0473d7754 ("get rid of __get_task_comm()"),
get_task_comm() does just a redundant check for the buffer size and call
strscpy_pad(). Replace get_task_comm() calls with strscpy_pad(), that will
do the right thing if the buffers sizes doesn't match: zero-pad if it's
bigger, and truncate if it's smaller.
Link: https://lore.kernel.org/lkml/CAHk-=wi5c=_-FBGo_88CowJd_F-Gi6Ud9d=TALm65ReN7YjrMw@mail.gmail.com/
Co-developed-by: Bhupesh <bhupesh@igalia.com>
Signed-off-by: Bhupesh <bhupesh@igalia.com>
Signed-off-by: André Almeida <andrealmeid@igalia.com>
---
Changes from v1:
- Fix for security/ipe/audit.c and net/netfilter/nf_tables_api.c
---
drivers/connector/cn_proc.c | 2 +-
drivers/dma-buf/sw_sync.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_eviction_fence.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 2 +-
drivers/gpu/drm/lima/lima_ctx.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_gem.c | 2 +-
drivers/gpu/drm/panthor/panthor_gem.c | 2 +-
drivers/gpu/drm/panthor/panthor_sched.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 2 +-
drivers/hwtracing/stm/core.c | 2 +-
drivers/tty/tty_audit.c | 2 +-
fs/binfmt_elf.c | 2 +-
fs/binfmt_elf_fdpic.c | 2 +-
fs/proc/array.c | 2 +-
include/linux/sched.h | 19 -------------------
kernel/audit.c | 6 ++++--
kernel/auditsc.c | 6 ++++--
kernel/printk/printk.c | 2 +-
kernel/sys.c | 2 +-
net/bluetooth/hci_sock.c | 2 +-
net/netfilter/nf_tables_api.c | 4 +++-
security/integrity/integrity_audit.c | 3 ++-
security/ipe/audit.c | 3 ++-
security/landlock/domain.c | 2 +-
security/lsm_audit.c | 7 ++++---
29 files changed, 42 insertions(+), 52 deletions(-)
diff --git a/drivers/connector/cn_proc.c b/drivers/connector/cn_proc.c
index 0056ab81fbc3..c78243ed3c2a 100644
--- a/drivers/connector/cn_proc.c
+++ b/drivers/connector/cn_proc.c
@@ -278,7 +278,7 @@ void proc_comm_connector(struct task_struct *task)
ev->what = PROC_EVENT_COMM;
ev->event_data.comm.process_pid = task->pid;
ev->event_data.comm.process_tgid = task->tgid;
- get_task_comm(ev->event_data.comm.comm, task);
+ strscpy_pad(ev->event_data.comm.comm, task->comm);
memcpy(&msg->id, &cn_proc_event_id, sizeof(msg->id));
msg->ack = 0; /* not used */
diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index 8df20b0218a9..d501657ad801 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -312,7 +312,7 @@ static int sw_sync_debugfs_open(struct inode *inode, struct file *file)
struct sync_timeline *obj;
char task_comm[TASK_COMM_LEN];
- get_task_comm(task_comm, current);
+ strscpy_pad(task_comm, current->comm);
obj = sync_timeline_create(task_comm);
if (!obj)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
index 6a364357522b..13c8857e4ffb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
@@ -74,7 +74,7 @@ struct amdgpu_amdkfd_fence *amdgpu_amdkfd_fence_create(u64 context,
/* This reference gets released in amdkfd_fence_release */
mmgrab(mm);
fence->mm = mm;
- get_task_comm(fence->timeline_name, current);
+ strscpy_pad(fence->timeline_name, current->comm);
spin_lock_init(&fence->lock);
fence->svm_bo = svm_bo;
fence->context_id = context_id;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_eviction_fence.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_eviction_fence.c
index 4c5e38dea4c2..faf0f36d8328 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_eviction_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_eviction_fence.c
@@ -129,7 +129,7 @@ int amdgpu_evf_mgr_rearm(struct amdgpu_eviction_fence_mgr *evf_mgr,
return -ENOMEM;
ev_fence->evf_mgr = evf_mgr;
- get_task_comm(ev_fence->timeline_name, current);
+ strscpy_pad(ev_fence->timeline_name, current->comm);
spin_lock_init(&ev_fence->lock);
dma_fence_init64(&ev_fence->base, &amdgpu_eviction_fence_ops,
&ev_fence->lock, evf_mgr->ev_fence_ctx,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index 6c644cfe6695..c45630457155 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -4419,7 +4419,7 @@ int amdgpu_ras_init(struct amdgpu_device *adev)
}
con->init_task_pid = task_pid_nr(current);
- get_task_comm(con->init_task_comm, current);
+ strscpy_pad(con->init_task_comm, current->comm);
mutex_init(&con->critical_region_lock);
INIT_LIST_HEAD(&con->critical_region_head);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c
index e2d5f04296e1..8fdc38d8d64d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c
@@ -85,7 +85,7 @@ int amdgpu_userq_fence_driver_alloc(struct amdgpu_device *adev,
fence_drv->adev = adev;
fence_drv->context = dma_fence_context_alloc(1);
- get_task_comm(fence_drv->timeline_name, current);
+ strscpy_pad(fence_drv->timeline_name, current->comm);
*fence_drv_req = fence_drv;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 9ba9de16a27a..de80d0ace905 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2571,10 +2571,10 @@ void amdgpu_vm_set_task_info(struct amdgpu_vm *vm)
return;
vm->task_info->task.pid = current->pid;
- get_task_comm(vm->task_info->task.comm, current);
+ strscpy_pad(vm->task_info->task.comm, current->comm);
vm->task_info->tgid = current->tgid;
- get_task_comm(vm->task_info->process_name, current->group_leader);
+ strscpy_pad(vm->task_info->process_name, current->group_leader->comm);
}
/**
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 2a241a5b12c4..f8ce59d8587a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -563,7 +563,7 @@ static int amdgpu_vram_mgr_new(struct ttm_resource_manager *man,
}
vres->task.pid = task_pid_nr(current);
- get_task_comm(vres->task.comm, current);
+ strscpy_pad(vres->task.comm, current->comm);
list_add_tail(&vres->vres_node, &mgr->allocated_vres_list);
if (bo->flags & AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS && adjust_dcc_size) {
diff --git a/drivers/gpu/drm/lima/lima_ctx.c b/drivers/gpu/drm/lima/lima_ctx.c
index 68ede7a725e2..e8c5c3601bf1 100644
--- a/drivers/gpu/drm/lima/lima_ctx.c
+++ b/drivers/gpu/drm/lima/lima_ctx.c
@@ -29,7 +29,7 @@ int lima_ctx_create(struct lima_device *dev, struct lima_ctx_mgr *mgr, u32 *id)
goto err_out0;
ctx->pid = task_pid_nr(current);
- get_task_comm(ctx->pname, current);
+ strscpy_pad(ctx->pname, current->comm);
return 0;
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c b/drivers/gpu/drm/panfrost/panfrost_gem.c
index 3a7fce428898..11936c4d3573 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
@@ -36,7 +36,7 @@ static void panfrost_gem_debugfs_bo_add(struct panfrost_device *pfdev,
struct panfrost_gem_object *bo)
{
bo->debugfs.creator.tgid = current->tgid;
- get_task_comm(bo->debugfs.creator.process_name, current->group_leader);
+ strscpy_pad(bo->debugfs.creator.process_name, current->group_leader->comm);
mutex_lock(&pfdev->debugfs.gems_lock);
list_add_tail(&bo->debugfs.node, &pfdev->debugfs.gems_list);
diff --git a/drivers/gpu/drm/panthor/panthor_gem.c b/drivers/gpu/drm/panthor/panthor_gem.c
index cd49859da89b..b44fd715c17e 100644
--- a/drivers/gpu/drm/panthor/panthor_gem.c
+++ b/drivers/gpu/drm/panthor/panthor_gem.c
@@ -46,7 +46,7 @@ static void panthor_gem_debugfs_bo_add(struct panthor_gem_object *bo)
struct panthor_device, base);
bo->debugfs.creator.tgid = current->tgid;
- get_task_comm(bo->debugfs.creator.process_name, current->group_leader);
+ strscpy_pad(bo->debugfs.creator.process_name, current->group_leader->comm);
mutex_lock(&ptdev->gems.lock);
list_add_tail(&bo->debugfs.node, &ptdev->gems.node);
diff --git a/drivers/gpu/drm/panthor/panthor_sched.c b/drivers/gpu/drm/panthor/panthor_sched.c
index 2fe04d0f0e3a..8ee9de96acf6 100644
--- a/drivers/gpu/drm/panthor/panthor_sched.c
+++ b/drivers/gpu/drm/panthor/panthor_sched.c
@@ -3603,7 +3603,7 @@ static void group_init_task_info(struct panthor_group *group)
struct task_struct *task = current->group_leader;
group->task_info.pid = task->pid;
- get_task_comm(group->task_info.comm, task);
+ strscpy_pad(group->task_info.comm, task->comm);
}
static void add_group_kbo_sizes(struct panthor_device *ptdev,
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index c33c057365f8..d2bf221e8f01 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -50,7 +50,7 @@ static void virtio_gpu_create_context_locked(struct virtio_gpu_device *vgdev,
} else {
char dbgname[TASK_COMM_LEN];
- get_task_comm(dbgname, current);
+ strscpy_pad(dbgname, current->comm);
virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id,
vfpriv->context_init, strlen(dbgname),
dbgname);
diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index f48c6a8a0654..c7715439964e 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -634,7 +634,7 @@ static ssize_t stm_char_write(struct file *file, const char __user *buf,
char comm[sizeof(current->comm)];
char *ids[] = { comm, "default", NULL };
- get_task_comm(comm, current);
+ strscpy_pad(comm, current->comm);
err = stm_assign_first_policy(stmf->stm, &stmf->output, ids, 1);
/*
diff --git a/drivers/tty/tty_audit.c b/drivers/tty/tty_audit.c
index d014af6ab060..d514a81d0a5c 100644
--- a/drivers/tty/tty_audit.c
+++ b/drivers/tty/tty_audit.c
@@ -77,7 +77,7 @@ static void tty_audit_log(const char *description, dev_t dev,
audit_log_format(ab, "%s pid=%u uid=%u auid=%u ses=%u major=%d minor=%d comm=",
description, pid, uid, loginuid, sessionid,
MAJOR(dev), MINOR(dev));
- get_task_comm(name, current);
+ strscpy_pad(name, current->comm);
audit_log_untrustedstring(ab, name);
audit_log_format(ab, " data=");
audit_log_n_hex(ab, data, size);
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 16a56b6b3f6c..d25922460b63 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1557,7 +1557,7 @@ static int fill_psinfo(struct elf_prpsinfo *psinfo, struct task_struct *p,
SET_UID(psinfo->pr_uid, from_kuid_munged(cred->user_ns, cred->uid));
SET_GID(psinfo->pr_gid, from_kgid_munged(cred->user_ns, cred->gid));
rcu_read_unlock();
- get_task_comm(psinfo->pr_fname, p);
+ strscpy_pad(psinfo->pr_fname, p->comm);
return 0;
}
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index 7e3108489c83..c4d4e59ff34d 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -1371,7 +1371,7 @@ static int fill_psinfo(struct elf_prpsinfo *psinfo, struct task_struct *p,
SET_UID(psinfo->pr_uid, from_kuid_munged(cred->user_ns, cred->uid));
SET_GID(psinfo->pr_gid, from_kgid_munged(cred->user_ns, cred->gid));
rcu_read_unlock();
- get_task_comm(psinfo->pr_fname, p);
+ strscpy_pad(psinfo->pr_fname, p->comm);
return 0;
}
diff --git a/fs/proc/array.c b/fs/proc/array.c
index 90fb0c6b5f99..c8c3fbd9bfa9 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -110,7 +110,7 @@ void proc_task_name(struct seq_file *m, struct task_struct *p, bool escape)
else if (p->flags & PF_KTHREAD)
get_kthread_comm(tcomm, sizeof(tcomm), p);
else
- get_task_comm(tcomm, p);
+ strscpy_pad(tcomm, p->comm);
if (escape)
seq_escape_str(m, tcomm, ESCAPE_SPACE | ESCAPE_SPECIAL, "\n\\");
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 60d004a49a27..b6de742b1155 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2000,25 +2000,6 @@ extern void __set_task_comm(struct task_struct *tsk, const char *from, bool exec
__set_task_comm(tsk, from, false); \
})
-/*
- * - Why not use task_lock()?
- * User space can randomly change their names anyway, so locking for readers
- * doesn't make sense. For writers, locking is probably necessary, as a race
- * condition could lead to long-term mixed results.
- * The logic inside __set_task_comm() ensures that the task comm is
- * always NUL-terminated and zero-padded. Therefore the race condition between
- * reader and writer is not an issue.
- *
- * - BUILD_BUG_ON() can help prevent the buf from being truncated.
- * Since the callers don't perform any return value checks, this safeguard is
- * necessary.
- */
-#define get_task_comm(buf, tsk) ({ \
- BUILD_BUG_ON(sizeof(buf) < TASK_COMM_LEN); \
- strscpy_pad(buf, (tsk)->comm); \
- buf; \
-})
-
static __always_inline void scheduler_ipi(void)
{
/*
diff --git a/kernel/audit.c b/kernel/audit.c
index e1d489bc2dff..6fc867adbf3d 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1662,7 +1662,8 @@ static void audit_log_multicast(int group, const char *op, int err)
audit_put_tty(tty);
audit_log_task_context(ab); /* subj= */
audit_log_format(ab, " comm=");
- audit_log_untrustedstring(ab, get_task_comm(comm, current));
+ strscpy_pad(comm, current->comm);
+ audit_log_untrustedstring(ab, comm);
audit_log_d_path_exe(ab, current->mm); /* exe= */
audit_log_format(ab, " nl-mcgrp=%d op=%s res=%d", group, op, !err);
audit_log_end(ab);
@@ -2465,7 +2466,8 @@ void audit_log_task_info(struct audit_buffer *ab)
audit_get_sessionid(current));
audit_put_tty(tty);
audit_log_format(ab, " comm=");
- audit_log_untrustedstring(ab, get_task_comm(comm, current));
+ strscpy_pad(comm, current->comm);
+ audit_log_untrustedstring(ab, comm);
audit_log_d_path_exe(ab, current->mm);
audit_log_task_context(ab);
}
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index ab54fccba215..8e4f70105a13 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2877,7 +2877,8 @@ void __audit_log_nfcfg(const char *name, u8 af, unsigned int nentries,
audit_log_format(ab, " pid=%u", task_tgid_nr(current));
audit_log_task_context(ab); /* subj= */
audit_log_format(ab, " comm=");
- audit_log_untrustedstring(ab, get_task_comm(comm, current));
+ strscpy_pad(comm, current->comm);
+ audit_log_untrustedstring(ab, comm);
audit_log_end(ab);
}
EXPORT_SYMBOL_GPL(__audit_log_nfcfg);
@@ -2900,7 +2901,8 @@ static void audit_log_task(struct audit_buffer *ab)
sessionid);
audit_log_task_context(ab);
audit_log_format(ab, " pid=%d comm=", task_tgid_nr(current));
- audit_log_untrustedstring(ab, get_task_comm(comm, current));
+ strscpy_pad(comm, current->comm);
+ audit_log_untrustedstring(ab, comm);
audit_log_d_path_exe(ab, current->mm);
}
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 0323149548f6..1f04e753ca02 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2247,7 +2247,7 @@ static u16 printk_sprint(char *text, u16 size, int facility,
static void printk_store_execution_ctx(struct printk_info *info)
{
info->caller_id2 = printk_caller_id2();
- get_task_comm(info->comm, current);
+ strscpy_pad(info->comm, current->comm);
}
static void pmsg_load_execution_ctx(struct printk_message *pmsg,
diff --git a/kernel/sys.c b/kernel/sys.c
index 62e842055cc9..1d5152d2395e 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -2609,7 +2609,7 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
proc_comm_connector(me);
break;
case PR_GET_NAME:
- get_task_comm(comm, me);
+ strscpy_pad(comm, me->comm);
if (copy_to_user((char __user *)arg2, comm, sizeof(comm)))
return -EFAULT;
break;
diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
index 0290dea081f6..38e16ba2de38 100644
--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -106,7 +106,7 @@ static bool hci_sock_gen_cookie(struct sock *sk)
id = 0xffffffff;
hci_pi(sk)->cookie = id;
- get_task_comm(hci_pi(sk)->comm, current);
+ strscpy_pad(hci_pi(sk)->comm, current->comm);
return true;
}
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index 87387adbca65..cd00d4da1316 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -9709,9 +9709,11 @@ static int nf_tables_fill_gen_info(struct sk_buff *skb, struct net *net,
if (!nlh)
goto nla_put_failure;
+ strscpy_pad(buf, current->comm);
+
if (nla_put_be32(skb, NFTA_GEN_ID, htonl(nft_base_seq(net))) ||
nla_put_be32(skb, NFTA_GEN_PROC_PID, htonl(task_pid_nr(current))) ||
- nla_put_string(skb, NFTA_GEN_PROC_NAME, get_task_comm(buf, current)))
+ nla_put_string(skb, NFTA_GEN_PROC_NAME, buf))
goto nla_put_failure;
nlmsg_end(skb, nlh);
diff --git a/security/integrity/integrity_audit.c b/security/integrity/integrity_audit.c
index d8d9e5ff1cd2..98060060929d 100644
--- a/security/integrity/integrity_audit.c
+++ b/security/integrity/integrity_audit.c
@@ -54,7 +54,8 @@ void integrity_audit_message(int audit_msgno, struct inode *inode,
audit_get_sessionid(current));
audit_log_task_context(ab);
audit_log_format(ab, " op=%s cause=%s comm=", op, cause);
- audit_log_untrustedstring(ab, get_task_comm(name, current));
+ strscpy_pad(name, current->comm);
+ audit_log_untrustedstring(ab, name);
if (fname) {
audit_log_format(ab, " name=");
audit_log_untrustedstring(ab, fname);
diff --git a/security/ipe/audit.c b/security/ipe/audit.c
index 93fb59fbddd6..90a6acfb7cdf 100644
--- a/security/ipe/audit.c
+++ b/security/ipe/audit.c
@@ -145,7 +145,8 @@ void ipe_audit_match(const struct ipe_eval_ctx *const ctx,
audit_log_format(ab, "ipe_op=%s ipe_hook=%s enforcing=%d pid=%d comm=",
op, audit_hook_names[ctx->hook], READ_ONCE(enforce),
task_tgid_nr(current));
- audit_log_untrustedstring(ab, get_task_comm(comm, current));
+ strscpy_pad(comm, current->comm);
+ audit_log_untrustedstring(ab, comm);
if (ctx->file) {
audit_log_d_path(ab, " path=", &ctx->file->f_path);
diff --git a/security/landlock/domain.c b/security/landlock/domain.c
index 06b6bd845060..a35a27f523e6 100644
--- a/security/landlock/domain.c
+++ b/security/landlock/domain.c
@@ -101,7 +101,7 @@ static struct landlock_details *get_current_details(void)
memcpy(details->exe_path, path_str, path_size);
details->pid = get_pid(task_tgid(current));
details->uid = from_kuid(&init_user_ns, current_uid());
- get_task_comm(details->comm, current);
+ strscpy_pad(details->comm, current->comm);
return details;
}
diff --git a/security/lsm_audit.c b/security/lsm_audit.c
index 737f5a263a8f..a587ffecd985 100644
--- a/security/lsm_audit.c
+++ b/security/lsm_audit.c
@@ -276,8 +276,8 @@ void audit_log_lsm_data(struct audit_buffer *ab,
if (pid) {
char tskcomm[sizeof(tsk->comm)];
audit_log_format(ab, " opid=%d ocomm=", pid);
- audit_log_untrustedstring(ab,
- get_task_comm(tskcomm, tsk));
+ strscpy_pad(tskcomm, tsk->comm);
+ audit_log_untrustedstring(ab, tskcomm);
}
}
break;
@@ -417,7 +417,8 @@ static void dump_common_audit_data(struct audit_buffer *ab,
char comm[sizeof(current->comm)];
audit_log_format(ab, " pid=%d comm=", task_tgid_nr(current));
- audit_log_untrustedstring(ab, get_task_comm(comm, current));
+ strscpy_pad(comm, current->comm);
+ audit_log_untrustedstring(ab, comm);
audit_log_lsm_data(ab, a);
}
--
2.54.0
^ permalink raw reply related
* [PATCH v2 3/6] treewide: Replace memcpy(..., current->comm) with strscpy()
From: André Almeida @ 2026-05-24 22:38 UTC (permalink / raw)
To: Peter Zijlstra, Juri Lelli, Vincent Guittot, Steven Rostedt,
Christian Brauner, Kees Cook, Shuah Khan, willy,
mathieu.desnoyers, David Laight, Linus Torvalds, akpm,
Yafang Shao, andrii.nakryiko, arnaldo.melo, Petr Mladek
Cc: linux-kernel, kernel-dev, linux-mm, linux-api, André Almeida
In-Reply-To: <20260524-tonyk-long_name-v2-0-332f6bd041c4@igalia.com>
In order to increase the size of current->comm[] and to avoid breaking any
existing code, replace memcpy() with strscpy(). The later function makes
sure that the copy is NUL terminated. This is crucial given that the
source buffer might be larger than the destination buffer and could
truncate the NUL character out of it.
Signed-off-by: André Almeida <andrealmeid@igalia.com>
---
Changes from v2:
- New patch, dropped strtostr() from last version
---
include/linux/coredump.h | 2 +-
include/linux/tracepoint.h | 4 ++--
include/trace/events/block.h | 10 +++++-----
include/trace/events/coredump.h | 2 +-
include/trace/events/f2fs.h | 4 ++--
include/trace/events/oom.h | 2 +-
include/trace/events/osnoise.h | 2 +-
include/trace/events/sched.h | 10 +++++-----
include/trace/events/signal.h | 2 +-
include/trace/events/task.h | 4 ++--
kernel/printk/nbcon.c | 2 +-
kernel/printk/printk.c | 2 +-
12 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/include/linux/coredump.h b/include/linux/coredump.h
index 68861da4cf7c..45cd55114120 100644
--- a/include/linux/coredump.h
+++ b/include/linux/coredump.h
@@ -54,7 +54,7 @@ extern void vfs_coredump(const kernel_siginfo_t *siginfo);
do { \
char comm[TASK_COMM_LEN]; \
/* This will always be NUL terminated. */ \
- memcpy(comm, current->comm, sizeof(comm)); \
+ strscpy(comm, current->comm, sizeof(comm)); \
printk_ratelimited(Level "coredump: %d(%*pE): " Format "\n", \
task_tgid_vnr(current), (int)strlen(comm), comm, ##__VA_ARGS__); \
} while (0) \
diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index 763eea4d80d8..90fd9109210c 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -615,10 +615,10 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
* *
*
* TP_fast_assign(
- * memcpy(__entry->next_comm, next->comm, TASK_COMM_LEN);
+ * strscpy(__entry->next_comm, next->comm, TASK_COMM_LEN);
* __entry->prev_pid = prev->pid;
* __entry->prev_prio = prev->prio;
- * memcpy(__entry->prev_comm, prev->comm, TASK_COMM_LEN);
+ * strscpy(__entry->prev_comm, prev->comm, TASK_COMM_LEN);
* __entry->next_pid = next->pid;
* __entry->next_prio = next->prio;
* ),
diff --git a/include/trace/events/block.h b/include/trace/events/block.h
index 6aa79e2d799c..73db3713b967 100644
--- a/include/trace/events/block.h
+++ b/include/trace/events/block.h
@@ -213,7 +213,7 @@ DECLARE_EVENT_CLASS(block_rq,
blk_fill_rwbs(__entry->rwbs, rq->cmd_flags);
__get_str(cmd)[0] = '\0';
- memcpy(__entry->comm, current->comm, TASK_COMM_LEN);
+ strscpy(__entry->comm, current->comm, TASK_COMM_LEN);
),
TP_printk("%d,%d %s %u (%s) %llu + %u %s,%u,%u [%s]",
@@ -351,7 +351,7 @@ DECLARE_EVENT_CLASS(block_bio,
__entry->sector = bio->bi_iter.bi_sector;
__entry->nr_sector = bio_sectors(bio);
blk_fill_rwbs(__entry->rwbs, bio->bi_opf);
- memcpy(__entry->comm, current->comm, TASK_COMM_LEN);
+ strscpy(__entry->comm, current->comm, TASK_COMM_LEN);
),
TP_printk("%d,%d %s %llu + %u [%s]",
@@ -434,7 +434,7 @@ TRACE_EVENT(block_plug,
),
TP_fast_assign(
- memcpy(__entry->comm, current->comm, TASK_COMM_LEN);
+ strscpy(__entry->comm, current->comm, TASK_COMM_LEN);
),
TP_printk("[%s]", __entry->comm)
@@ -453,7 +453,7 @@ DECLARE_EVENT_CLASS(block_unplug,
TP_fast_assign(
__entry->nr_rq = depth;
- memcpy(__entry->comm, current->comm, TASK_COMM_LEN);
+ strscpy(__entry->comm, current->comm, TASK_COMM_LEN);
),
TP_printk("[%s] %d", __entry->comm, __entry->nr_rq)
@@ -504,7 +504,7 @@ TRACE_EVENT(block_split,
__entry->sector = bio->bi_iter.bi_sector;
__entry->new_sector = new_sector;
blk_fill_rwbs(__entry->rwbs, bio->bi_opf);
- memcpy(__entry->comm, current->comm, TASK_COMM_LEN);
+ strscpy(__entry->comm, current->comm, TASK_COMM_LEN);
),
TP_printk("%d,%d %s %llu / %llu [%s]",
diff --git a/include/trace/events/coredump.h b/include/trace/events/coredump.h
index c7b9c53fc498..dc21ec89a4fb 100644
--- a/include/trace/events/coredump.h
+++ b/include/trace/events/coredump.h
@@ -32,7 +32,7 @@ TRACE_EVENT(coredump,
TP_fast_assign(
__entry->sig = sig;
- memcpy(__entry->comm, current->comm, TASK_COMM_LEN);
+ strscpy(__entry->comm, current->comm, TASK_COMM_LEN);
),
TP_printk("sig=%d comm=%s",
diff --git a/include/trace/events/f2fs.h b/include/trace/events/f2fs.h
index b5188d2671d7..1e56e448268c 100644
--- a/include/trace/events/f2fs.h
+++ b/include/trace/events/f2fs.h
@@ -2505,7 +2505,7 @@ TRACE_EVENT(f2fs_lock_elapsed_time,
TP_fast_assign(
__entry->dev = sbi->sb->s_dev;
- memcpy(__entry->comm, p->comm, TASK_COMM_LEN);
+ strscpy(__entry->comm, p->comm, TASK_COMM_LEN);
__entry->pid = p->pid;
__entry->prio = p->prio;
__entry->ioprio_class = IOPRIO_PRIO_CLASS(ioprio);
@@ -2558,7 +2558,7 @@ DECLARE_EVENT_CLASS(f2fs_priority_update,
TP_fast_assign(
__entry->dev = sbi->sb->s_dev;
- memcpy(__entry->comm, p->comm, TASK_COMM_LEN);
+ strscpy(__entry->comm, p->comm, TASK_COMM_LEN);
__entry->pid = p->pid;
__entry->lock_name = lock_name;
__entry->is_write = is_write;
diff --git a/include/trace/events/oom.h b/include/trace/events/oom.h
index 9f0a5d1482c4..172278a7e20a 100644
--- a/include/trace/events/oom.h
+++ b/include/trace/events/oom.h
@@ -23,7 +23,7 @@ TRACE_EVENT(oom_score_adj_update,
TP_fast_assign(
__entry->pid = task->pid;
- memcpy(__entry->comm, task->comm, TASK_COMM_LEN);
+ strscpy(__entry->comm, task->comm, TASK_COMM_LEN);
__entry->oom_score_adj = task->signal->oom_score_adj;
),
diff --git a/include/trace/events/osnoise.h b/include/trace/events/osnoise.h
index 3f4273623801..4db90931e897 100644
--- a/include/trace/events/osnoise.h
+++ b/include/trace/events/osnoise.h
@@ -116,7 +116,7 @@ TRACE_EVENT(thread_noise,
),
TP_fast_assign(
- memcpy(__entry->comm, t->comm, TASK_COMM_LEN);
+ strscpy(__entry->comm, t->comm, TASK_COMM_LEN);
__entry->pid = t->pid;
__entry->start = start;
__entry->duration = duration;
diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
index 535860581f15..a932f443f327 100644
--- a/include/trace/events/sched.h
+++ b/include/trace/events/sched.h
@@ -152,7 +152,7 @@ DECLARE_EVENT_CLASS(sched_wakeup_template,
),
TP_fast_assign(
- memcpy(__entry->comm, p->comm, TASK_COMM_LEN);
+ strscpy(__entry->comm, p->comm, TASK_COMM_LEN);
__entry->pid = p->pid;
__entry->prio = p->prio; /* XXX SCHED_DEADLINE */
__entry->target_cpu = task_cpu(p);
@@ -237,11 +237,11 @@ TRACE_EVENT(sched_switch,
),
TP_fast_assign(
- memcpy(__entry->prev_comm, prev->comm, TASK_COMM_LEN);
+ strscpy(__entry->prev_comm, prev->comm, TASK_COMM_LEN);
__entry->prev_pid = prev->pid;
__entry->prev_prio = prev->prio;
__entry->prev_state = __trace_sched_switch_state(preempt, prev_state, prev);
- memcpy(__entry->next_comm, next->comm, TASK_COMM_LEN);
+ strscpy(__entry->next_comm, next->comm, TASK_COMM_LEN);
__entry->next_pid = next->pid;
__entry->next_prio = next->prio;
/* XXX SCHED_DEADLINE */
@@ -346,7 +346,7 @@ TRACE_EVENT(sched_process_exit,
),
TP_fast_assign(
- memcpy(__entry->comm, p->comm, TASK_COMM_LEN);
+ strscpy(__entry->comm, p->comm, TASK_COMM_LEN);
__entry->pid = p->pid;
__entry->prio = p->prio; /* XXX SCHED_DEADLINE */
__entry->group_dead = group_dead;
@@ -787,7 +787,7 @@ TRACE_EVENT(sched_skip_cpuset_numa,
),
TP_fast_assign(
- memcpy(__entry->comm, tsk->comm, TASK_COMM_LEN);
+ strscpy(__entry->comm, tsk->comm, TASK_COMM_LEN);
__entry->pid = task_pid_nr(tsk);
__entry->tgid = task_tgid_nr(tsk);
__entry->ngid = task_numa_group_id(tsk);
diff --git a/include/trace/events/signal.h b/include/trace/events/signal.h
index 1db7e4b07c01..6aa7d1123f04 100644
--- a/include/trace/events/signal.h
+++ b/include/trace/events/signal.h
@@ -67,7 +67,7 @@ TRACE_EVENT(signal_generate,
TP_fast_assign(
__entry->sig = sig;
TP_STORE_SIGINFO(__entry, info);
- memcpy(__entry->comm, task->comm, TASK_COMM_LEN);
+ strscpy(__entry->comm, task->comm, TASK_COMM_LEN);
__entry->pid = task->pid;
__entry->group = group;
__entry->result = result;
diff --git a/include/trace/events/task.h b/include/trace/events/task.h
index b9a129eb54d9..f75dbf20fe02 100644
--- a/include/trace/events/task.h
+++ b/include/trace/events/task.h
@@ -21,7 +21,7 @@ TRACE_EVENT(task_newtask,
TP_fast_assign(
__entry->pid = task->pid;
- memcpy(__entry->comm, task->comm, TASK_COMM_LEN);
+ strscpy(__entry->comm, task->comm, TASK_COMM_LEN);
__entry->clone_flags = clone_flags;
__entry->oom_score_adj = task->signal->oom_score_adj;
),
@@ -46,7 +46,7 @@ TRACE_EVENT(task_rename,
TP_fast_assign(
__entry->pid = task->pid;
- memcpy(entry->oldcomm, task->comm, TASK_COMM_LEN);
+ strscpy(entry->oldcomm, task->comm, TASK_COMM_LEN);
strscpy(entry->newcomm, comm, TASK_COMM_LEN);
__entry->oom_score_adj = task->signal->oom_score_adj;
),
diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c
index d7044a7a214b..7625adc0a2e1 100644
--- a/kernel/printk/nbcon.c
+++ b/kernel/printk/nbcon.c
@@ -952,7 +952,7 @@ static void wctxt_load_execution_ctx(struct nbcon_write_context *wctxt,
{
wctxt->cpu = pmsg->cpu;
wctxt->pid = pmsg->pid;
- memcpy(wctxt->comm, pmsg->comm, sizeof(wctxt->comm));
+ strscpy(wctxt->comm, pmsg->comm, sizeof(wctxt->comm));
static_assert(sizeof(wctxt->comm) == sizeof(pmsg->comm));
}
#else
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 1f04e753ca02..eaf8b7b930df 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2255,7 +2255,7 @@ static void pmsg_load_execution_ctx(struct printk_message *pmsg,
{
pmsg->cpu = printk_info_get_cpu(info);
pmsg->pid = printk_info_get_pid(info);
- memcpy(pmsg->comm, info->comm, sizeof(pmsg->comm));
+ strscpy(pmsg->comm, info->comm, sizeof(pmsg->comm));
static_assert(sizeof(pmsg->comm) == sizeof(info->comm));
}
#else
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox