From: Ralf Baechle <ralf@linux-mips.org>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: stern@rowland.harvard.edu, jim.ramsay@gmail.com,
mdharm-kernel@one-eyed-alien.net,
linux-usb-users@lists.sourceforge.net,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-usb-devel@lists.sourceforge.net
Subject: Re: [Linux-usb-users] Possible bug in usb storage (2.6.11 kernel)
Date: Fri, 30 Sep 2005 17:48:45 +0100 [thread overview]
Message-ID: <20050930164845.GA14585@linux-mips.org> (raw)
In-Reply-To: <20050929.012705.37532453.anemo@mba.ocn.ne.jp>
On Thu, Sep 29, 2005 at 01:27:05AM +0900, Atsushi Nemoto wrote:
> >>>>> On Tue, 27 Sep 2005 11:38:35 -0400 (EDT), Alan Stern <stern@rowland.harvard.edu> said:
>
> stern> If that is so, it's a bug in linux-mips. ARCH_KMALLOC_MINALIGN
> stern> is supposed to be at least as large as a cacheline. See this
> stern> comment in mm/slab.c:
>
> Thank you for pointing out this.
>
> Some time ago I also supposed so, but I was told to use
> dma_get_cache_alignment() instead. The comment was not exist at that
> time...
ARCH_KMALLOC_MINALIGN is set to 8 on MIPS because we used to have 64-bit
members in struct semaphore but on 32-bit kernels kmalloc would return 4-byte
allocated memory only. Whoops, an ooops ;) Obviously that's been a thinko
as it was done without consideration for DMA.
Coherent I/O isn't affected, also there are a few R3000-class processors where
8 bytes happens to be just the right value. For anything else this is a bug
which we probably get away most of the time and the value should would be
the largest size of any cacheline in the cache hierarchy, so upto 128 for some
systems.
Ralf
next prev parent reply other threads:[~2005-09-30 16:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4789af9e05090810142bd3531d@mail.gmail.com>
[not found] ` <20050908175852.GA3196@one-eyed-alien.net>
[not found] ` <4789af9e05090812521d9d687b@mail.gmail.com>
2005-09-08 20:28 ` [Linux-usb-users] Possible bug in usb storage (2.6.11 kernel) Jim Ramsay
2005-09-08 20:40 ` Alan Stern
2005-09-27 13:38 ` Atsushi Nemoto
2005-09-27 14:21 ` [Linux-usb-users] " Alan Stern
2005-09-27 14:46 ` Atsushi Nemoto
2005-09-27 15:38 ` [Linux-usb-users] " Alan Stern
2005-09-28 16:27 ` Atsushi Nemoto
2005-09-30 16:48 ` Ralf Baechle [this message]
2005-09-08 20:43 ` Matthew Dharm
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=20050930164845.GA14585@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=anemo@mba.ocn.ne.jp \
--cc=jim.ramsay@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=linux-usb-users@lists.sourceforge.net \
--cc=mdharm-kernel@one-eyed-alien.net \
--cc=stern@rowland.harvard.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).