Query on lock protection in random number driver

Query on lock protection in random number driver

[Nikanth Karthikesan]

A query on locks used to protect entropy_store

struct entropy_store {
	/* mostly-read data: */
	struct poolinfo *poolinfo;
	__u32 *pool;
	const char *name;
	int limit;
	struct entropy_store *pull;

	/* read-write data: */
	spinlock_t lock ____cacheline_aligned_in_smp;
	unsigned add_ptr;
	int entropy_count;
	int input_rotate;
};

Is this lock meant to protect all the data within the structure?
The lock is being taken whenever entropy_count is modified, but it is
not so when it is read, see random_poll(), random_read(). Either it
should be lock protected or made as atomic_t, right?

Also the globals random_read_wakeup_thresh and
random_write_wakeup_thresh are not at all protected by any locks! Why
locks are not needed for these?

Sorry, if that was a stupid question.

Thanks
Nikanth Karthikesan

Re: Query on lock protection in random number driver

[Andi Kleen]

Nikanth Karthikesan <knikanth@suse.de> writes:
>
> Also the globals random_read_wakeup_thresh and
> random_write_wakeup_thresh are not at all protected by any locks! Why
> locks are not needed for these?

Reading variables sizeof <= native word size (32bit or 64bit depending
on architecture) is atomic by itself. This is not necessarily
guaranteed in ISO-C or POSIX threads, but Linux can assume that.

-Andi

Re: Query on lock protection in random number driver

[Nikanth Karthikesan]

On Fri, 2008-01-11 at 12:12 +0100, Andi Kleen wrote:
> Nikanth Karthikesan <knikanth@suse.de> writes:
> >
> > Also the globals random_read_wakeup_thresh and
> > random_write_wakeup_thresh are not at all protected by any locks! Why
> > locks are not needed for these?
> 
> Reading variables sizeof <= native word size (32bit or 64bit depending
> on architecture) is atomic by itself. This is not necessarily
> guaranteed in ISO-C or POSIX threads, but Linux can assume that.

Yes, I found that by checking the implementation of atomic_read.

But I didnt check the implementation of atomic_set before sending the
mail and assumed assigning to a variable may not be atomic on all arch,
and because of that, we may be reading a half-written, variable! But
assigning to an int is also atomic on all arch.

Thanks a lot.

Thanks
Nikanth Karthikesan

Re: Query on lock protection in random number driver

[Andi Kleen]

On Fri, Jan 11, 2008 at 04:58:28PM +0530, Nikanth Karthikesan wrote:
> On Fri, 2008-01-11 at 12:12 +0100, Andi Kleen wrote:
> > Nikanth Karthikesan <knikanth@suse.de> writes:
> > >
> > > Also the globals random_read_wakeup_thresh and
> > > random_write_wakeup_thresh are not at all protected by any locks! Why
> > > locks are not needed for these?
> > 
> > Reading variables sizeof <= native word size (32bit or 64bit depending
> > on architecture) is atomic by itself. This is not necessarily
> > guaranteed in ISO-C or POSIX threads, but Linux can assume that.
> 
> Yes, I found that by checking the implementation of atomic_read.
> 
> But I didnt check the implementation of atomic_set before sending the
> mail and assumed assigning to a variable may not be atomic on all arch,
> and because of that, we may be reading a half-written, variable! But
> assigning to an int is also atomic on all arch.

For completeness this both only applies to naturally aligned variables
for portable code.

-Andi