mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nadav Amit <namit@vmware.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Nadia Yvette Chambers <nyc@holomorphy.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Eric Biggers <ebiggers3@gmail.com>
Subject: Re: [PATCH] hugetlbfs: change put_page/unlock_page order in hugetlbfs_fallocate()
Date: Sun, 27 Aug 2017 20:08:58 +0000	[thread overview]
Message-ID: <B2EE58B0-893D-4BA4-88E1-BDE3149E9F81@vmware.com> (raw)
In-Reply-To: <6bf36198-0693-5735-7180-6529aa4c29e4@oracle.com>

Mike Kravetz <mike.kravetz@oracle.com> wrote:

> On 08/26/2017 12:11 PM, Nadav Amit wrote:
>> hugetlfs_fallocate() currently performs put_page() before unlock_page().
>> This scenario opens a small time window, from the time the page is added
>> to the page cache, until it is unlocked, in which the page might be
>> removed from the page-cache by another core. If the page is removed
>> during this time windows, it might cause a memory corruption, as the
>> wrong page will be unlocked.
>> 
>> It is arguable whether this scenario can happen in a real system, and
>> there are several mitigating factors. The issue was found by code
>> inspection (actually grep), and not by actually triggering the flow.
>> Yet, since putting the page before unlocking is incorrect it should be
>> fixed, if only to prevent future breakage or someone copy-pasting this
>> code.
>> 
>> Fixes: 70c3547e36f5c ("hugetlbfs: add hugetlbfs_fallocate()")
>> 
>> cc: Eric Biggers <ebiggers3@gmail.com>
>> cc: Mike Kravetz <mike.kravetz@oracle.com>
>> 
>> Signed-off-by: Nadav Amit <namit@vmware.com>
> 
> Thank you Nadav.

No problem.

> 
> Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
> 
> Since hugetlbfs is an in memory filesystem, the only way one 'should' be
> able to remove a page (file content) is through an inode operation such as
> truncate, hole punch, or unlink.  That was the basis for my response that
> the inode lock would be required for page freeing.
> 
> Eric's question about sys_fadvise64(POSIX_FADV_DONTNEED) is interesting.
> I was expecting to see a check for hugetlbfs pages and exit (without
> modification) if encountered.  A quick review of the code did not find
> any such checks.
> 
> I'll take a closer look to determine exactly how hugetlbfs files are
> handled.  IMO, there should be something similar to the DAX check where
> the routine quickly exits.

I did not cc stable when submitting the patch, based on your previous
response. Let me know if you want me to send v2 which does so.

Thanks,
Nadav

  reply	other threads:[~2017-08-27 20:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <599df681.NreP1dR3/HGSfpCe%akpm@linux-foundation.org>
     [not found] ` <20170824060957.GA29811@dhcp22.suse.cz>
2017-08-25 22:02   ` + mm-madvise-fix-freeing-of-locked-page-with-madv_free.patch added to -mm tree Nadav Amit
2017-08-25 22:31     ` Mike Kravetz
2017-08-25 22:51       ` Nadav Amit
2017-08-25 23:41         ` Mike Kravetz
2017-08-26 21:09           ` Eric Biggers
2017-08-26 19:11             ` [PATCH] hugetlbfs: change put_page/unlock_page order in hugetlbfs_fallocate() Nadav Amit
2017-08-27 17:15               ` Mike Kravetz
2017-08-27 20:08                 ` Nadav Amit [this message]
2017-08-28 17:45                   ` Mike Kravetz
2017-08-28 18:09                     ` Michal Hocko
2017-08-28 18:51                       ` Mike Kravetz
2017-08-28 13:46               ` Michal Hocko
2017-11-29  2:37               ` Eric Biggers
2017-11-29  3:22                 ` Mike Kravetz

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=B2EE58B0-893D-4BA4-88E1-BDE3149E9F81@vmware.com \
    --to=namit@vmware.com \
    --cc=ebiggers3@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike.kravetz@oracle.com \
    --cc=nyc@holomorphy.com \
    /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

all inboxes | Powered by JetHome®