03 Oct, 2012
1 commit
-
Pull workqueue changes from Tejun Heo:
"This is workqueue updates for v3.7-rc1. A lot of activities this
round including considerable API and behavior cleanups.* delayed_work combines a timer and a work item. The handling of the
timer part has always been a bit clunky leading to confusing
cancelation API with weird corner-case behaviors. delayed_work is
updated to use new IRQ safe timer and cancelation now works as
expected.* Another deficiency of delayed_work was lack of the counterpart of
mod_timer() which led to cancel+queue combinations or open-coded
timer+work usages. mod_delayed_work[_on]() are added.These two delayed_work changes make delayed_work provide interface
and behave like timer which is executed with process context.* A work item could be executed concurrently on multiple CPUs, which
is rather unintuitive and made flush_work() behavior confusing and
half-broken under certain circumstances. This problem doesn't
exist for non-reentrant workqueues. While non-reentrancy check
isn't free, the overhead is incurred only when a work item bounces
across different CPUs and even in simulated pathological scenario
the overhead isn't too high.All workqueues are made non-reentrant. This removes the
distinction between flush_[delayed_]work() and
flush_[delayed_]_work_sync(). The former is now as strong as the
latter and the specified work item is guaranteed to have finished
execution of any previous queueing on return.* In addition to the various bug fixes, Lai redid and simplified CPU
hotplug handling significantly.* Joonsoo introduced system_highpri_wq and used it during CPU
hotplug.There are two merge commits - one to pull in IRQ safe timer from
tip/timers/core and the other to pull in CPU hotplug fixes from
wq/for-3.6-fixes as Lai's hotplug restructuring depended on them."Fixed a number of trivial conflicts, but the more interesting conflicts
were silent ones where the deprecated interfaces had been used by new
code in the merge window, and thus didn't cause any real data conflicts.Tejun pointed out a few of them, I fixed a couple more.
* 'for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: (46 commits)
workqueue: remove spurious WARN_ON_ONCE(in_irq()) from try_to_grab_pending()
workqueue: use cwq_set_max_active() helper for workqueue_set_max_active()
workqueue: introduce cwq_set_max_active() helper for thaw_workqueues()
workqueue: remove @delayed from cwq_dec_nr_in_flight()
workqueue: fix possible stall on try_to_grab_pending() of a delayed work item
workqueue: use hotcpu_notifier() for workqueue_cpu_down_callback()
workqueue: use __cpuinit instead of __devinit for cpu callbacks
workqueue: rename manager_mutex to assoc_mutex
workqueue: WORKER_REBIND is no longer necessary for idle rebinding
workqueue: WORKER_REBIND is no longer necessary for busy rebinding
workqueue: reimplement idle worker rebinding
workqueue: deprecate __cancel_delayed_work()
workqueue: reimplement cancel_delayed_work() using try_to_grab_pending()
workqueue: use mod_delayed_work() instead of __cancel + queue
workqueue: use irqsafe timer for delayed_work
workqueue: clean up delayed_work initializers and add missing one
workqueue: make deferrable delayed_work initializer names consistent
workqueue: cosmetic whitespace updates for macro definitions
workqueue: deprecate system_nrt[_freezable]_wq
workqueue: deprecate flush[_delayed]_work_sync()
...
21 Aug, 2012
1 commit
-
flush[_delayed]_work_sync() are now spurious. Mark them deprecated
and convert all users to flush[_delayed]_work().If you're cc'd and wondering what's going on: Now all workqueues are
non-reentrant and the regular flushes guarantee that the work item is
not pending or running on any CPU on return, so there's no reason to
use the sync flushes at all and they're going away.This patch doesn't make any functional difference.
Signed-off-by: Tejun Heo
Cc: Russell King
Cc: Paul Mundt
Cc: Ian Campbell
Cc: Jens Axboe
Cc: Mattia Dongili
Cc: Kent Yoder
Cc: David Airlie
Cc: Jiri Kosina
Cc: Karsten Keil
Cc: Bryan Wu
Cc: Benjamin Herrenschmidt
Cc: Alasdair Kergon
Cc: Mauro Carvalho Chehab
Cc: Florian Tobias Schandinat
Cc: David Woodhouse
Cc: "David S. Miller"
Cc: linux-wireless@vger.kernel.org
Cc: Anton Vorontsov
Cc: Sangbeom Kim
Cc: "James E.J. Bottomley"
Cc: Greg Kroah-Hartman
Cc: Eric Van Hensbergen
Cc: Takashi Iwai
Cc: Steven Whitehouse
Cc: Petr Vandrovec
Cc: Mark Fasheh
Cc: Christoph Hellwig
Cc: Avi Kivity
11 Aug, 2012
1 commit
-
The termios and other changes mean the other protections needed on the driver
tty arrays should be adequate. Turn it all back on.This contains pieces folded in from the fixes made to the original patches
| From: Geert Uytterhoeven (fix m68k)
| From: Paul Gortmaker (fix cris)
| From: Jiri Kosina (lockdep)
| From: Eric Dumazet (lockdep)Signed-off-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman
28 Jul, 2012
1 commit
-
Ian Abbott found that the tty layer would explode with the right set of
parallel open and close operations. This is because we race in the
handling of tty->drivers->termios[].Correct this by
Making tty_ldisc_release behave like nromal code (takes the lock,
does stuff, drops the lock)
Drop the tty lock earlier in tty_ldisc_release
Taking the tty mutex around the driver->termios update in all cases
Adding a WARN_ON to catch future screwups.I also forgot to clean up the pty resources properly. With a pty pair we
need to pull both halves out of the tables.Signed-off-by: Alan Cox
Tested-by: Ian Abbott
Signed-off-by: Greg Kroah-Hartman
27 Jul, 2012
1 commit
-
Commit acfa747b introduced the TTY_HUPPING flag to distinguish
closed TTY from currently closing ones. The test in tty_set_ldisc
still remained pointing at the old flag. This causes pppd to
sometimes lapse into uninterruptible sleep when killed and
restarted.Signed-off-by: Shachar Shemesh
Signed-off-by: Greg Kroah-Hartman
17 Jul, 2012
2 commits
-
This will let us sort out a whole pile of tty related races. The
alternative would be to keep points and refcount the termios objects.
However
1. They are tiny anyway
2. Many devices don't use the stored copies
3. We can remove a pty special caseSigned-off-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
I sent GregKH this after the pre-requisites. He dropped the pre-requesites
for good reason and unfortunately then applied this patch. Without this
reverted you get random kernel memory corruption which will make bisecting
anything between it and the properly applied patches a complete sod.Signed-off-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman
13 Jul, 2012
1 commit
-
Commit acfa747b introduced the TTY_HUPPING flag to distinguish
closed TTY from currently closing ones. The test in tty_set_ldisc
still remained pointing at the old flag. This causes pppd to
sometimes lapse into uninterruptible sleep when killed and
restarted.Signed-off-by: Shachar Shemesh
Signed-off-by: Greg Kroah-Hartman
07 Jul, 2012
1 commit
-
The termios and other changes mean the other protections needed on the driver
tty arrays should be adequate. Turn it all back on.This contains pieces folded in from the fixes made to the original patches
| From: Geert Uytterhoeven (fix m68k)
| From: Paul Gortmaker (fix cris)
| From: Jiri Kosina (lockdep)
| From: Eric Dumazet (lockdep)Signed-off-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman
03 Jun, 2012
1 commit
-
This reverts the tty layer change to use per-tty locking, because it's
not correct yet, and fixing it will require some more deep surgery.The main revert is d29f3ef39be4 ("tty_lock: Localise the lock"), but
there are several smaller commits that built upon it, they also get
reverted here. The list of reverted commits is:fde86d310886 - tty: add lockdep annotations
8f6576ad476b - tty: fix ldisc lock inversion trace
d3ca8b64b97e - pty: Fix lock inversion
b1d679afd766 - tty: drop the pty lock during hangup
abcefe5fc357 - tty/amiserial: Add missing argument for tty_unlock()
fd11b42e3598 - cris: fix missing tty arg in wait_event_interruptible_tty call
d29f3ef39be4 - tty_lock: Localise the lockThe revert had a trivial conflict in the 68360serial.c staging driver
that got removed in the meantime.Signed-off-by: Linus Torvalds
30 May, 2012
1 commit
-
This is caused by tty_release using tty_lock_pair to lock both sides of
the pty/tty pair, and then tty_ldisc_release dropping and relocking one
side only. We can drop both fine, so drop both to avoid any lock
ordering concerns.Rework the release path to fix the new locking model.
Signed-off-by: Alan Cox
Acked-by: Greg Kroah-Hartman
Signed-off-by: Linus Torvalds
11 May, 2012
1 commit
-
The global wait_queue that is used for line discipline idle handling is
moved to a separate wait_queue for each line instance. This prevents
unnecessary blocking on one line, because of idle handling on another
line.Signed-off-by: Ivo Sieben
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman
05 May, 2012
1 commit
-
In each remaining case the tty_lock is associated with a specific tty. This
means we can now lock on a per tty basis. We do need tty_lock_pair() for
the pty case. Uglier but still a step in the right direction.[fixed up calls in 3 missing drivers - gregkh]
Signed-off-by: Alan Cox
Acked-by: Arnd Bergmann
Signed-off-by: Greg Kroah-Hartman
27 Nov, 2011
1 commit
-
Signed-off-by: Greg Kroah-Hartman
18 Nov, 2011
4 commits
-
They were cut&pasted from tty_io. Many of them are not needed in
tty_ldisc.Signed-off-by: Jiri Slaby
Cc: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
For /dev/console case, we do not kill all ldisc users. It's due to
redirected_tty_write test in __tty_hangup. In that case there still
might be a process waiting e.g. in n_tty_read for input.We wait for such processes to disappear. The problem is that we use a
timeout. After this timeout, we continue closing the ldisc and start
freeing tty resources. It obviously leads to crashes when the other
process is woken.So to fix this, we wait infinitely before reiniting the ldisc. (The
tiocsetd remains untouched -- times out after 5s.)This is nicely reproducible with this run from shell:
exec 0<>/dev/console 1<>/dev/console 2<>/dev/console
and stopping a getty like:
systemctl stop serial-getty@ttyS0.serviceThe crash proper may be produced only under load or with constified
timing the same as for 92f6fa09b.Signed-off-by: Jiri Slaby
Cc: Dave Young
Cc: Dave Jones
Cc: Ben Hutchings
Cc: Dmitriy Matrosov
Cc: Alan Cox
Cc: stable
Signed-off-by: Greg Kroah-Hartman -
It is the only place where reinit is called from. And we really need
to wait for the old ldisc to go once. Actually this is the place where
the waiting originally was (before removed and re-added later).This will make the fix in the following patch easier to implement.
Signed-off-by: Jiri Slaby
Cc: Dave Young
Cc: Dave Jones
Cc: Ben Hutchings
Cc: Dmitriy Matrosov
Cc: Alan Cox
Cc: stable
Signed-off-by: Greg Kroah-Hartman -
To fix a nasty bug in ldisc hup vs. reinit we need to wait infinitely
long for ldisc to be gone. So here we add a parameter to
tty_ldisc_wait_idle to allow that.This is only a preparation for the real fix which is done in the
following patches.Signed-off-by: Jiri Slaby
Cc: Dave Young
Cc: Dave Jones
Cc: Ben Hutchings
Cc: Dmitriy Matrosov
Cc: Alan Cox
Cc: stable
Signed-off-by: Greg Kroah-Hartman
16 Nov, 2011
1 commit
-
wait_event_timeout always return value >= 0
remove the unnecessary ret < 0 checkSigned-off-by: Dave Young
Acked-by: Jiri Slaby
Signed-off-by: Greg Kroah-Hartman
24 Aug, 2011
1 commit
-
We used it really only serial and ami_serial. The rest of the
callsites were BUG/WARN_ONs to check if BTM is held. Now that we
pruned tty_locked from both of the real users, we can get rid of
tty_lock along with __big_tty_mutex_owner.Signed-off-by: Jiri Slaby
Acked-by: Arnd Bergmann
Cc: Alan Cox
Signed-off-by: Greg Kroah-Hartman
08 Jun, 2011
1 commit
-
We restored tty_ldisc_wait_idle in 100eeae2c5c (TTY: restore
tty_ldisc_wait_idle). We used it in the ldisc changing path to fix the
case where there are tasks in n_tty_read waiting for data and somebody
tries to change ldisc.Similar to the case above, there may be also tasks waiting in
n_tty_read while hangup is performed. As 65b770468e98 (tty-ldisc: turn
ldisc user count into a proper refcount) removed the wait-until-idle
from all paths, hangup path won't wait for them to disappear either
now. So add it back even to the hangup path.There is a difference, we need uninterruptible sleep as there is
obviously HUP signal pending. So tty_ldisc_wait_idle now sleeps
without possibility to be interrupted. This is what original
tty_ldisc_wait_idle did. After the wait idle reintroduction
(100eeae2c5c), we have had interruptible sleeps for the ldisc changing
path. But as there is a 5s timeout anyway, we don't allow it to be
interrupted from now on. It's not worth the added complexity of
deciding what kind of sleep we want.Before 65b770468e98 tty_ldisc_release was called also from
tty_ldisc_release. It is called from tty_release, so I don't think we
need to restore that one.This is nicely reproducible after constifying the timing when
drivers/tty/n_tty.c is patched as follows ("TTY: ntty, add one more
sanity check" patch is needed to actually see it explode):
%% -1548,6 +1549,7 @@ static int n_tty_open(struct tty_struct *tty)/* These are ugly. Currently a malloc failure here can panic */
if (!tty->read_buf) {
+ msleep(100);
tty->read_buf = kzalloc(N_TTY_BUF_SIZE, GFP_KERNEL);
if (!tty->read_buf)
return -ENOMEM;
%% -1785,6 +1788,7 @@ do_it_again:
break;
}
timeout = schedule_timeout(timeout);
+ msleep(20);
continue;
}
__set_current_state(TASK_RUNNING);
===== With a process: =====
while (1) {
int fd = open(argv[1], O_RDWR);
read(fd, buf, sizeof(buf));
close(fd);
}
===== and its child: =====
setsid();
while (1) {
int fd = open(tty, O_RDWR|O_NOCTTY);
ioctl(fd, TIOCSCTTY, 1);
vhangup();
close(fd);
usleep(100 * (10 + random() % 1000));
}
===== EOF =====References: https://bugzilla.novell.com/show_bug.cgi?id=693374
References: https://bugzilla.novell.com/show_bug.cgi?id=694509
Signed-off-by: Jiri Slaby
Cc: Alan Cox
Cc: Linus Torvalds
Cc: stable [32, 33, 34, 39]
Signed-off-by: Greg Kroah-Hartman
20 Apr, 2011
1 commit
-
Introduce deinitialize_tty_struct which should be called after
initialize_tty_struct and before successfull tty_ldisc_setup.It calls tty_ldisc_deinit which is opposite of tty_ldisc_init. It only
puts a reference to ldisc and assigns NULL to tty->ldisc.It will be used to shut down ldisc when tty_release cannot be called
yet.Signed-off-by: Jiri Slaby
Cc: Alan Cox
Cc: Julian Anastasov
Signed-off-by: Greg Kroah-Hartman
23 Mar, 2011
1 commit
-
Using delayed-work for tty flip buffers ends up causing us to wait for
the next tick to complete some actions. That's usually not all that
noticeable, but for certain latency-critical workloads it ends up being
totally unacceptable.As an extreme case of this, passing a token back-and-forth over a pty
will take two ticks per iteration, so even just a thousand iterations
will take 8 seconds assuming a common 250Hz configuration.Avoiding the whole delayed work issue brings that ping-pong test-case
down to 0.009s on my machine.In more practical terms, this latency has been a performance problem for
things like dive computer simulators (simulating the serial interface
using the ptys) and for other environments (Alan mentions a CP/M emulator).Reported-by: Jef Driesen
Acked-by: Greg KH
Acked-by: Alan Cox
Signed-off-by: Linus Torvalds
17 Mar, 2011
1 commit
-
* 'config' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/bkl:
BKL: That's all, folks
fs/locks.c: Remove stale FIXME left over from BKL conversion
ipx: remove the BKL
appletalk: remove the BKL
x25: remove the BKL
ufs: remove the BKL
hpfs: remove the BKL
drivers: remove extraneous includes of smp_lock.h
tracing: don't trace the BKL
adfs: remove the big kernel lock
02 Mar, 2011
1 commit
-
These were missed the last time I cleaned this up
globally, because of code moving around or new code
getting merged.Signed-off-by: Arnd Bergmann
04 Feb, 2011
1 commit
-
flush_scheduled_work() is scheduled to be deprecated. Explicitly sync
flush the used work items instead. Note that before this change,
flush_scheduled_work() wouldn't have properly flushed tty->buf.work if
it were on timer.Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman
30 Nov, 2010
1 commit
-
When a concrete ldisc open fails in tty_ldisc_open, we forget to clear
TTY_LDISC_OPEN. This causes a false warning on the next ldisc open:
WARNING: at drivers/char/tty_ldisc.c:445 tty_ldisc_open+0x26/0x38()
Hardware name: System Product Name
Modules linked in: ...
Pid: 5251, comm: a.out Tainted: G W 2.6.32-5-686 #1
Call Trace:
[] ? warn_slowpath_common+0x5e/0x8a
[] ? warn_slowpath_null+0xa/0xc
[] ? tty_ldisc_open+0x26/0x38
[] ? tty_set_ldisc+0x218/0x304
...So clear the bit when failing...
Introduced in c65c9bc3efa (tty: rewrite the ldisc locking) back in
2.6.31-rc1.Signed-off-by: Jiri Slaby
Cc: Alan Cox
Reported-by: Sergey Lapin
Tested-by: Sergey Lapin
Cc: stable
Signed-off-by: Greg Kroah-Hartman
10 Nov, 2010
2 commits
-
A kernel BUG when bluetooth rfcomm connection drop while the associated
serial port is open is sometime triggered.It seems that the line discipline can disappear between the
tty_ldisc_put and tty_ldisc_get. This patch fall back to the N_TTY line
discipline if the previous discipline is not available anymore.Signed-off-by: Philippe Retornaz
Acked-by: Alan Cox
Cc: stable
Signed-off-by: Greg Kroah-Hartman -
It was removed in 65b770468e98 (tty-ldisc: turn ldisc user count into
a proper refcount), but we need to wait for last user to quit the
ldisc before we close it in tty_set_ldisc.Otherwise weird things start to happen. There might be processes
waiting in tty_read->n_tty_read on tty->read_wait for input to appear
and at that moment, a change of ldisc is fatal. n_tty_close is called,
it frees read_buf and the waiting process is still in the middle of
reading and goes nuts after it is woken.Previously we prevented close to happen when others are in ldisc ops
by tty_ldisc_wait_idle in tty_set_ldisc. But the commit above removed
that. So revoke the change and test whether there is 1 user (=we), and
allow the close then.We can do that without ldisc/tty locks, because nobody else can open
the device due to TTY_LDISC_CHANGING bit set, so we in fact wait for
everybody to leave.I don't understand why tty_ldisc_lock would be needed either when the
counter is an atomic variable, so this is a lockless
tty_ldisc_wait_idle.On the other hand, if we fail to wait (timeout or signal), we have to
reenable the halted ldiscs, so we take ldisc lock and reuse the setup
path at the end of tty_set_ldisc.Signed-off-by: Jiri Slaby
Acked-by: Linus Torvalds
Tested-by: Sebastian Andrzej Siewior
LKML-Reference:
LKML-Reference:
Cc: Alan Cox
Cc: stable@kernel.org [32, 33, 36]
Signed-off-by: Greg Kroah-Hartman
05 Nov, 2010
1 commit
-
The tty code should be in its own subdirectory and not in the char
driver with all of the cruft that is currently there.Based on work done by Arnd Bergmann
Acked-by: Arnd Bergmann
Cc: Jiri Slaby
Cc: Alan Cox
Signed-off-by: Greg Kroah-Hartman