From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4BC8682E.4090406@domain.hid> Date: Fri, 16 Apr 2010 15:37:50 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4BC855E6.106@domain.hid> <4BC85899.90700@domain.hid> <4BC85EF5.3000008@domain.hid> <4BC8617E.4060307@domain.hid> <4BC865F1.5000303@domain.hid> <4BC8674B.5090302@domain.hid> In-Reply-To: <4BC8674B.5090302@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] [Xenomai-git] Wolfgang Mauerer : RTDM: Fix potential NULL pointer dereference List-Id: Xenomai life and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: xenomai-core Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Gilles Chanteperdrix wrote: >>>> Jan Kiszka wrote: >>>>> Gilles Chanteperdrix wrote: >>>>>> GIT version control wrote: >>>>>>> Module: xenomai-jki >>>>>>> Branch: for-upstream >>>>>>> Commit: 55ebde80258b5b6c3d29d37b5f30a3199faf0881 >>>>>>> URL: http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=55ebde80258b5b6c3d29d37b5f30a3199faf0881 >>>>>>> >>>>>>> Author: Wolfgang Mauerer >>>>>>> Date: Tue Mar 30 11:13:33 2010 +0200 >>>>>>> >>>>>>> RTDM: Fix potential NULL pointer dereference >>>>>>> >>>>>>> The rework in 95278926edc559d4 misses the case that context can be NULL, >>>>>>> which can (and has) triggered a kernel oops. Take care of this case. >>>>>>> >>>>>>> Signed-off-by: Wolfgang Mauerer >>>>>>> Signed-off-by: Jan Kiszka >>>>>> I still think that fix is a useles waste of time. Let us merge >>>>>> Philippe's patches instead. >>>>> Please accept that Philippe's patch is orthogonal to this bug. >>>>> >>>>> And it didn't work as-is. I'll post a rework which has the same benefit >>>>> (avoiding to poll on pending context references) - once it is tested. >>>> Ok. I am fine with any variation as long as: >>>> - close returns immediately even if the request is not taken into >>>> account immediately; >>>> - the file descriptor index is available again as soon as close returns; >>>> - the kernel objects attached to the file descriptor are destroyed when >>>> the last reference to it is closed. >>> That's precisely what I implemented. Additionally, I had to take care of >>> RTDM drivers deferring the close via EAGAIN and some other minor aspects. >> I am afraid EAGAIN gets translated automatically into ENOMERGE ;-) > > Sorry, I'm also concerned about legacy compatibility. So this is a > must-have. > > But don't worry, this is an internal detail between driver and RTDM. > Neither the user nor drivers that makes no use of it will notice. > >>>> In shoft: POSIX conformance. >>> At least blocking has nothing to do with POSIX (some drivers will >>> continue to block in their close handlers). And - AFAIU - the order of >>> releasing the fd internally and blocking on something during close is >>> not specified. >> The point is that the close handler should not be called when close is >> called, but when the last reference to the file descriptor is closed, >> asynchronously if need be. So, it may block. But the close service >> should return immediately. >> >> Maybe it is not POSIX, but it is the way it should be, and the way >> people expect a sane driver API to answer. Crappy drivers which do not >> answer to SIGINT are simply not acceptable and only a waste developer >> time (and POSIX mandates EINTR in that case). > > We can't change these bits. The close handler will continue to be called > when the request is issued and possibly once again (or more if it asks > for this via EAGAIN) when the final release happens. As fare as I remember Philippe's patch fixed these bits. I have no problem if the polling happens in a kernel thread (or workqueue, as far as I remember Philippe's patch), and the close service has already returned and freed the file descriptor. -- Gilles.