On 03/31/2014 08:19 AM, Lars-Peter Clausen wrote:
> On 03/31/2014 02:03 PM, Alessandro Zummo wrote:
>> On Mon, 31 Mar 2014 13:07:10 +0200
>> Lars-Peter Clausen wrote:
>>
>>> It doesn't really matter where it is unregistered. device_unregister() will
>>> (somewhere down it's callchain) take the ker
On 03/31/2014 02:03 PM, Alessandro Zummo wrote:
On Mon, 31 Mar 2014 13:07:10 +0200
Lars-Peter Clausen wrote:
It doesn't really matter where it is unregistered. device_unregister() will
(somewhere down it's callchain) take the kernfs lock, hence it must be
callled with the rtc mutex being held.
On Mon, 31 Mar 2014 13:07:10 +0200
Lars-Peter Clausen wrote:
> It doesn't really matter where it is unregistered. device_unregister() will
> (somewhere down it's callchain) take the kernfs lock, hence it must be
> callled with the rtc mutex being held.
Maybe device_remove_attrs could be calle
On 03/31/2014 12:43 PM, Alessandro Zummo wrote:
On Mon, 31 Mar 2014 11:52:36 +0200
Lars-Peter Clausen wrote:
It's the same bug, device_unregister(&rtc->dev) will try to unregister all
sysfs files attached to the device and that function is still called with
the rtc mutex held.
rtc-cmos tri
On Mon, 31 Mar 2014 11:52:36 +0200
Lars-Peter Clausen wrote:
> It's the same bug, device_unregister(&rtc->dev) will try to unregister all
> sysfs files attached to the device and that function is still called with
> the rtc mutex held.
rtc-cmos tries to unregister the rtc device in the probe
On 03/31/2014 11:46 AM, Alessandro Zummo wrote:
On Sun, 30 Mar 2014 12:04:16 -0400
Sasha Levin wrote:
Look good, thanks!
Or not...
Hit it again during overnight fuzzing:
I think this is a different bug, please try this.
It's the same bug, device_unregister(&rtc->dev) will try to unre
On Sun, 30 Mar 2014 12:04:16 -0400
Sasha Levin wrote:
> > Look good, thanks!
>
> Or not...
>
> Hit it again during overnight fuzzing:
>
I think this is a different bug, please try this.
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index cae212f..2c77d8e 100644
--- a/driver
On 03/29/2014 08:28 PM, Sasha Levin wrote:
On 03/25/2014 08:19 PM, Sasha Levin wrote:
On 03/25/2014 06:39 PM, Alessandro Zummo wrote:
On Tue, 25 Mar 2014 17:52:30 -0400
Sasha Levin wrote:
Pretty interesting indeed. One option would be to remove
the sys files before acquiring the lock.
On 03/25/2014 08:19 PM, Sasha Levin wrote:
On 03/25/2014 06:39 PM, Alessandro Zummo wrote:
On Tue, 25 Mar 2014 17:52:30 -0400
Sasha Levin wrote:
Pretty interesting indeed. One option would be to remove
the sys files before acquiring the lock. But I wonder
if this could lead to other
On 03/25/2014 06:39 PM, Alessandro Zummo wrote:
On Tue, 25 Mar 2014 17:52:30 -0400
Sasha Levin wrote:
Pretty interesting indeed. One option would be to remove
the sys files before acquiring the lock. But I wonder
if this could lead to other issues.
Ping? Seems this thing got lost.
On Tue, 25 Mar 2014 17:52:30 -0400
Sasha Levin wrote:
> >
> > Pretty interesting indeed. One option would be to remove
> > the sys files before acquiring the lock. But I wonder
> > if this could lead to other issues.
> >
>
> Ping? Seems this thing got lost.
What if we move
rtc_sysf
On 02/24/2014 06:04 AM, Alessandro Zummo wrote:
On Sat, 22 Feb 2014 15:52:17 -0500
Tejun Heo wrote:
The problem is rtc_device_unregister(). It grabs rtc->ops_lock and
then tries to remove the sysfs files. Some of those sysfs file
implementations acquire rtc->ops_lock, so it of course can lea
On Sat, 22 Feb 2014 15:52:17 -0500
Tejun Heo wrote:
> The problem is rtc_device_unregister(). It grabs rtc->ops_lock and
> then tries to remove the sysfs files. Some of those sysfs file
> implementations acquire rtc->ops_lock, so it of course can lead to
> deadlocks. One can't try to delete a
Hello,
On Sat, Feb 22, 2014 at 12:51:42PM -0500, Sasha Levin wrote:
> While fuzzing with trinity inside a KVM tools guest running the
> latest -next kernel I've stumbled on the following (now with pretty
> line numbers!) spew:
Heh, that's pretty awesome.
> [ 218.132898]
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next kernel I've stumbled on
the following (now with pretty line numbers!) spew:
[ 218.132898] ==
[ 218.133902] [ INFO: possible circular locking dependency det
15 matches
Mail list logo
