2008-01-11 11:04:49

by Nikanth Karthikesan

[permalink] [raw]
Subject: Query on lock protection in random number driver

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


2008-01-11 11:12:24

by Andi Kleen

[permalink] [raw]
Subject: Re: Query on lock protection in random number driver

Nikanth Karthikesan <[email protected]> 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

2008-01-11 11:24:55

by Nikanth Karthikesan

[permalink] [raw]
Subject: Re: Query on lock protection in random number driver

On Fri, 2008-01-11 at 12:12 +0100, Andi Kleen wrote:
> Nikanth Karthikesan <[email protected]> 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

2008-01-11 12:47:20

by Andi Kleen

[permalink] [raw]
Subject: Re: Query on lock protection in random number driver

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 <[email protected]> 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