All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yury Norov <yury.norov@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Bartosz Golaszewski <brgl@bgdev.pl>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org,
	Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Subject: Re: [PATCH 1/4] genirq/irq_sim: dispose of remaining mappings before removing the domain
Date: Tue, 15 Aug 2023 09:09:10 -0700	[thread overview]
Message-ID: <ZNujJhy9fmCFwwLK@yury-ThinkPad> (raw)
In-Reply-To: <ZNtVuUWTZa0gLwXz@smile.fi.intel.com>

On Tue, Aug 15, 2023 at 01:38:49PM +0300, Andy Shevchenko wrote:
> On Sat, Aug 12, 2023 at 09:44:54PM +0200, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > 
> > If the device providing simulated interrupts is unbound (real life
> > example: gpio-sim is disabled with users that didn't free their irqs)
> > and removes the simulated domain while interrupts are still requested,
> > we will hit memory issues when they are eventually freed and the
> > mappings destroyed in the process.
> > 
> > Specifically we'll access freed memory in __irq_domain_deactivate_irq().
> > 
> > Dispose of all mappings before removing the simulator domain.
> 
> ...
> 
> > +#include <linux/list.h>
> 
> Maybe ordered?
> 
> >  #include <linux/irq.h>
> >  #include <linux/irq_sim.h>
> >  #include <linux/irq_work.h>
> 
> ...
> 
> > @@ -16,12 +17,14 @@ struct irq_sim_work_ctx {
> >  	unsigned int		irq_count;
> >  	unsigned long		*pending;
> >  	struct irq_domain	*domain;
> > +	struct list_head	irqs;
> >  };
> >  
> >  struct irq_sim_irq_ctx {
> >  	int			irqnum;
> >  	bool			enabled;
> >  	struct irq_sim_work_ctx	*work_ctx;
> 
> > +	struct list_head	siblings;
> 
> You can reduce the code size by moving this to be the first member.
> Not sure about struct irq_sim_work_ctx, you can play with bloat-o-meter.

Pahole you meant?

  yury:linux$ pahole -C irq_sim_irq_ctx /sys/kernel/btf/vmlinux
  struct irq_sim_irq_ctx {
  	int                        irqnum;               /*     0     4 */
  	bool                       enabled;              /*     4     1 */
  
  	/* XXX 3 bytes hole, try to pack */
  
  	struct irq_sim_work_ctx *  work_ctx;             /*     8     8 */
  
  	/* size: 16, cachelines: 1, members: 3 */
  	/* sum members: 13, holes: 1, sum holes: 3 */
  	/* last cacheline: 16 bytes */
  };

In this particular case, there will be no hole because list head
position (16) will be aligned to sizeof(struct list_head) == 16.

But as Bartosz said in the other email, "it's just good practice
resulting from years of" kernel coding to have:
 - members declared strongly according to the logic of the code, and
   if no strong preference: 
 - list head be the first element of the structure, to let compiler
   avoid generating offsets when traversing lists;
 - put elements of greater size at the beginning, so no holes will be
   emitted like in the example above.

So I'd suggest:

  struct irq_sim_irq_ctx {
     struct list_head        siblings;
     struct irq_sim_work_ctx *work_ctx;
     int                     irqnum;
     bool                    enabled;
  }
  
Again, if there's NO ANY reason to have the irq number at the
beginning.

While here, I wonder, why irqnum is signed? Looking at the very first
random function in kernel/irq/irq_sim.c, I see that it's initialized
from a function returning unsigned value:

  static void irq_sim_handle_irq(struct irq_work *work)
  {
          struct irq_sim_work_ctx *work_ctx;
          unsigned int offset = 0;
          int irqnum;
  
          work_ctx = container_of(work, struct irq_sim_work_ctx, work);
  
          while (!bitmap_empty(work_ctx->pending, work_ctx->irq_count)) {
                  offset = find_next_bit(work_ctx->pending,
                                         work_ctx->irq_count, offset);
                  clear_bit(offset, work_ctx->pending);
                  irqnum = irq_find_mapping(work_ctx->domain, offset);
                  handle_simple_irq(irq_to_desc(irqnum));
          }
  }

Thanks,
Yury

  reply	other threads:[~2023-08-15 16:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-12 19:44 [PATCH 0/4] genirq/irq_sim: fix a use-after-free bug + some Bartosz Golaszewski
2023-08-12 19:44 ` [PATCH 1/4] genirq/irq_sim: dispose of remaining mappings before removing the domain Bartosz Golaszewski
2023-08-15 10:38   ` Andy Shevchenko
2023-08-15 16:09     ` Yury Norov [this message]
2023-08-15 16:53       ` Andy Shevchenko
2023-08-15 18:42       ` Bartosz Golaszewski
2023-08-15 18:38     ` Bartosz Golaszewski
2023-08-17  9:17       ` Andy Shevchenko
2023-08-21 21:15   ` Bartosz Golaszewski
2023-08-12 19:44 ` [PATCH 2/4] genirq/irq_sim: order includes alphabetically Bartosz Golaszewski
2023-08-15 10:39   ` Andy Shevchenko
2023-08-12 19:44 ` [PATCH 3/4] bitmap: define a cleanup function for bitmaps Bartosz Golaszewski
2023-08-14  1:02   ` Yury Norov
2023-08-14  7:13     ` Bartosz Golaszewski
2023-08-12 19:44 ` [PATCH 4/4] genirq/irq_sim: shrink code by using cleanup helpers Bartosz Golaszewski
2023-08-14  1:09   ` Yury Norov
2023-08-14  6:58     ` Bartosz Golaszewski

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=ZNujJhy9fmCFwwLK@yury-ThinkPad \
    --to=yury.norov@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bartosz.golaszewski@linaro.org \
    --cc=brgl@bgdev.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=tglx@linutronix.de \
    /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.