Re: [PATCH v2 1/3] compiler-gcc: hide COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW from sparse

2018-11-17 Thread Johannes Berg
On Sat, 2018-11-17 at 01:42 +0100, Luc Van Oostenryck wrote: > On Fri, Nov 09, 2018 at 10:35:32AM +0100, Johannes Berg wrote: > > From: Johannes Berg > > > > Sparse doesn't support all the overflow builtins, so just hide > > them from it to avoid lots

[PATCH v2 1/3] compiler-gcc: hide COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW from sparse

2018-11-09 Thread Johannes Berg
From: Johannes Berg Sparse doesn't support all the overflow builtins, so just hide them from it to avoid lots of warnings/errors reported by it. We could try to teach them to sparse, but the passed types are variable, and sparse doesn't seem to handle that well. Signed-off-by: Johannes Berg

[PATCH v2 3/3] slab: use logical instead of bitwise operation in kmalloc_type()

2018-11-09 Thread Johannes Berg
From: Johannes Berg The operation here really is more logical than bitwise, even if due to the setup the bitwise operation works fine. However, this causes a complaint from sparse that the operation doesn't really make sense due to the not. Use a logical and instead of bitwise. In my (somewhat

[PATCH 2/3] kernel.h: hide __is_constexpr() from sparse

2018-11-09 Thread Johannes Berg
From: Johannes Berg __is_constexpr() is a work of art, understandable only to the most respected wizards of C. Even sparse doesn't seem to belong to that group and warns that there's an "expression using sizeof(void)". Just hide the definition from sparse and pretend it's always tru

[PATCH v2 2/3] kernel.h: hide __is_constexpr() from sparse

2018-11-09 Thread Johannes Berg
From: Johannes Berg __is_constexpr() is a work of art, understandable only to the most respected wizards of C. Even sparse doesn't seem to belong to that group and warns that there's an "expression using sizeof(void)". Just hide the definition from sparse and pretend it's always tru

[PATCH 3/3] slab: use logical instead of bitwise operation in kmalloc_type()

2018-11-09 Thread Johannes Berg
From: Johannes Berg The operation here really is more logical than bitwise, even if due to the setup the bitwise operation works fine. However, this causes a complaint from sparse that the operation doesn't really make sense due to the not. Use a logical and instead of bitwise. In my (somewhat

[PATCH 1/3] compiler-gcc: hide COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW from sparse

2018-11-09 Thread Johannes Berg
From: Johannes Berg Sparse doesn't support all the overflow builtins, so just hide them from it to avoid lots of warnings/errors reported by it. We could try to teach them to sparse, but the passed types are variable, and sparse doesn't seem to handle that well. Signed-off-by: Johannes Berg

Re: [PATCH 3/3] kernel/workqueue: Suppress a false positive lockdep complaint

2018-10-25 Thread Johannes Berg
On Thu, 2018-10-25 at 13:39 -0700, Bart Van Assche wrote: > > > +void flush_workqueue_nested(struct workqueue_struct *wq, int subclass) > > { > > struct wq_flusher this_flusher = { > > .list = LIST_HEAD_INIT(this_flusher.list), > > @@ -2652,7 +2653,7 @@ void

Re: [PATCH 3/3] kernel/workqueue: Suppress a false positive lockdep complaint

2018-10-25 Thread Johannes Berg
On Thu, 2018-10-25 at 16:21 -0400, Theodore Y. Ts'o wrote: > We can guarantee it from someone who is looking at the code path. In > dio_set_defer_completion: [snip] Right, it's indeed pretty obvious. I shouldn't have tried to reply before the kids went to bed, that made me cut some corners ;-)

Re: [PATCH 3/3] kernel/workqueue: Suppress a false positive lockdep complaint

2018-10-25 Thread Johannes Berg
On Thu, 2018-10-25 at 15:36 +, Tejun Heo wrote: > We > wanna annotate the users for the exceptions rather than weakening the > workqueue lockdep checks, especially because workqueue related > deadlocks can be pretty difficult to trigger and root cause > afterwards. I think you just said more

Re: [PATCH 3/3] kernel/workqueue: Suppress a false positive lockdep complaint

2018-10-25 Thread Johannes Berg
On Thu, 2018-10-25 at 08:55 -0700, Bart Van Assche wrote: > Please have a look at the call trace in the description of this patch and also > at the direct I/O code. The lockdep complaint in the description of this patch > really is a false positive. I agree. I just don't agree that it's a false

Re: [PATCH 3/3] kernel/workqueue: Suppress a false positive lockdep complaint

2018-10-25 Thread Johannes Berg
On Thu, 2018-10-25 at 10:11 -0700, Bart Van Assche wrote: > On Thu, 2018-10-25 at 19:02 +0200, Johannes Berg wrote: > > On Thu, 2018-10-25 at 15:05 +, Bart Van Assche wrote: > > > It can happen that the direct I/O queue creates and destroys an empty > > > workqueue

Re: [PATCH 2/3] kernel/workqueue: Surround work execution with shared lock annotations

2018-10-25 Thread Johannes Berg
On Thu, 2018-10-25 at 10:22 -0700, Bart Van Assche wrote: > > What's this intended to change? I currently don't see how lockdep's > > behaviour would differ with read==1, unless you actually tried to do > > recursive locking, which isn't really possible? > > > > Or perhaps this is actually the

Re: [PATCH 3/3] kernel/workqueue: Suppress a false positive lockdep complaint

2018-10-25 Thread Johannes Berg
On Thu, 2018-10-25 at 15:05 +, Bart Van Assche wrote: > It can happen that the direct I/O queue creates and destroys an empty > workqueue from inside a work function. So, thinking about this more, can you guarantee (somehow) that the workqueue is empty at this point? Perhaps then we should

Re: [PATCH 2/3] kernel/workqueue: Surround work execution with shared lock annotations

2018-10-25 Thread Johannes Berg
On Thu, 2018-10-25 at 15:05 +, Bart Van Assche wrote: > Surround execution of work with a shared lockdep annotation because multiple > work items associated with a work queue may execute concurrently. Hmm. So, I'm not really entirely sure of the semantics here, but I fail to see how "may

Re: [PATCH 1/3] kernel/workqueue: Remove lockdep annotation from __flush_work()

2018-10-25 Thread Johannes Berg
On Thu, 2018-10-25 at 17:31 +0200, Johannes Berg wrote: > On Thu, 2018-10-25 at 15:05 +, Bart Van Assche wrote: > > As documented in a comment in start_flush_work(), calling flush_work() > > from a multi-threaded workqueue is safe if that workqueue is not > > equipped

Re: [PATCH 3/3] kernel/workqueue: Suppress a false positive lockdep complaint

2018-10-25 Thread Johannes Berg
On Thu, 2018-10-25 at 15:05 +, Bart Van Assche wrote: > @@ -2889,7 +2893,7 @@ static bool start_flush_work(struct work_struct *work, > struct wq_barrier *barr, >* workqueues the deadlock happens when the rescuer stalls, blocking >* forward progress. >*/ > - if

Re: [PATCH 1/3] kernel/workqueue: Remove lockdep annotation from __flush_work()

2018-10-25 Thread Johannes Berg
On Thu, 2018-10-25 at 15:05 +, Bart Van Assche wrote: > As documented in a comment in start_flush_work(), calling flush_work() > from a multi-threaded workqueue is safe if that workqueue is not > equipped with a rescuer. Avoid that flush_work() calls from inside a > work item executing on such

Re: [PATCH 0/3] Suppress false positives triggered by workqueue lockdep annotations

2018-10-25 Thread Johannes Berg
Hi Bart, > In my tests with kernel v4.19 I noticed that several new false positive > reports were generated by the workqueue lockdep annotations. This patch > series addresses one of these false positives. I tried my best to explain why they're not false positives as far as lockdep is concerned,

Re: [PATCH v2] wireless: mark expected switch fall-throughs

2018-10-23 Thread Johannes Berg
On Tue, 2018-10-23 at 12:58 +0200, Gustavo A. R. Silva wrote: > On 10/23/18 10:59 AM, Gustavo A. R. Silva wrote: > > > > On 10/23/18 9:01 AM, Johannes Berg wrote: > > > On Tue, 2018-10-23 at 02:13 +0200, Gustavo A. R. Silva wrote: > > > > In preparation to e

Re: [PATCH] Revert "workqueue: re-add lockdep dependencies for flushing"

2018-10-23 Thread Johannes Berg
On Tue, 2018-10-23 at 21:50 +0200, Johannes Berg wrote: > > The reason for the report is that with the workqueue annotations, we've > added new links to the chains that lockdep sees. I _think_ those > annotations are correct and only create links in the chain when they are > a

Re: [PATCH] Revert "workqueue: re-add lockdep dependencies for flushing"

2018-10-23 Thread Johannes Berg
On Tue, 2018-10-23 at 21:44 +0200, Johannes Berg wrote: > > There is > > no agreement however that the kind of checking implemented by the > > "crosslock" > > code made sense. My understanding is that you are trying to reintroduce > > throu

Re: [PATCH] Revert "workqueue: re-add lockdep dependencies for flushing"

2018-10-23 Thread Johannes Berg
On Mon, 2018-10-22 at 18:17 -0700, Bart Van Assche wrote: > It seems to me that the inode lock has been annotated correctly as an > rwsem. It's not clear to me however why lockdep complains about a > deadlock for the direct I/O code. I hope someone has the time to go to > the bottom of this.

Re: [PATCH] Revert "workqueue: re-add lockdep dependencies for flushing"

2018-10-23 Thread Johannes Berg
On Mon, 2018-10-22 at 14:26 -0700, Bart Van Assche wrote: > On Mon, 2018-10-22 at 23:04 +0200, Johannes Berg wrote: > > When lockdep was added, the networking socket locks also were (mostly) > > fine, recursion there only happened on different types of sockets. Yet, > > lockd

Re: [PATCH] Revert "workqueue: re-add lockdep dependencies for flushing"

2018-10-23 Thread Johannes Berg
On Mon, 2018-10-22 at 17:43 -0700, Sagi Grimberg wrote: > > > I must also say that I'm disappointed you'd try to do things this way. > > > I'd be (have been?) willing to actually help you understand the problem > > > and add the annotations, but rather than answer my question ("where do I > > >

Re: [PATCH] Revert "workqueue: re-add lockdep dependencies for flushing"

2018-10-22 Thread Johannes Berg
On Mon, 2018-10-22 at 13:54 -0700, Bart Van Assche wrote: > On Mon, 2018-10-22 at 22:28 +0200, Johannes Berg wrote: > > The lockdep report even more or less tells you what's going on. Perhaps > > we need to find a way to make lockdep not print "lock()" but "start()&qu

Re: [PATCH] Revert "workqueue: re-add lockdep dependencies for flushing"

2018-10-22 Thread Johannes Berg
On Mon, 2018-10-22 at 22:14 +0200, Johannes Berg wrote: > "False positives" - which in this case really should more accurately be > called "bad lockdep annotations" - of the kind you report here are > inherent in how lockdep works, and thus following your argument to

Re: [PATCH] Revert "workqueue: re-add lockdep dependencies for flushing"

2018-10-22 Thread Johannes Berg
On Mon, 2018-10-22 at 15:18 +, Bart Van Assche wrote: > Lockdep is a tool that developers rely on to find actual bugs. False > positive lockdep warnings are very annoying because it takes time to > analyze these and to verify that the warning is really a false positive > report. Since commit

Re: linux-next: manual merge of the crypto tree with the mac80211-next tree

2018-10-11 Thread Johannes Berg
On Thu, 2018-10-11 at 11:13 +1100, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the crypto tree got conflicts in: > > net/wireless/lib80211_crypt_tkip.c > net/wireless/lib80211_crypt_wep.c > > between commit: > > b802a5d6f345 ("lib80211: don't use skcipher") > >

Re: 4.19-rc[23] iwlwifi: BUG in swiotlb

2018-09-11 Thread Johannes Berg
On Mon, 2018-09-10 at 19:17 -0700, Randy Dunlap wrote: > Hi, > > Any ideas? Hmm. Is this new? > 2018-09-10T18:47:54.532837-07:00 dragon kernel: [ 31.472371] kernel BUG at > ../kernel/dma/swiotlb.c:521! nslots = ALIGN(size, 1 << IO_TLB_SHIFT) >> IO_TLB_SHIFT; [...]

[PATCH 0/2] workqueue lockdep limitations/bugs

2018-08-21 Thread Johannes Berg
Hi Tejun, Lia, all, While doing some unrelated testing earlier, I found a bug in workqueue lockdep, and while looking into the code I found another bug, and another limitation. I'll follow up with patches for the two bugs, and explain all three issues here. 1) Lockdep report is below - the

Re: [PATCH] bitfield: avoid gcc-8 -Wint-in-bool-context warning

2018-08-14 Thread Johannes Berg
On Tue, 2018-08-14 at 13:08 +0200, Arnd Bergmann wrote: > > It would be much more useful to indicate where the values are used. > > Such a field/parameter could (probably) have the type of the enum. > > But, at some point, the compiler might start barfing at that at well. > > I think the

Re: [PATCH] bitfield: avoid gcc-8 -Wint-in-bool-context warning

2018-08-14 Thread Johannes Berg
On Tue, 2018-08-14 at 08:57 +0900, Masahiro Yamada wrote: > 2018-08-14 7:09 GMT+09:00 Arnd Bergmann : > > Passing an enum into FIELD_GET() produces a long but harmless warning on > > newer compilers: > > > > from include/linux/linkage.h:7, > > from

Re: [PATCH v6 13/18] wireless/lib80211: Convert from ahash to shash

2018-07-25 Thread Johannes Berg
On Tue, 2018-07-24 at 09:49 -0700, Kees Cook wrote: > In preparing to remove all stack VLA usage from the kernel[1], this > removes the discouraged use of AHASH_REQUEST_ON_STACK in favor of > the smaller SHASH_DESC_ON_STACK by converting from ahash-wrapped-shash > to direct shash. By removing a

[PATCH v4 2/3] bitfield: add u8 helpers

2018-06-18 Thread Johannes Berg
There's no reason why we shouldn't pack/unpack bits into/from u8 values/registers/etc., so add u8 helpers. Use the MAKE_OP() macro directly to avoid having nonsense le8_encode_bits() and similar functions. Signed-off-by: Johannes Berg --- include/linux/bitfield.h | 1 + 1 file changed, 1

Re: [PATCH v2] bitfield: fix *_encode_bits()

2018-06-15 Thread Johannes Berg
On Fri, 2018-06-15 at 11:51 +0300, Andy Shevchenko wrote: > On Fri, Jun 15, 2018 at 12:26 AM, Johannes Berg > wrote: > > There's a bug in *_encode_bits() in using ~field_multiplier() for > > the check whether or not the constant value fits into the field, > > this is wrong

[PATCH v2] bitfield: fix *_encode_bits()

2018-06-14 Thread Johannes Berg
host- and fixed-endian.") Signed-off-by: Johannes Berg --- v2: replace stray tab by space If you don't mind, I'd like to take this through the networking tree(s) as a fix since I have some pending code that depends on it. --- include/linux/bitfield.h | 6 +++--- 1 file changed, 3 insertions(+), 3

[PATCH] bitfield: fix *_encode_bits()

2018-06-14 Thread Johannes Berg
host- and fixed-endian.") Signed-off-by: Johannes Berg --- If you don't mind, I'd like to take this through the networking tree(s) as a fix since I have some pending code that depends on it. --- include/linux/bitfield.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/inc

Re: WARNING in dev_vprintk_emit

2018-05-14 Thread Johannes Berg
On Sun, 2018-05-13 at 11:47 -0700, Eric Biggers wrote: > The bug is that mac80211_hwsim allows creating device names that are too long, > via HWSIM_CMD_NEW_RADIO. Commit a7cfebcb7594a2 ("cfg80211: limit wiphy names > to > 128 bytes") limited them to 128 bytes, but it's not enough because >

Re: [PATCH 09/18] net: mac80211.h: fix a bad comment line

2018-05-09 Thread Johannes Berg
On Wed, 2018-05-09 at 09:04 -0300, Mauro Carvalho Chehab wrote: > Em Mon, 07 May 2018 14:38:26 +0200 > Johannes Berg <johan...@sipsolutions.net> escreveu: > > > On Mon, 2018-05-07 at 15:37 +0300, Kalle Valo wrote: > > > Mauro Carvalho Chehab <m

Re: linux-next: build warning after merge of the mac80211-next tree

2018-05-09 Thread Johannes Berg
Thanks Stephen, The 0-day bot also gave me this heads-up, there are a few more places like it too. I'd asked Toke to fix the ones in the stack, but we both missed the ones in the drivers. I'll get a fix in for that one way or the other. johannes

Re: [PATCH] mac80211: ethtool: avoid 32 bit multiplication overflow

2018-05-08 Thread Johannes Berg
On Tue, 2018-05-08 at 13:57 +0100, Colin King wrote: > From: Colin Ian King > > The multiplication of 10 * cfg80211_calculate_bitrate() is a 32 bit > operation and can overflow if cfg80211_calculate_bitrate is greater > than 42949. Although I don't believe this is

Re: [PATCH 09/18] net: mac80211.h: fix a bad comment line

2018-05-07 Thread Johannes Berg
On Mon, 2018-05-07 at 15:37 +0300, Kalle Valo wrote: > Mauro Carvalho Chehab writes: > > > Sphinx produces a lot of errors like this: > > ./include/net/mac80211.h:2083: warning: bad line: > > > > > Signed-off-by: Mauro Carvalho Chehab

Re: WARNING in kernfs_add_one

2018-05-07 Thread Johannes Berg
On Mon, 2018-05-07 at 11:33 +0200, Dmitry Vyukov wrote: > On Mon, May 7, 2018 at 10:43 AM, Johannes Berg > <johan...@sipsolutions.net> wrote: > > On Sat, 2018-05-05 at 15:07 -0700, Greg KH wrote: > > > > > > > > syzbot found the following crash on: >

Re: WARNING in kernfs_add_one

2018-05-07 Thread Johannes Berg
On Sat, 2018-05-05 at 15:07 -0700, Greg KH wrote: > > > > syzbot found the following crash on: Maybe it should learn to differentiate warnings, if it's going to set panic_on_warn :-) I get why, but still, at least differentiating in the emails wouldn't be bad. > > > > kernfs: ns required in

Re: make xmldocs failed with error after 4.17 merge period

2018-04-07 Thread Johannes Berg
On Fri, 2018-04-06 at 13:38 +0200, Markus Heiser wrote: > > Sorry, not yet. Johannes started a discussion about this. Its a long > time ago and I do not have any new ideas yet :/ see: > > https://www.mail-archive.com/linux-doc@vger.kernel.org/msg07035.html I still think the tools themselves

Re: WARNING in add_uevent_var

2018-04-03 Thread Johannes Berg
On Sun, 2018-04-01 at 23:01 -0700, syzbot wrote: > So far this crash happened 5 times on net-next, upstream. > C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6614377067184128 > Huh, fun. Looks like you're basically creating a new HWSIM radio with an insanely long name (4k!) and

Re: [PATCH 1/3] ieee80211: Replace bit shifts with the BIT() macro for WLAN_CAPABILITY_*.

2018-03-27 Thread Johannes Berg
On Sat, 2018-03-24 at 16:02 -0700, Quytelda Kahja wrote: > The "document" refers to the file in which the changes were made > ('include/linux/ieee80211.h'). You're the first person ever to do that, to my knowledge :) Either way, I don't really want to merge this since it would break staging, and

Re: [PATCH] mac80211: aes-cmac: remove VLA usage

2018-03-21 Thread Johannes Berg
On Wed, 2018-03-21 at 08:57 -0500, Gustavo A. R. Silva wrote: > > SHA_DESC_ON_STACK is currently being used in multiple places. But, yeah, > I think we can define multiple macros of the same kind and adjust to the > characteristics of each the component. > > How big do you think tfm can get?

Re: [PATCH] mac80211: aes-cmac: remove VLA usage

2018-03-21 Thread Johannes Berg
On Wed, 2018-03-21 at 08:42 -0500, Gustavo A. R. Silva wrote: > In preparation to enabling -Wvla, remove VLAs and replace them > with dynamic memory allocation instead. > > The use of stack Variable Length Arrays needs to be avoided, as they > can be a vector for stack exhaustion, which can be

Re: KASAN: use-after-free Read in mac80211_hwsim_del_radio

2018-03-01 Thread Johannes Berg
On Thu, 2018-03-01 at 13:32 +0100, Benjamin Beichler wrote: > > Could you give me a link to or forward the original email ? I googled > "KASAN: use-after-free Read in mac80211_hwsim_del_radio", but only your > answer (without the logs) appears. I try to have a look then in the next > few days. >

Re: KASAN: use-after-free Read in mac80211_hwsim_del_radio

2018-03-01 Thread Johannes Berg
Hi, > syzbot hit the following crash on upstream commit > f3afe530d644488a074291da04a69a296ab63046 (Tue Feb 27 22:02:39 2018 +) > Merge branch 'fixes-v4.16-rc4' of > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security > > So far this crash happened 4 times on upstream. >

Re: [PATCH 2/3] mwifiex: support sysfs initiated device coredump

2018-02-23 Thread Johannes Berg
Hey, Hadn't really followed this discussion much due to other fires elsewhere :-) On Fri, 2018-02-23 at 11:39 +0100, Arend van Spriel wrote: > > > Well, that depends on the eye of the beholder I guess. From user-space > > > perspective it is asynchronous regardless. A write access to the

Re: nla_put_string() vs NLA_STRING

2018-02-22 Thread Johannes Berg
On Tue, 2018-02-20 at 22:00 -0800, Kees Cook wrote: > It seems that in at least one case[1], nla_put_string() is being used > on an NLA_STRING, which lacks a NULL terminator, which leads to > silliness when nla_put_string() uses strlen() to figure out the size: Fun! I'm not a big fan of the

Re: WARNING in check_flush_dependency

2018-02-19 Thread Johannes Berg
On Mon, 2018-02-19 at 19:58 +0100, Dmitry Vyukov wrote: > > > Yeah, we clearly shouldn't have WQ_RECLAIM set on this workqueue... > > Hi Johannes, > > Do you mind to send a patch to fix this? Yeah, sorry, I've been behind on patches a bit. I just applied it today, and once I've let it sit for

Re: WARNING in check_flush_dependency

2018-01-23 Thread Johannes Berg
On Mon, 2018-01-22 at 23:39 -0800, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > 0d665e7b109d512b7cae3ccef6e8654714887844 (Fri Jan 19 12:49:24 2018 +) > mm, page_vma_mapped: Drop faulty pointer arithmetics in check_pte() > > So far this crash happened 23

Re: [PATCH v4 10/10] nl80211: sanitize array index in parse_txq_params

2018-01-21 Thread Johannes Berg
ize txq_params->ac with respect to speculation. I.e. ensure that > any speculation into ->conf_tx() handlers is done with a value of > txq_params->ac that is within the bounds of [0, NL80211_NUM_ACS). Sorry, I didn't realize you were waiting for me to review. LGTM. Reviewed-by: Johanne

Re: [PATCH] cfg80211: stop demanding lots of new stuff

2018-01-18 Thread Johannes Berg
On Thu, 2018-01-18 at 13:07 -0800, Hugh Dickins wrote: > Perhaps you did not try on a system without SYSTEM_DATA_VERIFICATION > already enabled - that "select SYSTEM_DATA_VERIFICATION" seems to be > taking effect even when CFG80211_REQUIRE_SIGNED_REGDB is not enabled, > and pulls in a boatload.

Re: [PATCH] cfg80211: stop demanding lots of new stuff

2018-01-17 Thread Johannes Berg
On Wed, 2018-01-17 at 14:55 -0800, Hugh Dickins wrote: > "make oldconfig" from 4.14 (when CONFIG_CFG80211_CERTIFICATION_ONUS > is not set) to 4.15-rc, gets into asking lots of new questions, and > configuring in unwanted stuff: I'm unsure of my Kconfig skills, but > it looks like

Re: UBSAN: Undefined behaviour in net/wireless/nl80211.c:718:4: -1665903437 * 100 cannot be represented in type 'int'

2018-01-17 Thread Johannes Berg
On Wed, 2018-01-17 at 13:22 +0100, Paul Menzel wrote: > > Yes it does. Thank you. Rebuilding Linux 4.15-rc8+ with this patch > applied, the UBSAN doesn’t report this issue anymore. Thanks for testing, the patch is on its way to get to 4.15 (hopefully) johannes

Re: linux-next: manual merge of the mac80211-next tree with the mac80211 tree

2018-01-15 Thread Johannes Berg
Hi Stephen, > between commit: > > b71d856ab536 ("mac80211_hwsim: add workqueue to wait for deferred radio > deletion on mod unload") > > from the mac80211 tree and commit: > > c6509cc3b3e8 ("mac80211_hwsim: add hashtable with mac address keys for > faster lookup") > > from the

Re: WARNING in rfkill_alloc

2018-01-15 Thread Johannes Berg
On Mon, 2018-01-15 at 10:12 +0100, Dmitry Vyukov wrote: > However, there can be some surprising things, for example, executing > one ioctl/setsockopt with data meant for another one, or these > 0x are actually mean 0 (for involved reasons), I think those fff was actually what

Re: WARNING in rfkill_alloc

2018-01-15 Thread Johannes Berg
Hi, > RIP: 0010:rfkill_alloc+0x2c0/0x380 net/rfkill/core.c:930 This seems pretty obvious - there's no name given. > wiphy_new_nm+0x159c/0x21d0 net/wireless/core.c:487 > ieee80211_alloc_hw_nm+0x4b4/0x2140 net/mac80211/main.c:531 which is strange, because we try to validate the name here.

Re: WARNING in wiphy_register

2018-01-15 Thread Johannes Berg
Hi syzbot maintainers, Thanks for the report. > hwsim_new_radio_nl+0x5b7/0x7c0 drivers/net/wireless/mac80211_hwsim.c:3152 > genl_family_rcv_msg+0x7b7/0xfb0 net/netlink/genetlink.c:599 > genl_rcv_msg+0xb2/0x140 net/netlink/genetlink.c:624 You're getting into the kernel via generic netlink

Re: [PATCH v3] nl80211: take RCU read lock when calling ieee80211_bss_get_ie()

2018-01-15 Thread Johannes Berg
On Mon, 2018-01-15 at 08:12 +0100, Dominik Brodowski wrote: > As ieee80211_bss_get_ie() derefences an RCU to return ssid_ie, both > the call to this function and any operation on this variable need > protection by the RCU read lock. > > Fixes: 44905265bc15 ("nl80211: don't expose wdev->ssid for

Re: [PATCH v2] nl80211: take RCU read lock when calling ieee80211_bss_get_ie()

2018-01-14 Thread Johannes Berg
On Sun, 2018-01-14 at 23:22 +0100, Dominik Brodowski wrote: > > + rcu_read_lock(); > ssid_ie = ieee80211_bss_get_ie(>current_bss->pub, > WLAN_EID_SSID); > if (!ssid_ie) > - break; nit-picking

Re: [PATCH] nl80211: take RCU read lock when calling ieee80211_bss_get_ie()

2018-01-14 Thread Johannes Berg
Hi, > Fixes: 44905265bc15 ("nl80211: don't expose wdev->ssid for most interfaces") > Signed-off-by: Dominik Brodowski > --- > > This patch fixes the regression I reported in the last couple of weeks for > various v4.15-rcX revisions to netdev, where a "suspicious RCU

Re: [PATCH v4 31/36] mac80211_hwsim: Replace hrtimer tasklet with softirq hrtimer

2018-01-04 Thread Johannes Berg
On Thu, 2017-12-21 at 11:42 +0100, Anna-Maria Gleixner wrote: > From: Thomas Gleixner > > Switch the timer to HRTIMER_MODE_SOFT, which executed the timer I've pointed out before that this should say HRTIMER_MODE_REL_SOFT. Anyway, since it still doesn't apply on my tree,

Re: [PATCH] nl80211: Check for the required netlink attribute presence

2018-01-04 Thread Johannes Berg
On Wed, 2018-01-03 at 11:00 +0800, Hao Chen wrote: > nl80211_nan_add_func() does not check if the required attribute > NL80211_NAN_FUNC_FOLLOW_UP_DEST is present when processing > NL80211_CMD_ADD_NAN_FUNCTION request. This request can be issued > by users with CAP_NET_ADMIN privilege and may

Re: UBSAN: Undefined behaviour in net/wireless/nl80211.c:718:4: -1665903437 * 100 cannot be represented in type 'int'

2018-01-04 Thread Johannes Berg
Hi, Can you reproduce this? > [ 54.426491] UBSAN: Undefined behaviour in net/wireless/nl80211.c:718:4 > [ 54.426492] signed integer overflow: > [ 54.426493] -1665903437 * 100 cannot be represented in type 'int' Obviously. However, it looks like the real reason is that there's some

Re: [PATCH for-4.15] wireless: create, don't append, to shipped-certs.c

2017-12-19 Thread Johannes Berg
On Tue, 2017-12-19 at 11:23 -0800, Brian Norris wrote: > > In practice, this is seen often by having a separate source and build > directory, where the build artifacts remain but the source tree changes > (even if Seth's cert doesn't change, it might get created/removed when > checking out

Re: [PATCH] wireless: Always rewrite generated files from scratch

2017-12-19 Thread Johannes Berg
On Thu, 2017-12-14 at 14:33 +0100, Thierry Reding wrote: > From: Thierry Reding > > Currently the certs C code generation appends to the generated files, > which is most likely a leftover from commit 715a12334764 ("wireless: > don't write C files on failures"). This causes

Re: error: redefinition of ‘shipped_regdb_certs’

2017-12-19 Thread Johannes Berg
Hi Michal, > this is the first time I am seeing this with the current Linus > tree. 4.15-rc3 compiled fine. I have checked that you have updated the > makefile which generates the file by 715a12334764 ("wireless: don't > write C files on failures"). Which introduced the problem - I accidentally

Re: linux-next: build failure after merge of the mac80211-next tree

2017-12-12 Thread Johannes Berg
Hi Stephen, Thanks! Felix made me aware of this yesterday evening and said he's going to work out the required changes to mt76. Kalle and I will make sure to submit the trees to Dave one by one so he doesn't have to deal with it :) Unfortunately, this might take a few days to resolve. > -void

Re: [PATCH v3 31/36] mac80211_hwsim: Replace hrtimer tasklet with softirq hrtimer

2017-12-11 Thread Johannes Berg
IMER_MODE_REL_SOFT, but otherwise looks good to me. Reviewed-by: Johannes Berg <johan...@sipsolutions.net johannes

Re: Wireless regressions in v4.15-rc1

2017-12-09 Thread Johannes Berg
On Sat, 2017-12-02 at 14:59 +0200, Kalle Valo wrote: > > net: netlink: Update attr validation to require exact length for some types > https://git.kernel.org/linus/28033ae4e0f5 This was reverted, more or less, to print only a warning:

Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input

2017-12-05 Thread Johannes Berg
Hi, > > Ah, here we go - you probably don't have "hexdump" installed on this > > system? > > Well, I didn’t, but got the error, that hexdump couldn’t be found. After > installing it, I got the error above, and sent the message. Ah, ok. > Removing the file `net/wireless/shipped-certs.c`, and

Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input

2017-12-05 Thread Johannes Berg
On Tue, 2017-12-05 at 11:01 +0100, Paul Menzel wrote: > > > ``` > $ git describe > v4.15-rc2-79-gfd6d2e506ce6 > $ git log --oneline -1 > fd6d2e506ce6 Merge tag 'docs-4.15-fixes' of git://git.lwn.net/linux > $ time ARCH=i386 make deb-pkg -j50 > […] > net/wireless/shipped-certs.c:2:1: error:

Re: d7be102f29 ("cfg80211: initialize regulatory keys/database later"): kernel BUG at crypto/asymmetric_keys/public_key.c:80!

2017-11-27 Thread Johannes Berg
On Mon, 2017-11-27 at 21:46 +, Linus Torvalds wrote: > On Sat, Nov 25, 2017 at 7:07 PM, Fengguang Wu wrote: > > FYI, we noticed the following commit (built with gcc-4.8): > > > > commit: d7be102f2945a626f55e0501e52bb31ba3e77b81 ("cfg80211: initialize > > regulatory

Re: [PATCH 2/2] staging: rtl8188eu: Fix private WEXT IOCTL calls

2017-11-27 Thread Johannes Berg
Hi, So I removed those call-through place because private wext operations are a really bad idea and should just die. We don't want drivers to require specially patched hostapd versions to work right, like here. I suppose in staging you might want to work around that like here, but that really

Re: [PATCH v3] staging: rtl8188eu: Fix private WEXT IOCTL calls

2017-11-27 Thread Johannes Berg
In addition to what Dan said, > +static iw_handler rtw_handlers_private[] = { > + NULL, /* Empty */ > + rtw_hostapd_sta_flush_pvt, /* RTL871X_HOSTAPD_FLUSH */ > + rtw_add_sta_pvt, /* RTL871X_HOSTAPD_ADD_STA */ > + rtw_del_sta_pvt,

Re: kernel BUG at crypto/asymmetric_keys/public_key.c:80

2017-11-23 Thread Johannes Berg
On Thu, 2017-11-23 at 09:47 -0800, Florian Fainelli wrote: > Absolutely, please find it enclosed. Thanks. This is a bit odd. I didn't think the most likely reason is that you have CONFIG_CRYPTO_SHA256=m but everything else built-in. Thus, when loading the certificate, there's no way to

Re: kernel BUG at crypto/asymmetric_keys/public_key.c:80

2017-11-23 Thread Johannes Berg
On Wed, 2017-11-22 at 15:07 -0800, Florian Fainelli wrote: > On 11/22/2017 10:42 AM, Johannes Berg wrote: > > On Wed, 2017-11-22 at 19:29 +0100, Arend van Spriel wrote: > > > + Johannes > > > > > > >>> BUG_ON(!sig->digest); > > >

Re: kernel BUG at crypto/asymmetric_keys/public_key.c:80

2017-11-22 Thread Johannes Berg
On Wed, 2017-11-22 at 19:29 +0100, Arend van Spriel wrote: > + Johannes > > >>> BUG_ON(!sig->digest); > BUG_ON(!sig->s); I *think* this is the same bug that was reported before, then this should fix it:

Re: [PATCH net] genetlink: fix genlmsg_nlhdr()

2017-11-15 Thread Johannes Berg
note, family->hdrsize is 0 for all the families calling this right now. Reviewed-by: Johannes Berg <johan...@sipsolutions.net> johannes

Re: [PATCH v4] af_netlink: ensure that NLMSG_DONE never fails in dumps

2017-11-11 Thread Johannes Berg
> > If you're handling this by forcing another read() to procude the > > NLMSG_DONE, then you have no reason to WARN_ON() here. > > > > In fact you are adding a WARN_ON() which is trivially triggerable by > > any user. > > I added this in my suggestion for how this could work, but I don't >

Re: [PATCH v4] af_netlink: ensure that NLMSG_DONE never fails in dumps

2017-11-11 Thread Johannes Berg
On Sat, 2017-11-11 at 23:09 +0900, David Miller wrote: > From: "Jason A. Donenfeld" > Date: Thu, 9 Nov 2017 13:04:44 +0900 > > > @@ -2195,13 +2197,15 @@ static int netlink_dump(struct sock *sk) > > return 0; > > } > > > > - nlh = nlmsg_put_answer(skb,

Re: [PATCH v3] af_netlink: ensure that NLMSG_DONE never fails in dumps

2017-11-08 Thread Johannes Berg
On Thu, 2017-11-09 at 10:42 +0900, Jason A. Donenfeld wrote: > +++ b/net/netlink/af_netlink.c > @@ -2136,7 +2136,7 @@ static int netlink_dump(struct sock *sk) > struct sk_buff *skb = NULL; > struct nlmsghdr *nlh; > struct module *module; > - int len, err = -ENOBUFS; > +

Re: [PATCH] af_netlink: give correct bounds to dump skb for NLMSG_DONE

2017-11-07 Thread Johannes Berg
On Tue, 2017-11-07 at 20:29 +0900, Jason A. Donenfeld wrote: > > This patch thus reserves and restores the required length for > NLMSG_DONE during the call to the dump function. > That basically removes that space though, even when the dump isn't complete... wouldn't it be better to do

Re: [PATCH] devcoredump: remove redundant assignment to iter

2017-11-07 Thread Johannes Berg
On Tue, 2017-11-07 at 10:42 +, Colin King wrote: > From: Colin Ian King > > The assignment to pointer iter is redundant as this is also performed > in the following macro for_each_sg, hence it can be removed. Cleans > up clang warning: > >

Re: [PATCH 09/19] net: average: Kill off ACCESS_ONCE()

2017-10-23 Thread Johannes Berg
n E; > @@ > > - ACCESS_ONCE(E) > + READ_ONCE(E) > > > Signed-off-by: Mark Rutland <mark.rutl...@arm.com> > Cc: Johannes Berg <johannes.b...@intel.com> Reviewed-by: Johannes Berg <johan...@sipsolutions.net> Let me know if you want me to apply this, since I seem to be the average.h maintainer :-) johannes

Re: [PATCH v2 31/37] mac80211_hwsim: Replace hrtimer tasklet with softirq hrtimer

2017-10-23 Thread Johannes Berg
> > I guess you mean you *can* build it? Surely you're introducing the new > > HR timer modes in some patch that I didn't see? :-) > > Sorry, we did not want to expose you to 30 patches fiddling with the core > code. They are on LKML though. Sure, no worries. I just didn't even realize I

Re: [PATCH v2 31/37] mac80211_hwsim: Replace hrtimer tasklet with softirq hrtimer

2017-10-23 Thread Johannes Berg
On Mon, 2017-10-23 at 12:23 +0200, Thomas Gleixner wrote: > On Mon, 23 Oct 2017, Johannes Berg wrote: > > > On Sun, 2017-10-22 at 23:40 +0200, Anna-Maria Gleixner wrote: > > > From: Thomas Gleixner <t...@linutronix.de> > > > > > > Switch the timer t

Re: [PATCH v2 31/37] mac80211_hwsim: Replace hrtimer tasklet with softirq hrtimer

2017-10-23 Thread Johannes Berg
On Sun, 2017-10-22 at 23:40 +0200, Anna-Maria Gleixner wrote: > From: Thomas Gleixner > > Switch the timer to HRTIMER_MODE_SOFT, which executed the timer > callback in softirq context and remove the hrtimer_tasklet. This doesn't build on my tree, due to HRTIMER_MODE_REL_SOFT

Re: [PATCH] net: wireless: mark expected switch fall-throughs

2017-10-23 Thread Johannes Berg
On Fri, 2017-10-20 at 12:21 -0500, Gustavo A. R. Silva wrote: > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Signed-off-by: Gustavo A. R. Silva > --- > This code was tested by compilation only (GCC

Re: [PATCH] mac80211: aggregation: Convert timers to use timer_setup()

2017-10-18 Thread Johannes Berg
On Wed, 2017-10-18 at 07:19 -0700, Kees Cook wrote: > On Wed, Oct 18, 2017 at 3:29 AM, Johannes Berg > <johan...@sipsolutions.net> wrote: > > > This has been the least trivial timer conversion yet. Given the use of > > > RCU and other things I may not even know

Re: [PATCH] mac80211: aggregation: Convert timers to use timer_setup()

2017-10-18 Thread Johannes Berg
On Wed, 2017-10-18 at 13:31 +0200, Johannes Berg wrote: > On Wed, 2017-10-18 at 12:29 +0200, Johannes Berg wrote: > > > Anyway, the change here looks correct to me, so I'll apply it and then > > perhaps clean up more. I've only changed "u16 tid" to "u8 tid&q

Re: [PATCH] mac80211: aggregation: Convert timers to use timer_setup()

2017-10-18 Thread Johannes Berg
On Wed, 2017-10-18 at 12:29 +0200, Johannes Berg wrote: > Anyway, the change here looks correct to me, so I'll apply it and then > perhaps clean up more. I've only changed "u16 tid" to "u8 tid" since > the valid range is 0-15 (in theory, in practice 0-7). Well, I g

Re: [PATCH] mac80211: aggregation: Convert timers to use timer_setup()

2017-10-18 Thread Johannes Berg
Hi, [quoting your other email:] > This has been the least trivial timer conversion yet. Given the use of > RCU and other things I may not even know about, I'd love to get a close > look at this. I *think* this is correct, as it will re-lookup the tid > entries when firing the timer. I'm not

Re: deadlock in debugfs synchronize_srcu() when unplugging USB

2017-10-16 Thread Johannes Berg
On Mon, 2017-10-16 at 09:51 +0200, Greg Kroah-Hartman wrote: > As Paul stated, fixing up the patches and sending them in is the best > solution, can you help out with that? Is there anything to fix though? I'm not really aware of anything, and there were no comments on his v2 patchset. johannes

  1   2   3   4   5   6   7   8   9   10   >