All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benedikt Spranger <b.spranger@linutronix.de>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org, hjk@hansjkoch.de,
	Alexander.Frank@eberspaecher.com
Subject: Re: [PATCH 1/2] uio: add warning to documentation
Date: Wed, 12 Dec 2012 01:45:34 +0100	[thread overview]
Message-ID: <20121212014534.287c8ba8@linutronix.de> (raw)
In-Reply-To: <20121211231816.GA23621@kroah.com>

On Tue, 11 Dec 2012 15:18:16 -0800
Greg KH <gregkh@linuxfoundation.org> wrote:

> > -<function>open()</function>, you will probably also want a custom
> > +<function>release()</function>, you will probably also want a
> > custom <function>release()</function> function. 
> That sentance no longer makes sense.
DUH! will fix...

> > +</para><para>CAVE: The release hook may be processed, even if a
> > mmap is aktive.
> Huh?
OK, think about a user of uio_pdrv_genirq and you did your
powermanagement well. The user open the UIO device, do a mmap() and
close the UIO device. Then he access the given pointer and wonders why
the system is stuck. It is a bad idea to disable clocks on release
while a mmap is active.

> > +Disabling clocks or other powermanagement functionality may cause
> > a system +crash, hangup or other unwanted sideeffects.
> > +</para><para><emphasis>The mmap() function shall add an extra
> > reference to the file associated with the file descriptor fildes
> > which is not removed by a subsequent close() on that file
> > descriptor. This reference shall be removed when there are no more
> > mappings to the file.</emphasis></para><para> +<link
> > xlink:href="http://pubs.opengroup.org/onlinepubs/009695399/functions/mmap.html">IEEE
> > Std 1003.1, 2004 Edition, mmap()</link>
> 
> It's not up to us to document the mmap system call here, you should
> know how to use it if you write a program with it, right?
Its not the user of mmap(), it is for the driver programmer. It is a
bad idea to do every kind of powermanagement function in the release
hook.

Regards 
    Bene

  reply	other threads:[~2012-12-12  0:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-11 23:12 [PATCH 0/2] uio: open(), mmap(), close() Benedikt Spranger
2012-12-11 23:12 ` [PATCH 1/2] uio: add warning to documentation Benedikt Spranger
2012-12-11 23:18   ` Greg KH
2012-12-12  0:45     ` Benedikt Spranger [this message]
2012-12-12  4:49       ` Greg KH
2012-12-12  1:56     ` Hans J. Koch
2012-12-12  4:47       ` Greg KH
2012-12-11 23:12 ` [PATCH 2/2] uio: do not expose inode to uio open/release hooks Benedikt Spranger
2012-12-11 23:20   ` Greg KH
2012-12-12  1:42     ` Hans J. Koch
2012-12-12  4:46       ` Greg KH
2012-12-12  8:50         ` Hans J. Koch
2012-12-12  8:56           ` Benedikt Spranger
2012-12-12 15:08             ` Greg KH
2012-12-13  0:08               ` Hans J. Koch
2012-12-13  0:15                 ` Greg KH

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=20121212014534.287c8ba8@linutronix.de \
    --to=b.spranger@linutronix.de \
    --cc=Alexander.Frank@eberspaecher.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hjk@hansjkoch.de \
    --cc=linux-kernel@vger.kernel.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.