linux-kernel - Re: [PATCH v2] After swapout/swapin private dirty mappings are reported clean in smaps

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:	Wed, 15 Sep 2010 21:53:26 +0200 (CEST)
From:	Richard Guenther <rguenther@...e.de>
To:	Matt Mackall <mpm@...enic.com>
Cc:	Hugh Dickins <hugh.dickins@...cali.co.uk>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	Nikanth Karthikesan <knikanth@...e.de>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
	Michael Matz <matz@...ell.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] After swapout/swapin private dirty mappings are
 reported clean in smaps

On Wed, 15 Sep 2010, Matt Mackall wrote:

> On Wed, 2010-09-15 at 12:18 -0700, Hugh Dickins wrote:
> > On Wed, Sep 15, 2010 at 10:24 AM, Matt Mackall <mpm@...enic.com> wrote:
> > 
> > > But that's my point: the consistency problem is NOT in smaps. The page
> > > is NOT marked dirty, ergo smaps doesn't report it as dirty. Whether or
> > > not there is MORE information smaps could be reporting is irrelevant,
> > > the information it IS reporting is consistent with the underlying VM
> > > data. If there's an inconsistency about what it means to be clean, it's
> > > either in the VM or in your head.
> > >
> > > And I frankly think it's in the VM.
> > 
> > I don't believe there's any problem in the VM here, we'd be having
> > SIGSEGVs all over if there were.
> 
> Of course it works. It's just not as orthogonal (aka consistent) as it
> could be in this case: it's not actually reflecting any of the usual
> meanings of dirtiness here.
> 
> > The problem is that /proc/pid/smaps exports a simplified view of the
> > VM, and Richard and Nikanth were hoping that it gave them some info
> > which it has never pretended to give them,
> > 
> > It happens to use a pte_dirty(ptent) test: you could argue that that
> > should be pte_dirty(ptent) || PageDirty(page) (which would then "fix
> > the issue" which Richard sees with swapoff/swapon),
> 
> That might be interesting. Are there any other notable cases where
> pte_dirty() differs from PageDirty()?
> 
> >  or you could argue
> > that it should be pte_dirty(ptent) || PageDirty(page) ||
> > PageSwapCache(page) (which would then note clean copies of swap cache
> > as dirty in the sense which Richard and Nikanth are interested in).
> > 
> > But after these years, we should probably assume that most users of
> > /proc/pid/smaps are used to the existing pte_dirty(ptent) test, and
> > would be troubled by a departure from it.
> 
> Dunno, my smem tool[1] is probably also expecting too much here and I
> should know better!

The question is also what smaps is supposed to deliver (I guess the
only documentation as of that respect is the kernel source ...).

The appearantly incomplete information isn't too useful at the
moment (apart from displaying the numbers in some form).  So
changing the semantics of the numbers in a slight way shouldn't
cause regressions in tools that formerly worked correct in all
cases.

Unfortunately gdb needs some reliable way of checking whether
the mappings content in memory is still equal to that of
the backing file (best without actually carrying out that
comparison ...).  /proc/pid/smaps looked like the most precise
interface for that - now unfortunately it's not usable for this.
Is there any other way?

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