On Wed, 31 Mar 2021 08:44:53 +0200
David Hildenbrand wrote:
> On 31.03.21 06:32, HORIGUCHI NAOYA(堀口 直也) wrote:
> > On Wed, Mar 31, 2021 at 10:43:36AM +0800, Aili Yao wrote:
> >> On Wed, 31 Mar 2021 01:52:59 + HORIGUCHI NAOYA(堀口 直也)
> >> wrote:
> >>> On Fri, Mar 26, 2021 at 03:22:49PM +0
On Wed, 31 Mar 2021 08:44:53 +0200
David Hildenbrand wrote:
> On 31.03.21 06:32, HORIGUCHI NAOYA(堀口 直也) wrote:
> > On Wed, Mar 31, 2021 at 10:43:36AM +0800, Aili Yao wrote:
> >> On Wed, 31 Mar 2021 01:52:59 + HORIGUCHI NAOYA(堀口 直也)
> >> wrote:
> >>> On Fri, Mar 26, 2021 at 03:22:49PM +0
On 31.03.21 08:53, HORIGUCHI NAOYA(堀口 直也) wrote:
On Wed, Mar 31, 2021 at 07:07:39AM +0100, Matthew Wilcox wrote:
On Wed, Mar 31, 2021 at 01:52:59AM +, HORIGUCHI NAOYA(堀口 直也) wrote:
If we successfully unmapped but failed in truncate_error_page() for example,
the processes mapping the page wo
On Wed, Mar 31, 2021 at 07:07:39AM +0100, Matthew Wilcox wrote:
> On Wed, Mar 31, 2021 at 01:52:59AM +, HORIGUCHI NAOYA(堀口 直也) wrote:
> > If we successfully unmapped but failed in truncate_error_page() for example,
> > the processes mapping the page would get -EFAULT as expected. But even in
>
On 31.03.21 06:32, HORIGUCHI NAOYA(堀口 直也) wrote:
On Wed, Mar 31, 2021 at 10:43:36AM +0800, Aili Yao wrote:
On Wed, 31 Mar 2021 01:52:59 + HORIGUCHI NAOYA(堀口 直也)
wrote:
On Fri, Mar 26, 2021 at 03:22:49PM +0100, David Hildenbrand wrote:
On 26.03.21 15:09, David Hildenbrand wrote:
On 22.03
On Wed, Mar 31, 2021 at 01:52:59AM +, HORIGUCHI NAOYA(堀口 直也) wrote:
> If we successfully unmapped but failed in truncate_error_page() for example,
> the processes mapping the page would get -EFAULT as expected. But even in
> this case, other processes could reach the error page via page cache
On Wed, Mar 31, 2021 at 10:43:36AM +0800, Aili Yao wrote:
> On Wed, 31 Mar 2021 01:52:59 + HORIGUCHI NAOYA(堀口 直也)
> wrote:
> > On Fri, Mar 26, 2021 at 03:22:49PM +0100, David Hildenbrand wrote:
> > > On 26.03.21 15:09, David Hildenbrand wrote:
> > > > On 22.03.21 12:33, Aili Yao wrote:
>
On Wed, 31 Mar 2021 01:52:59 +
HORIGUCHI NAOYA(堀口 直也) wrote:
> On Fri, Mar 26, 2021 at 03:22:49PM +0100, David Hildenbrand wrote:
> > On 26.03.21 15:09, David Hildenbrand wrote:
> > > On 22.03.21 12:33, Aili Yao wrote:
> > > > When we do coredump for user process signal, this may be one S
On Fri, Mar 26, 2021 at 03:22:49PM +0100, David Hildenbrand wrote:
> On 26.03.21 15:09, David Hildenbrand wrote:
> > On 22.03.21 12:33, Aili Yao wrote:
> > > When we do coredump for user process signal, this may be one SIGBUS signal
> > > with BUS_MCEERR_AR or BUS_MCEERR_AO code, which means this s
On 26.03.21 15:09, David Hildenbrand wrote:
On 22.03.21 12:33, Aili Yao wrote:
When we do coredump for user process signal, this may be one SIGBUS signal
with BUS_MCEERR_AR or BUS_MCEERR_AO code, which means this signal is
resulted from ECC memory fail like SRAR or SRAO, we expect the memory
rec
On 22.03.21 12:33, Aili Yao wrote:
When we do coredump for user process signal, this may be one SIGBUS signal
with BUS_MCEERR_AR or BUS_MCEERR_AO code, which means this signal is
resulted from ECC memory fail like SRAR or SRAO, we expect the memory
recovery work is finished correctly, then the ge
When we do coredump for user process signal, this may be one SIGBUS signal
with BUS_MCEERR_AR or BUS_MCEERR_AO code, which means this signal is
resulted from ECC memory fail like SRAR or SRAO, we expect the memory
recovery work is finished correctly, then the get_dump_page() will not
return the err
12 matches
Mail list logo