linux-kernel - Re: How could we get rid of saved_max

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: <20140306160508.GA23025@redhat.com>
Date:	Thu, 6 Mar 2014 11:05:08 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Muli Ben-Yehuda <muli@...technion.ac.il>
Cc:	WANG Chao <chaowang@...hat.com>, "Jon D. Mason" <jdmason@...zu.us>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, Yinghai Lu <yinghai@...nel.org>,
	Baoquan He <bhe@...hat.com>, kexec@...ts.infradead.org,
	discuss@...-64.org, x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: How could we get rid of saved_max_pfn for calgary iommu?

On Thu, Mar 06, 2014 at 08:47:56AM +0200, Muli Ben-Yehuda wrote:
> On Wed, Mar 05, 2014 at 01:36:17PM +0800, WANG Chao wrote:
> 
> > Hi, Muli
> > 
> > saved_max_pfn is becoming a setback for kexec-tools. Ideally calgary
> > could get rid of saved_max_pfn at all. But If this can't work, how
> > about exporting a calgary tce table size to user space, so that
> > kexec-tools can simply pass calgary=xxx cmdline to 2nd kernel.
> 
> As Jon noted, this code is used to so that the TCE table remains
> consistent between the original and the kexec'd kernel. I see two
> options: either we hard code the TCE table size to the max so that
> this bit of code becomes redundant, or we explicitly pass the original
> table size (or the original max_pfn) to the kexec'd kernel. The first
> option is more appealing, because I don't think anyone is actually
> using the TCE table size -- we mostly added it for debugging the IOMMU
> TCE code at the time -- but since I don't have a Calgary machine
> anymore, I don't have any way to test it. The second option is uglier
> but would be fully backward-compatible and less likely to break
> things. Given that very few people are likely running the latest
> upstream kernel on Calgary/CalIOC2 machines, I'm inclined towards the
> first option.

I like the first idea too. If we always use the max table size, then
we don't have to pass table size around.

This is not fully backward compatible in the sense if people are running
newer kernel but use an older kernel for dump capture. But that's a real
corner case. And there will be a workaround for that corner case too.
One will be able to specify a command line option to kexec-tools to switch
to old behavior. 

Majority of users use same kernel for dump capture as first kernel and
they should be just fine with this change.

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