netdev - Re: [PATCH v3 0/7] Convert skb_frag_t to bio

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]

Date:   Mon, 22 Jul 2019 13:39:59 -0700
From:   Matthew Wilcox <willy@...radead.org>
To:     David Miller <davem@...emloft.net>
Cc:     hch@....de, netdev@...r.kernel.org
Subject: Re: [PATCH v3 0/7] Convert skb_frag_t to bio_vec

On Fri, Jul 12, 2019 at 11:27:07AM -0700, David Miller wrote:
> From: Matthew Wilcox <willy@...radead.org>
> Date: Fri, 12 Jul 2019 06:43:38 -0700
> 
> > From: "Matthew Wilcox (Oracle)" <willy@...radead.org>
> > 
> > The skb_frag_t and bio_vec are fundamentally the same (page, offset,
> > length) tuple.  This patch series unifies the two, leaving the
> > skb_frag_t typedef in place.  This has the immediate advantage that
> > we already have iov_iter support for bvecs and don't need to add
> > support for iterating skbuffs.  It enables a long-term plan to use
> > bvecs more broadly within the kernel and should make network-storage
> > drivers able to do less work converting between skbuffs and biovecs.
> > 
> > It will consume more memory on 32-bit kernels.  If that proves
> > problematic, we can look at ways of addressing it.
> > 
> > v3: Rebase on latest Linus with net-next merged.
> >   - Reorder the uncontroversial 'Use skb accessors' patches first so you
> >     can apply just those two if you want to hold off on the full
> >     conversion.
> >   - Convert all the users of 'struct skb_frag_struct' to skb_frag_t.
> 
> I have no objections to this series, please resubmit it (taking into
> consideration any more feedback you get) when net-next opens back
> up.

No further feedback received, and the patches still apply cleanly to
Linus' head.  Do you want the patch series resent, or does your workflow
let you just pick these patches up now?