* Re: [PATCH 1/2] b43: fix unitialized reads of ret by initializing the array to zero
From: Michael Büsch @ 2017-09-05 20:18 UTC (permalink / raw)
To: Colin King
Cc: Kalle Valo, linux-wireless, b43-dev, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20170905181550.23839-1-colin.king@canonical.com>
[-- Attachment #1: Type: text/plain, Size: 1434 bytes --]
On Tue, 5 Sep 2017 19:15:50 +0100
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The u8 char array ret is not being initialized and elements outside
> the range start to end contain just garbage values from the stack.
> This results in a later scan of the array to read potentially
> uninitialized values. Fix this by initializing the array to zero.
> This seems to have been an issue since the very first commit.
>
> Detected by CoverityScan CID#139652 ("Uninitialized scalar variable")
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/net/wireless/broadcom/b43/phy_g.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/b43/phy_g.c b/drivers/net/wireless/broadcom/b43/phy_g.c
> index 822dcaa8ace6..f59c02166462 100644
> --- a/drivers/net/wireless/broadcom/b43/phy_g.c
> +++ b/drivers/net/wireless/broadcom/b43/phy_g.c
> @@ -2297,7 +2297,7 @@ static u8 b43_gphy_aci_detect(struct b43_wldev *dev, u8 channel)
> static u8 b43_gphy_aci_scan(struct b43_wldev *dev)
> {
> struct b43_phy *phy = &dev->phy;
> - u8 ret[13];
> + u8 ret[13] = { 0 };
> unsigned int channel = phy->channel;
> unsigned int i, j, start, end;
>
This fix seems to be correct.
Thanks for finding and fixing the issue.
Reviewed-by: Michael Buesch <m@bues.ch>
--
Michael
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v5] brcmfmac: add CLM download support
From: Arend van Spriel @ 2017-09-05 20:03 UTC (permalink / raw)
To: Wright Feng, franky.lin, hante.meuleman, kvalo, chi-hsien.lin
Cc: linux-wireless, brcm80211-dev-list.pdl, Chung-Hsien Hsu
In-Reply-To: <1503987821-6132-1-git-send-email-wright.feng@cypress.com>
On 29-08-17 08:23, Wright Feng wrote:
> From: Chung-Hsien Hsu <stanley.hsu@cypress.com>
>
> The firmware for brcmfmac devices includes information regarding
> regulatory constraints. For certain devices this information is kept
> separately in a binary form that needs to be downloaded to the device.
> This patch adds support to download this so-called CLM blob file. It
> uses the same naming scheme as the other firmware files with extension
> of .clm_blob.
>
> The CLM blob file is optional. If the file does not exist, the download
> process will be bypassed. It will not affect the driver loading.
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com>
> ---
> v2: Revise commit message to describe in more detail
> v3: Add error handling in brcmf_c_get_clm_name function
> v4: Correct the length of dload_buf in brcmf_c_download function
> v5: Remove unnecessary cast and alignment
> ---
> .../net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 10 ++
> .../wireless/broadcom/brcm80211/brcmfmac/common.c | 160 +++++++++++++++++++++
> .../wireless/broadcom/brcm80211/brcmfmac/core.c | 2 +
> .../wireless/broadcom/brcm80211/brcmfmac/core.h | 2 +
> .../broadcom/brcm80211/brcmfmac/fwil_types.h | 31 ++++
> .../wireless/broadcom/brcm80211/brcmfmac/pcie.c | 19 +++
> .../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 19 +++
> .../net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 18 +++
> 8 files changed, 261 insertions(+)
[...]
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> index 7a2b495..f6268e0 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> @@ -18,6 +18,7 @@
> #include <linux/string.h>
> #include <linux/netdevice.h>
> #include <linux/module.h>
> +#include <linux/firmware.h>
> #include <brcmu_wifi.h>
> #include <brcmu_utils.h>
> #include "core.h"
> @@ -28,6 +29,7 @@
> #include "tracepoint.h"
> #include "common.h"
> #include "of.h"
> +#include "firmware.h"
You are not calling anything in firmware.c from this source file so I do
not think you need to include firmware.h here. Or did I miss something?
> MODULE_AUTHOR("Broadcom Corporation");
> MODULE_DESCRIPTION("Broadcom 802.11 wireless LAN fullmac driver.");
> @@ -104,12 +106,138 @@ void brcmf_c_set_joinpref_default(struct brcmf_if *ifp)
> brcmf_err("Set join_pref error (%d)\n", err);
> }
[...]
> +static int brcmf_c_process_clm_blob(struct brcmf_if *ifp)
> +{
> + struct device *dev = ifp->drvr->bus_if->dev;
> + struct brcmf_dload_data_le *chunk_buf;
> + const struct firmware *clm = NULL;
> + u8 clm_name[BRCMF_FW_NAME_LEN];
> + u32 chunk_len;
> + u32 datalen;
> + u32 cumulative_len = 0;
> + u16 dl_flag = DL_BEGIN;
> + u32 status;
> + s32 err;
> +
> + brcmf_dbg(INFO, "Enter\n");
Please use TRACE level for function entry logging.
> + memset(clm_name, 0, BRCMF_FW_NAME_LEN);
> + err = brcmf_c_get_clm_name(ifp, clm_name);
> + if (err) {
> + brcmf_err("get CLM blob file name failed (%d)\n", err);
> + return err;
> + }
> +
> + err = request_firmware(&clm, clm_name, dev);
> + if (err) {
> + if (err == -ENOENT)
> + return 0;
This exit point is worth a comment or even a brcmf_dbg(INFO, ...) to
clarify what is happening here, ie. continue with CLM data currently
present in firmware.
> + brcmf_err("request CLM blob file failed (%d)\n", err);
> + return err;
> + }
> +
> + datalen = clm->size;
move this initialization just before the do-while loop.
> + chunk_buf = kzalloc(sizeof(*chunk_buf) + MAX_CHUNK_LEN - 1, GFP_KERNEL);
> + if (!chunk_buf) {
> + err = -ENOMEM;
> + goto done;
> + }
initialize datalen and cumulative_len here.
> + do {
> + if (datalen > MAX_CHUNK_LEN) {
> + chunk_len = MAX_CHUNK_LEN;
> + } else {
> + chunk_len = datalen;
> + dl_flag |= DL_END;
> + }
> + memcpy(chunk_buf->data, clm->data + cumulative_len, chunk_len);
> +
> + err = brcmf_c_download(ifp, dl_flag, chunk_buf, chunk_len);
> +
> + dl_flag &= ~DL_BEGIN;
> +
> + cumulative_len += chunk_len;
> + datalen -= chunk_len;
> + } while ((datalen > 0) && (err == 0));
> +
> + if (err) {
> + brcmf_err("clmload (%d byte file) failed (%d); ",
> + (u32)clm->size, err);
Instead of casting clm->size it seems better to use the proper format
specifier, ie. %zu (see format_decode() [1]).
> + /* Retrieve clmload_status and print */
> + err = brcmf_fil_iovar_int_get(ifp, "clmload_status", &status);
> + if (err)
> + brcmf_err("get clmload_status failed (%d)\n", err);
> + else
> + brcmf_dbg(INFO, "clmload_status=%d\n", status);
> + err = -EIO;
> + }
> +
> + kfree(chunk_buf);
> +done:
> + release_firmware(clm);
> + return err;
> +}
> +
^ permalink raw reply
* Re: [PATCH] brcmfmac: return -EPERM when getting error in vendor command handler
From: Franky Lin @ 2017-09-05 20:02 UTC (permalink / raw)
To: Wright Feng
Cc: Arend Van Spriel, Hante Meuleman, Kalle Valo, Chi-Hsien Lin,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER
In-Reply-To: <1504510473-13549-1-git-send-email-wright.feng@cypress.com>
On Mon, Sep 4, 2017 at 12:34 AM, Wright Feng <wright.feng@cypress.com> wrote:
> Firmware returns proprietary error code when getting error in
> fil_cmd_data_set or fil_cmd_data_get. The vendor tools or
> utilities which uses libnl may stuck in some commands when wl is down.
> For example, issue "scan" command after issuing "down" command, the
> "scan" command will be the blocking call and stuck as no response from
> libnl. It is caused by that firmware returns BCME_NOTUP(-4) when wl
> is down, but the -4 is -EINTR in Linux kernel, so libnl catches the error
> and not passes to upper layer.
> Because of that, the driver should return Linux error code instead of the
> proprietary error code, and the tools or utilities need to get the real
> firmware error code by command "bcmerror" or "bcmerrorstr" after receiving
> the error.
>
> Signed-off-by: Wright Feng <wright.feng@cypress.com>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
> index 8eff275..2b88ba1 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
> @@ -80,8 +80,12 @@ static int brcmf_cfg80211_vndr_cmds_dcmd_handler(struct wiphy *wiphy,
> else
> ret = brcmf_fil_cmd_data_get(ifp, cmdhdr->cmd, dcmd_buf,
> ret_len);
> - if (ret != 0)
> +
> + if (ret != 0) {
> + brcmf_dbg(INFO, "error(%d), return -EPERM\n", ret);
> + ret = -EPERM;
> goto exit;
> + }
It would be better to handle the conversion in brcmf_fil_cmd_data so
everyone can benefit. Also please try to assign an appropriate error
code when possible to provide more information to the upper layer. For
this case "ENETDOWN" seems to be a better fit for BCME_NOTUP.
Thanks,
Franky
> wr_pointer = dcmd_buf;
> while (ret_len > 0) {
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH v5] brcmfmac: add CLM download support
From: Arend van Spriel @ 2017-09-05 19:31 UTC (permalink / raw)
To: Chung-Hsien Hsu
Cc: franky.lin, hante.meuleman, kvalo, chi-hsien.lin, linux-wireless,
brcm80211-dev-list.pdl, wright.feng
In-Reply-To: <20170904113324.GA126340@aremote01.aus.cypress.com>
On 04-09-17 13:33, Chung-Hsien Hsu wrote:
> On Tue, Aug 29, 2017 at 02:23:41PM +0800, Wright Feng wrote:
>> From: Chung-Hsien Hsu <stanley.hsu@cypress.com>
>>
>> The firmware for brcmfmac devices includes information regarding
>> regulatory constraints. For certain devices this information is kept
>> separately in a binary form that needs to be downloaded to the device.
>> This patch adds support to download this so-called CLM blob file. It
>> uses the same naming scheme as the other firmware files with extension
>> of .clm_blob.
>>
>> The CLM blob file is optional. If the file does not exist, the download
>> process will be bypassed. It will not affect the driver loading.
>>
>> Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com>
>> ---
>> v2: Revise commit message to describe in more detail
>> v3: Add error handling in brcmf_c_get_clm_name function
>> v4: Correct the length of dload_buf in brcmf_c_download function
>> v5: Remove unnecessary cast and alignment
>> ---
>> .../net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 10 ++
>> .../wireless/broadcom/brcm80211/brcmfmac/common.c | 160 +++++++++++++++++++++
>> .../wireless/broadcom/brcm80211/brcmfmac/core.c | 2 +
>> .../wireless/broadcom/brcm80211/brcmfmac/core.h | 2 +
>> .../broadcom/brcm80211/brcmfmac/fwil_types.h | 31 ++++
>> .../wireless/broadcom/brcm80211/brcmfmac/pcie.c | 19 +++
>> .../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 19 +++
>> .../net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 18 +++
>> 8 files changed, 261 insertions(+)
>
> Hi Arend,
>
> Do you think this patch is ready to be merged or is there something more
> to change?
Ultimately it is not my decision, but I will respond to it.
Regards,
Arend
^ permalink raw reply
* Re: 915f3e3f76 ("mac80211_hwsim: Replace bogus hrtimer clockid"): BUG: kernel reboot-without-warning in test stage
From: Thomas Gleixner @ 2017-09-05 19:30 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: kernel test robot, LKP, linux-kernel, netdev, linux-wireless, wfg
In-Reply-To: <20170905164103.tkrhxzca4b5ulps2@breakpoint.cc>
On Tue, 5 Sep 2017, Sebastian Andrzej Siewior wrote:
> On 2017-09-05 09:12:40 [+0200], Thomas Gleixner wrote:
> > Sorry, no. That bisect is completely bogus. The commit in question merily
> > replaces the unsupported clockid with a valid one.
>
> The bisect is correct. It just has problems to express itself properly. So
> the table says:
>
> | WARNING:at_kernel/time/hrtimer.c:#hrtimer_init | 7 | | | |
> | BUG:kernel_reboot-without-warning_in_test_stage | 0 | 12 | 6 | 6 |
>
> which means _before_ your commit it counted a warning in hrtimer_init()
> (an unsupported clock id was used). With your commit, the warning was
> gone and I *think* the userland then printed
> "BUG:kernel_reboot-without-warning_in_test_stage" because it had no
> warning.
> It seems that the bot learned to live with that warning which was around
> for more than three years. Now that you removed it, it seems to be a
> mistake to do so because nobody complained about it so far.
Thanks for the translation. I'll never learn to decode these reports.
tglx
^ permalink raw reply
* [PATCH 2/2] b43legacy: fix unitialized reads of ret by initializing the array to zero
From: Colin King @ 2017-09-05 18:16 UTC (permalink / raw)
To: Larry Finger, Kalle Valo, linux-wireless, b43-dev, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The u8 char array ret is not being initialized and elements outside
the range start to end contain just garbage values from the stack.
This results in a later scan of the array to read potentially
uninitialized values. Fix this by initializing the array to zero.
This seems to have been an issue since the very first commit.
Detected by CoverityScan CID#139653 ("Uninitialized scalar variable")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/broadcom/b43legacy/radio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/b43legacy/radio.c b/drivers/net/wireless/broadcom/b43legacy/radio.c
index 9501420340a9..eab1c9387846 100644
--- a/drivers/net/wireless/broadcom/b43legacy/radio.c
+++ b/drivers/net/wireless/broadcom/b43legacy/radio.c
@@ -280,7 +280,7 @@ u8 b43legacy_radio_aci_detect(struct b43legacy_wldev *dev, u8 channel)
u8 b43legacy_radio_aci_scan(struct b43legacy_wldev *dev)
{
struct b43legacy_phy *phy = &dev->phy;
- u8 ret[13];
+ u8 ret[13] = { 0 };
unsigned int channel = phy->channel;
unsigned int i;
unsigned int j;
--
2.14.1
^ permalink raw reply related
* [PATCH 1/2] b43: fix unitialized reads of ret by initializing the array to zero
From: Colin King @ 2017-09-05 18:15 UTC (permalink / raw)
To: Kalle Valo, linux-wireless, b43-dev, netdev; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The u8 char array ret is not being initialized and elements outside
the range start to end contain just garbage values from the stack.
This results in a later scan of the array to read potentially
uninitialized values. Fix this by initializing the array to zero.
This seems to have been an issue since the very first commit.
Detected by CoverityScan CID#139652 ("Uninitialized scalar variable")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/broadcom/b43/phy_g.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/b43/phy_g.c b/drivers/net/wireless/broadcom/b43/phy_g.c
index 822dcaa8ace6..f59c02166462 100644
--- a/drivers/net/wireless/broadcom/b43/phy_g.c
+++ b/drivers/net/wireless/broadcom/b43/phy_g.c
@@ -2297,7 +2297,7 @@ static u8 b43_gphy_aci_detect(struct b43_wldev *dev, u8 channel)
static u8 b43_gphy_aci_scan(struct b43_wldev *dev)
{
struct b43_phy *phy = &dev->phy;
- u8 ret[13];
+ u8 ret[13] = { 0 };
unsigned int channel = phy->channel;
unsigned int i, j, start, end;
--
2.14.1
^ permalink raw reply related
* Re: Bug Report for iwlwifi kernel module
From: Luca Coelho @ 2017-09-05 17:19 UTC (permalink / raw)
To: Carl Myers; +Cc: linux-wireless, linuxwifi
In-Reply-To: <20170905165112.GF7829@cmyers.org>
On Tue, 2017-09-05 at 09:51 -0700, Carl Myers wrote:
> Hi Luca,
>
> On Mon, Sep 04, 2017 at 10:34:37AM +0300, Luca Coelho wrote:
> > Date: Mon, 04 Sep 2017 10:34:37 +0300
> > From: Luca Coelho <luca@coelho.fi>
> > To: Carl Myers <cmyers@cmyers.org>, linux-wireless@vger.kernel.org
> > Cc: linuxwifi@intel.com
> > Subject: Re: Bug Report for iwlwifi kernel module
> >
> > Hi Carl,
> >
> > On Sun, 2017-09-03 at 12:15 -0700, Carl Myers wrote:
> > > Greetings all,
> > >
> > > Apologies if any of this is wrong, this is my first attempt to report a bug in
> > > the linux kernel =)
> > >
> > > I got here by running the get_maintainer script on the iwlwifi directory of a
> > > linux kernel checkout.
> > >
> > > I am running debian stock kernel 4.8.15, and using the built in iwlwifi
> > > driver
> > >
> > > $⮀ uname -a
> > > Linux powerhouse 4.8.0-2-amd64 #1 SMP Debian 4.8.15-2 (2017-01-04) x86_64 GNU/Linux
> > > $⮀ dpkg -l | grep iwlwifi
> > > ii firmware-iwlwifi 20160110-1~bpo8+1 all Binary firmware for Intel Wireless cards
> > >
> > > I am on a slightly older firmware and kernel due to the currently-outstanding bug:
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849330
> > >
> > > This is the newest combination of kernel/firmware I've been able to make work.
> > >
> > > Here is the lspci -v output for my wifi:
> > > 03:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
> > > Subsystem: Intel Corporation Wireless 8260
> > > Flags: bus master, fast devsel, latency 0, IRQ 136
> > > Memory at df200000 (64-bit, non-prefetchable) [size=8K]
> > > Capabilities: <access denied>
> > > Kernel driver in use: iwlwifi
> > > Kernel modules: iwlwifi
> >
> > First of all, what makes you think this is a bug in the iwlwifi driver
> > module?
> >
> >
>
> Ok, good question. It's been giving me problems and I was mucking with it.
> Every so often, my wifi just quits working and I have a script that unloads and
> reloads the module, whih generally fixes it for a time. I thought it was likely
> the cause because I was messing with it at the time and it was first in the list
> of modules, but now that you mention it, I guess it was only listed first
> because it was recently removed and re-added.
Okay, you should report those bugs to us so we can fix them. https://bu
gzilla.kernel.org is your friend. :)
> > > Recently, while testing a 2nd panda wifi card (trying to make a hotspot and use
> > > the iwl card as a gateway device), I got a kernel panic. Here is the relevant
> > > excerpt from kern.log:
> > >
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510512] ------------[ cut here ]------------
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510514] kernel BUG at /build/linux-zDY19G/linux-4.8.15/kernel/module.c:890!
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510515] invalid opcode: 0000 [#1] SMP
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510516] Modules linked in: iwlmvm iwlwifi ipt_REJECT nf_reject_ipv4 xt_tcpudp nf_nat_h323 nf_conntrack_h323 nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_tftp nf_conntrack_tftp nf_nat_sip nf_conntrack_sip nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp hid_generic rt2800usb rt2x00usb rt2800lib rt2x00lib crc_ccitt ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype xt_conntrack nf_nat nf_conntrack br_netfilter bridge stp overlay iptable_filter appletalk ax25 ipx p8023 p8022 psnap llc bnep snd_hda_codec_hdmi arc4 binfmt_misc nls_ascii nls_cp437 vfat fat mac80211 snd_hda_codec_realtek intel_rapl x86_pkg_temp_thermal mxm_wmi intel_powerclamp coretemp snd_hda_codec_generic kvm_intel kvm efi_pstore irqbypass snd_hda_intel intel_cstate snd_hda_codec uvcvideo videobuf2_vmalloc rtsx_pci_ms videobuf2_memops snd_hda_core videobuf2_v4l2 iTCO_wdt videobuf2_core snd_hwdep intel_uncore videodev joydev btusb intel_rapl_perf evdev media btrtl cfg80211 serio_raw pcspkr efivars memstick iTCO_vendor_support snd_pcm snd_timer mei_me hci_uart snd mei soundcore btbcm btqca btintel bluetooth rfkill wmi video intel_lpss_acpi intel_lpss shpchp battery acpi_pad ac tpm_tis button tpm_tis_core tpm nvidia_drm(POE) drm_kms_helper drm nvidia_modeset(POE) nvidia(POE) parport_pc ppdev lp parport efivarfs ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb mbcache algif_skcipher af_alg dm_crypt dm_mod hid_logitech_hidpp hid_logitech_dj usbhid rtsx_pci_sdmmc mmc_core crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel ahci libahci aes_x86_64 lrw gf128mul glue_helper xhci_pci ablk_helper cryptd libata xhci_hcd psmouse usbcore nvme scsi_mod i2c_i801 nvme_core i2c_smbus rtsx_pci r8169 mii mfd_core usb_common thermal i2c_hid hid fjes [last unloaded: iwlwifi]
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510561] CPU: 4 PID: 8122 Comm: rmmod Tainted: P R OE 4.8.0-2-amd64 #1 Debian 4.8.15-2
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510562] Hardware name: System76, Inc. Oryx Pro/Oryx Pro, BIOS 1.05.09RSA1 11/16/2015
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510563] task: ffff8dec4a3e0000 task.stack: ffff8decf4cd4000
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510564] RIP: 0010:[<ffffffffbccf98b9>] [<ffffffffbccf98b9>] SyS_delete_module+0x259/0x260
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510568] RSP: 0018:ffff8decf4cd7ef0 EFLAGS: 00010297
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510569] RAX: 00000000ffffffff RBX: ffffffffc1aa71c0 RCX: 0000000000000005
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510570] RDX: ffffffffc1aa74a0 RSI: ffffffffc1aa74c8 RDI: ffffffffc1aa71d8
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510571] RBP: 000055fb472021f0 R08: 0000000000000000 R09: 000000000000006d
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510572] R10: 000055fb472011c0 R11: 8080808080808080 R12: 0000000000000a00
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510572] R13: 0000000000000a00 R14: 00007fff6cd8d4f8 R15: 0000000000000000
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510573] FS: 00007f498ef22700(0000) GS:ffff8ded76500000(0000) knlGS:0000000000000000
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510574] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510575] CR2: 00007f498eacf801 CR3: 0000000fa99d0000 CR4: 00000000003406e0
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510576] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510576] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510577] Stack:
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510578] 00006d766d6c7769 0000000000000002 ffff8decf4cd4000 ffffffffbcc03290
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510579] ffff8decf4cd7f58 ffff8decf4cd4000 0000000000000050 00000000520cd409
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510581] 00007fff6cd8d338 000055fb472021f0 00007fff6cd8d508 00007fff6cd8ebbb
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510582] Call Trace:
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510586] [<ffffffffbcc03290>] ? exit_to_usermode_loop+0xa0/0xc0
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510588] [<ffffffffbd1e8cb6>] ? system_call_fast_compare_end+0xc/0x96
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510588] Code: fe ff ff 41 f7 c4 00 02 00 00 48 c7 c5 f0 ff ff ff 0f 84 5c fe ff ff be 01 00 00 00 bf 03 00 00 00 e8 0c b3 f7 ff e9 b7 fe ff ff <0f> 0b e8 90 b4 f7 ff 0f 1f 44 00 00 31 c0 c3 0f 1f 84 00 00 00
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510605] RIP [<ffffffffbccf98b9>] SyS_delete_module+0x259/0x260
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510607] RSP <ffff8decf4cd7ef0>
> > > Sep 3 11:37:49 powerhouse kernel: [21394.510608] ---[ end trace 5b24b93b49e857eb ]---
> > > Sep 3 11:37:49 powerhouse kernel: [21409.372738] ieee80211 phy3: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x0438 with error -110
> > > Sep 3 11:38:05 powerhouse kernel: [21425.406196] INFO: rcu_sched detected stalls on CPUs/tasks:
> > > Sep 3 11:38:20 powerhouse kernel: [21425.406201] 4-...: (0 ticks this GP) idle=02d/140000000000000/0 softirq=277173/277173 fqs=8
> > > Sep 3 11:38:20 powerhouse kernel: [21425.406202] (detected by 7, t=7721 jiffies, g=246559, c=246558, q=936)
> > > Sep 3 11:38:20 powerhouse kernel: [21425.406204] Task dump for CPU 4:
> > > Sep 3 11:38:20 powerhouse kernel: [21425.406206] rmmod R running task 0 8122 8121 0x00000008
> > > Sep 3 11:38:20 powerhouse kernel: [21425.406209] 0000000000000002 ffff8decf4cd7e48 ffffffffbd3df853 0000000000000000
> > > Sep 3 11:38:20 powerhouse kernel: [21425.406211] 0000000000000000 ffffffffbcccc3d3 0000000000000246 000000000000000b
> > > Sep 3 11:38:20 powerhouse kernel: [21425.406214] ffffffffbcc289f8 0000000000000006 ffff8decf4cd7e48 0000000000000004
> > > Sep 3 11:38:20 powerhouse kernel: [21425.406216] Call Trace:
> > > Sep 3 11:38:20 powerhouse kernel: [21425.406222] [<ffffffffbcccc3d3>] ? kmsg_dump+0x93/0xb0
> > > Sep 3 11:38:20 powerhouse kernel: [21425.406225] [<ffffffffbcc289f8>] ? oops_end+0x78/0xd0
> > > Sep 3 11:38:20 powerhouse kernel: [21425.406228] [<ffffffffbcc26446>] ? do_error_trap+0x86/0x100
> > > Sep 3 11:38:20 powerhouse kernel: [21425.406976] [<ffffffffbccf98b9>] ? SyS_delete_module+0x259/0x260
> > > Sep 3 11:38:20 powerhouse kernel: [21425.406979] [<ffffffffbcdda242>] ? kmem_cache_alloc+0x122/0x530
> > > Sep 3 11:38:20 powerhouse kernel: [21425.406982] [<ffffffffbd1e9a2e>] ? invalid_op+0x1e/0x30
> > > Sep 3 11:38:20 powerhouse kernel: [21425.407276] [<ffffffffbccf98b9>] ? SyS_delete_module+0x259/0x260
> > > Sep 3 11:38:20 powerhouse kernel: [21425.407277] perf: interrupt took too long (8612 > 2500), lowering kernel.perf_event_max_sample_rate to 23000
> > > Sep 3 11:3Sep 3 11:39:51 powerhouse kernel: [ 0.000000] Linux version 4.8.0-2-amd64 (debian-kernel@lists.debian.org) (gcc version 5.4.1 20161202 (Debian 5.4.1-4) ) #1 SMP Debian 4.8.15-2 (2017-01-04)
> > > Sep 3 11:39:51 powerhouse kernel: [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.8.0-2-amd64 root=/dev/mapper/powerhouse--vg-root ro quiet
> > >
> > > Obviously, I'm not certain the bug is in this kernel module or even has
> > > anything to do with it, but I thought this was a good place to start. Advice
> > > welcome, happy to help however I can, I am a software engineer but not very
> > > experienced at kernel hacking.
> >
> > The bug you're seeing is happening in the module removal code[1].
> > Apparently the system is getting a bad value in refcnt and it's becoming
> > negative, which should never happen. Have you been trying to force-
> > remove modules or something like that?
> >
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/kernel/module.c?h=linux-4.8.y#n890
> >
> > In any case, this doesn't seem like a iwlwifi bug at all.
> >
> > HTH.
>
> Yeeeeahh, I don't normally force-remove it, but now that you mention it I did
> have to force remove it earlier that day, I think, I think I hadn't rebooted
> since that. So that very well could be the cause. I guess if you do things
> like force-remove kernel modules, then the results aren't necessarily a bug,
> huh? =)
Right, force-removing a module is evil and you should never really do
it, unless you *really* know what you are doing. And even then, don't
do it. :)
It's better to reboot completely rather than force-remove a module. If
the shutdown itself gets stuck, then maybe you can force-remove the
module that is holding it.
> That was very helpful, thanks very much for your time!
You're welcome! I'm glad I could help.
> I'd love to figure out how to make this module more stable for me, but I'm not
> sure where to even get started, and since I am on old firmware (due to the
> previously mentioned bug), I'm not sure it's worth poking until I can get on the
> tip version first.
v4.8 is old but not ancient and we will certainly still try to debug it
if someone is seeing failures. The worst that can happen is that we
will tell you to upgrade your kernel.
You can't imagine what kind of ancient kernels people sometimes use.
Some of them are the same version that Tutankhamun had installed in his
hieroglyphs tablet. :D
A good place to start is our wikipage[1]. You can find a lot of
information on how to help us help you debug the iwlwifi driver. An
even simpler start is to send us dmesg so we can have an initial idea of
what is going on.
[1] https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging
--
Cheers,
Luca.
>
^ permalink raw reply
* Re: Bug Report for iwlwifi kernel module
From: Carl Myers @ 2017-09-05 16:51 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <1504510477.5400.23.camel@coelho.fi>
[-- Attachment #1: Type: text/plain, Size: 11783 bytes --]
Hi Luca,
On Mon, Sep 04, 2017 at 10:34:37AM +0300, Luca Coelho wrote:
> Date: Mon, 04 Sep 2017 10:34:37 +0300
> From: Luca Coelho <luca@coelho.fi>
> To: Carl Myers <cmyers@cmyers.org>, linux-wireless@vger.kernel.org
> Cc: linuxwifi@intel.com
> Subject: Re: Bug Report for iwlwifi kernel module
>
> Hi Carl,
>
> On Sun, 2017-09-03 at 12:15 -0700, Carl Myers wrote:
> > Greetings all,
> >
> > Apologies if any of this is wrong, this is my first attempt to report a bug in
> > the linux kernel =)
> >
> > I got here by running the get_maintainer script on the iwlwifi directory of a
> > linux kernel checkout.
> >
> > I am running debian stock kernel 4.8.15, and using the built in iwlwifi
> > driver
> >
> > $⮀ uname -a
> > Linux powerhouse 4.8.0-2-amd64 #1 SMP Debian 4.8.15-2 (2017-01-04) x86_64 GNU/Linux
> > $⮀ dpkg -l | grep iwlwifi
> > ii firmware-iwlwifi 20160110-1~bpo8+1 all Binary firmware for Intel Wireless cards
> >
> > I am on a slightly older firmware and kernel due to the currently-outstanding bug:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849330
> >
> > This is the newest combination of kernel/firmware I've been able to make work.
> >
> > Here is the lspci -v output for my wifi:
> > 03:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
> > Subsystem: Intel Corporation Wireless 8260
> > Flags: bus master, fast devsel, latency 0, IRQ 136
> > Memory at df200000 (64-bit, non-prefetchable) [size=8K]
> > Capabilities: <access denied>
> > Kernel driver in use: iwlwifi
> > Kernel modules: iwlwifi
>
> First of all, what makes you think this is a bug in the iwlwifi driver
> module?
>
>
Ok, good question. It's been giving me problems and I was mucking with it.
Every so often, my wifi just quits working and I have a script that unloads and
reloads the module, whih generally fixes it for a time. I thought it was likely
the cause because I was messing with it at the time and it was first in the list
of modules, but now that you mention it, I guess it was only listed first
because it was recently removed and re-added.
> > Recently, while testing a 2nd panda wifi card (trying to make a hotspot and use
> > the iwl card as a gateway device), I got a kernel panic. Here is the relevant
> > excerpt from kern.log:
> >
> > Sep 3 11:37:49 powerhouse kernel: [21394.510512] ------------[ cut here ]------------
> > Sep 3 11:37:49 powerhouse kernel: [21394.510514] kernel BUG at /build/linux-zDY19G/linux-4.8.15/kernel/module.c:890!
> > Sep 3 11:37:49 powerhouse kernel: [21394.510515] invalid opcode: 0000 [#1] SMP
> > Sep 3 11:37:49 powerhouse kernel: [21394.510516] Modules linked in: iwlmvm iwlwifi ipt_REJECT nf_reject_ipv4 xt_tcpudp nf_nat_h323 nf_conntrack_h323 nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_tftp nf_conntrack_tftp nf_nat_sip nf_conntrack_sip nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp hid_generic rt2800usb rt2x00usb rt2800lib rt2x00lib crc_ccitt ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype xt_conntrack nf_nat nf_conntrack br_netfilter bridge stp overlay iptable_filter appletalk ax25 ipx p8023 p8022 psnap llc bnep snd_hda_codec_hdmi arc4 binfmt_misc nls_ascii nls_cp437 vfat fat mac80211 snd_hda_codec_realtek intel_rapl x86_pkg_temp_thermal mxm_wmi intel_powerclamp coretemp snd_hda_codec_generic kvm_intel kvm efi_pstore irqbypass snd_hda_intel intel_cstate snd_hda_codec uvcvideo videobuf2_vmalloc rtsx_pci_ms videobuf2_memops snd_hda_core videobuf2_v4l2 iTCO_wdt videobuf2_core snd_hwdep intel_uncore videodev joydev btusb intel_rapl_perf evdev media btrtl cfg80211 serio_raw pcspkr efivars memstick iTCO_vendor_support snd_pcm snd_timer mei_me hci_uart snd mei soundcore btbcm btqca btintel bluetooth rfkill wmi video intel_lpss_acpi intel_lpss shpchp battery acpi_pad ac tpm_tis button tpm_tis_core tpm nvidia_drm(POE) drm_kms_helper drm nvidia_modeset(POE) nvidia(POE) parport_pc ppdev lp parport efivarfs ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb mbcache algif_skcipher af_alg dm_crypt dm_mod hid_logitech_hidpp hid_logitech_dj usbhid rtsx_pci_sdmmc mmc_core crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel ahci libahci aes_x86_64 lrw gf128mul glue_helper xhci_pci ablk_helper cryptd libata xhci_hcd psmouse usbcore nvme scsi_mod i2c_i801 nvme_core i2c_smbus rtsx_pci r8169 mii mfd_core usb_common thermal i2c_hid hid fjes [last unloaded: iwlwifi]
> > Sep 3 11:37:49 powerhouse kernel: [21394.510561] CPU: 4 PID: 8122 Comm: rmmod Tainted: P R OE 4.8.0-2-amd64 #1 Debian 4.8.15-2
> > Sep 3 11:37:49 powerhouse kernel: [21394.510562] Hardware name: System76, Inc. Oryx Pro/Oryx Pro, BIOS 1.05.09RSA1 11/16/2015
> > Sep 3 11:37:49 powerhouse kernel: [21394.510563] task: ffff8dec4a3e0000 task.stack: ffff8decf4cd4000
> > Sep 3 11:37:49 powerhouse kernel: [21394.510564] RIP: 0010:[<ffffffffbccf98b9>] [<ffffffffbccf98b9>] SyS_delete_module+0x259/0x260
> > Sep 3 11:37:49 powerhouse kernel: [21394.510568] RSP: 0018:ffff8decf4cd7ef0 EFLAGS: 00010297
> > Sep 3 11:37:49 powerhouse kernel: [21394.510569] RAX: 00000000ffffffff RBX: ffffffffc1aa71c0 RCX: 0000000000000005
> > Sep 3 11:37:49 powerhouse kernel: [21394.510570] RDX: ffffffffc1aa74a0 RSI: ffffffffc1aa74c8 RDI: ffffffffc1aa71d8
> > Sep 3 11:37:49 powerhouse kernel: [21394.510571] RBP: 000055fb472021f0 R08: 0000000000000000 R09: 000000000000006d
> > Sep 3 11:37:49 powerhouse kernel: [21394.510572] R10: 000055fb472011c0 R11: 8080808080808080 R12: 0000000000000a00
> > Sep 3 11:37:49 powerhouse kernel: [21394.510572] R13: 0000000000000a00 R14: 00007fff6cd8d4f8 R15: 0000000000000000
> > Sep 3 11:37:49 powerhouse kernel: [21394.510573] FS: 00007f498ef22700(0000) GS:ffff8ded76500000(0000) knlGS:0000000000000000
> > Sep 3 11:37:49 powerhouse kernel: [21394.510574] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > Sep 3 11:37:49 powerhouse kernel: [21394.510575] CR2: 00007f498eacf801 CR3: 0000000fa99d0000 CR4: 00000000003406e0
> > Sep 3 11:37:49 powerhouse kernel: [21394.510576] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > Sep 3 11:37:49 powerhouse kernel: [21394.510576] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > Sep 3 11:37:49 powerhouse kernel: [21394.510577] Stack:
> > Sep 3 11:37:49 powerhouse kernel: [21394.510578] 00006d766d6c7769 0000000000000002 ffff8decf4cd4000 ffffffffbcc03290
> > Sep 3 11:37:49 powerhouse kernel: [21394.510579] ffff8decf4cd7f58 ffff8decf4cd4000 0000000000000050 00000000520cd409
> > Sep 3 11:37:49 powerhouse kernel: [21394.510581] 00007fff6cd8d338 000055fb472021f0 00007fff6cd8d508 00007fff6cd8ebbb
> > Sep 3 11:37:49 powerhouse kernel: [21394.510582] Call Trace:
> > Sep 3 11:37:49 powerhouse kernel: [21394.510586] [<ffffffffbcc03290>] ? exit_to_usermode_loop+0xa0/0xc0
> > Sep 3 11:37:49 powerhouse kernel: [21394.510588] [<ffffffffbd1e8cb6>] ? system_call_fast_compare_end+0xc/0x96
> > Sep 3 11:37:49 powerhouse kernel: [21394.510588] Code: fe ff ff 41 f7 c4 00 02 00 00 48 c7 c5 f0 ff ff ff 0f 84 5c fe ff ff be 01 00 00 00 bf 03 00 00 00 e8 0c b3 f7 ff e9 b7 fe ff ff <0f> 0b e8 90 b4 f7 ff 0f 1f 44 00 00 31 c0 c3 0f 1f 84 00 00 00
> > Sep 3 11:37:49 powerhouse kernel: [21394.510605] RIP [<ffffffffbccf98b9>] SyS_delete_module+0x259/0x260
> > Sep 3 11:37:49 powerhouse kernel: [21394.510607] RSP <ffff8decf4cd7ef0>
> > Sep 3 11:37:49 powerhouse kernel: [21394.510608] ---[ end trace 5b24b93b49e857eb ]---
> > Sep 3 11:37:49 powerhouse kernel: [21409.372738] ieee80211 phy3: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x0438 with error -110
> > Sep 3 11:38:05 powerhouse kernel: [21425.406196] INFO: rcu_sched detected stalls on CPUs/tasks:
> > Sep 3 11:38:20 powerhouse kernel: [21425.406201] 4-...: (0 ticks this GP) idle=02d/140000000000000/0 softirq=277173/277173 fqs=8
> > Sep 3 11:38:20 powerhouse kernel: [21425.406202] (detected by 7, t=7721 jiffies, g=246559, c=246558, q=936)
> > Sep 3 11:38:20 powerhouse kernel: [21425.406204] Task dump for CPU 4:
> > Sep 3 11:38:20 powerhouse kernel: [21425.406206] rmmod R running task 0 8122 8121 0x00000008
> > Sep 3 11:38:20 powerhouse kernel: [21425.406209] 0000000000000002 ffff8decf4cd7e48 ffffffffbd3df853 0000000000000000
> > Sep 3 11:38:20 powerhouse kernel: [21425.406211] 0000000000000000 ffffffffbcccc3d3 0000000000000246 000000000000000b
> > Sep 3 11:38:20 powerhouse kernel: [21425.406214] ffffffffbcc289f8 0000000000000006 ffff8decf4cd7e48 0000000000000004
> > Sep 3 11:38:20 powerhouse kernel: [21425.406216] Call Trace:
> > Sep 3 11:38:20 powerhouse kernel: [21425.406222] [<ffffffffbcccc3d3>] ? kmsg_dump+0x93/0xb0
> > Sep 3 11:38:20 powerhouse kernel: [21425.406225] [<ffffffffbcc289f8>] ? oops_end+0x78/0xd0
> > Sep 3 11:38:20 powerhouse kernel: [21425.406228] [<ffffffffbcc26446>] ? do_error_trap+0x86/0x100
> > Sep 3 11:38:20 powerhouse kernel: [21425.406976] [<ffffffffbccf98b9>] ? SyS_delete_module+0x259/0x260
> > Sep 3 11:38:20 powerhouse kernel: [21425.406979] [<ffffffffbcdda242>] ? kmem_cache_alloc+0x122/0x530
> > Sep 3 11:38:20 powerhouse kernel: [21425.406982] [<ffffffffbd1e9a2e>] ? invalid_op+0x1e/0x30
> > Sep 3 11:38:20 powerhouse kernel: [21425.407276] [<ffffffffbccf98b9>] ? SyS_delete_module+0x259/0x260
> > Sep 3 11:38:20 powerhouse kernel: [21425.407277] perf: interrupt took too long (8612 > 2500), lowering kernel.perf_event_max_sample_rate to 23000
> > Sep 3 11:3Sep 3 11:39:51 powerhouse kernel: [ 0.000000] Linux version 4.8.0-2-amd64 (debian-kernel@lists.debian.org) (gcc version 5.4.1 20161202 (Debian 5.4.1-4) ) #1 SMP Debian 4.8.15-2 (2017-01-04)
> > Sep 3 11:39:51 powerhouse kernel: [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.8.0-2-amd64 root=/dev/mapper/powerhouse--vg-root ro quiet
> >
> > Obviously, I'm not certain the bug is in this kernel module or even has
> > anything to do with it, but I thought this was a good place to start. Advice
> > welcome, happy to help however I can, I am a software engineer but not very
> > experienced at kernel hacking.
>
> The bug you're seeing is happening in the module removal code[1].
> Apparently the system is getting a bad value in refcnt and it's becoming
> negative, which should never happen. Have you been trying to force-
> remove modules or something like that?
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/kernel/module.c?h=linux-4.8.y#n890
>
> In any case, this doesn't seem like a iwlwifi bug at all.
>
> HTH.
Yeeeeahh, I don't normally force-remove it, but now that you mention it I did
have to force remove it earlier that day, I think, I think I hadn't rebooted
since that. So that very well could be the cause. I guess if you do things
like force-remove kernel modules, then the results aren't necessarily a bug,
huh? =)
That was very helpful, thanks very much for your time!
I'd love to figure out how to make this module more stable for me, but I'm not
sure where to even get started, and since I am on old firmware (due to the
previously mentioned bug), I'm not sure it's worth poking until I can get on the
tip version first.
Thanks again for your time!
-Carl
>
> --
> Cheers,
> Luca.
--
Carl Myers
PGP Key ID 3537595B
PGP Key fingerprint 9365 0FAF 721B 992A 0A20 1E0D C795 2955 3537 595B
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 06/10] cfg80211: honor NL80211_RRF_NO_HT40{MINUS,PLUS}
From: Grumbach, Emmanuel @ 2017-09-05 16:49 UTC (permalink / raw)
To: luca@coelho.fi, johannes@sipsolutions.net
Cc: linux-wireless@vger.kernel.org, Coelho, Luciano
In-Reply-To: <1504621814.12380.23.camel@sipsolutions.net>
T24gVHVlLCAyMDE3LTA5LTA1IGF0IDE2OjMwICswMjAwLCBKb2hhbm5lcyBCZXJnIHdyb3RlOg0K
PiBPbiBTYXQsIDIwMTctMDgtMDUgYXQgMTE6NDQgKzAzMDAsIEx1Y2EgQ29lbGhvIHdyb3RlOg0K
PiANCj4gPiArCXJlZ2QgPSBnZXRfd2lwaHlfcmVnZG9tKHdpcGh5KTsNCj4gPiArCWlmIChyZWdk
KSB7DQo+ID4gKwkJY29uc3Qgc3RydWN0IGllZWU4MDIxMV9yZWdfcnVsZSAqcmVnX3J1bGUgPQ0K
PiA+ICsJCQlmcmVxX3JlZ19pbmZvX3JlZ2QoTUhaX1RPX0tIWihjaGFubmVsLQ0KPiA+ID4gY2Vu
dGVyX2ZyZXEpLA0KPiA+IA0KPiA+ICsJCQkJCcKgwqDCoHJlZ2QsIE1IWl9UT19LSFooMjApKTsN
Cj4gPiANCj4gDQo+IFRoaXMgY291bGQgcmV0dXJuIGFuIGVycm9yLCBob3cgY2FuIHlvdSBiZSBz
dXJlIGl0IGRvZXNuJ3Q/DQo+IA0KDQpIbS4uLiBzbyBJIGd1ZXNzIEkgY291bGQgY2hlY2sgdGhh
dCBpdCBkaWRuJ3QgcmV0dXJuIGFueSBlcnJvciBhbmQgaWYNCml0IGRpZCwgdGhlbiBmbGFncyA9
IDA/DQoNClNvbWV0aGluZyBsaWtlIHRoaXM/IChvbiB0b3Agb2YgdGhpcyBwYXRjaCk6DQoNCkBA
IC0xNTA2LDE1ICsxNTA2LDE1IEBAIHN0YXRpYyB2b2lkIHJlZ19wcm9jZXNzX2h0X2ZsYWdzX2No
YW5uZWwoc3RydWN0IHdpcGh5ICp3aXBoeSwNCiAgICAgICAgICAgICAgICAgICAgICAgIGNoYW5u
ZWxfYWZ0ZXIgPSBjOw0KICAgICAgICB9DQogDQorICAgICAgIGZsYWdzID0gMDsNCiAgICAgICAg
cmVnZCA9IGdldF93aXBoeV9yZWdkb20od2lwaHkpOw0KICAgICAgICBpZiAocmVnZCkgew0KICAg
ICAgICAgICAgICAgIGNvbnN0IHN0cnVjdCBpZWVlODAyMTFfcmVnX3J1bGUgKnJlZ19ydWxlID0N
CiAgICAgICAgICAgICAgICAgICAgICAgIGZyZXFfcmVnX2luZm9fcmVnZChNSFpfVE9fS0haKGNo
YW5uZWwtPmNlbnRlcl9mcmVxKSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICByZWdkLCBNSFpfVE9fS0haKDIwKSk7DQogDQotICAgICAgICAgICAgICAgZmxhZ3Mg
PSByZWdfcnVsZS0+ZmxhZ3M7DQotICAgICAgIH0gZWxzZSB7DQotICAgICAgICAgICAgICAgZmxh
Z3MgPSAwOw0KKyAgICAgICAgICAgICAgIGlmICghSVNfRVJSKHJlZ19ydWxlKSkNCisgICAgICAg
ICAgICAgICAgICAgICAgIGZsYWdzID0gcmVnX3J1bGUtPmZsYWdzOw0KICAgICAgICB9DQogDQog
ICAgICAgIC8q
^ permalink raw reply
* Re: 915f3e3f76 ("mac80211_hwsim: Replace bogus hrtimer clockid"): BUG: kernel reboot-without-warning in test stage
From: Sebastian Andrzej Siewior @ 2017-09-05 16:41 UTC (permalink / raw)
To: Thomas Gleixner
Cc: kernel test robot, LKP, linux-kernel, netdev, linux-wireless, wfg
In-Reply-To: <alpine.DEB.2.20.1709050910150.1900@nanos>
On 2017-09-05 09:12:40 [+0200], Thomas Gleixner wrote:
> Sorry, no. That bisect is completely bogus. The commit in question merily
> replaces the unsupported clockid with a valid one.
The bisect is correct. It just has problems to express itself properly. So
the table says:
| WARNING:at_kernel/time/hrtimer.c:#hrtimer_init | 7 | | | |
| BUG:kernel_reboot-without-warning_in_test_stage | 0 | 12 | 6 | 6 |
which means _before_ your commit it counted a warning in hrtimer_init()
(an unsupported clock id was used). With your commit, the warning was
gone and I *think* the userland then printed
"BUG:kernel_reboot-without-warning_in_test_stage" because it had no
warning.
It seems that the bot learned to live with that warning which was around
for more than three years. Now that you removed it, it seems to be a
mistake to do so because nobody complained about it so far.
> Thanks,
>
> tglx
Sebastian
^ permalink raw reply
* Re: [PATCH 06/10] cfg80211: honor NL80211_RRF_NO_HT40{MINUS,PLUS}
From: Johannes Berg @ 2017-09-05 14:30 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Emmanuel Grumbach, Luca Coelho
In-Reply-To: <20170805084438.12550-7-luca@coelho.fi>
On Sat, 2017-08-05 at 11:44 +0300, Luca Coelho wrote:
> + regd = get_wiphy_regdom(wiphy);
> + if (regd) {
> + const struct ieee80211_reg_rule *reg_rule =
> + freq_reg_info_regd(MHZ_TO_KHZ(channel-
> >center_freq),
> + regd, MHZ_TO_KHZ(20));
>
This could return an error, how can you be sure it doesn't?
johannes
^ permalink raw reply
* Re: [PATCH 00/10] mac80211 patches from our internal tree 2017-08-05
From: Johannes Berg @ 2017-09-05 14:29 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Luca Coelho
In-Reply-To: <20170805084438.12550-1-luca@coelho.fi>
On Sat, 2017-08-05 at 11:44 +0300, Luca Coelho wrote:
>
> Liad Kaufman (2):
> mac80211: add MESH IE in the correct order
applied.
> Naftali Goldstein (1):
> mac80211: add api to start ba session timer expired flow
you already had this merged
> Sharon Dvir (1):
> mac80211: shorten debug prints using ht_dbg() to avoid warning
applied
johannes
^ permalink raw reply
* VLAN/bridge "compression" in wifi (was: Re: [PATCH 3/8] qtnfmac: implement AP_VLAN iftype support)
From: Johannes Berg @ 2017-09-05 14:20 UTC (permalink / raw)
To: Sergey Matyukevich, linux-wireless, netdev; +Cc: Igor Mitsyanko, Avinash Patil
In-Reply-To: <1504619151.12380.16.camel@sipsolutions.net>
+netdev
On Tue, 2017-09-05 at 15:45 +0200, Johannes Berg wrote:
>
> In a way this feature seems mis-designed - you never have 802.1Q tags
> over the air, but you're inserting them on RX and stripping them on
> TX, probably in order to make bridging to ethernet easier and not
> have to have 802.1Q acceleration on the ethernet port, or - well - in
> order to have an ability to do this with an ethernet card that only
> has a single CPU port.
Ok this isn't really right either - it's only for saving the 802.1Q
acceleration on the Ethernet port, really - and saving the extra
bridges.
To clarify, I think what you - conceptually - want is the following
topology:
+--- eth0.1 --- br.1 --- wlan0.1
|
eth0 ---+--- eth0.2 --- br.2 --- wlan0.2
|
+--- eth0.3 --- br.3 --- wlan0.3
where eth0.N is just "ip link add link eth0 name eth0.N type vlan id N"
and br.N is obviously a bridge for each, and the wlan0.N are AP_VLAN
type interfaces that isolate the clients against each other as far as
wifi is concerned.
Is this correct? As far as I understand, that's the baseline topology
that you're trying to achieve, expressed in terms of Linux networking.
Now, you seem to want to compress this to
+--- wlan0.1
|
eth0 --- br ---+--- wlan0.2
|
+--- wlan0.3
and have the 802.1Q tag insertion/removal that's normally configured to
happen in eth0.N already be handled in wlan0.N.
Also correct?
We clearly don't have APIs for this, and I don't think it makes sense
in the Linux space - the bridge and wlan0.N suddenly have tagged
traffic rather than untagged, and the VLAN tagging is completely hidden
from the management view.
johannes
^ permalink raw reply
* Re: [PATCH 3/8] qtnfmac: implement AP_VLAN iftype support
From: Johannes Berg @ 2017-09-05 13:45 UTC (permalink / raw)
To: Sergey Matyukevich, linux-wireless; +Cc: Igor Mitsyanko, Avinash Patil
In-Reply-To: <20170620195517.18373-4-sergey.matyukevich.os@quantenna.com>
Hi Sergey, all,
On Tue, 2017-06-20 at 22:55 +0300, Sergey Matyukevich wrote:
> This patch implements AP_VLAN interface type support enabling
> the use of dynamic VLAN mode in hostapd.
My first thought here is that this is completely wrong.
AP_VLAN interfaces have no relation to 802.1Q, but it seems that you're
trying to use them as such.
I'll comment a bit below, but I'd like to ask you to actually explain
what you're trying to achieve, because then I think I can comment
better on what you need to be doing.
> Implementation notes.
>
> 1. Passing dynamic VLAN tag to firmware
There's no such thing as a "VLAN tag" with AP_VLAN interfaces. You want
802.1Q, which can be done on top of them if needed, but it's an
unrelated concept.
> Currently there is no established way to pass VLAN tag assigned to
> STA by Radius server to wireless driver. It is assumed that hostapd
> is able to setup all the bridging and tagging on its own.
I don't even know if this is true? Does hostapd in fact set up 802.1Q
tagging in any way? Can you say how to configure this?
This might actually be your problem - what you *want* is doing 802.1Q
tagging which hostapd doesn't support, and so you're actually doing
client isolation which hostapd *does* support, instead?
As far as I can tell hostapd only has the ability to put different
types of clients into different AP_VLANs to achieve *over the air*
isolation. It has no isolation over the backend (yet) - that's
typically set up by putting the AP_VLAN interfaces into different
bridges or whatever.
> However qtnf firmware needs to know the assigned dynamic VLAN tags in
> order to perform various internal tasks including group key
> management, filtering, acceleration, and more.
This doesn't make any sense - what does it need the *tag* for? I can
understand it needing *a* tag, but not *the* tag that the RADIUS server
gave it?
IOW - I can understand it needing an identifier of the VLAN or
something like that, but then why can't you just number the AP_VLAN
interfaces 1,2,3,4,...?
> Current implementation makes use of the following workaround.
[snip]
This really shouldn't be done.
> 2. Packet routing to/from AP/VLAN interfaces
> Firmware operates with tagged packets after dynamic VLAN mode is
> configured. In particular, packets destined to STAs should be
> properly tagged before they can be passed to firmware. Packets
> received from STAs are properly tagged by firmware and then
> passed to wireless driver. As a result, packet routing to AP/VLAN
> interfaces is straightforward: it is enough to check VLAN tags.
Ok, so here the whole tagging comes - a bit - into play. Technically
you could, however, do the following:
* assign "fake" tags as I suggested above
* pack/unpack the 802.1Q header from the firmware (or put it into
metadata) in the driver and just tx/rx untagged packets into the
right interface
* if the AP_VLAN has a real 802.1Q on top, then it's re-packed again
by the ethernet driver when the data goes out
> Normally hostapd expects untagged packets from AP/VLAN interfaces.
hostapd doesn't really expect anything there, does it?
> Meanwhile firmware performs tagging using h/w acceleration. That
> is why it makes sense to avoid untagging packets in driver if
> they are supposed to by tagged again on host. To enable this
> behavior a new module parameter 'dyn_vlan_tagged' has been
> introduced:
>
> - dyn_vlan_tagged = 0 (default)
> In this case untagged packets are sent to and expected from AP/VLAN
> interfaces.
> Driver tags/untags packets going to/from firmware. This behaviour is
> expected
> by hostapd which is able to create bridges and VLAN interfaces
> automatically
> when hostapd is built with CONFIG_FULL_DYNAMIC_VLAN option enabled.
>
> - dyn_vlan_tagged = 1
> In this case tagged packets are sent to and expected from AP/VLAN
> interfaces.
> Hostapd build option CONFIG_FULL_DYNAMIC_VLAN should be disabled.
> Setup of
> networking topology on host is left up to the implementers.
This is all very hacky, I really don't think we can accept that.
Firewalling and similar things will likely not work correctly if
there's an 802.1Q packet coming in that they don't expect, for example.
We don't want to go around all the Linux infrastructure for something
like this.
In a way this feature seems mis-designed - you never have 802.1Q tags
over the air, but you're inserting them on RX and stripping them on TX,
probably in order to make bridging to ethernet easier and not have to
have 802.1Q acceleration on the ethernet port, or - well - in order to
have an ability to do this with an ethernet card that only has a single
CPU port.
In a way this is more like a switch or bridge feature, but I don't
think we have any abstraction for this in Linux. I think this is
something we should discuss over on netdev and perhaps in person at the
wireless workshop/netdev conference?
johannes
^ permalink raw reply
* Re: Cisco's Wi-Fi Direct Client Policy and iwlwifi (8260)
From: Johannes Berg @ 2017-09-05 13:23 UTC (permalink / raw)
To: Luca Coelho, Dariusz Gadomski, linux-wireless
In-Reply-To: <1503076588.15969.320.camel@coelho.fi>
On Fri, 2017-08-18 at 20:16 +0300, Luca Coelho wrote:
>
> I have heard about this before. The issue is that the Cisco AP
> doesn't allow the 8260 to connect because it has the P2P IE in
> it. But AFAICT it is not against any specs to include this IE. The
> Cisco AP is using the IE as an indication that we are trying to
> connect as a P2P device, which in this case we are not.
I believe that this is technically incorrect: they're assuming that
because P2P IEs are included, the device is P2P *capable* - completely
unrelated to connecting as a P2P-client (vs. a regular BSS client).
Because the device is P2P capable, there's a policy decision in the
configuration to not allow these clients to connect. This is actually
described in sections 3.4.3/3.4.4 of the P2P spec, and we should
probably implement the recommendations there?
johannes
^ permalink raw reply
* Re: [PATCH 3/3] mac80211: fix VLAN handling with TXQs
From: Toke Høiland-Jørgensen @ 2017-09-05 10:16 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: nbd
In-Reply-To: <1504605297.12380.8.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Tue, 2017-09-05 at 11:49 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wrote:
>>=20
>> Ah, so the station is attached to the VLAN interface, not the parent
>> interface?
>
> Doesn't actually matter, but if the VLAN goes where the station belongs
> then either the station must've moved somewhere else or have been
> destroyed, you can't have the station pointing to a VLAN that no longer
> exists :)
Yeah, that makes sense. I was thinking of VLANs as something that was
carried "on top" of the station<->ap connection (so that the VLAN tag is
propagated to the client).
>> I guess that the only case where there is likely to be any
>> significant effects of dropping the whole queue is if someone is
>> sending large amounts of multicast traffic (live video streaming? is
>> that even feasible over WiFi?) while reconfiguring their VLAN setup.
>> That is probably not a terribly common combination...
>
> Right.
>
> Anyway I've applied this with the pointless null check removed.
Cool :)
-Toke
^ permalink raw reply
* Re: [PATCH 3/3] mac80211: fix VLAN handling with TXQs
From: Johannes Berg @ 2017-09-05 9:54 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, linux-wireless; +Cc: nbd
In-Reply-To: <87zia91nmc.fsf@toke.dk>
On Tue, 2017-09-05 at 11:49 +0200, Toke Høiland-Jørgensen wrote:
>
> Ah, so the station is attached to the VLAN interface, not the parent
> interface?
Doesn't actually matter, but if the VLAN goes where the station belongs
then either the station must've moved somewhere else or have been
destroyed, you can't have the station pointing to a VLAN that no longer
exists :)
> I guess that the only case where there is likely to be any
> significant effects of dropping the whole queue is if someone is
> sending large amounts of multicast traffic (live video streaming? is
> that even feasible over WiFi?) while reconfiguring their VLAN setup.
> That is probably not a terribly common combination...
Right.
Anyway I've applied this with the pointless null check removed.
johannes
^ permalink raw reply
* Re: [PATCH 3/3] mac80211: fix VLAN handling with TXQs
From: Toke Høiland-Jørgensen @ 2017-09-05 9:49 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: nbd
In-Reply-To: <1504603125.12380.7.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Tue, 2017-09-05 at 11:02 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wrote:
>>=20
>> > I'm not sure. However, I think it's less bad than one might guess
>> > since it really should only affect multicast frames, right? All
>> > unicast frames should go directly to the per-STA TXQ.
>>=20
>> Ah, right, that is the interface txq that is being purged. Gotcha.
>>=20
>> But, erm, what happens with unicast traffic sent on the VLAN
>> interface when it goes down? Shouldn't that be purged from the per-
>> station TXQs as well?
>
> Well, those entire TXQs are destroyed with the station :)
Ah, so the station is attached to the VLAN interface, not the parent
interface?
I guess that the only case where there is likely to be any significant
effects of dropping the whole queue is if someone is sending large
amounts of multicast traffic (live video streaming? is that even
feasible over WiFi?) while reconfiguring their VLAN setup. That is
probably not a terribly common combination...
-Toke
^ permalink raw reply
* Re: [PATCH 3/3] mac80211: fix VLAN handling with TXQs
From: Johannes Berg @ 2017-09-05 9:18 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, linux-wireless; +Cc: nbd
In-Reply-To: <8760cx34cm.fsf@toke.dk>
On Tue, 2017-09-05 at 11:02 +0200, Toke Høiland-Jørgensen wrote:
>
> > I'm not sure. However, I think it's less bad than one might guess
> > since it really should only affect multicast frames, right? All
> > unicast frames should go directly to the per-STA TXQ.
>
> Ah, right, that is the interface txq that is being purged. Gotcha.
>
> But, erm, what happens with unicast traffic sent on the VLAN
> interface when it goes down? Shouldn't that be purged from the per-
> station TXQs as well?
Well, those entire TXQs are destroyed with the station :)
> One nit with the patch:
>
> > - tx.sdata = vif_to_sdata(info->control.vif);
> > + if (info->control.vif)
> > + tx.sdata = vif_to_sdata(info->control.vif);
>
> Why the conditional assignment? The code below unconditionally
> dereferences tx.sdata, so if info->control.vif is null it is going to
> crash anyway?
Yeah, I agree that makes no sense, I'll remove that piece again.
johannes
^ permalink raw reply
* Re: [PATCH 3/3] mac80211: fix VLAN handling with TXQs
From: Toke Høiland-Jørgensen @ 2017-09-05 9:02 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: nbd
In-Reply-To: <1504594708.6667.1.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Mon, 2017-09-04 at 16:23 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wrote:
>>=20
>> Hmm, not apart from agreeing with you that it would be better to not
>> drop everything when removing a VLAN. Not sure how often this
>> happens, though (and hence how big of a problem it is). What happens
>> in scenarios where hostapd is setup to automatically generate a bunch
>> of VLANs for every client, for instance?
>
> I'm not sure. However, I think it's less bad than one might guess
> since it really should only affect multicast frames, right? All
> unicast frames should go directly to the per-STA TXQ.
Ah, right, that is the interface txq that is being purged. Gotcha.
But, erm, what happens with unicast traffic sent on the VLAN interface
when it goes down? Shouldn't that be purged from the per-station TXQs as
well?
> Right now, with TXQ, encrypted VLANs are completely broken, so surely
> it's a step in the right direction?
Yeah, fair point ;)
One nit with the patch:
> - tx.sdata =3D vif_to_sdata(info->control.vif);
> + if (info->control.vif)
> + tx.sdata =3D vif_to_sdata(info->control.vif);
Why the conditional assignment? The code below unconditionally
dereferences tx.sdata, so if info->control.vif is null it is going to
crash anyway?
-Toke
^ permalink raw reply
* Re: [PATCH 20/25] mac80211_hwsim: Replace hrtimer tasklet with softirq hrtimer
From: Johannes Berg @ 2017-09-05 8:51 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Anna-Maria Gleixner, LKML, Peter Zijlstra, Ingo Molnar,
Christoph Hellwig, keescook, John Stultz, Kalle Valo,
linux-wireless
In-Reply-To: <alpine.DEB.2.20.1709051047360.1900@nanos>
On Tue, 2017-09-05 at 10:49 +0200, Thomas Gleixner wrote:
>
> > Are you planning to integrate all patches in the series through
> > some other tree, perhaps to be able to get rid of the
> > tasklet_hrtimer API, or should I apply this?
>
> The patch depends on the hrtimer core changes, so we either delay the
> removal for a release cycle or just take the whole lot through
> tip:timers/core and get rid of it in one go.
Ok. For now then I'll assume that it'll go through tip; if not please
resend when it's appropriate.
Thanks,
johannes
^ permalink raw reply
* Re: [PATCH 20/25] mac80211_hwsim: Replace hrtimer tasklet with softirq hrtimer
From: Thomas Gleixner @ 2017-09-05 8:49 UTC (permalink / raw)
To: Johannes Berg
Cc: Anna-Maria Gleixner, LKML, Peter Zijlstra, Ingo Molnar,
Christoph Hellwig, keescook, John Stultz, Kalle Valo,
linux-wireless
In-Reply-To: <1504594996.6667.2.camel@sipsolutions.net>
On Tue, 5 Sep 2017, Johannes Berg wrote:
> On Thu, 2017-08-31 at 12:23 +0000, Anna-Maria Gleixner wrote:
> > From: Thomas Gleixner <tglx@linutronix.de>
> >
> > Switch the timer to CLOCK_MONOTONIC_SOFT, which executed the timer
> > callback in softirq context and remove the hrtimer_tasklet.
> >
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
> > Cc: Johannes Berg <johannes@sipsolutions.net>
> > Cc: Kalle Valo <kvalo@codeaurora.org>
> > Cc: linux-wireless@vger.kernel.org
> >
> This looks fine to me,
>
> Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
>
> Are you planning to integrate all patches in the series through some
> other tree, perhaps to be able to get rid of the tasklet_hrtimer API,
> or should I apply this?
The patch depends on the hrtimer core changes, so we either delay the
removal for a release cycle or just take the whole lot through
tip:timers/core and get rid of it in one go.
Thanks,
tglx
^ permalink raw reply
* Re: 915f3e3f76 ("mac80211_hwsim: Replace bogus hrtimer clockid"): BUG: kernel reboot-without-warning in test stage
From: Thomas Gleixner @ 2017-09-05 7:12 UTC (permalink / raw)
To: kernel test robot; +Cc: LKP, linux-kernel, netdev, linux-wireless, wfg
In-Reply-To: <59ade247.WzhbxWeytBOa6Xu4%fengguang.wu@intel.com>
On Tue, 5 Sep 2017, kernel test robot wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
> commit 915f3e3f76c05b2da93c4cc278eebc2d9219d9f4
> Author: Thomas Gleixner <tglx@linutronix.de>
> AuthorDate: Sat Feb 25 11:27:37 2017 +0100
> Commit: Linus Torvalds <torvalds@linux-foundation.org>
> CommitDate: Sat Feb 25 09:48:16 2017 -0800
>
> mac80211_hwsim: Replace bogus hrtimer clockid
>
> mac80211_hwsim initializes a hrtimer with clockid CLOCK_MONOTONIC_RAW.
> That's not supported.
>
> Use CLOCK_MONOTNIC instead.
Sorry, no. That bisect is completely bogus. The commit in question merily
replaces the unsupported clockid with a valid one.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 20/25] mac80211_hwsim: Replace hrtimer tasklet with softirq hrtimer
From: Johannes Berg @ 2017-09-05 7:03 UTC (permalink / raw)
To: Anna-Maria Gleixner, LKML
Cc: Peter Zijlstra, Ingo Molnar, Christoph Hellwig, keescook,
John Stultz, Thomas Gleixner, Kalle Valo, linux-wireless
In-Reply-To: <20170831105827.172599262@linutronix.de>
On Thu, 2017-08-31 at 12:23 +0000, Anna-Maria Gleixner wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
>
> Switch the timer to CLOCK_MONOTONIC_SOFT, which executed the timer
> callback in softirq context and remove the hrtimer_tasklet.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
> Cc: Johannes Berg <johannes@sipsolutions.net>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: linux-wireless@vger.kernel.org
>
This looks fine to me,
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Are you planning to integrate all patches in the series through some
other tree, perhaps to be able to get rid of the tasklet_hrtimer API,
or should I apply this?
johannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox