Group,
To my reading of the function, I think gcc has a point:
drivers/serial/8250.c: In function 'serial8250_shutdown':
drivers/serial/8250.c:1685: warning: 'i' may be used uninitialized in this function
It does read as if the code might try to initialize
the 'lock' field of a null pointer.
Suggestions?
Mike
> To my reading of the function, I think gcc has a point:
>
> drivers/serial/8250.c: In function 'serial8250_shutdown':
> drivers/serial/8250.c:1685: warning: 'i' may be used uninitialized in this function
>
> It does read as if the code might try to initialize
> the 'lock' field of a null pointer.
The code in question is:
static void serial_unlink_irq_chain(struct uart_8250_port *up)
{
struct irq_info *i;
struct hlist_node *n;
struct hlist_head *h;
mutex_lock(&hash_mutex);
h = &irq_lists[up->port.irq % NR_IRQ_HASH];
hlist_for_each(n, h) {
i = hlist_entry(n, struct irq_info, node);
if (i->irq == up->port.irq)
break;
}
BUG_ON(n == NULL);
BUG_ON(i->head == NULL);
if (list_empty(i->head))
free_irq(up->port.irq, i);
and if the hlist_for_each() doesn't find a matching irq_info to put in
i, then the BUG_ON(n == NULL) will kill the system. So there's no bug
although it is understandable that gcc can't see that.
(Not sure why you talk about "the 'lock' field of a null pointer" -- I
assume your gcc warns about the function serial8250_shutdown() because
it is inlining a function only called from a single location)
- R.
On Fri June 5 2009, Roland Dreier wrote:
> > To my reading of the function, I think gcc has a point:
> >
> > drivers/serial/8250.c: In function 'serial8250_shutdown':
> > drivers/serial/8250.c:1685: warning: 'i' may be used uninitialized in this function
> >
> > It does read as if the code might try to initialize
> > the 'lock' field of a null pointer.
>
> The code in question is:
>
> static void serial_unlink_irq_chain(struct uart_8250_port *up)
> {
> struct irq_info *i;
> struct hlist_node *n;
> struct hlist_head *h;
>
> mutex_lock(&hash_mutex);
>
> h = &irq_lists[up->port.irq % NR_IRQ_HASH];
>
> hlist_for_each(n, h) {
> i = hlist_entry(n, struct irq_info, node);
> if (i->irq == up->port.irq)
> break;
> }
>
> BUG_ON(n == NULL);
> BUG_ON(i->head == NULL);
>
> if (list_empty(i->head))
> free_irq(up->port.irq, i);
>
> and if the hlist_for_each() doesn't find a matching irq_info to put in
> i, then the BUG_ON(n == NULL) will kill the system. So there's no bug
> although it is understandable that gcc can't see that.
>
> (Not sure why you talk about "the 'lock' field of a null pointer" -- I
> assume your gcc warns about the function serial8250_shutdown() because
> it is inlining a function only called from a single location)
>
Later in the code that gcc thought had the problem - -
where it tries to do a spinlock_init(i->lock).
Of course, I, just like gcc, did not know the machine had already died.
I'll stick an "i = something" at the top (NULL?) just to shut up gcc.
Mike
> - R.
>
>
> I'll stick an "i = something" at the top (NULL?) just to shut up gcc.
you can do uninitialized_var(i) as a zero-overhead way to handle this.
On Fri, 5 Jun 2009 11:43:03 -0500
"Michael S. Zick" <[email protected]> wrote:
> Group,
>
> To my reading of the function, I think gcc has a point:
>
> drivers/serial/8250.c: In function 'serial8250_shutdown':
> drivers/serial/8250.c:1685: warning: 'i' may be used uninitialized in this function
>
> It does read as if the code might try to initialize
> the 'lock' field of a null pointer.
>
> Suggestions?
Newer gcc ? At least current gcc appears to correctly deduce the code is
safe.
Alan
> Of course, I, just like gcc, did not know the machine had already died.
> I'll stick an "i = something" at the top (NULL?) just to shut up gcc.
And it will not get merged. Current gcc understands the code perfectly
well.
On Fri, 5 Jun 2009 19:01:38 +0100
Alan Cox <[email protected]> wrote:
> On Fri, 5 Jun 2009 11:43:03 -0500
> "Michael S. Zick" <[email protected]> wrote:
>
> > Group,
> >
> > To my reading of the function, I think gcc has a point:
> >
> > drivers/serial/8250.c: In function 'serial8250_shutdown':
> > drivers/serial/8250.c:1685: warning: 'i' may be used uninitialized in this function
> >
> > It does read as if the code might try to initialize
> > the 'lock' field of a null pointer.
> >
> > Suggestions?
>
> Newer gcc ? At least current gcc appears to correctly deduce the code is
> safe.
That's a gcc regression isn't it?
static void serial_unlink_irq_chain(struct uart_8250_port *up)
{
struct irq_info *i;
struct hlist_node *n;
struct hlist_head *h;
mutex_lock(&hash_mutex);
h = &irq_lists[up->port.irq % NR_IRQ_HASH];
hlist_for_each(n, h) {
i = hlist_entry(n, struct irq_info, node);
if (i->irq == up->port.irq)
break;
}
#define hlist_for_each(pos, head) \
for (pos = (head)->first; pos && ({ prefetch(pos->next); 1; }); \
pos = pos->next)
I don't think there's any way in which gcc can deduce that h->first is
non-zero on entry to that loop. Even if it inlines
serial_unlink_irq_chain() into serial8250_shutdown().
> I don't think there's any way in which gcc can deduce that h->first is
> non-zero on entry to that loop. Even if it inlines
> serial_unlink_irq_chain() into serial8250_shutdown().
Why does it care ?
Suppose the list is empty, n is loaded with NULL
That follows the BUG_ON path which expands to include a function marked
as not returning
gcc is just rather smarter than your average cc
On Fri, 5 Jun 2009 23:06:41 +0100
Alan Cox <[email protected]> wrote:
> > I don't think there's any way in which gcc can deduce that h->first is
> > non-zero on entry to that loop. Even if it inlines
> > serial_unlink_irq_chain() into serial8250_shutdown().
>
> Why does it care ?
>
> Suppose the list is empty, n is loaded with NULL
>
> That follows the BUG_ON path which expands to include a function marked
> as not returning
Ah, OK.
btw, I think there are still several architectures whose BUG() isn't
correctly set up to tell gcc that it doesn't return. Not that this is
a reason to change the serial code.