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

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

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

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

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

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

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

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

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

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

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

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 3/3] kernel/workqueue: Suppress a false positive lockdep complaint

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

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 2/3] kernel/workqueue: Surround work execution with shared lock annotations

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

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 3/3] kernel/workqueue: Suppress a false positive lockdep complaint

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

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 2/3] kernel/workqueue: Surround work execution with shared lock annotations

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()

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 1/3] kernel/workqueue: Remove lockdep annotation from __flush_work()

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

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 3/3] kernel/workqueue: Suppress a false positive lockdep complaint

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()

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 1/3] kernel/workqueue: Remove lockdep annotation from __flush_work()

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

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 0/3] Suppress false positives triggered by workqueue lockdep annotations

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

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 v2] wireless: mark expected switch fall-throughs

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"

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"

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"

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"

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"

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"

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"

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"

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"

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"

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"

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"

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"

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"

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"

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: [PATCH] Revert "workqueue: re-add lockdep dependencies for flushing"

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

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: linux-next: manual merge of the crypto tree with the mac80211-next tree

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

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; [...]

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

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

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

[PATCH 0/2] workqueue lockdep limitations/bugs

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

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

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

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] bitfield: avoid gcc-8 -Wint-in-bool-context warning

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

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

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

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

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

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

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()

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

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

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()

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 v2] bitfield: fix *_encode_bits()

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()

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

[PATCH] bitfield: fix *_encode_bits()

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

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: WARNING in dev_vprintk_emit

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

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: [PATCH 09/18] net: mac80211.h: fix a bad comment line

On Wed, 2018-05-09 at 09:04 -0300, Mauro Carvalho Chehab wrote: > Em Mon, 07 May 2018 14:38:26 +0200 > Johannes Berg escreveu: > > > On Mon, 2018-05-07 at 15:37 +0300, Kalle Valo wrote: > > > Mauro Carvalho Chehab writes: > > > > > &

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

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: linux-next: build warning after merge of the mac80211-next tree

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

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] mac80211: ethtool: avoid 32 bit multiplication overflow

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 occurring at present, it >

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

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: [PATCH 09/18] net: mac80211.h: fix a bad comment line

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 > > Randy already submitted a similar patch: > >

Re: WARNING in kernfs_add_one

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

On Mon, 2018-05-07 at 11:33 +0200, Dmitry Vyukov wrote: > On Mon, May 7, 2018 at 10:43 AM, Johannes Berg > wrote: > > On Sat, 2018-05-05 at 15:07 -0700, Greg KH wrote: > > > > > > > > syzbot found the following crash on: > > > > Maybe it shoul

Re: WARNING in kernfs_add_one

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: WARNING in kernfs_add_one

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

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: make xmldocs failed with error after 4.17 merge period

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

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: WARNING in add_uevent_var

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_*.

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 1/3] ieee80211: Replace bit shifts with the BIT() macro for WLAN_CAPABILITY_*.

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

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

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

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: [PATCH] mac80211: aes-cmac: remove VLA usage

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

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

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

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: KASAN: use-after-free Read in mac80211_hwsim_del_radio

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

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: [PATCH 2/3] mwifiex: support sysfs initiated device coredump

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

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: nla_put_string() vs NLA_STRING

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

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

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

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: WARNING in check_flush_dependency

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

<    1   2   3   4   5   6   7   8   9   10   >