We introduced setname ioctl in commit bb2bb90304 ("dma-buf:
add DMA_BUF_SET_NAME ioctls") that provides userpsace
to attach a free-form name for tracking and counting shared
buffers. However the d_dname callback could be called in atomic
context. This call path comes from selinux that verifies all
inherited open files from exec call. To verify all inherited
open files, kernel would iterate all fds which need to hold
spin_lock to get denty name by calling d_dname operation.
In dma-buf d_dname callback, we use mutex lock to prevent the
race from setname causing this issue.
This commit adds a spinlock to protect set/get name operation
to fix this issue.
[ 165.617090] Call trace:
[ 165.620504] ___might_sleep+0x114/0x118
[ 165.625344] __might_sleep+0x50/0x84
[ 165.629928] __mutex_lock_common+0x5c/0x10b0
[ 165.635215] mutex_lock_nested+0x40/0x50
[ 165.640157] dmabuffs_dname+0x48/0xdc
[ 165.644821] d_path+0x78/0x1e4
[ 165.648870] audit_log_d_path+0x68/0x134
[ 165.653807] common_lsm_audit+0x33c/0x6f4
[ 165.658832] slow_avc_audit+0xb4/0xf0
[ 165.663503] avc_has_perm+0xdc/0x1a4
[ 165.668081] file_has_perm+0x70/0x154
[ 165.672750] match_file+0x54/0x6c
[ 165.677064] iterate_fd+0x74/0xac
[ 165.681369] selinux_bprm_committing_creds+0xfc/0x210
[ 165.687459] security_bprm_committing_creds+0x2c/0x40
[ 165.693546] install_exec_creds+0x1c/0x68
[ 165.698569] load_elf_binary+0x3a0/0x13c8
[ 165.703590] search_binary_handler+0xb8/0x1e4
[ 165.708964] __do_execve_file+0x6e4/0x9c8
[ 165.713984] __arm64_sys_execve+0x44/0x54
[ 165.719008] el0_svc_common+0xa8/0x168
[ 165.723765] el0_svc_handler+0x78/0x94
[ 165.728522] el0_svc+0x8/0xc
Signed-off-by: Martin Liu <liumartin@google.com>
[surenb: cherry-picked and backported from:
https://lkml.org/lkml/2020/1/14/799
Conflicts:
drivers/dma-buf/dma-buf.c
1. Resolved diffs between 4.19 and upstream by replacing dma_resv_lock
with dmabuf->lock
]
Bug: 150611569
Test: build
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ia0b20a40d491eb41b8844d05dc86dfd6039de07f
Allow kernel clients to get the flags associated with a buffer
that is wrapped by a dma-buf. This information can be used to
communicate the type of memory associated with the
buffer(e.g. uncached vs cached memory).
Bug: 133508579
Test: ion-unit-tests
Change-Id: I82eab8beb738b258616c22a01080615d7ffb6ad5
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Signed-off-by: Sandeep Patil <sspatil@google.com>
[surenb: cherry-picked from ACK 5.4 branch]
Bug: 150611569
Test: build
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I6f094f625f38b363fe7815bb5b0ab33273a4a3a5
When mapping the memory represented by a dma-buf into a device's
address space, it might be desireable to map the memory with
certain DMA attributes. Thus, introduce the dma_mapping_attrs
field in the dma_buf_attachment structure so that when
the memory is mapped with dma_buf_map_attachment, it is mapped
with the desired DMA attributes.
Bug: 133508579
Test: ion-unit-tests
Change-Id: Ib2e5bafdc02ae31a58ce96a82d77cc508dd71bd4
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Signed-off-by: Sandeep Patil <sspatil@google.com>
[surenb: cherry-picked from ACK 5.4 branch]
Bug: 150611569
Test: build
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I9a8b4f83a61bcff6e5d3ee2d7f4887875a9654ef
In order to improve performance, allow dma-buf clients to
apply cache maintenance to only a subset of a dma-buf.
Kernel clients will be able to use the dma_buf_begin_cpu_access_partial
and dma_buf_end_cpu_access_partial functions to only apply cache
maintenance to a range within the dma-buf.
Bug: 133508579
Test: ion-unit-tests
Change-Id: Icce61fc21b1542f5248daea34f713184449a62c3
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Signed-off-by: Sandeep Patil <sspatil@google.com>
[surenb: cherry-picked from ACK 5.4 branch]
Bug: 150611569
Test: build
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I453e69fa792508c367fb03a8d543ee42254e7138
Currently the removed_dma_ops are set only once for dev nodes
which are associated with a reserved-memory region (PIL devices)
in device_init and when the probe of these devices fail,
we end up calling dma_deconfigure which sets the dma_ops to NULL.
Eventually when the probe succeeds, since dma_ops was set to
NULL during probe failure, we end up setting dma_ops to
arm64_swiotlb_dma_ops. Hence in arch_setup_dma_ops, if the
dma_ops is NULL, check to see if there is a reserved memory
associated with the dev and if so set dma_ops to removed_dma_ops
such that the right callback functions are invoked.
Bug: 145617272
Signed-off-by: Swathi Sridhar <swatsrid@codeaurora.org>
[surenb: cherry picked from commit:
903192a5412d "mm: Support setting removed_dma_ops in arch_setup_dma_ops"]
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ibc1028391ba90cbdd5c5826022b5015d9e261c09
The current DMA coherent pool assumes that there is a kernel
mapping at all times for the entire pool. This may not be
what we want for the entire times. Add the dma_removed ops to
support this use case.
Bug: 145617272
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
Signed-off-by: Liam Mark <lmark@codeaurora.org>
Signed-off-by: Swathi Sridhar <swatsrid@codeaurora.org>
[surenb Squashed the following commits:
a478a8bf78ad "drivers: Add dma removed ops"
8510985ae320 "dma: removed: Merge dma removed changes from 4.14"
and removed-dma-pool driver changes from
9d4b7d641556 "iommu: arm-smmu: Merge for ..."]
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ie4f1e9bdf57b79699fa8fa7e7a6087e6d88ebbfa
Trimmed down version of:
4008eb493aa2 "iommu/arm-smmu: Merge of smmu changes from 4.14"
which includes only changes required for removed-dma-pool driver.
Bug: 145617272
Signed-off-by: Swathi Sridhar <swatsrid@codeaurora.org>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I4b9ae665aaf8aabf89c3b158bc38db458f31657a
Enables us to catch build-breaks for 32-bit ARM with an allmodconfig
build in continuous integration testing.
Bug: 151459448
Change-Id: I825a18771c214e6389fc2755fce20c8fc2531695
Signed-off-by: Alistair Delva <adelva@google.com>
Leaf changes summary: 3 artifacts changed
Changed leaf types summary: 3 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 module at module.h:331:1' changed:
type size hasn't changed
2 data member insertions:
'jump_entry* module::jump_entries', at offset 5632 (in bits) at module.h:444:1
'unsigned int module::num_jump_entries', at offset 5696 (in bits) at module.h:445:1
there are data member changes:
'unsigned int module::num_trace_bprintk_fmt' offset changed from 5632 to 5728 (in bits) (by +96 bits)
'const char** module::trace_bprintk_fmt_start' offset changed from 5696 to 5760 (in bits) (by +64 bits)
'trace_event_call** module::trace_events' offset changed from 5760 to 5824 (in bits) (by +64 bits)
'unsigned int module::num_trace_events' offset changed from 5824 to 5888 (in bits) (by +64 bits)
'trace_eval_map** module::trace_evals' offset changed from 5888 to 5952 (in bits) (by +64 bits)
'unsigned int module::num_trace_evals' offset changed from 5952 to 6016 (in bits) (by +64 bits)
'list_head module::source_list' offset changed from 6016 to 6080 (in bits) (by +64 bits)
'list_head module::target_list' offset changed from 6144 to 6208 (in bits) (by +64 bits)
'void ()* module::exit' offset changed from 6272 to 6336 (in bits) (by +64 bits)
'atomic_t module::refcnt' offset changed from 6336 to 6400 (in bits) (by +64 bits)
1532 impacted interfaces:
'struct static_key at jump_label.h:110:1' changed:
type size changed from 32 to 128 (in bits)
1 data member insertion:
'union {unsigned long int type; jump_entry* entries; static_key_mod* next;}', at offset 64 (in bits) at jump_label.h:102:1
1532 impacted interfaces:
'struct tracepoint at tracepoint-defs.h:30:1' changed:
type size changed from 320 to 384 (in bits)
there are data member changes:
type 'struct static_key' of 'tracepoint::key' changed as reported earlier
and size changed from 32 to 128 (in bits) (by +96 bits)
'void ()* tracepoint::regfunc' offset changed from 128 to 192 (in bits) (by +64 bits)
'void ()* tracepoint::unregfunc' offset changed from 192 to 256 (in bits) (by +64 bits)
'tracepoint_func* tracepoint::funcs' offset changed from 256 to 320 (in bits) (by +64 bits)
1532 impacted interfaces:
Bug: 145162121
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I3b11e0952c06f1a0dda7a9eb28dcb4988e5f050a
It's needed to speed up trace points and other dynamic debugging stuff.
Bug: 145162121
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I811b538bc5280a633c56e0544ba1f54cd6b234f2
Add a gki-debug build.config file which disables whitelisting trimming.
This is intended to ease GKI development.
Bug: 150772411
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: I4b7f001eaca37fe993260ddff914fb05a1310df9
Add a gki-debug build.config file which disables whitelisting trimming.
This is intended to ease GKI development.
Bug: 150772411
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: Ia5241f17b1cf730b357c6501180834bd01eb589f
When I backported 52918ed5fc ("KVM: SVM: Override default MMIO mask if
memory encryption is enabled") to 4.19 (which resulted in commit
a4e761c9f6 ("KVM: SVM: Override default MMIO mask if memory encryption
is enabled")), I messed up the call to kvm_mmu_set_mmio_spte_mask()
Fix that here now.
Reported-by: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(Upstream commit d0022c0ef29b78bcbe8a5c5894bd2307143afce1.)
Add brackets around the evaluation of the 'addr' parameter to the
untagged_addr() macro so that the cast to 'u64' applies to the result
of the expression.
Cc: <stable@vger.kernel.org>
Fixes: 597399d0cb ("arm64: tags: Preserve tags for addresses translated via TTBR1")
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 135692346
Change-Id: I1bce8f6a185258a365aaa292483fabc02519301f
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
(Upstream commit dcde237319e626d1ec3c9d8b7613032f0fd4663a.)
Currently the arm64 kernel ignores the top address byte passed to brk(),
mmap() and mremap(). When the user is not aware of the 56-bit address
limit or relies on the kernel to return an error, untagging such
pointers has the potential to create address aliases in user-space.
Passing a tagged address to munmap(), madvise() is permitted since the
tagged pointer is expected to be inside an existing mapping.
The current behaviour breaks the existing glibc malloc() implementation
which relies on brk() with an address beyond 56-bit to be rejected by
the kernel.
Remove untagging in the above functions by partially reverting commit
ce18d171cb ("mm: untag user pointers in mmap/munmap/mremap/brk"). In
addition, update the arm64 tagged-address-abi.rst document accordingly.
Link: https://bugzilla.redhat.com/1797052
Fixes: ce18d171cb ("mm: untag user pointers in mmap/munmap/mremap/brk")
Cc: <stable@vger.kernel.org> # 5.4.x-
Cc: Florian Weimer <fweimer@redhat.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Victor Stinner <vstinner@redhat.com>
Acked-by: Will Deacon <will@kernel.org>
Acked-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 135692346
Change-Id: Iadeceb2d5d5fb576ab1bb5ae1a67f4971bbbf88e
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
This module allows presenting the kernel TPM interface while proxying
the TPM commands into a file descriptor. The module was originally
implemented to support running a TPM simulator on the same host system
and exposing a kernel TPM interface to a Linux container, but it is also
a convenient incremental step while we figure out our long-term strategy
with crosvm, which does not have TPM support following the same
standards as qemu.
CONFIG_TCG_TPM, the base config for the various TPM drivers, required
CONFIG_SECURITYFS. CONFIG_SECURITYFS exists only as a boolean and not a
tristate, so we can't install it as a module.
Bug: 148102533
Test: Build and run locally with cuttlefish, check for /dev/vtpmx
Change-Id: I568a50c2ecb7899aae70e7a20efaedc84443511d
Signed-off-by: A. Cody Schuffelen <schuffelen@google.com>
We don't need this any more as devices which are consoles and also
platform devices are automatically excluded from binding unless the user
opts into it.
This reverts commit 2fdad105a0.
Bug: 146517987
Change-Id: I2b9cc9c13870e5ecccbf04addadd48e59658aee3
Signed-off-by: Alistair Delva <adelva@google.com>
Make the fallback path for claiming platform devices trigger only if a
new module parameter is specified:
serdev_ttyport.pdev_tty_port=ttyS2
Bug: 146517987
Change-Id: Ibf331ad6e6d8712a405921530f217f7122428b13
Signed-off-by: Alistair Delva <adelva@google.com>
Leaf changes summary: 3 artifacts changed
Changed leaf types summary: 3 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 typec_mux at typec_mux.h:38:1' changed:
type size changed from 256 to 6272 (in bits)
1 data member deletion:
'list_head typec_mux::entry', at offset 64 (in bits) at typec_mux.h:40:1
there are data member changes:
type 'void ()*' of 'typec_mux::set' changed:
entity changed from 'void ()*' to compatible type 'typedef typec_mux_set_fn_t' at typec_mux.h:32:1
type size hasn't changed
and offset changed from 192 to 6208 (in bits) (by +6016 bits)
10 impacted interfaces
'struct typec_switch at typec_mux.h:21:1' changed:
type size changed from 256 to 6272 (in bits)
1 data member deletion:
'list_head typec_switch::entry', at offset 64 (in bits) at typec_mux.h:23:1
there are data member changes:
type 'void ()*' of 'typec_switch::set' changed:
entity changed from 'void ()*' to compatible type 'typedef typec_switch_set_fn_t' at typec_mux.h:13:1
type size hasn't changed
and offset changed from 192 to 6208 (in bits) (by +6016 bits)
10 impacted interfaces
'struct usb_pd_identity at typec.h:83:1' changed:
type size changed from 96 to 128 (in bits)
1 data member insertion:
'u32 usb_pd_identity::product_type', at offset 96 (in bits) at typec.h:88:1
4 impacted interfaces
Signed-off-by: Will McVicker <willmcvicker@google.com>
Bug: 150877929
Change-Id: I769ce04dfc099c5de744c39e5a850397589f313a
This ABI difference was introduced by commit 6e7065617217 ("tcpm: Add
support for VPD detection by a DRP port"). Add the struct field for ABI
compatibility for TPCM vendor module support.
Signed-off-by: Will McVicker <willmcvicker@google.com>
Bug: 150877929
Change-Id: I036893d5f149cfe1314b45c6308888dcfc3f417f
Registering real device entries (struct device) for the mode
muxes as well as for the orientation switches.
The Type-C mux code was deliberately attempting to avoid
creation of separate device entries for the orientation
switch and the mode switch (alternate modes) because they
are not physical devices. They are functions of a single
physical multiplexer/demultiplexer switch device.
Unfortunately because of the dependency we still have on the
underlying mux device driver, we had to put in hacks like
the one in the commit 3e3b81965c ("usb: typec: mux: Take
care of driver module reference counting") to make sure the
driver does not disappear from underneath us. Even with
those hacks we were still left with a potential NUll pointer
dereference scenario, so just creating the device entries,
and letting the core take care of the dependencies. No more
hacks needed.
Bug: 150877929
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Change-Id: I63038acfdbf2fff9eef5f5d6a9eae77fc7f0fcb4
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 3370db3519)
All the code paths that lead to the return statement are where
match is always true, hence the check to see if it is true is
redundant and can be removed.
Detected by CoverityScan, CID#14769672 ("Logically dead code")
Bug: 150877929
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: Iedfd85df7b0719ff0b9dc4431188850921157e57
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit eb76b37aaf)
The return from the call to fwnode_property_read_u16_array is int,
it can be a negative error code however this is being assigned to
an size_t variable 'nval', hence the check is always false.
Fix this by making 'nval' an int.
Detected by Coccinelle ("Unsigned expression compared with
zero: nval < 0")
Bug: 150877929
Fixes: 96a6d031ca ("usb: typec: mux: Find the muxes by also matching against the device node")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I3169e47b59bbe5972b79ce88f849b345a401898e
(cherry picked from commit 4e46f271c3)
Signed-off-by: Will McVicker <willmcvicker@google.com>
When the connections are defined in firmware, struct
device_connection will have the fwnode member pointing to
the device node (struct fwnode_handle) of the requested
device, and the endpoint will not be used at all in that
case.
Bug: 150877929
Acked-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Jun Li <jun.li@nxp.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I9e109b61a63ed005d419ee59c5fbad48903835b3
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 96a6d031ca)
When the connections are defined in firmware, struct
device_connection will have the fwnode member pointing to
the device node (struct fwnode_handle) of the requested
device, and the endpoint will not be used at all in that
case.
Bug: 150877929
Acked-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Jun Li <jun.li@nxp.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: Ie6e233c158bae77cf1f332c45957248e4521c7f8
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 6a0bbcf96b)
Since with accessory modes there is no need for additional
identification when requesting a handle to the mux, we can
replace the second parameter that is passed to the
typec_mux_get() function with a pointer to alternate mode
description structure, and simply passing NULL with
accessory modes.
This change means the naming of the mux device connections
can be updated. Alternate and Accessory Modes will both be
handled with muxes named "mode-switch", and the orientation
switches will be named "orientation-switch".
Future identification of the alternate modes will be later
done using device property "svid" of the mux.
Bug: 150877929
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Jun Li <jun.li@nxp.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: Iafd151d0c0dab6847a35ac222d0d209c77096cd1
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 540bfab7fb)
The usual pattern to allocate the necessary space for an array of properties is
to count them first by calling:
count = device_property_read_uXX_array(dev, propname, NULL, 0);
if (count < 0)
return count;
Introduce helpers device_property_count_uXX() to count items by supplying hard
coded last two parameters to device_property_readXX_array().
Bug: 150877929
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Will McVicker <willmcvicker@google.com>
Change-Id: If7cdedae76d0543997b96b3da3d28f6657472d29
(cherry picked from commit 33ee09cd59)
The new mux connection naming scheme is now in use, so
dropping the connections still using the old names. From now
on the same connection description named "mode-switch" is
used with both the port and the alternate modes, so on CHT
the DP alt mode will use the same connection as the port to
get a handle to the mux device.
Bug: 150877929
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Jun Li <jun.li@nxp.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: If11eda46906d48ab4824aca0d949e1cf23067756
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 393cd68d0d)
Because of UCSI, we have to support alt mode enter/exit
reporting even when there is no alt mode driver bind to the
alt mode device. With UCSI a firmware handles the alternate
modes, and the modes are entered automatically from OS PoW.
Changing typec_altmode_update_active() so that the driver
module ref count is incremented/decremented only if there
really is a driver for the alt mode. That avoids a NULL
pointer dereference from happening when the driver is
missing.
Bug: 150877929
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: If8dd297875ff88c2c82bdb1d43eb2c72469e9bf0
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit b0fcdffdd6)
Add API to find the ddr device type from memory node.
Test: build
Bug: 150980314
Change-Id: I1cfc38d46f1ea0abc6fbe8cbb6e37cde72b9fc2e
Signed-off-by: Channagoud Kadabi <ckadabi@codeaurora.org>
(cherry picked from commit 368f22bc0d35888285a523f190ac1f5024168fa4)
[hridya: added an EXPORT_SYMBOL_GPL statement to make the new
symbol avaialable to kernel modules].
Signed-off-by: Hridya Valsaraju <hridya@google.com>
We need to reset input device's timestamp on input_sync(), otherwise
drivers not using input_set_timestamp() will end up with a stale
timestamp after their clients consume first input event.
Bug: 150896413
Fixes: 3b51c44bd6 ("Input: allow drivers specify timestamp for input events")
Reported-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
(cherry picked from commit 4370b231d1)
Signed-off-by: Hridya Valsaraju <hridya@google.com>
Change-Id: I35b76cbed146a4ee8e021388eb7a68282daf9003
Currently, evdev stamps events with timestamps acquired in evdev_events()
However, this timestamping may not be accurate in terms of measuring
when the actual event happened.
Let's allow individual drivers specify timestamp in order to provide a more
accurate sense of time for the event. It is expected that drivers will set the
timestamp in their hard interrupt routine.
Bug: 150896413
Signed-off-by: Atif Niyaz <atifniyaz@google.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Change-Id: I718209b41958a771c48f6069a597cec469c4074d
(cherry picked from commit 3b51c44bd6)
Signed-off-by: Hridya Valsaraju <hridya@google.com>
dwc_usb31 supports DRD only mode. It does not support
USB OTG mode. SNPS core consultant parameter DWC_USB3_EN_OTG
is not set for dwc_usb31. Hence add USB_DR_MODE_DRD which
reflects support for host and device mode support without
supporting USB OTG features.
Bug: 150901210
Test: make
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Change-Id: If3b683d4d47f0eb846a2ac302aff8848096395b9
(cherry picked from commit d4c4fb2d63ce1f2f7bf07975f71a5a0a4b2f5aec)
[hridya: commit amended to only include the ABI diff]
Signed-off-by: Hridya Valsaraju <hridya@google.com>
This API registers a virtual thermal sensor.
Test: build
Bug: 149945768
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
Change-Id: I72b29b4296d9be949d096913471153b596c67e1f
[hridya: commit amended to only pull in the API implementation and code
needed to build it.]
(cherry picked commit from 8a12149c264c7b871932ad90f76e5981452bb4bb)
Signed-off-by: Hridya Valsaraju <hridya@google.com>
In preparation for removal of VLAs due to skcipher requests on the stack
via SKCIPHER_REQUEST_ON_STACK() usage, this introduces the infrastructure
for the "sync skcipher" tfm, which is for handling the on-stack cases of
skcipher, which are always non-ASYNC and have a known limited request
size.
The crypto API additions:
struct crypto_sync_skcipher (wrapper for struct crypto_skcipher)
crypto_alloc_sync_skcipher()
crypto_free_sync_skcipher()
crypto_sync_skcipher_setkey()
crypto_sync_skcipher_get_flags()
crypto_sync_skcipher_set_flags()
crypto_sync_skcipher_clear_flags()
crypto_sync_skcipher_blocksize()
crypto_sync_skcipher_ivsize()
crypto_sync_skcipher_reqtfm()
skcipher_request_set_sync_tfm()
SYNC_SKCIPHER_REQUEST_ON_STACK() (with tfm type check)
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Bug: 150811495
Test: make
Change-Id: I5d002a7af64509a293cd4d685b97d2cd2c4d10e1
(cherry picked from commit b350bee5ea)
Signed-off-by: Hridya Valsaraju <hridya@google.com>
AP stopped interface can be used to indicate that the AP mode has
stopped functioning, WLAN driver may have encountered errors that has
forced the driver to stop the AP mode.
When the driver is in P2P-Go mode, and when it goes thru automatic
recovery from firmware crashes, it uses this interface to notify the
userspace that the group has been deleted.
CRs-Fixed: 1078172
Bug: 150894598
Test: make
Signed-off-by: Sameer Thalappil <sameert@codeaurora.org>
Change-Id: Id566b35cd0afdb7277fbd2aef74601bfabc65e42
(cherry picked from commit 44643035d7f5d74edebac551928a7b03fe76f19c)
Signed-off-by: Hridya Valsaraju <hridya@google.com>
Patch series "Unexport kallsyms_lookup_name() and kallsyms_on_each_symbol()".
Despite having just a single modular in-tree user that I could spot,
kallsyms_lookup_name() is exported to modules and provides a mechanism
for out-of-tree modules to access and invoke arbitrary, non-exported
kernel symbols when kallsyms is enabled.
This patch series fixes up that one user and unexports the symbol along
with kallsyms_on_each_symbol(), since that could also be abused in a
similar manner.
I would like to avoid out-of-tree modules being easily able to call
functions that are not exported. kallsyms_lookup_name() makes this
trivial to the point that there is very little incentive to rework these
modules to either use upstream interfaces correctly or propose
functionality which may be otherwise missing upstream. Both of these
latter solutions would be pre-requisites to upstreaming these modules, and
the current state of things actively discourages that approach.
The background here is that we are aiming for Android devices to be able
to use a generic binary kernel image closely following upstream, with any
vendor extensions coming in as kernel modules. In this case, we (Google)
end up maintaining the binary module ABI within the scope of a single LTS
kernel. Monitoring and managing the ABI surface is not feasible if it
effectively includes all data and functions via kallsyms_lookup_name().
Of course, we could just carry this patch in the Android kernel tree, but
we're aiming to carry as little as possible (ideally nothing) and I think
it's a sensible change in its own right. I'm surprised you object to it,
in all honesty.
Now, you could turn around and say "that's not upstream's problem", but it
still seems highly undesirable to me to have an upstream bypass for
exported symbols that isn't even used by upstream modules. It's ripe for
abuse and encourages people to work outside of the upstream tree. The
usual rule is that we don't export symbols without a user in the tree and
that seems especially relevant in this case.
Joe Lawrence said:
: FWIW, kallsyms was historically used by the out-of-tree kpatch support
: module to resolve external symbols as well as call set_memory_r{w,o}()
: API. All of that support code has been merged upstream, so modern kpatch
: modules* no longer leverage kallsyms by default.
:
: That said, there are still some users who still use the deprecated support
: module with newer kernels, but that is not officially supported by the
: project.
This patch (of 3):
Given the name of a kernel symbol, the 'data_breakpoint' test claims to
"report any write operations on the kernel symbol". However, it creates
the breakpoint using both HW_BREAKPOINT_W and HW_BREAKPOINT_R, which menas
it also fires for read access.
Drop HW_BREAKPOINT_R from the breakpoint attributes.
Bug: 149978696
Change-Id: I12f793136a7187c844841e7dd65b90645d5519f6
Link: http://lkml.kernel.org/r/20200221114404.14641-2-will@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: K.Prasad <prasad@linux.vnet.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Quentin Perret <qperret@google.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Miroslav Benes <mbenes@suse.cz>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Joe Lawrence <joe.lawrence@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 0c1b9251116b972cafa3cf16bd02cb2354535b38
https://github.com/hnaz/linux-mm.git master)
Signed-off-by: Quentin Perret <qperret@google.com>
After FS_IOC_REMOVE_ENCRYPTION_KEY removes a key, it syncs the
filesystem and tries to get and put all inodes that were unlocked by the
key so that unused inodes get evicted via fscrypt_drop_inode().
Normally, the inodes are all clean due to the sync.
However, after the filesystem is sync'ed, userspace can modify and close
one of the files. (Userspace is *supposed* to close the files before
removing the key. But it doesn't always happen, and the kernel can't
assume it.) This causes the inode to be dirtied and have i_count == 0.
Then, fscrypt_drop_inode() failed to consider this case and indicated
that the inode can be dropped, causing the write to be lost.
On f2fs, other problems such as a filesystem freeze could occur due to
the inode being freed while still on f2fs's dirty inode list.
Fix this bug by making fscrypt_drop_inode() only drop clean inodes.
I've written an xfstest which detects this bug on ext4, f2fs, and ubifs.
Fixes: b1c0ec3599 ("fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl")
Cc: <stable@vger.kernel.org> # v5.4+
Link: https://lore.kernel.org/r/20200305084138.653498-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 2b4eae95c7)
Bug: 150589360
Test: kvm-xfstests -c ext4,f2fs -g encrypt
Change-Id: Ia32db980c2fffb68caeaf9f38e5cfbe781b45011
Signed-off-by: Eric Biggers <ebiggers@google.com>
This was "default y" but disabled manually because we set
CONFIG_EXPERT=y. Disabling it does not seem to be a big win and we have
had requests to enable it.
Bug: 150871026
Change-Id: I4a7f8da1e8480dc46f168def89016a5152e421ea
Signed-off-by: Alistair Delva <adelva@google.com>
