~kmously/ubuntu/+source/linux/+git/xenial:update-to-4.4.181
- Git
- lp:~kmously/ubuntu/+source/linux/+git/xenial
- update-to-4.4.181
- Get this branch:
-
git clone
-b update-to-4.4.181
https://git.launchpad.net/~kmously/ubuntu/+source/linux/+git/xenial
Branch merges
Related source package recipes
Branch information
- Name:
- update-to-4.4.181
- Repository:
- lp:~kmously/ubuntu/+source/linux/+git/xenial
Recent commits
- aa07bcd... by Greg Kroah-Hartman <email address hidden>
-
Linux 4.4.181
BugLink: https:/
/bugs.launchpad .net/bugs/ 1832661 Signed-off-by: Khalid Elmously <email address hidden>
- b350800... by Yunsheng Lin <email address hidden>
-
ethtool: check the return value of get_regs_len
BugLink: https:/
/bugs.launchpad .net/bugs/ 1832661 commit f9fc54d313fab28
34f44f516459cdc 8ac91d797f upstream. The return type for get_regs_len in struct ethtool_ops is int,
the hns3 driver may return error when failing to get the regs
len by sending cmd to firmware.Signed-off-by: Yunsheng Lin <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
Cc: Michal Kubecek <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden> - ba41cc5... by David Ahern
-
ipv4: Define __ipv4_
neigh_lookup_ noref when CONFIG_INET is disabled BugLink: https:/
/bugs.launchpad .net/bugs/ 1832661 commit 9b3040a6aafd789
8ece7fc7efcbca7 1e42aa8069 upstream. Define __ipv4_
neigh_lookup_ noref to return NULL when CONFIG_INET is disabled. Fixes: 4b2a2bfeb3f0 ("neighbor: Call __ipv4_
neigh_lookup_ noref in neigh_xmit")
Reported-by: kbuild test robot <email address hidden>
Signed-off-by: David Ahern <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
Cc: Nobuhiro Iwamatsu <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden> - bb648e0... by Kirill Smelkov
-
fuse: Add FOPEN_STREAM to use stream_open()
BugLink: https:/
/bugs.launchpad .net/bugs/ 1832661 commit bbd84f33652f852
ce5992d65db4d02 0aba21f882 upstream. Starting from commit 9c225f2655e3 ("vfs: atomic f_pos accesses as per
POSIX") files opened even via nonseekable_open gate read and write via lock
and do not allow them to be run simultaneously. This can create read vs
write deadlock if a filesystem is trying to implement a socket-like file
which is intended to be simultaneously used for both read and write from
filesystem client. See commit 10dce8af3422 ("fs: stream_open - opener for
stream-like files so that read and write can run simultaneously without
deadlock") for details and e.g. commit 581d21a2d02a ("xenbus: fix deadlock
on writes to /proc/xen/xenbus") for a similar deadlock example on
/proc/xen/xenbus.To avoid such deadlock it was tempting to adjust fuse_finish_open to use
stream_open instead of nonseekable_open on just FOPEN_NONSEEKABLE flags,
but grepping through Debian codesearch shows users of FOPEN_NONSEEKABLE,
and in particular GVFS which actually uses offset in its read and write
handlershttps:/
/codesearch. debian. net/search? q=-%3Enonseekab le+%3D
https://gitlab. gnome.org/ GNOME/gvfs/ blob/1. 40.0-6- gcbc54396/ client/ gvfsfusedaemon. c#L1080
https://gitlab. gnome.org/ GNOME/gvfs/ blob/1. 40.0-6- gcbc54396/ client/ gvfsfusedaemon. c#L1247- 1346
https://gitlab. gnome.org/ GNOME/gvfs/ blob/1. 40.0-6- gcbc54396/ client/ gvfsfusedaemon. c#L1399- 1481 so if we would do such a change it will break a real user.
Add another flag (FOPEN_STREAM) for filesystem servers to indicate that the
opened handler is having stream-like semantics; does not use file position
and thus the kernel is free to issue simultaneous read and write request on
opened file handle.This patch together with stream_open() should be added to stable kernels
starting from v3.14+. This will allow to patch OSSPD and other FUSE
filesystems that provide stream-like files to return FOPEN_STREAM |
FOPEN_NONSEEKABLE in open handler and this way avoid the deadlock on all
kernel versions. This should work because fuse_finish_open ignores unknown
open flags returned from a filesystem and so passing FOPEN_STREAM to a
kernel that is not aware of this flag cannot hurt. In turn the kernel that
is not aware of FOPEN_STREAM will be < v3.14 where just FOPEN_NONSEEKABLE
is sufficient to implement streams without read vs write deadlock.Cc: <email address hidden> # v3.14+
Signed-off-by: Kirill Smelkov <email address hidden>
Signed-off-by: Miklos Szeredi <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden> - bda554e... by Kirill Smelkov
-
fs: stream_open - opener for stream-like files so that read and write can run simultaneously without deadlock
BugLink: https:/
/bugs.launchpad .net/bugs/ 1832661 commit 10dce8af34226d9
0fa56746a934f8d a5dcdba3df upstream. Commit 9c225f2655e3 ("vfs: atomic f_pos accesses as per POSIX") added
locking for file.f_pos access and in particular made concurrent read and
write not possible - now both those functions take f_pos lock for the
whole run, and so if e.g. a read is blocked waiting for data, write will
deadlock waiting for that read to complete.This caused regression for stream-like files where previously read and
write could run simultaneously, but after that patch could not do so
anymore. See e.g. commit 581d21a2d02a ("xenbus: fix deadlock on writes
to /proc/xen/xenbus") which fixes such regression for particular case of
/proc/xen/xenbus.The patch that added f_pos lock in 2014 did so to guarantee POSIX thread
safety for read/write/lseek and added the locking to file descriptors of
all regular files. In 2014 that thread-safety problem was not new as it
was already discussed earlier in 2006.However even though 2006'th version of Linus's patch was adding f_pos
locking "only for files that are marked seekable with FMODE_LSEEK (thus
avoiding the stream-like objects like pipes and sockets)", the 2014
version - the one that actually made it into the tree as 9c225f2655e3 -
is doing so irregardless of whether a file is seekable or not.See
https://<email address hidden>/
https://lwn.net/ Articles/ 180387
https://lwn.net/ Articles/ 180396 for historic context.
The reason that it did so is, probably, that there are many files that
are marked non-seekable, but e.g. their read implementation actually
depends on knowing current position to correctly handle the read. Some
examples:kernel/
power/user. c snapshot_read
fs/debugfs/file.c u32_array_read
fs/fuse/control.c fuse_conn_waiting_ read + ...
drivers/hwmon/asus_ atk0110. c atk_debugfs_ ggrp_read
arch/s390/hypfs/inode. c hypfs_read_iter
...Despite that, many nonseekable_open users implement read and write with
pure stream semantics - they don't depend on passed ppos at all. And for
those cases where read could wait for something inside, it creates a
situation similar to xenbus - the write could be never made to go until
read is done, and read is waiting for some, potentially external, event,
for potentially unbounded time -> deadlock.Besides xenbus, there are 14 such places in the kernel that I've found
with semantic patch (see below):drivers/
xen/evtchn. c:667:8- 24: ERROR: evtchn_fops: .read() can deadlock .write()
drivers/isdn/capi/ capi.c: 963:8-24: ERROR: capi_fops: .read() can deadlock .write()
drivers/input/evdev. c:527:1- 17: ERROR: evdev_fops: .read() can deadlock .write()
drivers/char/pcmcia/ cm4000_ cs.c:1685: 7-23: ERROR: cm4000_fops: .read() can deadlock .write()
net/rfkill/core.c: 1146:8- 24: ERROR: rfkill_fops: .read() can deadlock .write()
drivers/s390/char/ fs3270. c:488:1- 17: ERROR: fs3270_fops: .read() can deadlock .write()
drivers/usb/misc/ ldusb.c: 310:1-17: ERROR: ld_usb_fops: .read() can deadlock .write()
drivers/hid/uhid. c:635:1- 17: ERROR: uhid_fops: .read() can deadlock .write()
net/batman-adv/icmp_ socket. c:80:1- 17: ERROR: batadv_fops: .read() can deadlock .write()
drivers/media/rc/ lirc_dev. c:198:1- 17: ERROR: lirc_fops: .read() can deadlock .write()
drivers/leds/uleds. c:77:1- 17: ERROR: uleds_fops: .read() can deadlock .write()
drivers/input/misc/ uinput. c:400:1- 17: ERROR: uinput_fops: .read() can deadlock .write()
drivers/infiniband/ core/user_ mad.c:985: 7-23: ERROR: umad_fops: .read() can deadlock .write()
drivers/gnss/core. c:45:1- 17: ERROR: gnss_fops: .read() can deadlock .write() In addition to the cases above another regression caused by f_pos
locking is that now FUSE filesystems that implement open with
FOPEN_NONSEEKABLE flag, can no longer implement bidirectional
stream-like files - for the same reason as above e.g. read can deadlock
write locking on file.f_pos in the kernel.FUSE's FOPEN_NONSEEKABLE was added in 2008 in a7c1b990f715 ("fuse:
implement nonseekable open") to support OSSPD. OSSPD implements /dev/dsp
in userspace with FOPEN_NONSEEKABLE flag, with corresponding read and
write routines not depending on current position at all, and with both
read and write being potentially blocking operations:See
https:/
/github. com/libfuse/ osspd
https://lwn.net/ Articles/ 308445 https:/
/github. com/libfuse/ osspd/blob/ 14a9cff0/ osspd.c# L1406
https://github. com/libfuse/ osspd/blob/ 14a9cff0/ osspd.c# L1438-L1477
https://github. com/libfuse/ osspd/blob/ 14a9cff0/ osspd.c# L1479-L1510 Corresponding libfuse example/test also describes FOPEN_NONSEEKABLE as
"somewhat pipe-like files ..." with read handler not using offset.
However that test implements only read without write and cannot exercise
the deadlock scenario:https:/
/github. com/libfuse/ libfuse/ blob/fuse- 3.4.2-3- ga1bff7d/ example/ poll.c# L124-L131
https://github. com/libfuse/ libfuse/ blob/fuse- 3.4.2-3- ga1bff7d/ example/ poll.c# L146-L163
https://github. com/libfuse/ libfuse/ blob/fuse- 3.4.2-3- ga1bff7d/ example/ poll.c# L209-L216 I've actually hit the read vs write deadlock for real while implementing
my FUSE filesystem where there is /head/watch file, for which open
creates separate bidirectional socket-like stream in between filesystem
and its user with both read and write being later performed
simultaneously. And there it is semantically not easy to split the
stream into two separate read-only and write-only channels:https:/
/lab.nexedi. com/kirr/ wendelin. core/blob/ f13aa600/ wcfs/wcfs. go#L88- 169 Let's fix this regression. The plan is:
1. We can't change nonseekable_open to include &~FMODE_ATOMIC_POS -
doing so would break many in-kernel nonseekable_open users which
actually use ppos in read/write handlers.2. Add stream_open() to kernel to open stream-like non-seekable file
descriptors. Read and write on such file descriptors would never use
nor change ppos. And with that property on stream-like files read and
write will be running without taking f_pos lock - i.e. read and write
could be running simultaneously.3. With semantic patch search and convert to stream_open all in-kernel
nonseekable_open users for which read and write actually do not
depend on ppos and where there is no other methods in file_operations
which assume @offset access.4. Add FOPEN_STREAM to fs/fuse/ and open in-kernel file-descriptors via
steam_open if that bit is present in filesystem open reply.It was tempting to change fs/fuse/ open handler to use stream_open
instead of nonseekable_open on just FOPEN_NONSEEKABLE flags, but
grepping through Debian codesearch shows users of FOPEN_NONSEEKABLE,
and in particular GVFS which actually uses offset in its read and
write handlershttps:/
/codesearch. debian. net/search? q=-%3Enonseekab le+%3D
https://gitlab. gnome.org/ GNOME/gvfs/ blob/1. 40.0-6- gcbc54396/ client/ gvfsfusedaemon. c#L1080
https://gitlab. gnome.org/ GNOME/gvfs/ blob/1. 40.0-6- gcbc54396/ client/ gvfsfusedaemon. c#L1247- 1346
https://gitlab. gnome.org/ GNOME/gvfs/ blob/1. 40.0-6- gcbc54396/ client/ gvfsfusedaemon. c#L1399- 1481 so if we would do such a change it will break a real user.
5. Add stream_open and FOPEN_STREAM handling to stable kernels starting
from v3.14+ (the kernel where 9c225f2655 first appeared).This will allow to patch OSSPD and other FUSE filesystems that
provide stream-like files to return FOPEN_STREAM | FOPEN_NONSEEKABLE
in their open handler and this way avoid the deadlock on all kernel
versions. This should work because fs/fuse/ ignores unknown open
flags returned from a filesystem and so passing FOPEN_STREAM to a
kernel that is not aware of this flag cannot hurt. In turn the kernel
that is not aware of FOPEN_STREAM will be < v3.14 where just
FOPEN_NONSEEKABLE is sufficient to implement streams without read vs
write deadlock.This patch adds stream_open, converts /proc/xen/xenbus to it and adds
semantic patch to automatically locate in-kernel places that are either
required to be converted due to read vs write deadlock, or that are just
safe to be converted because read and write do not use ppos and there
are no other funky methods in file_operations.Regarding semantic patch I've verified each generated change manually -
that it is correct to convert - and each other nonseekable_open instance
left - that it is either not correct to convert there, or that it is not
converted due to current stream_open.cocci limitations.The script also does not convert files that should be valid to convert,
but that currently have .llseek = noop_llseek or generic_file_llseek for
unknown reason despite file being opened with nonseekable_open (e.g.
drivers/input/mousedev. c) Cc: Michael Kerrisk <email address hidden>
Cc: Yongzhi Pan <email address hidden>
Cc: Jonathan Corbet <email address hidden>
Cc: David Vrabel <email address hidden>
Cc: Juergen Gross <email address hidden>
Cc: Miklos Szeredi <email address hidden>
Cc: Tejun Heo <email address hidden>
Cc: Kirill Tkhai <email address hidden>
Cc: Arnd Bergmann <email address hidden>
Cc: Christoph Hellwig <email address hidden>
Cc: Greg Kroah-Hartman <email address hidden>
Cc: Julia Lawall <email address hidden>
Cc: Nikolaus Rath <email address hidden>
Cc: Han-Wen Nienhuys <email address hidden>
[ backport to 4.4: actually fixed deadlock on /proc/xen/xenbus as 581d21a2d02a was not backported to 4.4 ]
Signed-off-by: Kirill Smelkov <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden> - b72d4ae... by Patrik Jakobsson
-
drm/gma500/cdv: Check vbt config bits when detecting lvds panels
BugLink: https:/
/bugs.launchpad .net/bugs/ 1832661 commit 7c420636860a719
049fae9403e2c87 804f53bdde upstream. Some machines have an lvds child device in vbt even though a panel is
not attached. To make detection more reliable we now also check the lvds
config bits available in the vbt.Bugzilla: https:/
/bugzilla. redhat. com/show_ bug.cgi? id=1665766
Cc: <email address hidden>
Reviewed-by: Hans de Goede <email address hidden>
Signed-off-by: Patrik Jakobsson <email address hidden>
Link: https://patchwork. freedesktop<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden> - a8e9483... by Dan Carpenter <email address hidden>
-
genwqe: Prevent an integer overflow in the ioctl
BugLink: https:/
/bugs.launchpad .net/bugs/ 1832661 commit 110080cea0d0e4d
fdb0b536e7f8a56 33ead6a781 upstream. There are a couple potential integer overflows here.
round_up(m->size + (m->addr & ~PAGE_MASK), PAGE_SIZE);
The first thing is that the "m->size + (...)" addition could overflow,
and the second is that round_up() overflows to zero if the result is
within PAGE_SIZE of the type max.In this code, the "m->size" variable is an u64 but we're saving the
result in "map_size" which is an unsigned long and genwqe_user_vmap()
takes an unsigned long as well. So I have used ULONG_MAX as the upper
bound. From a practical perspective unsigned long is fine/better than
trying to change all the types to u64.Fixes: eaf4722d4645 ("GenWQE Character device and DDCB queue")
Signed-off-by: Dan Carpenter <email address hidden>
Cc: stable <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden> - 69e5429... by Paul Burton <email address hidden>
-
MIPS: pistachio: Build uImage.gz by default
BugLink: https:/
/bugs.launchpad .net/bugs/ 1832661 commit e4f2d1af7163bec
b181419af9dece9 206001e0a6 upstream. The pistachio platform uses the U-Boot bootloader & generally boots a
kernel in the uImage format. As such it's useful to build one when
building the kernel, but to do so currently requires the user to
manually specify a uImage target on the make command line.Make uImage.gz the pistachio platform's default build target, so that
the default is to build a kernel image that we can actually boot on a
board such as the MIPS Creator Ci40.Marked for stable backport as far as v4.1 where pistachio support was
introduced. This is primarily useful for CI systems such as kernelci.org
which will benefit from us building a suitable image which can then be
booted as part of automated testing, extending our test coverage to the
affected stable branches.Signed-off-by: Paul Burton <email address hidden>
Reviewed-by: Philippe Mathieu-Daudé <email address hidden>
Reviewed-by: Kevin Hilman <email address hidden>
Tested-by: Kevin Hilman <email address hidden>
URL: https://groups. io/g/kernelci/ message/ 388
Cc: <email address hidden> # v4.1+
Cc: <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden> - 62b7bfb... by Miklos Szeredi <email address hidden>
-
fuse: fallocate: fix return with locked inode
BugLink: https:/
/bugs.launchpad .net/bugs/ 1832661 commit 35d6fcbb7c3e296
a52136347346a69 8a35af3fda upstream. Do the proper cleanup in case the size check fails.
Tested with xfstests:
generic/ 228 Reported-by: kbuild test robot <email address hidden>
Reported-by: Dan Carpenter <email address hidden>
Fixes: 0cbade024ba5 ("fuse: honor RLIMIT_FSIZE in fuse_file_fallocate" )
Cc: Liu Bo <email address hidden>
Cc: <email address hidden> # v3.5
Signed-off-by: Miklos Szeredi <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden> - 87abf25... by John David Anglin
-
parisc: Use implicit space register selection for loading the coherence index of I/O pdirs
BugLink: https:/
/bugs.launchpad .net/bugs/ 1832661 commit 63923d2c3800919
774f5c651d503d1 dd2adaddd5 upstream. We only support I/O to kernel space. Using %sr1 to load the coherence
index may be racy unless interrupts are disabled. This patch changes the
code used to load the coherence index to use implicit space register
selection. This saves one instruction and eliminates the race.Tested on rp3440, c8000 and c3750.
Signed-off-by: John David Anglin <email address hidden>
Cc: <email address hidden>
Signed-off-by: Helge Deller <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>