All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: linux-kernel@vger.kernel.org
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	Thierry Reding <thierry.reding@gmail.com>,
	Joey Gouly <joey.gouly@arm.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Hector Martin <marcan@marcan.st>, Sven Peter <sven@svenpeter.dev>,
	Alyssa Rosenzweig <alyssa@rosenzweig.io>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Andy Gross <agross@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-gpio@vger.kernel.org, linux-tegra@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, kernel-team@android.com
Subject: [PATCH 0/5] gpiolib: Handle immutable irq_chip structures
Date: Wed, 23 Feb 2022 15:44:00 +0000	[thread overview]
Message-ID: <20220223154405.54912-1-maz@kernel.org> (raw)

I recently realised that the gpiolib play ugly tricks on the
unsuspecting irq_chip structures by patching the callbacks.

Not only this breaks when an irq_chip structure is made const (which
really should be the default case), but it also forces this structure
to be copied at nauseam for each instance of the GPIO block, which is
a waste of memory.

My current approach is to add a new irq_chip flag (IRQCHIP_IMMUTABLE)
which does what it says on the tin: don't you dare writing there.
Gpiolib is further updated not to install its own callbacks, and it
becomes the responsibility of the driver to call into the gpiolib when
required. This is similar to what we do for other subsystems such as
PCI-MSI.

3 drivers are updated to this new model: M1, QC and Tegra, as I
actively use them (though Tegra is hosed at the moment), keeping a
single irq_chip structure, marking it const, and exposing the new
flag.

Nothing breaks, the volume of change is small, the memory usage goes
down and we have fewer callbacks that can be used as attack vectors.

Another approach was to let gpiolib provide its own irq_chip structure
and stack it, but:
- only a few drivers are hierarchy aware
- the diversity of interrupt flows makes it impractical

I'd welcome comments on the approach. If deemed acceptable, there are
another 300+ drivers to update! Not to mention the documentation. I
appreciate that this is a lot of potential changes, but the current
situation is messy.

Note that these patches are on top of irqchip-next, which contains
more constifying work.

	M.

Marc Zyngier (5):
  gpio: Don't fiddle with irqchips marked as immutable
  gpio: Expose the gpiochip_irq_re[ql]res helpers
  pinctrl: apple-gpio: Make the irqchip immutable
  pinctrl: msmgpio: Make the irqchip immutable
  gpio: tegra186: Make the irqchip immutable

 drivers/gpio/gpio-tegra186.c         | 33 ++++++++++++-----
 drivers/gpio/gpiolib.c               | 13 +++++--
 drivers/pinctrl/pinctrl-apple-gpio.c | 30 +++++++++-------
 drivers/pinctrl/qcom/pinctrl-msm.c   | 53 +++++++++++++++++-----------
 include/linux/gpio/driver.h          |  4 +++
 include/linux/irq.h                  |  2 ++
 kernel/irq/debugfs.c                 |  1 +
 7 files changed, 91 insertions(+), 45 deletions(-)

-- 
2.30.2


WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: linux-kernel@vger.kernel.org
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	Thierry Reding <thierry.reding@gmail.com>,
	Joey Gouly <joey.gouly@arm.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Hector Martin <marcan@marcan.st>, Sven Peter <sven@svenpeter.dev>,
	Alyssa Rosenzweig <alyssa@rosenzweig.io>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Andy Gross <agross@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-gpio@vger.kernel.org, linux-tegra@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, kernel-team@android.com
Subject: [PATCH 0/5] gpiolib: Handle immutable irq_chip structures
Date: Wed, 23 Feb 2022 15:44:00 +0000	[thread overview]
Message-ID: <20220223154405.54912-1-maz@kernel.org> (raw)

I recently realised that the gpiolib play ugly tricks on the
unsuspecting irq_chip structures by patching the callbacks.

Not only this breaks when an irq_chip structure is made const (which
really should be the default case), but it also forces this structure
to be copied at nauseam for each instance of the GPIO block, which is
a waste of memory.

My current approach is to add a new irq_chip flag (IRQCHIP_IMMUTABLE)
which does what it says on the tin: don't you dare writing there.
Gpiolib is further updated not to install its own callbacks, and it
becomes the responsibility of the driver to call into the gpiolib when
required. This is similar to what we do for other subsystems such as
PCI-MSI.

3 drivers are updated to this new model: M1, QC and Tegra, as I
actively use them (though Tegra is hosed at the moment), keeping a
single irq_chip structure, marking it const, and exposing the new
flag.

Nothing breaks, the volume of change is small, the memory usage goes
down and we have fewer callbacks that can be used as attack vectors.

Another approach was to let gpiolib provide its own irq_chip structure
and stack it, but:
- only a few drivers are hierarchy aware
- the diversity of interrupt flows makes it impractical

I'd welcome comments on the approach. If deemed acceptable, there are
another 300+ drivers to update! Not to mention the documentation. I
appreciate that this is a lot of potential changes, but the current
situation is messy.

Note that these patches are on top of irqchip-next, which contains
more constifying work.

	M.

Marc Zyngier (5):
  gpio: Don't fiddle with irqchips marked as immutable
  gpio: Expose the gpiochip_irq_re[ql]res helpers
  pinctrl: apple-gpio: Make the irqchip immutable
  pinctrl: msmgpio: Make the irqchip immutable
  gpio: tegra186: Make the irqchip immutable

 drivers/gpio/gpio-tegra186.c         | 33 ++++++++++++-----
 drivers/gpio/gpiolib.c               | 13 +++++--
 drivers/pinctrl/pinctrl-apple-gpio.c | 30 +++++++++-------
 drivers/pinctrl/qcom/pinctrl-msm.c   | 53 +++++++++++++++++-----------
 include/linux/gpio/driver.h          |  4 +++
 include/linux/irq.h                  |  2 ++
 kernel/irq/debugfs.c                 |  1 +
 7 files changed, 91 insertions(+), 45 deletions(-)

-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2022-02-23 15:44 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-23 15:44 Marc Zyngier [this message]
2022-02-23 15:44 ` [PATCH 0/5] gpiolib: Handle immutable irq_chip structures Marc Zyngier
2022-02-23 15:44 ` [PATCH 1/5] gpio: Don't fiddle with irqchips marked as immutable Marc Zyngier
2022-02-23 15:44   ` Marc Zyngier
2022-02-23 17:48   ` Jeffrey Hugo
2022-02-23 17:48     ` Jeffrey Hugo
2022-02-23 18:14     ` Marc Zyngier
2022-02-23 18:14       ` Marc Zyngier
2022-02-24 16:51   ` Thierry Reding
2022-02-24 16:51     ` Thierry Reding
2022-02-26 10:32     ` Marc Zyngier
2022-02-26 10:32       ` Marc Zyngier
2022-02-23 15:44 ` [PATCH 2/5] gpio: Expose the gpiochip_irq_re[ql]res helpers Marc Zyngier
2022-02-23 15:44   ` Marc Zyngier
2022-02-23 15:44 ` [PATCH 3/5] pinctrl: apple-gpio: Make the irqchip immutable Marc Zyngier
2022-02-23 15:44   ` Marc Zyngier
2022-02-23 15:44 ` [PATCH 4/5] pinctrl: msmgpio: " Marc Zyngier
2022-02-23 15:44   ` Marc Zyngier
2022-02-23 15:44 ` [PATCH 5/5] gpio: tegra186: " Marc Zyngier
2022-02-23 15:44   ` Marc Zyngier
2022-02-24 16:40 ` [PATCH 0/5] gpiolib: Handle immutable irq_chip structures Thierry Reding
2022-02-24 16:40   ` Thierry Reding
2022-02-24 17:42   ` Marc Zyngier
2022-02-24 17:42     ` Marc Zyngier
2022-03-04 17:19     ` Marc Zyngier
2022-03-04 17:19       ` Marc Zyngier
2022-03-15  0:44 ` Linus Walleij
2022-03-15  0:44   ` Linus Walleij
2022-03-15  9:35   ` Marc Zyngier
2022-03-15  9:35     ` Marc Zyngier
2022-03-24 22:30     ` Linus Walleij
2022-03-24 22:30       ` Linus Walleij

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=20220223154405.54912-1-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=agross@kernel.org \
    --cc=alyssa@rosenzweig.io \
    --cc=bjorn.andersson@linaro.org \
    --cc=brgl@bgdev.pl \
    --cc=joey.gouly@arm.com \
    --cc=jonathanh@nvidia.com \
    --cc=kernel-team@android.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=marcan@marcan.st \
    --cc=sven@svenpeter.dev \
    --cc=tglx@linutronix.de \
    --cc=thierry.reding@gmail.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 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.