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
CVE-2016-3070
Signed-off-by: Luis Henriques <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>
365318c...
by
Benjamin Tissoires <email address hidden>
Plugging a Logitech DJ receiver with KASAN activated raises a bunch of
out-of-bound readings.
The fields are allocated up to MAX_USAGE, meaning that potentially, we do
not have enough fields to fit the incoming values.
Add checks and silence KASAN.
Signed-off-by: Benjamin Tissoires <email address hidden>
Signed-off-by: Jiri Kosina <email address hidden>
(cherry picked from commit 50220dead1650609206efe91f0cc116132d59b3f)
Signed-off-by: Kamal Mostafa <email address hidden>
Acked-by: Andy Whitcroft <email address hidden>
Acked-by: Tim Gardner <email address hidden>
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
moksbstate_disabled==0.
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.
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.
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.
UEFI Secure Boot provides a mechanism for ensuring that the firmware will
only load signed bootloaders and kernels. Certain use cases may also
require that all kernel modules also be signed. Add a configuration option
that enforces this automatically when enabled.
Signed-off-by: Matthew Garrett <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>
