[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAO8a2Sh6wJ++BQE_6WjK0H5ySNer8i2GqqW=BY3uAgK-6Wbj=g@mail.gmail.com>
Date: Thu, 28 Nov 2024 14:48:43 +0200
From: Alex Markuze <amarkuze@...hat.com>
To: Max Kellermann <max.kellermann@...os.com>
Cc: xiubli@...hat.com, idryomov@...il.com, ceph-devel@...r.kernel.org,
linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] fs/ceph/file: fix memory leaks in __ceph_sync_read()
The ergonomics and error handling on this function seem awkward. I'll
take a closer look on how to arrange it better.
On Thu, Nov 28, 2024 at 2:31 PM Max Kellermann <max.kellermann@...os.com> wrote:
>
> On Thu, Nov 28, 2024 at 1:28 PM Max Kellermann <max.kellermann@...os.com> wrote:
> >
> > On Thu, Nov 28, 2024 at 1:18 PM Alex Markuze <amarkuze@...hat.com> wrote:
> > > Pages are freed in `ceph_osdc_put_request`, trying to release them
> > > this way will end badly.
> >
> > I don't get it. If this ends badly, why does the other
> > ceph_release_page_vector() call after ceph_osdc_put_request() in that
> > function not end badly?
>
> Look at this piece:
>
> osd_req_op_extent_osd_data_pages(req, 0, pages, read_len,
> offset_in_page(read_off),
> false, false);
>
> The last parameter is "own_pages". Ownership of these pages is NOT
> transferred to the osdc request, therefore ceph_osdc_put_request()
> will NOT free them, and this is really a leak bug and my patch fixes
> it.
>
> I just saw this piece of code for the first time, I have no idea. What
> am I missing?
>
Powered by blists - more mailing lists