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: <AM4PR0401MB2260F19C276A1329FD2BB8A7FF7E0@AM4PR0401MB2260.eurprd04.prod.outlook.com>
Date:   Thu, 19 Jan 2017 08:18:27 +0000
From:   Andy Duan <fugang.duan@....com>
To:     Eric Dumazet <eric.dumazet@...il.com>,
        "Ashizuka, Yuusuke" <ashiduka@...fujitsu.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Pravin B Shelar <pshelar@...ira.com>
Subject: RE: [PATCH] net: fec: Fixed panic problem with non-tso

From: Eric Dumazet <eric.dumazet@...il.com> Sent: Wednesday, January 18, 2017 12:36 PM
>To: Ashizuka, Yuusuke <ashiduka@...fujitsu.com>
>Cc: Andy Duan <fugang.duan@....com>; netdev@...r.kernel.org; Pravin B
>Shelar <pshelar@...ira.com>
>Subject: Re: [PATCH] net: fec: Fixed panic problem with non-tso
>
>On Tue, 2017-01-17 at 20:21 -0800, Eric Dumazet wrote:
>> On Wed, 2017-01-18 at 03:12 +0000, Ashizuka, Yuusuke wrote:
>>
>> > indeed.
>> >
>> > In the case of TSO with i.MX6 system (highmem enabled) with 2GB
>> > memory, "this_frag->page.p" did not become highmem area.
>> > (We confirmed by transferring about 100MB of files)
>> >
>> > However, in the case of non-tso on an i.MX6 system with 2GB of
>> > memory, "this_frag->page.p" may become a highmem area.
>> > (Occurred with approximately 2MB of file transfer)
>> >
>> > For non-tso only, I do not know the reason why "this_frag-> page.p"
>> > in this driver shows highmem area.
>>
>> This worries me, since this driver does not set NETIF_F_HIGHDMA in its
>> features.
>>
>> No packet should be given to this driver with a highmem fragment
>>
>> Check is done in illegal_highdma() in net/core/dev.c
>
>This used to work.
>
>I suspect commit ec5f061564238892005257c83565a0b58ec79295
>("net: Kill link between CSUM and SG features.")
>
>added this bug.
>
>Can you try this hot fix :
>
>diff --git a/net/core/dev.c b/net/core/dev.c index
>ad5959e561166f445bdd9d7260652a338f74cfea..073b832b945257dba9ed47f4bf
>875605225effc9 100644
>--- a/net/core/dev.c
>+++ b/net/core/dev.c
>@@ -2773,9 +2773,9 @@ static netdev_features_t harmonize_features(struct
>sk_buff *skb,
> 	if (skb->ip_summed != CHECKSUM_NONE &&
> 	    !can_checksum_protocol(features, type)) {
> 		features &= ~(NETIF_F_CSUM_MASK | NETIF_F_GSO_MASK);
>-	} else if (illegal_highdma(skb->dev, skb)) {
>-		features &= ~NETIF_F_SG;
> 	}
>+	if (illegal_highdma(skb->dev, skb))
>+		features &= ~NETIF_F_SG;
>
> 	return features;
> }
>
>

I will double check your fix. Thanks.

And, if driver is to support highmem,  then we should add tso highmem support in net/core/tso.c,  do you think it is necessary ?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ