All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislaw Gruszka <sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Sid Hayn <sidhayn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-wireless
	<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	nbd-Vt+b4OUoWG0@public.gmane.org,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH v2 00/17] mt76 patches 2018-08-24 v2
Date: Thu, 30 Aug 2018 12:08:50 +0200	[thread overview]
Message-ID: <20180830100848.GA3029@redhat.com> (raw)
In-Reply-To: <CAM0KTbALSzvxagKTtDV7X0G9wtnSEogxNbch046LCsN_rUz4eA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Wed, Aug 29, 2018 at 06:10:01PM +0000, Sid Hayn wrote:
> I rebuilt wireless-testing (which updated today)  with
> CONFIG_DEBUG_KMEMLEAK=y.  I am still able to replicate the issue, and
> presently have 4 devices in the "No space left on device" state.
> 
> This is from /sys/kernel/debug/kmemleak:
> 
> unreferenced object 0xffff9183f9a4d000 (size 2048):
>   comm "iwconfig", pid 14872, jiffies 4295540797 (age 1233.338s)
>   hex dump (first 32 bytes):
>     46 00 00 00 00 00 00 00 05 00 00 00 00 00 00 00  F...............
>     12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>   backtrace:
>     [<000000003ec4c8c4>] sta_set_sinfo+0x5d2/0x890 [mac80211]
>     [<000000008bbf0699>] ieee80211_get_station+0x4b/0x70 [mac80211]
>     [<0000000030cbddbc>] cfg80211_wext_giwrate+0xdb/0x140 [cfg80211]
>     [<000000001e9277be>] ioctl_standard_call+0x49/0xd0
>     [<00000000a0eeae49>] wext_handle_ioctl+0xbe/0x120
>     [<00000000832bf9a4>] sock_ioctl+0x164/0x360
>     [<00000000d3578d89>] do_vfs_ioctl+0xa3/0x6c0
>     [<0000000036a4185e>] ksys_ioctl+0x6b/0x80
>     [<00000000e8443423>] __x64_sys_ioctl+0x11/0x20
>     [<00000000e2ddce89>] do_syscall_64+0x50/0xf0
>     [<000000005d6a8051>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>     [<00000000e724c32b>] 0xffffffffffffffff

I do not see what can leak here. Did you run clear and scan commands,
i.e:

echo clear > /sys/kernel/debug/kmemleak
Run test
echo scan > /sys/kernel/debug/kmemleak
cat /sys/kernel/debug/kmemleak

to get results ? I forgot that this is required (full docs can
be found here: 
https://www.kernel.org/doc/html/v4.16/dev-tools/kmemleak.html).

> None of my scripts directly use iwconfig, but it is possible that
> wpa_supplicant or dhcpcd invoke it (although a grep of their source
> code indicates they do not). In case it matters, this is what my
> wpa_supplicant invokation looks like:
> 
> wpa_supplicant -Dnl80211 -i ${interface} -c test_config/${conffile}
> 
> I am leaving the system in this state for now, I can resume from
> broken or reboot to working for whatever testing you suggest next.
> This is a test rig, so it takes a few but I'm happy to rebuild
> whatever you want however you want it to debug this.

You can move /usr/sbin/iwconfig somewhere and see what will fail,
or remove WEXT support from kernel, perhaps that itself will solve
the problem ;-)

Regards
Stanislaw

WARNING: multiple messages have this Message-ID (diff)
From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Sid Hayn <sidhayn@gmail.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>,
	lorenzo.bianconi@redhat.com, nbd@nbd.name,
	linux-mediatek@lists.infradead.org
Subject: Re: [PATCH v2 00/17] mt76 patches 2018-08-24 v2
Date: Thu, 30 Aug 2018 12:08:50 +0200	[thread overview]
Message-ID: <20180830100848.GA3029@redhat.com> (raw)
In-Reply-To: <CAM0KTbALSzvxagKTtDV7X0G9wtnSEogxNbch046LCsN_rUz4eA@mail.gmail.com>

On Wed, Aug 29, 2018 at 06:10:01PM +0000, Sid Hayn wrote:
> I rebuilt wireless-testing (which updated today)  with
> CONFIG_DEBUG_KMEMLEAK=y.  I am still able to replicate the issue, and
> presently have 4 devices in the "No space left on device" state.
> 
> This is from /sys/kernel/debug/kmemleak:
> 
> unreferenced object 0xffff9183f9a4d000 (size 2048):
>   comm "iwconfig", pid 14872, jiffies 4295540797 (age 1233.338s)
>   hex dump (first 32 bytes):
>     46 00 00 00 00 00 00 00 05 00 00 00 00 00 00 00  F...............
>     12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>   backtrace:
>     [<000000003ec4c8c4>] sta_set_sinfo+0x5d2/0x890 [mac80211]
>     [<000000008bbf0699>] ieee80211_get_station+0x4b/0x70 [mac80211]
>     [<0000000030cbddbc>] cfg80211_wext_giwrate+0xdb/0x140 [cfg80211]
>     [<000000001e9277be>] ioctl_standard_call+0x49/0xd0
>     [<00000000a0eeae49>] wext_handle_ioctl+0xbe/0x120
>     [<00000000832bf9a4>] sock_ioctl+0x164/0x360
>     [<00000000d3578d89>] do_vfs_ioctl+0xa3/0x6c0
>     [<0000000036a4185e>] ksys_ioctl+0x6b/0x80
>     [<00000000e8443423>] __x64_sys_ioctl+0x11/0x20
>     [<00000000e2ddce89>] do_syscall_64+0x50/0xf0
>     [<000000005d6a8051>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>     [<00000000e724c32b>] 0xffffffffffffffff

I do not see what can leak here. Did you run clear and scan commands,
i.e:

echo clear > /sys/kernel/debug/kmemleak
Run test
echo scan > /sys/kernel/debug/kmemleak
cat /sys/kernel/debug/kmemleak

to get results ? I forgot that this is required (full docs can
be found here: 
https://www.kernel.org/doc/html/v4.16/dev-tools/kmemleak.html).

> None of my scripts directly use iwconfig, but it is possible that
> wpa_supplicant or dhcpcd invoke it (although a grep of their source
> code indicates they do not). In case it matters, this is what my
> wpa_supplicant invokation looks like:
> 
> wpa_supplicant -Dnl80211 -i ${interface} -c test_config/${conffile}
> 
> I am leaving the system in this state for now, I can resume from
> broken or reboot to working for whatever testing you suggest next.
> This is a test rig, so it takes a few but I'm happy to rebuild
> whatever you want however you want it to debug this.

You can move /usr/sbin/iwconfig somewhere and see what will fail,
or remove WEXT support from kernel, perhaps that itself will solve
the problem ;-)

Regards
Stanislaw

  parent reply	other threads:[~2018-08-30 10:08 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-27 14:56 [PATCH v2 00/17] mt76 patches 2018-08-24 v2 Stanislaw Gruszka
2018-08-27 14:56 ` Stanislaw Gruszka
     [not found] ` <1535381791-14908-1-git-send-email-sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-08-27 14:56   ` [PATCH v2 01/17] mt76: unify wait_for_mac Stanislaw Gruszka
2018-08-27 14:56     ` Stanislaw Gruszka
2018-08-27 14:56   ` [PATCH v2 02/17] mt76: rename mt76x2_regs.h Stanislaw Gruszka
2018-08-27 14:56     ` Stanislaw Gruszka
2018-08-27 14:56   ` [PATCH v2 03/17] mt76: merge mt76x0/regs.h into mt76x02_regs.h Stanislaw Gruszka
2018-08-27 14:56     ` Stanislaw Gruszka
2018-08-27 14:56   ` [PATCH v2 04/17] mt76: create new mt76x02-lib module for common mt76x{0,2} code Stanislaw Gruszka
2018-08-27 14:56     ` Stanislaw Gruszka
2018-08-27 14:56   ` [PATCH v2 05/17] mt76: fix mt76x02-lib module license Stanislaw Gruszka
2018-08-27 14:56     ` Stanislaw Gruszka
     [not found]     ` <1535381791-14908-6-git-send-email-sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-08-27 19:54       ` Felix Fietkau
2018-08-27 19:54         ` Felix Fietkau
2018-08-27 14:56   ` [PATCH v2 06/17] mt76: unify mac_get_key_info Stanislaw Gruszka
2018-08-27 14:56     ` Stanislaw Gruszka
2018-08-27 14:56   ` [PATCH v2 07/17] mt76: add helpers for register access with mt76_dev struct Stanislaw Gruszka
2018-08-27 14:56     ` Stanislaw Gruszka
2018-08-27 14:56   ` [PATCH v2 08/17] mt76: unify mac_shared_key_setup Stanislaw Gruszka
2018-08-27 14:56     ` Stanislaw Gruszka
2018-08-27 14:56   ` [PATCH v2 09/17] mt76: unify mt76x02_mac_wcid_set_key Stanislaw Gruszka
2018-08-27 14:56     ` Stanislaw Gruszka
2018-08-27 14:56   ` [PATCH v2 10/17] mt76: unify mac_wcid_setup Stanislaw Gruszka
2018-08-27 14:56     ` Stanislaw Gruszka
2018-08-27 14:56   ` [PATCH v2 11/17] mt76: use mac_wcid_set_drop in mt76x0 Stanislaw Gruszka
2018-08-27 14:56     ` Stanislaw Gruszka
2018-08-27 14:56   ` [PATCH v2 12/17] mt76x0: use mt76_wcid_free " Stanislaw Gruszka
2018-08-27 14:56     ` Stanislaw Gruszka
2018-08-27 14:56   ` [PATCH v2 13/17] mt76: unify mt76x02_vif struct Stanislaw Gruszka
2018-08-27 14:56     ` Stanislaw Gruszka
2018-08-27 14:56   ` [PATCH v2 14/17] mt76: unify sta structure part 1 Stanislaw Gruszka
2018-08-27 14:56     ` Stanislaw Gruszka
2018-08-27 14:56   ` [PATCH v2 15/17] mt76: unify sta structure part 2 Stanislaw Gruszka
2018-08-27 14:56     ` Stanislaw Gruszka
2018-08-27 14:56   ` [PATCH v2 16/17] mt76x0: initalize custom tx queues Stanislaw Gruszka
2018-08-27 14:56     ` Stanislaw Gruszka
2018-08-27 14:56   ` [PATCH v2 17/17] mt76x0: use mt76x02_sta and mt76x02_tx_status Stanislaw Gruszka
2018-08-27 14:56     ` Stanislaw Gruszka
2018-08-29  2:26   ` [PATCH v2 00/17] mt76 patches 2018-08-24 v2 Sid Hayn
2018-08-29  2:26     ` Sid Hayn
     [not found]     ` <CAM0KTbB5k54BvA2UOmoss-PuGtgHE_SGy2cG4n4ROxPH7kxYXA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-08-29 10:27       ` Stanislaw Gruszka
2018-08-29 10:27         ` Stanislaw Gruszka
     [not found]         ` <20180829102737.GA20763-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-08-29 18:10           ` Sid Hayn
2018-08-29 18:10             ` Sid Hayn
     [not found]             ` <CAM0KTbALSzvxagKTtDV7X0G9wtnSEogxNbch046LCsN_rUz4eA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-08-30 10:08               ` Stanislaw Gruszka [this message]
2018-08-30 10:08                 ` Stanislaw Gruszka
2018-09-01  7:47       ` Stanislaw Gruszka
2018-09-01  7:47         ` Stanislaw Gruszka
     [not found]         ` <20180901074757.GB3719-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-09-03  2:45           ` Sid Hayn
2018-09-03  2:45             ` Sid Hayn

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=20180830100848.GA3029@redhat.com \
    --to=sgruszka-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=nbd-Vt+b4OUoWG0@public.gmane.org \
    --cc=sidhayn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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.