* Re: [PATCH 3/3] nl80211: Include wiphy address setup in NEW_WIPHY
From: Johannes Berg @ 2019-06-20 6:58 UTC (permalink / raw)
To: Denis Kenzior; +Cc: linux-wireless
In-Reply-To: <20190619223606.4575-3-denkenz@gmail.com>
Didn't really review all of this yet, but
switch (state->split_start) {
> case 0:
> + if (nla_put(msg, NL80211_ATTR_MAC, ETH_ALEN,
> + rdev->wiphy.perm_addr))
> + goto nla_put_failure;
We generally can't add anything to any of the cases before the split was
allowed, for compatibility with old userspace.
johannes
^ permalink raw reply
* Re: [PATCH v2] Revert "cfg80211: fix processing world regdomain when non modular"
From: Kalle Valo @ 2019-06-20 7:48 UTC (permalink / raw)
To: Johannes Berg; +Cc: Hodaszi, Robert, linux-wireless@vger.kernel.org
In-Reply-To: <6a9c7642a2fcca60658036c605438ff2ac982bd0.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Fri, 2019-06-14 at 13:58 +0000, Hodaszi, Robert wrote:
>>
>> I didn't just resend that. I just realized, accidentally I forgot to fix
>> the debug message printing function, that define doesn't exist anymore.
>> Sorry for the confusion!
>
> Oops. I looked too superficially then and didn't even see the
> difference, sorry.
>
> I guess that's why Kalle always says you should have a patch changelog
> :-)
Indeed :) And the obligatory link:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#changelog_missing
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/3] nl80211: Update uapi for CMD_FRAME_WAIT_CANCEL
From: Kalle Valo @ 2019-06-20 7:50 UTC (permalink / raw)
To: Denis Kenzior; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <20190619223606.4575-1-denkenz@gmail.com>
Denis Kenzior <denkenz@gmail.com> writes:
> 1c38c7f2 added the possibility of NL80211_CMD_FRAME_WAIT_CANCEL
> being sent whenever the off-channel wait time associated with a
> CMD_FRAME completes. Document this in the uapi/linux/nl80211.h file.
The preferred format for referencing commits is:
Commit 1c38c7f22068 ("nl80211: send event when CMD_FRAME duration
expires") added...
--
Kalle Valo
^ permalink raw reply
* pull request: iwlwifi firmware updates 2019-06-20
From: Luca Coelho @ 2019-06-20 7:51 UTC (permalink / raw)
To: linux-firmware@kernel.org
Cc: linux-wireless@vger.kernel.org, linuxwifi, kyle@infradead.org,
jwboyer@kernel.org, ben@decadent.org.uk
[-- Attachment #1: Type: text/plain, Size: 2492 bytes --]
Hi,
This contains some updated firmwares for the 9000 and 22000 series of
devices, and new firmwares for new integrated 22000 series devices.
Please pull or let me know if there are any issues.
--
Cheers,
Luca.
The following changes since commit acb56f2fae3235195bc99ecb7d09742fb4b65e63:
cavium: Add firmware for CNN55XX crypto driver. (2019-06-18 09:12:52 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git tags/iwlwifi-fw-2019-06-20
for you to fetch changes up to 90e6845190c2f32bb631f40a9d6c929eb504a82f:
iwlwifi: add new firmwares for integrated 22000 series (2019-06-20 10:41:13 +0300)
----------------------------------------------------------------
iwlwifi firmware updates
* Update version 46 FWs for 9260 and 9000;
* Add version 48 FWs for 22000 series;
* Add version 48 FWs for new integrated 22000 series;
----------------------------------------------------------------
Emmanuel Grumbach (1):
iwlwifi: udpate -36 firmware for 8000 series
Luca Coelho (4):
iwlwifi: update Core45 FWs for 22260, 9000 and 9260
iwlwifi: update FWs for 9000 series to Core45-96
iwlwifi: update FW for 22000 to Core45-96
iwlwifi: add new firmwares for integrated 22000 series
WHENCE | 29 +++++++++++++++++++++++++----
iwlwifi-8000C-36.ucode | Bin 2486572 -> 2400700 bytes
iwlwifi-8265-36.ucode | Bin 2498044 -> 2414296 bytes
iwlwifi-9000-pu-b0-jf-b0-46.ucode | Bin 1448644 -> 1460788 bytes
iwlwifi-9260-th-b0-jf-b0-46.ucode | Bin 1456088 -> 1462324 bytes
iwlwifi-Qu-b0-hr-b0-48.ucode | Bin 0 -> 1106208 bytes
iwlwifi-Qu-b0-jf-b0-48.ucode | Bin 0 -> 1053156 bytes
iwlwifi-Qu-c0-hr-b0-48.ucode | Bin 0 -> 1106228 bytes
iwlwifi-Qu-c0-jf-b0-48.ucode | Bin 0 -> 1053176 bytes
iwlwifi-QuZ-a0-hr-b0-48.ucode | Bin 0 -> 1105648 bytes
iwlwifi-QuZ-a0-jf-b0-48.ucode | Bin 0 -> 1052968 bytes
iwlwifi-cc-a0-48.ucode | Bin 0 -> 1096684 bytes
12 files changed, 25 insertions(+), 4 deletions(-)
create mode 100644 iwlwifi-Qu-b0-hr-b0-48.ucode
create mode 100644 iwlwifi-Qu-b0-jf-b0-48.ucode
create mode 100644 iwlwifi-Qu-c0-hr-b0-48.ucode
create mode 100644 iwlwifi-Qu-c0-jf-b0-48.ucode
create mode 100644 iwlwifi-QuZ-a0-hr-b0-48.ucode
create mode 100644 iwlwifi-QuZ-a0-jf-b0-48.ucode
create mode 100644 iwlwifi-cc-a0-48.ucode
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 09/11] mwifiex: update set_mac_address logic
From: Kalle Valo @ 2019-06-20 8:08 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Zhiyuan Yang,
James Cao, Rakesh Parmar, Sharvari Harisangam
In-Reply-To: <MN2PR18MB2637F76B11A51E34A8586208A0EC0@MN2PR18MB2637.namprd18.prod.outlook.com>
Ganapathi Bhat <gbhat@marvell.com> writes:
> This change is correct one, but I missed changing the .patch file name before sending. Let me know if this needs to be resend.
I don't understand your comment. Are you saying that even if this is
marked as "9/11" this was supposed to submitted as a single patch? If
that's the case, no need to resend.
--
Kalle Valo
^ permalink raw reply
* RE: [PATCH 09/11] mwifiex: update set_mac_address logic
From: Ganapathi Bhat @ 2019-06-20 8:18 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Zhiyuan Yang,
James Cao, Rakesh Parmar, Sharvari Harisangam
In-Reply-To: <875zp0u1ao.fsf@purkki.adurom.net>
Hi Kalle,
> I don't understand your comment. Are you saying that even if this is marked
> as "9/11" this was supposed to submitted as a single patch? If that's the case,
> no need to resend.
Yes; That is the case;
Thanks,
Ganapathi
^ permalink raw reply
* [PATCH] iwlwifi: add support for hr1 RF ID
From: Luca Coelho @ 2019-06-20 8:46 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Oren Givon, stable, Luciano Coelho
From: Oren Givon <oren.givon@intel.com>
The 22000 series FW that was meant to be used with hr is
also the FW that is used for hr1 and has a different RF ID.
Add support to load the hr FW when hr1 RF ID is detected.
Cc: stable@vger.kernel.org # 5.1+
Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/iwl-csr.h | 1 +
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 8 +++++---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-csr.h b/drivers/net/wireless/intel/iwlwifi/iwl-csr.h
index 553554846009..93da96a7247c 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-csr.h
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-csr.h
@@ -336,6 +336,7 @@ enum {
/* RF_ID value */
#define CSR_HW_RF_ID_TYPE_JF (0x00105100)
#define CSR_HW_RF_ID_TYPE_HR (0x0010A000)
+#define CSR_HW_RF_ID_TYPE_HR1 (0x0010c100)
#define CSR_HW_RF_ID_TYPE_HRCDB (0x00109F00)
#define CSR_HW_RF_ID_TYPE_GF (0x0010D000)
#define CSR_HW_RF_ID_TYPE_GF4 (0x0010E000)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index b93753233223..38ab24d96244 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -3575,9 +3575,11 @@ struct iwl_trans *iwl_trans_pcie_alloc(struct pci_dev *pdev,
trans->cfg = &iwlax411_2ax_cfg_so_gf4_a0;
}
} else if (cfg == &iwl_ax101_cfg_qu_hr) {
- if (CSR_HW_RF_ID_TYPE_CHIP_ID(trans->hw_rf_id) ==
- CSR_HW_RF_ID_TYPE_CHIP_ID(CSR_HW_RF_ID_TYPE_HR) &&
- trans->hw_rev == CSR_HW_REV_TYPE_QNJ_B0) {
+ if ((CSR_HW_RF_ID_TYPE_CHIP_ID(trans->hw_rf_id) ==
+ CSR_HW_RF_ID_TYPE_CHIP_ID(CSR_HW_RF_ID_TYPE_HR) &&
+ trans->hw_rev == CSR_HW_REV_TYPE_QNJ_B0) ||
+ (CSR_HW_RF_ID_TYPE_CHIP_ID(trans->hw_rf_id) ==
+ CSR_HW_RF_ID_TYPE_CHIP_ID(CSR_HW_RF_ID_TYPE_HR1))) {
trans->cfg = &iwl22000_2ax_cfg_qnj_hr_b0;
} else if (CSR_HW_RF_ID_TYPE_CHIP_ID(trans->hw_rf_id) ==
CSR_HW_RF_ID_TYPE_CHIP_ID(CSR_HW_RF_ID_TYPE_HR)) {
--
2.20.1
^ permalink raw reply related
* Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk
From: Arend Van Spriel @ 2019-06-20 9:44 UTC (permalink / raw)
To: Stefan Wahren, Chi-Hsien Lin, Marcel Holtmann
Cc: Stanley Hsu, Franky Lin, Hante Meuleman, Wright Feng,
linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com, brcm80211-dev-list,
Jouni Malinen
In-Reply-To: <ab26ac30-e49c-8712-f124-8cf996b32a76@gmx.net>
On 6/18/2019 7:03 PM, Stefan Wahren wrote:
> Hi,
>
> Am 18.06.19 um 10:27 schrieb Arend Van Spriel:
>> + Jouni
>>
>> On 6/18/2019 7:33 AM, Chi-Hsien Lin wrote:
>>>
>>>
>>> On 06/17/2019 10:33, Marcel Holtmann wrote:
>>>> Hi Chi-hsien,
>>>>
>>>>>>> i was able to reproduce an (maybe older issue) with 4-way handshake
>>>>>>> offloading for 802.1X in the brcmfmac driver. My setup consists of
>>>>>>> Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA
>>>>>>> side and a
>>>>>>> Raspberry Pi 3 A+ (Linux 4.19) on AP side.
>>>>>>
>>>>>> Looks like Raspberry Pi isn't the only affected platform [3], [4].
>>>>>>
>>>>>> [3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
>>>>>> [4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521
>>>>>
>>>>> Stefan,
>>>>>
>>>>> Could you please try the attached patch for your wpa_supplicant? We'll
>>>>> upstream if it works for you.
> i've forward this patch to the Arch Linux board hoping someone else has
> currently more time.
>>>>
>>>> I hope that someone is also providing a kernel patch to fix the
>>>> issue. Hacking around a kernel issue in userspace is not enough. Fix
>>>> the root cause in the kernel.
>>>
>>> Marcel,
>>>
>>> This is a kernel warning for invalid application PMK set actions, so the
>>> fix is to only set PMK to wifi driver when 4-way is offloaded. I think
>>> Arend added the WARN_ON() intentionally to catch application misuse of
>> > PMK setting.
>>>
>>> You may also remove the warnings with the attached patch, but let's see
>>> what Arend says first.
> Instead of removing the WARN_ON i suggest to replace it with a more user
> friendly dev_warn().
>>>
>>>
>>> Arend,
>>>
>>> Any comment?
>>
>> Hi Chi-Hsien, Marcel
>>
>> From the kernel side I do not see an issue. In order to use 802.1X
>> offload the NL80211_ATTR_WANT_1X_4WAY_HS flag must be set in
>> NL80211_CMD_CONNECT. Otherwise, NL80211_CMD_SET_PMK is not accepted.
>> The only improvement would be to document this more clearly in the
>> "WPA/WPA2 EAPOL handshake offload" DOC section in nl80211.h.
>
> I missed to add my expectation as a user. At first i assume this new
> behavior in wpa_supplicant 2.8 has been tested successful with at least
> one Linux wifi driver. So i'm curious if all drivers behave that way?
As a matter of fact it has been tested with brcmfmac.
> Another point is that in my wpa_supplicant.conf i never enforced 802.1X
> offload and i assume this feature is optional. So can't we do some kind
> of fallback in this case?
So when the driver indicates it supports the offload, wpa_supplicant opt
in. There is no possibility for the user to opt out.
Regards,
Arend
^ permalink raw reply
* Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk
From: Arend Van Spriel @ 2019-06-20 10:04 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Chi-Hsien Lin, Stefan Wahren, Stanley Hsu, Franky Lin,
Hante Meuleman, Wright Feng, linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com, brcm80211-dev-list,
Jouni Malinen
In-Reply-To: <0ABBF42F-1C9C-4564-A27C-511026EB733C@holtmann.org>
On 6/19/2019 7:26 AM, Marcel Holtmann wrote:
> Hi Arend,
>
>>>>>>> i was able to reproduce an (maybe older issue) with 4-way handshake
>>>>>>> offloading for 802.1X in the brcmfmac driver. My setup consists of
>>>>>>> Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA side and a
>>>>>>> Raspberry Pi 3 A+ (Linux 4.19) on AP side.
>>>>>>
>>>>>> Looks like Raspberry Pi isn't the only affected platform [3], [4].
>>>>>>
>>>>>> [3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
>>>>>> [4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521
>>>>>
>>>>> Stefan,
>>>>>
>>>>> Could you please try the attached patch for your wpa_supplicant? We'll
>>>>> upstream if it works for you.
>>>>
>>>> I hope that someone is also providing a kernel patch to fix the issue. Hacking around a kernel issue in userspace is not enough. Fix the root cause in the kernel.
>>> Marcel,
>>> This is a kernel warning for invalid application PMK set actions, so the
>>> fix is to only set PMK to wifi driver when 4-way is offloaded. I think
>>> Arend added the WARN_ON() intentionally to catch application misuse of
>>> PMK setting.
>>> You may also remove the warnings with the attached patch, but let's see
>>> what Arend says first.
>>> Arend,
>>> Any comment?
>>
>> Hi Chi-Hsien, Marcel
>>
>> From the kernel side I do not see an issue. In order to use 802.1X offload the NL80211_ATTR_WANT_1X_4WAY_HS flag must be set in NL80211_CMD_CONNECT. Otherwise, NL80211_CMD_SET_PMK is not accepted. The only improvement would be to document this more clearly in the "WPA/WPA2 EAPOL handshake offload" DOC section in nl80211.h.
>
> so nl80211 is an API. And an application can use that API wrongly (be that intentionally or unintentionally), the kernel can not just go WARN_ON and print a backtrace. That is your bug. So please handle wrong user input properly.
Hi Marcel,
You are right. However, the kernel does also return an error if the
WARN_ON is hit. We can improve by using the EXT_ACK functionality to
provide more info than just -EINVAL, eg. "PMK not accepted; no 802.1X
offload requested on connect".
> Frankly, I don’t get why nl80211 itself is not validating the input and this is left to the driver. I think we need a nl80211 fuzzer that really exercises this API with random values and parameters to provide invalid input.
That would mean nl80211 should keep state info between commands. From
what I remember that has been avoided from day one because of the
experiences with that in the WEXT days. I welcome any testing be it
fuzzer or something else.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] iwlwifi: add support for hr1 RF ID
From: Luciano Coelho @ 2019-06-20 10:30 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Oren Givon, stable
In-Reply-To: <20190620084623.12014-1-luca@coelho.fi>
Hi Kalle,
Please take this to 5.1-rc* as well.
--
Cheers,
Luca.
On Thu, 2019-06-20 at 11:46 +0300, Luca Coelho wrote:
> From: Oren Givon <oren.givon@intel.com>
>
> The 22000 series FW that was meant to be used with hr is
> also the FW that is used for hr1 and has a different RF ID.
> Add support to load the hr FW when hr1 RF ID is detected.
>
> Cc: stable@vger.kernel.org # 5.1+
> Signed-off-by: Oren Givon <oren.givon@intel.com>
> Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
> ---
> drivers/net/wireless/intel/iwlwifi/iwl-csr.h | 1 +
> drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 8 +++++---
> 2 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-csr.h b/drivers/net/wireless/intel/iwlwifi/iwl-csr.h
> index 553554846009..93da96a7247c 100644
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-csr.h
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-csr.h
> @@ -336,6 +336,7 @@ enum {
> /* RF_ID value */
> #define CSR_HW_RF_ID_TYPE_JF (0x00105100)
> #define CSR_HW_RF_ID_TYPE_HR (0x0010A000)
> +#define CSR_HW_RF_ID_TYPE_HR1 (0x0010c100)
> #define CSR_HW_RF_ID_TYPE_HRCDB (0x00109F00)
> #define CSR_HW_RF_ID_TYPE_GF (0x0010D000)
> #define CSR_HW_RF_ID_TYPE_GF4 (0x0010E000)
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> index b93753233223..38ab24d96244 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> @@ -3575,9 +3575,11 @@ struct iwl_trans *iwl_trans_pcie_alloc(struct pci_dev *pdev,
> trans->cfg = &iwlax411_2ax_cfg_so_gf4_a0;
> }
> } else if (cfg == &iwl_ax101_cfg_qu_hr) {
> - if (CSR_HW_RF_ID_TYPE_CHIP_ID(trans->hw_rf_id) ==
> - CSR_HW_RF_ID_TYPE_CHIP_ID(CSR_HW_RF_ID_TYPE_HR) &&
> - trans->hw_rev == CSR_HW_REV_TYPE_QNJ_B0) {
> + if ((CSR_HW_RF_ID_TYPE_CHIP_ID(trans->hw_rf_id) ==
> + CSR_HW_RF_ID_TYPE_CHIP_ID(CSR_HW_RF_ID_TYPE_HR) &&
> + trans->hw_rev == CSR_HW_REV_TYPE_QNJ_B0) ||
> + (CSR_HW_RF_ID_TYPE_CHIP_ID(trans->hw_rf_id) ==
> + CSR_HW_RF_ID_TYPE_CHIP_ID(CSR_HW_RF_ID_TYPE_HR1))) {
> trans->cfg = &iwl22000_2ax_cfg_qnj_hr_b0;
> } else if (CSR_HW_RF_ID_TYPE_CHIP_ID(trans->hw_rf_id) ==
> CSR_HW_RF_ID_TYPE_CHIP_ID(CSR_HW_RF_ID_TYPE_HR)) {
^ permalink raw reply
* Re: [PATCH] iwlwifi: add support for hr1 RF ID
From: Luciano Coelho @ 2019-06-20 10:34 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Oren Givon, stable
In-Reply-To: <26ffc4023329e2421e459837bdcb92672f26cb62.camel@intel.com>
On Thu, 2019-06-20 at 13:30 +0300, Luciano Coelho wrote:
> Hi Kalle,
>
> Please take this to 5.1-rc* as well.
I obviously meant 5.2-rc*.
Thanks!
--
Luca.
^ permalink raw reply
* [PATCH v4] mt76: mt76u: reduce rx memory footprint
From: Lorenzo Bianconi @ 2019-06-20 10:39 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, sgruszka
Reduce rx memory footprint allocating just one SG buffer since for the
moment we support just 3839B as maximal size of an A-MSDU.
Introduce different SG_MAX_SIZE definitions for TX and RX sides.
Moreover set q->buf_size to PAGE_SIZE even for SG case.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
Changes since v3:
- drop patch 2/3: mt76u: introduce mt76u_ep data structure
- do not align usb buffer size to usb max endpoint length
---
drivers/net/wireless/mediatek/mt76/mt76.h | 3 ++-
.../net/wireless/mediatek/mt76/mt76x0/usb.c | 2 +-
.../wireless/mediatek/mt76/mt76x2/usb_init.c | 2 +-
drivers/net/wireless/mediatek/mt76/usb.c | 18 +++++++++++-------
4 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index 23a5ebefac3a..eee83c369a64 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -384,7 +384,8 @@ enum mt76u_out_ep {
__MT_EP_OUT_MAX,
};
-#define MT_SG_MAX_SIZE 8
+#define MT_TX_SG_MAX_SIZE 8
+#define MT_RX_SG_MAX_SIZE 1
#define MT_NUM_TX_ENTRIES 256
#define MT_NUM_RX_ENTRIES 128
#define MCU_RESP_URB_SIZE 1024
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c b/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
index 7c38ec4418db..5b9701ce6f37 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
@@ -191,7 +191,7 @@ static int mt76x0u_register_device(struct mt76x02_dev *dev)
/* check hw sg support in order to enable AMSDU */
if (dev->mt76.usb.sg_en)
- hw->max_tx_fragments = MT_SG_MAX_SIZE;
+ hw->max_tx_fragments = MT_TX_SG_MAX_SIZE;
else
hw->max_tx_fragments = 1;
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_init.c b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_init.c
index f2c57d5b87f9..94f52f98019b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_init.c
@@ -225,7 +225,7 @@ int mt76x2u_register_device(struct mt76x02_dev *dev)
/* check hw sg support in order to enable AMSDU */
if (dev->mt76.usb.sg_en)
- hw->max_tx_fragments = MT_SG_MAX_SIZE;
+ hw->max_tx_fragments = MT_TX_SG_MAX_SIZE;
else
hw->max_tx_fragments = 1;
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
index dd90427b2d67..ecc1aa59f5c1 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -333,12 +333,13 @@ mt76u_refill_rx(struct mt76_dev *dev, struct urb *urb, int nsgs, gfp_t gfp)
}
static int
-mt76u_urb_alloc(struct mt76_dev *dev, struct mt76_queue_entry *e)
+mt76u_urb_alloc(struct mt76_dev *dev, struct mt76_queue_entry *e,
+ int sg_max_size)
{
unsigned int size = sizeof(struct urb);
if (dev->usb.sg_en)
- size += MT_SG_MAX_SIZE * sizeof(struct scatterlist);
+ size += sg_max_size * sizeof(struct scatterlist);
e->urb = kzalloc(size, GFP_KERNEL);
if (!e->urb)
@@ -357,11 +358,12 @@ mt76u_rx_urb_alloc(struct mt76_dev *dev, struct mt76_queue_entry *e)
{
int err;
- err = mt76u_urb_alloc(dev, e);
+ err = mt76u_urb_alloc(dev, e, MT_RX_SG_MAX_SIZE);
if (err)
return err;
- return mt76u_refill_rx(dev, e->urb, MT_SG_MAX_SIZE, GFP_KERNEL);
+ return mt76u_refill_rx(dev, e->urb, MT_RX_SG_MAX_SIZE,
+ GFP_KERNEL);
}
static void mt76u_urb_free(struct urb *urb)
@@ -605,8 +607,9 @@ static int mt76u_alloc_rx(struct mt76_dev *dev)
if (!q->entry)
return -ENOMEM;
- q->buf_size = dev->usb.sg_en ? MT_RX_BUF_SIZE : PAGE_SIZE;
q->ndesc = MT_NUM_RX_ENTRIES;
+ q->buf_size = PAGE_SIZE;
+
for (i = 0; i < q->ndesc; i++) {
err = mt76u_rx_urb_alloc(dev, &q->entry[i]);
if (err < 0)
@@ -763,7 +766,7 @@ mt76u_tx_setup_buffers(struct mt76_dev *dev, struct sk_buff *skb,
urb->transfer_buffer = skb->data;
return 0;
} else {
- sg_init_table(urb->sg, MT_SG_MAX_SIZE);
+ sg_init_table(urb->sg, MT_TX_SG_MAX_SIZE);
urb->num_sgs = skb_to_sgvec(skb, urb->sg, 0, skb->len);
if (urb->num_sgs == 0)
return -ENOMEM;
@@ -857,7 +860,8 @@ static int mt76u_alloc_tx(struct mt76_dev *dev)
q->ndesc = MT_NUM_TX_ENTRIES;
for (j = 0; j < q->ndesc; j++) {
- err = mt76u_urb_alloc(dev, &q->entry[j]);
+ err = mt76u_urb_alloc(dev, &q->entry[j],
+ MT_TX_SG_MAX_SIZE);
if (err < 0)
return err;
}
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v3 0/7] Hexdump Enhancements
From: Jani Nikula @ 2019-06-20 10:50 UTC (permalink / raw)
To: Joe Perches, Alastair D'Silva
Cc: Joonas Lahtinen, Rodrigo Vivi, David Airlie, Daniel Vetter,
Dan Carpenter, Karsten Keil, Jassi Brar, Tom Lendacky,
David S. Miller, Jose Abreu, Kalle Valo, Stanislaw Gruszka,
Benson Leung, Enric Balletbo i Serra, James E.J. Bottomley,
Martin K. Petersen, Greg Kroah-Hartman, Alexander Viro,
Petr Mladek, Sergey Senozhatsky, Steven Rostedt, David Laight,
Andrew Morton, intel-gfx, dri-devel, linux-kernel, netdev, ath10k,
linux-wireless, linux-scsi, linux-fbdev, devel, linux-fsdevel
In-Reply-To: <fcf57339aea60fb1744cea2a2593656c728c4ec4.camel@perches.com>
On Wed, 19 Jun 2019, Joe Perches <joe@perches.com> wrote:
> On Thu, 2019-06-20 at 11:14 +1000, Alastair D'Silva wrote:
>> On Wed, 2019-06-19 at 17:35 -0700, Joe Perches wrote:
>> > On Thu, 2019-06-20 at 09:15 +1000, Alastair D'Silva wrote:
>> > > On Wed, 2019-06-19 at 09:31 -0700, Joe Perches wrote:
>> > > > On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote:
>> > > > > From: Alastair D'Silva <alastair@d-silva.org>
>> > > > >
>> > > > > Apologies for the large CC list, it's a heads up for those
>> > > > > responsible
>> > > > > for subsystems where a prototype change in generic code causes
>> > > > > a
>> > > > > change
>> > > > > in those subsystems.
>> > > > >
>> > > > > This series enhances hexdump.
>> > > >
>> > > > Still not a fan of these patches.
>> > >
>> > > I'm afraid there's not too much action I can take on that, I'm
>> > > happy to
>> > > address specific issues though.
>> > >
>> > > > > These improve the readability of the dumped data in certain
>> > > > > situations
>> > > > > (eg. wide terminals are available, many lines of empty bytes
>> > > > > exist,
>> > > > > etc).
>> >
>> > I think it's generally overkill for the desired uses.
>>
>> I understand where you're coming from, however, these patches make it a
>> lot easier to work with large chucks of binary data. I think it makes
>> more sense to have these patches upstream, even though committed code
>> may not necessarily have all the features enabled, as it means that
>> devs won't have to apply out-of-tree patches during development to make
>> larger dumps manageable.
>>
>> > > > Changing hexdump's last argument from bool to int is odd.
>> > > >
>> > >
>> > > Think of it as replacing a single boolean with many booleans.
>> >
>> > I understand it. It's odd.
>> >
>> > I would rather not have a mixture of true, false, and apparently
>> > random collections of bitfields like 0xd or 0b1011 or their
>> > equivalent or'd defines.
>> >
>>
>> Where's the mixture? What would you propose instead?
>
> create a hex_dump_to_buffer_ext with a new argument
> and a new static inline for the old hex_dump_to_buffer
> without modifying the argument list that calls
> hex_dump_to_buffer with whatever added argument content
> you need.
>
> Something like:
>
> static inline
> int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
> int groupsize, char *linebuf, size_t linebuflen,
> bool ascii)
> {
> return hex_dump_to_buffer_ext(buf, len, rowsize, groupsize,
> linebuf, linebuflen, ascii, 0);
> }
>
> and remove EXPORT_SYMBOL(hex_dump_to_buffer)
If you decide to do something like this, I'd actually suggest you drop
the bool ascii parameter from hex_dump_to_buffer() altogether, and
replace the callers that do require ascii with
hex_dump_to_buffer_ext(..., HEXDUMP_ASCII). Even if that also requires
touching all callers.
But no strong opinions, really.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply
* Re: use exact allocation for dma coherent memory
From: Christoph Hellwig @ 2019-06-20 10:51 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Christoph Hellwig, Potnuri Bharat Teja, Dan Carpenter,
Maarten Lankhorst, Maxime Ripard, Sean Paul, David Airlie,
Daniel Vetter, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Ian Abbott, H Hartley Sweeten, devel, linux-s390,
Intel Linux Wireless, linux-rdma, netdev, intel-gfx,
linux-wireless, linux-kernel, dri-devel, linux-mm, iommu,
moderated list:ARM PORT, linux-media
In-Reply-To: <20190619162903.GF9360@ziepe.ca>
On Wed, Jun 19, 2019 at 01:29:03PM -0300, Jason Gunthorpe wrote:
> > Yes. This will blow up badly on many platforms, as sq->queue
> > might be vmapped, ioremapped, come from a pool without page backing.
>
> Gah, this addr gets fed into io_remap_pfn_range/remap_pfn_range too..
>
> Potnuri, you should fix this..
>
> You probably need to use dma_mmap_from_dev_coherent() in the mmap ?
The function to use is dma_mmap_coherent, dma_mmap_from_dev_coherent is
just an internal helper.
That beiŋ said the drivers/infiniband code has a lot of
*remap_pfn_range, and a lot of them look like they might be for
DMA memory.
^ permalink raw reply
* Re: pull request: iwlwifi firmware updates 2019-06-20
From: Josh Boyer @ 2019-06-20 11:07 UTC (permalink / raw)
To: Luca Coelho
Cc: linux-firmware@kernel.org, linux-wireless@vger.kernel.org,
linuxwifi, kyle@infradead.org, ben@decadent.org.uk
In-Reply-To: <86eada55d771732ac0477a008d3c5f0a61570952.camel@coelho.fi>
On Thu, Jun 20, 2019 at 4:16 AM Luca Coelho <luca@coelho.fi> wrote:
>
> Hi,
>
> This contains some updated firmwares for the 9000 and 22000 series of
> devices, and new firmwares for new integrated 22000 series devices.
>
> Please pull or let me know if there are any issues.
>
> --
> Cheers,
> Luca.
>
>
> The following changes since commit acb56f2fae3235195bc99ecb7d09742fb4b65e63:
>
> cavium: Add firmware for CNN55XX crypto driver. (2019-06-18 09:12:52 -0400)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git tags/iwlwifi-fw-2019-06-20
Pulled and pushed out.
josh
^ permalink raw reply
* [GIT PULL] MMC fixes for v5.2-rc6
From: Ulf Hansson @ 2019-06-20 11:16 UTC (permalink / raw)
To: Linus, linux-mmc, linux-kernel
Cc: Ulf Hansson, Douglas Anderson, Kalle Valo, Arend van Spriel,
linux-wireless, Adrian Hunter
Hi Linus,
Here's a PR with quite a few MMC fixes intended for v5.2-rc6. This time the PR
also contains fixes for a WiFi driver, which device is attached to the SDIO
interface. Patches for the WiFi driver have been acked by the corresponding
maintainers. More details about the highlights are as usual found in the signed
tag.
Please pull this in!
Kind regards
Ulf Hansson
The following changes since commit d1fdb6d8f6a4109a4263176c84b899076a5f8008:
Linux 5.2-rc4 (2019-06-08 20:24:46 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v5.2-rc4
for you to fetch changes up to 83293386bc95cf5e9f0c0175794455835bd1cb4a:
mmc: core: Prevent processing SDIO IRQs when the card is suspended (2019-06-18 14:06:32 +0200)
----------------------------------------------------------------
MMC core:
- Make switch to eMMC HS400 more robust for some controllers
- Add two SDIO func API to manage re-tuning constraints
- Prevent processing SDIO IRQs when the card is suspended
MMC host:
- sdhi: Disallow broken HS400 for M3-W ES1.2, RZ/G2M and V3H
- mtk-sd: Fixup support for SDIO IRQs
- sdhci-pci-o2micro: Fixup support for tuning
Wireless BRCMFMAC (SDIO):
- Deal with expected transmission errors related to the idle states
(handled by the Always-On-Subsystem or AOS) on the SDIO-based WiFi on
rk3288-veyron-minnie, rk3288-veyron-speedy and rk3288-veyron-mickey.
----------------------------------------------------------------
Douglas Anderson (5):
Revert "brcmfmac: disable command decode in sdio_aos"
mmc: core: API to temporarily disable retuning for SDIO CRC errors
brcmfmac: sdio: Disable auto-tuning around commands expected to fail
mmc: core: Add sdio_retune_hold_now() and sdio_retune_release()
brcmfmac: sdio: Don't tune while the card is off
Raul E Rangel (1):
mmc: sdhci: sdhci-pci-o2micro: Correctly set bus width when tuning
Ulf Hansson (1):
mmc: core: Prevent processing SDIO IRQs when the card is suspended
Wolfram Sang (2):
mmc: sdhi: disallow HS400 for M3-W ES1.2, RZ/G2M, and V3H
mmc: core: complete HS400 before checking status
jjian zhou (2):
mmc: mediatek: fix SDIO IRQ interrupt handle flow
mmc: mediatek: fix SDIO IRQ detection issue
drivers/mmc/core/core.c | 5 +-
drivers/mmc/core/mmc.c | 6 +-
drivers/mmc/core/sdio.c | 13 +++-
drivers/mmc/core/sdio_io.c | 77 ++++++++++++++++++++++
drivers/mmc/core/sdio_irq.c | 4 ++
drivers/mmc/host/mtk-sd.c | 39 ++++++-----
drivers/mmc/host/renesas_sdhi_core.c | 9 ++-
drivers/mmc/host/sdhci-pci-o2micro.c | 5 +-
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 17 +++--
include/linux/mmc/host.h | 1 +
include/linux/mmc/sdio_func.h | 6 ++
11 files changed, 151 insertions(+), 31 deletions(-)
^ permalink raw reply
* [PATCH] Add SPDX identifiers
From: yegorslists @ 2019-06-20 13:01 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Yegor Yefremov
From: Yegor Yefremov <yegorslists@googlemail.com>
Software Package Data Exchange identifiers help to detect source file
licenses and hence simplify the FOSS compliance process.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
---
ap.c | 2 ++
bitrate.c | 2 ++
bloom.c | 2 ++
coalesce.c | 2 ++
connect.c | 2 ++
cqm.c | 2 ++
event.c | 2 ++
ftm.c | 2 ++
genl.c | 2 ++
hwsim.c | 2 ++
ibss.c | 2 ++
ieee80211.h | 2 ++
info.c | 2 ++
interface.c | 2 ++
iw.c | 2 ++
iw.h | 2 ++
link.c | 2 ++
measurements.c | 2 ++
mesh.c | 2 ++
mgmt.c | 2 ++
mpath.c | 2 ++
mpp.c | 2 ++
nan.c | 2 ++
nl80211.h | 2 ++
ocb.c | 2 ++
offch.c | 2 ++
p2p.c | 2 ++
phy.c | 2 ++
ps.c | 2 ++
reason.c | 2 ++
reg.c | 2 ++
roc.c | 2 ++
scan.c | 2 ++
sections.c | 2 ++
sha256.c | 2 ++
sha256.h | 2 ++
station.c | 2 ++
status.c | 2 ++
survey.c | 2 ++
util.c | 2 ++
vendor.c | 2 ++
wowlan.c | 2 ++
42 files changed, 84 insertions(+)
diff --git a/ap.c b/ap.c
index db9efb7..4b9157a 100644
--- a/ap.c
+++ b/ap.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <netlink/genl/genl.h>
#include <netlink/genl/family.h>
diff --git a/bitrate.c b/bitrate.c
index 4a026a4..c0ff319 100644
--- a/bitrate.c
+++ b/bitrate.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include "nl80211.h"
diff --git a/bloom.c b/bloom.c
index 877a6b5..f697b94 100644
--- a/bloom.c
+++ b/bloom.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <inttypes.h>
#include "iw.h"
diff --git a/coalesce.c b/coalesce.c
index 36dcaef..f3826ca 100644
--- a/coalesce.c
+++ b/coalesce.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
#include <stdio.h>
diff --git a/connect.c b/connect.c
index 3237a27..a486d21 100644
--- a/connect.c
+++ b/connect.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <netlink/genl/genl.h>
diff --git a/cqm.c b/cqm.c
index 093b744..4e2e846 100644
--- a/cqm.c
+++ b/cqm.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <netlink/genl/genl.h>
diff --git a/event.c b/event.c
index 100f644..a8b4611 100644
--- a/event.c
+++ b/event.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <stdint.h>
#include <stdbool.h>
#include <net/if.h>
diff --git a/ftm.c b/ftm.c
index 23be38e..03eaf38 100644
--- a/ftm.c
+++ b/ftm.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <netlink/genl/genl.h>
diff --git a/genl.c b/genl.c
index 7dc27f7..f8dbac3 100644
--- a/genl.c
+++ b/genl.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
/*
* This ought to be provided by libnl
*/
diff --git a/hwsim.c b/hwsim.c
index 6f82207..fbfaed3 100644
--- a/hwsim.c
+++ b/hwsim.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
diff --git a/ibss.c b/ibss.c
index f6cbc4c..645639e 100644
--- a/ibss.c
+++ b/ibss.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
#include <strings.h>
diff --git a/ieee80211.h b/ieee80211.h
index 8745608..0a7e205 100644
--- a/ieee80211.h
+++ b/ieee80211.h
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#ifndef __IEEE80211
#define __IEEE80211
diff --git a/info.c b/info.c
index e6270c8..fc0361d 100644
--- a/info.c
+++ b/info.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <stdbool.h>
#include <netlink/genl/genl.h>
diff --git a/interface.c b/interface.c
index b697482..de5546b 100644
--- a/interface.c
+++ b/interface.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
#include <stdbool.h>
diff --git a/iw.c b/iw.c
index da71617..5bb22c4 100644
--- a/iw.c
+++ b/iw.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
/*
* nl80211 userspace tool
*
diff --git a/iw.h b/iw.h
index bc0b3ac..ea7bd6c 100644
--- a/iw.h
+++ b/iw.h
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#ifndef __IW_H
#define __IW_H
diff --git a/link.c b/link.c
index 1ed7f63..4e73279 100644
--- a/link.c
+++ b/link.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <net/if.h>
#include <errno.h>
#include <string.h>
diff --git a/measurements.c b/measurements.c
index 385143f..54ca402 100644
--- a/measurements.c
+++ b/measurements.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include "nl80211.h"
diff --git a/mesh.c b/mesh.c
index 0650d0c..2591a4b 100644
--- a/mesh.c
+++ b/mesh.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
diff --git a/mgmt.c b/mgmt.c
index 338435d..8639f9c 100644
--- a/mgmt.c
+++ b/mgmt.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <string.h>
#include <errno.h>
diff --git a/mpath.c b/mpath.c
index e39c24b..3cb465b 100644
--- a/mpath.c
+++ b/mpath.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <net/if.h>
#include <errno.h>
#include <string.h>
diff --git a/mpp.c b/mpp.c
index 58bf28e..23193a4 100644
--- a/mpp.c
+++ b/mpp.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <net/if.h>
#include <errno.h>
diff --git a/nan.c b/nan.c
index 1d8d795..a846b68 100644
--- a/nan.c
+++ b/nan.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <net/if.h>
#include <errno.h>
#include <string.h>
diff --git a/nl80211.h b/nl80211.h
index 6f09d15..750b116 100644
--- a/nl80211.h
+++ b/nl80211.h
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#ifndef __LINUX_NL80211_H
#define __LINUX_NL80211_H
/*
diff --git a/ocb.c b/ocb.c
index fc9579b..1678e49 100644
--- a/ocb.c
+++ b/ocb.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
diff --git a/offch.c b/offch.c
index 19e170e..684eea3 100644
--- a/offch.c
+++ b/offch.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <netlink/genl/genl.h>
diff --git a/p2p.c b/p2p.c
index 2d4bab0..1d12046 100644
--- a/p2p.c
+++ b/p2p.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <netlink/genl/genl.h>
#include <netlink/genl/family.h>
#include <netlink/genl/ctrl.h>
diff --git a/phy.c b/phy.c
index 716677e..a5159c7 100644
--- a/phy.c
+++ b/phy.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <stdbool.h>
#include <errno.h>
#include <strings.h>
diff --git a/ps.c b/ps.c
index de36d2b..67f7a38 100644
--- a/ps.c
+++ b/ps.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
diff --git a/reason.c b/reason.c
index f91c681..74f516b 100644
--- a/reason.c
+++ b/reason.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <stdint.h>
#include "iw.h"
diff --git a/reg.c b/reg.c
index a2368df..7a83df2 100644
--- a/reg.c
+++ b/reg.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
#include <stdbool.h>
diff --git a/roc.c b/roc.c
index c6eda10..a159487 100644
--- a/roc.c
+++ b/roc.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
diff --git a/scan.c b/scan.c
index 6ad3ad4..1993f0b 100644
--- a/scan.c
+++ b/scan.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <net/if.h>
#include <errno.h>
#include <string.h>
diff --git a/sections.c b/sections.c
index 38095f6..3b0ec8b 100644
--- a/sections.c
+++ b/sections.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include "iw.h"
SECTION(get);
diff --git a/sha256.c b/sha256.c
index 4a43df8..da9d967 100644
--- a/sha256.c
+++ b/sha256.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include "sha256.h"
/**
diff --git a/sha256.h b/sha256.h
index d3eb3c0..4a32604 100644
--- a/sha256.h
+++ b/sha256.h
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#ifndef SHA256
#define SHA256
diff --git a/station.c b/station.c
index aaad079..d8f0ae3 100644
--- a/station.c
+++ b/station.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <net/if.h>
#include <errno.h>
#include <string.h>
diff --git a/status.c b/status.c
index 731727d..7529021 100644
--- a/status.c
+++ b/status.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <stdint.h>
#include "iw.h"
diff --git a/survey.c b/survey.c
index 9325353..ffaf85a 100644
--- a/survey.c
+++ b/survey.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <net/if.h>
#include <netlink/genl/genl.h>
diff --git a/util.c b/util.c
index 41277b5..55993c7 100644
--- a/util.c
+++ b/util.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <ctype.h>
#include <netlink/attr.h>
#include <errno.h>
diff --git a/vendor.c b/vendor.c
index d203d85..7610354 100644
--- a/vendor.c
+++ b/vendor.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
diff --git a/wowlan.c b/wowlan.c
index 778c0db..71392d1 100644
--- a/wowlan.c
+++ b/wowlan.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
#include <stdio.h>
--
2.17.0
^ permalink raw reply related
* Re: [PATCH 0/7] mmc: sdio: Various fixes/improvements for SDIO PM
From: Ulf Hansson @ 2019-06-20 13:43 UTC (permalink / raw)
To: linux-mmc@vger.kernel.org, Ulf Hansson, Adrian Hunter,
Douglas Anderson
Cc: Brian Norris, Shawn Lin, Guenter Roeck, Heiko Stuebner,
Kalle Valo, Arend Van Spriel, linux-wireless
In-Reply-To: <20190618153448.27145-1-ulf.hansson@linaro.org>
On Tue, 18 Jun 2019 at 17:34, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> The power management support implemented via system suspend/resume and runtime
> suspend/resume for SDIO cards is rather messy, but also fragile.
>
> This series makes some improvement to this code. In particular the so called
> powered-on re-initialization of SDIO card is quite questionable, I suspect
> it may never really worked well. Therefore this series removes this code, which
> helps to prepare for additional improvements on top in a later series.
>
> So far the series has only been compile tested, so any help in testing on HW for
> regressions is greatly appreciated.
>
> Kind regards
> Uffe
>
> Ulf Hansson (7):
> mmc: sdio: Turn sdio_run_irqs() into static
> mmc: sdio: Drop mmc_claim|release_host() in mmc_sdio_power_restore()
> mmc: sdio: Move comment about re-initialization to
> mmc_sdio_reinit_card()
> mmc: sdio: Drop powered-on re-init at runtime resume and HW reset
> mmc: sdio: Don't re-initialize powered-on removable SDIO cards at
> resume
> mmc: sdio: Drop unused in-parameter to mmc_sdio_reinit_card()
> mmc: sdio: Drop unused in-parameter from mmc_sdio_init_card()
>
> drivers/mmc/core/sdio.c | 92 +++++++++++++++----------------------
> drivers/mmc/core/sdio_irq.c | 3 +-
> include/linux/mmc/host.h | 1 -
> 3 files changed, 38 insertions(+), 58 deletions(-)
>
> --
> 2.17.1
>
I decided to queue this up, to see what tests from linux-next and
kernelCI reports.
Still, that doesn't mean I am appreciating test done on HW. I can also
apply tested-by tags by amending patches after this point.
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH] carl9170: fix enum compare splat
From: Christian Lamparter @ 2019-06-20 14:41 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <87a7ef9jp2.fsf@kamboji.qca.qualcomm.com>
On Tuesday, June 18, 2019 2:11:53 PM CEST Kalle Valo wrote:
> Christian Lamparter <chunkeey@gmail.com> writes:
> > On Monday, June 10, 2019 9:06:30 AM CEST Kalle Valo wrote:
> >> Christian Lamparter <chunkeey@gmail.com> writes:
> >>
> >> > This patch fixes a noisy warning triggered by -Wenum-compare
> >> >
> >> > |main.c:1390:31: warning: comparison between ‘enum nl80211_ac’
> >> > | and ‘enum ar9170_txq’ [-Wenum-compare]
> >> > | BUILD_BUG_ON(NL80211_NUM_ACS > __AR9170_NUM_TXQ);
> >> > | ^
> >> > | [...]
> >> >
> >> > This is a little bit unfortunate, since the number of queues
> >> > (hence NL80211_NUM_ACS) is a constant based on the IEEE 802.11
> >> > (much like IEEE80211_NUM_ACS) and __AR9170_NUM_TXQ is more or
> >> > less defined by the AR9170 hardware.
> >>
> >> Is the warning enabled by default? TBH I'm not seeing how useful this
> >> warning is for kernel development.
> >
> > It is included in the "-Wall" (which is coming from "KBUILD_CFLAGS"
> > in the main Makefile).
> >
> > I tried debian's gcc starting from 4.6 to the lastest 8.3. They all
> > complain about it in various degrees.
> >
> > https://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Warning-Options.html#Warning-Options
>
> Ok, odd that I haven't noticed this warning. Maybe I have been just
> blind.
Sorry. No, I messed up there. I made a patch back in the day during the spectre
mac80211 patches that I kept in my tree for the driver. But I now remember that
I never published those because of that exact "warning".
These lines are coming from there.
> >> > --- a/drivers/net/wireless/ath/carl9170/main.c
> >> > +++ b/drivers/net/wireless/ath/carl9170/main.c
> >> > @@ -1387,7 +1387,7 @@ static int carl9170_op_conf_tx(struct ieee80211_hw *hw,
> >> > int ret;
> >> >
> >> > BUILD_BUG_ON(ARRAY_SIZE(ar9170_qmap) != __AR9170_NUM_TXQ);
> >> > - BUILD_BUG_ON(NL80211_NUM_ACS > __AR9170_NUM_TXQ);
> >> > + BUILD_BUG_ON((size_t)NL80211_NUM_ACS > (size_t)__AR9170_NUM_TXQ);
> >>
> >> IMHO this just makes the code worse. Does it make sense to workaround
> >> (stupid) compiler warnings like this?
> >
> > True. What's worse: This isn't really code. The BUILD_BUG_ON Macro is there
> > to guard but it's getting compiled away. I could also just drop it.
>
> Either way is fine for me. If the GCC (by default) emits a warning for
> this we need to silence that warning, so in that respect I guess we
> should apply this. Unless better solutions come up, of course :)
Note: I dropped this patch from patchwork. So, there's nothing that
needs to be done now ;)
Well, except OT: Would you mind adding the QCA4019 boardfiles that
have accumulated over the past six-ish months?
<https://www.mail-archive.com/ath10k@lists.infradead.org/msg09966.html>
That list already had:
ath10k-firmware: QCA4019 hw1.0: Add ASUS Lyra specific BDFs
ath10k-firmware: QCA4019 hw1.0: Add Linksys EA6350v3
ath10k-firmware: QCA4019 hw1.0: Add Qxwlan E2600AC specific BDFs
ath10k-firmware: QCA4019 hw1.0: Update OpenMesh A62 specific BDFs
ath10k-firmware: QCA9888 hw2.0: Update OpenMesh A62 specific BDFs
ath10k-firmware: QCA4019 hw1.0: Update OpenMesh A42 specific BDFs
ath10k-firmware: QCA4019 hw1.0: Add ALFA Network AP120C-AC specific BDF
ath10k-firmware: QCA4019 hw1.0: Add AVM FRITZ!Box 7530 specific BDFs
ath10k-firmware: QCA4019 hw1.0: Update Linksys EA6350v3 specific BDFs
and now there's even more:
+ ath10k-firmware: QCA4019 hw1.0: Add Qxwlan E2600AC specific BDFs
(Watch out, there are multiple versions! The first ones are dodgy
with a bad crc)
This should be the right "one"
<https://www.mail-archive.com/ath10k@lists.infradead.org/msg10007.html>
+ ath10k-firmware: QCA4019 hw1.0: Add AVM FRITZ!Repeater 3000 specific BDFs
<https://www.mail-archive.com/ath10k@lists.infradead.org/msg10101.html>
+ ath10k-firmware: IPQ4018 hw1.0: Add EnGenius ENS620EXT specific BDFs
<http://lists.infradead.org/pipermail/ath10k/2019-March/013034.html>
+ ath10k-firmware: QCA9984 hw1.0: Update Netgear Orbi Pro SRK60 specific BDFs
ath10k-firmware: QCA4019 hw1.0: Update Netgear Orbi Pro SRK60 specific BDFs
One for QCA9984 and one for two QCA4019
<https://www.mail-archive.com/ath10k@lists.infradead.org/msg10170.html>
<https://www.mail-archive.com/ath10k@lists.infradead.org/msg10171.html>
+ ath10k-firmware: IPQ4019 hw1.0: Add BDF for Linksys EA8300 [1/2]
ath10k-firmware: QCA9888 hw1.0: Add BDF for Linksys EA8300 [2/2]
<http://lists.infradead.org/pipermail/ath10k/2019-May/013403.html>
<http://lists.infradead.org/pipermail/ath10k/2019-May/013404.html>
Cheers,
Christian
^ permalink raw reply
* Re: [PATCH 3/3] nl80211: Include wiphy address setup in NEW_WIPHY
From: Denis Kenzior @ 2019-06-20 16:16 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <ec1ca95a5789f9001e89e603633b20316d687721.camel@sipsolutions.net>
Hi Johannes,
On 06/20/2019 01:58 AM, Johannes Berg wrote:
> Didn't really review all of this yet, but
>
> switch (state->split_start) {
>> case 0:
>> + if (nla_put(msg, NL80211_ATTR_MAC, ETH_ALEN,
>> + rdev->wiphy.perm_addr))
>> + goto nla_put_failure;
>
> We generally can't add anything to any of the cases before the split was
> allowed, for compatibility with old userspace.
Can you educate me here? Is it because the non-split dump messages would
grow too large? But then non-dumps aren't split, so I still don't get
how anyone can be broken by this (that isn't already broken in the first
place).
Anyhow, What is the cut off point? It didn't seem worthwhile to send
yet-another-message for ~60 bytes of data, but if you want me to add it
as a separate message, no problem.
Regards,
-Denis
^ permalink raw reply
* Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk
From: Stefan Wahren @ 2019-06-20 18:01 UTC (permalink / raw)
To: Chi-Hsien Lin, Stanley Hsu, Arend van Spriel, Franky Lin,
Hante Meuleman, Wright Feng, linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com, brcm80211-dev-list,
Jouni Malinen
In-Reply-To: <605ea0a8-3303-b810-6223-18ccc7eb7af4@cypress.com>
Hi Chi-Hsien,
Am 17.06.19 um 10:04 schrieb Chi-Hsien Lin:
> (+Stanley)
>
> On 06/16/2019 1:21, Stefan Wahren wrote:
>> Am 15.06.19 um 19:01 schrieb Stefan Wahren:
>>> Hi,
>>>
>>> i was able to reproduce an (maybe older issue) with 4-way handshake
>>> offloading for 802.1X in the brcmfmac driver. My setup consists of
>>> Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA side and a
>>> Raspberry Pi 3 A+ (Linux 4.19) on AP side.
>> Looks like Raspberry Pi isn't the only affected platform [3], [4].
>>
>> [3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
>> [4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521
> Stefan,
>
> Could you please try the attached patch for your wpa_supplicant? We'll
> upstream if it works for you.
i tested your wpa_supplicant patch on top of current hostap-2.9-devel.
After applying the patch the driver warning disappeared.
Please take care of the upstream work.
Thanks
Stefan
>
> Regards,
> Chi-hsien Lin
^ permalink raw reply
* Re: [GIT PULL] MMC fixes for v5.2-rc6
From: pr-tracker-bot @ 2019-06-20 18:05 UTC (permalink / raw)
To: Ulf Hansson
Cc: Linus, linux-mmc, linux-kernel, Ulf Hansson, Douglas Anderson,
Kalle Valo, Arend van Spriel, linux-wireless, Adrian Hunter
In-Reply-To: <20190620111602.17958-1-ulf.hansson@linaro.org>
The pull request you sent on Thu, 20 Jun 2019 13:16:02 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v5.2-rc4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6331d118ac61454ee52d5f9be098e9ddab6d6572
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk
From: Marcel Holtmann @ 2019-06-20 18:39 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Chi-Hsien Lin, Stefan Wahren, Stanley Hsu, Franky Lin,
Hante Meuleman, Wright Feng, linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com, brcm80211-dev-list,
Jouni Malinen
In-Reply-To: <a65a9b67-8307-12d0-9ef7-94bd2eb5badf@broadcom.com>
Hi Arend,
>>>>>>>> i was able to reproduce an (maybe older issue) with 4-way handshake
>>>>>>>> offloading for 802.1X in the brcmfmac driver. My setup consists of
>>>>>>>> Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA side and a
>>>>>>>> Raspberry Pi 3 A+ (Linux 4.19) on AP side.
>>>>>>>
>>>>>>> Looks like Raspberry Pi isn't the only affected platform [3], [4].
>>>>>>>
>>>>>>> [3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
>>>>>>> [4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521
>>>>>>
>>>>>> Stefan,
>>>>>>
>>>>>> Could you please try the attached patch for your wpa_supplicant? We'll
>>>>>> upstream if it works for you.
>>>>>
>>>>> I hope that someone is also providing a kernel patch to fix the issue. Hacking around a kernel issue in userspace is not enough. Fix the root cause in the kernel.
>>>> Marcel,
>>>> This is a kernel warning for invalid application PMK set actions, so the
>>>> fix is to only set PMK to wifi driver when 4-way is offloaded. I think
>>>> Arend added the WARN_ON() intentionally to catch application misuse of
>>>> PMK setting.
>>>> You may also remove the warnings with the attached patch, but let's see
>>>> what Arend says first.
>>>> Arend,
>>>> Any comment?
>>>
>>> Hi Chi-Hsien, Marcel
>>>
>>> From the kernel side I do not see an issue. In order to use 802.1X offload the NL80211_ATTR_WANT_1X_4WAY_HS flag must be set in NL80211_CMD_CONNECT. Otherwise, NL80211_CMD_SET_PMK is not accepted. The only improvement would be to document this more clearly in the "WPA/WPA2 EAPOL handshake offload" DOC section in nl80211.h.
>> so nl80211 is an API. And an application can use that API wrongly (be that intentionally or unintentionally), the kernel can not just go WARN_ON and print a backtrace. That is your bug. So please handle wrong user input properly.
>
> You are right. However, the kernel does also return an error if the WARN_ON is hit. We can improve by using the EXT_ACK functionality to provide more info than just -EINVAL, eg. "PMK not accepted; no 802.1X offload requested on connect”.
just remove the WARN_ON and replace it with a dev_warn. Userspace should not be able to trigger WARN_ON by using nl80211.
>> Frankly, I don’t get why nl80211 itself is not validating the input and this is left to the driver. I think we need a nl80211 fuzzer that really exercises this API with random values and parameters to provide invalid input.
>
> That would mean nl80211 should keep state info between commands. From what I remember that has been avoided from day one because of the experiences with that in the WEXT days. I welcome any testing be it fuzzer or something else.
And now driver bugs are bleeding into the API. I expect from a kernel API that it hides driver details. From an userspace program perspective I expect exactly the same input validation and behavior no matter what hardware is used underneath. If we can not do that, then this API has a broken design.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 3/3] nl80211: Include wiphy address setup in NEW_WIPHY
From: Johannes Berg @ 2019-06-20 19:17 UTC (permalink / raw)
To: Denis Kenzior; +Cc: linux-wireless
In-Reply-To: <7da9b924-78c7-ba72-fecc-a11700a34ff4@gmail.com>
Hi Denis,
> > We generally can't add anything to any of the cases before the split was
> > allowed, for compatibility with old userspace.
>
> Can you educate me here? Is it because the non-split dump messages would
> grow too large?
No. Those messages aren't really relevant, userspace will need to do a
larger buffer for it.
The problem is that old userspace (like really old) didn't split even
dumps. Eventually, we had so much information here that the default dump
message size is exceeded, and we simply couldn't dump that particular
wiphy anymore.
We solved this by splitting the wiphy information into multiple
messages, but that needed new userspace, so when userspace doesn't
request split dumps, we fall through all the way to "case 8" and then
stop - old userspace cannot care about new information anyway.
The reason it was split into cases 0-8 that are combined in non-split
dumps is that it was safer that way - there were certain configurations
where even the original data would go above the message size limit.
> Anyhow, What is the cut off point? It didn't seem worthwhile to send
> yet-another-message for ~60 bytes of data, but if you want me to add it
> as a separate message, no problem.
It doesn't matter if you add it as a separate message or not, you can
add it to later messages, i.e. anything in or after "case 9" is fine.
johannes
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in p54u_load_firmware_cb
From: Alan Stern @ 2019-06-20 19:46 UTC (permalink / raw)
To: syzbot
Cc: andreyknvl, chunkeey, davem, kvalo, Kernel development list,
USB list, linux-wireless, netdev, syzkaller-bugs
In-Reply-To: <000000000000f00cf1058bb7fb56@google.com>
On Wed, 19 Jun 2019, syzbot wrote:
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit: 9939f56e usb-fuzzer: main usb gadget fuzzer driver
> git tree: https://github.com/google/kasan.git usb-fuzzer
> console output: https://syzkaller.appspot.com/x/log.txt?x=135e29faa00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=df134eda130bb43a
> dashboard link: https://syzkaller.appspot.com/bug?extid=6d237e74cdc13f036473
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=175d946ea00000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+6d237e74cdc13f036473@syzkaller.appspotmail.com
>
> usb 3-1: Direct firmware load for isl3887usb failed with error -2
> usb 3-1: Firmware not found.
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in p54u_load_firmware_cb.cold+0x97/0x13d
> drivers/net/wireless/intersil/p54/p54usb.c:936
> Read of size 8 at addr ffff8881c9cf7588 by task kworker/1:5/2759
>
> CPU: 1 PID: 2759 Comm: kworker/1:5 Not tainted 5.2.0-rc5+ #11
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: events request_firmware_work_func
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0xca/0x13e lib/dump_stack.c:113
> print_address_description+0x67/0x231 mm/kasan/report.c:188
> __kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317
> kasan_report+0xe/0x20 mm/kasan/common.c:614
> p54u_load_firmware_cb.cold+0x97/0x13d
> drivers/net/wireless/intersil/p54/p54usb.c:936
> request_firmware_work_func+0x126/0x242
> drivers/base/firmware_loader/main.c:785
> process_one_work+0x905/0x1570 kernel/workqueue.c:2269
> worker_thread+0x96/0xe20 kernel/workqueue.c:2415
> kthread+0x30b/0x410 kernel/kthread.c:255
> ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
>
> Allocated by task 1612:
> save_stack+0x1b/0x80 mm/kasan/common.c:71
> set_track mm/kasan/common.c:79 [inline]
> __kasan_kmalloc mm/kasan/common.c:489 [inline]
> __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:462
> kmalloc include/linux/slab.h:547 [inline]
> syslog_print kernel/printk/printk.c:1346 [inline]
> do_syslog kernel/printk/printk.c:1519 [inline]
> do_syslog+0x4f4/0x12e0 kernel/printk/printk.c:1493
> kmsg_read+0x8a/0xb0 fs/proc/kmsg.c:40
> proc_reg_read+0x1c1/0x280 fs/proc/inode.c:221
> __vfs_read+0x76/0x100 fs/read_write.c:425
> vfs_read+0x18e/0x3d0 fs/read_write.c:461
> ksys_read+0x127/0x250 fs/read_write.c:587
> do_syscall_64+0xb7/0x560 arch/x86/entry/common.c:301
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Freed by task 1612:
> save_stack+0x1b/0x80 mm/kasan/common.c:71
> set_track mm/kasan/common.c:79 [inline]
> __kasan_slab_free+0x130/0x180 mm/kasan/common.c:451
> slab_free_hook mm/slub.c:1421 [inline]
> slab_free_freelist_hook mm/slub.c:1448 [inline]
> slab_free mm/slub.c:2994 [inline]
> kfree+0xd7/0x280 mm/slub.c:3949
> syslog_print kernel/printk/printk.c:1405 [inline]
> do_syslog kernel/printk/printk.c:1519 [inline]
> do_syslog+0xff3/0x12e0 kernel/printk/printk.c:1493
> kmsg_read+0x8a/0xb0 fs/proc/kmsg.c:40
> proc_reg_read+0x1c1/0x280 fs/proc/inode.c:221
> __vfs_read+0x76/0x100 fs/read_write.c:425
> vfs_read+0x18e/0x3d0 fs/read_write.c:461
> ksys_read+0x127/0x250 fs/read_write.c:587
> do_syscall_64+0xb7/0x560 arch/x86/entry/common.c:301
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The buggy address belongs to the object at ffff8881c9cf7180
> which belongs to the cache kmalloc-1k of size 1024
> The buggy address is located 8 bytes to the right of
> 1024-byte region [ffff8881c9cf7180, ffff8881c9cf7580)
> The buggy address belongs to the page:
> page:ffffea0007273d00 refcount:1 mapcount:0 mapping:ffff8881dac02a00
> index:0x0 compound_mapcount: 0
> flags: 0x200000000010200(slab|head)
> raw: 0200000000010200 dead000000000100 dead000000000200 ffff8881dac02a00
> raw: 0000000000000000 00000000000e000e 00000001ffffffff 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8881c9cf7480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8881c9cf7500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ffff8881c9cf7580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ^
> ffff8881c9cf7600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8881c9cf7680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
Isn't this the same as syzkaller bug 200d4bb11b23d929335f ? Doesn't
the same patch fix it?
Alan Stern
^ 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