2021-03-18 23:18:55

by Stephen Rothwell

[permalink] [raw]
Subject: linux-next: Signed-off-by missing for commit in the block tree

Hi all,

Commit

c2c6c067c050 ("io_uring: remove structures from include/linux/io_uring.h")

is missing a Signed-off-by from its author.

--
Cheers,
Stephen Rothwell


Attachments:
(No filename) (499.00 B)
OpenPGP digital signature

2021-03-18 23:27:14

by Jens Axboe

[permalink] [raw]
Subject: Re: linux-next: Signed-off-by missing for commit in the block tree

On 3/18/21 5:16 PM, Stephen Rothwell wrote:
> Hi all,
>
> Commit
>
> c2c6c067c050 ("io_uring: remove structures from include/linux/io_uring.h")
>
> is missing a Signed-off-by from its author.

Stefan, let me know if you're OK with me adding that, not sure how I missed
that.

--
Jens Axboe

2021-03-19 08:04:03

by Stefan Metzmacher

[permalink] [raw]
Subject: Re: linux-next: Signed-off-by missing for commit in the block tree


Am 19.03.21 um 00:25 schrieb Jens Axboe:
> On 3/18/21 5:16 PM, Stephen Rothwell wrote:
>> Hi all,
>>
>> Commit
>>
>> c2c6c067c050 ("io_uring: remove structures from include/linux/io_uring.h")
>>
>> is missing a Signed-off-by from its author.
>
> Stefan, let me know if you're OK with me adding that, not sure how I missed
> that.

Yes, sure :-)
I guess you removed it while adding 'Link:'

You may want to remove cc: stable from 3aab52c9a708f7183460d368700181ef0c2a09e6
("io_uring: imply MSG_NOSIGNAL for send[msg]()/recv[msg]() calls")
for now.

I'll want to do some more test with it on 5.12,
I guess we'd then have to backport it to stable as part of the
io_thread worker backport. I'll post some more details later
to the io-uring list.

Thanks!
metze

2021-03-19 13:10:52

by Jens Axboe

[permalink] [raw]
Subject: Re: linux-next: Signed-off-by missing for commit in the block tree

On 3/19/21 2:02 AM, Stefan Metzmacher wrote:
>
> Am 19.03.21 um 00:25 schrieb Jens Axboe:
>> On 3/18/21 5:16 PM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Commit
>>>
>>> c2c6c067c050 ("io_uring: remove structures from include/linux/io_uring.h")
>>>
>>> is missing a Signed-off-by from its author.
>>
>> Stefan, let me know if you're OK with me adding that, not sure how I missed
>> that.
>
> Yes, sure :-)
> I guess you removed it while adding 'Link:'

That was b4, I don't add those manually. But maybe it stripped those too,
annoying...

> You may want to remove cc: stable from 3aab52c9a708f7183460d368700181ef0c2a09e6
> ("io_uring: imply MSG_NOSIGNAL for send[msg]()/recv[msg]() calls")
> for now.
>
> I'll want to do some more test with it on 5.12,
> I guess we'd then have to backport it to stable as part of the
> io_thread worker backport. I'll post some more details later
> to the io-uring list.

Sure, let's do that. I also dropped the short link sever as well for now.
I do like it on principle, but it does have a risk of breaking valid
use cases.

--
Jens Axboe

2021-03-19 13:12:29

by Stefan Metzmacher

[permalink] [raw]
Subject: Re: linux-next: Signed-off-by missing for commit in the block tree


Am 19.03.21 um 14:08 schrieb Jens Axboe:
> On 3/19/21 2:02 AM, Stefan Metzmacher wrote:
>>
>> Am 19.03.21 um 00:25 schrieb Jens Axboe:
>>> On 3/18/21 5:16 PM, Stephen Rothwell wrote:
>>>> Hi all,
>>>>
>>>> Commit
>>>>
>>>> c2c6c067c050 ("io_uring: remove structures from include/linux/io_uring.h")
>>>>
>>>> is missing a Signed-off-by from its author.
>>>
>>> Stefan, let me know if you're OK with me adding that, not sure how I missed
>>> that.
>>
>> Yes, sure :-)
>> I guess you removed it while adding 'Link:'
>
> That was b4, I don't add those manually. But maybe it stripped those too,
> annoying...
>
>> You may want to remove cc: stable from 3aab52c9a708f7183460d368700181ef0c2a09e6
>> ("io_uring: imply MSG_NOSIGNAL for send[msg]()/recv[msg]() calls")
>> for now.
>>
>> I'll want to do some more test with it on 5.12,
>> I guess we'd then have to backport it to stable as part of the
>> io_thread worker backport. I'll post some more details later
>> to the io-uring list.
>
> Sure, let's do that. I also dropped the short link sever as well for now.
> I do like it on principle, but it does have a risk of breaking valid
> use cases.

Thanks, I'll resubmit that with the MSG_WAITALL logic.

metze