mm, gup: return EINTR when gup is interrupted by fatal signals

Commit Message

Michal Hocko April 9, 2020, 7:11 a.m. UTC

From: Michal Hocko <[e-mail]>

EINTR is the usual error code which other killable interfaces return.
This is the case for the other fatal_signal_pending break out from
the same function. Make the code consistent.

ERESTARTSYS is also quite confusing because the signal is fatal and so
no handling will happen before returning to the userspace.

Signed-off-by: Michal Hocko <[e-mail]>
---
 mm/gup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Linus Torvalds April 9, 2020, 7:55 p.m. UTC | #1

On Thu, Apr 9, 2020 at 12:11 AM Michal Hocko <[e-mail]> wrote:
>
> ERESTARTSYS is also quite confusing because the signal is fatal and so
> no handling will happen before returning to the userspace.

Ack. Except I'd rephrase that as "no restart" rather than "no handling".

We do end up handling the fatal signal, it's just that the handling
doesn't involve restarting, it just involves dying.

That said, I'll leave this to the usual channels, since it isn't
exactly the same kind of urgent fix that I picked up directly..

              Linus

Patch

diff --git a/mm/gup.c b/mm/gup.c
index 6076df8e04a4..50681f0286de 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1088,7 +1088,7 @@  static long __get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
 		 * potentially allocating memory.
 		 */
 		if (fatal_signal_pending(current)) {
-			ret = -ERESTARTSYS;
+			ret = -EINTR;
 			goto out;
 		}
 		cond_resched();