kernel/git/stable/linux.git/arch/um/drivers, branch linux-5.18.y

um: random: Don't initialise hwrng struct with zero

2022-08-17T12:41:49+00:00

[ Upstream commit 9e70cbd11b03889c92462cf52edb2bd023c798fa ] Initialising the hwrng struct with zeros causes a compile-time sparse warning: $ ARCH=um make -j10 W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ... CHECK arch/um/drivers/random.c arch/um/drivers/random.c:31:31: sparse: warning: Using plain integer as NULL pointer Fix the warning by not initialising the hwrng struct with zeros as it is initialised anyway during module init. Fixes: 72d3e093afae ("um: random: Register random as hwrng-core device") Reported-by: kernel test robot Signed-off-by: Christopher Obbard Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin

um: line: Use separate IRQs per line

2022-06-14T16:45:13+00:00

[ Upstream commit d5a9597d6916a76663085db984cb8fe97f0a5c56 ] Today, all possible serial lines (ssl*=) as well as all possible consoles (con*=) each share a single interrupt (with a fixed number) with others of the same type. Now, if you have two lines, say ssl0 and ssl1, and one of them is connected to an fd you cannot read (e.g. a file), but the other gets a read interrupt, then both of them get the interrupt since it's shared. Then, the read() call will return EOF, since it's a file being written and there's nothing to read (at least not at the current offset, at the end). Unfortunately, this is treated as a read error, and we close this line, losing all the possible output. It might be possible to work around this and make the IRQ sharing work, however, now that we have dynamically allocated IRQs that are easy to use, simply use that to achieve separating between the events; then there's no interrupt for that line and we never attempt the read in the first place, thus not closing the line. This manifested itself in the wifi hostap/hwsim tests where the parallel script communicates via one serial console and the kernel messages go to another (a file) and sending data on the communication console caused the kernel messages to stop flowing into the file. Reported-by: Jouni Malinen Signed-off-by: Johannes Berg Acked-By: anton ivanov Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin

um: chan_user: Fix winch_tramp() return value

2022-06-09T08:30:50+00:00

commit 57ae0b67b747031bc41fb44643aa5344ab58607e upstream. The previous fix here was only partially correct, it did result in returning a proper error value in case of error, but it also clobbered the pid that we need to return from this function (not just zero for success). As a result, it returned 0 here, but later this is treated as a pid and used to kill the process, but since it's now 0 we kill(0, SIGKILL), which makes UML kill itself rather than just the helper thread. Fix that and make it more obvious by using a separate variable for the pid. Fixes: ccf1236ecac4 ("um: fix error return code in winch_tramp()") Reported-and-tested-by: Nathan Chancellor Signed-off-by: Johannes Berg Cc: stable@vger.kernel.org Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman

um: virtio_uml: Fix broken device handling in time-travel

2022-06-09T08:30:50+00:00

commit af9fb41ed315ce95f659f0b10b4d59a71975381d upstream. If a device implementation crashes, virtio_uml will mark it as dead by calling virtio_break_device() and scheduling the work that will remove it. This still seems like the right thing to do, but it's done directly while reading the message, and if time-travel is used, this is in the time-travel handler, outside of the normal Linux machinery. Therefore, we cannot acquire locks or do normal "linux-y" things because e.g. lockdep will be confused about the context. Move handling this situation out of the read function and into the actual IRQ handler and response handling instead, so that in the case of time-travel we don't call it in the wrong context. Chances are the system will still crash immediately, since the device implementation crashing may also cause the time- travel controller to go down, but at least all of that now happens without strange warnings from lockdep. Fixes: c8177aba37ca ("um: time-travel: rework interrupt handling in ext mode") Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman

um: port_user: Improve error handling when port-helper is not found

2022-03-11T09:55:55+00:00

Check if port-helper exists and is executable. If not, write an error message to the kernel log with information to help the user diagnose the issue and exit with an error. If UML_PORT_HELPER was not set, write a message suggesting that the user set it. This makes it easier to understand why telneting to the UML instance is failing and what can be done to fix it. Signed-off-by: Glenn Washburn Signed-off-by: Richard Weinberger

um: port_user: Allow setting path to port-helper using UML_PORT_HELPER envvar

2022-03-11T09:55:38+00:00

This is useful when the uml-utilities user-space package has not been installed by the administrator and an unprivileged user wants to be able to telnet into a UML instance. The user can install the port-helper binary to a writable path and set UML_PORT_HELPER. Fallback to using hardcoded path to port-helper if environment variable is not set. Signed-off-by: Glenn Washburn Signed-off-by: Richard Weinberger

um: port_user: Search for in.telnetd in PATH

2022-03-11T09:55:16+00:00

This allows in.telnetd to be run from non-standard installation locations and is especially useful when running a UML instance as an unprivileged user on a system where the administrator has not installed the in.telnetd binary. Signed-off-by: Glenn Washburn Signed-off-by: Richard Weinberger

um: Fix uml_mconsole stop/go

2022-03-11T09:49:19+00:00

Moving to an EPOLL based IRQ controller broke uml_mconsole stop/go commands. This fixes it and restores stop/go functionality. Fixes: ff6a17989c08 ("Epoll based IRQ controller") Signed-off-by: Anton Ivanov Signed-off-by: Richard Weinberger

uml: net: vector: fix const issue

2022-03-11T09:47:05+00:00

Since the constification of MAC addresses, the argument to uml_vector_default_bpf() must be const. Signed-off-by: Johannes Berg Acked-By: anton ivanov Signed-off-by: Richard Weinberger

um: Fix WRITE_ZEROES in the UBD Driver

2022-03-11T09:46:34+00:00

Call to fallocate with FALLOC_FL_PUNCH_HOLE on a device backed by a sparse file can end up by missing data, zeroes data range, if the underlying file is used with a tool like bmaptool which will referenced only used spaces. Signed-off-by: Frédéric Danis Acked-by: Anton Ivanov Signed-off-by: Richard Weinberger