netdev - Re: [PATCH 0/8] reduce open coded skb->next access for gso segment walking

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: <20200108.152137.1374468272236816533.davem@davemloft.net>
Date:   Wed, 08 Jan 2020 15:21:37 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     Jason@...c4.com
Cc:     netdev@...r.kernel.org, siva.kallam@...adcom.com,
        christopher.lee@...i.com, ecree@...arflare.com,
        johannes.berg@...el.com
Subject: Re: [PATCH 0/8] reduce open coded skb->next access for gso segment
 walking

From: "Jason A. Donenfeld" <Jason@...c4.com>
Date: Wed,  8 Jan 2020 16:59:01 -0500

> This patchset introduces the skb_list_walk_safe helper macro, in order
> to add some sanity to the myrid ways drivers have of walking through gso
> segments. The goal is to reduce future bugs commonly caused by open
> coding these sorts of things, and to in the future make it easier to
> swap out the underlying list representation.
> 
> This first patch series addresses the easy uses of drivers iterating
> over the returned list of skb_gso_segments, for drivers that live in
> drivers/net/*. There are still other use cases to tackle later for
> net/*, and after these low-hanging fruits are taken care of, I imagine
> there are more subtle cases of gso segment walking that isn't just a
> direct return value from skb_gso_segments, and eventually this will have
> to be tackled. This series is the first in that direction.

I like this, applied to net-next and build testing.  Let's see where this
goes.

In the iwlwifi case, the skb_mark_not_on_list() is really redundant because
deep down inside the skb queue tail insert, __skb_insert() will unconditionally
always write both ->next and ->prev and there are no debugging checks along
the way which would trigger if skb->next was non-NULL.

I guess you could argue for defensive programming here, so there's that.

Anyways, thanks.