public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bernd Harries <bha@gmx.de>
To: linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org
Subject: 2.2.x: Secret stack size limit in Driver file-ops??? (Was:are Generic  ioctls a good thing?)
Date: Sun, 05 Nov 2000 13:08:40 +0100	[thread overview]
Message-ID: <3A054DC8.1D9701EC@gmx.de> (raw)
In-Reply-To: <3A01C6FA.25A90016@gmx.de>

Hi kernel hackers,

Is there a limit to the stack size (automatic variables) in driver methods, esp.
ioctl?

I was just implementing some generic ioctls where the size field and cmd field
are defined at runtime. For testing I use a kernbuf on the stack.

The driver's ioctl interface, which is normally a big case construction, looks
like this, the default case is another switch:

xyz_ioctl(..., ..., unsigned int request, unsigned long arg)
{

  ----some smaller declarations----

  switch(request)
  {
    ...
    case IOR_GET_FIX:
    {
      fix_par_t   fix_par;   /* small struct */

      ----some code----
      if(copy_to_user( , , sizeof(fix_par)))  return(-EFAULT);  
      break;
    }
    ...

    default:
    {
      switch(request & 0xF000FF00)
      {
        case IOW_000_G_00:
        {
          UINT32    kernbuf[0x0400];  /* is this too much??? */

          if(copy_from_user( , , dyn_size))  return(-EFAULT);
          ----some code----
          break;
        }
        case IOR_000_G_00:
        {
          UINT32    kernbuf[0x0400];  /* how much is allowed??? */

          ----some code----
          if(copy_to_user( , , dyn_size))  return(-EFAULT);
          break;
        }

      }
      /*endswitch(request & 0xF000FF00)*/
    }
    /*endcase default:*/
  }
  /*endswitch(request)*/
}
/*endproc()*/

Having this and testing not yet the generic ioctls, but the older, once working
'primitive' ioctls, I experienced that suddenly copy_to_user would not work any
more and return the complete length as remainder. The whole system seemed to
behave strange the more often I started the testprogram. Compiling the driver
module again would show strange error messages.

Observe, that the case-Block with the additional kernbuf was not even entered,
because the IOR_GET_FIX: returned an error "Bad address" or so.

Today I reduced the kernbuf to 4 * UINT32 and it seems to work. I will next try
to use a static kernbuf of 0x400 * UINT32...

In the Linux Device Drivers book I didn't find 'stack size' or similar in the
index. Are there any limits on the stacksize? If yes, how large are they and why
would the driver behave so stange and not oops or hang? I fear, my filesystem on
the test Box could be damaged. I saw this bad addres error quite some times and
suddenly make modules complained about strange contents in .config...

Does gcc grow the stack only at the beginning of a function, or can it save the
space and re-grow it on entering code_blocks also?

Thanks for any hints,
-- 
Bernd Harries

bha@gmx.de           http://www.freeyellow.com/members/bharries
bha@nikocity.de       Tel. +49 421 809 7343 priv.  | MSB First!
harries@stn-atlas.de       +49 421 457 3966 offi.  | Linux-m68k
bernd@linux-m68k.org      8.48'21" E  52.48'52" N  | Medusa T40
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  reply	other threads:[~2000-11-05 12:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-02 19:56 are Generic ioctls a good thing? Bernd Harries
2000-11-05 12:08 ` Bernd Harries [this message]
2000-11-05 14:26   ` 2.2.x: Secret stack size limit in Driver file-ops??? (Was:are Generic ioctls a good thing?) Ingo Oeser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A054DC8.1D9701EC@gmx.de \
    --to=bha@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox