linux-kernel - Re: locks inside receive

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1302008671.17430.10.camel@frodo>
Date:	Tue, 05 Apr 2011 09:04:31 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Pavan Savoy <pavan_savoy@...y.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org
Subject: Re: locks inside receive_buf

On Tue, 2011-04-05 at 16:43 +0530, Pavan Savoy wrote:

> > The program counter is at st_int_recv+0x2a0 when this happened, so that
> > function is probably where you accessed some structure that was not
> > initialized.
> >
> >        foo->bar
> >
> > if foo is NULL, you'll get that error.
> >
> >> LR is at schedule+0x414/0x4e8
> >
> > LR is Link Register, or where this function was called from.
> >
> > Now why is the scheduler calling your function, I have no idea.
> 
> Well this is exactly the problem I have and hence the question
> regarding sleep in tty's receive_buf function.
> 
> the function called st_recv or st_int_recv() is basically my line
> discipline's receive_buf function - which happens like zillions of
> times properly with tty->disc_data being populated with what I
> need....
> 
> However on a corner case - when I perform some operation - which has
> absolutely NO relation to TTY (at most may be console is using 1 uart)
> - Everything breaks loose...

Well, if this corner case that you perform causes the corruption, I
think they are related. What corner case do you do?

> 
> If I bump into a NULL pointer it is because the tty->disc_data is NULL ....
> However my check for tty->disc_data being NULL also is fine - i.e when
> I do get this error - my disc_data is NOT null ... But not sure what
> (which data) is NULL ??

How are you checking for NULL?

	if (data == NULL)

may not work as the error shows:

"Unable to handle kernel NULL pointer dereference at virtual address 0000001a"

Where data (or what ever it was using) was 0x1a not 0. We consider NULL
anything less that a page size. Because of something just like this. You
have a structure pointer that is NULL, accessing the element may not be
NULL.

> 
> So now back to the question - What cannot I do inside tty's receive_buf ?

I don't know, but it may not be the issue. Something else may be broken.

Perhaps you can't schedule, which means you can't use something like a
mutex. But if that was the issue, the scheduler itself would give you a
nasty warning that you are scheduling in non-schedulable context.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/