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 <zenczykow...@gmail.com> wrote: > > From: Maciej Żenczykowski <m...@google.com> > > 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 <xiyou.wangc...@gmail.com> > Cc: Eric Dumazet <eduma...@google.com> > Cc: Pablo Neira Ayuso <pa...@netfilter.org> > Signed-off-by: Maciej Żenczykowski <m...@google.com> > --- > 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 >
