Hi,
Looks like this played out while I wasn't paying attention :-)
So first, I'll say that I have no objection in principle to the patch,
as a debugging aid.
However, the story is more complicated.
> IIUC tshark and other specific capture tools need wireless netdevice
> to be in monitor mode.
Hi,
As we discussed in April already (it's really been that long...), I'd
wanted to allow using BPF to filter wireless monitor frames, to enable
new use cases and higher performance in monitoring. I have some code,
at
https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git/log/?h=
On Mon, Oct 16, 2017 at 02:41:38AM +, Pkshih wrote:
> 2) The rtlwifi in staging
>In staging, the module phydm v13 contains bugs, so I want to upgrade
>to v21 (Realtek internal version number). This upgrade contains a
>big patch that the difference between v13 and v21, and there are
On Mon, Oct 16, 2017 at 02:41:38AM +, Pkshih wrote:
>
>
> > -Original Message-
> > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> > Sent: Thursday, October 12, 2017 6:35 PM
> > To: Kalle Valo
> > Cc: Larry Finger; Dan Carpenter; Pkshih; 莊彥宣; Johannes Berg; Souptick
>
Hello Johannes and all,
> So first, I'll say that I have no objection in principle to the patch,
> as a debugging aid.
>
> However, the story is more complicated.
>
> > IIUC tshark and other specific capture tools need wireless netdevice
> > to be in monitor mode.
>
> This is correct, but shoul
From: Johannes Berg
When a key is reinstalled we can reset the replay counters
etc. which can lead to nonce reuse and/or replay detection
being impossible, breaking security properties, as described
in the "KRACK attacks".
In particular, CVE-2017-13080 applies to GTK rekeying that
happened in fi
Hi!
In -next... after few days of usage with suspend and resume cycles,
wifi failed on thinkpad x60. I have not seen this in years...
[28140.944044] CE: hpet increased min_delta_ns to 20115 nsec
[28174.048418] iwl3945 :03:00.0: Error sending C_RATE_SCALE: time
out after 500ms.
[28174.048430]
On Mon, 2017-10-16 at 11:48 +0300, Sergey Matyukevich wrote:
>
> Well, monitor mode support in qtnfmac is in our todo list for sure.
Sure. I'm saying you don't really need full monitor support at all,
just a pure software construct for this.
> Meanwhile the purpose of the patch was not to imple
Hi Dmitry
On Sat, Oct 14, 2017 at 04:38:03PM +0200, Dmitry Vyukov wrote:
> On Thu, Oct 12, 2017 at 9:25 AM, Stanislaw Gruszka
> wrote:
> > Hi
> >
> > On Mon, Oct 09, 2017 at 07:50:53PM +0200, Andrey Konovalov wrote:
> >> I've got the following report while fuzzing the kernel with syzkaller.
> >>
> > Let me know if you have any objections to implementation details :)
>
> Yeah, I'll need to review it, just need a bit more time for that.
>
> > Then I will resubmit it addressing all the comments. Besides I am
> > going to change command name from 'capture' to 'dump' to avoid
> > confusion. F
Dmitry Vyukov writes:
> On Thu, Oct 12, 2017 at 9:25 AM, Stanislaw Gruszka
> wrote:
>> Hi
>>
>> On Mon, Oct 09, 2017 at 07:50:53PM +0200, Andrey Konovalov wrote:
>>> I've got the following report while fuzzing the kernel with syzkaller.
>>>
>>> On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f
Hi!
> In -next... after few days of usage with suspend and resume cycles,
> wifi failed on thinkpad x60. I have not seen this in years...
>
> [28140.944044] CE: hpet increased min_delta_ns to 20115 nsec
> [28174.048418] iwl3945 :03:00.0: Error sending C_RATE_SCALE: time
> out after 500ms.
> [
Hi
Site note: Intel folks do not support iwlegacy, I removed them from CC.
On Mon, Oct 16, 2017 at 12:27:45PM +0200, Pavel Machek wrote:
> > In -next... after few days of usage with suspend and resume cycles,
> > wifi failed on thinkpad x60. I have not seen this in years...
> > Any ideas?
We do
On Mon, Oct 16, 2017 at 11:40 AM, Stanislaw Gruszka wrote:
> Hi Dmitry
>
> On Sat, Oct 14, 2017 at 04:38:03PM +0200, Dmitry Vyukov wrote:
>> On Thu, Oct 12, 2017 at 9:25 AM, Stanislaw Gruszka
>> wrote:
>> > Hi
>> >
>> > On Mon, Oct 09, 2017 at 07:50:53PM +0200, Andrey Konovalov wrote:
>> >> I've
On Mon, Oct 16, 2017 at 12:27 PM, Kalle Valo wrote:
> Dmitry Vyukov writes:
>
>> On Thu, Oct 12, 2017 at 9:25 AM, Stanislaw Gruszka
>> wrote:
>>> Hi
>>>
>>> On Mon, Oct 09, 2017 at 07:50:53PM +0200, Andrey Konovalov wrote:
I've got the following report while fuzzing the kernel with syzkall
On Mon 2017-10-16 12:51:55, Stanislaw Gruszka wrote:
> Hi
>
> Site note: Intel folks do not support iwlegacy, I removed them from CC.
>
> On Mon, Oct 16, 2017 at 12:27:45PM +0200, Pavel Machek wrote:
> > > In -next... after few days of usage with suspend and resume cycles,
> > > wifi failed on th
On Mon, Oct 16, 2017 at 02:24:56PM +0200, Pavel Machek wrote:
> So far it happened once... so I don't know about reproducibility. And
> I'm not even sure if I'm using iwlegacy driver. Am I?
iwl3945 (and iwl4965) are iwlegacy drivers.
Regards
Stanislaw
From: Rafał Miłecki
Using bcma_debug gives a device-specific prefix for messages and pr_cont
is a common helper for continuing a line.
Signed-off-by: Rafał Miłecki
---
drivers/bcma/driver_mips.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/bcma/driver_mips
icen...@aosc.io writes:
> > > Like I asked already last time, AFAICS there is no upstream xr819
> > > wireless driver in drivers/net/wireless directory. Do we still
accept
> > > bindings like this for out-of-tree drivers?
> >
> > See esp8089.
> >
> > There's also n
Dan Carpenter writes:
> On Mon, Oct 16, 2017 at 02:41:38AM +, Pkshih wrote:
>> 2) The rtlwifi in staging
>>In staging, the module phydm v13 contains bugs, so I want to upgrade
>>to v21 (Realtek internal version number). This upgrade contains a
>>big patch that the difference betwe
Oleksij Rempel writes:
>> 4) As Kalle mentioned, rtlwifi contains many magic numbers, and I
>>plan to fix them after rtl8723de and rtl8821ce. Because the drivers
>>are developing, the changes will make us hard to integrate. However,
>>I don't have plan to process the magic numbers in
Am 16.10.2017 um 15:07 schrieb Kalle Valo:
> Oleksij Rempel writes:
>
>>> 4) As Kalle mentioned, rtlwifi contains many magic numbers, and I
>>>plan to fix them after rtl8723de and rtl8821ce. Because the drivers
>>>are developing, the changes will make us hard to integrate. However,
>>>
Hi PK,
you got good answers already so only short reply from me:
Pkshih writes:
> 3) Coming drivers -- rtl8723de and rtl8821ce
>We're developing the two drivers, and rtl8723de and rtl8821ce will
>be ready on 2017Q4 and 2018Q1 respectively. The drivers are based on
>rtl8822be that in
Hi Dave,
Here's a fix, for a small part of the "KRACK" announced today
(krackattacks.com).
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit c0576e3975084d4699b7bfef578613fb8e1144f6:
net: call cgroup_sk_alloc() earlier in sk_clone_lock(
From: Johannes Berg
When netlink_ack() reports an allocation error to the sending
socket, there's no need to look up the sending socket since
it's available in the SKB's CB. Use that instead of going to
the trouble of looking it up.
Note that the pointer is only available since Eric Biederman's
The fq structure would fail to properly enforce the memory limit in the case
where the packet being enqueued was bigger than the packet being removed to
bring the memory usage down. So keep dropping packets until the memory usage is
back below the limit. Also, fix the statistics for memory limit vi
From: Johannes Berg
It seems that it's possible to toggle NETLINK_F_EXT_ACK
through setsockopt() while another thread/CPU is building
a message inside netlink_ack(), which could then trigger
the WARN_ON()s I added since if it goes from being turned
off to being turned on between allocating and fi
This adds an API to mac80211 to handle scheduling of TXQs and changes the
interface between driver and mac80211 for TXQ handling as follows:
- The wake_tx_queue callback interface no longer includes the TXQ. Instead, the
driver is expected to retrieve that from ieee80211_next_txq()
- Two new ma
This adds airtime accounting and scheduling to the mac80211 TXQ scheduler. A new
hardware flag, AIRTIME_ACCOUNTING, is added that drivers can set if they support
reporting airtime usage of transmissions. When this flag is set, mac80211 will
expect the actual airtime usage to be reported in the tx_t
On 10/16/2017 02:24 AM, Johannes Berg wrote:
Right, and I didn't originally see the patch as such, just that the
discussion (and in particular Julian's suggestion) veered off in that
direction.
Nevertheless in certain cases it is handy to dump selected types of
mgmt frames while system is up
On 10/15/2017 01:53 PM, Sergey Matyukevich wrote:
Hello Kalle, Igor, and all
This patch series includes a number of small features and fixes
for qtnfmac driver.
Igor Mitsyanko (1):
qtnfmac: advertise support of inactivity timeout
Sergey Matyukevich (4):
qtnfmac: modify full Tx queue error
From: Johannes Berg
Date: Mon, 16 Oct 2017 15:46:17 +0200
> Here's a fix, for a small part of the "KRACK" announced today
> (krackattacks.com).
>
> Please pull and let me know if there's any problem.
Pulled.
On 10/16/2017 02:54 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> Using bcma_debug gives a device-specific prefix for messages and pr_cont
> is a common helper for continuing a line.
>
> Signed-off-by: Rafał Miłecki
Acked-By: Hauke Mehrtens
> ---
> drivers/bcma/driver_mips.c | 7 --
As part of removing the timer_list.data field, this converts the wilc1000
driver to using from_timer and an explicit per-timer data field, since
there doesn't appear to be a way to sanely resolve vif from hif_drv.
Cc: Aditya Shankar
Cc: Ganesh Krishna
Cc: Greg Kroah-Hartman
Cc: linux-wireless@v
Mobile phone right now, so not able to write patch, but you probably
should be using crypto_memneq for comparing those two keys, not
memcmp.
Jason
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Cc: Johannes Berg
Cc: "David S. Miller"
Cc: linux-wireless@vger.kernel.org
Cc: net...@vger.kernel.org
Sign
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Cc: Igor Mitsyanko
Cc: Avinash Patil
Cc: Sergey Matyukevich
Cc: Kalle Valo
Cc: Kamlesh Rath
Cc: linux-w
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Cc: Larry Finger
Cc: Chaoming Li
Cc: Kalle Valo
Cc: Ping-Ke Shih
Cc: Arvind Yadav
Cc: Souptick Joarder
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Cc: Stanislaw Gruszka
Cc: Kalle Valo
Cc: linux-wireless@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Cc: Kalle Valo
Signed-off-by: Kees Cook
---
drivers/net/wireless/ath/ar5523/ar5523.c | 7 +++
d
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Cc: Kalle Valo
Cc: linux-wireless@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off-by: Kees Cook
---
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Cc: Solomon Peachy
Cc: Kalle Valo
Cc: linux-wireless@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off
> -Original Message-
> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> Sent: Monday, October 16, 2017 3:50 PM
> To: Pkshih
> Cc: Larry Finger; Kalle Valo; Dan Carpenter; 莊彥宣; Johannes Berg; Souptick
> Joarder;
> de...@driverdev.osuosl.org; linux-wireless@vger.kernel.org;
> -Original Message-
> From: Kalle Valo [mailto:kv...@codeaurora.org]
> Sent: Monday, October 16, 2017 9:23 PM
> To: Pkshih
> Cc: Larry Finger; Greg Kroah-Hartman; Dan Carpenter; 莊彥宣; Johannes Berg;
> Souptick Joarder;
> de...@driverdev.osuosl.org; linux-wireless@vger.kernel.org;
> kern
On Tue, 2017-10-17 at 01:30 +0200, Jason A. Donenfeld wrote:
> Mobile phone right now, so not able to write patch, but you probably
> should be using crypto_memneq for comparing those two keys, not
> memcmp.
I know that's a gut instinct, but I really don't see the point.
If you actually get this
> Maybe we could add an additional nl attribute to
> NL80211_CMD_REGISTER_FRAME command to allow applications to
> advertise
> what is their intention, something like
> NL80211_ATTR_MGMT_LISTENER_TYPE.
> Only allow to register more then one listener if it explicitly
> specifies
> that it will n
> /* protects shared structure data */
> spinlock_t data_lock;
> - /* protects: ar->txqs, artxq->list */
> - spinlock_t txqs_lock;
>
> - struct list_head txqs;
I don't see you removing the artxq->list member, but surely it can't be
used any more now, without a list?
[sn
47 matches
Mail list logo
