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: <20080603.163317.148261530.davem@davemloft.net>
Date:	Tue, 03 Jun 2008 16:33:17 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	akpm@...ux-foundation.org
Cc:	netdev@...r.kernel.org, bugme-daemon@...zilla.kernel.org,
	f0h3a-kernel@...oo.com, kkeil@...e.de
Subject: Re: [Bugme-new] [Bug 10790] New: driver "sunhme" experiences
 corrupt packets if machine has more than 2GB of memory

From: Andrew Morton <akpm@...ux-foundation.org>
Date: Sun, 25 May 2008 11:45:48 -0700

> Note that this patch from Karsten:
> https://bugzilla.novell.com/attachment.cgi?id=217968 did not work.

That patch is unlikely to be the issue, right.

> Stoopid question: if it fails at 2GB, should we try DMA_31BIT_MASK?

I've scoured all of the docs and the chip itself and the PCI front-end
it is connected to support full 32-bit PCI addressing.

The bug report says platform "All" but the report specifically
mentions Q6600 cpus, is this x86_64 by chance?  I wonder if the
problem is that we use GFP_ATOMIC/GFP_KERNEL for allocations
of SKB data, and we end up with buffers above 4GB but the IOMMU
mapping operation doesn't cope with that correctly.

In the arch/x86/kernel/pci-nommu.c case, this would result in
kernel log messages from check_addr():

		if (*hwdev->dma_mask >= DMA_32BIT_MASK)
			printk(KERN_ERR
			    "nommu_%s: overflow %Lx+%zu of device mask %Lx\n",
				name, (long long)bus, size,
				(long long)*hwdev->dma_mask);
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ