From: Qasim Ijaz <qasdev00@gmail.com>
To: Hugh Dickins <hughd@google.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/shmem: Fix invalid PTR_ERR(NULL) call in shmem_xattr_handler_set()
Date: Wed, 29 Jan 2025 12:57:34 +0000 [thread overview]
Message-ID: <Z5olvnlsWOJe7GJH@qasdev.system> (raw)
On Tue, Jan 28, 2025 at 08:37:51PM -0800, Hugh Dickins wrote:
> On Tue, 28 Jan 2025, Qasim Ijaz wrote:
>
> > In shmem_xattr_handler_set() if simple_xattr_set() succeeds and the pointer
> > returned is not an error pointer, then old_xattr will be set to NULL in
> > the body of the following if statement:
> >
> > if (!IS_ERR(old_xattr))
> >
> > Later on shmem_xattr_handler_set() calls:
> >
> > return PTR_ERR(old_xattr);
> >
> > The PTR_ERR macro is used to extract an error code from an error pointer
> > and NULL is not an error pointer, PTR_ERR(NULL) simply results in 0.
>
> NULL pointer returns 0 for success: yes, that's what's wanted there.
>
> >
> > To improve correctness and readability,
>
> Correctness? Please explain - I don't see any incorrectness.
>
> Readability? Perhaps - I should not be the judge of that.
>
> > refactor the error handling
> > to have an explicit default return value of 0 (success) in "ret".
> > If simple_xattr_set() returns an error pointer, store its
> > error code in "ret".
> >
> > Signed-off-by: Qasim Ijaz <qasdev00@gmail.com>
> > ---
> > mm/shmem.c | 9 +++++++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
>
> I prefer how it was written before.
Hi Hugh,
By correctness I mean that NULL is not an error pointer, here are some additional points:
The code goes against the documentation of PTR_ERR() which mentions the argument to PTR_ERR() should be an error pointer. NULL is not an error pointer so I think it is inconsistent in that regard.
Secondly the current code is hinging on a side effect of the PTR_ERR() API being passed NULL, sure it works but I think it would be better if the API was used clearly and consistently with how it is meant to be used.
Also to add onto my points I decided to run the mm/shmem.c file through smatch (since one of its key features is detecting 0 being passed to PTR_ERR()) to see if it detects what I spotted and it brings up the following message:
mm/shmem.c:4174 shmem_xattr_handler_set() warn: passing zero to 'PTR_ERR'
Best regards,
Qasim
>
> >
> > diff --git a/mm/shmem.c b/mm/shmem.c
> > index 532afd8e049c..3e97c7890aac 100644
> > --- a/mm/shmem.c
> > +++ b/mm/shmem.c
> > @@ -4143,6 +4143,7 @@ static int shmem_xattr_handler_set(const struct xattr_handler *handler,
> > struct shmem_sb_info *sbinfo = SHMEM_SB(inode->i_sb);
> > struct simple_xattr *old_xattr;
> > size_t ispace = 0;
> > + int ret = 0;
> >
> > name = xattr_full_name(handler, name);
> > if (value && sbinfo->max_inodes) {
> > @@ -4158,7 +4156,9 @@ static int shmem_xattr_handler_set(const struct xattr_handler *handler,
> > }
> >
> > old_xattr = simple_xattr_set(&info->xattrs, name, value, size, flags);
> > - if (!IS_ERR(old_xattr)) {
> > + if (IS_ERR(old_xattr)) {
> > + ret = PTR_ERR(old_xattr);
> > + } else {
> > ispace = 0;
> > if (old_xattr && sbinfo->max_inodes)
> > ispace = simple_xattr_space(old_xattr->name,
> > @@ -4168,12 +4171,13 @@ static int shmem_xattr_handler_set(const struct xattr_handler *handler,
> > inode_set_ctime_current(inode);
> > inode_inc_iversion(inode);
> > }
> > +
> > if (ispace) {
> > raw_spin_lock(&sbinfo->stat_lock);
> > sbinfo->free_ispace += ispace;
> > raw_spin_unlock(&sbinfo->stat_lock);
> > }
> > - return PTR_ERR(old_xattr);
> > + return ret;
> > }
> >
> > static const struct xattr_handler shmem_security_xattr_handler = {
> > --
> > 2.39.5
next reply other threads:[~2025-01-29 12:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-29 12:57 Qasim Ijaz [this message]
-- strict thread matches above, loose matches on Subject: below --
2025-01-28 23:54 [PATCH] mm/shmem: Fix invalid PTR_ERR(NULL) call in shmem_xattr_handler_set() Qasim Ijaz
2025-01-29 4:37 ` Hugh Dickins
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=Z5olvnlsWOJe7GJH@qasdev.system \
--to=qasdev00@gmail.com \
--cc=16055fb0-bed3-e000-8c36-6e4886b08c9d@google.com \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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.