Re: [PATCH]bluetooth rfcomm_dev refcount bug fix

2007-11-06 Thread Dave Young
On Nov 6, 2007 9:33 PM, Marcel Holtmann <[EMAIL PROTECTED]> wrote: > Hi Dave, > > > I'm afraid to be considered as spam ;) > > > > (Due to timezone offset, I have to mail again and cann't wait for your > > reply, sorry for the annoying) > > I am in a different timezone every other week. So nevermin

Re: [PATCH]bluetooth rfcomm_dev refcount bug fix

2007-11-06 Thread Marcel Holtmann
Hi Dave, > I'm afraid to be considered as spam ;) > > (Due to timezone offset, I have to mail again and cann't wait for your > reply, sorry for the annoying) I am in a different timezone every other week. So nevermind ;) > I think the rfcomm_dev_put could be seperated from the rfcomm_dev_put, >

Re: [PATCH]bluetooth rfcomm_dev refcount bug fix

2007-11-05 Thread Dave Young
Hi marcel, I'm afraid to be considered as spam ;) (Due to timezone offset, I have to mail again and cann't wait for your reply, sorry for the annoying) I think the rfcomm_dev_put could be seperated from the rfcomm_dev_put, it will be more straitforward then. please consider below patch, tested o

Re: [PATCH]bluetooth rfcomm_dev refcount bug fix

2007-11-05 Thread Dave Young
On 11/5/07, Marcel Holtmann <[EMAIL PROTECTED]> wrote: > Hi Dave, > > > In the rfcomm_tty_hangup the rfcomm_dev refcnt should be dropped later. > > > > If rfcomm_dev is destructed in tty_hangup function, then the later > > tty_close function will oops. > > your patch removes the complete release o

Re: [PATCH]bluetooth rfcomm_dev refcount bug fix

2007-11-05 Thread Dave Young
On 11/5/07, Marcel Holtmann <[EMAIL PROTECTED]> wrote: > Hi Dave, > > > In the rfcomm_tty_hangup the rfcomm_dev refcnt should be dropped later. > > > > If rfcomm_dev is destructed in tty_hangup function, then the later > > tty_close function will oops. > > your patch removes the complete release o

Re: [PATCH]bluetooth rfcomm_dev refcount bug fix

2007-11-05 Thread Marcel Holtmann
Hi Dave, > In the rfcomm_tty_hangup the rfcomm_dev refcnt should be dropped later. > > If rfcomm_dev is destructed in tty_hangup function, then the later tty_close > function will oops. your patch removes the complete release on hangup logic. That can't be right. I think the problem is with cal

[PATCH]bluetooth rfcomm_dev refcount bug fix

2007-11-04 Thread Dave Young
In the rfcomm_tty_hangup the rfcomm_dev refcnt should be dropped later. If rfcomm_dev is destructed in tty_hangup function, then the later tty_close function will oops. BUG: unable to handle kernel NULL pointer dereference at virtual address 0008 printing eip: c01c0884 *pde = Oops