[PATCH] Keep a shadow copy of HFA384X_INTEN_OFF

[Denis Vlasenko]

> > > A lot of races can be avoided by enabling interrupts after such
> > > manipulation and disabling them before doing anything drastic
> > > (e.g. reset), provided that the hardware behaves properly and
> > > obeys those registers.
> >
> > This is not enough considering SMP/preempt. IMHO current code
> > does not take this into consideration.
>
> I don't understand.  We started the discussion about interrupts and
> now it seems you are talking about locking between two user contexts.

When thinking about locking I must take into consideration
all stuff: IRQs, other CPUs, preemption. Ignoring SMP and thinking
about IRQs only will produce racy code.

> > > The question is what is can happen and how can it affect
> > > correctness of the operation.  I cannot think of anything bad in
> > > this case.  RID settings become affective on reset, i.e.
> > > atomically.
> >
> > But IRQs and, worse, other CPUs can bite us:
> >
> > CPU1: doing ioctl			CPU2: doing ioctl
> > -----------------			-------------------------
> > hostap_set_word(...)
> > IRQ---->				hostap_set_word(...)
> > 	processing IRQ...		hostap_set_word(...)
> > <-------
> > hostap_set_word(...)
> > reset_port(...)
> > 					reset_port(...)
> >
> > There is locking inside set_word(), but we need locking around
> > whole {set_word(),set_word(),reset_port()} thing.
>
> But why?  I'm not aware of any reason why it's bad.  Are you afraid
> to lose one of the settings?  But each of them if written correctly,
> and they are kept separately in the MAC chip.

Hey hey... In my example CPU1 executes ioctl to set rate to 5M
while CPU2 sets rate to 11M. Look at the picture again: those set_word()s
write rate settings into two separate registers, and due to race
one reg is set to 5, and other to 11M. This is not ok.
--
vda