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.
>
> >
> >
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
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
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 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 wrote:
Hello, Rafael.
Hi,
On Wed, Apr 23, 2014 at 12:21:33AM
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 wrote:
Hello, Rafael.
Hi,
On Wed, Apr 23, 2014 at 12:21:33AM
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
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:
Can you please elaborate a bit?
Because it can get involved in
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 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 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:
Can you please elaborate a bit?
Because it can get involved in
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 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
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
Hello, Rafael.
On Wed, Apr 23, 2014 at 06:12:01PM +0200, Rafael J. Wysocki wrote:
> >Why add this additional global lock across multiple subsystems?
>
> That basically is because of how eject works when it is triggered via ACPI.
>
> It is signaled for a device at the top of a subtree. It may
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
joining dependency graphs of two otherwise largely disjoint
Hello, Rafael.
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
joining dependency graphs of two otherwise largely disjoint
subsystems. It has potential to create possible
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 lockdep assertions in
> > > > places to verify and
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:
> > > > Hello,
> > > >
> > > > On Mon, Apr 21, 2014 at
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 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:
Hello,
On Mon, Apr 21, 2014 at 05:23:50PM +0800, Li
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 lockdep assertions in
places to verify and enforce this? If
Hello, Rafael.
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
joining dependency graphs of two otherwise largely disjoint
subsystems. It has potential to create possible
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
joining dependency graphs of two otherwise largely disjoint
Hello, Rafael.
On Wed, Apr 23, 2014 at 06:12:01PM +0200, Rafael J. Wysocki wrote:
Why add this additional global lock across multiple subsystems?
That basically is because of how eject works when it is triggered via ACPI.
It is signaled for a device at the top of a subtree. It may be a
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
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
On 4/22/2014 10:44 PM, 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?
It seems not true ...
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?
>
> It seems not true ... I think there are devices
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.
>
> Ok, will try to write some in next version.
>
> >
>
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.
Ok, will try to write some in next version.
+struct
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?
It seems not true ... I think there are devices that
On 4/22/2014 10:44 PM, 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?
It seems not true ...
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: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_sysfs(struct device *dev,
> > +
Hello,
On Mon, Apr 21, 2014 at 05:23:50PM +0800, Li Zhong wrote:
Proper /** function comment would be nice.
> +struct kernfs_node *lock_device_hotplug_sysfs(struct device *dev,
> +struct device_attribute *attr)
I can see why you did this but let's
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.
The active protection is there to keep the file alive by blocking
deletion while operations are on-going in the file. This
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.
The active protection is there to keep the file alive by blocking
deletion while operations are on-going in the file. This
Hello,
On Mon, Apr 21, 2014 at 05:23:50PM +0800, Li Zhong wrote:
Proper /** function comment would be nice.
+struct kernfs_node *lock_device_hotplug_sysfs(struct device *dev,
+struct device_attribute *attr)
I can see why you did this but let's
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,
+
42 matches
Mail list logo
