On 2020-11-13 13:51:19 [+0100], Andrey Konovalov wrote:
> Hi Sebastian,
Hi Andrey,
> Replaced with what and why?
Linus requested in
https://lkml.kernel.org/r/CAHk-=wht7kaeyr5xew2orj7m0hibvxz3t+2ie8vnhlqfdbn...@mail.gmail.com/
that drivers should not change their behaviour on context
On 2020-10-16 15:57:45 [+0200], Andrey Konovalov wrote:
> --- a/drivers/usb/core/hcd.c
> +++ b/drivers/usb/core/hcd.c
> @@ -1646,9 +1646,16 @@ static void __usb_hcd_giveback_urb(struct urb *urb)
>
> /* pass ownership to the completion handler */
> urb->status = status;
> -
Dear RT folks!
I'm pleased to announce the v5.10-rc3-rt7 patch set.
Changes since v5.10-rc3-rt6:
- Mike Galbraith reported a lockdep warning triggered by the nouveau
driver with threaded interrupts.
- The recently reworked highmem code could trigger a warning on
certain ARM
On 2020-11-12 13:39:02 [+0100], Daniel Wagner wrote:
> With the current version signaltest + your test patch and 'taskset -c1'
> the results looks good again, around 230us (running since 2 hours). I've
> tested first without taskset and it took about an half hour to hit
> 350us. So pinning the
On 2020-11-12 09:10:34 [+0100], Marek Szyprowski wrote:
> I can do more tests to help fixing this issue. Just let me know what to do.
-> https://lkml.kernel.org/r/87y2j6n8mj@nanos.tec.linutronix.de
Sebastian
On 2020-11-09 15:37:03 [+0100], Daniel Wagner wrote:
> > I've been staring at the code of signaltest on Friday and I might need
> > to stare longer to figure out what it does.
>
> I hear you. Anyway, I gave the current head a run with lazy preemption
> disabled as you asked for.
I just sent a
Mike reported [0] a lockdep splat triggered by the nouveau driver together
with enabled threaded interrupts.
I can't easily tell if moving / changing locking within nouveau does not
break anything and does not create the same lockchain in another path.
Mike did confirm that the lockdep splat can
Fixes: 710da3c8ea7df ("sched/core: Prevent race condition between cpuset and
__sched_setscheduler()")
Reported-by: Mike Galbraith
Signed-off-by: Sebastian Andrzej Siewior
Link:
https://lkml.kernel.org/r/a23a826af7c108ea5651e73b8fbae5e653f16e86.ca...@gmx.de
---
kernel/kthread.c | 16 +
of the newly created thread.
Fixes: 710da3c8ea7df ("sched/core: Prevent race condition between cpuset and
__sched_setscheduler()")
Reported-by: Mike Galbraith
Signed-off-by: Thomas Gleixner
[bigeasy: Patch description]
Signed-off-by: Sebastian Andrzej Siewior
L
On 2020-11-09 12:01:06 [-0500], Steven Rostedt wrote:
> Note, I took this because it mentioned:
>
> "Commit
>9652dc2eb9e40 ("tcp: relax listening_hash operations")
>
> removed the need to disable bottom half while acquiring
> listening_hash.lock. There are still two callers
On 2020-11-09 15:37:03 [+0100], Daniel Wagner wrote:
> > this looks odd. So rt1 has 415, rt2 has 399 and rt3 has 420 so lets say
> > it is the same. And then rt4 should reduce it to 340. The only part that
> > could have some influence is the are the highmem/kmap patches. But for
> > ARM64 these
Dear RT folks!
I'm pleased to announce the v5.10-rc3-rt6 patch set.
Changes since v5.10-rc3-rt5:
- The new migrate-disable didn't release a lock in an error path.
Reported by Joe Korty.
Known issues
- It has been pointed out that due to changes to the printk code the
On 2020-11-06 17:14:13 [+0100], Daniel Wagner wrote:
> On Fri, Nov 06, 2020 at 11:54:47AM +0100, Sebastian Andrzej Siewior wrote:
> > > rpi3signaltest 5.9.0-rc8-rt12
> > > 813 0_signaltest t0-max-latency : fail 214.00
> > > rpi3
I've been looking at the patch and it looks like it should work. Having
numbers to backup the performance in the pure-software version and with
HW acceleration would _very_ nice to have.
On 2020-11-07 19:53:32 [+1300], Barry Song wrote:
> index fbb7829..73f04de 100644
> --- a/mm/zswap.c
> +++
On 2020-11-06 21:06:42 [-0500], Steven Rostedt wrote:
> 5.4.74-rt42-rc1 stable review patch.
> If anyone has any objections, please let me know.
The remaining queue looks good.
Sebastian
On 2020-11-06 21:06:38 [-0500], Steven Rostedt wrote:
> 5.4.74-rt42-rc1 stable review patch.
> If anyone has any objections, please let me know.
Please drop that one. Lockep complains on RT with newer softirq code.
Older RT and mainline does not complain here unless it observes
On 2020-11-02 18:12:38 [+], Christoph Hellwig wrote:
> > to not break that assumption you just mentioned and provide
> > |static inline void blk_mq_complete_request_local(struct request *rq)
> > |{
> > | rq->q->mq_ops->complete(rq);
> > |}
> >
> > so that completion issued
On 2020-11-04 17:06:50 [+0100], Daniel Wagner wrote:
> On Wed, Nov 04, 2020 at 02:09:30PM +0100, Sebastian Andrzej Siewior wrote:
> > Could you figure out if the arm64 thingy started with -rt4 or was
> > already in rt3?
>
> I wrote a quick and dirty script to extract the dat
On 2020-11-04 13:47:46 [+0100], Daniel Wagner wrote:
> On Wed, Nov 04, 2020 at 12:19:48PM +0100, Daniel Wagner wrote:
> > Yes, Just fired up signaltest 5 times for arm64 and x86_64 with the
> > latest release. Keep you posted.
>
> arm64
> 1184 0_signaltest t0-max-latency : fail
On 2020-11-04 11:38:09 [+0100], Daniel Wagner wrote:
> On Tue, Nov 03, 2020 at 08:57:31PM +0100, Sebastian Andrzej Siewior wrote:
> > I'm pleased to announce the v5.10-rc2-rt4 patch set.
>
> All tests on passed in my lab. On arm64 and arm I saw slightly higher
> max latency val
Dear RT folks!
I'm pleased to announce the v5.10-rc2-rt4 patch set.
Changes since v5.10-rc2-rt3:
- Update Thomas Gleixner's "mm/highmem: Preemptible variant of
kmap_atomic & friends" series from v2 to v3.
- Compile fix PREEMPT_COUNT=n.
- Luis Claudio R. Goncalve reported a ptrace
timer.
Add a lockdep annotation to ensure that this function is always invoked
in preemptible context on PREEMPT_RT.
Reported-by: Mike Galbraith
Signed-off-by: Sebastian Andrzej Siewior
---
kernel/time/timer.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/kernel/time
On 2020-10-31 09:00:49 [-0600], Jens Axboe wrote:
> There really aren't any rules for this, and it's perfectly legit to
> complete from process context. Maybe you're a kthread driven driver and
> that's how you handle completions. The block completion path has always
> been hard IRQ safe, but
On 2020-10-29 14:07:59 [-0700], Sagi Grimberg wrote:
> > in which context?
>
> Not sure what is the question.
The question is in which context do you complete your requests. My guess
by now is "usually softirq/NAPI and context in rare error case".
> > But this is probably nr_hw_queues > 1?
>
>
Dear RT folks!
I'm pleased to announce the v5.10-rc1-rt2 patch set.
Changes since v5.10-rc1-rt1:
- Add Thomas Gleixner's "Preemptible variant of kmap_atomic & friends"
series.
- Apply patch by Paul E. McKenney which avoids a warning while a RCU
stall is printed.
- The last
On 2020-10-29 13:03:26 [-0700], Sagi Grimberg wrote:
>
> > > > Well, usb-storage obviously seems to do it, and the block layer
> > > > does not prohibit it.
> > >
> > > Also loop, nvme-tcp and then I stopped looking.
> > > Any objections about adding local_bh_disable() around it?
> >
> > To me
On 2020-10-29 14:05:36 [+], Christoph Hellwig wrote:
> Well, usb-storage obviously seems to do it, and the block layer
> does not prohibit it.
Also loop, nvme-tcp and then I stopped looking.
Any objections about adding local_bh_disable() around it?
Sebastian
On 2020-10-28 15:12:51 [+0100], To linux-bl...@vger.kernel.org wrote:
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -667,14 +632,21 @@ bool blk_mq_complete_request_remote(struct request *rq)
> return false;
>
> if (blk_mq_complete_need_ipi(rq)) {
…
> } else {
>
On 2020-10-27 10:07:35 [-0700], Fernando Lopez-Lezcano wrote:
> The compilation process went ahead (not finished yet), let me know if there
> is a proper patch. No hurry...
I just released -rt20 and it compiles now. I looked at the code and I
wouldn't recommend to use it unless you know exactly
Controllers with multiple queues have their IRQ-handelers pinned to a
CPU. The core shouldn't need to complete the request on a remote CPU.
Remove this case and always raise the softirq to complete the request.
Signed-off-by: Sebastian Andrzej Siewior
---
block/blk-mq.c | 14 +-
1
was added (otherwise it is already pending).
This simplifies the code a little and reduces the IRQ-off regions. With
this change it possible to reduce the SMP-function call a simple
__raise_softirq_irqoff().
Signed-off-by: Sebastian Andrzej Siewior
---
block/blk-mq.c | 78
mode) is bad because the completion handler may
acquire sleeping locks which violate the locking context.
Disable request completing on a remote CPU in force threaded mode.
Signed-off-by: Sebastian Andrzej Siewior
---
block/blk-mq.c | 8
1 file changed, 8 insertions(+)
diff --git
On 2020-10-28 14:44:53 [+], Christoph Hellwig wrote:
> On Wed, Oct 28, 2020 at 03:12:51PM +0100, Sebastian Andrzej Siewior wrote:
> > static int blk_softirq_cpu_dead(unsigned int cpu)
> > {
> > - /*
> > -* If a CPU goes away, splice its entries to the current
or interrupts
even with GFP_ATOMIC.
Signed-off-by: Sebastian Andrzej Siewior
---
lib/test_lockup.c | 16
1 file changed, 16 insertions(+)
diff --git a/lib/test_lockup.c b/lib/test_lockup.c
index f1a020bcc763e..864554e769738 100644
--- a/lib/test_lockup.c
+++ b/lib
()
for the same reason.
Cc: stable...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior
---
mm/memcontrol.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index f35ffe52cc4f8..09fa87f7a8119 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -829,6
Dear RT folks!
I'm pleased to announce the v5.9.1-rt20 patch set.
Changes since v5.9.1-rt19:
- Tiny update to the rtmutex patches (make __read_rt_trylock()
static).
- The test_lockup module failed to compile. Reported by Fernando
Lopez-Lezcano.
- The `kcompactd' daemon together
Dear RT folks!
I'm pleased to announce the v5.10-rc1-rt1 patch set.
Changes since v5.9.1-rt20
- Rebase to v5.10-rc1.
Known issues
- It has been pointed out that due to changes to the printk code the
internal buffer representation changed. This is only an issue if tools
On 2020-10-27 17:23:09 [+], Christoph Hellwig wrote:
> Ok. I was hoping we could hide this in core code somehow, especially
> a peterz didn't like the use of smp_call_function_single_async in the
> blk-mq completion code very much.
No idea how you could efficiently avoid
On 2020-10-27 17:23:09 [+], Christoph Hellwig wrote:
> On Tue, Oct 27, 2020 at 06:05:15PM +0100, Thomas Gleixner wrote:
> > > Is there a way to raise a softirq and preferably place it on a given
> > > CPU without our IPI dance? That should be a win-win situation for
> > > everyone.
> >
> >
On 2020-10-27 11:34:11 [+0100], Daniel Wagner wrote:
> On Tue, Oct 27, 2020 at 11:28:51AM +0100, Sebastian Andrzej Siewior wrote:
> > Is it running as a RT task?
>
> root@c2d:~/rt-tests# ./pi_stress
> Starting PI Stress Test
> Number of thread groups: 1
> Duration of tes
On 2020-10-27 11:09:51 [+0100], Thomas Gleixner wrote:
> --- a/arch/x86/include/asm/fpu/api.h
> +++ b/arch/x86/include/asm/fpu/api.h
> @@ -32,15 +32,27 @@ extern void fpregs_mark_activate(void);
> *
> * local_bh_disable() protects against both preemption and soft interrupts
> * on !RT
On 2020-10-27 11:25:47 [+0100], Daniel Wagner wrote:
> Well, one thing I need to figure out is how to get pi_stress working
> correctly on my machines (that is for all -rt trees, so it's nothing
> new). It consistently triggers RCU stall warnings with hackbench as
> workload. Clark told me the
On 2020-10-27 11:14:34 [+0100], Mike Galbraith wrote:
> On Tue, 2020-10-27 at 10:00 +0100, Sebastian Andrzej Siewior wrote:
> > Let me try if I can figure out when this broke.
>
> My money is on...
> 710da3c8ea7df (Juri Lelli 2019-07-19 16:00:00 +0200 5317) if (pi)
>
On 2020-10-27 09:26:06 [+], Christoph Hellwig wrote:
> On Fri, Oct 23, 2020 at 03:52:19PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2020-10-23 12:21:30 [+0100], Christoph Hellwig wrote:
> > > > - if (!IS_ENABLED(CONFIG_SMP) ||
> > > > +
On 2020-10-27 10:36:16 [+0100], Daniel Wagner wrote:
> On Sat, Oct 24, 2020 at 11:18:38AM +0200, Sebastian Andrzej Siewior wrote:
> > I'm pleased to announce the v5.9.1-rt19 patch set.
>
> FWIW, all tests pass in my lab (by avoiding doing the same stupid
> mistake as last time
On 2020-10-27 07:03:38 [+0100], Mike Galbraith wrote:
> On Mon, 2020-10-26 at 20:53 +0100, Sebastian Andrzej Siewior wrote:
> >
> > Could you try this, please?
>
> Nogo, first call of sched_setscheduler() is via kthread_create(). I
> confirmed that nuking that (gra
On 2020-10-26 23:53:20 [-0700], Fernando Lopez-Lezcano wrote:
> Maybe I'm doing something wrong but I get a compilation error (see below)
> when trying to do a debug build (building rpm packages for Fedora). 5.9.1 +
> rt19...
>
> Builds fine otherwise...
If you could remove CONFIG_TEST_LOCKUP
On 2020-10-26 20:15:23 [+0100], Mike Galbraith wrote:
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
> @@ -116,7 +116,17 @@ nvkm_pci_oneinit(struct nvkm_subdev *sub
> return ret;
> }
>
> + /*
> + *
On 2020-10-24 13:00:00 [+0800], Hillf Danton wrote:
>
> Hmm...curious how that word went into your mind. And when?
> > [ 30.457363]
> >other info that might help us debug this:
> > [ 30.457369] Possible unsafe locking scenario:
> >
> > [ 30.457375]CPU0
> > [
On 2020-10-24 17:42:24 [+0800], Hillf Danton wrote:
> Hmm...sounds like you learned English neither at high school nor
> college. When did you start learning it?
He learned enough to submit valid bug report where you could reply with
Thank you Mike!
Sebastian
On 2020-10-07 18:18:03 [+0200], Rafael J. Wysocki wrote:
> On 10/6/2020 11:49 PM, Sebastian Andrzej Siewior wrote:
> > On 2020-08-11 20:49:05 [+0200], To Stephen Berman wrote:
> > > On 2020-08-11 19:22:19 [+0200], Stephen Berman wrote:
> > > > Attached.
> > >
t.
Signed-off-by: Ahmed S. Darwish
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
Cc: Johan Hovold
Cc: Greg Kroah-Hartman
Cc: linux-...@vger.kernel.org
---
v2…v3:
- Don't make dev_dbg() conditional on `tty'
- Remove the part "tty happens always in proces
On 2020-10-25 17:56:47 [+0100], Johan Hovold wrote:
> There's a ton of issues with this driver, but this is arguably making
> things worse. A line discipline may call write() from just about any
> context so we cannot rely on tty being non-NULL here (e.g. PPP).
I wasn't aware of that. I've been
s up the xircom device support and some style
> issues.
Thank you Johan. This series fixes quite some issues including the
in_interrupt() part. I added the buffer part because it hurt to see an
allocation for one byte. There is no loss without it :)
Acked-by: Sebastian Andrzej Siewior
> Johan
Sebastian
On 2020-10-25 18:45:57 [+0100], Johan Hovold wrote:
> Drop the separate Kconfig symbol for Xircom / Entrega and always include
> support in the keyspan_pda driver.
>
> Signed-off-by: Johan Hovold
> ---
> drivers/usb/serial/Kconfig | 19 ++---
> drivers/usb/serial/Makefile | 1 -
Dear RT folks!
I'm pleased to announce the v5.9.1-rt19 patch set.
Changes since v5.9.1-rt18:
- Mike Galbraith reported a possible circular locking dependency with
a seqcount. Backported a patch from upstream solving the issue.
- David Runge reported a crash in the block layer.
-
On 2020-10-23 12:21:30 [+0100], Christoph Hellwig wrote:
> > - if (!IS_ENABLED(CONFIG_SMP) ||
> > + if (!IS_ENABLED(CONFIG_SMP) || IS_ENABLED(CONFIG_PREEMPT_RT) ||
> > !test_bit(QUEUE_FLAG_SAME_COMP, >q->queue_flags))
>
> This needs a big fat comment explaining your rationale. And
of the routine in softirq context.
Let blk_mq_complete_need_ipi() return that there is no need for IPI on
PREEMPT_RT.
Signed-off-by: Sebastian Andrzej Siewior
---
block/blk-mq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index e37aa31332b70
On 2020-10-22 07:28:20 [+0200], Mike Galbraith wrote:
> I've only as yet seen nouveau lockdep gripage when firing up one of my
> full distro KVM's.
Could you please check !RT with the `threadirqs' command line option? I
don't think RT is doing here anything different (except for having
threaded
On 2020-10-22 07:21:13 [+0200], Mike Galbraith wrote:
> Greetings,
Hi,
> The gripe below is repeatable in two ways here, boot with nomodeset so
> nouveau doesn't steal the lockdep show when I then fire up one of my
> (oink) full distro VM's, or from an ltp directory ./runltp -f cpuset
> with the
On 2020-10-21 14:53:27 [+0200], To Thomas Gleixner wrote:
> Dear RT folks!
>
> I'm pleased to announce the v5.9.1-rt18 patch set.
>
> Changes since v5.9.1-rt17:
>
> - Update the migrate-disable series by Peter Zijlstra to v3. Include
> also fixes discussed in the thread.
>
> - UP
On 2020-10-20 13:41:37 [+0200], Peter Zijlstra wrote:
> Right, but this patch set doesn't include the lazy preemption stuff, and
> given the 'fun' Valentin and me are still having with it, I'd like to
> keep it like that.
>
> But yes, that might warrant a slightly less NOP implementation.
Uh.
On 2020-10-20 13:30:09 [+0200], Peter Zijlstra wrote:
> On Mon, Oct 19, 2020 at 05:09:35PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2020-10-19 12:21:06 [+0200], Christian Eggers wrote:
> > > I have problems with the latest 5.9-rt releases on i.MX6ULL (!CONFIG_SMP):
>
jlstra (Intel)
> Tested-by: Mikhail Gavrilov
We have the same patch in RT. I didn't submit it with the other
local-lock patches because this splat pops up once pin_tag() is made a
sleeping lock. I missed the part where migrate_read_lock() can be a
lock. So:
Acked-by: Sebastian Andrzej Siewior
Sebastian
On 2020-10-19 12:21:06 [+0200], Christian Eggers wrote:
> I have problems with the latest 5.9-rt releases on i.MX6ULL (!CONFIG_SMP):
>
…
> Any hints?
Thank you for the report. The reason is the migrate_disable()
implementation for !SMP.
> Best regards
> Christian
Sebastian
Dear RT folks!
I'm pleased to announce the v5.9-rt16 patch set.
Changes since v5.9-rt15:
- The rtmutex rework resulted in "unused variable" warnings if built
without lockdep. Reported by Mike Galbraith.
- The softirq rework led to a warning which could be triggered by the
`ss'
On 2020-10-14 12:34:25 [-0400], Alan Stern wrote:
> On Wed, Oct 14, 2020 at 06:27:14PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2020-10-14 12:14:33 [-0400], Alan Stern wrote:
> > > Instead, consider using the new usb_control_msg_recv() API. But it
> > >
On 2020-10-14 12:27:21 [-0400], Alan Stern wrote:
> > --- a/drivers/usb/core/hcd.c
> > +++ b/drivers/usb/core/hcd.c
> > @@ -746,9 +746,6 @@ static int rh_call_control (struct usb_h
> > * Root Hub interrupt transfers are polled using a timer if the
> > * driver requests it; otherwise the driver
On 2020-10-14 12:14:33 [-0400], Alan Stern wrote:
> Instead, consider using the new usb_control_msg_recv() API. But it
> might be better to allocate the buffer once and for all.
This will still allocate and free buffer on each invocation. What about
moving the query_buf to the begin of the
On 2020-10-13 05:00:18 [+0200], Mike Galbraith wrote:
> Well, I do have a gripe from 5.6-rt, which I just took a moment to
> confirm in virgin source, but that kernel is probably EOL.
Yes. But I you patch for v5.9 so this should also work on v5.6.
Sebastian
On 2020-10-13 15:01:15 [+0100], Valentin Schneider wrote:
> migrate_disable();
> set_cpus_allowed_ptr(current, {something excluding task_cpu(current)});
> affine_move_task(); <-- never returns
>
> Signed-off-by: Valentin Schneider
> ---
> kernel/sched/core.c | 5 +
> 1 file changed, 5
() conditionally acquires listening_hash->lock.
Signed-off-by: Sebastian Andrzej Siewior
---
net/ipv4/inet_hashtables.c | 19 ---
net/ipv6/inet6_hashtables.c | 5 +
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet
On 2020-10-10 16:45:54 [-0500], Clark Williams wrote:
> This patch is against v5.9-rc8-rt14
>
> Fix a compile issue when CONFIG_PREEMPT_RT is not defined. If
> we're not on an RT kernel, just set the migration disabled
> status to zero.
Thank you. Let me fold it where it belongs. As of now, I
On 2020-10-11 22:32:38 [+0100], Russell King - ARM Linux admin wrote:
> I don't have a problem getting rid of the hex numbers in [< >]
> although then I will need to convert the symbol back to an address
> using the vmlinux to then calculate its address to then find the
> appropriate place in the
On 2020-10-12 10:14:42 [+0200], Eelco Chaudron wrote:
>
>
> On 9 Oct 2020, at 17:41, Sebastian Andrzej Siewior wrote:
>
> > On 2020-10-09 14:47:59 [+0200], Juri Lelli wrote:
> > > This happens because openvswitch/flow_table::flow_lookup() accesses
> > >
Dear RT folks!
I'm pleased to announce the v5.9-rc8-rt14 patch set.
Changes since v5.9-rc8-rt13:
- Replace current migrate disable patches with Peter Zijlstra's
migrate disable series. As part of the new implementation the manual
balancing of the migrate vs preemption counter has
Dear RT folks!
I'm pleased to announce the v5.9-rc8-rt13 patch set.
Changes since v5.9-rc8-rt12:
- Refurbish the rtmutex related patches:
- Remove unused code, struct members.
- Add a scheduling function to the scheduler which is invoked
instead of schedule() while blocking
On 2020-10-09 14:47:59 [+0200], Juri Lelli wrote:
> This happens because openvswitch/flow_table::flow_lookup() accesses
> per-cpu data while being preemptible (and migratable).
>
> Fix it by adding get/put_cpu_light(), so that, even if preempted, the
> task executing this code is not migrated
On 2020-10-09 09:08:50 [+0100], Russell King - ARM Linux admin wrote:
> I am really not happy about this - it hurts at least my ability to
> debug the kernel when people post oopses to the mailing list. If
> people wish to make the kernel harder to debug, and are prepared
> to be told "your kernel
On 2020-10-05 16:57:32 [+0200], Peter Zijlstra wrote:
> In order to minimize the interference of migrate_disable() on lower
> priority tasks, which can be deprived of runtime due to being stuck
> below a higher priority task. Teach the RT/DL balancers to push away
> these higher priority tasks
On 2020-10-08 12:45:30 [+0530], Maninder Singh wrote:
> Observed Stack Overflow on 8KB kernel stack on ARM specially
> incase on network interrupts, which results in undeterministic behaviour.
> So there is need for per cpu dedicated IRQ stack for ARM.
You could try to look where this stack
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 24a1877286822293684ef3f7bada4ea48a6e129e
Gitweb:
https://git.kernel.org/tip/24a1877286822293684ef3f7bada4ea48a6e129e
Author:Sebastian Andrzej Siewior
AuthorDate:Thu, 24 Sep 2020 17:48:51
On 2020-08-11 20:49:05 [+0200], To Stephen Berman wrote:
> On 2020-08-11 19:22:19 [+0200], Stephen Berman wrote:
> > Attached.
>
> ssdt6.dsl:
> | ThermalZone (TZ10)
> | {
> …
> | Method (_TSP, 0, Serialized) // _TSP: Thermal Sampling Period
> | {
> | Return (0x0A)
> | }
On 2020-10-06 16:37:21 [+0200], Daniel Wagner wrote:
> Hi Sebastian,
Hi Daniel,
> On 06.10.20 10:58, Sebastian Andrzej Siewior wrote:
> > Dear RT folks!
> >
> > I'm pleased to announce the v5.9-rc8-rt12 patch set.
>
> Just as heads up. I just tried to
n argument.
>
> Add a dummy argument to keep ctags quiet.
ping.
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> include/linux/seqlock.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
> index 96
Dear RT folks!
I'm pleased to announce the v5.9-rc8-rt12 patch set.
Changes since v5.9-rc8-rt11:
- The kernel test robot reported a few warnings due to the printk code
and a compile error in the powerpc architecture.
Known issues
- It has been pointed out that due to changes to the
On 2020-10-02 16:21:49 [+0200], Peter Zijlstra wrote:
> Yeah, I didn't want it in a header where world can access it and attempt
> creative use :/
tell me about it. Currently cleaning up other creative abuse of things…
Sebastian
On 2020-10-02 13:37:25 [+0200], Greg Kroah-Hartman wrote:
> > Is it possible to end up here in softirq context or is this a relic?
>
> I think it's a relic of where USB host controllers completed their urbs
> in hard-irq mode. The BH/tasklet change is a pretty recent change.
But the BH thingy
I was trying to get rid of the in in_softirq() in ezusb_req_ctx_wait()
within the orinoco usb driver,
drivers/net/wireless/intersil/orinoco/orinoco_usb.c. A small snippet:
| static void ezusb_req_ctx_wait(struct ezusb_priv *upriv,
|struct request_context *ctx)
…
|
er had the luck to be
successfully compiled. Let it finally find peace in byte heaven.
Reported-by: kernel test robot
Signed-off-by: Sebastian Andrzej Siewior
---
Repost of
https://lore.kernel.org/lkml/20200916081629.cfi6svr3yjvzi...@linutronix.de/
drivers/pcmcia/Kconfig |
On 2020-09-29 10:02:15 [+], Song Bao Hua (Barry Song) wrote:
> > My point was that there will be a warning at run-time and you don't want
> > that. There are raw_ accessors if you know what you are doing. But…
>
> I have only seen get_cpu_ptr/var() things will disable preemption. I don't
>
On 2020-09-29 05:14:31 [+], Song Bao Hua (Barry Song) wrote:
> After second thought and trying to make this change, I would like to change
> my mind
> and disagree with this idea. Two reasons:
> 1. while using this_cpu_ptr() without preemption lock, people usually put all
> things bound
>
On 2020-09-26 22:54:18 [-0400], Brad Harper wrote:
> ---
What happens if you boot this on a non-RT kernel with the `threadirqs'
command line option?
Sebastian
On 2020-08-19 00:31:00 [+1200], Barry Song wrote:
> diff --git a/mm/zswap.c b/mm/zswap.c
> index fbb782924ccc..00b5f14a7332 100644
> --- a/mm/zswap.c
> +++ b/mm/zswap.c
> @@ -127,9 +129,17 @@ module_param_named(same_filled_pages_enabled,
> zswap_same_filled_pages_enabled,
> * data structures
>
On 2020-09-21 18:35:57 [+0200], Peter Zijlstra wrote:
> Hi,
Hi,
> Here's my take on migrate_disable(). It avoids growing a second means of
I have here:
|005: numa_remove_cpu cpu 5 node 0: mask now 0,3-4,6-7
|007: smpboot: CPU 5 is now offline
|006: [ cut here ]
|006:
On 2020-09-21 18:36:04 [+0200], Peter Zijlstra wrote:
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1700,6 +1700,68 @@ void check_preempt_curr(struct rq *rq, s
>
> #ifdef CONFIG_SMP
>
> +#ifdef CONFIG_PREEMPT_RT
…
> +static inline bool is_migration_disabled(struct task_struct
On 2020-09-25 16:14:09 [+0200], Jerome Brunet wrote:
> Looks like we need to do manually what IRQF_ONESHOT was doing for us :(
IRQF_ONESHOT disables the IRQ at the irqchip level. You must ensure that
the device keeps quite. Usually you mast the interrupt source at the
device lee.
> This brings a
On 2020-09-25 11:11:42 [+0200], Jerome Brunet wrote:
> I'm not sure about this.
> As you have explained on IRC, I understand that IRQF_ONESHOT is causing
> trouble with RT as the hard IRQ part of the thread will not be migrated
> to a thread. That was certainly not the intent when putting this
Dear RT folks!
I'm pleased to announce the v5.9-rc6-rt9 patch set.
Changes since v5.9-rc6-rt8:
- Correct the tracing header output and labels. Patch by Thomas
Gleixner.
- Rework the softirq code. The semantic remains unchanged. Rework by
Thomas Gleixner.
Known issues
- It
ctags creates a warning:
|ctags: Warning: include/linux/seqlock.h:738: null expansion of name pattern
"\2"
The DEFINE_SEQLOCK() macro is passed to ctags and being told to expect
an argument.
Add a dummy argument to keep ctags quiet.
Signed-off-by: Sebastian Andrzej Siewior
---
inc
201 - 300 of 6306 matches
Mail list logo
