linux-kernel - Re: [PATCH 06/10] HWPOISON: Handle hwpoison in current process

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:	Fri, 10 Jun 2011 13:36:01 -0700
From:	Tony Luck <tony.luck@...el.com>
To:	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Borislav Petkov <bp@...64.org>,
	linux-kernel@...r.kernel.org, "Huang, Ying" <ying.huang@...el.com>,
	Avi Kivity <avi@...hat.com>
Subject: Re: [PATCH 06/10] HWPOISON: Handle hwpoison in current process

2011/6/10 Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>:
> It doesn't make sense that the function named "*_ao" sends _AR.

Oops. Good point.

> I suppose that usually SRAO is handled in worker thread scheduled after
> MCE, so current is unlikely one of affected threads in that case...
> And I also suppose that you'd like to use this function to be called
> from affected thread before leaving kernel in the case of SRAR...
>
> My concern is that "t == current" is neither strong nor clear statement
> to switch the type of signal.  Someone might want to use this function
> to inject _AO to current.
>
> It is better to have new kill_proc_ar() (separated, or one shared _common
> plus a couple of _ar/_ao), I think.  I believe that there is no caller
> who have no idea whether it should request sending _AR or _AO.

Agreed - each call chain should know whether it is AR or AO. I think
there is plenty of room to make this code cleaner and clearer.

In the AR case we will always be in the current task context - and we
know that we cannot let the process ignore the signal.

In the AO case we will usually be in some other task context (except
by random chance) - and we shouldn't mind if the signal is currently
blocked, or ignored.

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