linux-kernel - Re: [RFC] [Patch] calgary iommu: Use the first kernel's tce tables in kdump

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:	Thu, 17 Jul 2008 16:14:14 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Chandru <chandru@...ibm.com>
Cc:	muli@...ibm.com, linux-kernel@...r.kernel.org, alexisb@...ibm.com,
	Andy Whitcroft <apw@...dowen.org>
Subject: Re: [RFC] [Patch] calgary iommu: Use the first kernel's tce tables
 in kdump

On Tue, 15 Jul 2008 14:15:27 +0530
Chandru <chandru@...ibm.com> wrote:

> kdump kernel fails to boot with calgary iommu and aacraid driver on a x366 
> box. The ongoing dma's of aacraid from the first kernel continue to exist 
> until the driver is loaded in the kdump kernel. Calgary is initialized prior 
> to aacraid and creation of new tce tables causes wrong dma's to occur. Here 
> we try to get the tce tables of the first kernel in kdump kernel and use 
> them. While in the kdump kernel we do not allocate new tce tables but instead 
> read the base addres register contents of calgary iommu and use the tables 
> that the registers point to. With these changes the kdump kernel and hence 
> aacraid now boots normally.
> 
> Signed-off-by: Chandru Siddalingappa <chandru@...ibm.com>
> ---
> 
> patch taken on top of linux-2.6.26 stable. Comments from Muli Ben-Yehuda taken 
> into consideration. Pls apply it as a stop-gap patch until we can come up 
> with a more stable patch for this issue. Thanks,

Is this needed in 2.6.26?

If so, the patch whcih I applied will need a little work because I had
to touch up some rejects against already-queued changes.  I can fix
that issue by applying this _ahead_ of those changes, but I'm just not
able to judge whether this is needed from the information which was
provided.

> diff -Narup linux-2.6.26-orig/arch/x86/kernel/pci-calgary_64.c 
> linux-2.6.26/arch/x86/kernel/pci-calgary_64.c
> --- linux-2.6.26-orig/arch/x86/kernel/pci-calgary_64.c	2008-07-15 
> 13:36:00.000000000 +0530
> +++ linux-2.6.26/arch/x86/kernel/pci-calgary_64.c	2008-07-15 
> 13:45:36.000000000 +0530
> @@ -36,6 +36,7 @@
>  #include <linux/delay.h>
>  #include <linux/scatterlist.h>
>  #include <linux/iommu-helper.h>
> +#include <linux/crash_dump.h>

You don't _have_ to put new includes right at the end of the list! 
Everyone does this, and it just maximises the probability of merge
conflcits :(


>  #include <asm/gart.h>
>  #include <asm/calgary.h>
>  #include <asm/tce.h>
> @@ -167,6 +168,8 @@ static void calgary_dump_error_regs(stru
>  static void calioc2_handle_quirks(struct iommu_table *tbl, struct pci_dev 
> *dev);

The patch was wordwrapped.

> +	max_pfn = is_kdump_kernel() ? saved_max_pfn : end_pfn ;
> ...
> +	return (elfcorehdr_addr != ELFCORE_ADDR_MAX) ? 1 : 0 ;
> ...

A couple of little coding-style errors there.  checkpatch missed them.
--
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/