There is no reason why crypto_rng_reset should modify the seed
so this patch marks it as const. Since our algorithms don't
export a const seed function yet we have to go through some
contortions for now.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 3c5d8fa9f56ad0928e7a1f06003e5034f5eedb52) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
This patch adds the new top-level function crypto_rng_generate
which generates random numbers with additional input. It also
extends the mid-level rng_gen_random function to take additional
data as input.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit ff030b099a21a4753af575b4304249e88400e506) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
This patch converts the top-level crypto_rng to the "new" style.
It was the last algorithm type added before we switched over
to the new way of doing things exemplified by shash.
All users will automatically switch over to the new interface.
Note that this patch does not touch the low-level interface to
rng implementations.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit d0e83059a6c9b04f00264a74b8f6439948de4613) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
Under CONFIG_STRICT_DEVMEM, reading System RAM through /dev/mem is
disallowed. However, on x86, the first 1MB was always allowed for BIOS
and similar things, regardless of it actually being System RAM. It was
possible for heap to end up getting allocated in low 1MB RAM, and then
read by things like x86info or dd, which would trip hardened usercopy:
This changes the x86 exception for the low 1MB by reading back zeros for
System RAM areas instead of blindly allowing them. More work is needed to
extend this to mmap, but currently mmap doesn't go through usercopy, so
hardened usercopy won't Oops the kernel.
Reported-by: Tommi Rantala <tommi.t.rantala@nokia.com> Tested-by: Tommi Rantala <tommi.t.rantala@nokia.com> Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit a4866aa812518ed1a37d8ea0c881dc946409de94)
This commit restores commit 5acb959ad599 ("RDS: add reconnect retry scheme
for stalled connections"). Even though this retry scheme "workaround"
causes a long brownout time in the OVM configuration, it is needed to avoid
RDS loopback connections stalls after switch reboot in the bare-metal
system. As for now, the plan agreed with Exadata is to put back this commit
first and have a similar code path among QU6, QU5 and QU4.
Wei Lin Guay [Thu, 10 Aug 2017 09:59:35 +0000 (11:59 +0200)]
Revert "net/rds: prioritize the base connection establishment"
This reverts commit 1bc87d23681a ("net/rds: prioritize the base connection
establishment"). This patch is reverted because the RDS path record caching
is replaced by the underlying ibacm path record caching. By doing so, all
the TOS connections can be established without depending on its base
connection to perform SA query. Thus, it is not required to prioritize
the base connection establishment.
Wei Lin Guay [Thu, 10 Aug 2017 09:57:34 +0000 (11:57 +0200)]
Revert "net/rds: determine active/passive connection with IP addresses"
This reverts commit 1f2ea7a020a1 ("net/rds: determine active/passive
connection with IP addresses"). The plan is to use the original, well
tested one-sided reconnection that was reverted in "812c02791: RDS: restore
the exponential back-off scheme".
Wei Lin Guay [Thu, 10 Aug 2017 09:36:03 +0000 (11:36 +0200)]
Revert "net/rds: use different workqueue for base_conn"
This reverts commit ad7312bb8b8e ("net/rds: use different workqueue for
base_conn"). The RDS path record caching will be replaced by ibacm. Thus,
all the TOS connections do not rely on its base connection to perform SA
query. As a result, RDS does not need a separate "priority" workqueue for
the base connection.
Shaohua Li [Fri, 8 May 2015 17:51:31 +0000 (10:51 -0700)]
blk-mq: avoid re-initialize request which is failed in direct dispatch
If we directly issue a request and it fails, we use
blk_mq_merge_queue_io(). But we already assigned bio to a request in
blk_mq_bio_to_request. blk_mq_merge_queue_io shouldn't run
blk_mq_bio_to_request again.
Orabug: 26339553 Suggested-by: Jianchao Wang <jianchao.w.wang@oracle.com> Signed-off-by: Shaohua Li <shli@fb.com> Signed-off-by: Jens Axboe <axboe@fb.com>
(cherry picked from commit 239ad215f0d8388cbe6c09a0fab8ad8ff5dba420) Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Bhavesh Davda <bhavesh.davda@oracle.com> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
Instead of duplicating the logic multiple times. Also, it is unnecessary
to zero the buffer in .get_ethtool_stats() because it is already zeroed
by the caller.
Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 5c8227d0d3b1eb1ad8f98d0b6dc619d70f2cfa04) Signed-off-by: Brian Maly <brian.maly@oracle.com>
To allow users to set the hardware bridging mode to VEB or VEPA. Only
single function PF can change the bridging mode.
Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 39d8ba2e71fbdde686d7e31ad141a01994dc0793) Signed-off-by: Brian Maly <brian.maly@oracle.com>
Conflicts:
drivers/net/ethernet/broadcom/bnxt/bnxt.c
Retrieve and store the hardware bridge mode, so that we can implement
ndo_bridge_{get|set)link methods in the next patch.
Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 32e8239c9138a050bc1feeea7cf41f27d79e6664) Signed-off-by: Brian Maly <brian.maly@oracle.com>
VF representors and PTP are added features in the new firmware spec.
Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit acb2005463612930b07723e852b2483d669ff856) Signed-off-by: Brian Maly <brian.maly@oracle.com>
Andy Lutomirski [Sat, 22 Apr 2017 07:01:22 +0000 (00:01 -0700)]
x86/mm: Fix flush_tlb_page() on Xen
flush_tlb_page() passes a bogus range to flush_tlb_others() and
expects the latter to fix it up. native_flush_tlb_others() has the
fixup but Xen's version doesn't. Move the fixup to
flush_tlb_others().
AFAICS the only real effect is that, without this fix, Xen would
flush everything instead of just the one page on remote vCPUs in
when flush_tlb_page() was called.
Signed-off-by: Andy Lutomirski <luto@kernel.org> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Juergen Gross <jgross@suse.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Nadav Amit <namit@vmware.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: e7b52ffd45a6 ("x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range") Link: http://lkml.kernel.org/r/10ed0e4dfea64daef10b87fb85df1746999b4dba.1492844372.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
OraBug: 26662731
(cherry picked from commit dbd68d8e84c606673ebbcf15862f8c155fa92326) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Conflicts:
arch/x86/mm/tlb.c
(uek's native_flush_tlb_others() did not have end's non-zero check)
Add a flag to indicate if a queue is rate-limited. Test the flag in
NAPI poll handler and avoid rescheduling the queue if true, otherwise
we risk locking up the host. The rescheduling will be done in the
timer callback function.
Reported-by: Jean-Louis Dupond <jean-louis@dupond.be> Signed-off-by: Wei Liu <wei.liu2@citrix.com> Tested-by: Jean-Louis Dupond <jean-louis@dupond.be> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Signed-off-by: David S. Miller <davem@davemloft.net>
OraBug: 26662731
(cherry picked from commit dfa523ae9f2542bee4cddaea37b3be3e157f6e6b) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Conflicts:
drivers/net/xen-netback/interface.c
(Upstream's code used napi_complete_done())
Juergen Gross [Thu, 18 May 2017 15:28:49 +0000 (17:28 +0200)]
xen/blkback: don't use xen_blkif_get() in xen-blkback kthread
There is no need to use xen_blkif_get()/xen_blkif_put() in the kthread
of xen-blkback. Thread stopping is synchronous and using the blkif
reference counting in the kthread will avoid to ever let the reference
count drop to zero at the end of an I/O running concurrent to
disconnecting and multiple rings.
Setting ring->xenblkd to NULL after stopping the kthread isn't needed
as the kthread does this already.
Signed-off-by: Juergen Gross <jgross@suse.com> Tested-by: Steven Haigh <netwiz@crc.id.au> Acked-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
OraBug: 26662731
(cherry picked from commit a24fa22ce22ae302b3bf8f7008896d52d5d57b8d) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Juergen Gross [Thu, 18 May 2017 15:28:48 +0000 (17:28 +0200)]
xen/blkback: don't free be structure too early
The be structure must not be freed when freeing the blkif structure
isn't done. Otherwise a use-after-free of be when unmapping the ring
used for communicating with the frontend will occur in case of a
late call of xenblk_disconnect() (e.g. due to an I/O still active
when trying to disconnect).
Signed-off-by: Juergen Gross <jgross@suse.com> Tested-by: Steven Haigh <netwiz@crc.id.au> Acked-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
OraBug: 26662731
(cherry picked from commit 71df1d7ccad1c36f7321d6b3b48f2ea42681c363) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Juergen Gross [Wed, 10 May 2017 04:08:44 +0000 (06:08 +0200)]
xen: adjust early dom0 p2m handling to xen hypervisor behavior
When booted as pv-guest the p2m list presented by the Xen is already
mapped to virtual addresses. In dom0 case the hypervisor might make use
of 2M- or 1G-pages for this mapping. Unfortunately while being properly
aligned in virtual and machine address space, those pages might not be
aligned properly in guest physical address space.
So when trying to obtain the guest physical address of such a page
pud_pfn() and pmd_pfn() must be avoided as those will mask away guest
physical address bits not being zero in this special case.
(cherry picked from commit 69861e0a52f8733355ce246f0db15e1b240ad667) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Conflicts:
arch/x86/xen/mmu_pv.c
(No mmu_pv.c in our tree)
Boris Ostrovsky [Wed, 3 May 2017 20:20:51 +0000 (16:20 -0400)]
xen/x86: Do not call xen_init_time_ops() until shared_info is initialized
Routines that are set by xen_init_time_ops() use shared_info's
pvclock_vcpu_time_info area. This area is not properly available until
shared_info is mapped in xen_setup_shared_info().
This became especially problematic due to commit dd759d93f4dd ("x86/timers:
Add simple udelay calibration") where we end up reading tsc_to_system_mul
from xen_dummy_shared_info (i.e. getting zero value) and then trying
to divide by it in pvclock_tsc_khz().
(cherry picked from commit d162809f85b4f54ef075517ffa2f3d02e55d5a53) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Conflicts:
arch/x86/xen/enlighten_pv.c
(No enlighten_pv.c in our tree. Note also that
we don't have dd759d93f4dd. Still, this fixes a
latent bug).
When rebooting DOM0 with ACPI on ARM64, the kernel is crashing with the stack
trace [1].
This is happening because when EFI runtimes are enabled, the reset code
(see machine_restart) will first try to use EFI restart method.
However, the EFI restart code is expecting the reset_system callback to
be always set. This is not the case for Xen and will lead to crash.
The EFI restart helper is used in multiple places and some of them don't
not have fallback (see machine_power_off). So implement reset_system
callback as a call to xen_reboot when using EFI Xen.
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: x86@kernel.org
The x86 code has theoritically a similar issue, altought EFI does not
seem to be the preferred method. I have only built test it on x86.
This should also probably be fixed in stable tree.
Changes in v2:
- Implement xen_efi_reset_system using xen_reboot
- Move xen_efi_reset_system in drivers/xen/efi.c Signed-off-by: Juergen Gross <jgross@suse.com>
OraBug: 26662731
(cherry picked from commit e371fd7607999fabbd955b4d22c8e912594a7997) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
(cherry picked from commit 5d9404e1185de8d508cd042761306495f727d7eb) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Conflicts:
arch/x86/xen/xen-ops.h
arch/x86/xen/enlighten.c
(No changes to xen-ops.h, make xen_reboot() non-static)
Boris Ostrovsky [Fri, 21 Apr 2017 15:13:14 +0000 (11:13 -0400)]
xen/pvh: Do not fill kernel's e820 map in init_pvh_bootparams()
e820 map is updated with information from the zeropage (i.e. pvh_bootparams)
by default_machine_specific_memory_setup(). With the way things are done
now, we end up with a duplicated e820 map.
(cherry picked from commit 5f6a1614fab801834e32b420b60acdc27acfcdec) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Conflicts:
arch/x86/xen/enlighten_pvh.c
(No enlighten_pvh.c in our tree)
xen,kdump: handle pv domain in paddr_vmcoreinfo_note()
For kdump to work correctly it needs the physical address of
vmcoreinfo_note. When running as dom0 this means the virtual address
has to be translated to the related machine address.
paddr_vmcoreinfo_note() is meant to do the translation via
__pa_symbol() only, but being attributed "weak" it can be replaced
easily in Xen case.
Signed-off-by: Juergen Gross <jgross@suse.com> Tested-by: Petr Tesarik <ptesarik@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Juergen Gross <jgross@suse.com>
OraBug: 26662731
(cherry picked from commit 29985b09613ba106a1ed0496988636d288600515) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Conflicts:
arch/x86/xen/mmu_pv.c
( no mmu_pv.c in our tree)
Input: xen-kbdfront - add module parameter for setting resolution
Add a parameter for setting the resolution of xen-kbdfront in order to
be able to cope with a (virtual) frame buffer of arbitrary resolution.
While at it remove the pointless second reading of parameters from
Xenstore in the device connection phase: all parameters are available
during device probing already and that is where they should be read.
Marc Olson [Tue, 11 Apr 2017 19:24:09 +0000 (12:24 -0700)]
blkfront: add uevent for size change
When a blkfront device is resized from dom0, emit a KOBJ_CHANGE uevent to
notify the guest about the change. This allows for custom udev rules, such
as automatically resizing a filesystem, when an event occurs.
Nicolai Stange [Thu, 30 Mar 2017 20:06:42 +0000 (22:06 +0200)]
x86/xen/time: Set ->min_delta_ticks and ->max_delta_ticks
In preparation for making the clockevents core NTP correction aware,
all clockevent device drivers must set ->min_delta_ticks and
->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a
clockevent device's rate is going to change dynamically and thus, the
ratio of ns to ticks ceases to stay invariant.
Make the x86 arch's xen clockevent driver initialize these fields properly.
This patch alone doesn't introduce any change in functionality as the
clockevents core still looks exclusively at the (untouched) ->min_delta_ns
and ->max_delta_ns. As soon as this has changed, a followup patch will
purge the initialization of ->min_delta_ns and ->max_delta_ns from this
driver.
Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: x86@kernel.org Cc: xen-devel@lists.xenproject.org Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Nicolai Stange <nicstange@gmail.com> Signed-off-by: John Stultz <john.stultz@linaro.org>
OraBug: 26662731
(cherry picked from commit 3d18d661aaad5a22f4d37a0592acc9d784f2a11b) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Conflicts:
arch/x86/xen/time.c
(whitespaces)
xen, fbfront: add support for specifying size via xenstore
Today xen-fbfront supports specifying the display size via module
parameters only. Add support for specifying the size via Xenstore in
order to enable doing this easily via the domain's Xen configuration.
Add an error message in case the configured display size conflicts
with video memory size.
Connecting to the backend isn't working reliably in xen-fbfront: in
case XenbusStateInitWait of the backend has been missed the backend
transition to XenbusStateConnected will trigger the connected state
only without doing the actions required when the backend has
connected.
Jan Beulich [Tue, 4 Apr 2017 12:27:22 +0000 (06:27 -0600)]
xenbus: remove transaction holder from list before freeing
After allocation the item is being placed on the list right away.
Consequently it needs to be taken off the list before freeing in the
case xenbus_dev_request_and_reply() failed, as in that case the
callback (xenbus_dev_queue_reply()) is not being called (and if it
was called, it should do both).
Fixes: 5584ea250ae44f929feb4c7bd3877d1c5edbf813 Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
OraBug: 26662731
(cherry picked from commit ac4cde398a96c1d28b1c28a0f69b6efd892a1c8a) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Ankur Arora [Tue, 21 Mar 2017 22:43:38 +0000 (15:43 -0700)]
xen/acpi: upload PM state from init-domain to Xen
This was broken in commit cd979883b9ed ("xen/acpi-processor:
fix enabling interrupts on syscore_resume"). do_suspend (from
xen/manage.c) and thus xen_resume_notifier never get called on
the initial-domain at resume (it is if running as guest.)
The rationale for the breaking change was that upload_pm_data()
potentially does blocking work in syscore_resume(). This patch
addresses the original issue by scheduling upload_pm_data() to
execute in workqueue context.
Cc: Stanislaw Gruszka <sgruszka@redhat.com> Cc: stable@vger.kernel.org Based-on-patch-by: Konrad Wilk <konrad.wilk@oracle.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
OraBug: 26662731
(cherry picked from commit 1914f0cd203c941bba72f9452c8290324f1ef3dc) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Paul Durrant [Mon, 13 Feb 2017 17:03:24 +0000 (17:03 +0000)]
xen/privcmd: add IOCTL_PRIVCMD_RESTRICT
The purpose if this ioctl is to allow a user of privcmd to restrict its
operation such that it will no longer service arbitrary hypercalls via
IOCTL_PRIVCMD_HYPERCALL, and will check for a matching domid when
servicing IOCTL_PRIVCMD_DM_OP or IOCTL_PRIVCMD_MMAP*. The aim of this
is to limit the attack surface for a compromised device model.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
OraBug: 26662731
(cherry picked from commit 4610d240d691768203fdd210a5da0a2e02eddb76) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Paul Durrant [Mon, 13 Feb 2017 17:03:23 +0000 (17:03 +0000)]
xen/privcmd: Add IOCTL_PRIVCMD_DM_OP
Recently a new dm_op[1] hypercall was added to Xen to provide a mechanism
for restricting device emulators (such as QEMU) to a limited set of
hypervisor operations, and being able to audit those operations in the
kernel of the domain in which they run.
This patch adds IOCTL_PRIVCMD_DM_OP as gateway for __HYPERVISOR_dm_op.
NOTE: There is no requirement for user-space code to bounce data through
locked memory buffers (as with IOCTL_PRIVCMD_HYPERCALL) since
privcmd has enough information to lock the original buffers
directly.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
OraBug: 26662731
(cherry picked from commit ab520be8cd5d56867fc95cfbc34b90880faf1f9d) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Conflicts:
arch/arm/xen/enlighten.c
arch/arm/xen/hypercall.S
arch/arm64/xen/hypercall.S
(uek doesn't define HYPERVISOR_vm_assist() for ARM)
arch/arm/include/asm/xen/hypercall.h
(Upstream defines HYPERVISOR_dm_op() in
include/xen/arm/hypercall.h, which uek4 does not have)
Julia Lawall [Sun, 5 Feb 2017 21:39:37 +0000 (22:39 +0100)]
tpm xen: drop unneeded chip variable
The call that used chip was dropped in 1f0f30e404b3. Drop the
leftover declaration and initialization.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
OraBug: 26662731
(cherry picked from commit 5cec5bacd37784a1596d2f8fea377212948a0bf4) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Juergen Gross [Thu, 9 Feb 2017 13:39:58 +0000 (14:39 +0100)]
xen: optimize xenbus driver for multiple concurrent xenstore accesses
Handling of multiple concurrent Xenstore accesses through xenbus driver
either from the kernel or user land is rather lame today: xenbus is
capable to have one access active only at one point of time.
Rewrite xenbus to handle multiple requests concurrently by making use
of the request id of the Xenstore protocol. This requires to:
- Instead of blocking inside xb_read() when trying to read data from
the xenstore ring buffer do so only in the main loop of
xenbus_thread().
- Instead of doing writes to the xenstore ring buffer in the context of
the caller just queue the request and do the write in the dedicated
xenbus thread.
- Instead of just forwarding the request id specified by the caller of
xenbus to xenstore use a xenbus internal unique request id. This will
allow multiple outstanding requests.
- Modify the locking scheme in order to allow multiple requests being
active in parallel.
- Instead of waiting for the reply of a user's xenstore request after
writing the request to the xenstore ring buffer return directly to
the caller and do the waiting in the read path.
Additionally signal handling was optimized by avoiding waking up the
xenbus thread or sending an event to Xenstore in case the addressed
entity is known to be running already.
As a result communication with Xenstore is sped up by a factor of up
to 5: depending on the request type (read or write) and the amount of
data transferred the gain was at least 20% (small reads) and went up to
a factor of 5 for large writes.
In the end some more rough edges of xenbus have been smoothed:
- Handling of memory shortage when reading from xenstore ring buffer in
the xenbus driver was not optimal: it was busy looping and issuing a
warning in each loop.
- In case of xenstore not running in dom0 but in a stubdom we end up
with two xenbus threads running as the initialization of xenbus in
dom0 expecting a local xenstored will be redone later when connecting
to the xenstore domain. Up to now this was no problem as locking
would prevent the two xenbus threads interfering with each other, but
this was just a waste of kernel resources.
- An out of memory situation while writing to or reading from the
xenstore ring buffer no longer will lead to a possible loss of
synchronization with xenstore.
- The user read and write part are now interruptible by signals.
Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
OraBug: 26662731
(cherry picked from commit fd8aa9095a95c02dcc35540a263267c29b8fda9d) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Conflicts:
drivers/xen/xenbus/xenbus_comms.c
(Use mb() instead of virt_mb() for consistency in our code)
Cc: konrad.wilk@oracle.com Cc: roger.pau@citrix.com Cc: wei.liu2@citrix.com Cc: paul.durrant@citrix.com Cc: netdev@vger.kernel.org Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
OraBug: 26662731
(cherry picked from commit 5584ea250ae44f929feb4c7bd3877d1c5edbf813) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Conflicts:
drivers/xen/ovmapi.c
(Updated for new interface)
Juergen Gross [Thu, 9 Feb 2017 13:39:56 +0000 (14:39 +0100)]
xen: clean up xenbus internal headers
The xenbus driver has an awful mixture of internally and globally
visible headers: some of the internally used only stuff is defined in
the global header include/xen/xenbus.h while some stuff defined in
internal headers is used by other drivers, too.
Clean this up by moving the externally used symbols to
include/xen/xenbus.h and the symbols used internally only to a new
header drivers/xen/xenbus/xenbus.h replacing xenbus_comms.h and
xenbus_probe.h
Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
OraBug: 26662731
(cherry picked from commit 332f791dc98d98116f4473b726f67c9321b0f31e) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Conflicts:
drivers/xen/xenbus/xenbus_dev_frontend.c
(MODULE_LICENSE() is present in our code)
Boris Ostrovsky [Mon, 6 Feb 2017 15:58:06 +0000 (10:58 -0500)]
xen/pvh: Use Xen's emergency_restart op for PVH guests
Using native_machine_emergency_restart (called during reboot) will
lead PVH guests to machine_real_restart() where we try to use
real_mode_header which is not initialized.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Juergen Gross <jgross@suse.com>
OraBug: 26662731
(cherry picked from commit 7a1c44ebc5ac2e2c28d95b0da6060728c334e7e4) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Boris Ostrovsky [Mon, 6 Feb 2017 15:56:15 +0000 (10:56 -0500)]
xen/pvh: Initialize grant table for PVH guests
Like PV guests, PVH does not have PCI devices and therefore cannot
use MMIO space to store grants. Instead it balloons out memory and
keeps grants there.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Juergen Gross <jgross@suse.com>
OraBug: 26662731
(cherry picked from commit 8613d78ab09900010a5b32e78ff229f551d661d6) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Boris Ostrovsky [Mon, 6 Feb 2017 00:50:58 +0000 (19:50 -0500)]
xen/pvh: Make sure we don't use ACPI_IRQ_MODEL_PIC for SCI
Since we are not using PIC and (at least currently) don't have IOAPIC
we want to make sure that acpi_irq_model doesn't stay set to
ACPI_IRQ_MODEL_PIC (which is the default value). If we allowed it to
stay then acpi_os_install_interrupt_handler() would try (and fail) to
request_irq() for PIC.
Instead we set the model to ACPI_IRQ_MODEL_PLATFORM which will prevent
this from happening.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Juergen Gross <jgross@suse.com>
OraBug: 26662731
(cherry picked from commit 5adad168e586cb381633f45d181bb729b04393a5) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Boris Ostrovsky [Mon, 6 Feb 2017 00:50:52 +0000 (19:50 -0500)]
xen/pvh: Bootstrap PVH guest
Start PVH guest at XEN_ELFNOTE_PHYS32_ENTRY address. Setup hypercall
page, initialize boot_params, enable early page tables.
Since this stub is executed before kernel entry point we cannot use
variables in .bss which is cleared by kernel. We explicitly place
variables that are initialized here into .data.
While adjusting xen_hvm_init_shared_info() make it use cpuid_e?x()
instead of cpuid() (wherever possible).
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Juergen Gross <jgross@suse.com>
OraBug: 26662731
(cherry picked from commit 7243b93345f7f8de260e8f5b4670803e64fcbb00) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Boris Ostrovsky [Fri, 3 Feb 2017 21:57:22 +0000 (16:57 -0500)]
xen/x86: Remove PVH support
We are replacing existing PVH guests with new implementation.
We are keeping xen_pvh_domain() macro (for now set to zero) because
when we introduce new PVH implementation later in this series we will
reuse current PVH-specific code (xen_pvh_gnttab_setup()), and that
code is conditioned by 'if (xen_pvh_domain())'. (We will also need
a noop xen_pvh_domain() for !CONFIG_XEN_PVH).
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Juergen Gross <jgross@suse.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
OraBug: 26662731
(cherry picked from commit 063334f30543597430f172bd7690d21e3590e148) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Conflicts:
arch/x86/xen/enlighten.c
(We don't have xen_dom0_set_legacy_features() and xen_cpuhp_setup())
arch/x86/xen/smp.h
(xen_smp_intr_*() are not in our header files)
arch/x86/xen/xen-head.S
(difference in a comment)
include/xen/xen.h
(xen_have_vector_callback is not in upstream's definition of xen_pvh_domain())
Juergen Gross [Tue, 10 Jan 2017 13:32:52 +0000 (14:32 +0100)]
xen/netback: set default upper limit of tx/rx queues to 8
The default for the maximum number of tx/rx queues of one interface is
the number of cpus of the system today. As each queue pair reserves 512
grant pages this default consumes a ridiculous number of grants for
large guests.
Limit the queue number to 8 as default. This value can be modified
via a module parameter if required.
Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
OraBug: 26662731
(cherry picked from commit 56dd5af9bc23d0d5d23bb207c477715b4c2216c5) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Juergen Gross [Tue, 10 Jan 2017 13:32:51 +0000 (14:32 +0100)]
xen/netfront: set default upper limit of tx/rx queues to 8
The default for the number of tx/rx queues of one interface is the
number of vcpus of the system today. As each queue pair reserves 512
grant pages this default consumes a ridiculous number of grants for
large guests.
Limit the queue number to 8 as default. This value can be modified
via a module parameter if required.
Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
OraBug: 26662731
(cherry picked from commit 034702a64a6692a8d5d0d9630064a014fc633728) Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
Ka-Cheong Poon [Thu, 31 Aug 2017 03:16:26 +0000 (20:16 -0700)]
rds: reduce memory footprint for RDS when transport is RDMA
RDS over IB does not use multipath RDS, so the array
of additional rds_conn_path structures is always superfluous
in this case. Reduce the memory footprint of the rds module
by making this a dynamic allocation predicated on whether
the transport is mp_capable.
Avinash Repaka [Fri, 21 Oct 2016 22:34:19 +0000 (15:34 -0700)]
RDS: IB: Destroy rdma_cm_id when unloading module
rdma_cm_id is not being destroyed as part of module_exit(). This would
lead to memory corruption and eventual node crash if rds_rdma module is
unloaded.
To avoid this, stop listening(destroy rdma_cm_id) as the first step of
unloading the module and curb any more connection attempts.
This undoes the change made by commit 4d4692145bf7 ("RDS: Drop stale
iWARP support")
Avinash Repaka [Thu, 31 Aug 2017 21:37:42 +0000 (14:37 -0700)]
RDS: IB: Destroy aux_wq if rds_ib_init() fails
This patch destroys rds_aux_wq in rds_ib_init() error path to avoid
memory leak. Since destroy_workqueue() waits on pending work to be done,
we can remove flush_workqueue() prior to destroying.
Commit 8fba54aebbdf ("fuse: direct-io: don't dirty ITER_BVEC pages") fixes
the ITER_BVEC page deadlock for direct io in fuse by checking in
fuse_direct_io(), whether the page is a bvec page or not, before locking
it. However, this check is missed when the "async_dio" mount option is
enabled. In this case, set_page_dirty_lock() is called from the req->end
callback in request_end(), when the fuse thread is returning from userspace
to respond to the read request. This will cause the same deadlock because
the bvec condition is not checked in this path.
Here is the stack of the deadlocked thread, while returning from userspace:
Håkon Bugge [Tue, 8 Aug 2017 09:13:32 +0000 (11:13 +0200)]
rds: Reintroduce statistics counting
In commit 7e3f2952eeb1 ("rds: don't let RDS shutdown a connection
while senders are present"), refilling the receive queue was removed
from rds_ib_recv(), along with the increment of
s_ib_rx_refill_from_thread.
Commit 73ce4317bf98 ("RDS: make sure we post recv buffers")
re-introduces filling the receive queue from rds_ib_recv(), but does
not add the statistics counter. rds_ib_recv() was later renamed to
rds_ib_recv_path().
This commit reintroduces the statistics counting of
s_ib_rx_refill_from_thread and s_ib_rx_refill_from_cq.
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com> Reviewed-by: Knut Omang <knut.omang@oracle.com> Reviewed-by: Wei Lin Guay <wei.lin.guay@oracle.com> Reviewed-by: Shamir Rabinovitch <shamir.rabinovitch@oracle.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry-picked from upstream 05bfd7dbb53a10be4a3e7aebaeec04b558198d49)
It is not always easy to determine the cause of an RCU stall just by
analysing the RCU stall messages, mainly when the problem is caused
by the indirect starvation of rcu threads. For example, when preempt_rcu
is not awakened due to the starvation of a timer softirq.
We have been hard coding panic() in the RCU stall functions for
some time while testing the kernel-rt. But this is not possible in
some scenarios, like when supporting customers.
This patch implements the sysctl kernel.panic_on_rcu_stall. If
set to 1, the system will panic() when an RCU stall takes place,
enabling the capture of a vmcore. The vmcore provides a way to analyze
all kernel/tasks states, helping out to point to the culprit and the
solution for the stall.
The kernel.panic_on_rcu_stall sysctl is disabled by default.
Changes from v1:
- Fixed a typo in the git log
- The if(sysctl_panic_on_rcu_stall) panic() is in a static function
- Fixed the CONFIG_TINY_RCU compilation issue
- The var sysctl_panic_on_rcu_stall is now __read_mostly
Cc: Jonathan Corbet <corbet@lwn.net> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Cc: Josh Triplett <josh@joshtriplett.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Lai Jiangshan <jiangshanlai@gmail.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Reviewed-by: Arnaldo Carvalho de Melo <acme@kernel.org> Tested-by: "Luis Claudio R. Goncalves" <lgoncalv@redhat.com> Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
(cherry picked from commit 088e9d253d3a4ab7e058dd84bb532c32dadf1882) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
Conflicts:
Documentation/sysctl/kernel.txt
update_group_capacity()
update_cpu_capacity()
scale_rt_capacity()
{
...
total = sched_avg_period() + delta;
used = div_u64(avg, total);
...
}
Seems this issue could be reproduced on all I tried stable 4.1 - last
kernel.
To fix this issue, check user input value of sysctl_sched_time_avg, keep
it unchanged when hit invalid input, set the min limit of
sysctl_sched_time_avg to 1 ms.
Thomas Gleixner [Tue, 14 Jul 2015 20:03:57 +0000 (22:03 +0200)]
genirq: Revert sparse irq locking around __cpu_up() and move it to x86 for now
Boris reported that the sparse_irq protection around __cpu_up() in the
generic code causes a regression on Xen. Xen allocates interrupts and
some more in the xen_cpu_up() function, so it deadlocks on the
sparse_irq_lock.
There is no simple fix for this and we really should have the
protection for all architectures, but for now the only solution is to
move it to x86 where actual wreckage due to the lack of protection has
been observed.
Reported-and-tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Fixes: a89941816726 'hotplug: Prevent alloc/free of irq descriptors during cpu up/down' Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: xiao jin <jin.xiao@intel.com> Cc: Joerg Roedel <jroedel@suse.de> Cc: Borislav Petkov <bp@suse.de> Cc: Yanmin Zhang <yanmin_zhang@linux.intel.com> Cc: xen-devel <xen-devel@lists.xenproject.org>
(cherry picked from commit ce0d3c0a6fb1422101498ef378c0851dabbbf67f)
gcc warns about the newly added driver when phys_addr_t is wider than
a pointer:
drivers/uio/uio_hv_generic.c: In function 'hv_uio_mmap':
drivers/uio/uio_hv_generic.c:71:17: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
virt_to_phys((void *)info->mem[mi].addr) >> PAGE_SHIFT,
drivers/uio/uio_hv_generic.c: In function 'hv_uio_probe':
drivers/uio/uio_hv_generic.c:140:5: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
= (phys_addr_t)dev->channel->ringbuffer_pages;
drivers/uio/uio_hv_generic.c:147:3: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
(phys_addr_t)vmbus_connection.int_page;
drivers/uio/uio_hv_generic.c:153:3: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
(phys_addr_t)vmbus_connection.monitor_pages[1];
I can't see why we store a virtual address in a phys_addr_t here,
as the only user of that variable converts it into a physical
address anyway, so this moves the conversion to where it logically
fits according to the types.
Fixes: 95096f2fbd10 ("uio-hv-generic: new userspace i/o driver for VMBus") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 190cc65e912de7e8f7ebddcecfbf55a610281a8c) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
This is a new driver to enable userspace networking on VMBus.
It is based largely on the similar driver that already exists
for PCI, and earlier work done by Brocade to support DPDK.
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 95096f2fbd10186d3e78a328b327afc71428f65f) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
Guests running within virtual machines might be affected by SMP effects even if
the guest itself is compiled without SMP support. This is an artifact of
interfacing with an SMP host while running an UP kernel. Using mandatory
barriers for this use-case would be possible but is often suboptimal.
In particular, virtio uses a bunch of confusing ifdefs to work around
this, while xen just uses the mandatory barriers.
To better handle this case, low-level virt_mb() etc macros are made available.
These are implemented trivially using the low-level __smp_xxx macros,
the purpose of these wrappers is to annotate those specific cases.
These have the same effect as smp_mb() etc when SMP is enabled, but generate
identical code for SMP and non-SMP systems. For example, virtual machine guests
should use virt_mb() rather than smp_mb() when synchronizing against a
(possibly SMP) host.
Suggested-by: David Miller <davem@davemloft.net> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
(cherry picked from commit 6a65d26385bf487926a0616650927303058551e3) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
On !SMP, most architectures define their
barriers as compiler barriers.
On SMP, most need an actual barrier.
Make it possible to remove the code duplication for
!SMP by defining low-level __smp_xxx barriers
which do not depend on the value of SMP, then
use them from asm-generic conditionally.
Besides reducing code duplication, these low level APIs will also be
useful for virtualization, where a barrier is sometimes needed even if
!SMP since we might be talking to another kernel on the same SMP system.
Both virtio and Xen drivers will benefit.
The smp_xxx variants should use __smp_XXX ones or barrier() depending on
SMP, identically for all architectures.
We keep ifndef guards around them for now - once/if all
architectures are converted to use the generic
code, we'll be able to remove these.
Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
(cherry picked from commit a9e4252a9b147043142282ebb65da94dcb951e2a) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
Conflicts:
include/asm-generic/barrier.h
As on most architectures, on x86 read_barrier_depends and
smp_read_barrier_depends are empty. Drop the local definitions and pull
the generic ones from asm-generic/barrier.h instead: they are identical.
This is in preparation to refactoring this code area.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit 300b06d4555305dc227748674f75970f2f84c224) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
Conflicts:
arch/x86/include/asm/barrier.h
Since kernel-ueknano has no explicit dependencies specified in the spec
file, it fails to check or install linux-nano-firmware rpm. This commit
adds requires, provides, conflicts, obsoletes directives to kernel-ueknano
same as in kernel-uek package.
After some idle time on a RC connection xve driver cleans up the idle entry
and by that time arp entry for that address would be flushed out.
Further, traffic re-establishment for that address is taken care by arps
generated by the system. But its not rare that arp entry for that
address is still present with driver cleaned up the path and in that
case xve driver generates arp/ndp packets to resolve the path.
While generating an vlan based arp, xve driver uses "vlan_eth_hdr" API
to fill vlan specific data. This API works as expected only if skb
mac_header is initialized to proper value before using API.
In xve_create_arp and xve_create_ndp newly allocated skb's will not have
correct mac_header offset and as a result the pointer returned by
vlan_eth_hdr function is not the correct address to use, some times this
will result in a kernel panic.
Call Trace:
BUG: unable to handle kernel paging request at ffff88005a47060b
IP: [<ffffffffa12e3614>] xve_create_arp+0x1ae/0x200 [xve]
The fix here is to directly typecast skb->data instead of using
"vlan_eth_hdr" API.
This change in xve of using "vlan_eth_hdr" was mostly introduced during
EDR/uVNIC development and is applicable only for UEK4.
Signed-off-by: Pradeep Gopanapalli <pradeep.gopanapalli@oracle.com> Reviewed-by: Chien Yen <chien.yen@oracle.com>
Nick Alcock [Fri, 4 Aug 2017 16:54:24 +0000 (17:54 +0100)]
dtrace: work around libdtrace-ctf bug
The bug involves synthesising pointers to types (ipaddr_t *, in
particular) when such pointer types do not appear in the CTF files but
are needed by the CTF itself. This is working in standalone modules,
but not in modules with parent type containers.
As a workaround, pro tem before fixing this properly in libdtrace-ctf,
hack around it for the one type it is necessary for (a type that is used
in the DTrace system translators, so if this type does not resolve
correctly DTrace will not start). A suitable workaround is simply to
introduce a use of this pointer type in the C code, and it so happens
that we have a place where this would fit perfectly well.
Orabug: 26583958 Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: Tomas Jedlicka <tomas.jedlicka@oracle.com> Reviewed-by: Kris Van Hees <kris.van.hees@oracle.com>
Signed-off-by: Tomas Jedlicka <tomas.jedlicka@oracle.com> Reviewed-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: Kris Van Hees <kris.van.hees@oracle.com>
Tomas Jedlicka [Tue, 1 Aug 2017 13:15:44 +0000 (09:15 -0400)]
dtrace: Integrate DTrace Modules into kernel proper
This changeset integrates DTrace module sources into the main kernel
source tree under the GPLv2 license. Sources have been moved to
appropriate locations in the kernel tree.
In addition a new RPM package is introduced: kernel-headers-dtrace.
This package is responsible for installation of DTrace related header
files for its userspace component.
Signed-off-by: Tomas Jedlicka <tomas.jedlicka@oracle.com> Signed-off-by: David Mc Lean <david.mclean@oracle.com> Reviewed-by: Kris Van Hees <kris.van.hees@oracle.com>
Updates to tp_reserve can race with reads of the field in
packet_set_ring. Avoid this by holding the socket lock during
updates in setsockopt PACKET_RESERVE.
This bug was discovered by syzkaller.
Fixes: 8913336a7e8d ("packet: add PACKET_RESERVE sockopt") Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit c27927e372f0785f3303e8fad94b85945e2c97b7) Signed-off-by: Brian Maly <brian.maly@oracle.com>
Satish Kharat [Tue, 27 Jun 2017 00:49:06 +0000 (17:49 -0700)]
scsi: fnic: changing queue command to return result DID_IMM_RETRY when rport is init
Currently the queue command returns DID_NO_CONNECT anytime the rport is
not in RPORT_ST_READY state. Changing it to return DID_NO_CONNECT only
when the rport is in RPORT_ST_DELETE state. When the rport is in one of
the init states retruning DID_IMM_RETRY.
Signed-off-by: Sesidhar Baddela <sebaddel@cisco.com> Signed-off-by: Satish Kharat <satishkh@cisco.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 4a1108d6caf7cd0f15d439bee6163ba00c7c1b33) Signed-off-by: Joe Jin <joe.jin@oracle.com>
stub_disconnect() calls stub_device_reset() during usb_unbind_device() when
usb device is locked. So usb_lock_device_for_reset() in stub_device_reset()
in that case polls for one second and returns -EBUSY anyway.
Remove useless flag USBIP_EH_RESET from SDEV_EVENT_REMOVED.
Signed-off-by: Alexander Popov <alpopov@ptsecurity.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 134a92659f9382f00f94b880183472b0769ad53e) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
Add constants for VUDC events in usbip_common.h
and make use of them in usbip_common.c.
This commit is a result of cooperation between Samsung R&D Institute
Poland and Open Operating Systems Student Society at University
of Warsaw (O2S3@UW) consisting of:
Igor Kotrasinski <ikotrasinsk@gmail.com>
Karol Kosik <karo9@interia.eu>
Ewelina Kosmider <3w3lfin@gmail.com>
Dawid Lazarczyk <lazarczyk.dawid@gmail.com>
Piotr Szulc <ps347277@students.mimuw.edu.pl>
Tutor and project owner:
Krzysztof Opasiak <k.opasiak@samsung.com>
Signed-off-by: Igor Kotrasinski <i.kotrasinsk@samsung.com> Signed-off-by: Karol Kosik <karo9@interia.eu>
[Small fixes and commit message update] Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c7af4c221878ad684f0412eba2a1f18fa126c6d5) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
In current USB/IP implementation, event kernel threads are created for
each port. The functions of the threads are closing connection and
error handling so they don't have not so many events to handle. There's
no need to have thread for each port.
BEFORE) vhci side - VHCI_NPORTS(8) threads are created.
$ ps aux | grep usbip
root 10059 0.0 0.0 0 0 ? S 17:06 0:00 [usbip_eh]
root 10060 0.0 0.0 0 0 ? S 17:06 0:00 [usbip_eh]
root 10061 0.0 0.0 0 0 ? S 17:06 0:00 [usbip_eh]
root 10062 0.0 0.0 0 0 ? S 17:06 0:00 [usbip_eh]
root 10063 0.0 0.0 0 0 ? S 17:06 0:00 [usbip_eh]
root 10064 0.0 0.0 0 0 ? S 17:06 0:00 [usbip_eh]
root 10065 0.0 0.0 0 0 ? S 17:06 0:00 [usbip_eh]
root 10066 0.0 0.0 0 0 ? S 17:06 0:00 [usbip_eh]
BEFORE) stub side - threads will be created every bind operation.
$ ps aux | grep usbip
root 8368 0.0 0.0 0 0 ? S 17:56 0:00 [usbip_eh]
root 8399 0.0 0.0 0 0 ? S 17:56 0:00 [usbip_eh]
This patch put event threads of stub and vhci driver as one workqueue.
AFTER) only one event threads in each vhci and stub side.
$ ps aux | grep usbip
root 10457 0.0 0.0 0 0 ? S< 17:47 0:00 [usbip_event]
2. Modification to usbip_event.c
BEFORE) kernel threads are created in usbip_start_eh().
AFTER) one workqueue is created in new usbip_init_eh().
Event handler which was main loop of kernel thread is modified to
workqueue handler.
Events themselves are stored in struct usbip_device - same as before.
usbip_devices which have event are listed in event_list.
The handler picks an element from the list and wakeup usbip_device. The
wakeup method is same as before.
usbip_in_eh() substitutes statement which checks whether functions are
called from eh_ops or not. In this function, the worker context is used
for the checking. The context will be set in a variable in the
beginning of first event handling. usbip_in_eh() is used in event
handler so it works well.
3. Modifications to programs using usbip_event.c
Initialization and termination of workqueue are added to init and exit
routine of usbip_core respectively.
A. version info
v2)
build fail at 1/2 casued unmodified user programs in 1/2.
Hidehiro Kawai [Mon, 14 Dec 2015 10:19:13 +0000 (11:19 +0100)]
x86/nmi: Save regs in crash dump on external NMI
Now, multiple CPUs can receive an external NMI simultaneously by
specifying the "apic_extnmi=all" command line parameter. When we take
a crash dump by using external NMI with this option, we fail to save
registers into the crash dump. This happens as follows:
CPU 0 CPU 1
================================ =============================
receive an external NMI
default_do_nmi() receive an external NMI
spin_lock(&nmi_reason_lock) default_do_nmi()
io_check_error() spin_lock(&nmi_reason_lock)
panic() busy loop
...
kdump_nmi_shootdown_cpus()
issue NMI IPI -----------> blocked until IRET
busy loop...
Here, since CPU 1 is in NMI context, an additional NMI from CPU 0
remains unhandled until CPU 1 IRETs. However, CPU 1 will never execute
IRET so the NMI is not handled and the callback function to save
registers is never called.
To solve this issue, we check if the IPI for crash dumping was issued
while waiting for nmi_reason_lock to be released, and if so, call its
callback function directly. If the IPI is not issued (e.g. kdump is
disabled), the actual behavior doesn't change.
Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> Acked-by: Michal Hocko <mhocko@suse.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Baoquan He <bhe@redhat.com> Cc: Dave Young <dyoung@redhat.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: kexec@lists.infradead.org Cc: linux-doc@vger.kernel.org Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stefan Lippers-Hollmann <s.l-h@gmx.de> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: x86-ml <x86@kernel.org> Link: http://lkml.kernel.org/r/20151210065245.4587.39316.stgit@softrs Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit b279d67df88a49c6ca32b3eebd195660254be394)
This ensures that do_mmap() won't implicitly make AIO memory mappings
executable if the READ_IMPLIES_EXEC personality flag is set. Such
behavior is problematic because the security_mmap_file LSM hook doesn't
catch this case, potentially permitting an attacker to bypass a W^X
policy enforced by SELinux.
Eric W. Biederman [Mon, 29 Jun 2015 19:42:03 +0000 (14:42 -0500)]
vfs: Commit to never having exectuables on proc and sysfs.
Today proc and sysfs do not contain any executable files. Several
applications today mount proc or sysfs without noexec and nosuid and
then depend on there being no exectuables files on proc or sysfs.
Having any executable files show on proc or sysfs would cause
a user space visible regression, and most likely security problems.
Therefore commit to never allowing executables on proc and sysfs by
adding a new flag to mark them as filesystems without executables and
enforce that flag.
Test the flag where MNT_NOEXEC is tested today, so that the only user
visible effect will be that exectuables will be treated as if the
execute bit is cleared.
The filesystems proc and sysfs do not currently incoporate any
executable files so this does not result in any user visible effects.
This makes it unnecessary to vet changes to proc and sysfs tightly for
adding exectuable files or changes to chattr that would modify
existing files, as no matter what the individual file say they will
not be treated as exectuable files by the vfs.
Not having to vet changes to closely is important as without this we
are only one proc_create call (or another goof up in the
implementation of notify_change) from having problematic executables
on proc. Those mistakes are all too easy to make and would create
a situation where there are security issues or the assumptions of
some program having to be broken (and cause userspace regressions).
Tejun Heo [Tue, 16 Jun 2015 22:48:31 +0000 (18:48 -0400)]
vfs, writeback: replace FS_CGROUP_WRITEBACK with SB_I_CGROUPWB
FS_CGROUP_WRITEBACK indicates whether a file_system_type supports
cgroup writeback; however, different super_blocks of the same
file_system_type may or may not support cgroup writeback depending on
filesystem options. This patch replaces FS_CGROUP_WRITEBACK with a
per-super_block flag.
super_block->s_flags carries some internal flags in the high bits but
it's exposd to userland through uapi header and running out of space
anyway. This patch adds a new field super_block->s_iflags to carry
kernel-internal flags. It is currently only used by the new
SB_I_CGROUPWB flag whose concatenated and abbreviated name is for
consistency with other super_block flags.
ext2_fill_super() is updated to set SB_I_CGROUPWB.
v2: Added super_block->s_iflags instead of stealing another high bit
from sb->s_flags as suggested by Christoph and Jan.
Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: linux-fsdevel@vger.kernel.org Cc: Christoph Hellwig <hch@infradead.org> Cc: Jan Kara <jack@suse.cz> Cc: linux-ext4@vger.kernel.org Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@fb.com>
(cherry picked from commit 46b15caa7cb19b0f6e3bc8ebaee5bc1bb2e35110)
krobot warning: make sure that all error return paths release locks.
Signed-off-by: Gary R Hook <gary.hook@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 30b4c54ccdebfc5a0210d9a4d77cc3671c9d1576) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
Expose some data about the configuration and operation of the CCP
through debugfs entries: device name, capabilities, configuration,
statistics.
Allow the user to reset the counters to zero by writing (any value)
to the 'stats' file. This can be done per queue or per device.
Changes from V1:
- Correct polarity of test when destroying devices at module unload
Signed-off-by: Gary R Hook <gary.hook@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 3cdbe346ed3f380eae1cb3e9febfe703e7d8a7b0) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
projects / users / jedix / linux-maple.git / log