https://bugzilla.kernel.org/show_bug.cgi?id=214913
Michael Ellerman (michael@ellerman.id.au) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
CC| |michael@ellerman.id.au
--- Comment #2 from Michael Ellerman (michael@ellerman.id.au) ---
Thanks for the report, I agree this looks like a powerpc bug not an XFS bug.
I won't have time to look at this until next week probably, unless someone
beats me to it.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=214913
Michal Suchanek (hramrach@gmail.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hramrach@gmail.com
--- Comment #3 from Michal Suchanek (hramrach@gmail.com) ---
What CPU is this?
Does it go away if you boot with ppc_tm=off
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
--- Comment #4 from Zorro Lang (zlang@redhat.com) ---
(In reply to Michal Suchanek from comment #3)
What CPU is this?
Does it go away if you boot with ppc_tm=off
(In reply to Michael Ellerman from comment #2)
Thanks for the report, I agree this looks like a powerpc bug not an XFS bug.
I won't have time to look at this until next week probably, unless someone
beats me to it.
Thanks for you reply. (Un)fortunately, due to linux keeps updating, I can't
reproduce this panic on latest mainline linux master branch now. The HEAD
commit is 7ddb58cb0eca. From 8bb7eca972ad (v5.15) to 7ddb58cb0eca (v5.15+),
there're many changes, I can't sure which commit fixes this bug, or hide it? Do
you know if there was a known issue about this has been fixed?
Thanks,
Zorro
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=214913
Michael Ellerman (michael@ellerman.id.au) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEEDINFO
--- Comment #5 from Michael Ellerman (michael@ellerman.id.au) ---
Sorry I don't have any idea which commit could have fixed this.
The process that crashed was "fsstress", do you know if it uses io_uring?
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
--- Comment #7 from Zorro Lang (zlang@redhat.com) ---
(In reply to Michael Ellerman from comment #5)
Sorry I don't have any idea which commit could have fixed this.
The process that crashed was "fsstress", do you know if it uses io_uring?
Yes, fsstress has io_uring read/write operations. And from the kernel .config
file(as attachment), the CONFIG_IO_URING=y
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
--- Comment #7 from Zorro Lang (zlang@redhat.com) ---
(In reply to Michael Ellerman from comment #5)
quoted
Sorry I don't have any idea which commit could have fixed this.
The process that crashed was "fsstress", do you know if it uses io_uring?
Yes, fsstress has io_uring read/write operations. And from the kernel .config
file(as attachment), the CONFIG_IO_URING=y
The task being dumped seems like it's lost its task->thread.regs. The
NULL pointer is here:
int tm_cgpr_active(struct task_struct *target, const struct user_regset *regset)
{
if (!cpu_has_feature(CPU_FTR_TM))
return -ENODEV;
if (!MSR_TM_ACTIVE(target->thread.regs->msr))
return 0;
return regset->n;
}
On that regs->msr deref. r9 contains the regs pointer.
The kernel attempt to read user page - exploit attempt? message is
I think a red herring it's coming up because of the NULL deref I
think (I thought we fixed that).
Anyway I'm not sure how we could lose regs, all user threads should
have them set to non-NULL. It doesn't look like we can collect threads
for dumping before we have called copy_thread(), which is where they
get thread.regs set. AFAIK it's not supposed to change after that.
Would you be able to try this patch, hopefully it catches the problem
thread on the exit side, and gives a clue why regs is NULL.
Thanks,
Nick
---
@@ -1898,9 +1898,21 @@ static int fill_note_info(struct elfhdr *elf, int phdrs,/**Nowfillineachthread'sinformation.*/-for(t=info->thread;t!=NULL;t=t->next)+for(t=info->thread;t!=NULL;t=t->next){+if(!t->task){+WARN_ON(1);+printk("core info lost task\n");+continue;+}+if(!t->task->thread.regs){+WARN_ON(1);+printk("lost regs pid:%d (current->pid:%d)\n",t->task->pid,current->pid);+continue;+}+if(!fill_thread_core_info(t,view,cprm->siginfo->si_signo,info))return0;+}/**Fillinthetwoprocess-widenotes.
--- Comment #7 from Zorro Lang (zlang@redhat.com) ---
(In reply to Michael Ellerman from comment #5)
quoted
Sorry I don't have any idea which commit could have fixed this.
The process that crashed was "fsstress", do you know if it uses io_uring?
Yes, fsstress has io_uring read/write operations. And from the kernel .config
file(as attachment), the CONFIG_IO_URING=y
The task being dumped seems like it's lost its task->thread.regs. The
NULL pointer is here:
int tm_cgpr_active(struct task_struct *target, const struct user_regset
*regset)
{
if (!cpu_has_feature(CPU_FTR_TM))
return -ENODEV;
if (!MSR_TM_ACTIVE(target->thread.regs->msr))
return 0;
return regset->n;
}
On that regs->msr deref. r9 contains the regs pointer.
The kernel attempt to read user page - exploit attempt? message is
I think a red herring it's coming up because of the NULL deref I
think (I thought we fixed that).
Anyway I'm not sure how we could lose regs, all user threads should
have them set to non-NULL. It doesn't look like we can collect threads
for dumping before we have called copy_thread(), which is where they
get thread.regs set. AFAIK it's not supposed to change after that.
Would you be able to try this patch, hopefully it catches the problem
thread on the exit side, and gives a clue why regs is NULL.
Thanks,
Nick
---
@@ -1898,9 +1898,21 @@ static int fill_note_info(struct elfhdr *elf, int phdrs,/**Nowfillineachthread'sinformation.*/-for(t=info->thread;t!=NULL;t=t->next)+for(t=info->thread;t!=NULL;t=t->next){+if(!t->task){+WARN_ON(1);+printk("core info lost task\n");+continue;+}+if(!t->task->thread.regs){+WARN_ON(1);+printk("lost regs pid:%d (current->pid:%d)\n",
t->task->pid, current->pid);
+ continue;
+ }
+
if (!fill_thread_core_info(t, view, cprm->siginfo->si_signo,
info))
return 0;
+ }
/*
* Fill in the two process-wide notes.
--- Comment #9 from Michael Ellerman (michael@ellerman.id.au) ---
I assume it's an io_uring IO worker.
They're created via create_io_worker() -> create_io_thread().
They pass a non-NULL `args->fn` to copy_process() -> copy_thread(), so we end
up in the "kernel thread" branch of the if, which sets p->thread.regs = NULL.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
--- Comment #9 from Michael Ellerman (michael@ellerman.id.au) ---
I assume it's an io_uring IO worker.
They're created via create_io_worker() -> create_io_thread().
They pass a non-NULL `args->fn` to copy_process() -> copy_thread(), so we end
up in the "kernel thread" branch of the if, which sets p->thread.regs = NULL.
Hmm, you might be right. These things are created with the memory and
thread / signal context shared with the userspace process.
Still doesn't seem like they should be involved in core dumping though,
pt_regs would have no meaning even if we did set something there. How
best to catch these and filter them out of the core dump? Check for
PF_IO_WORKER in the coredump gathering?
Thanks,
Nick
--- Comment #9 from Michael Ellerman (michael@ellerman.id.au) ---
I assume it's an io_uring IO worker.
They're created via create_io_worker() -> create_io_thread().
They pass a non-NULL `args->fn` to copy_process() -> copy_thread(), so we end
up in the "kernel thread" branch of the if, which sets p->thread.regs = NULL.
Hmm, you might be right. These things are created with the memory and
thread / signal context shared with the userspace process.
Still doesn't seem like they should be involved in core dumping though,
pt_regs would have no meaning even if we did set something there. How
best to catch these and filter them out of the core dump? Check for
PF_IO_WORKER in the coredump gathering?
Thanks,
Nick
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
--- Comment #7 from Zorro Lang (zlang@redhat.com) ---
(In reply to Michael Ellerman from comment #5)
quoted
Sorry I don't have any idea which commit could have fixed this.
The process that crashed was "fsstress", do you know if it uses io_uring?
Yes, fsstress has io_uring read/write operations. And from the kernel
.config
file(as attachment), the CONFIG_IO_URING=y
The task being dumped seems like it's lost its task->thread.regs. The
NULL pointer is here:
int tm_cgpr_active(struct task_struct *target, const struct user_regset
*regset)
{
if (!cpu_has_feature(CPU_FTR_TM))
return -ENODEV;
if (!MSR_TM_ACTIVE(target->thread.regs->msr))
return 0;
return regset->n;
}
On that regs->msr deref. r9 contains the regs pointer.
The kernel attempt to read user page - exploit attempt? message is
I think a red herring it's coming up because of the NULL deref I
think (I thought we fixed that).
No we didn't fix that, my patch was rejected see
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/8b865b93d25c15c8e6d41e71c368bfc28da4489d.1606816701.git.christophe.leroy@csgroup.eu/
The reason for the rejection was:
The first page can be mapped if mmap_min_addr is 0.
Blocking all faults to the first page would potentially break any
program that does that.
Also if there is something mapped at 0 it's a good chance it is an
exploit attempt :)
Christophe
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
--- Comment #7 from Zorro Lang (zlang@redhat.com) ---
(In reply to Michael Ellerman from comment #5)
quoted
Sorry I don't have any idea which commit could have fixed this.
The process that crashed was "fsstress", do you know if it uses io_uring?
Yes, fsstress has io_uring read/write operations. And from the kernel .config
file(as attachment), the CONFIG_IO_URING=y
The task being dumped seems like it's lost its task->thread.regs. The
NULL pointer is here:
int tm_cgpr_active(struct task_struct *target, const struct user_regset *regset)
{
if (!cpu_has_feature(CPU_FTR_TM))
return -ENODEV;
if (!MSR_TM_ACTIVE(target->thread.regs->msr))
return 0;
return regset->n;
}
On that regs->msr deref. r9 contains the regs pointer.
The kernel attempt to read user page - exploit attempt? message is
I think a red herring it's coming up because of the NULL deref I
think (I thought we fixed that).