linux-kernel - Re: net: fec: fix regression on i.MX28 introduced by rx

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: <20141104.112858.356827532569349127.davem@davemloft.net>
Date:	Tue, 04 Nov 2014 11:28:58 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	LW@...O-electronics.de
Cc:	fabio.estevam@...escale.com, Frank.Li@...escale.com,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	rmk+kernel@....linux.org.uk, linux-arm-kernel@...ts.infradead.org
Subject: Re: net: fec: fix regression on i.MX28 introduced by rx_copybreak
 support

From: Lothar Waßmann <LW@...O-electronics.de>
Date: Tue, 4 Nov 2014 11:29:12 +0100

> Hi David,
> 
> Lothar Waßmann wrote:
>> David Miller wrote:
>> > From: Lothar Waßmann <LW@...O-electronics.de>
>> > Date: Thu, 30 Oct 2014 07:51:04 +0100
>> > 
>> > >> Also, I don't thnk your DIV_ROUND_UP() eliminate for the loop
>> > >> in swap_buffer() is valid.  The whole point is that the current
>> > >> code handles buffers which have a length which is not a multiple
>> > >> of 4 properly, after your change it will no longer do so.
>> > >>
>> > > Do you really think so?
>> > 
>> > Yes, because you're rounding down so you'll miss the final
>> > partial word (if any).
>> >
>> Nope. DIV_ROUND_UP() would give '1' as upper bound for lengths from 1 to
>> 4, '2' for lengths from 5 to 8 and so on.
>> 
>> The loop with increment 4 and i < len does exactly the same.
>> Try it for yourself, if you don't believe it.
>> 
>> 
> Do you still think, the loop without DIV_ROUND_UP() is incorrect,
> or can this patch be applied?

I haven't had the time to fully re-look into the details, I'm busy
with many other things at the moment.

But looking at DIV_ROUND_UP() macro it rounds up.  It gives an
upper bound of 4 for any value 1 to 4.  Unlike what you claim.

Because it goes "(n + (d - 1)) / d"

Which for 'd' of 4 gives:

1 --> 4
2 --> 4
3 --> 4
4 --> 4
--
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/