On Wed, 2025-03-26 at 17:44 +0100, Frederic Weisbecker wrote:
> Hi Walter Chang,
>
> Le Wed, Mar 26, 2025 at 05:46:38AM +, Walter Chang (張維哲) a écrit
> :
> > On Tue, 2025-01-21 at 09:08 -0800, Paul E. McKenney wrote:
> > > On Sat, Jan 18, 2025 at 12:24:33AM +0100, Frederic Weisbecker
> > > wro
Hi Linus,
Please pull the following RCU fixes:
The following changes since commit 467c890f2d1ad6de9fd1dbd196fdc8f3ee63190a:
Merge branches 'docs.2025.02.04a', 'lazypreempt.2025.03.04a',
'misc.2025.03.04a', 'srcu.2025.02.05a' and 'torture.2025.02.05a' (2025-03-04
18:47:32 -0800)
are availabl
When setting up XDP for a running interface, we call napi_disable() on
the receive queue's napi. In delayed refill_work, it also calls
napi_disable() on the receive queue's napi. This can leads to deadlock
when napi_disable() is called on an already disabled napi. This commit
fixes this by disablin
On Tue, 2025-04-01 at 21:23 -0700, Paul E. McKenney wrote:
> On Tue, Apr 01, 2025 at 08:48:44PM -0700, Joe Perches wrote:
> > On Tue, 2025-04-01 at 07:05 -0700, Paul E. McKenney wrote:
> > > On Mon, Mar 31, 2025 at 11:53:25PM -0700, Joe Perches wrote:
> > > > On Mon, 2025-03-31 at 14:03 -0700, Paul
On Tue, Apr 01, 2025 at 08:48:44PM -0700, Joe Perches wrote:
> On Tue, 2025-04-01 at 07:05 -0700, Paul E. McKenney wrote:
> > On Mon, Mar 31, 2025 at 11:53:25PM -0700, Joe Perches wrote:
> > > On Mon, 2025-03-31 at 14:03 -0700, Paul E. McKenney wrote:
> > > > Uses of srcu_read_lock_lite() and srcu_
On Tue, Apr 01, 2025 at 03:38:21PM +0200, Frederic Weisbecker wrote:
> Le Mon, Mar 31, 2025 at 02:29:52PM -0700, Paul E. McKenney a écrit :
> > The disagreement is a feature, at least up to a point. That feature
> > allows CPUs to go idle for long periods without RCU having to bother
> > them or t
On Tue, Sep 10, 2024 at 11:43:58PM +, Ackerley Tng wrote:
> guest_memfd files can always be mmap()ed to userspace, but
> faultability is controlled by an attribute on the inode.
>
> Co-developed-by: Fuad Tabba
> Signed-off-by: Fuad Tabba
> Co-developed-by: Ackerley Tng
> Signed-off-by: Acke
On Tue, 2025-04-01 at 07:05 -0700, Paul E. McKenney wrote:
> On Mon, Mar 31, 2025 at 11:53:25PM -0700, Joe Perches wrote:
> > On Mon, 2025-03-31 at 14:03 -0700, Paul E. McKenney wrote:
> > > Uses of srcu_read_lock_lite() and srcu_read_unlock_lite() are better
> > > served by the new srcu_read_lock_
The pull request you sent on Mon, 31 Mar 2025 12:34:04 -0400:
> https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4b98d5dcd145aab10219b9f259b70110cd34f01a
Thank you!
--
Deet-doot-dot, I am a b
From: Dmitry Safonov <0x7f454...@gmail.com>
self-connect-ipv6 got slightly flaky on netdev:
> # timeout set to 120
> # selftests: net/tcp_ao: self-connect_ipv6
> # 1..5
> # # 708[lib/setup.c:250] rand seed 1742872572
> # TAP version 13
> # # 708[lib/proc.c:213]Snmp6Ip6OutNoRoutes:
On Tue, Apr 01, 2025 at 10:05:03AM -0600, Mathieu Poirier wrote:
>On Tue, Apr 01, 2025 at 09:41:24AM +0800, Peng Fan wrote:
>> On Mon, Mar 31, 2025 at 09:40:41AM -0600, Mathieu Poirier wrote:
>> >On Sat, Mar 29, 2025 at 08:56:29PM +0800, Peng Fan wrote:
>> >> On Fri, Mar 28, 2025 at 08:14:41AM -060
On 4/1/25 4:41 PM, Waiman Long wrote:
On 4/1/25 3:59 PM, Tejun Heo wrote:
Hello, Waiman.
On Mon, Mar 31, 2025 at 11:12:06PM -0400, Waiman Long wrote:
The problem is the RCU delay between the time a cgroup is killed and
is in a
dying state and when the partition is deactivated when
cpuset_c
On 4/1/25 3:59 PM, Tejun Heo wrote:
Hello, Waiman.
On Mon, Mar 31, 2025 at 11:12:06PM -0400, Waiman Long wrote:
The problem is the RCU delay between the time a cgroup is killed and is in a
dying state and when the partition is deactivated when cpuset_css_offline()
is called. That delay can be
Ever since the introduction of the virtio vsock driver, it included
pushback logic that blocks it from taking any new RX packets until the
TX queue backlog becomes shallower than the virtqueue size.
This logic works fine when you connect a user space application on the
hypervisor with a virtio-vso
2025-03-18, 02:40:51 +0100, Antonio Quartulli wrote:
> @@ -124,6 +154,13 @@ void ovpn_decrypt_post(void *data, int ret)
> goto drop;
> }
>
> + if (ovpn_is_keepalive(skb)) {
> + net_dbg_ratelimited("%s: ping received from peer %u\
Commit c5c6fd8be51207f0abd3 ("openrisc: Introduce new utility functions
to flush and invalidate caches") introduced new functions to flush or
invalidate a range of addresses. These functions make use of the mtspr
macro.
The kernel test robot reported an asm constraint-related warning and
error rel
Hello, Waiman.
On Mon, Mar 31, 2025 at 11:12:06PM -0400, Waiman Long wrote:
> The problem is the RCU delay between the time a cgroup is killed and is in a
> dying state and when the partition is deactivated when cpuset_css_offline()
> is called. That delay can be rather lengthy depending on the cu
On Tue, Apr 01 2025 at 13:19, Miroslav Lichvar wrote:
> On Tue, Apr 01, 2025 at 08:34:23AM +0200, Thomas Gleixner wrote:
>> On Mon, Mar 31 2025 at 16:53, Miroslav Lichvar wrote:
>> > Mult reduction Updates/sec Skew before Skew after
>> > 16 4 0.004 0.009
On Tue, Apr 01, 2025 at 10:47:09AM -0700, Dan Williams wrote:
> David Hildenbrand wrote:
> > diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
> > index e97d47f42ee2e..23a68ff809cdf 100644
> > --- a/drivers/dax/kmem.c
> > +++ b/drivers/dax/kmem.c
> > @@ -67,8 +67,8 @@ static void kmem_put_memory
On Mon, Mar 31, 2025 at 11:17 PM Chen Ni wrote:
>
> Replace comma between expressions with semicolons.
>
> Using a ',' in place of a ';' can have unintended side effects.
> Although that is not the case here, it is seems best to use ';'
> unless ',' is intended.
>
> Found by inspection.
> No funct
David Hildenbrand wrote:
> On 21.03.25 19:07, Gregory Price wrote:
> > Device capacity intended for use as system ram should be aligned to the
> > architecture-defined memory block size or that capacity will be silently
> > truncated and capacity stranded.
> >
> > As hotplug dax memory becomes mor
On Tue, Apr 01, 2025 at 09:41:24AM +0800, Peng Fan wrote:
> On Mon, Mar 31, 2025 at 09:40:41AM -0600, Mathieu Poirier wrote:
> >On Sat, Mar 29, 2025 at 08:56:29PM +0800, Peng Fan wrote:
> >> On Fri, Mar 28, 2025 at 08:14:41AM -0600, Mathieu Poirier wrote:
> >> >On Fri, Mar 28, 2025 at 12:50:12PM +0
On 3/24/25 9:41 AM, Luca Weiss wrote:
> Add a node for the videocc found on the SM6350 SoC.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/sm6350.dtsi | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi
> b/arch/arm64/bo
Hello, Frederic,
On Tue, 1 Apr 2025 16:27:36 GMT, Frederic Weisbecker wrote:
> Le Mon, Mar 31, 2025 at 02:29:52PM -0700, Paul E. McKenney a écrit :
> > The disagreement is a feature, at least up to a point. That feature
> > allows CPUs to go idle for long periods without RCU having to bother
> >
On Tue, Apr 01, 2025 at 05:19:28PM +0200, David Hildenbrand wrote:
>
> Yes, it's valuable I think. But should it be a warning or rather an info?
>
dev_warn, but yeah I think so? A user expects to get their memory in
full, that means we're slightly misbehaving. I'm fine with either.
~Gregory
On Tue, Apr 01, 2025 at 10:04:02PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> Same as commit 47e6ab07018e ("remoteproc: imx_dsp_rproc: Add mutex
> protection for workqueue") and commit 35bdafda40cc ("remoteproc:
> stm32_rproc: Add mutex protection for workqueue"), imx_rproc driver
> also h
On 01.04.25 17:26, Gregory Price wrote:
On Tue, Apr 01, 2025 at 05:19:28PM +0200, David Hildenbrand wrote:
Yes, it's valuable I think. But should it be a warning or rather an info?
dev_warn, but yeah I think so? A user expects to get their memory in
full, that means we're slightly misbehavi
On Tue, Apr 01, 2025 at 04:50:40PM +0200, David Hildenbrand wrote:
>
> Oh, you mean with the whole memmap_on_memory thing. Even with that, using
> 2GB memory blocks would only fit a single 1GB memory block ... and it
> requires ZONE_NORMAL.
>
> For ordinary boot memory, the 1GB behavior should be
On 01.04.25 17:16, Gregory Price wrote:
On Tue, Apr 01, 2025 at 04:50:40PM +0200, David Hildenbrand wrote:
Oh, you mean with the whole memmap_on_memory thing. Even with that, using
2GB memory blocks would only fit a single 1GB memory block ... and it
requires ZONE_NORMAL.
For ordinary boot mem
On Mon, Mar 31, 2025 at 09:40:41AM -0600, Mathieu Poirier wrote:
>On Sat, Mar 29, 2025 at 08:56:29PM +0800, Peng Fan wrote:
>> On Fri, Mar 28, 2025 at 08:14:41AM -0600, Mathieu Poirier wrote:
>> >On Fri, Mar 28, 2025 at 12:50:12PM +0800, Peng Fan wrote:
>> >> On Thu, Mar 27, 2025 at 11:46:33AM -060
On 01.04.25 16:43, Gregory Price wrote:
On Tue, Apr 01, 2025 at 11:33:59AM +0200, David Hildenbrand wrote:
On 31.03.25 20:27, Gregory Price wrote:
We discussed [1] how this auto-sizing can cause 1GB huge page
allocation failures (assuming you online as ZONE_NORMAL). That means
ACPI-informed siz
On Tue, Apr 01, 2025 at 11:47:32AM +0200, David Hildenbrand wrote:
>
> Can't that be done a bit simpler?
Yes, this is better, lets do this. Thank you!
>
> diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
> index e97d47f42ee2e..23a68ff809cdf 100644
> --- a/drivers/dax/kmem.c
> +++ b/drivers
On Tue, Apr 01, 2025 at 11:33:59AM +0200, David Hildenbrand wrote:
> On 31.03.25 20:27, Gregory Price wrote:
> > We discussed [1] how this auto-sizing can cause 1GB huge page
> > allocation failures (assuming you online as ZONE_NORMAL). That means
> > ACPI-informed sizing by default would potential
Replace comma between expressions with semicolons.
Using a ',' in place of a ';' can have unintended side effects.
Although that is not the case here, it is seems best to use ';'
unless ',' is intended.
Found by inspection.
No functional change intended.
Compile tested only.
Signed-off-by: Chen
On Tue, Apr 01, 2025 at 09:35:33AM +, Reshetova, Elena wrote:
> > > None of these exceptional conditions are fatal or present an
> > > immediate danger to the system security. So, allowing the re-tries
> > > seems logical in this case. In case re-tries also fail, the system
> > > admin will hav
2025-03-18, 02:40:42 +0100, Antonio Quartulli wrote:
> +static int ovpn_udp_output(struct ovpn_peer *peer, struct dst_cache *cache,
> +struct sock *sk, struct sk_buff *skb)
> +{
> + struct ovpn_bind *bind;
> + int ret;
> +
> + /* set sk to null if skb is already
On Fri, Mar 28, 2025 at 06:02:51PM +0800, Cindy Lu wrote:
The VHOST_NEW_WORKER requires the inherit_owner
setting to be true. So we need to add a check for this.
Signed-off-by: Cindy Lu
---
drivers/vhost/vhost.c | 7 +++
1 file changed, 7 insertions(+)
IMHO we should squash this patch also
On Mon, Mar 31, 2025 at 11:53:25PM -0700, Joe Perches wrote:
> On Mon, 2025-03-31 at 14:03 -0700, Paul E. McKenney wrote:
> > Uses of srcu_read_lock_lite() and srcu_read_unlock_lite() are better
> > served by the new srcu_read_lock_fast() and srcu_read_unlock_fast() APIs.
> > As in srcu_read_lock_l
From: Peng Fan
Same as commit 47e6ab07018e ("remoteproc: imx_dsp_rproc: Add mutex
protection for workqueue") and commit 35bdafda40cc ("remoteproc:
stm32_rproc: Add mutex protection for workqueue"), imx_rproc driver
also has similar issue, although no issue reported until now.
The workqueue may e
On Fri, Mar 28, 2025 at 06:02:50PM +0800, Cindy Lu wrote:
Add a new UAPI to configure the vhost device to use the kthread mode
nit: missing . at the end
The userspace application can use IOCTL VHOST_FORK_FROM_OWNER
to choose between owner and kthread mode if necessary
Ditto
This setting m
On Fri, Mar 28, 2025 at 06:02:49PM +0800, Cindy Lu wrote:
This commit restores the previously removed functions kthread
wake/stop/create, and use ops structure vhost_worker_ops to
manage worker wakeup, stop and creation. The function
vhost_worker_create initializes these ops pointers based on
the
On Fri, Mar 28, 2025 at 06:02:46PM +0800, Cindy Lu wrote:
Add the previously removed function vhost_worker() back
to support the kthread and rename it to vhost_run_work_kthread_list.
The old function vhost_worker was change to support task in
nit: s/change/changed
commit 6e890c5d5021 ("vhost
Le Mon, Mar 31, 2025 at 02:29:52PM -0700, Paul E. McKenney a écrit :
> The disagreement is a feature, at least up to a point. That feature
> allows CPUs to go idle for long periods without RCU having to bother
> them or to mess with their per-CPU data (give or take ->gpwrap). It also
> allows per
On Fri, Mar 28, 2025 at 06:02:52PM +0800, Cindy Lu wrote:
Introduce a new config knob `CONFIG_VHOST_ENABLE_FORK_OWNER_IOCTL`,
to control the availability of the `VHOST_FORK_FROM_OWNER` ioctl.
When CONFIG_VHOST_ENABLE_FORK_OWNER_IOCTL is set to n, the ioctl
is disabled, and any attempt to use it w
On Fri, Mar 28, 2025 at 06:02:45PM +0800, Cindy Lu wrote:
The vhost now uses vhost_task and workers as a child of the owner thread.
While this aligns with containerization principles,it confuses some legacy
nit: missing space "principles,it"
userspace app, Therefore, we are reintroducing kthr
2025-03-18, 02:40:41 +0100, Antonio Quartulli wrote:
> +void ovpn_socket_release(struct ovpn_peer *peer)
> +{
> + struct ovpn_socket *sock;
> +
> + might_sleep();
> +
> + /* release may be invoked after socket was detached */
> + rcu_read_lock();
> + sock = rcu_dereference_prote
Skip second resolution alarm test if RTC is minute resolution.
Signed-off-by: Weizhao Ouyang
---
tools/testing/selftests/rtc/rtctest.c | 8
1 file changed, 8 insertions(+)
diff --git a/tools/testing/selftests/rtc/rtctest.c
b/tools/testing/selftests/rtc/rtctest.c
index e103097d0b5b..b8
On Fri, Mar 28, 2025 at 03:15:28PM +0100, Stefano Garzarella wrote:
From: Stefano Garzarella
When a peer attempts to establish a connection, vsock_connect() contains
a loop that waits for the state to be TCP_ESTABLISHED. However, the
other peer can be fast enough to accept the connection and cl
On 2025-03-31, Nam Cao wrote:
> The test waits for coredump to finish by busy-waiting for the
> stackdump_values file to be created. The maximum wait time is 10 seconds.
>
> This doesn't work for slow machine (qemu-system-riscv64), because coredump
> takes longer.
>
> Switch to use waitpid().
Not
On 3/28/25 3:15 PM, Stefano Garzarella wrote:
> From: Stefano Garzarella
>
> When a peer attempts to establish a connection, vsock_connect() contains
> a loop that waits for the state to be TCP_ESTABLISHED. However, the
> other peer can be fast enough to accept the connection and close it
> immed
On Tue, Apr 01, 2025 at 08:34:23AM +0200, Thomas Gleixner wrote:
> On Mon, Mar 31 2025 at 16:53, Miroslav Lichvar wrote:
> > Mult reduction Updates/sec Skew before Skew after
> > 16 4 0.004 0.009
> > 16 16 0.011 0.069
> >
2025-03-18, 02:40:44 +0100, Antonio Quartulli wrote:
> +/* this swap is not atomic, but there will be a very short time frame where
> the
> + * old_secondary key won't be available. This should not be a big deal as
> most
> + * likely both peers are already using the new primary at this point.
>
2025-03-18, 02:40:43 +0100, Antonio Quartulli wrote:
> diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
> index
> 024458ef163c9e24dfb37aea2690b2030f6a0fbc..b30175e34230d3dbf5d253838df894f0625c705c
> 100644
> --- a/net/ipv6/udp.c
> +++ b/net/ipv6/udp.c
> @@ -1933,6 +1933,7 @@ struct proto udpv6_prot =
On 31.03.25 20:27, Gregory Price wrote:
On Fri, Mar 21, 2025 at 02:07:31PM -0400, Gregory Price wrote:
Device capacity intended for use as system ram should be aligned to the
architecture-defined memory block size or that capacity will be silently
truncated and capacity stranded.
As hotplug dax
Hi Dmitry,
On Wed Mar 12, 2025 at 8:06 PM CET, Dmitry Baryshkov wrote:
> On Wed, Mar 12, 2025 at 01:05:07PM +0100, Luca Weiss wrote:
>> This series adds all the necessary bits to enable DisplayPort-out over
>> USB-C on Fairphone 5.
>>
>> There's currently a dt validation error with this, not quit
Add device awake calls in case of rproc boot and rproc shutdown path.
Currently, device awake call is only present in the recovery path
of remoteproc. If a user stops and starts rproc by using the sysfs
interface, then on pm suspension the firmware loading fails as the
request_firmware call under a
On 2025-03-31, Nam Cao wrote:
> The buffer pointer "line" is not initialized. This pointer is passed to
> getline().
Ouch.
> It can still work if the stack is zero-initialized, because getline() can
> work with a NULL pointer as buffer.
>
> But this is obviously broken. This bug shows up while r
57 matches
Mail list logo
