On Jan 18, 2008 7:26 PM, Cornelia Huck <[EMAIL PROTECTED]> wrote:
> On Fri, 18 Jan 2008 18:34:55 +0800,
> "Dave Young" <[EMAIL PROTECTED]> wrote:
>
>
> > On Jan 18, 2008 6:23 PM, Cornelia Huck <[EMAIL PROTECTED]> wrote:
> > > On Fri, 18 Jan 2008 10:19:33 +0100,
> > > Cornelia Huck <[EMAIL
On Jan 18, 2008 7:26 PM, Cornelia Huck [EMAIL PROTECTED] wrote:
On Fri, 18 Jan 2008 18:34:55 +0800,
Dave Young [EMAIL PROTECTED] wrote:
On Jan 18, 2008 6:23 PM, Cornelia Huck [EMAIL PROTECTED] wrote:
On Fri, 18 Jan 2008 10:19:33 +0100,
Cornelia Huck [EMAIL PROTECTED] wrote:
On Fri, 18 Jan 2008 18:34:55 +0800,
"Dave Young" <[EMAIL PROTECTED]> wrote:
> On Jan 18, 2008 6:23 PM, Cornelia Huck <[EMAIL PROTECTED]> wrote:
> > On Fri, 18 Jan 2008 10:19:33 +0100,
> > Cornelia Huck <[EMAIL PROTECTED]> wrote:
> >
> > > >
> > > > 1314 if (IS_ERR(new_parent_kobj)) {
> >
On Jan 18, 2008 6:23 PM, Cornelia Huck <[EMAIL PROTECTED]> wrote:
> On Fri, 18 Jan 2008 10:19:33 +0100,
> Cornelia Huck <[EMAIL PROTECTED]> wrote:
>
> > >
> > > 1314 if (IS_ERR(new_parent_kobj)) {
> > > 1315 error = PTR_ERR(new_parent_kobj);
> > > 1316
On Fri, 18 Jan 2008 10:19:33 +0100,
Cornelia Huck <[EMAIL PROTECTED]> wrote:
> >
> > 1314 if (IS_ERR(new_parent_kobj)) {
> > 1315 error = PTR_ERR(new_parent_kobj);
> > 1316 put_device(new_parent);
> > 1317 goto out;
> > 1318 }
> >
On Fri, 18 Jan 2008 11:37:21 +0800,
"Dave Young" <[EMAIL PROTECTED]> wrote:
> Lets see the device_move function, seems there's some problems in it:
>
> 1302 int device_move(struct device *dev, struct device *new_parent)
> 1303 {
> 1304 int error;
> 1305 struct device
On Fri, 18 Jan 2008 11:37:21 +0800,
Dave Young [EMAIL PROTECTED] wrote:
Lets see the device_move function, seems there's some problems in it:
1302 int device_move(struct device *dev, struct device *new_parent)
1303 {
1304 int error;
1305 struct device *old_parent;
1306
On Jan 18, 2008 6:23 PM, Cornelia Huck [EMAIL PROTECTED] wrote:
On Fri, 18 Jan 2008 10:19:33 +0100,
Cornelia Huck [EMAIL PROTECTED] wrote:
1314 if (IS_ERR(new_parent_kobj)) {
1315 error = PTR_ERR(new_parent_kobj);
1316 put_device(new_parent);
On Fri, 18 Jan 2008 10:19:33 +0100,
Cornelia Huck [EMAIL PROTECTED] wrote:
1314 if (IS_ERR(new_parent_kobj)) {
1315 error = PTR_ERR(new_parent_kobj);
1316 put_device(new_parent);
1317 goto out;
1318 }
1319
On Fri, 18 Jan 2008 18:34:55 +0800,
Dave Young [EMAIL PROTECTED] wrote:
On Jan 18, 2008 6:23 PM, Cornelia Huck [EMAIL PROTECTED] wrote:
On Fri, 18 Jan 2008 10:19:33 +0100,
Cornelia Huck [EMAIL PROTECTED] wrote:
1314 if (IS_ERR(new_parent_kobj)) {
1315
On Jan 17, 2008 7:42 PM, Cornelia Huck <[EMAIL PROTECTED]> wrote:
> On Thu, 17 Jan 2008 16:15:04 +0800,
> Dave Young <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Jan 17, 2008 at 03:24:50PM +0800, Dave Young wrote:
> > > On Jan 17, 2008 7:06 AM, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> > > > Hi,
> > >
On Thu, 17 Jan 2008 16:15:04 +0800,
Dave Young <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 17, 2008 at 03:24:50PM +0800, Dave Young wrote:
> > On Jan 17, 2008 7:06 AM, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > On Wed, Jan 16, 2008 at 09:02:05AM +0800, Dave Young wrote:
> > >
> >
On Thu, Jan 17, 2008 at 03:24:50PM +0800, Dave Young wrote:
> On Jan 17, 2008 7:06 AM, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > On Wed, Jan 16, 2008 at 09:02:05AM +0800, Dave Young wrote:
> >
> > > The rfcomm tty device will possibly retain even when conn is down,
> > > and sysfs
On Thu, 17 Jan 2008 16:15:04 +0800,
Dave Young [EMAIL PROTECTED] wrote:
On Thu, Jan 17, 2008 at 03:24:50PM +0800, Dave Young wrote:
On Jan 17, 2008 7:06 AM, Gabor Gombas [EMAIL PROTECTED] wrote:
Hi,
On Wed, Jan 16, 2008 at 09:02:05AM +0800, Dave Young wrote:
The rfcomm tty
On Jan 17, 2008 7:42 PM, Cornelia Huck [EMAIL PROTECTED] wrote:
On Thu, 17 Jan 2008 16:15:04 +0800,
Dave Young [EMAIL PROTECTED] wrote:
On Thu, Jan 17, 2008 at 03:24:50PM +0800, Dave Young wrote:
On Jan 17, 2008 7:06 AM, Gabor Gombas [EMAIL PROTECTED] wrote:
Hi,
On Wed, Jan 16,
On Jan 17, 2008 7:06 AM, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Wed, Jan 16, 2008 at 09:02:05AM +0800, Dave Young wrote:
>
> > The rfcomm tty device will possibly retain even when conn is down,
> > and sysfs doesn't support zombie device moving, so this patch
> > move the tty device
Hi,
On Wed, Jan 16, 2008 at 09:02:05AM +0800, Dave Young wrote:
> The rfcomm tty device will possibly retain even when conn is down,
> and sysfs doesn't support zombie device moving, so this patch
> move the tty device before conn device is destroyed.
>
> Signed-off-by: Dave Young <[EMAIL
On Jan 17, 2008 7:06 AM, Gabor Gombas [EMAIL PROTECTED] wrote:
Hi,
On Wed, Jan 16, 2008 at 09:02:05AM +0800, Dave Young wrote:
The rfcomm tty device will possibly retain even when conn is down,
and sysfs doesn't support zombie device moving, so this patch
move the tty device before conn
On Tue, Jan 15, 2008 at 09:57:41AM +0800, Dave Young wrote:
> On Mon, Jan 14, 2008 at 01:52:28PM +0100, Cornelia Huck wrote:
> > On Mon, 14 Jan 2008 15:05:19 +0800,
> > "Dave Young" <[EMAIL PROTECTED]> wrote:
> >
> > > On Jan 12, 2008 7:09 AM, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> > > > On
On Tue, Jan 15, 2008 at 09:57:41AM +0800, Dave Young wrote:
On Mon, Jan 14, 2008 at 01:52:28PM +0100, Cornelia Huck wrote:
On Mon, 14 Jan 2008 15:05:19 +0800,
Dave Young [EMAIL PROTECTED] wrote:
On Jan 12, 2008 7:09 AM, Gabor Gombas [EMAIL PROTECTED] wrote:
On Thu, Jan 10, 2008 at
On Mon, Jan 14, 2008 at 01:52:28PM +0100, Cornelia Huck wrote:
> On Mon, 14 Jan 2008 15:05:19 +0800,
> "Dave Young" <[EMAIL PROTECTED]> wrote:
>
> > On Jan 12, 2008 7:09 AM, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> > > On Thu, Jan 10, 2008 at 09:11:17AM +0800, Dave Young wrote:
> > >
> > > > For
On Mon, 14 Jan 2008 15:05:19 +0800,
"Dave Young" <[EMAIL PROTECTED]> wrote:
> On Jan 12, 2008 7:09 AM, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> > On Thu, Jan 10, 2008 at 09:11:17AM +0800, Dave Young wrote:
> >
> > > For bluetooth device_move, the only child device of hci_conn dev is
> > > the
On Mon, 14 Jan 2008 15:05:19 +0800,
Dave Young [EMAIL PROTECTED] wrote:
On Jan 12, 2008 7:09 AM, Gabor Gombas [EMAIL PROTECTED] wrote:
On Thu, Jan 10, 2008 at 09:11:17AM +0800, Dave Young wrote:
For bluetooth device_move, the only child device of hci_conn dev is
the rfcomm tty_dev. How
On Mon, Jan 14, 2008 at 01:52:28PM +0100, Cornelia Huck wrote:
On Mon, 14 Jan 2008 15:05:19 +0800,
Dave Young [EMAIL PROTECTED] wrote:
On Jan 12, 2008 7:09 AM, Gabor Gombas [EMAIL PROTECTED] wrote:
On Thu, Jan 10, 2008 at 09:11:17AM +0800, Dave Young wrote:
For bluetooth
On Jan 12, 2008 7:09 AM, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 10, 2008 at 09:11:17AM +0800, Dave Young wrote:
>
> > For bluetooth device_move, the only child device of hci_conn dev is
> > the rfcomm tty_dev. How about the following patch, please verify :
>
> There is now no oops,
On Jan 12, 2008 7:09 AM, Gabor Gombas [EMAIL PROTECTED] wrote:
On Thu, Jan 10, 2008 at 09:11:17AM +0800, Dave Young wrote:
For bluetooth device_move, the only child device of hci_conn dev is
the rfcomm tty_dev. How about the following patch, please verify :
There is now no oops, instead
On Thu, Jan 10, 2008 at 09:11:17AM +0800, Dave Young wrote:
> For bluetooth device_move, the only child device of hci_conn dev is
> the rfcomm tty_dev. How about the following patch, please verify :
There is now no oops, instead the keyboard becomes almost completely
unresponsible when I switch
On Thu, Jan 10, 2008 at 09:11:17AM +0800, Dave Young wrote:
For bluetooth device_move, the only child device of hci_conn dev is
the rfcomm tty_dev. How about the following patch, please verify :
There is now no oops, instead the keyboard becomes almost completely
unresponsible when I switch
Hi,
On Wed, Jan 09, 2008 at 06:16:02PM +0900, Tejun Heo wrote:
> Please confirm the attached patch fixes the oops. I'll separate it into
> two patches and forward them to Greg. But bluetooth code also needs to
> be updated such that it moves the refcommX device before killing the
> connection
Hi,
On Wed, Jan 09, 2008 at 06:16:02PM +0900, Tejun Heo wrote:
Please confirm the attached patch fixes the oops. I'll separate it into
two patches and forward them to Greg. But bluetooth code also needs to
be updated such that it moves the refcommX device before killing the
connection
On Wed, Jan 09, 2008 at 06:16:02PM +0900, Tejun Heo wrote:
> Hello,
>
> My laptop and cell finally decided to talk to each other and I could
> reproduce the bug here. The attached patch should remove the oops.
>
> The bug is two folded. I just skimmed through the bluetooth code and am
> very
On Wed, 09 Jan 2008 18:16:02 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> This isn't supported. sysfs doesn't allow parents to die first and the
> dangling children to be salvaged using sysfs_move().
But (with the sysfs bugs fixed) it will return an error, won't it? It
seems the bluetooth code
Hello,
My laptop and cell finally decided to talk to each other and I could
reproduce the bug here. The attached patch should remove the oops.
The bug is two folded. I just skimmed through the bluetooth code and am
very likely to wrong at places. Please correct me where I'm wrong.
1. It's
Hello,
My laptop and cell finally decided to talk to each other and I could
reproduce the bug here. The attached patch should remove the oops.
The bug is two folded. I just skimmed through the bluetooth code and am
very likely to wrong at places. Please correct me where I'm wrong.
1. It's
On Wed, 09 Jan 2008 18:16:02 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
This isn't supported. sysfs doesn't allow parents to die first and the
dangling children to be salvaged using sysfs_move().
But (with the sysfs bugs fixed) it will return an error, won't it? It
seems the bluetooth code is
On Wed, Jan 09, 2008 at 06:16:02PM +0900, Tejun Heo wrote:
Hello,
My laptop and cell finally decided to talk to each other and I could
reproduce the bug here. The attached patch should remove the oops.
The bug is two folded. I just skimmed through the bluetooth code and am
very likely
On Tue, Jan 08, 2008 at 06:42:43PM +0900, Tejun Heo wrote:
> Thanks. Please apply the attached patch and report the oops.
Jan 8 14:23:29 twister kernel: XXX: moving /devices/virtual/tty/rfcomm0 under
/devices/pci:00/:00:02.0/usb1/1-3/1-3:1.0/hci0/acl001BAFE1624D/tty
Jan 8 14:23:29
Gabor Gombas wrote:
> On Tue, Jan 08, 2008 at 12:24:05AM +0900, Tejun Heo wrote:
>
>> Does the attached patch fix the problem?
>
> No, it still oopses.
Thanks. Please apply the attached patch and report the oops.
--
tejun
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
diff
Gabor Gombas wrote:
On Tue, Jan 08, 2008 at 12:24:05AM +0900, Tejun Heo wrote:
Does the attached patch fix the problem?
No, it still oopses.
Thanks. Please apply the attached patch and report the oops.
--
tejun
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
diff --git
On Tue, Jan 08, 2008 at 06:42:43PM +0900, Tejun Heo wrote:
Thanks. Please apply the attached patch and report the oops.
Jan 8 14:23:29 twister kernel: XXX: moving /devices/virtual/tty/rfcomm0 under
/devices/pci:00/:00:02.0/usb1/1-3/1-3:1.0/hci0/acl001BAFE1624D/tty
Jan 8 14:23:29
On Tue, Jan 08, 2008 at 12:24:05AM +0900, Tejun Heo wrote:
> Does the attached patch fix the problem?
No, it still oopses.
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of
Gabor Gombas wrote:
> Hi,
>
> On Sat, Jan 05, 2008 at 07:50:39AM +, Al Viro wrote:
>
>> Could you stick
>> if (!parent->d_inode)
>> printk(KERN_WARNING "sysfs locking blows: %s",
>> parent->d_name.name);
>> right before
>>
Hi,
On Sat, Jan 05, 2008 at 07:50:39AM +, Al Viro wrote:
> Could you stick
> if (!parent->d_inode)
> printk(KERN_WARNING "sysfs locking blows: %s",
> parent->d_name.name);
> right before
> mutex_lock(>d_inode->i_mutex);
>
Hi,
On Fri, Jan 04, 2008 at 09:05:42AM +0800, Dave Young wrote:
> Could you try the patch (on 2.6.24-rc6) following and check the debug
> messages?
>
> diff -upr linux/net/bluetooth/rfcomm/tty.c
> linux.new/net/bluetooth/rfcomm/tty.c
> --- linux/net/bluetooth/rfcomm/tty.c 2008-01-04
Al Viro <[EMAIL PROTECTED]> writes:
> On Mon, Jan 07, 2008 at 06:18:21PM +0900, Tejun Heo wrote:
>> Tejun Heo wrote:
>> > Eric W. Biederman wrote:
>> >>> That said, the mechanism is a bit too fragile. sysfs currently ensures
>> >>> that dentry/inode point to the associated sysfs_dirent. This is
On Mon, Jan 07, 2008 at 06:18:21PM +0900, Tejun Heo wrote:
> Tejun Heo wrote:
> > Eric W. Biederman wrote:
> >>> That said, the mechanism is a bit too fragile. sysfs currently ensures
> >>> that dentry/inode point to the associated sysfs_dirent. This is mainly
> >>> remanent of conversion from
Tejun Heo wrote:
> Eric W. Biederman wrote:
>>> That said, the mechanism is a bit too fragile. sysfs currently ensures
>>> that dentry/inode point to the associated sysfs_dirent. This is mainly
>>> remanent of conversion from previous VFS based implementation. I think
>>> the right thing to do
Eric W. Biederman wrote:
>> That said, the mechanism is a bit too fragile. sysfs currently ensures
>> that dentry/inode point to the associated sysfs_dirent. This is mainly
>> remanent of conversion from previous VFS based implementation. I think
>> the right thing to do here is to make sysfs
Tejun Heo <[EMAIL PROTECTED]> writes:
> Hello,
>
> Tejun Heo wrote:
>> Al Viro wrote:
>>> On Sat, Jan 05, 2008 at 11:30:25PM +0900, Tejun Heo wrote:
> Assuming that this is what we get, everything looks explainable - we
> have sysfs_rename_dir() calling sysfs_get_dentry() while the parent
Dave Young wrote:
> On Thu, Jan 03, 2008 at 02:16:21PM +0100, Gabor Gombas wrote:
>> On Wed, Jan 02, 2008 at 04:16:42PM +0100, Gabor Gombas wrote:
>>
>>> So the patch referenced above does not help. But I've found a very easy
>>> way to trigger the bug:
>>>
>>> - do a "cat /dev/zero >
Dave Young wrote:
On Thu, Jan 03, 2008 at 02:16:21PM +0100, Gabor Gombas wrote:
On Wed, Jan 02, 2008 at 04:16:42PM +0100, Gabor Gombas wrote:
So the patch referenced above does not help. But I've found a very easy
way to trigger the bug:
- do a cat /dev/zero /dev/rfcomm0
- switch the
Tejun Heo [EMAIL PROTECTED] writes:
Hello,
Tejun Heo wrote:
Al Viro wrote:
On Sat, Jan 05, 2008 at 11:30:25PM +0900, Tejun Heo wrote:
Assuming that this is what we get, everything looks explainable - we
have sysfs_rename_dir() calling sysfs_get_dentry() while the parent
gets evicted. We
Eric W. Biederman wrote:
That said, the mechanism is a bit too fragile. sysfs currently ensures
that dentry/inode point to the associated sysfs_dirent. This is mainly
remanent of conversion from previous VFS based implementation. I think
the right thing to do here is to make sysfs behave
Tejun Heo wrote:
Eric W. Biederman wrote:
That said, the mechanism is a bit too fragile. sysfs currently ensures
that dentry/inode point to the associated sysfs_dirent. This is mainly
remanent of conversion from previous VFS based implementation. I think
the right thing to do here is to
On Mon, Jan 07, 2008 at 06:18:21PM +0900, Tejun Heo wrote:
Tejun Heo wrote:
Eric W. Biederman wrote:
That said, the mechanism is a bit too fragile. sysfs currently ensures
that dentry/inode point to the associated sysfs_dirent. This is mainly
remanent of conversion from previous VFS
Al Viro [EMAIL PROTECTED] writes:
On Mon, Jan 07, 2008 at 06:18:21PM +0900, Tejun Heo wrote:
Tejun Heo wrote:
Eric W. Biederman wrote:
That said, the mechanism is a bit too fragile. sysfs currently ensures
that dentry/inode point to the associated sysfs_dirent. This is mainly
remanent
Gabor Gombas wrote:
Hi,
On Sat, Jan 05, 2008 at 07:50:39AM +, Al Viro wrote:
Could you stick
if (!parent-d_inode)
printk(KERN_WARNING sysfs locking blows: %s,
parent-d_name.name);
right before
On Tue, Jan 08, 2008 at 12:24:05AM +0900, Tejun Heo wrote:
Does the attached patch fix the problem?
No, it still oopses.
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of
Hello,
Tejun Heo wrote:
> Al Viro wrote:
>> On Sat, Jan 05, 2008 at 11:30:25PM +0900, Tejun Heo wrote:
Assuming that this is what we get, everything looks explainable - we
have sysfs_rename_dir() calling sysfs_get_dentry() while the parent
gets evicted. We don't have any
Hello,
Tejun Heo wrote:
Al Viro wrote:
On Sat, Jan 05, 2008 at 11:30:25PM +0900, Tejun Heo wrote:
Assuming that this is what we get, everything looks explainable - we
have sysfs_rename_dir() calling sysfs_get_dentry() while the parent
gets evicted. We don't have any exclusion, so while we
Hello,
Al Viro wrote:
> On Sun, Jan 06, 2008 at 11:54:43AM +0900, Tejun Heo wrote:
>> That means sysfs_remove_dir() is called on parent while other operations
>> are in progress on children, right? sysfs has never allowed such things
>> && AFAIK no one does that. It's somewhat implied in the
On Sun, Jan 06, 2008 at 11:54:43AM +0900, Tejun Heo wrote:
> That means sysfs_remove_dir() is called on parent while other operations
> are in progress on children, right? sysfs has never allowed such things
> && AFAIK no one does that. It's somewhat implied in the interface (such
> as recursive
Hello, Al Viro.
Al Viro wrote:
> On Sun, Jan 06, 2008 at 11:07:52AM +0900, Tejun Heo wrote:
>
>> Right, I haven't thought about that. When sysfs_get_dentry() is called,
>> @sd is always valid so unless there was existing negative dentry, lookup
>> is guaranteed to return positive dentry, but by
On Sun, Jan 06, 2008 at 11:07:52AM +0900, Tejun Heo wrote:
> Right, I haven't thought about that. When sysfs_get_dentry() is called,
> @sd is always valid so unless there was existing negative dentry, lookup
> is guaranteed to return positive dentry, but by populating dcache with
> negative
Hello,
Al Viro wrote:
> On Sat, Jan 05, 2008 at 11:30:25PM +0900, Tejun Heo wrote:
>>> Assuming that this is what we get, everything looks explainable - we
>>> have sysfs_rename_dir() calling sysfs_get_dentry() while the parent
>>> gets evicted. We don't have any exclusion, so while we are
On Sat, Jan 05, 2008 at 11:30:25PM +0900, Tejun Heo wrote:
> > Assuming that this is what we get, everything looks explainable - we
> > have sysfs_rename_dir() calling sysfs_get_dentry() while the parent
> > gets evicted. We don't have any exclusion, so while we are playing
> > silly buggers with
Hello.
Al Viro wrote:
> sysfs_get_dentry(),
> mutex_lock(>d_inode->i_mutex);
> hitting parent->d_inode either NULL or very close to it, depending on your
> .config; most likely NULL, if offset of i_mutex is 0xb8 in your build.
> That's plausible - 0xb8 is what you'd get on UP
Hello.
Al Viro wrote:
sysfs_get_dentry(),
mutex_lock(parent-d_inode-i_mutex);
hitting parent-d_inode either NULL or very close to it, depending on your
.config; most likely NULL, if offset of i_mutex is 0xb8 in your build.
That's plausible - 0xb8 is what you'd get on UP build
On Sat, Jan 05, 2008 at 11:30:25PM +0900, Tejun Heo wrote:
Assuming that this is what we get, everything looks explainable - we
have sysfs_rename_dir() calling sysfs_get_dentry() while the parent
gets evicted. We don't have any exclusion, so while we are playing
silly buggers with lookups
On Sun, Jan 06, 2008 at 11:07:52AM +0900, Tejun Heo wrote:
Right, I haven't thought about that. When sysfs_get_dentry() is called,
@sd is always valid so unless there was existing negative dentry, lookup
is guaranteed to return positive dentry, but by populating dcache with
negative dentry
Hello, Al Viro.
Al Viro wrote:
On Sun, Jan 06, 2008 at 11:07:52AM +0900, Tejun Heo wrote:
Right, I haven't thought about that. When sysfs_get_dentry() is called,
@sd is always valid so unless there was existing negative dentry, lookup
is guaranteed to return positive dentry, but by
Hello,
Al Viro wrote:
On Sun, Jan 06, 2008 at 11:54:43AM +0900, Tejun Heo wrote:
That means sysfs_remove_dir() is called on parent while other operations
are in progress on children, right? sysfs has never allowed such things
AFAIK no one does that. It's somewhat implied in the interface
On Sun, Jan 06, 2008 at 11:54:43AM +0900, Tejun Heo wrote:
That means sysfs_remove_dir() is called on parent while other operations
are in progress on children, right? sysfs has never allowed such things
AFAIK no one does that. It's somewhat implied in the interface (such
as recursive
On Wed, Jan 02, 2008 at 04:16:42PM +0100, Gabor Gombas wrote:
> Heh, it seems talking about a bug makes it trigger:
>
> Jan 2 16:05:45 twister kernel: Unable to handle kernel NULL pointer
> dereference at 00b8 RIP:
> Jan 2 16:05:45 twister kernel: [] mutex_lock+0x10/0x1d
> So
On Wed, Jan 02, 2008 at 04:16:42PM +0100, Gabor Gombas wrote:
Heh, it seems talking about a bug makes it trigger:
Jan 2 16:05:45 twister kernel: Unable to handle kernel NULL pointer
dereference at 00b8 RIP:
Jan 2 16:05:45 twister kernel: [804720a5]
On Thu, Jan 03, 2008 at 02:16:21PM +0100, Gabor Gombas wrote:
> On Wed, Jan 02, 2008 at 04:16:42PM +0100, Gabor Gombas wrote:
>
> > So the patch referenced above does not help. But I've found a very easy
> > way to trigger the bug:
> >
> > - do a "cat /dev/zero > /dev/rfcomm0"
> > - switch the
On Wed, Jan 02, 2008 at 04:16:42PM +0100, Gabor Gombas wrote:
> So the patch referenced above does not help. But I've found a very easy
> way to trigger the bug:
>
> - do a "cat /dev/zero > /dev/rfcomm0"
> - switch the phone off
> - switch the phone on, and the kernel oopses
FYI I also remember
On Wed, Jan 02, 2008 at 04:16:42PM +0100, Gabor Gombas wrote:
So the patch referenced above does not help. But I've found a very easy
way to trigger the bug:
- do a cat /dev/zero /dev/rfcomm0
- switch the phone off
- switch the phone on, and the kernel oopses
FYI I also remember having
On Sat, Dec 29, 2007 at 04:07:04PM +0800, Dave Young wrote:
> Please try the -mm tree kernel, might have been fixed by :
> http://lkml.org/lkml/2007/11/18/141
Heh, it seems talking about a bug makes it trigger:
Jan 2 16:05:45 twister kernel: Unable to handle kernel NULL pointer
dereference at
On Sat, Dec 29, 2007 at 04:07:04PM +0800, Dave Young wrote:
> Please try the -mm tree kernel, might have been fixed by :
> http://lkml.org/lkml/2007/11/18/141
I've applied the patch on top of 2.6.24-rc6 (I don't want to run -mm
kernels on this machine). We'll see what happens.
Gabor
--
On Sat, Dec 29, 2007 at 04:07:04PM +0800, Dave Young wrote:
Please try the -mm tree kernel, might have been fixed by :
http://lkml.org/lkml/2007/11/18/141
I've applied the patch on top of 2.6.24-rc6 (I don't want to run -mm
kernels on this machine). We'll see what happens.
Gabor
--
On Sat, Dec 29, 2007 at 04:07:04PM +0800, Dave Young wrote:
Please try the -mm tree kernel, might have been fixed by :
http://lkml.org/lkml/2007/11/18/141
Heh, it seems talking about a bug makes it trigger:
Jan 2 16:05:45 twister kernel: Unable to handle kernel NULL pointer
dereference at
On Dec 29, 2007 1:32 AM, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm using my phone as a GPRS modem over Bluetooth. Sometimes Bluetooth
> on the phone seems to stall and the phone has to be switched off & on to
> get it back to a sane state. During this I sometimes get the following
>
On Dec 29, 2007 1:32 AM, Gabor Gombas [EMAIL PROTECTED] wrote:
Hi,
I'm using my phone as a GPRS modem over Bluetooth. Sometimes Bluetooth
on the phone seems to stall and the phone has to be switched off on to
get it back to a sane state. During this I sometimes get the following
Oops (this
84 matches
Mail list logo
