mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Deepak R Varma <drv@mailo.com>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jirislaby@kernel.org>,
	linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Saurabh Singh Sengar <ssengar@microsoft.com>,
	Praveen Kumar <kumarpraveen@linux.microsoft.com>,
	Deepak R Varma <drv@mailo.com>
Subject: [PATCH v3 1/2] tty: serial: dz: convert atomic_* to refcount_* APIs for map_guard
Date: Sat, 24 Dec 2022 22:03:48 +0530	[thread overview]
Message-ID: <d85c7441b96ce387d9010142efc3469d53b6aedc.1671898144.git.drv@mailo.com> (raw)
In-Reply-To: <cover.1671898144.git.drv@mailo.com>

The refcount_* APIs are designed to address known issues with the
atomic_t APIs for reference counting. They provide following distinct
advantages
   - protect the reference counters from overflow/underflow
   - avoid use-after-free errors
   - provide improved memory ordering guarantee schemes
   - neater and safer.
Hence, replace the atomic_* APIs by their equivalent refcount_t
API functions.

This patch proposal address the following warnings generated by
the atomic_as_refcounter.cocci coccinelle script
atomic_add_return(-1, ...)

Signed-off-by: Deepak R Varma <drv@mailo.com>
---
Please Note:
   1. The patch is compile tested using dec_station.defconfig for MIPS architecture.
   2. This patch should be applied before patch 2/2 of this series due to
      dependency.

Changes in v3:
   1. Include the individual patches in a series and highlight dependency.
      Feedback provided by gregkh@linuxfoundation.org

Changes in v2:
   1. Separate the combined change into one variable per patch as
      suggested by gregkh@linuxfoundation.org
   2. There was additional feedback on validating the change as it appeared to
      modify the existing logic. However, I found that the logic does not
      change with the proposed refcount_* APIs used in this change. Hence that
      feedback is not applied in this version.



 drivers/tty/serial/dz.c | 23 +++++++++--------------
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/drivers/tty/serial/dz.c b/drivers/tty/serial/dz.c
index 6b7ed7f2f3ca..b70edc248f8b 100644
--- a/drivers/tty/serial/dz.c
+++ b/drivers/tty/serial/dz.c
@@ -47,6 +47,7 @@
 #include <linux/tty_flip.h>

 #include <linux/atomic.h>
+#include <linux/refcount.h>
 #include <linux/io.h>
 #include <asm/bootinfo.h>

@@ -75,7 +76,7 @@ struct dz_port {

 struct dz_mux {
 	struct dz_port		dport[DZ_NB_PORT];
-	atomic_t		map_guard;
+	refcount_t		map_guard;
 	atomic_t		irq_guard;
 	int			initialised;
 };
@@ -662,13 +663,11 @@ static const char *dz_type(struct uart_port *uport)
 static void dz_release_port(struct uart_port *uport)
 {
 	struct dz_mux *mux = to_dport(uport)->mux;
-	int map_guard;

 	iounmap(uport->membase);
 	uport->membase = NULL;

-	map_guard = atomic_add_return(-1, &mux->map_guard);
-	if (!map_guard)
+	if (refcount_dec_and_test(&mux->map_guard))
 		release_mem_region(uport->mapbase, dec_kn_slot_size);
 }

@@ -687,23 +686,19 @@ static int dz_map_port(struct uart_port *uport)
 static int dz_request_port(struct uart_port *uport)
 {
 	struct dz_mux *mux = to_dport(uport)->mux;
-	int map_guard;
 	int ret;

-	map_guard = atomic_add_return(1, &mux->map_guard);
-	if (map_guard == 1) {
-		if (!request_mem_region(uport->mapbase, dec_kn_slot_size,
-					"dz")) {
-			atomic_add(-1, &mux->map_guard);
-			printk(KERN_ERR
-			       "dz: Unable to reserve MMIO resource\n");
+	refcount_inc(&mux->map_guard);
+	if (refcount_read(&mux->map_guard) == 1) {
+		if (!request_mem_region(uport->mapbase, dec_kn_slot_size, "dz")) {
+			refcount_dec(&mux->map_guard);
+			printk(KERN_ERR "dz: Unable to reserve MMIO resource\n");
 			return -EBUSY;
 		}
 	}
 	ret = dz_map_port(uport);
 	if (ret) {
-		map_guard = atomic_add_return(-1, &mux->map_guard);
-		if (!map_guard)
+		if (refcount_dec_and_test(&mux->map_guard))
 			release_mem_region(uport->mapbase, dec_kn_slot_size);
 		return ret;
 	}
--
2.34.1




WARNING: multiple messages have this Message-ID
From: Deepak R Varma <drv@mailo.com>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jirislaby@kernel.org>,
	linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Saurabh Singh Sengar <ssengar@microsoft.com>,
	Praveen Kumar <kumarpraveen@linux.microsoft.com>,
	Deepak R Varma <drv@mailo.com>
Subject: [PATCH v4 1/2] tty: serial: dz: convert atomic_* to refcount_* APIs for map_guard
Date: Mon, 26 Dec 2022 11:51:16 +0530	[thread overview]
Message-ID: <d85c7441b96ce387d9010142efc3469d53b6aedc.1671898144.git.drv@mailo.com> (raw)
Message-ID: <20221226062116.CdXVRfTZNzuIrImp-QhiP1TOVftmtiVaxaiXCtVzBqY@z> (raw)
In-Reply-To: <cover.1671898144.git.drv@mailo.com>

The refcount_* APIs are designed to address known issues with the
atomic_t APIs for reference counting. They provide following distinct
advantages
   - protect the reference counters from overflow/underflow
   - avoid use-after-free errors
   - provide improved memory ordering guarantee schemes
   - neater and safer.
Hence, replace the atomic_* APIs by their equivalent refcount_t
API functions.

This patch proposal address the following warnings generated by
the atomic_as_refcounter.cocci coccinelle script
atomic_add_return(-1, ...)

Signed-off-by: Deepak R Varma <drv@mailo.com>
---
Please Note:
   1. The patch is compile tested using dec_station.defconfig for MIPS architecture.
   2. This patch should be applied before patch 2/2 of this series due to
      dependency.

Changes in v4:
   1. None.

Changes in v3:
   1. Include the individual patches in a series and highlight dependency.
      Feedback provided by gregkh@linuxfoundation.org

Changes in v2:
   1. Separate the combined change into one variable per patch as
      suggested by gregkh@linuxfoundation.org
   2. There was additional feedback on validating the change as it appeared to
      modify the existing logic. However, I found that the logic does not
      change with the proposed refcount_* APIs used in this change. Hence that
      feedback is not applied in this version.



 drivers/tty/serial/dz.c | 23 +++++++++--------------
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/drivers/tty/serial/dz.c b/drivers/tty/serial/dz.c
index 6b7ed7f2f3ca..b70edc248f8b 100644
--- a/drivers/tty/serial/dz.c
+++ b/drivers/tty/serial/dz.c
@@ -47,6 +47,7 @@
 #include <linux/tty_flip.h>

 #include <linux/atomic.h>
+#include <linux/refcount.h>
 #include <linux/io.h>
 #include <asm/bootinfo.h>

@@ -75,7 +76,7 @@ struct dz_port {

 struct dz_mux {
 	struct dz_port		dport[DZ_NB_PORT];
-	atomic_t		map_guard;
+	refcount_t		map_guard;
 	atomic_t		irq_guard;
 	int			initialised;
 };
@@ -662,13 +663,11 @@ static const char *dz_type(struct uart_port *uport)
 static void dz_release_port(struct uart_port *uport)
 {
 	struct dz_mux *mux = to_dport(uport)->mux;
-	int map_guard;

 	iounmap(uport->membase);
 	uport->membase = NULL;

-	map_guard = atomic_add_return(-1, &mux->map_guard);
-	if (!map_guard)
+	if (refcount_dec_and_test(&mux->map_guard))
 		release_mem_region(uport->mapbase, dec_kn_slot_size);
 }

@@ -687,23 +686,19 @@ static int dz_map_port(struct uart_port *uport)
 static int dz_request_port(struct uart_port *uport)
 {
 	struct dz_mux *mux = to_dport(uport)->mux;
-	int map_guard;
 	int ret;

-	map_guard = atomic_add_return(1, &mux->map_guard);
-	if (map_guard == 1) {
-		if (!request_mem_region(uport->mapbase, dec_kn_slot_size,
-					"dz")) {
-			atomic_add(-1, &mux->map_guard);
-			printk(KERN_ERR
-			       "dz: Unable to reserve MMIO resource\n");
+	refcount_inc(&mux->map_guard);
+	if (refcount_read(&mux->map_guard) == 1) {
+		if (!request_mem_region(uport->mapbase, dec_kn_slot_size, "dz")) {
+			refcount_dec(&mux->map_guard);
+			printk(KERN_ERR "dz: Unable to reserve MMIO resource\n");
 			return -EBUSY;
 		}
 	}
 	ret = dz_map_port(uport);
 	if (ret) {
-		map_guard = atomic_add_return(-1, &mux->map_guard);
-		if (!map_guard)
+		if (refcount_dec_and_test(&mux->map_guard))
 			release_mem_region(uport->mapbase, dec_kn_slot_size);
 		return ret;
 	}
--
2.34.1




  reply	other threads:[~2022-12-24 16:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-24 16:32 [PATCH v3 0/2] tty: serial: dz: convert atomic_* to refcount_* Deepak R Varma
2022-12-24 16:33 ` Deepak R Varma [this message]
2022-12-26  6:21   ` [PATCH v4 1/2] tty: serial: dz: convert atomic_* to refcount_* APIs for map_guard Deepak R Varma
2023-01-03  8:59   ` Jiri Slaby
2023-01-03 10:05     ` Deepak R Varma
2023-01-04  8:28       ` Greg Kroah-Hartman
2023-01-04  8:59         ` Deepak R Varma
2023-01-10  6:19     ` Deepak R Varma
2023-01-10  7:27       ` Reshetova, Elena
2023-01-10  7:47         ` Deepak R Varma
2023-01-10  7:57           ` Greg Kroah-Hartman
2022-12-24 16:34 ` [PATCH 2/2] tty: serial: dz: convert atomic_* to refcount_* APIs for irq_guard Deepak R Varma
2022-12-26  6:21   ` [PATCH v4 " Deepak R Varma
2023-01-03  9:00   ` Jiri Slaby
2023-01-03 10:09     ` Deepak R Varma
2023-01-04  8:28       ` Greg Kroah-Hartman
2023-01-04  9:00         ` Deepak R Varma
2022-12-26  6:20 ` [PATCH v4 0/2] tty: serial: dz: convert atomic_* to refcount_* 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=d85c7441b96ce387d9010142efc3469d53b6aedc.1671898144.git.drv@mailo.com \
    --to=drv@mailo.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=kumarpraveen@linux.microsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=macro@orcam.me.uk \
    --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

all inboxes | Powered by JetHome®