On Thu, Apr 2, 2009 at 5:36 AM, Peter Teoh <[email protected]> wrote: > i think u are right, looking at drivers/char/rocket.c as an example > (read the comment): > Yes, with drivers write entry point this is fine......but what about using it with workqueue context? > /* > * 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; > > > On Wed, Apr 1, 2009 at 11:12 PM, Devesh Sharma <[email protected]> wrote: >> Hello list, >> >> Consider a case where I have a workqueue, a work is submitted to a it >> from some interrupt handler >> Lets say, some where in a code, it tries to get some semaphore to >> enter into a critical section, >> and fails to get it, sholud I still return from the work function by >> returning ERESTARTSYS? >> Kindly somebody clarify this to me >> >> Thanks in advance >> Devesh >> >> -- >> To unsubscribe from this list: send an email with >> "unsubscribe kernelnewbies" to [email protected] >> Please read the FAQ at http://kernelnewbies.org/FAQ >> >> > > > > -- > Regards, > Peter Teoh >
-- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to [email protected] Please read the FAQ at http://kernelnewbies.org/FAQ
