Hi,
We have a bunch more things for next, now that we got another
week "for free" ;-) Pretty much all over the map, see the tag
description and shortlog below.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following chang
ah, my bad, I only put the offending patch into -next, I
misremembered. Sorry for the noise.
johannes
rmware version: 17.3216344376.0
> 7260-17.ucode
> [ +0,05] iwlwifi :02:00.0: 0x0084 | NMI_INTERRUPT_UNKNOWN
Do you use MFP?
Could be related to
https://patchwork.kernel.org/project/linux-wireless/patch/20210416134702.ef8486a64293.If0a9025b39c71bb91b11dd6ac45547aba682df34@changeid/
I saw similar issues internally without that fix.
johannes
rating as non-
DMG yet on a DMG channel, which makes no sense.
I don't think anyone's planning to add DMG support to mac80211, and in
the absence of a real driver requiring that it wouldn't make sense
anyway. Quite possibly, it simply doesn't make sense period, because DMG
operation is sufficiently different.
johannes
On Mon, 2021-04-12 at 22:06 -0300, Ramon Fontes wrote:
> Advertise 60GHz channels to mac80211.
This is wrong. mac80211 doesn't support 60 GHz operation.
johannes
er overrun fix, as
reported by syzbot.
The only thing that's bigger is the rfkill thing, but that's just since
it adds a new version of the struct for userspace to use, since the
change to the existing struct caused various breakage all around.
Please pull and let me know if there
On Thu, 2021-04-08 at 14:53 +0200, Johannes Berg wrote:
> Hi,
>
> Yes, I'm late with this, sorry about that. I've mostly restricted this
> to the most necessary fixes, though the virt_wifi one isn't but since
> that's not used a lot, it's harmless and in
ng, but that's just since
it adds a new version of the struct for userspace to use, since the
change to the existing struct caused various breakage all around.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 8a12f8836145ffe37e
tes. You're breaking it with this patch.
Also, the (NULL) pointer is not actually _used_ anywhere, so why would
it matter?
johannes
On Thu, Mar 25, 2021 at 10:02:28AM +0100, Michal Hocko wrote:
> On Wed 24-03-21 15:49:15, Arjun Roy wrote:
> > On Wed, Mar 24, 2021 at 2:24 PM Johannes Weiner wrote:
> > >
> > > On Wed, Mar 24, 2021 at 10:12:46AM +0100, Michal Hocko wrote:
> > > > On
On Wed, Mar 24, 2021 at 10:12:46AM +0100, Michal Hocko wrote:
> On Tue 23-03-21 11:47:54, Arjun Roy wrote:
> > On Tue, Mar 23, 2021 at 7:34 AM Michal Hocko wrote:
> > >
> > > On Wed 17-03-21 18:12:55, Johannes Weiner wrote:
> > > [...]
> >
On Mon, Mar 22, 2021 at 02:35:11PM -0700, Arjun Roy wrote:
> To make sure we're on the same page, then, here's a tentative
> mechanism - I'd rather get buy in before spending too much time on
> something that wouldn't pass muster afterwards.
>
> A) An opt-in mechanism, that a driver needs to expli
On Tue, Mar 16, 2021 at 11:05:11PM -0700, Arjun Roy wrote:
> On Tue, Mar 16, 2021 at 3:27 AM Johannes Weiner wrote:
> >
> > Hello,
> >
> > On Mon, Mar 15, 2021 at 09:16:45PM -0700, Arjun Roy wrote:
> > > From: Arjun Roy
> > >
> > > TC
Hi Dave,
So here's a first set of fixes for the current rc cycle,
really nothing major, though the network namespace locking
fix is something a few people have been running into.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes si
o the 30s entry lifetime, that's nothing.
So what's the point? Please fix the driver instead to actually hold on
to it and report it back.
johannes
serts? That's only 32
pages worth of overcharging, so not more than the regular charge
batch memcg is using.
An even better way would be to do charge stealing where we reuse
the existing MEMCG_SOCK charges and don't have to get any new ones
at all - just set up page->memcg and remove the charge from the sk.
But yeah, it depends a bit if this is a practical concern.
Thanks,
Johannes
at
it (also way down the list since it was reported as directly in hwsim)
johannes
only case, tbh, since over the air you have
limits how much bandwidth you can get ... unless you have a very slow
CPU?
In any case, if you want anything merged you're going to have to submit
a proper patch with a real commit message and Signed-off-by, etc.
johannes
Muchun, can you please reduce the CC list to mm/memcg folks only for
the next submission? I think probably 80% of the current recipients
don't care ;-)
On Mon, Mar 01, 2021 at 10:11:45AM -0800, Shakeel Butt wrote:
> On Sun, Feb 28, 2021 at 10:25 PM Muchun Song wrote:
> >
> > We want to reuse the
+ return LOCK_STATE_UNKNOWN;
I'd argue that then the other two return places here should also be
changed.
johannes
On Mon, 2021-02-22 at 19:51 +0100, Marc Kleine-Budde wrote:
> On 22.02.2021 17:30:59, Johannes Berg wrote:
> > On Mon, 2021-02-22 at 16:12 +0100, Oleksij Rempel wrote:
> > > This code is trying to clone the skb with optional skb->sk. But this
> > > will fail to clon
ep the socket open for that :)
Having the ACK skb will just make us do more work by handing it back
to skb_complete_wifi_ack() at TX status time, which is supposed to put
it into the socket's error queue, but if the socket is closed ... no
point in that.
johannes
t this, wouldn't we be better off if we define
NL80211_BAND_INFRARED or something? That way, at least we can tell that
it's not going to interoperate with real 2.4 GHz, etc.
OTOH, this is a bit of a slippery slow - what if somebody else designs
an *incompatible* infrared PHY? I guess this is not really standardised
at this point.
Not really sure about all this, but I guess we need to think about it
more.
What are your reasons for piggy-backing on 2.4 GHz? Just practical "it's
there and we don't care"?
johannes
On Thu, 2021-02-18 at 18:31 +0100, Sebastian Andrzej Siewior wrote:
> The recent addition of in_serving_softirq() to kconv.h results in
You typo'ed "kconv.h" pretty consistently ;-)
But yes, that makes sense.
Acked-by: Johannes Berg
johannes
On Mon, 2021-02-15 at 17:04 +0100, Peter Zijlstra wrote:
> On Mon, Feb 15, 2021 at 02:12:30PM +0100, Johannes Berg wrote:
> > On Mon, 2021-02-15 at 11:44 +0100, Peter Zijlstra wrote:
> > > I think something like so will work, but please double check.
> >
>
int lock_is_held_type(const struct lockdep_map
> *lock, int read)
> int ret = 0;
>
> if (unlikely(!lockdep_enabled()))
> - return 1; /* avoid false negative lockdep_assert_held() */
> + return -1; /* avoid false negative lockdep_assert_held() */
Maybe add lockdep_assert_not_held() to the comment, to explain the -1
(vs non-zero)?
johannes
Hi,
This is almost certainly a last update for net-next, and
it's not very big - the biggest chunk here is minstrel
improvements from Felix, to lower overhead.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes si
to a few attempts
> + buffer = urb->transfer_buffer;
> + length = (*(u32 *)(buffer + sizeof(struct rx_status))) + sizeof(u32);
endian issues
> + kfree(urbs);
> +
> + spin_lock_irqsave(&rx->lock, flags);
> + rx->urbs = NULL;
> + rx->urbs_count = 0;
> + spin_unlock_irqrestore(&rx->lock, flags);
That looks ... really weird, first you free and then you assign the
pointer to NULL, but under the lock?
I guess the lock is completely pointless here.
> +void purelifi_usb_release(struct purelifi_usb *usb)
> +{
> + usb_set_intfdata(usb->intf, NULL);
> + usb_put_intf(usb->intf);
> + /* FIXME: usb_interrupt, usb_tx, usb_rx? */
what about them?
> + dma_buffer = kzalloc(usb_bulk_msg_len, GFP_KERNEL);
> +
> + if (!dma_buffer) {
> + r = -ENOMEM;
> + goto error;
> + }
> + memcpy(dma_buffer, &usb_req, usb_bulk_msg_len);
kmemdup()
> +static int pre_reset(struct usb_interface *intf)
> +{
> + struct ieee80211_hw *hw = usb_get_intfdata(intf);
> + struct purelifi_mac *mac;
> + struct purelifi_usb *usb;
> +
> + if (!hw || intf->condition != USB_INTERFACE_BOUND)
> + return 0;
> +
> + mac = purelifi_hw_mac(hw);
> + usb = &mac->chip.usb;
> +
> + usb->was_running = test_bit(PURELIFI_DEVICE_RUNNING, &mac->flags);
> +
> + purelifi_usb_stop(usb);
> +
> + mutex_lock(&mac->chip.mutex);
this looks kind of problematic locking-wise
> +static int post_reset(struct usb_interface *intf)
> +{
> + struct ieee80211_hw *hw = usb_get_intfdata(intf);
> + struct purelifi_mac *mac;
> + struct purelifi_usb *usb;
> +
> + if (!hw || intf->condition != USB_INTERFACE_BOUND)
> + return 0;
especially since this doesn't always unlock?
Not sure intf->condition can change inbetween, but it looks very
fragile.
> +#define TO_NETWORK(X) X) & 0xFF00) >> 24) | (((X) & 0xFF) >> 8)
> |\
> + (((X) & 0xFF00) << 8) | (((X) & 0xFF) << 24))
> +
> +#define TO_NETWORK_16(X) X) & 0xFF00) >> 8) | (((X) & 0x00FF) << 8))
> +
> +#define TO_NETWORK_32(X) TO_NETWORK(X)
> +
> +#define TO_HOST(X)TO_NETWORK(X)
> +#define TO_HOST_16(X) TO_NETWORK_16(X)
> +#define TO_HOST_32(X) TO_NETWORK_32(X)
Remove all of that.
> +static inline struct usb_device *purelifi_usb_to_usbdev(struct purelifi_usb
> + *usb)
indentation per above comment
johannes
or something.
But no, I was obviously wrong with what I said above.
So of course the condition is always true, like you said.
However, what was intended doesn't look like !, but rather == 0xff and
== 0x respectively, I'll send a patch.
johannes
On Fri, 2021-02-12 at 09:42 +0100, Johannes Berg wrote:
> On Tue, 2020-12-15 at 22:53 +0530, Youghandhar Chintala wrote:
> > The right fix would be to pull the entire data path into the host
> > +++ b/net/mac80211/ieee80211_i.h
> > @@ -748,6 +748,8 @@ struct ieee80211_if_m
E, but than
didn't check how that's actually used?
Please change it so that the two models are the same. You really don't
need the wiphy flag.
johannes
a BAR that updates the SN.
johannes
tart. This flag should be
> + * exposed by drivers which support target recovery.
You're not doing anything with this information in cfg80211, so
consequently it doesn't belong there.
johannes
.3000...@openwrt.org/
But maybe that isn't actually quite right due to integer promotion?
OTOH, that's a u8, so it should do the ~ in u8 space, and then compare
to 0 also?
johannes
suming that the AP is an authorized master).
> * In addition allow operation on a channel on which indoor operation is
> - * allowed, iff we are currently operating in an indoor environment.
> + * allowed, if we are currently operating in an indoor environment.
> */
I suspect that was intentional, as a common abbreviation for "if and
only if".
johannes
d let me know if there's any problem.
Thanks,
johannes
The following changes since commit d1f3bdd4eaae1222063c2f309625656108815915:
net: dsa: rtl8366rb: standardize init jam tables (2021-01-27 20:21:20 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/
hanks,
johannes
The following changes since commit eb4e8fac00d1e01ada5e57c05d24739156086677:
neighbour: Prevent a dead entry from updating gc_list (2021-01-30 11:09:07
-0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git
tags/mac
ah, forget about it. Usually this is a consequence of the way syzbot
creates tests - it might have created something like
if (!create_secret_memfd())
return;
try_something_on_wireless()
and then of course without your patch it cannot get to the wireless
bits.
Pretty sure I know what's going on here, I'll take a closer look later.
johannes
RTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+8dcc087eb24227ded...@syzkaller.appspotmail.com
Looks like this is a dup.
#syz dup: WARNING in sta_info_insert_rcu
Just in this case sta_info_insert_check() didn't get inlined into
sta_info_insert_rcu().
johannes
On Thu, 2021-01-28 at 19:56 +0800, samirweng1979 wrote:
> From: wengjianfeng
>
> If the length of hide ssid is zero in scan, don't pass
> it to driver, which doesn't make any sense.
Err, please check again how scanning works. This is quite obviously
intentional.
johannes
Hi Jakub,
Alright ... let's try again, with two more fixes on top, one
for the virt_wifi deadlock and one for a minstrel regression
in the earlier patches.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes si
On Tue, 2021-01-26 at 22:16 +0100, Johannes Berg wrote:
> Hi,
>
> So here's a pretty big and invasive mac80211-next pull. It has now been
> in linux-next for some time, and all the issues that had been reported by
> people running that are fixed. I've also thrown hwsim a
is case, as we still have the remaining
> > inconsistency.
>
> My problem with Krzysztof's patch[1] is that it adds a new Kconfig
> option for ath9k, is that really necessary? Like Arnd said, we should
> fix drivers to use CONFIG_MAC80211_LEDS instead of having driver
> specific options.
>
> So I would prefer take this Arnd's patch instead and queue it for v5.11.
> But as it modifies mac80211 I'll need an ack from Johannes, what do you
> think?
Sure, that seems fine.
Acked-by: Johannes Berg
johannes
cted-by: Ben Greear
> > Tested-by: Ben Greear
> > Cc: Luca Coelho
> > Cc: linux-wirel...@vger.kernel.org
> > Cc: Johannes Berg
>
> Johannes, Eric tagged this for net, are you okay with me taking it?
> No strong preference here.
I guess that really would norma
s, so if I
consider it, I sort of expect some more fallout from that. I did sprinkle
lockdep assertions fairly liberally, so we'll see.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 9e8789c85deee047c5753e22f725d5fc10682468:
dev)
int ret;
ASSERT_RTNL();
- lockdep_assert_held(&rdev->wiphy.mtx);
if (WARN_ON(!wdev))
return -EINVAL;
johannes
or) ?
>
> If you want me to submit it upstream, may I have / add your S-o-b
> for this ?
I'll send it out, with a note asking where it should go ... could also
take it through my tree since it fixes things from there.
johannes
Hi Jakub,
We have a few fixes - note one is for a staging driver, but acked by
Greg and fixing the driver for a change that came through my tree.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 1c45ba93d34cd6af75228f34d0675200c81
t through yours, as I don't think I'll have
> any more staging patches for 5.11-final (or none have been sent to me
> yet), so this might be the fastest way in:
>
> Acked-by: Greg Kroah-Hartman
OK, will do, thanks!
johannes
From: Johannes Berg
This code ends up calling wiphy_apply_custom_regulatory(), for which
we document that it should be called before wiphy_register(). This
driver doesn't do that, but calls it from ndo_open() with the RTNL
held, which caused deadlocks.
Since the driver just registers s
ng to get to the
wiphy from the adapter, but going through the wdev instead ... ouch.
Wow are these pointers a mess in that driver ... Something like this,
perhaps?
https://p.sipsolutions.net/4400d9a3b7b800bb.txt
johannes
Hi Eric,
On Tue, 2021-01-19 at 11:02 +0100, Eric Dumazet wrote:
>
> > This does fix the problems reported on iwlwifi, were you planning to
> > submit it as a proper patch?
>
> Sure, I will do, thanks !
Did you do that and I missed it? Or would you prefer we did?
Thanks,
Johannes
own
rather than *moving* it down. Ilan told me about it yesterday but I
didn't have time to check and fix it up. It's fixed in mac80211-next
now.
johannes
c regdomain, and the notifier does the work of
applying it to the channels as well.
> One thing which I forgot to mention earlier, it is not just lockdep
> complaining
> this appears to be a real deadlock, the wifi no longer functions, where
> as it does function with the patch drops.
Right.
johannes
eads-up. I guess I'll revert both patches for now,
unless we can quickly figure out a way to get all these paths in order.
Thanks,
johannes
On Wed, 2021-01-20 at 19:03 +0100, Johannes Berg wrote:
> Could you take a look at these bits to see if that's fine with you?
Actually, never mind. Given some bug reports, some rework was necessary,
and that means this is no longer needed :-)
johannes
ry about that. Evidently, I somehow managed to put
"wiphy_lock()" into that part of the code, rather than "wiphy_unlock()"!
I'll fix, thanks!
johannes
On Wed, 2021-01-20 at 12:37 -0800, Jakub Kicinski wrote:
> On Wed, 20 Jan 2021 18:59:21 +0100 Johannes Berg wrote:
> > Hi Jakub,
> >
> > > This pull request was applied to netdev/net.git (refs/heads/master):
> >
> > Since you pulled this now, question:
>
Hi Oliver,
Could you take a look at these bits to see if that's fine with you? I'd
like to merge it through mac80211-next (pending some logistics with a
conflict)
> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> index 1447da1d5729..47c4c1182ef1 100644
> --- a/drivers/net/usb/
nto mac80211-next? Or
do you prefer another approach here? I could also double-apply the
single patch, or pull myself but then we'd get a lot of net content into
net-next only via mac80211-next which seems odd.
Thanks,
johannes
From: Johannes Berg
Currently, _everything_ in cfg80211 holds the RTNL, and if you
have a slow USB device (or a few) you can get some bad lock
contention on that.
Fix that by re-adding a mutex to each wiphy/rdev as we had at
some point, so we have locking for the wireless_dev lists and
all the
KB_GSO_TCPV6;
> } else {
> if (qos) {
> u8 *qc;
This does fix the problems reported on iwlwifi, were you planning to
submit it as a proper patch?
Thanks,
johannes
Hi,
New try, dropped the 160 MHz CSA patch for now that has the sparse
issue since people are waiting for the kernel-doc fixes.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 220efcf9caf755bdf92892afd37484cb6859e0d2:
Merge tag
On Mon, 2021-01-18 at 10:12 +0100, Johannes Berg wrote:
> Hi Jakub,
>
> Here are some fixes for wireless - probably the thing people
> have most been waiting for is the kernel-doc fixes :-)
Now that the email finally went through, let me withdraw this, there's a
sparse er
Hi Jakub,
Here are some fixes for wireless - probably the thing people
have most been waiting for is the kernel-doc fixes :-)
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 220efcf9caf755bdf92892afd37484cb6859e0d2:
Merge tag
mpt at getting
traction for the common framework (before IPA got merged, after all.)
Also, non-technically speaking, I'm really not sure as to what we can
and should require from a single driver like this in terms of "cleaning
up the ecosystem". Yes, having a common framework would be nice, but if
nobody's going to use it, what's the point? And we didn't require such
from IPA. Now, granted, IPA already ships with a slightly better way of
doing things than ethernet+802.1q, but there's precedent for that as
well...
johannes
for message sending(). Prototype was for
> > > tipc_node_xmit() instead
> > >
> > > Signed-off-by: Mauro Carvalho Chehab
> >
> > Acked-by: Jon Maloy
>
> Thanks! Applied this one to net, the cfg80211 one does not apply to
> net, so I'll leave it
211/mac80211: fix kernel-doc for SAR APIs) on top of Linus'
> tree and still got this warning. That patch did not touch
> include/net/mac80211.h ...
Umm, I don't know what to say. I even added "cfg80211/mac80211" to the
subject, but somehow lost the change to mac80211.h. Sorry about that :(
I'll get a v3 out.
johannes
ecs' not described in 'ieee80211_ops'
>
> Introduced by commit
>
> c534e093d865 ("mac80211: add ieee80211_set_sar_specs")
>
> Sorry, I missed this earlier.
Right, thanks. I believe I also fixed it in the patch I sent a few days
ago that fixed the other documentation warning related to SAR that you
reported.
Thanks,
johannes
not sure what else happened yet.
Off the top of my head, I don't really see the issue. Does anyone have
the ability to capture the frames over the air (e.g. with another AX200
in monitor mode, load the driver with amsdu_size=3 module parameter to
properly capture A-MSDUs)?
johannes
Hi Dave,
Welcome back!
I'm a bit late with this, I guess, but I hope you can still
pull it into net-next for 5.11. Nothing really stands out,
we have some 6 GHz fixes, and various small things all over.
Please pull and let me know if there's any problem.
Thanks,
johannes
The
SCALL_64_after_hwframe+0x44/0xa9
>
> Fixes: 60854fd94573 ("mac80211: mesh: convert path table to rhashtable")
> Signed-off-by: Eric Dumazet
> Reported-by: syzbot
Reviewed-by: Johannes Berg
Jakub, if you want to take it to the net tree I wouldn't mind at all,
since I _just_ sent a pull request a little while ago.
Thanks,
johannes
On Fri, 2020-12-04 at 17:26 +0100, Johannes Berg wrote:
> On Fri, 2020-12-04 at 08:24 -0800, Eric Dumazet wrote:
> > From: Eric Dumazet
> >
> > If tbl_mpp can not be allocated, we call mesh_table_free(tbl_path)
> > while tbl_path rhashtable has not yet been initializ
774,6 @@ int mesh_pathtbl_init(struct ieee80211_sub_if_data *sdata)
> goto free_path;
> }
>
> - rhashtable_init(&tbl_path->rhead, &mesh_rht_params);
> - rhashtable_init(&tbl_mpp->rhead, &mesh_rht_params);
>
Hmm. There were two calls, now there's only one? Is that a bug, or am I
missing something?
johannes
Hi Jakub,
We've got a few more fixes for the current cycle, everything
else I have pending right now seems likely to go to 5.11 instead.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit bbe2ba04c5a92a49db8a42c850a5a2f6481e47eb
in
> ieee80211_del_key()) directly in cfg80211_validate_key_settings() itself - by
> updating max_key_index, and checking accordingly?
Yes, I think so. But similarly to cfg80211_validate_key_settings() it
should look at the device capabilities (beacon protection, etc.)
Thanks!
johannes
On Tue, 2020-12-01 at 17:26 +0530, Anant Thazhemadam wrote:
> On 01/12/20 3:30 pm, Johannes Berg wrote:
> > On Tue, 2020-12-01 at 15:26 +0530, Anant Thazhemadam wrote:
> > > Currently, it is assumed that key_idx values that are passed to
> > > ieee80211_del_key() are a
lly in cfg80211, like in
nl80211_new_key() we do it via cfg80211_validate_key_settings().
I suppose we cannot use the same function, but still, would be good to
address this generally in nl80211 for all drivers.
johannes
worth the
complexity.
> It is more complicated. We can go back to an skb field if this work is
> expected to yield results for mac80211. Would you mind sending a patch?
I can do that, but I'm not going to be able to do it now/tonight (GMT+1
here), so probably only Monday/Tuesday or so, sorry.
johannes
On Sat, 2020-11-21 at 10:35 -0800, Jakub Kicinski wrote:
> On Sat, 21 Nov 2020 19:12:21 +0100 Johannes Berg wrote:
> > > So I'm leaning towards reverting the whole thing. You can attach
> > > kretprobes and record the information you need in BPF maps.
> >
through the system.
IOW, it's not really about serving userland, it's about enabling (and
later disabling) coverage collection for the bits of code it cares
about, mostly because collecting it for _everything_ is going to be too
slow and will mess up the data since for coverage guided fuzzing you
really need the reported coverage data to be only about the injected
fuzz data...
johannes
f thats the case this u64 should be an sk_buff member, not an
> extension.
Because it was requested :-)
https://lore.kernel.org/netdev/20201009161558.57792...@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com/
johannes
uct ethtool_ops.
>
> Fix all the places which made use of this implicit include.
> include/net/cfg80211.h | 1 +
Sounds good to me, thanks. Will still cause all wireless drivers to
rebuild this way though. Maybe I'll see later if something can be done
ab
this is all the 'old compat' code, this patch looks fine. I
> think new stuff should probably encode types in some fashion (rather
> than via wrappers).
Everything mentioning wext has been deprecated for something like 15
years ... so yeah. But people still use it :(
johannes
when I get to your pr.
Yeah, I'll fast forward once you have pulled that, and generally I don't
apply anything while I have open pull requests (in case I have to
rejigger or whatnot), so all should be well. :)
Thanks!
johannes
t; Use core API instead of ieee80211_tx/rx_stats().
>
This looks like a 1/3 but I only ever saw this, not the others.
Seems I should take this through my tree, any objections?
johannes
Hi Jakub,
And here's another set of patches, this one for -next. Nothing
much stands out, perhaps apart from the WDS removal, but that
was old and pretty much dead code when we turned it off, so it
won't be missed.
Please pull and let me know if there's any problem.
Thanks,
Hi Jakub,
We have a few fixes, most importantly probably the fix for
the sleeping-in-atomic syzbot reported half a dozen (or so)
times.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 52755b66ddcef2e897778fac5656df18817b59ab:
On Wed, 2020-11-11 at 11:23 +0800, Claire Chang wrote:
> On Wed, Nov 11, 2020 at 1:35 AM Johannes Berg
> wrote:
> > On Tue, 2020-11-10 at 16:49 +0800, Claire Chang wrote:
> > > If a device is getting removed or reprobed during resume, use-after-free
> >
* said worker run, when it runs, calls rfkill_unregister()
* somehow rfkill_resume() still gets called after this
But that can't really be right, device_del() removes it from the PM
lists?
johannes
the ops, and a warning gets generated.
>
> Also it'd be good to mention why Johannes's approach was abandoned.
Well, I had two.
One was awful, and worked in all cases.
The other was less awful, and didn't work in all cases.
I think both gave Al Viro hives ;-)
> Patch 1 need
On Sun, 2020-11-08 at 20:34 +0100, Thomas Deutschmann wrote:
>
>
> Can we please get this applied to linux-5.10 and linux-5.9?
It's tagged for that, so once it enters mainline will get picked up.
Should be soon now, I assume.
johannes
rb].h_src, hdr->addr2);
> > +#endif
>
> Isn't there a better way to handle this? I really would not want
> checking for GCC versions become a common approach in drivers.
>
> I even think that using memcpy() always is better than the ugly ifdef.
If you put memcpy() always somebody will surely go and clean it up to
use ether_addr_copy() soon ...
That said, if there's a gcc issue with ether_addr_copy() then how come
it's specific to this place?
johannes
On Fri, 2020-10-30 at 13:52 -0700, Jakub Kicinski wrote:
> On Fri, 30 Oct 2020 10:43:48 +0100 Johannes Berg wrote:
> > Hi Jakub,
> >
> > Here's a first set of fixes, in particular the nl80211 eapol one
> > has people waiting for it.
> >
> > Please
Hi Jakub,
Here's a first set of fixes, in particular the nl80211 eapol one
has people waiting for it.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 07e0887302450a62f51dba72df6afb5fabb23d1c:
Merge tag 'fallthrough-f
se to be really much higher than that, so in practice
this won't happen.
johannes
idea how we'll get this merged - Jakub, do you want to take
the whole series? Or is somebody else responsible for the core kcov
part?
In any case,
Reviewed-by: Johannes Berg
johannes
AINTAINERS entry that refers to a broken mailing
> list and website.
>
> Suggested-by: Inaky Perez-Gonzalez
> Signed-off-by: Arnd Bergmann
> ---
> changes in v2:
> - fix a build regression
> - add more information about remaining networks (Dan Carpenter)_
>
> For v1,
ly now perhaps even
better ieee80211_rx_list(), so we get it even if the driver called that
API in the first place?
You might only care about hwsim at this point, but perhaps hwsim would
get optimised ..
johannes
the specific case of __sta_info_flush(), add a documentation
> for sta_info_flush(), as this one is the one used outside
> sta_info.c.
Are you taking the entire series through some tree, or should I pick up
this patch?
If you're going to take it:
Reviewed-by: Johannes Berg
johannes
1 - 100 of 2143 matches
Mail list logo
