similar to: [Bug 1041] nftables in a container affects the host

(CC'ing bridge maintainers.) Kuniyuki Iwashima <kuniyu at amazon.com> writes: > From: Harry Coin <hcoin at quietfountain.com> > Date: Tue, 11 Jul 2023 16:40:03 -0500 >> On 7/11/23 15:44, Andrew Lunn wrote: >> >>>>>> The current llc_rcv.c around line 166 in net/llc/llc_input.c has >> >>>>>> >>

https://bugzilla.netfilter.org/show_bug.cgi?id=1041 Phil Sutter <phil at nwl.cc> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |phil at nwl.cc Resolution|---

David Hildenbrand <david at redhat.com> writes: > Some devices/drivers that add memory via add_memory() and friends (e.g., > dax/kmem, but also virtio-mem in the future) don't want to create entries > in /sys/firmware/memmap/ - primarily to hinder kexec from adding this > memory to the boot memmap of the kexec kernel. > > In fact, such memory is never exposed via the

David Hildenbrand <david at redhat.com> writes: > Some devices/drivers that add memory via add_memory() and friends (e.g., > dax/kmem, but also virtio-mem in the future) don't want to create entries > in /sys/firmware/memmap/ - primarily to hinder kexec from adding this > memory to the boot memmap of the kexec kernel. > > In fact, such memory is never exposed via the

Hi Linus, First attempt at git, so please pull carefully. I've just put the three i386 boot changes in the repo for the moment. If this works I'll pile on the 44 lguest patches. git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-lguest.git Documentation/i386/boot.txt | 34 +++++++++++++++++++++++++++- arch/x86/boot/compressed/head_32.S | 15 ++++++++++-

Hi Linus, First attempt at git, so please pull carefully. I've just put the three i386 boot changes in the repo for the moment. If this works I'll pile on the 44 lguest patches. git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-lguest.git Documentation/i386/boot.txt | 34 +++++++++++++++++++++++++++- arch/x86/boot/compressed/head_32.S | 15 ++++++++++-

On 30.04.20 17:38, Eric W. Biederman wrote: > David Hildenbrand <david at redhat.com> writes: > >> Some devices/drivers that add memory via add_memory() and friends (e.g., >> dax/kmem, but also virtio-mem in the future) don't want to create entries >> in /sys/firmware/memmap/ - primarily to hinder kexec from adding this >> memory to the boot memmap of the

On 30.04.20 18:33, Eric W. Biederman wrote: > David Hildenbrand <david at redhat.com> writes: > >> On 30.04.20 17:38, Eric W. Biederman wrote: >>> David Hildenbrand <david at redhat.com> writes: >>> >>>> Some devices/drivers that add memory via add_memory() and friends (e.g., >>>> dax/kmem, but also virtio-mem in the future)

When get_pending detects the task has been marked to be killed we try to clean up the SIGKLL by doing a sigdelset and recalc_sigpending, but we still leave it in shared_pending. If the signal is being short circuit delivered there is no need to put in shared_pending so this adds a check in complete_signal. This patch was modified from Eric Biederman <ebiederm at xmission.com> original

On Tue, Sep 08, 2020 at 10:10:07PM +0200, David Hildenbrand wrote: > IORESOURCE_MEM_DRIVER_MANAGED currently uses an unused PnP bit, which is > always set to 0 by hardware. This is far from beautiful (and confusing), > and the bit only applies to SYSRAM. So let's move it out of the > bus-specific (PnP) defined bits. > > We'll add another SYSRAM specific bit soon. If we

From: Christian Borntraeger <borntraeger at de.ibm.com> This patch adds an entry for kvm on s390 to the MAINTAINERS file :-). We intend to push all patches regarding this via Avi's kvm.git. Signed-off-by: Christian Borntraeger <borntraeger at de.ibm.com> Signed-off-by: Carsten Otte <cotte at de.ibm.com> --- MAINTAINERS | 10 ++++++++++ 1 file changed, 10 insertions(+)

From: Christian Borntraeger <borntraeger at de.ibm.com> This patch adds an entry for kvm on s390 to the MAINTAINERS file :-). We intend to push all patches regarding this via Avi's kvm.git. Signed-off-by: Christian Borntraeger <borntraeger at de.ibm.com> Signed-off-by: Carsten Otte <cotte at de.ibm.com> --- MAINTAINERS | 10 ++++++++++ 1 file changed, 10 insertions(+)

On 2018/12/13 ??12:47, gchen.guomin at gmail.com wrote: > From: guomin chen <gchen.guomin at gmail.com> > > Under normal circumstances,When do_exit exits, mm->owner will > be updated on exit_mm(). but when the kernel process calls > unuse_mm() and then exits,mm->owner cannot be updated. And it > will point to a task that has been released. > > Below is

Some devices/drivers that add memory via add_memory() and friends (e.g., dax/kmem, but also virtio-mem in the future) don't want to create entries in /sys/firmware/memmap/ - primarily to hinder kexec from adding this memory to the boot memmap of the kexec kernel. In fact, such memory is never exposed via the firmware memmap as System RAM (e.g., e820), so exposing this memory via

IORESOURCE_MEM_DRIVER_MANAGED currently uses an unused PnP bit, which is always set to 0 by hardware. This is far from beautiful (and confusing), and the bit only applies to SYSRAM. So let's move it out of the bus-specific (PnP) defined bits. We'll add another SYSRAM specific bit soon. If we ever need more bits for other purposes, we can steal some from "desc", or

Hi! The Netfilter project proudly presents: nftables 0.8.2 This release fixes ./configure --with-xtables that enables interaction between iptables-compat [1] and nft, and it also includes a bunch of documentation updates. This release introduces a new explicit option for interval sets, that enables auto-merge of adjacent/overlapping elements when adding them to the set, eg. table

Hi! The Netfilter project proudly presents: nftables 0.9.6 This release fixes vmap support which broke in 0.9.5. You can download this new release from: https://www.netfilter.org/projects/nftables/downloads.html#nftables-0.9.6 https://www.netfilter.org/pub/nftables/ To build the code, libnftnl 1.1.7 and libmnl >= 1.0.4 are required: *

David Hildenbrand <david at redhat.com> writes: > On 30.04.20 17:38, Eric W. Biederman wrote: >> David Hildenbrand <david at redhat.com> writes: >> >>> Some devices/drivers that add memory via add_memory() and friends (e.g., >>> dax/kmem, but also virtio-mem in the future) don't want to create entries >>> in /sys/firmware/memmap/ -

David Hildenbrand <david at redhat.com> writes: > On 30.04.20 17:38, Eric W. Biederman wrote: >> David Hildenbrand <david at redhat.com> writes: >> >>> Some devices/drivers that add memory via add_memory() and friends (e.g., >>> dax/kmem, but also virtio-mem in the future) don't want to create entries >>> in /sys/firmware/memmap/ -

Currently, when adding memory, we create entries in /sys/firmware/memmap/ as "System RAM". This does not reflect the reality and will lead to kexec-tools to add that memory to the fixed-up initial memmap for a kexec kernel (loaded via kexec_load()). The memory will be considered initial System RAM by the kexec kernel. We should let the kexec kernel decide how to use that memory - just