lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-id: <alpine.DEB.2.00.0910182126120.6395@zirkon.biophys.uni-duesseldorf.de> Date: Sun, 18 Oct 2009 23:14:32 +0200 (CEST) From: Michael Schmitz <schmitz@...phys.uni-duesseldorf.de> To: Jiri Kosina <jkosina@...e.cz> Cc: Geert Uytterhoeven <geert@...ux-m68k.org>, linux-m68k <linux-m68k@...ts.linux-m68k.org>, Tejun Heo <tj@...nel.org>, Jens Axboe <jens.axboe@...cle.com>, linux-kernel@...r.kernel.org Subject: Re: Fwd: [PATCH] [RFC] ataflop: remove buggy IRQ disable from do_fd_request() 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@...e.cz> > > > > 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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists