linux-stable.git/drivers/tty/hvc, branch v5.15.78

tty: hvc: fix return value of __setup handler

2022-04-08T12:23:50+00:00

[ Upstream commit 53819a0d97aace1425bb042829e3446952a9e8a9 ]

__setup() handlers should return 1 to indicate that the boot option
has been handled or 0 to indicate that it was not handled.
Add a pr_warn() message if the option value is invalid and then
always return 1.

Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru
Fixes: 86b40567b917 ("tty: replace strict_strtoul() with kstrtoul()")
Cc: Jingoo Han 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: Michael Ellerman 
Cc: Julian Wiedmann 
Cc: Vasily Gorbik 
Cc: linuxppc-dev@lists.ozlabs.org
Reported-by: Igor Zhbanov 
Signed-off-by: Randy Dunlap 
Link: https://lore.kernel.org/r/20220308024228.20477-1-rdunlap@infradead.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

xen/console: harden hvc_xen against event channel storms

2021-12-22T08:32:52+00:00

commit fe415186b43df0db1f17fa3a46275fd92107fe71 upstream.

The Xen console driver is still vulnerable for an attack via excessive
number of events sent by the backend. Fix that by using a lateeoi event
channel.

For the normal domU initial console this requires the introduction of
bind_evtchn_to_irq_lateeoi() as there is no xenbus device available
at the time the event channel is bound to the irq.

As the decision whether an interrupt was spurious or not requires to
test for bytes having been read from the backend, move sending the
event into the if statement, as sending an event without having found
any bytes to be read is making no sense at all.

This is part of XSA-391

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'for-linus-5.15b-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip

2021-10-08T19:55:23+00:00

Pull xen fixes from Juergen Gross:

 - fix two minor issues in the Xen privcmd driver plus a cleanup patch
   for that driver

 - fix multiple issues related to running as PVH guest and some related
   earlyprintk fixes for other Xen guest types

 - fix an issue introduced in 5.15 the Xen balloon driver

* tag 'for-linus-5.15b-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  xen/balloon: fix cancelled balloon action
  xen/x86: adjust data placement
  x86/PVH: adjust function/data placement
  xen/x86: hook up xen_banner() also for PVH
  xen/x86: generalize preferred console model from PV to PVH Dom0
  xen/x86: make "earlyprintk=xen" work for HVM/PVH DomU
  xen/x86: allow "earlyprintk=xen" to work for PV Dom0
  xen/x86: make "earlyprintk=xen" work better for PVH Dom0
  xen/x86: allow PVH Dom0 without XEN_PV=y
  xen/x86: prevent PVH type from getting clobbered
  xen/privcmd: drop "pages" parameter from xen_remap_pfn()
  xen/privcmd: fix error handling in mmap-resource processing
  xen/privcmd: replace kcalloc() by kvcalloc() when allocating empty pages

xen/x86: make "earlyprintk=xen" work for HVM/PVH DomU

2021-10-05T06:36:05+00:00

xenboot_write_console() is dealing with these quite fine so I don't see
why xenboot_console_setup() would return -ENOENT in this case.

Adjust documentation accordingly.

Signed-off-by: Jan Beulich 
Reviewed-by: Juergen Gross 

Link: https://lore.kernel.org/r/3d212583-700e-8b2d-727a-845ef33ac265@suse.com
Signed-off-by: Juergen Gross

xen/x86: make "earlyprintk=xen" work better for PVH Dom0

2021-10-05T06:36:00+00:00

The xen_hvm_early_write() path better wouldn't be taken in this case;
while port 0xE9 can be used, the hypercall path is quite a bit more
efficient. Put that first, as it may also work for DomU-s (see also
xen_raw_console_write()).

While there also bail from the function when the first
domU_write_console() failed - later ones aren't going to succeed.

Signed-off-by: Jan Beulich 
Reviewed-by: Juergen Gross 

Link: https://lore.kernel.org/r/4fd89dcb-cfc5-c740-2e94-bb271e432d3e@suse.com
Signed-off-by: Juergen Gross

tty: drop put_tty_driver

2021-07-27T10:17:21+00:00

put_tty_driver() is an alias for tty_driver_kref_put(). There is no need
for two exported identical functions, therefore switch all users of
old put_tty_driver() to new tty_driver_kref_put() and remove the former
for good.

Cc: Richard Henderson 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Cc: Geert Uytterhoeven 
Cc: Jeff Dike 
Cc: Richard Weinberger 
Cc: Anton Ivanov 
Cc: Chris Zankel 
Cc: Max Filippov 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: Samuel Iglesias Gonsalvez 
Cc: Jens Taprogge 
Cc: Karsten Keil 
Cc: Scott Branden 
Cc: Ulf Hansson 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Cc: Christian Borntraeger 
Cc: David Lin 
Cc: Johan Hovold 
Cc: Alex Elder 
Cc: Jiri Slaby 
Cc: Laurentiu Tudor 
Cc: Jiri Kosina 
Cc: David Sterba 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Pengutronix Kernel Team 
Cc: Fabio Estevam 
Cc: NXP Linux Team 
Cc: Oliver Neukum 
Cc: Felipe Balbi 
Cc: Mathias Nyman 
Cc: Marcel Holtmann 
Cc: Johan Hedberg 
Cc: Luiz Augusto von Dentz 
Acked-by: Alex Elder 
Acked-by: Christian Borntraeger 
Acked-by: Max Filippov 
Acked-by: David Sterba 
Acked-by: Samuel Iglesias Gonsálvez 
Signed-off-by: Jiri Slaby 
Link: https://lore.kernel.org/r/20210723074317.32690-8-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman

tty: stop using alloc_tty_driver

2021-07-27T10:17:20+00:00

alloc_tty_driver was deprecated by tty_alloc_driver in commit
7f0bc6a68ed9 (TTY: pass flags to alloc_tty_driver) in 2012.

I never got into eliminating alloc_tty_driver until now. So we still
have two functions for allocating drivers which might be confusing. So
get rid of alloc_tty_driver uses to eliminate it for good in the next
patch.

Note we need to switch return value checking as tty_alloc_driver uses
ERR_PTR. And flags are now a parameter of tty_alloc_driver.

Cc: Richard Henderson (odd fixer:ALPHA PORT)
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Cc: Geert Uytterhoeven 
Cc: "James E.J. Bottomley" 
Cc: Helge Deller 
Cc: Jeff Dike 
Cc: Richard Weinberger 
Cc: Anton Ivanov 
Cc: Chris Zankel 
Cc: Max Filippov 
Cc: Samuel Iglesias Gonsalvez 
Cc: Jens Taprogge 
Cc: Karsten Keil 
Cc: Ulf Hansson 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Cc: Christian Borntraeger 
Cc: Laurentiu Tudor 
Cc: Jiri Kosina 
Cc: David Sterba 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Oliver Neukum 
Cc: Felipe Balbi 
Cc: Johan Hovold 
Cc: Marcel Holtmann 
Cc: Johan Hedberg 
Cc: Luiz Augusto von Dentz 
Acked-by: Samuel Iglesias Gonsálvez 
Acked-by: Max Filippov 
Acked-by: David Sterba 
Acked-by: Christian Borntraeger 
Signed-off-by: Jiri Slaby 
Link: https://lore.kernel.org/r/20210723074317.32690-5-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman

tty: don't store semi-state into tty drivers

2021-07-27T10:17:20+00:00

When a tty driver pointer is used as a return value of struct
console's device() hook, don't store a semi-state into global variable
which holds the tty driver. It could mean console::device() would return
a bogus value. This is important esp. after the next patch where we
switch from alloc_tty_driver to tty_alloc_driver. tty_alloc_driver
returns ERR_PTR in case of error and that might have unexpected results
as the code doesn't expect this.

Cc: Geert Uytterhoeven 
Cc: "James E.J. Bottomley" 
Cc: Helge Deller 
Cc: Chris Zankel 
Cc: Max Filippov 
Cc: Laurentiu Tudor 
Cc: Felipe Balbi 
Reviewed-by: Max Filippov 
Acked-by: Helge Deller 	# parisc
Signed-off-by: Jiri Slaby 
Link: https://lore.kernel.org/r/20210723074317.32690-4-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman

hvsi: don't panic on tty_register_driver failure

2021-07-27T10:17:20+00:00

The alloc_tty_driver failure is handled gracefully in hvsi_init. But
tty_register_driver is not. panic is called if that one fails.

So handle the failure of tty_register_driver gracefully too. This will
keep at least the console functional as it was enabled earlier by
console_initcall in hvsi_console_init. Instead of shooting down the
whole system.

This means, we disable interrupts and restore hvsi_wait back to
poll_for_state().

Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Jiri Slaby 
Link: https://lore.kernel.org/r/20210723074317.32690-3-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman

tty: hvc: replace BUG_ON() with negative return value

2021-07-21T13:57:28+00:00

Xen frontends shouldn't BUG() in case of illegal data received from
their backends. So replace the BUG_ON()s when reading illegal data from
the ring page with negative return values.

Reviewed-by: Jan Beulich 
Signed-off-by: Juergen Gross 
Link: https://lore.kernel.org/r/20210707091045.460-1-jgross@suse.com
Signed-off-by: Greg Kroah-Hartman