This patch adds a new document file on how to use the TO futexes.
Signed-off-by: Waiman Long
---
Documentation/00-INDEX |2 +
Documentation/to-futex.txt | 124
2 files changed, 126 insertions(+), 0 deletions(-)
create mode 100644
From: Long Li
This patch set fixes connectivity issues and improves performance for Fiber
Channel disks.
Long Li (3):
Use tagged SRB requests if supported by the device
Properly handle SRB_ERROR when sense message is present
Use block layer default segment size
drivers/scsi
From: Long Li
We no long have the restriction of page size limit in the SG list. Remove it.
The driver can properly handle default block segment size.
---
drivers/scsi/storvsc_drv.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
From: Long Li
Properly set SRB flags when hosting device supports tagged queuing. This patch
improves the performance on Fiber Channel disks.
---
drivers/scsi/storvsc_drv.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
From: Long Li
When sense message is present on error, we should pass along to the upper layer
to decide how to deal with the error. This patch fixes connectivity issues with
Fiber Channel devices.
---
drivers/scsi/storvsc_drv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers
(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
{
+ bool handler_found = false;
+
/*
* If we are stepping a pending breakpoint, call the hw_breakpoint
* handler first.
@@ -253,7 +255,14 @@ static int single_step_handler(unsigned
On 09/07/2016 01:52 AM, Masami Hiramatsu wrote:
On Tue, 6 Sep 2016 13:54:59 -0400
David Long wrote:
From: "David A. Long"
Kprobes searches backwards a finite number of instructions to determine if
there is an attempt to probe a load/store exclusive sequence. It stops when
i
> -Original Message-
> From: Johannes Thumshirn [mailto:jthumsh...@suse.de]
> Sent: Wednesday, September 7, 2016 12:47 AM
> To: Long Li
> Cc: KY Srinivasan ; Haiyang Zhang
> ; James E.J. Bottomley
> ; Martin K. Petersen
> ; de...@linuxdriverproject.org; linux
> -Original Message-
> From: Dexuan Cui
> Sent: Tuesday, September 13, 2016 2:51 AM
> To: Long Li ; KY Srinivasan ;
> Haiyang Zhang ; Bjorn Helgaas
>
> Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; linux-
> p...@vger.kernel.org
> Subject:
> -Original Message-
> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On
> Behalf Of Long Li
> Sent: Tuesday, September 13, 2016 10:33 AM
> To: Dexuan Cui ; KY Srinivasan
> ; Haiyang Zhang ; Bjorn
> Helgaas
> Cc: de...@linuxdriverp
> -Original Message-
> From: Dexuan Cui
> Sent: Tuesday, September 13, 2016 10:45 PM
> To: Long Li ; KY Srinivasan ;
> Haiyang Zhang ; Bjorn Helgaas
>
> Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; linux-
> p...@vger.kernel.org
> Subject:
all.
This patch prevents the schedule_work() call from being made before
system_wq is initialized.
Signed-off-by: Waiman Long
---
drivers/char/random.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 3efb3bf..3afc
On 09/14/2016 03:03 PM, Waiman Long wrote:
While booting a 4.8-rc6 kernel on a 16-socket 768-thread Broadwell-EX
system, the kernel panic'ed with the following log:
[ 51.837010] BUG: unable to handle kernel NULL pointer dereference at
0102
[ 51.845635] IP: [] __queue_work
On 09/14/2016 03:14 PM, Linus Torvalds wrote:
Ugh, I detest this patch.
My gut feeling is that a driver (even a fairly core one like the
random code) should not have to know these kinds of details like
"schedule_work() needs system_wq to have been initialized".
I'm wondering if we couldn't just
On 09/14/2016 03:19 PM, Linus Torvalds wrote:
On Wed, Sep 14, 2016 at 12:14 PM, Waiman Long wrote:
In the stack backtrace above, the kernel hadn't even reached SMP boot after
about 50s. That was extremely slow. I tried the 4.7.3 kernel and it booted
up fine. So I suspect that there may b
On 09/14/2016 05:06 PM, Linus Torvalds wrote:
On Wed, Sep 14, 2016 at 12:34 PM, Waiman Long wrote:
I can try, but the 16-socket system that I have at the moment takes a long
time (more than an hour) for one shutdown-reboot cycle. It may not be really
more interrupts in 4.8, it may be that the
From: Long Li
A PCI_EJECT message can arrive at the same time we are calling
pci_scan_child_bus in the workqueue for the previous PCI_BUS_RELATIONS message
or in create_root_hv_pci_bus(), in this case we could potentailly modify the
bus from multiple places. Properly lock the bus access
From: Long Li
hv_pci_devices_present is called in hv_pci_remove when we remove a PCI device
from host (e.g. by disabling SRIOV on a device). In hv_pci_remove, the bus is
already removed before the call, so we don't need to rescan the bus in the
workqueue scheduled from hv_pci_devices_pr
From: "David A. Long"
Kprobes searches backwards a finite number of instructions to determine if
there is an attempt to probe a load/store exclusive sequence. It stops when
it hits the maximum number of instructions or a load or store exclusive.
However this means it can run u
On 08/31/2016 10:38 PM, Masami Hiramatsu wrote:
Hi Dave,
On Wed, 31 Aug 2016 16:52:22 -0400
David Long wrote:
From: "David A. Long"
Kprobes searches backwards a finite number of instructions to determine if
there is an attempt to probe a load/store exclusive sequence. It stops wh
>> It doesn't make much sense to me. the codes I added cannot be
>> triggered without enable any pr policies. and I also did the tests in
>
> It seems these pr policies has to be turned on by user space, i.e.
> netperf in this case?
>
> I checked netperf's source code, it doesn't seem set any optio
On 08/08/2016 07:13 AM, Daniel Thompson wrote:
On 04/08/16 05:47, David Long wrote:
From b451caa1adaf1d03e08a44b5dad3fca31cebd97a Mon Sep 17 00:00:00 2001
From: "David A. Long"
Date: Thu, 4 Aug 2016 00:35:33 -0400
Subject: [PATCH] arm64: Remove stack duplicating code from jprobes
B
On 07/27/2016 11:12 AM, Christoph Lameter wrote:
On Mon, 25 Jul 2016, Tejun Heo wrote:
I don't get it. What's the harm of using percpu memory here? Other
percpu data structures have remote access too. They're to a lower
degree but I don't see a clear demarcation line and making addtions
per-
On 08/23/2016 12:57 PM, Peter Zijlstra wrote:
On Tue, Aug 23, 2016 at 09:35:03AM -0700, Jason Low wrote:
On Tue, 2016-08-23 at 09:17 -0700, Davidlohr Bueso wrote:
What's the motivation here? Is it just to unify counter and owner for
the starvation issue? If so, is this really the path we wanna
On 08/23/2016 08:46 AM, Peter Zijlstra wrote:
I have 2 more comments about the code.
1) There are a couple of places where you only use 0x3 in mutex.c. They
should be replaced by the symbolic name instead.
2) We should make __mutex_lock_slowpath() a noinline function just like
__mutex_lock_kill
On 08/23/2016 08:46 AM, Peter Zijlstra wrote:
/*
* Simple, straightforward mutexes with strict semantics:
@@ -48,13 +49,9 @@
* locks and tasks (and only those tasks)
*/
struct mutex {
- /* 1: unlocked, 0: locked, negative: locked, possible waiters */
- atomic_t
On 08/23/2016 04:41 PM, Peter Zijlstra wrote:
On Tue, Aug 23, 2016 at 03:36:17PM -0400, Waiman Long wrote:
I think this is the right way to go. There isn't any big change in the
slowpath, so the contended performance should be the same. The fastpath,
however, will get a bit slower as a s
On 08/24/2016 12:00 AM, Davidlohr Bueso wrote:
On Thu, 18 Aug 2016, Waiman Long wrote:
The default reader spining threshold is current set to 4096. However,
the right reader spinning threshold may vary from one system to
another and among the different architectures. This patch adds a new
On 08/23/2016 04:32 PM, Peter Zijlstra wrote:
On Tue, Aug 23, 2016 at 03:47:53PM -0400, Waiman Long wrote:
On 08/23/2016 08:46 AM, Peter Zijlstra wrote:
N
@@ -573,8 +600,14 @@ __mutex_lock_common(struct mutex *lock,
schedule_preempt_disabled();
spin_lock_mutex
On Fri, 2016-08-12 at 10:41 +0800, Long Cheng wrote:
> From: Eddie Huang
>
> mediatek can support baud rate up to 4M.
> the 'uart_get_baud_rate' function will limit the max baud rate.
> Modify max baud to remove the limit.
>
> Signed-off-by: Long Cheng
&
On 08/25/2016 11:43 AM, Peter Zijlstra wrote:
On Tue, Aug 23, 2016 at 06:13:43PM -0700, Jason Low wrote:
I tested this patch on an 8 socket system with the high_systime AIM7
workload with diskfs. The patch provided big performance improvements in
terms of throughput in the highly contended cases
On 08/25/2016 03:36 PM, Daniel Vetter wrote:
On Thu, Aug 25, 2016 at 8:37 PM, Peter Zijlstra wrote:
Poking at lock internals is not cool. Since I'm going to change the
implementation this will break, take it out.
Cc: Chris Wilson
Cc: Daniel Vetter
Signed-off-by: Peter Zijlstra (Intel)
It's ho
On 08/25/2016 02:50 PM, Dave Hansen wrote:
On 08/12/2016 05:59 PM, Waiman Long wrote:
+ * The lock and the hpet value are stored together and can be read in a
+ * single atomic 64-bit read. It is explicitly assumed that arch_spinlock_t
+ * is 32 bits in size.
This requirement forces us to give
On 08/25/2016 02:37 PM, Peter Zijlstra wrote:
@@ -468,9 +496,12 @@ void __sched mutex_unlock(struct mutex *
DEBUG_LOCKS_WARN_ON(__mutex_owner(lock) != current);
#endif
- owner = atomic_long_fetch_and(MUTEX_FLAGS,&lock->owner);
+ owner = atomic_long_read(&lock->owner);
+
On 08/25/2016 06:23 PM, Peter Zijlstra wrote:
On Thu, Aug 25, 2016 at 06:00:19PM -0400, Waiman Long wrote:
On 08/25/2016 02:37 PM, Peter Zijlstra wrote:
@@ -468,9 +496,12 @@ void __sched mutex_unlock(struct mutex *
DEBUG_LOCKS_WARN_ON(__mutex_owner(lock) != current);
#endif
On 08/26/2016 05:10 AM, Peter Zijlstra wrote:
On Fri, Aug 26, 2016 at 05:25:09AM +0200, Andreas Mohr wrote:
Another alternative is to provide a standard mutex API that returns the
owner of the lock if there is a real need for this capability. Peeking
into lock internal is not a good practice.
On 08/16/2017 06:33 AM, Wangkai (Kevin,C) wrote:
>> -Original Message-
>> From: linux-fsdevel-ow...@vger.kernel.org
>> [mailto:linux-fsdevel-ow...@vger.kernel.org] On Behalf Of Waiman Long
>> Sent: Wednesday, August 16, 2017 1:15 AM
>> To: Alexander Viro
On 08/16/2017 10:29 AM, Tejun Heo wrote:
> Hello, Waiman.
>
> On Tue, Aug 15, 2017 at 01:27:20PM -0400, Waiman Long wrote:
>> +cpuset_v2_mode= [KNL] Enable cpuset v2 behavior in cpuset v1 cgroups.
>> +In v2 mode, the cpus and me
On 08/16/2017 10:36 AM, Tejun Heo wrote:
> Hello,
>
> On Wed, Aug 16, 2017 at 10:34:05AM -0400, Waiman Long wrote:
>>> It feels weird to make this a kernel boot param when all other options
>>> are specified on mount time. Is there a reason why this can't be a
>
On 08/15/2017 07:11 PM, Steven Rostedt wrote:
> On Thu, 10 Aug 2017 13:02:33 -0400
> Waiman Long wrote:
>
>> The lockdep code had reported the following unsafe locking scenario:
>>
>>CPU0CPU1
>>
On 08/16/2017 02:17 PM, Steven Rostedt wrote:
> On Wed, 16 Aug 2017 14:14:36 -0400
> Waiman Long wrote:
>
>>> You also just turned the mutex into a spinlock. What happens if we just
>>> preempted the owner of bdev->bd_mutex and are an RT task with higher
>>&g
On 08/16/2017 02:59 PM, Steven Rostedt wrote:
> On Wed, 16 Aug 2017 14:46:42 -0400
> Waiman Long wrote:
>
>
>> I haven't been thinking about RT tasks. You are right that it can be a
>> problem in this case. I think I will have to revert back to use
>> mutex_loc
On 08/16/2017 03:14 PM, Steven Rostedt wrote:
> On Wed, 16 Aug 2017 15:07:25 -0400
> Waiman Long wrote:
>
>
>> I am thinking about maybe letting a RT task to sleep a tiny amount of
>> time instead of calling schedule(). Hopefully, that will allow a
>> lower-priority
will fail if a delete operation is
in progress.
Signed-off-by: Waiman Long
---
v2:
- Use READ_ONCE() and smp_store_mb() to read and write bd_deleting.
- Check for signal in the mutex_trylock loops.
- Use usleep() instead of schedule() for RT tasks.
block/ioctl.c | 3 +++
On 08/17/2017 12:00 AM, Wangkai (Kevin,C) wrote:
>
>>>
>>> Hi Longman,
>>> I am a fresher of fsdevel, about 2 weeks before, I have joined this
>>> mail list, recently I have met the same problem of negative dentries,
>>> in my opinion, the dentries should be remove together with the files or
>> dir
ck is when it is reported by lockdep. So it is changed to "kn->count"
which is how this variable is normally referenced in kernfs code.
Signed-off-by: Waiman Long
---
fs/kernfs/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/kernfs/file.c b/fs/kern
On 08/17/2017 09:34 AM, Steven Rostedt wrote:
> On Wed, 16 Aug 2017 16:40:40 -0400
> Waiman Long wrote:
>
>> The lockdep code had reported the following unsafe locking scenario:
>>
>>CPU0CPU1
>>
flag and use the v2 behavior if it is set.
Signed-off-by: Waiman Long
---
kernel/cgroup/cpuset.c | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index 9ed6a05..1c44df7 100644
--- a/kernel
in a v1 cgroup.
Waiman Long (2):
cgroup: Add a hint to allow v1 controller to use v2 behavior
cpuset: Allow v2 behavior in v1 cgroup
include/linux/cgroup-defs.h | 5 +
kernel/cgroup/cgroup-v1.c | 6 ++
kernel/cgroup/cpuset.c | 33 -
3 files change
semantics.
Signed-off-by: Waiman Long
---
include/linux/cgroup-defs.h | 5 +
kernel/cgroup/cgroup-v1.c | 6 ++
2 files changed, 11 insertions(+)
diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index 09f4c7d..fae33ed 100644
--- a/include/linux/cgroup-defs.h
+++
On 08/17/2017 02:48 PM, Tejun Heo wrote:
> Hello, Waiman.
>
> On Thu, Aug 17, 2017 at 02:25:38PM -0400, Waiman Long wrote:
>> For some cgroup controllers, the behavior on cgroup v1 differs somewhat
>> from cgroup v2. To indicate that a controller can use v2 behavior
>> i
k the cgroup_root flag
and switch to v2 behavior even in a v1 cgroup.
Waiman Long (2):
cgroup: Add mount flag to enable cpuset to use v2 behavior in v1
cgroup
cpuset: Allow v2 behavior in v1 cgroup
include/linux/cgroup-defs.h | 5 +
kernel/cgroup/cgroup-v1.c | 6 ++
kernel
CGRP_ROOT_CPUSET_V2_MODE flag and use the v2 behavior if it is set.
Signed-off-by: Waiman Long
---
kernel/cgroup/cpuset.c | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index 9ed6a05..060d575 100644
--- a
A new mount option "cpuset_v2_mode" is added to the v1 cgroupfs
filesystem to enable cpuset controller to use v2 behavior in a v1
cgroup. This mount option applies only to cpuset controller and have
no effect on other controllers.
Signed-off-by: Waiman Long
---
include/linux/cgroup-
On 08/17/2017 05:10 PM, Steven Rostedt wrote:
> On Thu, 17 Aug 2017 12:24:39 -0400
> Waiman Long wrote:
>
>>>> + * sysfs file and then acquiring the bd_mutex. Deleting a block device
>>>> + * requires acquiring the bd_mutex and then waiting for all the sysfs
>
On 06/21/2017 04:40 PM, Tejun Heo wrote:
> Hello, Waiman.
>
> On Wed, Jun 14, 2017 at 11:05:32AM -0400, Waiman Long wrote:
>> 2-4-3. No Internal Process Constraint
>>
>> +When a non-root cgroup distributes resources to their children while
>> +having processes o
On 06/21/2017 05:39 PM, Tejun Heo wrote:
> Hello,
>
> On Wed, Jun 21, 2017 at 05:37:00PM -0400, Waiman Long wrote:
>>> What happens when we add domain handling to CPU so that it is both a
>>> domain and resource controller? Even if that somehow can be resolved,
&g
On 06/21/2017 05:42 PM, Tejun Heo wrote:
> Hello,
>
> On Wed, Jun 14, 2017 at 11:05:36AM -0400, Waiman Long wrote:
>> While constantly turning on and off controllers, it is possible to
>> trigger the dying CSS warnings in cgroup_apply_control_enable() and
>> cgroup_a
On 06/21/2017 06:04 PM, Tejun Heo wrote:
> Hello,
>
> On Wed, Jun 21, 2017 at 06:01:56PM -0400, Waiman Long wrote:
>> I do think that it can happen with existing code because CSS killing is
>> asynchronous, I think. So the command can complete before the CSS is
>>
The EXPORT_SYMBOL() macro is now used in lib/dlock-list.c to enable
kernel modules to use dlock-list. Some warning messages are also added.
Signed-off-by: Waiman Long
---
lib/dlock-list.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/lib/dlock-list.c b/lib/dlock-list.c
is
changed to use a different lock class key for each of its call sites
in the kernel.
Reported-by: Boqun Feng
Signed-off-by: Waiman Long
---
include/linux/dlock-list.h | 16 +++-
lib/dlock-list.c | 21 +
2 files changed, 24 insertions(+), 13 deletions
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Tuesday, October 31, 2017 1:43 AM
> To: Long Li
> Cc: KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger ;
> de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; Paul Meyer
>
> Subject: Re: [PATCH] hv:
list_lock. So
there is no real need for safe iteration variant and we can use
list_for_each_entry() just fine.
Signed-off-by: Jan Kara
Signed-off-by: Waiman Long
---
fs/inode.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/inode.c b/fs/inode.c
index fd40102..a9a38
and unlock calls.
Signed-off-by: Waiman Long
---
fs/super.c | 2 +-
include/linux/dlock-list.h | 22 +-
lib/dlock-list.c | 46 --
3 files changed, 50 insertions(+), 20 deletions(-)
diff --git a/fs/super.c
can be done by iterating elements in the provided list
only instead of all the lists in a dlock-list.
The new APIs are:
struct dlock_list_head *dlock_list_hash(struct dlock_list_heads *, void *);
void dlock_list_add(struct dlock_list_node *, struct dlock_list_head *);
Signed-off-by: Waiman Long
iterated.
Signed-off-by: Waiman Long
---
lib/dlock-list.c | 74
1 file changed, 59 insertions(+), 15 deletions(-)
diff --git a/lib/dlock-list.c b/lib/dlock-list.c
index 17ced06..a4ddecc 100644
--- a/lib/dlock-list.c
+++ b/lib/dlock-list.c
most of the lock contention in the teardown phase.
Signed-off-by: Waiman Long
Reviewed-by: Jan Kara
---
fs/block_dev.c | 9 -
fs/drop_caches.c | 9 -
fs/inode.c | 34 +-
fs/notify/fsnotify.c | 9 -
fs/quota/dquot.c
ds that need to be iterated.
Patch 5 enables alternative use case of as a set of hashed lists.
Patch 6 provides an irq safe mode specified at dlock-list allocation
time so that it can be used within interrupt context.
Jan Kara (1):
vfs: Remove unnecessary list_for_each_entry_safe() variants
list_for_each_entry_safe() macros
respectively. The iteration states are keep in a dlock_list_iter
structure that is passed to the iteration macros.
Signed-off-by: Waiman Long
Reviewed-by: Jan Kara
---
include/linux/dlock-list.h | 242 +
lib/Makefile
previous
capacity (e.g. reading more than 100 KVP records whereas the in-memory
database was empty before).
Fix this by reading the correct number of KVP records from file each time.
Signed-off-by: Paul Meyer
Reviewed-by: Long Li
---
tools/hv/hv_kvp_daemon.c | 66
> On Tue, Oct 31, 2017 at 06:10:00PM +0000, Long Li wrote:
> > > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > > Sent: Tuesday, October 31, 2017 1:43 AM
> > > To: Long Li
> > > Cc: KY Srinivasan ; Haiyang Zhang
> > > ; Stephen Hemminger
&
previous
capacity (e.g. reading more than 100 KVP records whereas the in-memory
database was empty before).
Fix this by reading the correct number of KVP records from file each time.
Signed-off-by: Paul Meyer
Signed-off-by: Long Li
---
tools/hv/hv_kvp_daemon.c | 66
eads more than one block over the previous capacity (e.g. reading
> more than 100 KVP records whereas the in-memory database was empty before).
>
> Fix this by reading the correct number of KVP records from file each time.
Please drop this patch. I have sent a v2.
>
> Signed-off-by
From: Long Li
When there are multiple disks attached to the same SCSI controller,
the host may send several VSTOR_OPERATION_REMOVE_DEVICE or
VSTOR_OPERATION_ENUMERATE_BUS messages in a row, to indicate there is a
change on the SCSI controller. In response, storvsc rescans the SCSI host.
There
On 11/01/2017 04:40 AM, Jan Kara wrote:
> On Tue 31-10-17 14:50:59, Waiman Long wrote:
>> Insertion and deletion is relatively cheap and mostly contention
>> free for dlock-list. Lookup, on the other hand, can be rather costly
>> because all the lists in a dlock-list wil
this new parameter
in determining if pvqspinlock should be used. The parameter, however,
will override Xen's xen_nopvspin in term of disabling unfair lock.
Signed-off-by: Waiman Long
---
Documentation/admin-guide/kernel-parameters.txt | 7 +
arch/x86/include/asm/paravirt.h
On 11/01/2017 11:51 AM, Juergen Gross wrote:
> On 01/11/17 16:32, Waiman Long wrote:
>> Currently, there are 3 different lock types that can be chosen for
>> the x86 architecture:
>>
>> - qspinlock
>> - pvqspinlock
>> - unfair lock
>>
>> One
> From: Greg KH [mailto:g...@kroah.com]
> Sent: Tuesday, October 31, 2017 11:50 PM
> To: Long Li
> Cc: KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger
> ; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org; sta...@vger.kernel.org; Paul Meyer
> ; Long Li
On 10/31/2017 05:37 PM, Davidlohr Bueso wrote:
> On Tue, 31 Oct 2017, Waiman Long wrote:
>
>> +void dlock_lists_del(struct dlock_list_node *node)
>> +{
>> +struct dlock_list_head *head;
>> +bool retry;
>> +
>> +do {
>> +head =
Signed-off-by: Long Li
---
tools/hv/hv_kvp_daemon.c | 66
1 file changed, 10 insertions(+), 56 deletions(-)
diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index eaa3bec..2094036 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv
> -Original Message-
> From: Pavel Shilovsky [mailto:piastr...@gmail.com]
> Sent: Wednesday, November 1, 2017 10:19 AM
> To: Long Li
> Cc: Steve French ; linux-cifs c...@vger.kernel.org>; samba-technical ;
> Kernel Mailing List ; linux-
> r...@vger.kernel.o
> -Original Message-
> From: Pavel Shilovsky [mailto:piastr...@gmail.com]
> Sent: Wednesday, November 1, 2017 9:50 AM
> To: Long Li
> Cc: Steve French ; linux-cifs c...@vger.kernel.org>; samba-technical ;
> Kernel Mailing List ; linux-
> r...@vger.kernel.o
> -Original Message-
> From: Greg KH [mailto:g...@kroah.com]
> Sent: Wednesday, November 1, 2017 11:54 AM
> To: Long Li
> Cc: KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger
> ; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org; sta...@vge
On 11/01/2017 03:01 PM, Boris Ostrovsky wrote:
> On 11/01/2017 12:28 PM, Waiman Long wrote:
>> On 11/01/2017 11:51 AM, Juergen Gross wrote:
>>> On 01/11/17 16:32, Waiman Long wrote:
>>>> Currently, there are 3 different lock types that can be chosen
With the new pvlock_type kernel parameter, xen_nopvspin is no longer
needed. This patch deprecates the xen_nopvspin parameter by removing
its documentation and treating it as an alias of "pvlock_type=queued".
Signed-off-by: Waiman Long
---
Documentation/admin-guide/kernel-parameter
h 2 deprecates Xen's xen_nopvspin parameter as it is no longer
needed.
Waiman Long (2):
x86/paravirt: Add kernel parameter to choose paravirt lock type
x86/xen: Deprecate xen_nopvspin
Documentation/admin-guide/kernel-parameters.txt | 11 ---
arch/x86/include/asm/paravirt.h
this new parameter
in determining if pvqspinlock should be used. The parameter, however,
will override Xen's xen_nopvspin in term of disabling unfair lock.
Signed-off-by: Waiman Long
---
Documentation/admin-guide/kernel-parameters.txt | 7 +
arch/x86/include/asm/paravirt.h
sctp_association_free(asoc);
out_unlock:
release_sock(sk);
@@ -7976,10 +7976,11 @@ static int sctp_wait_for_sndbuf(struct
sctp_association *asoc, long *timeo_p,
for (;;) {
prepare_to_wait_exclusive(&asoc->wait, &wait,
On 11/01/2017 06:01 PM, Boris Ostrovsky wrote:
> On 11/01/2017 04:58 PM, Waiman Long wrote:
>> +/* TODO: To be removed in a future kernel version */
>> static __init int xen_parse_nopvspin(char *arg)
>> {
>> -xen_pvspin = false;
>> +pr_warn("xen_n
On 11/02/2017 01:04 PM, Davidlohr Bueso wrote:
> On Tue, 31 Oct 2017, Waiman Long wrote:
>
>> +/**
>> + * dlock_lists_empty - Check if all the dlock lists are empty
>> + * @dlist: Pointer to the dlock_list_heads structure
>> + * Return: true if
On 11/02/2017 02:08 PM, Eduardo Valentin wrote:
> On Thu, Nov 02, 2017 at 06:56:46PM +0100, Paolo Bonzini wrote:
>> On 02/11/2017 18:45, Eduardo Valentin wrote:
>>> Currently, the existing qspinlock implementation will fallback to
>>> test-and-set if the hypervisor has not set the PV_UNHALT flag.
>
On 10/24/2017 11:37 AM, Eduardo Valentin wrote:
> Hello Peter,
> On Tue, Oct 24, 2017 at 10:13:45AM +0200, Peter Zijlstra wrote:
>> On Mon, Oct 23, 2017 at 05:44:27PM -0700, Eduardo Valentin wrote:
>>> @@ -46,6 +48,8 @@ static inline bool virt_spin_lock(struct qspinlock *lock)
>>> if (!static_c
Hi Guenter,
Sorry for late reply, and thanks for your detail comments.
On Sun, Oct 22, 2017 at 09:07:29AM -0700, Guenter Roeck wrote:
> On Tue, Sep 12, 2017 at 07:40:09PM +0800, Eric Long wrote:
> > This patch adds the watchdog driver for Spreadtrum SC9860 platform.
> >
> >
On 10/06/2017 05:10 PM, Waiman Long wrote:
> Given the fact that thread mode had been merged into 4.14, it is now
> time to enable cpuset to be used in the default hierarchy (cgroup v2)
> as it is clearly threaded.
>
> The cpuset controller had experienced feature creep since its
On 10/26/2017 07:52 AM, Prateek Sood wrote:
> Remove circular dependency deadlock in a scenario where hotplug of CPU is
> being done while there is updation in cgroup and cpuset triggered from
> userspace.
>
> Process A => kthreadd => Process B => Process C => Process A
>
> Process A
> cpu_subsys_o
On Thu, Oct 26, 2017 at 10:49 PM, Dmitry Vyukov wrote:
> On Thu, Oct 26, 2017 at 10:53 AM, ChunYu Wang wrote:
>> Hi all,
>>
>> I am failed to reproduce it on target kernel with the reproducer file
>> or replaying the target syzkaller description log file, do I made
>> something wrong or there exi
On Fri, Oct 27, 2017 at 12:13 AM, Dmitry Vyukov wrote:
> On Thu, Oct 26, 2017 at 5:49 PM, Xin Long wrote:
>> On Thu, Oct 26, 2017 at 10:49 PM, Dmitry Vyukov wrote:
>>> On Thu, Oct 26, 2017 at 10:53 AM, ChunYu Wang wrote:
>>>> Hi all,
>>>>
>>>
On 10/26/2017 10:39 AM, Tejun Heo wrote:
> Hello, Waiman.
>
> On Wed, Oct 25, 2017 at 11:50:34AM -0400, Waiman Long wrote:
>> Ping! Any comment on this patch?
> Sorry about the lack of response. Here are my two thoughts.
>
> 1. I'm not really sure about the memory
On 10/05/2017 02:43 PM, Waiman Long wrote:
>
> This is a follow up of the following patchset:
>
> [PATCH v7 0/4] vfs: Use per-cpu list for SB's s_inodes list
> https://lkml.org/lkml/2016/4/12/1009
>
> This patchset provides new APIs for a set of distributed locked
On Fri, Oct 27, 2017 at 12:56 AM, Xin Long wrote:
> On Fri, Oct 27, 2017 at 12:13 AM, Dmitry Vyukov wrote:
>> On Thu, Oct 26, 2017 at 5:49 PM, Xin Long wrote:
>>> On Thu, Oct 26, 2017 at 10:49 PM, Dmitry Vyukov wrote:
>>>> On Thu, Oct 26, 2017 at 10:53 AM, Ch
401 - 500 of 5157 matches
Mail list logo
