lp:~mhcerri/ubuntu/+source/linux/+git/bionic

Owned by Marcelo Cerri
Get this repository:
git clone https://git.launchpad.net/~mhcerri/ubuntu/+source/linux/+git/bionic
Only Marcelo Cerri can upload to this repository. If you are Marcelo Cerri please log in for upload directions.

Branches

Name Last Modified Last Commit
azure-4.15-fsgsbase 2020-05-07 15:21:13 UTC 2020-05-07
UBUNTU: SAUCE: x86/elf: Enumerate kernel FSGSBASE capability in AT_HWCAP2

Author: Andi Kleen
Author Date: 2019-10-04 18:16:08 UTC

UBUNTU: SAUCE: x86/elf: Enumerate kernel FSGSBASE capability in AT_HWCAP2

BugLink: http://bugs.launchpad.net/bugs/1877425

The kernel needs to explicitly enable FSGSBASE. So, the application needs
to know if it can safely use these instructions. Just looking at the CPUID
bit is not enough because it may be running in a kernel that does not
enable the instructions.

One way for the application would be to just try and catch the SIGILL.
But that is difficult to do in libraries which may not want to overwrite
the signal handlers of the main application.

Enumerate the enabled FSGSBASE capability in bit 1 of AT_HWCAP2 in the ELF
aux vector. AT_HWCAP2 is already used by PPC for similar purposes.

The application can access it open coded or by using the getauxval()
function in newer versions of glibc.

Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>

lp1848739 2019-12-13 18:18:16 UTC 2019-12-13
blk-mq: punt failed direct issue to dispatch list

Author: axboe
Author Date: 2019-11-27 20:18:20 UTC

blk-mq: punt failed direct issue to dispatch list

BugLink: https://bugs.launchpad.net/bugs/1848739

After the direct dispatch corruption fix, we permanently disallow direct
dispatch of non read/write requests. This works fine off the normal IO
path, as they will be retried like any other failed direct dispatch
request. But for the blk_insert_cloned_request() that only DM uses to
bypass the bottom level scheduler, we always first attempt direct
dispatch. For some types of requests, that's now a permanent failure,
and no amount of retrying will make that succeed. This results in a
livelock.

Instead of making special cases for what we can direct issue, and now
having to deal with DM solving the livelock while still retaining a BUSY
condition feedback loop, always just add a request that has been through
->queue_rq() to the hardware queue dispatch list. These are safe to use
as no merging can take place there. Additionally, if requests do have
prepped data from drivers, we aren't dependent on them not sharing space
in the request structure to safely add them to the IO scheduler lists.

This basically reverts ffe81d45322c and is based on a patch from Ming,
but with the list insert case covered as well.

Fixes: ffe81d45322c ("blk-mq: fix corruption with direct issue")
Cc: stable@vger.kernel.org
Suggested-by: Ming Lei <ming.lei@redhat.com>
Reported-by: Bart Van Assche <bvanassche@acm.org>
Tested-by: Ming Lei <ming.lei@redhat.com>
Acked-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit c616cbee97aed4bc6178f148a7240206dcdb85a6)
Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>

12 of 2 results
This repository contains Public information 
Everyone can see this information.

Subscribers