On Wed, Apr 17, 2024 at 4:51 PM Jason Xing wrote:
>
> From: Jason Xing
>
> In production, there are so many cases about why the RST skb is sent but
> we don't have a very convenient/fast method to detect the exact underlying
> reasons.
>
> RST is implemented in two kinds: passive kind (like
On Wed, Apr 17, 2024 at 5:29 PM Michael S. Tsirkin wrote:
>
> On Fri, Apr 12, 2024 at 09:28:23PM +0800, Cindy Lu wrote:
> > Add the function vduse_alloc_reconnnect_info_mem
> > and vduse_alloc_reconnnect_info_mem
> > These functions allow vduse to allocate and free memory for reconnection
> >
On Wed, Apr 17, 2024 at 3:20 PM Liang Chen wrote:
>
> The RSS hash report is a feature that's part of the virtio specification.
> Currently, virtio backends like qemu, vdpa (mlx5), and potentially vhost
> (still a work in progress as per [1]) support this feature. While the
> capability to obtain
On 16/04/2024 3:20 pm, Haitao Huang wrote:
From: Kristen Carlson Accardi
Currently in the EPC page allocation, the kernel simply fails the
allocation when the current EPC cgroup fails to charge due to its usage
reaching limit. This is not ideal. When that happens, a better way is
to
On Tue, Apr 16, 2024 at 12:23 AM Mike Rapoport wrote:
>
> On Mon, Apr 15, 2024 at 06:36:39PM +0100, Mark Rutland wrote:
> > On Mon, Apr 15, 2024 at 09:52:41AM +0200, Peter Zijlstra wrote:
> > > On Thu, Apr 11, 2024 at 07:00:41PM +0300, Mike Rapoport wrote:
> > > > +/**
> > > > + * enum
On Wed Apr 17, 2024 at 1:04 AM EEST, Haitao Huang wrote:
> On Tue, 16 Apr 2024 11:08:11 -0500, Jarkko Sakkinen
> wrote:
>
> > On Tue Apr 16, 2024 at 5:54 PM EEST, Haitao Huang wrote:
> >> I did declare the configs in the config file but I missed it in my patch
> >> as stated earlier. IIUC, that
Hi Mike,
On Thu, 11 Apr 2024 19:00:50 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> kprobes depended on CONFIG_MODULES because it has to allocate memory for
> code.
>
> Since code allocations are now implemented with execmem, kprobes can be
> enabled in non-modular kernels.
>
On Thu, 11 Apr 2024 19:00:41 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> module_alloc() is used everywhere as a mean to allocate memory for code.
>
> Beside being semantically wrong, this unnecessarily ties all subsystems
> that need to allocate code, such as ftrace, kprobes
Sorry, this is actually v3. (miss-configured...)
Thanks,
On Thu, 18 Apr 2024 05:46:34 +0900
"Masami Hiramatsu (Google)" wrote:
> From: Masami Hiramatsu (Google)
>
> Currently, kprobe event checks whether the target symbol name is unique
> or not, so that it does not put a probe on an
From: Masami Hiramatsu (Google)
Currently, kprobe event checks whether the target symbol name is unique
or not, so that it does not put a probe on an unexpected place. But this
skips the check if the target is on a module because the module may not
be loaded.
To fix this issue, this patch
On 4/17/24 01:48, Willy Tarreau wrote:
On Wed, Apr 17, 2024 at 10:16:26AM +0200, Greg KH wrote:
at the scripts used by stable developers - and maybe at the ML server - to
catch different variations won't hurt, as it sounds likely that people will
end messing up with a big name like
Em Wed, 17 Apr 2024 10:16:26 +0200
Greg KH escreveu:
> On Wed, Apr 17, 2024 at 09:09:26AM +0100, Mauro Carvalho Chehab wrote:
> > Em Wed, 17 Apr 2024 09:48:18 +0200
> > Thorsten Leemhuis escreveu:
> >
> > > Hi kernel.org helpdesk!
> > >
> > > Could you please create the email alias
> > >
Dear RT Folks,
This is the RT stable review cycle of patch 4.19.312-rt134-rc1.
Please scream at me if I messed something up. Please test the patches
too.
The -rc release is also available on kernel.org
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
on the
v4.19.312-rt134-rc1 stable review patch.
If anyone has any objections, please let me know.
---
Signed-off-by: Daniel Wagner
---
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index c2c7e0fb6685..6067da4c8c99 100644
On Wed, Apr 17, 2024 at 03:38:28PM +0200, Greg KH wrote:
> > That afaics makes them useless for the stable team (Greg may correct
> > me
> > if I'm wrong here), as they deal with the commits and have no easy,
> > fast, and reliable way to look up the patch posting to query this. Or is
> > the
On Tue, 16 Apr 2024 00:47:26 -0400
Steven Rostedt wrote:
> On Mon, 15 Apr 2024 18:40:23 +0900
> "Masami Hiramatsu (Google)" wrote:
>
> > Check the number of probe target symbols in the target module when
> > the module is loaded. If the probe is not on the unique name symbols
> > in the
On Wed, Apr 17, 2024 at 03:21:12PM +0200, Thorsten Leemhuis wrote:
> On 17.04.24 14:52, Konstantin Ryabitsev wrote:
> > On Wed, Apr 17, 2024 at 09:48:18AM +0200, Thorsten Leemhuis wrote:
> >>
> >> Could you please create the email alias
> >> do-not-apply-to-sta...@kernel.org which redirects all
On Wed, Apr 17, 2024 at 03:21:12PM +0200, Thorsten Leemhuis wrote:
> > In general, I feel this information belongs in the patch basement
> > (the place where change-id, base-commit, etc goes). E.g.:
> >
> > stable-autosel: ignore
> > [This fix requires a feature that is only present in
On 17.04.24 14:52, Konstantin Ryabitsev wrote:
> On Wed, Apr 17, 2024 at 09:48:18AM +0200, Thorsten Leemhuis wrote:
>>
>> Could you please create the email alias
>> do-not-apply-to-sta...@kernel.org which redirects all mail to /dev/null,
>> just like sta...@kernel.org does?
>>
>> That's an idea
On 2024/4/17 0:12, Alexander H Duyck wrote:
> On Mon, 2024-04-15 at 21:19 +0800, Yunsheng Lin wrote:
>> Currently most of the API for page_frag API is returning
>> 'virtual address' as output or expecting 'virtual address'
>> as input, in order to differentiate the API handling between
>> 'virtual
On 4/17/24 2:52 PM, Konstantin Ryabitsev wrote:
> On Wed, Apr 17, 2024 at 09:48:18AM +0200, Thorsten Leemhuis wrote:
>> Hi kernel.org helpdesk!
>>
>> Could you please create the email alias
>> do-not-apply-to-sta...@kernel.org which redirects all mail to /dev/null,
>> just like sta...@kernel.org
Hello,
On Tue, 16 Apr 2024, Alexander Mikhalitsyn wrote:
> Let's make all IPVS sysctls visible and RO even when
> network namespace is owned by non-initial user namespace.
>
> Let's make a few sysctls to be writable:
> - conntrack
> - conn_reuse_mode
> - expire_nodest_conn
> -
On Wed, Apr 17, 2024 at 09:48:18AM +0200, Thorsten Leemhuis wrote:
> Hi kernel.org helpdesk!
>
> Could you please create the email alias
> do-not-apply-to-sta...@kernel.org which redirects all mail to /dev/null,
> just like sta...@kernel.org does?
>
> That's an idea GregKH brought up a few days
Hello,
syzbot found the following issue on:
HEAD commit:96fca68c4fbf Merge tag 'nfsd-6.9-3' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13967bb318
kernel config: https://syzkaller.appspot.com/x/.config?x=85dbe39cf8e4f599
On Fri, Apr 12, 2024 at 09:28:23PM +0800, Cindy Lu wrote:
> Add the function vduse_alloc_reconnnect_info_mem
> and vduse_alloc_reconnnect_info_mem
> These functions allow vduse to allocate and free memory for reconnection
> information. The amount of memory allocated is vq_num pages.
> Each VQS
Hello Eric,
On Wed, Apr 17, 2024 at 5:02 PM Eric Dumazet wrote:
>
> On Wed, Apr 17, 2024 at 10:51 AM Jason Xing wrote:
> >
> > From: Jason Xing
> >
> > Add a new standalone file for the easy future extension to support
> > both active reset and passive reset in the TCP/DCCP/MPTCP protocols.
>
On Wed, Apr 17, 2024 at 10:51 AM Jason Xing wrote:
>
> From: Jason Xing
>
> Add a new standalone file for the easy future extension to support
> both active reset and passive reset in the TCP/DCCP/MPTCP protocols.
>
> This patch only does the preparations for reset reason mechanism,
> nothing
Add support for the VIRTIO_F_SUSPEND feature. When this feature is
negotiated, power management can use it to suspend virtio devices
instead of resorting to resetting the devices entirely.
Signed-off-by: David Stevens
---
drivers/virtio/virtio.c| 32 ++
This series implements support for the virtio device suspend feature
that is under discussion. Unfortunately, the virtio mailing list is
currently being migrated, so recent discussion of the proposal is not
archived anywhere. There current version of the proposal is a
combination of [1] and [2].
On Wed, Apr 10, 2024 at 9:51 AM Jonathan Cameron
wrote:
>
> On Tue, 9 Apr 2024 12:02:31 -0700
> "Ho-Ren (Jack) Chuang" wrote:
>
> > Hi Jonathan,
> >
> > On Tue, Apr 9, 2024 at 9:12 AM Jonathan Cameron
> > wrote:
> > >
> > > On Fri, 5 Apr 2024 15:43:47 -0700
> > > "Ho-Ren (Jack) Chuang" wrote:
From: Jason Xing
Since we have mapped every mptcp reset reason definition
in enum sk_rst_reason, introducing a new helper can cover
some missing places where we have already set the
subflow->reset_reason.
Note: using SK_RST_REASON_NOT_SPECIFIED is the same as
SK_RST_REASON_MPTCP_RST_EUNSPEC.
From: Jason Xing
At last, we should let it work by introducing this reset reason in
trace world.
One of the possible expected outputs is:
... tcp_send_reset: skbaddr=xxx skaddr=xxx src=xxx dest=xxx
state=TCP_ESTABLISHED reason=NOT_SPECIFIED
Signed-off-by: Jason Xing
Reviewed-by: Steven
From: Jason Xing
It relys on what reset options in the skb are as rfc8684 says. Reusing
this logic can save us much energy. This patch replaces most of the prior
NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
---
net/mptcp/subflow.c | 22 +-
1 file changed, 17
From: Jason Xing
Reuse the dropreason logic to show the exact reason of tcp reset,
so we don't need to implement those duplicated reset reasons.
This patch replaces all the prior NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
---
net/ipv4/tcp_ipv4.c | 8
net/ipv6/tcp_ipv6.c | 8
From: Jason Xing
Like what we did to passive reset:
only passing possible reset reason in each active reset path.
No functional changes.
Signed-off-by: Jason Xing
---
include/net/tcp.h | 3 ++-
net/ipv4/tcp.c| 15 ++-
net/ipv4/tcp_output.c | 3 ++-
From: Jason Xing
Adjust the parameter and support passing reason of reset which
is for now NOT_SPECIFIED. No functional changes.
Signed-off-by: Jason Xing
---
include/net/request_sock.h | 4 +++-
net/dccp/ipv4.c| 10 ++
net/dccp/ipv6.c| 10 ++
From: Jason Xing
Add a new standalone file for the easy future extension to support
both active reset and passive reset in the TCP/DCCP/MPTCP protocols.
This patch only does the preparations for reset reason mechanism,
nothing else changes.
The reset reasons are divided into three parts:
1)
From: Jason Xing
In production, there are so many cases about why the RST skb is sent but
we don't have a very convenient/fast method to detect the exact underlying
reasons.
RST is implemented in two kinds: passive kind (like tcp_v4_send_reset())
and active kind (like tcp_send_active_reset()).
On Wed, Apr 17, 2024 at 10:16:26AM +0200, Greg KH wrote:
> > at the scripts used by stable developers - and maybe at the ML server - to
> > catch different variations won't hurt, as it sounds likely that people will
> > end messing up with a big name like "do-not-apply-to-stable", typing
> >
On Tue, Apr 16, 2024 at 11:46 AM Jason Wang wrote:
>
> On Fri, Apr 12, 2024 at 9:31 PM Cindy Lu wrote:
> >
> > Add a document explaining the reconnect process, including what the
> > Userspace App needs to do and how it works with the kernel.
> >
> > Signed-off-by: Cindy Lu
> > ---
> >
On Wed, Apr 17, 2024 at 09:09:26AM +0100, Mauro Carvalho Chehab wrote:
> Em Wed, 17 Apr 2024 09:48:18 +0200
> Thorsten Leemhuis escreveu:
>
> > Hi kernel.org helpdesk!
> >
> > Could you please create the email alias
> > do-not-apply-to-sta...@kernel.org which redirects all mail to /dev/null,
>
Em Wed, 17 Apr 2024 09:48:18 +0200
Thorsten Leemhuis escreveu:
> Hi kernel.org helpdesk!
>
> Could you please create the email alias
> do-not-apply-to-sta...@kernel.org which redirects all mail to /dev/null,
> just like sta...@kernel.org does?
>
> That's an idea GregKH brought up a few days
在 2024/4/17 下午3:18, Liang Chen 写道:
The RSS hash report is a feature that's part of the virtio specification.
Currently, virtio backends like qemu, vdpa (mlx5), and potentially vhost
(still a work in progress as per [1]) support this feature. While the
capability to obtain the RSS hash has
On Wed, Apr 17, 2024 at 09:48:18AM +0200, Thorsten Leemhuis wrote:
> Hi kernel.org helpdesk!
>
> Could you please create the email alias
> do-not-apply-to-sta...@kernel.org which redirects all mail to /dev/null,
> just like sta...@kernel.org does?
>
> That's an idea GregKH brought up a few days
On 17/04/2024 09.18, Liang Chen wrote:
The RSS hash report is a feature that's part of the virtio specification.
Currently, virtio backends like qemu, vdpa (mlx5), and potentially vhost
(still a work in progress as per [1]) support this feature. While the
capability to obtain the RSS hash has
Hi kernel.org helpdesk!
Could you please create the email alias
do-not-apply-to-sta...@kernel.org which redirects all mail to /dev/null,
just like sta...@kernel.org does?
That's an idea GregKH brought up a few days ago here:
https://lore.kernel.org/all/2024041123-earthling-primarily-4656@gregkh/
The RSS hash report is a feature that's part of the virtio specification.
Currently, virtio backends like qemu, vdpa (mlx5), and potentially vhost
(still a work in progress as per [1]) support this feature. While the
capability to obtain the RSS hash has been enabled in the normal path,
it's
47 matches
Mail list logo
