All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David McIlwraith" <quack@bigpond.net.au>
To: "Martin Diehl" <lists@mdiehl.de>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: calling context when writing to tty_driver
Date: Tue, 1 Oct 2002 21:13:22 +1000	[thread overview]
Message-ID: <08e001c2693b$8e64e8c0$41368490@archaic> (raw)
In-Reply-To: Pine.LNX.4.21.0210010523290.485-100000@notebook.diehl.home

Semaphores may sleep - therefore, they cannot be used from a 'non-sleep'
context.

Sincerely,
David McIlwraith quack@bigpond.net.au

----- Original Message -----
From: "Martin Diehl" <lists@mdiehl.de>
To: <linux-kernel@vger.kernel.org>
Cc: "Greg KH" <greg@kroah.com>
Sent: Tuesday, October 01, 2002 8:37 PM
Subject: calling context when writing to tty_driver


>
> Hi,
>
> just hitting another "sleeping on semaphore from illegal context" issue
> with 2.5.39. Happened on down() in either usbserial->write_room() or
> usbserial->write(), when invoked from bh context.
>
> Some grepping reveals no documentation of calling context requirements
> for those driver calls and existing serial code seems to be happy with bh
> context. Therefore I'm wondering whether it is permitted to call from
> don't-sleep context?
>
> Since write_room() is usually called immediately before write()'ing stuff
> to the driver it would be a good idea to keep them both callable from bh,
> IMHO. For example tty_ldisc->write_wakeup() might probably want to issue
> write_room() followed by write().
>
> Currently, usbserial calls write_wakeup() from bh (on OUT urb completion)
> but needs process context for write_room() and write(). My impression is
> the whole point of write_room() is to find out how many data can be
> accepted by the write() - if write() would be allowed to sleep it could
> just block to deal with any amount of data.
>
> TIA for any insight.
>
> Martin
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


  reply	other threads:[~2002-10-01 11:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-01 10:37 calling context when writing to tty_driver Martin Diehl
2002-10-01 11:13 ` David McIlwraith [this message]
2002-10-01 11:28   ` Martin Diehl
2002-10-01 11:32     ` David McIlwraith
2002-10-01 18:34 ` Greg KH
2002-10-01 19:30   ` Russell King
2002-10-01 21:10   ` Martin Diehl
2002-10-03  6:52     ` Greg KH
2002-10-03  9:51       ` Paul Mackerras
2002-10-03 21:36         ` Martin Diehl
2002-10-01 23:20   ` Paul Mackerras

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='08e001c2693b$8e64e8c0$41368490@archaic' \
    --to=quack@bigpond.net.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lists@mdiehl.de \
    /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.