Re: [PATCH] mt76: fix debugfs_simple_attr.cocci warnings

[Fengguang Wu]

Hi Kalle,

On Thu, Dec 07, 2017 at 03:42:39PM +0200, Kalle Valo wrote:

kbuild test robot <l...@intel.com> writes:


drivers/net/wireless/mediatek/mt76/debugfs.c:36:0-23: WARNING: fops_regval 
should be defined with DEFINE_DEBUGFS_ATTRIBUTE

 Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE
 for debugfs files.

Semantic patch information:
 Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file()
 imposes some significant overhead as compared to
 DEFINE_DEBUGFS_ATTRIBUTE + debugfs_create_file_unsafe().

Generated by: scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci

Fixes: a5f6039c8f9c ("mt76: add driver code for MT76x2e")
CC: Felix Fietkau <n...@nbd.name>
Signed-off-by: Fengguang Wu <fengguang...@intel.com>


I would like to apply this but the From field doesn't match the s-o-b
line. This patch is created automatically, right? I think the best is
that if you modify your script to add this to the beginning of the
commit log:

From: Fengguang Wu <fengguang...@intel.com>

That way From and s-o-b match and you can continue to submit it from the
lkp address.


Good idea! I'll follow up with the change.

Thanks,
Fengguang

Re: [run_timer_softirq] BUG: unable to handle kernel paging request at 0000000000010007

[Fengguang Wu]

On Fri, Nov 10, 2017 at 10:29:59PM +0100, Thomas Gleixner wrote:

On Fri, 10 Nov 2017, Linus Torvalds wrote:


On Wed, Nov 8, 2017 at 9:19 PM, Fengguang Wu <fengguang...@intel.com> wrote:
>
> Yes it's accessing the list. Here is the faddr2line output.

Ok, so it's a corrupted timer list. Which is not a big surprise.

It's

next->pprev = pprev;

in __hlist_del(), and the trapping instruction decodes as

mov%rdx,0x8(%rax)

with %rax having the value dead0200,

Which is just LIST_POISON2.

So we've deleted that entry twice - LIST_POISON2 is what hlist_del()
sets pprev to after already deleting it once.

Although in this case it might not be hlist_del(), because
detach_timer() also sets entry->next to LIST_POISON2.

Which is pretty bogus, we are supposed to use LIST_POISON1 for the
"next" pointer. Oh well. Nobody cares, except for the list entry
debugging code, which isn't run on the hlist cases.

Adding Thomas Gleixner to the cc. It should not be possible to delete
the same timer twice.


Right, it shouldn't.

Fengguang, can you please enable:

CONFIG_DEBUG_OBJECTS
CONFIG_DEBUG_OBJECTS_TIMERS

and try to reproduce? Debugobject should catch that hopefully.


Sure. However I've not got any results until now -- it's rather hard
to reproduce. I'll check possible results tomorrow.

Regards,
Fengguang

Re: [run_timer_softirq] BUG: unable to handle kernel paging request at 0000000000010007

[Fengguang Wu]

On Mon, Oct 30, 2017 at 12:29:47PM -0700, Linus Torvalds wrote:

On Sun, Oct 29, 2017 at 4:48 PM, Fengguang Wu <fengguang...@intel.com> wrote:


Here are 3 dmesgs related to wireless and 1 from ethernet.


Fengguang, these would be lovelier still _if_ you have DEBUG_INFO
enabled on the kernel, and your script were to find things like
"symbol+0xhex/0xhex", and run "./scripts/faddr2line" on them.

So


[  235.425464] BUG: unable to handle kernel paging request at 00010007
[  235.425470] IP: run_timer_softirq+0x13a/0x470


would also then have

  run_timer_softirq at timer.c:XYZ

which would make it easier to see exactly _what_ it is that faults. As
it is, I think there's a fair number of inlining that makes it hard to
see the cause, but that faddrtoline would make very obvious.


Good idea and tips! It'll definitely help debug the issues where
bisect cannot help.


Finding that "symbol+xyz/abc" pattern should be fairly easy to
automate, and should fit the 0day model fairly well. No?


Sure. We'll add DEBUG_INFO and automate faddr2line.

Regards,
Fengguang

Re: [linux-stable] 4fc2942b6e kernel BUG at kernel/time/hrtimer.c:109!

[Fengguang Wu]

On Fri, Feb 17, 2017 at 10:09:06AM +, Marc Zyngier wrote:

On 17/02/17 09:28, Thomas Gleixner wrote:

On Fri, 17 Feb 2017, kernel test robot wrote:


Hi Marc,

We find this oops in linux-4.4.y. The gcc-6 compiled mainline kernel is fine.


The last bit is worrying, as mainline has the exact same bug. Has it
been tested the same way?


Nope, mainline is not tested the same way because gcc-4.6 cannot build
a mainline kernel due to gcc-plugin related build errors.

Thanks,
Fengguang

Re: [kbuild-all] drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:58:6: error: redefinition of 'brcmf_debugfs_init'

[Fengguang Wu]

Hi Kalle,

On Thu, Feb 16, 2017 at 03:18:48PM +0200, Kalle Valo wrote:

Arend Van Spriel  writes:


On 16-2-2017 11:01, Kalle Valo wrote:

Arend Van Spriel  writes:


On 16-2-2017 10:39, Rafał Miłecki wrote:

On 02/16/2017 10:31 AM, Kalle Valo wrote:

(Adding linux-wireless)

Arend or Rafał, would you be able to look at this build problem? Kbuild
found the build errors below, apparently a very old issue. It just
blames me now because I moved the driver to a new directory :)


It is a very old issue. The thing is that the issue can not really occur
because we have this:

# common flags
subdir-ccflags-$(CONFIG_BRCMDBG)+= -DDEBUG

in drivers/net/wireless/broadcom/brcm80211/Makefile. So no clue what
happens in the "kbuild test robot" scenario.


I actually tried to reproduce this with kbuild bot's instructions and
was surprised to see that the build worked ok for me. So the issue is
not that simple.


Hi Kalle,

Here is the old email exchange we had about this [1]. In my opinion this
is a Kbuild issue that needs to be looked into.

Regards,
Arend

[1] http://www.spinics.net/lists/linux-wireless/msg142122.html


Heh, I had completely forgotten that we had discussed this before :)

Fengguang and the kbuild bot team, do you have any ideas why only the
bot is seeing this?


I guess the root cause is due to the robot's doing partial builds like
these

   make drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.o
   make drivers/net/wireless/broadcom/brcm80211/brcmfmac/

The solution I come about is to climb up to higher level dirs like 


   make drivers/net/wireless/

which is less likely to have Makefile tricks and still maintain fast
enough build tests.

Thanks,
Fengguang

Re: [kbuild-all] drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:58:6: error: redefinition of 'brcmf_debugfs_init'

[Fengguang Wu]

Hi all,

Yes sorry, it's a false report related to how we do bisects.


CONFIG_BRCM_TRACING=y
CONFIG_BRCMDBG=y

but DEBUG is not defined.

I think it would help if CONFIG_BRCMDBG set DEBUG
or if some of the tests for DEBUG used CONFIG_BRCMDBG instead.


Arend or Rafał, would you be able to look at this build problem? Kbuild
found the build errors below, apparently a very old issue. It just
blames me now because I moved the driver to a new directory :)


It is a very old issue. The thing is that the issue can not really occur
because we have this:

# common flags
subdir-ccflags-$(CONFIG_BRCMDBG)+= -DDEBUG

in drivers/net/wireless/broadcom/brcm80211/Makefile. So no clue what
happens in the "kbuild test robot" scenario.


As an optimization, the robot often does "partial builds" during bisects.
For example, when the error is found in

   drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c

It'll try

   make drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.o

And verify the bisect result with

   make drivers/net/wireless/broadcom/brcm80211/brcmfmac/

However in this case the whole dir is moved, so both logics failed to
give correct results. We'll check how to improve this. Sorry for the
confusions!


I actually tried to reproduce this with kbuild bot's instructions and
was surprised to see that the build worked ok for me. So the issue is
not that simple.


Hi Kalle,

Here is the old email exchange we had about this [1]. In my opinion this
is a Kbuild issue that needs to be looked into.

Regards,
Arend

[1] http://www.spinics.net/lists/linux-wireless/msg142122.html


Thanks,
Fengguang

Re: [PATCH] mac80211_hwsim: Set global RRM capability

[Fengguang Wu]

On Fri, Feb 26, 2016 at 09:17:15AM +0200, Kalle Valo wrote:
> kbuild test robot  writes:
> 
> > Hi David,
> >
> > [auto build test ERROR on wireless-drivers-next/master]
> > [also build test ERROR on v4.5-rc5 next-20160224]
> > [if your patch is applied to the wrong git tree, please drop us a note to 
> > help improving the system]
> >
> > url:
> > https://github.com/0day-ci/linux/commits/Emmanuel-Grumbach/mac80211_hwsim-Set-global-RRM-capability/20160225-172733
> > base:   
> > https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git
> >  master
> > config: sparc64-allyesconfig (attached as .config)
> > reproduce:
> > wget 
> > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> >  -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # save the attached .config to linux build tree
> > make.cross ARCH=sparc64 
> >
> > All errors (new ones prefixed by >>):
> >
> >drivers/net/wireless/mac80211_hwsim.c: In function 
> > 'mac80211_hwsim_new_radio':
> >>> drivers/net/wireless/mac80211_hwsim.c:2462:35: error: 
> >>> 'NL80211_EXT_FEATURE_RRM' undeclared (first use in this function)
> >  wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_RRM);
> >   ^
> >drivers/net/wireless/mac80211_hwsim.c:2462:35: note: each undeclared 
> > identifier is reported only once for each function it appears in
> 
> I think this build failure is because mac80211_hwsim is an exception to
> other wireless drivers and is applied via mac80211-next. Should we add
> an entry for mac80211_hwsim to MAINTAINERS with the correct git tree? I
> think kbuild test robot follows MAINTAINERS file nowdays (or at least I
> understood that's the plan).

That's right. The robot parses MAINTAINERS when judging which tree
to apply LKML patches to.

Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [iwlwifi] BUG: unable to handle kernel

[Fengguang Wu]

On Fri, Dec 19, 2014 at 03:42:17AM +0800, Grumbach, Emmanuel wrote:
 On Thu, 2014-12-18 at 09:13 -0800, Fengguang Wu wrote:
  Hi All,
  
  I don't see any relationship between the BUG and this bisected commit.
  Anyway, it's better to report it to the lists than to ignore.
 
 Right - but I have to say that I have no clue how this comment can cause
 the bug you are seeing...

s?comment?commit?

 Do you even have an Intel Wireless device the VM could access?

Nope. It's simple QEMU virtual machine boot test.

Thanks,
Fengguang

  
  git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git 
  master
  
  commit 03d6c3b0fa4f5f0379cede079ec828a6c999fe43
  Author: Emmanuel Grumbach emmanuel.grumb...@intel.com
  AuthorDate: Wed Dec 3 10:39:07 2014 +0200
  Commit: Emmanuel Grumbach emmanuel.grumb...@intel.com
  CommitDate: Sun Dec 14 10:20:29 2014 +0200
  
  iwlwifi: pcie: re-ACK all interrupts after device reset
  
  When we reset the device, the CSR_INT gets cleared as well
  as CSR_INT_MASK. Meaning that we shouldn't get any interrupt
  but, due to a hardware bug, recent devices will keep sending
  interrupts. This leads to an interrupt storm while stopping
  the device.
  The way to fix this is to ACK all the interrupts after the
  device is reset so that the value of CSR_INT will stay
  0x.
  
  Fixes: 522713c81e4e (iwlwifi: pcie: properly reset the device)
  Signed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
  
  +--++++
  |  | 0a79a0c011 | 03d6c3b0fa | 
  iwlwifi-fi |
  +--++++
  | boot_successes   | 60 | 19 | 3
|
  | boot_failures| 0  | 1  | 9
|
  | BUG:unable_to_handle_kernel  | 0  | 1  | 9
|
  | Oops | 0  | 1  | 9
|
  | RIP:strcmp   | 0  | 1  | 9
|
  | Kernel_panic-not_syncing:Fatal_exception | 0  | 1  | 9
|
  | backtrace:led_trigger_register_simple| 0  | 1  | 9
|
  | backtrace:ledtrig_usb_init   | 0  | 1  | 9
|
  | backtrace:kernel_init_freeable   | 0  | 1  | 9
|
  +--++++
  
  [5.345018] g_serial gadget: Gadget Serial v2.4
  [5.345927] g_serial gadget: g_serial ready
  [5.345927] g_serial gadget: g_serial ready
  [5.346777] BUG: unable to handle kernel 
  [5.346777] BUG: unable to handle kernel paging requestpaging request at 
  8804e5f0
   at 8804e5f0
  [5.348183] IP:
  [5.348183] IP: [81446a68] strcmp+0x6/0x20
   [81446a68] strcmp+0x6/0x20
  [5.349183] PGD 37f1067 
  [5.349183] PGD 37f1067 PUD 37f2067 PUD 37f2067 PMD 37f3067 PMD 37f3067 
  PTE 8004e060PTE 8004e060
  
  [5.350498] Oops:  [#1] 
  [5.350498] Oops:  [#1] DEBUG_PAGEALLOCDEBUG_PAGEALLOC
  
  [5.351360] CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-g03d6c3b #1
  [5.351360] CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-g03d6c3b #1
  [5.352660] task: 88001206 ti: 88001204c000 task.ti: 
  88001204c000
  [5.352660] task: 88001206 ti: 88001204c000 task.ti: 
  88001204c000
  [5.354143] RIP: 0010:[81446a68] 
  [5.354143] RIP: 0010:[81446a68]  [81446a68] 
  strcmp+0x6/0x20
   [81446a68] strcmp+0x6/0x20
  [5.354451] RSP: :88001204fe28  EFLAGS: 00010246
  [5.354451] RSP: :88001204fe28  EFLAGS: 00010246
  [5.354451] RAX:  RBX: 88000c08fe00 RCX: 
  81d35310
  [5.354451] RAX:  RBX: 88000c08fe00 RCX: 
  81d35310
  [5.354451] RDX: 88000c08fe68 RSI: 826d05be RDI: 
  8804e5f0
  [5.354451] RDX: 88000c08fe68 RSI: 826d05be RDI: 
  8804e5f0
  [5.354451] RBP: 88001204fe28 R08: 0001 R09: 
  033a
  [5.354451] RBP: 88001204fe28 R08: 0001 R09: 
  033a
  [5.354451] R10:  R11: 82531cd1 R12: 
  88000c19fa00
  [5.354451] R10:  R11: 82531cd1 R12: 
  88000c19fa00
  [5.354451] R13:  R14: 837958b8 R15: 
  
  [5.354451] R13:  R14: 837958b8 R15: 
  
  [5.354451] FS:  () GS:82789000() 
  knlGS:
  [5.354451] FS:  (

Re: [PATCH] mac80211_hwsim: release driver when ieee80211_register_hw fails

[Fengguang Wu]

On Wed, Oct 29, 2014 at 06:23:02PM +0800, Junjie Mao wrote:
 I was not familiar with the acquiring/releasing API either, until I met
 with this bug...
 
 Perhaps we can use static checkers to avoid these issues as early as
 possible. Any suggestions?

CC Dan. His smatch checker might be able (or could be enabled) to
handle the verification of missing device_release_driver() call.

Thanks,
Fengguang

 Martin Pitt martin.p...@ubuntu.com writes:
 
  Acked-By: Martin Pitt martin.p...@ubuntu.com
 
  Hello Junjie,
 
  Junjie Mao [2014-10-28  9:31 +0800]:
  The driver is not released when ieee80211_register_hw fails in
  mac80211_hwsim_create_radio, leading to the access to the unregistered (and
  possibly freed) device in platform_driver_unregister:
 
  Many thanks for fixing this! Sorry about that, I don't know these bits
  very well.
 
  Martin
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html