linux-kernel - Re: [RFC PATCH 0/4] Support vranges on files

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:	Tue, 09 Apr 2013 15:36:20 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Minchan Kim <minchan@...nel.org>
CC:	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Michael Kerrisk <mtk.manpages@...il.com>,
	Arun Sharma <asharma@...com>, Mel Gorman <mel@....ul.ie>,
	Hugh Dickins <hughd@...gle.com>, Dave Hansen <dave@...1.net>,
	Rik van Riel <riel@...hat.com>, Neil Brown <neilb@...e.de>,
	Mike Hommey <mh@...ndium.org>, Taras Glek <tglek@...illa.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Jason Evans <je@...com>, sanjay@...gle.com,
	Paul Turner <pjt@...gle.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Michel Lespinasse <walken@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH 0/4] Support vranges on files

On 04/08/2013 10:07 PM, Minchan Kim wrote:
> On Mon, Apr 08, 2013 at 08:27:50PM -0700, John Stultz wrote:
>> marked volatile, it should remain volatile until someone who has the
>> file open marks it as non-volatile.  The only time we clear the
>> volatility is when the file is closed by all users.
> Yes. We need it that clear volatile ranges when the file is closed
> by ball users. That's what we need and blow my concern out.

Ok, sorry this wasn't more clear. In all the implementations I've 
pushed, the volatility only persists as long as someone holds the file 
open. Once its closed by all users, the volatility is cleared.

Hopefully that calms your worries here. :)



>> I think the concern about surprising an application that isn't
>> expecting volatility is odd, since if an application jumped in and
>> punched a hole in the data, that could surprise other applications
>> as well.  If you're going to use a file that can be shared,
>> applications have to deal with potential changes to that file by
>> others.
> True. My concern is delayed punching without any client of fd and
> there is no interface to detect some range of file is volatile state or
> not. It means anyone mapped a file with shared could encunter SIGBUS
> although he try to best effort to check it with lsof before using.

I'll grant the SIGBUG semantics create the potential for stranger 
behavior then usual, but I think the use cases are still attractive 
enough to try to make it work.


>> To me, the value in using volatile ranges on the file data is
>> exactly because the file data can be shared. So it makes sense to me
>> to have the volatility state be like the data in the file. I guess
>> the only exception in my case is that if all the references to a
>> file are closed, we can clear the volatility (since we don't have a
>> sane way for the volatility to persist past that point).
> Agree if you provide to clear out volatility when file are closed by
> all stakeholder.

Agreed.


>> One question that might help resolve this: Would having some sort of
>> volatility checking interface be helpful in easing your concern
>> about applications being surprised by volatility?
> If we can provide above things, I think we don't need such interface
> until someone want it with reasonable logic.

Sure, I just wanted to know if you saw a need right away. For now we can 
leave it be.

>> True. And performance needs to be good if this hinting interface is
>> to be used easily. Although I worry about performance trumping sane
>> semantics. So let me try to implement the desired behavior and we
>> can measure the difference.
> NP. But keep in mind that mmap_sem was really terrible for performance
> when I took a expereiment(ie, concurrent page fault by many threads
> while a thread calls mmap).
> I guess primary reason is CONFIG_MUTEX_SPIN_ON_OWNER.
> So at least, we should avoid it by introducing new mode like
> VOLATILE_ANON|VOLATILE_FILE|VOLATILE_BOTH if we want to
> support mvrange-file and mvragne interface was thing userland people
> really want although ashmem have used fd-based model.

The VOLATILE_ANON|VOLATILE_FILE|VOLATILE_BOTH may be an interesting 
compromise.

Though, if one marks a VOLATILE_ANON range on an address that's an 
mmaped file, how do we detect this and provide a sane error value 
without checking the vmas?


thanks
-john

--
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/