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, 12 May 2016 19:53:18 +0200
From:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:	Francois Romieu <romieu@...zoreil.com>
Cc:	David Miller <davem@...emloft.net>,
	"<netdev@...r.kernel.org>" <netdev@...r.kernel.org>,
	Ricardo Salveti <ricardo.salveti@...aro.org>,
	Leo Duran <leo.duran@....com>,
	G Gregory <graeme.gregory@...aro.org>,
	Realtek linux nic maintainers <nic_swsd@...ltek.com>,
	Chunhao Lin <hau@...ltek.com>
Subject: Re: [PATCH] r8169: default to 64-bit DMA on systems without memory
 below 4 GB

On 12 May 2016 at 16:09, Francois Romieu <romieu@...zoreil.com> wrote:
>> On 12 May 2016 at 01:58, David Miller <davem@...emloft.net> wrote:
>> > From: Ard Biesheuvel <ard.biesheuvel@...aro.org>
>> > Date: Wed, 11 May 2016 09:47:49 +0200
> [...]
>> > I think we should just seriously consider changing the default, it's
>> > a really outdated reasoning behind the current default setting.  Maybe
>> > relevant a decade ago, but probably not now.
>> >
>> > And if the card is completely disfunctional in said configuration, the
>> > default is definitely wrong.
>>
>> The card is indeed completely disfunctional. So we could try to
>> resurrect 353176888386 ("r8169: enable 64-bit DMA by default for PCI
>> Express devices"), and instead of backing it out again if regressions
>> are reported, blacklist the particular chips. This is a much better
>> approach, since then we can also print some kind of diagnostic on
>> those arm64 systems why such a blacklisted NIC is not supported.
>
> I doubt there will be much *reporting* from broken systems that
> include plain old PCI realtek chipsets (r8169.c::RTL_CFG_0). Changing
> the default for those is imnsho asking for troubles without clear
> benefit (experimental evidence suggests that smsc etherpower II grows
> older more easily than plain pci 8169 :o/ ).
>

By resurrecting 353176888386, I mean the patch that changes the
default for PCI express devices, so I think we are in agreement here?

> I'd rather leave these alone and change the default for the PCI Express
> chipsets. Btw, while it does not seem to hurt, they should not need any
> CPlusCmd Dual Access Cycle tweak either. Realtek may establish it (Lin ?)
>
> A few news from the "pathologically better safe than sorry" squad:
> I have switched the default on a couple of non-critical production
> servers that include 8168c (RTL_GIGA_MAC_VER_22). It should give an hint
> for hardware from 2008 ~ 2009. I'll do some basic sanity testing with
> different chipsets.
>

Thanks for testing that. In the mean time, I will dust off the patch
and rebase it to today's -next.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ