RE: copy_from_user problem

["T Michael Turney" <tmike@recipes4linux.com>]

[-- Attachment #1: Type: text/plain, Size: 3324 bytes --]

Samsung Enterprise Portal mySingleMurahari,
I always start simple and work up to the harder things.  Try to access a
single
long word in the ioctl, e.g.,

int

chr1_ioctl(struct inode *ino, struct file *filp, unsigned int cmd, unsigned
long arg)

{

   int ret = 0;

  unsigned int userdata;



   switch(cmd)

   {

      case IOCTL_WIN_DEBUG_READ_CODE:

      {

        ret = get_user(userdata, (unsigned int *)arg);

        ......

         }

}

}



The two O'Reilly books, Linux Device Drivers and Understanding the Linux
Kernel are also good

references for how to use the get_user and copy_from_user macros.

Hope this helps.

Cheers,

T.mike

  -----Original Message-----
  From: linuxppc-dev-bounces@ozlabs.org
[mailto:linuxppc-dev-bounces@ozlabs.org]On Behalf Of V MURAHARI
  Sent: Wednesday, August 10, 2005 7:53 PM
  To: linuxppc-dev@ozlabs.org
  Subject: copy_from_user problem



  Hello,

  I am working on a character driver for reading and writing the registers
to FPGA in our system.

  I am using driver ioctl to read/write to these registers of FPGA. As the
function call to the ioctl is being made, the printk trace shows that the
call goes to switch->copy_from_user. As soon as the call is made to
copy_from_user, the kernel crashes

  Can someone help me with this problem?




****************************************************************************
***********************

   Unhandled kernel unaligned access in
unaligned.c::emulate_load_store_insn, line 483

  :

  $0 : 00000000 10001f00 8fbf0034 02a01021 801157a0 8fe8e000 10001f00
ffff00ff

  $8 : 8fe8ffe0 00001f00 00000000 00000003 74652053 8fe9fed8 0000000a
50434942

  $16: 10001f01 00000001 801157a0 0000000f 8fe8fee8 00000104 00000000
0000000f

  $24: 00000000 2ac0fdb0                   8fe8e000 8fe8fe38 00000001
8012010c

  Hi : 00000000

  Lo : 00000000

  epc  : 8011f774    Tainted: GF

  Status: 10001f02

  Cause : 00800014

  Process rsgbm (pid: 317, stackpage=8fe8e000)

  Stack:    802d920a 0000000a 10001f01 0000003c 10001f01 0000003c 8012010c

   80120104 caa8f356 8fe82008 8fe82000 0000000f 00000000 7fff7d00 7fff7d00

   0000c001 00000003 10012808 ffffffff caa8e548 00004000 8fe9e272 00000150

   7fff7d00 ffffffea 00000000 00000240 8fe82000 00000000 00000001 00000001

   7ebff310 00000000 0000000f 8fef24e0 00000004 7ebff3e8 00000000 0000002e

   80159c6c ...

  Call Trace:   [<8012010c>] [<80120104>] [<caa8f356>] [<caa8e548>]
[<80159c6c>]

   [<8010a5c4>] [<80271dc4>]



  Code: 8c820004  24110001  ac430000 <ac620004> ac800000  ac800004  ac800000
ac800004

    8f820004



  Unit Fault Handler !!! (INDEX=10)


****************************************************************************
**********************

  int

  chr1_ioctl(struct inode *ino, struct file *filp, unsigned int cmd,

        unsigned long arg)

  {

     int ret = 0;

     n2_debug_rw_reg *dw;



     switch(cmd)

     {

        case IOCTL_WIN_DEBUG_READ_CODE:

        {

     n2_debug_rw_reg test;

          printk("%s %d\n", current->comm, current->pid);

          printk("%lx\n", arg);

          copy_from_user(&test, (n2_debug_rw_reg*)arg,
sizeof(n2_debug_rw_reg));

          printk("%lx %lx\n", ((n2_debug_rw_reg*)arg)->data,
((n2_debug_rw_reg*)arg)->

  addr);

           }

  }

  }



  Thanks & Regards,

  --Murahari

[-- Attachment #2: Type: text/html, Size: 7237 bytes --]