[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEVpBa+r6AuB7hnCnTm8YKHzaj172q7Wy89yT=P_F6GQG-3-1A@mail.gmail.com>
Date: Thu, 14 May 2015 19:50:30 +0100
From: Mark Williamson <mwilliamson@...o-software.com>
To: Konstantin Khlebnikov <khlebnikov@...dex-team.ru>
Cc: linux-mm@...ck.org, Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
kernel list <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Pavel Emelyanov <xemul@...allels.com>,
Linux API <linux-api@...r.kernel.org>,
Andy Lutomirski <luto@...capital.net>,
Vlastimil Babka <vbabka@...e.cz>, Pavel Machek <pavel@....cz>,
Mark Seaborn <mseaborn@...omium.org>,
"Kirill A. Shutemov" <kirill@...temov.name>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Daniel James <djames@...o-software.com>,
Finn Grimwood <fgrimwood@...o-software.com>
Subject: Re: [PATCH v2 1/3] pagemap: add mmap-exclusive bit for marking pages
mapped only here
Hi Konstantin,
On Wed, May 13, 2015 at 11:51 AM, Konstantin Khlebnikov
<khlebnikov@...dex-team.ru> wrote:
> On 12.05.2015 15:05, Mark Williamson wrote:
<snip>
>> 1. I was hoping we'd be able to backport a compatible fix to older
>> kernels that might adopt the pagemap permissions change. Using the V2
>> format flags rules out doing this for kernels that are too old to have
>> soft-dirty, I think.
>>
>> 2. From our software's PoV, I feel it's worth noting that it doesn't
>> strictly fix ABI compatibility, though I realise that's probably not
>> your primary concern here. We'll need to modify our code to write the
>> clear_refs file but that change is OK for us if it's the preferred
>> solution.
<snip>
> I prefer to backport v2 format (except soft-dirty bit and clear_refs)
> into older kernels. Page-shift bits are barely used so nobody will see
> the difference.
My concern was whether a change to format would be acceptable to
include in the various -stable kernels; they are already including the
additional protections on pagemap, so we're starting to need our
fallback mode in distributions. Do you think that such a patch would
be acceptable there?
(As an application vendor we're likely to be particularly stuck with
what the commercial distributions decide to ship, which is why I'm
trying to keep an eye on this)
I appreciate that this is a slightly administrative concern! I
definitely like the technical approach of this code and it seems to
work fine for us.
Thanks,
Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists