Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 24 4月, 2019 3 次提交
    • C
      vfio-ccw: protect the I/O region · 4f766173
      由 Cornelia Huck 提交于 
      Introduce a mutex to disallow concurrent reads or writes to the
I/O region. This makes sure that the data the kernel or user
space see is always consistent.

The same mutex will be used to protect the async region as well.
Reviewed-by: NEric Farman <farman@linux.ibm.com>
Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      4f766173
    • C
      vfio-ccw: rework ssch state handling · 690f6a15
      由 Cornelia Huck 提交于 
      The flow for processing ssch requests can be improved by splitting
the BUSY state:

- CP_PROCESSING: We reject any user space requests while we are in
  the process of translating a channel program and submitting it to
  the hardware. Use -EAGAIN to signal user space that it should
  retry the request.
- CP_PENDING: We have successfully submitted a request with ssch and
  are now expecting an interrupt. As we can't handle more than one
  channel program being processed, reject any further requests with
  -EBUSY. A final interrupt will move us out of this state.
  By making this a separate state, we make it possible to issue a
  halt or a clear while we're still waiting for the final interrupt
  for the ssch (in a follow-on patch).

It also makes a lot of sense not to preemptively filter out writes to
the io_region if we're in an incorrect state: the state machine will
handle this correctly.
Reviewed-by: NEric Farman <farman@linux.ibm.com>
Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      690f6a15
    • C
      vfio-ccw: make it safe to access channel programs · 71189f26
      由 Cornelia Huck 提交于 
      When we get a solicited interrupt, the start function may have
been cleared by a csch, but we still have a channel program
structure allocated. Make it safe to call the cp accessors in
any case, so we can call them unconditionally.

While at it, also make sure that functions called from other parts
of the code return gracefully if the channel program structure
has not been initialized (even though that is a bug in the caller).
Reviewed-by: NEric Farman <farman@linux.ibm.com>
Reviewed-by: NFarhan Ali <alifm@linux.ibm.com>
Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      71189f26
  3. 23 4月, 2019 3 次提交
  5. 18 4月, 2019 2 次提交
  7. 11 4月, 2019 9 次提交
    • A
      s390: zcrypt: initialize variables before_use · 913140e2
      由 Arnd Bergmann 提交于 
      The 'func_code' variable gets printed in debug statements without
a prior initialization in multiple functions, as reported when building
with clang:

drivers/s390/crypto/zcrypt_api.c:659:6: warning: variable 'func_code' is used uninitialized whenever 'if' condition is true
      [-Wsometimes-uninitialized]
        if (mex->outputdatalength < mex->inputdatalength) {
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/s390/crypto/zcrypt_api.c:725:29: note: uninitialized use occurs here
        trace_s390_zcrypt_rep(mex, func_code, rc,
                                   ^~~~~~~~~
drivers/s390/crypto/zcrypt_api.c:659:2: note: remove the 'if' if its condition is always false
        if (mex->outputdatalength < mex->inputdatalength) {
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/s390/crypto/zcrypt_api.c:654:24: note: initialize the variable 'func_code' to silence this warning
        unsigned int func_code;
                              ^

Add initializations to all affected code paths to shut up the warning
and make the warning output consistent.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      913140e2
    • A
      s390: avoid __builtin_return_address(n) on clang · 6e042492
      由 Arnd Bergmann 提交于 
      llvm on s390 has problems with __builtin_return_address(n), with n>0,
this results in a somewhat cryptic error message:

fatal error: error in backend: Unsupported stack frame traversal count

To work around it, use the direct return address directly. This
is probably not ideal here, but gets things to compile and should
only lead to inferior reporting, not to misbehavior of the generated
code.

Link: https://bugs.llvm.org/show_bug.cgi?id=41424Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      6e042492
    • J
      s390: Convert IS_ENABLED uses to __is_defined · 475c8e9e
      由 Joe Perches 提交于 
      IS_ENABLED should be reserved for CONFIG_<FOO> uses so convert
the uses of IS_ENABLED with a #define to __is_defined.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      475c8e9e
    • A
      s390: make chkbss work with clang · 9a0ceb9c
      由 Arnd Bergmann 提交于 
      llvm skips an empty .bss section entirely, which makes
the check fail with an unexpected error:

/tmp/binutils-multi-test/bin/s390x-linux-gnu-objdump: section '.bss' mentioned in a -j option, but not found in any input file
error: arch/s390/boot/compressed/decompressor.o .bss section is not empty
../arch/s390/scripts/Makefile.chkbss:20: recipe for target 'arch/s390/boot/compressed/decompressor.o.chkbss' failed

Change the check so we first see if a .bss section exists
before trying to read its size.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      9a0ceb9c
    • A
      s390: make __load_psw_mask work with clang · 0a113efc
      由 Arnd Bergmann 提交于 
      clang fails to use the %O and %R inline assembly modifiers
the same way as gcc, leading to build failures with every use
of __load_psw_mask():

/tmp/nmi-4a9f80.s: Assembler messages:
/tmp/nmi-4a9f80.s:571: Error: junk at end of line: `+8(160(%r11))'
/tmp/nmi-4a9f80.s:626: Error: junk at end of line: `+8(160(%r11))'

Replace these with a more conventional way of passing the addresses
that should work with both clang and gcc.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      0a113efc
    • A
      s390: syscall_wrapper: avoid clang warning · efb150df
      由 Arnd Bergmann 提交于 
      Building system calls with clang results in a warning
about an alias from a global function to a static one:

../fs/namei.c:3847:1: warning: unused function '__se_sys_mkdirat' [-Wunused-function]
SYSCALL_DEFINE3(mkdirat, int, dfd, const char __user *, pathname, umode_t, mode)
^
../include/linux/syscalls.h:219:36: note: expanded from macro 'SYSCALL_DEFINE3'
 #define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__)
                                   ^
../include/linux/syscalls.h:228:2: note: expanded from macro 'SYSCALL_DEFINEx'
        __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
        ^
../arch/s390/include/asm/syscall_wrapper.h:126:18: note: expanded from macro '__SYSCALL_DEFINEx'
        asmlinkage long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__))          \
                        ^
<scratch space>:31:1: note: expanded from here
__se_sys_mkdirat
^

The only reference to the static __se_sys_mkdirat() here is the alias, but
this only gets evaluated later. Making this function global as well avoids
the warning.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      efb150df
    • A
      s390: don't build vdso32 with clang · 96ca7674
      由 Arnd Bergmann 提交于 
      clang does not support 31 bit object files on s390, so skip
the 32-bit vdso here, and only build it when using gcc to compile
the kernel.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      96ca7674
    • A
      s390: remove -fno-strength-reduce flag · c1afcaec
      由 Arnd Bergmann 提交于 
      This was added as a workaround for really old compilers, and it prevents
building with clang now. I can see no reason for keeping it, as it has
already been removed for most architectures in the pre-git era, so
let's remove it everywhere, rather than only for clang.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      c1afcaec
    • M
      s390: fine-tune stack switch helper · 7aa0055e
      由 Martin Schwidefsky 提交于 
      The CALL_ON_STACK helper currently does not work with clang and for
calls without arguments. It does not initialize r2 although the constraint
is "+&d". Rework the CALL_FMT_x and the CALL_ON_STACK macros to work
with clang and produce optimal code in all cases.
Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      7aa0055e
  9. 10 4月, 2019 13 次提交
  11. 29 3月, 2019 6 次提交
  13. 28 3月, 2019 4 次提交
    • D
      afs: Fix StoreData op marshalling · 8c7ae38d
      由 David Howells 提交于 
      The marshalling of AFS.StoreData, AFS.StoreData64 and YFS.StoreData64 calls
generated by ->setattr() ops for the purpose of expanding a file is
incorrect due to older documentation incorrectly describing the way the RPC
'FileLength' parameter is meant to work.

The older documentation says that this is the length the file is meant to
end up at the end of the operation; however, it was never implemented this
way in any of the servers, but rather the file is truncated down to this
before the write operation is effected, and never expanded to it (and,
indeed, it was renamed to 'TruncPos' in 2014).

Fix this by setting the position parameter to the new file length and doing
a zero-lengh write there.

The bug causes Xwayland to SIGBUS due to unexpected non-expansion of a file
it then mmaps.  This can be tested by giving the following test program a
filename in an AFS directory:

	#include <stdio.h>
	#include <stdlib.h>
	#include <unistd.h>
	#include <fcntl.h>
	#include <sys/mman.h>
	int main(int argc, char *argv[])
	{
		char *p;
		int fd;
		if (argc != 2) {
			fprintf(stderr,
				"Format: test-trunc-mmap <file>\n");
			exit(2);
		}
		fd = open(argv[1], O_RDWR | O_CREAT | O_TRUNC);
		if (fd < 0) {
			perror(argv[1]);
			exit(1);
		}
		if (ftruncate(fd, 0x140008) == -1) {
			perror("ftruncate");
			exit(1);
		}
		p = mmap(NULL, 4096, PROT_READ | PROT_WRITE,
			 MAP_SHARED, fd, 0);
		if (p == MAP_FAILED) {
			perror("mmap");
			exit(1);
		}
		p[0] = 'a';
		if (munmap(p, 4096) < 0) {
			perror("munmap");
			exit(1);
		}
		if (close(fd) < 0) {
			perror("close");
			exit(1);
		}
		exit(0);
	}

Fixes: 31143d5d ("AFS: implement basic file write support")
Reported-by: NJonathan Billings <jsbillin@umich.edu>
Tested-by: NJonathan Billings <jsbillin@umich.edu>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8c7ae38d
    • D
      vfs: Update mount API docs · 7d6ab823
      由 David Howells 提交于 
      Update the mount API docs to reflect recent changes to the code.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7d6ab823
    • L
      Merge tag 's390-5.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux · bfed6d0f
      由 Linus Torvalds 提交于 
      Pull s390 fixes from Martin Schwidefsky:
 "Improvements and bug fixes for 5.1-rc2:

   - Fix early free of the channel program in vfio

   - On AP device removal make sure that all messages are flushed with
     the driver still attached that queued the message

   - Limit brk randomization to 32MB to reduce the chance that the heap
     of ld.so is placed after the main stack

   - Add a rolling average for the steal time of a CPU, this will be
     needed for KVM to decide when to do busy waiting

   - Fix a warning in the CPU-MF code

   - Add a notification handler for AP configuration change to react
     faster to new AP devices"

* tag 's390-5.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/cpumf: Fix warning from check_processor_id
  zcrypt: handle AP Info notification from CHSC SEI command
  vfio: ccw: only free cp on final interrupt
  s390/vtime: steal time exponential moving average
  s390/zcrypt: revisit ap device remove procedure
  s390: limit brk randomization to 32MB
      bfed6d0f
    • L
      Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc · 97c41a6b
      由 Linus Torvalds 提交于 
      Pull ARM SoC fixes from Arnd Bergmann:
 "A couple of minor fixes only for now

   - fix for incorrect DMA channels on Renesas R-Car

   - Broadcom bcm2835 error handling fixes

   - Kconfig dependency fixes for bcm2835 and davinci

   - CPU idle wakeup fix for i.MX6

   - MMC regression on Tegra186

   - fix incorrect phy settings on one imx board"

* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
  arm64: tegra: Disable CQE Support for SDMMC4 on Tegra186
  ARM: dts: nomadik: Fix polarity of SPI CS
  ARM: davinci: fix build failure with allnoconfig
  ARM: imx_v4_v5_defconfig: enable PWM driver
  ARM: imx_v6_v7_defconfig: continue compiling the pwm driver
  ARM: dts: imx6dl-yapp4: Use correct pseudo PHY address for the switch
  ARM: dts: imx6qdl: Fix typo in imx6qdl-icore-rqs.dtsi
  ARM: dts: imx6ull: Use the correct style for SPDX License Identifier
  ARM: dts: pfla02: increase phy reset duration
  ARM: imx6q: cpuidle: fix bug that CPU might not wake up at expected time
  ARM: imx51: fix a leaked reference by adding missing of_node_put
  ARM: dts: imx6dl-yapp4: Use rgmii-id phy mode on the cpu port
  arm64: bcm2835: Add missing dependency on MFD_CORE.
  ARM: dts: bcm283x: Fix hdmi hpd gpio pull
  soc: bcm: bcm2835-pm: Fix error paths of initialization.
  soc: bcm: bcm2835-pm: Fix PM_IMAGE_PERI power domain support.
  arm64: dts: renesas: r8a774c0: Fix SCIF5 DMA channels
  arm64: dts: renesas: r8a77990: Fix SCIF5 DMA channels
      97c41a6b