netdev - Re: Keystone 2 boards boot failure

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] [day] [month] [year] [list]

Date:	Mon, 08 Feb 2016 14:59:45 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Grygorii Strashko <grygorii.strashko@...com>
Cc:	"Franklin S Cooper Jr." <fcooper@...com>, m-karicheri2@...com,
	netdev@...r.kernel.org, w-kwok2@...com, davem@...emloft.net,
	Santosh Shilimkar <ssantosh@...nel.org>
Subject: Re: Keystone 2 boards boot failure

On Friday 05 February 2016 19:11:06 Grygorii Strashko wrote:
> On 02/05/2016 06:18 PM, Arnd Bergmann wrote:
> > On Thursday 04 February 2016 18:25:08 Grygorii Strashko wrote:

> > @@ -1173,7 +1189,8 @@ static int netcp_tx_submit_skb(struct netcp_intf *netcp,
> >   	}
> >   
> >   	set_words(&tmp, 1, &desc->packet_info);
> > -	set_words((u32 *)&skb, 1, &desc->pad[0]);
> > +	tmp = (uintptr_t)&skb;
> > +	set_words(&tmp, 1, &desc->pad[0]);
> 
> &skb is virt address and its size is 32bit even when LPAE=y (phys/dma 64 bit)
> so  this is excess conversion to/from u64 ;)
> This is from the first look.

My original patch attempted to fix support for 64-bit CPUs, as no driver
should be written to support only 32-bit CPUs even if you think at this
point that there can never be a 64-bit keystone system.

The half-reverted patch above no longer works correctly for 64-bit CPUs
but it should not actually be wrong on 32-bit CPUs either, unless I'm
missing your point. 

> >   
> >   	if (tx_pipe->flags & SWITCH_TO_PORT_IN_TAGINFO) {
> >   		tmp = tx_pipe->switch_to_port;
> > 
> > 
> > I'm sure it's something obvious and stupid in there, but I just can't
> > see it and that is very unsatisfying. Do you see where I am going wrong?
> > Most of all, I want to know it so I don't make the same mistake again
> > when I patch another driver.
> > 
> 
> I'm very sorry, but I'll not be able to test it in the nearest future :(
> What I could do now is update your/my patch as i mentioned in [1]
> and re-send it at the weekend (with your authorship and my signoff).
> Do you agree?
> 
> 
> [1] https://www.mail-archive.com/netdev@vger.kernel.org/msg95831.html

Yes, let's do that in the meantime. I can also make sure that that
the driver doesn't build on 64-bit, just in case.

	Arnd