Eugene,

You must pass sys_ioctl a user address not a kernel address.  You can
set KERNEL_DS across the call to sys_ioctl(), but then *all* addresses
must be kernel addresses (including iocp->ic_dp), which means you will
have to copy the entire buffer in and then back out again.

I notices that the dlpi.h and npi.h header files in 2.18.0 are broken.
They use long instead of int32_t or t_scalar_t in many places.
Therefore, all 32/64-bit compatibility of networking is broken in
2.18.0.  These headers could be fixed (as they are in 2.18.2) but then
binary compatibility with 2.18.0 breaks.

I have just announced a version of Linux Fast-STREAMS, STREAMS XNS,
XTI/TLI, and INET that have validated 32/64-bit compatibility.  I ran
the 600 odd test cases in the POSIX test suite and the 1000 odd libxnet
and inet TPI test cases 32-bit over a 64-bit kernel (x86_64 on HT PIV
630) an passed them all.  (LiS can't even pass them all 32/32-bit!).

At the same time I noticed that LiS fails even more test cases 64/64-bit
than 32/32-bit, and locks the machine good on SMP for even more test
cases (with HT enabled on the 630).  I'm sorry but LiS is really too
broken to salvage.

--brian

On Fri, 10 Mar 2006, [EMAIL PROTECTED] wrote:

> 
>    Hi,
> 
>    I'm debugging 32-bit ioctls over 64-bit LiS/kernel.
> 
>    It  works  most  of  the  time,  but  then  it  crashes  due to memory
>    corruption
>    in the lis_ioctl32_str() function.
> 
>    The allocated memory,  saved in datap pointer:
>       datap = ALLOCF(par64.ic_len+32,"ioctl32 ");
> 
>    may get corrupted after   sys_ioctl()   call.
> 
>    To  catch  corruption, I have added check guard calls before and after
>    sys_ioctl() calls:
> 
>    lis_check_guard(datap, "---- before sys_ioctl\n");
> 
>    rc = sys_ioctl(fd,cmd,(unsigned long)&par64);
> 
>    lis_check_guard(datap, "---- after sys_ioctl\n");
> 
>    The '---after sys_ioctl' check guard call indicates memory corruption.
> 
> 
>    I looked through sources but cannot find the bug.
> 
>    Seems  like  memory  pointed  by datap will be memcpy'ied into streams
>    message
>    in  lis_strioctl/lis_strdoioctl  later  on and should be unaffected by
>    further processing
>    in underlying drivers.
> 
>    Or do I miss something here?
> 
>    --
>    Eugene
> 
> 
>      _________________________________________________________________
> 
>    Try the New Netscape Mail Today!
>    Virtually Spam-Free | More Storage | Import Your Contact List
>    [1]http://mail.netscape.com
> 
> References
> 
>    1. http://mail.netscape.com/

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[EMAIL PROTECTED]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦
_______________________________________________
Linux-streams mailing list
[email protected]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams

Reply via email to