From: Stefan Hajnoczi <stefanha@redhat.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Hannes Reinecke <hare@suse.de>,
linux-block@vger.kernel.org,
"Martin K. Petersen" <martin.petersen@oracle.com>,
linux-kernel@vger.kernel.org,
"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
Mike Christie <michael.christie@oracle.com>,
Jens Axboe <axboe@kernel.dk>,
linux-nvme@lists.infradead.org, Keith Busch <kbusch@kernel.org>,
Sagi Grimberg <sagi@grimberg.me>,
linux-scsi@vger.kernel.org, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 3/4] block: add IOC_PR_READ_KEYS ioctl
Date: Mon, 1 Dec 2025 13:36:21 -0500 [thread overview]
Message-ID: <20251201183621.GA919572@fedora> (raw)
In-Reply-To: <fadbd728-6810-49de-905d-214c2f72a857@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2122 bytes --]
On Mon, Dec 01, 2025 at 05:26:27PM +0100, Krzysztof Kozlowski wrote:
> On 01/12/2025 16:06, Stefan Hajnoczi wrote:
> > On Sat, Nov 29, 2025 at 03:32:35PM +0100, Krzysztof Kozlowski wrote:
> >> On 27/11/2025 08:07, Hannes Reinecke wrote:
> >>>
> >>>> + size_t keys_info_len = struct_size(keys_info, keys, inout.num_keys);
> >>>> +
> >>>> + keys_info = kzalloc(keys_info_len, GFP_KERNEL);
> >>>> + if (!keys_info)
> >>>> + return -ENOMEM;
> >>>> +
> >>>> + keys_info->num_keys = inout.num_keys;
> >>>> +
> >>>> + ret = ops->pr_read_keys(bdev, keys_info);
> >>>> + if (ret)
> >>>> + return ret;
> >>>> +
> >>>> + /* Copy out individual keys */
> >>>> + u64 __user *keys_ptr = u64_to_user_ptr(inout.keys_ptr);
> >>>> + u32 num_copy_keys = min(inout.num_keys, keys_info->num_keys);
> >>>> + size_t keys_copy_len = num_copy_keys * sizeof(keys_info->keys[0]);
> >>>
> >>> We just had the discussion about variable declarations on the ksummit
> >>> lists; I really would prefer to have all declarations at the start of
> >>> the scope (read: at the start of the function here).
> >>
> >> Then also cleanup.h should not be used here.
> >
> > Hi Krzysztof,
> > The documentation in cleanup.h says:
> >
> > * Given that the "__free(...) = NULL" pattern for variables defined at
> > * the top of the function poses this potential interdependency problem
> > * the recommendation is to always define and assign variables in one
> > ^^^^^^^^^^^^^^
> > * statement and not group variable definitions at the top of the
> > * function when __free() is used.
> >
> > This is a recommendation, not mandatory. It is also describing a
> > scenario that does not apply here.
>
> If you have actual argument, so allocation in some if branch, the of course.
I'm pointing out that the documentation uses the word "recommendation",
which is usually not considered mandatory but a suggestion.
Please update the documentation to clarify that __free() _must_ be
assigned the real value (no NULL initialization) so that it's clear this
is not a suggestion but mandatory.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2025-12-01 18:36 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-26 16:35 [PATCH 0/4] block: add IOC_PR_READ_KEYS and IOC_PR_READ_RESERVATION ioctls Stefan Hajnoczi
2025-11-26 16:35 ` [PATCH 1/4] scsi: sd: reject invalid pr_read_keys() num_keys values Stefan Hajnoczi
2025-11-27 6:59 ` Hannes Reinecke
2025-11-26 16:35 ` [PATCH 2/4] nvme: " Stefan Hajnoczi
2025-11-27 7:02 ` Hannes Reinecke
2025-11-26 16:35 ` [PATCH 3/4] block: add IOC_PR_READ_KEYS ioctl Stefan Hajnoczi
2025-11-26 18:06 ` kernel test robot
2025-11-27 7:07 ` Hannes Reinecke
2025-11-29 14:32 ` Krzysztof Kozlowski
2025-12-01 15:06 ` Stefan Hajnoczi
2025-12-01 16:26 ` Krzysztof Kozlowski
2025-12-01 18:36 ` Stefan Hajnoczi [this message]
2025-12-01 15:14 ` Stefan Hajnoczi
2025-12-01 16:27 ` Krzysztof Kozlowski
2025-11-29 14:31 ` Krzysztof Kozlowski
2025-11-26 16:36 ` [PATCH 4/4] block: add IOC_PR_READ_RESERVATION ioctl Stefan Hajnoczi
2025-11-27 7:07 ` Hannes Reinecke
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=20251201183621.GA919572@fedora \
--to=stefanha@redhat.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=axboe@kernel.dk \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=michael.christie@oracle.com \
--cc=sagi@grimberg.me \
/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.