linux-kernel - Re: [patch] crashdump: fix undefined reference to `elfcorehdr

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 28 Jul 2008 09:44:05 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Muli Ben-Yehuda <muli@...ibm.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Simon Horman <horms@...ge.net.au>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Chandru <chandru@...ibm.com>, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Terry Loftin <terry.loftin@...com>,
	Tony Luck <tony.luck@...el.com>, linux-ia64@...r.kernel.org
Subject: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr'

On Mon, Jul 28, 2008 at 09:24:46AM +0300, Muli Ben-Yehuda wrote:
> On Sun, Jul 27, 2008 at 10:39:30PM -0700, Eric W. Biederman wrote:
> > Simon Horman <horms@...ge.net.au> writes:
> > 
> > > There has long been a strong aversion to providing the second
> > > kernel with flags like im_in_kexec or im_in_kdump, as its felt
> > > that this kind of problem is better handled by making sure that
> > > the hardware is in a sensible state before leaving the
> > > first-kernel.  But this is arguably more reasonable in the kexec
> > > case than the kdump case.
> > 
> > That and because we can generally solve the specific problem with a
> > general feature.  Something we can enable/disable on the command
> > line if needed.  Right now this is especially interesting as on
> > several architectures distros are not building special kdump kernels
> > but have a single kernel binary that works in both cases.
> > 
> > Skimming through your patches this is a case we really do need to
> > implement and handle cleanly.
> > 
> > Currently we leave DMA running in the kexec on panic case.  We avoid
> > problems by only running out of a reserved area of memory.
> > 
> > As as general strategy that is fine.  However we have not
> > implemented that strategy in the case of IOMMUs.  And we are having
> > trouble with IOMMUs.
> > 
> > My hunch is that we should implement options to reserve a section of
> > the iommu and to tell to the iommu to use the previously reserved
> > section. Although turning iommus off altogether and simply using
> > swiotlb may be acceptable.  In which case we should just force usage
> > of the swiotlb on the command line in /sbin/kexec.
> 
> With an isolation-capable IOMMU (such as Calgary, VT-d and AMD's
> IOMMU) on the I/O path, as long as we want to keep DMAs running and
> going through to memory, we need to keep the IOMMU running, with the
> same set of permissions and translation tables. If we don't mind DMAs
> failing, we need to gracefully handle IOMMU DMA faults (where
> possible---Calgary can't do it at the moment). What we do instead with
> Calgary (c.f., the patch that instigated this discussion) is a hack,
> we "reinitialize" the IOMMU with the old IOMMU's translation tables so
> that DMAs continue working. 
> 

Hi Muli,

Agree, using old kernel's TCE tables is a hack. As Eric pointed out,
is there a reason why swiotlb will not work here? (I guess using
swiotlb will mean disabling iommu and that will again fault if 
DMA is going on).

So one of the solutions, as eric suggested,  will be to reserve some
entries in first kernel and then pass that info to second kernel and
let second kernel use thos entries for setting up DMA and let the
DMA's of first kernel run untouched.

This patch is effectively doing that (using previous kernel's TCE table),
except the fact that there are no gurantees that there are free table
entries when kdump kernel wants to perform a DMA of its own. Should
probably work though in most of the cases. 

> My preference would be to have stopped all DMAs in the old kernel,
> which would've made this nastiness go away. Can you explain in simple
> words why we can't or won't do that?
> 

Is there a reliable way of stopping all ongoing DMAs after kernel crash?

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/