Re: Fwd: [PATCH] [RFC] ataflop: remove buggy IRQ disable fromdo_fd_request()

[Michael Schmitz]

Hi Jiri,

trying for a somewhat more coherent opinion: 

> > > If you look at the code long enough, you will notioce that the
> > > local_irq_disable() call is actually commented out. This has been
> > > introduced back in 2002 in [1], but as you can see, the same bug has been
> > > there even before, with the sti() call being commented out in the very
> > > same way :)

The substitution of sti() by local_irq_disable() had me a bit confused here. The 
last time I worked on this driver was when we still had a big kernel lock, so 
the  sti() might have been crucial there. 

The code does evidently work fine without it, and redo_fd_request as well as 
do_fd_action do not need to reenable local interupts or otherwise change the 
interrupt level anymore. After a bit more pondering over the code I now 
understand why this is ... 

> > The surounding code probably hasn't been touched in ages. The floppy driver in 
> > its current state does work. If redo_fd_request could alter timers ot queues, 
> > rmoving the locking would be dangerous, no?
> 
> The patch is not removing any locking. It only
> 
> 1) removes the local_irq_disable() that has been commented out for many 
>    years already anyway
> 2) removes the saving and restoring of CPU flags around do_fd_request(), 
>    which is rather clearly a nop than any kind of "locking"
> 
> > > [1] http://lkml.org/lkml/2002/12/27/58
> > > 
> > > Signed-off-by: Jiri Kosina <jkosina@xxxxxxx>
> > 
> > NAck for my part. 
> 
> Please elaborate a little bit more which of the two points above you base 
> your NACK on.

The removal of local_irq_disable() (which should have been local_irq_enable()) 
just raised a flag, and I didn't immediately see why the interrupt enable had 
been commented out. 

With a bit of further thought on the matter I am satisfied that this patch will 
not impact on driver function at all, and do not wish to sustain my objection.

IOW: Ack, and my sincere apologies for wasting your time. 

	Michael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/