linux-kernel - Re: [PATCH] net: arc_emac: fix arc_emac

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]

Message-ID: <9170e5bb-4765-a4dd-9d85-e44791877ea1@gmail.com>
Date:   Tue, 19 Dec 2017 10:33:35 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Alexander Kochetkov <al.kochet@...il.com>,
        David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        edumazet@...gle.com
Subject: Re: [PATCH] net: arc_emac: fix arc_emac_rx() error paths

On 12/19/2017 07:49 AM, Alexander Kochetkov wrote:
> 
>> 19 дек. 2017 г., в 18:22, David Miller <davem@...emloft.net> написал(а):
>>
>> From: Alexander Kochetkov <al.kochet@...il.com>
>> Date: Fri, 15 Dec 2017 20:20:06 +0300
>>
>>> arc_emac_rx() has some issues found by code review.
>>>
>>> In case netdev_alloc_skb_ip_align() or dma_map_single() failure
>>> rx fifo entry will not be returned to EMAC.
>>>
>>> In case dma_map_single() failure previously allocated skb became
>>> lost to driver. At the same time address of newly allocated skb
>>> will not be provided to EMAC.
>>>
>>> Signed-off-by: Alexander Kochetkov <al.kochet@...il.com>
>>
>> This patch adds quite a few bugs, here is one which shows this is not
>> functionally tested:
> 
> May be I don’t understand correctly, but I don’t see bug here.
> 
> Wrong dma mapping usage should immediately manifest itself (kernel
> instability, koops and so on). The patch was tested on rk3188 and work fine for me.
> Also I did simulations of netdev_alloc_skb_ip_align() and dma_map_single()
> faults and can confirm that new error handling work.
> 
> Could someone else with ARC EMAC test the patch? I would be very grateful for the help.
> Florian or Eric, can you test it on your hardware?

I don't actually have access to this hardware, the only change I did to
this driver was to use a standard Device Tree property :)
-- 
Florian