archive mirror
 help / color / mirror / Atom feed
From: Laurent Cremmer <>
To: Mike Kravetz <>
Cc: Oscar Salvador <>,
	Andrew Morton <>,
	 Mina Almasry <>,
	David Rientjes <>,,  Shuah Khan <>
Subject: Re: [PATCH] hugetlb: fix locking in region_add,region_cgh,allocate_file_region_entries
Date: Tue, 27 Oct 2020 08:34:14 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

> On 10/23/20 5:11 AM, Oscar Salvador wrote:
> > On Fri, Oct 23, 2020 at 01:32:54PM +0200, Laurent Cremmer wrote:
> >> I came to the same conclusion with the help of David's remarks :-) .
> >> And in the end, this patch would be more about fixing the readability
> >> of the code than fixing a live problem per-se. If it ain't broken,
> >> don't fix it as they say :-)
> >
> > Yeah, definitely the code could benefit from a cleanup, so no one
> > has to stare at it for a while before he gets the idea.
> INDEED, those *region* routines dealing with reservation maps are difficult
> to understand, and could benefit from some cleanup.  Recent changes to add
> support for reservation cgroup support made them even more complex.
> Laurent, thank you for taking the time to look into this.  And thanks to
> Oscar and David for their analysis.  The suggested patch would make the
> code more readable.  However, that would be at the expense of another
> (and unnecessary) lock/unlock cycle.  I'll add cleanup of these routines
> to my 'todo' list, but would be happy to work with anyone else who wants
> to take on this task.
> --

Hi Mike,

I gave it a deeper look (although  I'm not familiar enough with the
whole subsystem to
really qualify!) and could not come up with an easy  "way" out.
In the end it might depend on how often the error path is taken and if
the unnecessary
lock/unlock cycle does really hurt under pressure.
What really tripped me (and smatch) is the erroneous "
annotation of the allocate_file_region_entries function.
It would be better suited to the function above (add_reservation_in_range).

If you think that adding documentation would be helpful, I can do that.

In any case, thanks for taking the time to review and consider adding to your
todo list. much appreciated.


  reply	other threads:[~2020-10-27  7:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-23  7:47 [PATCH] hugetlb: fix locking in region_add,region_cgh,allocate_file_region_entries Laurent Cremmer
2020-10-23 10:12 ` David Hildenbrand
2020-10-23 11:25   ` Laurent Cremmer
2020-10-23 11:39     ` David Hildenbrand
2020-10-23 11:02 ` Oscar Salvador
2020-10-23 11:32   ` Laurent Cremmer
2020-10-23 12:11     ` Oscar Salvador
2020-10-23 16:47       ` Mike Kravetz
2020-10-27  7:34         ` Laurent Cremmer [this message]
2020-10-28 19:18 ` Mina Almasry

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).