* [PATCH] mm, memory-failure: clarify error message @ 2019-05-17 4:08 Jane Chu 2019-05-17 4:48 ` Anshuman Khandual 2019-05-17 18:20 ` Verma, Vishal L 0 siblings, 2 replies; 6+ messages in thread From: Jane Chu @ 2019-05-17 4:08 UTC (permalink / raw) To: n-horiguchi, linux-mm, linux-kernel; +Cc: linux-nvdimm Some user who install SIGBUS handler that does longjmp out therefore keeping the process alive is confused by the error message "[188988.765862] Memory failure: 0x1840200: Killing cellsrv:33395 due to hardware memory corruption" Slightly modify the error message to improve clarity. Signed-off-by: Jane Chu <jane.chu@oracle.com> --- mm/memory-failure.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/mm/memory-failure.c b/mm/memory-failure.c index fc8b517..14de5e2 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -216,10 +216,9 @@ static int kill_proc(struct to_kill *tk, unsigned long pfn, int flags) short addr_lsb = tk->size_shift; int ret; - pr_err("Memory failure: %#lx: Killing %s:%d due to hardware memory corruption\n", - pfn, t->comm, t->pid); - if ((flags & MF_ACTION_REQUIRED) && t->mm == current->mm) { + pr_err("Memory failure: %#lx: Killing %s:%d due to hardware memory " + "corruption\n", pfn, t->comm, t->pid); ret = force_sig_mceerr(BUS_MCEERR_AR, (void __user *)tk->addr, addr_lsb, current); } else { @@ -229,6 +228,8 @@ static int kill_proc(struct to_kill *tk, unsigned long pfn, int flags) * This could cause a loop when the user sets SIGBUS * to SIG_IGN, but hopefully no one will do that? */ + pr_err("Memory failure: %#lx: Sending SIGBUS to %s:%d due to hardware " + "memory corruption\n", pfn, t->comm, t->pid); ret = send_sig_mceerr(BUS_MCEERR_AO, (void __user *)tk->addr, addr_lsb, t); /* synchronous? */ } -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] mm, memory-failure: clarify error message 2019-05-17 4:08 [PATCH] mm, memory-failure: clarify error message Jane Chu @ 2019-05-17 4:48 ` Anshuman Khandual 2019-05-20 10:21 ` Naoya Horiguchi 2019-05-21 1:53 ` Jane Chu 2019-05-17 18:20 ` Verma, Vishal L 1 sibling, 2 replies; 6+ messages in thread From: Anshuman Khandual @ 2019-05-17 4:48 UTC (permalink / raw) To: Jane Chu, n-horiguchi, linux-mm, linux-kernel; +Cc: linux-nvdimm On 05/17/2019 09:38 AM, Jane Chu wrote: > Some user who install SIGBUS handler that does longjmp out What the longjmp about ? Are you referring to the mechanism of catching the signal which was registered ? > therefore keeping the process alive is confused by the error > message > "[188988.765862] Memory failure: 0x1840200: Killing > cellsrv:33395 due to hardware memory corruption" Its a valid point because those are two distinct actions. > Slightly modify the error message to improve clarity. > > Signed-off-by: Jane Chu <jane.chu@oracle.com> > --- > mm/memory-failure.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/mm/memory-failure.c b/mm/memory-failure.c > index fc8b517..14de5e2 100644 > --- a/mm/memory-failure.c > +++ b/mm/memory-failure.c > @@ -216,10 +216,9 @@ static int kill_proc(struct to_kill *tk, unsigned long pfn, int flags) > short addr_lsb = tk->size_shift; > int ret; > > - pr_err("Memory failure: %#lx: Killing %s:%d due to hardware memory corruption\n", > - pfn, t->comm, t->pid); > - > if ((flags & MF_ACTION_REQUIRED) && t->mm == current->mm) { > + pr_err("Memory failure: %#lx: Killing %s:%d due to hardware memory " > + "corruption\n", pfn, t->comm, t->pid); > ret = force_sig_mceerr(BUS_MCEERR_AR, (void __user *)tk->addr, > addr_lsb, current); > } else { > @@ -229,6 +228,8 @@ static int kill_proc(struct to_kill *tk, unsigned long pfn, int flags) > * This could cause a loop when the user sets SIGBUS > * to SIG_IGN, but hopefully no one will do that? > */ > + pr_err("Memory failure: %#lx: Sending SIGBUS to %s:%d due to hardware " > + "memory corruption\n", pfn, t->comm, t->pid); > ret = send_sig_mceerr(BUS_MCEERR_AO, (void __user *)tk->addr, > addr_lsb, t); /* synchronous? */ As both the pr_err() messages are very similar, could not we just switch between "Killing" and "Sending SIGBUS to" based on a variable e.g action_[kill|sigbus] evaluated previously with ((flags & MF_ACTION_REQUIRED) && t->mm == current->mm). ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] mm, memory-failure: clarify error message 2019-05-17 4:48 ` Anshuman Khandual @ 2019-05-20 10:21 ` Naoya Horiguchi 2019-05-21 1:50 ` Jane Chu 2019-05-21 1:53 ` Jane Chu 1 sibling, 1 reply; 6+ messages in thread From: Naoya Horiguchi @ 2019-05-20 10:21 UTC (permalink / raw) To: Anshuman Khandual; +Cc: Jane Chu, linux-mm, linux-kernel, linux-nvdimm On Fri, May 17, 2019 at 10:18:02AM +0530, Anshuman Khandual wrote: > > > On 05/17/2019 09:38 AM, Jane Chu wrote: > > Some user who install SIGBUS handler that does longjmp out > > What the longjmp about ? Are you referring to the mechanism of catching the > signal which was registered ? AFAIK, longjmp() might be useful for signal-based retrying, so highly optimized applications like Oracle DB might want to utilize it to handle memory errors in application level, I guess. > > > therefore keeping the process alive is confused by the error > > message > > "[188988.765862] Memory failure: 0x1840200: Killing > > cellsrv:33395 due to hardware memory corruption" > > Its a valid point because those are two distinct actions. > > > Slightly modify the error message to improve clarity. > > > > Signed-off-by: Jane Chu <jane.chu@oracle.com> > > --- > > mm/memory-failure.c | 7 ++++--- > > 1 file changed, 4 insertions(+), 3 deletions(-) > > > > diff --git a/mm/memory-failure.c b/mm/memory-failure.c > > index fc8b517..14de5e2 100644 > > --- a/mm/memory-failure.c > > +++ b/mm/memory-failure.c > > @@ -216,10 +216,9 @@ static int kill_proc(struct to_kill *tk, unsigned long pfn, int flags) > > short addr_lsb = tk->size_shift; > > int ret; > > > > - pr_err("Memory failure: %#lx: Killing %s:%d due to hardware memory corruption\n", > > - pfn, t->comm, t->pid); > > - > > if ((flags & MF_ACTION_REQUIRED) && t->mm == current->mm) { > > + pr_err("Memory failure: %#lx: Killing %s:%d due to hardware memory " > > + "corruption\n", pfn, t->comm, t->pid); > > ret = force_sig_mceerr(BUS_MCEERR_AR, (void __user *)tk->addr, > > addr_lsb, current); > > } else { > > @@ -229,6 +228,8 @@ static int kill_proc(struct to_kill *tk, unsigned long pfn, int flags) > > * This could cause a loop when the user sets SIGBUS > > * to SIG_IGN, but hopefully no one will do that? > > */ > > + pr_err("Memory failure: %#lx: Sending SIGBUS to %s:%d due to hardware " > > + "memory corruption\n", pfn, t->comm, t->pid); > > ret = send_sig_mceerr(BUS_MCEERR_AO, (void __user *)tk->addr, > > addr_lsb, t); /* synchronous? */ > > As both the pr_err() messages are very similar, could not we just switch between "Killing" > and "Sending SIGBUS to" based on a variable e.g action_[kill|sigbus] evaluated previously > with ((flags & MF_ACTION_REQUIRED) && t->mm == current->mm). That might need additional if sentence, which I'm not sure worth doing. I think that the simplest fix for the reported problem (a confusing message) is like below: - pr_err("Memory failure: %#lx: Killing %s:%d due to hardware memory corruption\n", + pr_err("Memory failure: %#lx: Sending SIGBUS to %s:%d due to hardware memory corruption\n", pfn, t->comm, t->pid); Or, if we have a good reason to separate the message for MF_ACTION_REQUIRED and MF_ACTION_OPTIONAL, that might be OK. Thanks, Naoya Horiguchi ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] mm, memory-failure: clarify error message 2019-05-20 10:21 ` Naoya Horiguchi @ 2019-05-21 1:50 ` Jane Chu 0 siblings, 0 replies; 6+ messages in thread From: Jane Chu @ 2019-05-21 1:50 UTC (permalink / raw) To: Naoya Horiguchi, Anshuman Khandual; +Cc: linux-mm, linux-kernel, linux-nvdimm Thanks Vishal and Naoya! -jane On 5/20/2019 3:21 AM, Naoya Horiguchi wrote: > On Fri, May 17, 2019 at 10:18:02AM +0530, Anshuman Khandual wrote: >> >> On 05/17/2019 09:38 AM, Jane Chu wrote: >>> Some user who install SIGBUS handler that does longjmp out >> What the longjmp about ? Are you referring to the mechanism of catching the >> signal which was registered ? > AFAIK, longjmp() might be useful for signal-based retrying, so highly > optimized applications like Oracle DB might want to utilize it to handle > memory errors in application level, I guess. > >>> therefore keeping the process alive is confused by the error >>> message >>> "[188988.765862] Memory failure: 0x1840200: Killing >>> cellsrv:33395 due to hardware memory corruption" >> Its a valid point because those are two distinct actions. >> >>> Slightly modify the error message to improve clarity. >>> >>> Signed-off-by: Jane Chu <jane.chu@oracle.com> >>> --- >>> mm/memory-failure.c | 7 ++++--- >>> 1 file changed, 4 insertions(+), 3 deletions(-) >>> >>> diff --git a/mm/memory-failure.c b/mm/memory-failure.c >>> index fc8b517..14de5e2 100644 >>> --- a/mm/memory-failure.c >>> +++ b/mm/memory-failure.c >>> @@ -216,10 +216,9 @@ static int kill_proc(struct to_kill *tk, unsigned long pfn, int flags) >>> short addr_lsb = tk->size_shift; >>> int ret; >>> >>> - pr_err("Memory failure: %#lx: Killing %s:%d due to hardware memory corruption\n", >>> - pfn, t->comm, t->pid); >>> - >>> if ((flags & MF_ACTION_REQUIRED) && t->mm == current->mm) { >>> + pr_err("Memory failure: %#lx: Killing %s:%d due to hardware memory " >>> + "corruption\n", pfn, t->comm, t->pid); >>> ret = force_sig_mceerr(BUS_MCEERR_AR, (void __user *)tk->addr, >>> addr_lsb, current); >>> } else { >>> @@ -229,6 +228,8 @@ static int kill_proc(struct to_kill *tk, unsigned long pfn, int flags) >>> * This could cause a loop when the user sets SIGBUS >>> * to SIG_IGN, but hopefully no one will do that? >>> */ >>> + pr_err("Memory failure: %#lx: Sending SIGBUS to %s:%d due to hardware " >>> + "memory corruption\n", pfn, t->comm, t->pid); >>> ret = send_sig_mceerr(BUS_MCEERR_AO, (void __user *)tk->addr, >>> addr_lsb, t); /* synchronous? */ >> As both the pr_err() messages are very similar, could not we just switch between "Killing" >> and "Sending SIGBUS to" based on a variable e.g action_[kill|sigbus] evaluated previously >> with ((flags & MF_ACTION_REQUIRED) && t->mm == current->mm). > That might need additional if sentence, which I'm not sure worth doing. > I think that the simplest fix for the reported problem (a confusing message) > is like below: > > - pr_err("Memory failure: %#lx: Killing %s:%d due to hardware memory corruption\n", > + pr_err("Memory failure: %#lx: Sending SIGBUS to %s:%d due to hardware memory corruption\n", > pfn, t->comm, t->pid); > > Or, if we have a good reason to separate the message for MF_ACTION_REQUIRED and > MF_ACTION_OPTIONAL, that might be OK. > > Thanks, > Naoya Horiguchi ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] mm, memory-failure: clarify error message 2019-05-17 4:48 ` Anshuman Khandual 2019-05-20 10:21 ` Naoya Horiguchi @ 2019-05-21 1:53 ` Jane Chu 1 sibling, 0 replies; 6+ messages in thread From: Jane Chu @ 2019-05-21 1:53 UTC (permalink / raw) To: Anshuman Khandual, n-horiguchi, linux-mm, linux-kernel; +Cc: linux-nvdimm On 5/16/2019 9:48 PM, Anshuman Khandual wrote: > On 05/17/2019 09:38 AM, Jane Chu wrote: >> Some user who install SIGBUS handler that does longjmp out > What the longjmp about ? Are you referring to the mechanism of catching the > signal which was registered ? Yes. thanks, -jane ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] mm, memory-failure: clarify error message 2019-05-17 4:08 [PATCH] mm, memory-failure: clarify error message Jane Chu 2019-05-17 4:48 ` Anshuman Khandual @ 2019-05-17 18:20 ` Verma, Vishal L 1 sibling, 0 replies; 6+ messages in thread From: Verma, Vishal L @ 2019-05-17 18:20 UTC (permalink / raw) To: jane.chu, n-horiguchi, linux-mm, linux-kernel; +Cc: linux-nvdimm On Thu, 2019-05-16 at 22:08 -0600, Jane Chu wrote: > Some user who install SIGBUS handler that does longjmp out > therefore keeping the process alive is confused by the error > message > "[188988.765862] Memory failure: 0x1840200: Killing > cellsrv:33395 due to hardware memory corruption" > Slightly modify the error message to improve clarity. > > Signed-off-by: Jane Chu <jane.chu@oracle.com> > --- > mm/memory-failure.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/mm/memory-failure.c b/mm/memory-failure.c > index fc8b517..14de5e2 100644 > --- a/mm/memory-failure.c > +++ b/mm/memory-failure.c > @@ -216,10 +216,9 @@ static int kill_proc(struct to_kill *tk, unsigned long pfn, int flags) > short addr_lsb = tk->size_shift; > int ret; > > - pr_err("Memory failure: %#lx: Killing %s:%d due to hardware memory corruption\n", > - pfn, t->comm, t->pid); > - > if ((flags & MF_ACTION_REQUIRED) && t->mm == current->mm) { > + pr_err("Memory failure: %#lx: Killing %s:%d due to hardware memory " > + "corruption\n", pfn, t->comm, t->pid); Minor nit, but the string shouldn't be split over multiple lines to preserve grep-ability. In such a case it is usually considered OK to exceed 80 characters for the line if needed. > ret = force_sig_mceerr(BUS_MCEERR_AR, (void __user *)tk->addr, > addr_lsb, current); > } else { > @@ -229,6 +228,8 @@ static int kill_proc(struct to_kill *tk, unsigned long pfn, int flags) > * This could cause a loop when the user sets SIGBUS > * to SIG_IGN, but hopefully no one will do that? > */ > + pr_err("Memory failure: %#lx: Sending SIGBUS to %s:%d due to hardware " > + "memory corruption\n", pfn, t->comm, t->pid); > ret = send_sig_mceerr(BUS_MCEERR_AO, (void __user *)tk->addr, > addr_lsb, t); /* synchronous? */ > } ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-05-21 1:53 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-05-17 4:08 [PATCH] mm, memory-failure: clarify error message Jane Chu 2019-05-17 4:48 ` Anshuman Khandual 2019-05-20 10:21 ` Naoya Horiguchi 2019-05-21 1:50 ` Jane Chu 2019-05-21 1:53 ` Jane Chu 2019-05-17 18:20 ` Verma, Vishal L
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).