В Thu, 5 Aug 2010 14:31:47 +0200 Rodolfo Giometti пишет: > On Thu, Aug 05, 2010 at 03:42:31PM +0400, Alexander Gordeev wrote: > > ?? Thu, 5 Aug 2010 11:32:36 +0200 > > Rodolfo Giometti ??????????: > > > > > On Thu, Aug 05, 2010 at 01:06:42AM +0400, Alexander Gordeev wrote: > > > > Using device index as a pointer needs some unnecessary work to be done > > > > every time the pointer is needed (in irq handler for example). > > > > Using a direct pointer is much more easy (and safe as well). > > > > > > > > Signed-off-by: Alexander Gordeev > > [snip] > > > > > > If you remove these functions you can't be sure anymore that nobodies > > > may call pps_event() over a non existent device... > > > > [snip] > > > > > By dropping pps_get_source you may be here by a call from (i.e.) a > > > serial port driver whose doesn't know if your PPS source is gone or > > > not... > > > > > > I don't understand how your modifications may resolve this problem. > > > > Well, this can happen only if PPS client module calls pps_event before > > calling pps_register_source() or after pps_unregister_source(). This > > means that it's broken! If we try to handle/workaround broken clients it > > Suppose we are using pps-ldisc client. How can you assure that > nobodies may execute pps_tty_close() while you are into the > pps_event() related to the same serial port? > > You can't disable serial interrupts in order to avoid > pps_tty_dcd_change calls... Hmm, yes, I see... But this is custom problem of only one client. I think it should be fixed in place instead of trying to fix it in the subsystem. Are you 100% sure dcd_change can be called before open or after close? Then I'll try to deal with this. > > affects performance. So we have to choose what is the priority: > > security or performance. My guru told me I shouldn't bother too much > > about broken kernel-space code which my code interacts with. If it's > > broken it should be fixed. Some assertions enabled by DEBUG define are > > enough. For me it makes sense but I don't know what should I check here? > > I'm sorry but I disagree with you. Kernel code can't allow userland > programs to corrupt it! > > We are not discussing about security or performance but about > reliability. Sure, now I see the problem (in the pps-ldisc). -- Alexander