* 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.