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?
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
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
>
>