commit f148b9f402 upstream.
A Full-speed bulk USB audio device (DJ-Tech CTRL) with a invalid Maximum
Packet Size of 4 causes a xHC "Parameter Error" at enumeration.
This is because valid Maximum packet sizes for Full-speed bulk endpoints
are 8, 16, 32 and 64 bytes. Hosts are not required to support other values
than these. See usb 2 specs section 5.8.3 for details.
The device starts working after forcing the maximum packet size to 8.
This is most likely the case with other devices as well, so force the
maximum packet size to a valid range.
Cc: stable@vger.kernel.org
Reported-by: Rene D Obermueller <cmdrrdo@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200210134553.9144-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 687bff0cd0 upstream.
When pasting a selection to a vt, the task is set as INTERRUPTIBLE while
waiting for a tty to unthrottle. But signals are not handled at all.
Normally, this is not a problem as tty_ldisc_receive_buf receives all
the goods and a user has no reason to interrupt the task.
There are two scenarios where this matters:
1) when the tty is throttled and a signal is sent to the process, it
spins on a CPU until the tty is unthrottled. schedule() does not
really echedule, but returns immediately, of course.
2) when the sel_buffer becomes invalid, KASAN prevents any reads from it
and the loop simply does not proceed and spins forever (causing the
tty to throttle, but the code never sleeps, the same as above). This
sometimes happens as there is a race in the sel_buffer handling code.
So add signal handling to this ioctl (TIOCL_PASTESEL) and return -EINTR
in case a signal is pending.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200210081131.23572-1-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3f4ef485be upstream.
Commit a6dbe44275 ("vt: perform safe console erase in the right
order") provided fixes to an earlier commit by gathering all console
scrollback flushing operations in a function of its own. This includes
the invocation of vc_sw->con_switch() as previously done through a
update_screen() call. That commit failed to carry over the
con_is_visible() conditional though, as well as cursor handling, which
caused problems when "\e[3J" was written to a background console.
One could argue for preserving the call to update_screen(). However
this does far more than we need, and it is best to remove scrollback
assumptions from it. Instead let's gather the minimum needed to actually
perform scrollback flushing properly in that one place.
While at it, let's document the vc_sw->con_switch() side effect being
relied upon.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Reported-and-tested-by: Lukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/nycvar.YSQ.7.76.2001281205560.1655@knanqh.ubzr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2e90ca68b0 upstream.
Jordy Zomer reported a KASAN out-of-bounds read in the floppy driver in
wait_til_ready().
Which on the face of it can't happen, since as Willy Tarreau points out,
the function does no particular memory access. Except through the FDCS
macro, which just indexes a static allocation through teh current fdc,
which is always checked against N_FDC.
Except the checking happens after we've already assigned the value.
The floppy driver is a disgrace (a lot of it going back to my original
horrd "design"), and has no real maintainer. Nobody has the hardware,
and nobody really cares. But it still gets used in virtual environment
because it's one of those things that everybody supports.
The whole thing should be re-written, or at least parts of it should be
seriously cleaned up. The 'current fdc' index, which is used by the
FDCS macro, and which is often shadowed by a local 'fdc' variable, is a
prime example of how not to write code.
But because nobody has the hardware or the motivation, let's just fix up
the immediate problem with a nasty band-aid: test the fdc index before
actually assigning it to the static 'fdc' variable.
Reported-by: Jordy Zomer <jordy@simplyhacker.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 03cd45d2e2 upstream.
The driver does not populate .reg_read callback for the non-active NVMem
because the file is supposed to be write-only. However, it turns out
NVMem subsystem does not yet support this and expects that the .reg_read
callback is provided. If user reads the binary attribute it triggers
NULL pointer dereference like this one:
BUG: kernel NULL pointer dereference, address: 0000000000000000
...
Call Trace:
bin_attr_nvmem_read+0x64/0x80
kernfs_fop_read+0xa7/0x180
vfs_read+0xbd/0x170
ksys_read+0x5a/0xd0
do_syscall_64+0x43/0x150
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fix this in the driver by providing .reg_read callback that always
returns an error.
Reported-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Fixes: e6b245ccd5 ("thunderbolt: Add support for host and device NVM firmware upgrade")
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200213095604.1074-1-mika.westerberg@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b4a81b87a4 upstream.
In ecryptfs_init_messaging(), if the allocation for 'ecryptfs_msg_ctx_arr'
fails, the previously allocated 'ecryptfs_daemon_hash' is not deallocated,
leading to a memory leak bug. To fix this issue, free
'ecryptfs_daemon_hash' before returning the error.
Cc: stable@vger.kernel.org
Fixes: 88b4a07e66 ("[PATCH] eCryptfs: Public key transport mechanism")
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fe2e082f5d upstream.
In parse_tag_1_packet(), if tag 1 packet contains a key larger than
ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES, no cleanup is executed, leading to a
memory leak on the allocated 'auth_tok_list_item'. To fix this issue, go to
the label 'out_free' to perform the cleanup work.
Cc: stable@vger.kernel.org
Fixes: dddfa461fc ("[PATCH] eCryptfs: Public key; packet management")
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 44eeb081b8 upstream.
Some code in HD-audio driver calls snprintf() in a loop and still
expects that the return value were actually written size, while
snprintf() returns the expected would-be length instead. When the
given buffer limit were small, this leads to a buffer overflow.
Use scnprintf() for addressing those issues. It returns the actually
written size unlike snprintf().
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200218091409.27162-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit faf305c51a upstream.
Currently, the implementation of qcom_iommu_domain_free() is guaranteed
to do one of two things: WARN() and leak everything, or dereference NULL
and crash. That alone is terrible, but in fact the whole idea of trying
to track the liveness of a domain via the qcom_domain->iommu pointer as
a sanity check is full of fundamentally flawed assumptions. Make things
robust and actually functional by not trying to be quite so clever.
Reported-by: Brian Masney <masneyb@onstation.org>
Tested-by: Brian Masney <masneyb@onstation.org>
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Fixes: 0ae349a0f3 ("iommu/qcom: Add qcom_iommu")
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Stephan Gerhold <stephan@gerhold.net>
Cc: stable@vger.kernel.org # v4.14+
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Issuing write() with count parameter set to 0 on any file under
/proc/pressure/ will cause an OOB write because of the access to
buf[buf_size-1] when NUL-termination is performed. Fix this by checking
for buf_size to be non-zero.
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Link: https://lkml.kernel.org/r/20200203212216.7076-1-surenb@google.com
(cherry picked from commit 6fcca0fa48)
Bug: 148159562
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I9ec7acfc6e1083c677a95b0ea1c559ab50152873
Jingfeng reports rare div0 crashes in psi on systems with some uptime:
[58914.066423] divide error: 0000 [#1] SMP
[58914.070416] Modules linked in: ipmi_poweroff ipmi_watchdog toa overlay fuse tcp_diag inet_diag binfmt_misc aisqos(O) aisqos_hotfixes(O)
[58914.083158] CPU: 94 PID: 140364 Comm: kworker/94:2 Tainted: G W OE K 4.9.151-015.ali3000.alios7.x86_64 #1
[58914.093722] Hardware name: Alibaba Alibaba Cloud ECS/Alibaba Cloud ECS, BIOS 3.23.34 02/14/2019
[58914.102728] Workqueue: events psi_update_work
[58914.107258] task: ffff8879da83c280 task.stack: ffffc90059dcc000
[58914.113336] RIP: 0010:[] [] psi_update_stats+0x1c1/0x330
[58914.122183] RSP: 0018:ffffc90059dcfd60 EFLAGS: 00010246
[58914.127650] RAX: 0000000000000000 RBX: ffff8858fe98be50 RCX: 000000007744d640
[58914.134947] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00003594f700648e
[58914.142243] RBP: ffffc90059dcfdf8 R08: 0000359500000000 R09: 0000000000000000
[58914.149538] R10: 0000000000000000 R11: 0000000000000000 R12: 0000359500000000
[58914.156837] R13: 0000000000000000 R14: 0000000000000000 R15: ffff8858fe98bd78
[58914.164136] FS: 0000000000000000(0000) GS:ffff887f7f380000(0000) knlGS:0000000000000000
[58914.172529] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[58914.178467] CR2: 00007f2240452090 CR3: 0000005d5d258000 CR4: 00000000007606f0
[58914.185765] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[58914.193061] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[58914.200360] PKRU: 55555554
[58914.203221] Stack:
[58914.205383] ffff8858fe98bd48 00000000000002f0 0000002e81036d09 ffffc90059dcfde8
[58914.213168] ffff8858fe98bec8 0000000000000000 0000000000000000 0000000000000000
[58914.220951] 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[58914.228734] Call Trace:
[58914.231337] [] psi_update_work+0x22/0x60
[58914.237067] [] process_one_work+0x189/0x420
[58914.243063] [] worker_thread+0x4e/0x4b0
[58914.248701] [] ? process_one_work+0x420/0x420
[58914.254869] [] kthread+0xe6/0x100
[58914.259994] [] ? kthread_park+0x60/0x60
[58914.265640] [] ret_from_fork+0x39/0x50
[58914.271193] Code: 41 29 c3 4d 39 dc 4d 0f 42 dc <49> f7 f1 48 8b 13 48 89 c7 48 c1
[58914.279691] RIP [] psi_update_stats+0x1c1/0x330
The crashing instruction is trying to divide the observed stall time
by the sampling period. The period, stored in R8, is not 0, but we are
dividing by the lower 32 bits only, which are all 0 in this instance.
We could switch to a 64-bit division, but the period shouldn't be that
big in the first place. It's the time between the last update and the
next scheduled one, and so should always be around 2s and comfortably
fit into 32 bits.
The bug is in the initialization of new cgroups: we schedule the first
sampling event in a cgroup as an offset of sched_clock(), but fail to
initialize the last_update timestamp, and it defaults to 0. That
results in a bogusly large sampling period the first time we run the
sampling code, and consequently we underreport pressure for the first
2s of a cgroup's life. But worse, if sched_clock() is sufficiently
advanced on the system, and the user gets unlucky, the period's lower
32 bits can all be 0 and the sampling division will crash.
Fix this by initializing the last update timestamp to the creation
time of the cgroup, thus correctly marking the start of the first
pressure sampling period in a new cgroup.
Reported-by: Jingfeng Xie <xiejingfeng@linux.alibaba.com>
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Link: https://lkml.kernel.org/r/20191203183524.41378-2-hannes@cmpxchg.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 3dfbe25c27)
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Iaada5c2f1a03cf38cbb053adde478f762ce40843
merge cmd:
MPP_CMD_SET_REG -->
MPP_CMD_SET_VEPU22_CFG -->
MPP_CMD_SET_RKVENC_OSD_PLT --> MPP_CMD_SET_REG_WRITE
MPP_CMD_SET_RKVENC_L2_REG -->
change cmd:
MPP_CMD_GET_REG --> MPP_CMD_SET_REG_READ
tips:
1. the xx_WRITE cmd is to write register, while xx_READ cmd is to
read register.
2. move MPP_CMD_GET_REG to MPP_CMD_SET_REG_READ, then it can set
output when input.
Change-Id: Iee1d5c6aafdfea5e0d02d1865cd06079ef5f716b
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
If the USB cable is unplugged when powered on or connected to PC,
it will cause the system to freeze. The final log is as follows:
[ 5.109122] read descriptors
[ 5.109180] read strings
[ 5.113205] udc fe800000.dwc3: registering UDC driver [g1]
The crash is caused by visit registers of dwc3 when PD is off. the
function dwc3_gadget_set_speed is added in udc_bind_to_driver in
kernel 4.19 update. We need jump of this function when dwc3 is
suspended.
Change-Id: Ie0337aaf225543b4e9e05ee57a5eb7416797d56e
Signed-off-by: Jianing Ren <jianing.ren@rock-chips.com>
To avoid the potential parent PLL clock of display being
closed when PD is shutdown, excute protect loader clocks
earlier.
Signed-off-by: Guochun Huang <hero.huang@rock-chips.com>
Change-Id: I5125590aac51b423e7e9fdc0032da9185c450be1
Add IOMMU_TLB_SHOT_ENTIRE prot for iommu_map_sg, this shoot down entire
iommu tlb one time after iommu_map_sg.This may save about 5ms when DRM
mapping 12MB buffer.
Change-Id: I618aff1b3928bd1ec1dd3d896db746e09e96acdc
Signed-off-by: Simon Xue <xxm@rock-chips.com>
This expands f2fs's casefolding support to include encrypted
directories. For encrypted directories, we use the siphash of the
casefolded name. This ensures there is no direct way to go from an
unencrypted name to the stored hash on disk without knowledge of the
encryption policy keys.
Additionally, we switch to using the vfs layer's casefolding support
instead of storing this information inside of f2fs's private data.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Note: Fixed some missing type conversions, crypto length issue
and hash check for ciphertext name
Test: Boots, /data/media is case insensitive
Bug: 138322712
Link: https://lore.kernel.org/linux-f2fs-devel/20200208013552.241832-1-drosen@google.com/T/#t
Change-Id: I8f1e324472668e27d3e059cc80e4c981ce89dd9b
This shifts the responsibility of setting up dentry operations from
fscrypt to the individual filesystems, allowing them to have their own
operations while still setting fscrypt's d_revalidate as appropriate.
Also added helper function to libfs to unify ext4 and f2fs
implementations.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Test: Boots, /data/media is case insensitive
Bug: 138322712
Link: https://lore.kernel.org/linux-f2fs-devel/20200208013552.241832-1-drosen@google.com/T/#t
Change-Id: Iaf77f8c5961ecf22e22478701ab0b7fe2025225d
This adds general supporting functions for filesystems that use
utf8 casefolding. It provides standard dentry_operations and adds the
necessary structures in struct super_block to allow this standardization.
Ext4 and F2fs are switch to these implementations.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Note: Fixed issue with non-strictly enforced fallback hash
Test: Boots, /data/media is case insensitive
Bug: 138322712
Link: https://lore.kernel.org/linux-f2fs-devel/20200208013552.241832-1-drosen@google.com/T/#t
Change-Id: I81b5fb5d3ce0259a60712ae2505c1e4b03dbafde
The negative lower dentry created by vfs_path_lookup could be
reclaimed between vfs_path_lookup and d_hash_and_lookup.
Therefore, it is unsafe to just lookup dcache again for
the negative dentry cases.
Without this patch, users could occasionally get trapped into
`failed to create' under memory pressure.
So here is a workaround to hack it and in my opinion sdcardfs
should be refactored to close all races in the long term
as pointed out in the code comment of this commit.
Test: (Thread 1)
while true; do
echo 3 > /proc/sys/vm/drop_caches
done
(Thread 2)
i=0
while true; do
echo 123 > /sdcard/$i
i=$((i+1))
done
Bug: 63872684
Cc: Daniel Rosenberg <drosen@google.com>
Cc: Miao Xie <miaoxie@huawei.com>
Cc: Chao Yu <yuchao0@huawei.com>
Change-Id: Ic033e1f84a8b271c1f48010f4e1f189982bbbea2
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Signed-off-by: Daniel Rosenberg <drosen@google.com>
(cherry picked from commit bd77267426ed5ffe6a25aa77c149cde28f479f95)
Support future decompression of LZ4-compressed ramdisk images.
This support is in addition to the default support for gzip.
Bug: 150391496
Test: TreeHugger
Change-Id: I8c07e9363333c53cd6ff9c7e16fc42cbe318fe83
Signed-off-by: Alistair Delva <adelva@google.com>
The MD4 algorithm is heavily broken and obsolete, and there seems to be
no reason for it to be enabled in GKI. It originally got enabled at
partner request alongside many other options with the rationale that
they changed the kernel ABI, so they needed to be enabled in GKI for any
module to use it. But that doesn't apply to MD4 because it doesn't
change the kernel ABI. Nor should any module be using MD4 anyway.
So let's disable MD4 again.
Bug: 135666008
Bug: 150302692
Change-Id: Iec0946984c4e58bffeab7888e689af035cdd512b
Signed-off-by: Eric Biggers <ebiggers@google.com>
To prevent keys from being compromised if an attacker acquires read
access to kernel memory, some inline encryption hardware supports
protecting the keys in hardware without software having access to or the
ability to set the plaintext keys. Instead, software only sees "wrapped
keys", which may differ on every boot. The keys can be initially
generated either by software (in which case they need to be imported to
hardware to be wrapped), or directly by the hardware.
Add support for this type of hardware by allowing keys to be flagged as
hardware-wrapped. When used, dm-default-key will pass the wrapped key
to the inline encryption hardware to encryption metadata. The hardware
will internally unwrap the key and derive the metadata encryption key.
Bug: 147209885
Test: Validate metadata encryption & FBE with wrapped keys.
Change-Id: I8078b116dab9e04d7f3f15f29f11823185ea5d50
Signed-off-by: Barani Muthukumaran <bmuthuku@codeaurora.org>
Update the device-mapper core to support exposing the inline crypto
support of wrapped keys through the device-mapper device.
derive_raw_secret in keyslot manager is used to derive the software
raw secret from the given wrapped keyblob using the underlying blk
device. Given that the raw_secret is the same for a given wrapped
keyblob the call exits when the first underlying blk-device suceeds.
Bug: 147209885
Test: Validated FBE with wrappedkey_v0 when /data is mounted on a
dm device.
Change-Id: Ia49ed61613607f8b82f2be0615e5b6d2f7533859
Signed-off-by: Barani Muthukumaran <bmuthuku@codeaurora.org>
blk-crypto-fallback does not support wrapped keys, hence
prevent falling back when program_key fails. Add 'is_hw_wrapped'
flag to blk-crypto-key to mention if the key is wrapped
when the key is initialized.
Bug: 147209885
Test: Validate FBE, simulate a failure in the underlying blk
device and ensure the call fails without falling back
to blk-crypto-fallback.
Change-Id: I8bc301ca1ac9e55ba6ab622e8325486916b45c56
Signed-off-by: Barani Muthukumaran <bmuthuku@codeaurora.org>
When doing a cold build, autoksyms.h starts empty, and is updated late
in the build process to have visibility over the symbols used by in-tree
drivers. But since the symbol whitelist is known upfront, it can be used
to pre-populate autoksyms.h and maximize the amount of code that can be
compiled to its final state in a single pass, hence reducing build time.
Do this by using gen_autoksyms.sh to initialize autoksyms.h instead of
creating an empty file.
[ BACKPORT: 60ae1b194b not present, sed 3rd line of modules.order ]
Bug: 148277666
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Tested-by: Matthias Maennich <maennich@google.com>
Reviewed-by: Matthias Maennich <maennich@google.com>
Signed-off-by: Quentin Perret <qperret@google.com>
Link: https://lore.kernel.org/lkml/20200218094139.78835-4-qperret@google.com
Change-Id: I98f3394b190f097390f980e5d4d57981f91b22a6
In order to prepare the ground for a build-time optimization, split
adjust_autoksyms.sh into two scripts: one that generates autoksyms.h
based on all currently available information (whitelist, and .mod
files), and the other to inspect the diff between two versions of
autoksyms.h and trigger appropriate rebuilds.
[ BACKPORT: 60ae1b194b not present, sed 3rd line of modules.order ]
Bug: 148277666
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Tested-by: Matthias Maennich <maennich@google.com>
Reviewed-by: Matthias Maennich <maennich@google.com>
Signed-off-by: Quentin Perret <qperret@google.com>
Link: https://lore.kernel.org/lkml/20200218094139.78835-3-qperret@google.com
Change-Id: I7ed4f8f72c0ef9ac98419877efb5ef828d10b0d7
CONFIG_TRIM_UNUSED_KSYMS currently removes all unused exported symbols
from ksymtab. This works really well when using in-tree drivers, but
cannot be used in its current form if some of them are out-of-tree.
Indeed, even if the list of symbols required by out-of-tree drivers is
known at compile time, the only solution today to guarantee these don't
get trimmed is to set CONFIG_TRIM_UNUSED_KSYMS=n. This not only wastes
space, but also makes it difficult to control the ABI usable by vendor
modules in distribution kernels such as Android. Being able to control
the kernel ABI surface is particularly useful to ship a unique Generic
Kernel Image (GKI) for all vendors, which is a first step in the
direction of getting all vendors to contribute their code upstream.
As such, attempt to improve the situation by enabling users to specify a
symbol 'whitelist' at compile time. Any symbol specified in this
whitelist will be kept exported when CONFIG_TRIM_UNUSED_KSYMS is set,
even if it has no in-tree user. The whitelist is defined as a simple
text file, listing symbols, one per line.
[ BACKPORT: 60ae1b194b not present, sed 3rd line of modules.order ]
Bug: 148277666
Acked-by: Jessica Yu <jeyu@kernel.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Tested-by: Matthias Maennich <maennich@google.com>
Reviewed-by: Matthias Maennich <maennich@google.com>
Signed-off-by: Quentin Perret <qperret@google.com>
Link: https://lore.kernel.org/lkml/20200218094139.78835-2-qperret@google.com
Change-Id: Ie9a4bbb8eebb20202623f084859fb89e55a32698
This is essentially a partial backport of b7dca6dd1e ("kbuild: create
*.mod with full directory path and remove MODVERDIR") as a full backport
would pull in too many dependencies.
It is necessary to simplify the backport of the TRIM_NONLISTED_KMI
feature.
Bug: 148277666
Change-Id: Ibf85bf864b3961d5bec4965742f08a80e9f234af
Signed-off-by: Quentin Perret <qperret@google.com>
As commit 423a8155fa ("kbuild: Fix reading of .config in
link-vmlinux.sh") addressed, some shells fail to perform '.' if
${KCONFIG_CONFIG} does not contain a slash at all.
Instead, we can source include/config/auto.conf, which obviously
contain slashes, and we do not expect its file path overridden by
a user. Perhaps, the performance might be slightly better since
unset CONFIG options are stripped from include/config/auto.conf.
scripts/setlocalversion already works this way.
Bug: 148277666
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
(cherry picked from commit 94cf8acc38)
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: I414ffbfa92ee202f0c88757f896bf9c8811822d7
This patch is used by android 8+ system on RK3368 SoCs.
When drm to free object, it needs map sg again when alloc it next
time. For RK3368 SoCs' system, one dma buffer may used by ion and
drm devices together, it spend time to map sg, this patch remove
the destroy object and do it after final dma_buf_put.
Change-Id: Ia39a3d4691f0b545039efb880c999a35886178a0
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
