Re: O_DIRECT Inside Kernel Module?

I should have mentioned that I've already discovered filp_open, which is the
open that I am using, but is failing with the O_DIRECT flag set.


"Kasper Dupont"
<24429151269523788535@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:43DF468D.9DC5647D@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> "Peter T. Breuer" wrote:
>>
>> Clearly it expects a user space address as a buffer (my guess)..
>
> A reasonable guess. I haven't looked how it does. But I guess
> it will need to translate the address from virtual to physical
> to do DMA. There are major differences in how such a translation
> would be done for user and kernel space. Clearly kernel space is
> the simpler case of the two, but that doesn't do you any good if
> only the user space case has been implemented.
>
>>
>> But I am extremely surprised that you can read or write ordinarily from
>> within a kernel module.
>
> It can be done:
> http://www.daimi.au.dk/~kasperd/comp.os.linux.development.faq.html#filp_open
>
>> I would not expect that at all, since those are
>> system calls, and therefore must go via the syscall nterface, using
>> special assembly linkage, calling conventions, address space
>> requirements, and so on.
>
> Using the system call interface would be a design mistake.
> Using filp_open and methods in the struct returned by
> filp_open will work. The address space requirements can be
> changed using set_fs.
>
>> And then there is the possibility of creating
>> a deadlock loop - such as needing ram for buffer space to put your
>> writes into, but not being able to get any ram until you have flushed
>> existing writes aimed at your device, which needs ram for you to put
>> those writes into
>
> It is not the only case where such potential deadlocks
> exist. AFAIK it has been solved in most (all) of the other
> cases. In fact O_DIRECT should eliminate the buffer usage
> you are talking about.
>
>> ... I would have thought the only safe thing to do
>> would have been to create block write requests out of existing
>> buffers and buffer heads and launch them int the block device
>> subsystem.
>
> That is another solution.
>
> --
> Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
> #define _(_)"d.%.4s%."_"2s" /* This is my new email address */
> char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);


.

Relevant Pages