On 5/31/21 7:54 AM, Olivier Langlois wrote:
> Fix tabulation to make nice columns
Reviewed-by: Pavel Begunkov <[email protected]>
>
> Signed-off-by: Olivier Langlois <[email protected]>
> ---
> include/trace/events/io_uring.h | 35 ++++++++++++++++-----------------
> 1 file changed, 17 insertions(+), 18 deletions(-)
>
> diff --git a/include/trace/events/io_uring.h b/include/trace/events/io_uring.h
> index 12addad1f837..e4e44a2b4aa9 100644
> --- a/include/trace/events/io_uring.h
> +++ b/include/trace/events/io_uring.h
> @@ -12,11 +12,11 @@ struct io_wq_work;
> /**
> * io_uring_create - called after a new io_uring context was prepared
> *
> - * @fd: corresponding file descriptor
> - * @ctx: pointer to a ring context structure
> + * @fd: corresponding file descriptor
> + * @ctx: pointer to a ring context structure
> * @sq_entries: actual SQ size
> * @cq_entries: actual CQ size
> - * @flags: SQ ring flags, provided to io_uring_setup(2)
> + * @flags: SQ ring flags, provided to io_uring_setup(2)
> *
> * Allows to trace io_uring creation and provide pointer to a context, that can
> * be used later to find correlated events.
> @@ -52,12 +52,12 @@ TRACE_EVENT(io_uring_create,
> * io_uring_register - called after a buffer/file/eventfd was successfully
> * registered for a ring
> *
> - * @ctx: pointer to a ring context structure
> - * @opcode: describes which operation to perform
> + * @ctx: pointer to a ring context structure
> + * @opcode: describes which operation to perform
> * @nr_user_files: number of registered files
> * @nr_user_bufs: number of registered buffers
> * @cq_ev_fd: whether eventfs registered or not
> - * @ret: return code
> + * @ret: return code
> *
> * Allows to trace fixed files/buffers/eventfds, that could be registered to
> * avoid an overhead of getting references to them for every operation. This
> @@ -142,16 +142,16 @@ TRACE_EVENT(io_uring_queue_async_work,
> TP_ARGS(ctx, rw, req, work, flags),
>
> TP_STRUCT__entry (
> - __field( void *, ctx )
> - __field( int, rw )
> - __field( void *, req )
> + __field( void *, ctx )
> + __field( int, rw )
> + __field( void *, req )
> __field( struct io_wq_work *, work )
> __field( unsigned int, flags )
> ),
>
> TP_fast_assign(
> __entry->ctx = ctx;
> - __entry->rw = rw;
> + __entry->rw = rw;
> __entry->req = req;
> __entry->work = work;
> __entry->flags = flags;
> @@ -196,10 +196,10 @@ TRACE_EVENT(io_uring_defer,
>
> /**
> * io_uring_link - called before the io_uring request added into link_list of
> - * another request
> + * another request
> *
> - * @ctx: pointer to a ring context structure
> - * @req: pointer to a linked request
> + * @ctx: pointer to a ring context structure
> + * @req: pointer to a linked request
> * @target_req: pointer to a previous request, that would contain @req
> *
> * Allows to track linked requests, to understand dependencies between requests
> @@ -212,8 +212,8 @@ TRACE_EVENT(io_uring_link,
> TP_ARGS(ctx, req, target_req),
>
> TP_STRUCT__entry (
> - __field( void *, ctx )
> - __field( void *, req )
> + __field( void *, ctx )
> + __field( void *, req )
> __field( void *, target_req )
> ),
>
> @@ -244,7 +244,7 @@ TRACE_EVENT(io_uring_cqring_wait,
> TP_ARGS(ctx, min_events),
>
> TP_STRUCT__entry (
> - __field( void *, ctx )
> + __field( void *, ctx )
> __field( int, min_events )
> ),
>
> @@ -272,7 +272,7 @@ TRACE_EVENT(io_uring_fail_link,
> TP_ARGS(req, link),
>
> TP_STRUCT__entry (
> - __field( void *, req )
> + __field( void *, req )
> __field( void *, link )
> ),
>
> @@ -318,7 +318,6 @@ TRACE_EVENT(io_uring_complete,
> __entry->res, __entry->cflags)
> );
>
> -
> /**
> * io_uring_submit_sqe - called before submitting one SQE
> *
>
--
Pavel Begunkov
On 6/15/21 3:48 AM, Pavel Begunkov wrote:
> On 5/31/21 7:54 AM, Olivier Langlois wrote:
>> Fix tabulation to make nice columns
>
> Reviewed-by: Pavel Begunkov <[email protected]>
I don't have any of the original 1-3 patches, and don't see them on the
list either. I'd love to apply for 5.14, but...
Olivier, are you getting any errors sending these out? Usually I'd expect
them in my inbox as well outside of the list, but they don't seem to have
arrived there either.
In any case, please resend. As Pavel mentioned, a cover letter is always
a good idea for a series of more than one patch.
--
Jens Axboe
On Tue, 15 Jun 2021 15:50:29 -0600
Jens Axboe <[email protected]> wrote:
> On 6/15/21 3:48 AM, Pavel Begunkov wrote:
> > On 5/31/21 7:54 AM, Olivier Langlois wrote:
> >> Fix tabulation to make nice columns
> >
> > Reviewed-by: Pavel Begunkov <[email protected]>
>
> I don't have any of the original 1-3 patches, and don't see them on the
> list either. I'd love to apply for 5.14, but...
>
> Olivier, are you getting any errors sending these out? Usually I'd expect
> them in my inbox as well outside of the list, but they don't seem to have
> arrived there either.
>
> In any case, please resend. As Pavel mentioned, a cover letter is always
> a good idea for a series of more than one patch.
>
I found them in my inbox, but for some reason, none of them have a
Message-id tag, which explains why the replies don't follow them nor can
you find them in any mailing list.
-- Steve
On 6/15/21 5:35 PM, Steven Rostedt wrote:
> On Tue, 15 Jun 2021 15:50:29 -0600
> Jens Axboe <[email protected]> wrote:
>
>> On 6/15/21 3:48 AM, Pavel Begunkov wrote:
>>> On 5/31/21 7:54 AM, Olivier Langlois wrote:
>>>> Fix tabulation to make nice columns
>>>
>>> Reviewed-by: Pavel Begunkov <[email protected]>
>>
>> I don't have any of the original 1-3 patches, and don't see them on the
>> list either. I'd love to apply for 5.14, but...
>>
>> Olivier, are you getting any errors sending these out? Usually I'd expect
>> them in my inbox as well outside of the list, but they don't seem to have
>> arrived there either.
>>
>> In any case, please resend. As Pavel mentioned, a cover letter is always
>> a good idea for a series of more than one patch.
>>
>
> I found them in my inbox, but for some reason, none of them have a
> Message-id tag, which explains why the replies don't follow them nor can
> you find them in any mailing list.
Indeed, that is what is causing the situation, and I do have them here.
Olivier, you definitely want to fix your mail setup. It confuses both
MUAs, but it also actively prevents using the regular tooling to pull
these patches off lore for example.
--
Jens Axboe
On Tue, 2021-06-15 at 15:50 -0600, Jens Axboe wrote:
> On 6/15/21 3:48 AM, Pavel Begunkov wrote:
> > On 5/31/21 7:54 AM, Olivier Langlois wrote:
> > > Fix tabulation to make nice columns
> >
> > Reviewed-by: Pavel Begunkov <[email protected]>
>
> I don't have any of the original 1-3 patches, and don't see them on the
> list either. I'd love to apply for 5.14, but...
>
> Olivier, are you getting any errors sending these out?Usually I'd
> expect
> them in my inbox as well outside of the list, but they don't seem to
> have
> arrived there either.
>
> In any case, please resend. As Pavel mentioned, a cover letter is
> always
> a good idea for a series of more than one patch.
>
I do not get any errors but I have noticed too that my emails weren't
accepted by the lists.
They will accept replies in already existing threads but they won't let
me create new ones. ie: accepting my patches.
I'll learn how create a cover email and I will resend the series of
patches later today.
one thing that I can tell, it is that Pavel and you are always
recipients along with the lists for my patches... So you should have a
private copy somewhere in your mailbox...
The other day, I even got this:
-------- Forwarded Message --------
From: Mail Delivery System <[email protected]>
To: [email protected]
Subject: Mail delivery failed: returning message to sender
Date: Thu, 10 Jun 2021 11:38:51 -0400
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es)
failed:
[email protected]
host vger.kernel.org [23.128.96.18]
SMTP error from remote mail server after end of data:
550 5.7.1 Content-Policy accept-into-freezer-1 msg:
Bayes Statistical Bogofilter considers this message SPAM. BF:<S
0.9924> In case you disagree, send the ENTIRE message plus this error
message to <[email protected]> ; S230153AbhFJPkq
[email protected]
host vger.kernel.org [23.128.96.18]
SMTP error from remote mail server after end of data:
550 5.7.1 Content-Policy accept-into-freezer-1 msg:
Bayes Statistical Bogofilter considers this message SPAM. BF:<S
0.9924> In case you disagree, send the ENTIRE message plus this error
message to <[email protected]> ; S230153AbhFJPkq
There is definitely something that the list software doesn't like in my
emails but I don't know what...
I did send an email to [email protected] to tell them about
the problem but I didn't hear back anything from the postmaster... (My
email probably went to the SPAM folder as well!)
On Wed, 16 Jun 2021 09:33:18 -0400
Olivier Langlois <[email protected]> wrote:
> I do not get any errors but I have noticed too that my emails weren't
> accepted by the lists.
>
> They will accept replies in already existing threads but they won't let
> me create new ones. ie: accepting my patches.
How are you sending your patches? The patches that were rejected, did not
have the "Message-ID:" tag in the header. If you look at my email (and
yours that I'm replying to now) you'll see something like this:
Message-ID: <[email protected]>
(that's from the email I'm replying to).
All emails are suppose to have this tag. This is what is used to map
replies in a way that your email client can see what email is replying to
which email. Again, from your email:
In-Reply-To: <[email protected]>
That's because the email you replied to had:
Message-ID: <[email protected]>
This is also used for mail archives, as message ids are used to
differentiate emails from each other. But if the Message-ID is missing, the
archives have no idea to map it.
I'm guessing that the mailing lists also flag any email that is missing a
Message-ID as spam.
Thus, you should find out what is wrong with your client software that is
sending out the patches, and see why it's not including the Message-ID.
-- Steve
On 6/16/21 2:33 PM, Olivier Langlois wrote:
> On Tue, 2021-06-15 at 15:50 -0600, Jens Axboe wrote:
>> On 6/15/21 3:48 AM, Pavel Begunkov wrote:
>>> On 5/31/21 7:54 AM, Olivier Langlois wrote:
>>>> Fix tabulation to make nice columns
>>>
>>> Reviewed-by: Pavel Begunkov <[email protected]>
>>
>> I don't have any of the original 1-3 patches, and don't see them on the
>> list either. I'd love to apply for 5.14, but...
>>
>> Olivier, are you getting any errors sending these out?Usually I'd
>> expect
>> them in my inbox as well outside of the list, but they don't seem to
>> have
>> arrived there either.
>>
>> In any case, please resend. As Pavel mentioned, a cover letter is
>> always
>> a good idea for a series of more than one patch.
>>
> I do not get any errors but I have noticed too that my emails weren't
> accepted by the lists.
>
> They will accept replies in already existing threads but they won't let
> me create new ones. ie: accepting my patches.
>
> I'll learn how create a cover email and I will resend the series of
> patches later today.
"--cover-letter" to "git format-patch" will create a cover template
to fill in. Depends on patches, but can be a small description of the
series.
Regarding resending, Jens already took/applied them today, see
a reply to 1/3. You can find them queued at
https://git.kernel.dk/cgit/linux-block/log/?h=for-5.14/io_uring
> one thing that I can tell, it is that Pavel and you are always
> recipients along with the lists for my patches... So you should have a
> private copy somewhere in your mailbox...
>
> The other day, I even got this:
> -------- Forwarded Message --------
> From: Mail Delivery System <[email protected]>
> To: [email protected]
> Subject: Mail delivery failed: returning message to sender
> Date: Thu, 10 Jun 2021 11:38:51 -0400
>
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es)
> failed:
>
> [email protected]
> host vger.kernel.org [23.128.96.18]
> SMTP error from remote mail server after end of data:
> 550 5.7.1 Content-Policy accept-into-freezer-1 msg:
> Bayes Statistical Bogofilter considers this message SPAM. BF:<S
> 0.9924> In case you disagree, send the ENTIRE message plus this error
> message to <[email protected]> ; S230153AbhFJPkq
> [email protected]
> host vger.kernel.org [23.128.96.18]
> SMTP error from remote mail server after end of data:
> 550 5.7.1 Content-Policy accept-into-freezer-1 msg:
> Bayes Statistical Bogofilter considers this message SPAM. BF:<S
> 0.9924> In case you disagree, send the ENTIRE message plus this error
> message to <[email protected]> ; S230153AbhFJPkq
>
> There is definitely something that the list software doesn't like in my
> emails but I don't know what...
>
> I did send an email to [email protected] to tell them about
> the problem but I didn't hear back anything from the postmaster... (My
> email probably went to the SPAM folder as well!)
>
--
Pavel Begunkov
On Wed, 2021-06-16 at 06:49 -0600, Jens Axboe wrote:
>
> Indeed, that is what is causing the situation, and I do have them
> here.
> Olivier, you definitely want to fix your mail setup. It confuses both
> MUAs, but it also actively prevents using the regular tooling to pull
> these patches off lore for example.
>
Ok, I will... It seems that only my patch emails are having this issue.
I am pretty sure that I can find instances of non patch emails going
making it to the lists...
On 6/16/21 1:00 PM, Olivier Langlois wrote:
> On Wed, 2021-06-16 at 06:49 -0600, Jens Axboe wrote:
>>
>> Indeed, that is what is causing the situation, and I do have them
>> here.
>> Olivier, you definitely want to fix your mail setup. It confuses both
>> MUAs, but it also actively prevents using the regular tooling to pull
>> these patches off lore for example.
>>
> Ok, I will... It seems that only my patch emails are having this issue.
> I am pretty sure that I can find instances of non patch emails going
> making it to the lists...
The problem is that even if they do make it to the list, you can't
use eg b4 to pull them off the list.
--
Jens Axboe