linux-kernel - Re: [PATCH] After swapout/swapin private dirty mappings become clean

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]

Message-Id: <201009151030.36012.knikanth@suse.de>
Date:	Wed, 15 Sep 2010 10:30:35 +0530
From:	Nikanth Karthikesan <knikanth@...e.de>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc:	linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Matt Mackall <mpm@...enic.com>,
	balbir@...ux.vnet.ibm.com, rguenther@...ell.com, matz@...ell.com
Subject: Re: [PATCH] After swapout/swapin private dirty mappings become clean

On Wednesday 15 September 2010 10:16:36 KOSAKI Motohiro wrote:
> > On Wednesday 15 September 2010 05:54:31 KOSAKI Motohiro wrote:
> > > > /proc/$pid/smaps broken: After swapout/swapin private dirty mappings
> > > > become clean.
> > > >
> > > > When a page with private file mapping becomes dirty, the vma will be
> > > > in both i_mmap tree and anon_vma list. The /proc/$pid/smaps will
> > > > account these pages as dirty and backed by the file.
> > > >
> > > > But when those dirty pages gets swapped out, and when they are read
> > > > back from swap, they would be marked as clean, as it should be, as
> > > > they are part of swap cache now.
> > > >
> > > > But the /proc/$pid/smaps would report the vma as a mapping of a file
> > > > and it is clean. The pages are actually in same state i.e., dirty
> > > > with respect to file still, but which was once reported as dirty is
> > > > now being reported as clean to user-space.
> > > >
> > > > This confuses tools like gdb which uses this information. Those tools
> > > > think that those pages were never modified and it creates problem
> > > > when they create dumps.
> > > >
> > > > The file mapping of the vma also cannot be broken as pages never read
> > > > earlier, will still have to come from the file. Just that those dirty
> > > > pages have become clean anonymous pages.
> > > >
> > > > During swaping in, restoring the exact state as dirty file-backed
> > > > pages before swapout would be useless, as there in no real bug.
> > > > Breaking the vma with only anonymous pages as seperate vmas
> > > > unnecessary may not be a good thing as well. So let us just export
> > > > the information that a file-backed vma has anonymous dirty pages.
> > >
> > > Why can't gdb check Swap: field in smaps? I think Swap!=0 mean we need
> > > dump out.
> >
> > Yes. When the page is swapped out it is accounted in "Swap:".
> >
> > > Am I missing anything?
> >
> > But when it gets swapped in back to memory, it is removed from "Swap:"
> > and added to "Private_Clean:" instead of "Private_Dirty:".
> 
> Here is the code.
> I think the page will become dirty, again.
> 
> --------------------------------------------------------------
> int try_to_free_swap(struct page *page)
> {
>         VM_BUG_ON(!PageLocked(page));
> 
>         if (!PageSwapCache(page))
>                 return 0;
>         if (PageWriteback(page))
>                 return 0;
>         if (page_swapcount(page))
>                 return 0;
> 
>         delete_from_swap_cache(page);
>         SetPageDirty(page);
>         return 1;
> }
> 

I think this gets called only when the swap space gets freed. But when the 
page is just swapped out and swapped in, and the page is still part of 
SwapCache, it will be marked as clean, when the I/O read from swap completes.

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