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
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 put_de
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 }
> > 13
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;
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 doe
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 b
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 PROTEC
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
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 rfc
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, i
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 o
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 n
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 li
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 int
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 twi
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 --g
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 Sci
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
>> mutex_lock(&par
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(&parent->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 08:58:48
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 pr
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 h
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 be
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 > /dev/rfcomm0"
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,
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 int
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 dentr
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 playin
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(&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
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 th
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 ph
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 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 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
> Oop
45 matches
Mail list logo
