* Re: [PATCH v2 1/2] mm/memcontrol: add dmem charge/uncharge functions
From: Eric Chanudet @ 2026-05-27 19:10 UTC (permalink / raw)
To: Shakeel Butt
Cc: Johannes Weiner, Michal Hocko, Roman Gushchin, Muchun Song,
Andrew Morton, Maarten Lankhorst, Maxime Ripard, Natalie Vock,
Tejun Heo, Michal Koutný, Jonathan Corbet, Shuah Khan,
cgroups, linux-mm, linux-kernel, dri-devel, T.J. Mercier,
Christian König, Maxime Ripard, Albert Esteve, Dave Airlie,
linux-doc
In-Reply-To: <ahB7pCu_G4vuswc0@linux.dev>
On Fri, May 22, 2026 at 08:53:10AM -0700, Shakeel Butt wrote:
> On Tue, May 19, 2026 at 11:59:01AM -0400, Eric Chanudet wrote:
> > Add mem_cgroup_dmem_charge() and mem_cgroup_dmem_uncharge() to allow
> > dmem pool allocations to optionally be double-charged against the memory
> > controller. Take the struct cgroup from the dmem pool's css as there is
> > no convenient object exported to represent these allocations. These will
> > resolve the effective memory css from that cgroup and perform the
> > charge.
> >
> > Introduce a MEMCG_DMEM stat counter to memory.stat to make the cgroup's
> > dmem charge visible.
> >
> > Signed-off-by: Eric Chanudet <echanude@redhat.com>
> > ---
> > include/linux/memcontrol.h | 16 ++++++++++++
> > mm/memcontrol.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 81 insertions(+)
> >
> > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> > index dc3fa687759b45748b2acee6d7f43da325eb50c1..8e1d49b87fb64e6114f3eb920293e14920290fe7 100644
> > --- a/include/linux/memcontrol.h
> > +++ b/include/linux/memcontrol.h
> > @@ -39,6 +39,7 @@ enum memcg_stat_item {
> > MEMCG_ZSWAP_B,
> > MEMCG_ZSWAPPED,
> > MEMCG_ZSWAP_INCOMP,
> > + MEMCG_DMEM,
> > MEMCG_NR_STAT,
> > };
> >
> > @@ -1872,6 +1873,21 @@ static inline bool mem_cgroup_zswap_writeback_enabled(struct mem_cgroup *memcg)
> > }
> > #endif
> >
> > +#if defined(CONFIG_MEMCG) && defined(CONFIG_CGROUP_DMEM)
> > +bool mem_cgroup_dmem_charge(struct cgroup *cgrp, unsigned int nr_pages,
> > + gfp_t gfp_mask);
> > +void mem_cgroup_dmem_uncharge(struct cgroup *cgrp, unsigned int nr_pages);
> > +#else
> > +static inline bool mem_cgroup_dmem_charge(struct cgroup *cgrp,
> > + unsigned int nr_pages, gfp_t gfp_mask)
>
> Please follow Johannes's request to pass the actually memory object instead of
> naked numbers.
Sorry, I misunderstood Johannes' comment. I am not sure what to use
here. Since these are called from dmem.c, they don't have access to what
was allocated.
Looking at zswap, it uses obj_cgroup. I thought of resolving the
obj_cgroup from dmem_cgroup_try_charge and keep it in the
dmem_cgroup_pool_state, but that made me realize there is a catch with
this patch set, with something like:
A: +memory{max:32M}/+dmem
A/B: +memory{max:16M}
It gets the CSS from the dmem's cgroup with
cgroup_get_e_css(cgrp, &memory_cgrp_subsys);
mem_cgroup_from_css(mem_css);
Which would resolve to A's memcg and not enforce the memory.max limit
set in B when dmem.memcg is set for that region.
--
Eric Chanudet
^ permalink raw reply
* [PATCH v2 2/2] ALSA: usb-audio: Add quirk flag for Sennheiser MOMENTUM 3
From: Rong Zhang @ 2026-05-27 18:56 UTC (permalink / raw)
To: Jaroslav Kysela, Takashi Iwai, Jonathan Corbet, Shuah Khan
Cc: Rong Zhang, linux-sound, linux-doc, linux-kernel
In-Reply-To: <20260528-uac-quirk-get-cur-vol-v2-0-84d3c8f48150@rong.moe>
The Sennheiser MOMENTUM 3 is a wireless around-ear headphones featuring
ANC, which can be connected via Bluetooth or USB-C.
When connecting via USB-C, its UAC mixer works fine and precisely
corresponds to the reported dB range. However, the mixer's volume
GET_CUR method is somehow stubbed and returns a constant value (15dB).
Since commit 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky
mixers"), the sticky check considers the mixer to be sticky and
unnecessarily disables the mixer.
Add a quirk table entry matching VID/PID=0x1377/0x6004 and applying
the MIXER_GET_CUR_BROKEN quirk flag, so that the mixer is usable again.
Quirky device sample:
usb 7-1.4.4.1.1.1: new full-speed USB device number 30 using xhci_hcd
usb 7-1.4.4.1.1.1: New USB device found, idVendor=1377, idProduct=6004, bcdDevice=38.85
usb 7-1.4.4.1.1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 7-1.4.4.1.1.1: Product: MOMENTUM 3
usb 7-1.4.4.1.1.1: Manufacturer: Sennheiser electronic GmbH & Co. KG
usb 7-1.4.4.1.1.1: SerialNumber: <REDACTED>
usb 7-1.4.4.1.1.1: Found last interface = 0
usb 7-1.4.4.1.1.1: 1:1: add audio endpoint 0x3
usb 7-1.4.4.1.1.1: Creating new data endpoint #3
usb 7-1.4.4.1.1.1: 1:1 Set sample rate 48000, clock 0
usb 7-1.4.4.1.1.1: 6:0: sticky mixer values (0/11520/768 => 3840), disabling
usb 7-1.4.4.1.1.1: [6] FU [PCM Playback Volume] skipped due to invalid volume
input: Sennheiser electronic GmbH & Co. KG MOMENTUM 3 as /devices/pci0000:00/0000:00:08.3/0000:67:00.4/usb7/7-1/7-1.4/7-1.4.4/7-1.4.4.1/7-1.4.4.1.1/7-1.4.4.1.1.1/7-1.4.4.1.1.1:1.2/0003:1377:6004.002B/input/input208
input: Sennheiser electronic GmbH & Co. KG MOMENTUM 3 Consumer Control as /devices/pci0000:00/0000:00:08.3/0000:67:00.4/usb7/7-1/7-1.4/7-1.4.4/7-1.4.4.1/7-1.4.4.1.1/7-1.4.4.1.1.1/7-1.4.4.1.1.1:1.2/0003:1377:6004.002B/input/input209
hid-generic 0003:1377:6004.002B: input,hiddev99,hidraw12: USB HID v1.11 Device [Sennheiser electronic GmbH & Co. KG MOMENTUM 3] on usb-0000:67:00.4-1.4.4.1.1.1/input2
Signed-off-by: Rong Zhang <i@rong.moe>
---
sound/usb/quirks.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index ac2f0f6039be..149f2009df12 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -2357,6 +2357,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
QUIRK_FLAG_FORCE_IFACE_RESET | QUIRK_FLAG_IFACE_DELAY),
DEVICE_FLG(0x1224, 0x2a25, /* Jieli Technology USB PHY 2.0 */
QUIRK_FLAG_GET_SAMPLE_RATE | QUIRK_FLAG_MIC_RES_16),
+ DEVICE_FLG(0x1377, 0x6004, /* Sennheiser MOMENTUM 3 */
+ QUIRK_FLAG_MIXER_GET_CUR_BROKEN),
DEVICE_FLG(0x1395, 0x740a, /* Sennheiser DECT */
QUIRK_FLAG_GET_SAMPLE_RATE),
DEVICE_FLG(0x1397, 0x0507, /* Behringer UMC202HD */
--
2.53.0
^ permalink raw reply related
* [PATCH v2 0/2] ALSA: usb-audio: Add QUIRK_FLAG_MIXER_GET_CUR_BROKEN for Sennheiser MOMENTUM 3
From: Rong Zhang @ 2026-05-27 18:56 UTC (permalink / raw)
To: Jaroslav Kysela, Takashi Iwai, Jonathan Corbet, Shuah Khan
Cc: Rong Zhang, linux-sound, linux-doc, linux-kernel
Since commit 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky
mixers"), the UAC mixer core utilizes volume SET_CUR and GET_CUR to
identify devices with sticky mixers. Unfortunately, even though most
devices with sticky GET_CUR also have corresponding sticky SET_CUR,
which I actually met more since the commit had been merged, there is
also a rare case that some devices may have volume mixers that responds
to SET_CUR properly but with its GET_CUR stubbed. This cause the sticky
check to consider the mixer to be sticky and unnecessarily disable it.
As the sticky check can't distinguish between sticky mixers and working
SET_CUR but broken GET_CUR, add QUIRK_FLAG_MIXER_GET_CUR_BROKEN to tell
that the device should fall into the second category when GET_CUR
returns a constant value. In this case, the sticky check becomes
non-fatal and only disables GET_CUR instead of the whole mixer. The
current volume will then be provided by the internal cache that stores
the last set volume.
The Sennheiser MOMENTUM 3 needs the quirk flag. Though its UAC mixer
works fine and precisely corresponds to the reported dB range, the
mixer's volume GET_CUR method is somehow stubbed and returns a constant
value (15dB), resulting in it being disabled by the sticky check.
Signed-off-by: Rong Zhang <i@rong.moe>
---
Changes in v2:
- Turn the approach into a less radical one
- Rename the quirk flag to QUIRK_FLAG_MIXER_GET_CUR_BROKEN
- Add a flag `get_cur_broken' to `struct usb_mixer_elem_info'
- When the sticky check fails, check quirk flags. Gate further GET_CUR
by setting `cval->get_cur_broken' if QUIRK_FLAG_MIXER_GET_CUR_BROKEN
is set, otherwise disable the mixer as usual
- The quirk flag still applies to all mixers, but as long as a mixer
makes the sticky check happy, it won't be affected at all. Only
those mixers with constant GET_CUR values will have their GET_CUR
gated. I assume the impact is minimal, since it's very unlikely a
device would have sticky mixers (broken SET_CUR) along with mixers
with working SET_CUR but broken GET_CUR at the same time
- Link to v1: https://patch.msgid.link/20260527-uac-quirk-get-cur-vol-v1-0-e9362b712e5e@rong.moe
To: Jaroslav Kysela <perex@perex.cz>
To: Takashi Iwai <tiwai@suse.com>
To: Jonathan Corbet <corbet@lwn.net>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: linux-sound@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
Rong Zhang (2):
ALSA: usb-audio: Add QUIRK_FLAG_MIXER_GET_CUR_BROKEN
ALSA: usb-audio: Add quirk flag for Sennheiser MOMENTUM 3
Documentation/sound/alsa-configuration.rst | 12 ++++++++++++
sound/usb/mixer.c | 17 +++++++++++++++--
sound/usb/mixer.h | 1 +
sound/usb/quirks.c | 3 +++
sound/usb/usbaudio.h | 13 +++++++++++++
5 files changed, 44 insertions(+), 2 deletions(-)
---
base-commit: 72d8bf668954678bfae8f7296b4b1c01990bcdc2
change-id: 20260527-uac-quirk-get-cur-vol-d0b292c3e796
Thanks,
Rong
^ permalink raw reply
* [PATCH v2 1/2] ALSA: usb-audio: Add QUIRK_FLAG_MIXER_GET_CUR_BROKEN
From: Rong Zhang @ 2026-05-27 18:56 UTC (permalink / raw)
To: Jaroslav Kysela, Takashi Iwai, Jonathan Corbet, Shuah Khan
Cc: Rong Zhang, linux-sound, linux-doc, linux-kernel
In-Reply-To: <20260528-uac-quirk-get-cur-vol-v2-0-84d3c8f48150@rong.moe>
Since commit 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky
mixers"), the UAC mixer core utilizes volume SET_CUR and GET_CUR to
identify devices with sticky mixers. Unfortunately, even though most
devices with sticky GET_CUR also have corresponding sticky SET_CUR,
which I actually met more since the commit had been merged, there is
also a rare case that some devices may have volume mixers that responds
to SET_CUR properly but with its GET_CUR stubbed. This cause the sticky
check to consider the mixer to be sticky and unnecessarily disable it.
As the sticky check can't distinguish between sticky mixers and working
SET_CUR but broken GET_CUR, add QUIRK_FLAG_MIXER_GET_CUR_BROKEN to tell
that the device should fall into the second category when GET_CUR
returns a constant value. In this case, the sticky check becomes
non-fatal and only disables GET_CUR instead of the whole mixer. The
current volume will then be provided by the internal cache that stores
the last set volume.
Signed-off-by: Rong Zhang <i@rong.moe>
---
Documentation/sound/alsa-configuration.rst | 12 ++++++++++++
sound/usb/mixer.c | 17 +++++++++++++++--
sound/usb/mixer.h | 1 +
sound/usb/quirks.c | 1 +
sound/usb/usbaudio.h | 13 +++++++++++++
5 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/Documentation/sound/alsa-configuration.rst b/Documentation/sound/alsa-configuration.rst
index 4b30cd63c5a5..78fb484e8b04 100644
--- a/Documentation/sound/alsa-configuration.rst
+++ b/Documentation/sound/alsa-configuration.rst
@@ -2389,6 +2389,18 @@ quirk_flags
from snd_usb_handle_sync_urb. Instead fall through and enqueue a
packet_info containing only size-0 packets, so the OUT ring keeps
moving (emits silence). Needed by Behringer Flow 8 (1397:050c).
+ * bit 30: ``mixer_get_cur_broken``
+ Some mixers are sticky, which means that setting their current volume
+ is a no-op, and reading the current volume returns a constant value.
+ The sticky check disables these mixers to prevent confusing userspace.
+ However, some devices do have a tunable volume despite the reported
+ current volume being constant. As the sticky check can't distinguish
+ between the two categories, setting this flag tells that the device
+ should fall into the second category when GET_CUR returns a constant
+ value, resulting in the sticky check being non-fatal and only
+ disabling GET_CUR instead of the whole mixer. The current volume will
+ then be provided by the internal cache that stores the last set
+ volume
This module supports multiple devices, autoprobe and hotplugging.
diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c
index d61bde654219..27d6445cc319 100644
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -420,6 +420,9 @@ static int get_cur_ctl_value(struct usb_mixer_elem_info *cval,
static inline int get_cur_mix_raw(struct usb_mixer_elem_info *cval,
int channel, int *value)
{
+ if (cval->get_cur_broken)
+ return -ENXIO;
+
return get_ctl_value(cval, UAC_GET_CUR,
(cval->control << 8) | channel,
value);
@@ -1258,6 +1261,16 @@ static int check_sticky_volume_control(struct usb_mixer_elem_info *cval,
return 0;
}
+ if (cval->head.mixer->chip->quirk_flags & QUIRK_FLAG_MIXER_GET_CUR_BROKEN) {
+ usb_audio_warn(cval->head.mixer->chip,
+ "%d:%d: broken mixer GET_CUR (%d/%d/%d => %d)\n",
+ cval->head.id, mixer_ctrl_intf(cval->head.mixer),
+ cval->min, cval->max, cval->res, saved);
+
+ cval->get_cur_broken = 1;
+ return -ENXIO;
+ }
+
usb_audio_err(cval->head.mixer->chip,
"%d:%d: sticky mixer values (%d/%d/%d => %d), disabling\n",
cval->head.id, mixer_ctrl_intf(cval->head.mixer),
@@ -1360,12 +1373,12 @@ static int get_min_max_with_quirks(struct usb_mixer_elem_info *cval,
goto no_checks;
ret = check_sticky_volume_control(cval, minchn, saved);
- if (ret < 0) {
+ if (ret == -ENODEV) {
snd_usb_set_cur_mix_value(cval, minchn, 0, saved);
return ret;
}
- if (cval->min + cval->res < cval->max)
+ if (!ret && cval->min + cval->res < cval->max)
check_volume_control_res(cval, minchn, saved);
snd_usb_set_cur_mix_value(cval, minchn, 0, saved);
diff --git a/sound/usb/mixer.h b/sound/usb/mixer.h
index afbb3dd9f177..3fa1bd96f858 100644
--- a/sound/usb/mixer.h
+++ b/sound/usb/mixer.h
@@ -94,6 +94,7 @@ struct usb_mixer_elem_info {
int cache_val[MAX_CHANNELS];
u8 initialized;
u8 min_mute;
+ u8 get_cur_broken;
void *private_data;
};
diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index e2c95be38aca..ac2f0f6039be 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -2605,6 +2605,7 @@ static const char *const snd_usb_audio_quirk_flag_names[] = {
QUIRK_STRING_ENTRY(MIXER_PLAYBACK_LINEAR_VOL),
QUIRK_STRING_ENTRY(MIXER_CAPTURE_LINEAR_VOL),
QUIRK_STRING_ENTRY(IFB_SILENCE_ON_EMPTY),
+ QUIRK_STRING_ENTRY(MIXER_GET_CUR_BROKEN),
NULL
};
diff --git a/sound/usb/usbaudio.h b/sound/usb/usbaudio.h
index 9afcad8f143a..e472aef6eb87 100644
--- a/sound/usb/usbaudio.h
+++ b/sound/usb/usbaudio.h
@@ -242,6 +242,17 @@ extern bool snd_usb_skip_validation;
* from snd_usb_handle_sync_urb. Instead fall through and enqueue a
* packet_info containing only size-0 packets, so the OUT ring keeps
* moving (emits silence). Needed by Behringer Flow 8 (1397:050c).
+ * QUIRK_FLAG_MIXER_GET_CUR_BROKEN
+ * Some mixers are sticky, which means that setting their current volume is a
+ * no-op, and reading the current volume returns a constant value. The sticky
+ * check disables these mixers to prevent confusing userspace. However, some
+ * devices do have a tunable volume despite the reported current volume being
+ * constant. As the sticky check can't distinguish between the two categories,
+ * setting this flag tells that the device should fall into the second
+ * category when GET_CUR returns a constant value, resulting in the sticky
+ * check being non-fatal and only disabling GET_CUR instead of the whole mixer.
+ * The current volume will then be provided by the internal cache that stores
+ * the last set volume
*/
enum {
@@ -275,6 +286,7 @@ enum {
QUIRK_TYPE_MIXER_PLAYBACK_LINEAR_VOL = 27,
QUIRK_TYPE_MIXER_CAPTURE_LINEAR_VOL = 28,
QUIRK_TYPE_IFB_SILENCE_ON_EMPTY = 29,
+ QUIRK_TYPE_MIXER_GET_CUR_BROKEN = 30,
/* Please also edit snd_usb_audio_quirk_flag_names */
};
@@ -310,5 +322,6 @@ enum {
#define QUIRK_FLAG_MIXER_PLAYBACK_LINEAR_VOL QUIRK_FLAG(MIXER_PLAYBACK_LINEAR_VOL)
#define QUIRK_FLAG_MIXER_CAPTURE_LINEAR_VOL QUIRK_FLAG(MIXER_CAPTURE_LINEAR_VOL)
#define QUIRK_FLAG_IFB_SILENCE_ON_EMPTY QUIRK_FLAG(IFB_SILENCE_ON_EMPTY)
+#define QUIRK_FLAG_MIXER_GET_CUR_BROKEN QUIRK_FLAG(MIXER_GET_CUR_BROKEN)
#endif /* __USBAUDIO_H */
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v4 0/5] selftests/mm: separate GUP microbenchmarking from functional testing
From: Andrew Morton @ 2026-05-27 18:47 UTC (permalink / raw)
To: Sarthak Sharma
Cc: David Hildenbrand, Lorenzo Stoakes, Liam R . Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Shuah Khan, Zi Yan, Baolin Wang, Nico Pache, Ryan Roberts,
Dev Jain, Barry Song, Lance Yang, Jason Gunthorpe, John Hubbard,
Peter Xu, Leon Romanovsky, Jonathan Corbet, Shuah Khan,
Mark Brown, linux-mm, linux-kselftest, linux-doc, linux-kernel
In-Reply-To: <20260527142432.230127-1-sarthak.sharma@arm.com>
On Wed, 27 May 2026 19:54:27 +0530 Sarthak Sharma <sarthak.sharma@arm.com> wrote:
> gup_test.c currently serves two distinct purposes: microbenchmarking
> (GUP_FAST_BENCHMARK, PIN_FAST_BENCHMARK, PIN_LONGTERM_BENCHMARK) and
> functional correctness testing (GUP_BASIC_TEST, PIN_BASIC_TEST,
> DUMP_USER_PAGES_TEST). Mixing these in a single binary means functional
> tests cannot be run or reported individually and run_vmtests.sh must
> invoke the binary multiple times with different flag combinations to
> cover all configurations.
>
> This patch series separates the two concerns: tools/mm/gup_bench for
> benchmarking and tools/testing/selftests/mm/gup_test for functional
> testing. To avoid duplicating HugeTLB and related file helpers, the
> series first prepares the existing file helpers for sharing, then moves
> the common helper code to tools/lib/mm/ so it can be shared by both
> selftests and tools/mm.
Thanks. I'll duck this for now, see what reviewers have to say.
Sashiko still has a couple of nags. Minor stuff, arguably ignorable.
https://sashiko.dev/#/patchset/20260527142432.230127-1-sarthak.sharma@arm.com
^ permalink raw reply
* Re: [PATCH v13 5/6] iio: adc: ad4691: add oversampling support
From: Jonathan Cameron @ 2026-05-27 18:16 UTC (permalink / raw)
To: Radu Sabau via B4 Relay
Cc: radu.sabau, Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Uwe Kleine-König, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Philipp Zabel,
Jonathan Corbet, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-pwm, linux-gpio, linux-doc
In-Reply-To: <20260525-ad4692-multichannel-sar-adc-driver-v13-5-1b7626d3b35c@analog.com>
On Mon, 25 May 2026 13:10:14 +0300
Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org> wrote:
> From: Radu Sabau <radu.sabau@analog.com>
>
> Add per-channel oversampling ratio (OSR) support for CNV burst mode.
> The accumulator depth register (ACC_DEPTH_IN) is programmed with the
> selected OSR at buffer enable time and before each single-shot read.
>
> Supported OSR values: 1, 2, 4, 8, 16, 32.
>
> Introduce AD4691_MANUAL_CHANNEL() for manual mode channels, which do
> not expose the oversampling_ratio attribute since OSR is not applicable
> in that mode. A separate manual_channels array is added to
> struct ad4691_channel_info and selected at probe time.
>
> in_voltageN_sampling_frequency represents the effective output rate for
> channel N, defined as osc_freq / osr[N]. The chip has one internal
> oscillator shared by all channels; each channel independently
> accumulates osr[N] oscillator cycles before producing a result.
Sashiko notes this probably needs updating for moving to single osr.
>
> Writing sampling_frequency computes needed_osc = freq * osr[N] and
> snaps down to the largest oscillator table entry that satisfies both
> osc <= needed_osc and osc % osr[N] == 0, guaranteeing an exact integer
> read-back. The result is stored in target_osc_freq_Hz and written to
> OSC_FREQ_REG at buffer enable and single-shot time, so sampling_frequency
> and oversampling_ratio can be set in any order.
>
> in_voltageN_sampling_frequency_available is precomputed at probe for
> each OSR value, listing only oscillator table entries that divide
> evenly by that OSR, expressed as effective rates (osc_freq / osr[N]).
> The list becomes sparser as OSR increases, capping at max_rate / osr[N].
> read_avail picks the precomputed list for the channel's current OSR,
> making the returned pointer stable and race-free.
>
> Writing oversampling_ratio stores the new OSR for that channel and snaps
> target_osc_freq_Hz to the largest oscillator table entry that is both
> <= old_effective_rate * new_osr and evenly divisible by new_osr. This
> preserves an integer read-back of in_voltageN_sampling_frequency after
> the OSR change while keeping the oscillator as close as possible to the
> previous effective rate.
>
> OSR defaults to 1 (no accumulation) for all channels.
>
> Signed-off-by: Radu Sabau <radu.sabau@analog.com>
I didn't find anything else to comment on. LGTM
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: KVM: Include maintainer profile
From: Sean Christopherson @ 2026-05-27 18:10 UTC (permalink / raw)
To: Sean Christopherson, Paolo Bonzini, Jonathan Corbet, Shuah Khan,
kvm, workflows, linux-doc, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260518104154.38915-2-krzysztof.kozlowski@oss.qualcomm.com>
On Mon, 18 May 2026 12:41:55 +0200, Krzysztof Kozlowski wrote:
> No dedicated KVM maintainers are returned by get_maintainers.pl for the
> subsystem maintainer profile, thus patches changing that file miss
> the actual owners of the file.
Applied to kvm-x86 misc, thanks!
[1/1] MAINTAINERS: KVM: Include maintainer profile
https://github.com/kvm-x86/linux/commit/66472e86703f
--
https://github.com/kvm-x86/linux/tree/next
^ permalink raw reply
* Re: [PATCH v13 2/6] iio: adc: ad4691: add initial driver for AD4691 family
From: Jonathan Cameron @ 2026-05-27 18:07 UTC (permalink / raw)
To: Radu Sabau via B4 Relay
Cc: radu.sabau, Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Uwe Kleine-König, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Philipp Zabel,
Jonathan Corbet, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-pwm, linux-gpio, linux-doc
In-Reply-To: <20260525-ad4692-multichannel-sar-adc-driver-v13-2-1b7626d3b35c@analog.com>
On Mon, 25 May 2026 13:10:11 +0300
Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org> wrote:
> From: Radu Sabau <radu.sabau@analog.com>
>
> Add support for the Analog Devices AD4691 family of high-speed,
> low-power multichannel SAR ADCs: AD4691 (16-ch, 500 kSPS),
> AD4692 (16-ch, 1 MSPS), AD4693 (8-ch, 500 kSPS) and
> AD4694 (8-ch, 1 MSPS).
>
> The driver implements a custom regmap layer over raw SPI to handle the
> device's mixed 1/2/3/4-byte register widths and uses the standard IIO
> read_raw/write_raw interface for single-channel reads.
>
> The chip idles in Autonomous Mode so that single-shot read_raw can use
> the internal oscillator without disturbing the hardware configuration.
>
> Three voltage supply domains are managed: avdd (required), vio, and a
> reference supply on either the REF pin (ref-supply, external buffer)
> or the REFIN pin (refin-supply, uses the on-chip reference buffer;
> REFBUF_EN is set accordingly). Hardware reset is performed by asserting
> the reset-gpios GPIO line for at least 300 µs then deasserting it;
As Sashiko notes this doesn't quite correspond to the code which deasserts
then sleeps. The comments in the code make it obvious that was intended
so this commit description probably just needs an update.
I guess you probably already saw and fixed this.
> a software reset via SPI_CONFIG_A is used as fallback when no reset
> GPIO is provided.
>
> Accumulator channel masking for single-shot reads uses ACC_MASK_REG via
> an ADDR_DESCENDING SPI write, which covers both mask bytes in a single
> 16-bit transfer.
>
> Reviewed-by: David Lechner <dlechner@baylibre.com>
> Signed-off-by: Radu Sabau <radu.sabau@analog.com>
Otherwise, just one question inline.
> diff --git a/drivers/iio/adc/ad4691.c b/drivers/iio/adc/ad4691.c
> new file mode 100644
> index 000000000000..cc1e2ef6bfd8
> --- /dev/null
> +++ b/drivers/iio/adc/ad4691.c
> +
> +static bool ad4691_volatile_reg(struct device *dev, unsigned int reg)
> +{
> + switch (reg) {
> + case AD4691_STATUS_REG:
> + case AD4691_CLAMP_STATUS1_REG:
> + case AD4691_CLAMP_STATUS2_REG:
> + case AD4691_GPIO_READ:
> + case AD4691_ACC_STATUS_FULL1_REG ... AD4691_ACC_STATUS_SAT2_REG:
> + case AD4691_ACC_SAT_OVR_REG(0) ... AD4691_ACC_SAT_OVR_REG(15):
> + return true;
> + default:
> + break;
> + }
> +
> + /*
> + * Multi-byte registers have non-unit strides; only accept base
> + * addresses to prevent debugfs from triggering reads that cross
> + * register boundaries.
What does this have to do with preventing debugfs from doing anything.
It should allow reading of volatile registers. Why is it not enough to
make the non base aligned registers neither readable nor writeable?
> + */
> + if (reg >= AD4691_AVG_IN(0) && reg <= AD4691_AVG_IN(15))
> + return (reg - AD4691_AVG_IN(0)) % 2 == 0;
> + if (reg >= AD4691_AVG_STS_IN(0) && reg <= AD4691_AVG_STS_IN(15))
> + return (reg - AD4691_AVG_STS_IN(0)) % 3 == 0;
> + if (reg >= AD4691_ACC_IN(0) && reg <= AD4691_ACC_IN(15))
> + return (reg - AD4691_ACC_IN(0)) % 3 == 0;
> + if (reg >= AD4691_ACC_STS_DATA(0) && reg <= AD4691_ACC_STS_DATA(15))
> + return (reg - AD4691_ACC_STS_DATA(0)) % 4 == 0;
> +
> + return false;
> +}
> +
> +static bool ad4691_readable_reg(struct device *dev, unsigned int reg)
> +{
> + switch (reg) {
> + case 0 ... AD4691_OSC_FREQ_REG:
> + case AD4691_SPARE_CONTROL ... AD4691_ACC_SAT_OVR_REG(15):
> + case AD4691_STD_SEQ_CONFIG:
> + return true;
> + default:
> + break;
> + }
> +
> + /* Multi-byte registers: only accept base addresses (see volatile_reg). */
> + if (reg >= AD4691_AVG_IN(0) && reg <= AD4691_AVG_IN(15))
> + return (reg - AD4691_AVG_IN(0)) % 2 == 0;
> + if (reg >= AD4691_AVG_STS_IN(0) && reg <= AD4691_AVG_STS_IN(15))
> + return (reg - AD4691_AVG_STS_IN(0)) % 3 == 0;
> + if (reg >= AD4691_ACC_IN(0) && reg <= AD4691_ACC_IN(15))
> + return (reg - AD4691_ACC_IN(0)) % 3 == 0;
> + if (reg >= AD4691_ACC_STS_DATA(0) && reg <= AD4691_ACC_STS_DATA(15))
> + return (reg - AD4691_ACC_STS_DATA(0)) % 4 == 0;
> +
> + return false;
> +}
> +static int ad4691_reset(struct ad4691_state *st)
> +{
> + struct device *dev = regmap_get_device(st->regmap);
> + struct reset_control *rst;
> + int ret;
> +
> + rst = devm_reset_control_get_optional_exclusive(dev, NULL);
> + if (IS_ERR(rst))
> + return dev_err_probe(dev, PTR_ERR(rst), "Failed to get reset\n");
> +
> + if (rst) {
> + /*
> + * Assert the reset line to guarantee a clean reset pulse on
> + * every probe, including driver reloads where the line may
> + * already be deasserted (reset_control_put() does not
> + * re-assert on release). tRESETL (minimum pulse width) = 10 ns
> + * (Table 5); kernel function-call overhead alone exceeds this,
> + * so no explicit delay is needed between assert and deassert.
> + */
> + reset_control_assert(rst);
> + ret = reset_control_deassert(rst);
> + if (ret)
> + return ret;
> + } else {
> + /* No hardware reset available, fall back to software reset. */
> + ret = regmap_write(st->regmap, AD4691_SPI_CONFIG_A_REG,
> + AD4691_SW_RESET);
> + if (ret)
> + return ret;
> + }
> +
> + /*
> + * Wait 300 µs (Table 5) for the device to complete its internal reset
> + * sequence before accepting SPI commands.
> + */
> + fsleep(300);
This is what sashiko was moaning about.
> + return 0;
> +}
^ permalink raw reply
* Re: [PATCH 2/3] ALSA: usb-audio: Add QUIRK_FLAG_MIXER_SKIP_GET_CUR_VOL
From: Rong Zhang @ 2026-05-27 17:58 UTC (permalink / raw)
To: Takashi Iwai
Cc: Jaroslav Kysela, Takashi Iwai, Jonathan Corbet, Shuah Khan,
Gordon Chen, linux-sound, linux-doc, linux-kernel
In-Reply-To: <87tsrtwgyc.wl-tiwai@suse.de>
Hi Takashi,
Thanks for your review.
On Wed, 2026-05-27 at 07:37 +0200, Takashi Iwai wrote:
> On Tue, 26 May 2026 19:49:24 +0200,
> Rong Zhang wrote:
> >
> > Since commit 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky
> > mixers"), the UAC mixer core utilizes volume SET_CUR and GET_CUR to
> > identify devices with sticky mixers. Unfortunately, even though most
> > devices with sticky GET_CUR also have corresponding sticky SET_CUR,
> > which I actually met more since the commit had been merged, there is
> > also a rare case that some devices may have volume mixers that responds
> > to SET_CUR properly but with its GET_CUR stubbed. This cause the sticky
> > check to consider the mixer to be sticky and unnecessarily disable it.
> >
> > Add QUIRK_FLAG_MIXER_SKIP_GET_CUR_VOL to prevent sending GET_CUR to
> > mixers by returning -ENXIO early. The error effectively skips the sticky
> > check as it's only meaningful when the mixer has some sort of self-
> > awareness. Similar to QUIRK_FLAG_GET_SAMPLE_RATE, this should also help
> > if some unmet devices can't tolerate volume GET_CUR in other ways.
> >
> > Signed-off-by: Rong Zhang <i@rong.moe>
> > ---
> > Documentation/sound/alsa-configuration.rst | 4 ++++
> > sound/usb/mixer.c | 5 +++++
> > sound/usb/quirks.c | 1 +
> > sound/usb/usbaudio.h | 6 ++++++
> > 4 files changed, 16 insertions(+)
> >
> > diff --git a/Documentation/sound/alsa-configuration.rst b/Documentation/sound/alsa-configuration.rst
> > index 4b30cd63c5a5..bc3bc65c379a 100644
> > --- a/Documentation/sound/alsa-configuration.rst
> > +++ b/Documentation/sound/alsa-configuration.rst
> > @@ -2389,6 +2389,10 @@ quirk_flags
> > from snd_usb_handle_sync_urb. Instead fall through and enqueue a
> > packet_info containing only size-0 packets, so the OUT ring keeps
> > moving (emits silence). Needed by Behringer Flow 8 (1397:050c).
> > + * bit 30: ``mixer_skip_get_cur_vol``
> > + Skip reading current volume for mixers, as some devices return
> > + constant values or errors but otherwise works fine, i.e., setting
> > + volume takes desired effect.
> >
> > This module supports multiple devices, autoprobe and hotplugging.
> >
> > diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c
> > index d61bde654219..3b745aebb181 100644
> > --- a/sound/usb/mixer.c
> > +++ b/sound/usb/mixer.c
> > @@ -420,6 +420,11 @@ static int get_cur_ctl_value(struct usb_mixer_elem_info *cval,
> > static inline int get_cur_mix_raw(struct usb_mixer_elem_info *cval,
> > int channel, int *value)
> > {
> > + struct snd_usb_audio *chip = cval->head.mixer->chip;
> > +
> > + if (chip->quirk_flags & QUIRK_FLAG_MIXER_SKIP_GET_CUR_VOL)
> > + return -ENXIO;
>
> So this workaround is applied to all mixer controls?
Hmm, it is indeed not very optimal. My initial idea was to prevent
returning bogus values at all, so I gated GET_CUR here. But as you've
said this could have a wide impact on other mixers...
>
> We can put it as a common quirk as you've done, but the question is
> how many devices need this, too...
While I am not sure if more devices need this (my intuition says yes),
how about a less radical approach that still relies on the sticky check?
- Rename the quirk flag to QUIRK_FLAG_MIXER_GET_CUR_BROKEN.
- Add a flag to struct usb_mixer_elem_info to gate GET_CUR.
- When the sticky check fails, check quirk flags. Gate further GET_CUR
if the quirk flag is set, otherwise disable the mixer as usual.
- A mixer with GET_CUR gated will solely relies on the internal cache of
last set volume.
The quirk flag still applies to all mixers, but as long as a mixer makes
the sticky check happy, it won't be affected at all. Only those mixers
with constant GET_CUR values will have their GET_CUR gated. I assume the
impact is minimal, since it's very unlikely a device would have sticky
mixers (broken SET_CUR) along with mixers with working SET_CUR but
broken GET_CUR at the same time.
Thanks,
Rong
>
>
> thanks,
>
> Takashi
^ permalink raw reply
* Re: [PATCH v2 08/10] riscv: cpufeature: Introduce ISA bases bitmap and rva23u64 detection
From: Andrew Jones @ 2026-05-27 17:04 UTC (permalink / raw)
To: Guodong Xu
Cc: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
Albert Ou, Alexandre Ghiti, Shuah Khan, Anup Patel, Atish Patra,
Shuah Khan, Deepak Gupta, Zong Li, Christian Brauner,
Charlie Jenkins, Samuel Holland, linux-doc, linux-riscv,
linux-kernel, linux-kselftest, kvm, kvm-riscv
In-Reply-To: <20260511-rva23u64-hwprobe-v2-v2-8-21c5a544f1dc@riscstar.com>
On Mon, May 11, 2026 at 09:34:53PM -0400, Guodong Xu wrote:
...
> + /* Zic64b and Supm with PMLEN=7 */
> + if (riscv_cbom_block_size != 64 ||
> + riscv_cbop_block_size != 64 ||
> + riscv_cboz_block_size != 64 ||
The only mandated RVA23U64 extension we don't have ISA string support for
is Zic64b. I wonder if we shouldn't add that support too where it would
have a validate check like above.
Thanks,
drew
^ permalink raw reply
* Re: [PATCH] mm/mempool: use static key for boot-time debug enablement
From: Vlastimil Babka (SUSE) @ 2026-05-27 16:43 UTC (permalink / raw)
To: Usama Arif, lirongqing
Cc: Jonathan Corbet, Shuah Khan, Harry Yoo, Andrew Morton, Hao Li,
Christoph Lameter, David Rientjes, Roman Gushchin, linux-doc,
linux-kernel, linux-mm
In-Reply-To: <20260527130337.983366-1-usama.arif@linux.dev>
On 5/27/26 15:03, Usama Arif wrote:
> On Wed, 27 May 2026 06:46:34 -0400 lirongqing <lirongqing@baidu.com> wrote:
>> static int __init mempool_faul_inject_init(void)
>> {
>> int error;
>> @@ -37,7 +54,6 @@ static int __init mempool_faul_inject_init(void)
>> }
>> late_initcall(mempool_faul_inject_init);
>>
>> -#ifdef CONFIG_SLUB_DEBUG_ON
>> static void poison_error(struct mempool *pool, void *element, size_t size,
>> size_t byte)
>> {
>> @@ -73,6 +89,9 @@ static void __check_element(struct mempool *pool, void *element, size_t size)
>>
>> static void check_element(struct mempool *pool, void *element)
>> {
>> + if (!static_branch_unlikely(&mempool_debug_enabled))
>> + return;
>> +
>> /* Skip checking: KASAN might save its metadata in the element. */
>> if (kasan_enabled())
>> return;
>> @@ -112,6 +131,9 @@ static void __poison_element(void *element, size_t size)
>>
>> static void poison_element(struct mempool *pool, void *element)
>> {
>> + if (!static_branch_unlikely(&mempool_debug_enabled))
>> + return;
>> +
>
> Before this change, building with CONFIG_SLUB_DEBUG_ON=y compiled in
> check_element() and poison_element() unconditionally, so the
> poisoning and corruption checks ran on every mempool free/alloc.
> After this change those checks are gated on the mempool_debug boot
> parameter even when CONFIG_SLUB_DEBUG_ON=y.
The same would apply to the dmapool_debug [1]
https://lore.kernel.org/all/20260524034015.1830-1-lirongqing@baidu.com/
> Existing users who relied on CONFIG_SLUB_DEBUG_ON=y giving them
> mempool poison checking will silently lose it on upgrade unless they
> also add "mempool_debug" to the command line.
>
> Would it be worth defaulting the static key to true under
> CONFIG_SLUB_DEBUG_ON=y, for example:
>
> #ifdef CONFIG_SLUB_DEBUG_ON
> static DEFINE_STATIC_KEY_TRUE(mempool_debug_enabled);
> #else
> static DEFINE_STATIC_KEY_FALSE(mempool_debug_enabled);
> #endif
>
> so the previous default behaviour is preserved.
There's DEFINE_STATIC_KEY_MAYBE for this.
But I think nobody will care really. My objection was that this and
dmapool_debug was tied to CONFIG_SLUB_DEBUG_ON in the first place, despite
not being part of slab. I'd rather disconnect it completely.
If testing bots relied on this, we could give them heads up to start using
those boot options. I assume they already use some for stuff that has no
CONFIG_ enablement.
>> /* Skip poisoning: KASAN might save its metadata in the element. */
>> if (kasan_enabled())
>> return;
>> @@ -140,14 +162,6 @@ static void poison_element(struct mempool *pool, void *element)
>> #endif
>> }
>> }
>> -#else /* CONFIG_SLUB_DEBUG_ON */
>> -static inline void check_element(struct mempool *pool, void *element)
>> -{
>> -}
>> -static inline void poison_element(struct mempool *pool, void *element)
>> -{
>> -}
>> -#endif /* CONFIG_SLUB_DEBUG_ON */
>>
>> static __always_inline bool kasan_poison_element(struct mempool *pool,
>> void *element)
>> --
>> 2.9.4
>>
>>
^ permalink raw reply
* Re: [PATCH v2 08/10] riscv: cpufeature: Introduce ISA bases bitmap and rva23u64 detection
From: Andrew Jones @ 2026-05-27 16:35 UTC (permalink / raw)
To: Guodong Xu
Cc: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
Albert Ou, Alexandre Ghiti, Shuah Khan, Anup Patel, Atish Patra,
Shuah Khan, Deepak Gupta, Zong Li, Christian Brauner,
Charlie Jenkins, Samuel Holland, linux-doc, linux-riscv,
linux-kernel, linux-kselftest, kvm, kvm-riscv
In-Reply-To: <20260511-rva23u64-hwprobe-v2-v2-8-21c5a544f1dc@riscstar.com>
On Mon, May 11, 2026 at 09:34:53PM -0400, Guodong Xu wrote:
> Introduce a per-hart and host-wide bitmap of conformant ISA "bases" --
> named profile-class sets such as IMA and RVA23U64 -- and compute
> both at init time.
>
> This is the cache that subsequent consumers (hwprobe's
> RVA23U64 base behavior bit, /proc/cpuinfo's "isa bases" lines, etc.)
> read without recomputing.
>
> riscv_init_isa_bases() iterates over all possible cpus to populate
> each hart_isa[cpu].isa_bases, then computes the host-wide
> riscv_isa_bases against the AND-across-harts riscv_isa bitmap. It is
> registered as a subsys_initcall so it executes after
> core_initcall(tagged_addr_init), which probes senvcfg.PMM and
> populates have_user_pmlen_*. Without that ordering,
> riscv_have_user_pmlen(7) would still return its default false and the
> RVA23U64 detection path would always bail.
>
> The detection itself is encapsulated in riscv_set_isa_bases(), which
> takes an output bases bitmap and an input ISA bitmap.
>
> Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
> v2:
> - Implement riscv_init_isa_bases() that runs at system init time,
> after tagged_addr_init() populates have_user_pmlen_*.
> - Split RVA23S64 placeholder into a future patch.
> ---
> arch/riscv/include/asm/cpufeature.h | 14 ++++++
> arch/riscv/kernel/cpufeature.c | 92 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 106 insertions(+)
Sashiko points out a few things about this patch which I think I
agree with
https://sashiko.dev/#/patchset/20260511-rva23u64-hwprobe-v2-v2-0-21c5a544f1dc%40riscstar.com?part=8
Additional nit below.
>
> diff --git a/arch/riscv/include/asm/cpufeature.h b/arch/riscv/include/asm/cpufeature.h
> index 739fcc84bf7b2..facc31b2960c6 100644
> --- a/arch/riscv/include/asm/cpufeature.h
> +++ b/arch/riscv/include/asm/cpufeature.h
> @@ -25,10 +25,24 @@ struct riscv_cpuinfo {
> unsigned long mimpid;
> };
>
> +enum {
> + RISCV_ISA_BASE_IMA,
> + RISCV_ISA_BASE_RVA23U64,
> + RISCV_NR_ISA_BASES,
> +};
> +
> +/**
> + * struct riscv_isainfo - per-hart ISA state
> + * @isa: bitmap of ISA extensions this hart implements
> + * @isa_bases: bitmap of profile bases this hart conforms to
> + */
> struct riscv_isainfo {
> DECLARE_BITMAP(isa, RISCV_ISA_EXT_MAX);
> + DECLARE_BITMAP(isa_bases, RISCV_NR_ISA_BASES);
> };
>
> +extern unsigned long riscv_isa_bases[BITS_TO_LONGS(RISCV_NR_ISA_BASES)];
> +
> DECLARE_PER_CPU(struct riscv_cpuinfo, riscv_cpuinfo);
>
> extern const struct seq_operations cpuinfo_op;
> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> index 81145621dc378..6e8dd33aa3888 100644
> --- a/arch/riscv/kernel/cpufeature.c
> +++ b/arch/riscv/kernel/cpufeature.c
> @@ -41,6 +41,9 @@ unsigned long elf_hwcap __read_mostly;
> /* Host ISA bitmap */
> static DECLARE_BITMAP(riscv_isa, RISCV_ISA_EXT_MAX) __read_mostly;
>
> +/* Host ISA bases bitmap */
> +DECLARE_BITMAP(riscv_isa_bases, RISCV_NR_ISA_BASES) __read_mostly;
> +
> /* Per-cpu ISA extensions. */
> struct riscv_isainfo hart_isa[NR_CPUS];
>
> @@ -1305,3 +1308,92 @@ void __init_or_module riscv_cpufeature_patch_func(struct alt_entry *begin,
> }
> }
> #endif
> +
> +/*
> + * Compute the set of profile bases (IMA, RVA23U64, ...) a hart
> + * conforms to, given its resolved ISA bitmap.
> + *
> + * If @isa_bitmap is NULL, the host ISA bitmap (the AND across all harts) is
> + * used.
> + */
> +static void riscv_set_isa_bases(unsigned long *bases, const unsigned long *isa_bitmap)
> +{
> + const unsigned long *isa = isa_bitmap ? isa_bitmap : riscv_isa;
> + DECLARE_BITMAP(ext_mask, RISCV_ISA_EXT_MAX) = { 0 };
> + DECLARE_BITMAP(tmp, RISCV_ISA_EXT_MAX);
> +
> + /* IMA */
> + set_bit(RISCV_ISA_EXT_I, ext_mask);
> + set_bit(RISCV_ISA_EXT_M, ext_mask);
> + set_bit(RISCV_ISA_EXT_A, ext_mask);
> +
> + if (bitmap_andnot(tmp, ext_mask, isa, RISCV_ISA_EXT_MAX))
> + return;
> +
> + set_bit(RISCV_ISA_BASE_IMA, bases);
> +
> + /* RVA23U64 */
> +
> + /* Zic64b and Supm with PMLEN=7 */
> + if (riscv_cbom_block_size != 64 ||
> + riscv_cbop_block_size != 64 ||
> + riscv_cboz_block_size != 64 ||
> + !riscv_have_user_pmlen(7))
> + return;
> +
> + set_bit(RISCV_ISA_EXT_F, ext_mask);
> + set_bit(RISCV_ISA_EXT_D, ext_mask);
> + set_bit(RISCV_ISA_EXT_C, ext_mask);
> + set_bit(RISCV_ISA_EXT_B, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZICSR, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZICNTR, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZIHPM, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZICCIF, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZICCRSE, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZICCAMOA, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZICCLSM, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZA64RS, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZIHINTPAUSE, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZICBOM, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZICBOP, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZICBOZ, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZFHMIN, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZKT, ext_mask);
> + set_bit(RISCV_ISA_EXT_V, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZVFHMIN, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZVBB, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZVKT, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZIHINTNTL, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZICOND, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZIMOP, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZCMOP, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZCB, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZFA, ext_mask);
> + set_bit(RISCV_ISA_EXT_ZAWRS, ext_mask);
> + set_bit(RISCV_ISA_EXT_SUPM, ext_mask);
> +
> + if (bitmap_andnot(tmp, ext_mask, isa, RISCV_ISA_EXT_MAX))
> + return;
> +
> + set_bit(RISCV_ISA_BASE_RVA23U64, bases);
> +}
> +
> +/*
> + * Populate the host ISA bases bitmap (riscv_isa_bases) and each
> + * hart's per-cpu isa_bases.
> + */
> +static int __init riscv_init_isa_bases(void)
> +{
> + int cpu;
> +
> + for_each_possible_cpu(cpu)
> + riscv_set_isa_bases(hart_isa[cpu].isa_bases, hart_isa[cpu].isa);
> +
> + riscv_set_isa_bases(riscv_isa_bases, NULL);
> + return 0;
> +}
Missing blank line here.
Thanks,
drew
> +/*
> + * Registered as subsys_initcall so it runs after
> + * core_initcall(tagged_addr_init) populates have_user_pmlen_*.
> + */
> +subsys_initcall(riscv_init_isa_bases);
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH net-next v06 3/6] hinic3: Add ethtool coalesce ops
From: Jakub Kicinski @ 2026-05-27 16:28 UTC (permalink / raw)
To: Fan Gong
Cc: Zhu Yikai, netdev, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Andrew Lunn, Ioana Ciornei, Mohsin Bashir,
linux-kernel, linux-doc, luosifu, Xin Guo, Zhou Shuai, Wu Like,
Shi Jing, Zheng Jiezhen, Maxime Chevallier
In-Reply-To: <4bead457b595de335c10878bc09af9b86cea65d0.1779867397.git.zhuyikai1@h-partners.com>
On Wed, 27 May 2026 15:55:58 +0800 Fan Gong wrote:
> Implement following ethtool callback function:
> .get_coalesce
> .set_coalesce
>
> These callbacks allow users to utilize ethtool for detailed
> RX coalesce configuration and monitoring.
>
> Co-developed-by: Zhu Yikai <zhuyikai1@h-partners.com>
> Signed-off-by: Zhu Yikai <zhuyikai1@h-partners.com>
> Signed-off-by: Fan Gong <gongfan1@huawei.com>
The NIPA CI coccicheck test is failing on the hinic3 ethtool series
(coalesce ops and/or rss ops patches). Four new Coccinelle warnings
were introduced in drivers/net/ethernet/huawei/hinic3/hinic3_ethtool.c:
hinic3_ethtool.c:1021:11-45: WARNING avoid newline at end of message in NL_SET_ERR_MSG_FMT_MOD
hinic3_ethtool.c:1055:12-37: WARNING avoid newline at end of message in NL_SET_ERR_MSG_FMT_MOD
hinic3_ethtool.c:1078:11-62: WARNING avoid newline at end of message in NL_SET_ERR_MSG_FMT_MOD
hinic3_ethtool.c:1215:29-58: WARNING avoid newline at end of message in NL_SET_ERR_MSG_MOD
The NL_SET_ERR_MSG_MOD() and NL_SET_ERR_MSG_FMT_MOD() macros must not
be given a message string that ends with '\n'. The netlink error-message
infrastructure handles message termination itself; a trailing newline
results in malformed extack messages visible to user space.
Please remove the trailing '\n' from all four call sites, e.g.:
- NL_SET_ERR_MSG_FMT_MOD(extack, "some message\n");
+ NL_SET_ERR_MSG_FMT_MOD(extack, "some message");
The same rule applies to NL_SET_ERR_MSG_MOD() and the other
NL_SET_ERR_MSG* family of macros throughout the driver.
^ permalink raw reply
* [PATCH] docs: pt_BR: add translation for kernel development process guides
From: Daniel Pereira @ 2026-05-27 15:53 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-doc, Daniel Pereira
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 31217 bytes --]
Add the Brazilian Portuguese (pt_BR) translation for the
'development-process.rst' and '2.process.rst' files under
the 'process/' directory.
The main 'index.rst' file is also updated to include references
to the newly translated documents in the toctree.
Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
Documentation/translations/pt_BR/index.rst | 1 +
.../translations/pt_BR/process/2.Process.rst | 520 ++++++++++++++++++
.../pt_BR/process/development-process.rst | 21 +
3 files changed, 542 insertions(+)
create mode 100644 Documentation/translations/pt_BR/process/2.Process.rst
create mode 100644 Documentation/translations/pt_BR/process/development-process.rst
diff --git a/Documentation/translations/pt_BR/index.rst b/Documentation/translations/pt_BR/index.rst
index 76936710b..7a488f662 100644
--- a/Documentation/translations/pt_BR/index.rst
+++ b/Documentation/translations/pt_BR/index.rst
@@ -67,6 +67,7 @@ kernel e sobre como ver seu trabalho integrado.
:maxdepth: 1
Introdução <process/1.Intro>
+ Guia do Processo de Desenvolvimento <process/development-process>
Index de documentos do Kernel <process/kernel-docs>
Regras de licenciamento <process/license-rules>
Como começar <process/howto>
diff --git a/Documentation/translations/pt_BR/process/2.Process.rst b/Documentation/translations/pt_BR/process/2.Process.rst
new file mode 100644
index 000000000..5ff35f10a
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/2.Process.rst
@@ -0,0 +1,520 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Como funciona o processo de desenvolvimento
+===========================================
+
+O desenvolvimento do kernel Linux no início dos anos 1990 era uma
+atividade bastante informal, envolvendo um número relativamente pequeno de
+usuários e desenvolvedores. Com uma base de usuários atualmente na casa
+dos milhões e com cerca de 2.000 desenvolvedores envolvidos ao longo de
+um ano, o kernel desde então teve que evoluir uma série de processos
+para manter o desenvolvimento acontecendo de forma fluida. Uma
+compreensão sólida de como o processo funciona é necessária para ser uma
+parte eficaz dele.
+
+A Visão Geral
+-------------
+
+O kernel Linux usa um modelo de desenvolvimento de lançamento contínuo
+(*rolling release*), vagamente baseado em tempo. Um novo lançamento de
+versão principal do kernel (que chamaremos, como exemplo, de 9.x) [1]_
+ocorre a cada dois ou três meses, trazendo novos recursos, alterações em
+APIs internas e muito mais. Um lançamento típico pode conter cerca de
+13.000 conjuntos de alterações (*changesets*) com modificações em várias
+centenas de milhares de linhas de código. Lançamentos recentes,
+juntamente com suas datas, podem ser encontrados na `Wikipedia
+<https://en.wikipedia.org/wiki/Linux_kernel_version_history>`_.
+
+.. [1] Rigorosamente falando, o kernel Linux não utiliza o esquema de
+ numeração de versionamento semântico, mas, em vez disso, o par
+ 9.x identifica a versão de lançamento principal como um número
+ inteiro. Para cada lançamento, x é incrementado, mas o 9 é
+ incrementado apenas se x for considerado grande o suficiente
+ (por exemplo, o Linux 5.0 foi lançado após o Linux 4.20).
+
+O processo de integração (*merging*) de patches segue um fluxo simples a
+cada lançamento. No início de cada ciclo de desenvolvimento, abre-se a
+**"janela de integração" (*merge window*)**. Durante esse período, todo
+código considerado estável e aprovado pela comunidade é unificado ao
+kernel principal (*mainline*). A maior parte das novidades e todas as
+grandes mudanças estruturais — entra obrigatoriamente nessa fase, em um
+ritmo frenético que chega a **1.000 patches (ou conjuntos de alterações)
+por dia**.
+
+(Como observação secundária, vale destacar que as mudanças integradas durante
+a janela de integração não surgem do nada; elas foram coletadas, testadas e
+organizadas com antecedência. Como esse processo funciona será descrito em
+detalhes mais adiante).
+
+A janela de integração dura aproximadamente duas semanas. Ao final desse
+período, Linus Torvalds declarará que a janela está fechada e lançará o
+primeiro dos kernels "rc". Para o kernel que está destinado a ser o 9.x,
+por exemplo, o lançamento que ocorre ao final da janela de integração será
+chamado de 9.x-rc1. O lançamento -rc1 é o sinal de que o prazo para integrar
+novos recursos terminou e que o período para estabilizar o próximo kernel
+começou.
+
+Ao longo das próximas seis a dez semanas, apenas patches que corrijam
+problemas devem ser submetidos ao kernel principal. Ocasionalmente, uma
+mudança mais significativa será permitida, mas esses casos são raros;
+desenvolvedores que tentam integrar novos recursos fora da janela de
+integração costumam receber uma recepção pouco amigável. Como regra geral,
+se você perder a janela de integração para um determinado recurso, o melhor
+a fazer é esperar pelo próximo ciclo de desenvolvimento. (Abre-se uma
+exceção ocasional para drivers de hardware que antes não eram suportados;
+se eles não modificarem nenhum código já existente na árvore, não podem
+causar regressões e deve ser seguro adicioná-los a qualquer momento).
+
+À medida que as correções são integradas ao kernel principal, o ritmo de
+envio de patches diminui com o tempo. Linus lança novos kernels -rc cerca
+de uma vez por semana; uma série normal chega a algo entre -rc6 e -rc9 antes
+que o kernel seja considerado suficientemente estável e o lançamento final
+seja realizado. Nesse ponto, todo o processo recomeça.
+
+Como exemplo, veja como ocorreu o ciclo de desenvolvimento da versão 5.4
+(todas as datas são de 2019):
+
+ ============== ===============================
+ Setembro 15 5.3 Lançamento estável do 5.3
+ Setembro 30 5.4-rc1, fechamento da janela de integração
+ Outubro 6 5.4-rc2
+ Outubro 13 5.4-rc3
+ Outubro 20 5.4-rc4
+ October 27 5.4-rc5
+ Novembro 3 5.4-rc6
+ Novembro 10 5.4-rc7
+ Novembro 17 5.4-rc8
+ Novembro 24 5.4 Lançamento estável do 5.4
+ ============== ===============================
+
+Como os desenvolvedores decidem quando encerrar o ciclo de desenvolvimento
+e criar o lançamento estável? A métrica mais significativa utilizada é a
+lista de regressões de lançamentos anteriores. Nenhum bug é bem-vindo, mas
+aqueles que quebram sistemas que funcionavam no passado são considerados
+especialmente graves. Por esta razão, patches que causam regressões são
+vistos de forma desfavorável e têm grande probabilidade de serem revertidos
+durante o período de estabilização.
+
+O objetivo dos desenvolvedores é corrigir todas as regressões conhecidas
+antes que o lançamento estável seja feito. No mundo real, esse tipo de
+perfeição é difícil de alcançar; há simplesmente variáveis demais em um
+projeto deste tamanho. Chega um ponto em que adiar o lançamento final apenas
+torna o problema pior; o volume de mudanças esperando pela próxima janela de
+integração crescerá ainda mais, criando ainda mais regressões no ciclo
+seguinte. Portanto, a maioria dos kernels é lançada com um pequeno número de
+regressões conhecidas, embora, felizmente, nenhuma delas seja grave.
+
+Assim que um lançamento estável é feito, sua manutenção contínua é passada
+para a "equipe estável" (*stable team*), atualmente composta por Greg
+Kroah-Hartman e Sasha Levin. A equipe estável lançará atualizações ocasionais
+para a versão estável utilizando o esquema de numeração 9.x.y.
+
+Para ser considerado para um lançamento de atualização, um patch deve (1)
+corrigir um bug significativo e (2) já estar integrado ao kernel principal
+(*mainline*) para o próximo kernel de desenvolvimento. Os kernels normalmente
+receberão atualizações estáveis por um pouco mais de um ciclo de
+desenvolvimento após o seu lançamento inicial. Assim, por exemplo, o histórico
+do kernel 5.2 ocorreu da seguinte forma (todas as datas são de 2019):
+
+ ============== ===============================
+ 7 de Julho Lançamento estável do 5.2
+ 14 de Julho 5.2.1
+ 21 de Julho 5.2.2
+ 26 de Julho 5.2.3
+ 28 de Julho 5.2.4
+ 31 de Julho 5.2.5
+ ... ...
+ 11 de Outubro 5.2.21
+ ============== ===============================
+
+A versão 5.2.21 foi a última atualização estável do lançamento 5.2.
+
+Alguns kernels são designados como kernels de "longo prazo" (*long term*);
+eles receberão suporte por um período mais longo. Por favor, consulte o
+seguinte link para obter a lista de versões ativas do kernel de longo prazo
+e seus respectivos mantenedores:
+
+ https://www.kernel.org/category/releases.html
+
+A seleção de um kernel para suporte de longo prazo é puramente uma questão
+de um mantenedor ter a necessidade e o tempo para manter esse lançamento.
+Não há planos conhecidos para suporte de longo prazo para nenhum lançamento
+futuro específico.
+
+
+O Ciclo de Vida de um Patch
+---------------------------
+
+Os patches não vão diretamente do teclado do desenvolvedor para o kernel
+principal. Em vez disso, existe um processo um tanto complexo (embora um
+tanto informal) projetado para garantir que cada patch seja revisado quanto
+à sua qualidade e que cada patch implemente uma mudança que seja desejável
+ter no mainline. Esse processo pode acontecer rapidamente para correções
+menores ou, no caso de mudanças grandes e controversas, arrastar-se por
+anos. Grande parte da frustração dos desenvolvedores vem da falta de
+compreensão desse processo ou de tentativas de burlá-lo.
+
+Com a esperança de reduzir essa frustração, este documento descreverá como
+um patch entra no kernel. O que se segue abaixo é uma introdução que
+descreve o processo de uma forma um tanto idealizada. Um tratamento muito
+mais detalhado virá nas seções posteriores.
+
+As etapas pelas quais um patch passa são, geralmente:
+
+ - Design. É aqui que os requisitos reais para o patch e a forma
+ como esses requisitos serão atendidos são definidos. O trabalho de
+ design geralmente é feito sem envolver a comunidade, mas é melhor realizar
+ esse trabalho abertamente, se possível; isso pode economizar muito tempo
+ evitando ter que refazer o projeto mais tarde.
+
+ - Revisão inicial. Os patches são postados na lista de
+ discussão relevante, e os desenvolvedores dessa lista respondem com os
+ comentários que tiverem. Se tudo correr bem, esse processo deve apontar
+ qualquer problema grave no patch.
+
+ - Revisão ampla. Quando o patch estiver próximo de estar
+ pronto para inclusão no mainline, ele deve ser aceito por um mantenedor de
+ subsistema relevante — embora essa aceitação não seja uma garantia de que
+ o patch chegará até o kernel principal. O patch aparecerá na árvore de
+ subsistema do mantenedor e nas árvores -next. Quando o processo funciona,
+ esta etapa leva a uma revisão mais ampla do patch e à descoberta de
+ quaisquer problemas resultantes da integração deste patch com o trabalho
+ que está sendo feito por outros.
+
+ - Por favor, note que a maioria dos mantenedores também tem seus empregos
+ regulares, portanto, integrar o seu patch pode não ser a maior prioridade
+ deles. Se o seu patch estiver recebendo feedback sobre alterações que são
+ necessárias, você deve fazer essas alterações ou justificar por que elas
+ não devem ser feitas. Se o seu patch não tiver nenhuma objeção de revisão,
+ mas não estiver sendo integrado pelo mantenedor do subsistema ou driver
+ adequado, você deve ser persistente em atualizar o patch para o kernel
+ atual (garantindo que ele seja aplicado de forma limpa) e continuar
+ enviando-o para revisão e integração.
+
+ - Integração no mainline. Eventualmente, um
+ patch bem-sucedido será integrado ao repositório principal (*mainline*)
+ gerenciado por Linus Torvalds. Mais comentários e/ou problemas podem surgir
+ neste momento; é importante que o desenvolvedor seja responsivo a eles e
+ corrija quaisquer problemas que venham a aparecer.
+
+ - Lançamento estável. O número de usuários potencialmente
+ afetados pelo patch agora é grande, portanto, mais uma vez, novos
+ problemas podem surgir.
+
+ - Manutenção de longo prazo. Embora seja perfeitamente
+ possível para um desenvolvedor esquecer o código após integrá-lo, esse
+ tipo de comportamento tende a deixar uma má impressão na comunidade de
+ desenvolvimento. Integrar o código elimina parte do fardo de manutenção,
+ já que outros corrigirão problemas causados por mudanças de API. No entanto,
+ o desenvolvedor original deve continuar assumindo a responsabilidade pelo
+ código se ele quiser que este permaneça útil no longo prazo.
+
+Um dos maiores erros cometidos por desenvolvedores do kernel (ou por seus
+empregadores) é tentar reduzir todo o processo a uma única etapa de
+"integração no mainline". Essa abordagem invariavelmente leva à frustração
+de todos os envolvidos.
+
+Como os patches entram no Kernel
+--------------------------------
+
+Existe exatamente uma pessoa que pode integrar patches no repositório do
+kernel principal: Linus Torvalds. Mas, por exemplo, dos mais de 9.500 patches
+que entraram no kernel 2.6.38, apenas 112 (cerca de 1,3%) foram escolhidos
+diretamente pelo próprio Linus. O projeto do kernel há muito tempo cresceu
+para um tamanho onde nenhum desenvolvedor sozinho conseguiria inspecionar e
+selecionar cada patch sem ajuda. A maneira como os desenvolvedores do kernel
+lidaram com esse crescimento foi através do uso de um sistema de "tenentes"
+(*lieutenant system*) construído em torno de uma cadeia de confiança.
+
+A base de código do kernel é logicamente dividida em um conjunto de
+subsistemas: rede, suporte a arquiteturas específicas,
+gerenciamento de memória, dispositivos de vídeo, etc. A maioria dos
+subsistemas possui um mantenedor designado, um desenvolvedor que tem a
+responsabilidade geral pelo código dentro daquele subsistema. Esses
+mantenedores de subsistemas são os guardiões (de forma flexível)
+da parte do kernel que gerenciam; são eles que (geralmente) aceitarão um
+patch para inclusão no kernel principal.
+
+Cada um dos mantenedores de subsistemas gerencia sua própria versão da árvore
+de fontes do kernel, geralmente (mas certamente nem sempre) usando a
+ferramenta de gerenciamento de código-fonte Git. Ferramentas como o Git
+(e ferramentas relacionadas como o quilt ou mercurial) permitem que os
+mantenedores acompanhem uma lista de patches, incluindo informações de
+autoria e outros metadados. A qualquer momento, o mantenedor pode identificar
+quais patches em seu repositório não são encontrados no mainline.
+
+Quando a janela de integração se abre, os mantenedores de
+alto nível pedirão a Linus para realizar o pull de seus repositórios os patches
+que selecionaram para integração. Se Linus concordar, o fluxo de patches
+subirá para o seu repositório, tornando-se parte do kernel principal. A
+quantidade de atenção que Linus dedica a patches específicos
+recebidos em uma operação de pull varia. Está claro que, às vezes, ele os
+examina bem de perto. Mas, como regra geral, Linus confia que os mantenedores
+de subsistemas não enviarão patches ruins para o upstream.
+
+Os mantenedores de subsistemas, por sua vez, podem realizar o pull dos patches
+de outros mantenedores. Por exemplo, a árvore de rede é
+construída a partir de patches que se acumularam primeiro em árvores dedicadas
+a drivers de dispositivos de rede, rede sem fio, etc. Essa cadeia
+de repositórios pode ser arbitrariamente longa, embora raramente exceda dois
+ou três elos. Como cada mantenedor na cadeia confia naqueles que gerenciam as
+árvores de nível inferior, esse processo é conhecido como a "cadeia de
+confiança".
+
+Claramente, em um sistema como este, colocar patches no kernel depende de
+encontrar o mantenedor correto. Enviar patches diretamente para Linus
+normalmente não é o caminho certo a seguir.
+
+
+Árvore -next
+-------------
+
+A cadeia de árvores de subsistemas orienta o fluxo de patches para o kernel,
+mas também levanta uma questão interessante: e se alguém quiser dar uma
+olhada em todos os patches que estão sendo preparados para a próxima janela
+de integração? Os desenvolvedores estarão interessados em saber quais outras
+mudanças estão pendentes para ver se há conflitos com os quais se preocupar; um
+patch que altera o protótipo de uma função central do kernel, por exemplo,
+entrará em conflito com quaisquer outros patches que usem a forma mais antiga
+dessa função. Revisores e testadores querem ter acesso às mudanças em sua forma
+integrada antes que todas essas alterações cheguem ao kernel principal. Seria
+possível realizar o pull das mudanças de todas as árvores de subsistemas
+interessantes, mas isso seria um trabalho enorme e propenso a erros.
+
+A resposta vem na forma das árvores -next, onde as árvores de subsistemas
+são coletadas para testes e revisão. A mais antiga dessas árvores, mantida
+por Andrew Morton, é chamada de "-mm" (de *memory management*, gerenciamento
+de memória, que foi como ela começou). A árvore -mm integra patches de uma
+longa lista de árvores de subsistemas; ela também possui alguns patches
+destinados a ajudar na depuração (*debugging*).
+
+Além disso, a árvore -mm contém uma coleção significativa de patches que
+foram selecionados diretamente por Andrew. Esses patches podem ter sido
+postados em uma lista de discussão ou podem se aplicar a uma parte do kernel
+para a qual não existe uma árvore de subsistema designada. Como resultado, a
+-mm opera como uma espécie de árvore de subsistema de "último recurso"; se
+não houver outro caminho óbvio para um patch entrar no mainline, é provável
+que ele acabe na -mm. Patches diversos que se acumulam na
+-mm eventualmente serão encaminhados para uma árvore de subsistema adequada
+ou enviados diretamente para Linus. Em um ciclo de desenvolvimento típico,
+aproximadamente 5% a 10% do total de patches que entram no mainline chegam
+lá por meio da -mm.
+
+O patch -mm atual está disponível no diretório "mmotm" (*-mm of the moment*)
+em:
+
+ https://www.ozlabs.org/~akpm/mmotm/
+
+O uso da árvore MMOTM, no entanto, provavelmente será uma experiência
+frustrante; existe uma chance real de que ela sequer compile.
+
+A árvore primária para a integração de patches do próximo ciclo é a
+linux-next, mantida por Mark Brown. A árvore linux-next é, por design, um
+snapshot do que se espera que o mainline se pareça após o
+fechamento da próxima janela de integração. As árvores
+linux-next são anunciadas nas listas de discussão linux-kernel e linux-next
+quando são montadas; elas podem ser baixadas em:
+
+ https://www.kernel.org/pub/linux/kernel/next/
+
+A linux-next tornou-se uma parte integrante do processo de desenvolvimento
+do kernel; todos os patches integrados durante uma determinada janela de
+integração devem, idealmente, ter encontrado seu caminho para a linux-next algum
+tempo antes da abertura da janela de integração.
+
+
+Árvores de laboratório
+----------------------
+
+A árvore de fontes do kernel contém o diretório drivers/staging/, onde residem
+muitos subdiretórios para drivers ou sistemas de arquivos que estão a caminho
+de serem adicionados à árvore do kernel. Eles permanecem em drivers/staging/
+enquanto ainda precisam de mais trabalho; uma vez concluídos, podem ser movidos
+para o kernel proper Esta é uma maneira de acompanhar drivers que não estão à
+altura dos padrões de codificação ou de qualidade do kernel Linux, mas que as
+pessoas podem querer usar e acompanhar o desenvolvimento.
+
+Greg Kroah-Hartman atualmente mantém a árvore de staging. Os drivers que
+ainda precisam de trabalho são enviados a ele, com cada driver tendo seu
+próprio subdiretório em drivers/staging/. Junto com os arquivos de código-fonte
+do driver, um arquivo TODO também deve estar presente no diretório. O arquivo
+TODO lista o trabalho pendente que o driver precisa para ser aceito no kernel
+propriamente dito, bem como uma lista de pessoas que devem receber cópia
+(*Cc'd*) em quaisquer patches para o driver. As regras atuais exigem que os
+drivers contribuídos para o staging devem, no mínimo, compilar corretamente.
+
+O staging pode ser uma maneira relativamente fácil de colocar novos drivers
+no mainline onde, com sorte, eles chamarão a atenção de outros desenvolvedores
+e melhorarão rapidamente. No entanto, a entrada no staging não é o fim da
+história; o código no staging que não apresentar progresso regular será,
+eventualmente, removido. Os distribuidores também tendem a ser relativamente
+relutantes em habilitar drivers do staging. Portanto, o staging é, na melhor
+das hipóteses, uma parada no caminho para se tornar um driver mainline adequado.
+
+
+Ferramentas
+-----------
+
+Como pode ser visto no texto acima, o processo de desenvolvimento do kernel
+depende fortemente da capacidade de guiar coleções de patches em várias
+direções. Todo esse sistema não funcionaria nem de longe tão bem quanto
+funciona sem ferramentas adequadamente poderosas. Tutoriais sobre como usar
+essas ferramentas estão muito além do escopo deste documento, mas há espaço
+para algumas indicações.
+
+De longe, o sistema de gerenciamento de código-fonte dominante usado pela
+comunidade do kernel é o Git. O Git é um entre vários sistemas de controle
+de versão distribuídos desenvolvidos na comunidade de software livre. Ele é
+bem sintonizado para o desenvolvimento do kernel, uma vez que apresenta um
+excelente desempenho ao lidar com grandes repositórios e grandes volumes de
+patches. Ele também tem a reputação de ser difícil de aprender e usar, embora
+tenha melhorado ao longo do tempo. Algum tipo de familiaridade com o Git é
+quase um requisito para os desenvolvedores do kernel; mesmo que não o usem
+em seu próprio trabalho, eles precisarão do Git para acompanhar o que outros
+desenvolvedores (e o mainline) estão fazendo.
+
+O Git agora é empacotado por quase todas as distribuições Linux. Existe uma
+página inicial em:
+
+ https://git-scm.com/
+
+Essa página possui indicações para documentações e tutoriais.
+
+Entre os desenvolvedores do kernel que não usam o Git, a escolha mais popular
+é, quase certamente, o Mercurial:
+
+ https://www.selenic.com/mercurial/
+
+O Mercurial compartilha muitos recursos com o Git, mas oferece uma interface
+que muitos consideram mais fácil de usar.
+
+A outra ferramenta que vale a pena conhecer é o Quilt:
+
+ https://savannah.nongnu.org/projects/quilt/
+
+O Quilt é um sistema de gerenciamento de patches, em vez de um sistema de
+gerenciamento de código-fonte. Ele não rastreia o histórico ao longo do
+tempo; em vez disso, ele é orientado a rastrear um conjunto específico de
+alterações em relação a uma base de código em evolução. Alguns mantenedores
+de grandes subsistemas usam o Quilt para gerenciar patches destinados a ir
+para o upstream. Para o gerenciamento de certos tipos de árvores (-mm, por
+exemplo), o Quilt é a melhor ferramenta para o trabalho.
+
+
+Listas de discussão
+-------------------
+
+Uma grande parte do trabalho de desenvolvimento do kernel Linux é realizada por
+meio de listas de discussão. É difícil ser um membro plenamente ativo da
+comunidade sem se inscrever em pelo menos uma lista em algum lugar. No entanto,
+as listas de discussão do Linux também representam um risco potencial para os
+desenvolvedores, que correm o risco de serem soterrados por uma avalanche de
+e-mails, de violar as convenções utilizadas nas listas do Linux, ou ambos.
+
+A maioria das listas de discussão do kernel é hospedada no kernel.org; a
+lista mestre pode ser encontrada em:
+
+ https://subspace.kernel.org
+
+Existem listas hospedadas em outros locais; por favor, verifique o arquivo
+MAINTAINERS para encontrar a lista relevante para qualquer subsistema específico.
+
+A lista de discussão central para o desenvolvimento do kernel é, naturalmente,
+a linux-kernel. Esta lista é um lugar intimidador para se estar; o volume pode
+atingir 500 mensagens por dia, a quantidade de ruído é alta, a conversa pode
+ser severamente técnica e os participantes nem sempre estão preocupados em
+demonstrar um alto grau de polidez. No entanto, não há outro lugar onde a
+comunidade de desenvolvimento do kernel se reúna como um todo; desenvolvedores
+que evitam esta lista perderão informações importantes.
+
+Existem algumas dicas que podem ajudar na sobrevivência na lista linux-kernel:
+
+- Faça com que a lista seja entregue em uma pasta separada, em vez de na sua
+ caixa de entrada principal. É preciso ser capaz de ignorar o fluxo de e-mails
+ por períodos prolongados de tempo.
+
+- Não tente acompanhar cada conversa ninguém mais faz isso. É importante
+ filtrar tanto pelo tópico de interesse (embora note que conversas longas
+ podem se desviar do assunto original sem que a linha de assunto do e-mail
+ seja alterada) quanto pelas pessoas que estão participando.
+
+- Não alimente os trolls. Se alguém estiver tentando provocar uma resposta
+ irada, ignore-o.
+
+- Ao responder a um e-mail da lista linux-kernel (o mesmo valendo para outras
+ listas), preserve o cabeçalho Cc: para todos os envolvidos. Na ausência de um
+ motivo forte (como uma solicitação explícita), você nunca deve remover
+ destinatários. Sempre certifique-se de que a pessoa a quem você está
+ respondendo esteja na lista de Cc:. Essa convenção também torna desnecessário
+ solicitar explicitamente ser copiado em respostas às suas postagens.
+
+- Pesquise nos arquivos da lista (e na internet como um todo) antes de fazer
+ perguntas. Alguns desenvolvedores podem ficar impacientes com pessoas que
+ claramente não fizeram sua lição de casa.
+
+- Use respostas intercaladas, o que torna sua resposta mais fácil
+ de ler. (ou seja, evite o "top-posting" — a prática de colocar sua resposta
+ acima do texto citado ao qual você está respondendo). Para mais detalhes, veja
+ :ref:`Documentation/process/submitting-patches.rst <interleaved_replies>`.
+
+- Pergunte na lista de discussão correta. A lista linux-kernel pode até ser o
+ ponto de encontro geral, mas não é o melhor lugar para encontrar desenvolvedores
+ de todos os subsistemas.
+
+O último ponto, encontrar a lista de discussão correta é um lugar comum
+onde os desenvolvedores iniciantes costumam errar. Alguém que faça uma pergunta
+relacionada a redes na lista linux-kernel quase certamente receberá uma
+sugestão educada para perguntar na lista netdev em seu lugar, já que essa é a
+lista frequentada pela maioria dos desenvolvedores de redes. Existem outras
+listas para os subsistemas SCSI, video4linux, IDE, filesystem (sistemas de
+arquivos), etc. O melhor lugar para procurar por listas de discussão é no
+arquivo MAINTAINERS empacotado junto com o código-fonte do kernel.
+
+
+Começando com o desenvolvimento do kernel
+-----------------------------------------
+
+Perguntas sobre como começar com o processo de desenvolvimento do kernel são
+comuns — tanto por parte de indivíduos quanto de empresas. Igualmente comuns
+são os passos em falso que tornam o início do relacionamento mais difícil do
+que precisa ser.
+
+As empresas frequentemente buscam contratar desenvolvedores bem conhecidos para
+dar o pontapé inicial em um grupo de desenvolvimento. Esta pode, de fato, ser
+uma técnica eficaz. No entanto, ela também tende a ser cara e não faz muito para
+expandir o grupo de desenvolvedores de kernel experientes. É possível capacitar
+desenvolvedores internos no desenvolvimento do kernel Linux, desde que haja o
+investimento de um pouco de tempo. Dedicar esse tempo pode dotar um empregador
+de um grupo de desenvolvedores que entendem tanto o kernel quanto a própria
+empresa, e que também podem ajudar a treinar outros. A médio prazo, esta é
+frequentemente a abordagem mais lucrativa.
+
+Desenvolvedores individuais frequentemente, e de forma compreensível, ficam sem
+saber por onde começar. Iniciar com um grande projeto pode ser intimidante;
+muitas vezes deseja-se testar o terreno com algo menor primeiro. Este é o ponto
+onde alguns desenvolvedores saltam para a criação de patches que corrigem erros
+de ortografia ou pequenos problemas de estilo de código. Infelizmente, tais
+patches criam um nível de ruído que distrai a comunidade de desenvolvimento
+como um todo, por isso, cada vez mais, eles são vistos com desdém. Novos
+desenvolvedores que desejam se apresentar à comunidade não receberão o tipo de
+recepção que desejam por esses meios.
+
+Andrew Morton dá este conselho para aspirantes a desenvolvedores do kernel:
+
+::
+
+ "O projeto número um para todos os iniciantes no kernel certamente deveria
+ ser 'certificar-se de que o kernel funcione perfeitamente o tempo todo em
+ todas as máquinas em que você conseguir colocar as mãos'. Normalmente, a
+ maneira de fazer isso é trabalhar com outros para resolver as coisas (isso
+ pode exigir persistência!), mas tudo bem — isso é parte do desenvolvimento
+ do kernel."
+
+(https://lwn.net/Articles/283982/).
+
+Na ausência de problemas óbvios para corrigir, os desenvolvedores são
+aconselhados a olhar para as listas atuais de regressões e bugs abertos em
+geral. Nunca há escassez de problemas que precisam de correção; ao abordar
+esses problemas, os desenvolvedores ganharão experiência com o processo
+enquanto, ao mesmo tempo, constroem respeito com o restante da comunidade de
+desenvolvimento.
diff --git a/Documentation/translations/pt_BR/process/development-process.rst b/Documentation/translations/pt_BR/process/development-process.rst
new file mode 100644
index 000000000..737fdcdff
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/development-process.rst
@@ -0,0 +1,21 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Guia para o Processo de Desenvolvimento do Kernel
+=================================================
+
+O objetivo deste documento é ajudar desenvolvedores (e seus gerentes)
+a trabalhar com a comunidade de desenvolvimento com o mínimo de frustração.
+É uma tentativa de documentar como esta comunidade funciona de uma forma
+que seja acessível àqueles que não estão intimamente familiarizados com o
+desenvolvimento do kernel Linux (ou, de fato, com o desenvolvimento de
+software livre em geral). Embora haja algum material técnico aqui, esta
+é fundamentalmente uma discussão orientada ao processo, que não requer um
+conhecimento profundo de programação de kernel para ser compreendida.
+
+.. toctree::
+ :caption: Contents
+ :numbered:
+ :maxdepth: 2
+
+ 1.Intro
+ 2.Process
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2 04/10] riscv: Add Zicclsm to cpufeature and hwprobe
From: Andrew Jones @ 2026-05-27 15:53 UTC (permalink / raw)
To: Guodong Xu
Cc: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
Albert Ou, Alexandre Ghiti, Shuah Khan, Anup Patel, Atish Patra,
Shuah Khan, Deepak Gupta, Zong Li, Christian Brauner,
Charlie Jenkins, Samuel Holland, linux-doc, linux-riscv,
linux-kernel, linux-kselftest, kvm, kvm-riscv, Jesse Taube,
Andy Chiu
In-Reply-To: <20260511-rva23u64-hwprobe-v2-v2-4-21c5a544f1dc@riscstar.com>
On Mon, May 11, 2026 at 09:34:49PM -0400, Guodong Xu wrote:
> From: Jesse Taube <jesse@rivosinc.com>
>
> Zicclsm requires misaligned support for all regular load and store
> instructions, both scalar and vector, but not AMOs or other
> specialized forms of memory access, to main memory regions with both
> the cacheability and coherence PMAs, as defined in the profiles spec.
> Even though mandated, misaligned loads and stores might execute
> extremely slowly. Standard software distributions should assume their
> existence only for correctness, not for performance.
>
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> Reviewed-by: Andy Chiu <andy.chiu@sifive.com>
> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com>
> Tested-by: Charlie Jenkins <charlie@rivosinc.com>
> Signed-off-by: Jesse Taube <jesse@rivosinc.com>
> [Rebased, rewrote doc text, minor commit message revisions]
> Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
>
> ---
> v2:
> - Rebased onto v7.1-rc2; moved ZICCLSM to IMA_EXT_1 and
> allocated a new bit for it
> ---
> Documentation/arch/riscv/hwprobe.rst | 4 ++++
> arch/riscv/include/asm/hwcap.h | 1 +
> arch/riscv/include/uapi/asm/hwprobe.h | 1 +
> arch/riscv/kernel/cpufeature.c | 1 +
> arch/riscv/kernel/sys_hwprobe.c | 1 +
> 5 files changed, 8 insertions(+)
>
> diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
> index c3bb26d70c748..05f746061f679 100644
> --- a/Documentation/arch/riscv/hwprobe.rst
> +++ b/Documentation/arch/riscv/hwprobe.rst
> @@ -289,6 +289,10 @@ The following keys are defined:
> defined in the RISC-V ISA manual starting from commit f88abf1 ("Integrating
> load/store pair for RV32 with the main manual") of the riscv-isa-manual.
>
> + * :c:macro:`RISCV_HWPROBE_EXT_ZICCLSM`: The Zicclsm extension is supported,
> + as defined in the RISC-V Profiles specification starting from commit
> + b1d80660 ("Updated to ratified state.")
Sashiko[1] points out that now that this has been moved to IMA_EXT_1 it is
no longer the correct location.
[1] https://sashiko.dev/#/patchset/20260511-rva23u64-hwprobe-v2-v2-0-21c5a544f1dc%40riscstar.com
Thanks,
drew
> +
> * :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: Deprecated. Returns similar values to
> :c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`, but the key was
> mistakenly classified as a bitmask rather than a value.
> diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
> index 44bf8c7d8acc5..e8f4a7dd96a93 100644
> --- a/arch/riscv/include/asm/hwcap.h
> +++ b/arch/riscv/include/asm/hwcap.h
> @@ -112,6 +112,7 @@
> #define RISCV_ISA_EXT_ZCLSD 103
> #define RISCV_ISA_EXT_ZICFILP 104
> #define RISCV_ISA_EXT_ZICFISS 105
> +#define RISCV_ISA_EXT_ZICCLSM 106
>
> #define RISCV_ISA_EXT_XLINUXENVCFG 127
>
> diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
> index 9139edba0aecb..6819df159c51e 100644
> --- a/arch/riscv/include/uapi/asm/hwprobe.h
> +++ b/arch/riscv/include/uapi/asm/hwprobe.h
> @@ -116,6 +116,7 @@ struct riscv_hwprobe {
> #define RISCV_HWPROBE_KEY_ZICBOP_BLOCK_SIZE 15
> #define RISCV_HWPROBE_KEY_IMA_EXT_1 16
> #define RISCV_HWPROBE_EXT_ZICFISS (1ULL << 0)
> +#define RISCV_HWPROBE_EXT_ZICCLSM (1ULL << 1)
>
> /* Increase RISCV_HWPROBE_MAX_KEY when adding items. */
>
> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> index 5cf463570229d..4b4a8157277a3 100644
> --- a/arch/riscv/kernel/cpufeature.c
> +++ b/arch/riscv/kernel/cpufeature.c
> @@ -502,6 +502,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
> __RISCV_ISA_EXT_SUPERSET_VALIDATE(zicbom, RISCV_ISA_EXT_ZICBOM, riscv_xlinuxenvcfg_exts, riscv_ext_zicbom_validate),
> __RISCV_ISA_EXT_DATA_VALIDATE(zicbop, RISCV_ISA_EXT_ZICBOP, riscv_ext_zicbop_validate),
> __RISCV_ISA_EXT_SUPERSET_VALIDATE(zicboz, RISCV_ISA_EXT_ZICBOZ, riscv_xlinuxenvcfg_exts, riscv_ext_zicboz_validate),
> + __RISCV_ISA_EXT_DATA(zicclsm, RISCV_ISA_EXT_ZICCLSM),
> __RISCV_ISA_EXT_DATA(ziccrse, RISCV_ISA_EXT_ZICCRSE),
> __RISCV_ISA_EXT_SUPERSET_VALIDATE(zicfilp, RISCV_ISA_EXT_ZICFILP, riscv_xlinuxenvcfg_exts,
> riscv_cfilp_validate),
> diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c
> index f8f68ba781b45..9cf62266f1890 100644
> --- a/arch/riscv/kernel/sys_hwprobe.c
> +++ b/arch/riscv/kernel/sys_hwprobe.c
> @@ -205,6 +205,7 @@ static void hwprobe_isa_ext1(struct riscv_hwprobe *pair,
> * in the hart_isa bitmap, are made.
> */
> EXT_KEY(isainfo->isa, ZICFISS, pair->value, missing);
> + EXT_KEY(isainfo->isa, ZICCLSM, pair->value, missing);
> }
>
> /* Now turn off reporting features if any CPU is missing it. */
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v2 02/10] riscv: hwprobe.rst: Replace tabs with spaces
From: Andrew Jones @ 2026-05-27 15:45 UTC (permalink / raw)
To: Guodong Xu
Cc: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
Albert Ou, Alexandre Ghiti, Shuah Khan, Anup Patel, Atish Patra,
Shuah Khan, Deepak Gupta, Zong Li, Christian Brauner,
Charlie Jenkins, Samuel Holland, linux-doc, linux-riscv,
linux-kernel, linux-kselftest, kvm, kvm-riscv
In-Reply-To: <20260511-rva23u64-hwprobe-v2-v2-2-21c5a544f1dc@riscstar.com>
On Mon, May 11, 2026 at 09:34:47PM -0400, Guodong Xu wrote:
> From: Andrew Jones <andrew.jones@oss.qualcomm.com>
>
> A handful of vendor-extension entries indent continuation lines with a
> tab character, while the rest of hwprobe.rst uses spaces. Replace
> those tabs with spaces so the file is consistently space-indented.
>
> Cosmetic update, no functional change.
>
> Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
> v2: No change.
> ---
> Documentation/arch/riscv/hwprobe.rst | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
We could just move this patch to the beginning of the series and also use
it to make all indentation consistent in order to fix the consistency
issue I pointed out in the last patch.
Thanks,
drew
^ permalink raw reply
* Re: [PATCH v2 01/10] riscv: hwprobe.rst: Document EXT_ZICFISS
From: Andrew Jones @ 2026-05-27 15:42 UTC (permalink / raw)
To: Guodong Xu
Cc: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
Albert Ou, Alexandre Ghiti, Shuah Khan, Anup Patel, Atish Patra,
Shuah Khan, Deepak Gupta, Zong Li, Christian Brauner,
Charlie Jenkins, Samuel Holland, linux-doc, linux-riscv,
linux-kernel, linux-kselftest, kvm, kvm-riscv
In-Reply-To: <20260511-rva23u64-hwprobe-v2-v2-1-21c5a544f1dc@riscstar.com>
On Mon, May 11, 2026 at 09:34:46PM -0400, Guodong Xu wrote:
> Commit 30c3099036a9 ("riscv/hwprobe: add zicfilp / zicfiss
> enumeration in hwprobe") added RISCV_HWPROBE_EXT_ZICFISS as bit 0 of
> RISCV_HWPROBE_KEY_IMA_EXT_1 but did not add a matching entry to
> Documentation/arch/riscv/hwprobe.rst. Add it now.
We also need to document RISCV_HWPROBE_EXT_ZICFILP
>
> Fixes: 30c3099036a9 ("riscv/hwprobe: add zicfilp / zicfiss enumeration in hwprobe")
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
> v2: New patch.
> ---
> Documentation/arch/riscv/hwprobe.rst | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
> index c420a8349bc68..b1a84ac06da75 100644
> --- a/Documentation/arch/riscv/hwprobe.rst
> +++ b/Documentation/arch/riscv/hwprobe.rst
> @@ -391,3 +391,7 @@ The following keys are defined:
> * :c:macro:`RISCV_HWPROBE_KEY_IMA_EXT_1`: A bitmask containing additional
> extensions that are compatible with the
> :c:macro:`RISCV_HWPROBE_BASE_BEHAVIOR_IMA`: base system behavior.
> +
> + * :c:macro:`RISCV_HWPROBE_EXT_ZICFISS`: The Zicfiss extension is supported,
> + as defined in version 1.0 of the RISC-V Control-flow Integrity (CFI)
> + extensions specification, ratified 2024-07.
We have a variety of indentation in this file. Sometimes we align under
'm' as done here, sometimes under the first ':' and sometimes the second.
Not a huge deal, but maybe before documenting more extensions we should
have a patch that makes all the indentation consistent first.
Thanks,
drew
^ permalink raw reply
* Re: [PATCH v6 05/43] KVM: guest_memfd: Wire up kvm_get_memory_attributes() to per-gmem attributes
From: Ackerley Tng @ 2026-05-27 15:35 UTC (permalink / raw)
To: Sean Christopherson, Fuad Tabba
Cc: aik, andrew.jones, binbin.wu, brauner, chao.p.peng, david,
ira.weiny, jmattson, jthoughton, michael.roth, oupton,
pankaj.gupta, qperret, rick.p.edgecombe, rientjes, shivankg,
steven.price, willy, wyihan, yan.y.zhao, forkloop, pratyush,
suzuki.poulose, aneesh.kumar, liam, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Jonathan Corbet, Shuah Khan, Shuah Khan,
Vishal Annapurve, Andrew Morton, Chris Li, Kairui Song,
Kemeng Shi, Nhat Pham, Baoquan He, Barry Song, Axel Rasmussen,
Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng, Shakeel Butt,
Kiryl Shutsemau, Jason Gunthorpe, Vlastimil Babka, kvm,
linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <CAEvNRgEZ9vCKkoMC11tVrueAonGWH2x6OeaYYxXGEj2gwHUaKw@mail.gmail.com>
Ackerley Tng <ackerleytng@google.com> writes:
>
> [...snip...]
>
>>
>> Hmm, I wonder if we can figure out a way to consolidate some documentation,
>> because this is _exactly_ the same pattern that x86's host_pfn_mapping_level()
>> deals with (see its big comment below).
>>
>
> This would be great, are you thinking an actual comment or something in
> Documentation/?
>
> Perhaps we could iterate on this a little with me providing the newbie
> perspective. Do you want me to take a stab at writing something up?
>
Please see https://lore.kernel.org/all/20260527-kvm-locking-docs-v1-0-4fe8b602ff47@google.com/T/!
>>
>> [...snip...]
>>
^ permalink raw reply
* [PATCH RFC 11/12] KVM: mmu: Point users of host_pfn_mapping_level() to docs
From: Ackerley Tng via B4 Relay @ 2026-05-27 15:33 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Tianrui Zhao,
Bibo Mao, Huacai Chen, WANG Xuerui, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
Fuad Tabba, vannapurve, x86, H. Peter Anvin
Cc: kvm, linux-doc, linux-kernel, loongarch, Ackerley Tng
In-Reply-To: <20260527-kvm-locking-docs-v1-0-4fe8b602ff47@google.com>
From: Ackerley Tng <ackerleytng@google.com>
After consolidating documentation for host_pfn_mapping_level() in
Documentation/virt/kvm/locking.rst, point users of function to docs.
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
---
arch/loongarch/kvm/mmu.c | 24 ++++--------------------
arch/x86/kvm/mmu/mmu.c | 24 ++++--------------------
2 files changed, 8 insertions(+), 40 deletions(-)
diff --git a/arch/loongarch/kvm/mmu.c b/arch/loongarch/kvm/mmu.c
index a7fa458e33605..0313901171a2e 100644
--- a/arch/loongarch/kvm/mmu.c
+++ b/arch/loongarch/kvm/mmu.c
@@ -641,27 +641,11 @@ static bool fault_supports_huge_mapping(struct kvm_memory_slot *memslot,
/*
* Lookup the mapping level for @gfn in the current mm.
*
- * WARNING! Use of host_pfn_mapping_level() requires the caller and the end
- * consumer to be tied into KVM's handlers for MMU notifier events!
+ * WARNING! This derives information from the current state of memslots and
+ * page mappings and may race with invalidations.
*
- * There are several ways to safely use this helper:
- *
- * - Check mmu_invalidate_retry_gfn() after grabbing the mapping level, before
- * consuming it. In this case, mmu_lock doesn't need to be held during the
- * lookup, but it does need to be held while checking the MMU notifier.
- *
- * - Hold mmu_lock AND ensure there is no in-progress MMU notifier invalidation
- * event for the hva. This can be done by explicit checking the MMU notifier
- * or by ensuring that KVM already has a valid mapping that covers the hva.
- *
- * - Do not use the result to install new mappings, e.g. use the host mapping
- * level only to decide whether or not to zap an entry. In this case, it's
- * not required to hold mmu_lock (though it's highly likely the caller will
- * want to hold mmu_lock anyways, e.g. to modify SPTEs).
- *
- * Note! The lookup can still race with modifications to host page tables, but
- * the above "rules" ensure KVM will not _consume_ the result of the walk if a
- * race with the primary MMU occurs.
+ * See Documentation/virt/kvm/locking.rst to understand how to consuming the
+ * result of this lookup safely.
*/
static int host_pfn_mapping_level(struct kvm *kvm, gfn_t gfn,
const struct kvm_memory_slot *slot)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index f8aa7eda661ee..20cdcdd20e78d 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -3214,27 +3214,11 @@ static void direct_pte_prefetch(struct kvm_vcpu *vcpu, u64 *sptep)
/*
* Lookup the mapping level for @gfn in the current mm.
*
- * WARNING! Use of host_pfn_mapping_level() requires the caller and the end
- * consumer to be tied into KVM's handlers for MMU notifier events!
+ * WARNING! This derives information from the current state of memslots and
+ * page mappings and may race with invalidations.
*
- * There are several ways to safely use this helper:
- *
- * - Check mmu_invalidate_retry_gfn() after grabbing the mapping level, before
- * consuming it. In this case, mmu_lock doesn't need to be held during the
- * lookup, but it does need to be held while checking the MMU notifier.
- *
- * - Hold mmu_lock AND ensure there is no in-progress MMU notifier invalidation
- * event for the hva. This can be done by explicit checking the MMU notifier
- * or by ensuring that KVM already has a valid mapping that covers the hva.
- *
- * - Do not use the result to install new mappings, e.g. use the host mapping
- * level only to decide whether or not to zap an entry. In this case, it's
- * not required to hold mmu_lock (though it's highly likely the caller will
- * want to hold mmu_lock anyways, e.g. to modify SPTEs).
- *
- * Note! The lookup can still race with modifications to host page tables, but
- * the above "rules" ensure KVM will not _consume_ the result of the walk if a
- * race with the primary MMU occurs.
+ * See Documentation/virt/kvm/locking.rst to understand how to consuming the
+ * result of this lookup safely.
*/
static int host_pfn_mapping_level(struct kvm *kvm, gfn_t gfn,
const struct kvm_memory_slot *slot)
--
2.54.0.823.g6e5bcc1fc9-goog
^ permalink raw reply related
* [PATCH RFC 07/12] Documentation: KVM: Drop mention of kvm->lock in SRCU documentation
From: Ackerley Tng via B4 Relay @ 2026-05-27 15:33 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Tianrui Zhao,
Bibo Mao, Huacai Chen, WANG Xuerui, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
Fuad Tabba, vannapurve, x86, H. Peter Anvin
Cc: kvm, linux-doc, linux-kernel, loongarch, Ackerley Tng
In-Reply-To: <20260527-kvm-locking-docs-v1-0-4fe8b602ff47@google.com>
From: Ackerley Tng <ackerleytng@google.com>
The original comment says that synchronize_srcu(&kvm->srcu) is called
inside critical sections for kvm->lock, vcpu->mutex and
kvm->slots_lock. Drop mention of kvm->lock since this is no longer true.
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
---
Documentation/virt/kvm/locking.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst
index fc4537a7659a9..437dbfa0030b9 100644
--- a/Documentation/virt/kvm/locking.rst
+++ b/Documentation/virt/kvm/locking.rst
@@ -35,8 +35,8 @@ The acquisition orders for mutexes are as follows:
For SRCU:
- ``synchronize_srcu(&kvm->srcu)`` is called inside critical sections
- for kvm->lock, vcpu->mutex and kvm->slots_lock. These locks _cannot_
- be taken inside a kvm->srcu read-side critical section; that is, the
+ for vcpu->mutex and kvm->slots_lock. These locks _cannot_ be taken
+ inside a kvm->srcu read-side critical section; that is, the
following is broken::
srcu_read_lock(&kvm->srcu);
--
2.54.0.823.g6e5bcc1fc9-goog
^ permalink raw reply related
* [PATCH RFC 09/12] Documentation: KVM: Document synchronization for managing guest faults
From: Ackerley Tng via B4 Relay @ 2026-05-27 15:33 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Tianrui Zhao,
Bibo Mao, Huacai Chen, WANG Xuerui, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
Fuad Tabba, vannapurve, x86, H. Peter Anvin
Cc: kvm, linux-doc, linux-kernel, loongarch, Ackerley Tng
In-Reply-To: <20260527-kvm-locking-docs-v1-0-4fe8b602ff47@google.com>
From: Ackerley Tng <ackerleytng@google.com>
Document how synchronization is used while managing guest faults centrally
so code comments can point users at a central place.
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
---
Documentation/virt/kvm/locking.rst | 108 +++++++++++++++++++++++++++++++++++++
1 file changed, 108 insertions(+)
diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst
index f12664443e913..0663ccfe0633d 100644
--- a/Documentation/virt/kvm/locking.rst
+++ b/Documentation/virt/kvm/locking.rst
@@ -339,3 +339,111 @@ time it will be set using the Dirty tracking mechanism described above.
cpu_hotplug_lock is held, e.g. from cpufreq_boost_trigger_state(), and many
operations need to take cpu_hotplug_lock when loading a vendor module, e.g.
updating static calls.
+
+4. Synchronization while managing guest faults
+----------------------------------------------
+
+This section explains the intersection of these synchronization mechanisms:
+
+- ``kvm->srcu`` (for memslots)
+- ``kvm->mmu_invalidate_*`` (pending invalidations)
+- ``kvm->mn_*`` (synchronization for ``kvm->mmu_invalidate_*``)
+
+4.1 Overview
+^^^^^^^^^^^^
+
+KVM resolves guest page faults by translating the Guest Frame Number (GFN) into
+a Page Frame Number (PFN) via memslots and then populating its shadow page
+tables with the resulting mapping.
+
+While handling the guest page fault, KVM must ensure a consistent view of the
+active memslots container, so KVM takes ``srcu_read_lock(&kvm->srcu);``.
+
+Guest page fault handling can race with some request from host userspace to
+invalidate shadow page tables. These requests originate from a few places, such
+as
+
+1. MMU Notifiers: KVM registers callbacks with the kernel’s memory management
+ subsystem to know when there are changes to mappings in the host userspace
+ page tables.
+2. Memslot Updates: The host userspace VMM, such as QEMU may use the
+ ``KVM_SET_USER_MEMORY_REGION`` ioctl to add, delete, or move a memslot. KVM
+ must zap the affected shadow page tables to ensure the guest doesn't access
+ stale mappings.
+3. Memory Attribute Changes: The ``KVM_SET_MEMORY_ATTRIBUTES`` ioctl allows
+ userspace to change attributes for a range of guest memory (e.g., setting a
+ range as "private" for Confidential Computing). This also requires
+ invalidating existing shadow mappings.
+
+When such a race occurs, KVM optimistically allows the faulting logic to
+proceed, but just before committing the fault, KVM will check for a pending
+invalidation, and retry the fault process if there is a pending invalidation
+affecting the GFN where the fault occurred.
+
+4.2 Tracking pending invalidations with ``kvm->mmu_invalidate*`` fields
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A "pending invalidation" is determined using a combination of
+
+- ``kvm->mmu_invalidate_in_progress``
+- ``kvm->mmu_invalidate_range_start`` and ``kvm->mmu_invalidate_range_end``
+- ``kvm->mmu_invalidate_seq``
+
+``is_page_fault_stale()`` shows how the above fields are used to determine if
+the page fault is stale and requires a retry.
+
+To protect the above combination of fields, a lock is used, which is the
+``kvm->mmu_lock``.
+
+4.2.1 Derived information vs pending invalidations
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Generally, the result of any information derived from GFN aka page
+attribute/page metadata lookups may race with invalidations. Here are some
+examples of lookups:
+
+- ``host_pfn_mapping_level()`` uses memslot information to find the mapping
+ level of pages in host userspace page tables. If there's an invalidation, the
+ pages that were mapped would no longer be mapped and hence the mapping level
+ result would be stale.
+
+There are several ways to ensure valid results:
+
+- Check ``mmu_invalidate_retry_gfn()`` after grabbing the result, before
+ consuming it. In this case, ``mmu_lock`` doesn't need to be held during the
+ lookup, but it does need to be held while checking the MMU notifier. KVM's
+ guest page fault handling uses this option.
+- Hold ``mmu_lock`` AND ensure there is no in-progress MMU notifier invalidation
+ event for the hva. This can be done by explicit checking the MMU notifier or
+ by ensuring that KVM already has a valid mapping that covers the
+ hva. ``kvm_mmu_recover_huge_pages()`` uses this option.
+
+4.3 Further optimization: ignoring invalidations if there is no matching memslot
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Invalidation is only really required when the invalidated memory range overlaps
+with some memslot. Without a matching memslot, the invalidation request could
+actually just be ignored. Hence, KVM only updates the ``kvm->mmu_invalidate_*``
+fields and takes ``kvm->mmu_lock`` if it finds a matching memslot.
+
+This creates another problem: if memslots are updated while there is an ongoing
+invalidation, then the updates to the fields and the lock would be imbalanced.
+
+4.4 Synchronization for invalidation lock/fields: ``kvm->mn_*``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To make sure the updates to the invalidation lock/fields are balanced, KVM has a
+further layer of synchronization. ``kvm_swap_active_memslots()`` enforces that
+changes to memslots are only committed once all pending invalidations are
+complete.
+
+In other words, ``kvm->mn_*`` ensures the following does not happen:
+
+1. Some memslot existed, causing a pending invalidation request to be recorded
+ in the ``kvm->mmu_invalidate_*`` fields
+2. Memslot got removed, so the invalidation request was never removed from the
+ ``kvm->mmu_invalidate_*`` fields.
+
+In addition, ``kvm_swap_active_memslots()`` also enforces that changes to
+memslots are complete before doing ``synchronize_srcu(&kvm->srcu)`` to make sure
+running readers of the old memslots container are done before freeing it.
--
2.54.0.823.g6e5bcc1fc9-goog
^ permalink raw reply related
* [PATCH RFC 12/12] Documentation: KVM: Focus acquisition order section on preventing deadlocks
From: Ackerley Tng via B4 Relay @ 2026-05-27 15:33 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Tianrui Zhao,
Bibo Mao, Huacai Chen, WANG Xuerui, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
Fuad Tabba, vannapurve, x86, H. Peter Anvin
Cc: kvm, linux-doc, linux-kernel, loongarch, Ackerley Tng
In-Reply-To: <20260527-kvm-locking-docs-v1-0-4fe8b602ff47@google.com>
From: Ackerley Tng <ackerleytng@google.com>
Now that the first sentence is already described in more detail in the new
section on synchronization while managing guest faults, drop the first
sentence.
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
---
Documentation/virt/kvm/locking.rst | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst
index 0663ccfe0633d..f26ea3acd0b70 100644
--- a/Documentation/virt/kvm/locking.rst
+++ b/Documentation/virt/kvm/locking.rst
@@ -26,11 +26,9 @@ The acquisition orders for mutexes are as follows:
- vcpu->mutex is taken outside kvm->slots_lock and kvm->slots_arch_lock
-- kvm->mn_active_invalidate_count ensures that pairs of
- invalidate_range_start() and invalidate_range_end() callbacks
- use the same memslots array. kvm->slots_lock and kvm->slots_arch_lock
- are taken on the waiting side when modifying memslots, so MMU notifiers
- must not take either kvm->slots_lock or kvm->slots_arch_lock.
+- kvm->slots_lock and kvm->slots_arch_lock are taken on the waiting side when
+ modifying memslots, so MMU notifiers must not take either kvm->slots_lock or
+ kvm->slots_arch_lock.
For SRCU:
--
2.54.0.823.g6e5bcc1fc9-goog
^ permalink raw reply related
* [PATCH RFC 04/12] Documentation: KVM: Turn - into bullet point
From: Ackerley Tng via B4 Relay @ 2026-05-27 15:33 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Tianrui Zhao,
Bibo Mao, Huacai Chen, WANG Xuerui, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
Fuad Tabba, vannapurve, x86, H. Peter Anvin
Cc: kvm, linux-doc, linux-kernel, loongarch, Ackerley Tng
In-Reply-To: <20260527-kvm-locking-docs-v1-0-4fe8b602ff47@google.com>
From: Ackerley Tng <ackerleytng@google.com>
For the :Protects: section of kvm->mmu_lock, a missing space causes the -
to render as a literal - instead of a bullet point. Add space to make it
render as a bullet point.
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
---
Documentation/virt/kvm/locking.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst
index 67dd2066f6d98..e349c2cb94943 100644
--- a/Documentation/virt/kvm/locking.rst
+++ b/Documentation/virt/kvm/locking.rst
@@ -283,7 +283,7 @@ time it will be set using the Dirty tracking mechanism described above.
^^^^^^^^^^^^^^^^^
:Type: spinlock_t or rwlock_t
:Arch: any
-:Protects: -shadow page/shadow tlb entry
+:Protects: - shadow page/shadow tlb entry
:Comment: it is a spinlock since it is used in mmu notifier.
``kvm->srcu``
--
2.54.0.823.g6e5bcc1fc9-goog
^ permalink raw reply related
* [PATCH RFC 06/12] Documentation: KVM: Have actual headings for exceptions
From: Ackerley Tng via B4 Relay @ 2026-05-27 15:33 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Tianrui Zhao,
Bibo Mao, Huacai Chen, WANG Xuerui, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
Fuad Tabba, vannapurve, x86, H. Peter Anvin
Cc: kvm, linux-doc, linux-kernel, loongarch, Ackerley Tng
In-Reply-To: <20260527-kvm-locking-docs-v1-0-4fe8b602ff47@google.com>
From: Ackerley Tng <ackerleytng@google.com>
Exceptions documented are described but without headings, making it hard to
identify where each exception description ended.
Use actual headings at a lower level than that of the heading used for
Exception to improve readability.
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
---
Documentation/virt/kvm/locking.rst | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst
index 5161636cec481..fc4537a7659a9 100644
--- a/Documentation/virt/kvm/locking.rst
+++ b/Documentation/virt/kvm/locking.rst
@@ -65,7 +65,8 @@ The general rule in KVM is that any modification to shadow page tables
(and their entries (SPTEs)) must be protected by ``kvm->mmu_lock``,
with the exceptions described below.
-Fast page fault:
+2.1. Fast page fault
+^^^^^^^^^^^^^^^^^^^^
Fast page fault is the fast path which fixes the guest page fault out of
the mmu-lock on x86. Currently, the page fault can be fast in one of the
@@ -217,7 +218,8 @@ Since the spte is "volatile" if it can be updated out of mmu-lock, we always
atomically update the spte and the race caused by fast page fault can be avoided.
See the comments in spte_needs_atomic_update() and mmu_spte_update().
-Lockless Access Tracking:
+2.2 Lockless Access Tracking
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is used for Intel CPUs that are using EPT but do not support the EPT A/D
bits. In this case, PTEs are tagged as A/D disabled (using ignored bits), and
--
2.54.0.823.g6e5bcc1fc9-goog
^ permalink raw reply related
* [PATCH RFC 05/12] Documentation: KVM: Explain what rule the exception section is meant for
From: Ackerley Tng via B4 Relay @ 2026-05-27 15:33 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Tianrui Zhao,
Bibo Mao, Huacai Chen, WANG Xuerui, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
Fuad Tabba, vannapurve, x86, H. Peter Anvin
Cc: kvm, linux-doc, linux-kernel, loongarch, Ackerley Tng
In-Reply-To: <20260527-kvm-locking-docs-v1-0-4fe8b602ff47@google.com>
From: Ackerley Tng <ackerleytng@google.com>
The Exception section describes some exceptions but not the rule the
exception is for. Add a paragraph to clarify that detail.
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
---
Documentation/virt/kvm/locking.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst
index e349c2cb94943..5161636cec481 100644
--- a/Documentation/virt/kvm/locking.rst
+++ b/Documentation/virt/kvm/locking.rst
@@ -61,6 +61,10 @@ sections.
2. Exception
------------
+The general rule in KVM is that any modification to shadow page tables
+(and their entries (SPTEs)) must be protected by ``kvm->mmu_lock``,
+with the exceptions described below.
+
Fast page fault:
Fast page fault is the fast path which fixes the guest page fault out of
--
2.54.0.823.g6e5bcc1fc9-goog
^ permalink raw reply related
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