All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Yang <richard.weiyang@gmail.com>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Wei Yang <richard.weiyang@gmail.com>,
	akpm@linux-foundation.org, Liam.Howlett@oracle.com,
	vbabka@suse.cz, jannh@google.com, linux-mm@kvack.org
Subject: Re: [PATCH 0/2] vma: fix unmapped_area()
Date: Tue, 28 Jan 2025 01:56:19 +0000	[thread overview]
Message-ID: <20250128015619.w3rl2dcbdg2f43xd@master> (raw)
In-Reply-To: <2b7d4b72-5628-44d7-8e6c-2c8945b805d6@lucifer.local>

On Mon, Jan 27, 2025 at 10:50:17AM +0000, Lorenzo Stoakes wrote:
>Hi Wei,
>
>I seem to recall us having a very recent converation about holding off on
>patches like these for a little while to which you agreed, and then you
>sent this pretty much the very next day? And during the merge window?
>Honestly not _hugely_ impressed with that.
>

Yes I remember your suggestion. I send this because it is a bug fix to me. 
Per my understanding on your word, it is ok to send a fix.

If I misunderstand, I apologize.

>In my view this patch should have instead started as a query to Liam about
>the gap calculation, this would have been far more civil and would have
>allowed us to determine for sure if the approach you've taken here is
>valid.
>

You are right. I will try to be better next time.

As you mentioned a query before sending a patch, this is preferred, right?
Hope I don't mess this again.

>Given your history of sending entirely trivial patches which we keep asking
>you not to send (mixed in with the occasional actually useful patch) it is
>KEY to communicate to ensure we're on the same page.
>
>If you send meaningful commits, we want to merge them. Arbitrarily sending
>something like this, at this point in time, when you've been asked not to -
>does not help achieve this aim.
>

Thanks, I would be more considerate next time.

>On Mon, Jan 27, 2025 at 07:55:25AM +0000, Wei Yang wrote:
>> The gap check in unmapped_area() seems not correct.
>>
>> Add test cases to verify the behavior.
>
>This is an -entirely- unacceptable cover letter. It's two lines dude. Give
>some details. You're actually tackling a very, very specific aspect and
>scenario in some of the most sensitive code in all of mm.
>
>You really, really need to be clear on what it is you're doing, why, what
>workload you were doing to hit this, what testing you've done, what real
>life things this interacts with etc. etc.
>
>It makes our lives easier as maintainers. Right now I see this as 'another
>trivial Wei patch', you need to provide details to prove otherwise, if that
>is indeed, not the case.
>
>Also your subject line here is horrible - 'fix unmapped_area()' - actually
>you seem to be (in your view) correcting the calculation with respect to
>upward-growing stacks. Correct me if I'm wrong. I mean even your patch 1/2
>has a better message... It needs to be more specific to what you're doing.
>

Thanks to you and Liam. I will try to do better to not waste your time.

>>
>> Wei Yang (2):
>>   mm/vma: fix gap check for unmapped_area with VM_GROWSDOWN
>>   tools: testing: add unmapped_area() tests
>>
>>  mm/vma.c                         |   2 +-
>>  tools/testing/vma/vma.c          | 177 +++++++++++++++++++++++++++++++
>>  tools/testing/vma/vma_internal.h |   2 +-
>>  3 files changed, 179 insertions(+), 2 deletions(-)
>>
>> --
>> 2.34.1
>>
>>

-- 
Wei Yang
Help you, Help me


  reply	other threads:[~2025-01-28  1:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-27  7:55 [PATCH 0/2] vma: fix unmapped_area() Wei Yang
2025-01-27  7:55 ` [PATCH 1/2] mm/vma: fix gap check for unmapped_area with VM_GROWSDOWN Wei Yang
2025-01-27 12:08   ` Lorenzo Stoakes
2025-01-28  3:30     ` Wei Yang
2025-01-28  6:32       ` Lorenzo Stoakes
2025-01-27  7:55 ` [PATCH 2/2] tools: testing: add unmapped_area() tests Wei Yang
2025-01-27 12:26   ` Lorenzo Stoakes
2025-01-27 10:50 ` [PATCH 0/2] vma: fix unmapped_area() Lorenzo Stoakes
2025-01-28  1:56   ` Wei Yang [this message]
2025-01-28  6:38     ` Lorenzo Stoakes
2025-01-27 14:19 ` Liam R. Howlett
2025-01-28  2:00   ` Wei Yang

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=20250128015619.w3rl2dcbdg2f43xd@master \
    --to=richard.weiyang@gmail.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=jannh@google.com \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.