[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPcyv4jEmdfAz8foEUtDw4GEm2-+7J-4GULZ=6tCD+9K5CFzRw@mail.gmail.com>
Date: Tue, 8 Dec 2020 15:40:52 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: "Darrick J. Wong" <darrick.wong@...cle.com>
Cc: Matthew Wilcox <willy@...radead.org>,
Ira Weiny <ira.weiny@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Dave Hansen <dave.hansen@...el.com>,
Christoph Hellwig <hch@...radead.org>,
Al Viro <viro@...iv.linux.org.uk>,
Eric Biggers <ebiggers@...nel.org>,
Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH V2 2/2] mm/highmem: Lift memcpy_[to|from]_page to core
On Tue, Dec 8, 2020 at 2:49 PM Darrick J. Wong <darrick.wong@...cle.com> wrote:
[..]
> > So what's your preferred poison?
> >
> > 1. Corrupt random data in whatever's been mapped into the next page (which
> > is what the helpers currently do)
>
> Please no.
My assertion is that the kernel can't know it's corruption, it can
only know that the driver is abusing the API. So over-copy and WARN
seems better than violently regress by crashing what might have been
working silently before.
Powered by blists - more mailing lists