All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: semaphore woes in 2.6, 32bit
Date: Fri, 7 May 2004 18:10:31 -0700	[thread overview]
Message-ID: <20040507181031.F9702@mvista.com> (raw)


I got a bunch of segfaults which are due to HAS_LLSCD cpu operating
on a semaphore which is aligned along 4-byte boundary instead of the
desired 8-byte boundary.

I traced down one such place at serial/serial_core.c:

int uart_register_driver(struct uart_driver *drv)
{
        struct tty_driver *normal = NULL;
        int i, retval;

        BUG_ON(drv->state);

        /*
         * Maybe we should be using a slab cache for this, especially if
         * we have a large number of ports to handle.
         */
        drv->state = kmalloc(sizeof(struct uart_state) * drv->nr, GFP_KERNEL);
...

where drv->state contains a semaphore variable, but apparently kmalloc() only
give 4-byte boundary alignment.

There are many other faults, which I did not bother to trace down.
Simply removing CPU_HAS_LLSCD makes the problem go away, which probably indicates
they are all of the same nature.

I wonder why this problem only shows up now while it did not show up
earlier when we introduced the new up().  Perhaps kmalloc() always
returns 8-byte aligned blocks?

I can't think of an immediate and good fix.  Hopefully someone else smarter
than me can find a solution before I come back to it on Monday.  :)

Jun

             reply	other threads:[~2004-05-08  1:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-08  1:10 Jun Sun [this message]
2004-05-08  7:18 ` semaphore woes in 2.6, 32bit Ralf Baechle
2004-05-09  5:48   ` Jun Sun
2004-05-09  9:09     ` Geert Uytterhoeven
2004-05-09 12:57       ` Ralf Baechle
2004-05-09 13:56         ` Atsushi Nemoto
2004-05-09 16:48           ` Ralf Baechle
2004-05-10 13:28             ` Atsushi Nemoto
2004-05-10 14:06               ` Ralf Baechle
2004-05-11 13:53                 ` Atsushi Nemoto
2004-05-11 14:05                   ` Ralf Baechle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040507181031.F9702@mvista.com \
    --to=jsun@mvista.com \
    --cc=linux-mips@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.