Re: [RFC][PATCH] HWPOISON: only early kill processes who installed SIGBUS handler

From: Nick Piggin
Date: Wed Jun 17 2009 - 06:00:28 EST


On Wed, Jun 17, 2009 at 05:55:32PM +0800, Wu Fengguang wrote:
> On Wed, Jun 17, 2009 at 04:04:04PM +0800, Nick Piggin wrote:
> > Well then you can still early-kill random apps that did not
> > want it, and you may still cause problems if its sigbus
> > handler does something nontrivial.
> >
> > Can you use a prctl or something so it can expclitly
> > register interest in this?
>
> No I don't think prctl would be much better.
>
> - if an application want early/late kill, it can do so with a proper
> written SIGBUS handler: the prctl call is redundant.

s/proper written/is switched to new semantics based on the existance
of a/

> - if an admin want to control early/late kill for an unmodified app,
> prctl is as unhelpful as this patch(*).

Clearly you can execute a process with a given prctl.


> - prctl does can help legacy apps whose SIGBUS handler has trouble
> with the new SIGBUS codes, however such application should be rare
> and the application should be fixed(why shall it do something wrong
> on newly introduced code at all? Shall we stop introducing new codes
> just because some random buggy app cannot handle new codes?)

Backwards compatibility? Kind of important.


> So I still prefer this patch, until we come up with some solution that
> allows both app and admin to change the setting.

Not only does it allow that, but it also provides backwards
compatibility. Your patch does not allow admin to change
anything nor does it guarantee 100% back compat so I can't
see how you think it is better.

Also it does not allow for an app with a SIGBUS handler to
use late kill. If late kill is useful to anyone, why would
it not be useful to some app with a SIGBUS handler (that is
not KVM)?

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