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 <[email protected]>
---
Please Note:
1. The patch is compile tested using dec_station.defconfig for MIPS architecture.
2. This patch should be applied after patch 1/2 of this series due to
dependency.
Changes in v3:
1. Include the individual patches in a series and highlight dependency.
Feedback provided by [email protected]
Changes in v2:
1. Separate the combined change into one variable per patch as
suggested by [email protected]
drivers/tty/serial/dz.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/tty/serial/dz.c b/drivers/tty/serial/dz.c
index b70edc248f8b..0aa59a9beeb7 100644
--- a/drivers/tty/serial/dz.c
+++ b/drivers/tty/serial/dz.c
@@ -46,7 +46,6 @@
#include <linux/tty.h>
#include <linux/tty_flip.h>
-#include <linux/atomic.h>
#include <linux/refcount.h>
#include <linux/io.h>
#include <asm/bootinfo.h>
@@ -77,7 +76,7 @@ struct dz_port {
struct dz_mux {
struct dz_port dport[DZ_NB_PORT];
refcount_t map_guard;
- atomic_t irq_guard;
+ refcount_t irq_guard;
int initialised;
};
@@ -400,18 +399,16 @@ static int dz_startup(struct uart_port *uport)
struct dz_port *dport = to_dport(uport);
struct dz_mux *mux = dport->mux;
unsigned long flags;
- int irq_guard;
int ret;
u16 tmp;
- irq_guard = atomic_add_return(1, &mux->irq_guard);
- if (irq_guard != 1)
+ refcount_inc(&mux->irq_guard);
+ if (refcount_read(&mux->irq_guard) != 1)
return 0;
- ret = request_irq(dport->port.irq, dz_interrupt,
- IRQF_SHARED, "dz", mux);
+ ret = request_irq(dport->port.irq, dz_interrupt, IRQF_SHARED, "dz", mux);
if (ret) {
- atomic_add(-1, &mux->irq_guard);
+ refcount_dec(&mux->irq_guard);
printk(KERN_ERR "dz: Cannot get IRQ %d!\n", dport->port.irq);
return ret;
}
@@ -441,15 +438,13 @@ static void dz_shutdown(struct uart_port *uport)
struct dz_port *dport = to_dport(uport);
struct dz_mux *mux = dport->mux;
unsigned long flags;
- int irq_guard;
u16 tmp;
spin_lock_irqsave(&dport->port.lock, flags);
dz_stop_tx(&dport->port);
spin_unlock_irqrestore(&dport->port.lock, flags);
- irq_guard = atomic_add_return(-1, &mux->irq_guard);
- if (!irq_guard) {
+ if (refcount_dec_and_test(&mux->irq_guard)) {
/* Disable interrupts. */
tmp = dz_in(dport, DZ_CSR);
tmp &= ~(DZ_RIE | DZ_TIE);
--
2.34.1
On 26. 12. 22, 7:21, Deepak R Varma wrote:
> 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, ...)
...
> --- a/drivers/tty/serial/dz.c
> +++ b/drivers/tty/serial/dz.c
...
> @@ -400,18 +399,16 @@ static int dz_startup(struct uart_port *uport)
> struct dz_port *dport = to_dport(uport);
> struct dz_mux *mux = dport->mux;
> unsigned long flags;
> - int irq_guard;
> int ret;
> u16 tmp;
>
> - irq_guard = atomic_add_return(1, &mux->irq_guard);
> - if (irq_guard != 1)
> + refcount_inc(&mux->irq_guard);
> + if (refcount_read(&mux->irq_guard) != 1)
> return 0;
>
> - ret = request_irq(dport->port.irq, dz_interrupt,
> - IRQF_SHARED, "dz", mux);
> + ret = request_irq(dport->port.irq, dz_interrupt, IRQF_SHARED, "dz", mux);
How is this related to the above described change?
--
js
suse labs
On Tue, Jan 03, 2023 at 10:00:48AM +0100, Jiri Slaby wrote:
> On 26. 12. 22, 7:21, Deepak R Varma wrote:
> > 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, ...)
> ...
> > --- a/drivers/tty/serial/dz.c
> > +++ b/drivers/tty/serial/dz.c
> ...
> > @@ -400,18 +399,16 @@ static int dz_startup(struct uart_port *uport)
> > struct dz_port *dport = to_dport(uport);
> > struct dz_mux *mux = dport->mux;
> > unsigned long flags;
> > - int irq_guard;
> > int ret;
> > u16 tmp;
> >
> > - irq_guard = atomic_add_return(1, &mux->irq_guard);
> > - if (irq_guard != 1)
> > + refcount_inc(&mux->irq_guard);
> > + if (refcount_read(&mux->irq_guard) != 1)
> > return 0;
> >
> > - ret = request_irq(dport->port.irq, dz_interrupt,
> > - IRQF_SHARED, "dz", mux);
> > + ret = request_irq(dport->port.irq, dz_interrupt, IRQF_SHARED, "dz", mux);
>
> How is this related to the above described change?
No, it is not. My apologies. I must have joined the lines for improved readability
and forgot to revert. I will restore this in next revision based on the feedback
on the other patch of this series. OR I can include this change in the current
change log as a "while at it..." statement. Would you advise me?
Thank you,
./drv
>
> --
> js
> suse labs
>
On Tue, Jan 03, 2023 at 03:39:17PM +0530, Deepak R Varma wrote:
> On Tue, Jan 03, 2023 at 10:00:48AM +0100, Jiri Slaby wrote:
> > On 26. 12. 22, 7:21, Deepak R Varma wrote:
> > > 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, ...)
> > ...
> > > --- a/drivers/tty/serial/dz.c
> > > +++ b/drivers/tty/serial/dz.c
> > ...
> > > @@ -400,18 +399,16 @@ static int dz_startup(struct uart_port *uport)
> > > struct dz_port *dport = to_dport(uport);
> > > struct dz_mux *mux = dport->mux;
> > > unsigned long flags;
> > > - int irq_guard;
> > > int ret;
> > > u16 tmp;
> > >
> > > - irq_guard = atomic_add_return(1, &mux->irq_guard);
> > > - if (irq_guard != 1)
> > > + refcount_inc(&mux->irq_guard);
> > > + if (refcount_read(&mux->irq_guard) != 1)
> > > return 0;
> > >
> > > - ret = request_irq(dport->port.irq, dz_interrupt,
> > > - IRQF_SHARED, "dz", mux);
> > > + ret = request_irq(dport->port.irq, dz_interrupt, IRQF_SHARED, "dz", mux);
> >
> > How is this related to the above described change?
>
> No, it is not. My apologies. I must have joined the lines for improved readability
> and forgot to revert. I will restore this in next revision based on the feedback
> on the other patch of this series. OR I can include this change in the current
> change log as a "while at it..." statement. Would you advise me?
NEVER have a "while at it..." change as part of a commit unless it is
relevant to the main change being made. You know better...
thanks,
greg k-h
On Wed, Jan 04, 2023 at 09:28:50AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 03, 2023 at 03:39:17PM +0530, Deepak R Varma wrote:
> > On Tue, Jan 03, 2023 at 10:00:48AM +0100, Jiri Slaby wrote:
> > > On 26. 12. 22, 7:21, Deepak R Varma wrote:
> > > > + ret = request_irq(dport->port.irq, dz_interrupt, IRQF_SHARED, "dz", mux);
> > >
> > > How is this related to the above described change?
> >
> > No, it is not. My apologies. I must have joined the lines for improved readability
> > and forgot to revert. I will restore this in next revision based on the feedback
> > on the other patch of this series. OR I can include this change in the current
> > change log as a "while at it..." statement. Would you advise me?
>
> NEVER have a "while at it..." change as part of a commit unless it is
> relevant to the main change being made. You know better...
Sounds very good. Thank you for the advise. I will revert the change in the next
revision.
Thank you,
./drv
>
> thanks,
>
> greg k-h