mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: Peter Zaitcev <zaitcev@redhat.com>,
	"David S. Miller" <davem@redhat.com>,
	Russell King <rmk@arm.linux.org.uk>,
	linux-usb-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: SLAB vs. pci_alloc_xxx in usb-uhci patch
Date: Wed, 07 Mar 2001 09:43:11 -0800	[thread overview]
Message-ID: <003501c0a72e$168c46c0$6800000a@brownell.org> (raw)
In-Reply-To: <20010306004454.A12846@devserv.devel.redhat.com> <023301c0a693$087591e0$6800000a@brownell.org> <3AA5DDCC.7F9CBA91@colorfullife.com>

> > (1) CONFIG_SLAB_DEBUG breaks the documented
> > requirement that the slab cache return adequately aligned
> > data ...
> 
> adequately aligned for the _cpu_, not for some controllers. It's neither
> documented that HW_CACHEALIGN aligns to 16 byte boundaries

It's documented in mm/slab.c (line 612 in my ac7+tweaks).
"Aligns to hardware cache line."  The only cacheline define
I've found is in <asm/cache.h> for L1_CACHE_BYTES,
which is often more than 16 (not on x86).

If you don't like the patch I forwarded, then please submit
one that changes the kmem_cache_create() API spec ...
one or the other is needed.  (I'd not change that API!!)


> nor that kmalloc uses HW_CACHEALIGN. ...
>
> > + /* redzoning would break cache alignment requirements */
> > + if (flags & SLAB_HWCACHE_ALIGN)
> > +  flags &= ~SLAB_RED_ZONE;
> 
> The problem is that you've just disabled red zoning for kmalloc.   And
> kmalloc is the only case where redzoning is important: ...

If kmalloc wants to get auto redzoning, then I think it shouldn't be
using SLAB_HWCACHE_ALIGN when CONFIG_SLAB_DEBUG.
That'd be another simple fix.  (Or, make it use some new flag that's
just a performance hint that can be ignored for debugging.)

 
> I think everyone agrees that (2) correct fix.

I was saying that there were two bugs (two fixes needed), and you're
saying that there's only one ... despite the evidence of the API spec.
But you could persuade me there's a third bug:  kmalloc misuse of
that kmem_cache API.


> I see 2 temporary workarounds: either your patch or
> 
> + #ifdef CONFIG_SLAB_DEBUG
> + #error
> + #endif
> 
> in uhci.c.

Better in linux/drivers/usb/Config.in instead.  All the host controller
drivers rely on the kmem_cache_create() API spec to be followed.
(Even the OHCI driver, when using kmalloc not kmem_cache.)

- Dave



  reply	other threads:[~2001-03-07 17:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-06  5:44 Peter Zaitcev
2001-03-06 23:13 ` David Brownell
2001-03-07  7:05   ` Manfred Spraul
2001-03-07 17:43     ` David Brownell [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-03-05 22:08 Manfred Spraul
2001-03-05 22:52 ` David Brownell
2001-03-05 23:20   ` Russell King
2001-03-06  2:09     ` Alan Cox
2001-03-06  4:53   ` David S. Miller
2001-03-05 19:23 Peter Zaitcev

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='003501c0a72e$168c46c0$6800000a@brownell.org' \
    --to=david-b@pacbell.net \
    --cc=davem@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=manfred@colorfullife.com \
    --cc=rmk@arm.linux.org.uk \
    --cc=zaitcev@redhat.com \
    /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

all inboxes | Powered by JetHome®