Re: Question about SEA handling process happened in user space

From: Xiaofei Tan <tanxiaofei@huawei.com>
To: James Morse <james.morse@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Linuxarm <linuxarm@huawei.com>, Will Deacon <will@kernel.org>,
	Dave Martin <Dave.Martin@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	Shiju Jose <shiju.jose@huawei.com>
Subject: Re: Question about SEA handling process happened in user space
Date: Thu, 9 Apr 2020 17:17:57 +0800	[thread overview]
Message-ID: <5E8EE845.8090406@huawei.com> (raw)
In-Reply-To: <558ffd42-74d7-e364-2b79-93ab0998ab6e@arm.com>

Hi James,

On 2020/4/8 0:37, James Morse wrote:
> On 02/04/2020 07:35, Xiaofei Tan wrote:
>> On 2020/3/31 0:49, James Morse wrote:
>>> If the CPU doesn't tell us the address, we can't tell user-space what it is. The
>>> alternative is to upgrade to SIGKILL in that case.
>>>
>>>
>>> If you see this instead of the address provided via firmware-first, there is a
>>> series to improve that here:
>>> https://lore.kernel.org/linux-acpi/20200228174817.74278-1-james.morse@arm.com/
>>>
>>> (We skip this signal code of APEI promises it did all the work. This lets you
>>> take the signal from memory_failure() instead, which may have better information.)
> 
>> There may be an competition issue.
>> APEI run memory_failure() in an bottom half for memory errors. Then it may be not finished
>> before here SEA handling end, and application process may back to run.
> 
> I'm not sure what you mean by 'bottom half', isn't this a softirq term?
> 

I mean the bottom half of interrupt. Of course, this is SEA, but similar.

> With that series, it runs in process-context as task-work. memory_failure() needs to
> sleep, so it has to run in process-context. 

> Doing it as task-work means it runs before the thread returns to user-space.

Sorry, i don't understand this. i thought the task-work need to reschedule, and current thread should
have returned to user-space before it.

BTW, What context synchronous exception abort is? I thought it was process-context.
Because in_interrupt() return false called in do_sea().

> 
> If another thread in the same process accesses the affected memory, I'd expect to take a
> second external abort. If another process had the page mapped, it could access the
> affected memory, again taking an external abort.
> 

Yes, it is hard to avoid another thread to access the affected memory.
I just worry the same thread access it again.

> These two could happen while the first CPU was in firmware generating the CPER records, so
> its not a race we can fix. It should be harmless, the recovery action is the same, its
> just the error counters that count more events than errors. If you actually see it happen,
> we can try and make it smaller...
> 

Hmm, maybe this double SEA handling is an solution.

> 
> Thanks,
> 
> James
> 
> .
> 

-- 
 thanks
tanxiaofei

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel