Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> GIT version control wrote:
>>>> Module: xenomai-jki
>>>> Branch: for-upstream
>>>> Commit: 55ebde80258b5b6c3d29d37b5f30a3199faf0881
>>>> Author: Wolfgang Mauerer <wolfgang.maue...@siemens.com>
>>>> 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 <wolfgang.maue...@siemens.com>
>>>> Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
>>> 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.
> 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
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Xenomai-core mailing list