The variable init_pkru_value isn't used outside of this file.
Make init_pkru_value static.
Acked-by: Dave Hansen
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/mm/pkeys.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/mm/pkeys.c b/arch/x86/mm/pkeys.c
index 0af3ece1
There is no user of _TIF_ALLWORK_MASK since commit 21d375b6b34ff
("x86/entry/64: Remove the SYSCALL64 fast path").
Remove unused define _TIF_ALLWORK_MASK.
Reviewed-by: Borislav Petkov
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/include/asm/thread_info.h | 8
1 fi
text (and would be wrong in kernel context).
Remove user_fpu_begin(), it does not change fpu_fpregs_owner_ctx's
content.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/include/asm/fpu/internal.h | 17 -
arch/x86/kernel/fpu/core.c | 4 +---
arch/x86/kernel/f
_begin() could also force to save FPU's register after
fpu__initialize() without changing the outcome here.
Remove the preempt_disable() section in fpu__clear(), preemption here
does not hurt.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/kernel/fpu/core.c | 2 --
1 file changed,
The math_emu.h header files contains the definition of struct
math_emu_info. It is not used in this file.
Remove asm/math_emu.h include.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/kernel/process_32.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/kernel/process_32.c
There are no users of fpu__restore() so it is time to remove it.
The comment regarding fpu__restore() and TS bit is stale since commit
b3b0870ef3ffe ("i387: do not preload FPU state at task switch time") and
has no meaning since.
Signed-off-by: Sebastian Andrzej Siewior
---
Doc
n opcode is emulated. It makes the removal of ->initialized easier if
the struct is also initialized in FPU-less case at the same time.
Move fpu__initialize() before the FPU check so it is also performed in
FPU-less case.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/include/asm/fpu
pare copy_fpstate_to_sigframe() for TIF_NEED_FPU_LOAD
x86/fpu: Defer FPU state load until return to userspace
Sebastian Andrzej Siewior (18):
x86/fpu: Use ULL for shift in xfeature_uncompacted_offset()
x86/fpu: Remove fpu->initialized usage in __fpu__restore_sig()
x86/fpu: Remove fpu__restore()
d.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/kernel/fpu/xstate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 87a57b7642d36..9dc0a2c8c2755 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/
reased context switch time will be reverted once the FPU
registers are restored on return to userland.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/ia32/ia32_signal.c | 17 +++
arch/x86/include/asm/fpu/internal.h | 17 ---
arch/x86/include/asm/fpu/types.h| 9
On 2018-11-07 20:48:58 [+0100], To linux-kernel@vger.kernel.org wrote:
> index 8c03b42416656..d10b60d80d35a 100644
> --- a/arch/x86/include/asm/fpu/api.h
> +++ b/arch/x86/include/asm/fpu/api.h
The bot complained about missing definition for local_bh_disable() so I
swapped the preempt.h for bottom_
On 2018-11-06 15:34:55 [-0600], Grygorii Strashko wrote:
> Hi All,
Hi,
> Do anybody tried to use ARM64 RT with 76K pages enabled?
75 would be an off by one but this :)
> My attempt shows that enabling CONFIG_ARM64_64K_PAGES=y increases latencies
> by ~30%
>
> cyclictest -n -m -Sp98 -q -D2m wi
On 2018-09-25 22:14:56 [+0200], Alexandre Belloni wrote:
> On 22/09/2018 13:29:48+0200, Daniel Lezcano wrote:
> > You say for rt the PIT is not suitable because of the shared irq but in
> > the driver, the interrupt is flagged as shared.
> >
>
> Well, it is not simply sharing the interrupt that i
On 2018-11-08 15:09:35 [+0100], Alexandre Belloni wrote:
> It is not part of that series as I prefer to keep the discussion of how
> to configure that for later. This has been raised previously without any
> conclusion and I'd really like to see this rework enter upstream soon.
Okay. Does it make
; > By default, as a policy decision, disable the expediting of grace
> > periods (after boot) on configurations which enable PREEMPT_RT_FULL.
> >
> > Suggested-by: Luiz Capitulino
> > Signed-off-by: Julia Cartwright
> > Signed-off-by: Sebastian Andrzej Siewi
On 2018-11-01 16:18:04 [-0700], Paul E. McKenney wrote:
> The need for this goes away as of the current merge window because
> RCU-bh has gone away. (Aside from still being able to do things
> like rcu_read_lock_bh() as a documentation device.)
So in -RT rcu_read_lock_bh() does
{ local_bh_disabl
On 2018-11-01 16:25:18 [-0700], Paul E. McKenney wrote:
> > --- a/kernel/rcu/Kconfig
> > +++ b/kernel/rcu/Kconfig
> > @@ -36,7 +36,7 @@ config TINY_RCU
> >
> > config RCU_EXPERT
> > bool "Make expert-level adjustments to RCU configuration"
> > - default n
> > + default y if PREEMPT_RT_FU
On 2018-11-01 16:12:28 [-0700], Paul E. McKenney wrote:
> > The current check via srcu_online is slightly racy because after looking
> > at srcu_online there could be an interrupt that interrupted us long
> > enough until the CPU we checked against went offline.
>
> I don't see how this can happen
On 2018-11-01 16:21:34 [-0700], Paul E. McKenney wrote:
> > With RT_FULL we get the below wreckage:
>
> The code that this applies to has itself been fully frobbed as of the
> current merge window. I believe that it should now work in -rt as is,
> but who knows? ;-)
I will drop that patch in th
its successors, thus
> > queueing each rcu_node structure's expedited grace-period initialization
> > work on the first CPU of that rcu_node structure.
> >
> > Suggested-by: Sebastian Andrzej Siewior
> > Signed-off-by: Paul E. McKenney
> > Signed-off-b
On 2018-11-08 08:42:47 [-0800], Paul E. McKenney wrote:
> On Thu, Nov 08, 2018 at 05:02:57PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2018-11-01 16:18:04 [-0700], Paul E. McKenney wrote:
> > > The need for this goes away as of the current merge window because
> >
On 2018-11-08 09:10:24 [-0800], Paul E. McKenney wrote:
> > Is this again a hidden RCU detail that preempt_disable() on CPU4 is
> > enough to ensure that CPU2 does not get marked offline between?
>
> The call_rcu_sched parameter to synchronize_rcu_mult() makes this work.
> This synchronize_rcu_mul
On 2018-11-08 09:35:25 [-0800], Paul E. McKenney wrote:
> I agree that tglx's patch is needed for 4.19 and earlier. Just not for
> 4.20 and later.
>
> Or am I still missing your point?
nope, I think we are good.
> Thanx, Paul
Sebastian
On 2018-11-08 10:05:17 [-0800], Paul E. McKenney wrote:
> Just to make sure I understand, this is the call to queue_delayed_work_on()
> from srcu_queue_delayed_work_on(), right?
correct.
> And if I am guessing correctly, you would like to get rid of the
> constraint requiring CPUHP_RCUTREE_PREP t
On 2018-09-19 15:11:40 [-0700], Paul E. McKenney wrote:
> On Wed, Sep 19, 2018 at 01:55:21PM -0700, Tejun Heo wrote:
> > Unbound workqueue is NUMA-affine by default, so using it by default
> > might not harm anything.
>
> OK, so the above workaround would function correctly on -rt, thank you!
>
>
On 2018-10-04 09:14:33 [-0700], Andy Lutomirski wrote:
> > diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
> > index 3b2490b819181..3dad5c3b335eb 100644
> > --- a/arch/x86/entry/common.c
> > +++ b/arch/x86/entry/common.c
> > @@ -196,6 +197,14 @@ __visible inline void prepare_exit_to_
On 2018-10-12 11:07:28 [-0700], Andy Lutomirski wrote:
> All these "if" statements in the FPU code are messy and make
> understanding and reviewing this code hard.
>
> Can you prepare a patch for the beginning of your series that removes
> fpu->initialized and just ensures that the fpu is always i
On 2018-10-13 06:48:13 [-0700], Paul E. McKenney wrote:
>
> My concern would be that it would queue it by default for the current
> CPU, which would serialize the processing, losing the concurrency of
> grace-period initialization. But that was a long time ago, and perhaps
> workqueues have chang
On 2018-10-15 23:07:15 [+0800], Boqun Feng wrote:
> Hi, Sebastian
Hi Boqun,
> On Mon, Oct 15, 2018 at 04:42:17PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2018-10-13 06:48:13 [-0700], Paul E. McKenney wrote:
> > >
> > > My concern would be that it would queue
From: Rik van Riel
Add helper function that ensures the floating point registers for
the current task are active. Use with preemption disabled.
Signed-off-by: Rik van Riel
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/include/asm/fpu/internal.h | 27 ++-
1
egister on enry/exit path. I kept the flow as
is. First it ensures that the registers are loaded and then saves the
current (host) state before it loads the guest's register. Before
entring the guest, it ensures that the register are still loaded.
Signed-off-by: Rik van Riel
Signed-off-by: Sebas
From: Rik van Riel
If TIF_LOAD_FPU is set, then the registers are saved (not loaded). In that case
we skip the saving part.
Signed-off-by: Rik van Riel
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/kernel/fpu/signal.c | 16 ++--
1 file changed, 10 insertions(+), 6
Add TIF_LOAD_FPU. This is reserved for loading the FPU registers before
returning to userpace. This flag must not be set for systems without a
FPU.
It is introduced now, so we can add code handling it now before adding
the main feature.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86
lazy-FPU on x86. This is a preparation for loading the
FPU registers on return to userland.
Signed-off-by: Rik van Riel
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/include/asm/fpu/internal.h | 45
arch/x86/kernel/fpu/signal.c| 46 +++-
e loaded.
Signed-off-by: Rik van Riel
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/mm/pkeys.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/x86/mm/pkeys.c b/arch/x86/mm/pkeys.c
index a150984171684..eeb03b0f0f514 100644
--- a/arch/x86/mm/pkeys.c
+++ b/arc
n
suggested to use 0 as the PKRU value but this would bypass PKRU.
Set the initial (default) PKRU value for kernel threads.
Suggested-by: Paolo Bonzini
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/include/asm/fpu/internal.h | 20
1 file changed, 12 insertio
The variable init_pkru_value isn't used outside of this file.
Make init_pkru_value static.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/mm/pkeys.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/mm/pkeys.c b/arch/x86/mm/pkeys.c
index 4409ada551c5e..a150984171684 1
Most users of __raw_xsave_addr() use a feature number, shift it to a
mask and then __raw_xsave_addr() shifts it back to the feature number.
Make __raw_xsave_addr() use the feature number as argument.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/kernel/fpu/xstate.c | 16
This is a refurbished series originally started by by Rik van Riel. The
goal is load the FPU registers on return to userland and not on every
context switch. By this optimisation we can:
- avoid loading the registers if the task stays in kernel and does
not return to userland
- make kernel_fpu_be
che]
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/include/asm/fpu/internal.h | 20 +++
arch/x86/include/asm/fpu/xstate.h | 2 ++
arch/x86/include/asm/pgtable.h | 6 +-
arch/x86/include/asm/pkeys.h| 2 +-
arch/x86/kernel/fpu/core.c | 2 +-
arch
There is no user of _TIF_ALLWORK_MASK since commit 21d375b6b34ff
("x86/entry/64: Remove the SYSCALL64 fast path").
Remove unused define _TIF_ALLWORK_MASK.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/include/asm/thread_info.h | 8
1 file changed, 8 deletions(-)
di
On 2018-10-04 15:46:21 [+0200], Daniel Wagner wrote:
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 6df130a37d41..21f9418d850f 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -42,7 +42,7 @@ config X86
> select ARCH_USE_BUILTIN_BSWAP
> select ARCH_USE_CMPXCHG_LO
On 2018-10-04 12:45:08 [-0400], Rik van Riel wrote:
> Wait, so any thread can bypass its memory protection
> keys, even if there is a seccomp filter preventing
> it from calling the PKRU syscalls?
We have SYS_pkey_alloc +free and SYS_pkey_mprotect. For read/ write of
the register value, libc is us
On 2018-09-24 10:29:01 [+0200], Kurt Kanzenbach wrote:
> Silence the following gcc warning:
>
> drivers/tty/serial/amba-pl011.c: In function ‘pl011_console_write’:
> ./include/linux/spinlock.h:260:3: warning: ‘flags’ may be used uninitialized
> in this function [-Wmaybe-uninitialized]
>_raw_s
On 2018-09-18 10:29:31 [-0500], Clark Williams wrote:
So I received this from Clark:
> The static lock quarantine_lock is used in mm/kasan/quarantine.c to protect
> the quarantine queue datastructures. It is taken inside quarantine queue
> manipulation routines (quarantine_put(), quarantine_reduc
dn't that work for you?
Signed-off-by: Sebastian Andrzej Siewior
---
mm/kasan/quarantine.c | 45 +--
1 file changed, 26 insertions(+), 19 deletions(-)
diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
index 3a8ddf8baf7dc..8ed595960e3c1 100644
--- a/
On 2018-09-19 04:34:50 [+0800], kbuild test robot wrote:
> Hi Clark,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on linux-rt-devel/for-kbuild-bot/current-stable]
>
> url:
> https://github.com/0day-ci/linux/commits/Clark-Williams/rt-convert-mm-kasan
ormed under the lock
> is well-bounded and minimal.
>
> Cc: Sebastian Andrzej Siewior
> Cc: Guenter Roeck
> Reported-and-tested-by: Steffen Trumtrar
> Reported-by: Tim Sander
> Signed-off-by: Julia Cartwright
Acked-by: Sebastian Andrzej Siewior
Sebastian
On 2018-09-28 21:03:51 [+], Julia Cartwright wrote:
> When PREEMPT_RT_FULL is enabled, all hrtimer expiry functions are
> deferred for execution into the context of ktimersoftd unless otherwise
> annotated.
…
> Signed-off-by: Julia Cartwright
did s@HRTIMER_MODE_REL@HRTIMER_MODE_REL_HARD@ and
On 2018-10-12 11:15:51 [-0700], Dave Hansen wrote:
> > @@ -172,27 +155,20 @@ int copy_fpstate_to_sigframe(void __user *buf, void
> > __user *buf_fx, int size)
> > sizeof(struct user_i387_ia32_struct), NULL,
> > (struct _fpstate_32 __user *) buf) ? -1 : 1;
>
On 2018-10-15 17:24:31 [+0200], Borislav Petkov wrote:
> On Fri, Oct 12, 2018 at 12:40:19PM -0700, Dave Hansen wrote:
> > > + __fpregs_changes_end();
> >
> > Do we really need the __fpregs_changes_*() abstraction for this single
> > call site?
>
> Yap, I'm staring at those in patch 2, there's no
On 2018-10-12 12:40:19 [-0700], Dave Hansen wrote:
> On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> > From: Rik van Riel
> >
> > If TIF_LOAD_FPU is set, then the registers are saved (not loaded). In that
> > case
> > we skip the saving part.
t_xsave_addr() argument a xfeature number instead of mask and fix
up its callers.
As part of this use xfeature_nr and xfeature_mask consistently.
This results in changes to the kvm code as:
feature -> xfeature_mask
index -> xfeature_nr
Suggested-by: Dave Hansen
Signed-off-
On 2018-10-11 19:30:07 [+0200], Christophe de Dinechin wrote:
> > diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
> > index 87a57b7642d36..38d0b5ea40425 100644
> > --- a/arch/x86/kernel/fpu/xstate.c
> > +++ b/arch/x86/kernel/fpu/xstate.c
> > @@ -811,10 +811,8 @@ void fpu__r
On 2018-10-18 13:17:19 [+0200], To Dave Hansen wrote:
> --- a/arch/x86/include/asm/fpu/xstate.h
> +++ b/arch/x86/include/asm/fpu/xstate.h
> @@ -47,7 +47,7 @@ extern void __init update_regset_xstate_info(unsigned int
> size,
>
> void fpu__xstate_clear_all_cpu_caps(void);
> void *get_xsave_addr(
On 2018-10-17 12:01:43 [+0200], Borislav Petkov wrote:
> > -void *__raw_xsave_addr(struct xregs_state *xsave, int xstate_feature_mask)
> > +void *__raw_xsave_addr(struct xregs_state *xsave, int feature_nr)
>
> Don't forget to update the comment above it too - it still says "mask".
done.
> Otherwi
On 2018-10-12 10:51:34 [-0700], Dave Hansen wrote:
> > diff --git a/arch/x86/include/asm/fpu/internal.h
> > b/arch/x86/include/asm/fpu/internal.h
> > index 16c4077ffc945..956d967ca824a 100644
> > --- a/arch/x86/include/asm/fpu/internal.h
> > +++ b/arch/x86/include/asm/fpu/internal.h
> > @@ -570,11
On 2018-10-12 11:02:18 [-0700], Andy Lutomirski wrote:
> On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen
> wrote:
> >
> > On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> > > The PKRU value is not set for kernel threads because they do not have
> > &g
On 2018-10-18 09:48:24 [-0700], Andy Lutomirski wrote:
> > On Oct 18, 2018, at 9:26 AM, Sebastian Andrzej Siewior
> > wrote:
> >> On 2018-10-12 11:02:18 [-0700], Andy Lutomirski wrote:
> >> On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen
> >>> S
On 2018-10-18 13:56:24 [-0700], Dave Hansen wrote:
> > But this is not the only loophole: There is ptrace interface which is
> > used by gdb (just checked) and also bypasses PKRU. So…
>
> Bypassing protection keys is not a big deal IMNHO. In places where a
> sane one is not readily available, I'm
On 2018-09-15 23:26:53 [+], Michael Kelley (EOSG) wrote:
> From Sebastian Andrzej Siewior Sent: Thursday, August 30, 2018 12:55 AM
> >
> > On !RT the header file get_irq_regs() gets pulled in via other header
> > files. On
> > RT it does not and the build fai
On 2018-09-17 10:37:20 [+0200], Paolo Bonzini wrote:
> > . This is (again)
> > untested since I have no box with this PKRU feature. This only available
> > on Intel's Xeon Scalable, right?
>
> It is available on QEMU too (the slower JIT thing without KVM, i.e. use
> /usr/bin/qemu-system-x86_64 ins
On 2018-09-18 17:29:52 [+0200], Paolo Bonzini wrote:
> > I don't think it matters what the PKRU state is
> > for kernel threads, since kernel PTEs should not
> > be using protection keys anyway.
>
> What about copy_from/to_user?
This doesn't work for a kernel thread, does it? I mean they share th
haohua, are you with this?
> Cc: Shaohua Li
> Cc: linux-r...@vger.kernel.org
> Acked-by: Peter Zijlstra (Intel)
> Signed-off-by: Anna-Maria Gleixner
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> drivers/md/raid5.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 de
ituations.
Andrew, is it okay for you to collect this one (and 4/6 of this series,
both bdi)? The prerequisites are already in Linus' tree.
> Cc: linux...@kvack.org
> Cc: Andrew Morton
> Suggested-by: Peter Zijlstra
> Acked-by: Peter Zijlstra (Intel)
> Signed-off-
ituations.
Ingo, Andrew: who of you two feels most comfortable to apply this one
(and 6/6 of this series, both `userns')? If none, who would you suggest?
> Cc: Andrew Morton
> Suggested-by: Peter Zijlstra
> Acked-by: Peter Zijlstra (Intel)
> Signed-off-by: Sebastian Andrzej
On 2018-07-16 15:57:16 [-0700], Andrew Morton wrote:
> > --- a/mm/backing-dev.c
> > +++ b/mm/backing-dev.c
> > @@ -438,10 +438,10 @@ wb_congested_get_create(struct backing_dev_info *bdi,
> > int blkcg_id, gfp_t gfp)
> > if (new_congested) {
> > /* !found and storage for new one alr
w should cure the issue. It also renames the horribly
misnomed functions so it becomes clear what they are supposed to do.
Signed-off-by: Thomas Gleixner
[bigeasy: add the body of the patch, use the same functions in both
ifdef paths (spotted by Andy Shevchenko)]
Signed-off-by: Sebastian
On 2018-07-16 16:17:39 [+0100], Dave Martin wrote:
> On Fri, Jul 13, 2018 at 07:49:38PM +0200, Sebastian Andrzej Siewior wrote:
> > In v4.16-RT I noticed a number of warnings from task_fpsimd_load(). The
> > code disables BH and expects that it is not preemptible. On -RT the
&
On 2018-07-18 11:12:10 [+0200], To Dave Martin wrote:
> > > - if (may_use_simd()) {
> > > + if (!IS_ENABLED(CONFIG_PREEMPT_RT_BASE) && may_use_simd()) {
> >
> > I suspect this is wrong -- see comments on the commit message.
I'm sorry, I pressed send too early, I was aiming for the draft folder.
S
On 2018-07-14 00:03:44 [+0200], Mike Galbraith wrote:
> > This seems to make work (crypto chacha20-neon + cyclictest). I have no
> > EFI so I have no clue if saving SIMD while calling to EFI works.
>
> All is not well on cavium test box. I'm seeing random errors ala...
>
> ./include/linux/fs.h:3
On 2018-07-18 12:28:48 [+0200], Mike Galbraith wrote:
> > Okay, so you did not test this because you can't compile.
>
> Nope, the running kernel, the one that is doing the segfaulting etc,
> has the patches applied.
>
> It is exhibiting that symptom because those patches do not cure this
> sympto
On 2018-07-16 17:37:27 [-0700], Shaohua Li wrote:
> On Mon, Jul 16, 2018 at 02:27:40PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2018-07-03 22:01:36 [+0200], To linux-kernel@vger.kernel.org wrote:
> > > From: Anna-Maria Gleixner
> > >
> > > The irqsave va
The its_lock lock is held while a new device is added to the list and
during setup while the CPU is booted. Even on -RT the CPU-bootup is
performed with disabled interrupts.
Make its_lock a raw_spin_lock_t.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/irqchip/irq-gic-v3-its.c | 18
The errors popped up in -RT. One is the spinlock_t usage in IRQ-off
region which should be a raw_spinlock_t. I don't see this to be used
during run-time or for long period of time so I don't thing this is an
issue.
The second problem is the ->pend_page allocation on the target_cpu early
during CPU
ion to an earlier hotplug step which is invoked
with enabled interrupts on the boot CPU.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/irqchip/irq-gic-v3-its.c | 60 ++--
1 file changed, 41 insertions(+), 19 deletions(-)
diff --git a/drivers/irqchip/irq-gic
On 2023-12-18 09:52:05 [+0100], Daniel Borkmann wrote:
> Hi Sebastian,
Hi Daniel,
> Please exclude netkit from this set given it does not support XDP, but
> instead only accepts tc BPF typed programs.
okay, thank you.
> Thanks,
> Daniel
Sebastian
On 2024-02-02 18:04:56 [+0100], Daniel Wagner wrote:
> Dear RT Folks,
Hi,
> This is the RT stable review cycle of patch 4.19.306-rt132-rc1.
…
> Please scream at me if I messed something up. Please test the patches
> too.
Good.
> Enjoy!
> Daniel
Sebastian
On 2024-05-06 13:00:39 [+0200], Daniel Wagner wrote:
> Hi Sebastian,
Hi Daniel,
> On 06.05.24 12:46, Daniel Wagner wrote:
> > Dear RT Folks,
> >
> > This is the RT stable review cycle of patch 4.19.312-rt134-rc2.
> >
> > Please scream at me if I messed something up. Please test the patches
> > t
On 2024-05-07 17:16:47 [+0200], Daniel Wagner wrote:
> Dear RT Folks,
>
> This is the RT stable review cycle of patch 4.19.312-rt134-rc3.
>
> Please scream at me if I messed something up. Please test the patches
> too.
>
> The -rc release is also available on kernel.org
I do have to complain a b
ts.linux.dev
Cc: xen-de...@lists.xenproject.org
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/net/hyperv/netvsc_bpf.c | 1 +
drivers/net/netkit.c| 13 +++
drivers/net/tun.c | 28 +--
drivers/net/veth
On 2024-05-15 23:05:36 [+0100], Qais Yousef wrote:
> rt_task() checks if a task has RT priority. But depends on your
> dictionary, this could mean it belongs to RT class, or is a 'realtime'
> task, which includes RT and DL classes.
>
> Since this has caused some confusion already on discussion [1]
On 2024-05-28 00:45:08 [+0100], Qais Yousef wrote:
> diff --git a/include/linux/sched/deadline.h b/include/linux/sched/deadline.h
> index 5cb88b748ad6..87d2370dd3db 100644
> --- a/include/linux/sched/deadline.h
> +++ b/include/linux/sched/deadline.h
> @@ -10,7 +10,7 @@
>
> #include
>
> -stati
On 2024-05-27 18:26:50 [+0100], Qais Yousef wrote:
> > In order to be PI-boosted you need to acquire a lock and the only lock
> > you can sleep while acquired without generating a warning is a mutex_t
> > (or equivalent sleeping lock) on PREEMPT_RT.
>
> Note we care about the behavior for !PREEMP
On 2024-05-29 11:34:09 [+0100], Qais Yousef wrote:
> > behaviour. But then it is insistent which matters only in the RT case.
> > Puh. Any sched folks regarding policy?
>
> I am not sure I understood you here. Could you rephrase please?
Right now a SCHED_OTHER task boosted to a realtime priority
On 2024-05-30 12:10:44 [+0100], Qais Yousef wrote:
> > This is not consistent because IMHO the clock setup & slack should be
> > handled equally. So I am asking the sched folks for a policy and I am
> > leaning towards looking at task-policy in this case instead of prio
> > because you shouldn't do
On 2024-06-04 17:57:46 [+0200], Daniel Bristot de Oliveira wrote:
> On 6/4/24 16:42, Qais Yousef wrote:
> > - (wakeup_rt && !dl_task(p) && !rt_task(p)) ||
> > + (wakeup_rt && !realtime_task(p)) ||
>
> I do not like bikeshedding, and no hard feelings...
>
> But rt is a shortened versio
On 2024-06-04 15:42:26 [+0100], Qais Yousef wrote:
> Make rt_task() return true only for RT class and add new realtime_task() to
> return true for RT and DL classes to avoid some confusion the old API can
> cause.
Reviewed-by: Sebastian Andrzej Siewior
Sebastian
On 2021-02-13 08:45:54 [-0800], Paul E. McKenney wrote:
> Glad you like it! But let's see which (if any) of these patches solves
> the problem for Sebastian.
Looking at that, is there any reason for doing this that can not be
solved by moving the self-test a little later? Maybe once we reached at
the softirq thread on PREEMPT_RT if there are any pending softirqs.
Signed-off-by: Sebastian Andrzej Siewior
---
kernel/smp.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -450,8 +450,18 @@ void flush_smp_call_function_from_idle(v
Dear RT folks!
I'm pleased to announce the v5.10.16-rt30 patch set.
Changes since v5.10.16-rt29:
- Due to recent softirq rework it was not possible to compile a kernel
with RT && !SMP. Reported by Jonathan Schwender, patch by Christian
Eggers.
- Update the block-mq patches to the v
On 2021-02-16 09:42:30 [+0100], Christoph Hellwig wrote:
> On Mon, Feb 15, 2021 at 10:46:23PM +, David Howells wrote:
> > The in_softirq() in netfs_rreq_terminated() works fine for the cache being
> > on a normal disk, as the completion handlers may get called in softirq
> > context, but for an
On 2021-02-16 10:56:14 [+0100], Peter Zijlstra wrote:
> So while I'm in favour of adding a new interface, I'm not sure I see
> benefit of reimplementing the basics, sure it seems simpler now, but
> that's because you've not implemented all the 'fun' stuff.
The last attempt tried to hide the update
On 2021-02-16 10:32:15 [+0100], Miguel Ojeda wrote:
> Hi Sebastian,
Hi,
> On Sat, Feb 13, 2021 at 5:50 PM Sebastian Andrzej Siewior
> wrote:
> >
> > charlcd_write() is invoked as a VFS->write() callback and as such it is
> > always invoked from preemptible context
Dear RT folks!
I'm pleased to announce the v5.11-rt5 patch set.
Changes since v5.11-rt4:
- Lazy preemption fix for 64bit PowerPC. It was broken since
v5.9-rc2-rt1. Reported by John Ogness.
- Two patches for chelsio/cxgb network driver to avoid
tasklet_disable() usage in atomic cont
On 2021-02-16 13:42:19 [+0100], Miguel Ojeda wrote:
> It is not so much about documenting the obvious, but about stating
> that 1) the precondition was properly taken into account and that 2)
> nothing non-obvious is undocumented. When code is changed later on, it
> is much more likely assumptions
ove in_interrupt() and use cond_resched() to schedule every 32
iteration if needed.
Link: https://lkml.kernel.org/r/20200914204209.256266...@linutronix.de
Cc: Miguel Ojeda Sandonis
Signed-off-by: Sebastian Andrzej Siewior
---
v2…v4: - Spelling fixes got lot.
- Add a comment before cond_resched()
dev_err(&pdev->dev, "failed to get alias/pdev id\n");
return ret;
}
up.port.line = ret;
but I didn't think of that others might pass < 0 since it wasn't used
before.
Does the original patch (you noted) break anything as of now? Because
then t
- Yoshihiro YUNOMAE
(reason: 550 5.1.1 : Recipient
address rejected: User Unknown)
On 01/16/2015 11:37 AM, Michal Simek wrote:
> Hi,
Hi,
> Origin patch looks good to me but this checking will be good to add.
> Are you using of_serial.c because I didn't find any of_alias_get_id call
> for 8250?
On 01/16/2015 12:02 PM, Michal Simek wrote:
>>> Origin patch looks good to me but this checking will be good to add.
>>> Are you using of_serial.c because I didn't find any of_alias_get_id call
>>> for 8250?
>>
>> I'm using of_alias_get_id() in 8250_omap.c which made it into
>> v3.19-rc1. I think t
801 - 900 of 3688 matches
Mail list logo
