linux-kernel - Re: [v3.13][v3.14][Regression] kthread: make kthread

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140318174527.GA11866@redhat.com>
Date:	Tue, 18 Mar 2014 18:45:27 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Joseph Salisbury <joseph.salisbury@...onical.com>,
	penguin-kernel@...ove.SAKURA.ne.jp, rientjes@...gle.com,
	Linus Torvalds <torvalds@...ux-foundation.org>, tj@...nel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Kernel Team <kernel-team@...ts.ubuntu.com>
Subject: Re: [v3.13][v3.14][Regression] kthread: make kthread_create()
	killable

On 03/17, Andrew Morton wrote:
>
> On Mon, 17 Mar 2014 21:19:19 +0100 Oleg Nesterov <oleg@...hat.com> wrote:
>
> > > Root cause time: it's wrong for the oom-killer to use SIGKILL.
> >
> > Not sure... what else?
>
> If we really really have to use userspace IPC in the kernel then I
> suppose we could add a new signal type (SIGKERNEL?) which userspace can
> neither receive nor send.

But for what?

> > > In fact
> > > it's basically always wrong to send signals from in-kernel.
> >
> > Well, SIGSEGV, SIGIO...
>
> Those are kernel->userspace, not kernel->kernel.

OK, this is probably true.

> We have all sorts of cross-task mechanisms available in kernel (set_bit
> and wake_up would suffice here) so we don't need to use signals with
> all the baggage they bring along.

but why do we need another mechanism if we want terminate the task
for any reason?

OK. Perhaps the killed task wants to know if it was killed by kernel
or user-space... Not sure we really need this, but OK. We can add the
SIGNAL_GROUP_KILLED_BY_KERNEL flag. But it is not clear if we want
TASK_WAKEKILL_BY_KERNEL or not... And probably I missed your point.

> > Well, I think in this case it doesn't matter who/why sends a signal.
> > The task is killed, it should react and exit asap. And kthread_create()
> > can fail in any case, at least the kernel should not crash.
>
> Well yes.  In this "bug", userspace tried to kill udev and surprise
> surprise, that's what happened.  The only real kernel bug here is the
> incorrect errno.

and the kernel crash in mptsas_probe's error paths. This should be fixed.
And it seems that this driver has more problems, but I can be wrong.

> But in the real world, the kernel changed and systems
> broke - we should try to unbreak them.

Yes, yes, sure. But so far I think we should uglify the driver or scsi
(unless we have the right fix), not the poor kthread_create().

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/