Thread (17 messages) 17 messages, 8 authors, 2021-03-19

Re: [PATCH][next] loop: Fix missing max_active argument in alloc_workqueue call

From: Krzysztof Kozlowski <krzk@kernel.org>
Date: 2021-03-19 10:04:10
Also in: linux-block, lkml

On 19/03/2021 10:47, Dan Carpenter wrote:
On Thu, Mar 18, 2021 at 02:42:33PM -0600, Jens Axboe wrote:
quoted
On 3/18/21 2:24 PM, Colin Ian King wrote:
quoted
On 18/03/2021 20:12, Jens Axboe wrote:
quoted
On 3/18/21 9:16 AM, Colin King wrote:
quoted
From: Colin Ian King <redacted>

The 3rd argument to alloc_workqueue should be the max_active count,
however currently it is the lo->lo_number that is intended for the
loop%d number. Fix this by adding in the missing max_active count.
Dan, please fold this (or something similar) in when you're redoing the
series.
Appreciate this fix being picked up. Are we going to lose the SoB?
If it's being redone, would be silly to have that error in there. Do
we have a tag that's appropriate for this? I often wonder when I'm
folding in a fix. Ala Fixes-by: or something like that.
I've always lobied for a Fixes-from: tag, but the kbuild-bot tells
everyone to add a Reported-by: tag.  But then a lot of people are like
Reported-by doesn't make sense.  And other people are like Reported-by
is fine, what's wrong with it?
If the original commit is a fix and the fix for it is being squashed,
then Reported-by might mislead.

kbuild-bot tests also patches from list directly, so in such case the
patch can be re-done with a risk of loosing kbuild's credits. But when
the patch is already in the maintainer tree - just create a fixup. You
preserve the development history and the kbuild's credits.


Best regards,
Krzysztof
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help