linux-kernel - Re: [PATCH] coredump: Retry writes where appropriate

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]

Date:	Mon,  1 Jun 2009 16:02:10 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, paul@...-scientist.net,
	linux-kernel@...r.kernel.org, stable@...nel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: [PATCH] coredump: Retry writes where appropriate

> I don't think ->real_blocked is a good choice, we have to add more checks
> to the signal sending path. Note that currenly it is only checked under
> sig_fatal() && !SIGNAL_GROUP_EXIT.

No, you're right.  It's not a good idea.

> Perhaps it is easier to change dump_write() to clear TIF_SIGPENDING
> unless fatal_signal_pending(),

That is almost a separate subject, really.  Having i/o calls' waits wrongly
interrupted and then clearing TIF_SIGPENDING just seems goofy to me.  It
might not be just the ->write call, it might affect filp_open or dump_seek
or whatever.  It makes no sense to me to take the approach of fiddling
after doing the wrong thing.  Just don't do the wrong thing to begin with.

That means clear TIF_SIGPENDING and don't let it be set again by a signal
that is not meant to abort the core dump.  Why do anything but that?

It's almost certain that recalc_sigpending_tsk won't be called once dumping
has started.  But there is the possibility of recalc_sigpending_and_wake
via cancel_freezing, at least.  Seems safer to make recalc_sigpending_tsk
robust in this case.

Thanks,
Roland
--
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/