Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 24 4月, 2019 9 次提交
    • F
      vfio-ccw: Prevent quiesce function going into an infinite loop · d1ffa760
      由 Farhan Ali 提交于 
      The quiesce function calls cio_cancel_halt_clear() and if we
get an -EBUSY we go into a loop where we:
	- wait for any interrupts
	- flush all I/O in the workqueue
	- retry cio_cancel_halt_clear

During the period where we are waiting for interrupts or
flushing all I/O, the channel subsystem could have completed
a halt/clear action and turned off the corresponding activity
control bits in the subchannel status word. This means the next
time we call cio_cancel_halt_clear(), we will again start by
calling cancel subchannel and so we can be stuck between calling
cancel and halt forever.

Rather than calling cio_cancel_halt_clear() immediately after
waiting, let's try to disable the subchannel. If we succeed in
disabling the subchannel then we know nothing else can happen
with the device.
Suggested-by: NEric Farman <farman@linux.ibm.com>
Signed-off-by: NFarhan Ali <alifm@linux.ibm.com>
Message-Id: <4d5a4b98ab1b41ac6131b5c36de18b76c5d66898.1555449329.git.alifm@linux.ibm.com>
Reviewed-by: NEric Farman <farman@linux.ibm.com>
Acked-by: NHalil Pasic <pasic@linux.ibm.com>
Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      d1ffa760
    • F
      vfio-ccw: Release any channel program when releasing/removing vfio-ccw mdev · b49bdc86
      由 Farhan Ali 提交于 
      When releasing the vfio-ccw mdev, we currently do not release
any existing channel program and its pinned pages. This can
lead to the following warning:

[1038876.561565] WARNING: CPU: 2 PID: 144727 at drivers/vfio/vfio_iommu_type1.c:1494 vfio_sanity_check_pfn_list+0x40/0x70 [vfio_iommu_type1]

....

1038876.561921] Call Trace:
[1038876.561935] ([<00000009897fb870>] 0x9897fb870)
[1038876.561949]  [<000003ff8013bf62>] vfio_iommu_type1_detach_group+0xda/0x2f0 [vfio_iommu_type1]
[1038876.561965]  [<000003ff8007b634>] __vfio_group_unset_container+0x64/0x190 [vfio]
[1038876.561978]  [<000003ff8007b87e>] vfio_group_put_external_user+0x26/0x38 [vfio]
[1038876.562024]  [<000003ff806fc608>] kvm_vfio_group_put_external_user+0x40/0x60 [kvm]
[1038876.562045]  [<000003ff806fcb9e>] kvm_vfio_destroy+0x5e/0xd0 [kvm]
[1038876.562065]  [<000003ff806f63fc>] kvm_put_kvm+0x2a4/0x3d0 [kvm]
[1038876.562083]  [<000003ff806f655e>] kvm_vm_release+0x36/0x48 [kvm]
[1038876.562098]  [<00000000003c2dc4>] __fput+0x144/0x228
[1038876.562113]  [<000000000016ee82>] task_work_run+0x8a/0xd8
[1038876.562125]  [<000000000014c7a8>] do_exit+0x5d8/0xd90
[1038876.562140]  [<000000000014d084>] do_group_exit+0xc4/0xc8
[1038876.562155]  [<000000000015c046>] get_signal+0x9ae/0xa68
[1038876.562169]  [<0000000000108d66>] do_signal+0x66/0x768
[1038876.562185]  [<0000000000b9e37e>] system_call+0x1ea/0x2d8
[1038876.562195] 2 locks held by qemu-system-s39/144727:
[1038876.562205]  #0: 00000000537abaf9 (&container->group_lock){++++}, at: __vfio_group_unset_container+0x3c/0x190 [vfio]
[1038876.562230]  #1: 00000000670008b5 (&iommu->lock){+.+.}, at: vfio_iommu_type1_detach_group+0x36/0x2f0 [vfio_iommu_type1]
[1038876.562250] Last Breaking-Event-Address:
[1038876.562262]  [<000003ff8013aa24>] vfio_sanity_check_pfn_list+0x3c/0x70 [vfio_iommu_type1]
[1038876.562272] irq event stamp: 4236481
[1038876.562287] hardirqs last  enabled at (4236489): [<00000000001cee7a>] console_unlock+0x6d2/0x740
[1038876.562299] hardirqs last disabled at (4236496): [<00000000001ce87e>] console_unlock+0xd6/0x740
[1038876.562311] softirqs last  enabled at (4234162): [<0000000000b9fa1e>] __do_softirq+0x556/0x598
[1038876.562325] softirqs last disabled at (4234153): [<000000000014e4cc>] irq_exit+0xac/0x108
[1038876.562337] ---[ end trace 6c96d467b1c3ca06 ]---

Similarly we do not free the channel program when we are removing
the vfio-ccw device. Let's fix this by resetting the device and freeing
the channel program and pinned pages in the release path. For the remove
path we can just quiesce the device, since in the remove path the mediated
device is going away for good and so we don't need to do a full reset.
Signed-off-by: NFarhan Ali <alifm@linux.ibm.com>
Message-Id: <ae9f20dc8873f2027f7b3c5d2aaa0bdfe06850b8.1554756534.git.alifm@linux.ibm.com>
Acked-by: NEric Farman <farman@linux.ibm.com>
Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      b49bdc86
    • F
      vfio-ccw: Do not call flush_workqueue while holding the spinlock · cea5dde4
      由 Farhan Ali 提交于 
      Currently we call flush_workqueue while holding the subchannel
spinlock. But flush_workqueue function can go to sleep, so
do not call the function while holding the spinlock.

Fixes the following bug:

[  285.203430] BUG: scheduling while atomic: bash/14193/0x00000002
[  285.203434] INFO: lockdep is turned off.
....
[  285.203485] Preemption disabled at:
[  285.203488] [<000003ff80243e5c>] vfio_ccw_sch_quiesce+0xbc/0x120 [vfio_ccw]
[  285.203496] CPU: 7 PID: 14193 Comm: bash Tainted: G        W
....
[  285.203504] Call Trace:
[  285.203510] ([<0000000000113772>] show_stack+0x82/0xd0)
[  285.203514]  [<0000000000b7a102>] dump_stack+0x92/0xd0
[  285.203518]  [<000000000017b8be>] __schedule_bug+0xde/0xf8
[  285.203524]  [<0000000000b95b5a>] __schedule+0x7a/0xc38
[  285.203528]  [<0000000000b9678a>] schedule+0x72/0xb0
[  285.203533]  [<0000000000b9bfbc>] schedule_timeout+0x34/0x528
[  285.203538]  [<0000000000b97608>] wait_for_common+0x118/0x1b0
[  285.203544]  [<0000000000166d6a>] flush_workqueue+0x182/0x548
[  285.203550]  [<000003ff80243e6e>] vfio_ccw_sch_quiesce+0xce/0x120 [vfio_ccw]
[  285.203556]  [<000003ff80245278>] vfio_ccw_mdev_reset+0x38/0x70 [vfio_ccw]
[  285.203562]  [<000003ff802458b0>] vfio_ccw_mdev_remove+0x40/0x78 [vfio_ccw]
[  285.203567]  [<000003ff801a499c>] mdev_device_remove_ops+0x3c/0x80 [mdev]
[  285.203573]  [<000003ff801a4d5c>] mdev_device_remove+0xc4/0x130 [mdev]
[  285.203578]  [<000003ff801a5074>] remove_store+0x6c/0xa8 [mdev]
[  285.203582]  [<000000000046f494>] kernfs_fop_write+0x14c/0x1f8
[  285.203588]  [<00000000003c1530>] __vfs_write+0x38/0x1a8
[  285.203593]  [<00000000003c187c>] vfs_write+0xb4/0x198
[  285.203597]  [<00000000003c1af2>] ksys_write+0x5a/0xb0
[  285.203601]  [<0000000000b9e270>] system_call+0xdc/0x2d8
Signed-off-by: NFarhan Ali <alifm@linux.ibm.com>
Reviewed-by: NEric Farman <farman@linux.ibm.com>
Reviewed-by: NPierre Morel <pmorel@linux.ibm.com>
Message-Id: <626bab8bb2958ae132452e1ddaf1b20882ad5a9d.1554756534.git.alifm@linux.ibm.com>
Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      cea5dde4
    • C
      vfio-ccw: add handling for async channel instructions · d5afd5d1
      由 Cornelia Huck 提交于 
      Add a region to the vfio-ccw device that can be used to submit
asynchronous I/O instructions. ssch continues to be handled by the
existing I/O region; the new region handles hsch and csch.

Interrupt status continues to be reported through the same channels
as for ssch.
Acked-by: NEric Farman <farman@linux.ibm.com>
Reviewed-by: NFarhan Ali <alifm@linux.ibm.com>
Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      d5afd5d1
    • C
      s390/cio: export hsch to modules · b0940857
      由 Cornelia Huck 提交于 
      The vfio-ccw code will need this, and it matches treatment of ssch
and csch.
Reviewed-by: NPierre Morel <pmorel@linux.ibm.com>
Reviewed-by: NHalil Pasic <pasic@linux.ibm.com>
Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      b0940857
    • C
      vfio-ccw: add capabilities chain · db8e5d17
      由 Cornelia Huck 提交于 
      Allow to extend the regions used by vfio-ccw. The first user will be
handling of halt and clear subchannel.
Reviewed-by: NEric Farman <farman@linux.ibm.com>
Reviewed-by: NFarhan Ali <alifm@linux.ibm.com>
Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      db8e5d17
    • 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 4 次提交