With CONFIG_LTO_CLANG, clang generates LLVM IR instead of ELF object
files. As empty.o is used for probing target properties, disable LTO
for it to produce an object file instead.
Bug: 145210207
Change-Id: I618d8b86ed88ad048abdee3c541ced19d12982c0
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
With CONFIG_LTO_CLANG enabled, LLVM IR won't be compiled into object
files until modpost_link. This change postpones calls to recordmcount
until after this step.
In order to exclude ftrace_process_locs from inspection, we add a new
code section .text..ftrace, which we tell recordmcount to ignore, and
a __norecordmcount attribute for moving functions to this section.
Bug: 145210207
Change-Id: Ib77f7c431fce54243c46d584b55761ed2342965c
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
This change adds the configuration option CONFIG_LTO_CLANG, and
build system support for Clang's Link Time Optimization (LTO). In
preparation for LTO support with other compilers, potentially common
parts of the changes are gated behind CONFIG_LTO instead.
With -flto, instead of object files, Clang produces LLVM bitcode,
which is compiled into a native object at link time, allowing the
final binary to be optimized globally. For more details, see:
https://llvm.org/docs/LinkTimeOptimization.html
While the kernel normally uses GNU ld for linking, LLVM supports LTO
only with LLD or GNU gold linkers. This change assumes LLD is used.
Bug: 145210207
Change-Id: If1164ff33d073358ee7d4bba84cbb06c349c4a88
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Similarly to the CC_IS_CLANG config, add LD_IS_LLD to simplify feature
selection based on the linker.
Bug: 145210207
Change-Id: I097c52899dcf9829eb0e1ea89211b17972301c1a
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
platform_find_device_by_driver calls bus_find_device and passes
platform_match as the callback function. Casting the function to a
mismatching type trips indirect call Control-Flow Integrity (CFI) checking.
This change adds a callback function with the correct type and instead
of casting the function, explicitly casts the second parameter to struct
device_driver* as expected by platform_match.
Bug: 145210207
Change-Id: Idef667974d3c54ebd79f0813531cf2523d651dfe
(cherry picked from commit 492c88720d36eb662f9f10c1633f7726fbb07fc4
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
driver-core-next)
Fixes: 36f3313d6b ("platform: Add platform_find_device_by_driver() helper")
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191112214156.3430-1-samitolvanen@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Filter out CC_FLAGS_SCS for code that runs at a different exception
level.
Bug: 145210207
Change-Id: I834424fba7aa18598b618891814327ecc2841c6e
(am from https://lore.kernel.org/patchwork/patch/1149062/)
Suggested-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Shadow stacks are only available in the kernel, so disable SCS
instrumentation for the vDSO.
Bug: 145210207
Change-Id: Id894b77112801c00a44bcc539cc3882b5f72b251
(am from https://lore.kernel.org/patchwork/patch/1149061/)
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
If we detect a corrupted x18 and SCS is enabled, restore the register
before jumping back to instrumented code. This is safe, because the
wrapper is called with preemption disabled and a separate shadow stack
is used for interrupt handling.
Bug: 145210207
Change-Id: Idb75117e38c895231a14f5573261861e722c1264
(am from https://lore.kernel.org/patchwork/patch/1149060/)
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Don't lose the current task's shadow stack when the CPU is suspended.
Bug: 145210207
Change-Id: I8db58daadcc15a00a6f585580a3c97905c678eb3
(am from https://lore.kernel.org/patchwork/patch/1149059/)
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Reserve the x18 register from general allocation when SCS is enabled,
because the compiler uses the register to store the current task's
shadow stack pointer. Note that all external kernel modules must also be
compiled with -ffixed-x18 if the kernel has SCS enabled.
Bug: 145210207
Change-Id: I0407d38a0a5ecb6852b3f281d52f6601c565157e
(am from https://lore.kernel.org/patchwork/patch/1149058/)
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
The graph tracer hooks returns by modifying frame records on the
(regular) stack, but with SCS the return address is taken from the
shadow stack, and the value in the frame record has no effect. As we
don't currently have a mechanism to determine the corresponding slot
on the shadow stack (and to pass this through the ftrace
infrastructure), for now let's disable the graph tracer when SCS is
enabled.
Bug: 145210207
Change-Id: I65dd098be827121ecf0c08538b11e3b98f5eacde
(am from https://lore.kernel.org/patchwork/patch/1149057/)
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Implements CONFIG_DEBUG_STACK_USAGE for shadow stacks. When enabled,
also prints out the highest shadow stack usage per process.
Bug: 145210207
Change-Id: I2b2fea68760ca8d94d6f887cfe5828883d233b88
(am from https://lore.kernel.org/patchwork/patch/1149056/)
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
This change adds accounting for the memory allocated for shadow stacks.
Bug: 145210207
Change-Id: Iee94c22abefcabb63a3bcd4db8ba952130f30a82
(am from https://lore.kernel.org/patchwork/patch/1149055/)
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
This change adds generic support for Clang's Shadow Call Stack,
which uses a shadow stack to protect return addresses from being
overwritten by an attacker. Details are available here:
https://clang.llvm.org/docs/ShadowCallStack.html
Note that security guarantees in the kernel differ from the
ones documented for user space. The kernel must store addresses
of shadow stacks used by other tasks and interrupt handlers in
memory, which means an attacker capable reading and writing
arbitrary memory may be able to locate them and hijack control
flow by modifying shadow stacks that are not currently in use.
Bug: 145210207
Change-Id: I2a8ba6a3decac50c169731c3121c9dcab96621d2
(am from https://lore.kernel.org/patchwork/patch/1149054/)
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
The code in __cpu_soft_restart() uses x18 as an arbitrary temp register,
which will shortly be disallowed. So use x8 instead.
Bug: 145210207
Change-Id: Iad10392005b66e6bf3a0f00c40024448e9798b89
(am from https://lore.kernel.org/patchwork/patch/1149053/)
Link: https://patchwork.kernel.org/patch/9836877/
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
[Sami: updated commit message]
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
In preparation of reserving x18, stop treating it as caller save in
the KVM guest entry/exit code. Currently, the code assumes there is
no need to preserve it for the host, given that it would have been
assumed clobbered anyway by the function call to __guest_enter().
Instead, preserve its value and restore it upon return.
Bug: 145210207
Change-Id: I341bcb10b615999a59a8413a6b98cb2ce1c62e02
(am from https://lore.kernel.org/patchwork/patch/1149065/)
Link: https://patchwork.kernel.org/patch/9836891/
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
[Sami: updated commit message, switched from x18 to x29 for the guest context]
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Register x18 will no longer be used as a caller save register in the
future, so stop using it in the copy_page() code.
Bug: 145210207
Change-Id: Iffd77db101d6e83ec8c5e12b11d9f0fef09a630b
(am from https://lore.kernel.org/patchwork/patch/1149064/)
Link: https://patchwork.kernel.org/patch/9836869/
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
[Sami: changed the offset and bias to be explicit]
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
idmap_kpti_install_ng_mappings uses x18 as a temporary register, which
will result in a conflict when x18 is reserved. Use x16 and x17 instead
where needed.
Bug: 145210207
Change-Id: I9fbf40769c5c241422fff8558c7a9bade8ebadb6
(am from https://lore.kernel.org/patchwork/patch/1149052/)
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Leaf changes summary: 4 artifacts changed
Changed leaf types summary: 4 leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
'struct pwm_args at pwm.h:41:1' changed:
type size changed from 64 to 128 (in bits)
there are data member changes:
type 'unsigned int' of 'pwm_args::period' changed:
entity changed from 'unsigned int' to compatible type 'typedef u64' at int-ll64.h:23:1
type size changed from 32 to 64 (in bits)
, size changed from 32 to 64 (in bits) (by +32 bits)
'pwm_polarity pwm_args::polarity' offset changed from 32 to 64 (in bits) (by +32 bits)
19 impacted interfaces:
[...]
'struct pwm_capture at pwm.h:335:1' changed:
type size changed from 64 to 128 (in bits)
there are data member changes:
type 'unsigned int' of 'pwm_capture::period' changed:
entity changed from 'unsigned int' to compatible type 'typedef u64' at int-ll64.h:23:1
type size changed from 32 to 64 (in bits)
, size changed from 32 to 64 (in bits) (by +32 bits)
type 'unsigned int' of 'pwm_capture::duty_cycle' changed:
entity changed from 'unsigned int' to compatible type 'typedef u64' at int-ll64.h:23:1
type size changed from 32 to 64 (in bits)
, offset changed from 32 to 64 (in bits) (by +32 bits), size changed from 32 to 64 (in bits) (by +32 bits)
19 impacted interfaces:
[...]
'struct pwm_device at pwm.h:88:1' changed:
type size changed from 576 to 704 (in bits)
there are data member changes:
type 'struct pwm_args' of 'pwm_device::args' changed as reported earlier
and size changed from 64 to 128 (in bits) (by +64 bits)
type 'struct pwm_state' of 'pwm_device::state' changed:
, offset changed from 384 to 448 (in bits) (by +64 bits), size changed from 160 to 256 (in bits) (by +96 bits)
19 impacted interfaces:
[...]
'struct pwm_state at pwm.h:69:1' changed:
type size changed from 160 to 256 (in bits)
there are data member changes:
type 'unsigned int' of 'pwm_state::period' changed:
entity changed from 'unsigned int' to compatible type 'typedef u64' at int-ll64.h:23:1
type size changed from 32 to 64 (in bits)
, size changed from 32 to 64 (in bits) (by +32 bits)
type 'unsigned int' of 'pwm_state::duty_cycle' changed:
entity changed from 'unsigned int' to compatible type 'typedef u64' at int-ll64.h:23:1
type size changed from 32 to 64 (in bits)
, offset changed from 32 to 64 (in bits) (by +32 bits), size changed from 32 to 64 (in bits) (by +32 bits)
'pwm_polarity pwm_state::polarity' offset changed from 64 to 128 (in bits) (by +64 bits)
'pwm_output_type pwm_state::output_type' offset changed from 96 to 160 (in bits) (by +64 bits)
'bool pwm_state::enabled' offset changed from 128 to 192 (in bits) (by +64 bits)
19 impacted interfaces:
[...]
Fixes: 0453f563cc ("FROMLIST: pwm: Convert period and duty cycle to u64")
Change-Id: I84a0b3ad7d7798ab3d00d3f45a9eb5b20cea04a9
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Because period and duty cycle are defined as ints with units of
nanoseconds, the maximum time duration that can be set is limited to
~2.147 seconds. Change their definitions to u64 in the structs of the
PWM framework so that higher durations may be set.
Also make the relevant fixes to those drivers that use the period and
duty_cycle struct members in division operations, viz. replacing the
division operations with 64-bit division macros as appropriate.
Bug: 140290586
Change-Id: Ibb8c7f007f4c11ebf8cf01e7a468cc9c29aa8b23
Link: https://www.spinics.net/lists/linux-pwm/msg11133.html
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Reported-by: kbuild test robot <lkp@intel.com>
Set the default for FW_CACHE to n to match Android expectations.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 32180327
Bug: 137566496
Change-Id: I86a28040be07fb2f30125d28f7f379798727785c
(cherry picked from commit 8331ce00073074134a283a72a5731cb4689a28e6)
Because firmware caching generates uevent messages that are sent over
a netlink socket, it can prevent suspend on many platforms. It's
also not always useful, so make it a configurable option.
Signed-off-by: Mark Salyzyn <salyzyn@android.com>
Cc: Tim Murray <timmurray@google.com>
Cc: Venkata Narendra Kumar Gutta <vnkgutta@codeaurora.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: linux-kernel@vger.kernel.org
Cc: kernel-team@android.com
Acked-by: Luis Chamberlain <mcgrof@kernel.org>
Link: https://lore.kernel.org/r/20191113225429.118495-1-salyzyn@android.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c74f8056621738f5be9f5d3d7e0caa927b21aef6 git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-testing)
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 32180327
Bug: 137566496
Change-Id: I1250512b27edb56caa78d536e5ccf1fb669476ad
(cherry picked from commit cd403ef6a75c38bc126b1b7f2362ab6426062df0)
I no longer work for Arm, so update the stale reference to my old email
address.
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-15-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I7676e5f736fcb31376444bbfee419bc49ef17287
By conditionally dropping support for the legacy binding and exporting
the newly introduced 'arm_smmu_impl_init()' function we can allow the
ARM SMMU driver to be built as a module.
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-14-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Id42da5829cb180966a0d051ec636be0c9f90efed
When removing the SMMU driver, we need to clear any state that we
registered during probe. This includes our bus ops, sysfs entries and
the IOMMU device registered for early firmware probing of masters.
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-13-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I5dd6e68a609ac60bc704f9f916acc0f31dc1bd67
By removing the redundant call to 'pci_request_acs()' we can allow the
ARM SMMUv3 driver to be built as a module.
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-12-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I1d8fbe26ab7114af6409ea13a68fff8afed49703
When removing the SMMUv3 driver, we need to clear any state that we
registered during probe. This includes our bus ops, sysfs entries and
the IOMMU device registered for early firmware probing of masters.
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-11-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I54372d917c871231ced86250498fe2e45cf39246
Forcefully unbinding the Arm SMMU drivers is a pretty dangerous operation,
since it will likely lead to catastrophic failure for any DMA devices
mastering through the SMMU being unbound. When the driver then attempts
to "handle" the fatal faults, it's very easy to trip over dead data
structures, leading to use-after-free.
On John's machine, he reports that the machine was "unusable" due to
loss of the storage controller following a forced unbind of the SMMUv3
driver:
| # cd ./bus/platform/drivers/arm-smmu-v3
| # echo arm-smmu-v3.0.auto > unbind
| hisi_sas_v2_hw HISI0162:01: CQE_AXI_W_ERR (0x800) found!
| platform arm-smmu-v3.0.auto: CMD_SYNC timeout at 0x00000146
| [hwprod 0x00000146, hwcons 0x00000000]
Prevent this forced unbinding of the drivers by setting "suppress_bind_attrs"
to true.
Link: https://lore.kernel.org/lkml/06dfd385-1af0-3106-4cc5-6a5b8e864759@huawei.com
Reported-by: John Garry <john.garry@huawei.com>
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-10-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I8b1c439f7ba11d6fc38cdf686948ef5909871dfb
This reverts commit addb672f20.
Let's get the SMMU driver building as a module, which means putting
back some dead code that we used to carry.
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-9-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I9779ffa7befa8535a0d7196ef5f728e40ae7d7f7
This reverts commit c07b6426df.
Let's get the SMMUv3 driver building as a module, which means putting
back some dead code that we used to carry.
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-8-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Ifde3c5dc81a0db600532b305906c67aa065d2f47
'bus_set_iommu()' allows IOMMU drivers to register their ops for a given
bus type. Unfortunately, it then doesn't allow them to be removed, which
is necessary for modular drivers to shutdown cleanly so that they can be
reloaded later on.
Allow 'bus_set_iommu()' to take a NULL 'ops' argument, which clear the
ops pointer for the selected bus_type.
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-7-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Ia89fa2df61d2a9ad04901d4c2e71e293c4c6171d
Ensure that we hold a reference to the IOMMU driver module while calling
the '->of_xlate()' callback during early device probing.
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-6-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Ica9ef2d5ed172c2451c0a19538dc28852c2270d5
To avoid accidental removal of an active IOMMU driver module, take a
reference to the driver module in 'iommu_probe_device()' immediately
prior to invoking the '->add_device()' callback and hold it until the
after the device has been removed by '->remove_device()'.
Suggested-by: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-5-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I8f6a8aad8c41faa51df9c3a440c8b80c74e3ce8a
Building drivers for ATS-aware IOMMUs as modules requires access to
pci_ats_disabled(). Export it as a GPL symbol to get things working.
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-4-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Ia5457fd6c4593565799b97f40c0def3558a97696
To avoid having to export 'pci_request_acs()' to modular IOMMU drivers,
move the call into the 'of_dma_configure()' path in a similar manner to
the way in which ACS is configured when probing via ACPI/IORT.
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-3-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I3c689845ca493fbe037a2def2050a089036fb7d3
Building IOMMU drivers as modules requires that the core IOMMU API
symbols are exported as GPL symbols.
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-2-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Ic1b3b5e6e92c5852af1e3473dd230c506b8d7865
Commit 8e12257dead7 ("of: property: Add device link support for iommus,
mboxes and io-channels") added device link support for IOMMU linkages
described using the "iommus" property. For PCI devices, this property
is not present and instead the "iommu-map" property is used on the host
bridge node to map the endpoint RequesterIDs to their corresponding
IOMMU instance.
Add support for "iommu-map" to the device link supplier bindings so that
probing of PCI devices can be deferred until after the IOMMU is
available.
Cc: Rob Herring <robh@kernel.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Acked-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20191120190028.4722-1-will@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry-picked from commit e149573b2f84d0517648dafc0db625afa681ed54
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-next)
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Ife0cf1ed0256af47ed0cae7156f3184de355c42c
Pull cramfs fix from Al Viro:
"Regression fix, fallen through the cracks"
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
cramfs: fix usage on non-MTD device
