Hi Arnaud,
kernel test robot noticed the following build errors:
[auto build test ERROR on remoteproc/rproc-next]
[also build test ERROR on linus/master v6.7 next-20240117]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
On Thu, 18 Jan 2024 02:18:42 +
Chen Zhongjin wrote:
> There is a deadlock scenario in kprobe_optimizer():
>
> pid A pid B pid C
> kprobe_optimizer()do_exit() perf_kprobe_init()
> mutex_lock(_mutex)
Hi Simon,
Thanks for your reply.
On 2024/1/17 17:29, Simon Horman wrote:
On Wed, Jan 17, 2024 at 03:20:45PM +0800, Kunwu Chan wrote:
Use the new KMEM_CACHE() macro instead of direct kmem_cache_create
to simplify the creation of SLAB caches.
Signed-off-by: Kunwu Chan
Hi Kunwu Chan,
I
There is a deadlock scenario in kprobe_optimizer():
pid A pid B pid C
kprobe_optimizer() do_exit() perf_kprobe_init()
mutex_lock(_mutex) exit_tasks_rcu_start()
mutex_lock(_mutex)
synchronize_rcu_tasks()
The pull request you sent on Sun, 14 Jan 2024 19:35:34 -0800:
> https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git
> tags/rproc-v6.8
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e88481f74fee690316c1e0fd3777f919067d2d58
Thank you!
--
The pull request you sent on Sun, 14 Jan 2024 19:24:43 -0800:
> https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git
> tags/rpmsg-v6.8
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2a43434675b2114e8f909a5039cc421d35d35ce9
Thank you!
--
The pull request you sent on Sun, 14 Jan 2024 19:40:55 -0800:
> https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git
> tags/hwlock-v6.8
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a2ec2071cad819fe952a3f1ef66f2d2112c27b6e
Thank you!
--
Hi Arnaud,
kernel test robot noticed the following build warnings:
[auto build test WARNING on remoteproc/rproc-next]
[also build test WARNING on robh/for-next linus/master v6.7 next-20240117]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
On Wed, 17 Jan 2024 13:11:03 -0800 SeongJae Park wrote:
[...]
> Hi Honggyu,
>
> On Wed, 17 Jan 2024 20:49:25 +0900 Honggyu Kim wrote:
>
> > Hi SeongJae,
> >
> > Thanks very much for your comments in details.
> >
> > On Tue, 16 Jan 2024 12:31:59 -0800 SeongJae Park wrote:
> >
[...]
> > >
Hi Honggyu,
On Wed, 17 Jan 2024 20:49:25 +0900 Honggyu Kim wrote:
> Hi SeongJae,
>
> Thanks very much for your comments in details.
>
> On Tue, 16 Jan 2024 12:31:59 -0800 SeongJae Park wrote:
>
> > Thank you so much for this great patches and the above nice test results. I
> > believe the
On 1/10/2024 5:24 PM, Michael S. Tsirkin wrote:
> On Wed, Jan 10, 2024 at 12:40:03PM -0800, Steve Sistare wrote:
>> Remember the count of pinned memory for the device.
>>
>> Signed-off-by: Steve Sistare
>
> Can we have iommufd support in vdpa so we do not keep extending these hacks?
I assume
On 1/10/2024 9:55 PM, Jason Wang wrote:
> On Thu, Jan 11, 2024 at 4:40 AM Steve Sistare
> wrote:
>>
>> Live update is a technique wherein an application saves its state, exec's
>> to an updated version of itself, and restores its state. Clients of the
>> application experience a brief
On 1/10/2024 10:08 PM, Jason Wang wrote:
> On Thu, Jan 11, 2024 at 4:40 AM Steve Sistare
> wrote:
>>
>> When device ownership is passed to a new process via VHOST_NEW_OWNER,
>> some devices need to know the new userland addresses of the dma mappings.
>> Define the new iotlb message type
On Wed, 17 Jan 2024 06:16:36 + Chen Zhongjin
wrote:
> There is a deadlock scenario in kprobe_optimizer():
>
> pid A pid B pid C
> kprobe_optimizer()do_exit() perf_kprobe_init()
> mutex_lock(_mutex)
On 1/10/2024 10:09 PM, Jason Wang wrote:
> On Thu, Jan 11, 2024 at 4:40 AM Steve Sistare
> wrote:
>>
>> To pass ownership of a live vdpa device to a new process, the user
>> suspends the device, calls VHOST_NEW_OWNER to change the mm, and calls
>> VHOST_IOTLB_REMAP to change the user virtual
On 1/16/2024 1:57 PM, Eugenio Perez Martin wrote:
> On Wed, Jan 10, 2024 at 9:40 PM Steve Sistare
> wrote:
>>
>> To pass ownership of a live vdpa device to a new process, the user
>> suspends the device, calls VHOST_NEW_OWNER to change the mm, and calls
>> VHOST_IOTLB_REMAP to change the user
On 1/11/2024 9:28 PM, Jason Wang wrote:
> On Fri, Jan 12, 2024 at 12:18 AM Mike Christie
> wrote:
>>
>> On 1/10/24 9:09 PM, Jason Wang wrote:
>>> On Thu, Jan 11, 2024 at 4:40 AM Steve Sistare
>>> wrote:
To pass ownership of a live vdpa device to a new process, the user
suspends
vdpasim_do_reset sets running to true, which is wrong, as it allows
vdpasim_kick_vq to post work requests before the device has been
configured. To fix, do not set running until VIRTIO_CONFIG_S_FEATURES_OK
is set.
Fixes: 0c89e2a3a9d0 ("vdpa_sim: Implement suspend vdpa op")
Signed-off-by: Steve
On Thu, 18 Jan 2024, Chuck Lever wrote:
> On Tue, Jan 16, 2024 at 02:45:56PM -0500, Jeff Layton wrote:
> > Long ago, file locks used to hang off of a singly-linked list in struct
> > inode. Because of this, when leases were added, they were added to the
> > same list and so they had to be tracked
Alright, I spent several hours looking at this patchset and the driver as a
whole. I certainly salute your efforts to heed my advice and make the code less
brittle but I'm afraid we are not there.
See below for a different way to proceed.
On Wed, Jan 10, 2024 at 01:35:05PM -0800, Tanmay Shah
On Wed, 2024-01-17 at 10:12 -0500, Chuck Lever wrote:
> On Tue, Jan 16, 2024 at 02:45:56PM -0500, Jeff Layton wrote:
> > Long ago, file locks used to hang off of a singly-linked list in struct
> > inode. Because of this, when leases were added, they were added to the
> > same list and so they had
On Tue, Jan 16, 2024 at 02:46:00PM -0500, Jeff Layton wrote:
> The coccinelle script doesn't catch quite everythng (particularly with
> embedded structs). These are some by-hand fixups after the split of
> common fields into struct file_lock_core.
>
> Signed-off-by: Jeff Layton
For the changes
On Tue, Jan 16, 2024 at 02:45:56PM -0500, Jeff Layton wrote:
> Long ago, file locks used to hang off of a singly-linked list in struct
> inode. Because of this, when leases were added, they were added to the
> same list and so they had to be tracked using the same sort of
> structure.
>
> Several
On Tue, Jan 16, 2024 at 02:45:59PM -0500, Jeff Layton wrote:
> This is the direct result of the changes generated by coccinelle. There
> is still about 1/4 of the callsites that need to be touched by hand
> here.
>
> Signed-off-by: Jeff Layton
For the changes in include/linux/lockd/lockd.h,
]---
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20240117/202401172200.c8731564-oliver.s...@intel.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
2]
[ 46.637161][ T312] 2024-01-15 00:33:43 echo 1 > tracing_on
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20240117/202401172217.36e37075-oliver.s...@intel.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
The sparse tool complains about the remove of the _iomem attribute.
stm32_rproc.c:660:17: warning: cast removes address space '__iomem' of
expression
Add '__force' to explicitly specify that the cast is intentional.
This conversion is necessary to cast to addresses pointer,
which are then
The sparse tool complains about the attribute conversion between
a _iomem void * and a void *:
stm32_rproc.c:122:12: sparse: sparse: incorrect type in assignment (different
address spaces) @@ expected void *va @@ got void [noderef] __iomem * @@
stm32_rproc.c:122:12: sparse: expected
Fix warnings reported by sparse using make option "C=1"
Arnaud Pouliquen (2):
remoteproc: stm32: Fix incorrect type in assignment for va
remoteproc: stm32: Fix incorrect type assignment returned by
stm32_rproc_get_loaded_rsc_tablef
drivers/remoteproc/stm32_rproc.c | 6 +++---
1 file
On Wed, 2024-01-17 at 13:25 +, David Howells wrote:
> Do we need to keep these coccinelle scripts for posterity? Or can they just
> be included in the patch description of the patch that generates them?
>
I have the same question. I included them here mostly so they can be
reviewed as well,
Do we need to keep these coccinelle scripts for posterity? Or can they just
be included in the patch description of the patch that generates them?
David
Hi,
On 1/17/24 14:18, Arnaud Pouliquen wrote:
> Fix warnings reported by sparse using make option "C=1"
>
> Arnaud Pouliquen (2):
> remoteproc: stm32: Fix incorrect type in assignment for va
> remoteproc: stm32: Fix incorrect type assignment returned by
>
The sparse tool complains about the attribute conversion between
a _iomem void * and a void *:
stm32_rproc.c:122:12: sparse: sparse: incorrect type in assignment (different
address spaces) @@ expected void *va @@ got void [noderef] __iomem * @@
stm32_rproc.c:122:12: sparse: expected
Fix warnings reported by sparse using make option "C=1"
Arnaud Pouliquen (2):
remoteproc: stm32: Fix incorrect type in assignment for va
remoteproc: stm32: Fix incorrect type assignment returned by
stm32_rproc_get_loaded_rsc_tablef
drivers/remoteproc/stm32_rproc.c | 6 +++---
1 file
On Wed, 2024-01-17 at 13:48 +0100, Christian Brauner wrote:
> > I'd like to have this considered for inclusion in v6.9. Christian, would
> > you be amenable to shepherding this into mainline (assuming there are no
> > major objections, of course)?
>
> Yes, of course I will be happy to.
Great! I
> I'd like to have this considered for inclusion in v6.9. Christian, would
> you be amenable to shepherding this into mainline (assuming there are no
> major objections, of course)?
Yes, of course I will be happy to.
On Wed, 2024-01-17 at 09:07 +1100, NeilBrown wrote:
> On Wed, 17 Jan 2024, Jeff Layton wrote:
> > In a future patch, we're going to split file leases into their own
> > structure. Since a lot of the underlying machinery uses the same fields
> > move those into a new file_lock_core, and embed that
On Wed, 2024-01-17 at 09:44 +1100, NeilBrown wrote:
> On Wed, 17 Jan 2024, Jeff Layton wrote:
> > Add a new struct file_lease and move the lease-specific fields from
> > struct file_lock to it. Convert the appropriate API calls to take
> > struct file_lease instead, and convert the callers to use
On Mon, Jan 15, 2024 at 05:39:22PM +0300, Fedor Pchelkin wrote:
> Inside decrement_ttl() upon discovering that the packet ttl has exceeded,
> __IP_INC_STATS and __IP6_INC_STATS macros can be called from preemptible
> context having the following backtrace:
>
> check_preemption_disabled: 48
On Wed, 2024-01-17 at 09:32 +1100, NeilBrown wrote:
> On Wed, 17 Jan 2024, Jeff Layton wrote:
> > Have both __locks_insert_block and the deadlock and conflict checking
> > functions take a struct file_lock_core pointer instead of a struct
> > file_lock one. Also, change posix_locks_deadlock to
On Wed, 2024-01-17 at 09:23 +1100, NeilBrown wrote:
> On Wed, 17 Jan 2024, Jeff Layton wrote:
> > Convert __locks_delete_block and __locks_wake_up_blocks to take a struct
> > file_lock_core pointer. Note that to accomodate this, we need to add a
> > new file_lock() wrapper to go from
On Wed, 2024-01-17 at 09:16 +1100, NeilBrown wrote:
> On Wed, 17 Jan 2024, Jeff Layton wrote:
> > I couldn't get them to work properly as macros, so convert them
> > to static inlines instead (which is probably better for the type safety
> > anyway).
> >
> > Signed-off-by: Jeff Layton
> > ---
>
Hi SeongJae,
Thanks very much for your comments in details.
On Tue, 16 Jan 2024 12:31:59 -0800 SeongJae Park wrote:
> Thank you so much for this great patches and the above nice test results. I
> believe the test setup and results make sense, and merging a revised version
> of
> this
Hi,
On 1/11/2024 6:34 AM, Bernd Schubert wrote:
>
>
> On 1/10/24 02:16, Hou Tao wrote:
>> Hi,
>>
>> On 1/9/2024 9:11 PM, Bernd Schubert wrote:
>>>
>>>
>>> On 1/3/24 11:59, Hou Tao wrote:
From: Hou Tao
When trying to insert a 10MB kernel module kept in a virtiofs with
cache
On Wed, Jan 17, 2024 at 03:20:45PM +0800, Kunwu Chan wrote:
> Use the new KMEM_CACHE() macro instead of direct kmem_cache_create
> to simplify the creation of SLAB caches.
>
> Signed-off-by: Kunwu Chan
Hi Kunwu Chan,
I think this is more of a cleanup than a fix,
so it should probably be
On 1/17/24 10:20, Kunwu Chan wrote:
> Use the new KMEM_CACHE() macro instead of direct kmem_cache_create
> to simplify the creation of SLAB caches.
>
> Signed-off-by: Kunwu Chan
The patch is actually for net-next
> ---
> net/netfilter/ipvs/ip_vs_conn.c | 4 +---
> 1 file changed, 1
46 matches
Mail list logo
