All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Coly Li <colyli@suse.de>
Cc: stable@vger.kernel.org, Kent Overstreet <kent.overstreet@gmail.com>
Subject: Re: [PATCH] bcache: Make gc wakeup sane, remove set_task_state()
Date: Mon, 20 Feb 2017 13:31:37 +0100	[thread overview]
Message-ID: <20170220123137.GA28408@kroah.com> (raw)
In-Reply-To: <20170123145407.GA24796@kroah.com>

On Mon, Jan 23, 2017 at 03:54:07PM +0100, Greg KH wrote:
> On Mon, Jan 23, 2017 at 10:45:47PM +0800, Coly Li wrote:
> > On 2017/1/23 下午10:16, Greg KH wrote:
> > > On Mon, Jan 23, 2017 at 09:20:12PM +0800, colyli@suse.de wrote:
> > >> Hi stable maintainers,
> > >>
> > >> This patch is from Kent, upstream commit ID is be628be09563.
> > >> Olav Reinert <seroton10@gmail.com> reports a kerenl crash from
> > >> bcache (boo#1021260) and Oliver Nuekum points out this patch fixes the problem. 
> > > 
> > > "boo"?
> > > 
> > 
> > Hi Greg,
> > 
> > 
> > "boo" is abbreviation of bugzilla.opensuse.org, I paste the original bug
> > report here,
> > ==== start of bug report ==========
> > I have starting seeing errors like the one quoted below in the system
> > log. It occurs infrequently, but quite regularly, about 1-3 times a
> > week, on a server running 24x7.
> > 
> > Around the time it began, I started running a beta version of Leap 42.2,
> > upgraded from 42.1. Also, I enabled the "discard" option (SSD TRIM) on
> > the bcache cache about 3-6 months ago. I believe one of those two events
> > caused the bug to appear.
> > 
> > Not sure what other info is useful, please ask for whatever you need.
> > 
> > 
> > Oct 10 00:00:02 blackbox kernel: ------------[ cut here ]------------
> > Oct 10 00:00:02 blackbox kernel: WARNING: CPU: 4 PID: 1269 at
> > ../kernel/sched/core.c:7891 __might_sleep+0x76/0x80()
> > Oct 10 00:00:02 blackbox kernel: do not call blocking ops when
> > !TASK_RUNNING; state=1 set at [<ffffffffa09e2325>]
> > bch_gc_thread+0x25/0x100 [
> > Oct 10 00:00:02 blackbox kernel: Modules linked in: vhost_net vhost
> > macvtap macvlan fuse ebt_arp ebt_ip ebtable_nat ebtable_filter ebtables
> > Oct 10 00:00:02 blackbox kernel:  mxm_wmi
> > Oct 10 00:00:02 blackbox kernel:  bcache aesni_intel raid1
> > snd_hda_codec_realtek aes_x86_64 lrw snd_hda_codec_generic gf128mul
> > md_mod glue_h
> > Oct 10 00:00:02 blackbox kernel:
> > Oct 10 00:00:02 blackbox kernel: CPU: 4 PID: 1269 Comm: bcache_gc Not
> > tainted 4.4.21-2-default #1
> > Oct 10 00:00:02 blackbox kernel: Hardware name: To be filled by O.E.M.
> > To be filled by O.E.M./M5A99X EVO R2.0, BIOS 2301 01/06/2014
> > Oct 10 00:00:02 blackbox kernel:  0000000000000000 ffffffff81326967
> > ffff8800b605be10 ffffffff81a5e431
> > Oct 10 00:00:02 blackbox kernel:  ffffffff8107e7d1 ffffffff81a5f54f
> > ffff8800b605be60 0000000000000061
> > Oct 10 00:00:02 blackbox kernel:  0000000000000000
> > Oct 10 00:00:02 blackbox kernel:  0000000000000000 ffffffff8107e84c
> > ffffffff81a4ef88
> > Oct 10 00:00:02 blackbox kernel: Call Trace:
> > Oct 10 00:00:02 blackbox kernel:  [<ffffffff81019e69>] dump_trace+0x59/0x320
> > Oct 10 00:00:02 blackbox kernel:  [<ffffffff8101a22a>]
> > show_stack_log_lvl+0xfa/0x180
> > Oct 10 00:00:02 blackbox kernel:  [<ffffffff8101afd1>] show_stack+0x21/0x40
> > Oct 10 00:00:02 blackbox kernel:  [<ffffffff81326967>] dump_stack+0x5c/0x85
> > Oct 10 00:00:02 blackbox kernel:  [<ffffffff8107e7d1>]
> > warn_slowpath_common+0x81/0xb0
> > Oct 10 00:00:02 blackbox kernel:  [<ffffffff8107e84c>]
> > warn_slowpath_fmt+0x4c/0x50
> > Oct 10 00:00:02 blackbox kernel:  [<ffffffff810a3026>]
> > __might_sleep+0x76/0x80
> > Oct 10 00:00:02 blackbox kernel:  [<ffffffff81605cac>] mutex_lock+0x1c/0x38
> > Oct 10 00:00:02 blackbox kernel:  [<ffffffffa09e2365>]
> > bch_gc_thread+0x65/0x100 [bcache]
> > Oct 10 00:00:02 blackbox kernel:  [<ffffffff8109d268>] kthread+0xc8/0xe0
> > Oct 10 00:00:02 blackbox kernel:  [<ffffffff8160828f>]
> > ret_from_fork+0x3f/0x70
> > Oct 10 00:00:02 blackbox kernel: DWARF2 unwinder stuck at
> > ret_from_fork+0x3f/0x70
> > Oct 10 00:00:02 blackbox kernel:
> > Oct 10 00:00:02 blackbox kernel: Leftover inexact backtrace:
> > Oct 10 00:00:02 blackbox kernel:  [<ffffffff8109d1a0>] ?
> > kthread_park+0x50/0x50
> > Oct 10 00:00:02 blackbox kernel: ---[ end trace c63abcb6c473e79b ]---
> > ==== end of bug report ==========
> > 
> > 
> > # journalctl|grep "blocking ops"
> > Oct 10 00:00:02 blackbox kernel: do not call blocking ops when
> > !TASK_RUNNING; state=1 set at [<ffffffffa09e2325>]
> > bch_gc_thread+0x25/0x100 [bcache]
> > [snip repeated lines]
> > 
> > 
> > 
> > >> I send this patch to stable@kernel.vger.org, hope this patch can be taken care
> > >> in stable kernels.
> > >>
> > >> Thanks in advance.
> > >>
> > >> Coly Li
> > >>
> > >> Here I attach the original patch, just FYI.
> > >> ---
> > >> From: Kent Overstreet <kent.overstreet@gmail.com>
> > >> Date: Wed, 26 Oct 2016 20:31:17 -0700
> > >> Subject: [PATCH] bcache: Make gc wakeup sane, remove set_task_state()
> > >>
> > >> Signed-off-by: Kent Overstreet <kent.overstreet@gmail.com>
> > > 
> > > No changelog text?  Worst short changelog description ever?
> > 
> > There is no change log from original patch, I am not the author, and it
> > is in upstream already. So I think I am not the right person to change
> > its commit log.
> 
> Oh, I didn't mean to complain to you, my complain was to Kent.
> 
> Kent, please go read the section, "The canonical patch format" in the
> Documentation/SubmittingPatches file for how to do this properly.
> 
> > This is the first time I encounter this situation, that send a patch to
> > stable which is not from me. I guess Kent does not notice that this
> > patch indeed fixes a kernel oops. But it does fix a bug report for Leap
> > 42.2 and SLE12-SP2.
> > > 
> > > This gives me no context of what is going on here.  Why does this fix a
> > > bug?  What kernel(s) should it be backported to?
> > > 
> > 
> > The bug is reported on Linux 4.4 based kernel, so at least all kernels
> > since Linux 4.4 should have the fix. Maybe Kent can provide more
> > accurate suggestion.
> 
> Kent, any hints?

Without a response from the maintainer, I can't apply this...

greg k-h

  reply	other threads:[~2017-02-20 12:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-23 13:20 [PATCH] bcache: Make gc wakeup sane, remove set_task_state() colyli
2017-01-23 14:16 ` Greg KH
2017-01-23 14:45   ` Coly Li
2017-01-23 14:54     ` Greg KH
2017-02-20 12:31       ` Greg KH [this message]
2017-02-20 13:12         ` Kent Overstreet
2017-02-20 14:06           ` Greg KH
2017-02-20 14:36             ` Coly Li
2017-02-20 15:19               ` Greg KH

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=20170220123137.GA28408@kroah.com \
    --to=greg@kroah.com \
    --cc=colyli@suse.de \
    --cc=kent.overstreet@gmail.com \
    --cc=stable@vger.kernel.org \
    /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.