<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/tty/vt, branch linux-3.4.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>vt: provide notifications on selection changes</title>
<updated>2015-06-19T03:40:13+00:00</updated>
<author>
<name>Nicolas Pitre</name>
<email>nicolas.pitre@linaro.org</email>
</author>
<published>2015-01-23T22:07:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=68e9176bf7429cce8ed93859a1995f2d0f3ca209'/>
<id>68e9176bf7429cce8ed93859a1995f2d0f3ca209</id>
<content type='text'>
commit 19e3ae6b4f07a87822c1c9e7ed99d31860e701af upstream.

The vcs device's poll/fasync support relies on the vt notifier to signal
changes to the screen content.  Notifier invocations were missing for
changes that comes through the selection interface though.  Fix that.

Tested with BRLTTY 5.2.

Signed-off-by: Nicolas Pitre &lt;nico@linaro.org&gt;
Cc: Dave Mielke &lt;dave@mielke.cc&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 19e3ae6b4f07a87822c1c9e7ed99d31860e701af upstream.

The vcs device's poll/fasync support relies on the vt notifier to signal
changes to the screen content.  Notifier invocations were missing for
changes that comes through the selection interface though.  Fix that.

Tested with BRLTTY 5.2.

Signed-off-by: Nicolas Pitre &lt;nico@linaro.org&gt;
Cc: Dave Mielke &lt;dave@mielke.cc&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tty/vt: don't set font mappings on vc not supporting this</title>
<updated>2015-02-02T09:05:15+00:00</updated>
<author>
<name>Imre Deak</name>
<email>imre.deak@intel.com</email>
</author>
<published>2014-10-02T13:34:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0bb9566eaaabf31b2368340fbedc34010c09e8f0'/>
<id>0bb9566eaaabf31b2368340fbedc34010c09e8f0</id>
<content type='text'>
commit 9e326f78713a4421fe11afc2ddeac07698fac131 upstream.

We can call this function for a dummy console that doesn't support
setting the font mapping, which will result in a null ptr BUG. So check
for this case and return error for consoles w/o font mapping support.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=59321
Signed-off-by: Imre Deak &lt;imre.deak@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
[lizf: Backported to 3.4: just return -EINVAL as we don't need to unlock]
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9e326f78713a4421fe11afc2ddeac07698fac131 upstream.

We can call this function for a dummy console that doesn't support
setting the font mapping, which will result in a null ptr BUG. So check
for this case and return error for consoles w/o font mapping support.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=59321
Signed-off-by: Imre Deak &lt;imre.deak@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
[lizf: Backported to 3.4: just return -EINVAL as we don't need to unlock]
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>vt: synchronize_rcu() under spinlock is not nice...</title>
<updated>2013-04-05T17:04:19+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2013-03-27T00:30:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=86302600f82d715647154e18a96245642f1bf71e'/>
<id>86302600f82d715647154e18a96245642f1bf71e</id>
<content type='text'>
commit e8cd81693bbbb15db57d3c9aa7dd90eda4842874 upstream.

vcs_poll_data_free() calls unregister_vt_notifier(), which calls
atomic_notifier_chain_unregister(), which calls synchronize_rcu().
Do it *after* we'd dropped -&gt;f_lock.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e8cd81693bbbb15db57d3c9aa7dd90eda4842874 upstream.

vcs_poll_data_free() calls unregister_vt_notifier(), which calls
atomic_notifier_chain_unregister(), which calls synchronize_rcu().
Do it *after* we'd dropped -&gt;f_lock.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>fb: Yet another band-aid for fixing lockdep mess</title>
<updated>2013-02-28T14:59:05+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2013-01-25T00:28:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f515e1d59602f8eafaad39b6842bd823ad34654e'/>
<id>f515e1d59602f8eafaad39b6842bd823ad34654e</id>
<content type='text'>
commit e93a9a868792ad71cdd09d75e5a02d8067473c4e upstream.

I've still got lockdep warnings even after Alan's patch, and it seems that
yet more band aids are required to paper over similar paths for
unbind_con_driver() and unregister_con_driver().  After this hack, lockdep
warnings are finally gone.

Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: Alan Cox &lt;alan@linux.intel.com&gt;
Cc: Florian Tobias Schandinat &lt;FlorianSchandinat@gmx.de&gt;
Cc: Jiri Kosina &lt;jkosina@suse.cz&gt;
Tested-by: Sedat Dilek &lt;sedat.dilek@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e93a9a868792ad71cdd09d75e5a02d8067473c4e upstream.

I've still got lockdep warnings even after Alan's patch, and it seems that
yet more band aids are required to paper over similar paths for
unbind_con_driver() and unregister_con_driver().  After this hack, lockdep
warnings are finally gone.

Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: Alan Cox &lt;alan@linux.intel.com&gt;
Cc: Florian Tobias Schandinat &lt;FlorianSchandinat@gmx.de&gt;
Cc: Jiri Kosina &lt;jkosina@suse.cz&gt;
Tested-by: Sedat Dilek &lt;sedat.dilek@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>fb: rework locking to fix lock ordering on takeover</title>
<updated>2013-02-28T14:59:05+00:00</updated>
<author>
<name>Alan Cox</name>
<email>alan@linux.intel.com</email>
</author>
<published>2013-01-25T00:28:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c30b55c385288be48f7accd16a6929ad4d983311'/>
<id>c30b55c385288be48f7accd16a6929ad4d983311</id>
<content type='text'>
commit 50e244cc793d511b86adea24972f3a7264cae114 upstream.

Adjust the console layer to allow a take over call where the caller
already holds the locks.  Make the fb layer lock in order.

This is partly a band aid, the fb layer is terminally confused about the
locking rules it uses for its notifiers it seems.

[akpm@linux-foundation.org: remove stray non-ascii char, tidy comment]
[akpm@linux-foundation.org: export do_take_over_console()]
[airlied: cleanup another non-ascii char]
Signed-off-by: Alan Cox &lt;alan@linux.intel.com&gt;
Cc: Florian Tobias Schandinat &lt;FlorianSchandinat@gmx.de&gt;
Cc: Stephen Rothwell &lt;sfr@canb.auug.org.au&gt;
Cc: Jiri Kosina &lt;jkosina@suse.cz&gt;
Tested-by: Sedat Dilek &lt;sedat.dilek@gmail.com&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 50e244cc793d511b86adea24972f3a7264cae114 upstream.

Adjust the console layer to allow a take over call where the caller
already holds the locks.  Make the fb layer lock in order.

This is partly a band aid, the fb layer is terminally confused about the
locking rules it uses for its notifiers it seems.

[akpm@linux-foundation.org: remove stray non-ascii char, tidy comment]
[akpm@linux-foundation.org: export do_take_over_console()]
[airlied: cleanup another non-ascii char]
Signed-off-by: Alan Cox &lt;alan@linux.intel.com&gt;
Cc: Florian Tobias Schandinat &lt;FlorianSchandinat@gmx.de&gt;
Cc: Stephen Rothwell &lt;sfr@canb.auug.org.au&gt;
Cc: Jiri Kosina &lt;jkosina@suse.cz&gt;
Tested-by: Sedat Dilek &lt;sedat.dilek@gmail.com&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>vgacon/vt: clear buffer attributes when we load a 512 character font (v2)</title>
<updated>2013-02-28T14:59:03+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2013-01-24T04:14:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=df28f4890263a0540b395402b43b57f047ccf7d5'/>
<id>df28f4890263a0540b395402b43b57f047ccf7d5</id>
<content type='text'>
commit 2a2483072393b27f4336ab068a1f48ca19ff1c1e upstream.

When we switch from 256-&gt;512 byte font rendering mode, it means the
current contents of the screen is being reinterpreted. The bit that holds
the high bit of the 9-bit font, may have been previously set, and thus
the new font misrenders.

The problem case we see is grub2 writes spaces with the bit set, so it
ends up with data like 0x820, which gets reinterpreted into 0x120 char
which the font translates into G with a circumflex. This flashes up on
screen at boot and is quite ugly.

A current side effect of this patch though is that any rendering on the
screen changes color to a slightly darker color, but at least the screen
no longer corrupts.

v2: as suggested by hpa, always clear the attribute space, whether we
are are going to or from 512 chars.

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2a2483072393b27f4336ab068a1f48ca19ff1c1e upstream.

When we switch from 256-&gt;512 byte font rendering mode, it means the
current contents of the screen is being reinterpreted. The bit that holds
the high bit of the 9-bit font, may have been previously set, and thus
the new font misrenders.

The problem case we see is grub2 writes spaces with the bit set, so it
ends up with data like 0x820, which gets reinterpreted into 0x120 char
which the font translates into G with a circumflex. This flashes up on
screen at boot and is quite ugly.

A current side effect of this patch though is that any rendering on the
screen changes color to a slightly darker color, but at least the screen
no longer corrupts.

v2: as suggested by hpa, always clear the attribute space, whether we
are are going to or from 512 chars.

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>kdb,vt_console: Fix missed data due to pager overruns</title>
<updated>2012-10-21T16:27:59+00:00</updated>
<author>
<name>Jason Wessel</name>
<email>jason.wessel@windriver.com</email>
</author>
<published>2012-08-27T03:37:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c4c493a4adcee75e1e44af044d0b7fc1b5192b61'/>
<id>c4c493a4adcee75e1e44af044d0b7fc1b5192b61</id>
<content type='text'>
commit 17b572e82032bc246324ce136696656b66d4e3f1 upstream.

It is possible to miss data when using the kdb pager.  The kdb pager
does not pay attention to the maximum column constraint of the screen
or serial terminal.  This result is not incrementing the shown lines
correctly and the pager will print more lines that fit on the screen.
Obviously that is less than useful when using a VGA console where you
cannot scroll back.

The pager will now look at the kdb_buffer string to see how many
characters are printed.  It might not be perfect considering you can
output ASCII that might move the cursor position, but it is a
substantially better approximation for viewing dmesg and trace logs.

This also means that the vt screen needs to set the kdb COLUMNS
variable.

Signed-off-by: Jason Wessel &lt;jason.wessel@windriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 17b572e82032bc246324ce136696656b66d4e3f1 upstream.

It is possible to miss data when using the kdb pager.  The kdb pager
does not pay attention to the maximum column constraint of the screen
or serial terminal.  This result is not incrementing the shown lines
correctly and the pager will print more lines that fit on the screen.
Obviously that is less than useful when using a VGA console where you
cannot scroll back.

The pager will now look at the kdb_buffer string to see how many
characters are printed.  It might not be perfect considering you can
output ASCII that might move the cursor position, but it is a
substantially better approximation for viewing dmesg and trace logs.

This also means that the vt screen needs to set the kdb COLUMNS
variable.

Signed-off-by: Jason Wessel &lt;jason.wessel@windriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tty: keyboard.c: Remove locking from vt_get_leds.</title>
<updated>2012-10-07T15:32:23+00:00</updated>
<author>
<name>Christopher Brannon</name>
<email>chris@the-brannons.com</email>
</author>
<published>2012-06-22T13:16:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0f2c427a4f4a994526bea7ce3855284fc5a7940a'/>
<id>0f2c427a4f4a994526bea7ce3855284fc5a7940a</id>
<content type='text'>
commit 157a4b311c45c9aba75a990464d9680867dc8805 upstream.

There are three call sites for this function, and all three
are called within a keyboard handler.
kbd_event_lock is already held within keyboard handlers,
so attempting to lock it in vt_get_leds causes deadlock.

Signed-off-by: Christopher Brannon &lt;chris@the-brannons.com&gt;
Acked-by: Alan Cox &lt;alan@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 157a4b311c45c9aba75a990464d9680867dc8805 upstream.

There are three call sites for this function, and all three
are called within a keyboard handler.
kbd_event_lock is already held within keyboard handlers,
so attempting to lock it in vt_get_leds causes deadlock.

Signed-off-by: Christopher Brannon &lt;chris@the-brannons.com&gt;
Acked-by: Alan Cox &lt;alan@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tty: Fix LED error return</title>
<updated>2012-05-14T17:43:24+00:00</updated>
<author>
<name>Alan Cox</name>
<email>alan@linux.intel.com</email>
</author>
<published>2012-05-14T13:41:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=eea41aee2bfad4cf5c84e1cab8aa068c66206651'/>
<id>eea41aee2bfad4cf5c84e1cab8aa068c66206651</id>
<content type='text'>
3.4-rc introduced a regression when setting the LEDS. We do the right thing
but then return an error code.

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=43144
Reported-by: Christian Casteyde
Signed-off-by: Alan Cox &lt;alan@linux/intel.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
3.4-rc introduced a regression when setting the LEDS. We do the right thing
but then return an error code.

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=43144
Reported-by: Christian Casteyde
Signed-off-by: Alan Cox &lt;alan@linux/intel.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>vt: Fix deadlock on scroll-lock</title>
<updated>2012-05-01T18:01:28+00:00</updated>
<author>
<name>Alan Cox</name>
<email>alan@linux.intel.com</email>
</author>
<published>2012-05-01T15:12:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=84f904ecd3aa2ccb5779b815b69c1cb592f07bb5'/>
<id>84f904ecd3aa2ccb5779b815b69c1cb592f07bb5</id>
<content type='text'>
Fixing the locking accidentally replaced a race in the scroll
lock handling with a deadlock. Turn it back into a race for
now.

The basic problem is that there are two paths into the tty
stop/start helpers. One via the tty layer ^S/^Q handling
where we need to take the kbd_event_lock and one via the
special keyboard handler for fn_hold where we already hold
it. Probably we need to split out into a separate LED lock
but for now just go back to the race as it's a bit close
to release.

Reported-by: Clemens Ladisch &lt;clemens@ladisch.de&gt;
Cc: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Alan Cox &lt;alan@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fixing the locking accidentally replaced a race in the scroll
lock handling with a deadlock. Turn it back into a race for
now.

The basic problem is that there are two paths into the tty
stop/start helpers. One via the tty layer ^S/^Q handling
where we need to take the kbd_event_lock and one via the
special keyboard handler for fn_hold where we already hold
it. Probably we need to split out into a separate LED lock
but for now just go back to the race as it's a bit close
to release.

Reported-by: Clemens Ladisch &lt;clemens@ladisch.de&gt;
Cc: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Alan Cox &lt;alan@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
