Last commit made on 2016-07-15
Get this branch:
git clone -b wily https://git.launchpad.net/~tuxonice/linux
Members of TuxOnIce can upload to this branch. Log in for directions.

Branch merges

Branch information


Recent commits

164c215... by Martin Schläffer

Merge tag 'Ubuntu-4.2.0-42.49'

0e42b32... by Ben Romer

UBUNTU: Ubuntu-4.2.0-42.49

Signed-off-by: Benjamin M Romer <email address hidden>

c38debc... by Stefan Bader

UBUNTU: [Config] Add pm80xx scsi driver to d-i

This will add debian installer support for the Adaptec PMC-Sierra SAS
HBA controller.

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

Signed-off-by: Stefan Bader <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Andy Whitcroft <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>

7a53462... by Hugh Dickins <email address hidden>

mm: migrate dirty page without clear_page_dirty_for_io etc

commit 42cb14b110a5698ccf26ce59c4441722605a3743 upstream.

clear_page_dirty_for_io() has accumulated writeback and memcg subtleties
since v2.6.16 first introduced page migration; and the set_page_dirty()
which completed its migration of PageDirty, later had to be moderated to
__set_page_dirty_nobuffers(); then PageSwapBacked had to skip that too.

No actual problems seen with this procedure recently, but if you look into
what the clear_page_dirty_for_io(page)+set_page_dirty(newpage) is actually
achieving, it turns out to be nothing more than moving the PageDirty flag,
and its NR_FILE_DIRTY stat from one zone to another.

It would be good to avoid a pile of irrelevant decrementations and
incrementations, and improper event counting, and unnecessary descent of
the radix_tree under tree_lock (to set the PAGECACHE_TAG_DIRTY which
radix_tree_replace_slot() left in place anyway).

Do the NR_FILE_DIRTY movement, like the other stats movements, while
interrupts still disabled in migrate_page_move_mapping(); and don't even
bother if the zone is the same. Do the PageDirty movement there under
tree_lock too, where old page is frozen and newpage not yet visible:
bearing in mind that as soon as newpage becomes visible in radix_tree, an
un-page-locked set_page_dirty() might interfere (or perhaps that's just
not possible: anything doing so should already hold an additional
reference to the old page, preventing its migration; but play safe).

But we do still need to transfer PageDirty in migrate_page_copy(), for
those who don't go the mapping route through migrate_page_move_mapping().

Signed-off-by: Hugh Dickins <email address hidden>
Cc: Christoph Lameter <email address hidden>
Cc: "Kirill A. Shutemov" <email address hidden>
Cc: Rik van Riel <email address hidden>
Cc: Vlastimil Babka <email address hidden>
Cc: Davidlohr Bueso <email address hidden>
Cc: Oleg Nesterov <email address hidden>
Cc: Sasha Levin <email address hidden>
Cc: Dmitry Vyukov <email address hidden>
Cc: KOSAKI Motohiro <email address hidden>
Signed-off-by: Andrew Morton <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
[bwh: Backported to 3.16: adjust context. This is not just an optimisation,
 but turned out to fix a possible oops (CVE-2016-3070).]
Signed-off-by: Ben Hutchings <email address hidden>

BugLink: https://bugs.launchpad.net/bugs/1581865
Signed-off-by: Luis Henriques <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>

0594d45... by Tim Gardner

Revert "perf test: Ignore kcore files in the "vmlinux matches kallsyms" test"

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

This reverts commit 159436d273a248e99f05dcd15f39e2c6bdb02652.

Causes an FTBS.

tests/vmlinux-kallsyms.c: In function 'test__vmlinux_matches_kallsyms':
tests/vmlinux-kallsyms.c:64:6: error: implicit declaration of function '__machine__load_kallsyms' [-Werror=implicit-function-declaration]
  if (__machine__load_kallsyms(&kallsyms, "/proc/kallsyms", type, true, NULL) <= 0) {
tests/vmlinux-kallsyms.c:64:2: error: nested extern declaration of '__machine__load_kallsyms' [-Werror=nested-externs]
  if (__machine__load_kallsyms(&kallsyms, "/proc/kallsyms", type, true, NULL) <= 0) {
cc1: all warnings being treated as errors

Signed-off-by: Tim Gardner <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>

c6994d5... by Tim Gardner

UBUNTU: SAUCE: UEFI: Add secure boot and MOK SB State disabled sysctl

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

This is a better method for detecting the state of secure boot and
the MOKSBState override, as opposed to grepping status from the kernel log.
Both variables return 0 or 1. If secure_boot==0 then signed module
enforcement is not enabled. Likewise, if moksbstate_disabled==1 then
signed module enforcement is not enabled. The only conditions uder which
signed module enforcement is enabled is when secure_boot==1 and


Signed-off-by: Tim Gardner <email address hidden>

1d873a3... by Tim Gardner

UBUNTU: SAUCE: UEFI: Display MOKSBState when disabled

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

It would be much simpler if one could pass MOKSBState via a global variable,
but the the EFI bits appear to be managed and linked a bit differently then
a normal text section. Hence the shennanigans with boot_params.secure_boot.

Signed-off-by: Tim Gardner <email address hidden>

1b1045d... by Josh Boyer <email address hidden>

UBUNTU: SAUCE: UEFI: efi: Disable secure boot if shim is in insecure mode

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

A user can manually tell the shim boot loader to disable validation of
images it loads. When a user does this, it creates a UEFI variable called
MokSBState that does not have the runtime attribute set. Given that the
user explicitly disabled validation, we can honor that and not enable
secure boot mode if that variable is set.

Signed-off-by: Josh Boyer <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>

0ab73ca... by Josh Boyer <email address hidden>

UBUNTU: SAUCE: UEFI MODSIGN: Import certificates from UEFI Secure Boot

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

Secure Boot stores a list of allowed certificates in the 'db' variable.
This imports those certificates into the system trusted keyring. This
allows for a third party signing certificate to be used in conjunction
with signed modules. By importing the public certificate into the 'db'
variable, a user can allow a module signed with that certificate to
load. The shim UEFI bootloader has a similar certificate list stored
in the 'MokListRT' variable. We import those as well.

In the opposite case, Secure Boot maintains a list of disallowed
certificates in the 'dbx' variable. We load those certificates into
the newly introduced system blacklist keyring and forbid any module
signed with those from loading.

Signed-off-by: Josh Boyer <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>

bb605a2... by Josh Boyer <email address hidden>


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

The functionality of the config option is dependent upon the platform being
UEFI based. Reflect this in the config deps.

Signed-off-by: Josh Boyer <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>