All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Petr Mladek <pmladek@suse.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"Paul E. McKenney" <paulmck@linux.ibm.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Liu Chuansheng <chuansheng.liu@intel.com>,
	Valdis Kletnieks <valdis.kletnieks@vt.edu>,
	linux-kernel@vger.kernel.org, Dmitry Vyukov <dvyukov@google.com>
Subject: Re: [PATCH] kernel/hung_task.c: Monitor killed tasks.
Date: Wed, 22 May 2019 21:38:45 +0900	[thread overview]
Message-ID: <a6b6a5ef-c65c-6999-2bc1-7aaf9dd19fe8@i-love.sakura.ne.jp> (raw)
In-Reply-To: <a3d9de97-46e8-aa43-1743-ebf66b434830@i-love.sakura.ne.jp>

Hello, Stephen.

I want to send debug printk() patches to linux-next.git. Petr Mladek
is suggesting me to have a git tree for debug printk() patches.
But it seems that there is "git quiltimport" command, and I prefer
"subversion + quilt", and I don't have trees for sending "git pull"
requests. Therefore, just ignoring "git quiltimport" failure is fine.
What do you think?

On 2019/05/16 21:38, Tetsuo Handa wrote:
> On 2019/05/16 20:57, Petr Mladek wrote:
>> CCed Stephen to discuss linux-next related question at the bottom
>> of the mail.
>>
>> On Thu 2019-05-16 17:19:12, Tetsuo Handa wrote:
>>> On 2019/05/15 19:55, Petr Mladek wrote:
>>> But in the context of syzbot's testing where there are only 2 CPUs
>>> in the target VM (which means that only small number of threads and
>>> not so much memory) and threads get SIGKILL after 5 seconds from fork(),
>>> being unable to reach do_exit() within 10 seconds is likely a sign of
>>> something went wrong. For example, 6 out of 7 trials of a reproducer for
>>> https://syzkaller.appspot.com/bug?id=835a0b9e75b14b55112661cbc61ca8b8f0edf767
>>> resulted in "no output from test machine" rather than "task hung".
>>> This patch is revealing that such killed threads are failing to reach
>>> do_exit() because they are trapped at unkillable retry loop due to a
>>> race bug.
>>>
>>> Therefore, I would like to try this patch in linux-next.git for feasibility
>>> testing whether this patch helps finding more bugs and reproducers for such
>>> bugs, by bringing "unable to terminate threads" reports out of "no output from
>>> test machine" reports. We can add sysctl settings before sending to linux.git.
>>
>> In this case, the watchdog should get enabled on with
>> CONFIG_DEBUG_AID_FOR_SYZBOT
> 
> Since "[PATCH] printk: Monitor change of console loglevel." is one time (only
> needed until we find the reason of silence), testing on only linux-next.git
> is sufficient and it gets enabled on with CONFIG_DEBUG_AID_FOR_SYZBOT.
> 
>>
>> Also we should ask/inform Stephen about this. I am not sure
>> if he is willing to resolve eventual conflicts for these
>> syzboot-specific patches that are not upstream candidates.
>>
>> A solution might be to create sysbot-specific for-next branch
>> that Stephen might simply ignore when there are conflicts.
>> And you would be responsible for updating it.
> 
> syzbot tests not only linux-next.git but also various trees, and tests
> attempted depends on target git tree. Therefore, apart from whether we
> can introduce a kernel config option for fuzzing testing,
> "[PATCH] kernel/hung_task.c: Monitor killed tasks." is expected to be
> in linux.git. This patch will eventually become upstream candidate.
> 


  reply	other threads:[~2019-05-22 12:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-13 11:02 [PATCH] kernel/hung_task.c: Monitor killed tasks Tetsuo Handa
2019-05-13 11:11 ` Dmitry Vyukov
2019-05-14 22:28 ` Paul E. McKenney
2019-05-15 10:55 ` Petr Mladek
2019-05-16  8:19   ` Tetsuo Handa
2019-05-16 11:57     ` Petr Mladek
2019-05-16 12:38       ` Tetsuo Handa
2019-05-22 12:38         ` Tetsuo Handa [this message]
2019-05-22 13:41           ` Stephen Rothwell
2019-05-22 14:58             ` Tetsuo Handa
2019-05-22 21:09               ` Tetsuo Handa
2019-05-22 21:39                 ` Stephen Rothwell
2019-05-22 21:43                   ` Andrew Morton
2019-05-22 23:46                     ` Tetsuo Handa
2019-05-27 14:12         ` Tetsuo Handa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a6b6a5ef-c65c-6999-2bc1-7aaf9dd19fe8@i-love.sakura.ne.jp \
    --to=penguin-kernel@i-love.sakura.ne.jp \
    --cc=akpm@linux-foundation.org \
    --cc=chuansheng.liu@intel.com \
    --cc=dvyukov@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulmck@linux.ibm.com \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=sfr@canb.auug.org.au \
    --cc=valdis.kletnieks@vt.edu \
    --cc=vkuznets@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.