On Thu, 27 Oct 2022, Dave Hansen wrote:
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 67745ceab0db..b68661d0633b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -69,6 +69,7 @@ config X86
select ARCH_ENABLE_THP_MIGRATION if X86_64 && TRANSPARENT_HUGEPAGE
select
:
e2efb6359e62 ("ACPICA: Avoid cache flush inside virtual machines")
Signed-off-by: Davidlohr Bueso
---
Changes from v2
(https://lore.kernel.org/all/20220829212918.4039240-1-d...@stgolabs.net/):
- Change the names and params (Dan).
- GPL symbols (Boris).
- Mentioned VMM check in the
On Fri, 09 Sep 2022, Jonathan Cameron wrote:
On Thu, 8 Sep 2022 16:22:26 -0700
Dan Williams wrote:
Andrew Morton wrote:
> On Thu, 8 Sep 2022 15:51:50 -0700 Dan Williams
wrote:
>
> > Jonathan Cameron wrote:
> > > On Wed, 7 Sep 2022 18:07:31 -0700
> > > Dan Williams wrote:
> > >
> > > >
Not sure the proper way to route this (akpm?). But unless any remaining
objections, could this be picked up?
Thanks,
Davidlohr
On Wed, 07 Sep 2022, Borislav Petkov wrote:
On Mon, Aug 29, 2022 at 02:29:18PM -0700, Davidlohr Bueso wrote:
diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
index 1abd5438f126..18463cb704fb 100644
--- a/arch/x86/mm/pat/set_memory.c
+++ b/arch/x86/mm/pat/set_memory.c
On Wed, 07 Sep 2022, Dan Williams wrote:
Davidlohr Bueso wrote:
On Wed, 07 Sep 2022, Borislav Petkov wrote:
>On Mon, Aug 29, 2022 at 02:29:18PM -0700, Davidlohr Bueso wrote:
>> diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
>> index 1abd5438f126..1846
whether this
functionality is available on the architecture. Only enable it on x86-64
via the wbinvd() hammer.
Signed-off-by: Davidlohr Bueso
---
Changes from v2
(https://lore.kernel.org/all/20220819171024.1766857-1-d...@stgolabs.net/):
- Redid to use memregion based interfaces + VMM check on x86 (Dan
On Mon, 22 Aug 2022, Dan Williams wrote:
Davidlohr Bueso wrote:
On Sun, 21 Aug 2022, Christoph Hellwig wrote:
>On Fri, Aug 19, 2022 at 10:10:24AM -0700, Davidlohr Bueso wrote:
>> index b192d917a6d0..ac4d4fd4e508 100644
>> --- a/arch/x86/include/asm/cacheflush.h
>> +++ b
On Sun, 21 Aug 2022, Christoph Hellwig wrote:
On Fri, Aug 19, 2022 at 10:10:24AM -0700, Davidlohr Bueso wrote:
index b192d917a6d0..ac4d4fd4e508 100644
--- a/arch/x86/include/asm/cacheflush.h
+++ b/arch/x86/include/asm/cacheflush.h
@@ -10,4 +10,8 @@
void clflush_cache_range(void *addr
On Fri, 19 Aug 2022, Ira Weiny wrote:
Did you mean "must"?
Yep.
+ * such as those which caches are in a consistent state. The
+ * caller can verify the situation early on.
+ */
+#ifndef flush_all_caches
+# define flush_all_caches_capable() false
+static inline void flush_all_caches(void)
+{
-by: Davidlohr Bueso
---
Changes from v1
(https://lore.kernel.org/all/20220815160706.tqd42dv24tgb7x7y@offworld/):
- Added comments and improved changelog to reflect this is
routine should be avoided and not considered a general API (Peter, Dan).
arch/x86/include/asm/cacheflush.h | 4 +++
drivers/acpi
On Tue, 16 Aug 2022, Dan Williams wrote:
On Tue, Aug 16, 2022 at 10:30 AM Davidlohr Bueso wrote:
On Tue, 16 Aug 2022, Dan Williams wrote:
>Peter Zijlstra wrote:
>> On Mon, Aug 15, 2022 at 09:07:06AM -0700, Davidlohr Bueso wrote:
>> > diff --git a/arch/x86/include/asm/ca
On Tue, 16 Aug 2022, Dan Williams wrote:
Peter Zijlstra wrote:
On Mon, Aug 15, 2022 at 09:07:06AM -0700, Davidlohr Bueso wrote:
> diff --git a/arch/x86/include/asm/cacheflush.h
b/arch/x86/include/asm/cacheflush.h
> index b192d917a6d0..ce2ec9556093 100644
> --- a/arch/x86/in
security
related, and therefore become less important.
Signed-off-by: Davidlohr Bueso
---
After a few iterations I circled back to an interface without granularity.
It just doesn't make sense right now to define a range if arm64 will not
support this (won't do VA-based physical address space
nd elegant :)
Some nit comments below, but I agree with the idea, with the observation
that the search will always do the worst case amount of logN loops, even
when the retval is found (in which normal implementations would just
break out of the looping).
Acked-by: Davidlohr Bueso
Signed-off-b
On Mon, 05 Apr 2021, Andrew Morton wrote:
Tricky. 339ddb53d373 was merged in December 2019. So do we backport
this fix? Could any userspace code be depending upon the
post-339ddb53d373 behavior?
As with previous trouble caused by this commit, I vote for restoring the
behavior
backporting
() such that the next thread
can be awoken, in a cascading style, after the waker's corresponding
ep_send_events().
Signed-off-by: Davidlohr Bueso
---
fs/eventpoll.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 73138ea68342..1e596e1d0bba 100644
--- a/fs
-by: Davidlohr Bueso
---
.../filesystems/epoll/epoll_wakeup_test.c | 44 +++
1 file changed, 44 insertions(+)
diff --git a/tools/testing/selftests/filesystems/epoll/epoll_wakeup_test.c
b/tools/testing/selftests/filesystems/epoll/epoll_wakeup_test.c
index ad7fabd575f9
/epoll: remove unnecessary wakeups of nested epoll), which
has had various problems in the past, beyond only nested epoll usage.
Thanks!
Davidlohr Bueso (2):
kselftest: introduce new epoll test case
fs/epoll: restore waking from ep_done_scan()
fs/eventpoll.c| 6
It's a lot more intuitive to have it in the locking section of the kernel
hacking part rather than under "General architecture-dependent options".
Signed-off-by: Davidlohr Bueso
---
arch/Kconfig | 9 -
lib/Kconfig.debug | 9 +
2 files changed, 9 insertions(+), 9
The following commit has been merged into the locking/core branch of tip:
Commit-ID: bd9a5fc2edb0bdcb0756298daa31ddd6a02f0634
Gitweb:
https://git.kernel.org/tip/bd9a5fc2edb0bdcb0756298daa31ddd6a02f0634
Author:Davidlohr Bueso
AuthorDate:Fri, 22 Jan 2021 09:11:01 -08:00
website now shows a
mere Godaddy parking add.
Suggested-by: Christoph Hellwig
Signed-off-by: Davidlohr Bueso
---
arch/mips/configs/malta_defconfig |1 -
arch/mips/configs/malta_kvm_defconfig |1 -
arch/mips/configs/maltaup_xpa_defconfig |1 -
drivers/block/Kconfig
-by: Davidlohr Bueso
---
arch/mips/configs/malta_defconfig |1 -
arch/mips/configs/malta_kvm_defconfig |1 -
arch/mips/configs/maltaup_xpa_defconfig |1 -
drivers/block/Kconfig | 17 -
drivers/block/Makefile |1 -
drivers/block/umem.c
On Tue, 23 Mar 2021, Jens Axboe wrote:
Me too, I'd be surprised if anyone has used it in... forever. We can
probably drop it - I really dislike making core changes to something
that can't even be tested. Davidlohr, assuming you had no way of
testing this change?
No, no way of testing these
instead and deal with the async
processing in task context.
Signed-off-by: Davidlohr Bueso
---
drivers/block/umem.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/block/umem.c b/drivers/block/umem.c
index 982732dbe82e..6b0a110f9233 100644
Hi,
On Mon, 09 Nov 2020, Michal Simek wrote:
Sysace IP is no longer used on Xilinx PowerPC 405/440 and Microblaze
systems. The driver is not regularly tested and very likely not working for
quite a long time that's why remove it.
Is there a reason this patch was never merged? can the driver
-by: Nicholas Piggin
Signed-off-by: Davidlohr Bueso
---
Changes from v1:
Added small description and labeling smp_cond_load_relaxed requested by Nick.
Added Nick's ack.
arch/powerpc/include/asm/barrier.h | 16
arch/powerpc/include/asm/qspinlock.h | 7 +++
2 files changed, 7
On Tue, 16 Mar 2021, Nicholas Piggin wrote:
One request, could you add a comment in place that references
smp_cond_load_relaxed() so this commit can be found again if
someone looks at it? Something like this
/*
* smp_cond_load_relaxed was found to have performance problems if
* implemented
On Tue, 16 Mar 2021, Waiman Long wrote:
The ww_acquire_ctx structure for ww_mutex needs to persist for a complete
lock/unlock cycle. In the ww_mutex test in locktorture, however, both
ww_acquire_init() and ww_acquire_fini() are called within the lock
function only. This causes a lockdep splat
ve splat,
treat ww_mutex_lock() like a trylock().
After applying this patch, the locktorture test can run for a long time
without triggering the circular locking dependency splat.
Signed-off-by: Waiman Long
Acked-by Davidlohr Bueso
d at all if !use_ww_ctx. Simplify
ww_mutex code by dropping use_ww_ctx from mutex_optimistic_spin() an
clear ww_ctx if !use_ww_ctx. In this way, we can replace (use_ww_ctx &&
ww_ctx) by just (ww_ctx).
Signed-off-by: Waiman Long
Acked-by: Davidlohr Bueso
---
kernel/lock
On Tue, 16 Mar 2021, Peter Zijlstra wrote:
IIRC we made the explicit choice to never loop here. That saves having
to worry about getting stuck in in-kernel loops.
Userspace triggering the case where the futex goes corrupt is UB, after
that we have no obligation for anything to still work. It's
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 3a0ade0c521a542f8a25e96ce8ea0dfaa532ac75
Gitweb:
https://git.kernel.org/tip/3a0ade0c521a542f8a25e96ce8ea0dfaa532ac75
Author:Davidlohr Bueso
AuthorDate:Sat, 06 Mar 2021 13:36:58 -08:00
On Mon, 15 Mar 2021, Peter Zijlstra wrote:
Or am I reading this wrong?
No, I read it wrong. Please ignore this patch, there are rather a few
cases that do this trickery.
Thanks,
Davidlohr
Hi,
Some unrelated fixlets found via code inspection. Please consider for v5.13.
Thanks!
Davidlohr Bueso (2):
futex: Fix irq mismatch in exit_pi_state_list()
futex: Leave the pi lock stealer in a consistent state upon successful
fault
kernel/futex.c | 18 ++
1 file
xtraordinary scenario.
For the cases of a normal fixups, this does add some unnecessary overhead
by having to deal with userspace value when things are already ok, but
this case is pretty rare and we've already given up any inch of performance
when releasing all locks, for faulting/blocking.
Signed-of
The pi_mutex->wait_lock is irq safe and needs to enable local
interrupts upon unlocking, matching it's corresponding
raw_spin_lock_irq().
Fixes: c74aef2d06a9f (futex: Fix pi_state->owner serialization)
Signed-off-by: Davidlohr Bueso
---
kernel/futex.c | 2 +-
1 file changed, 1 insertion
The following commit has been merged into the locking/core branch of tip:
Commit-ID: a1565aa4699847febfdfd6af3bf06ca17a9e16af
Gitweb:
https://git.kernel.org/tip/a1565aa4699847febfdfd6af3bf06ca17a9e16af
Author:Davidlohr Bueso
AuthorDate:Fri, 26 Feb 2021 09:50:27 -08:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: a3f2428d2b9c9ca70f52818774a2f6e0e30a0f0b
Gitweb:
https://git.kernel.org/tip/a3f2428d2b9c9ca70f52818774a2f6e0e30a0f0b
Author:Davidlohr Bueso
AuthorDate:Fri, 26 Feb 2021 09:50:28 -08:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 9a4b99fce659c03699f1cb5003ebe7c57c084d49
Gitweb:
https://git.kernel.org/tip/9a4b99fce659c03699f1cb5003ebe7c57c084d49
Author:Davidlohr Bueso
AuthorDate:Fri, 26 Feb 2021 09:50:26 -08:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: c2e4bfe0eef313eeb1c4c9d921be7a9d91d5d71a
Gitweb:
https://git.kernel.org/tip/c2e4bfe0eef313eeb1c4c9d921be7a9d91d5d71a
Author:Davidlohr Bueso
AuthorDate:Fri, 26 Feb 2021 09:50:29 -08:00
On Tue, 09 Mar 2021, Michal Such�nek wrote:
On Mon, Mar 08, 2021 at 05:59:50PM -0800, Davidlohr Bueso wrote:
49a7d46a06c3 (powerpc: Implement smp_cond_load_relaxed()) added
busy-waiting pausing with a preferred SMT priority pattern, lowering
the priority (reducing decode cycles) during
contention on the main
qdisc lock. So any races against spin_is_locked() for archs that
use LL/SC for spin_lock() will be benign and not break any mutual
exclusion; furthermore, both the seqlock and busylock have the same
scope.
Cc: parri.and...@gmail.com
Cc: pab...@redhat.com
Signed-off-by: Davidlohr
win.
Thanks!
Davidlohr Bueso (3):
powerpc/spinlock: Define smp_mb__after_spinlock only once
powerpc/spinlock: Unserialize spin_is_locked
powerpc/qspinlock: Use generic smp_cond_load_relaxed
arch/powerpc/include/asm/barrier.h | 16
arch/powerpc/include/asm/qspinlock.h
Instead of both queued and simple spinlocks doing it. Move
it into the arch's spinlock.h.
Signed-off-by: Davidlohr Bueso
---
arch/powerpc/include/asm/qspinlock.h | 2 --
arch/powerpc/include/asm/simple_spinlock.h | 3 ---
arch/powerpc/include/asm/spinlock.h| 3 +++
3 files changed
( 0.00%)15243.14 * 1.48%*
Hmean 51214891.27 ( 0.00%)15162.11 * 1.82%*
Measuring the dbench4 Per-VFS Operation latency, shows some very minor
differences within the noise level, around the 0-1% ranges.
Signed-off-by: Davidlohr Bueso
---
arch/powerpc/include/asm/barrier.h
Ever since RCU was converted to softirq, it has no users.
Signed-off-by: Davidlohr Bueso
---
include/linux/interrupt.h | 1 -
kernel/softirq.c | 32
2 files changed, 33 deletions(-)
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
ant, but that should't really matter.
Signed-off-by: Davidlohr Bueso
---
kernel/futex.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index db8002dbca7a..ee09995d707b 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -3241,15 +3241
gracefully in
remove_waiter())
So instead of keeping the call around, just use the good ole
rt_mutex_top_waiter().
This patch implies no change in semantics.
Signed-off-by: Davidlohr Bueso
---
kernel/futex.c | 7 +--
kernel/locking/rtmutex.c| 20
kern
This seems to belong in the serialization and lifetime rules section.
pi_state_update_owner() will take the pi_mutex's owner's pi_lock to
do whatever fixup, successful or not.
Signed-off-by: Davidlohr Bueso
---
kernel/futex.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/futex.c b
This improves the code readability, and the locking more obvious
as it becomes symmetric for the caller.
Signed-off-by: Davidlohr Bueso
---
kernel/futex.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index ee09995d707b
-by: Davidlohr Bueso
Signed-off-by: Daniel Thompson
---
Notes:
During this cycle two developers have proposed tidying up the
DECLARE_TASKLET_OLD() in the debug core. Both threads ended with a
suggestion to remove kgdb_schedule_breakpoint() but I don't recall
seeing a follow up patch
On Mon, 25 Jan 2021, Peter Zijlstra wrote:
Reduce rbtree boilerplate by using the new helpers.
This reminds me of:
https://lore.kernel.org/lkml/20200207180305.11092-6-d...@stgolabs.net/
Would a walk optimization (list+rbtree) serve here? Not sure how big
the uprobes_trees gets.
Thanks,
proposing to stick them in tip and get on with life. What say you?
I like consolidating this code with helpers, reduces LoC and improves
readability imo. Feel free to add my:
Acked-by: Davidlohr Bueso
es I/O requests states to COMPLETE and notifies the
hypervisor of the completion via hypercalls.
Signed-off-by: Shuo Liu
Reviewed-by: Zhi Wang
Reviewed-by: Reinette Chatre
Cc: Zhi Wang
Cc: Zhenyu Wang
Cc: Yu Wang
Cc: Reinette Chatre
Cc: Greg Kroah-Hartman
Cc: Davidlohr Bueso
Thanks
I'm volunteering to help review some of the pain.
Signed-off-by: Davidlohr Bueso
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3978e8b21fc4..6f204358908b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7333,6 +7333,7 @@ M:Thomas
As the comment in usb_disconnect() hints, do not defer the
disconnect processing, and instead just do it directly in
the irq handler. This allows the driver to avoid using a
nowadays deprecated tasklet.
Signed-off-by: Davidlohr Bueso
---
drivers/usb/gadget/udc/snps_udc_core.c | 30
Update old comments as of 8b4c62aef6f (usb: gadget: u_serial: process RX
in workqueue instead of tasklet).
Signed-off-by: Davidlohr Bueso
---
drivers/usb/gadget/function/u_serial.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/function/u_serial.c
b
further
concurrency - tasklets being serialized among themselves, but this
is done holding the port_lock, so it should be fine.
Signed-off-by: Davidlohr Bueso
---
drivers/usb/host/xhci-dbgcap.h | 2 +-
drivers/usb/host/xhci-dbgtty.c | 19 +++
2 files changed, 12 insertions(+), 9
On Thu, 14 Jan 2021, Jassi Brar wrote:
On Thu, Jan 14, 2021 at 6:21 PM Davidlohr Bueso wrote:
Tasklets have long been deprecated as being too heavy on the system
by running in irq context - and this is not a performance critical
path. If a higher priority process wants to run, it must wait
instead and deal with the signaled
pipes in task context.
Signed-off-by: Davidlohr Bueso
---
drivers/platform/goldfish/goldfish_pipe.c | 28 +--
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform
and do the
async work in process context.
Signed-off-by: Davidlohr Bueso
---
drivers/mailbox/bcm-pdc-mailbox.c | 23 +++
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/drivers/mailbox/bcm-pdc-mailbox.c
b/drivers/mailbox/bcm-pdc-mailbox.c
index 5b375985f7b8
This was removed long ago, back in:
6e16d9409e1 ([PARISC] Convert soft power switch driver to kthread)
Signed-off-by: Davidlohr Bueso
---
arch/parisc/include/asm/irq.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/parisc/include/asm/irq.h b/arch/parisc/include/asm/irq.h
index
process wants to run, it must
wait for the tasklet to finish before doing so. Instead, generate
the breakpoint exception in process context.
Signed-off-by: Davidlohr Bueso
---
Compile-tested only.
kernel/debug/debug_core.c | 16
1 file changed, 8 insertions(+), 8 deletions
This was replaced with a kauditd_wait kthread long ago,
back in:
b7d1125817c (AUDIT: Send netlink messages from a separate kernel thread)
Update the stale comment.
Signed-off-by: Davidlohr Bueso
---
kernel/audit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel
further
concurrency (tasklets being serialized among themselves), but this
is done holding the c67x00->lock, so it should be fine. Furthermore,
this patch fixes the usage of the lock in the callback as otherwise
it would need to be irq-safe.
Signed-off-by: Davidlohr Bueso
---
Changes from
On Tue, 12 Jan 2021, Shuo A Liu wrote:
On Mon 11.Jan'21 at 13:52:19 -0800, Davidlohr Bueso wrote:
Could this not be done in process context instead?
It could be. The original consideration with tasklet was more about
performance as the I/O requests dispatching is a hot code path. I think
irq
On Wed, 06 Jan 2021, shuo.a@intel.com wrote:
The processing flow of I/O requests are listed as following:
a) The I/O handler of the hypervisor will fill an I/O request with
PENDING state when a trapped I/O access happens in a User VM.
b) The hypervisor makes an upcall, which is a
On Mon, 11 Jan 2021, Hillf Danton wrote:
On Sun, 10 Jan 2021 20:40:50 -0800 Davidlohr Bueso wrote:
Tasklets have long been deprecated as being too heavy on the system
by running in irq context - and this is not a performance critical
path. If a higher priority process wants to run, it must
further
concurrency (tasklets being serialized among themselves), but this
is done holding the c67x00->lock, so it should be fine. Furthermore,
this patch fixes the usage of the lock in the callback as otherwise
it would need to be irq-safe.
Signed-off-by: Davidlohr Bueso
---
drivers/usb/c67
Iwai
Signed-off-by: Davidlohr Bueso
---
drivers/usb/gadget/function/f_midi.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/function/f_midi.c
b/drivers/usb/gadget/function/f_midi.c
index 8fff995b8dd5..71a1a26e85c7 100644
--- a/drivers/usb/gadget
On Tue, 08 Dec 2020, Peter Zijlstra wrote:
I suppose I'll queue the below into tip/perf/core for next merge window,
unless you want it in a hurry?
I'm thinking we'd still want Eric's series on top of this for the reader
benefits of the lock.
Thanks,
Davidlohr
er optimistic spinning for now. As readers
are not going to do optimistic spinning anymore, we don't need to
consider if the OSQ is empty or not when doing lock stealing.
Signed-off-by: Waiman Long
Reviewed-by: Davidlohr Bueso
is in the count already. If it is
the first reader in this state, it will try to wake up other readers
in the wait queue.
Signed-off-by: Waiman Long
Reviewed-by: Davidlohr Bueso
On Thu, 03 Dec 2020, Bueso wrote:
On Mon, 16 Apr 2018, Sebastian Andrzej Siewior wrote:
On 2018-03-08 10:57:39 [+0100], To Mauro Carvalho Chehab wrote:
On 2018-02-27 14:39:34 [-0300], Mauro Carvalho Chehab wrote:
Hi Sebastian,
Hi Mauro,
Sorry for taking some time to test it, has been
On Fri, 04 Dec 2020, Linus Torvalds wrote:
On Fri, Dec 4, 2020 at 12:30 PM Bernd Edlinger
wrote:
>perf_event_open (exec_update_mutex -> ovl_i_mutex)
Side note: this one looks like it should be easy to fix.
Is there any real reason why exec_update_mutex is actually gotten that
early,
On Mon, 16 Apr 2018, Sebastian Andrzej Siewior wrote:
On 2018-03-08 10:57:39 [+0100], To Mauro Carvalho Chehab wrote:
On 2018-02-27 14:39:34 [-0300], Mauro Carvalho Chehab wrote:
> Hi Sebastian,
Hi Mauro,
> Sorry for taking some time to test it, has been busy those days...
:)
> Anyway, I
to the deadlock.
Acked-by: Davidlohr Bueso
ping
On Sun, 01 Nov 2020, Davidlohr Bueso wrote:
Use the mutex api instead of renaming the calls for this
driver.
Signed-off-by: Davidlohr Bueso
---
This was found while auditing mutex semantics in drivers.
drivers/media/common/siano/smscoreapi.c | 42
drivers/media
On Fri, 20 Nov 2020, David Laight wrote:
I got massive performance improvements from changing a driver
we have to use mutex instead of the old semaphores (the driver
was written a long time ago).
While these weren't 'rw' the same issue will apply.
The problem was that the semaphore/mutex was
, potentially blocking a higher
priority task from running.
Signed-off-by: Davidlohr Bueso
---
drivers/usb/serial/mos7720.c | 234 ++-
1 file changed, 35 insertions(+), 199 deletions(-)
diff --git a/drivers/usb/serial/mos7720.c b/drivers/usb/serial/mos7720.c
index
On Tue, 17 Nov 2020, Waiman Long wrote:
The column "CS Load" represents the number of pause instructions issued
in the locking critical section. A CS load of 1 is extremely short and
is not likey in real situations. A load of 20 (moderate) and 100 (long)
are more realistic.
It can be seen that
On Tue, 17 Nov 2020, Waiman Long wrote:
The rwsem wakeup logic has been modified by commit d3681e269fff
("locking/rwsem: Wake up almost all readers in wait queue") to wake up
all readers in the wait queue if the first waiter is a reader. In the
case of RWSEM_WAKE_READ_OWNED, not all readers can
, potentially blocking a higher
priority task from running. We also get rid of hacks
such as trylocking a mutex in irq, something which does
not play nice with priority boosting in PREEMPT_RT.
Signed-off-by: Davidlohr Bueso
---
Changes from v1: remove bogus irq comment.
drivers/usb/serial/mos7720.c | 234
On Mon, 16 Nov 2020, Johan Hovold wrote:
On Fri, Nov 13, 2020 at 08:27:25PM -0800, Davidlohr Bueso wrote:
@@ -1883,21 +1724,17 @@ static void mos7720_release(struct usb_serial *serial)
if (mos_parport->msg_pending)
wait_for_completion_timeout(_parp
, potentially blocking a higher
priority task from running. We also get rid of hacks
such as trylocking a mutex in irq, something which does
not play nice with priority boosting in PREEMPT_RT.
Signed-off-by: Davidlohr Bueso
---
drivers/usb/serial/mos7720.c | 235 ++-
1
Thanks for providing the fix and a testcase.
Reviewed-by: Davidlohr Bueso
On Mon, 09 Nov 2020, Oliver Neukum wrote:
Am Donnerstag, den 05.11.2020, 22:17 -0800 schrieb Davidlohr Bueso:
@@ -1888,16 +1732,8 @@ static void mos7720_release(struct usb_serial *serial)
usb_set_serial_data(serial, NULL);
mos_parport->serial = N
On Sat, 07 Nov 2020, Soheil Hassas Yeganeh wrote:
FWIW, I also stress-tested the patch series applied on top of
linux-next/master for a couple of hours.
Out of curiosity, what exactly did you use for testing?
Thanks,
Davidlohr
have.
Acked-by: Davidlohr Bueso
Cc: Davidlohr Bueso
Signed-off-by: Paul E. McKenney
---
kernel/locking/locktorture.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
index 62d215b..316531d 100644
--- a/kernel/locking/locktorture.c
+++ b/k
On Thu, 05 Nov 2020, Johan Hovold wrote:
On Wed, Nov 04, 2020 at 04:13:07PM -0800, Davidlohr Bueso wrote:
Also, but not strictly related to this. What do you think of deferring all
work in write_parport_reg_nonblock() unconditionally? I'd like to avoid
that mutex_trylock() because eventually
On Wed, 04 Nov 2020, Johan Hovold wrote:
Hmm. I took at closer look at the parport code and it seems the current
implementation is already racy but that removing the tasklet is going to
widen that that window.
Those register writes in restore() should be submitted before any
later requests.
On Mon, 02 Nov 2020, Bueso wrote:
There is
also no need anymore for atomic allocations.
Bleh this is a brain fart - obviously not true as usb_submit_urb() is
called under mos_parport->listlock. I'll send a v2 unless you have
any objections.
Thanks,
Davidlohr
the mutex normally. There is
also no need anymore for atomic allocations.
Signed-off-by: Davidlohr Bueso
---
Compile tested only.
drivers/usb/serial/mos7720.c | 38
1 file changed, 17 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/serial/mos7720.c b
Use the mutex api instead of renaming the calls for this
driver.
Signed-off-by: Davidlohr Bueso
---
This was found while auditing mutex semantics in drivers.
drivers/media/common/siano/smscoreapi.c | 42
drivers/media/common/siano/smscoreapi.h | 5 ---
drivers/media
ing).
Signed-off-by: Davidlohr Bueso
---
fs/dcache.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/dcache.c b/fs/dcache.c
index ea0485861d93..9177f0d08a5a 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -2504,8 +2504,8 @@ static inline unsigned start_dir_add(struct inode *
identical. It might be worth adding builder macros for these.
Agreed, all three could be nicely consolidated. Otherwise this series looks
sane, feel free to add my:
Acked-by: Davidlohr Bueso
The following commit has been merged into the timers/core branch of tip:
Commit-ID: 1a2b85f1e2a93a3f84243e654d225e4088735336
Gitweb:
https://git.kernel.org/tip/1a2b85f1e2a93a3f84243e654d225e4088735336
Author:Davidlohr Bueso
AuthorDate:Wed, 21 Oct 2020 12:07:49 -07:00
so models will
have a nop for smp_rmb/smp_acquire__after_ctrl_dep.
Signed-off-by: Davidlohr Bueso
---
Alternatively I guess we could just use cmpxchg_acquire().
fs/dcache.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/fs/dcache.c b/fs/dcache.c
index ea0
By doing so we can associate the sequence counter to the chunk_mutex
for lockdep purposes (compiled-out otherwise) and also avoid
explicitly disabling preemption around the write region as it will now
be done automatically by the seqcount machinery based on the lock type.
Signed-off-by: Davidlohr
1 - 100 of 4799 matches
Mail list logo
