Re: [PATCH 4/8] i386: bitops: Kill volatile-casting of memory addresses

[Nick Piggin <nickpiggin@yahoo.com.au>]

Satyam Sharma wrote:
> On Tue, 24 Jul 2007, Nick Piggin wrote:
> 
> 
>>Linus Torvalds wrote:
>>

>>>Of course, if we remove all "volatiles" in data in the kernel (with the
>>>possible exception of "jiffies"), we can then remove them from function
>>>declarations too, but it should be done in that order.
>>
>>Well, regardless, it still forces the function to treat the pointer
>>target as volatile, won't it? It definitely prevents valid optimisations
>>that would be useful for me in mm/page_alloc.c where page flags are
>>being set up or torn down or checked with non-atomic bitops.
> 
> 
> Yes, and yes. But I think what he meant there is that we'd need to
> audit the kernel for all users of set_bit and friends and see if callers
> actually pass in any _data_ that _is_ volatile. So we have to kill them
> there first, and then in the function declarations here. I think I'll put
> that on my long-term todo list, but see below.

Yeah that is probably what he meant.


>>Anyway by type safety, do you mean it will stop the compiler from
>>warning if a pointer to a volatile is passed to the bitop?
> 
> 
> The compiler would start warning for all those cases (passing in
> a pointer to volatile data, when the bitops have lost the volatile
> casting from their function declarations), actually. Something like
> "passing argument discards qualifiers from pointer type" ... but
> considering I didn't see *any* of those warnings after these patches,
> I'm confused as to what exactly Linus meant here ... and what exactly
> do we need to do "kill the volatiles".

Because even with an allyesconfig, your compile isn't testing the
entire kernel. So given the relatively minor benefit of removing
the volatiles, I suppose we shouldn't risk slipping a bug in. If
you can make gcc throw an error in that case it would be a different
story.

-- 
SUSE Labs, Novell Inc.