Private IOCTL in Network driver - Linux

This is a discussion on Private IOCTL in Network driver - Linux ; Hello All, I have a network driver which uses SIOCDEVPRIVATE (depricated) to pass the data to and from the kernel/user space. I used struct ifreq *ifr datastructure ifr->if_data to pass my own datastructure to the kernel and get updated from ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Private IOCTL in Network driver

  1. Private IOCTL in Network driver

    Hello All,

    I have a network driver which uses SIOCDEVPRIVATE (depricated) to pass
    the data to and from the kernel/user space. I used struct ifreq *ifr
    datastructure ifr->if_data to pass my own datastructure to the kernel
    and get updated from kernel to user space.
    But I am not using any copy_to_user/copy_from_user call in the driver
    IOCTL calls.
    Wit this I am able to set and get my device parameter through private
    IOCTL calls.


    Should I do copy_to_user/copy_from_user calls for kernel to user and
    user to kernel data updation. I am not seeing any issue without that.
    Could you point out any problem will happen after that( i mean page
    fault etc ... )

    Looks to me ifr_data holds the copy of the data in the kernel space
    with out expecting copyt_to_user and copy from user calls in our
    driver.

    Please throw some light on this.

    Thanks.
    Kamaraj

  2. Re: Private IOCTL in Network driver

    Kamaraj wrote in news:f474bc47-4012-44b7-8dbd-
    e8ccb27dcd2f@t18g2000prt.googlegroups.com:

    > I have a network driver which uses SIOCDEVPRIVATE (depricated) to pass
    > the data to and from the kernel/user space. I used struct ifreq *ifr
    > datastructure ifr->if_data to pass my own datastructure to the kernel
    > and get updated from kernel to user space.
    > But I am not using any copy_to_user/copy_from_user call in the driver
    > IOCTL calls.
    > Wit this I am able to set and get my device parameter through private
    > IOCTL calls.
    >
    >
    > Should I do copy_to_user/copy_from_user calls for kernel to user and
    > user to kernel data updation. I am not seeing any issue without that.
    > Could you point out any problem will happen after that( i mean page
    > fault etc ... )


    You should use them. This comment is in the x86 do_page_fault function:
    /* When running in the kernel we expect faults to occur only to
    * addresses in user space. All other faults represent errors in the
    * kernel and should generate an OOPS. Unfortunately, in the case of an
    * erroneous fault occurring in a code path which already holds mmap_sem
    * we will deadlock attempting to validate the fault against the
    * address space. Luckily the kernel only validly references user
    * space from well defined areas of code, which are listed in the
    * exceptions table.

    The copy_from_user and copy_to_user functions set up entries in the
    above-mentioned exceptions table. In other words, if everything goes
    well, you don't need them. Should something go wrong, though, and that
    user-space page you're copying to gets unmapped (due to a bug in the
    program for example), you'll get a page fault that is unexpected, and
    the OOPS will be the ultimate result.


    > Looks to me ifr_data holds the copy of the data in the kernel space
    > with out expecting copyt_to_user and copy from user calls in our
    > driver.


    The socket ioctl handler handles its own arguments correctly. So if the
    data you're copying is *only* the actual ifr_data value (ifr_data is
    just a single pointer field), you're fine. Typically though, ifr_data
    is used as a way of passing a pointer to a user-space data area and
    hence a secondary copy to/from user space is required. Assuming that
    you're using ifr_data in the typical way, you should be using
    copy_xxx_user.


    GH

+ Reply to Thread