On Wed, 2021-02-03 at 15:00 +0800, samirweng1979 wrote:
> From: wengjianfeng
>
> change 'iff' to 'if'.
>
> Signed-off-by: wengjianfeng
> ---
> net/wireless/chan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/wireless/chan.c b/net/wireless/chan.c
> index 285b807
On Mon, 2021-02-01 at 14:37 +0200, Mike Rapoport wrote:
> On Mon, Feb 01, 2021 at 01:17:13AM -0800, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:b01f250d Add linux-next specific files for 20210129
> > git tree: linux-next
> > console output:
On Sun, 2021-01-31 at 21:26 -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:bec4c296 Merge tag 'ecryptfs-5.11-rc6-setxattr-fix' of git..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=11991778d0
> kernel config
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
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
sendfile() to a pipe.
Fix this by using iter_file_splice_write for the splice_write
method of pipes, as suggested by Christoph.
Cc: sta...@vger.kernel.org
Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops")
Suggested-by: Christoph Hellwig
Tested-by
On Mon, 2021-01-25 at 01:52 -0800, syzbot wrote:
>
> [ cut here ]
> WARNING: CPU: 0 PID: 1 at net/wireless/core.c:1336
> cfg80211_register_netdevice+0x235/0x330 net/wireless/core.c:1336
>
Yes, umm. I accidentally *copied* that line a few lines further down
rather than *
On Thu, 2021-01-21 at 07:05 +0100, Willy Tarreau wrote:
> I think that most users of splice() on sockets got used to falling back
> to recv/send on splice failure due to various cases not being supported
> historically (UNIX family sockets immediately come to my mind but I seem
> to remember other
On Wed, 2021-01-20 at 18:04 +0100, Peter Oberparleiter wrote:
>
> > Tested with a kernel configured with CONFIG_GCOV_KERNEL, without
> > the patch nothing ever appears in /sys/kernel/debug/gcov/ (apart
> > from the reset file), and with it we get the files and they work.
>
> Just to be sure: coul
From: Johannes Berg
On ARCH=um, loading a module doesn't result in its constructors
getting called, which breaks module gcov since the debugfs files
are never registered. On the other hand, in-kernel constructors
have already been called by the dynamic linker, so we can't call
them a
On Wed, 2021-01-20 at 17:07 +0100, Peter Oberparleiter wrote:
> Do you expect other users for these new config symbols?
Probably not.
> If not it seems
> to me that the goal of enabling module constructors for UML could also
> be achieved without introducing new config symbols.
Yeah, true.
>
From: Johannes Berg
On ARCH=um, loading a module doesn't result in its constructors
getting called, which breaks module gcov since the debugfs files
are never registered. On the other hand, in-kernel constructors
have already been called by the dynamic linker, so we can't call
them a
On Mon, 2021-01-18 at 09:53 +0100, Christoph Hellwig wrote:
> On Sat, Jan 16, 2021 at 05:46:33PM +0100, Johannes Berg wrote:
> > > For my case, I attempted to instead implement splice_write and
> > > splice_read in tty_fops; I managed to get splice_write working calling
>
On Sat, 2021-01-16 at 20:35 +1300, Oliver Giles wrote:
> Commit 36e2c7421f02 (fs: don't allow splice read/write without
> explicit ops) broke my userspace application which talks to an SSL VPN
> by splice()ing between "openssl s_client" and "pppd". The latter
> operates over a pty, and since that c
On Thu, 2021-01-14 at 10:34 -0800, Jakub Kicinski wrote:
> On Thu, 14 Jan 2021 10:59:08 -0500 Jon Maloy wrote:
> > On 1/14/21 3:04 AM, Mauro Carvalho Chehab wrote:
> > > A function has a different name between their prototype
> > > and its kernel-doc markup:
> > >
> > > ../net/tipc/link.c:2551:
From: Johannes Berg
If kmemleak is enabled, it uses a kmem cache for its own objects.
These objects are used to hold information kmemleak uses, including
a stack trace. If slub_debug is also turned on, each of them has
*another* stack trace, so the overhead adds up, and on my tests (on
ARCH=um
On Wed, 2021-01-13 at 17:59 +0100, Vlastimil Babka wrote:
> On 1/13/21 5:09 PM, Johannes Berg wrote:
> > From: Johannes Berg
> >
> > If kmemleak is enabled, it uses a kmem cache for its own objects.
> > These objects are used to hold information kmemleak uses, incl
From: Johannes Berg
If kmemleak is enabled, it uses a kmem cache for its own objects.
These objects are used to hold information kmemleak uses, including
a stack trace. If slub_debug is also turned on, each of them has
*another* stack trace, so the overhead adds up, and on my tests (on
ARCH=um
Hi Stephen,
> > 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.
>
> I don't think so :-( I did a htmldocs build with your patch ([PATCH
> v2] cfg80211/mac80211: fix kernel-doc for SAR
Hi Stephen,
On Thu, 2021-01-07 at 09:05 +1100, Stephen Rothwell wrote:
> Hi all,
>
> Building Linus' tree, today's linux-next build (htmldocs) produced
> this warning:
>
> include/net/mac80211.h:4200: warning: Function parameter or member
> 'set_sar_specs' not described in 'ieee80211_ops'
>
>
On Wed, 2020-12-30 at 08:03 -0500, Sasha Levin wrote:
>
> We've been running into stack overflows in helper threads
> corrupting memory
For the record, that was mostly referring to "while development", so
while this change makes a few things a bit safer, I don't think there's
all that much point
From: Johannes Berg
If we store the relative path, the user might later cd to a
different directory, and that would break the automatic symbol
resolving that happens when a module is loaded into the target
kernel. Fix this by storing the abspath() of each path given,
just like we already do for
Hi Jan,
> > -sys.path.insert(0, os.path.dirname(__file__) + "/scripts/gdb")
> > +sys.path.insert(0, os.path.dirname(__file__))
> >
> > try:
> > gdb.parse_and_eval("0")
> >
>
> How did you test that, which setup? I just ran "gdb
> /build/vmlinux", and "python print(sys.path)" didn't expos
From: Johannes Berg
If we store the relative path, the user might later cd to a
different directory, and that would break the automatic symbol
resolving that happens when a module is loaded into the target
kernel. Fix this by storing the abspath() of each path given,
just like we already do for
From: Johannes Berg
Perhaps something got moved around at some point, but the
current path that gets inserted has "/scripts/gdb" twice,
since the script is located in scripts/gdb/ already. Fix
the path.
Signed-off-by: Johannes Berg
---
scripts/gdb/vmlinux-gdb.py | 2 +-
1 file
On Tue, 2020-12-01 at 18:15 +0530, Anant Thazhemadam wrote:
>
> cfg80211_supported_cipher_suite(&rdev->wiphy, params->cipher) returned
> false, and thus it worked for the syzbot reproducer.
> Would it be a safer idea to enforce the conditions that I initially put (in
> ieee80211_del_key()) directl
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
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 all valid indexes as is, and no sanity checks
> are performed for it.
> However, syzbot was able to trigger an array-index-out-of-bounds bug
> by p
On Sat, 2020-11-21 at 12:55 -0800, Jakub Kicinski wrote:
> [snip]
> Ack, you have to figure out all the places anyway, the question is
> whether you put probes there or calls in the source code.
>
> Shifting the maintenance burden but also BPF is flexibility.
Yeah, true. Though I'd argue also vis
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.
> >
On Sat, 2020-11-21 at 10:06 -0800, Jakub Kicinski wrote:
> On Sat, 21 Nov 2020 17:52:27 +0100 Florian Westphal wrote:
> > Ido Schimmel wrote:
> > > Other suggestions?
> >
> > Aleksandr, why was this made into an skb extension in the first place?
> >
> > AFAIU this feature is usually always dis
On Sat, 2020-11-21 at 17:52 +0100, Florian Westphal wrote:
>
> Aleksandr, why was this made into an skb extension in the first place?
>
> AFAIU this feature is usually always disabled at build time.
> For debug builds (test farm /debug kernel etc) its always needed.
>
> If thats the case this u6
On Fri, 2020-11-20 at 11:26 -0800, Kees Cook wrote:
> On Tue, Nov 17, 2020 at 02:07:43PM -0800, Sami Tolvanen wrote:
> > On Tue, Nov 17, 2020 at 1:45 PM Kees Cook wrote:
> > > On Tue, Nov 17, 2020 at 12:59:02PM -0800, Sami Tolvanen wrote:
> > > > Instead of casting callback functions to type iw_ha
On Fri, 2020-11-13 at 11:51 -0800, Jakub Kicinski wrote:
> On Fri, 13 Nov 2020 14:25:25 +0200 Lev Stipakov wrote:
> > > Seems I should take this through my tree, any objections?
>
> Go for it, you may need to pull net-next first but that should happen
> soonish anyway, when I get to your pr.
Yeah
On Fri, 2020-11-13 at 10:58 +0200, Lev Stipakov wrote:
> Commits
>
> d3fd65484c781 ("net: core: add dev_sw_netstats_tx_add")
> 451b05f413d3f ("net: netdevice.h: sw_netstats_rx_add helper)
>
> have added API to update net device per-cpu TX/RX stats.
>
> Use core API instead of ieee80211_tx/rx
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
> >
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
> might happen. For example, h5_btrtl_resume()[drivers/bluetooth/hci_h5.c]
> schedules a work queue for device reprobing. During the reprobing, if
> rfkill_set_block() i
On Mon, 2020-11-09 at 16:43 +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mac80211-next tree, today's linux-next build (htmldocs)
> produced this warning:
>
> Documentation/driver-api/80211/cfg80211:48: include/net/cfg80211.h:1014:
> WARNING: Unexpected indentation.
> Documentat
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
On Mon, 2020-11-02 at 18:26 +0200, Kalle Valo wrote:
> Arnd Bergmann writes:
>
> > From: Arnd Bergmann
> >
> > gcc-10 shows a false-positive warning with CONFIG_KASAN:
> >
> > drivers/net/wireless/ath/ath9k/dynack.c: In function
> > 'ath_dynack_sample_tx_ts':
> > include/linux/etherdevice.h:2
On Thu, 2020-10-29 at 22:24 +, Colin King wrote:
> From: Colin Ian King
>
> The for-loop iterates with a u8 loop counter and compares this
> with the loop upper limit of request->n_ssids which is an int type.
> There is a potential infinite loop if n_ssids is larger than the
> u8 loop counter
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
Greg said he'd appply the patch when he gets an Ack
> from the maintainers.
>
> Inaky, Johannes, Jakub: are you happy with this version?
Sure, looks fine to me.
Acked-by: Johannes Berg
Not that I have much relation to this code other than having fixed up
genetlink stuff over the years :)
johannes
On Wed, 2020-10-28 at 18:20 +, Aleksandr Nogikh wrote:
> From: Aleksandr Nogikh
>
> Add KCOV remote annotations to ieee80211_iface_work and
> ieee80211_rx. This will enable coverage-guided fuzzing of
> mac80211 code that processes incoming 802.11 frames.
>
> Signed-off-by: Aleksandr Nogikh
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
ht thing in the separate policies.
OTOH, that really just makes it use more space, for no discernible
effect to userspace.
So as far as the warning fix is concerned:
Acked-by: Johannes Berg
Looks like I introduced a bug there with WIMAX_GNL_MSG_PIPE_NAME, but
obviously nobody cared.
johannes
From: Johannes Berg
Joe's commit didn't only convert uses of __section(...) to add
the quotes, but _also_ converted 'raw' uses of __attribute__(())
for setting the section to use __section, but didn't update the
includes where necessary. Add them now.
Fixes: 33def84
On Tue, 2020-10-13 at 22:41 +0200, Mauro Carvalho Chehab wrote:
> Em Tue, 13 Oct 2020 20:47:47 +0200
> Johannes Berg escreveu:
>
> > Thanks Mauro.
> >
> >
> > On Tue, 2020-10-13 at 13:54 +0200, Mauro Carvalho Chehab wrote:
> > > Changeset df
Thanks Mauro.
On Tue, 2020-10-13 at 13:54 +0200, Mauro Carvalho Chehab wrote:
> Changeset df78a0c0b67d ("nl80211: S1G band and channel definitions")
> added a new parameter, but didn't add the corresponding kernel-doc
> markup, as repoted when doing "make htmldocs":
>
> ./include/net/cfg80
On Mon, 2020-10-12 at 14:18 +0300, Aleksandr Nogikh wrote:
>
> Currently we're injecting frames via mac80211_hwsim (by pretenting to
> be wmediumd -
> https://github.com/google/syzkaller/blob/4a77ae0bdc5cd75ebe88ce7c896aae6bbf457a29/executor/common_linux.h#L4922).
Ah, ok, of course that works too
On Wed, 2020-10-07 at 10:17 +, Aleksandr Nogikh wrote:
>
> @@ -904,6 +905,10 @@ struct sk_buff {
> __u16 network_header;
> __u16 mac_header;
>
> +#ifdef CONFIG_KCOV
> + u64 kcov_handle;
> +#endif
[...]
> @@ -233,6 +233
On Fri, 2020-10-09 at 17:01 +, Aleksandr Nogikh wrote:
> From: Aleksandr Nogikh
>
> This patch series enables remote KCOV coverage collection during
> 802.11 frames processing. These changes make it possible to perform
> coverage-guided fuzzing in search of remotely triggerable bugs.
Btw, it
On 11 October 2020 12:37:29 CEST, Andrey Konovalov
wrote:
>I initially hesitated to do that, as it would multiply the number of
>kcov callbacks. But perhaps you're right and a clean API look
>outweighs the rest. I will do this in v3.
Yeah, OK, dunno. You can always make it an inline calling
On Sat, 2020-10-10 at 11:38 +0200, Greg KH wrote:
> On Fri, Oct 09, 2020 at 10:48:09AM +0200, Johannes Berg wrote:
> > On Fri, 2020-10-09 at 10:47 +0200, Greg KH wrote:
> >
> > > > I think adding the .owner everywhere would be good, and perhaps we can
> > >
On 9 October 2020 19:01:59 CEST, Aleksandr Nogikh wrote:
>This patch series conflicts with another proposed patch
>http://lkml.kernel.org/r/223901affc7bd759b2d6995c2dbfbdd0a29bc88a.1602248029.git.andreyk...@google.com
>One of these patches needs to be rebased once the other one is merged.
Ma
On Fri, 2020-10-09 at 10:56 +, David Laight wrote:
> From: Johannes Berg
> > Sent: 09 October 2020 11:48
> >
> > On Fri, 2020-10-09 at 12:41 +0200, Johannes Berg wrote:
> >
> > > If the fops doesn't have a release method, we don't even need
>
On Fri, 2020-10-09 at 12:41 +0200, Johannes Berg wrote:
> If the fops doesn't have a release method, we don't even need
> to keep a reference to the real_fops, we can just fops_put()
> them already in debugfs remove, and a later full_proxy_release()
> won't call
From: Johannes Berg
Currently, things will crash (or at least UAF) in release() when
a module owning a debugfs file, but that didn't set the fops.owner,
is removed while the offending debugfs file is open.
Since we have the proxy_fops, we can break that down into two
different cases:
I
On Fri, 2020-10-09 at 10:47 +0200, Greg KH wrote:
> > I think adding the .owner everywhere would be good, and perhaps we can
> > somehow put a check somewhere like
> >
> > WARN_ON(is_module_address((unsigned long)fops) && !fops->owner);
> >
> > to prevent the issue in the future?
>
> That w
On Fri, 2020-10-09 at 08:34 +, David Laight wrote:
>
> > I think adding the .owner everywhere would be good, and perhaps we can
> > somehow put a check somewhere like
> >
> > WARN_ON(is_module_address((unsigned long)fops) && !fops->owner);
> >
> > to prevent the issue in the future?
>
>
On Fri, 2020-10-09 at 10:16 +0200, Greg KH wrote:
> On Fri, Oct 09, 2020 at 10:06:14AM +0200, Johannes Berg wrote:
> > We used to say the proxy_fops weren't needed and it wasn't an issue, and
> > then still implemented it. Dunno. I'm not really too concerned about it
On Fri, 2020-10-09 at 10:03 +0200, Greg KH wrote:
> For lots of debugfs files, .owner should already be set, if you use the
> DEFINE_SIMPLE_ATTRIBUTE() or DEFINE_DEBUGFS_ATTRIBUTE() macros.
>
> But yes, not all.
Right.
You didn't see the original thread:
https://lore.kernel.org/netdev/20201008
[RFF = Request For Flaming]
THIS IS PROBABLY COMPLETELY CRAZY.
Currently, if a module is unloaded while debugfs files are being
kept open, things crash since the ->release() method is called
only at the actual release, despite the proxy_fops, and then the
code is no longer around.
The correct wa
On Mon, 2020-10-05 at 11:38 +0200, Mauro Carvalho Chehab wrote:
> the files under /80211 calls kernel-doc script 207 times, one for each
> single function and doc chapter. Due to that, it takes a lot of time
> handling it:
>
> $ touch Documentation/driver-api/80211/*rst && time make
> SPHIN
On Wed, 2020-10-07 at 13:43 -0700, Kees Cook wrote:
> > > > I actually wonder if this should use refcount_t just because it is
> > > > designed to be an alway-unique value. It is hard to imagine ever causing
> > > > this to overflow, but why not let it be protected?
> > > >
> > >
> > > This is on
On Wed, 2020-10-07 at 13:33 -0600, Shuah Khan wrote:
> On 10/7/20 12:15 PM, Kees Cook wrote:
> > On Tue, Oct 06, 2020 at 02:44:35PM -0600, Shuah Khan wrote:
> > > counter_atomic* is introduced to be used when a variable is used as
> > > a simple counter and doesn't guard object lifetimes. This clea
On Wed, 2020-10-07 at 10:17 +, Aleksandr Nogikh wrote:
> From: Aleksandr Nogikh
>
> This patch series enables remote KCOV coverage collection for the
> mac80211 code that processes incoming 802.11 frames. These changes
> make it possible to perform coverage-guided fuzzing in search of
> remot
Hi Jann,
> > > +++ b/arch/um/include/asm/mmu_context.h
> > > @@ -48,9 +48,8 @@ static inline void activate_mm(struct mm_struct *old,
> > > struct mm_struct *new)
> > >* when the new ->mm is used for the first time.
> > >*/
> > > __switch_mm(&new->context.id);
> > > - mma
On Wed, 2020-10-07 at 00:54 +0200, Jann Horn wrote:
> Until now, the mmap lock of the nascent mm was ordered inside the mmap lock
> of the old mm (in dup_mmap() and in UML's activate_mm()).
> A following patch will change the exec path to very broadly lock the
> nascent mm, but fine-grained locking
On Thu, 2020-10-01 at 21:31 -0700, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit 16d4d43595b4780daac8fcea6d042689124cb094
> Author: Christoph Hellwig
> Date: Wed Jul 20 01:38:55 2016 +
>
> xfs: split direct I/O and DAX path
>
LOL!
Unlike in many other cases, here I d
On Wed, 2020-09-30 at 12:55 +0300, Leon Romanovsky wrote:
> On Wed, Sep 30, 2020 at 11:01:27AM +0300, Kalle Valo wrote:
> > Leon Romanovsky writes:
> >
> > > > diff --git a/drivers/net/wireless/purelifi/Kconfig
> > > b/drivers/net/wireless/purelifi/Kconfig
> > > > new file mode 100644
> > > > ind
On Wed, 2020-08-19 at 14:10 -0700, Brendan Higgins wrote:
> On Wed, Jul 29, 2020 at 10:58 AM Vitor Massaru Iha wrote:
> > This adds the conversion of the runtime tests of test_bitfield,
> > from `lib/test_bitfield.c` to KUnit tests.
> >
> > Please apply this commit first (linux-kselftest/kunit-fi
From: Johannes Berg
In the policy export for binary attributes I erroneously used
a != NLA_VALIDATE_NONE comparison instead of checking for the
two possible values, which meant that if a validation function
pointer ended up aliasing the min/max as negatives, we'd hit
a warni
box :)
> In such a case, netlink_recvmsg will use this 2nd skb instead of the
> original one.
>
> Without this patch, such compat applications will retrieve
> all netlink dump data, but will then get an unexpected EOF.
>
> Cc: Johannes Berg
> Signed-off-by: Florian Westpha
On Thu, 2020-08-20 at 11:47 +0200, Jason A. Donenfeld wrote:
> On Wed, Aug 19, 2020 at 8:42 PM syzbot
> wrote:
> > syzbot has bisected this issue to:
> >
> > commit e7096c131e5161fa3b8e52a650d7719d2857adfd
> > Author: Jason A. Donenfeld
> > Date: Sun Dec 8 23:27:34 2019 +
> >
> > net:
On Tue, 2020-08-04 at 14:05 -0700, Rustam Kovhaev wrote:
> this warning can be triggered by userspace, so it should not cause a
> panic if panic_on_warn is set
This is incorrect, it just addresses a particular symptom. I'll make a
proper fix.
johannes
ct ieee80211_local *local = from_tasklet(local, t, tasklet);
Yay, thank you!
Reviewed-by: Johannes Berg
Dave, if you want to take this patch, I have no objections - I have
nothing in my mac80211-next tree (yet).
johannes
On Thu, 2020-08-13 at 10:35 -0400, Laura Abbott wrote:
> The voting itself will be taking place during the week of Linux
> Plumbers/Kernel summit, August 24-28. Keep an eye out for the
> ballot during that time period. We'll send out another e-mail
> when the ballots go out.
OK, thanks for the in
Hi Laura,
Seeing your reminder reminded me :)
> We will be using the electronic voting method that we used in 2019. All
> Linux Plumbers Attendees will automatically receive a ballot. Anyone
> who is otherwise eligible to vote should e-mail
> tab-electi...@lists.linuxfoundation.org to request a
On Fri, 2020-07-31 at 08:21 +1000, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> 5fa4ab3cf34e ("mac80211: avoid bss color setting in non-HE modes")
>
> Fixes tag
>
> Fixes: eb024f1abca3("mac80211: avoid bss color setting in non-he mode")
>
> has these problem(s):
>
> - Target SHA1
Hi,
Sorry ... long delay.
> > The reason I'm asking is that it's starting to sound like we really
> > ought to be implementing devlink, but we've got a bunch of
> > infrastructure that uses the devcoredump, and it'll take time
> > (significantly so) to change all that...
>
> In devlink world pur
On Sun, 2020-07-26 at 21:49 +0530, Rakesh Pillai wrote:
> We do have the usage of napi_gro_receive and netif_receive_skb in mac80211.
> /* deliver to local stack */
> if (rx->napi)
> napi_gro_receive(rx->napi, skb);
> else
>
On Thu, 2020-07-23 at 23:56 +0530, Rakesh Pillai wrote:
> > > - WARN_ON_ONCE(softirq_count() == 0);
> > > + WARN_ON_ONCE(napi && softirq_count() == 0);
> >
> > FWIW, I'm pretty sure this is incorrect - we make assumptions on
> > softirqs being disabled in mac80211 for serialization and in place o
On Wed, 2020-07-15 at 16:57 -0500, Gustavo A. R. Silva wrote:
> One-element arrays are being deprecated[1]. Replace the one-element
> array with a simple value type 'u8 reserved'[2], once this is just
> a placeholder for alignment.
>
> [1] https://github.com/KSPP/linux/issues/79
> [2] https://gith
On Tue, 2020-07-21 at 22:44 +0530, Rakesh Pillai wrote:
> The function ieee80211_rx_napi can be now called
> from a thread context as well, with napi context
> being NULL.
>
> Hence add the napi context check before giving out
> a warning for softirq count being 0.
>
> Tested-on: WCN3990 hw1.0 SN
On Wed, 2020-07-22 at 14:27 +0200, Felix Fietkau wrote:
> I'm considering testing a different approach (with mt76 initially):
> - Add a mac80211 rx function that puts processed skbs into a list
> instead of handing them to the network stack directly.
Would this be *after* all the mac80211 process
On Mon, 2020-07-20 at 16:01 +0200, Geert Uytterhoeven wrote:
> On Mon, Jul 20, 2020 at 3:12 PM Geert Uytterhoeven
> wrote:
> > JFYI, when comparing v5.8-rc6[1] to v5.8-rc5[3], the summaries are:
> > - build errors: +6/-3
>
> + error: modpost: "devm_ioremap"
> [drivers/net/ethernet/xilinx/ll_
On Wed, 2020-07-15 at 21:11 +0100, Ignat Korchagin wrote:
> It is possible to produce a statically linked UML binary with UML_NET_VECTOR,
> UML_NET_VDE and UML_NET_PCAP options enabled using alternative libc
> implementations, which do not rely on NSS, such as musl.
>
> Allow static linking in thi
On Wed, 2020-07-15 at 08:48 -0700, Jakub Kicinski wrote:
> On Tue, 14 Jul 2020 19:59:02 -0700 Randy Dunlap wrote:
> > Drop doubled words in several comments.
> >
> > Signed-off-by: Randy Dunlap
> > Cc: "David S. Miller"
> > Cc: Jakub Kicinski
> > Cc: net...@vger.kernel.org
>
> Hi Randy, the Wi
On Tue, 2020-07-14 at 11:43 +0100, Anton Ivanov wrote:
> Patch is OK with me, should not read patches before the 3rd double espresso
> next time.
>
> I will +1 it, Richard, Johannes, what do you think?
I got dropped off the list in "The Great Infradead Purge" but I see it
in patchwork ;)
Not s
On Mon, 2020-06-08 at 09:14 +0200, Sedat Dilek wrote:
> On Sat, Jun 6, 2020 at 9:56 AM Johannes Berg
> wrote:
> > Hi, sorry for the top post, on my phone.
> >
> > Yes, your analysis is spot on I think. I've got a fix for this in my
> > jberg/mac80211 tree, th
Hi, sorry for the top post, on my phone.
Yes, your analysis is spot on I think. I've got a fix for this in my
jberg/mac80211 tree, there's a deadlock with a work struct and the rtnl.
Sorry about that. My testing should've caught it, but that exact scenario
didn't happen, and lockdep for disabl
On Tue, 2020-05-26 at 08:36 -0300, Ramon Fontes wrote:
> > Not sure this is enough? How about wmediumd, for example?
>
> It works with wmediumd too. At least I was able to enable 5 / 10MHz
> via iw with 5.9GHz
Yeah, but wmediumd won't know that it's not 20 MHz, I guess :-)
> > And also, 5/10 MHz
On Fri, 2020-05-15 at 13:46 -0300, Ramon Fontes wrote:
> Signed-off-by: Ramon Fontes
> ---
> drivers/net/wireless/mac80211_hwsim.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/mac80211_hwsim.c
> b/drivers/net/wireless/mac80211_hwsim.c
> index 0528d4cb4..67f97ac3
On Fri, 2020-05-22 at 10:17 -0700, Jakub Kicinski wrote:
> > > --- a/net/core/Makefile
> > > +++ b/net/core/Makefile
> > > @@ -31,7 +31,7 @@ obj-$(CONFIG_LWTUNNEL_BPF) += lwt_bpf.o
> > > obj-$(CONFIG_BPF_STREAM_PARSER) += sock_map.o
> > > obj-$(CONFIG_DST_CACHE) += dst_cache.o
> > > obj-$(CONFI
On Mon, 2020-05-18 at 13:35 -0700, Jakub Kicinski wrote:
>
> It's intended to be a generic netlink channel for configuring devices.
>
> All the firmware-related interfaces have no dependencies on netdevs,
> in fact that's one of the reasons we moved to devlink - we don't want
> to hold rtnl lock
On Mon, 2020-05-18 at 13:28 -0700, Jakub Kicinski wrote:
> On Mon, 18 May 2020 21:25:09 +0200 Johannes Berg wrote:
> > It's pretty clear, but even then, first of all I doubt this is the case
> > for many of the places that you've sprinkled the annotation on, and
>
On Mon, 2020-05-18 at 19:59 +, Luis Chamberlain wrote:
> > Err, no. Those two are most definitely related. Have you looked at (most
> > or some or whatever) staging drivers recently? Those contain all kinds
> > of garbage that might do whatever with your kernel.
>
> No, I stay away :)
:)
>
On Mon, 2020-05-18 at 19:09 +, Luis Chamberlain wrote:
> > Unfortunately a "taint" is interpreted by many users as: "your kernel
> > is really F#*D up, you better do something about it right now."
> > Assuming they're paying attention at all in the first place of course.
>
> Taint historicall
On Sat, 2020-05-16 at 15:24 +0200, Johannes Berg wrote:
> Instead of the kernel taint, IMHO you should provide an annotation in
> sysfs (or somewhere else) for the *struct device* that had its firmware
> crash. Or maybe, if it's too complex to walk the entire hierarchy
> checking
101 - 200 of 1060 matches
Mail list logo
