From: Christoph Hellwig <hch@lst.de>
To: Andreas Gruenbacher <agruenba@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>,
Andrew Morton <akpm@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
Gao Xiang <xiang@kernel.org>, Chao Yu <chao@kernel.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-erofs@lists.ozlabs.org, gfs2@lists.linux.dev
Subject: Re: [PATCH 8/8] gfs2: use lockref_init for qd_lockref
Date: Thu, 16 Jan 2025 05:32:26 +0100 [thread overview]
Message-ID: <20250116043226.GA23137@lst.de> (raw)
In-Reply-To: <CAHc6FU58eBO0i8er5+gK--eAMVHULCzHPnJ9H5oN12fr=AAnbg@mail.gmail.com>
On Wed, Jan 15, 2025 at 02:35:03PM +0100, Andreas Gruenbacher wrote:
> > +++ b/fs/gfs2/quota.c
> > @@ -236,8 +236,7 @@ static struct gfs2_quota_data *qd_alloc(unsigned hash, struct gfs2_sbd *sdp, str
> > return NULL;
> >
> > qd->qd_sbd = sdp;
> > - qd->qd_lockref.count = 0;
> > - spin_lock_init(&qd->qd_lockref.lock);
> > + lockref_init(&qd->qd_lockref, 0);
>
> Hmm, initializing count to 0 seems to be the odd case and it's fairly
> simple to change gfs2 to work with an initial value of 1. I wonder if
> lockref_init() should really have a count argument.
Well, if you can fix it to start with 1 we could start out with 1
as the default. FYI, I also didn't touch the other gfs2 lockref
because it initialize the lock in the slab init_once callback and
the count on every initialization.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Andreas Gruenbacher <agruenba@redhat.com>
Cc: Christian Brauner <brauner@kernel.org>,
linux-kernel@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
gfs2@lists.linux.dev, Al Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
linux-erofs@lists.ozlabs.org
Subject: Re: [PATCH 8/8] gfs2: use lockref_init for qd_lockref
Date: Thu, 16 Jan 2025 05:32:26 +0100 [thread overview]
Message-ID: <20250116043226.GA23137@lst.de> (raw)
In-Reply-To: <CAHc6FU58eBO0i8er5+gK--eAMVHULCzHPnJ9H5oN12fr=AAnbg@mail.gmail.com>
On Wed, Jan 15, 2025 at 02:35:03PM +0100, Andreas Gruenbacher wrote:
> > +++ b/fs/gfs2/quota.c
> > @@ -236,8 +236,7 @@ static struct gfs2_quota_data *qd_alloc(unsigned hash, struct gfs2_sbd *sdp, str
> > return NULL;
> >
> > qd->qd_sbd = sdp;
> > - qd->qd_lockref.count = 0;
> > - spin_lock_init(&qd->qd_lockref.lock);
> > + lockref_init(&qd->qd_lockref, 0);
>
> Hmm, initializing count to 0 seems to be the odd case and it's fairly
> simple to change gfs2 to work with an initial value of 1. I wonder if
> lockref_init() should really have a count argument.
Well, if you can fix it to start with 1 we could start out with 1
as the default. FYI, I also didn't touch the other gfs2 lockref
because it initialize the lock in the slab init_once callback and
the count on every initialization.
next prev parent reply other threads:[~2025-01-16 4:32 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-15 9:46 lockref cleanups Christoph Hellwig
2025-01-15 9:46 ` Christoph Hellwig
2025-01-15 9:46 ` [PATCH 1/8] lockref: remove lockref_put_not_zero Christoph Hellwig
2025-01-15 9:46 ` Christoph Hellwig
2025-01-15 9:46 ` [PATCH 2/8] lockref: improve the lockref_get_not_zero description Christoph Hellwig
2025-01-15 9:46 ` Christoph Hellwig
2025-01-15 13:28 ` Andreas Gruenbacher
2025-01-15 13:28 ` Andreas Gruenbacher
2025-01-15 9:46 ` [PATCH 3/8] lockref: use bool for false/true returns Christoph Hellwig
2025-01-15 9:46 ` Christoph Hellwig
2025-03-18 15:25 ` Mateusz Guzik
2025-03-18 15:51 ` Mateusz Guzik
2025-03-19 6:29 ` Christoph Hellwig
2025-03-19 12:04 ` Mateusz Guzik
2025-03-20 5:34 ` Christoph Hellwig
2025-01-15 9:46 ` [PATCH 4/8] lockref: drop superfluous externs Christoph Hellwig
2025-01-15 9:46 ` Christoph Hellwig
2025-01-15 9:46 ` [PATCH 5/8] lockref: add a lockref_init helper Christoph Hellwig
2025-01-15 9:46 ` Christoph Hellwig
2025-01-15 9:46 ` [PATCH 6/8] dcache: use lockref_init for d_lockref Christoph Hellwig
2025-01-15 9:46 ` Christoph Hellwig
2025-01-15 20:13 ` Dave Chinner
2025-01-15 20:13 ` Dave Chinner via Linux-erofs
2025-01-15 20:30 ` Al Viro
2025-01-15 20:30 ` Al Viro
2025-01-16 5:03 ` Dave Chinner
2025-01-16 5:03 ` Dave Chinner via Linux-erofs
2025-01-15 9:46 ` [PATCH 7/8] erofs: use lockref_init for pcl->lockref Christoph Hellwig
2025-01-15 9:46 ` Christoph Hellwig
2025-01-15 9:49 ` Gao Xiang
2025-01-15 9:49 ` Gao Xiang
2025-01-15 9:46 ` [PATCH 8/8] gfs2: use lockref_init for qd_lockref Christoph Hellwig
2025-01-15 9:46 ` Christoph Hellwig
2025-01-15 13:35 ` Andreas Gruenbacher
2025-01-15 13:35 ` Andreas Gruenbacher
2025-01-16 4:32 ` Christoph Hellwig [this message]
2025-01-16 4:32 ` Christoph Hellwig
2025-01-17 16:03 ` Andreas Gruenbacher
2025-01-17 16:03 ` Andreas Gruenbacher
2025-01-20 15:25 ` Christian Brauner
2025-01-20 15:25 ` Christian Brauner via Linux-erofs
2025-01-20 15:44 ` Andreas Gruenbacher
2025-01-20 15:44 ` Andreas Gruenbacher
2025-01-22 12:59 ` Christian Brauner
2025-01-22 12:59 ` Christian Brauner via Linux-erofs
2025-01-15 10:50 ` lockref cleanups Christian Brauner
2025-01-15 10:50 ` Christian Brauner via Linux-erofs
2025-01-22 20:40 ` Jeff Layton
2025-01-22 20:40 ` Jeff Layton via Linux-erofs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250116043226.GA23137@lst.de \
--to=hch@lst.de \
--cc=agruenba@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=chao@kernel.org \
--cc=gfs2@lists.linux.dev \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=xiang@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.