Please think both these patches through. I'm not going to claim I'm 100% certain of their correctness.
I'm confused by: include/net/netfilter/nf_conntrack.h:65: * beware nf_ct_get() is different and don't inc refcnt. and maybe there's some subtlety to this krealloc+rcu+kmemleak thing I'm missing. On Mon, Oct 7, 2019 at 10:35 PM Maciej Żenczykowski <[email protected]> wrote: > > From: Maciej Żenczykowski <[email protected]> > > This reverts commit 114aa35d06d4920c537b72f9fa935de5dd205260. > > By my understanding of kmemleak the reasoning for this patch > is incorrect. If kmemleak couldn't handle rcu we'd have it > reporting leaks all over the place. My belief is that this > was instead papering over a real leak. > > Cc: Cong Wang <[email protected]> > Cc: Eric Dumazet <[email protected]> > Cc: Pablo Neira Ayuso <[email protected]> > Signed-off-by: Maciej Żenczykowski <[email protected]> > --- > net/netfilter/nf_conntrack_extend.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/net/netfilter/nf_conntrack_extend.c > b/net/netfilter/nf_conntrack_extend.c > index d4ed1e197921..fb208877338a 100644 > --- a/net/netfilter/nf_conntrack_extend.c > +++ b/net/netfilter/nf_conntrack_extend.c > @@ -68,7 +68,6 @@ void *nf_ct_ext_add(struct nf_conn *ct, enum nf_ct_ext_id > id, gfp_t gfp) > rcu_read_unlock(); > > alloc = max(newlen, NF_CT_EXT_PREALLOC); > - kmemleak_not_leak(old); > new = __krealloc(old, alloc, gfp); > if (!new) > return NULL; > -- > 2.23.0.581.g78d2f28ef7-goog >
