linux-kernel - Re: [PATCH] Revert "mm/vunmap: add cond_resched() in vunmap_pmd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 5 Nov 2020 09:33:54 -0800
From:   Minchan Kim <minchan@...nel.org>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, linux-mm <linux-mm@...ck.org>,
        "Aneesh Kumar K . V" <aneesh.kumar@...ux.ibm.com>,
        Harish Sriram <harish@...ux.ibm.com>, stable@...r.kernel.org
Subject: Re: [PATCH] Revert "mm/vunmap: add cond_resched() in
 vunmap_pmd_range"

On Thu, Nov 05, 2020 at 05:16:02PM +0000, Matthew Wilcox wrote:
> On Thu, Nov 05, 2020 at 09:02:49AM -0800, Minchan Kim wrote:
> > This reverts commit e47110e90584a22e9980510b00d0dfad3a83354e.
> > 
> > While I was doing zram testing, I found sometimes decompression failed
> > since the compression buffer was corrupted. With investigation,
> > I found below commit calls cond_resched unconditionally so it could
> > make a problem in atomic context if the task is reschedule.
> 
> I don't think you're supposed to call unmap_kernel_range() from
> atomic context.  At least vfree() punts to __vfree_deferred() if
> in_interrupt() is true.  I forget the original reason for why that is.

It would be desirable, However, the logic was there for several years
and made regression from the commit in stable kernel for now.

Can't we have graceful shutdown if we want to deprecate the API usecase
in atomic context?