Hi, Al.
I can not get output of command line on SH in latest linux kernel.
I bisected, I confirmed that this problem occurred by following commit.
-----
commit 4a9d4b024a3102fc083c925c242d98ac27b1c5f6
Author: Al Viro <[email protected]>
Date: Sun Jun 24 09:56:45 2012 +0400
switch fput to task_work_add
... and schedule_work() for interrupt/kernel_thread callers
(and yes, now it *is* OK to call from interrupt).
We are guaranteed that __fput() will be done before we return
to userland (or exit). Note that for fput() from a kernel
thread we get an async behaviour; it's almost always OK, but
sometimes you might need to have __fput() completed before
you do anything else. There are two mechanisms for that -
a general barrier (flush_delayed_fput()) and explicit
__fput_sync(). Both should be used with care (as was the
case for fput() from kernel threads all along). See comments
in fs/file_table.c for details.
Signed-off-by: Al Viro <[email protected]>
-----
For example ,when I input 'ls', nothing is displayed.
However, it is outputted when 'Ctrl+C' is inputted.
I checked other CPUs, it is only SH that this problem occurs.
Paul, do you think about this?
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
On Fri, Aug 31, 2012 at 04:32:45PM +0900, Nobuhiro Iwamatsu wrote:
> Hi, Al.
>
> I can not get output of command line on SH in latest linux kernel.
> I bisected, I confirmed that this problem occurred by following commit.
>
> -----
> commit 4a9d4b024a3102fc083c925c242d98ac27b1c5f6
> Author: Al Viro <[email protected]>
> Date: Sun Jun 24 09:56:45 2012 +0400
>
> switch fput to task_work_add
> For example ,when I input 'ls', nothing is displayed.
> However, it is outputted when 'Ctrl+C' is inputted.
> I checked other CPUs, it is only SH that this problem occurs.
>
> Paul, do you think about this?
Smells like broken TIF_NOTIFY_RESUME hookup on sh... Arrrgh. Looks like
while it is in the relevant masks *and* checked in do_notify_resume() both
on 32bit and 64bit variants since commit ab99c733ae73cce31f2a2434f7099564e5a73d95
Author: Paul Mundt <[email protected]>
Date: Wed Jul 30 19:55:30 2008 +0900
sh: Make syscall tracer use tracehook notifiers, add TIF_NOTIFY_RESUME.
they are actually *not* reached without simulataneous SIGPENDING, since the
actual glue in the callers had not been updated back then and still checks
for _TIF_SIGPENDING alone when deciding whether to hit do_notify_resume()
or not. Looks like the following ought to fix that:
Signed-off-by: Al Viro <[email protected]>
---
diff --git a/arch/sh/kernel/cpu/sh5/entry.S b/arch/sh/kernel/cpu/sh5/entry.S
index b7cf6a5..7e605b9 100644
--- a/arch/sh/kernel/cpu/sh5/entry.S
+++ b/arch/sh/kernel/cpu/sh5/entry.S
@@ -933,7 +933,7 @@ ret_with_reschedule:
pta restore_all, tr1
- movi _TIF_SIGPENDING, r8
+ movi (_TIF_SIGPENDING|_TIF_NOTIFY_RESUME), r8
and r8, r7, r8
pta work_notifysig, tr0
bne r8, ZERO, tr0
diff --git a/arch/sh/kernel/entry-common.S b/arch/sh/kernel/entry-common.S
index f67601c..b96489d 100644
--- a/arch/sh/kernel/entry-common.S
+++ b/arch/sh/kernel/entry-common.S
@@ -139,7 +139,7 @@ work_pending:
! r8: current_thread_info
! t: result of "tst #_TIF_NEED_RESCHED, r0"
bf/s work_resched
- tst #_TIF_SIGPENDING, r0
+ tst #(_TIF_SIGPENDING | _TIF_NOTIFY_RESUME), r0
work_notifysig:
bt/s __restore_all
mov r15, r4