cvs commit: src/sys/sys vnode.h src/sys/gnu/ext2fs ext2_vnops.c src/sys/nfsclient nfs_vnops.c src/sys/ufs/ufs ufs_vnops.c

[Poul-Henning Kamp]

In message <5DA9481A-4713-11D9-A4F2-000D93C47836 at xcllnt.net>, Marcel Moolenaar 
writes:
>
>On Dec 5, 2004, at 2:37 PM, Poul-Henning Kamp wrote:
>
>> In message <200412052230.iB5MUTZs021927 at repoman.freebsd.org>, Marcel  
>> Moolenaar
>> writes:
>>> marcel      2004-12-05 22:30:29 UTC
>>>
>>>  FreeBSD src repository
>>>
>>>  Modified files:
>>>    sys/sys              vnode.h
>>>    sys/gnu/ext2fs       ext2_vnops.c
>>>    sys/nfsclient        nfs_vnops.c
>>>    sys/ufs/ufs          ufs_vnops.c
>>>  Log:
>>>  Fix null-pointer indirect function calls introduced in the previous
>>>  commit. In the new world order, the transitive closure on the vector
>>>  operations is not precomputed. As such, it's unsafe to actually use
>>>  any of the function pointers in an indirect function call.
>>
>> Uhm not really.
>>
>> You'll notice that these three cases vector through a fifo_*specop*.
>>
>> The "specop" as opposed to "vnodeop", means that you're supposed to
>> know what you're doing.
>>
>> Did you actually get a zero pointer deref on this ?
>
>Yes, on vop_write(). See my posting to current@
>
>http://docs.freebsd.org/cgi/getmsg.cgi?fetch=895498+0+archive/2004/ 
>freebsd-current/20041205.freebsd-current

Hmm...

Your commit doesn't actually fix this problem, it only prevents the
panic.

The real problem is that with the fifofs vnode bypass you can't
call VOP_WRITE() on a fifo any longer.

If you back your commit out I'll fix it the right way.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.