Hello Linus,
Please consider for pull,
The following changes since commit fc033cf25e612e840e545f8d5ad2edd6ba613ed5:
Linux 6.13-rc5 (2024-12-29 13:15:45 -0800)
are available in the Git repository at:
https://github.com/openrisc/linux.git tags/for-linus
for you to fetch changes up to ea1413
On Fri, 24 Jan 2025 16:03:32 + Cosmin Ratiu wrote:
> On Fri, 2025-01-24 at 07:38 -0800, Jakub Kicinski wrote:
> > On Thu, 23 Jan 2025 15:24:37 + Cosmin Ratiu wrote:
> > > I've sent another patch to suggest these changes.
> >
> > FTR this is not the normal way to proceed in code review,
On Sat, Jan 25, 2025 at 12:03:58AM +0100, Frederic Weisbecker wrote:
> Le Fri, Dec 13, 2024 at 11:49:49AM -0800, Paul E. McKenney a écrit :
> > diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
> > index 2f9c9272cd486..d2a91f705a4ab 100644
> > --- a/kernel/rcu/rcu.h
> > +++ b/kernel/rcu/rcu.h
> > @@
Le Fri, Dec 13, 2024 at 11:49:49AM -0800, Paul E. McKenney a écrit :
> diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
> index 2f9c9272cd486..d2a91f705a4ab 100644
> --- a/kernel/rcu/rcu.h
> +++ b/kernel/rcu/rcu.h
> @@ -162,7 +162,7 @@ static inline bool rcu_seq_done_exact(unsigned long *sp,
> uns
On Fri, Jan 24, 2025 at 11:25:01PM +0100, Frederic Weisbecker wrote:
> Le Fri, Jan 24, 2025 at 11:40:54AM -0800, Paul E. McKenney a écrit :
> > > > > I'm wondering, what prevents us from removing rcu_state.gp_seq and
> > > > > rely only on
> > > > > the root node for the global state ?
> > > >
>
Le Fri, Jan 24, 2025 at 11:40:54AM -0800, Paul E. McKenney a écrit :
> > > > I'm wondering, what prevents us from removing rcu_state.gp_seq and rely
> > > > only on
> > > > the root node for the global state ?
> > >
> > > One scenario comes to mind immediately. There may be others.
> > >
> > >
On Fri, Jan 24, 2025 at 09:14:54AM +0800, Jason Wang wrote:
> On Thu, Jan 23, 2025 at 10:47 AM Joe Damato wrote:
> >
> > On Thu, Jan 23, 2025 at 10:40:43AM +0800, Jason Wang wrote:
> > > On Thu, Jan 23, 2025 at 1:41 AM Joe Damato wrote:
> > > >
> > > > On Wed, Jan 22, 2025 at 02:12:46PM +0800, Ja
On 1/24/25 12:17, Maciej Wieczor-Retman wrote:
>> Could you poke around and see if there is any existing ABI that we can
>> use to query LA57 support? Maybe one of the things KVM exports, or some
>> TASK_SIZE_MAX comparisons?
> Sure, I'll try to find some other way.
>
> My previous tactic was to m
On 2025-01-24 at 21:17:22 +0100, Maciej Wieczor-Retman wrote:
>On 2025-01-24 at 08:14:41 -0800, Dave Hansen wrote:
>>On 11/27/24 09:35, Maciej Wieczor-Retman wrote:
>Sure, I'll try to find some other way.
>
>My previous tactic was to munmap() a high address and see if it works. Does
>that
>sound o
On Fri, Jan 24, 2025 at 9:56 AM Frederic Weisbecker wrote:
>
> Le Thu, Jan 23, 2025 at 08:49:47PM -0500, Joel Fernandes a écrit :
> > On Thu, Dec 12, 2024 at 7:59 PM Paul E. McKenney wrote:
> > >
> > > The get_state_synchronize_rcu_full() and poll_state_synchronize_rcu_full()
> > > functions use
On 2025-01-24 at 08:32:18 -0800, Dave Hansen wrote:
>On 11/27/24 09:35, Maciej Wieczor-Retman wrote:
>...
>> +switch (test->later) {
>> +case GET_USER_USER:
>> +/* Control group - properly tagger user pointer */
>> +ptr = (void *)set_metadata((uint64_t)ptr, test->lam
On 2025-01-24 at 08:14:41 -0800, Dave Hansen wrote:
>On 11/27/24 09:35, Maciej Wieczor-Retman wrote:
>> -/* Check 5-level page table feature in CPUID.(EAX=07H, ECX=00H):ECX.[bit
>> 16] */
>> static inline int cpu_has_la57(void)
>> {
>> -unsigned int cpuinfo[4];
>> -
>> -__cpuid_count(0x7
On Fri, Jan 24, 2025 at 06:21:30PM +0100, Uladzislau Rezki wrote:
> On Fri, Jan 24, 2025 at 07:45:23AM -0800, Paul E. McKenney wrote:
> > On Fri, Jan 24, 2025 at 12:41:38PM +0100, Uladzislau Rezki wrote:
> > > On Thu, Jan 23, 2025 at 12:29:45PM -0800, Paul E. McKenney wrote:
> > > > On Thu, Jan 23,
On 2025-01-24 at 08:23:09 -0800, Dave Hansen wrote:
>On 11/27/24 09:35, Maciej Wieczor-Retman wrote:
>> +static inline int kernel_has_lam(void)
>> +{
>> +unsigned long bits;
>> +
>> +syscall(SYS_arch_prctl, ARCH_GET_MAX_TAG_BITS, &bits);
>> +return !!bits;
>> +}
>
>Generally, I'm less p
On Fri, Jan 24, 2025 at 06:48:40PM +0100, Uladzislau Rezki wrote:
> On Fri, Jan 24, 2025 at 09:36:07AM -0800, Paul E. McKenney wrote:
> > On Fri, Jan 24, 2025 at 06:21:30PM +0100, Uladzislau Rezki wrote:
> > > On Fri, Jan 24, 2025 at 07:45:23AM -0800, Paul E. McKenney wrote:
> > > > On Fri, Jan 24,
On Fri, Jan 24, 2025 at 05:42:29PM +0100, Frederic Weisbecker wrote:
> Le Fri, Jan 24, 2025 at 07:58:20AM -0800, Paul E. McKenney a écrit :
> > On Fri, Jan 24, 2025 at 03:49:24PM +0100, Frederic Weisbecker wrote:
> > > Le Fri, Dec 13, 2024 at 11:49:49AM -0800, Paul E. McKenney a écrit :
> > > > The
Murad Masimov wrote:
>
>
> От: Dave Jiang
> Отправлено: 24 января 2025 г. 2:43
> Кому: Masimov Murad; Dan Williams
> Копия: Vishal Verma; Ira Weiny; Rafael J. Wysocki; Len Brown;
> nvd...@lists.linux.dev; linux-a...@vger.kernel.org;
> linux-kernel@vger.k
On Wed, Jan 22, 2025 at 1:53 PM Slava Imameev
wrote:
>
> BPF programs designated as dynamically loaded can be loaded and
> attached independently after the initial bpf_object loading and
> attaching.
>
> These programs can also be reloaded and reattached multiple times,
> enabling more flexible ma
On 1/7/25 02:16, Gokul Sriram Palanisamy wrote:
> This series depends on Sricharan's tmel-qmp mailbox driver series v2 [1].
>
> - Secure PIL is signed, split firmware images which only TrustZone (TZ)
> can authenticate and load. Linux kernel will send a request to TZ to
> authenticate and load
On 2025-01-13 12:09:27 [+0100], Petr Pavlu wrote:
> Thanks for this cleanup. I've queued the fix in patch #1 on
> modules-fixes. For the rest, I plan to give folks more time to look at
> the changes as this affects a number of subsystems. If there are no
> other concerns, I'd then add the series on
On Fri, Jan 24, 2025 at 09:36:07AM -0800, Paul E. McKenney wrote:
> On Fri, Jan 24, 2025 at 06:21:30PM +0100, Uladzislau Rezki wrote:
> > On Fri, Jan 24, 2025 at 07:45:23AM -0800, Paul E. McKenney wrote:
> > > On Fri, Jan 24, 2025 at 12:41:38PM +0100, Uladzislau Rezki wrote:
> > > > On Thu, Jan 23,
On Fri, Jan 24, 2025 at 07:45:23AM -0800, Paul E. McKenney wrote:
> On Fri, Jan 24, 2025 at 12:41:38PM +0100, Uladzislau Rezki wrote:
> > On Thu, Jan 23, 2025 at 12:29:45PM -0800, Paul E. McKenney wrote:
> > > On Thu, Jan 23, 2025 at 07:58:26PM +0100, Uladzislau Rezki (Sony) wrote:
> > > > This con
On Fri, Jan 24, 2025 at 02:17:51PM +, Murad Masimov wrote:
>
>
> От: Dave Jiang
> Отправлено: 24 января 2025 г. 2:43
> Кому: Masimov Murad; Dan Williams
> Копия: Vishal Verma; Ira Weiny; Rafael J. Wysocki; Len Brown;
> nvd...@lists.linux.dev; linux-a
Le Fri, Jan 24, 2025 at 07:58:20AM -0800, Paul E. McKenney a écrit :
> On Fri, Jan 24, 2025 at 03:49:24PM +0100, Frederic Weisbecker wrote:
> > Le Fri, Dec 13, 2024 at 11:49:49AM -0800, Paul E. McKenney a écrit :
> > > The get_state_synchronize_rcu_full() and poll_state_synchronize_rcu_full()
> > >
On 11/27/24 09:35, Maciej Wieczor-Retman wrote:
...
> + switch (test->later) {
> + case GET_USER_USER:
> + /* Control group - properly tagger user pointer */
> + ptr = (void *)set_metadata((uint64_t)ptr, test->lam);
> + break;
s/tagger/tagged/ ?
> +
On 11/27/24 09:35, Maciej Wieczor-Retman wrote:
> +static inline int kernel_has_lam(void)
> +{
> + unsigned long bits;
> +
> + syscall(SYS_arch_prctl, ARCH_GET_MAX_TAG_BITS, &bits);
> + return !!bits;
> +}
Generally, I'm less picky about selftest/ code than in-kernel code. But
people r
On 11/27/24 09:35, Maciej Wieczor-Retman wrote:
> -/* Check 5-level page table feature in CPUID.(EAX=07H, ECX=00H):ECX.[bit 16]
> */
> static inline int cpu_has_la57(void)
> {
> - unsigned int cpuinfo[4];
> -
> - __cpuid_count(0x7, 0, cpuinfo[0], cpuinfo[1], cpuinfo[2], cpuinfo[3]);
> -
On Fri, 2025-01-24 at 07:38 -0800, Jakub Kicinski wrote:
> On Thu, 23 Jan 2025 15:24:37 + Cosmin Ratiu wrote:
> > I've sent another patch to suggest these changes.
>
> FTR this is not the normal way to proceed in code review,
> please try to share your feedback rather than taking over
> the su
On Fri, Jan 24, 2025 at 03:49:24PM +0100, Frederic Weisbecker wrote:
> Le Fri, Dec 13, 2024 at 11:49:49AM -0800, Paul E. McKenney a écrit :
> > The get_state_synchronize_rcu_full() and poll_state_synchronize_rcu_full()
> > functions use the root rcu_node structure's ->gp_seq field to detect
> > the
On Fri, Jan 24, 2025 at 12:48:12PM +0100, Uladzislau Rezki wrote:
> On Thu, Jan 23, 2025 at 01:52:57PM -0800, Paul E. McKenney wrote:
> > On Thu, Jan 23, 2025 at 07:58:28PM +0100, Uladzislau Rezki (Sony) wrote:
> > > Switch for using of get_state_synchronize_rcu_full() and
> > > poll_state_synchron
On Fri, Jan 24, 2025 at 12:41:38PM +0100, Uladzislau Rezki wrote:
> On Thu, Jan 23, 2025 at 12:29:45PM -0800, Paul E. McKenney wrote:
> > On Thu, Jan 23, 2025 at 07:58:26PM +0100, Uladzislau Rezki (Sony) wrote:
> > > This configuration specifies the maximum number of CPUs which
> > > is set to 8. T
On Thu, 23 Jan 2025 15:24:37 + Cosmin Ratiu wrote:
> I've sent another patch to suggest these changes.
FTR this is not the normal way to proceed in code review,
please try to share your feedback rather than taking over
the submission (unless the original author explicitly asks
you to).
Le Thu, Jan 23, 2025 at 08:49:47PM -0500, Joel Fernandes a écrit :
> On Thu, Dec 12, 2024 at 7:59 PM Paul E. McKenney wrote:
> >
> > The get_state_synchronize_rcu_full() and poll_state_synchronize_rcu_full()
> > functions use the root rcu_node structure's ->gp_seq field to detect
> > the beginning
Le Fri, Dec 13, 2024 at 11:49:49AM -0800, Paul E. McKenney a écrit :
> The get_state_synchronize_rcu_full() and poll_state_synchronize_rcu_full()
> functions use the root rcu_node structure's ->gp_seq field to detect
> the beginnings and ends of grace periods, respectively. This choice is
> necess
От: Dave Jiang
Отправлено: 24 января 2025 г. 2:43
Кому: Masimov Murad; Dan Williams
Копия: Vishal Verma; Ira Weiny; Rafael J. Wysocki; Len Brown;
nvd...@lists.linux.dev; linux-a...@vger.kernel.org;
linux-kernel@vger.kernel.org; lvc-proj...@linuxtesting.
On 2025/1/20 13:54, Nicolin Chen wrote:
On Sun, Jan 19, 2025 at 06:40:57PM +0800, Yi Liu wrote:
On 2025/1/19 04:32, Nicolin Chen wrote:
On Sat, Jan 18, 2025 at 04:23:22PM +0800, Yi Liu wrote:
On 2025/1/11 11:32, Nicolin Chen wrote:
+static int iommufd_hwpt_attach_device(struct iommufd_hw_page
On Thu, Jan 23, 2025 at 01:52:57PM -0800, Paul E. McKenney wrote:
> On Thu, Jan 23, 2025 at 07:58:28PM +0100, Uladzislau Rezki (Sony) wrote:
> > Switch for using of get_state_synchronize_rcu_full() and
> > poll_state_synchronize_rcu_full() pair for debug a normal
> > synchronize_rcu() call.
> >
>
On Thu, Jan 23, 2025 at 12:29:45PM -0800, Paul E. McKenney wrote:
> On Thu, Jan 23, 2025 at 07:58:26PM +0100, Uladzislau Rezki (Sony) wrote:
> > This configuration specifies the maximum number of CPUs which
> > is set to 8. The problem is that it can not be overwritten for
> > something higher.
> >
# qboot is faster than SeaBIOS and doesn't mess up
+ # the terminal.
+ extra_qemu_params=['-bios', 'qboot.rom'])
---
base-commit: 8ea24b869adeb39c6b9ce7542657a7251b56
change-id: 20250124-kunit-qboot-5201945f7e86
Best regards,
--
Brendan Jackman
Hi Stanislav
On 1/23/25 8:45 PM, Stanislav Fomichev wrote:
On 01/21, Bastien Curutchet (eBPF Foundation) wrote:
Hi all,
This patch series continues the work to migrate the *.sh tests into
prog_tests framework.
test_xdp_redirect_multi.sh tests the XDP redirections done through
bpf_redirect_map
On 23/01/2025 17:40, Peter Xu wrote:
> On Thu, Jan 23, 2025 at 02:38:46PM +, Ryan Roberts wrote:
>>> @@ -5470,7 +5471,18 @@ static void move_huge_pte(struct vm_area_struct
>>> *vma, unsigned long old_addr,
>>> spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING);
>>>
>>> pte = hug
41 matches
Mail list logo
