All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ftp.linux.org.uk>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: linux-kernel@vger.kernel.org, Linus Torvalds <torvalds@osdl.org>
Subject: [RFC] gfp flags annotations
Date: Thu, 6 Oct 2005 21:15:34 +0100	[thread overview]
Message-ID: <20051006201534.GX7992@ftp.linux.org.uk> (raw)
In-Reply-To: <20051005202904.GA27229@mipter.zuzino.mipt.ru>

On Thu, Oct 06, 2005 at 12:29:04AM +0400, Alexey Dobriyan wrote:
> > --- RC14-rc3-git4/arch/arm/mm/consistent.c
> > +++ RC14-rc3-git4-final/arch/arm/mm/consistent.c
> 
> > -vm_region_alloc(struct vm_region *head, size_t size, int gfp)
> > +vm_region_alloc(struct vm_region *head, size_t size, unsigned int gfp)
> 
> > -__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle, int gfp,
> > -	    pgprot_t prot)
> > +__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
> > +	    unsigned int gfp, pgprot_t prot)
> 
> 	unsigned int __nocast gfp
> 
> 	=> dma_alloc_coherent
> 	=> dma_alloc_writecombine

Speaking of that...  IMO we should do the following:

a) typedef unsigned int __nocast gfp_t;
b) replace __nocast uses for gfp flags with gfp_t - it gives exactly the same
warnings as far as sparse is concerned, doesn't change generated code and
documents what's going on far better.  If we are using __nocast for anything
else - sure, let it stay.
c) then replace __nocast in declaration of gfp_t with __bitwise [*], add
force cast to gfp_t to definitions of __GFP_... and deal with resulting
warnings.

Note that unlike __nocast, __bitwise is hard to lose; lossage like the above
will not go unnoticed.  We will need a couple of inline helpers to deal with
extraction of zone from gfp, etc., but after that it's basically a matter of
switching the missed chunks like the above.

I've done that several months ago, but that patch series had been killed
by bitrot (patches fixing the bugs I've found back then had been merged,
the rest had gone to bitbucket after a while).  It's not hard to reproduce,
though.

Objections?


[*] since endainness annotations are nowhere near complete, I suggest
the following: define __bitwise__ as __attribute__((bitwise)) or empty,
depending on __CHECKER__, then have

#ifdef __CHECK_ENDIAN__
#define __bitwise __bitwise__
#else
#define __bitwise
#endif
typedef unsigned int __bitwise__ gfp_t;

with -Wbitwise unconditionally in CHECKFLAGS.  Then normal run will pick
the places that use __bitwise__ and CF=-D__CHECK_ENDIAN__ will pick all
endianness warnings on top of that.  Basically, that allows to use
bitwise annotations while endianness stuff is not finished and do that
without drowning in warnings.

  reply	other threads:[~2005-10-06 20:15 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-05  3:58 [PATCHSET] 2.6.13-git3-bird1 viro
2005-09-05 15:55 ` Alexey Dobriyan
2005-09-05 16:03   ` viro
2005-09-05 16:47     ` [PATCHSET] 2.6.13-git5-bird1 viro
2005-09-05 21:20       ` [PATCHSET] 2.6.13-git5-bird2 viro
2005-09-07 18:31         ` [PATCHSET] 2.6.13-git7-bird1 viro
2005-09-12 19:17           ` [PATCHSET] 2.6.13-git12-bird1 Al Viro
2005-09-12 19:20             ` Al Viro
2005-09-30 12:08               ` [PATCHSET] 2.6.14-rc2-git8-bird1 Al Viro
2005-09-30 12:56                 ` kernel cross-toolchain (FC4) Al Viro
2005-09-30 16:09                   ` kernel cross-toolchain (Gentoo) Alexey Dobriyan
2005-09-30 16:05                     ` Al Viro
2005-09-30 17:55                       ` Alexey Dobriyan
2005-09-30 19:31                         ` Al Viro
2005-09-30 22:28                           ` Alexey Dobriyan
2005-09-30 19:06                       ` Alexey Dobriyan
2005-10-04 20:30                 ` [PATCHSET] 2.6.14-rc3-git4-bird1 Al Viro
2005-10-05 20:29                   ` Alexey Dobriyan
2005-10-06 20:15                     ` Al Viro [this message]
2005-10-07  2:56                       ` [RFC] gfp flags annotations Greg KH
     [not found]                         ` <20051007064604.GB7992@ftp.linux.org.uk>
2005-10-07 10:01                           ` [PATCH] gfp flags annotations - part 1 Alexey Dobriyan
2005-10-07 10:04                             ` Heiko Carstens
2005-10-07 12:27                               ` Alexey Dobriyan
2005-10-08 23:34                       ` [RFC] gfp flags annotations Linus Torvalds
2005-10-09  1:13                         ` Alexey Dobriyan
2005-10-09  1:06                           ` Al Viro
2005-10-09  5:32                         ` [RFC] gfp flags annotations - part 2 Al Viro
2005-10-09  5:35                         ` [RFC] gfp flags annotations - part 3 (simple parts of mm/*) Al Viro
2005-10-09  5:36                         ` [RFC] gfp flags annotations - part 4 (lib/*) Al Viro
2005-10-09  5:38                         ` [RFC] gfp flags annotations - part 5 (net/*) Al Viro
2005-10-09  5:55                         ` [RFC] gfp flags annotations - part 6 (simple parts of fs/*) Al Viro
2005-10-09 15:41                           ` Tom Zanussi
2005-10-09  6:01                         ` [RFC] gfp flags annotations - part 7 (block layer) Al Viro
2005-09-12 20:42             ` [PATCH] n_r3964: drop bogus fmt casts Alexey Dobriyan
2005-09-12 20:39               ` Al Viro
2005-09-05 18:39   ` [PATCHSET] 2.6.13-git3-bird1 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=20051006201534.GX7992@ftp.linux.org.uk \
    --to=viro@ftp.linux.org.uk \
    --cc=adobriyan@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.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.