linux-kernel - Re: [PATCH] coredump: wait on the core pattern umh at least once

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: <CA+bD78hSSDkOBsNTy=VjnzjYSMMtw_B6Gu2hX39G7zp2smGUVg@mail.gmail.com>
Date:	Sat, 29 Oct 2011 11:01:44 -0700
From:	Scott James Remnant <scott@...split.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	linux-kernel@...r.kernel.org,
	Mandeep Singh Baines <msb@...omium.org>,
	Neil Horman <nhorman@...driver.com>
Subject: Re: [PATCH] coredump: wait on the core pattern umh at least once

On Sat, Oct 29, 2011 at 7:13 AM, Oleg Nesterov <oleg@...hat.com> wrote:

> On 10/28, Scott James Remnant wrote:
> >
> > If a thread crashes as a result of a signal on the thread group leader
> > that signal can still be pending,
>
> No. do_coredump() clears TIF_SIGPENDING.
>
I'm definitely seeing cases where SIGTERM sent to the process group
that chrome is in results in one of chrome's thread's crashing (not
your concern, obviously), but at the point it enters this function
TIF_SIGPENDING is definitely set and the signal is SIGTERM.

The SIGTERM is in the shared pending set.

> I already tried to explain why this signal_pending() was added, but
> apparently I was not clear. I'll try again in the previous thread.
>
Could you add me to the Cc: of that thread?

Scott
--
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/