linux-kernel - Re: [RFC Patch] use MTRR for write combining if PAT is not available

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] [day] [month] [year] [list]

Message-Id: <1256218013.2546.9.camel@sbs-t61>
Date:	Thu, 22 Oct 2009 06:26:53 -0700
From:	Suresh Siddha <suresh.b.siddha@...el.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Thomas Schlichter <thomas.schlichter@....de>,
	Jan Beulich <JBeulich@...ell.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	"dri-devel@...ts.sourceforge.net" <dri-devel@...ts.sourceforge.net>,
	Robert Hancock <hancockrwd@...il.com>,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	"jbarnes@...tuousgeek.org" <jbarnes@...tuousgeek.org>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>, Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Thomas Hellstrom <thellstrom@...are.com>,
	Tejun Heo <tj@...nel.org>,
	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>,
	"x86@...nel.org" <x86@...nel.org>, Yinghai Lu <yinghai@...nel.org>
Subject: Re: [RFC Patch] use MTRR for write combining if PAT is not
 available

On Thu, 2009-10-22 at 05:14 -0700, H. Peter Anvin wrote:
> On 10/22/2009 09:08 PM, Thomas Schlichter wrote:
> >>
> >> I have couple of issues with this patchset still. pci_mmap_page_range()
> >> doesn't get called for each fork(). So, we won't be ref counting the
> >> mtrr usage properly.
> >
> > When forking, what happens with the "struct file"? If it is being copied, then the
> > processes share the same private data which would be freed during the first
> > release(). I think this would be a problem whereever file-private data are used.
> >
> > So I think it must be shared between the forked processes and some reference
> > counting must exist. This reference counting must ensure that release() is only
> > called when all processes did close() their file.
> >
> > And in that case (shared "struct file", one single release() call in the end) this
> > implementation should be completely safe...
> >
> 
> struct file is shared between forked processes.

That is correct. But I am referring to the ref-count getting incremented
in Thomas's patch only in the pci_mmap_page_range() which will be called
only during first mmap.

We need to keep track of the counts of later forks too. For PAT, we keep
track of this ref counting in track_pfn_vma_copy(). We shouldn't use
different tracking mechanisms for PAT and non-PAT. We should cleanly tap
into track_pfn_vma_copy() or extend that to cover this case aswell.

thanks,
suresh

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