Message ID | 163111665914.283156.3038561975681836591.stgit@warthog.procyon.org.uk (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | afs: Fixes for 3rd party-induced data corruption | expand |
On Wed, Sep 8, 2021 at 12:58 PM David Howells <dhowells@redhat.com> wrote: > > The afs_read objects created by afs_req_issue_op() get leaked because > afs_alloc_read() returns a ref and then afs_fetch_data() gets its own ref > which is released when the operation completes, but the initial ref is > never released. > > Fix this by discarding the initial ref at the end of afs_req_issue_op(). > > This leak also covered another bug whereby a ref isn't got on the key > attached to the read record by afs_req_issue_op(). This isn't a problem as > long as the afs_read req never goes away... > > Fix this by calling key_get() in afs_req_issue_op(). > > This was found by the generic/074 test. It leaks a bunch of kmalloc-192 > objects each time it is run, which can be observed by watching > /proc/slabinfo. > > Fixes: f7605fa869cf ("afs: Fix leak of afs_read objects") > Reported-by: Marc Dionne <marc.dionne@auristor.com> > Signed-off-by: David Howells <dhowells@redhat.com> > cc: linux-afs@lists.infradead.org > Link: https://lore.kernel.org/r/163010394740.3035676.8516846193899793357.stgit@warthog.procyon.org.uk/ > --- > > fs/afs/file.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/fs/afs/file.c b/fs/afs/file.c > index db035ae2a134..6688fff14b0b 100644 > --- a/fs/afs/file.c > +++ b/fs/afs/file.c > @@ -295,7 +295,7 @@ static void afs_req_issue_op(struct netfs_read_subrequest *subreq) > fsreq->subreq = subreq; > fsreq->pos = subreq->start + subreq->transferred; > fsreq->len = subreq->len - subreq->transferred; > - fsreq->key = subreq->rreq->netfs_priv; > + fsreq->key = key_get(subreq->rreq->netfs_priv); > fsreq->vnode = vnode; > fsreq->iter = &fsreq->def_iter; > > @@ -304,6 +304,7 @@ static void afs_req_issue_op(struct netfs_read_subrequest *subreq) > fsreq->pos, fsreq->len); > > afs_fetch_data(fsreq->vnode, fsreq); > + afs_put_read(fsreq); > } > > static int afs_symlink_readpage(struct page *page) Tested that it prevents the leak of about 49K kmalloc-192 objects for a run of generic/074. Reviewed-and-tested-by: Marc Dionne <marc.dionne@auristor.com> Marc
diff --git a/fs/afs/file.c b/fs/afs/file.c index db035ae2a134..6688fff14b0b 100644 --- a/fs/afs/file.c +++ b/fs/afs/file.c @@ -295,7 +295,7 @@ static void afs_req_issue_op(struct netfs_read_subrequest *subreq) fsreq->subreq = subreq; fsreq->pos = subreq->start + subreq->transferred; fsreq->len = subreq->len - subreq->transferred; - fsreq->key = subreq->rreq->netfs_priv; + fsreq->key = key_get(subreq->rreq->netfs_priv); fsreq->vnode = vnode; fsreq->iter = &fsreq->def_iter; @@ -304,6 +304,7 @@ static void afs_req_issue_op(struct netfs_read_subrequest *subreq) fsreq->pos, fsreq->len); afs_fetch_data(fsreq->vnode, fsreq); + afs_put_read(fsreq); } static int afs_symlink_readpage(struct page *page)
The afs_read objects created by afs_req_issue_op() get leaked because afs_alloc_read() returns a ref and then afs_fetch_data() gets its own ref which is released when the operation completes, but the initial ref is never released. Fix this by discarding the initial ref at the end of afs_req_issue_op(). This leak also covered another bug whereby a ref isn't got on the key attached to the read record by afs_req_issue_op(). This isn't a problem as long as the afs_read req never goes away... Fix this by calling key_get() in afs_req_issue_op(). This was found by the generic/074 test. It leaks a bunch of kmalloc-192 objects each time it is run, which can be observed by watching /proc/slabinfo. Fixes: f7605fa869cf ("afs: Fix leak of afs_read objects") Reported-by: Marc Dionne <marc.dionne@auristor.com> Signed-off-by: David Howells <dhowells@redhat.com> cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/163010394740.3035676.8516846193899793357.stgit@warthog.procyon.org.uk/ --- fs/afs/file.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)