Re: [PATCH V2] Fix a sleep-in-atomic bug in shash_setkey_unaligned

On Mon, Oct 02, 2017 at 09:18:24PM -0700, Andy Lutomirski wrote: > > On Oct 2, 2017, at 7:25 PM, Jia-Ju Bai wrote: > > > > The SCTP program may sleep under a spinlock, and the function call path is: > > sctp_generate_t3_rtx_event (acquire the spinlock) > > sctp_do_sm > >

Re: [PATCH V2] Fix a sleep-in-atomic bug in shash_setkey_unaligned

> On Oct 2, 2017, at 7:25 PM, Jia-Ju Bai wrote: > > The SCTP program may sleep under a spinlock, and the function call path is: > sctp_generate_t3_rtx_event (acquire the spinlock) > sctp_do_sm >sctp_side_effects > sctp_cmd_interpreter >sctp_make_init_ack >

[PATCH V2] Fix a sleep-in-atomic bug in shash_setkey_unaligned

The SCTP program may sleep under a spinlock, and the function call path is: sctp_generate_t3_rtx_event (acquire the spinlock) sctp_do_sm sctp_side_effects sctp_cmd_interpreter sctp_make_init_ack sctp_pack_cookie crypto_shash_setkey

[PATCH] Fix a sleep-in-atomic bug in shash_setkey_unaligned

For the same reason, the orinoco driver may sleep in interrupt handler, and the function call path is: orinoco_rx_isr_tasklet orinoco_rx orinoco_mic crypto_shash_setkey shash_setkey_unaligned kmalloc(GFP_KERNEL) To fix it, GFP_KERNEL is replaced with GFP_ATOMIC.

Re: [PATCH 05/18] net: use ARRAY_SIZE

On Mon, 02 Oct 2017 16:46:29 +0300 Kalle Valo wrote: > We have a tree for wireless so usually it's better to submit wireless > changes on their own but here I assume Dave will apply this to his tree. > If not, please resubmit the wireless part in a separate patch. Ok, I

Re: [PATCH 00/18] use ARRAY_SIZE macro

On Mon, 2 Oct 2017 15:22:24 -0400 bfie...@fieldses.org (J. Bruce Fields) wrote: > Mainly I'd just like to know which you're asking for. Do you want me to > apply this, or to ACK it so someone else can? If it's sent as a series > I tend to assume the latter. > > But in this case I'm assuming

Re: [PATCH 05/18] net: use ARRAY_SIZE

On Mon, 2 Oct 2017 16:07:36 +0300 Andy Shevchenko wrote: > > + {_lut_core0_rev0, ARRAY_SIZE(gainctrl_lut_core0_rev0), 26, > > 192, > > +32}, > > For all such cases I would rather put on one line disregard checkpatch > warning for better readability. I

Re: [PATCH] cfg80211/nl80211: add a port authorized event

On 29-09-17 14:21, Johannes Berg wrote: From: Avraham Stern Add an event that indicates that a connection is authorized (i.e. the 4 way handshake was performed by the driver). This event should be sent by the driver after sending a connect/roamed event. So is this

Re: [PATCH 00/18] use ARRAY_SIZE macro

On Mon, Oct 02, 2017 at 07:35:54AM +0200, Greg KH wrote: > On Sun, Oct 01, 2017 at 08:52:20PM -0400, Jérémy Lefaure wrote: > > On Mon, 2 Oct 2017 09:01:31 +1100 > > "Tobin C. Harding" wrote: > > > > > > In order to reduce the size of the To: and Cc: lines, each patch of the > > >

Re: [PATCH 00/18] use ARRAY_SIZE macro

Em Sun, 1 Oct 2017 20:52:20 -0400 Jérémy Lefaure escreveu: > Anyway, I can tell to each maintainer that they can apply the patches > they're concerned about and next time I may send individual patches. In the case of media, we'll handle it as if they were individual

Re: [PATCH] PCI MSI: allow alignment restrictions on vector allocation

On Mon, 2 Oct 2017, Thomas Gleixner wrote: > On Mon, 2 Oct 2017, Daniel Drake wrote: > 2) The affinity setting of straight MSI interrupts (w/o remapping) on x86 > requires to make the affinity change from the interrupt context of the > current active vector in order not to lose

Re: [PATCH] nl80211: look for HT/VHT capabilities in beacon's tail

On Wed, Aug 30, 2017 at 01:52:25PM -0700, igor.mitsyanko...@quantenna.com wrote: > There are no HT/VHT capabilities in cfg80211_ap_settings::beacon_ies, > these should be looked for in beacon's tail instead. > > Signed-off-by: Igor Mitsyanko > --- > > This is

Re: [PATCH] PCI MSI: allow alignment restrictions on vector allocation

Daniel, On Mon, 2 Oct 2017, Daniel Drake wrote: > On Wed, Sep 27, 2017 at 11:28 PM, Thomas Gleixner wrote: > On another system, I have multiple devices using IR-PCI-MSI according > to /proc/interrupts, and lspci shows that a MSI Message Data value 0 > is used for every single

Re: [V3,1/3] brcmfmac: Avoid possible out-of-bounds read

Kevin Cernekee wrote: > In brcmf_p2p_notify_rx_mgmt_p2p_probereq(), chanspec is assigned before > the length of rxframe is validated. This could lead to uninitialized > data being accessed (but not printed). Since we already have a > perfectly good endian-swapped copy of

Re: [v4,2/9] brcmsmac: split up wlc_phy_workarounds_nphy

Arnd Bergmann wrote: > The stack consumption in this driver is still relatively high, with one > remaining warning if the warning level is lowered to 1536 bytes: > > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:17135:1: error: > the frame size of 1880 bytes is

Re: [v4, 1/9] brcmsmac: make some local variables 'static const' to reduce stack size

Arnd Bergmann wrote: > With KASAN and a couple of other patches applied, this driver is one > of the few remaining ones that actually use more than 2048 bytes of > kernel stack: > > broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function > 'wlc_phy_workarounds_nphy_gainctrl': >

Re: [V3,3/3] brcmfmac: Add check for short event packets

Kevin Cernekee wrote: > The length of the data in the received skb is currently passed into > brcmf_fweh_process_event() as packet_len, but this value is not checked. > event_packet should be followed by DATALEN bytes of additional event > data. Ensure that the received

Re: [PATCH 05/18] net: use ARRAY_SIZE

Jérémy Lefaure writes: > Using the ARRAY_SIZE macro improves the readability of the code. Also, > it is not always useful to use a variable to store this constant > calculated at compile time. > > Found with Coccinelle with the following semantic patch: > @r depends

Re: [PATCH 05/18] net: use ARRAY_SIZE

On Sun, Oct 1, 2017 at 10:30 PM, Jérémy Lefaure wrote: > Using the ARRAY_SIZE macro improves the readability of the code. Also, > it is not always useful to use a variable to store this constant > calculated at compile time. > > + {_lut_core0_rev0,

Re: rtlwifi: rtl8821ae: Fix connection lost problem

Larry Finger wrote: > In commit 40b368af4b75 ("rtlwifi: Fix alignment issues"), the read > of REG_DBI_READ was changed from 16 to 8 bits. For unknown reasonsi > this change results in reduced stability for the wireless connection. > This regression was located using

Re: [V3,3/3] brcmfmac: Add check for short event packets

Kevin Cernekee wrote: > The length of the data in the received skb is currently passed into > brcmf_fweh_process_event() as packet_len, but this value is not checked. > event_packet should be followed by DATALEN bytes of additional event > data. Ensure that the received

Re: [RFC] Add cfg80211/nl80211 support for AP mode 802.11 FT roaming

On Mon, 2017-09-25 at 15:30 +0300, Dedy Lansky wrote: > From: Dedy Lansky > > Drivers which have integrated AP SME can use this to communicate with > userspace (e.g. hostapd) for the purpose of FT roaming processing. > > cfg80211 API added for driver to indicate received

Re: [PATCH] mac80211: aead api to reduce redundancy

Please use "v2" tag or so in the subject line, having the same patch again is really not helpful. The next should be v3, obviously. > +++ b/net/mac80211/aead_api.c > @@ -1,7 +1,4 @@ > -/* > - * Copyright 2014-2015, Qualcomm Atheros, Inc. > - * > - * This program is free software; you can

Re: [PATCH] ath10k: Retry pci probe on failure.

Hi Ben, [auto build test ERROR on ath6kl/ath-next] [also build test ERROR on v4.14-rc3 next-20170929] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 02/11] ath10k_sdio: wb396 reference card fix

Hi Alagu, On 2017-10-02 09:02, Alagu Sankar wrote: Hi Steve, On 2017-10-02 04:17, Steve deRosier wrote: Hi Alagu, On Sat, Sep 30, 2017 at 10:37 AM, wrote: From: Alagu Sankar The QCA9377-3 WB396 sdio reference card does not get

Re: [PATCH 00/11] SDIO support for ath10k

Hi Alagu, It is great to see that we are finally about have fully working mainline support for QCA9377 SDIO chipsets! Great job! On 2017-09-30 19:37, silexcom...@gmail.com wrote: From: Alagu Sankar This patchset, generated against master-pending branch, enables

Re: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN

On Thu, Sep 28, 2017 at 4:30 PM, Arnd Bergmann wrote: > On Thu, Sep 28, 2017 at 6:09 AM, Andrey Ryabinin > wrote: >> On 09/27/2017 04:26 PM, Arnd Bergmann wrote: >>> On Tue, Sep 26, 2017 at 9:49 AM, Andrey Ryabinin >>> wrote: >

Re: [PATCH 02/11] ath10k_sdio: wb396 reference card fix

Hi Steve, On 2017-10-02 04:17, Steve deRosier wrote: Hi Alagu, On Sat, Sep 30, 2017 at 10:37 AM, wrote: From: Alagu Sankar The QCA9377-3 WB396 sdio reference card does not get initialized due to the conflict in uart gpio pins. This fix

Re: [PATCH 01/11] ath10k_sdio: sdio htt data transfer fixes

Hi Arend, On 2017-10-02 13:06, Arend van Spriel wrote: On 9/30/2017 7:37 PM, silexcom...@gmail.com wrote: From: Alagu Sankar [...] Signed-off-by: Alagu Sankar Not really have a specific remark for this patch, but for the

Re: [PATCH 01/11] ath10k_sdio: sdio htt data transfer fixes

On 9/30/2017 7:37 PM, silexcom...@gmail.com wrote: From: Alagu Sankar [...] Signed-off-by: Alagu Sankar Not really have a specific remark for this patch, but for the entire series. These patches are sent using an anonymous