device_hotplug_lock is not needed.
In this case, their specific online/offline callbacks needs to check whether
the device has been removed.
Cc: Tejun Heo
Cc: Rafael J. Wysocki
Cc: Greg Kroah-Hartman
Cc: Toshi Kani
Signed-off-by: Li Zhong
---
drivers/base/core.c| 93
ss,
as they are not to be removed. So we could use lock_device_hotplug() here.
Cc: Tejun Heo
Cc: Rafael J. Wysocki
Cc: Greg Kroah-Hartman
Cc: Toshi Kani
Signed-off-by: Li Zhong
---
drivers/base/cpu.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/base/cpu.c
viOn Tue, 2014-04-22 at 11:34 +0800, Li Zhong wrote:
> On Mon, 2014-04-21 at 18:46 -0400, Tejun Heo wrote:
> > Hello,
> >
> > On Mon, Apr 21, 2014 at 05:23:50PM +0800, Li Zhong wrote:
> >
> > Proper /** function comment would be nice.
>
> Ok,
viOn Tue, 2014-04-22 at 11:34 +0800, Li Zhong wrote:
On Mon, 2014-04-21 at 18:46 -0400, Tejun Heo wrote:
Hello,
On Mon, Apr 21, 2014 at 05:23:50PM +0800, Li Zhong wrote:
Proper /** function comment would be nice.
Ok, will try to write some in next version.
+struct
lock_device_hotplug() here.
Cc: Tejun Heo t...@kernel.org
Cc: Rafael J. Wysocki rafael.j.wyso...@intel.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Toshi Kani toshi.k...@hp.com
Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
---
drivers/base/cpu.c | 8 ++--
1 file changed, 2 insertions(+), 6
Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
---
drivers/base/core.c| 93 +-
drivers/base/memory.c | 5 +--
include/linux/device.h | 7 +++-
mm/memory_hotplug.c| 2 ++
4 files changed, 95 insertions(+), 12 deletions(-)
diff --git
On Fri, 2014-04-25 at 09:59 -0400, Alan Stern wrote:
> On Fri, 25 Apr 2014, Li Zhong wrote:
>
> > > No, this isn't self removal. The driver-attribute (not device-attribute)
> > > store operation simply grabs a lock that is also held while the driver
> > > is be
On Fri, 2014-04-25 at 09:54 -0400, Alan Stern wrote:
> On Fri, 25 Apr 2014, Li Zhong wrote:
>
> > > I don't get why try_module_get() matters here. We can't call into
> > > ->store if the object at hand is already destroyed and the underlying
> > > modul
On Fri, 2014-04-25 at 14:47 +0200, Rafael J. Wysocki wrote:
> On 4/25/2014 3:46 AM, Li Zhong wrote:
> > On Thu, 2014-04-24 at 12:02 +0200, Rafael J. Wysocki wrote:
> >> On 4/24/2014 10:59 AM, Li Zhong wrote:
> >>> On Wed, 2014-04-23 at 18:12 +0200, Rafael J. Wysocki w
On Fri, 2014-04-25 at 08:28 -0400, Tejun Heo wrote:
> On Fri, Apr 25, 2014 at 09:56:10AM +0800, Li Zhong wrote:
> > > A nests cpu subsys mutex under s_active of the online node. B nests
> > > s_active of the online node under the cpu subsys mutex. What am I
> > > mi
On Fri, 2014-04-25 at 12:15 +0200, Johan Hovold wrote:
> On Fri, Apr 25, 2014 at 10:16:57AM +0800, Li Zhong wrote:
> > On Thu, 2014-04-24 at 16:52 +0200, Johan Hovold wrote:
>
> > > No, this isn't self removal. The driver-attribute (not device-attribute)
> > > store
On Fri, 2014-04-25 at 12:15 +0200, Johan Hovold wrote:
On Fri, Apr 25, 2014 at 10:16:57AM +0800, Li Zhong wrote:
On Thu, 2014-04-24 at 16:52 +0200, Johan Hovold wrote:
No, this isn't self removal. The driver-attribute (not device-attribute)
store operation simply grabs a lock
On Fri, 2014-04-25 at 08:28 -0400, Tejun Heo wrote:
On Fri, Apr 25, 2014 at 09:56:10AM +0800, Li Zhong wrote:
A nests cpu subsys mutex under s_active of the online node. B nests
s_active of the online node under the cpu subsys mutex. What am I
missing?
From the above two chain, I
On Fri, 2014-04-25 at 14:47 +0200, Rafael J. Wysocki wrote:
On 4/25/2014 3:46 AM, Li Zhong wrote:
On Thu, 2014-04-24 at 12:02 +0200, Rafael J. Wysocki wrote:
On 4/24/2014 10:59 AM, Li Zhong wrote:
On Wed, 2014-04-23 at 18:12 +0200, Rafael J. Wysocki wrote:
On 4/23/2014 4:23 PM, Tejun Heo
On Fri, 2014-04-25 at 09:54 -0400, Alan Stern wrote:
On Fri, 25 Apr 2014, Li Zhong wrote:
I don't get why try_module_get() matters here. We can't call into
-store if the object at hand is already destroyed and the underlying
module can't go away if the target device is still alive
On Fri, 2014-04-25 at 09:59 -0400, Alan Stern wrote:
On Fri, 25 Apr 2014, Li Zhong wrote:
No, this isn't self removal. The driver-attribute (not device-attribute)
store operation simply grabs a lock that is also held while the driver
is being deregistered at module unload. Taking
On Thu, 2014-04-24 at 16:52 +0200, Johan Hovold wrote:
> On Thu, Apr 24, 2014 at 10:35:17AM -0400, Tejun Heo wrote:
> > On Thu, Apr 24, 2014 at 04:29:15PM +0800, Li Zhong wrote:
> > > On Wed, 2014-04-23 at 10:19 -0400, Tejun Heo wrote:
> > > > cc'ing Li Zhong wh
On Thu, 2014-04-24 at 10:35 -0400, Tejun Heo wrote:
> On Thu, Apr 24, 2014 at 04:29:15PM +0800, Li Zhong wrote:
> > On Wed, 2014-04-23 at 10:19 -0400, Tejun Heo wrote:
> > > cc'ing Li Zhong who's working on a simliar issue in the following
> > > thread and quoting whol
On Thu, 2014-04-24 at 10:32 -0400, Tejun Heo wrote:
> Hello,
>
> On Thu, Apr 24, 2014 at 04:37:23PM +0800, Li Zhong wrote:
> > On Wed, 2014-04-23 at 10:39 -0400, Tejun Heo wrote:
> > After thinking it harder, I still couldn't see ABBA here ...
> >
> >
On Thu, 2014-04-24 at 12:02 +0200, Rafael J. Wysocki wrote:
> On 4/24/2014 10:59 AM, Li Zhong wrote:
> > On Wed, 2014-04-23 at 18:12 +0200, Rafael J. Wysocki wrote:
> >> On 4/23/2014 4:23 PM, Tejun Heo wrote:
> >>> Hello, Rafael.
> >> Hi,
> >>
> &
On Wed, 2014-04-23 at 18:12 +0200, Rafael J. Wysocki wrote:
> On 4/23/2014 4:23 PM, Tejun Heo wrote:
> > Hello, Rafael.
>
> Hi,
>
> > On Wed, Apr 23, 2014 at 12:21:33AM +0200, Rafael J. Wysocki wrote:
> >> Can you please elaborate a bit?
> > Because it can get involved in larger locking
On Wed, 2014-04-23 at 10:39 -0400, Tejun Heo wrote:
> On Wed, Apr 23, 2014 at 10:00:26AM +0800, Li Zhong wrote:
> > If you remove cpu0, then the cpu0 directory will be removed, together
> > with the "online" file in the directory, while some other process mi
On Wed, 2014-04-23 at 10:19 -0400, Tejun Heo wrote:
> cc'ing Li Zhong who's working on a simliar issue in the following
> thread and quoting whole body.
>
> http://thread.gmane.org/gmane.linux.kernel/1680706
>
> Li, this is another variation of the same problem. Maybe thi
On Wed, 2014-04-23 at 10:19 -0400, Tejun Heo wrote:
cc'ing Li Zhong who's working on a simliar issue in the following
thread and quoting whole body.
http://thread.gmane.org/gmane.linux.kernel/1680706
Li, this is another variation of the same problem. Maybe this can be
covered by your
On Wed, 2014-04-23 at 10:39 -0400, Tejun Heo wrote:
On Wed, Apr 23, 2014 at 10:00:26AM +0800, Li Zhong wrote:
If you remove cpu0, then the cpu0 directory will be removed, together
with the online file in the directory, while some other process might
be writing 0 or 1 to it.
But here
On Wed, 2014-04-23 at 18:12 +0200, Rafael J. Wysocki wrote:
On 4/23/2014 4:23 PM, Tejun Heo wrote:
Hello, Rafael.
Hi,
On Wed, Apr 23, 2014 at 12:21:33AM +0200, Rafael J. Wysocki wrote:
Can you please elaborate a bit?
Because it can get involved in larger locking dependency issues by
On Thu, 2014-04-24 at 12:02 +0200, Rafael J. Wysocki wrote:
On 4/24/2014 10:59 AM, Li Zhong wrote:
On Wed, 2014-04-23 at 18:12 +0200, Rafael J. Wysocki wrote:
On 4/23/2014 4:23 PM, Tejun Heo wrote:
Hello, Rafael.
Hi,
On Wed, Apr 23, 2014 at 12:21:33AM +0200, Rafael J. Wysocki wrote
On Thu, 2014-04-24 at 10:32 -0400, Tejun Heo wrote:
Hello,
On Thu, Apr 24, 2014 at 04:37:23PM +0800, Li Zhong wrote:
On Wed, 2014-04-23 at 10:39 -0400, Tejun Heo wrote:
After thinking it harder, I still couldn't see ABBA here ...
the active protection taken here is for probe/release
On Thu, 2014-04-24 at 10:35 -0400, Tejun Heo wrote:
On Thu, Apr 24, 2014 at 04:29:15PM +0800, Li Zhong wrote:
On Wed, 2014-04-23 at 10:19 -0400, Tejun Heo wrote:
cc'ing Li Zhong who's working on a simliar issue in the following
thread and quoting whole body.
http
On Thu, 2014-04-24 at 16:52 +0200, Johan Hovold wrote:
On Thu, Apr 24, 2014 at 10:35:17AM -0400, Tejun Heo wrote:
On Thu, Apr 24, 2014 at 04:29:15PM +0800, Li Zhong wrote:
On Wed, 2014-04-23 at 10:19 -0400, Tejun Heo wrote:
cc'ing Li Zhong who's working on a simliar issue
On Wed, 2014-04-23 at 12:58 +0200, Rafael J. Wysocki wrote:
> On Wednesday, April 23, 2014 01:03:42 PM Li Zhong wrote:
> > On Tue, 2014-04-22 at 16:44 -0400, Tejun Heo wrote:
> > > Hello,
> > >
> > > On Tue, Apr 22, 2014 at 11:34:39AM +0800, Li Zhong wrot
On Wed, 2014-04-23 at 12:54 +0200, Rafael J. Wysocki wrote:
> On Wednesday, April 23, 2014 09:50:32 AM Li Zhong wrote:
> > On Tue, 2014-04-22 at 12:11 +0200, Rafael J. Wysocki wrote:
> > > On Tuesday, April 22, 2014 11:34:39 AM Li Zhong wrote:
> > > > On Mon, 2014-0
On Wed, 2014-04-23 at 12:54 +0200, Rafael J. Wysocki wrote:
On Wednesday, April 23, 2014 09:50:32 AM Li Zhong wrote:
On Tue, 2014-04-22 at 12:11 +0200, Rafael J. Wysocki wrote:
On Tuesday, April 22, 2014 11:34:39 AM Li Zhong wrote:
On Mon, 2014-04-21 at 18:46 -0400, Tejun Heo wrote
On Wed, 2014-04-23 at 12:58 +0200, Rafael J. Wysocki wrote:
On Wednesday, April 23, 2014 01:03:42 PM Li Zhong wrote:
On Tue, 2014-04-22 at 16:44 -0400, Tejun Heo wrote:
Hello,
On Tue, Apr 22, 2014 at 11:34:39AM +0800, Li Zhong wrote:
Is this assumption true? If so, can we add
On Tue, 2014-04-22 at 16:44 -0400, Tejun Heo wrote:
> Hello,
>
> On Tue, Apr 22, 2014 at 11:34:39AM +0800, Li Zhong wrote:
> > > Is this assumption true? If so, can we add lockdep assertions in
> > > places to verify and enforce this? If not, aren't we just feeling
On Tue, 2014-04-22 at 16:40 -0400, Tejun Heo wrote:
> Hello,
>
> On Tue, Apr 22, 2014 at 10:29:37AM +0800, Li Zhong wrote:
> > The probe/release files are attribute files for cpu subsys, looks like
> > following in sysfs dirs
> >
> > $ cd /sys/devices/sy
On Tue, 2014-04-22 at 12:11 +0200, Rafael J. Wysocki wrote:
> On Tuesday, April 22, 2014 11:34:39 AM Li Zhong wrote:
> > On Mon, 2014-04-21 at 18:46 -0400, Tejun Heo wrote:
> > > Hello,
> > >
> > > On Mon, Apr 21, 2014 at 05:23:50PM +0800, Li Zhong wrote:
>
On Tue, 2014-04-22 at 12:11 +0200, Rafael J. Wysocki wrote:
On Tuesday, April 22, 2014 11:34:39 AM Li Zhong wrote:
On Mon, 2014-04-21 at 18:46 -0400, Tejun Heo wrote:
Hello,
On Mon, Apr 21, 2014 at 05:23:50PM +0800, Li Zhong wrote:
Proper /** function comment would be nice
On Tue, 2014-04-22 at 16:40 -0400, Tejun Heo wrote:
Hello,
On Tue, Apr 22, 2014 at 10:29:37AM +0800, Li Zhong wrote:
The probe/release files are attribute files for cpu subsys, looks like
following in sysfs dirs
$ cd /sys/devices/system/cpu/
$ ls -l
total 0
drwxr-xr-x. 7 root
On Tue, 2014-04-22 at 16:44 -0400, Tejun Heo wrote:
Hello,
On Tue, Apr 22, 2014 at 11:34:39AM +0800, Li Zhong wrote:
Is this assumption true? If so, can we add lockdep assertions in
places to verify and enforce this? If not, aren't we just feeling
good when the reality is broken
On Mon, 2014-04-21 at 18:46 -0400, Tejun Heo wrote:
> Hello,
>
> On Mon, Apr 21, 2014 at 05:23:50PM +0800, Li Zhong wrote:
>
> Proper /** function comment would be nice.
Ok, will try to write some in next version.
>
> > +struct kernfs_node *lock_device_hotplug_
On Mon, 2014-04-21 at 18:38 -0400, Tejun Heo wrote:
> Hello,
>
> On Mon, Apr 21, 2014 at 05:20:59PM +0800, Li Zhong wrote:
> > While auditing the usage of lock_device_hotplug_sysfs() for implementing
> > it in another way in following patch, it seems to me that the code here
we grab the
device_hotplug_lock, we need check whether that really happens. If so,
we should abort and not invoke the online/offline callbacks anymore. In
this case, NULL is returned to the caller, so it could return with
ENODEV.
Signed-off-by: Li Zhong
---
drivers/base/core.c| 63
here, and we
could just use lock_device_hotplug().
Signed-off-by: Li Zhong
---
drivers/base/cpu.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 006b1bc..9483225 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
here, and we
could just use lock_device_hotplug().
Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
---
drivers/base/cpu.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 006b1bc..9483225 100644
--- a/drivers/base/cpu.c
+++ b
we grab the
device_hotplug_lock, we need check whether that really happens. If so,
we should abort and not invoke the online/offline callbacks anymore. In
this case, NULL is returned to the caller, so it could return with
ENODEV.
Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
---
drivers/base
On Mon, 2014-04-21 at 18:38 -0400, Tejun Heo wrote:
Hello,
On Mon, Apr 21, 2014 at 05:20:59PM +0800, Li Zhong wrote:
While auditing the usage of lock_device_hotplug_sysfs() for implementing
it in another way in following patch, it seems to me that the code here
is to add/remove device
On Mon, 2014-04-21 at 18:46 -0400, Tejun Heo wrote:
Hello,
On Mon, Apr 21, 2014 at 05:23:50PM +0800, Li Zhong wrote:
Proper /** function comment would be nice.
Ok, will try to write some in next version.
+struct kernfs_node *lock_device_hotplug_sysfs(struct device *dev
On Thu, 2014-04-17 at 11:17 -0400, Tejun Heo wrote:
> Hello,
>
> On Thu, Apr 17, 2014 at 02:50:44PM +0800, Li Zhong wrote:
> > This patch tries to solve the device hot remove locking issues in a
> > different way from commit 5e33bc41, as kernfs already has a mechanism
On Thu, 2014-04-17 at 11:17 -0400, Tejun Heo wrote:
Hello,
On Thu, Apr 17, 2014 at 02:50:44PM +0800, Li Zhong wrote:
This patch tries to solve the device hot remove locking issues in a
different way from commit 5e33bc41, as kernfs already has a mechanism
to break active protection
dependency graph, so it won't
dead lock with any hotplug realted locks.
Signed-off-by: Li Zhong
---
drivers/base/core.c | 37 ++---
drivers/base/memory.c | 18 +++---
2 files changed, 49 insertions(+), 6 deletions(-)
diff --git a/drivers/base/core.c b
dependency graph, so it won't
dead lock with any hotplug realted locks.
Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
---
drivers/base/core.c | 37 ++---
drivers/base/memory.c | 18 +++---
2 files changed, 49 insertions(+), 6 deletions(-)
diff --git
On Wed, 2014-04-16 at 11:17 -0400, Tejun Heo wrote:
> Hello,
>
> On Wed, Apr 16, 2014 at 09:41:40AM +0800, Li Zhong wrote:
> > > If so, that is
> > > an actually possible deadlock, no?
> >
> > Yes, but it seems to me that it is solved in commit 5e33bc41, w
On Wed, 2014-04-16 at 11:17 -0400, Tejun Heo wrote:
Hello,
On Wed, Apr 16, 2014 at 09:41:40AM +0800, Li Zhong wrote:
If so, that is
an actually possible deadlock, no?
Yes, but it seems to me that it is solved in commit 5e33bc41, which uses
lock_device_hotplug_sysfs() to return
-off-by: Li Zhong
Reviewed-by: Zhang Yanfei
---
v3: memort->memory, pointed out by Yanfei
Documentation/memory-hotplug.txt | 125 +++---
drivers/base/memory.c| 12
2 files changed, 61 insertions(+), 76 deletions(-)
diff --git a/Documentat
On Tue, 2014-04-15 at 10:50 -0400, Tejun Heo wrote:
> Hello,
>
> On Tue, Apr 15, 2014 at 10:44:37AM +0800, Li Zhong wrote:
> > / *
> > * This process might deadlock with another process trying to
> > * remove this device:
> > * This process holding t
On Tue, 2014-04-15 at 10:50 -0400, Tejun Heo wrote:
Hello,
On Tue, Apr 15, 2014 at 10:44:37AM +0800, Li Zhong wrote:
/ *
* This process might deadlock with another process trying to
* remove this device:
* This process holding the s_active of online attribute, and tries
-off-by: Li Zhong zh...@linux.vnet.ibm.com
Reviewed-by: Zhang Yanfei zhangyan...@cn.fujitsu.com
---
v3: memort-memory, pointed out by Yanfei
Documentation/memory-hotplug.txt | 125 +++---
drivers/base/memory.c| 12
2 files changed, 61 insertions
On Mon, 2014-04-14 at 17:13 +0800, Zhang Yanfei wrote:
> On 04/14/2014 04:43 PM, Li Zhong wrote:
> > Seems we all agree that information about SECTION, e.g. section size,
> > sections per memory block should be kept as kernel internals, and not
> > exposed to userspace.
> &
On Mon, 2014-04-14 at 16:13 -0400, Tejun Heo wrote:
> Hello,
>
> On Mon, Apr 14, 2014 at 03:47:29PM +0800, Li Zhong wrote:
> > @@ -439,6 +439,7 @@ static ssize_t online_store(struct device *dev, struct
> > device_attribute *attr,
> > {
> > bool val
-off-by: Li Zhong
---
Documentation/memory-hotplug.txt | 125 +++---
drivers/base/memory.c| 12
2 files changed, 61 insertions(+), 76 deletions(-)
diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt
index 58340d5
As Tejun suggested, to avoid this lockdep warning,
kernfs_break_active_protection() is used before online/offline callbacks
to take the s_active lock out of the dependency chain during
online/offline operations.
Signed-off-by: Li Zhong
---
drivers/base/core.c | 13 +
1 file changed, 13 i
On Mon, 2014-04-14 at 16:13 -0400, Tejun Heo wrote:
Hello,
On Mon, Apr 14, 2014 at 03:47:29PM +0800, Li Zhong wrote:
@@ -439,6 +439,7 @@ static ssize_t online_store(struct device *dev, struct
device_attribute *attr,
{
bool val;
int ret;
+ struct kernfs_node *kn
On Mon, 2014-04-14 at 17:13 +0800, Zhang Yanfei wrote:
On 04/14/2014 04:43 PM, Li Zhong wrote:
Seems we all agree that information about SECTION, e.g. section size,
sections per memory block should be kept as kernel internals, and not
exposed to userspace.
This patch updates
callbacks
to take the s_active lock out of the dependency chain during
online/offline operations.
Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
---
drivers/base/core.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 0dd6528
-off-by: Li Zhong zh...@linux.vnet.ibm.com
---
Documentation/memory-hotplug.txt | 125 +++---
drivers/base/memory.c| 12
2 files changed, 61 insertions(+), 76 deletions(-)
diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory
As Tejun suggested, to avoid this lockdep warning,
kernfs_break_active_protection() is used before online/offline callbacks
to take the s_active lock out of the dependency chain during
online/offline operations.
Signed-off-by: Li Zhong
---
drivers/base/core.c | 9 +
1 file changed, 9 inserti
This patch uses DEVICE_ATTR_IGNORE_LOCKDEP for "online" attr to suppress
this lockdep warning. But I'm a little afraid it might also hide
(future) potential real dead lock scenarios?
Signed-off-by: Li Zhong
---
drivers/base/core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -
it might also hide
(future) potential real dead lock scenarios?
Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
---
drivers/base/core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 0dd6528..98e3e09 100644
--- a/drivers/base
callbacks
to take the s_active lock out of the dependency chain during
online/offline operations.
Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
---
drivers/base/core.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 0dd6528..2b9f68e
On Wed, 2014-04-09 at 12:39 -0500, Nathan Fontenot wrote:
> On 04/08/2014 02:47 PM, Dave Hansen wrote:
> >
> > That document really needs to be updated to stop referring to sections
> > (at least in the descriptions of the user interface). We can not change
> > the units of
On Wed, 2014-04-09 at 08:49 -0700, Dave Hansen wrote:
> On 04/09/2014 02:20 AM, Li Zhong wrote:
> > Or do you mean we don't need to expose any information related to
> > SECTION to userspace?
>
> Right, we don't need to expose sections themselves to userspace.
On Tue, 2014-04-08 at 12:47 -0700, Dave Hansen wrote:
> On 04/08/2014 11:23 AM, Nathan Fontenot wrote:
> > On 04/08/2014 11:13 AM, Dave Hansen wrote:
> >> On 04/08/2014 01:27 AM, Li Zhong wrote:
> >>> If Dave and others don't have further objections, it se
On Tue, 2014-04-08 at 12:47 -0700, Dave Hansen wrote:
On 04/08/2014 11:23 AM, Nathan Fontenot wrote:
On 04/08/2014 11:13 AM, Dave Hansen wrote:
On 04/08/2014 01:27 AM, Li Zhong wrote:
If Dave and others don't have further objections, it seems this small
userspace incompatibility could
On Wed, 2014-04-09 at 08:49 -0700, Dave Hansen wrote:
On 04/09/2014 02:20 AM, Li Zhong wrote:
Or do you mean we don't need to expose any information related to
SECTION to userspace?
Right, we don't need to expose sections themselves to userspace. Do we?
OK, I agree with that.
Yanfei
On Wed, 2014-04-09 at 12:39 -0500, Nathan Fontenot wrote:
On 04/08/2014 02:47 PM, Dave Hansen wrote:
That document really needs to be updated to stop referring to sections
(at least in the descriptions of the user interface). We can not change
the units of phys_index/end_phys_index
On Fri, 2014-04-04 at 10:29 +0900, Yasuaki Ishimatsu wrote:
> (2014/04/02 17:56), Li Zhong wrote:
> > I noticed the phys_index and end_phys_index under
> > /sys/devices/system/memory/memoryXXX/ have the same value, e.g.
> > (for the test machine, one memory
On Fri, 2014-04-04 at 10:29 +0900, Yasuaki Ishimatsu wrote:
(2014/04/02 17:56), Li Zhong wrote:
I noticed the phys_index and end_phys_index under
/sys/devices/system/memory/memoryXXX/ have the same value, e.g.
(for the test machine, one memory block has 8 sections
On Thu, 2014-04-03 at 11:06 +0800, Zhang Yanfei wrote:
> On 04/03/2014 10:37 AM, Li Zhong wrote:
> > On Thu, 2014-04-03 at 09:37 +0800, Zhang Yanfei wrote:
> >> Add ccing
> >>
> >> On 04/02/2014 04:56 PM, Li Zhong wrote:
> >>> I noticed the phys_in
On Thu, 2014-04-03 at 11:06 +0800, Zhang Yanfei wrote:
On 04/03/2014 10:37 AM, Li Zhong wrote:
On Thu, 2014-04-03 at 09:37 +0800, Zhang Yanfei wrote:
Add ccing
On 04/02/2014 04:56 PM, Li Zhong wrote:
I noticed the phys_index and end_phys_index under
/sys/devices/system/memory
On Thu, 2014-04-03 at 09:37 +0800, Zhang Yanfei wrote:
> Add ccing
>
> On 04/02/2014 04:56 PM, Li Zhong wrote:
> > I noticed the phys_index and end_phys_index under
> > /sys/devices/system/memory/memoryXXX/ have the same value, e.g.
> > (for the test machine, one
On Wed, 2014-04-02 at 09:09 -0700, Dave Hansen wrote:
> On 04/02/2014 01:56 AM, Li Zhong wrote:
> > I noticed the phys_index and end_phys_index under
> > /sys/devices/system/memory/memoryXXX/ have the same value, e.g.
> > (for the test machine, one memory
example looks like:
# cat phys_index end_phys_index
0320
0327
Signed-off-by: Li Zhong
---
drivers/base/memory.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index bece691..b10f2fa 100644
--- a/drivers/base/memory.c
example looks like:
# cat phys_index end_phys_index
0320
0327
Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
---
drivers/base/memory.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index bece691..b10f2fa 100644
On Wed, 2014-04-02 at 09:09 -0700, Dave Hansen wrote:
On 04/02/2014 01:56 AM, Li Zhong wrote:
I noticed the phys_index and end_phys_index under
/sys/devices/system/memory/memoryXXX/ have the same value, e.g.
(for the test machine, one memory block has 8 sections
On Thu, 2014-04-03 at 09:37 +0800, Zhang Yanfei wrote:
Add ccing
On 04/02/2014 04:56 PM, Li Zhong wrote:
I noticed the phys_index and end_phys_index under
/sys/devices/system/memory/memoryXXX/ have the same value, e.g.
(for the test machine, one memory block has 8 sections
quot;khelper") khelper
"xfs-data/%s"mp->m_fsname xfs-data/dm-3
Signed-off-by: Li Zhong
---
include/linux/workqueue.h |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index
-m_fsname xfs-data/dm-3
Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
---
include/linux/workqueue.h |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 594521b..704f4f6 100644
--- a/include/linux/workqueue.h
On Tue, 2014-02-11 at 10:27 -0500, Tejun Heo wrote:
> On Tue, Feb 11, 2014 at 12:00:36PM +0100, Peter Zijlstra wrote:
> > > Looks good to me. Can you please post the patch with SOB?
> >
> > ---
> > Subject: workqueue: Fix workqueue lockdep name
> >
> > Tommi noticed a 'funny' lock class name:
On Tue, 2014-02-11 at 10:27 -0500, Tejun Heo wrote:
On Tue, Feb 11, 2014 at 12:00:36PM +0100, Peter Zijlstra wrote:
Looks good to me. Can you please post the patch with SOB?
---
Subject: workqueue: Fix workqueue lockdep name
Tommi noticed a 'funny' lock class name: %s#5 from a
On Thu, 2013-08-22 at 16:30 +0930, Rusty Russell wrote:
> Greg KH writes:
> > On Wed, Aug 21, 2013 at 05:49:58PM +0800, Li Zhong wrote:
> > > struct kobj_type module_ktype = {
> > > + .release =module_kobj_release,
> > > .sysfs_ops =
6] RIP [] kobject_put+0x11/0x60
[ 1845.185026] RSP
[ 1845.185026] CR2: a01601d0
[ 1845.185026] ---[ end trace 49a70afd109f5653 ]---
Signed-off-by: Li Zhong
---
drivers/base/core.c| 2 +-
drivers/base/module.c | 4 ++--
include/linux/module.h | 2 +-
kernel/module.c
[ 1845.185026] CR2: a01601d0
[ 1845.185026] ---[ end trace 49a70afd109f5653 ]---
Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
---
drivers/base/core.c| 2 +-
drivers/base/module.c | 4 ++--
include/linux/module.h | 2 +-
kernel/module.c| 37
On Thu, 2013-08-22 at 16:30 +0930, Rusty Russell wrote:
Greg KH gre...@linuxfoundation.org writes:
On Wed, Aug 21, 2013 at 05:49:58PM +0800, Li Zhong wrote:
struct kobj_type module_ktype = {
+ .release =module_kobj_release,
.sysfs_ops =module_sysfs_ops,
};
Wait
On Wed, 2013-08-21 at 21:03 -0700, Greg KH wrote:
> On Thu, Aug 22, 2013 at 10:34:06AM +0800, Li Zhong wrote:
> > On Wed, 2013-08-21 at 09:18 -0700, Greg KH wrote:
> > > On Wed, Aug 21, 2013 at 05:49:58PM +0800, Li Zhong wrote:
> > > > DEBUG_KOBJECT_RELEASE helps to
On Wed, 2013-08-21 at 09:18 -0700, Greg KH wrote:
> On Wed, Aug 21, 2013 at 05:49:58PM +0800, Li Zhong wrote:
> > DEBUG_KOBJECT_RELEASE helps to find the issue attached below.
> >
> > After some investigation, it seems the reason is:
> > The mod->mkobj.kobj(ff
00 00 55 48 89 e5 53 48 89 fb 48 83 ec 08 48 85 ff 74 1d 87
00 01 00 00 01 74 1e 48 8d 7b 38 83 6b 38 01 0f 94 c0 84
[ 1845.185026] RIP [] kobject_put+0x11/0x60
[ 1845.185026] RSP
[ 1845.185026] CR2: a01601d0
[ 1845.185026] ---[ end trace 49a70afd109f5653 ]---
Signed-off-by: Li
1e 48 8d 7b 38 83 6b 38 01 0f 94 c0 84
[ 1845.185026] RIP [812cda81] kobject_put+0x11/0x60
[ 1845.185026] RSP 88007ca5dd08
[ 1845.185026] CR2: a01601d0
[ 1845.185026] ---[ end trace 49a70afd109f5653 ]---
Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
---
include/linux
On Wed, 2013-08-21 at 09:18 -0700, Greg KH wrote:
On Wed, Aug 21, 2013 at 05:49:58PM +0800, Li Zhong wrote:
DEBUG_KOBJECT_RELEASE helps to find the issue attached below.
After some investigation, it seems the reason is:
The mod-mkobj.kobj(a01600d0 below) is freed together
On Wed, 2013-08-21 at 21:03 -0700, Greg KH wrote:
On Thu, Aug 22, 2013 at 10:34:06AM +0800, Li Zhong wrote:
On Wed, 2013-08-21 at 09:18 -0700, Greg KH wrote:
On Wed, Aug 21, 2013 at 05:49:58PM +0800, Li Zhong wrote:
DEBUG_KOBJECT_RELEASE helps to find the issue attached below
1 - 100 of 286 matches
Mail list logo
