All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philip Li <philip.li@intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: kernel test robot <lkp@intel.com>, Christoph Hellwig <hch@lst.de>,
	David Miller <davem@davemloft.net>,
	linux-ide@vger.kernel.org, lkp@01.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [LKP] [ide] ec7d9c9ce8: WARNING:at_fs/proc/generic.c:#remove_proc_entry
Date: Fri, 21 Dec 2018 09:53:52 +0800	[thread overview]
Message-ID: <20181221015352.GA7734@intel.com> (raw)
In-Reply-To: <CAHk-=wjvxCn2uYp7USY5bbVuffJcugusxHc-RU7u5H1=ubMyPw@mail.gmail.com>

On Thu, Dec 20, 2018 at 08:05:28AM -0800, Linus Torvalds wrote:
> On Thu, Dec 20, 2018 at 1:19 AM kernel test robot <lkp@intel.com> wrote:
> >
> > FYI, we noticed the following commit (built with gcc-7):
> >
> > commit: ec7d9c9ce897174243af4fcd201dbfc34df0f3a3 ("ide: replace ->proc_fops with ->proc_show")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> 
> Funky.  How did the kernel test robot suddenly figure out an 8-month
> old problem?
Hi Linus, sorry for this late report. I can't figure out exact reason but some possible clues.

The issue is captured by rcutoture which doesn't work well before. And only from late october,
we have solved a few issues of the execution including the rootfs (yocto) it is using. And this issue
is against an randconfig, i'm not sure whether the issue depends on a certain kconfig thus only
be triggered or successfully bisected this time.

> 
> > [   44.180514] WARNING: CPU: 1 PID: 165 at fs/proc/generic.c:662 remove_proc_entry+0xb9/0x155
> 
> This is a warning for somebody doing "remove_proc_entry() on a name
> that doesn't actually exist in that /proc directory.
> 
> In this case, it does seem to be due to the named commit adding a
> 
> +               remove_proc_entry("settings", drive->proc);
> 
> to ide_proc_unregister_device(), and looking at the patch I get the
> feeling that it's due to a typo: the code *creates* the file called
> "setting", but removes the file "settings". Note the missing "s" at
> creation time.
> 
> And yes, the name of the /proc file _should_be "settings", judging by
> the rest of the patch.
> 
> So it does seem to be a real bug. Nobody noticed until now? Why did
> the test robot suddenly react to it?
> 
>               Linus
> _______________________________________________
> LKP mailing list
> LKP@lists.01.org
> https://lists.01.org/mailman/listinfo/lkp

WARNING: multiple messages have this Message-ID (diff)
From: Philip Li <philip.li@intel.com>
To: lkp@lists.01.org
Subject: Re: [ide] ec7d9c9ce8: WARNING:at_fs/proc/generic.c:#remove_proc_entry
Date: Fri, 21 Dec 2018 09:53:52 +0800	[thread overview]
Message-ID: <20181221015352.GA7734@intel.com> (raw)
In-Reply-To: <CAHk-=wjvxCn2uYp7USY5bbVuffJcugusxHc-RU7u5H1=ubMyPw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]

On Thu, Dec 20, 2018 at 08:05:28AM -0800, Linus Torvalds wrote:
> On Thu, Dec 20, 2018 at 1:19 AM kernel test robot <lkp@intel.com> wrote:
> >
> > FYI, we noticed the following commit (built with gcc-7):
> >
> > commit: ec7d9c9ce897174243af4fcd201dbfc34df0f3a3 ("ide: replace ->proc_fops with ->proc_show")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> 
> Funky.  How did the kernel test robot suddenly figure out an 8-month
> old problem?
Hi Linus, sorry for this late report. I can't figure out exact reason but some possible clues.

The issue is captured by rcutoture which doesn't work well before. And only from late october,
we have solved a few issues of the execution including the rootfs (yocto) it is using. And this issue
is against an randconfig, i'm not sure whether the issue depends on a certain kconfig thus only
be triggered or successfully bisected this time.

> 
> > [   44.180514] WARNING: CPU: 1 PID: 165 at fs/proc/generic.c:662 remove_proc_entry+0xb9/0x155
> 
> This is a warning for somebody doing "remove_proc_entry() on a name
> that doesn't actually exist in that /proc directory.
> 
> In this case, it does seem to be due to the named commit adding a
> 
> +               remove_proc_entry("settings", drive->proc);
> 
> to ide_proc_unregister_device(), and looking at the patch I get the
> feeling that it's due to a typo: the code *creates* the file called
> "setting", but removes the file "settings". Note the missing "s" at
> creation time.
> 
> And yes, the name of the /proc file _should_be "settings", judging by
> the rest of the patch.
> 
> So it does seem to be a real bug. Nobody noticed until now? Why did
> the test robot suddenly react to it?
> 
>               Linus
> _______________________________________________
> LKP mailing list
> LKP(a)lists.01.org
> https://lists.01.org/mailman/listinfo/lkp

  parent reply	other threads:[~2018-12-21  1:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-20  9:19 [ide] ec7d9c9ce8: WARNING:at_fs/proc/generic.c:#remove_proc_entry kernel test robot
2018-12-20  9:19 ` kernel test robot
2018-12-20 16:05 ` Linus Torvalds
2018-12-20 16:05   ` Linus Torvalds
2018-12-20 16:14   ` Jens Axboe
2018-12-20 16:18     ` Christoph Hellwig
2018-12-20 16:18       ` Christoph Hellwig
2018-12-20 16:18       ` Christoph Hellwig
2018-12-21  1:53   ` Philip Li [this message]
2018-12-21  1:53     ` Philip Li

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=20181221015352.GA7734@intel.com \
    --to=philip.li@intel.com \
    --cc=davem@davemloft.net \
    --cc=hch@lst.de \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@01.org \
    --cc=lkp@intel.com \
    --cc=torvalds@linux-foundation.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.