netdev - Re: [PATCH] dp83640: don't recieve time stamps twice

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: <1492601312.3108.3.camel@spectralink.com>
Date:   Wed, 19 Apr 2017 11:28:34 +0000
From:   Sørensen, Stefan 
        <Stefan.Sorensen@...ctralink.com>
To:     "richardcochran@...il.com" <richardcochran@...il.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "dan.carpenter@...cle.com" <dan.carpenter@...cle.com>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "andrew@...n.ch" <andrew@...n.ch>,
        "kernel-janitors@...r.kernel.org" <kernel-janitors@...r.kernel.org>
Subject: Re: [PATCH] dp83640: don't recieve time stamps twice

On Wed, 2017-04-19 at 12:31 +0200, Richard Cochran wrote:
> Can we please fix this in another way?  There is no need to hold the
> spin lock during the callback into the networking stack.  Instead,
> how about the following diff, which also fixes the other call site...


I agree that this is a better way to fix it - I think that this was the
purpose of the patch that got halfway mixed in.

@@ -874,14 +874,15 @@ static void decode_rxts(struct dp83640_private
> *dp83640,
>  			shhwtstamps = skb_hwtstamps(skb);
>  			memset(shhwtstamps, 0,
> sizeof(*shhwtstamps));
>  			shhwtstamps->hwtstamp = ns_to_ktime(rxts-
> >ns);
> -			netif_rx_ni(skb);
>  			list_add(&rxts->list, &dp83640->rxpool);
>  			break;
>  		}
>  	}
>  	spin_unlock(&dp83640->rx_queue.lock);
>  
> -	if (!shhwtstamps)
> +	if (shhwtstamps)
> +		netif_rx_ni(skb);
> +	else
>  		list_add_tail(&rxts->list, &dp83640->rxts);
>  out:
>  	spin_unlock_irqrestore(&dp83640->rx_lock, flags);

Here we still hold rx_lock while during the callback, wouldn't it be
beneficial to release that first?

Stefan