- 19 Oct, 2017 7 commits
-
-
Colin Ian King authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 08d90c81 ] ralink_soc sould be assigned to RT3883_SOC, replace incorrect comparision with assignment. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Fixes: 418d29c8 ("MIPS: ralink: Unify SoC id handling") Cc: John Crispin <john@phrozen.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14903/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
Sasha Levin <alexander.levin@verizon.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Paul Burton authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 3f00f4d8 ] When clearing the .bss section in kernel_entry we do so using LONG_S instructions, and branch whilst the current write address doesn't equal the end of the .bss section minus the size of a long integer. The .bss section always begins at a long-aligned address and we always increment the write pointer by the size of a long integer - we therefore rely upon the .bss section ending at a long-aligned address. If this is not the case then the long-aligned write address can never be equal to the non-long-aligned end address & we will continue to increment past the end of the .bss section, attempting to zero the rest of memory. Despite this requirement that .bss end at a long-aligned address we pass 0 as the end alignment requirement to the BSS_SECTION macro and thus don't guarantee any particular alignment, allowing us to hit the error condition described above. Fix this by instead passing 8 bytes as the end alignment argument to the BSS_SECTION macro, ensuring that the end of the .bss section is always at least long-aligned. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14526/Signed-off-by:
-
Simon Horman authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 654450ba ] Use recently added R-Car Gen 2 fallback binding for msiof nodes in DT for r8a7790 SoC. This has no run-time effect for the current driver as the initialisation sequence is the same for the SoC-specific binding for r8a7790 and the fallback binding for R-Car Gen 2. Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Santosh Shilimkar authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 941f8d55 ] When application sends an RDS RDMA composite message consist of RDMA transfer to be followed up by non RDMA payload, it expect to be notified *only* when the full message gets delivered. RDS RDMA notification doesn't behave this way though. Thanks to Venkat for debug and root casuing the issue where only first part of the message(RDMA) was successfully delivered but remainder payload delivery failed. In that case, application should not be notified with a false positive of message delivery success. Fix this case by making sure the user gets notified only after the full message delivery. Reviewed-by:
Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com> Signed-off-by:
Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by:
-
Dan Carpenter authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 14d37564 ] This patch fixes a place where function gfs2_glock_iter_next can reference an invalid error pointer. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Bob Peterson <rpeterso@redhat.com> Signed-off-by:
-
Bartosz Golaszewski authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit 2e644be3 ] THS8135 is a configurable video DAC. Add DT bindings for this chip. Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1481623759-12786-3-git-send-email-bgolaszewski@baylibre.comSigned-off-by:
-
Kristian H. Kristensen authored
BugLink: http://bugs.launchpad.net/bugs/1724772 [ Upstream commit af913418 ] We need to define DRM_FORMAT_MOD_VENDOR_NONE for the fourcc_mod_code() macro to work correctly. Signed-off-by:
Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1481657272-25975-1-git-send-email-hoegsberg@google.comSigned-off-by:
-
- 17 Oct, 2017 1 commit
-
-
Thadeu Lima de Souza Cascardo authored
Ignore: yes Signed-off-by:
-
- 10 Oct, 2017 6 commits
-
-
Thadeu Lima de Souza Cascardo authored
Signed-off-by: -
Marcelo Henrique Cerri authored
Ignore: yes Make insert-ubuntu-changes to consider full version numbers when looping through debian.master/changelog entries and comparing the version number of each entry with the arguments passed to the script to decide which entries should be included in the output changelog file. Previously, only the last number in the version was used in this comparison. For example, when comparing 4.4.0-50.51 and 4.4.0-83.84 only the numbers 51 and 84 were actually used in the comparison. That however might not work properly when the major version is bumped. For instance, using "end" as 4.4.0-50.51 and "start" as 4.4.0-83.84 used to work fine because 84 is greater than 51. However when using "end" as 4.11.0-10.11 and "start" as 4.13.0-2.3, no entry was being selected since 3 is not greater than 11. Signed-off-by:
Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Acked-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
-
Yadan Fan authored
BugLink: https://bugs.launchpad.net/bugs/1720359 The hpsa firmware will bypass the cache for any request larger than 1MB, so we should cap the request size to avoid any performance degradation in kernels later than v4.3 This degradation is caused from d2be537c, which changed max_sectors_kb to 1280k, but the hardware is able to work fine with it, so the true fix should be from hpsa driver. Signed-off-by:
Yadan Fan <ydfan@suse.com> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Acked-by:
Don Brace <don.brace@microsemi.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> (cherry picked from commit e2c7b433) Signed-off-by:
Eric Desrochers <eric.desrochers@canonical.com> Acked-by:
-
hayeswang authored
BugLink: http://bugs.launchpad.net/bugs/1720977 The list rx_done would be initialized when the linking on occurs. Therefore, if a napi is scheduled without any linking on before, the following kernel panic would happen. BUG: unable to handle kernel NULL pointer dereference at 000000000000008 IP: [<ffffffffc085efde>] r8152_poll+0xe1e/0x1210 [r8152] PGD 0 Oops: 0002 [#1] SMP Signed-off-by:
Hayes Wang <hayeswang@realtek.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 98d068ab) Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Acked-by:
Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by:
-
Vinson Lee authored
BugLink: http://bugs.launchpad.net/bugs/1720466Signed-off-by:
Vinson Lee <vlee@freedesktop.org> Acked-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
-
Paolo Pisati authored
BugLink: http://bugs.launchpad.net/bugs/1718886Signed-off-by:
Paolo Pisati <paolo.pisati@canonical.com> Acked-by:
-
- 09 Oct, 2017 7 commits
-
-
Weifeng Voon authored
BugLink: https://bugs.launchpad.net/bugs/1718578 This allows applications to set the transfer timeout in 10ms increments via ioctl I2C_TIMEOUT. Signed-off-by:
Weifeng Voon <weifeng.voon@intel.com> Acked-by:
Jarkko Nikula <jarkko.nikula@linux.intel.com> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> (cherry picked from commit d0bcd8df) Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by:
Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by:
-
Ewan D. Milne authored
BugLink: http://bugs.launchpad.net/bugs/1693369 The call to scsi_is_sas_rphy() needs to be made on the SAS end_device, not on the SCSI device. Fixes: 835831c5 ("ses: use scsi_is_sas_rphy instead of is_sas_attached") Signed-off-by:
Ewan D. Milne <emilne@redhat.com> Reviewed-by:
James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by:
-
Johannes Thumshirn authored
BugLink: http://bugs.launchpad.net/bugs/1693369 Provide a stub implementation for scsi_is_sas_rphy for kernel configurations which do not have CONFIG_SCSI_SAS_ATTRS defined. Reported-by:
kbuild test robot <lkp@intel.com> Suggested-by:
James Bottomley <jejb@linux.vnet.ibm.com> Reviewed-by:
-
James Bottomley authored
BugLink: http://bugs.launchpad.net/bugs/1693369 The current discovery routines use the VPD 0x83 inquiry page to find the device SAS address and match it to the end point in the enclosure. This doesn't work for SATA devices because expanders (or hosts) simply make up an endpoint address for STP and thus the address returned by the VPD page never matches. Instead of doing this, for SAS attached devices, match by the direct endpoint address instead. Signed-off-by:
-
James Bottomley authored
BugLink: http://bugs.launchpad.net/bugs/1693369 For a device known to be SAS connected, this will return the endpoint address. This is useful for getting the SAS address of SATA devices. Reviewed-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
-
Mauricio Faria de Oliveira authored
BugLink: http://bugs.launchpad.net/bugs/1718397 Currently, aio-nr is incremented in steps of 'num_possible_cpus() * 8' for io_setup(nr_events, ..) with 'nr_events < num_possible_cpus() * 4': ioctx_alloc() ... nr_events = max(nr_events, num_possible_cpus() * 4); nr_events *= 2; ... ctx->max_reqs = nr_events; ... aio_nr += ctx->max_reqs; .... This limits the number of aio contexts actually available to much less than aio-max-nr, and is increasingly worse with greater number of CPUs. For example, with 64 CPUs, only 256 aio contexts are actually available (with aio-max-nr = 65536) because the increment is 512 in that scenario. Note: 65536 [max aio contexts] / (64*4*2) [increment per aio context] is 128, but make it 256 (double) as counting against 'aio-max-nr * 2': ioctx_alloc() ... if (aio_nr + nr_events > (aio_max_nr * 2UL) || ... goto err_ctx; ... This patch uses the original value of nr_events (from userspace) to increment aio-nr and count against aio-max-nr, which resolves those. Signed-off-by:
Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> Reported-by:
Lekshmi C. Pillai <lekshmi.cpillai@in.ibm.com> Tested-by:
Paul Nguyen <nguyenp@us.ibm.com> Reviewed-by:
Jeff Moyer <jmoyer@redhat.com> Signed-off-by:
Benjamin LaHaise <bcrl@kvack.org> (cherry picked from commit 2a8a9867) Signed-off-by:
-
Shrirang Bagul authored
BugLink: http://bugs.launchpad.net/bugs/1721455 Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74 series which will by default boot with vid 0x413c and pid's 0x81cf, 0x81d0, 0x81d1,0x81d2. Signed-off-by:
-
- 06 Oct, 2017 9 commits
-
-
Jan Beulich authored
Rather than constructing a local structure instance on the stack, fill the fields directly on the shared ring, just like other backends do. Build on the fact that all response structure flavors are actually identical (the old code did make this assumption too). This is XSA-216. Cc: stable@vger.kernel.org Signed-off-by:
Jan Beulich <jbeulich@suse.com> Reviewed-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Tyler Hicks authored
BugLink: https://launchpad.net/bugs/1567597 Add a new action, SECCOMP_RET_LOG, that logs a syscall before allowing the syscall. At the implementation level, this action is identical to the existing SECCOMP_RET_ALLOW action. However, it can be very useful when initially developing a seccomp filter for an application. The developer can set the default action to be SECCOMP_RET_LOG, maybe mark any obviously needed syscalls with SECCOMP_RET_ALLOW, and then put the application through its paces. A list of syscalls that triggered the default action (SECCOMP_RET_LOG) can be easily gleaned from the logs and that list can be used to build the syscall whitelist. Finally, the developer can change the default action to the desired value. This provides a more friendly experience than seeing the application get killed, then updating the filter and rebuilding the app, seeing the application get killed due to a different syscall, then updating the filter and rebuilding the app, etc. The functionality is similar to what's supported by the various LSMs. SELinux has permissive mode, AppArmor has complain mode, SMACK has bring-up mode, etc. SECCOMP_RET_LOG is given a lower value than SECCOMP_RET_ALLOW as allow while logging is slightly more restrictive than quietly allowing. Unfortunately, the tests added for SECCOMP_RET_LOG are not capable of inspecting the audit log to verify that the syscall was logged. With this patch, the logic for deciding if an action will be logged is: if action == RET_ALLOW: do not log else if action == RET_KILL && RET_KILL in actions_logged: log else if action == RET_LOG && RET_LOG in actions_logged: log else if filter-requests-logging && action in actions_logged: log else if audit_enabled && process-is-being-audited: log else: do not log Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Signed-off-by:
Kees Cook <keescook@chromium.org> (backported from commit 59f5cf44) Acked-by:
-
Tyler Hicks authored
BugLink: https://launchpad.net/bugs/1721676 Add a new filter flag, SECCOMP_FILTER_FLAG_LOG, that enables logging for all actions except for SECCOMP_RET_ALLOW for the given filter. SECCOMP_RET_KILL actions are always logged, when "kill" is in the actions_logged sysctl, and SECCOMP_RET_ALLOW actions are never logged, regardless of this flag. This flag can be used to create noisy filters that result in all non-allowed actions to be logged. A process may have one noisy filter, which is loaded with this flag, as well as a quiet filter that's not loaded with this flag. This allows for the actions in a set of filters to be selectively conveyed to the admin. Since a system could have a large number of allocated seccomp_filter structs, struct packing was taken in consideration. On 64 bit x86, the new log member takes up one byte of an existing four byte hole in the struct. On 32 bit x86, the new log member creates a new four byte hole (unavoidable) and consumes one of those bytes. Unfortunately, the tests added for SECCOMP_FILTER_FLAG_LOG are not capable of inspecting the audit log to verify that the actions taken in the filter were logged. With this patch, the logic for deciding if an action will be logged is: if action == RET_ALLOW: do not log else if action == RET_KILL && RET_KILL in actions_logged: log else if filter-requests-logging && action in actions_logged: log else if audit_enabled && process-is-being-audited: log else: do not log Signed-off-by:
-
Tyler Hicks authored
BugLink: https://launchpad.net/bugs/1721676 BugLink: https://launchpad.net/bugs/1567597 Userspace needs to be able to reliably detect the support of a filter flag. A good way of doing that is by attempting to enter filter mode, with the flag bit(s) in question set, and a NULL pointer for the args parameter of seccomp(2). EFAULT indicates that the flag is valid and EINVAL indicates that the flag is invalid. This patch adds a selftest that can be used to test this method of detection in userspace. Signed-off-by:
-
Tyler Hicks authored
BugLink: https://launchpad.net/bugs/1721676 BugLink: https://launchpad.net/bugs/1567597 Adminstrators can write to this sysctl to set the seccomp actions that are allowed to be logged. Any actions not found in this sysctl will not be logged. For example, all SECCOMP_RET_KILL, SECCOMP_RET_TRAP, and SECCOMP_RET_ERRNO actions would be loggable if "kill trap errno" were written to the sysctl. SECCOMP_RET_TRACE actions would not be logged since its string representation ("trace") wasn't present in the sysctl value. The path to the sysctl is: /proc/sys/kernel/seccomp/actions_logged The actions_avail sysctl can be read to discover the valid action names that can be written to the actions_logged sysctl with the exception of "allow". SECCOMP_RET_ALLOW actions cannot be configured for logging. The default setting for the sysctl is to allow all actions to be logged except SECCOMP_RET_ALLOW. While only SECCOMP_RET_KILL actions are currently logged, an upcoming patch will allow applications to request additional actions to be logged. There's one important exception to this sysctl. If a task is specifically being audited, meaning that an audit context has been allocated for the task, seccomp will log all actions other than SECCOMP_RET_ALLOW despite the value of actions_logged. This exception preserves the existing auditing behavior of tasks with an allocated audit context. With this patch, the logic for deciding if an action will be logged is: if action == RET_ALLOW: do not log else if action == RET_KILL && RET_KILL in actions_logged: log else if audit_enabled && task-is-being-audited: log else: do not log Signed-off-by:
-
Tyler Hicks authored
BugLink: https://launchpad.net/bugs/1721676 BugLink: https://launchpad.net/bugs/1567597 Userspace code that needs to check if the kernel supports a given action may not be able to use the /proc/sys/kernel/seccomp/actions_avail sysctl. The process may be running in a sandbox and, therefore, sufficient filesystem access may not be available. This patch adds an operation to the seccomp(2) syscall that allows userspace code to ask the kernel if a given action is available. If the action is supported by the kernel, 0 is returned. If the action is not supported by the kernel, -1 is returned with errno set to -EOPNOTSUPP. If this check is attempted on a kernel that doesn't support this new operation, -1 is returned with errno set to -EINVAL meaning that userspace code will have the ability to differentiate between the two error cases. Signed-off-by:
Andy Lutomirski <luto@amacapital.net> Signed-off-by:
-
Tyler Hicks authored
BugLink: https://launchpad.net/bugs/1721676 BugLink: https://launchpad.net/bugs/1567597 This patch creates a read-only sysctl containing an ordered list of seccomp actions that the kernel supports. The ordering, from left to right, is the lowest action value (kill) to the highest action value (allow). Currently, a read of the sysctl file would return "kill trap errno trace allow". The contents of this sysctl file can be useful for userspace code as well as the system administrator. The path to the sysctl is: /proc/sys/kernel/seccomp/actions_avail libseccomp and other userspace code can easily determine which actions the current kernel supports. The set of actions supported by the current kernel may be different than the set of action macros found in kernel headers that were installed where the userspace code was built. In addition, this sysctl will allow system administrators to know which actions are supported by the kernel and make it easier to configure exactly what seccomp logs through the audit subsystem. Support for this level of logging configuration will come in a future patch. Signed-off-by:
-
Kees Cook authored
BugLink: https://launchpad.net/bugs/1721676 BugLink: https://launchpad.net/bugs/1567597 Both the upcoming logging improvements and changes to RET_KILL will need to know which filter a given seccomp return value originated from. In order to delay logic processing of result until after the seccomp loop, this adds a single pointer assignment on matches. This will allow both log and RET_KILL logic to work off the filter rather than doing more expensive tests inside the time-critical run_filters loop. Running tight cycles of getpid() with filters attached shows no measurable difference in speed. Suggested-by:
-
Wen-chien Jesse Sung authored
BugLink: https://launchpad.net/bugs/1721511 The new version can be found at OpenNSL git repo: https://github.com/Broadcom-Switch/OpenNSL/tree/v3.4.1.5Signed-off-by:
Wen-chien Jesse Sung <jesse.sung@canonical.com> Acked-by:
Juerg Haefliger <juerg.haefliger@canonical.com> Acked-by:
-
- 05 Oct, 2017 10 commits
-
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1721550Signed-off-by:
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1721550 xen_swiotlb_dma_mmap was backported from v4.10, but older kernels before commit 00085f1e ("dma-mapping: use unsigned long for dma_attrs") use a different signature: arm/xen/mm.c:202:10: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .mmap = xen_swiotlb_dma_mmap, ^~~~~~~~~~~~~~~~~~~~ arm/xen/mm.c:202:10: note: (near initialization for 'xen_swiotlb_dma_ops.mmap') This adapts the patch to the old calling conventions. Fixes: "swiotlb-xen: implement xen_swiotlb_dma_mmap callback" Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Stefano Stabellini <sstabellini@kernel.org> Signed-off-by:
-
Stefano Stabellini authored
BugLink: http://bugs.launchpad.net/bugs/1721550 commit 7e91c7df upstream. This function creates userspace mapping for the DMA-coherent memory. Signed-off-by:
Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by:
Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com> Signed-off-by:
Andrii Anisov <andrii_anisov@epam.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad@kernel.org> Signed-off-by:
-
Vladis Dronov authored
BugLink: http://bugs.launchpad.net/bugs/1721550 commit 8e75f7a7 upstream. 'clk' is copied to a userland with padding byte(s) after 'vclk_post_div' field unitialized, leaking data from the stack. Fix this ensuring all of 'clk' is initialized to zero. References: https://github.com/torvalds/linux/pull/441Reported-by:
sohu0106 <sohu0106@126.com> Signed-off-by:
Vladis Dronov <vdronov@redhat.com> Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
Paolo Bonzini authored
BugLink: http://bugs.launchpad.net/bugs/1721550 commit c0a1666b upstream. This fixes a compilation failure on 32-bit systems. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Robert Jarzmik authored
BugLink: http://bugs.launchpad.net/bugs/1721550 commit 4c35430a upstream. The number of requestor lines was clamped to 0 for all pxa architectures in the requestor declaration. Fix this by using the value. Fixes: 72b195cb ("ARM: pxa: add the number of DMA requestor lines") Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Robert Jarzmik authored
BugLink: http://bugs.launchpad.net/bugs/1721550 commit 72b195cb upstream. Declare the number of DMA requestor lines per platform : - for pxa25x: 40 requestor lines - for pxa27x: 75 requestor lines - for pxa3xx: 100 requestor lines This information will be used to activate the DMA flow control or not. Signed-off-by:
-
Robert Jarzmik authored
BugLink: http://bugs.launchpad.net/bugs/1721550 commit c283e41e upstream. The DMA chip has a fixed number of requestor lines used for flow control. This number is platform dependent. The pxa_dma dma driver will use this value to activate or not the flow control. There won't be any impact on mmp_pdma driver. Signed-off-by:
-
Frederic Barrat authored
BugLink: http://bugs.launchpad.net/bugs/1721550 commit 197267d0 upstream. cxl keeps a driver use count, which is used with the hash memory model on p8 to know when to upgrade local TLBIs to global and to trigger callbacks to manage the MMU for PSL8. If a process opens a context and closes without attaching or fails the attachment, the driver use count is never decremented. As a consequence, TLB invalidations remain global, even if there are no active cxl contexts. We should increment the driver use count when the process is attaching to the cxl adapter, and not on open. It's not needed before the adapter starts using the context and the use count is decremented on the detach path, so it makes more sense. It affects only the user api. The kernel api is already doing The Right Thing. Signed-off-by:
Frederic Barrat <fbarrat@linux.vnet.ibm.com> Fixes: 7bb5d91a ("cxl: Rework context lifetimes") Acked-by:
Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> [ajd: backport to stable v4.4 tree] Signed-off-by:
-
Haozhong Zhang authored
BugLink: http://bugs.launchpad.net/bugs/1721550 commit 5753743f upstream. WARN_ON_ONCE(pi_test_sn(&vmx->pi_desc)) in kvm_vcpu_trigger_posted_interrupt() intends to detect the violation of invariant that VT-d PI notification event is not suppressed when vcpu is in the guest mode. Because the two checks for the target vcpu mode and the target suppress field cannot be performed atomically, the target vcpu mode may change in between. If that does happen, WARN_ON_ONCE() here may raise false alarms. As the previous patch fixed the real invariant breaker, remove this WARN_ON_ONCE() to avoid false alarms, and document the allowed cases instead. Signed-off-by:
Haozhong Zhang <haozhong.zhang@intel.com> Reported-by:
"Ramamurthy, Venkatesh" <venkatesh.ramamurthy@intel.com> Reported-by:
Dan Williams <dan.j.williams@intel.com> Reviewed-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
-
