linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Grant Edwards <grant.b.edwards@gmail.com>
To: linux-serial@vger.kernel.org
Subject: Persistent problem with wait_until_sent timeout parameter type mismatch
Date: Fri, 21 Aug 2009 20:03:54 +0000 (UTC)	[thread overview]
Message-ID: <h6muja$6ol$1@ger.gmane.org> (raw)

I seem to have run into a problem which people have been
pointing out for years, but never gets fixed.

In tty_driver.h, the low-level driver routine wait_until_set()
function takes an "int" as a timeout value:

   192	struct tty_operations {
   193		int  (*open)(struct tty_struct * tty, struct file * filp);
[...]
   214		void (*wait_until_sent)(struct tty_struct *tty, int timeout);
[...]
   228	};

But, in tty_ioclt.c in the tty_wait_unti_sent() function, the
timeout is a "long":

    98	void tty_wait_until_sent(struct tty_struct *tty, long timeout)
    99	{
   100	#ifdef TTY_DEBUG_WAIT_UNTIL_SENT
   101		char buf[64];
   102	
   103		printk(KERN_DEBUG "%s wait until sent...\n", tty_name(tty, buf));
   104	#endif
   105		if (!timeout)
   106			timeout = MAX_SCHEDULE_TIMEOUT;
   107		if (wait_event_interruptible_timeout(tty->write_wait,
   108				!tty_chars_in_buffer(tty), timeout) >= 0) {
   109			if (tty->ops->wait_until_sent)
   110				tty->ops->wait_until_sent(tty, timeout);
   111		}
   112	}
   113	EXPORT_SYMBOL(tty_wait_until_sent);

This is fine on 32-bit systems, where "int" and "long" are
equivalent, but it results in breakage on 64-bit systems.  At
line 106, timeout is set to MAX_SCHEDULE_TIMEOUT which is 
7fffffffffffffff.  When that value is passed to the low-level
driver routine at line 110, it gets truncated to ffffffff --
which is -1.  That means that waiting until (jiffies+timeout)
returns immediately when the caller's intent was to wait as
long as possible.

People have been pointing out that type mismatch for many years
now.  What's the justification for the low-level driver routine
parameter being "int" instead of "long"?

Since this doesn't seem to be something that's going to be
fixed, I guess a work-around for those of us who maintain
serial drivers is to treat a timeout of -1 as a special value
that means "forever"?  Is that the intent?

-- 
Grant Edwards                   grante             Yow! I feel like a wet
                                  at               parking meter on Darvon!
                               visi.com            


             reply	other threads:[~2009-08-21 20:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-21 20:03 Grant Edwards [this message]
2009-08-28 14:33 ` Persistent problem with wait_until_sent timeout parameter type mismatch Grant Edwards
2009-09-16  5:57 ` Grant Edwards

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='h6muja$6ol$1@ger.gmane.org' \
    --to=grant.b.edwards@gmail.com \
    --cc=linux-serial@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).