ext, with the
blocking console lock always acquired.
Remove the "!in_interrupt()" check.
Signed-off-by: Ahmed S. Darwish
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/tty/vt/vt_ioctl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/tty/vt/vt_i
Folks,
a small series removing in_interrupt() usage within the tty layer.
Sebastian
ion if needed.
Cc: Miguel Ojeda Sandonis
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/auxdisplay/charlcd.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/auxdisplay/charlcd.c b/drivers/auxdisplay/charlcd.c
index f43430e9dceed..fbfce95919f72 100
Dear RT folks!
I'm pleased to announce the v5.10.12-rt26 patch set.
Changes since v5.10.12-rt25:
- Updated the "tracing: Merge irqflags + preempt counter." patch to
the version Steven posted for upstream inclusion.
- Update the work-in-progress softirq patch. One difference is that
b2a02fc43a1f4 ("smp: Optimize send_call_function_single_ipi()")
> Reported-by: Jens Axboe
> Signed-off-by: Sebastian Andrzej Siewior
A gentle ping.
This isn't just a requirement for the series: rps_trigger_softirq() is
invoked from smp_call_function_single_async() and raises a softirq.
Sebastian
On 2021-02-01 13:32:10 [-0500], Steven Rostedt wrote:
> Hi!
Hi,
> I'll let you know if your patches have any issues, but expect to seem a
> "for-next" post this week (if all goes well!).
Thanks for the update.
> -- Steve
Sebastian
On 2021-01-25 20:45:07 [+0100], To linux-kernel@vger.kernel.org wrote:
> The merge irqflags + preempt counter, v2.
>
> v1…v2:
> - Helper functions renamed.
> - Added patch #2 which inlines the helper functions.
>
a gentle ping.
Sebastian
Dear RT folks!
I'm pleased to announce the v5.11-rc5-rt3 patch set.
Changes since v5.11-rc5-rt2:
- Update the work-in-progress softirq patch. One difference is that
tasklet_disable() becomes now sleeping if the tasklet is running
instead busy-spinning until it is done. Driver which
On 2021-01-28 03:55:06 [-0300], Leonardo Bras wrote:
> Currently, during flush_smp_call_function_queue():
> - All items are transversed once, for inverting.
> - The SYNC items are transversed twice.
> - The ASYNC & IRQ_WORK items are transversed tree times.
> - The TTWU items are transversed four
On 2021-01-25 08:32:48 [+], Christoph Hellwig wrote:
> Well, I put it in quotes because I'm not sure what the exact effect
> is. But we do delay these completions to the softirq now instead of
> hardirq context, which at least in theory increases latency. OTOH it
> might even have positive
On 2021-01-25 08:25:42 [+], Christoph Hellwig wrote:
> On Mon, Jan 25, 2021 at 08:10:16AM +0100, Hannes Reinecke wrote:
> > I don't get this.
> > This code is about _avoiding_ having to raise a softirq if the driver
> > exports more than one hardware queue.
> > So where exactly does the remote
On 2021-01-26 10:59:32 [+], Russell King - ARM Linux admin wrote:
> On Tue, Jan 26, 2021 at 05:17:08PM +0800, Lecopzer Chen wrote:
> > Hi all,
> >
> > I don't see any fix for this issue now(maybe I missed it..?),
> > could we fix this if there is better solution?
> > This issue exists almost
On 2021-01-22 17:07:50 [-0500], Steven Rostedt wrote:
> On Wed, 13 Jan 2021 00:00:55 +0100
> Sebastian Andrzej Siewior wrote:
>
> > +unsigned int _tracing_gen_ctx_flags(unsigned long irqflags);
> > +unsigned int tracing_gen_ctx_flags(void);
> > +unsigned int trac
and remove the check.
Signed-off-by: Sebastian Andrzej Siewior
---
include/linux/trace_events.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index 67ae708de40d6..5d1eeac4bfbea 100644
--- a/include/linux/trace_even
-by: Sebastian Andrzej Siewior
---
include/linux/trace_events.h | 54 ++--
kernel/trace/trace.c | 38 ++---
kernel/trace/trace.h | 19 -
3 files changed, 53 insertions(+), 58 deletions(-)
diff --git a/include/linux
The merge irqflags + preempt counter, v2.
v1…v2:
- Helper functions renamed.
- Added patch #2 which inlines the helper functions.
Sebastian
d by using in_serving_softirq() on
!PREEMPT_RT is that gcc-10 implemented tracing_gen_ctx_flags() as
reading FLAG, jmp _tracing_gen_ctx_flags(). Without in_serving_softirq()
it inlined _tracing_gen_ctx_flags() into tracing_gen_ctx_flags().
Signed-off-by: Sebastian Andrzej Siewior
---
kernel/trace/t
639260 46693721 2c87d59 vmlinux.new
text shrank by 379 bytes, data remained constant.
Signed-off-by: Sebastian Andrzej Siewior
---
include/linux/trace_events.h | 25 +++-
kernel/trace/blktrace.c | 17 +--
kernel/trace/trace.c | 208 ++---
On 2021-01-25 14:03:23 [-0500], Steven Rostedt wrote:
>
> I was thinking about the inlining for two reasons. One was to consolidate
> the logic in the header file, as they are small functions. And two, inlined
> functions tend to be faster than non-inlined functions. Thus, I wasn't
> looking at
On 2021-01-25 08:30:12 [+], Christoph Hellwig wrote:
> > +static void blk_mq_complete_send_ipi(struct request *rq)
> > +{
> > + struct llist_head *list;
> > + unsigned int cpu;
> > +
> > + cpu = rq->mq_ctx->cpu;
> > + list = _cpu(blk_cpu_done, cpu);
> > + if (llist_add(>ipi_list,
this path in preemptible context.
Signed-off-by: Sebastian Andrzej Siewior
---
v1…v2: Move var initialisation to declaration in
blk_mq_complete_send_ipi(). Suggested by hch.
block/blk-mq.c | 95 +-
include/linux/blkdev.h | 2 +-
2 files
back to idle with
pending softirqs and the NOHZ will rightfully complain.
Process pending softirqs on return from flush_smp_call_function_queue().
Fixes: b2a02fc43a1f4 ("smp: Optimize send_call_function_single_ipi()")
Reported-by: Jens Axboe
Signed-off-by: Sebastian Andrzej Siewior
-
this path in preemptible context.
Signed-off-by: Sebastian Andrzej Siewior
---
block/blk-mq.c | 97 ++
include/linux/blkdev.h | 2 +-
2 files changed, 42 insertions(+), 57 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index
Patch 2+3 were applied and then dropped by Jens due to a NOHZ+softirq
related warning [0]. Turns out a successful wakeup via
set_nr_if_polling() will not process any softirqs and the CPU may go
back to idle. This is addressed by patch #1.
smpcfd_dying_cpu() will also invoke SMP-functions calls
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
On 2021-01-22 17:23:36 [+0100], Rafael J. Wysocki wrote:
>
> Well, it's been over a week since this was posted.
Thank you for this ;)
> Does anyone have any comments?
I looked over it and it makes sense, so
Reviewed-by: Sebastian Andrzej Siewior
I didn't comment on it since
On 2021-01-20 13:54:03 [-0800], Paul E. McKenney wrote:
> > > +// Record ptr in a page managed by krcp, with the pre-krc_this_cpu_lock()
> > > +// state specified by flags. If can_alloc is true, the caller must
> > > +// be schedulable and not be holding any locks or mutexes that might be
> > >
On 2021-01-21 13:38:34 [+0100], Uladzislau Rezki wrote:
> __get_free_page() returns "unsigned long" whereas a bnode is a pointer
> to kvfree_rcu_bulk_data struct, without a casting the compiler will
> emit a warning.
Yes, learned about it, sorry.
> >> You think that a CPU migration is a bad
Dear RT folks!
I'm pleased to announce the v5.11-rc4-rt1 patch set.
Changes since v5.10.8-rt24:
- Updated to v5.11-rc4
Known issues
- kdb/kgdb can easily deadlock.
- kmsg dumpers expecting not to be called in parallel can clobber
their temp buffer.
- netconsole
On 2021-01-20 17:21:46 [+0100], Uladzislau Rezki (Sony) wrote:
> For a single argument we can directly request a page from a caller
> context when a "carry page block" is run out of free spots. Instead
> of hitting a slow path we can request an extra page by demand and
> proceed with a fast path.
On 2021-01-20 17:21:48 [+0100], Uladzislau Rezki (Sony) wrote:
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -3489,10 +3489,12 @@ add_ptr_to_bulk_krc_lock(struct kfree_rcu_cpu **krcp,
> (*krcp)->bkvhead[idx]->nr_records ==
> KVFREE_BULK_MAX_ENTR) {
>
On 2021-01-20 15:27:08 [+0800], Jiapeng Zhong wrote:
> diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> index be4c0e6..c198222 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
Dear RT folks!
I'm pleased to announce the v5.10.8-rt24 patch set.
Changes since v5.10.8-rt23:
- Added RT's version of __down_read_interruptible() which is used by
stable tree since v5.10.6.
- Updated the "tracing: Merge irqflags + preempt counter." patch to
the latest version
On 2021-01-14 18:15:08 [+0100], Vitaly Wool wrote:
>
> Basically, yes. Minchan was very clear that he didn't want to remove
> that inter-function locking, so be it.
> I wouldn't really advise to use zsmalloc with zswap because zsmalloc
> has no support for reclaim, nevertheless I wouldn't like
On 2021-01-14 17:29:37 [+0100], Vitaly Wool wrote:
> On Thu, 14 Jan 2021, 17:18 Sebastian Andrzej Siewior,
> wrote:
> >
> > On 2020-12-23 19:25:02 [+0100], Vitaly Wool wrote:
> > > > write the following patch according to your idea, what do you think ?
> > &
On 2020-12-23 19:25:02 [+0100], Vitaly Wool wrote:
> > write the following patch according to your idea, what do you think ?
>
> Yep, that is basically what I was thinking of. Some nitpicks below:
Did this go somewhere? The thread just ends here on my end.
Mike, is this patch fixing / helping
On 2020-12-20 08:21:37 [+0100], Vitaly Wool wrote:
> Not really because bit spinlock leaves preemption disabled.
It leaves it disabled for a reason. Now you just spin until the original
context gets back on the CPU. On UP with preemption, if the "lock owner"
gets preempted, the next lock attempt
and remove the check.
Signed-off-by: Sebastian Andrzej Siewior
---
include/linux/trace_events.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index aa9123878e126..252dfcabda3c1 100644
--- a/include/linux/trace_even
639260 46693721 2c87d59 vmlinux.new
text shrank by 379 bytes, data remained constant.
Signed-off-by: Sebastian Andrzej Siewior
---
include/linux/trace_events.h | 25 +++-
kernel/trace/blktrace.c | 17 +--
kernel/trace/trace.c | 208 ++---
d by using in_serving_softirq() on
!PREEMPT_RT is that gcc-10 implemented tracing_gen_ctx_flags() as
reading FLAG, jmp _tracing_gen_ctx_flags(). Without in_serving_softirq()
it inlined _tracing_gen_ctx_flags() into tracing_gen_ctx_flags().
Signed-off-by: Sebastian Andrzej Siewior
---
kernel/trace/t
This is a follow-up to the RFC patch posted earlier.
It has been rebased on top of v5.11-rc3 and RT related bits are moved
into the second patch.
Sebastian
On 2021-01-11 18:04:36 [-0500], Steven Rostedt wrote:
> > The actual preemption value is not used except for the tracing record.
> > The `irqflags' is also not used except for the _irqsave() locking in a
> > few spots.
>
> Which spots?
Hmm. So I had memory of code sequences like
On 2021-01-09 01:33:52 [+0100], Thomas Bogendoerfer wrote:
> On Sat, Jan 09, 2021 at 12:58:05AM +0100, Thomas Bogendoerfer wrote:
> > On Fri, Jan 08, 2021 at 08:20:43PM +, Paul Cercueil wrote:
> > > Hi Thomas,
> > >
> > > 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this
Dear RT folks!
I'm pleased to announce the v5.10.4-rt22 patch set.
Changes since v5.10.4-rt21:
- Avoid "set but not used" warnings in the irq-off tracer.
- The local-lock patch for powerpc64/pseries/iommu didn't get update
and failed to compile.
- Powerpc64/pseries didn't compile
I just noticed that we have raw_spin_lock_bh() and it has a few users.
My guess is that the API should be removed and the existing user(s)
should be moved to spin_lock_bh() / spinlock_t instead.
On !RT it works as expected and there is no difference compared to
spinlock_t.
On RT it is kind of
Dear RT folks!
I'm pleased to announce the v5.10.1-rt20 patch set.
Changes since v5.10.1-rt19:
- Fix a compile failure in the trace branch profiler introduced in the
previous release. Reported by kernel test bot.
- Mike Galbraith reported errors in the z3fold code. Patches by Vitaly
Dear RT folks!
I'm pleased to announce the v5.10.1-rt19 patch set.
Changes since v5.10.1-rt18:
- The RCU related patches have been updated resulting in updated
documentation.
- The tracing infrastructure is able to recognize "serving softirq"
context with PREEMPT_RT enabled and
8 22148850 13996284 60446382 39a56ae vmlinux.new
data increased by 256 bytes, text shrank by 469 bytes.
Signed-off-by: Sebastian Andrzej Siewior
---
include/linux/trace_events.h | 27 +++-
include/trace/trace_events.h | 2 +-
kernel/trace/blktrace.c | 17 ++-
ke
On 2020-12-15 20:06:04 [+0800], Ming Lei wrote:
>
> [ 284.527619] BUG: sleeping function called from invalid context at
> kernel/locking/rtmutex.c:968
> [ 284.527626] in_atomic(): 1, irqs_disabled(): 0, pid: 6705, name: mandb
> [ 284.527631] 4 locks held by mandb/6705:
> [ 284.527634] #0:
On 2020-12-08 23:58:27 [+], Orivej Desh wrote:
> Greetings!
Hi,
> With sched-Add-migrate_disable.patch first released in v5.9-rc8-rt14 [1]
> linux-rt defines functions migrate_disable and migrate_enable.
> They are used in linux headers in various macros and static inline
> functions, and in
On 2020-12-11 16:41:05 [-0500], Steven Rostedt wrote:
> 5.4.82-rt46-rc1 stable review patch.
> If anyone has any objections, please let me know.
>
> --
>
> From: Sebastian Andrzej Siewior
>
> This change is no longer needed since commit
>
() also resets the sector size back to the default once it
> is done.
>
> Remove the conditional sector size update from sr_init_command() and
> sr_release() because it is not needed.
>
> Link: https://lkml.kernel.org/r/20201204164803.ovwurzs3257em...@linutronix.de
> Signe
Dear RT folks!
I'm pleased to announce the v5.10-rc7-rt16 patch set.
Changes since v5.10-rc7-rt15:
- Drop hrtimer-Allow-raw-wakeups-during-boot.patch. It is not needed
since another change came in.
- Assign timer_base::timer_running with base::lock held. Reported by
syzbot,
On 2020-12-11 15:36:27 [+0100], Thomas Gleixner wrote:
> So the change at hand does not make things worse, right?
Correct. This *ping*-*pong* was there before this patch because
->running_timer is always cleared after the callback finishes.
I was just curious why out of a sudden there are *that*
On 2020-12-09 11:05:45 [+0100], Peter Zijlstra wrote:
> In general we have the rule that as long as a lock is only ever used
> from task context (like the above ilb->lock, afaict) then it doesn't
> matter if you also take it with (soft)irqs disabled or not. But this
> softirq scheme breaks that.
On 2020-12-09 11:25:34 [+0100], Mike Galbraith wrote:
> Sebastian fixed this via...
We still look if we go that road or update lockdep.
Sebastian
On 2020-12-07 08:06:48 [-0800], Paul E. McKenney wrote:
> > Yes, but it triggers frequently. Like `rcuc' is somehow is aligned with
> > the timeout.
>
> Given that a lot of RCU processing is event-driven based on timers,
> and given that the scheduling-clock interrupts are synchronized for
>
On 2020-12-07 16:21:20 [+0100], Vitaly Wool wrote:
> On Mon, Dec 7, 2020 at 1:34 PM Mike Galbraith wrote:
> >
> > Unfortunately, that made zero difference.
>
> Okay, I suggest that you submit the patch that changes read_lock() to
> write_lock() in __release_z3fold_page() and I'll ack it then.
>
On 2020-12-07 16:22:07 [+0100], Thomas Gleixner wrote:
> On Mon, Dec 07 2020 at 15:00, Sebastian Andrzej Siewior wrote:
> > So we keep the RT part as-is and replace the non-RT bits with this?
>
> No. It would work for both.
So instead of boosting our way through we simply wait un
On 2020-12-07 15:29:50 [+0100], Thomas Gleixner wrote:
> On Mon, Dec 07 2020 at 14:07, Sebastian Andrzej Siewior wrote:
> > One thing I noticed while testing it is that the "corner" case in
> > timer_sync_wait_running() is quite reliably hit by rcu_pr
On 2020-12-07 12:47:43 [+0100], Peter Zijlstra wrote:
> On Fri, Dec 04, 2020 at 06:02:00PM +0100, Thomas Gleixner wrote:
> > @@ -825,7 +848,20 @@ void tasklet_kill(struct tasklet_struct
> >
> > while (test_and_set_bit(TASKLET_STATE_SCHED, >state)) {
> > do {
> > -
On 2020-12-06 22:40:07 [+0100], Thomas Gleixner wrote:
> syzbot reported KCSAN data races vs. timer_base::timer_running being set to
> NULL without holding base::lock in expire_timers().
>
> This looks innocent and most reads are clearly not problematic but for a
> non-RT kernel it's completely
On 2020-12-04 18:01:51 [+0100], Thomas Gleixner wrote:
> The RT variant has sucessfully been tested in the current 5.10-rt
> patches. For non-RT kernels there is no functional change.
this series is part of v5.10-rc6-rt14.
Tested-by: Sebastian Andrzej Siewior
> Thanks,
>
On 2020-11-19 18:06:24 [+0100], To linux-kernel@vger.kernel.org wrote:
> On 2020-11-13 22:34:08 [+0100], To linux-kernel@vger.kernel.org wrote:
> > This driver is the very definition of bitrotting:
> > - Introduced in commit
> > 79a140932c776 ("[PATCH] mips: vR41xx updates")
> > which is
Dear RT folks!
I'm pleased to announce the v5.10-rc6-rt14 patch set.
Changes since v5.10-rc6-rt13:
- Update Thomas Gleixner's softirq patches. This updated version has
been posted as v2.
This update also includes a handful patches by Frederic Weisbecker
which were required as a
nd
sr_release() because it is not needed.
Link: https://lkml.kernel.org/r/20201204164803.ovwurzs3257em...@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior
---
This change makes also ide-cd providing the last non-empty
cdrom_device_info::release callback.
drivers/scsi/sr.c | 17
left.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/scsi/sr_ioctl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/scsi/sr_ioctl.c b/drivers/scsi/sr_ioctl.c
index ffcf902da3901..5703f8400b73c 100644
--- a/drivers/scsi/sr_ioctl.c
+++ b/drivers/scsi/sr_ioctl.c
@@ -549,6 +549,8
...@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/cdrom/cdrom.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 0c271b9e3c5b7..8f0e52a714938 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
Before v2.1.62 sr_read_sector() did MODE_SELECT to set the requested sector
size,
issued READ_10 and then used MODE_SELECT to select a sector size of 2048 bytes.
This function was used to serve ioctl()'s command CDROMREADMODE2 and
CDROMREADRAW
which do not use 2048 bytes as sector size.
In
On 2020-12-03 09:18:21 [+0100], Mike Galbraith wrote:
> On Thu, 2020-12-03 at 03:16 +0100, Mike Galbraith wrote:
> > On Wed, 2020-12-02 at 23:08 +0100, Sebastian Andrzej Siewior wrote:
> > Looks like...
> >
> > d8f117abb380 z3fold: fix use-after-free when freein
On 2020-12-02 03:30:27 [+0100], Mike Galbraith wrote:
> > > In an LTP install, ./runltp -f mm. Shortly after box starts swapping
> > > insanely, it explodes quite reliably here with either z3fold or
> > > zsmalloc.. but not with zbud.
>
> What I'm seeing is the below. rt_mutex_has_waiters()
On 2020-10-26 18:20:59 [+0100], To Rafael J. Wysocki wrote:
> > > > > Done as Bug 208877.
> > > Rafael, do you have any suggestions?
> >
> > I've lost track of this sorry.
> >
> > I have ideas, let me get back to this next week.
>
> :)
Rafael, any update? If you outline an idea or so then I
inlock
held.
Use 0 in NCR5380_poll_politely2() delay argument if sleeping is not
possible. Otherwise pass the requested time out in jiffies.
For the mixed ones, trickle-down context from upper layers.
Signed-off-by: Ahmed S. Darwish
[bigeasy: remove the bool, make decision bas
On 2020-11-30 18:53:44 [+0100], To Thomas Gleixner wrote:
> 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
>like `crash' are used to extract the printk buffer from a
Dear RT folks!
I'm pleased to announce the v5.10-rc6-rt13 patch set.
Changes since v5.10-rc6-rt12:
- John's printk series was updated to his current status.
- The notifier lock has been made a raw_spinlock_t to avoid a
acquiring a sleeping lock in atomic context. Patch by Valentin
On 2020-11-30 17:27:17 [+0100], Mike Galbraith wrote:
> > This just passed. It however killed my git-gc task which wasn't done.
> > Let me try tomorrow with your config.
>
> FYI, I tried 5.9-rt (after fixing 5.9.11), it exploded in the same way,
> so (as expected) it's not some devel tree oopsie.
On 2020-11-30 16:01:11 [+0100], Mike Galbraith wrote:
> On Mon, 2020-11-30 at 15:52 +0100, Sebastian Andrzej Siewior wrote:
> > How do you test this? I triggered a few oom-killer and I have here git
> > gc running for a few hours now… Everything is fine.
>
> In an LTP in
On 2020-11-30 15:42:46 [+0100], Mike Galbraith wrote:
> This explodes in write_unlock() as mine did. Oleksandr's local_lock()
> variant explodes in the lock he added. (ew, corruption)
>
> I think I'll try a stable-rt tree. This master tree _should_ be fine
> given it seems to work just peachy
On 2020-11-30 14:53:22 [+0100], Oleksandr Natalenko wrote:
> > diff --git a/mm/zswap.c b/mm/zswap.c
> > index 78a20f7b00f2c..b24f761b9241c 100644
> > --- a/mm/zswap.c
> > +++ b/mm/zswap.c
> > @@ -394,7 +394,9 @@ struct zswap_comp {
> > u8 *dstmem;
> > };
> >
> > -static
On 2020-11-30 10:09:41 [+], Valentin Schneider wrote:
> FWIW, still squealing under v5.10-rc5-rt11.
I could apply this into my current RT but it would be nice to get this
applied upstream.
Sebastian
On 2020-11-29 12:41:14 [+0100], Mike Galbraith wrote:
> On Sun, 2020-11-29 at 12:29 +0100, Oleksandr Natalenko wrote:
> >
> > Ummm so do compressors explode under non-rt kernel in your tests as
> > well, or it is just -rt that triggers this?
>
> I only tested a non-rt kernel with z3fold, which
On 2020-11-28 15:36:51 [+0100], Oleksandr Natalenko wrote:
> Hi.
Hi,
> It seems that the v5.10-rc5-rt11 tag was not pushed:
Indeed. Just pushed it.
Sebastian
Dear RT folks!
I'm pleased to announce the v5.10-rc5-rt11 patch set.
Changes since v5.10-rc5-rt10:
- The workaround for the IMX clock driver failure has been replaced
with a another patch which was proposed upstream.
- Tweak the rtmutex patches to build a allnoconfig with RT enabled.
On 2020-11-25 00:46:32 [+], Matthew Wilcox wrote:
>
> Thanks for debugging this! I didn't realise start1 was allowed to be
> less than start2. Try this ... (systemd is sabotaging my efforts to
> test an i386 kernel)
You are welcome.
Reviewed-by: Sebastian Andrzej Siewior
Sebastian
On 2020-11-24 18:52:44 [+0530], Naresh Kamboju wrote:
> While running LTP test case access01 the following kernel BUG
> noticed on linux next 20201124 tag kernel on i386.
>
> git short log:
>
> git log --oneline next-20201120..next-20201124 -- mm/highmem.c
> d9927d46febf Merge
Dear RT folks!
I'm pleased to announce the v5.10-rc5-rt10 patch set.
Changes since v5.10-rc5-rt9:
- A patch from upstream addressing migrate disable related issue
reported by Oleksandr Natalenko. Patch by Peter Zijlstra.
- A patch from upstream addressing migrate disable related issue
On 2020-11-18 09:44:34 [-0500], Qian Cai wrote:
> On Tue, 2020-11-17 at 19:28 +, Valentin Schneider wrote:
> > We did have some breakage in that area, but all the holes I was aware of
> > have been plugged. What would help here is to see which tasks are still
> > queued on that outgoing CPU,
On 2020-11-20 14:35:35 [-0800], Andrew Morton wrote:
> On Fri, 20 Nov 2020 10:24:20 +0100 Sebastian Andrzej Siewior
> wrote:
>
> > falconide_get_lock() is called by ide_lock_host() and its caller
> > (ide_issue_rq()) has already a might_sleep() check.
> >
>
On 2020-11-17 13:45:03 [+0100], Peter Zijlstra wrote:
> On Tue, Nov 10, 2020 at 12:38:47PM +0100, Sebastian Andrzej Siewior wrote:
> > With enabled threaded interrupts the nouveau driver reported the
> > following:
> > | Chain exists of:
> > | >mma
On 2020-11-20 16:49:44 [-0500], Steven Rostedt wrote:
> On Thu, 12 Nov 2020 17:58:24 +0100
> Sebastian Andrzej Siewior wrote:
> > Changes since v5.10-rc3-rt6:
> >
> > - Mike Galbraith reported a lockdep warning triggered by the nouveau
> > driver with thre
lain about the
missuses.
Remove the BUG_ON() statements.
Cc: "David S. Miller"
Cc: linux-...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior
Acked-by: Jens Axboe
---
drivers/ide/ide-probe.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/ide/ide-probe.c b/drivers/i
Sebastian Andrzej Siewior
Acked-by: Jens Axboe
---
drivers/ide/falconide.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/ide/falconide.c b/drivers/ide/falconide.c
index dbeb2605e5f6e..77af4c1a3f38c 100644
--- a/drivers/ide/falconide.c
+++ b/drivers/ide/falconide.c
@@ -51,8 +51,6
In the discussion about preempt count consistency across kernel
configurations:
https://lore.kernel.org/r/20200914204209.256266...@linutronix.de/
it was concluded that the usage of in_interrupt() and related context
checks should be removed from non-core code.
This ide subsystem has two
On 2020-11-13 22:34:08 [+0100], To linux-kernel@vger.kernel.org wrote:
> This driver is the very definition of bitrotting:
> - Introduced in commit
> 79a140932c776 ("[PATCH] mips: vR41xx updates")
> which is 2.6.11-rc3.
>
> - Provides ->register_callback which was removed in commit
>
del_timer_sync().]
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
Cc: Greg Kroah-Hartman
Cc: Cliff Whickman
Cc: Arnd Bergmann
Cc: Robin Holt
Cc: Steve Wahl
Cc: Dimitri Sivanich
Cc: Russ Anderson
---
v1…v2: Use xpc_partition_disengaged_from_timer() and don't export
del_timer_sync().]
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
Cc: Greg Kroah-Hartman
Cc: Cliff Whickman
Cc: Arnd Bergmann
Cc: Robin Holt
Cc: Steve Wahl
Cc: Dimitri Sivanich
Cc: Russ Anderson
---
drivers/misc/sgi-xp/xpc.h | 2 +-
drivers/misc/sgi-xp
On 2020-11-15 05:52:33 [+0100], Mike Galbraith wrote:
> On Sat, 2020-11-14 at 13:24 -0600, Tom Zanussi wrote:
> > On Sat, 2020-11-14 at 20:00 +0100, Mike Galbraith wrote:
> >
> > > __raw_write_seqcount_end() is an integral part of write_sequnlock(),
> > > but we do seem to be missing a
does nothing.
Remove rio_get_asm() and rio_get_device() which have no callers now.
Cc: Matt Porter
Cc: Alexandre Bounine
Cc: Andrew Morton
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/rapidio/rio.c | 81 -
include/linux/rio_drv.h | 3 --
2 files c
The following commit has been merged into the timers/core branch of tip:
Commit-ID: c725dafc95f1b37027840aaeaa8b7e4e9cd20516
Gitweb:
https://git.kernel.org/tip/c725dafc95f1b37027840aaeaa8b7e4e9cd20516
Author:Sebastian Andrzej Siewior
AuthorDate:Tue, 03 Nov 2020 20:09:37
er had the luck to be
successfully compiled. Let it finally find peace in byte heaven.
Signed-off-by: Sebastian Andrzej Siewior
Cc: Dominik Brodowski
Cc: Andrew Morton
Cc: Yoichi Yuasa
Cc: Thomas Bogendoerfer
Cc: linux-m...@vger.kernel.org
---
This is a repost of
https://lkml.kernel
101 - 200 of 6306 matches
Mail list logo
