* Re: [PATCH v5 05/14] iio: light: lm3533-als: Remove redundant pdata helpers
From: Johan Hovold @ 2026-07-03 9:55 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
dri-devel, linux-leds, devicetree, linux-kernel, linux-iio,
linux-fbdev
In-Reply-To: <20260617080031.99156-6-clamor95@gmail.com>
On Wed, Jun 17, 2026 at 11:00:22AM +0300, Svyatoslav Ryhel wrote:
> The lm3533_als_set_input_mode() and lm3533_als_set_resistor() functions
> are used only in lm3533_als_setup(). Incorporate their code into
> lm3533_als_setup() directly to simplify driver readability.
That's a debatable claim.
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> drivers/iio/light/lm3533-als.c | 56 ++++++++++------------------------
> 1 file changed, 16 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/iio/light/lm3533-als.c b/drivers/iio/light/lm3533-als.c
> index a9af8e2b965f..69bac1b202f1 100644
> --- a/drivers/iio/light/lm3533-als.c
> +++ b/drivers/iio/light/lm3533-als.c
> -static int lm3533_als_setup(struct lm3533_als *als,
> - const struct lm3533_als_platform_data *pdata)
> -{
> - int ret;
> -
> - ret = lm3533_als_set_input_mode(als, pdata->pwm_mode);
> + pdata->r_select);
> if (ret)
> - return ret;
> -
> - /* ALS input is always high impedance in PWM-mode. */
> - if (!pdata->pwm_mode) {
> - ret = lm3533_als_set_resistor(als, pdata->r_select);
> - if (ret)
> - return ret;
> - }
> + return dev_err_probe(dev, ret, "failed to set resistor\n");
> return 0;
> }
There's nothing hard to read about the above. To the contrary the logic
is more obvious this way.
You also remove the high-impedance comment for no good reason.
Johan
^ permalink raw reply
* Re: [PATCH v5 04/14] mfd: lm3533: Pass only regmap and light sensor presence to child devices
From: Johan Hovold @ 2026-07-03 9:50 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
dri-devel, linux-leds, devicetree, linux-kernel, linux-iio,
linux-fbdev
In-Reply-To: <20260617080031.99156-5-clamor95@gmail.com>
On Wed, Jun 17, 2026 at 11:00:21AM +0300, Svyatoslav Ryhel wrote:
> Instead of passing the entire lm3533 core data structure, only pass the
> regmap and the light sensor presence flag to child devices.
Again, why?
Johan
^ permalink raw reply
* Re: [PATCH v5 01/14] dt-bindings: leds: Document TI LM3533 LED controller
From: Johan Hovold @ 2026-07-03 9:49 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
dri-devel, linux-leds, devicetree, linux-kernel, linux-iio,
linux-fbdev
In-Reply-To: <20260617080031.99156-2-clamor95@gmail.com>
On Wed, Jun 17, 2026 at 11:00:18AM +0300, Svyatoslav Ryhel wrote:
> Document the LM3533 - a complete power source for backlight, keypad and
> indicator LEDs in smartphone handsets. The high-voltage inductive boost
> converter provides the power for two series LED strings display backlight
> and keypad functions.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Reviewed-by: Jonathan Cameron <jic23@kernel.org> #for light sensor
> Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org> #for backlight
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + led-controller@36 {
> + compatible = "ti,lm3533";
> + reg = <0x36>;
> +
> + enable-gpios = <&gpio 110 GPIO_ACTIVE_HIGH>;
> + vin-supply = <&vdd_3v3_bat>;
> +
> + ti,boost-ovp-microvolt = <24000000>;
> + ti,boost-freq-hz = <500000>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + backlight@0 {
> + compatible = "ti,lm3533-backlight";
> + reg = <0>;
> +
> + default-brightness = <113>;
> +
> + led-max-microamp = <23400>;
> + led-sources = <0 1>;
> + };
> +
> + led@2 {
> + compatible = "ti,lm3533-leds";
> + reg = <2>;
> +
> + led-max-microamp = <23400>;
> + led-sources = <0 1>;
> + };
> +
> + led@4 {
> + compatible = "ti,lm3533-leds";
> + reg = <4>;
> +
> + led-max-microamp = <23400>;
> + led-sources = <2>;
> + };
> +
> + led@5 {
> + compatible = "ti,lm3533-leds";
> + reg = <5>;
> +
> + led-max-microamp = <23400>;
> + led-sources = <3 4>;
> + };
> +
> + light-sensor {
Doesn't the binding (or dts) checker complain about this node not having
an address?
> + compatible = "ti,lm3533-als";
> +
> + interrupt-parent = <&gpio>;
> + interrupts = <80 IRQ_TYPE_LEVEL_LOW>;
> +
> + ti,pwm-mode;
> + };
> + };
> + };
> +...
Johan
^ permalink raw reply
* Re: [PATCH v5 02/14] mfd: lm3533: Remove driver specific regmap wrappers
From: Johan Hovold @ 2026-07-03 9:44 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
dri-devel, linux-leds, devicetree, linux-kernel, linux-iio,
linux-fbdev
In-Reply-To: <20260617080031.99156-3-clamor95@gmail.com>
On Wed, Jun 17, 2026 at 11:00:19AM +0300, Svyatoslav Ryhel wrote:
> Remove driver-specific regmap wrappers in favor of using regmap helpers
> directly.
The commit message should explain why you think this is a good idea.
Based on a quick look you lose the errnos that were logged on errors and
also the register debugging provided by those helpers.
Johan
^ permalink raw reply
* Re: [PATCH v5 00/14] mfd: lm3533: convert to OF bindings, improve support
From: Svyatoslav Ryhel @ 2026-07-03 8:50 UTC (permalink / raw)
To: Lee Jones
Cc: Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <20260702161828.GB2108533@google.com>
чт, 2 лип. 2026 р. о 19:18 Lee Jones <lee@kernel.org> пише:
>
> On Wed, 17 Jun 2026, Svyatoslav Ryhel wrote:
>
> > Convert LM3533 to OF bindings, add missing VIN supply, add support for
> > setting mapping mode and LED sources based on device tree.
> >
> > ---
> > Changes in v2:
> >
> > schema
> > - maximum led sources for leds set to 4
> > - anyOf > oneOf in ALS
> > - improved ALS descriptions
> > - adjusted example
> > drivers
> > - dropped devm convertion of irq and mfd helpers
> > - all als configuration moved into lm3533_als_setup
> > - added regulator/consumer.h
> > - lm3533_bl_setup set before sysfs_create_group in backlight
> > - added check if LVLED is valid
> > - LM3533_REG_OUTPUT_CONF1 > LM3533_REG_OUTPUT_CONF2 for LVLED4 and LVLED5
>
> This set looks good to me now.
>
> Let me know when you have all of the Acks and I'll merge it via MFD.
>
Hello there!
Jonathan and Daniel added their Reviewed-by for IIO and backlight
subsystems, so I assume that should be all required.
Best regards,
Svyatoslav R.
> --
> Lee Jones
^ permalink raw reply
* Re: [PATCH v5 05/14] iio: light: lm3533-als: Remove redundant pdata helpers
From: Jonathan Cameron @ 2026-07-03 0:57 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, David Lechner, Nuno Sá,
Andy Shevchenko, Helge Deller, Johan Hovold, dri-devel,
linux-leds, devicetree, linux-kernel, linux-iio, linux-fbdev
In-Reply-To: <20260617080031.99156-6-clamor95@gmail.com>
On Wed, 17 Jun 2026 11:00:22 +0300
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> The lm3533_als_set_input_mode() and lm3533_als_set_resistor() functions
> are used only in lm3533_als_setup(). Incorporate their code into
> lm3533_als_setup() directly to simplify driver readability.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
LGTM
Reviewed-by: Jonathan Cameron <jic23@kernel.org>
^ permalink raw reply
* Re: [PATCH 13/13] mm/mremap: convert mremap code to use vma_flags_t
From: Lorenzo Stoakes @ 2026-07-02 16:31 UTC (permalink / raw)
To: Lance Yang
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, hughd, vbabka, rppt,
surenb, mhocko, jannh, pfalcato, kees, perex, tiwai, linux-mips,
linux-kernel, linuxppc-dev, dri-devel, etnaviv, linux-arm-kernel,
linux-samsung-soc, intel-gfx, linux-arm-msm, freedreno, nouveau,
linux-rockchip, linux-tegra, virtualization, intel-xe, xen-devel,
linux-fbdev, linux-aio, linux-fsdevel, linux-mm, linux-sound
In-Reply-To: <2f36a2da-0686-485f-b4b9-ae699bef4fd4@linux.dev>
On Fri, Jul 03, 2026 at 12:17:29AM +0800, Lance Yang wrote:
>
>
> On 2026/7/3 00:07, Lorenzo Stoakes wrote:
> > On Thu, Jul 02, 2026 at 09:49:47PM +0800, Lance Yang wrote:
> > >
> > > On Mon, Jun 29, 2026 at 08:25:36PM +0100, Lorenzo Stoakes wrote:
> > > > Replace use of the legacy vm_flags_t flags with vma_flags_t values
> > > > throughout the mremap logic.
> > > >
> > > > Additionally update comments to reflect the changes to be consistent.
> > > >
> > > > No functional change intended.
> > > >
> > > > Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> > > > ---
> > >
> > > The vm_flags_set() cases below spell out vma_start_write(), but the
> > > vm_flags_clear() cases don't?
> >
> > Yep as I said elsewhere, implicitly taking the lock is terrible and me doing
> > this is completely on purpose to get rid of that :)
> >
> > But I haven't been clear enough clearly, so I should put the argument as to why
> > that's ok in the commit message.
> >
> > Will do so on respin.
>
> Makes sense, thanks for spelling it out! A short changelog note
> should clear it up for me :D
Yeah absolutely, that's necessary and was an oversight on my part, will correct!
Thanks for your great review here, much appreciated! :)
>
> [...]
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH v5 0/2] backlight: Add SY7758 6-channel High Efficiency LED Driver support
From: Lee Jones @ 2026-07-02 16:31 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Neil Armstrong
Cc: dri-devel, linux-leds, devicetree, linux-kernel, linux-fbdev,
KancyJoe, Krzysztof Kozlowski
In-Reply-To: <20260529-topic-sm8650-ayaneo-pocket-s2-sy7758-v5-0-03aacd49747c@linaro.org>
On Fri, 29 May 2026 21:23:07 +0200, Neil Armstrong wrote:
> Implement support for the Silergy SY7758 6-channel High Efficiency LED Driver
> used for backlight brightness control in the Ayaneo Pocket S2 dual-DSI panel.
Applied, thanks!
[1/2] dt-bindings: leds: backlight: document the SY7758 6-channel High Efficiency LED Driver
commit: 2019a2a7268f6f7387f052110558b9f90b500324
[2/2] backlight: Add SY7758 6-channel High Efficiency LED Driver support
commit: 110d67699a430daf0316f941254c46221e3f0914
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v5 00/14] mfd: lm3533: convert to OF bindings, improve support
From: Lee Jones @ 2026-07-02 16:18 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <20260617080031.99156-1-clamor95@gmail.com>
On Wed, 17 Jun 2026, Svyatoslav Ryhel wrote:
> Convert LM3533 to OF bindings, add missing VIN supply, add support for
> setting mapping mode and LED sources based on device tree.
>
> ---
> Changes in v2:
>
> schema
> - maximum led sources for leds set to 4
> - anyOf > oneOf in ALS
> - improved ALS descriptions
> - adjusted example
> drivers
> - dropped devm convertion of irq and mfd helpers
> - all als configuration moved into lm3533_als_setup
> - added regulator/consumer.h
> - lm3533_bl_setup set before sysfs_create_group in backlight
> - added check if LVLED is valid
> - LM3533_REG_OUTPUT_CONF1 > LM3533_REG_OUTPUT_CONF2 for LVLED4 and LVLED5
This set looks good to me now.
Let me know when you have all of the Acks and I'll merge it via MFD.
--
Lee Jones
^ permalink raw reply
* Re: [PATCH 13/13] mm/mremap: convert mremap code to use vma_flags_t
From: Lance Yang @ 2026-07-02 16:17 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, hughd, vbabka, rppt,
surenb, mhocko, jannh, pfalcato, kees, perex, tiwai, linux-mips,
linux-kernel, linuxppc-dev, dri-devel, etnaviv, linux-arm-kernel,
linux-samsung-soc, intel-gfx, linux-arm-msm, freedreno, nouveau,
linux-rockchip, linux-tegra, virtualization, intel-xe, xen-devel,
linux-fbdev, linux-aio, linux-fsdevel, linux-mm, linux-sound
In-Reply-To: <akaJx8Zt8kazlrjq@lucifer>
On 2026/7/3 00:07, Lorenzo Stoakes wrote:
> On Thu, Jul 02, 2026 at 09:49:47PM +0800, Lance Yang wrote:
>>
>> On Mon, Jun 29, 2026 at 08:25:36PM +0100, Lorenzo Stoakes wrote:
>>> Replace use of the legacy vm_flags_t flags with vma_flags_t values
>>> throughout the mremap logic.
>>>
>>> Additionally update comments to reflect the changes to be consistent.
>>>
>>> No functional change intended.
>>>
>>> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>>> ---
>>
>> The vm_flags_set() cases below spell out vma_start_write(), but the
>> vm_flags_clear() cases don't?
>
> Yep as I said elsewhere, implicitly taking the lock is terrible and me doing
> this is completely on purpose to get rid of that :)
>
> But I haven't been clear enough clearly, so I should put the argument as to why
> that's ok in the commit message.
>
> Will do so on respin.
Makes sense, thanks for spelling it out! A short changelog note
should clear it up for me :D
[...]
^ permalink raw reply
* Re: [PATCH v5 02/14] mfd: lm3533: Remove driver specific regmap wrappers
From: Lee Jones @ 2026-07-02 16:12 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Svyatoslav Ryhel, Daniel Thompson, Jingoo Han, Pavel Machek,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <ajJ30lHG5lEXri7I@ashevche-desk.local>
On Wed, 17 Jun 2026, Andy Shevchenko wrote:
> On Wed, Jun 17, 2026 at 11:00:19AM +0300, Svyatoslav Ryhel wrote:
> > Remove driver-specific regmap wrappers in favor of using regmap helpers
> > directly.
>
> OK, let's go with this variant.
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
>
> Some side notes below for the record.
>
> ...
>
> > struct lm3533_led *led = to_lm3533_led(led_cdev);
> > unsigned enable;
>
> Oh, besides using the old way of declaring unsigned int, it most likely
> just needs to be kstrtobool().
>
> > u8 reg;
> > - u8 mask;
> > - u8 val;
> > int ret;
> >
> > if (kstrtouint(buf, 0, &enable))
> > return -EINVAL;
>
> We should unshadow error codes (it may return more than -EINVAL).
Right, this masks -ERANGE.
We should fix that.
> > reg = lm3533_led_get_lv_reg(led, LM3533_REG_CTRLBANK_BCONF_BASE);
> > - mask = LM3533_REG_CTRLBANK_BCONF_ALS_EN_MASK;
> >
> > - if (enable)
> > - val = mask;
> > - else
> > - val = 0;
> > -
>
> ...
>
> > - if (kstrtou8(buf, 0, &val))
> > + if (kstrtou32(buf, 0, &val))
> > return -EINVAL;
>
> Like in the previous case we should unshadow error codes.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
--
Lee Jones
^ permalink raw reply
* Re: [PATCH 13/13] mm/mremap: convert mremap code to use vma_flags_t
From: Lorenzo Stoakes @ 2026-07-02 16:07 UTC (permalink / raw)
To: Lance Yang
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, hughd, vbabka, rppt,
surenb, mhocko, jannh, pfalcato, kees, perex, tiwai, linux-mips,
linux-kernel, linuxppc-dev, dri-devel, etnaviv, linux-arm-kernel,
linux-samsung-soc, intel-gfx, linux-arm-msm, freedreno, nouveau,
linux-rockchip, linux-tegra, virtualization, intel-xe, xen-devel,
linux-fbdev, linux-aio, linux-fsdevel, linux-mm, linux-sound
In-Reply-To: <20260702134947.25189-1-lance.yang@linux.dev>
On Thu, Jul 02, 2026 at 09:49:47PM +0800, Lance Yang wrote:
>
> On Mon, Jun 29, 2026 at 08:25:36PM +0100, Lorenzo Stoakes wrote:
> >Replace use of the legacy vm_flags_t flags with vma_flags_t values
> >throughout the mremap logic.
> >
> >Additionally update comments to reflect the changes to be consistent.
> >
> >No functional change intended.
> >
> >Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> >---
>
> The vm_flags_set() cases below spell out vma_start_write(), but the
> vm_flags_clear() cases don't?
Yep as I said elsewhere, implicitly taking the lock is terrible and me doing
this is completely on purpose to get rid of that :)
But I haven't been clear enough clearly, so I should put the argument as to why
that's ok in the commit message.
Will do so on respin.
>
> Thanks, Lance
>
> > mm/mremap.c | 38 ++++++++++++++++++++------------------
> > 1 file changed, 20 insertions(+), 18 deletions(-)
> >
> >diff --git a/mm/mremap.c b/mm/mremap.c
> >index 079a0ba0c4a7..0ea43302b7ed 100644
> >--- a/mm/mremap.c
> >+++ b/mm/mremap.c
> >@@ -68,7 +68,7 @@ struct vma_remap_struct {
> > bool populate_expand; /* mlock()'d expanded, must populate. */
> > enum mremap_type remap_type; /* expand, shrink, etc. */
> > bool mmap_locked; /* Is mm currently write-locked? */
> >- unsigned long charged; /* If VM_ACCOUNT, # pages to account. */
> >+ unsigned long charged; /* If VMA_ACCOUNT_BIT, # pgs to account */
> > bool vmi_needs_invalidate; /* Is the VMA iterator invalidated? */
> > };
> >
> >@@ -954,7 +954,7 @@ static unsigned long vrm_set_new_addr(struct vma_remap_struct *vrm)
> >
> > if (vrm->flags & MREMAP_FIXED)
> > map_flags |= MAP_FIXED;
> >- if (vma->vm_flags & VM_MAYSHARE)
> >+ if (vma_test(vma, VMA_MAYSHARE_BIT))
> > map_flags |= MAP_SHARED;
> >
> > res = get_unmapped_area(vma->vm_file, new_addr, vrm->new_len, pgoff,
> >@@ -976,7 +976,7 @@ static bool vrm_calc_charge(struct vma_remap_struct *vrm)
> > {
> > unsigned long charged;
> >
> >- if (!(vrm->vma->vm_flags & VM_ACCOUNT))
> >+ if (!vma_test(vrm->vma, VMA_ACCOUNT_BIT))
> > return true;
> >
> > /*
> >@@ -1003,7 +1003,7 @@ static bool vrm_calc_charge(struct vma_remap_struct *vrm)
> > */
> > static void vrm_uncharge(struct vma_remap_struct *vrm)
> > {
> >- if (!(vrm->vma->vm_flags & VM_ACCOUNT))
> >+ if (!vma_test(vrm->vma, VMA_ACCOUNT_BIT))
> > return;
> >
> > vm_unacct_memory(vrm->charged);
> >@@ -1023,7 +1023,7 @@ static void vrm_stat_account(struct vma_remap_struct *vrm,
> > struct vm_area_struct *vma = vrm->vma;
> >
> > vm_stat_account(mm, vma->vm_flags, pages);
> >- if (vma->vm_flags & VM_LOCKED)
> >+ if (vma_test(vma, VMA_LOCKED_BIT))
> > mm->locked_vm += pages;
> > }
> >
> >@@ -1167,7 +1167,7 @@ static void unmap_source_vma(struct vma_remap_struct *vrm)
> > * arose, in which case we _do_ wish to unmap the _new_ VMA, which means
> > * we actually _do_ want it be unaccounted.
> > */
> >- bool accountable_move = (vma->vm_flags & VM_ACCOUNT) &&
> >+ bool accountable_move = vma_test(vma, VMA_ACCOUNT_BIT) &&
> > !(vrm->flags & MREMAP_DONTUNMAP);
> >
> > /*
> >@@ -1186,7 +1186,7 @@ static void unmap_source_vma(struct vma_remap_struct *vrm)
> > * portions of the original VMA that remain.
> > */
> > if (accountable_move) {
> >- vm_flags_clear(vma, VM_ACCOUNT);
> >+ vma_clear_flags(vma, VMA_ACCOUNT_BIT);
This is called from move_vma() which holds the VMA write lock on vma.
> > /* We are about to split vma, so store the start/end. */
> > vm_start = vma->vm_start;
> > vm_end = vma->vm_end;
> >@@ -1211,8 +1211,8 @@ static void unmap_source_vma(struct vma_remap_struct *vrm)
> > * | |
> > * |-------------|
> > *
> >- * Having cleared VM_ACCOUNT from the whole VMA, after we unmap above
> >- * we'll end up with:
> >+ * Having cleared VMA_ACCOUNT_BIT from the whole VMA, after we unmap
> >+ * above we'll end up with:
> > *
> > * addr end
> > * | |
> >@@ -1232,13 +1232,15 @@ static void unmap_source_vma(struct vma_remap_struct *vrm)
> > if (vm_start < addr) {
> > struct vm_area_struct *prev = vma_prev(&vmi);
> >
> >- vm_flags_set(prev, VM_ACCOUNT); /* Acquires VMA lock. */
> >+ vma_start_write(prev);
> >+ vma_set_flags(prev, VMA_ACCOUNT_BIT);
> > }
> >
> > if (vm_end > end) {
> > struct vm_area_struct *next = vma_next(&vmi);
> >
> >- vm_flags_set(next, VM_ACCOUNT); /* Acquires VMA lock. */
> >+ vma_start_write(next);
> >+ vma_set_flags(next, VMA_ACCOUNT_BIT);
These need vma_start_write() as referencing other, unlocked VMAs.
> > }
> > }
> > }
> >@@ -1321,8 +1323,8 @@ static void dontunmap_complete(struct vma_remap_struct *vrm,
> > unsigned long old_start = vrm->vma->vm_start;
> > unsigned long old_end = vrm->vma->vm_end;
> >
> >- /* We always clear VM_LOCKED[ONFAULT] on the old VMA. */
> >- vm_flags_clear(vrm->vma, VM_LOCKED_MASK);
> >+ /* We always clear VMA_LOCKED[ONFAULT]_BIT on the old VMA. */
> >+ vma_clear_flags_mask(vrm->vma, VMA_LOCKED_MASK);
-
Same as above, called from move_vma() with VMA write lock held.
> >
> > /*
> > * anon_vma links of the old vma is no longer needed after its page
> >@@ -1758,14 +1760,14 @@ static int check_prep_vma(struct vma_remap_struct *vrm)
> > * based on the original. There are no known use cases for this
> > * behavior. As a result, fail such attempts.
> > */
> >- if (!old_len && !(vma->vm_flags & (VM_SHARED | VM_MAYSHARE))) {
> >+ if (!old_len && !vma_test_any(vma, VMA_SHARED_BIT, VMA_MAYSHARE_BIT)) {
> > pr_warn_once("%s (%d): attempted to duplicate a private mapping with mremap. This is not supported.\n",
> > current->comm, current->pid);
> > return -EINVAL;
> > }
> >
> > if ((vrm->flags & MREMAP_DONTUNMAP) &&
> >- (vma->vm_flags & (VM_DONTEXPAND | VM_PFNMAP)))
> >+ vma_test_any(vma, VMA_DONTEXPAND_BIT, VMA_PFNMAP_BIT))
> > return -EINVAL;
> >
> > /*
> >@@ -1795,7 +1797,7 @@ static int check_prep_vma(struct vma_remap_struct *vrm)
> > return 0;
> >
> > /* We are expanding and the VMA is mlock()'d so we need to populate. */
> >- if (vma->vm_flags & VM_LOCKED)
> >+ if (vma_test(vma, VMA_LOCKED_BIT))
> > vrm->populate_expand = true;
> >
> > /* Need to be careful about a growing mapping */
> >@@ -1803,10 +1805,10 @@ static int check_prep_vma(struct vma_remap_struct *vrm)
> > if (pgoff + (new_len >> PAGE_SHIFT) < pgoff)
> > return -EINVAL;
> >
> >- if (vma->vm_flags & (VM_DONTEXPAND | VM_PFNMAP))
> >+ if (vma_test_any(vma, VMA_DONTEXPAND_BIT, VMA_PFNMAP_BIT))
> > return -EFAULT;
> >
> >- if (!mlock_future_ok(mm, vma->vm_flags & VM_LOCKED, vrm->delta))
> >+ if (!mlock_future_ok(mm, vma_test(vma, VMA_LOCKED_BIT), vrm->delta))
> > return -EAGAIN;
> >
> > if (!may_expand_vm(mm, &vma->flags, vrm->delta >> PAGE_SHIFT))
> >--
> >2.54.0
> >
> >
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH v5 2/2] backlight: Add SY7758 6-channel High Efficiency LED Driver support
From: Neil Armstrong @ 2026-07-02 16:01 UTC (permalink / raw)
To: Lee Jones
Cc: Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, dri-devel,
linux-leds, devicetree, linux-kernel, linux-fbdev, KancyJoe
In-Reply-To: <20260702155157.GX2108533@google.com>
Hi Lee,
On 7/2/26 17:51, Lee Jones wrote:
> Please consider these:
>
> /* Sashiko Automation: Issues Found (4 Findings) */
>
> On Fri, 29 May 2026, Neil Armstrong wrote:
>
>> From: KancyJoe <kancy2333@outlook.com>
>>
>> Implement support for the Silergy SY7758 6-channel High Efficiency LED
>> Driver used for backlight brightness control in the Ayaneo Pocket S2
>> dual-DSI panel.
>>
>> Signed-off-by: KancyJoe <kancy2333@outlook.com>
>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
>> ---
>> drivers/video/backlight/Kconfig | 8 ++
>> drivers/video/backlight/Makefile | 1 +
>> drivers/video/backlight/sy7758.c | 259 +++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 268 insertions(+)
>>
>> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
>> index a7a3fbaf7c29..a1f70a2bae99 100644
>> --- a/drivers/video/backlight/Kconfig
>> +++ b/drivers/video/backlight/Kconfig
>> @@ -207,6 +207,14 @@ config BACKLIGHT_KTZ8866
>> Say Y to enable the backlight driver for the Kinetic KTZ8866
>> found in Xiaomi Mi Pad 5 series.
>>
>> +config BACKLIGHT_SY7758
>> + tristate "Backlight Driver for Silergy SY7758"
>> + depends on I2C
>> + select REGMAP_I2C
>> + help
>> + Say Y to enable the backlight driver for the Silergy SY7758
>> + backlight controller found in Ayaneo Pocket S2.
>> +
>> config BACKLIGHT_LM3533
>> tristate "Backlight Driver for LM3533"
>> depends on MFD_LM3533
>> diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
>> index 794820a98ed4..39ef588b1cf2 100644
>> --- a/drivers/video/backlight/Makefile
>> +++ b/drivers/video/backlight/Makefile
>> @@ -56,6 +56,7 @@ obj-$(CONFIG_BACKLIGHT_PWM) += pwm_bl.o
>> obj-$(CONFIG_BACKLIGHT_QCOM_WLED) += qcom-wled.o
>> obj-$(CONFIG_BACKLIGHT_RT4831) += rt4831-backlight.o
>> obj-$(CONFIG_BACKLIGHT_SAHARA) += kb3886_bl.o
>> +obj-$(CONFIG_BACKLIGHT_SY7758) += sy7758.o
>> obj-$(CONFIG_BACKLIGHT_SKY81452) += sky81452-backlight.o
>> obj-$(CONFIG_BACKLIGHT_TPS65217) += tps65217_bl.o
>> obj-$(CONFIG_BACKLIGHT_WM831X) += wm831x_bl.o
>> diff --git a/drivers/video/backlight/sy7758.c b/drivers/video/backlight/sy7758.c
>> new file mode 100644
>> index 000000000000..786589cb8df9
>> --- /dev/null
>> +++ b/drivers/video/backlight/sy7758.c
>> @@ -0,0 +1,259 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Silergy SY7758 6-channel High Efficiency LED Driver
>> + *
>> + * Copyright (C) 2025 Kancy Joe <kancy2333@outlook.com>
>> + * Copyright (C) 2026 Linaro Limited
>> + * Author: Neil Armstrong <neil.armstrong@linaro.org>
>> + */
>> +#include <linux/backlight.h>
>> +#include <linux/module.h>
>> +#include <linux/i2c.h>
>> +#include <linux/of.h>
>> +#include <linux/err.h>
>> +#include <linux/bits.h>
>> +#include <linux/delay.h>
>> +#include <linux/regmap.h>
>> +#include <linux/bitfield.h>
>> +#include <linux/gpio/consumer.h>
>> +#include <linux/regulator/consumer.h>
>> +
>> +#define DEFAULT_BRIGHTNESS 1024
>> +#define MAX_BRIGHTNESS 4080
>> +#define REG_MAX 0xAE
>> +
>> +/* Registers */
>> +#define REG_DEV_CTL 0x01
>> +#define REG_DEV_ID 0x03
>> +#define REG_BRT_12BIT_L 0x10
>> +#define REG_BRT_12BIT_H 0x11
>> +
>> +/* OTP memory */
>> +#define REG_OTP_CFG0 0xA0
>> +#define REG_OTP_CFG1 0xA1
>> +#define REG_OTP_CFG2 0xA2
>> +#define REG_OTP_CFG5 0xA5
>> +#define REG_OTP_CFG9 0xA9
>> +
>> +/* Fields */
>> +#define BIT_DEV_CTL_FAST BIT(7)
>> +#define MSK_DEV_CTL_BRT_MODE GENMASK(2, 1)
>> +#define BIT_DEV_CTL_BL_CTLB BIT(0)
>> +
>> +#define MSK_BRT_12BIT_L GENMASK(7, 0)
>> +#define MSK_BRT_12BIT_H GENMASK(3, 0)
>> +
>> +#define MSK_CFG0_CURRENT_LOW GENMASK(7, 0)
>> +
>> +#define BIT_CFG1_PDET_STDBY BIT(7)
>> +#define MSK_CFG1_CURRENT_MAX GENMASK(6, 4)
>> +#define MSK_CFG1_CURRENT_HIGH GENMASK(3, 0)
>> +
>> +#define BIT_CFG2_UVLO_EN BIT(5)
>> +#define BIT_CFG2_UVLO_TH BIT(4)
>> +#define BIT_CFG2_BL_ON BIT(3)
>> +#define BIT_CFG2_ISET_EN BIT(2)
>> +#define BIT_CFG2_BST_ESET_EN BIT(1)
>> +
>> +#define BIT_CFG5_PWM_DIRECT BIT(7)
>> +#define MSK_CFG5_PS_MODE GENMASK(6, 4)
>> +#define MSK_CFG5_PWM_FREQ GENMASK(3, 0)
>> +
>> +#define MSK_CFG9_VBST_MAX GENMASK(7, 5)
>> +#define BIT_CFG9_JUMP_EN BIT(4)
>> +#define MSK_CFG9_JUMP_TH GENMASK(3, 2)
>> +#define MSK_CFG9_JUMP_VOLTAGE GENMASK(1, 0)
>> +
>> +struct sy7758 {
>> + struct i2c_client *client;
>> + struct regmap *regmap;
>> + struct gpio_desc *gpio;
>> + struct backlight_device *bl;
>> +};
>> +
>> +static const struct regmap_config sy7758_regmap_config = {
>> + .reg_bits = 8,
>> + .val_bits = 8,
>> + .max_register = REG_MAX,
>> +};
>> +
>> +static int sy7758_backlight_update_status(struct backlight_device *backlight_dev)
>> +{
>> + struct sy7758 *sydev = bl_get_data(backlight_dev);
>> + unsigned int brightness = backlight_get_brightness(backlight_dev);
>> + int ret;
>> +
>> + ret = regmap_write(sydev->regmap, REG_BRT_12BIT_L,
>> + FIELD_PREP(MSK_BRT_12BIT_L,
>> + brightness & 0xff));
>> + if (ret)
>> + return ret;
>> +
>> + ret = regmap_write(sydev->regmap, REG_BRT_12BIT_H,
>> + FIELD_PREP(MSK_BRT_12BIT_H,
>> + (brightness >> 8) & 0xf));
>> + if (ret)
>> + return ret;
>> +
>> + return 0;
>> +}
>> +
>> +static const struct backlight_ops sy7758_backlight_ops = {
>> + .options = BL_CORE_SUSPENDRESUME,
>> + .update_status = sy7758_backlight_update_status,
>> +};
>
> [Severity: High]
> This driver sets the BL_CORE_SUSPENDRESUME option, which relies on the
> backlight core to blank and unblank the brightness on suspend and resume.
> However, if the system's power management cuts power to the vdd regulator
> during suspend, won't the device lose all the configuration state established
> in sy7758_init()?
This will never happen, if we don't disable the regulators they will stay on during system suspend.
>
> Because there are no standard pm_ops to re-apply this initialization sequence
> upon resume, it seems the backlight might operate with incorrect parameters or
> fail to turn on. Should this driver implement a resume callback to restore the
> volatile hardware configuration?
>
>
>
>> +
>> +static int sy7758_init(struct sy7758 *sydev)
>> +{
>> + int ret = 0;
>> +
>> + ret = regmap_write(sydev->regmap, REG_DEV_CTL,
>> + BIT_DEV_CTL_FAST | BIT_DEV_CTL_BL_CTLB |
>> + FIELD_PREP(MSK_DEV_CTL_BRT_MODE, 2));
>> + if (ret)
>> + return ret;
>> +
>> + ret = regmap_write(sydev->regmap, REG_BRT_12BIT_L,
>> + FIELD_PREP(MSK_BRT_12BIT_L,
>> + DEFAULT_BRIGHTNESS & 0xff));
>> + if (ret)
>> + return ret;
>> +
>> + ret = regmap_write(sydev->regmap, REG_BRT_12BIT_H,
>> + FIELD_PREP(MSK_BRT_12BIT_H,
>> + (DEFAULT_BRIGHTNESS >> 8)));
>> + if (ret)
>> + return ret;
>> +
>> + ret = regmap_write(sydev->regmap, REG_OTP_CFG5,
>> + FIELD_PREP(MSK_CFG5_PS_MODE, 6) |
>> + FIELD_PREP(MSK_CFG5_PWM_FREQ, 4));
>> + if (ret)
>> + return ret;
>> +
>> + ret = regmap_write(sydev->regmap, REG_OTP_CFG0,
>> + FIELD_PREP(MSK_CFG0_CURRENT_LOW, 85));
>> + if (ret)
>> + return ret;
>> +
>> + ret = regmap_write(sydev->regmap, REG_OTP_CFG1,
>> + BIT_CFG1_PDET_STDBY |
>> + FIELD_PREP(MSK_CFG1_CURRENT_MAX, 1) |
>> + FIELD_PREP(MSK_CFG1_CURRENT_HIGH, 10));
>> + if (ret)
>> + return ret;
>> +
>> + ret = regmap_write(sydev->regmap, REG_OTP_CFG9,
>> + FIELD_PREP(MSK_CFG9_VBST_MAX, 4));
>> + if (ret)
>> + return ret;
>> +
>> + ret = regmap_write(sydev->regmap, REG_OTP_CFG2,
>> + BIT_CFG2_BL_ON | BIT_CFG2_UVLO_EN);
>> + if (ret)
>> + return ret;
>> +
>> + return 0;
>> +}
>> +
>> +static int sy7758_probe(struct i2c_client *client)
>> +{
>> + struct backlight_properties props = { };
>> + struct device *dev = &client->dev;
>> + struct sy7758 *sydev;
>> + unsigned int dev_id;
>> + int ret;
>> +
>> + sydev = devm_kzalloc(dev, sizeof(*sydev), GFP_KERNEL);
>> + if (!sydev)
>> + return -ENOMEM;
>> +
>> + i2c_set_clientdata(client, sydev);
>> +
>> + /* Initialize regmap */
>> + sydev->client = client;
>> + sydev->regmap = devm_regmap_init_i2c(client, &sy7758_regmap_config);
>> + if (IS_ERR(sydev->regmap))
>> + return dev_err_probe(dev, PTR_ERR(sydev->regmap),
>> + "failed to init regmap\n");
>> +
>> + /* Get and enable regulator */
>> + ret = devm_regulator_get_enable(dev, "vdd");
>> + if (ret)
>> + return dev_err_probe(dev, ret, "failed to get regulator\n");
>> +
>> + fsleep(100);
>> +
>> + /* Get enable GPIO and set to high */
>> + sydev->gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_HIGH);
>> + if (IS_ERR(sydev->gpio))
>> + return dev_err_probe(dev, PTR_ERR(sydev->gpio),
>> + "failed to get enable GPIO\n");
>
> [Severity: Medium]
> Is it possible for the enable pin to be hardwired to a power rail on some
> hardware designs? Using devm_gpiod_get() makes this GPIO strictly mandatory
> and fails the probe if the enable-gpios property is absent in the Device Tree.
> Would devm_gpiod_get_optional() be more appropriate here?
>
This makes no sense, the enable gpio is required per the spec, and is required in the bindings.
>
> [Severity: High]
> The enable GPIO is asserted high here, but is there a mechanism to ensure it
> is explicitly driven low during driver removal or if the probe fails later?
This is not an issue, the enable is required to be high when operating the IC
which depends on vdd to be on. No need to put it back.
>
> If devres automatically disables the vdd regulator while the host is still
> driving the GPIO high, couldn't this back-power the chip through its internal
> ESD protection diodes and cause hardware damage? Using
> devm_add_action_or_reset() to drive the GPIO low before the regulator is
> disabled might prevent this.
No, spec says this won't happen and is safe.
>
>
>
>> +
>> + /* Let some time for HW to settle */
>> + fsleep(10000);
>> +
>> + /* try read and check device id */
>> + ret = regmap_read(sydev->regmap, REG_DEV_ID, &dev_id);
>> + if (ret < 0)
>> + return dev_err_probe(dev, ret, "failed to read device id\n");
>> + if (dev_id != 0x63) {
>> + dev_err(dev, "unexpected device id: 0x%02x\n", dev_id);
>> + return -ENODEV;
>> + }
>> +
>> + /* Initialize and set default brightness */
>> + ret = sy7758_init(sydev);
>> + if (ret)
>> + return ret;
>> +
>> + props.type = BACKLIGHT_RAW;
>> + props.max_brightness = MAX_BRIGHTNESS;
>> + props.brightness = DEFAULT_BRIGHTNESS;
>> + props.scale = BACKLIGHT_SCALE_LINEAR;
>> +
>> + sydev->bl = devm_backlight_device_register(dev, "sy7758-backlight",
>> + dev, sydev, &sy7758_backlight_ops,
>> + &props);
>> + if (IS_ERR(sydev->bl))
>> + return dev_err_probe(dev, PTR_ERR(sydev->bl),
>> + "failed to register backlight device\n");
>> +
>> + return backlight_update_status(sydev->bl);
>> +}
>> +
>> +static void sy7758_remove(struct i2c_client *client)
>> +{
>> + struct sy7758 *sydev = i2c_get_clientdata(client);
>> +
>> + backlight_disable(sydev->bl);
>> +}
>
> [Severity: Medium]
> Since the backlight was registered using devm_backlight_device_register(),
> devres will unregister the sysfs interface after sy7758_remove() returns.
this will never happen.
>
> Does this leave a race window where userspace could concurrently write to the
> sysfs brightness file and re-enable the hardware right after
> backlight_disable() turns it off?
>
>> +
>> +static const struct i2c_device_id sy7758_ids[] = {
>> + { "sy7758" },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(i2c, sy7758_ids);
>> +
>> +static const struct of_device_id sy7758_match_table[] = {
>> + { .compatible = "silergy,sy7758", },
>> + { },
>> +};
>> +MODULE_DEVICE_TABLE(of, sy7758_match_table);
>> +
>> +static struct i2c_driver sy7758_driver = {
>> + .driver = {
>> + .name = "sy7758",
>> + .of_match_table = sy7758_match_table,
>> + },
>> + .probe = sy7758_probe,
>> + .remove = sy7758_remove,
>> + .id_table = sy7758_ids,
>> +};
>> +
>> +module_i2c_driver(sy7758_driver);
>> +
>> +MODULE_DESCRIPTION("Silergy SY7758 Backlight Driver");
>> +MODULE_AUTHOR("Kancy Joe <kancy2333@outlook.com>");
>> +MODULE_AUTHOR("Neil Armstrong <neil.armstrong@linaro.org>");
>> +MODULE_LICENSE("GPL");
>>
>> --
>> 2.34.1
>>
>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH 12/13] mm/mprotect: convert mprotect code to use vma_flags_t
From: Lorenzo Stoakes @ 2026-07-02 15:53 UTC (permalink / raw)
To: Lance Yang
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, hughd, vbabka, rppt,
surenb, mhocko, jannh, pfalcato, kees, perex, tiwai, linux-mips,
linux-kernel, linuxppc-dev, dri-devel, etnaviv, linux-arm-kernel,
linux-samsung-soc, intel-gfx, linux-arm-msm, freedreno, nouveau,
linux-rockchip, linux-tegra, virtualization, intel-xe, xen-devel,
linux-fbdev, linux-aio, linux-fsdevel, linux-mm, linux-sound
In-Reply-To: <20260701160917.91435-1-lance.yang@linux.dev>
On Thu, Jul 02, 2026 at 12:09:17AM +0800, Lance Yang wrote:
>
> On Mon, Jun 29, 2026 at 08:25:35PM +0100, Lorenzo Stoakes wrote:
> >Replace use of the legacy vm_flags_t flags with vma_flags_t values
> >throughout the mprotect logic.
> >
> >Note that we retain the legacy vm_flags_t bit shifting code in
> >do_mprotect_key(), deferring a vma_flags_t approach to this for the time
> >being.
> >
> >Additionally update comments to reflect the changes to be consistent.
> >
> >No functional change intended.
> >
> >Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> >---
> > mm/mprotect.c | 16 ++++++++--------
> > 1 file changed, 8 insertions(+), 8 deletions(-)
> >
> >diff --git a/mm/mprotect.c b/mm/mprotect.c
> >index 9cbf932b028c..c9504b2a2525 100644
> >--- a/mm/mprotect.c
> >+++ b/mm/mprotect.c
> >@@ -40,7 +40,7 @@
> >
> > static bool maybe_change_pte_writable(struct vm_area_struct *vma, pte_t pte)
> > {
> >- if (WARN_ON_ONCE(!(vma->vm_flags & VM_WRITE)))
> >+ if (WARN_ON_ONCE(!vma_test(vma, VMA_WRITE_BIT)))
> > return false;
> >
> > /* Don't touch entries that are not even readable. */
> >@@ -97,7 +97,7 @@ static bool can_change_shared_pte_writable(struct vm_area_struct *vma,
> > bool can_change_pte_writable(struct vm_area_struct *vma, unsigned long addr,
> > pte_t pte)
> > {
> >- if (!(vma->vm_flags & VM_SHARED))
> >+ if (!vma_test(vma, VMA_SHARED_BIT))
> > return can_change_private_pte_writable(vma, addr, pte);
> >
> > return can_change_shared_pte_writable(vma, pte);
> >@@ -194,7 +194,7 @@ static __always_inline void set_write_prot_commit_flush_ptes(struct vm_area_stru
> > {
> > bool set_write;
> >
> >- if (vma->vm_flags & VM_SHARED) {
> >+ if (vma_test(vma, VMA_SHARED_BIT)) {
> > set_write = can_change_shared_pte_writable(vma, ptent);
> > prot_commit_flush_ptes(vma, addr, ptep, oldpte, ptent, nr_ptes,
> > /* idx = */ 0, set_write, tlb);
> >@@ -811,8 +811,8 @@ mprotect_fixup(struct vma_iterator *vmi, struct mmu_gather *tlb,
> > vm_unacct_memory(nrpages);
> >
> > /*
> >- * Private VM_LOCKED VMA becoming writable: trigger COW to avoid major
> >- * fault on access.
> >+ * Private VMA_LOCKED_BIT VMA becoming writable: trigger COW to avoid
> >+ * major fault on access.
> > */
> > if (vma_flags_test(&new_vma_flags, VMA_WRITE_BIT) &&
> > vma_flags_test(&old_vma_flags, VMA_LOCKED_BIT) &&
> >@@ -886,7 +886,7 @@ static int do_mprotect_pkey(unsigned long start, size_t len,
> > goto out;
> > start = vma->vm_start;
> > error = -EINVAL;
> >- if (!(vma->vm_flags & VM_GROWSDOWN))
> >+ if (!vma_test(vma, VMA_GROWSDOWN_BIT))
> > goto out;
> > } else {
> > if (vma->vm_start > start)
> >@@ -894,7 +894,7 @@ static int do_mprotect_pkey(unsigned long start, size_t len,
> > if (unlikely(grows & PROT_GROWSUP)) {
> > end = vma->vm_end;
> > error = -EINVAL;
> >- if (!(vma->vm_flags & VM_GROWSUP))
> >+ if (!vma_test(vma, VMA_GROWSUP_BIT))
>
> IIUC, should this be
>
> if (!vma_test_single_mask(vma, VMA_GROWSUP))
>
> instead?
>
> #elif defined(CONFIG_PARISC)
> #define VM_GROWSUP INIT_VM_FLAG(GROWSUP)
> ...
> #ifndef VM_GROWSUP
> #define VM_GROWSUP VM_NONE
> ...
>
> VM_GROWSUP is only defined as GROWSUP on parisc and becomes VM_NONE
> elsewhere. But VMA_GROWSUP_BIT is the raw ARCH_1 bit, which is also used
> for other arch-specific VMA flags:
>
> DECLARE_VMA_BIT_ALIAS(SAO, ARCH_1), /* Strong Access Ordering (powerpc) */
> DECLARE_VMA_BIT_ALIAS(GROWSUP, ARCH_1), /* parisc */
> DECLARE_VMA_BIT_ALIAS(SPARC_ADI, ARCH_1), /* sparc64 */
> DECLARE_VMA_BIT_ALIAS(ARM64_BTI, ARCH_1), /* arm64 */
> DECLARE_VMA_BIT_ALIAS(ARCH_CLEAR, ARCH_1), /* sparc64, arm64 */
> DECLARE_VMA_BIT_ALIAS(MAPPED_COPY, ARCH_1), /* !CONFIG_MMU */
>
> Other vma_test() changes look fine to me: just fixed INIT_VM_FLAG()
> masks matching their VMA_*_BIT :)
Thanks you're right, will fix!
Again I swear I ran claude on all of this so it's failing me here :)
>
> Cheers, Lance
>
> > goto out;
> > }
> > }
> >@@ -918,7 +918,7 @@ static int do_mprotect_pkey(unsigned long start, size_t len,
> > }
> >
> > /* Does the application expect PROT_READ to imply PROT_EXEC */
> >- if (rier && (vma->vm_flags & VM_MAYEXEC))
> >+ if (rier && vma_test(vma, VMA_MAYEXEC_BIT))
> > prot |= PROT_EXEC;
> >
> > /*
> >--
> >2.54.0
> >
> >
^ permalink raw reply
* Re: [PATCH v5 2/2] backlight: Add SY7758 6-channel High Efficiency LED Driver support
From: Lee Jones @ 2026-07-02 15:51 UTC (permalink / raw)
To: Neil Armstrong
Cc: Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, dri-devel,
linux-leds, devicetree, linux-kernel, linux-fbdev, KancyJoe
In-Reply-To: <20260529-topic-sm8650-ayaneo-pocket-s2-sy7758-v5-2-03aacd49747c@linaro.org>
Please consider these:
/* Sashiko Automation: Issues Found (4 Findings) */
On Fri, 29 May 2026, Neil Armstrong wrote:
> From: KancyJoe <kancy2333@outlook.com>
>
> Implement support for the Silergy SY7758 6-channel High Efficiency LED
> Driver used for backlight brightness control in the Ayaneo Pocket S2
> dual-DSI panel.
>
> Signed-off-by: KancyJoe <kancy2333@outlook.com>
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
> drivers/video/backlight/Kconfig | 8 ++
> drivers/video/backlight/Makefile | 1 +
> drivers/video/backlight/sy7758.c | 259 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 268 insertions(+)
>
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index a7a3fbaf7c29..a1f70a2bae99 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -207,6 +207,14 @@ config BACKLIGHT_KTZ8866
> Say Y to enable the backlight driver for the Kinetic KTZ8866
> found in Xiaomi Mi Pad 5 series.
>
> +config BACKLIGHT_SY7758
> + tristate "Backlight Driver for Silergy SY7758"
> + depends on I2C
> + select REGMAP_I2C
> + help
> + Say Y to enable the backlight driver for the Silergy SY7758
> + backlight controller found in Ayaneo Pocket S2.
> +
> config BACKLIGHT_LM3533
> tristate "Backlight Driver for LM3533"
> depends on MFD_LM3533
> diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
> index 794820a98ed4..39ef588b1cf2 100644
> --- a/drivers/video/backlight/Makefile
> +++ b/drivers/video/backlight/Makefile
> @@ -56,6 +56,7 @@ obj-$(CONFIG_BACKLIGHT_PWM) += pwm_bl.o
> obj-$(CONFIG_BACKLIGHT_QCOM_WLED) += qcom-wled.o
> obj-$(CONFIG_BACKLIGHT_RT4831) += rt4831-backlight.o
> obj-$(CONFIG_BACKLIGHT_SAHARA) += kb3886_bl.o
> +obj-$(CONFIG_BACKLIGHT_SY7758) += sy7758.o
> obj-$(CONFIG_BACKLIGHT_SKY81452) += sky81452-backlight.o
> obj-$(CONFIG_BACKLIGHT_TPS65217) += tps65217_bl.o
> obj-$(CONFIG_BACKLIGHT_WM831X) += wm831x_bl.o
> diff --git a/drivers/video/backlight/sy7758.c b/drivers/video/backlight/sy7758.c
> new file mode 100644
> index 000000000000..786589cb8df9
> --- /dev/null
> +++ b/drivers/video/backlight/sy7758.c
> @@ -0,0 +1,259 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Silergy SY7758 6-channel High Efficiency LED Driver
> + *
> + * Copyright (C) 2025 Kancy Joe <kancy2333@outlook.com>
> + * Copyright (C) 2026 Linaro Limited
> + * Author: Neil Armstrong <neil.armstrong@linaro.org>
> + */
> +#include <linux/backlight.h>
> +#include <linux/module.h>
> +#include <linux/i2c.h>
> +#include <linux/of.h>
> +#include <linux/err.h>
> +#include <linux/bits.h>
> +#include <linux/delay.h>
> +#include <linux/regmap.h>
> +#include <linux/bitfield.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/regulator/consumer.h>
> +
> +#define DEFAULT_BRIGHTNESS 1024
> +#define MAX_BRIGHTNESS 4080
> +#define REG_MAX 0xAE
> +
> +/* Registers */
> +#define REG_DEV_CTL 0x01
> +#define REG_DEV_ID 0x03
> +#define REG_BRT_12BIT_L 0x10
> +#define REG_BRT_12BIT_H 0x11
> +
> +/* OTP memory */
> +#define REG_OTP_CFG0 0xA0
> +#define REG_OTP_CFG1 0xA1
> +#define REG_OTP_CFG2 0xA2
> +#define REG_OTP_CFG5 0xA5
> +#define REG_OTP_CFG9 0xA9
> +
> +/* Fields */
> +#define BIT_DEV_CTL_FAST BIT(7)
> +#define MSK_DEV_CTL_BRT_MODE GENMASK(2, 1)
> +#define BIT_DEV_CTL_BL_CTLB BIT(0)
> +
> +#define MSK_BRT_12BIT_L GENMASK(7, 0)
> +#define MSK_BRT_12BIT_H GENMASK(3, 0)
> +
> +#define MSK_CFG0_CURRENT_LOW GENMASK(7, 0)
> +
> +#define BIT_CFG1_PDET_STDBY BIT(7)
> +#define MSK_CFG1_CURRENT_MAX GENMASK(6, 4)
> +#define MSK_CFG1_CURRENT_HIGH GENMASK(3, 0)
> +
> +#define BIT_CFG2_UVLO_EN BIT(5)
> +#define BIT_CFG2_UVLO_TH BIT(4)
> +#define BIT_CFG2_BL_ON BIT(3)
> +#define BIT_CFG2_ISET_EN BIT(2)
> +#define BIT_CFG2_BST_ESET_EN BIT(1)
> +
> +#define BIT_CFG5_PWM_DIRECT BIT(7)
> +#define MSK_CFG5_PS_MODE GENMASK(6, 4)
> +#define MSK_CFG5_PWM_FREQ GENMASK(3, 0)
> +
> +#define MSK_CFG9_VBST_MAX GENMASK(7, 5)
> +#define BIT_CFG9_JUMP_EN BIT(4)
> +#define MSK_CFG9_JUMP_TH GENMASK(3, 2)
> +#define MSK_CFG9_JUMP_VOLTAGE GENMASK(1, 0)
> +
> +struct sy7758 {
> + struct i2c_client *client;
> + struct regmap *regmap;
> + struct gpio_desc *gpio;
> + struct backlight_device *bl;
> +};
> +
> +static const struct regmap_config sy7758_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = REG_MAX,
> +};
> +
> +static int sy7758_backlight_update_status(struct backlight_device *backlight_dev)
> +{
> + struct sy7758 *sydev = bl_get_data(backlight_dev);
> + unsigned int brightness = backlight_get_brightness(backlight_dev);
> + int ret;
> +
> + ret = regmap_write(sydev->regmap, REG_BRT_12BIT_L,
> + FIELD_PREP(MSK_BRT_12BIT_L,
> + brightness & 0xff));
> + if (ret)
> + return ret;
> +
> + ret = regmap_write(sydev->regmap, REG_BRT_12BIT_H,
> + FIELD_PREP(MSK_BRT_12BIT_H,
> + (brightness >> 8) & 0xf));
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
> +static const struct backlight_ops sy7758_backlight_ops = {
> + .options = BL_CORE_SUSPENDRESUME,
> + .update_status = sy7758_backlight_update_status,
> +};
[Severity: High]
This driver sets the BL_CORE_SUSPENDRESUME option, which relies on the
backlight core to blank and unblank the brightness on suspend and resume.
However, if the system's power management cuts power to the vdd regulator
during suspend, won't the device lose all the configuration state established
in sy7758_init()?
Because there are no standard pm_ops to re-apply this initialization sequence
upon resume, it seems the backlight might operate with incorrect parameters or
fail to turn on. Should this driver implement a resume callback to restore the
volatile hardware configuration?
> +
> +static int sy7758_init(struct sy7758 *sydev)
> +{
> + int ret = 0;
> +
> + ret = regmap_write(sydev->regmap, REG_DEV_CTL,
> + BIT_DEV_CTL_FAST | BIT_DEV_CTL_BL_CTLB |
> + FIELD_PREP(MSK_DEV_CTL_BRT_MODE, 2));
> + if (ret)
> + return ret;
> +
> + ret = regmap_write(sydev->regmap, REG_BRT_12BIT_L,
> + FIELD_PREP(MSK_BRT_12BIT_L,
> + DEFAULT_BRIGHTNESS & 0xff));
> + if (ret)
> + return ret;
> +
> + ret = regmap_write(sydev->regmap, REG_BRT_12BIT_H,
> + FIELD_PREP(MSK_BRT_12BIT_H,
> + (DEFAULT_BRIGHTNESS >> 8)));
> + if (ret)
> + return ret;
> +
> + ret = regmap_write(sydev->regmap, REG_OTP_CFG5,
> + FIELD_PREP(MSK_CFG5_PS_MODE, 6) |
> + FIELD_PREP(MSK_CFG5_PWM_FREQ, 4));
> + if (ret)
> + return ret;
> +
> + ret = regmap_write(sydev->regmap, REG_OTP_CFG0,
> + FIELD_PREP(MSK_CFG0_CURRENT_LOW, 85));
> + if (ret)
> + return ret;
> +
> + ret = regmap_write(sydev->regmap, REG_OTP_CFG1,
> + BIT_CFG1_PDET_STDBY |
> + FIELD_PREP(MSK_CFG1_CURRENT_MAX, 1) |
> + FIELD_PREP(MSK_CFG1_CURRENT_HIGH, 10));
> + if (ret)
> + return ret;
> +
> + ret = regmap_write(sydev->regmap, REG_OTP_CFG9,
> + FIELD_PREP(MSK_CFG9_VBST_MAX, 4));
> + if (ret)
> + return ret;
> +
> + ret = regmap_write(sydev->regmap, REG_OTP_CFG2,
> + BIT_CFG2_BL_ON | BIT_CFG2_UVLO_EN);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
> +static int sy7758_probe(struct i2c_client *client)
> +{
> + struct backlight_properties props = { };
> + struct device *dev = &client->dev;
> + struct sy7758 *sydev;
> + unsigned int dev_id;
> + int ret;
> +
> + sydev = devm_kzalloc(dev, sizeof(*sydev), GFP_KERNEL);
> + if (!sydev)
> + return -ENOMEM;
> +
> + i2c_set_clientdata(client, sydev);
> +
> + /* Initialize regmap */
> + sydev->client = client;
> + sydev->regmap = devm_regmap_init_i2c(client, &sy7758_regmap_config);
> + if (IS_ERR(sydev->regmap))
> + return dev_err_probe(dev, PTR_ERR(sydev->regmap),
> + "failed to init regmap\n");
> +
> + /* Get and enable regulator */
> + ret = devm_regulator_get_enable(dev, "vdd");
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to get regulator\n");
> +
> + fsleep(100);
> +
> + /* Get enable GPIO and set to high */
> + sydev->gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_HIGH);
> + if (IS_ERR(sydev->gpio))
> + return dev_err_probe(dev, PTR_ERR(sydev->gpio),
> + "failed to get enable GPIO\n");
[Severity: Medium]
Is it possible for the enable pin to be hardwired to a power rail on some
hardware designs? Using devm_gpiod_get() makes this GPIO strictly mandatory
and fails the probe if the enable-gpios property is absent in the Device Tree.
Would devm_gpiod_get_optional() be more appropriate here?
[Severity: High]
The enable GPIO is asserted high here, but is there a mechanism to ensure it
is explicitly driven low during driver removal or if the probe fails later?
If devres automatically disables the vdd regulator while the host is still
driving the GPIO high, couldn't this back-power the chip through its internal
ESD protection diodes and cause hardware damage? Using
devm_add_action_or_reset() to drive the GPIO low before the regulator is
disabled might prevent this.
> +
> + /* Let some time for HW to settle */
> + fsleep(10000);
> +
> + /* try read and check device id */
> + ret = regmap_read(sydev->regmap, REG_DEV_ID, &dev_id);
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "failed to read device id\n");
> + if (dev_id != 0x63) {
> + dev_err(dev, "unexpected device id: 0x%02x\n", dev_id);
> + return -ENODEV;
> + }
> +
> + /* Initialize and set default brightness */
> + ret = sy7758_init(sydev);
> + if (ret)
> + return ret;
> +
> + props.type = BACKLIGHT_RAW;
> + props.max_brightness = MAX_BRIGHTNESS;
> + props.brightness = DEFAULT_BRIGHTNESS;
> + props.scale = BACKLIGHT_SCALE_LINEAR;
> +
> + sydev->bl = devm_backlight_device_register(dev, "sy7758-backlight",
> + dev, sydev, &sy7758_backlight_ops,
> + &props);
> + if (IS_ERR(sydev->bl))
> + return dev_err_probe(dev, PTR_ERR(sydev->bl),
> + "failed to register backlight device\n");
> +
> + return backlight_update_status(sydev->bl);
> +}
> +
> +static void sy7758_remove(struct i2c_client *client)
> +{
> + struct sy7758 *sydev = i2c_get_clientdata(client);
> +
> + backlight_disable(sydev->bl);
> +}
[Severity: Medium]
Since the backlight was registered using devm_backlight_device_register(),
devres will unregister the sysfs interface after sy7758_remove() returns.
Does this leave a race window where userspace could concurrently write to the
sysfs brightness file and re-enable the hardware right after
backlight_disable() turns it off?
> +
> +static const struct i2c_device_id sy7758_ids[] = {
> + { "sy7758" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, sy7758_ids);
> +
> +static const struct of_device_id sy7758_match_table[] = {
> + { .compatible = "silergy,sy7758", },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, sy7758_match_table);
> +
> +static struct i2c_driver sy7758_driver = {
> + .driver = {
> + .name = "sy7758",
> + .of_match_table = sy7758_match_table,
> + },
> + .probe = sy7758_probe,
> + .remove = sy7758_remove,
> + .id_table = sy7758_ids,
> +};
> +
> +module_i2c_driver(sy7758_driver);
> +
> +MODULE_DESCRIPTION("Silergy SY7758 Backlight Driver");
> +MODULE_AUTHOR("Kancy Joe <kancy2333@outlook.com>");
> +MODULE_AUTHOR("Neil Armstrong <neil.armstrong@linaro.org>");
> +MODULE_LICENSE("GPL");
>
> --
> 2.34.1
>
--
Lee Jones
^ permalink raw reply
* [PATCH] fb: omap2: dsi: do not copy isr table
From: Andreas Kemnade @ 2026-07-02 15:50 UTC (permalink / raw)
To: Helge Deller
Cc: linux-omap, linux-fbdev, dri-devel, linux-kernel, sashiko-bot,
Andreas Kemnade
To te able to unregister stuff from isrs, the corresponding table was
copied. Nobody seems to unregister stuff that way, so it does not help.
But there are stack-allocated objects passed to these isrs giving chances
of UAF of these objects if irqs are unregistered while they are handled,
so better do not copy that table.
Suggested-by: sashiko-bot@kernel.org
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
Fix for drm variant fo driver:
https://lore.kernel.org/lkml/20260702-dsi-uaf-v2-1-dbb4aa0f0b8e@kemnade.info/
---
drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
index 330d9fb7d2b0..d98db01fdd39 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
@@ -326,8 +326,6 @@ struct dsi_data {
spinlock_t irq_lock;
struct dsi_isr_tables isr_tables;
- /* space for a copy used by the interrupt handler */
- struct dsi_isr_tables isr_tables_copy;
int update_channel;
#ifdef DSI_PERF_MEASURE
@@ -838,15 +836,10 @@ static irqreturn_t omap_dsi_irq_handler(int irq, void *arg)
timer_delete(&dsi->te_timer);
#endif
- /* make a copy and unlock, so that isrs can unregister
- * themselves */
- memcpy(&dsi->isr_tables_copy, &dsi->isr_tables,
- sizeof(dsi->isr_tables));
+ dsi_handle_isrs(&dsi->isr_tables, irqstatus, vcstatus, ciostatus);
spin_unlock(&dsi->irq_lock);
- dsi_handle_isrs(&dsi->isr_tables_copy, irqstatus, vcstatus, ciostatus);
-
dsi_handle_irq_errors(dsidev, irqstatus, vcstatus, ciostatus);
dsi_collect_irq_stats(dsidev, irqstatus, vcstatus, ciostatus);
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260702-fbomap-uaf-fix-167ed8a8bf38
Best regards,
--
Andreas Kemnade <andreas@kemnade.info>
^ permalink raw reply related
* Re: [PATCH 11/13] mm/mlock: convert mlock code to use vma_flags_t
From: Lorenzo Stoakes @ 2026-07-02 15:47 UTC (permalink / raw)
To: Lance Yang
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, hughd, vbabka, rppt,
surenb, mhocko, jannh, pfalcato, kees, perex, tiwai, linux-mips,
linux-kernel, linuxppc-dev, dri-devel, etnaviv, linux-arm-kernel,
linux-samsung-soc, intel-gfx, linux-arm-msm, freedreno, nouveau,
linux-rockchip, linux-tegra, virtualization, intel-xe, xen-devel,
linux-fbdev, linux-aio, linux-fsdevel, linux-mm, linux-sound
In-Reply-To: <20260702132107.73727-1-lance.yang@linux.dev>
On Thu, Jul 02, 2026 at 09:21:07PM +0800, Lance Yang wrote:
>
> On Mon, Jun 29, 2026 at 08:25:34PM +0100, Lorenzo Stoakes wrote:
> >Replace use of the legacy vm_flags_t flags with vma_flags_t values
> >throughout the mlock logic.
> >
> >Additionally update comments to reflect the changes to be consistent.
> >
> >No functional change intended.
> >
> >Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> >---
>
> Nothing scary jumped out at me. Just one tiny nit below ;)
>
> [...]
> >@@ -466,24 +466,23 @@ static void mlock_vma_pages_range(struct vm_area_struct *vma,
> > */
> > static int mlock_fixup(struct vma_iterator *vmi, struct vm_area_struct *vma,
> > struct vm_area_struct **prev, unsigned long start,
> >- unsigned long end, vm_flags_t newflags)
> >+ unsigned long end, vma_flags_t *new_vma_flags)
> > {
> >- vma_flags_t new_vma_flags = legacy_to_vma_flags(newflags);
> > const vma_flags_t old_vma_flags = vma->flags;
> > struct mm_struct *mm = vma->vm_mm;
> > int nr_pages;
> > int ret = 0;
> >
> >- if (vma_flags_same_pair(&old_vma_flags, &new_vma_flags) ||
> >+ if (vma_flags_same_pair(&old_vma_flags, new_vma_flags) ||
> > vma_is_secretmem(vma) || !vma_supports_mlock(vma)) {
> > /*
> >- * Don't set VM_LOCKED or VM_LOCKONFAULT and don't count.
> >+ * Don't set VMA_LOCKED_BIT or VM_LOCKONFAULT and don't count.
>
> s/VM_LOCKONFAULT/VMA_LOCKONFAULT_BIT/
Ah yeah oops, will fix and respin! Good spot [and claude missed it ugh] :)
>
> Otherwise LGTM. Feel free to add:
>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
>
> > * For secretmem, don't allow the memory to be unlocked.
> > */
> > goto out;
> > }
> >
> >- vma = vma_modify_flags(vmi, *prev, vma, start, end, &new_vma_flags);
> >+ vma = vma_modify_flags(vmi, *prev, vma, start, end, new_vma_flags);
> > if (IS_ERR(vma)) {
> > ret = PTR_ERR(vma);
> > goto out;
> [...]
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH 10/13] mm/vma: convert miscellaneous uses of VMA flags in core mm
From: Lorenzo Stoakes @ 2026-07-02 15:46 UTC (permalink / raw)
To: Lance Yang
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, hughd, vbabka, rppt,
surenb, mhocko, jannh, pfalcato, kees, perex, tiwai, linux-mips,
linux-kernel, linuxppc-dev, dri-devel, etnaviv, linux-arm-kernel,
linux-samsung-soc, intel-gfx, linux-arm-msm, freedreno, nouveau,
linux-rockchip, linux-tegra, virtualization, intel-xe, xen-devel,
linux-fbdev, linux-aio, linux-fsdevel, linux-mm, linux-sound
In-Reply-To: <20260702131233.59026-1-lance.yang@linux.dev>
On Thu, Jul 02, 2026 at 09:12:33PM +0800, Lance Yang wrote:
>
> On Mon, Jun 29, 2026 at 08:25:33PM +0100, Lorenzo Stoakes wrote:
> >Update various uses of legacy flags in vma.c and mmap.c to the new
> >vma_flags_t type, updating comments alongside them to be consistent.
> >
> >Also update __install_special_mapping() to rearrange things slightly to
> >accommodate the changes.
> >
> >Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> >---
> [...]
> >diff --git a/mm/vma.c b/mm/vma.c
> >index b81c05e67a61..ab2ef0f04420 100644
> >--- a/mm/vma.c
> >+++ b/mm/vma.c
> >@@ -3417,23 +3417,27 @@ struct vm_area_struct *__install_special_mapping(
> > vm_flags_t vm_flags, void *priv,
> > const struct vm_operations_struct *ops)
> > {
> >- int ret;
> >+ vma_flags_t vma_flags = legacy_to_vma_flags(vm_flags);
> > struct vm_area_struct *vma;
> >+ int ret;
> >
> > vma = vm_area_alloc(mm);
> >- if (unlikely(vma == NULL))
> >+ if (unlikely(!vma))
> > return ERR_PTR(-ENOMEM);
> >
> >- vma_set_range(vma, addr, addr + len, 0);
> >- vm_flags |= vma_flags_to_legacy(mm->def_vma_flags) | VM_DONTEXPAND;
> >+ vma_flags_set_mask(&vma_flags, mm->def_vma_flags);
> >+ vma_flags_set(&vma_flags, VMA_DONTEXPAND_BIT);
> > if (pgtable_supports_soft_dirty())
> >- vm_flags |= VM_SOFTDIRTY;
> >- vm_flags_init(vma, vm_flags & ~VM_LOCKED_MASK);
> >+ vma_flags_set(&vma_flags, VMA_SOFTDIRTY_BIT);
> >+ vma_flags_clear_mask(&vma_flags, VMA_LOCKED_MASK);
> >+ vma->flags = vma_flags;
>
> Maybe worth a vma_flags_init() helper here to mirror vm_flags_init()?
> With this open-coded, we lose the soft-dirty WARN_ON_ONCE sanity check.
>
> Might be nicer to keep that check in one place ;)
I really hate all the VMA flag accessors, they conflate things horribly - we
should be explicitly taking VMA write locks when we need to (and often killable
ones actually) not assuming that a VMA flags accessor does (they should at most
assert).
This case is even more terribly egregious - you are setting flags at an
arbitrary time, why are we asserting something about softdirty?
You may update them as part of initialisation, maybe not. It's far from a
guarantee and feels like a lazy place to put it.
BUT obviously it's an oversight not to open code that here, so I'll update the
patch to do that!
I want VMA flags to be a clean stateless thing, other than the flags
themselves. Implicit, unrelated, asserts or lock acquisitions in general should
be done separately IMO.
>
> [...]
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH 08/13] mm: introduce vma_get_page_prot() and use it
From: Lorenzo Stoakes @ 2026-07-02 15:40 UTC (permalink / raw)
To: Lance Yang
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, hughd, vbabka, rppt,
surenb, mhocko, jannh, pfalcato, kees, perex, tiwai, linux-mips,
linux-kernel, linuxppc-dev, dri-devel, etnaviv, linux-arm-kernel,
linux-samsung-soc, intel-gfx, linux-arm-msm, freedreno, nouveau,
linux-rockchip, linux-tegra, virtualization, intel-xe, xen-devel,
linux-fbdev, linux-aio, linux-fsdevel, linux-mm, linux-sound
In-Reply-To: <20260702123845.95316-1-lance.yang@linux.dev>
On Thu, Jul 02, 2026 at 08:38:45PM +0800, Lance Yang wrote:
>
> On Mon, Jun 29, 2026 at 08:25:31PM +0100, Lorenzo Stoakes wrote:
> >There's a large number of vm_get_page_prot(vma->vm_flags) invocations. Make
> >life easier by introducing vma_get_page_prot() parameterised by the VMA.
> >
> >This also makes converting vm_get_page_prot() to vma_flags_t easier.
> >
> >Also update the userland VMA tests to reflect the change.
> >
> >No functional change intended.
> >
> >Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> >---
> > drivers/gpu/drm/drm_gem.c | 2 +-
> > drivers/gpu/drm/drm_gem_dma_helper.c | 2 +-
> > drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +-
> > drivers/gpu/drm/etnaviv/etnaviv_gem.c | 2 +-
> > drivers/gpu/drm/exynos/exynos_drm_gem.c | 6 +++---
> > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 12 ++++++------
> > drivers/gpu/drm/msm/msm_gem.c | 2 +-
> > drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
> > drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
> > drivers/gpu/drm/omapdrm/omap_gem.c | 6 +++---
> > drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 2 +-
> > drivers/gpu/drm/tegra/gem.c | 2 +-
> > drivers/gpu/drm/virtio/virtgpu_vram.c | 2 +-
> > drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 2 +-
> > drivers/gpu/drm/xe/xe_device.c | 2 +-
> > drivers/gpu/drm/xe/xe_mmio_gem.c | 2 +-
> > drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +-
> > drivers/video/fbdev/core/fb_io_fops.c | 2 +-
>
> One missed?
>
> drivers/gpu/drm/panthor/panthor_gem.c still has:
>
> vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
>
> Can use vma_get_page_prot(vma) too.
Oops! Will respin and update. Good spot!
>
> [...]
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH 06/13] mm/vma: convert vm_pgprot_modify() to use vma_flags_t and rename
From: Lorenzo Stoakes @ 2026-07-02 15:29 UTC (permalink / raw)
To: Lance Yang
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, hughd, vbabka, rppt,
surenb, mhocko, jannh, pfalcato, kees, perex, tiwai, linux-mips,
linux-kernel, linuxppc-dev, dri-devel, etnaviv, linux-arm-kernel,
linux-samsung-soc, intel-gfx, linux-arm-msm, freedreno, nouveau,
linux-rockchip, linux-tegra, virtualization, intel-xe, xen-devel,
linux-fbdev, linux-aio, linux-fsdevel, linux-mm, linux-sound
In-Reply-To: <20260702122116.65642-1-lance.yang@linux.dev>
On Thu, Jul 02, 2026 at 08:21:16PM +0800, Lance Yang wrote:
>
> On Mon, Jun 29, 2026 at 08:25:29PM +0100, Lorenzo Stoakes wrote:
> >Update vm_pgprot_modify() to use the new VMA flags type vma_flags_t, and
> >rename to vma_pgprot_modify() accordingly.
> >
> >This is part of the ongoing work to convert vm_flags_t to vma_flags_t, in
> >order to eliminate the arbitrary limit of the number of bits in a system
> >word on available VMA flags.
> >
> >Update VMA userland tests accordingly, updating vma_set_page_prot() to no
> >longer inline vma_pgprot_modify(), rather we can simply define
> >vma_pgprot_modify() as a static inline function and the tests will pick it
> >up from vma.h.
> >
> >No functional change intended.
> >
> >Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> >---
> [...]
> >diff --git a/mm/vma.h b/mm/vma.h
> >index bcf0c2773449..6a8abb8ae937 100644
> >--- a/mm/vma.h
> >+++ b/mm/vma.h
> >@@ -522,9 +522,11 @@ static inline bool vma_wants_manual_pte_write_upgrade(struct vm_area_struct *vma
> > }
> >
> > #ifdef CONFIG_MMU
> >-static inline pgprot_t vm_pgprot_modify(pgprot_t oldprot, vm_flags_t vm_flags)
> >+static inline pgprot_t vma_pgprot_modify(pgprot_t oldprot, vma_flags_t vma_flags)
> > {
> >- return pgprot_modify(oldprot, vm_get_page_prot(vm_flags));
> >+ const pgprot_t prot = vma_get_page_prot(vma_flags);
> >+
> >+ return pgprot_modify(oldprot, prot);
>
> Nit: could this just stay as a single return? something like:
>
> return pgprot_modify(oldprot, vma_get_page_prot(vma_flags));
I feel it's a bit clearer this way, separating out the two, I know it's a super
tiny difference but anyway :P
>
> Otherwise, LGTM, feel free to add:
>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
Thanks!
>
> [...]
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH 05/13] mm: prefer mm->def_vma_flags in mm logic
From: Lorenzo Stoakes @ 2026-07-02 15:24 UTC (permalink / raw)
To: Lance Yang
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, hughd, vbabka, rppt,
surenb, mhocko, jannh, pfalcato, kees, perex, tiwai, linux-mips,
linux-kernel, linuxppc-dev, dri-devel, etnaviv, linux-arm-kernel,
linux-samsung-soc, intel-gfx, linux-arm-msm, freedreno, nouveau,
linux-rockchip, linux-tegra, virtualization, intel-xe, xen-devel,
linux-fbdev, linux-aio, linux-fsdevel, linux-mm, linux-sound
In-Reply-To: <20260702121022.49113-1-lance.yang@linux.dev>
On Thu, Jul 02, 2026 at 08:10:22PM +0800, Lance Yang wrote:
>
> On Mon, Jun 29, 2026 at 08:25:28PM +0100, Lorenzo Stoakes wrote:
> >Currently mm->def_flags (of type vm_flags_t) is union'd with
> >mm->def_vma_flags (of type vma_flags_t).
> >
> >As part of the effort to convert vm_flags_t usage to vma_flags_t (in order
> >to no longer be arbitrarily limited to a system word size for VMA flags),
> >prefer mm->def_vma_flags to mm->def_flags throughout the mm logic.
> >
> >No functional change intended.
> >
> >Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> >---
> > mm/debug.c | 2 +-
> > mm/mlock.c | 13 +++++++------
> > mm/mmap.c | 11 ++++++-----
> > mm/vma.c | 4 ++--
> > 4 files changed, 16 insertions(+), 14 deletions(-)
> >
> >diff --git a/mm/debug.c b/mm/debug.c
> >index 497654b36f1a..f0a354a9496a 100644
> >--- a/mm/debug.c
> >+++ b/mm/debug.c
> >@@ -226,7 +226,7 @@ void dump_mm(const struct mm_struct *mm)
> > mm->numa_next_scan, mm->numa_scan_offset, mm->numa_scan_seq,
> > #endif
> > atomic_read(&mm->tlb_flush_pending),
> >- mm->def_flags, &mm->def_flags
> >+ vma_flags_to_legacy(mm->def_vma_flags), &mm->def_vma_flags
> > );
>
> While at it, one thing for later: dump_mm() still assumes one-world VMA
> flags. That works today since vma_flags_t is one word. Maybe worth a
> BUILD_BUG_ON() here, before that stops being true?
Ah yeah that could actually be pretty straightforward, if you see
https://www.kernel.org/doc/Documentation/printk-formats.txt there is a bitmap
format that could be used.
Can do that on a respin!
>
> Not a big deal though. Feel free to add:
>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
>
> > }
> > EXPORT_SYMBOL(dump_mm);
> [...]
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH 02/13] mm/vma: update do_mmap() to use vma_flags_t
From: Lance Yang @ 2026-07-02 15:08 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, hughd, vbabka, rppt,
surenb, mhocko, jannh, pfalcato, kees, perex, tiwai, linux-mips,
linux-kernel, linuxppc-dev, dri-devel, etnaviv, linux-arm-kernel,
linux-samsung-soc, intel-gfx, linux-arm-msm, freedreno, nouveau,
linux-rockchip, linux-tegra, virtualization, intel-xe, xen-devel,
linux-fbdev, linux-aio, linux-fsdevel, linux-mm, linux-sound
In-Reply-To: <akZwsS-_cywsXSjL@lucifer>
On 2026/7/2 22:16, Lorenzo Stoakes wrote:
> On Thu, Jul 02, 2026 at 07:15:31PM +0800, Lance Yang wrote:
[...]
>>
>> [...]
>>> diff --git a/mm/mmap.c b/mm/mmap.c
>>> index 46174e706bbe..547352183214 100644
>>> --- a/mm/mmap.c
>>> +++ b/mm/mmap.c
>> [...]
>>> @@ -488,23 +496,27 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
>>> * Check to see if we are violating any seals and update VMA
>>> * flags if necessary to avoid future seal violations.
>>> */
>>> - err = memfd_check_seals_mmap(file, &vm_flags);
>>> + err = memfd_check_seals_mmap(file, &vma_flags);
>>> if (err)
>>> return (unsigned long)err;
>>> } else {
>>> switch (flags & MAP_TYPE) {
>>> case MAP_SHARED:
>>> - if (vm_flags & (VM_GROWSDOWN|VM_GROWSUP))
>>> + if (vma_flags_can_grow(&vma_flags))
>>> return -EINVAL;
>>> /*
>>> * Ignore pgoff.
>>> */
>>> pgoff = 0;
>>> - vm_flags |= VM_SHARED | VM_MAYSHARE;
>>> + vma_flags_set(&vma_flags, VMA_SHARED_BIT, VMA_MAYSHARE_BIT);
>>> break;
>>> - case MAP_DROPPABLE:
>>> - if (VM_DROPPABLE == VM_NONE)
>>> + case MAP_DROPPABLE: {
>>> + vma_flags_t droppable = VMA_DROPPABLE;
>>> +
>>> + if (vma_flags_empty(&droppable))
>>> return -EOPNOTSUPP;
>>> + vma_flags_set_mask(&vma_flags, droppable);
>>> +
>>> /*
>>> * A locked or stack area makes no sense to be droppable.
>>> *
>>> @@ -515,23 +527,24 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
>>> */
>>> if (flags & (MAP_LOCKED | MAP_HUGETLB))
>>> return -EINVAL;
>>> - if (vm_flags & (VM_GROWSDOWN | VM_GROWSUP))
>>> + if (vma_flags_can_grow(&vma_flags))
>>> return -EINVAL;
>>>
>>> - vm_flags |= VM_DROPPABLE;
>>
>> Old code checked VM_GROWSDOWN|VM_GROWSUP before seting VM_DROPPABLE. New
>> code flips that around. Hmm, shouldn't master, just made me look twice ;)
>>
>> Maybe keep old order?
>
> I guess I feared that defining droppable above then referencing it below would
> be less clear?
>
> Can move if you feel strongly about it, and sorry for making the move at the
> same time as the general vm_flags_t -> vma_flags_t refactor as it does make that
> less clear...
No need to churn just for me. Thanks :)
^ permalink raw reply
* Re: [PATCH 02/13] mm/vma: update do_mmap() to use vma_flags_t
From: Lorenzo Stoakes @ 2026-07-02 14:16 UTC (permalink / raw)
To: Lance Yang
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, hughd, vbabka, rppt,
surenb, mhocko, jannh, pfalcato, kees, perex, tiwai, linux-mips,
linux-kernel, linuxppc-dev, dri-devel, etnaviv, linux-arm-kernel,
linux-samsung-soc, intel-gfx, linux-arm-msm, freedreno, nouveau,
linux-rockchip, linux-tegra, virtualization, intel-xe, xen-devel,
linux-fbdev, linux-aio, linux-fsdevel, linux-mm, linux-sound
In-Reply-To: <20260702111531.64883-1-lance.yang@linux.dev>
On Thu, Jul 02, 2026 at 07:15:31PM +0800, Lance Yang wrote:
>
> On Mon, Jun 29, 2026 at 08:25:25PM +0100, Lorenzo Stoakes wrote:
> >The core do_mmap() function accepts a vm_flags_t parameter which it then
> >manipulates before passing to mmap_region() to do the heavy lifting of the
> >memory mapping.
> >
> >Update do_mmap() to instead accept a vma_flags_t parameter, and adjust all
> >the logic within do_mmap() to manipulate this instead.
> >
> >This is as part of the ongoing effort to convert VMA flags from a system
> >word size to a bitmap type which allows us to unrestrict the number of VMA
> >flags, as well as gain control over how VMA flag manipulation occurs.
> >
> >We do not cascade these changes to all functions which accept vm_flags_t,
> >but rather use vma_flags_to_legacy() where necessary, specifically
> >deferring converting calc_vm_prot_bits(), calc_vm_flag_bits() and
> >__get_unmapped_area() to vma_flags_t.
> >
> >Also utilise the new vma_flags_can_grow() predicate which correctly handles
> >the case of architectures without upward growing stacks.
> >
> >As part of this change, introduce VMA_SHADOW_STACK so we can correctly
> >handle the case of the shadow stack not being defined.
> >
> >No functional change intended.
> >
> >Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> >---
>
> Not exactly a small one :) I stared at this patch for a while, hopefully
> don't miss anythig ...
Yeah sorry maybe I could have broken this down more!
>
> Just one tiny nit below. Overall, LGTM, feel free to add:
>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
Thanks!
>
> [...]
> >diff --git a/mm/mmap.c b/mm/mmap.c
> >index 46174e706bbe..547352183214 100644
> >--- a/mm/mmap.c
> >+++ b/mm/mmap.c
> [...]
> >@@ -488,23 +496,27 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
> > * Check to see if we are violating any seals and update VMA
> > * flags if necessary to avoid future seal violations.
> > */
> >- err = memfd_check_seals_mmap(file, &vm_flags);
> >+ err = memfd_check_seals_mmap(file, &vma_flags);
> > if (err)
> > return (unsigned long)err;
> > } else {
> > switch (flags & MAP_TYPE) {
> > case MAP_SHARED:
> >- if (vm_flags & (VM_GROWSDOWN|VM_GROWSUP))
> >+ if (vma_flags_can_grow(&vma_flags))
> > return -EINVAL;
> > /*
> > * Ignore pgoff.
> > */
> > pgoff = 0;
> >- vm_flags |= VM_SHARED | VM_MAYSHARE;
> >+ vma_flags_set(&vma_flags, VMA_SHARED_BIT, VMA_MAYSHARE_BIT);
> > break;
> >- case MAP_DROPPABLE:
> >- if (VM_DROPPABLE == VM_NONE)
> >+ case MAP_DROPPABLE: {
> >+ vma_flags_t droppable = VMA_DROPPABLE;
> >+
> >+ if (vma_flags_empty(&droppable))
> > return -EOPNOTSUPP;
> >+ vma_flags_set_mask(&vma_flags, droppable);
> >+
> > /*
> > * A locked or stack area makes no sense to be droppable.
> > *
> >@@ -515,23 +527,24 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
> > */
> > if (flags & (MAP_LOCKED | MAP_HUGETLB))
> > return -EINVAL;
> >- if (vm_flags & (VM_GROWSDOWN | VM_GROWSUP))
> >+ if (vma_flags_can_grow(&vma_flags))
> > return -EINVAL;
> >
> >- vm_flags |= VM_DROPPABLE;
>
> Old code checked VM_GROWSDOWN|VM_GROWSUP before seting VM_DROPPABLE. New
> code flips that around. Hmm, shouldn't master, just made me look twice ;)
>
> Maybe keep old order?
I guess I feared that defining droppable above then referencing it below would
be less clear?
Can move if you feel strongly about it, and sorry for making the move at the
same time as the general vm_flags_t -> vma_flags_t refactor as it does make that
less clear...
>
> Cheers, Lance
>
> >-
> > /*
> > * If the pages can be dropped, then it doesn't make
> > * sense to reserve them.
> > */
> >- vm_flags |= VM_NORESERVE;
> >+ vma_flags_set(&vma_flags, VMA_NORESERVE_BIT);
> >
> > /*
> > * Likewise, they're volatile enough that they
> > * shouldn't survive forks or coredumps.
> > */
> >- vm_flags |= VM_WIPEONFORK | VM_DONTDUMP;
> >+ vma_flags_set(&vma_flags, VMA_WIPEONFORK_BIT,
> >+ VMA_DONTDUMP_BIT);
> >+
> > fallthrough;
> >+ }
> > case MAP_PRIVATE:
> > /*
> > * Set pgoff according to addr for anon_vma.
> [...]
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH 13/13] mm/mremap: convert mremap code to use vma_flags_t
From: Lance Yang @ 2026-07-02 13:49 UTC (permalink / raw)
To: ljs
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, lance.yang, hughd, vbabka,
rppt, surenb, mhocko, jannh, pfalcato, kees, perex, tiwai,
linux-mips, linux-kernel, linuxppc-dev, dri-devel, etnaviv,
linux-arm-kernel, linux-samsung-soc, intel-gfx, linux-arm-msm,
freedreno, nouveau, linux-rockchip, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-aio, linux-fsdevel,
linux-mm, linux-sound
In-Reply-To: <380f761d35a3faa4370f8b3f92e3d4af3d4c7110.1782760670.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 08:25:36PM +0100, Lorenzo Stoakes wrote:
>Replace use of the legacy vm_flags_t flags with vma_flags_t values
>throughout the mremap logic.
>
>Additionally update comments to reflect the changes to be consistent.
>
>No functional change intended.
>
>Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>---
The vm_flags_set() cases below spell out vma_start_write(), but the
vm_flags_clear() cases don't?
Thanks, Lance
> mm/mremap.c | 38 ++++++++++++++++++++------------------
> 1 file changed, 20 insertions(+), 18 deletions(-)
>
>diff --git a/mm/mremap.c b/mm/mremap.c
>index 079a0ba0c4a7..0ea43302b7ed 100644
>--- a/mm/mremap.c
>+++ b/mm/mremap.c
>@@ -68,7 +68,7 @@ struct vma_remap_struct {
> bool populate_expand; /* mlock()'d expanded, must populate. */
> enum mremap_type remap_type; /* expand, shrink, etc. */
> bool mmap_locked; /* Is mm currently write-locked? */
>- unsigned long charged; /* If VM_ACCOUNT, # pages to account. */
>+ unsigned long charged; /* If VMA_ACCOUNT_BIT, # pgs to account */
> bool vmi_needs_invalidate; /* Is the VMA iterator invalidated? */
> };
>
>@@ -954,7 +954,7 @@ static unsigned long vrm_set_new_addr(struct vma_remap_struct *vrm)
>
> if (vrm->flags & MREMAP_FIXED)
> map_flags |= MAP_FIXED;
>- if (vma->vm_flags & VM_MAYSHARE)
>+ if (vma_test(vma, VMA_MAYSHARE_BIT))
> map_flags |= MAP_SHARED;
>
> res = get_unmapped_area(vma->vm_file, new_addr, vrm->new_len, pgoff,
>@@ -976,7 +976,7 @@ static bool vrm_calc_charge(struct vma_remap_struct *vrm)
> {
> unsigned long charged;
>
>- if (!(vrm->vma->vm_flags & VM_ACCOUNT))
>+ if (!vma_test(vrm->vma, VMA_ACCOUNT_BIT))
> return true;
>
> /*
>@@ -1003,7 +1003,7 @@ static bool vrm_calc_charge(struct vma_remap_struct *vrm)
> */
> static void vrm_uncharge(struct vma_remap_struct *vrm)
> {
>- if (!(vrm->vma->vm_flags & VM_ACCOUNT))
>+ if (!vma_test(vrm->vma, VMA_ACCOUNT_BIT))
> return;
>
> vm_unacct_memory(vrm->charged);
>@@ -1023,7 +1023,7 @@ static void vrm_stat_account(struct vma_remap_struct *vrm,
> struct vm_area_struct *vma = vrm->vma;
>
> vm_stat_account(mm, vma->vm_flags, pages);
>- if (vma->vm_flags & VM_LOCKED)
>+ if (vma_test(vma, VMA_LOCKED_BIT))
> mm->locked_vm += pages;
> }
>
>@@ -1167,7 +1167,7 @@ static void unmap_source_vma(struct vma_remap_struct *vrm)
> * arose, in which case we _do_ wish to unmap the _new_ VMA, which means
> * we actually _do_ want it be unaccounted.
> */
>- bool accountable_move = (vma->vm_flags & VM_ACCOUNT) &&
>+ bool accountable_move = vma_test(vma, VMA_ACCOUNT_BIT) &&
> !(vrm->flags & MREMAP_DONTUNMAP);
>
> /*
>@@ -1186,7 +1186,7 @@ static void unmap_source_vma(struct vma_remap_struct *vrm)
> * portions of the original VMA that remain.
> */
> if (accountable_move) {
>- vm_flags_clear(vma, VM_ACCOUNT);
>+ vma_clear_flags(vma, VMA_ACCOUNT_BIT);
> /* We are about to split vma, so store the start/end. */
> vm_start = vma->vm_start;
> vm_end = vma->vm_end;
>@@ -1211,8 +1211,8 @@ static void unmap_source_vma(struct vma_remap_struct *vrm)
> * | |
> * |-------------|
> *
>- * Having cleared VM_ACCOUNT from the whole VMA, after we unmap above
>- * we'll end up with:
>+ * Having cleared VMA_ACCOUNT_BIT from the whole VMA, after we unmap
>+ * above we'll end up with:
> *
> * addr end
> * | |
>@@ -1232,13 +1232,15 @@ static void unmap_source_vma(struct vma_remap_struct *vrm)
> if (vm_start < addr) {
> struct vm_area_struct *prev = vma_prev(&vmi);
>
>- vm_flags_set(prev, VM_ACCOUNT); /* Acquires VMA lock. */
>+ vma_start_write(prev);
>+ vma_set_flags(prev, VMA_ACCOUNT_BIT);
> }
>
> if (vm_end > end) {
> struct vm_area_struct *next = vma_next(&vmi);
>
>- vm_flags_set(next, VM_ACCOUNT); /* Acquires VMA lock. */
>+ vma_start_write(next);
>+ vma_set_flags(next, VMA_ACCOUNT_BIT);
> }
> }
> }
>@@ -1321,8 +1323,8 @@ static void dontunmap_complete(struct vma_remap_struct *vrm,
> unsigned long old_start = vrm->vma->vm_start;
> unsigned long old_end = vrm->vma->vm_end;
>
>- /* We always clear VM_LOCKED[ONFAULT] on the old VMA. */
>- vm_flags_clear(vrm->vma, VM_LOCKED_MASK);
>+ /* We always clear VMA_LOCKED[ONFAULT]_BIT on the old VMA. */
>+ vma_clear_flags_mask(vrm->vma, VMA_LOCKED_MASK);
>
> /*
> * anon_vma links of the old vma is no longer needed after its page
>@@ -1758,14 +1760,14 @@ static int check_prep_vma(struct vma_remap_struct *vrm)
> * based on the original. There are no known use cases for this
> * behavior. As a result, fail such attempts.
> */
>- if (!old_len && !(vma->vm_flags & (VM_SHARED | VM_MAYSHARE))) {
>+ if (!old_len && !vma_test_any(vma, VMA_SHARED_BIT, VMA_MAYSHARE_BIT)) {
> pr_warn_once("%s (%d): attempted to duplicate a private mapping with mremap. This is not supported.\n",
> current->comm, current->pid);
> return -EINVAL;
> }
>
> if ((vrm->flags & MREMAP_DONTUNMAP) &&
>- (vma->vm_flags & (VM_DONTEXPAND | VM_PFNMAP)))
>+ vma_test_any(vma, VMA_DONTEXPAND_BIT, VMA_PFNMAP_BIT))
> return -EINVAL;
>
> /*
>@@ -1795,7 +1797,7 @@ static int check_prep_vma(struct vma_remap_struct *vrm)
> return 0;
>
> /* We are expanding and the VMA is mlock()'d so we need to populate. */
>- if (vma->vm_flags & VM_LOCKED)
>+ if (vma_test(vma, VMA_LOCKED_BIT))
> vrm->populate_expand = true;
>
> /* Need to be careful about a growing mapping */
>@@ -1803,10 +1805,10 @@ static int check_prep_vma(struct vma_remap_struct *vrm)
> if (pgoff + (new_len >> PAGE_SHIFT) < pgoff)
> return -EINVAL;
>
>- if (vma->vm_flags & (VM_DONTEXPAND | VM_PFNMAP))
>+ if (vma_test_any(vma, VMA_DONTEXPAND_BIT, VMA_PFNMAP_BIT))
> return -EFAULT;
>
>- if (!mlock_future_ok(mm, vma->vm_flags & VM_LOCKED, vrm->delta))
>+ if (!mlock_future_ok(mm, vma_test(vma, VMA_LOCKED_BIT), vrm->delta))
> return -EAGAIN;
>
> if (!may_expand_vm(mm, &vma->flags, vrm->delta >> PAGE_SHIFT))
>--
>2.54.0
>
>
^ permalink raw reply
* Re: [PATCH 11/13] mm/mlock: convert mlock code to use vma_flags_t
From: Lance Yang @ 2026-07-02 13:21 UTC (permalink / raw)
To: ljs
Cc: akpm, tsbogend, maddy, mpe, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, l.stach, inki.dae, sw0312.kim,
kyungmin.park, krzk, peter.griffin, jani.nikula, joonas.lahtinen,
rodrigo.vivi, tursulin, robin.clark, lumag, lyude, dakr,
tomi.valkeinen, hjc, heiko, andy.yan, thierry.reding, mperttunen,
jonathanh, kraxel, dmitry.osipenko, zack.rusin, matthew.brost,
thomas.hellstrom, oleksandr_andrushchenko, deller, bcrl, viro,
brauner, muchun.song, osalvador, david, ziy, baolin.wang, liam,
npache, ryan.roberts, dev.jain, baohua, lance.yang, hughd, vbabka,
rppt, surenb, mhocko, jannh, pfalcato, kees, perex, tiwai,
linux-mips, linux-kernel, linuxppc-dev, dri-devel, etnaviv,
linux-arm-kernel, linux-samsung-soc, intel-gfx, linux-arm-msm,
freedreno, nouveau, linux-rockchip, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-aio, linux-fsdevel,
linux-mm, linux-sound
In-Reply-To: <2db16db81538355ca65f778c246d2381c673cad4.1782760670.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 08:25:34PM +0100, Lorenzo Stoakes wrote:
>Replace use of the legacy vm_flags_t flags with vma_flags_t values
>throughout the mlock logic.
>
>Additionally update comments to reflect the changes to be consistent.
>
>No functional change intended.
>
>Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>---
Nothing scary jumped out at me. Just one tiny nit below ;)
[...]
>@@ -466,24 +466,23 @@ static void mlock_vma_pages_range(struct vm_area_struct *vma,
> */
> static int mlock_fixup(struct vma_iterator *vmi, struct vm_area_struct *vma,
> struct vm_area_struct **prev, unsigned long start,
>- unsigned long end, vm_flags_t newflags)
>+ unsigned long end, vma_flags_t *new_vma_flags)
> {
>- vma_flags_t new_vma_flags = legacy_to_vma_flags(newflags);
> const vma_flags_t old_vma_flags = vma->flags;
> struct mm_struct *mm = vma->vm_mm;
> int nr_pages;
> int ret = 0;
>
>- if (vma_flags_same_pair(&old_vma_flags, &new_vma_flags) ||
>+ if (vma_flags_same_pair(&old_vma_flags, new_vma_flags) ||
> vma_is_secretmem(vma) || !vma_supports_mlock(vma)) {
> /*
>- * Don't set VM_LOCKED or VM_LOCKONFAULT and don't count.
>+ * Don't set VMA_LOCKED_BIT or VM_LOCKONFAULT and don't count.
s/VM_LOCKONFAULT/VMA_LOCKONFAULT_BIT/
Otherwise LGTM. Feel free to add:
Reviewed-by: Lance Yang <lance.yang@linux.dev>
> * For secretmem, don't allow the memory to be unlocked.
> */
> goto out;
> }
>
>- vma = vma_modify_flags(vmi, *prev, vma, start, end, &new_vma_flags);
>+ vma = vma_modify_flags(vmi, *prev, vma, start, end, new_vma_flags);
> if (IS_ERR(vma)) {
> ret = PTR_ERR(vma);
> goto out;
[...]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox