(no subject)

[michi@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]

From michi1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Thu Apr  2 19:55:26 2009
Date: Thu, 2 Apr 2009 19:55:26 +0200
From: Michael Blizek <michi1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
To: Peter Teoh <htmldeveloper@xxxxxxxxx>
Cc: Devesh Sharma <devesh28@xxxxxxxxx>, kernelnewbies@xxxxxxxxxxxx
Subject: Re: Usage of Semaphore with a workqueue
Message-ID: <20090402175526.GA1724@grml>
References: <309a667c0904010812p23ddde3fjda53a5d3e0250075@xxxxxxxxxxxxxx> <804dabb00904011706h2763da72i1ff000ca7cf79bde@xxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <804dabb00904011706h2763da72i1ff000ca7cf79bde@xxxxxxxxxxxxxx>
User-Agent: Mutt/1.5.18 (2008-05-17)
Status: RO
Content-Length: 1829
Lines: 46

Hi!

On 08:06 Thu 02 Apr     , Peter Teoh wrote:
> i think u are right, looking at drivers/char/rocket.c as an example
> (read the comment):
> 
> /*
>  *  Exception handler - write routine, called when user app writes to
> the device.
>  *  A per port write mutex is used to protect from another process writing to
>  *  this port at the same time.  This other process could be running
> on the other CPU
>  *  or get control of the CPU if the copy_from_user() blocks due to a
> page fault (swapped out).
>  *  Spinlocks protect the info xmit members.
>  */
> static int rp_write(struct tty_struct *tty,
>                     const unsigned char *buf, int count)
> {
>         struct r_port *info = tty->driver_data;
>         CHANNEL_t *cp;
>         const unsigned char *b;
>         int c, retval = 0;
>         unsigned long flags;
> 
>         if (count <= 0 || rocket_paranoia_check(info, "rp_write"))
>                 return 0;
> 
>         if (mutex_lock_interruptible(&info->write_mtx))
>                 return -ERESTARTSYS;

What makes you think that this is called in workqueue context? The only
caller of this function I have found is in drivers/char/rocket.c
"static const struct tty_operations rocket_ops". It is probably called
in system call context. For this reason, the mutex is locked interruptible
and the return value is ERESTARTSYS. This value is not returned, if the
mutex is locked, but if the mutex is locked and the user space process
receives a signal. In this case the system call has to terminate, because
otherwise the call of the user space signal handler will be delayed. The
system call will be restarted be the user space application, which gets
errno set to EINTR by write().

        -Michi
-- 
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.twilightparadox.com



--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ