All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: akpm@linux-foundation.org
Cc: kirill.shutemov@linux.intel.com, dave.hansen@intel.com,
	mhocko@suse.com, reinette.chatre@intel.com,
	stable@vger.kernel.org, ying.huang@intel.com,
	mm-commits@vger.kernel.org
Subject: Re: + thp-mm-fix-crash-due-race-in-madv_free-handling.patch added to -mm tree
Date: Fri, 30 Jun 2017 08:36:09 +0900	[thread overview]
Message-ID: <20170629233609.GA24419@bbox> (raw)
In-Reply-To: <595568b4.Or66YmQRVZfA0ulN%akpm@linux-foundation.org>

Hi Andrew,

On Thu, Jun 29, 2017 at 01:53:08PM -0700, akpm@linux-foundation.org wrote:
> 
> The patch titled
>      Subject: thp, mm: fix crash due race in MADV_FREE handling
> has been added to the -mm tree.  Its filename is
>      thp-mm-fix-crash-due-race-in-madv_free-handling.patch
> 
> This patch should soon appear at
>     http://ozlabs.org/~akpm/mmots/broken-out/thp-mm-fix-crash-due-race-in-madv_free-handling.patch
> and later at
>     http://ozlabs.org/~akpm/mmotm/broken-out/thp-mm-fix-crash-due-race-in-madv_free-handling.patch
> 
> Before you just go and hit "reply", please:
>    a) Consider who else should be cc'ed
>    b) Prefer to cc a suitable mailing list as well
>    c) Ideally: find the original patch on the mailing list and do a
>       reply-to-all to that, adding suitable additional cc's
> 
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
> 
> The -mm tree is included into linux-next and is updated
> there every 3-4 working days
> 
> ------------------------------------------------------
> From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
> Subject: thp, mm: fix crash due race in MADV_FREE handling
> 
> Reinette reported following crash:
> 
>   BUG: Bad page state in process log2exe  pfn:57600
>   page:ffffea00015d8000 count:0 mapcount:0 mapping:          (null) index:0x20200
>   flags: 0x4000000000040019(locked|uptodate|dirty|swapbacked)
>   raw: 4000000000040019 0000000000000000 0000000000020200 00000000ffffffff
>   raw: ffffea00015d8020 ffffea00015d8020 0000000000000000 0000000000000000
>   page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
>   bad because of flags: 0x1(locked)
>   Modules linked in: rfcomm 8021q bnep intel_rapl x86_pkg_temp_thermal coretemp efivars btusb btrtl btbcm pwm_lpss_pci snd_hda_codec_hdmi btintel pwm_lpss snd_hda_codec_realtek snd_soc_skl snd_hda_codec_generic snd_soc_skl_ipc spi_pxa2xx_platform snd_soc_sst_ipc snd_soc_sst_dsp i2c_designware_platform i2c_designware_core snd_hda_ext_core snd_soc_sst_match snd_hda_intel snd_hda_codec mei_me snd_hda_core mei snd_soc_rt286 snd_soc_rl6347a snd_soc_core efivarfs
>   CPU: 1 PID: 354 Comm: log2exe Not tainted 4.12.0-rc7-test-test #19
>   Hardware name: Intel corporation NUC6CAYS/NUC6CAYB, BIOS AYAPLCEL.86A.0027.2016.1108.1529 11/08/2016
>   Call Trace:
>    dump_stack+0x95/0xeb
>    bad_page+0x16a/0x1f0
>    free_pages_check_bad+0x117/0x190
>    ? rcu_read_lock_sched_held+0xa8/0x130
>    free_hot_cold_page+0x7b1/0xad0
>    __put_page+0x70/0xa0
>    madvise_free_huge_pmd+0x627/0x7b0
>    madvise_free_pte_range+0x6f8/0x1150
>    ? debug_check_no_locks_freed+0x280/0x280
>    ? swapin_walk_pmd_entry+0x380/0x380
>    __walk_page_range+0x6b5/0xe30
>    walk_page_range+0x13b/0x310
>    madvise_free_page_range.isra.16+0xad/0xd0
>    ? force_swapin_readahead+0x110/0x110
>    ? swapin_walk_pmd_entry+0x380/0x380
>    ? lru_add_drain_cpu+0x160/0x320
>    madvise_free_single_vma+0x2e4/0x470
>    ? madvise_free_page_range.isra.16+0xd0/0xd0
>    ? vmacache_update+0x100/0x130
>    ? find_vma+0x35/0x160
>    SyS_madvise+0x8ce/0x1450
> 
> If somebody frees the page under us and we hold the last reference to
> it, put_page() would attempt to free the page before unlocking it.
> 
> The fix is trivial reorder of operations.
> 
> Dave said:
> 
> : I came up with the exact same patch.  For posterity, here's the test
> : case, generated by syzkaller and trimmed down by Reinette:
> : 
> : 	https://www.sr71.net/~dave/intel/log2.c
> : 
> : And the config that helps detect this:
> : 
> : 	https://www.sr71.net/~dave/intel/config-log2
> 
> Fixes: 9818b8cde622 ("madvise_free, thp: fix madvise_free_huge_pmd return value after splitting")

Bad commit to be fixed is not 9818b8cde622 but b8d3c4c3009d as Kirill sent
again https://marc.info/?l=linux-mm&m=149872564723003&w=2.

Thanks.

      reply	other threads:[~2017-06-29 23:36 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-29 20:53 + thp-mm-fix-crash-due-race-in-madv_free-handling.patch added to -mm tree akpm
2017-06-29 23:36 ` Minchan Kim [this message]

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=20170629233609.GA24419@bbox \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=dave.hansen@intel.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=mhocko@suse.com \
    --cc=mm-commits@vger.kernel.org \
    --cc=reinette.chatre@intel.com \
    --cc=stable@vger.kernel.org \
    --cc=ying.huang@intel.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 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.