All of lore.kernel.org
 help / color / mirror / Atom feed
* Question about copy_from/copy_to
@ 2002-11-27 20:26 Linux Geek
  2002-11-27 20:52 ` Richard B. Johnson
  0 siblings, 1 reply; 3+ messages in thread
From: Linux Geek @ 2002-11-27 20:26 UTC (permalink / raw)
  To: linux-kernel

I'm trying to write a device driver (module) for one of my customers and 
have the following problem.

kernel veraion 2.4.18...

Memory is allocated (kmalloc) in the "open" call.

The above memory is used in copy_from/to in the "ioctl" (and possibly 
the read/write) call.

I understand that the copy_from/to may wait for pages to be swapped in, 
If the waiting process is killed at this point, is it safe to free the 
memory in the "close/release" call? If not, when is it safe to call  kfree?


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Question about copy_from/copy_to
  2002-11-27 20:26 Question about copy_from/copy_to Linux Geek
@ 2002-11-27 20:52 ` Richard B. Johnson
  2002-11-27 21:13   ` Linux Geek
  0 siblings, 1 reply; 3+ messages in thread
From: Richard B. Johnson @ 2002-11-27 20:52 UTC (permalink / raw)
  To: Linux Geek; +Cc: linux-kernel

On Wed, 27 Nov 2002, Linux Geek wrote:

> I'm trying to write a device driver (module) for one of my customers and 
> have the following problem.
> 
> kernel veraion 2.4.18...
> 
> Memory is allocated (kmalloc) in the "open" call.

Hmmm. What happens if there are multiple tasks that open the same
device? Do you end up with multiple allocations? If so, why? And
How do you keep track of what opened what? Are you using the
private-data pointer in struct file? 

These are all questions that would have to be answered. The 'best'
place to allocate memory, if you are going to re-use it for all
access to the driver, is in init_module(). You free it in
cleanup_module(). That "solves" a lot of race problems.

If you intend to allocate memory every time you call the driver,
you allocate it when you need it, i.e., in read(), write(), etc.
You immediately free it when you are done.

Unless you seg-fault the kernel, you should always have control
after the copy/to/from to release the memory, even if the user
gave you a bad pointer.

So, I would say that it's not a good idea to allocate memory during
an open(). If you some political reason, you are forced to do this,
you need to count the number of open/close operations and only
deallocate memory after the final close. There are atomic-counter
macros you can use for this.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
   Bush : The Fourth Reich of America



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Question about copy_from/copy_to
  2002-11-27 20:52 ` Richard B. Johnson
@ 2002-11-27 21:13   ` Linux Geek
  0 siblings, 0 replies; 3+ messages in thread
From: Linux Geek @ 2002-11-27 21:13 UTC (permalink / raw)
  To: root; +Cc: linux-kernel

Richard,

Thanks fpr your response,

Yup, it's "political" this project is "work for hire" for an internal 
system - the code will never be distributed - all very hush hush. (I 
signed a non-disclosure agreement - so I can't be too specific.)

In essence, memory is allocated for each minor device number (total 
number of minors and the values are unknown at init time), and the data 
stored in a linked list. So for each open, the list is searched, and if 
the minor number is found, that is what is used (and a counter 
incremented), otherwise memory is allocated ad added to the list. (BTW - 
this is not my design and they're paying the bill.)

On the close the memory counter is decremented for the minor, and if 
zero, the memory is deallocated, So, it sounds like this is OK,

Richard B. Johnson wrote:
>... 
> So, I would say that it's not a good idea to allocate memory during
> an open(). If you some political reason, you are forced to do this,
> you need to count the number of open/close operations and only
> deallocate memory after the final close. There are atomic-counter
> macros you can use for this.
> 
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
>    Bush : The Fourth Reich of America
> 
> 



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-11-27 21:07 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-11-27 20:26 Question about copy_from/copy_to Linux Geek
2002-11-27 20:52 ` Richard B. Johnson
2002-11-27 21:13   ` Linux Geek

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.