Re: [PATCH 2/2] ceph: use GFP_KERNEL consistently in __ceph_pool_perm_get()

Xiubo Li <[email protected]>
Newsgroups org.kernel.vger.ceph-devel,org.kernel.vger.linux-kernel
Message-ID <CAOJNxRJ2k+M4rbSaO5m=8Xr47pTJFN7SnH_FW4JC+A+Xb0gCCA@mail.gmail.com>
Hi Slava,

Sorry for the late reply. I think I just missed your email.

Yeah, you are right. Let me fix it.

Thanks
- XIubo

On Thu, 23 Jul 2026 at 10:11, Viacheslav Dubeyko <[email protected]> wrote:
>
> On Thu, 2026-07-23 at 13:47 +0800, Xiubo Li via B4 Relay wrote:
> > From: Xiubo Li <[email protected]>
> >
> > __ceph_pool_perm_get() has four allocations for building OSD STAT
> > requests, three of which used GFP_NOFS and one (the page vector
> > allocation) used GFP_KERNEL, making them inconsistent.
>
> __ceph_pool_perm_get() has six allocation calls, not four:
>
> 2457: rd_req = ceph_osdc_alloc_request(..., GFP_NOFS);      // (1) NOT
> touched by this patch
> 2471: err = ceph_osdc_alloc_messages(rd_req, GFP_NOFS);     // (2)
> changed -> GFP_KERNEL
> 2475: wr_req = ceph_osdc_alloc_request(..., GFP_NOFS);      // (3)
> changed -> GFP_KERNEL
> 2487: err = ceph_osdc_alloc_messages(wr_req, GFP_NOFS);     // (4)
> changed -> GFP_KERNEL
> 2492: pages = ceph_alloc_page_vector(1, GFP_KERNEL);         // (5)
> already GFP_KERNEL
> 2526: perm = kmalloc_flex(*perm, pool_ns, ..., GFP_NOFS);    // (6) NOT
> touched by this patch
>
> Should we change other places too?
>
> Thanks,
> Slava.
>
> >
> > The function is only called from ceph_try_get_caps() and
> > __ceph_get_caps(), both of which are in the user I/O path (read,
> > write, fallocate, mmap fault), not in the writeback path.  There is
> > no risk of recursive writeback, so GFP_NOFS is unnecessarily
> > restrictive.  Use GFP_KERNEL consistently for all four allocations.
> >
> > Signed-off-by: Xiubo Li <[email protected]>
> > ---
> >  fs/ceph/addr.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c
> > index e2da3ab9f808..d2ac3df47e97 100644
> > --- a/fs/ceph/addr.c
> > +++ b/fs/ceph/addr.c
> > @@ -2479,12 +2479,12 @@ static int __ceph_pool_perm_get(struct
> > ceph_inode_info *ci,
> >               rd_req->r_base_oloc.pool_ns =
> > ceph_get_string(pool_ns);
> >       ceph_oid_printf(&rd_req->r_base_oid, "%llx.00000000", ci-
> > >i_vino.ino);
> >
> > -     err = ceph_osdc_alloc_messages(rd_req, GFP_NOFS);
> > +     err = ceph_osdc_alloc_messages(rd_req, GFP_KERNEL);
> >       if (err)
> >               goto out_unlock;
> >
> >       wr_req = ceph_osdc_alloc_request(&fsc->client->osdc, NULL,
> > -                                      1, false, GFP_NOFS);
> > +                                      1, false, GFP_KERNEL);
> >       if (!wr_req) {
> >               err = -ENOMEM;
> >               goto out_unlock;
> > @@ -2495,7 +2495,7 @@ static int __ceph_pool_perm_get(struct
> > ceph_inode_info *ci,
> >       ceph_oloc_copy(&wr_req->r_base_oloc, &rd_req->r_base_oloc);
> >       ceph_oid_copy(&wr_req->r_base_oid, &rd_req->r_base_oid);
> >
> > -     err = ceph_osdc_alloc_messages(wr_req, GFP_NOFS);
> > +     err = ceph_osdc_alloc_messages(wr_req, GFP_KERNEL);
> >       if (err)
> >               goto out_unlock;
> >
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.