All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitalii Demianets <vitas@nppfactor.kiev.ua>
To: "Hans J. Koch" <hjk@hansjkoch.de>
Cc: Cong Ding <dinggnu@gmail.com>,
	linux-kernel@vger.kernel.org,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v2] drivers/uio/uio_pdrv_genirq.c: Fix memory freeing issues
Date: Thu, 6 Dec 2012 11:11:38 +0200	[thread overview]
Message-ID: <201212061111.39057.vitas@nppfactor.kiev.ua> (raw)
In-Reply-To: <20121206024101.GB7175@local>

On Thursday 06 December 2012 04:41:01 Hans J. Koch wrote:
> > @@ -63,7 +68,7 @@ static irqreturn_t uio_pdrv_genirq_handler(int irq, 
struct uio_info *dev_info)
> >  	 * remember the state so we can allow user space to enable it later.
> >  	 */
> >  
> > -	if (!test_and_set_bit(0, &priv->flags))
> > +	if (!test_and_set_bit(UIO_IRQ_DISABLED, &priv->flags))
> >  		disable_irq_nosync(irq);
> 
> That is not safe. That flag can only be changed by userspace, and if the
> userspace part is not running, the CPU on which the irq is pending will
> hang. 
> The handler has to disable the interrupt in any case.
> (The original version had the same problem, I know...)
> 

Perhaps I'm missing something here, but I don't see your point. If userspace 
is not (implicitly) calling uio_pdrv_genirq_irqcontrol() by writing to the 
device file, then on the first invocation of interrupt handler that IRQ is 
disabled by disable_irq_nosync() and that's the end of story - no more irqs, 
no problems. Until userspace writes non-zero to the device file, of course.

> >  	priv->uioinfo = uioinfo;
> >  	spin_lock_init(&priv->lock);
> > -	priv->flags = 0; /* interrupt is enabled to begin with */
> > +	/* interrupt is enabled to begin with */
> > +	priv->flags = uioinfo_alloced ? (1 << UIO_INFO_ALLOCED) : 0;
> 
> The comment doesn't describe the line it's supposed to comment.
> 

The comment draws attention to the fact that UIO_IRQ_DISABLED is not set 
initially, and this is done on purpose. Particularly it is done because of 
the potential problem you noted earlier - if userspace is never setting this 
flag, the interrupt handler will disable irq on the first invocation thanks 
to the absence of the flag (if(!test_and_set_bit(UIO_IRQ_DISABLED,...) will 
succeed).
So, I think we really need some comment explaining how the things are arranged 
here; after all even you haven't got the whole picture on the first glance.
Maybe the current wording of the comment is not the best. I've just left what 
was there before.

  reply	other threads:[~2012-12-06  9:11 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-27 17:29 [PATCH] drivers/uio/uio_pdrv_genirq.c: Fix memory leak & confusing labels Vitalii Demianets
2012-11-27 23:07 ` Hans J. Koch
2012-11-28  0:07   ` Cong Ding
2012-11-28  0:37     ` Hans J. Koch
2012-11-28  9:29       ` Cong Ding
2012-11-28 21:09         ` Hans J. Koch
2012-11-28  9:37       ` Vitalii Demianets
2012-11-28 21:14         ` Hans J. Koch
2012-11-29 11:47           ` [PATCH] drivers/uio/uio_pdrv_genirq.c: Fix memory freeing issues Vitalii Demianets
2012-12-04 21:04             ` Hans J. Koch
2012-12-05  9:22               ` [PATCH v2] " Vitalii Demianets
2012-12-06  2:41                 ` Hans J. Koch
2012-12-06  9:11                   ` Vitalii Demianets [this message]
2012-12-06 22:15                     ` Hans J. Koch
2012-12-07  9:41                       ` Vitalii Demianets
2012-12-07 13:51                         ` Vitalii Demianets
2012-12-07 15:00                           ` Vitalii Demianets
2012-12-07 23:47                             ` Hans J. Koch
2012-12-10  9:03                               ` Vitalii Demianets
2012-12-10  9:52                                 ` Hans J. Koch
2012-12-10 10:24                                   ` Vitalii Demianets
2012-12-10 22:37                                     ` Hans J. Koch
2012-12-11 10:47                                       ` Vitalii Demianets
2012-12-13 17:11                                         ` Hans J. Koch
2012-12-13 17:23                                           ` Vitalii Demianets
2012-12-13 17:34                                             ` Hans J. Koch
2012-12-13 18:00                                               ` Vitalii Demianets

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=201212061111.39057.vitas@nppfactor.kiev.ua \
    --to=vitas@nppfactor.kiev.ua \
    --cc=dinggnu@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hjk@hansjkoch.de \
    --cc=linux-kernel@vger.kernel.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.