Re: [PATCH v2 2/3] io_uring: minor clean up in trace events definition

Re: [PATCH v2 2/3] io_uring: minor clean up in trace events definition

[Pavel Begunkov]

On 5/31/21 7:54 AM, Olivier Langlois wrote:
> Fix tabulation to make nice columns

Reviewed-by: Pavel Begunkov <asml.silence@gmail.com>

> 
> Signed-off-by: Olivier Langlois <olivier@trillion01.com>
> ---
>  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

Re: [PATCH v2 2/3] io_uring: minor clean up in trace events definition

[Jens Axboe]

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 <asml.silence@gmail.com>

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

Re: [PATCH v2 2/3] io_uring: minor clean up in trace events definition

[Steven Rostedt]

On Tue, 15 Jun 2021 15:50:29 -0600
Jens Axboe <axboe@kernel.dk> 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 <asml.silence@gmail.com>  
> 
> 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

Re: [PATCH v2 2/3] io_uring: minor clean up in trace events definition

[Jens Axboe]

On 6/15/21 5:35 PM, Steven Rostedt wrote:
> On Tue, 15 Jun 2021 15:50:29 -0600
> Jens Axboe <axboe@kernel.dk> 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 <asml.silence@gmail.com>  
>>
>> 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

Re: [PATCH v2 2/3] io_uring: minor clean up in trace events definition

[Olivier Langlois]

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 <asml.silence@gmail.com>
> 
> 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 <Mailer-Daemon@cloud48395.mywhc.ca>
To: olivier@trillion01.com
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:

  linux-kernel@vger.kernel.org
    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 <postmaster@vger.kernel.org> ; S230153AbhFJPkq
  io-uring@vger.kernel.org
    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 <postmaster@vger.kernel.org> ; 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 postmaster@vger.kernel.org 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!)

Re: [PATCH v2 2/3] io_uring: minor clean up in trace events definition

[Steven Rostedt]

On Wed, 16 Jun 2021 09:33:18 -0400
Olivier Langlois <olivier@trillion01.com> 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: <f3cf3dc047dcee400423f526c1fe31510c5bcf61.camel@trillion01.com>

(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: <def5421f-a3ae-12fd-87a2-6e584f753127@kernel.dk>

That's because the email you replied to had:

 Message-ID: <def5421f-a3ae-12fd-87a2-6e584f753127@kernel.dk>

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

Re: [PATCH v2 2/3] io_uring: minor clean up in trace events definition

[Pavel Begunkov]

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 <asml.silence@gmail.com>
>>
>> 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 <Mailer-Daemon@cloud48395.mywhc.ca>
> To: olivier@trillion01.com
> 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:
> 
>   linux-kernel@vger.kernel.org
>     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 <postmaster@vger.kernel.org> ; S230153AbhFJPkq
>   io-uring@vger.kernel.org
>     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 <postmaster@vger.kernel.org> ; 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 postmaster@vger.kernel.org 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

Re: [PATCH v2 2/3] io_uring: minor clean up in trace events definition

[Olivier Langlois]

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

Re: [PATCH v2 2/3] io_uring: minor clean up in trace events definition

[Jens Axboe]

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

Re: [PATCH v2 2/3] io_uring: minor clean up in trace events definition

[Olivier Langlois]

On Wed, 2021-06-16 at 13:02 -0600, Jens Axboe wrote:
> 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,

I am unfamiliar with the regular tooling and eg b4 (which I assume are
part of the regular tooling) so I am not fully understanding everything
you say.

My take away from all this is that it is very important that my patches
do reach the lists and I commit to put the necessary efforts to make
that happen.

My last email was simply myself starting diagnose where my problem
could be outloud.

Steven did mention that he wasn't seeing the Message-Id field in my
patch emails. I'm very grateful for this clue!

My main email client is Gnome Evolution (when Message-Id is present in
my mails) and I do the following to send out patches:

1. git format-patch -o ~/patches HEAD^
2. Edit patch file by adding recipients listed by
scripts/get_maintainer.pl
3. cat patch_file | msmtp -t -a default

The weird thing is that when I have noticed that my patches weren't
making it to the lists, I started to Cc myself to receive a copy of the
patch. When I inspect the copy header, it contains the Message-Id field
but it might be the receiving email client that on reception does add
the missing field so I don't know exactly what is happening.

you have my word. Next patch I send, it will be make it to the lists.

thx a lot for your comprehension and your assistance!
Olivier

Re: [PATCH v2 2/3] io_uring: minor clean up in trace events definition

[Jens Axboe]

On 6/16/21 3:30 PM, Olivier Langlois wrote:
> On Wed, 2021-06-16 at 13:02 -0600, Jens Axboe wrote:
>> 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,
> 
> I am unfamiliar with the regular tooling and eg b4 (which I assume are
> part of the regular tooling) so I am not fully understanding everything
> you say.

Sorry, I could have been more clear. b4 is a tool that pulls patches off
lists managed by lore.kernel.org, and I use it quite often to avoid
manually saving emails and applying. It'll collect reviews etc as well,
and I integrate it with git. That means, if you send a patchset of 3
patches with a cover letter, if I like the series I just do:

$ git b4 <message id of cover>

and it applies it for me, adding links, reviews, etc.

> My take away from all this is that it is very important that my patches
> do reach the lists and I commit to put the necessary efforts to make
> that happen.

Yes. Both for tooling, but also so that non-cc'ed people see it and can
reply.

> My last email was simply myself starting diagnose where my problem
> could be outloud.
> 
> Steven did mention that he wasn't seeing the Message-Id field in my
> patch emails. I'm very grateful for this clue!
> 
> My main email client is Gnome Evolution (when Message-Id is present in
> my mails) and I do the following to send out patches:
> 
> 1. git format-patch -o ~/patches HEAD^
> 2. Edit patch file by adding recipients listed by
> scripts/get_maintainer.pl
> 3. cat patch_file | msmtp -t -a default

Why not just use git send-email? That's literally what that is for. It's
what I use to send out patches.

> The weird thing is that when I have noticed that my patches weren't
> making it to the lists, I started to Cc myself to receive a copy of the
> patch. When I inspect the copy header, it contains the Message-Id field
> but it might be the receiving email client that on reception does add
> the missing field so I don't know exactly what is happening.
> 
> you have my word. Next patch I send, it will be make it to the lists.
> 
> thx a lot for your comprehension and your assistance!

Thanks for sending out patches!

-- 
Jens Axboe

Re: [PATCH v2 2/3] io_uring: minor clean up in trace events definition

[Olivier Langlois]

On Wed, 2021-06-16 at 15:33 -0600, Jens Axboe wrote:
> On 6/16/21 3:30 PM, Olivier Langlois wrote:
> > 
> 
> > My take away from all this is that it is very important that my
> > patches
> > do reach the lists and I commit to put the necessary efforts to
> > make
> > that happen.
> 
> Yes. Both for tooling, but also so that non-cc'ed people see it and
> can
> reply.
> 
> > My last email was simply myself starting diagnose where my problem
> > could be outloud.
> > 
> > Steven did mention that he wasn't seeing the Message-Id field in my
> > patch emails. I'm very grateful for this clue!
> > 
> > My main email client is Gnome Evolution (when Message-Id is present
> > in
> > my mails) and I do the following to send out patches:
> > 
> > 1. git format-patch -o ~/patches HEAD^
> > 2. Edit patch file by adding recipients listed by
> > scripts/get_maintainer.pl
> > 3. cat patch_file | msmtp -t -a default
> 
> Why not just use git send-email? That's literally what that is for.
> It's
> what I use to send out patches.
> 
> 
> 
I found my problem. I had to add the option --thread to git format-
patch

as in:
$ git format-patch --thread -o ~/patches HEAD^

Re: [PATCH v2 2/3] io_uring: minor clean up in trace events definition

[Pavel Begunkov]

On 6/20/21 8:15 PM, Olivier Langlois wrote:
>>
> I found my problem. I had to add the option --thread to git format-
> patch
> 
> as in:
> $ git format-patch --thread -o ~/patches HEAD^

fwiw, was always using

$ git format-patch -n --thread=shallow --subject-prefix "PATCH" -o <path> --cover-letter HEAD~N..HEAD~0

without --cover-letter if a single patch

-- 
Pavel Begunkov