linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@osdl.org>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Add sparse "__iomem" infrastructure to check PCI address usage
Date: Sun, 12 Sep 2004 19:31:41 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.58.0409121922450.13491@ppc970.osdl.org> (raw)
In-Reply-To: <4144E93E.5030404@pobox.com>



On Sun, 12 Sep 2004, Jeff Garzik wrote:
>
> Linux Kernel Mailing List wrote:
> > --- a/include/linux/compiler.h	2004-09-11 00:26:40 -07:00
> > +++ b/include/linux/compiler.h	2004-09-11 00:26:40 -07:00
> > @@ -6,13 +6,17 @@
> >  # define __kernel	/* default address space */
> >  # define __safe		__attribute__((safe))
> >  # define __force	__attribute__((force))
> > +# define __iomem	__attribute__((noderef, address_space(2)))
> 
> Dumb gcc attribute questions:
> 
> 1) what does force do? it doesn't appear to be in gcc 3.3.3 docs.

It doesn't do anything for gcc. You're looking at the sparse-only code.

What "attribute((force))" does for sparse is to mark a type to be 
"forced", ie a cast to a forced type will not complain even if the cast 
otherwise would be invalid.

For example, "sparse" will warn about explicit casts that drop address 
space information:

	void __user *userptr;

	...
	memset((void *)userptr, 0, ...)

will cause a

	warning: cast removes address space of expression

complaint from sparse. But some _internal_ functions want to force the 
cast because they know it's safe. For example, you'll find

	#define __addr_ok(addr) ((unsigned long __force)(addr) < (current_thread_info()->addr_limit.seg))

because this internal x86 implementation detail knows that in that 
particular case it's safe to remove the address space information (it's 
just checking the user pointer against the address limit).

For gcc, none of this means anything, so all the #define's just become 
empty.

> 2) is "volatile ... __force" redundant?

No, although it's likely to be a strange combination. If you want to force 
a static address space conversion to a volatile pointer, you can do so. I 
don't see _why_ you'd want to do it ;)

> 3) can we use 'malloc' attribute on kmalloc?

Since we can't use the gcc alias analysis anyway (it's too broken until
very late gcc versions), the gcc 'malloc' attribute shouldn't make any
difference that I can tell.

But there wouldn't be anything _wrong_ in adding it to kmalloc(), if 
that's what you're asking.

		Linus

  parent reply	other threads:[~2004-09-13  2:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200409110726.i8B7QTGn009468@hera.kernel.org>
2004-09-13  0:26 ` Add sparse "__iomem" infrastructure to check PCI address usage Jeff Garzik
2004-09-13  0:50   ` David S. Miller
2004-09-13  2:31   ` Linus Torvalds [this message]
2004-09-13  2:41     ` Jeff Garzik
2004-09-13  3:00       ` Linus Torvalds
2004-09-13 14:22         ` Geert Uytterhoeven
2004-09-13 14:33           ` Linus Torvalds
2004-09-13 18:31         ` Tonnerre
2004-09-13 18:48           ` Linus Torvalds
2004-09-13 18:51           ` viro

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=Pine.LNX.4.58.0409121922450.13491@ppc970.osdl.org \
    --to=torvalds@osdl.org \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.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 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).