On 08/20/2018 11:50 AM, Matthew Wilcox wrote:
> On Mon, Aug 20, 2018 at 11:14:04AM -0400, Waiman Long wrote:
>> On 08/20/2018 11:06 AM, Matthew Wilcox wrote:
>>> Both spin locks and write locks currently do:
>>>
>>> f0 0f b1 17
On 12/12/2018 12:04 AM, Sergey Senozhatsky wrote:
> On (12/12/18 12:42), Sergey Senozhatsky wrote:
> [..]
> [ 87.255156]CPU0CPU1
> [ 87.255813]
> [ 87.256460] lock(&port_lock_key);
> [ 87.256973]
60] which lock already depends on the new lock.
This patch was also found to be able to fix a boot hanging problem
when the initramfs image was switched on after a debugobjects splat
from the EFI code.
Signed-off-by: Waiman Long
---
lib/debugobjects.c | 61 +--
CONFIG_LOCKDEP is on.
Signed-off-by: Waiman Long
---
mm/mmap.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 6c04292..62a5593 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2962,16 +2962,6 @@ int vm_munmap(unsigned long start, size_t len
On 12/12/2018 08:14 PM, Yang Shi wrote:
> Cc'ed Peter, Ingo and Waiman.
>
>
> It took me a few days to look into this warning, but I got lost in
> lockdep code.
>
>
> The problem is the commit dd2283f2605e ("mm: mmap: zap pages with read
> mmap_sem in munmap") does an optimization for munmap by dow
On 12/12/2018 09:03 PM, Sergey Senozhatsky wrote:
> On (12/12/18 17:28), Waiman Long wrote:
>> The db->lock is a raw spinlock and so the lock hold time is supposed
>> to be short. This will not be the case when printk() is being involved
>> in some of the critical section
n the new lock.
This patch was also found to be able to fix a boot hanging problem
when the initramfs image was switched on after a debugobjects splat
from the EFI code.
v2: Move debug_print_object() in check_results(), eliminate
debug_print_obj & modify URL.
Signed-off-by: Wai
On 12/12/2018 06:39 PM, Andrew Morton wrote:
> On Wed, 12 Dec 2018 17:28:14 -0500 Waiman Long wrote:
>
>> The db->lock is a raw spinlock and so the lock hold time is supposed
>> to be short. This will not be the case when printk() is being involved
>> in some of the cri
-debian
> Reported-by: kernel test robot
> Cc: Andrew Morton
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Sergey Senozhatsky
> Cc: Thomas Gleixner
> Cc: Waiman Long
> Signed-off-by: Dmitry Safonov
> ---
> lib/debugobjects.c | 89
On 12/12/2018 11:35 PM, Dmitry Safonov wrote:
> Hi Waiman,
>
> On 12/12/18 10:28 PM, Waiman Long wrote:
>> The db->lock is a raw spinlock and so the lock hold time is supposed
>> to be short. This will not be the case when printk() is being involved
>> in some of the
On 12/17/2018 01:17 PM, Ingo Molnar wrote:
> * Waiman Long wrote:
>
>> The db->lock is a raw spinlock and so the lock hold time is supposed to
>> be short. This will not be the case when printk() is being involved in
>> some of the critical sections.
>>
>> I
o be consistent with
"Cpus_allowed:".
With that change, the "Mems_allowed:" line becomes
Mems_allowed: f
Signed-off-by: Waiman Long
---
include/linux/nodemask.h | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/include/linux/nodemask.h b/include/linux/
On 12/18/2018 01:54 PM, Davidlohr Bueso wrote:
> Some users, specifically futexes and rwsems, required fixes
> that allowed the callers to be safe when wakeups occur before
> they are expected by wake_up_q(). Such scenarios also play
> games and rely on reference counting, and until now were
> pivo
ly by the wake_up_q() call
> in the
> + * same context, _HOWEVER_ this is not guaranteed, the wakeup can come
> + * instantly.
> + *
> + * This function must be used as-if it were wake_up_process(); IOW
> the task
> + * must be ready to be woken at this location.
> + *
> + * This function is essentially a task-safe equivalent to
> wake_q_add(). Callers
> + * that already hold reference to @task can call the 'safe' version
> and trust
> + * wake_q to do the right thing depending whether or not the @task is
> already
> + * queued for wakeup.
> + */
> +void wake_q_add_safe(struct wake_q_head *head, struct task_struct *task)
> +{
> + if (!__wake_q_add(head, task))
> + put_task_struct(task);
> }
>
> void wake_up_q(struct wake_q_head *head)
Acked-by: Waiman Long
pr_args() in the kernel.
Of them, only cpuset_task_status_allowed() in kernel/cgroup/cpuset.c
uses the "%*pb" format string that will be affected by this change. That
cpuset function is called by proc_pid_status() only.
Signed-off-by: Waiman Long
---
include/linux/nodemask.h | 7 +++-
On 12/18/2018 03:41 PM, Andrew Morton wrote:
> On Tue, 18 Dec 2018 12:30:31 -0500 Waiman Long wrote:
>
>> When viewing the /proc//status file, one can see output lines like
>>
>> Cpus_allowed: ,,
>> Cpus_allowe
r the TIF_SSBD
bit unless it has been force-disabled.
Signed-off-by: Waiman Long
---
Documentation/userspace-api/spec_ctrl.rst | 3 +++
arch/x86/kernel/process.c | 10 ++
2 files changed, 13 insertions(+)
diff --git a/Documentation/userspace-api/spec_ctrl.rst
b/Document
On 12/19/2018 02:38 PM, Andi Kleen wrote:
> On Wed, Dec 19, 2018 at 02:09:50PM -0500, Waiman Long wrote:
>> With the default SPEC_STORE_BYPASS_SECCOMP/SPEC_STORE_BYPASS_PRCTL mode,
>> the TIF_SSBD bit will be inherited when a new task is fork'ed or cloned.
>>
&
pr_args() in the kernel.
Of them, only cpuset_task_status_allowed() in kernel/cgroup/cpuset.c
uses the "%*pb" format string that will be affected by this change. That
cpuset function is called by proc_pid_status() only.
v3: Fix build problem with MAX_NUMNODES=1.
Signed-off-by: Waiman Lon
On 12/14/2018 01:06 PM, Dmitry Safonov wrote:
> On 12/13/18 10:10 PM, Waiman Long wrote:
>> The bucket lock is for protecting the insertion and deletion of
>> debug_obj to/from the bucket list as well as searching within the bucket
>> list. It has nothing to do with the life
ive per-cpu counter.
Various filesystem related tests were run and no statistically
significant changes in performance outside of the possible noise range
was observed.
Waiman Long (3):
fs/dcache: Fix incorrect nr_dentry_unused accounting in
shrink_dcache_sb()
fs: Don't need to put list_lr
nt to make the list_lru structures to sit in their
own cachelines.
Signed-off-by: Waiman Long
Reviewed-by: Dave Chinner
---
include/linux/fs.h | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index c95c080..7707c4a 100644
--- a/in
kernel.org
Signed-off-by: Waiman Long
Reviewed-by: Dave Chinner
---
fs/dcache.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/fs/dcache.c b/fs/dcache.c
index 2593153..44e5652 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1188,15 +1188,11 @@ static enum
ne of the dummy array entry for
negative dentry count.
Signed-off-by: Waiman Long
---
Documentation/sysctl/fs.txt | 26 --
fs/dcache.c | 32
include/linux/dcache.h | 7 ---
3 files changed, 52 insertions(+), 13
: Waiman Long
---
mm/page_alloc.c | 37 +
1 file changed, 29 insertions(+), 8 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 2ec9cc4..941161d 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -294,6 +294,32 @@ bool pm_suspended_storage(void
On 11/29/2018 06:18 AM, Dan Carpenter wrote:
> Hi Waiman,
>
> Thank you for the patch! Perhaps something to improve:
>
> url:
> https://github.com/0day-ci/linux/commits/Waiman-Long/cgroup-Introducing-bypass-mode/20181123-030552
> base: https://git.kernel.org/pub/sc
The newly added cgroup controller masks (subtree_bypass and
enable_ss_mask) are now being reported in the debug.masks controller
file.
Signed-off-by: Waiman Long
---
kernel/cgroup/debug.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/cgroup/debug.c b/kernel/cgroup/debug.c
index
hierarchy. This mode will also allow
more freedom in how each controller can shape its effective hierarchy
independent of the others.
Signed-off-by: Waiman Long
---
include/linux/cgroup-defs.h | 19 --
kernel/cgroup/cgroup.c | 151 ++--
2 fil
er name
with the '+' prefix to the "cgroup.controllers" file.
Patch 3 extends the debug controller to expose additional controller
masks introduced by this patchset.
Patch 4 makes the cpu controller bypassable.
Patch 5 documents the new bypass mode in cgroup-v2.rst file.
W
The cgroup-v2.rst file is updated to document the new bypass mode.
Signed-off-by: Waiman Long
---
Documentation/admin-guide/cgroup-v2.rst | 66 -
1 file changed, 48 insertions(+), 18 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v2.rst
b
Make the cpu cgroup controller bypassable in the default hierarchy so
that cpu controller could be activated only in those cgroups that really
need it instead of all the cgroups down to the lowest level that need it.
Signed-off-by: Waiman Long
---
kernel/sched/core.c | 1 +
1 file changed, 1
e.
This capability allows a cgroup parent to individually enable bypassable
controllers in a subset of its children instead of either all or none
of them. This increases the flexibility each controller has in shaping
the effective cgroup hierarchy to best suit its need.
Signed-off-by: Waiman Long
---
pr_args() in the kernel.
Of them, only cpuset_task_status_allowed() in kernel/cgroup/cpuset.c
uses the "%*pb" format string that will be affected by this change. That
cpuset function is called by proc_pid_status() only.
v4: Fix build problem with MAX_NUMNODES=1.
Signed-off-by: Waiman Long
On 12/17/2018 08:12 AM, Yongji Xie wrote:
> On Mon, 17 Dec 2018 at 19:37, Peter Zijlstra wrote:
>> On Mon, Dec 10, 2018 at 11:12:52PM +0800, Yongji Xie wrote:
>>> Hi Peter,
>>>
>>> Please let me know If there is any progress on this issue. Thank you!
>> Right, sorry, my brain was filled with snot
On 12/19/2018 02:09 PM, Waiman Long wrote:
> With the default SPEC_STORE_BYPASS_SECCOMP/SPEC_STORE_BYPASS_PRCTL mode,
> the TIF_SSBD bit will be inherited when a new task is fork'ed or cloned.
>
> As only certain class of applications (like Java) requires disabling
> speculat
the performance impact
by using a sysctl parameter to control the maximum frequency at which the
IRQ count computation can be done. The result is that the IRQ counts from
/proc/stat may be a bit stale, but still provide the needed information.
Waiman Long (2):
/proc/stat: Extract irqs counting code
The code that generates the "intr" line of /proc/stat is now moved
from show_stat() into a new function - show_stat_irqs(). There is no
functional change.
Signed-off-by: Waiman Long
---
fs/proc/stat.c | 39 +--
1 file changed, 29 insertions(+), 10
100 8.003s 4.882s
1000 8.000s 4.740s
Signed-off-by: Waiman Long
---
Documentation/sysctl/fs.txt | 16 +++
fs/proc/stat.c | 48 +
kernel/sysctl.c | 12
On 01/07/2019 10:31 AM, Peter Zijlstra wrote:
> On Mon, Jan 07, 2019 at 09:35:09AM -0500, Waiman Long wrote:
>> On 12/17/2018 08:12 AM, Yongji Xie wrote:
>>> On Mon, 17 Dec 2018 at 19:37, Peter Zijlstra wrote:
>>>> On Mon, Dec 10, 2018 at 11:12:52PM +0800, Yo
On 01/07/2019 10:58 AM, Matthew Wilcox wrote:
> On Mon, Jan 07, 2019 at 10:12:58AM -0500, Waiman Long wrote:
>> Reading /proc/stat can be slow especially if there are many irqs and on
>> systems with many CPUs as summation of all the percpu counts for each
>> of the irqs is re
On 01/07/2019 11:14 AM, Matthew Wilcox wrote:
> On Mon, Jan 07, 2019 at 11:07:47AM -0500, Waiman Long wrote:
>>> Why are you caching the _output_ of calling sprintf(), rather than caching
>>> the
>>> values of each interrupt?
>>>
>> It is just faster
On 01/07/2019 11:33 AM, Alexey Dobriyan wrote:
> On Mon, Jan 07, 2019 at 07:58:40AM -0800, Matthew Wilcox wrote:
>> On Mon, Jan 07, 2019 at 10:12:58AM -0500, Waiman Long wrote:
>>> A new "fs/proc-stat-irqs-latency-ms" sysctl parameter is now added to
>> No. N
On 01/07/2019 05:32 PM, Dave Chinner wrote:
> On Mon, Jan 07, 2019 at 10:12:56AM -0500, Waiman Long wrote:
>> As newer systems have more and more IRQs and CPUs available in their
>> system, the performance of reading /proc/stat frequently is getting
>> worse and worse.
> Be
lkp-boun...@lists.01.org] On Behalf Of Waiman Long
> Sent: Tuesday, November 6, 2018 6:40 AM
> To: Linus Torvalds ; vba...@suse.cz; Davidlohr
> Bueso
> Cc: yang@linux.alibaba.com; Linux Kernel Mailing List
> ; Matthew Wilcox ;
> mho...@kernel.org; Colin King ; Andrew Mor
On 10/09/2018 11:39 AM, Lukasz Luba wrote:
> This patch add some comment related to performance impact,
> which can be really big (x3 times slower context switch).
>
> Signed-off-by: Lukasz Luba
> ---
> lib/Kconfig.debug | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/lib/Kc
On 10/29/2018 03:25 PM, Davidlohr Bueso wrote:
> A recent report from a large database vendor which I shall not name
> shows concerns about poor performance when consuming /proc/stat info.
> Particularly kstat_irq() pops up in the profiles and most time is
> being spent there. The overall system i
On 10/29/2018 04:00 PM, Davidlohr Bueso wrote:
> On Mon, 29 Oct 2018, Waiman Long wrote:
>
>> I am wondering if /proc/stat_noirqs will be a more descriptive name of
>> the intent of this new procfs file or we should just go with the more
>> generic stat2 name.
>
>
On 10/29/2018 04:38 PM, Davidlohr Bueso wrote:
> On Mon, 29 Oct 2018, Waiman Long wrote:
>
>> BTW, since you are making stat2 compatible with stat, will that be
>> easier from the user API perspective if we use a sysctl parameter to
>> turn on and off IRQs reporting for
On 10/29/2018 03:25 PM, Davidlohr Bueso wrote:
> A recent report from a large database vendor which I shall not name
> shows concerns about poor performance when consuming /proc/stat info.
> Particularly kstat_irq() pops up in the profiles and most time is
> being spent there. The overall system i
On 10/29/2018 05:23 PM, Vito Caputo wrote:
> On Mon, Oct 29, 2018 at 04:59:03PM -0400, Waiman Long wrote:
>> On 10/29/2018 04:38 PM, Davidlohr Bueso wrote:
>>> On Mon, 29 Oct 2018, Waiman Long wrote:
>>>
>>>> BTW, since you are making stat2 compatible with
On 10/31/2018 10:10 AM, Peter Zijlstra wrote:
> On Wed, Oct 31, 2018 at 09:54:17AM +0800, Yi Sun wrote:
>> On 18-10-23 17:33:28, Yi Sun wrote:
>>> On 18-10-23 10:51:27, Peter Zijlstra wrote:
Can you try and explain why vcpu_is_preempted() doesn't work for you?
>>> I thought HvSpinWaitInfo is u
1,012,15082 00
After parallel build + perf-top 125,195,00982 00
So the chance of needing more than 2 levels of nesting is extremely rare.
Signed-off-by: Waiman Long
---
kernel/locking/qspinlock.c | 5 +
kernel/locking/qspinlock_stat.h | 6 ++
2
ended to have two more long
words when PV qspinlock lock is configured to hold the extra data
that it needs. As a result, the PV qspinlock code will enjoy the same
benefit of using just one extra cacheline like the native counterpart
for most cases.
Signed-off-by: Waiman Long
---
kernel/lo
On 10/15/2018 06:55 AM, Christian Brauner wrote:
> Currently, when writing
>
> echo 18446744073709551616 > /proc/sys/fs/file-max
>
> /proc/sys/fs/file-max will overflow and be set to 0. That quickly
> crashes the system.
> This commit explicitly caps the value for file-max to ULONG_MAX.
>
> Note, t
On 10/16/2018 11:21 AM, Christian Brauner wrote:
> On Tue, Oct 16, 2018 at 11:13:28AM -0400, Waiman Long wrote:
>> On 10/15/2018 06:55 AM, Christian Brauner wrote:
>>> Currently, when writing
>>>
>>> echo 18446744073709551616 > /proc/sys/fs/file-max
>>
On 10/16/2018 11:29 AM, Christian Brauner wrote:
> On Tue, Oct 16, 2018 at 11:25:42AM -0400, Waiman Long wrote:
>> On 10/16/2018 11:21 AM, Christian Brauner wrote:
>>> On Tue, Oct 16, 2018 at 11:13:28AM -0400, Waiman Long wrote:
>>>> On 10/15/2018 06:55 AM, Christian
On 10/16/2018 11:40 AM, Christian Brauner wrote:
> On Tue, Oct 16, 2018 at 11:34:07AM -0400, Waiman Long wrote:
>> On 10/16/2018 11:29 AM, Christian Brauner wrote:
>>> On Tue, Oct 16, 2018 at 11:25:42AM -0400, Waiman Long wrote:
>>>> On 10/16/2018 11:21 AM, Christi
On 10/16/2018 11:47 AM, Christian Brauner wrote:
> On Tue, Oct 16, 2018 at 11:44:40AM -0400, Waiman Long wrote:
>> On 10/16/2018 11:40 AM, Christian Brauner wrote:
>>> On Tue, Oct 16, 2018 at 11:34:07AM -0400, Waiman Long wrote:
>>>> On 10/16/2018 11:29 AM, Christi
On 10/16/2018 03:53 PM, Christian Brauner wrote:
> Currently, when writing
>
> echo 18446744073709551616 > /proc/sys/fs/file-max
>
> /proc/sys/fs/file-max will overflow and be set to 0. That quickly
> crashes the system.
> This commit sets the max and min value for file-max and returns -EINVAL
> wh
On 10/17/2018 03:38 AM, Peter Zijlstra wrote:
> On Tue, Oct 16, 2018 at 09:45:06AM -0400, Waiman Long wrote:
>> Queued spinlock supports up to 4 levels of lock slowpath nesting -
>> user context, soft IRQ, hard IRQ and NMI. However, we are not sure how
>> often the nesting h
On 11/05/2018 05:14 PM, Linus Torvalds wrote:
> On Mon, Nov 5, 2018 at 12:12 PM Vlastimil Babka wrote:
>> I didn't spot an obvious mistake in the patch itself, so it looks
>> like some bad interaction between scheduler and the mmap downgrade?
> I'm thinking it's RWSEM_SPIN_ON_OWNER that ends up be
On 11/06/2018 06:50 AM, Peter Zijlstra wrote:
> On Mon, Oct 15, 2018 at 04:29:35PM -0400, Waiman Long wrote:
>> The cgroup-v2.rst file is updated to document the purpose of the new
>> "cpuset.sched.partition" flag and how its usage.
>>
>> Signed-off-by: Waiman
decide
if a segmentation fault should happen, when the RLIMIT_STACK limit is
exceeded, for example.
Signed-off-by: Waiman Long
---
arch/x86/mm/fault.c | 12
1 file changed, 12 deletions(-)
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 71d4b9d..29525cf 100644
--- a/arch/
On 11/06/2018 03:12 PM, Waiman Long wrote:
> The current x86 page fault handler allows stack access below the stack
> pointer if it is no more than 64k+256 bytes. Any access beyond the 64k+
> limit will cause a segmentation fault.
>
> The gcc -fstack-check option generates code to
On 11/06/2018 10:32 PM, Davidlohr Bueso wrote:
> On Tue, 06 Nov 2018, Andrew Morton wrote:
>
>> It would be interesting to know precisely which stat fields the
>> database-which-shall-not-be-named is looking for. Then we could cook
>> up a very whizzy way of getting at the info.
>
> The ctxt field
On 11/06/2018 07:18 PM, Tim Chen wrote:
> Thomas,
>
2) Add _TIF_UPDATE_SPEC_CTRL to the SYSCALL_EXIT_WORK_FLAGS and handle it
in the slow work path.
>>> There can be tasks that don't do any syscalls, and it seems like we can
>>> have MSRs getting out of sync?
>> Setting the TIF flag di
On 10/04/2018 05:04 AM, Juri Lelli wrote:
> On 03/10/18 15:42, Steven Rostedt wrote:
>> On Mon, 3 Sep 2018 16:28:00 +0200
>> Juri Lelli wrote:
>>
>>
>>> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
>>> index 5b43f482fa0f..8dc26005bb1e 100644
>>> --- a/kernel/cgroup/cpuset.c
>>> ++
>
>>> https://lore.kernel.org/lkml/20180925130750.GA25664@localhost.localdomain/
>> Can you please loop Waiman Long into discussion?
>> He's working on cgroup2 cpuset support which might collide.
> Sure, I've been originally working on this on top of his series,
68419 -10.0%
stack-trace entries 110403 104341 -5.5%
There were some reductions in the size of the lockdep tables. They were
not significant, but it is still a good start to rein in the number of
entries in those tables to make it harder to overflow them.
Waiman
By making logbuf_lock a terminal lock, it reduces the performance
overhead when lockdep is enabled.
Signed-off-by: Waiman Long
---
kernel/printk/printk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 1b2a029..6b63fda
By marking the internal pool_lock as a terminal lock, lockdep will be
able to skip full validation to improve locking performance.
Signed-off-by: Waiman Long
---
lib/debugobjects.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/debugobjects.c b/lib/debugobjects.c
index
Add new DEFINE_RAW_TERMINAL_SPINLOCK() and DEFINE_TERMINAL_SPINLOCK()
macro to define a raw terminal spinlock and a terminal spinlock.
Signed-off-by: Waiman Long
---
include/linux/spinlock_types.h | 34 +++---
kernel/printk/printk_safe.c| 2 +-
2 files changed
locks[], list_entries[] and stack_trace[]. By marking suitable
locks as terminal, we reduce the chance of overflowing those tables
allowing them to focus on locks that can have both forward and backward
dependencies.
Signed-off-by: Waiman Long
---
include/linux/lockdep.h
By defining depot_lock as a terminal spinlock, it reduces the
lockdep overhead when this lock is being used.
Signed-off-by: Waiman Long
---
lib/stackdepot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/stackdepot.c b/lib/stackdepot.c
index e513459..fb17888 100644
By making the object hash locks nested terminal locks, we can avoid
a bunch of unnecessary lockdep validations as well as saving space
in the lockdep tables.
Signed-off-by: Waiman Long
---
lib/debugobjects.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/lib
and debug_print_object() calls are now moved out of those critical
sections.
Signed-off-by: Waiman Long
---
lib/debugobjects.c | 61 +-
1 file changed, 42 insertions(+), 19 deletions(-)
diff --git a/lib/debugobjects.c b/lib/debugobjects.c
index 403d
There are use cases where we want to allow 2-level nesting of one
terminal lock underneath another one. So the terminal lock type is now
extended to support a new nested terminal lock where it can allow the
acquisition of another regular terminal lock underneath it.
Signed-off-by: Waiman Long
; field
is added to both the lockdep_map and lock_class structures.
The new field can now be used to designate a lock and a class object
as novalidate. The lockdep_set_novalidate_class() call, however, should
be called before lock initialization which calls lockdep_init_map().
Signed-off-by: W
By making quarantine_lock a terminal spinlock, it reduces the lockdep
overhead when this lock is being used.
Signed-off-by: Waiman Long
---
mm/kasan/quarantine.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
index b209dba
: Waiman Long
---
include/linux/rwsem.h | 11 ++-
kernel/locking/rwsem-xadd.c | 1 +
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
index 67dbb57..a2a2385 100644
--- a/include/linux/rwsem.h
+++ b/include/linux/rwsem.h
By classifying the cgroup rstat percpu locks as terminal locks, it
reduces the lockdep overhead when these locks are being used.
Signed-off-by: Waiman Long
---
kernel/cgroup/rstat.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/kernel/cgroup/rstat.c b/kernel
Remove the duplicated lock_class_ops percpu array that is not used
anywhere.
Fixes: 8ca2b56cd7da ("locking/lockdep: Make class->ops a percpu counter
and move it under CONFIG_DEBUG_LOCKDEP=y")
Signed-off-by: Waiman Long
---
kernel/locking/lockdep.c | 1 -
1 file changed, 1 dele
On 10/04/2018 06:14 AM, Ingo Molnar wrote:
> * Waiman Long wrote:
>
>> diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
>> index b0d0b51c4d85..1fd82ff99c65 100644
>> --- a/include/linux/lockdep.h
>> +++ b/include/linux/lockdep.h
>>
On 10/04/2018 03:16 AM, Jan Kara wrote:
> On Wed 12-09-18 15:28:52, Waiman Long wrote:
>> From: Davidlohr Bueso
>>
>> Instead of the current O(N) implementation, at the cost
>> of adding an atomic counter, we can convert the call to
>> an atomic_read(). The c
On 10/31/2018 11:20 PM, Yi Sun wrote:
> On 18-10-31 18:15:39, Peter Zijlstra wrote:
>> On Wed, Oct 31, 2018 at 11:07:22AM -0400, Waiman Long wrote:
>>> On 10/31/2018 10:10 AM, Peter Zijlstra wrote:
>>>> On Wed, Oct 31, 2018 at 09:54:17AM +0800, Yi Sun wrote:
>
("### ok\n");
return 0;
}
% gcc -fstack-check -g -o test test.c
% ./test
Segmentation fault
The 64k+ limit check is kind of arbitrary. So the check is now removed
to just let expand_stack() decide if a segmentation fault should happen.
Signed-off-by: Waiman Long
---
arch
On 11/02/2018 03:44 PM, Dave Hansen wrote:
> On 11/2/18 12:40 PM, Waiman Long wrote:
>> The 64k+ limit check is kind of arbitrary. So the check is now removed
>> to just let expand_stack() decide if a segmentation fault should happen.
> With the 64k check removed, what's
On 11/02/2018 04:11 PM, Andy Lutomirski wrote:
> On Fri, Nov 2, 2018 at 12:50 PM Waiman Long wrote:
>> On 11/02/2018 03:44 PM, Dave Hansen wrote:
>>> On 11/2/18 12:40 PM, Waiman Long wrote:
>>>> The 64k+ limit check is kind of arbitrary. So the check is now removed
On 11/02/2018 06:28 PM, Dave Hansen wrote:
> On 11/2/18 12:50 PM, Waiman Long wrote:
>> On 11/02/2018 03:44 PM, Dave Hansen wrote:
>>> On 11/2/18 12:40 PM, Waiman Long wrote:
>>>> The 64k+ limit check is kind of arbitrary. So the check is now removed
>>>&
On 10/17/2018 01:59 PM, Tim Chen wrote:
> Add static key to indicate whether we are using Enhanced IBRS to mitigate
> Spectre v2. This will be used in later patches to disengage STIBP code
> for Spectre v2 mitigation as STIBP is not needed when Enhanced IBRS is
> in use.
>
> Signed-off-by: Tim Che
On 10/17/2018 01:59 PM, Tim Chen wrote:
> With enhanced IBRS in use, the application running on sibling CPU will not
> be able to launch Spectre v2 attack to the application on current CPU.
> There is no need to use STIBP for this case. Disable the STIBP code
> when enhanced IBRS is used.
>
> Sign
On 10/17/2018 01:59 PM, Tim Chen wrote:
> Reorganize the spculation control MSR update code. Currently it is limited
> to only dynamic update of the Speculative Store Bypass Disable bit.
> This patch consolidates the logic to check for AMD CPUs that may or may
> not use this MSR to control SSBD. Th
On 10/17/2018 01:59 PM, Tim Chen wrote:
> Mark the non-dumpable processes with TIF_STIBP flag so they will
> use STIBP and IBPB defenses against Spectre v2 attack from
> processes in user space.
>
> Signed-off-by: Tim Chen
> ---
> arch/x86/kernel/cpu/bugs.c | 21 +
> 1 file ch
put into the same cacheline as debug_locks.
Signed-off-by: Waiman Long
---
include/linux/debug_locks.h | 4 ++--
lib/debug_locks.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/debug_locks.h b/include/linux/debug_locks.h
index 120225e..257ab3c
cacheline, lock_acquired()
and lock_contended() now checks the state of debug_locks before
proceeding. The debug_locks_off() function is also modified to check
debug_locks before calling __debug_locks_off().
Signed-off-by: Waiman Long
---
kernel/locking/lockdep.c | 4 ++--
lib/debug_locks.c| 2
On 10/22/2018 03:32 AM, Juergen Gross wrote:
> On 22/10/2018 03:53, Yi Sun wrote:
>> On 18-10-19 16:20:52, Juergen Gross wrote:
>>> On 19/10/2018 15:13, Yi Sun wrote:
>> [...]
>>
diff --git a/kernel/locking/qspinlock_paravirt.h
b/kernel/locking/qspinlock_paravirt.h
index 0130e48..9e
On 10/22/2018 01:15 PM, Peter Zijlstra wrote:
> Firstly, who come a patch that is grubbing around in kernel/locking/ has
> an x86/hyperv subject and isn't Cc'ed to the locking maintainers?
>
> On Mon, Oct 22, 2018 at 12:31:45PM -0400, Waiman Long wrote:
>> On 10/22/
On 10/22/2018 01:31 PM, Peter Zijlstra wrote:
> On Mon, Oct 22, 2018 at 01:27:27PM -0400, Waiman Long wrote:
>
>>>> I agree with Juergen on that. I would suggest rename the
>>>> vcpu_is_preempted hook into a more generic vcpu_stop_spinning, perhaps,
>>>&g
On 09/17/2018 10:15 AM, Davidlohr Bueso wrote:
> On Wed, 12 Sep 2018, Waiman Long wrote:
>
>> @@ -927,8 +921,6 @@ struct inode *new_inode(struct super_block *sb)
>> {
>> struct inode *inode;
>>
>> -spin_lock_prefetch(&sb->s_inode_li
-by: Waiman Long
---
arch/alpha/include/asm/processor.h | 12
arch/arm64/include/asm/processor.h | 8
arch/ia64/include/asm/processor.h| 2 --
.../include/asm/mach-cavium-octeon/cpu-feature
701 - 800 of 3826 matches
Mail list logo
