All of lore.kernel.org
 help / color / mirror / Atom feed
From: pranjas@gmail.com (Pranay Srivastava)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Understanding of write file operation in char driver
Date: Sat, 3 Jan 2015 23:49:52 +0530	[thread overview]
Message-ID: <CA+aCy1GtrxjXiAEkdWKCqXrK335tk5QZRmmKp-fw3F7GxA6OPg@mail.gmail.com> (raw)
In-Reply-To: <CAHmg6GPpE5ru6tVUzvwz-qhe+32T63g1MOHdauy3X=D3Wh9PSA@mail.gmail.com>

Hi Prasad,


On Sat, Jan 3, 2015 at 9:23 PM, me storage <me.storage126@gmail.com> wrote:
> Hi,
> Thanks Valdis for your nice explanation. After practising i got another
> doubt
> if read from my driver as below
>
> cat /dev/myDev
>
> for this how many times read function will call because some times it is
> executing only once but some times it is executing infinite times.
> Like for write also
> echo "hello" > /dev/myDev
> for that particular call it is executing 1 or 2 times.
> So can one please clarify my doubts

Make sure you return the correct amount to be read based on the amount
asked and the amount of data available from current value of fpos. If
there's nothing to read then return 0 based on the current value of
fpos. Doing strace would help. You would see that cat stops if the
amount of data read is lesser than it asks for which is usually a
page.

Try using generic read/write routines and instead override the
readpage(s)/writepage(s) of aops. You won't need to handle those
checks then.

> Thanks & Regards
> Prasad
>
> On 2 January 2015 at 21:32, <Valdis.Kletnieks@vt.edu> wrote:
>>
>> On Fri, 02 Jan 2015 07:50:55 +0530, me storage said:
>>
>> > Can any one please tell me difference between kernal space & user space
>> > in
>> > code perspective
>>
>> Two biggies:
>>
>> 1) Kernel space pages are usually nailed down and not paging in and out,
>> this is *not* true for userspace pages (so special tap-dancing in
>> copy_(to/from)_user() is needed to make sure no page faults happen).
>>
>> 2) Data inside the kernel can usually be trusted from a security
>> standpoint.
>> Data in userspace *MUST NOT* be trusted.  Also, beware of TOCTOU (time of
>> check / time of use) bugs - that's why we should copy the user-supplied
>> data
>> to an internal buffer *first*, and then validity-check the buffer - if we
>> check
>> the value in userspace and then later copy it, there's a race condition
>> where
>> the userspace value can be changed after the check but before the copy.
>>
>> Also, keep in mind that a userspace pointer needs to be translated before
>> using it to dereference data from kernel space....
>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>



-- 
        ---P.K.S

  reply	other threads:[~2015-01-03 18:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-02  2:20 Understanding of write file operation in char driver me storage
2015-01-02 16:02 ` Valdis.Kletnieks at vt.edu
2015-01-03 15:53   ` me storage
2015-01-03 18:19     ` Pranay Srivastava [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-01-01  8:24 me storage
2015-01-01 15:50 ` Victor Rodriguez

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=CA+aCy1GtrxjXiAEkdWKCqXrK335tk5QZRmmKp-fw3F7GxA6OPg@mail.gmail.com \
    --to=pranjas@gmail.com \
    --cc=kernelnewbies@lists.kernelnewbies.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 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.