From: James Bottomley <jejb@linux.ibm.com>
To: Deepak R Varma <drv@mailo.com>, Hannes Reinecke <hare@suse.de>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Saurabh Singh Sengar <ssengar@microsoft.com>,
Praveen Kumar <kumarpraveen@linux.microsoft.com>
Subject: Re: [PATCH RESEND] scsi: libfc: Use refcount_* APIs for reference count management
Date: Wed, 01 Mar 2023 14:28:49 -0500 [thread overview]
Message-ID: <cfe11fadc3d3e61ce6c7d6f00e1e427edea8a4e3.camel@linux.ibm.com> (raw)
In-Reply-To: <Y/+hVSSFgeV+yPhY@ubun2204.myguest.virtualbox.org>
On Thu, 2023-03-02 at 00:32 +0530, Deepak R Varma wrote:
> The atomic_t API based object reference counter management is prone
> to counter value overflows, object use-after-free issues and to
> return puzzling values. The improved refcount_t APIs are designed to
> address these known issues with atomic_t reference counter
> management. This white paper [1] has detailed reasons for moving from
> atomic_t to refcount_t APIs. Hence replace the atomic_* based
> implementation by its refcount_* based equivalent.
> The issue is identified using atomic_as_refcounter.cocci Coccinelle
> semantic patch script.
>
> [1] https://arxiv.org/pdf/1710.06175.pdf
Citing long whitepapers in support of a patch isn't helpful to time
pressed reviewers, particularly when it's evident you didn't understand
the paper you cite. The argument in the paper for replacing atomics
with refcounts can be summarized as: if a user can cause a counter
overflow in an atomic_t simply by performing some action from userspace
then that represents a source of potential overflow attacks on the
kernel which should be mitigated by replacing the atomic_t in question
with a refcount_t which is overflow resistant.
What's missing from the quoted changelog is a justification of how a
user could cause an overflow in the ex_refcnt atomic_t.
James
next prev parent reply other threads:[~2023-03-01 19:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-01 19:02 [PATCH RESEND] scsi: libfc: Use refcount_* APIs for reference count management Deepak R Varma
2023-03-01 19:28 ` James Bottomley [this message]
2023-03-01 19:53 ` Deepak R Varma
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=cfe11fadc3d3e61ce6c7d6f00e1e427edea8a4e3.camel@linux.ibm.com \
--to=jejb@linux.ibm.com \
--cc=drv@mailo.com \
--cc=hare@suse.de \
--cc=kumarpraveen@linux.microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=ssengar@microsoft.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox