bris...@redhat.com; x...@kernel.org; linux...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-hyp...@vger.kernel.org; Michael Kelley
>
> Subject: Re: v5.10: sched_cpu_dying() hits BUG_ON during hibernation: kernel
> BUG at kernel/sched/core.c:7596!
>
>
> Hi,
>
Hi,
On 22/12/20 09:13, Dexuan Cui wrote:
> Hi,
> I'm running a Linux VM with the recent mainline (48342fc07272, 12/20/2020) on
> Hyper-V.
> When I test hibernation, the VM can easily hit the below BUG_ON during the
> resume
> procedure (I estimate this can repro about 1/5 of the time). BTW,
71224] smpboot: CPU 37 is now offline
[ 11.795089] [ cut here ]----
[ 11.798052] kernel BUG at kernel/sched/core.c:7596!
[ 11.798052] invalid opcode: [#1] PREEMPT SMP PTI
[ 11.798052] CPU: 38 PID: 202 Comm: migration/38 Tainted: GE
5.10.0+ #6
[ 11.79
Jann Horn writes:
> On Mon, Nov 23, 2020 at 2:45 PM Arnd Bergmann wrote:
>> On Mon, Nov 23, 2020 at 12:15 PM Naresh Kamboju
>> wrote:
>> >
>> > While booting arm64 kernel the following kernel BUG noticed on several
>> > arm64
>>
On Mon, Nov 23, 2020 at 2:45 PM Arnd Bergmann wrote:
> On Mon, Nov 23, 2020 at 12:15 PM Naresh Kamboju
> wrote:
> >
> > While booting arm64 kernel the following kernel BUG noticed on several arm64
> > devices running linux next 20201123 tag kernel.
> >
> >
&
On Mon, Nov 23, 2020 at 12:15 PM Naresh Kamboju
wrote:
>
> While booting arm64 kernel the following kernel BUG noticed on several arm64
> devices running linux next 20201123 tag kernel.
>
>
> $ git log --oneline next-20201120..next-20201123 -- kernel/seccomp.c
> 5c5c5fa055ea
While booting arm64 kernel the following kernel BUG noticed on several arm64
devices running linux next 20201123 tag kernel.
$ git log --oneline next-20201120..next-20201123 -- kernel/seccomp.c
5c5c5fa055ea Merge remote-tracking branch 'seccomp/for-next/seccomp'
bce6a8cba7bf Merge branch 'linus
false;
err = ppp_dev_configure(src_net, dev, );
out_unlock:
mutex_unlock(_mutex);
out:
fput(file);
return err;
}
Need people that under stand this part of kernel code.
> On 1 Sep 2020, at 22:36, Martin Zaharinov wrote:
>
> HI all kernel team
>
> We
HI all kernel team
We detect bug in kernel with pppd server
When disconnect and connect 1000+ users after many time kernel have lock
please see debug log :
Aug 30 05:34:55 10.20.22.1 [139221.203949][ T817] INFO: task pppd:6009 blocked
for more than 122 seconds.
Aug 30 05:34:55 10.20.22.1
>
> commit 991e7673859ed41e7ba83c8c4e57afe8cfebe314
> Author: Shakeel Butt
> Date: Thu Aug 6 23:21:37 2020 -0700
>
> mm: memcontrol: account kernel stack per node
>
>
> since the BUG_ON() at line 390 is removed by this patch.
>
It's not really removed. T
l stack per node
since the BUG_ON() at line 390 is removed by this patch.
> ----[ cut here ]
> kernel BUG at kernel/fork.c:390!
> invalid opcode: [#1] PREEMPT SMP KASAN
> CPU: 0 PID: 5239 Comm: syz-executor.1 Not tainted 5.8.0-syzkaller #0
> Hardware na
...@syzkaller.appspotmail.com
[ cut here ]
kernel BUG at kernel/fork.c:390!
invalid opcode: [#1] PREEMPT SMP KASAN
CPU: 0 PID: 5239 Comm: syz-executor.1 Not tainted 5.8.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01
On 20/07/20 15:21, Peter Zijlstra wrote:
> On Mon, Jul 20, 2020 at 04:02:24PM +0200, Oleg Nesterov wrote:
>> I have to admit, I do not understand the usage of prev_state in schedule(),
>> it looks really, really subtle...
>
> Right, so commit dbfb089d360 solved a problem where schedule() re-read
On Tue, Jul 21, 2020 at 12:52:52AM -0400, Paul Gortmaker wrote:
> [Re: 5.8-rc*: kernel BUG at kernel/signal.c:1917] On 20/07/2020 (Mon 16:21)
> Peter Zijlstra wrote:
>
> > On Mon, Jul 20, 2020 at 04:02:24PM +0200, Oleg Nesterov wrote:
> > > I have to admit, I do
[Re: 5.8-rc*: kernel BUG at kernel/signal.c:1917] On 20/07/2020 (Mon 16:21)
Peter Zijlstra wrote:
> On Mon, Jul 20, 2020 at 04:02:24PM +0200, Oleg Nesterov wrote:
> > I have to admit, I do not understand the usage of prev_state in schedule(),
> > it looks really, really subtle...
On Mon, Jul 20, 2020 at 05:35:15PM +0200, Oleg Nesterov wrote:
> On 07/20, Oleg Nesterov wrote:
> >
> > On 07/20, Peter Zijlstra wrote:
> > >
> > > --- a/kernel/sched/core.c
> > > +++ b/kernel/sched/core.c
> > > @@ -4193,9 +4193,6 @@ static void __sched notrace __schedule(bool preempt)
> > >
On 07/20, Oleg Nesterov wrote:
>
> On 07/20, Peter Zijlstra wrote:
> >
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -4193,9 +4193,6 @@ static void __sched notrace __schedule(bool preempt)
> > local_irq_disable();
> > rcu_note_context_switch(preempt);
> >
> > - /*
On 07/20, Peter Zijlstra wrote:
>
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4193,9 +4193,6 @@ static void __sched notrace __schedule(bool preempt)
> local_irq_disable();
> rcu_note_context_switch(preempt);
>
> - /* See deactivate_task() below. */
> -
On 20/07/20 14:17, pet...@infradead.org wrote:
> On Mon, Jul 20, 2020 at 01:20:26PM +0100, Valentin Schneider wrote:
>> On 20/07/20 12:26, pet...@infradead.org wrote:
>
>> > + /*
>> > + * We must re-load prev->state in case ttwu_remote() changed it
>> > + * before we acquired rq->lock.
>> >
On Mon, Jul 20, 2020 at 04:02:24PM +0200, Oleg Nesterov wrote:
> I have to admit, I do not understand the usage of prev_state in schedule(),
> it looks really, really subtle...
Right, so commit dbfb089d360 solved a problem where schedule() re-read
prev->state vs prev->on_rq = 0. That is,
On Mon, Jul 20, 2020 at 01:26:23PM +0200, pet...@infradead.org wrote:
> kernel/sched/core.c | 34 --
> 1 file changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index e15543cb84812..b5973d7fa521c 100644
> ---
On 07/20, Peter Zijlstra wrote:
>
> Also, is there any way to not have ptrace do this?
Well, we need to ensure that even SIGKILL can't wake the tracee up while
debugger plays with its registers/etc.
> How performance
> critical is this ptrace path?
This is a slow path.
We can probably change
On Mon, Jul 20, 2020 at 01:20:26PM +0100, Valentin Schneider wrote:
> On 20/07/20 12:26, pet...@infradead.org wrote:
> > + /*
> > +* We must re-load prev->state in case ttwu_remote() changed it
> > +* before we acquired rq->lock.
> > +*/
> > + tmp_state = prev->state;
> > + if
On Mon, Jul 20, 2020 at 01:26:23PM +0200, pet...@infradead.org wrote:
> On Mon, Jul 20, 2020 at 12:59:24PM +0200, pet...@infradead.org wrote:
> > On Mon, Jul 20, 2020 at 10:41:06AM +0200, Peter Zijlstra wrote:
> > > On Mon, Jul 20, 2020 at 10:26:58AM +0200, Oleg Nesterov wrote:
> > > > Peter,
> >
On 20/07/20 12:26, pet...@infradead.org wrote:
> ---
> kernel/sched/core.c | 34 --
> 1 file changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index e15543cb84812..b5973d7fa521c 100644
> ---
On 20. 07. 20, 13:26, pet...@infradead.org wrote:
> On Mon, Jul 20, 2020 at 12:59:24PM +0200, pet...@infradead.org wrote:
>> On Mon, Jul 20, 2020 at 10:41:06AM +0200, Peter Zijlstra wrote:
>>> On Mon, Jul 20, 2020 at 10:26:58AM +0200, Oleg Nesterov wrote:
Peter,
Let me add another
On Mon, Jul 20, 2020 at 12:59:24PM +0200, pet...@infradead.org wrote:
> On Mon, Jul 20, 2020 at 10:41:06AM +0200, Peter Zijlstra wrote:
> > On Mon, Jul 20, 2020 at 10:26:58AM +0200, Oleg Nesterov wrote:
> > > Peter,
> > >
> > > Let me add another note. TASK_TRACED/TASK_STOPPED was always
On Mon, Jul 20, 2020 at 10:41:06AM +0200, Peter Zijlstra wrote:
> On Mon, Jul 20, 2020 at 10:26:58AM +0200, Oleg Nesterov wrote:
> > Peter,
> >
> > Let me add another note. TASK_TRACED/TASK_STOPPED was always protected by
> > ->siglock. In particular, ttwu(__TASK_TRACED) must be always called
On Mon, Jul 20, 2020 at 10:26:58AM +0200, Oleg Nesterov wrote:
> Peter,
>
> Let me add another note. TASK_TRACED/TASK_STOPPED was always protected by
> ->siglock. In particular, ttwu(__TASK_TRACED) must be always called with
> ->siglock held. That is why ptrace_freeze_traced() assumes it can
Peter,
Let me add another note. TASK_TRACED/TASK_STOPPED was always protected by
->siglock. In particular, ttwu(__TASK_TRACED) must be always called with
->siglock held. That is why ptrace_freeze_traced() assumes it can safely
do s/TASK_TRACED/__TASK_TRACED/ under spin_lock(siglock).
Can this
On 07/20, Jiri Slaby wrote:
>
> On 18. 07. 20, 19:14, Oleg Nesterov wrote:
> >
> > This is already wrong. But
> >
> > Where does this __might_sleep() come from ??? I ses no blocking calls
> > in ptrace_stop(). Not to mention it is called with ->siglock held and
> > right after this
On 07/20, Jiri Slaby wrote:
>
> You tackled it, we cherry-picked dbfb089d360 to our kernels. Ccing more
> people.
Thanks... so with this patch __schedule() does
prev_state = prev->state;
...
if (!preempt && prev_state && prev_state == prev->state) {
if
On 18. 07. 20, 19:14, Oleg Nesterov wrote:
> On 07/18, Jiri Slaby wrote:
>>
>> On 17. 07. 20, 14:40, Oleg Nesterov wrote:
>>>
>>> please see the updated patch below, lets check ptrace_unfreeze() too.
>>
>> Sure, dmesg attached.
>
> Thanks a lot!
>
> But I am totally confused...
>
>> [
On 18. 07. 20, 19:44, Christian Brauner wrote:
> On Sat, Jul 18, 2020 at 07:14:07PM +0200, Oleg Nesterov wrote:
>> On 07/18, Jiri Slaby wrote:
>>>
>>> On 17. 07. 20, 14:40, Oleg Nesterov wrote:
please see the updated patch below, lets check ptrace_unfreeze() too.
>>>
>>> Sure, dmesg
Hi Hillf,
On 07/19, Hillf Danton wrote:
>
> Dunno if the wheel prior to JOBCTL_TASK_WORK helps debug the warnings.
>
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -2541,7 +2541,7 @@ bool get_signal(struct ksignal *ksig)
>
> relock:
> spin_lock_irq(>siglock);
> - current->jobctl
On Sat, Jul 18, 2020 at 07:14:07PM +0200, Oleg Nesterov wrote:
> On 07/18, Jiri Slaby wrote:
> >
> > On 17. 07. 20, 14:40, Oleg Nesterov wrote:
> > >
> > > please see the updated patch below, lets check ptrace_unfreeze() too.
> >
> > Sure, dmesg attached.
>
> Thanks a lot!
>
> But I am totally
On 07/18, Jiri Slaby wrote:
>
> On 17. 07. 20, 14:40, Oleg Nesterov wrote:
> >
> > please see the updated patch below, lets check ptrace_unfreeze() too.
>
> Sure, dmesg attached.
Thanks a lot!
But I am totally confused...
> [ 94.513944] [ cut here ]
> [ 94.513985] do
On 17. 07. 20, 13:12, Christian Brauner wrote:
> On Fri, Jul 17, 2020 at 01:04:38PM +0200, Jiri Slaby wrote:
>> On 17. 07. 20, 12:45, Jiri Slaby wrote:
>>> Hi,
>>>
>>> the strace testsuite triggers this on 5.8-rc4 and -rc5 both on x86_64
>>> and i586:
>>
>> make check needs -jsomething, running is
On 17. 07. 20, 14:40, Oleg Nesterov wrote:
> On 07/17, Oleg Nesterov wrote:
>>
>> On 07/17, Jiri Slaby wrote:
>>>
>>> On 17. 07. 20, 12:45, Jiri Slaby wrote:
Hi,
the strace testsuite triggers this on 5.8-rc4 and -rc5 both on x86_64
and i586:
>>>
>>> make check needs
On 07/17, Oleg Nesterov wrote:
>
> On 07/17, Jiri Slaby wrote:
> >
> > On 17. 07. 20, 12:45, Jiri Slaby wrote:
> > > Hi,
> > >
> > > the strace testsuite triggers this on 5.8-rc4 and -rc5 both on x86_64
> > > and i586:
> >
> > make check needs -jsomething, running is sequentially (-j1) doesn't
> >
On 07/17, Jiri Slaby wrote:
>
> On 17. 07. 20, 12:45, Jiri Slaby wrote:
> > Hi,
> >
> > the strace testsuite triggers this on 5.8-rc4 and -rc5 both on x86_64
> > and i586:
>
> make check needs -jsomething, running is sequentially (-j1) doesn't
> trigger it. After the error, I cannot run anything.
On Fri, Jul 17, 2020 at 01:04:38PM +0200, Jiri Slaby wrote:
> On 17. 07. 20, 12:45, Jiri Slaby wrote:
> > Hi,
> >
> > the strace testsuite triggers this on 5.8-rc4 and -rc5 both on x86_64
> > and i586:
>
> make check needs -jsomething, running is sequentially (-j1) doesn't
> trigger it. After
test caused the crash...
5.7 was fine.
>> kernel BUG at kernel/signal.c:1917!
>> invalid opcode: [#1] SMP NOPTI
>> CPU: 7 PID: 18367 Comm: filter-unavaila Not tainted
>> 5.8.0-rc4-3.g2cd7849-default #1 openSUSE Tumbleweed (unreleased)
>> Hardware name: QEMU Stand
Hi,
the strace testsuite triggers this on 5.8-rc4 and -rc5 both on x86_64
and i586:
> kernel BUG at kernel/signal.c:1917!
> invalid opcode: [#1] SMP NOPTI
> CPU: 7 PID: 18367 Comm: filter-unavaila Not tainted
> 5.8.0-rc4-3.g2cd7849-default #1 openSUSE Tumbleweed (unreleased
Hi, Thomas
I canceled that patch. In my testing, that will not fix the problem.
Why the IRQ is unexpectedly masked, that is not an easy bug for me.
More time need to hacking the driver/kernel code.
Thanks for your reply.
Thomas Gleixner 于2019年10月14日周一 下午8:34写道：
>
> On Tue, 8 Oct 2019, Yi Zheng
On Tue, 8 Oct 2019, Yi Zheng wrote:
> There is some defects on IRQ processing:
>
> (1) At the beginning of handle_level_irq(), the IRQ-28 is masked, and ACK
> action is executed: On my machine, it runs the 'else' branch:
>
> static inline void mask_ack_irq(struct
* Yi Zheng [191010 06:22]:
> Hi
>
>My patch is canceled. I have tested that simple adjustment, the
> device IRQ masked unexpectedly. It seems that it is more easily to
> occur with that patch.
>
> So, the root cause is not found yet.
OK. Based on your description, it could be a missing
Hi
My patch is canceled. I have tested that simple adjustment, the
device IRQ masked unexpectedly. It seems that it is more easily to
occur with that patch.
So, the root cause is not found yet.
Hi,
* Yi Zheng [191008 13:06]:
> NOTE: (1) My SoC is a single core ARM chip: TI-AM3352, so the raw
> spin-lock irq_desc->lock will be optimized to
> nothing. handle_level_irq() has no spin-lock protection, right?
Well not always, With CONFIG_SMP we modify only some of
Hi,
I found something wrong on my AM3352 SoC machine, the GPIO triggered IRQ is
masked unexpectedly. That bug cause the devices using that GPIO-IRQ can
not work. Even the latest kernel version (v5.4-rc2-20-geda57a0e4299)!
After a long time hacking, I guess the bug
Hi,
I found something wrong on my AM3352 SoC machine, the GPIO
triggered IRQ is masked
unexpectedly. That bug cause the devices using that GPIO-IRQ can
not work. Even the
latest kernel version (v5.4-rc2-20-geda57a0e4299)!
After a long time hacking, I guess the bug
to the commit:
Reported-by: syzbot+f49d12d34f2321cf4...@syzkaller.appspotmail.com
[ cut here ]
kernel BUG at kernel/time/timer.c:956!
invalid opcode: [#1] SMP KASAN
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.0-rc1+ #0
Hardware name: Google Google Compute Engine/Google
On 2019-09-09 15:47, risha...@codeaurora.org wrote:
Hi Miklos
In 4.19 kernel when we write to a file that doesn't exist we see the
following stack:
[ 377.382745] ovl_create_or_link+0xac/0x710
[ 377.382745] ovl_create_object+0xb8/0x110
[ 377.382745] ovl_create+0x34/0x40
[ 377.382745]
Hi Miklos
In 4.19 kernel when we write to a file that doesn't exist we see the
following stack:
[ 377.382745] ovl_create_or_link+0xac/0x710
[ 377.382745] ovl_create_object+0xb8/0x110
[ 377.382745] ovl_create+0x34/0x40
[ 377.382745] path_openat+0xd44/0x15a8
[ 377.382745]
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 1 of them as possibly being a bug in the "kernel/c
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 1 of them as possibly being a bug in the "kernel/c
On Tue, Apr 23, 2019 at 12:08 AM Yang Yingliang
wrote:
> On 2019/4/23 3:48, Paul Moore wrote:
> > On Sat, Apr 20, 2019 at 3:39 AM Yang Yingliang
> > wrote:
> >> I'm not sure you got my point.
> > I went back and looked at your previous emails again to try and
> > understand what you are talking
On 2019/4/23 3:48, Paul Moore wrote:
On Sat, Apr 20, 2019 at 3:39 AM Yang Yingliang wrote:
I'm not sure you got my point.
I went back and looked at your previous emails again to try and
understand what you are talking about, and I'm a little confused by
some of the output ...
---
his again? Looking at the task
pointer and the timestamp, this is the same task exiting and trying to
write to the accounting file, yes? This output is particularly
curious since it appears that real_cred has changed; where is this
happening?
> [ 56.653565] [ cut here ]-
On 2019/4/20 0:13, Paul Moore wrote:
On Fri, Apr 19, 2019 at 10:34 AM Yang Yingliang
wrote:
On 2019/4/19 21:24, Paul Moore wrote:
On Thu, Apr 18, 2019 at 10:42 PM Yang Yingliang
wrote:
On 2019/4/19 10:04, Paul Moore wrote:
On Wed, Apr 17, 2019 at 10:50 PM Yang Yingliang
wrote:
On
On Thu, Apr 18, 2019 at 10:42 PM Yang Yingliang
wrote:
> On 2019/4/19 10:04, Paul Moore wrote:
> > On Wed, Apr 17, 2019 at 10:50 PM Yang Yingliang
> > wrote:
> >> On 2019/4/18 8:24, Casey Schaufler wrote:
> >>> On 4/17/2019 4:39 PM, Paul Moore wrote:
> Since it looks like all three LSMs
On Fri, Apr 19, 2019 at 10:34 AM Yang Yingliang
wrote:
> On 2019/4/19 21:24, Paul Moore wrote:
> > On Thu, Apr 18, 2019 at 10:42 PM Yang Yingliang
> > wrote:
> >> On 2019/4/19 10:04, Paul Moore wrote:
> >>> On Wed, Apr 17, 2019 at 10:50 PM Yang Yingliang
> >>> wrote:
> On 2019/4/18 8:24,
f88841ae450c0
[ 56.653565] --------[ cut here ]
[ 56.655119] kernel BUG at kernel/cred.c:434!
[ 56.656590] invalid opcode: [#1] SMP PTI
[ 56.658033] CPU: 2 PID: 4169 Comm: syz-executor.15 Not tainted
5.1.0-rc4-00034-g869e3305f23d-dirty #143
[ 56.661077] Hardware name: QEMU S
On 2019/4/19 10:04, Paul Moore wrote:
On Wed, Apr 17, 2019 at 10:50 PM Yang Yingliang
wrote:
On 2019/4/18 8:24, Casey Schaufler wrote:
On 4/17/2019 4:39 PM, Paul Moore wrote:
Since it looks like all three LSMs which implement the setprocattr
hook are vulnerable I'm open to the idea that
On Wed, Apr 17, 2019 at 10:50 PM Yang Yingliang
wrote:
> On 2019/4/18 8:24, Casey Schaufler wrote:
> > On 4/17/2019 4:39 PM, Paul Moore wrote:
> >>
> >> Since it looks like all three LSMs which implement the setprocattr
> >> hook are vulnerable I'm open to the idea that proc_pid_attr_write() is
>
On 4/17/19 12:42 PM, Casey Schaufler wrote:
On 4/17/2019 9:27 AM, Oleg Nesterov wrote:
On 04/17, Paul Moore wrote:
On Wed, Apr 17, 2019 at 10:57 AM Oleg Nesterov wrote:
On 04/17, Paul Moore wrote:
I'm tempted to simply return an error in selinux_setprocattr() if
the task's credentials are
Hi, Casey
On 2019/4/18 8:24, Casey Schaufler wrote:
On 4/17/2019 4:39 PM, Paul Moore wrote:
On Wed, Apr 17, 2019 at 12:27 PM Oleg Nesterov wrote:
On 04/17, Paul Moore wrote:
On Wed, Apr 17, 2019 at 10:57 AM Oleg Nesterov
wrote:
On 04/17, Paul Moore wrote:
I'm tempted to simply return an
On 4/17/2019 4:39 PM, Paul Moore wrote:
On Wed, Apr 17, 2019 at 12:27 PM Oleg Nesterov wrote:
On 04/17, Paul Moore wrote:
On Wed, Apr 17, 2019 at 10:57 AM Oleg Nesterov wrote:
On 04/17, Paul Moore wrote:
I'm tempted to simply return an error in selinux_setprocattr() if
the task's
On 4/17/19 4:39 PM, Paul Moore wrote:
> On Wed, Apr 17, 2019 at 12:27 PM Oleg Nesterov wrote:
>> On 04/17, Paul Moore wrote:
>>>
>>> On Wed, Apr 17, 2019 at 10:57 AM Oleg Nesterov wrote:
On 04/17, Paul Moore wrote:
>
> I'm tempted to simply return an error in selinux_setprocattr()
On Wed, Apr 17, 2019 at 12:27 PM Oleg Nesterov wrote:
> On 04/17, Paul Moore wrote:
> >
> > On Wed, Apr 17, 2019 at 10:57 AM Oleg Nesterov wrote:
> > > On 04/17, Paul Moore wrote:
> > > >
> > > > I'm tempted to simply return an error in selinux_setprocattr() if
> > > > the task's credentials are
On 4/17/2019 9:27 AM, Oleg Nesterov wrote:
On 04/17, Paul Moore wrote:
On Wed, Apr 17, 2019 at 10:57 AM Oleg Nesterov wrote:
On 04/17, Paul Moore wrote:
I'm tempted to simply return an error in selinux_setprocattr() if
the task's credentials are not the same as its real_cred;
What about
On 04/17, Paul Moore wrote:
>
> On Wed, Apr 17, 2019 at 10:57 AM Oleg Nesterov wrote:
> > On 04/17, Paul Moore wrote:
> > >
> > > I'm tempted to simply return an error in selinux_setprocattr() if
> > > the task's credentials are not the same as its real_cred;
> >
> > What about other modules? I
On Wed, Apr 17, 2019 at 10:57 AM Oleg Nesterov wrote:
> On 04/17, Paul Moore wrote:
> >
> > I'm tempted to simply return an error in selinux_setprocattr() if
> > the task's credentials are not the same as its real_cred;
>
> What about other modules? I have no idea what smack_setprocattr() is,
>
On 4/17/2019 7:57 AM, Oleg Nesterov wrote:
On 04/17, Paul Moore wrote:
I'm tempted to simply return an error in selinux_setprocattr() if
the task's credentials are not the same as its real_cred;
What about other modules? I have no idea what smack_setprocattr() is,
but it too does
On 04/17, Paul Moore wrote:
>
> I'm tempted to simply return an error in selinux_setprocattr() if
> the task's credentials are not the same as its real_cred;
What about other modules? I have no idea what smack_setprocattr() is,
but it too does prepare_creds/commit creds.
it seems that the
On Tue, Apr 16, 2019 at 10:46 AM chengjian (D) wrote:
> On 2019/4/16 11:40, Kees Cook wrote:
> > On Mon, Apr 15, 2019 at 11:20 AM Paul Moore wrote:
> >> On Mon, Apr 15, 2019 at 11:05 AM Oleg Nesterov wrote:
> >>> On 04/15, Paul Moore wrote:
> On Mon, Apr 15, 2019 at 9:43 AM Oleg Nesterov
On 2019/4/16 11:40, Kees Cook wrote:
On Mon, Apr 15, 2019 at 11:20 AM Paul Moore wrote:
On Mon, Apr 15, 2019 at 11:05 AM Oleg Nesterov wrote:
On 04/15, Paul Moore wrote:
On Mon, Apr 15, 2019 at 9:43 AM Oleg Nesterov wrote:
Well, acct("/proc/self/attr/current") doesn't look like a good
On Mon, Apr 15, 2019 at 11:20 AM Paul Moore wrote:
>
> On Mon, Apr 15, 2019 at 11:05 AM Oleg Nesterov wrote:
> > On 04/15, Paul Moore wrote:
> > >
> > > On Mon, Apr 15, 2019 at 9:43 AM Oleg Nesterov wrote:
> > > > Well, acct("/proc/self/attr/current") doesn't look like a good idea,
> > > > but
On Mon, Apr 15, 2019 at 11:05 AM Oleg Nesterov wrote:
> On 04/15, Paul Moore wrote:
> >
> > On Mon, Apr 15, 2019 at 9:43 AM Oleg Nesterov wrote:
> > > Well, acct("/proc/self/attr/current") doesn't look like a good idea, but
> > > I do
> > > not know where should we put the additional check...
On 04/15, Paul Moore wrote:
>
> On Mon, Apr 15, 2019 at 9:43 AM Oleg Nesterov wrote:
> > Well, acct("/proc/self/attr/current") doesn't look like a good idea, but I
> > do
> > not know where should we put the additional check... And probably
> > "echo /proc/self/attr/current >
PM, chengjian (D) wrote:
> >
> > Added LSM and SELinux lists.
> >
> >
> > >Hi.
> > >
> > >
> > >syzkaller reported the following BUG:
> > >
> > >[ 73.146973] kernel BUG at kernel/cred.c:434!
> > >[
t;Hi.
> >
> >
> >syzkaller reported the following BUG:
> >
> >[ 73.146973] kernel BUG at kernel/cred.c:434!
> >[ 73.150231] invalid opcode: [#1] SMP KASAN PTI
> >[ 73.151928] CPU: 2 PID: 4058 Comm: syz-executor.6 Not tainted
> >5.1.0-rc4-00062-g2d06b
On 4/11/2019 11:21 PM, chengjian (D) wrote:
Added LSM and SELinux lists.
Hi.
syzkaller reported the following BUG:
[ 73.146973] kernel BUG at kernel/cred.c:434!
[ 73.150231] invalid opcode: [#1] SMP KASAN PTI
[ 73.151928] CPU: 2 PID: 4058 Comm: syz-executor.6 Not tainted
5.1.0
Hi.
syzkaller reported the following BUG:
[ 73.146973] kernel BUG at kernel/cred.c:434!
[ 73.150231] invalid opcode: [#1] SMP KASAN PTI
[ 73.151928] CPU: 2 PID: 4058 Comm: syz-executor.6 Not tainted
5.1.0-rc4-00062-g2d06b235815e-dirty #2
[ 73.155174] Hardware name: QEMU Standard
The kernel module is loaded into vmalloc region which is located below
to the PAGE_OFFSET. Hence the condition, pc < PAGE_OFFSET, in the
is_valid_bugaddr() will filter out all trap exceptions triggered
by kernel module. To support BUG() in kernel module, the condition is
changed to
The kernel module is loaded into vmalloc region which is located below
to the PAGE_OFFSET. Hence the condition, pc < PAGE_OFFSET, in the
is_valid_bugaddr() will filter out all trap exceptions triggered
by kernel module. To support BUG() in kernel module, the condition is
changed to
.006927] CRED: ->usage=1, subscr=0
> [ 54.006935] CRED: ->*uid = { 0,0,0,0 }
> [ 54.006944] CRED: ->*gid = { 0,0,0,0 }
> [ 54.006954] ----[ cut here ]----
> [ 54.006964] kernel BUG at kernel/cred.c:825!
>
Fedora
On Thu, Jan 17, 2019 at 06:26:58PM +0800, Ming Lei wrote:
> On Wed, Jan 16, 2019 at 09:54:05AM +0100, Krzysztof Kozlowski wrote:
> > On Wed, 16 Jan 2019 at 09:52, Krzysztof Kozlowski wrote:
> > >
> > > Hi,
> > >
> > > On today's next-20190116 I see a
On Wed, Jan 16, 2019 at 09:54:05AM +0100, Krzysztof Kozlowski wrote:
> On Wed, 16 Jan 2019 at 09:52, Krzysztof Kozlowski wrote:
> >
> > Hi,
> >
> > On today's next-20190116 I see a bug during boot:
> > [ 6.843308] kernel BUG at ../block/bio.c:1833!
> > [
--[ cut here ]
[ 54.006964] kernel BUG at kernel/cred.c:825!
[ 54.006977] invalid opcode: [#1] SMP RIP: __invalid_creds+0x48/0x50
[ 54.006987] CPU: 2 PID: 814 Comm: mount.nfs Tainted: GW
5.0.0-rc1-backup+ #1
[ 54.006997] Hardware name: ASUS All Series/Z97-DELUXE, BIOS 260
On 01/12, Kohli, Gaurav wrote:
>
> HI Peter, Oleg,
>
> as per flag and state this seems to be possible only from below code:
Not sure I understand you,
> XXX: 0 1 0x40844c
> PF_NOFREEZE
> PF_RANDOMIZE
> PF_SIGNALED
> PF_FORKNOEXEC
> PF_EXITING
> PF_EXITPIDONE
>
> above state shows do_exit runs
On Wed, 16 Jan 2019 at 09:52, Krzysztof Kozlowski wrote:
>
> Hi,
>
> On today's next-20190116 I see a bug during boot:
> [ 6.843308] kernel BUG at ../block/bio.c:1833!
> [ 6.847723] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
> ...
> [ 7.543824] [] (bio_split) f
Hi,
On today's next-20190116 I see a bug during boot:
[ 6.843308] kernel BUG at ../block/bio.c:1833!
[ 6.847723] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
...
[ 7.543824] [] (bio_split) from [<>] ( (null))
[ 7.549881] Code: 13833b01 11c630bc e1a6 e8bd8070 (e7
HI Peter, Oleg,
as per flag and state this seems to be possible only from below code:
XXX: 0 1 0x40844c
PF_NOFREEZE
PF_RANDOMIZE
PF_SIGNALED
PF_FORKNOEXEC
PF_EXITING
PF_EXITPIDONE
above state shows do_exit runs properely and if somehow after parked
stated , TASK_WAKEKILL got set and
On Fri, 2019-01-11 at 16:07 +0530, Kohli, Gaurav wrote:
>
> On 1/7/2019 11:26 PM, Oleg Nesterov wrote:
> > pr_crit("XXX: %ld %d\n", current->state, current->on_rq);
>
> Can we also add flags, this may help to know the path of problem:
>
> pr_crit("XXX: %ld %d 0x%x\n", current->state,
On 1/7/2019 11:26 PM, Oleg Nesterov wrote:
pr_crit("XXX: %ld %d\n", current->state, current->on_rq);
Can we also add flags, this may help to know the path of problem:
pr_crit("XXX: %ld %d 0x%x\n", current->state, current->on_rq,
current->flags);
--
Qualcomm India Private Limited, on
: 5daa4529
[ 54.006916] CRED: ->magic=0, put_addr= (null)
[ 54.006927] CRED: ->usage=1, subscr=0
[ 54.006935] CRED: ->*uid = { 0,0,0,0 }
[ 54.006944] CRED: ->*gid = { 0,0,0,0 }
[ 54.006954] [ cut here ]
[ 54.006964] kernel BUG at kerne
On 01/07, Qian Cai wrote:
>
>
> On 1/7/19 8:52 AM, Peter Zijlstra wrote:
> > On Tue, Jan 01, 2019 at 12:44:35AM -0500, Qian Cai wrote:
> >> Running some mmap() workloads to put the system on low memory situation
> >> with
> >> swapping and OOM, and then it trigger this BUG(),
> >>
> >> void
On 1/7/19 8:52 AM, Peter Zijlstra wrote:
> On Tue, Jan 01, 2019 at 12:44:35AM -0500, Qian Cai wrote:
>> Running some mmap() workloads to put the system on low memory situation with
>> swapping and OOM, and then it trigger this BUG(),
>>
>> void __noreturn do_task_dead(void)
>> {
>> /*
On Tue, Jan 01, 2019 at 12:44:35AM -0500, Qian Cai wrote:
> Running some mmap() workloads to put the system on low memory situation with
> swapping and OOM, and then it trigger this BUG(),
>
> void __noreturn do_task_dead(void)
> {
> /* Causes final put_task_struct in
1 - 100 of 1743 matches
Mail list logo
