Re: [PATCH] tracing: Fix uaf issue in tracing_open_file_tr

2024-05-01 Thread 吳澤南
On Wed, 2024-05-01 at 23:50 -0400, Steven Rostedt wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On Thu, 2 May 2024 03:10:24 + > Tze-nan Wu (吳澤南) wrote: > > > > > > Sorry for my late reply, I'm testi

Re: [PATCH] tracing: Fix uaf issue in tracing_open_file_tr

2024-05-01 Thread 吳澤南
On Wed, 2024-05-01 at 23:50 -0400, Steven Rostedt wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On Thu, 2 May 2024 03:10:24 + > Tze-nan Wu (吳澤南) wrote: > > > > > > Sorry for my late reply, I'm testi

Re: [RFC][PATCH] uprobe: support for private hugetlb mappings

2024-05-01 Thread Guillaume Morin
On 30 Apr 21:25, David Hildenbrand wrote: > > I tried to get the hugepd stuff right but this was the first I heard > > about it :-) Afaict follow_huge_pmd and friends were already DTRT > > I'll have to have a closer look at some details (the hugepd writability > check looks a bit odd), but it's mo

Re: [PATCH] tracing: Fix uaf issue in tracing_open_file_tr

2024-05-01 Thread Steven Rostedt
On Thu, 2 May 2024 03:10:24 + Tze-nan Wu (吳澤南) wrote: > > > Sorry for my late reply, I'm testing the patch on my machine now. > Test will be done in four hours. > > There's something I'm worrying about in the patch, > what I'm worrying about is commented in the code below. > > /kernel/t

Re: [PATCH resend ftrace] Asynchronous grace period for register_ftrace_direct()

2024-05-01 Thread Paul E. McKenney
On Thu, May 02, 2024 at 11:05:01AM +0900, Masami Hiramatsu wrote: > On Wed, 1 May 2024 16:12:37 -0700 > "Paul E. McKenney" wrote: > > > Note that the immediate pressure for this patch should be relieved by the > > NAPI patch series [1], but this sort of problem could easily arise again. > > > >

Re: [PATCH] tracing: Fix uaf issue in tracing_open_file_tr

2024-05-01 Thread 吳澤南
On Mon, 2024-04-29 at 14:46 -0400, Steven Rostedt wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On Sun, 28 Apr 2024 20:28:37 -0400 > Steven Rostedt wrote: > > > > Looking for any suggestion or solution, ap

[PATCH 5/5] eventfs: Have "events" directory get permissions from its parent

2024-05-01 Thread Steven Rostedt
From: "Steven Rostedt (Google)" The events directory gets its permissions from the root inode. But this can cause an inconsistency if the instances directory changes its permissions, as the permissions of the created directories under it should inherit the permissions of the instances directory w

[PATCH 4/5] eventfs: Do not treat events directory different than other directories

2024-05-01 Thread Steven Rostedt
From: "Steven Rostedt (Google)" Treat the events directory the same as other directories when it comes to permissions. The events directory was considered different because it's dentry is persistent, whereas the other directory dentries are created when accessed. But the way tracefs now does its

[PATCH 3/5] eventfs: Do not differentiate the toplevel events directory

2024-05-01 Thread Steven Rostedt
From: "Steven Rostedt (Google)" The toplevel events directory is really no different than the events directory of instances. Having the two be different caused inconsistencies and made it harder to fix the permissions bugs. Make all events directories act the same. Cc: sta...@vger.kernel.org Fi

[PATCH 2/5] tracefs: Still use mount point as default permissions for instances

2024-05-01 Thread Steven Rostedt
From: "Steven Rostedt (Google)" If the instances directory's permissions were never change, then have it and its children use the mount point permissions as the default. Currently, the permissions of instance directories are determined by the instance directory's permissions itself. But if the t

[PATCH 0/5] tracefs/eventfs: Fix inconsistent permissions

2024-05-01 Thread Steven Rostedt
The tracefs and eventfs permissions are created dynamically based on what the mount point inode has or the instances directory inode has. But the way it worked had some inconsistencies that could lead to security issues as the file system is not behaving like admins would expect. The files and d

[PATCH 1/5] tracefs: Reset permissions on remount if permissions are options

2024-05-01 Thread Steven Rostedt
From: "Steven Rostedt (Google)" There's an inconsistency with the way permissions are handled in tracefs. Because the permissions are generated when accessed, they default to the root inode's permission if they were never set by the user. If the user sets the permissions, then a flag is set and t

Re: [PATCH resend ftrace] Asynchronous grace period for register_ftrace_direct()

2024-05-01 Thread Google
On Wed, 1 May 2024 16:12:37 -0700 "Paul E. McKenney" wrote: > Note that the immediate pressure for this patch should be relieved by the > NAPI patch series [1], but this sort of problem could easily arise again. > > When running heavy test workloads with KASAN enabled, RCU Tasks grace > periods

Re: [v3] tracing/probes: Fix memory leak in traceprobe_parse_probe_arg_body()

2024-05-01 Thread Google
On Mon, 29 Apr 2024 15:55:09 +0200 Markus Elfring wrote: > … > > > it jumps to the label 'out' instead of 'fail' by mistake.In the result, > … > > > > Looks good to me. > > * Do you care for a typo in this change description? > > * Would you like to read any improved (patch) version description

[PATCH resend ftrace] Asynchronous grace period for register_ftrace_direct()

2024-05-01 Thread Paul E. McKenney
Note that the immediate pressure for this patch should be relieved by the NAPI patch series [1], but this sort of problem could easily arise again. When running heavy test workloads with KASAN enabled, RCU Tasks grace periods can extend for many tens of seconds, significantly slowing trace registr

Re: [syzbot] [net?] [virt?] [kvm?] KASAN: slab-use-after-free Read in vhost_task_fn

2024-05-01 Thread syzbot
Hello, syzbot has tested the proposed patch and the reproducer did not trigger any issue: Reported-and-tested-by: syzbot+98edc2df894917b34...@syzkaller.appspotmail.com Tested on: commit: f138e94c KASAN: slab-use-after-free Read in vhost_task.. git tree: https://git.kernel.org/pub

Re: [PATCH next] vhost_task: after freeing vhost_task it should not be accessed in vhost_task_fn

2024-05-01 Thread Michael S. Tsirkin
On Wed, May 01, 2024 at 10:57:38AM -0500, Mike Christie wrote: > On 5/1/24 2:50 AM, Hillf Danton wrote: > > On Wed, 1 May 2024 02:01:20 -0400 Michael S. Tsirkin > >> > >> and then it failed testing. > >> > > So did my patch [1] but then the reason was spotted [2,3] > > > > [1] https://lore.kernel

Re: [syzbot] [net?] [virt?] [kvm?] KASAN: slab-use-after-free Read in vhost_task_fn

2024-05-01 Thread Michael S. Tsirkin
#syz test https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git f138e94c1f0dbeae721917694fb2203446a68ea9

Re: [PATCH next] vhost_task: after freeing vhost_task it should not be accessed in vhost_task_fn

2024-05-01 Thread Michael S. Tsirkin
On Wed, May 01, 2024 at 10:57:38AM -0500, Mike Christie wrote: > On 5/1/24 2:50 AM, Hillf Danton wrote: > > On Wed, 1 May 2024 02:01:20 -0400 Michael S. Tsirkin > >> > >> and then it failed testing. > >> > > So did my patch [1] but then the reason was spotted [2,3] > > > > [1] https://lore.kernel

Re: [PATCH next] vhost_task: after freeing vhost_task it should not be accessed in vhost_task_fn

2024-05-01 Thread Mike Christie
On 5/1/24 2:50 AM, Hillf Danton wrote: > On Wed, 1 May 2024 02:01:20 -0400 Michael S. Tsirkin >> >> and then it failed testing. >> > So did my patch [1] but then the reason was spotted [2,3] > > [1] https://lore.kernel.org/lkml/20240430110209.4310-1-hdan...@sina.com/ > [2] https://lore.kernel.org

Re: EEVDF/vhost regression (bisected to 86bfbb7ce4f6 sched/fair: Add lag based placement)

2024-05-01 Thread Michael S. Tsirkin
On Wed, May 01, 2024 at 12:51:51PM +0200, Peter Zijlstra wrote: > On Tue, Apr 30, 2024 at 12:50:05PM +0200, Tobias Huschle wrote: > > It took me a while, but I was able to figure out why EEVDF behaves > > different then CFS does. I'm still waiting for some official confirmation > > of my assumptio

Re: [PATCH] eventfs/tracing: Add callback for release of an eventfs_inode

2024-05-01 Thread Google
On Tue, 30 Apr 2024 14:23:27 -0400 Steven Rostedt wrote: > From: "Steven Rostedt (Google)" > > Synthetic events create and destroy tracefs files when they are created > and removed. The tracing subsystem has its own file descriptor > representing the state of the events attached to the tracefs

Re: EEVDF/vhost regression (bisected to 86bfbb7ce4f6 sched/fair: Add lag based placement)

2024-05-01 Thread Peter Zijlstra
On Tue, Apr 30, 2024 at 12:50:05PM +0200, Tobias Huschle wrote: > It took me a while, but I was able to figure out why EEVDF behaves > different then CFS does. I'm still waiting for some official confirmation > of my assumptions but it all seems very plausible to me. > > Leaving aside all the spe

Re: [PATCH next] vhost_task: after freeing vhost_task it should not be accessed in vhost_task_fn

2024-05-01 Thread Hillf Danton
On Wed, 1 May 2024 02:01:20 -0400 Michael S. Tsirkin > > and then it failed testing. > So did my patch [1] but then the reason was spotted [2,3] [1] https://lore.kernel.org/lkml/20240430110209.4310-1-hdan...@sina.com/ [2] https://lore.kernel.org/lkml/20240430225005.4368-1-hdan...@sina.com/ [3]