Re: [PATCH net-next v9 3/6] tun: Introduce virtio-net hash feature
On Wed, Mar 19, 2025 at 1:29 PM Akihiko Odaki wrote: > > On 2025/03/19 9:58, Jason Wang wrote: > > On Tue, Mar 18, 2025 at 6:10 PM Akihiko Odaki > > wrote: > >> > >> On 2025/03/18 9:15, Jason Wang wrote: > >>> On Mon, Mar 17, 2025 at 3:07 PM Akihiko Odaki > >>> wrote: > > On 2025/03/17 10:12, Jason Wang wrote: > > On Wed, Mar 12, 2025 at 1:03 PM Akihiko Odaki > > wrote: > >> > >> On 2025/03/12 11:35, Jason Wang wrote: > >>> On Tue, Mar 11, 2025 at 2:11 PM Akihiko Odaki > >>> wrote: > > On 2025/03/11 9:38, Jason Wang wrote: > > On Mon, Mar 10, 2025 at 3:45 PM Akihiko Odaki > > wrote: > >> > >> On 2025/03/10 12:55, Jason Wang wrote: > >>> On Fri, Mar 7, 2025 at 7:01 PM Akihiko Odaki > >>> wrote: > > Hash reporting > == > > Allow the guest to reuse the hash value to make receive steering > consistent between the host and guest, and to save hash > computation. > > RSS > === > > RSS is a receive steering algorithm that can be negotiated to > use with > virtio_net. Conventionally the hash calculation was done by the > VMM. > However, computing the hash after the queue was chosen defeats > the > purpose of RSS. > > Another approach is to use eBPF steering program. This approach > has > another downside: it cannot report the calculated hash due to the > restrictive nature of eBPF steering program. > > Introduce the code to perform RSS to the kernel in order to > overcome > thse challenges. An alternative solution is to extend the eBPF > steering > program so that it will be able to report to the userspace, but > I didn't > opt for it because extending the current mechanism of eBPF > steering > program as is because it relies on legacy context rewriting, and > introducing kfunc-based eBPF will result in non-UAPI dependency > while > the other relevant virtualization APIs such as KVM and vhost_net > are > UAPIs. > > Signed-off-by: Akihiko Odaki > Tested-by: Lei Yang > --- > Documentation/networking/tuntap.rst | 7 ++ > drivers/net/Kconfig | 1 + > drivers/net/tap.c | 68 ++- > drivers/net/tun.c | 98 > +- > drivers/net/tun_vnet.h | 159 > ++-- > include/linux/if_tap.h | 2 + > include/linux/skbuff.h | 3 + > include/uapi/linux/if_tun.h | 75 > + > net/core/skbuff.c | 4 + > 9 files changed, 386 insertions(+), 31 deletions(-) > > diff --git a/Documentation/networking/tuntap.rst > b/Documentation/networking/tuntap.rst > index > 4d7087f727be5e37dfbf5066a9e9c872cc98898d..86b4ae8caa8ad062c1e558920be42ce0d4217465 > 100644 > --- a/Documentation/networking/tuntap.rst > +++ b/Documentation/networking/tuntap.rst > @@ -206,6 +206,13 @@ enable is true we enable it, otherwise we > disable it:: > return ioctl(fd, TUNSETQUEUE, (void *)&ifr); > } > > >>> > >>> [...] > >>> > +static inline long tun_vnet_ioctl_sethash(struct > tun_vnet_hash_container __rcu **hashp, > + bool can_rss, void > __user *argp) > >>> > >>> So again, can_rss seems to be tricky. Looking at its caller, it > >>> tires > >>> to make eBPF and RSS mutually exclusive. I still don't understand > >>> why > >>> we need this. Allow eBPF program to override some of the path > >>> seems to > >>> be common practice. > >>> > >>> What's more, we didn't try (or even can't) to make automq and > >>> eBPF to > >>> be mutually exclusive. So I still didn't see what we gain from > >>> this > >>> and it complicates the codes and may lead to ambiguous > >>> uAPI/behaviour. > >> > >> automq and eBPF are mutually exclusive; automq is disabled whe
Re: [PATCH 1/2] fs/proc/task_mmu: add guard region bit to pagemap
On Wed, Mar 19, 2025 at 07:12:45PM +, Lorenzo Stoakes wrote: > +cc Greg for stable question > > On Wed, Mar 19, 2025 at 11:22:40AM -0700, Andrei Vagin wrote: > > On Mon, Feb 24, 2025 at 2:39 AM David Hildenbrand wrote: > > > > > > On 24.02.25 11:18, Lorenzo Stoakes wrote: > > [snip] > > > >> > > > >> Acked-by: David Hildenbrand > > > > > > > > Thanks! :) > > > >> > > > >> Something that might be interesting is also extending the PAGEMAP_SCAN > > > >> ioctl. > > > > > > > > Yeah, funny you should mention that, I did see that, but on reading the > > > > man > > > > page it struck me that it requires the region to be uffd afaict? All the > > > > tests seem to establish uffd, and the man page implies it: > > > > > > > > To start tracking the written state (flag) of a page or range of > > > > memory, the UFFD_FEATURE_WP_ASYNC must be enabled by UFFDIO_API > > > > ioctl(2) on userfaultfd and memory range must be registered with > > > > UFFDIO_REGISTER ioctl(2) in UFFDIO_REGISTER_MODE_WP mode. > > > > > > > > It would be a bit of a weird edge case to add support there. I was > > > > excited > > > > when I first saw this ioctl, then disappointed afterwards... but maybe I > > > > got it wrong? > > > > > > > > > > > > I never managed to review that fully, but I thing that > > > UFFD_FEATURE_WP_ASYNC thingy is only required for PM_SCAN_CHECK_WPASYNC > > > and PM_SCAN_WP_MATCHING. > > > > > > See pagemap_scan_test_walk(). > > > > > > I do recall that it works on any VMA. > > > > > > Ah yes, tools/testing/selftests/mm/vm_util.c ends up using it for > > > pagemap_is_swapped() and friends via page_entry_is() to sanity check > > > that what pagemap gives us is consistent with what pagemap_scan gives us. > > > > > > So it should work independent of the uffd magic. > > > I might be wrong, though ... > > > > > > PAGEMAP_SCAN can work without the UFFD magic. CRIU utilizes PAGEMAP_SCAN > > as a more efficient alternative to /proc/pid/pagemap: > > https://github.com/checkpoint-restore/criu/blob/d18912fc88f3dc7bde5fdfa3575691977eb21753/criu/pagemap-cache.c#L178 > > > > Yeah we ascertained that - is on my list, LSF coming up next week means we > aren't great on timing here, but I'll prioritise this. When I'm back. > > > For CRIU, obtaining information about guard regions is critical. > > Without this functionality in the kernel, CRIU is broken. We probably should > > consider backporting these changes to the 6.13 and 6.14 stable branches. > > > > I'm not sure on precedent for backporting a feature like this - Greg? Am > happy to do it though. If it's a regression, sure, we can take it for stable. > As a stop gap we can backport the pagemap feature if Greg feels this is > appropriate? Which do the maintainers of the code feel is appropriate? I'll defer to them for making that call :) thanks, greg k-h
Re: [PATCH net-next v9 3/6] tun: Introduce virtio-net hash feature
On 2025/03/20 10:31, Jason Wang wrote: On Wed, Mar 19, 2025 at 1:29 PM Akihiko Odaki wrote: On 2025/03/19 9:58, Jason Wang wrote: On Tue, Mar 18, 2025 at 6:10 PM Akihiko Odaki wrote: On 2025/03/18 9:15, Jason Wang wrote: On Mon, Mar 17, 2025 at 3:07 PM Akihiko Odaki wrote: On 2025/03/17 10:12, Jason Wang wrote: On Wed, Mar 12, 2025 at 1:03 PM Akihiko Odaki wrote: On 2025/03/12 11:35, Jason Wang wrote: On Tue, Mar 11, 2025 at 2:11 PM Akihiko Odaki wrote: On 2025/03/11 9:38, Jason Wang wrote: On Mon, Mar 10, 2025 at 3:45 PM Akihiko Odaki wrote: On 2025/03/10 12:55, Jason Wang wrote: On Fri, Mar 7, 2025 at 7:01 PM Akihiko Odaki wrote: Hash reporting == Allow the guest to reuse the hash value to make receive steering consistent between the host and guest, and to save hash computation. RSS === RSS is a receive steering algorithm that can be negotiated to use with virtio_net. Conventionally the hash calculation was done by the VMM. However, computing the hash after the queue was chosen defeats the purpose of RSS. Another approach is to use eBPF steering program. This approach has another downside: it cannot report the calculated hash due to the restrictive nature of eBPF steering program. Introduce the code to perform RSS to the kernel in order to overcome thse challenges. An alternative solution is to extend the eBPF steering program so that it will be able to report to the userspace, but I didn't opt for it because extending the current mechanism of eBPF steering program as is because it relies on legacy context rewriting, and introducing kfunc-based eBPF will result in non-UAPI dependency while the other relevant virtualization APIs such as KVM and vhost_net are UAPIs. Signed-off-by: Akihiko Odaki Tested-by: Lei Yang --- Documentation/networking/tuntap.rst | 7 ++ drivers/net/Kconfig | 1 + drivers/net/tap.c | 68 ++- drivers/net/tun.c | 98 +- drivers/net/tun_vnet.h | 159 ++-- include/linux/if_tap.h | 2 + include/linux/skbuff.h | 3 + include/uapi/linux/if_tun.h | 75 + net/core/skbuff.c | 4 + 9 files changed, 386 insertions(+), 31 deletions(-) diff --git a/Documentation/networking/tuntap.rst b/Documentation/networking/tuntap.rst index 4d7087f727be5e37dfbf5066a9e9c872cc98898d..86b4ae8caa8ad062c1e558920be42ce0d4217465 100644 --- a/Documentation/networking/tuntap.rst +++ b/Documentation/networking/tuntap.rst @@ -206,6 +206,13 @@ enable is true we enable it, otherwise we disable it:: return ioctl(fd, TUNSETQUEUE, (void *)&ifr); } [...] +static inline long tun_vnet_ioctl_sethash(struct tun_vnet_hash_container __rcu **hashp, + bool can_rss, void __user *argp) So again, can_rss seems to be tricky. Looking at its caller, it tires to make eBPF and RSS mutually exclusive. I still don't understand why we need this. Allow eBPF program to override some of the path seems to be common practice. What's more, we didn't try (or even can't) to make automq and eBPF to be mutually exclusive. So I still didn't see what we gain from this and it complicates the codes and may lead to ambiguous uAPI/behaviour. automq and eBPF are mutually exclusive; automq is disabled when an eBPF steering program is set so I followed the example here. I meant from the view of uAPI, the kernel doesn't or can't reject eBPF while using automq. > >> We don't even have an interface for eBPF to let it fall back to another alogirhtm. It doesn't even need this, e.g XDP overrides the default receiving path. I could make it fall back to RSS if the eBPF steeering program is designed to fall back to automq when it returns e.g., -1. But such an interface is currently not defined and defining one is out of scope of this patch series. Just to make sure we are on the same page, I meant we just need to make the behaviour consistent: allow eBPF to override the behaviour of both automq and rss. That assumes eBPF takes precedence over RSS, which is not obvious to me. Well, it's kind of obvious. Not speaking the eBPF selector, we have other eBPF stuffs like skbedit etc. Let's add an interface for the eBPF steering program to fall back to another steering algorithm. I said it is out of scope before, but it makes clear that the eBPF steering program takes precedence over other algorithms and allows us to delete the code for the configuration validation in this patch. Fallback is out of scope but it's not what I meant. I meant in the current uAPI take eBPF precedence over automq. It's much more simpler to stick this precedence unless we see obvious advanatge. We still have three different design options that preserve the current precedence
Re: [PATCH 1/2] fs/proc/task_mmu: add guard region bit to pagemap
On Mon, Feb 24, 2025 at 2:39 AM David Hildenbrand wrote:
>
> On 24.02.25 11:18, Lorenzo Stoakes wrote:
> > On Mon, Feb 24, 2025 at 10:27:28AM +0100, David Hildenbrand wrote:
> >> On 21.02.25 13:05, Lorenzo Stoakes wrote:
> >>> Currently there is no means by which users can determine whether a given
> >>> page in memory is in fact a guard region, that is having had the
> >>> MADV_GUARD_INSTALL madvise() flag applied to it.
> >>>
> >>> This is intentional, as to provide this information in VMA metadata would
> >>> contradict the intent of the feature (providing a means to change fault
> >>> behaviour at a page table level rather than a VMA level), and would
> >>> require
> >>> VMA metadata operations to scan page tables, which is unacceptable.
> >>>
> >>> In many cases, users have no need to reflect and determine what regions
> >>> have been designated guard regions, as it is the user who has established
> >>> them in the first place.
> >>>
> >>> But in some instances, such as monitoring software, or software that
> >>> relies
> >>> upon being able to ascertain the nature of mappings within a remote
> >>> process
> >>> for instance, it becomes useful to be able to determine which pages have
> >>> the guard region marker applied.
> >>>
> >>> This patch makes use of an unused pagemap bit (58) to provide this
> >>> information.
> >>>
> >>> This patch updates the documentation at the same time as making the change
> >>> such that the implementation of the feature and the documentation of it
> >>> are
> >>> tied together.
> >>>
> >>> Signed-off-by: Lorenzo Stoakes
> >>> ---
> >>
> >>
> >> Acked-by: David Hildenbrand
> >
> > Thanks! :)
> >>
> >> Something that might be interesting is also extending the PAGEMAP_SCAN
> >> ioctl.
> >
> > Yeah, funny you should mention that, I did see that, but on reading the man
> > page it struck me that it requires the region to be uffd afaict? All the
> > tests seem to establish uffd, and the man page implies it:
> >
> > To start tracking the written state (flag) of a page or range of
> > memory, the UFFD_FEATURE_WP_ASYNC must be enabled by UFFDIO_API
> > ioctl(2) on userfaultfd and memory range must be registered with
> > UFFDIO_REGISTER ioctl(2) in UFFDIO_REGISTER_MODE_WP mode.
> >
> > It would be a bit of a weird edge case to add support there. I was excited
> > when I first saw this ioctl, then disappointed afterwards... but maybe I
> > got it wrong?
> >
>
> I never managed to review that fully, but I thing that
> UFFD_FEATURE_WP_ASYNC thingy is only required for PM_SCAN_CHECK_WPASYNC
> and PM_SCAN_WP_MATCHING.
>
> See pagemap_scan_test_walk().
>
> I do recall that it works on any VMA.
>
> Ah yes, tools/testing/selftests/mm/vm_util.c ends up using it for
> pagemap_is_swapped() and friends via page_entry_is() to sanity check
> that what pagemap gives us is consistent with what pagemap_scan gives us.
>
> So it should work independent of the uffd magic.
> I might be wrong, though ...
PAGEMAP_SCAN can work without the UFFD magic. CRIU utilizes PAGEMAP_SCAN
as a more efficient alternative to /proc/pid/pagemap:
https://github.com/checkpoint-restore/criu/blob/d18912fc88f3dc7bde5fdfa3575691977eb21753/criu/pagemap-cache.c#L178
For CRIU, obtaining information about guard regions is critical.
Without this functionality in the kernel, CRIU is broken. We probably should
consider backporting these changes to the 6.13 and 6.14 stable branches.
>
> >>
> >>
> >> See do_pagemap_scan().
> >>
> >> The benefit here might be that one could effectively search/filter for
> >> guard
> >> regions without copying 64bit per base-page to user space.
> >>
> >> But the idea would be to indicate something like PAGE_IS_GUARD_REGION as a
> >> category when we hit a guard region entry in pagemap_page_category().
> >>
> >> (the code is a bit complicated, and I am not sure why we indicate
> >> PAGE_IS_SWAPPED for non-swap entries, likely wrong ...)
> >
> > Yeah, I could go on here about how much I hate how uffd does a 'parallel
> > implementation' of a ton of stuff and then chucks in if (uffd) { go do
> > something weird + wonderful } but I'll resist the urge :P :))
> >
> > Do you think, if it were uffd-specific, this would be useful?
>
> If it really is completely uffd-specific for now, I agree that we should
> rather leave it alone.
>
> >
> > At any rate, I'm not sure it's _hugely_ beneficial in this form as pagemap
> > is binary in any case so you're not having to deal with overhead of parsing
> > a text file at least!
>
> My thinking was, that if you have a large VMA, with ordinary pagemap you
> have to copy 8byte per entry (and have room for that somewhere in user
> space). In theory, with the scanning feature, you can leave that ...
> scanning to the kernel and don't have to do any copying/allocate space
> for it in user space etc.
PAGEMAP_SCAN doesn't have this issue and it was one of the reasons to
implement it.
Thanks,
Andrei
Re: [PATCH 1/2] fs/proc/task_mmu: add guard region bit to pagemap
+cc Greg for stable question On Wed, Mar 19, 2025 at 11:22:40AM -0700, Andrei Vagin wrote: > On Mon, Feb 24, 2025 at 2:39 AM David Hildenbrand wrote: > > > > On 24.02.25 11:18, Lorenzo Stoakes wrote: [snip] > > >> > > >> Acked-by: David Hildenbrand > > > > > > Thanks! :) > > >> > > >> Something that might be interesting is also extending the PAGEMAP_SCAN > > >> ioctl. > > > > > > Yeah, funny you should mention that, I did see that, but on reading the > > > man > > > page it struck me that it requires the region to be uffd afaict? All the > > > tests seem to establish uffd, and the man page implies it: > > > > > > To start tracking the written state (flag) of a page or range of > > > memory, the UFFD_FEATURE_WP_ASYNC must be enabled by UFFDIO_API > > > ioctl(2) on userfaultfd and memory range must be registered with > > > UFFDIO_REGISTER ioctl(2) in UFFDIO_REGISTER_MODE_WP mode. > > > > > > It would be a bit of a weird edge case to add support there. I was excited > > > when I first saw this ioctl, then disappointed afterwards... but maybe I > > > got it wrong? > > > > > > > > I never managed to review that fully, but I thing that > > UFFD_FEATURE_WP_ASYNC thingy is only required for PM_SCAN_CHECK_WPASYNC > > and PM_SCAN_WP_MATCHING. > > > > See pagemap_scan_test_walk(). > > > > I do recall that it works on any VMA. > > > > Ah yes, tools/testing/selftests/mm/vm_util.c ends up using it for > > pagemap_is_swapped() and friends via page_entry_is() to sanity check > > that what pagemap gives us is consistent with what pagemap_scan gives us. > > > > So it should work independent of the uffd magic. > > I might be wrong, though ... > > > PAGEMAP_SCAN can work without the UFFD magic. CRIU utilizes PAGEMAP_SCAN > as a more efficient alternative to /proc/pid/pagemap: > https://github.com/checkpoint-restore/criu/blob/d18912fc88f3dc7bde5fdfa3575691977eb21753/criu/pagemap-cache.c#L178 > Yeah we ascertained that - is on my list, LSF coming up next week means we aren't great on timing here, but I'll prioritise this. When I'm back. > For CRIU, obtaining information about guard regions is critical. > Without this functionality in the kernel, CRIU is broken. We probably should > consider backporting these changes to the 6.13 and 6.14 stable branches. > I'm not sure on precedent for backporting a feature like this - Greg? Am happy to do it though. As a stop gap we can backport the pagemap feature if Greg feels this is appropriate? [snip] > > My thinking was, that if you have a large VMA, with ordinary pagemap you > > have to copy 8byte per entry (and have room for that somewhere in user > > space). In theory, with the scanning feature, you can leave that ... > > scanning to the kernel and don't have to do any copying/allocate space > > for it in user space etc. > > PAGEMAP_SCAN doesn't have this issue and it was one of the reasons to > implement it. Ack. > > Thanks, > Andrei
Re: [PATCH v4 03/12] KVM: guest_memfd: Add flag to remove from direct map
Hi David!
On Wed, 2025-02-26 at 15:30 +, David Hildenbrand wrote:
> On 26.02.25 16:14, Patrick Roy wrote:
>>
>>
>> On Wed, 2025-02-26 at 09:08 +, David Hildenbrand wrote:
>>> On 26.02.25 09:48, Patrick Roy wrote:
On Tue, 2025-02-25 at 16:54 +, David Hildenbrand wrote:> On 21.02.25
17:07, Patrick Roy wrote:
>> Add KVM_GMEM_NO_DIRECT_MAP flag for KVM_CREATE_GUEST_MEMFD() ioctl. When
>> set, guest_memfd folios will be removed from the direct map after
>> preparation, with direct map entries only restored when the folios are
>> freed.
>>
>> To ensure these folios do not end up in places where the kernel cannot
>> deal with them, set AS_NO_DIRECT_MAP on the guest_memfd's struct
>> address_space if KVM_GMEM_NO_DIRECT_MAP is requested.
>>
>> Note that this flag causes removal of direct map entries for all
>> guest_memfd folios independent of whether they are "shared" or "private"
>> (although current guest_memfd only supports either all folios in the
>> "shared" state, or all folios in the "private" state if
>> !IS_ENABLED(CONFIG_KVM_GMEM_SHARED_MEM)). The usecase for removing
>> direct map entries of also the shared parts of guest_memfd are a special
>> type of non-CoCo VM where, host userspace is trusted to have access to
>> all of guest memory, but where Spectre-style transient execution attacks
>> through the host kernel's direct map should still be mitigated.
>>
>> Note that KVM retains access to guest memory via userspace
>> mappings of guest_memfd, which are reflected back into KVM's memslots
>> via userspace_addr. This is needed for things like MMIO emulation on
>> x86_64 to work. Previous iterations attempted to instead have KVM
>> temporarily restore direct map entries whenever such an access to guest
>> memory was needed, but this turned out to have a significant performance
>> impact, as well as additional complexity due to needing to refcount
>> direct map reinsertion operations and making them play nicely with gmem
>> truncations.
>>
>> This iteration also doesn't have KVM perform TLB flushes after direct
>> map manipulations. This is because TLB flushes resulted in a up to 40x
>> elongation of page faults in guest_memfd (scaling with the number of CPU
>> cores), or a 5x elongation of memory population. On the one hand, TLB
>> flushes are not needed for functional correctness (the virt->phys
>> mapping technically stays "correct", the kernel should simply to not it
>> for a while), so this is a correct optimization to make. On the other
>> hand, it means that the desired protection from Spectre-style attacks is
>> not perfect, as an attacker could try to prevent a stale TLB entry from
>> getting evicted, keeping it alive until the page it refers to is used by
>> the guest for some sensitive data, and then targeting it using a
>> spectre-gadget.
>>
>> Signed-off-by: Patrick Roy
>
> ...
>
>>
>> +static bool kvm_gmem_test_no_direct_map(struct inode *inode)
>> +{
>> + return ((unsigned long) inode->i_private) & KVM_GMEM_NO_DIRECT_MAP;
>> +}
>> +
>> static inline void kvm_gmem_mark_prepared(struct folio *folio)
>> {
>> + struct inode *inode = folio_inode(folio);
>> +
>> + if (kvm_gmem_test_no_direct_map(inode)) {
>> + int r = set_direct_map_valid_noflush(folio_page(folio, 0),
>> folio_nr_pages(folio),
>> + false);
>
> Will this work if KVM is built as a module, or is this another good
> reason why we might want guest_memfd core part of core-mm?
mh, I'm admittedly not too familiar with the differences that would come
from building KVM as a module vs not. I do remember something about the
direct map accessors not being available for modules, so this would
indeed not work. Does that mean moving gmem into core-mm will be a
pre-requisite for the direct map removal stuff?
>>>
>>> Likely, we'd need some shim.
>>>
>>> Maybe for the time being it could be fenced using #if IS_BUILTIN() ...
>>> but that sure won't win in a beauty contest.
>>
>> Is anyone working on such a shim at the moment? Otherwise, would it make
>> sense for me to look into it? (although I'll probably need a pointer or
>> two for what is actually needed)
>>
>> I saw your comment on Fuad's series [1] indicating that he'll also need
>> some shim, so probably makes sense to tackle it anyway instead of
>> hacking around it with #if-ery.
>
> Elliot (CC) was working on "guestmem library" project [1], but it was
> unclear what we could factor out into the core.
>
> Looks like a simple shim for such stuff might be a good starting point,
> although not the final idea of encapsulating more in the library.
So I started looking into this based on what we talked
Re: [PATCH net-next 5/6] selftests: netconsole: Add tests for 'release' feature in sysdata
On Fri, Mar 14, 2025 at 10:58:49AM -0700, Breno Leitao wrote: > Expands the self-tests to include the 'release' feature in > sysdata. > > Verifies that enabling the 'release' feature appends the > correct data and ensures that disabling it functions as expected. > > When enabled, the message should have an item similar to in the > userdata: `release=$(uname -r)` > > Signed-off-by: Breno Leitao Reviewed-by: Simon Horman
Re: [PATCH net-next 1/6] netconsole: introduce 'release' as a new sysdata field
On Fri, Mar 14, 2025 at 10:58:45AM -0700, Breno Leitao wrote: > This commit adds a new feature to the sysdata structure, allowing the > kernel release/version to be appended as part of sysdata. Additionally, > it updates the logic to count this new field as a used entry when > enabled. > > Signed-off-by: Breno Leitao Reviewed-by: Simon Horman
Re: [PATCH net-next 6/6] docs: netconsole: document release feature
On Fri, Mar 14, 2025 at 10:58:50AM -0700, Breno Leitao wrote: > Add documentation explaining the kernel release auto-population feature > in netconsole. > > This feature appends kernel version information to the userdata > dictionary in every message sent when enabled via the `release_enabled` > file in the configfs hierarchy. > > Signed-off-by: Breno Leitao Reviewed-by: Simon Horman
Re: [PATCH net-next 3/6] netconsole: add 'sysdata' suffix to related functions
On Fri, Mar 14, 2025 at 10:58:47AM -0700, Breno Leitao wrote: > This commit appends a common "sysdata" suffix to functions responsible > for appending data to sysdata. > > This change enhances code clarity and prevents naming conflicts with > other "append" functions, particularly in anticipation of the upcoming > inclusion of the `release` field in the next patch. > > Signed-off-by: Breno Leitao Reviewed-by: Simon Horman
Re: [PATCH net-next 4/6] netconsole: append release to sysdata
On Fri, Mar 14, 2025 at 10:58:48AM -0700, Breno Leitao wrote: > Append the init_utsname()->release to sysdata buffer before sending the > message in case the feature is set. > > Signed-off-by: Breno Leitao Reviewed-by: Simon Horman
Re: [PATCH net-next 2/6] netconsole: implement configfs for release_enabled
On Fri, Mar 14, 2025 at 10:58:46AM -0700, Breno Leitao wrote: > Implement the configfs helpers to show and set release_enabled configfs > directories under userdata. > > When enabled, set the feature bit in netconsole_target->sysdata_fields. > > Signed-off-by: Breno Leitao Reviewed-by: Simon Horman
