linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: John Hubbard <jhubbard@nvidia.com>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Pedro Falcato <pedro.falcato@gmail.com>,
	Christian Brauner <christian@brauner.io>,
	Shuah Khan <shuah@kernel.org>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>,
	Suren Baghdasaryan <surenb@google.com>,
	"Vlastimil Babka" <vbabka@suse.cz>,
	<linux-kselftest@vger.kernel.org>, <linux-mm@kvack.org>,
	<linux-fsdevel@vger.kernel.org>, <linux-api@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	Oliver Sang <oliver.sang@intel.com>
Subject: Re: [PATCH v5 2/5] pidfd: add PIDFD_SELF_* sentinels to refer to own thread/process
Date: Fri, 25 Oct 2024 14:51:29 -0700	[thread overview]
Message-ID: <330c0dae-fa8a-49e5-94b4-25b915f74e37@nvidia.com> (raw)
In-Reply-To: <239456b7-4045-46cd-a2e7-8445dd6640c6@lucifer.local>

On 10/25/24 2:09 PM, Lorenzo Stoakes wrote:
> On Fri, Oct 25, 2024 at 01:31:49PM -0700, John Hubbard wrote:
>> On 10/25/24 12:49 PM, Lorenzo Stoakes wrote:
>>> On Fri, Oct 25, 2024 at 11:44:34AM -0700, John Hubbard wrote:
>>>> On 10/25/24 11:38 AM, Pedro Falcato wrote:
>>>>> On Fri, Oct 25, 2024 at 6:41 PM John Hubbard <jhubbard@nvidia.com> wrote:
>> ...
>> I'll admit to being easily cowed by "you're breaking userspace" arguments.
>> Even when they start to get rather absurd. Because I can't easily tell where
>> the line is.
>>
>> Maybe "-std=c89 -pedantic" is on the other side of the line. I'd like it
>> to be! :)
> 
> Well, apparently not...

Why not? Your arguments are clear and reasonable. Why shouldn't they prevail?

Please don't think that I have some sort of firm position here. I'm simply
looking for the right answer. And if that's different than something I
proposed earlier, no problem. The best answer should win.

...
>>> The bike shed should be blue! Wait no no, it should be red... Hang on
>>> yellow yes! Yellow's great!
>>
>> Putting a header in the right location, so as to avoid breakage here or
>> there, is not bikeshedding. Sorry.
> 
> There are 312 uses of "static inline" already in UAPI headers, not all
> quite as obscure as claimed.
> 

OK, good. Let's lead with that. It seems very clear, then, that a new one
won't cause a problem.

> Specifically requiring me and only me to support ansi C89 for a theorised
> scenario is in my opinion bikeshedding, but I don't want to get into an
> argument about something so petty :)

An argument about the definition of bikeshedding sounds delightfully
recursive, but yes, let's not. :)

...
>>> ANyway if you guys feel strong enough about this, I'll respin again and
>>> just open-code this trivial check where it's used.
>>
>> No strong feelings, just hoping to help make a choice that gets you
>> closer to getting your patches committed.
> 
> I mean, you are saying I am breaking things and implying the series is
> blocked on this, that sounds like a strong opinion, but again I'm not going
> to argue.

Actually, Pedro's request kicked this off, and I was hoping to dismiss
it--again, in order to help move things along. My opinion is that we
should shun ancient toolchains and ancient systems whenever possible.

Somehow that got turned into "I'm trying to block the patchset". Really,
whatever works, follows The Rules (whatever we eventually understand
them to be), and doesn't cause someone *else* to come out of the
woodwork and claim a problem, is fine with me.

> 
> As with the requirement that I, only for my part of the change, must fix up
> test header import, while I disagree I should be doing the fix, I did it
> anyway as I am accommodating and reasonable.

I agree that pre-existing problems in selftests should not be your
problem.

By the way, I'm occasionally involved in helping fix up various
selftest-related problems, especially when they impact mm. Send me a
note if you have anything in mind that ought to be fixed up, I might be
able to help head off future grief in that area.

> 
> So fine - I'll respin and just open-code this as it's trivial and there's
> no (other) sensible place to put it anyway.
> 
> A P.S. though - a very NOT theoretical issue with userspace is the import
> of linux/fcntl.h in pidfd.h which seems to me to have been imported solely
> for the kernel's sake.
> 
> A gentle suggestion (it seems I can't win - gentle suggestions are ignored,
> tongue-in-cheek parody is taken to be mean... but anyway) is to do

Actually, these come across as sarcasm, especially in the context of
these emails that show you are becoming quite distraught.

I've met you several times at the conferences. We get along well. And
your work is top notch. So please consider that I'm very much supportive
of you and your work here.

I'm still trying to understand why you are recently sending these very
strong emails (Vlastimil also took some heat), but I see that you also
mentioned some long hours.

If my feedback is making things worse here, I'll try to adjust.
Selftests in general are a frustrating area.


thanks,
-- 
John Hubbard


> something like:
> 
> #ifdef __KERNEL__
> #include <linux/fcntl.h>
> #else
> #include <fcntl.h>
> #endif
> 
> At the top of the pidfd.h header. This must surely sting a _lot_ of people
> in userland otherwise.
> 
> But this is out of scope for this change.



  reply	other threads:[~2024-10-25 21:51 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-25  9:41 [PATCH v5 0/5] introduce PIDFD_SELF* sentinels Lorenzo Stoakes
2024-10-25  9:41 ` [PATCH v5 1/5] pidfd: extend pidfd_get_pid() and de-duplicate pid lookup Lorenzo Stoakes
2024-10-25  9:41 ` [PATCH v5 2/5] pidfd: add PIDFD_SELF_* sentinels to refer to own thread/process Lorenzo Stoakes
2024-10-25 12:50   ` Pedro Falcato
2024-10-25 13:08     ` Lorenzo Stoakes
2024-10-25 17:41     ` John Hubbard
2024-10-25 18:38       ` Pedro Falcato
2024-10-25 18:44         ` John Hubbard
2024-10-25 19:49           ` Lorenzo Stoakes
2024-10-25 20:31             ` John Hubbard
2024-10-25 21:09               ` Lorenzo Stoakes
2024-10-25 21:51                 ` John Hubbard [this message]
2024-10-25 22:17                   ` Lorenzo Stoakes
2024-10-25  9:41 ` [PATCH v5 3/5] tools: testing: separate out wait_for_pid() into helper header Lorenzo Stoakes
2024-10-25  9:41 ` [PATCH v5 4/5] selftests: pidfd: add pidfd.h UAPI wrapper Lorenzo Stoakes
2024-10-25  9:41 ` [PATCH v5 5/5] selftests: pidfd: add tests for PIDFD_SELF_* Lorenzo Stoakes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=330c0dae-fa8a-49e5-94b4-25b915f74e37@nvidia.com \
    --to=jhubbard@nvidia.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=christian@brauner.io \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=oliver.sang@intel.com \
    --cc=pedro.falcato@gmail.com \
    --cc=shuah@kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox