linux-stable.git/drivers/xen, branch v4.16.7

xen: xenbus_dev_frontend: Fix XS_TRANSACTION_END handling

2018-04-19T06:54:09+00:00

commit 2a22ee6c3ab1d761bc9c04f1e4117edd55b82f09 upstream.

Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple
concurrent xenstore accesses") made a subtle change to the semantic of
xenbus_dev_request_and_reply() and xenbus_transaction_end().

Before on an error response to XS_TRANSACTION_END
xenbus_dev_request_and_reply() would not decrement the active
transaction counter. But xenbus_transaction_end() has always counted the
transaction as finished regardless of the response.

The new behavior is that xenbus_dev_request_and_reply() and
xenbus_transaction_end() will always count the transaction as finished
regardless the response code (handled in xs_request_exit()).

But xenbus_dev_frontend tries to end a transaction on closing of the
device if the XS_TRANSACTION_END failed before. Trying to close the
transaction twice corrupts the reference count. So fix this by also
considering a transaction closed if we have sent XS_TRANSACTION_END once
regardless of the return code.

Cc:  # 4.11
Fixes: fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent xenstore accesses")
Signed-off-by: Simon Gaiser 
Reviewed-by: Juergen Gross 
Signed-off-by: Boris Ostrovsky 
Signed-off-by: Greg Kroah-Hartman

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

2018-03-10T00:54:18+00:00

Pull xen fix from Juergen Gross:
 "Just one fix for the correct error handling after a failed
  device_register()"

* tag 'for-linus-4.16a-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  xen: xenbus: use put_device() instead of kfree()

xen: xenbus: use put_device() instead of kfree()

2018-03-08T14:30:30+00:00

Never directly free @dev after calling device_register(), even
if it returned an error! Always use put_device() to give up the
reference initialized.

Signed-off-by: Arvind Yadav 
Reviewed-by: Juergen Gross 
Signed-off-by: Juergen Gross

Merge tag 'for-linus-4.16a-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip

2018-03-02T18:19:57+00:00

Pull xen fixes from Juergen Gross:
 "Five minor fixes for Xen-specific drivers"

* tag 'for-linus-4.16a-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  pvcalls-front: 64-bit align flags
  x86/xen: add tty0 and hvc0 as preferred consoles for dom0
  xen-netfront: Fix hang on device removal
  xen/pirq: fix error path cleanup when binding MSIs
  xen/pvcalls: fix null pointer dereference on map->sock

pvcalls-front: 64-bit align flags

2018-03-01T06:23:36+00:00

We are using test_and_* operations on the status and flag fields of
struct sock_mapping. However, these functions require the operand to be
64-bit aligned on arm64. Currently, only status is 64-bit aligned.

Make status and flags explicitly 64-bit aligned.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: Juergen Gross

xen/pirq: fix error path cleanup when binding MSIs

2018-02-28T19:20:01+00:00

Current cleanup in the error path of xen_bind_pirq_msi_to_irq is
wrong. First of all there's an off-by-one in the cleanup loop, which
can lead to unbinding wrong IRQs.

Secondly IRQs not bound won't be freed, thus leaking IRQ numbers.

Note that there's no need to differentiate between bound and unbound
IRQs when freeing them, __unbind_from_irq will deal with both of them
correctly.

Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups")
Reported-by: Hooman Mirhadi 
Signed-off-by: Roger Pau Monné 
Reviewed-by: Amit Shah 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: Juergen Gross

xen/pvcalls: fix null pointer dereference on map->sock

2018-02-26T16:13:12+00:00

Currently if map is null then a potential null pointer deference
occurs when calling sock_release on map->sock.  I believe the
actual intention was to call sock_release on sock instead. Fix
this.

Fixes: 5db4d286a8ef ("xen/pvcalls: implement connect command")
Signed-off-by: Colin Ian King 
Reviewed-by: Juergen Gross 
Signed-off-by: Juergen Gross

mm, swap, frontswap: fix THP swap if frontswap enabled

2018-02-21T23:35:43+00:00

It was reported by Sergey Senozhatsky that if THP (Transparent Huge
Page) and frontswap (via zswap) are both enabled, when memory goes low
so that swap is triggered, segfault and memory corruption will occur in
random user space applications as follow,

kernel: urxvt[338]: segfault at 20 ip 00007fc08889ae0d sp 00007ffc73a7fc40 error 6 in libc-2.26.so[7fc08881a000+1ae000]
 #0  0x00007fc08889ae0d _int_malloc (libc.so.6)
 #1  0x00007fc08889c2f3 malloc (libc.so.6)
 #2  0x0000560e6004bff7 _Z14rxvt_wcstoutf8PKwi (urxvt)
 #3  0x0000560e6005e75c n/a (urxvt)
 #4  0x0000560e6007d9f1 _ZN16rxvt_perl_interp6invokeEP9rxvt_term9hook_typez (urxvt)
 #5  0x0000560e6003d988 _ZN9rxvt_term9cmd_parseEv (urxvt)
 #6  0x0000560e60042804 _ZN9rxvt_term6pty_cbERN2ev2ioEi (urxvt)
 #7  0x0000560e6005c10f _Z17ev_invoke_pendingv (urxvt)
 #8  0x0000560e6005cb55 ev_run (urxvt)
 #9  0x0000560e6003b9b9 main (urxvt)
 #10 0x00007fc08883af4a __libc_start_main (libc.so.6)
 #11 0x0000560e6003f9da _start (urxvt)

After bisection, it was found the first bad commit is bd4c82c22c36 ("mm,
THP, swap: delay splitting THP after swapped out").

The root cause is as follows:

When the pages are written to swap device during swapping out in
swap_writepage(), zswap (fontswap) is tried to compress the pages to
improve performance.  But zswap (frontswap) will treat THP as a normal
page, so only the head page is saved.  After swapping in, tail pages
will not be restored to their original contents, causing memory
corruption in the applications.

This is fixed by refusing to save page in the frontswap store functions
if the page is a THP.  So that the THP will be swapped out to swap
device.

Another choice is to split THP if frontswap is enabled.  But it is found
that the frontswap enabling isn't flexible.  For example, if
CONFIG_ZSWAP=y (cannot be module), frontswap will be enabled even if
zswap itself isn't enabled.

Frontswap has multiple backends, to make it easy for one backend to
enable THP support, the THP checking is put in backend frontswap store
functions instead of the general interfaces.

Link: http://lkml.kernel.org/r/20180209084947.22749-1-ying.huang@intel.com
Fixes: bd4c82c22c367e068 ("mm, THP, swap: delay splitting THP after swapped out")
Signed-off-by: "Huang, Ying" 
Reported-by: Sergey Senozhatsky 
Tested-by: Sergey Senozhatsky 
Suggested-by: Minchan Kim 	[put THP checking in backend]
Cc: Konrad Rzeszutek Wilk 
Cc: Dan Streetman 
Cc: Seth Jennings 
Cc: Tetsuo Handa 
Cc: Shaohua Li 
Cc: Michal Hocko 
Cc: Johannes Weiner 
Cc: Mel Gorman 
Cc: Shakeel Butt 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: 	[4.14]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

pvcalls-front: wait for other operations to return when release passive sockets

2018-02-17T08:41:06+00:00

Passive sockets can have ongoing operations on them, specifically, we
have two wait_event_interruptable calls in pvcalls_front_accept.

Add two wake_up calls in pvcalls_front_release, then wait for the
potential waiters to return and release the sock_mapping refcount.

Signed-off-by: Stefano Stabellini 
Acked-by: Juergen Gross 
Signed-off-by: Juergen Gross

pvcalls-front: introduce a per sock_mapping refcount

2018-02-17T08:40:58+00:00

Introduce a per sock_mapping refcount, in addition to the existing
global refcount. Thanks to the sock_mapping refcount, we can safely wait
for it to be 1 in pvcalls_front_release before freeing an active socket,
instead of waiting for the global refcount to be 1.

Signed-off-by: Stefano Stabellini 
Acked-by: Juergen Gross 
Signed-off-by: Juergen Gross