15a5e4ad4f
897177 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Steve Muckle
|
15a5e4ad4f |
ANDROID: add TEST_MAPPING for net/, include/net
Run CtsNetTestCases in presubmit for changes in net/ and include/net/. Bug: 186664401 Change-Id: I3cf942bd0418ad55a6559d6933927b0da86da595 Signed-off-by: Steve Muckle <smuckle@google.com> (cherry picked from commit 55415d7022a8835d8979e09a74da3df29c9091ec) |
||
Jialiang Wang
|
f5b4a7be57 |
UPSTREAM: nfp: fix use-after-free in area_cache_get()
commit 02e1a114fdb71e59ee6770294166c30d437bf86a upstream. area_cache_get() is used to distribute cache->area and set cache->id, and if cache->id is not 0 and cache->area->kref refcount is 0, it will release the cache->area by nfp_cpp_area_release(). area_cache_get() set cache->id before cpp->op->area_init() and nfp_cpp_area_acquire(). But if area_init() or nfp_cpp_area_acquire() fails, the cache->id is is already set but the refcount is not increased as expected. At this time, calling the nfp_cpp_area_release() will cause use-after-free. To avoid the use-after-free, set cache->id after area_init() and nfp_cpp_area_acquire() complete successfully. Note: This vulnerability is triggerable by providing emulated device equipped with specified configuration. BUG: KASAN: use-after-free in nfp6000_area_init (drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:760) Write of size 4 at addr ffff888005b7f4a0 by task swapper/0/1 Call Trace: <TASK> nfp6000_area_init (drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:760) area_cache_get.constprop.8 (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:884) Allocated by task 1: nfp_cpp_area_alloc_with_name (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:303) nfp_cpp_area_cache_add (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:802) nfp6000_init (drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:1230) nfp_cpp_from_operations (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:1215) nfp_pci_probe (drivers/net/ethernet/netronome/nfp/nfp_main.c:744) Freed by task 1: kfree (mm/slub.c:4562) area_cache_get.constprop.8 (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:873) nfp_cpp_read (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:924 drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:973) nfp_cpp_readl (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cpplib.c:48) Bug: 254471126 Signed-off-by: Jialiang Wang <wangjialiang0806@163.com> Reviewed-by: Yinjun Zhang <yinjun.zhang@corigine.com> Acked-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20220810073057.4032-1-wangjialiang0806@163.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Lee Jones <joneslee@google.com> Change-Id: Iad626deee45edc6bdf7a095d3de1defc5c6ad996 Signed-off-by: Lee Jones <joneslee@google.com> |
||
Linus Torvalds
|
5a9d35543f |
UPSTREAM: proc: avoid integer type confusion in get_proc_long
commit e6cfaf34be9fcd1a8285a294e18986bfc41a409c upstream. proc_get_long() is passed a size_t, but then assigns it to an 'int' variable for the length. Let's not do that, even if our IO paths are limited to MAX_RW_COUNT (exactly because of these kinds of type errors). So do the proper test in the rigth type. Bug: 261488859 Reported-by: Kyle Zeng <zengyhkyle@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Lee Jones <joneslee@google.com> Change-Id: I75a06fe777c638b82ef3fbd1346e985065ab17f2 Signed-off-by: Lee Jones <joneslee@google.com> |
||
|
Linus Torvalds
|
cffda199e1 |
UPSTREAM: proc: proc_skip_spaces() shouldn't think it is working on C strings
commit bce9332220bd677d83b19d21502776ad555a0e73 upstream. proc_skip_spaces() seems to think it is working on C strings, and ends up being just a wrapper around skip_spaces() with a really odd calling convention. Instead of basing it on skip_spaces(), it should have looked more like proc_skip_char(), which really is the exact same function (except it skips a particular character, rather than whitespace). So use that as inspiration, odd coding and all. Now the calling convention actually makes sense and works for the intended purpose. Bug: 261488859 Reported-and-tested-by: Kyle Zeng <zengyhkyle@gmail.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Lee Jones <joneslee@google.com> Change-Id: Ie21bf20f3b92b78c5f31093b354a77b4133810e7 Signed-off-by: Lee Jones <joneslee@google.com> |
||
Lee Jones
|
e418b27c0c |
ANDROID: usb: f_accessory: Check buffer size when initialised via composite
When communicating with accessory devices via USBFS, the initialisation call-stack looks like: ConfigFS > Gadget ConfigFS > UDC > Gadget ConfigFS > Composite Eventually ending up in composite_dev_prepare() where memory for the data buffer is allocated and initialised. The default size used for the allocation is USB_COMP_EP0_BUFSIZ (4k). When handling bulk transfers, acc_ctrlrequest() needs to be able to handle buffers up to BULK_BUFFER_SIZE (16k). Instead of adding new generic attributes to 'struct usb_request' to track the size of the allocated buffer, we can simply split off the affected thread of execution to travel via a knowledgeable abstracted function acc_ctrlrequest_composite() where we can complete the necessary specific checks. Bug: 264029575 Signed-off-by: Lee Jones <joneslee@google.com> Change-Id: Ia1280f85499621d3fa57f7262b4a2c80f4be7773 Signed-off-by: Lee Jones <joneslee@google.com> |
||
Minchan Kim
|
8912db2538 |
BACKPORT: mm: don't be stuck to rmap lock on reclaim path
The rmap locks(i_mmap_rwsem and anon_vma->root->rwsem) could be contended
under memory pressure if processes keep working on their vmas(e.g., fork,
mmap, munmap). It makes reclaim path stuck. In our real workload traces,
we see kswapd is waiting the lock for 300ms+(worst case, a sec) and it
makes other processes entering direct reclaim, which were also stuck on
the lock.
This patch makes lru aging path try_lock mode like shink_page_list so the
reclaim context will keep working with next lru pages without being stuck.
if it found the rmap lock contended, it rotates the page back to head of
lru in both active/inactive lrus to make them consistent behavior, which
is basic starting point rather than adding more heristic.
Since this patch introduces a new "contended" field as out-param along
with try_lock in-param in rmap_walk_control, it's not immutable any longer
if the try_lock is set so remove const keywords on rmap related functions.
Since rmap walking is already expensive operation, I doubt the const
would help sizable benefit( And we didn't have it until 5.17).
In a heavy app workload in Android, trace shows following statistics. It
almost removes rmap lock contention from reclaim path.
Martin Liu reported:
Before:
max_dur(ms) min_dur(ms) max-min(dur)ms avg_dur(ms) sum_dur(ms) count blocked_function
1632 0 1631 151.542173 31672 209 page_lock_anon_vma_read
601 0 601 145.544681 28817 198 rmap_walk_file
After:
max_dur(ms) min_dur(ms) max-min(dur)ms avg_dur(ms) sum_dur(ms) count blocked_function
NaN NaN NaN NaN NaN 0.0 NaN
0 0 0 0.127645 1 12 rmap_walk_file
[minchan@kernel.org: add comment, per Matthew]
Link: https://lkml.kernel.org/r/YnNqeB5tUf6LZ57b@google.com
Link: https://lkml.kernel.org/r/20220510215423.164547-1-minchan@kernel.org
Signed-off-by: Minchan Kim <minchan@kernel.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: John Dias <joaodias@google.com>
Cc: Tim Murray <timmurray@google.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Martin Liu <liumartin@google.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Conflicts:
folio->page
(cherry picked from commit 6d4675e601357834dadd2ba1d803f6484596015c)
Bug: 239681156
Bug: 252333201
Bug: 265247508
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I0c63e0291120c8a1b5f2d83b8a7b210cb56c27a2
Signed-off-by: chenxin <chenxinxin@xiaomi.corp-partner.google.com>
Signed-off-by: guchongchong <guchongchong@xiaomi.corp-partner.google.com>
(cherry picked from commit a0eae55f26a0cbdd828db226592093ad2142889c)
|
||
A. Cody Schuffelen
|
a69a8cd3c5 |
ANDROID: Add more hvc devices for virtio-console.
This allows creating more TTY devices bound to virtio-console devices. Bug: 170149708 Test: ls /dev/hvc* on a cuttlefish device Change-Id: Id07c25bded35dac5d17736731bfd8b8f4f1d463b Signed-off-by: A. Cody Schuffelen <schuffelen@google.com> |
||
Roderick Colenbrander
|
7b7c361b98 |
UPSTREAM: HID: playstation: support updated DualSense rumble mode.
Newer DualSense firmware supports a revised classic rumble mode, which feels more similar to rumble as supported on previous PlayStation controllers. It has been made the default on PlayStation and non-PlayStation devices now (e.g. iOS and Windows). Default to this new mode when supported. Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20221010212313.78275-4-roderick.colenbrander@sony.com Bug: 260685629 (cherry picked from commit 9fecab247ed15e6145c126fc56ee1e89860741a7) Change-Id: Icd330111a4d1b1e76a04cd11c623d0982ce3d66f Signed-off-by: Farid Chahla <farid.chahla@sony.com> |
||
|
Roderick Colenbrander
|
ff79b92f34 |
UPSTREAM: HID: playstation: add initial DualSense Edge controller support
Provide initial support for the DualSense Edge controller. The brings support up to the level of the original DualSense, but won't yet provide support for new features (e.g. reprogrammable buttons). Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com> CC: stable@vger.kernel.org Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20221010212313.78275-3-roderick.colenbrander@sony.com Bug: 260685629 (cherry picked from commit b8a968efab301743fd659b5649c5d7d3e30e63a6) Change-Id: I5b95de806e823085d1144f016d8cfd76e4a933ef Signed-off-by: Farid Chahla <farid.chahla@sony.com> |
||
|
Roderick Colenbrander
|
9c127a4a06 |
UPSTREAM: HID: playstation: stop DualSense output work on remove.
Ensure we don't schedule any new output work on removal and wait for any existing work to complete. If we don't do this e.g. rumble work can get queued during deletion and we trigger a kernel crash. Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com> CC: stable@vger.kernel.org Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20221010212313.78275-2-roderick.colenbrander@sony.com Bug: 260685629 (cherry picked from commit 182934a1e93b17f4edf71f4fcc8d19b19a6fe67a) Change-Id: I40cadfde5765cdabf45def929860258d6019bf10 Signed-off-by: Farid Chahla <farid.chahla@sony.com> |
||
Greg Kroah-Hartman
|
b32bdd3e88 |
UPSTREAM: HID: playstation: convert to use dev_groups
There is no need for a driver to individually add/create device groups, the driver core will do it automatically for you. Convert the hid-playstation driver to use the dev_groups pointer instead of manually calling the driver core to create the group and have it be cleaned up later on by the devm core. Cc: Roderick Colenbrander <roderick.colenbrander@sony.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: linux-input@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Roderick Colenbrander <roderick.colenbrander@sony.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Bug: 260685629 (cherry picked from commit b4a9af9be628e4f9d09997e0bdef30f6718e88ec) Change-Id: I516a1b0ef7f4f8545e0c1b9485b49879dd7a3136 Signed-off-by: Farid Chahla <farid.chahla@sony.com> |
||
Jiri Kosina
|
c1ac1f8001 |
UPSTREAM: HID: playstation: fix return from dualsense_player_led_set_brightness()
brightness_set_blocking() callback expects function returning int. This fixes the follwoing build failure: drivers/hid/hid-playstation.c: In function ‘dualsense_player_led_set_brightness’: drivers/hid/hid-playstation.c:885:1: error: no return statement in function returning non-void [-Werror=return-type] } ^ Signed-off-by: Jiri Kosina <jkosina@suse.cz> Bug: 260685629 (cherry picked from commit 3c92cb4cb60c71b574e47108ead8b6f0470850db) Change-Id: Id16b960826a26ac22c1a14572444f9af29689ed6 Signed-off-by: Farid Chahla <farid.chahla@sony.com> |
||
|
Roderick Colenbrander
|
d44545535e |
UPSTREAM: HID: playstation: expose DualSense player LEDs through LED class.
The DualSense player LEDs were so far not adjustable from user-space. This patch exposes each LED individually through the LED class. Each LED uses the new 'player' function resulting in a name like: 'inputX:white:player-1' for the first LED. Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Bug: 260685629 (cherry picked from commit 8c0ab553b072025530308f74b2c0223ec50dffe5) Change-Id: I49c699a99b0b8a7bb7980560e3ea7a12faf646aa Signed-off-by: Farid Chahla <farid.chahla@sony.com> |
||
|
Roderick Colenbrander
|
07dd46d289 |
BACKPORT: leds: add new LED_FUNCTION_PLAYER for player LEDs for game controllers.
Player LEDs are commonly found on game controllers from Nintendo and Sony to indicate a player ID across a number of LEDs. For example, "Player 2" might be indicated as "-x--" on a device with 4 LEDs where "x" means on. This patch introduces LED_FUNCTION_PLAYER1-5 defines to properly indicate player LEDs from the kernel. Until now there was no good standard, which resulted in inconsistent behavior across xpad, hid-sony, hid-wiimote and other drivers. Moving forward new drivers should use LED_FUNCTION_PLAYERx. Note: management of Player IDs is left to user space, though a kernel driver may pick a default value. Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Bug: 260685629 (cherry picked from commit 61177c088a57bed259122f3c7bc6d61984936a12) [Farid: Fixed minor conflict due to skipped commits outside scope of hid-playstation] Change-Id: I696f62cda377be1523e74e92b66b28f3c0716c43 Signed-off-by: Farid Chahla <farid.chahla@sony.com> |
||
|
Roderick Colenbrander
|
f91c45c176 |
UPSTREAM: HID: playstation: expose DualSense lightbar through a multi-color LED.
The DualSense lightbar has so far been supported, but it was not yet adjustable from user space. This patch exposes it through a multi-color LED. Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Bug: 260685629 (cherry picked from commit fc97b4d6a1a6d418fd4053fd7716eca746fdd163) Change-Id: I48204113da804b13ad5bed2f651a5826ab5a86f7 Signed-off-by: Farid Chahla <farid.chahla@sony.com> |
||
Gene Chen
|
749207d940 |
UPSTREAM: leds: flash: Fix multicolor no-ops registration by return 0
Fix multicolor no-ops registration by return 0, and move the same registration functions outside of #ifdef block. Signed-off-by: Gene Chen <gene_chen@richtek.com> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz> Bug: 260685629 (cherry picked from commit 6039b7e87be0b350a5f8fc135adfb5d1f4ba66ad) Change-Id: Ieb8cace2978f61bd2de5c576e851987c6ba31e2c Signed-off-by: Farid Chahla <farid.chahla@sony.com> |
||
Dan Murphy
|
3e667a0854 |
UPSTREAM: leds: multicolor: Introduce a multicolor class definition
Introduce a multicolor class that groups colored LEDs within a LED node. The multicolor class groups monochrome LEDs and allows controlling two aspects of the final combined color: hue and lightness. The former is controlled via the intensity file and the latter is controlled via brightness file. Signed-off-by: Dan Murphy <dmurphy@ti.com> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz> [squashed leds: multicolor: Fix camel case in documentation in] Bug: 260685629 (cherry picked from commit 55d5d3b46b08a4dc0b05343d24640744e7430ed7) Change-Id: Ib1f41d74ace8e3a9c1071d52202c8d8b70a912e0 Signed-off-by: Farid Chahla <farid.chahla@sony.com> |
||
Farid Chahla
|
0b5ee17e7d |
ANDROID: GKI: enable mulitcolor-led
To enable newer version of DualSense driver, i.e. hid-playstation, we need to set LEDS_CLASS_MULTICOLOR to "y". Bug: 260685629 Change-Id: I52b0b1b6a061457e009b62a6bd6b66a91c8c37a2 Signed-off-by: Farid Chahla <farid.chahla@sony.com> |
||
Lee Jones
|
0ce03d1655 |
BACKPORT: Kconfig.debug: provide a little extra FRAME_WARN leeway when KASAN is enabled
[ Upstream commit 152fe65f300e1819d59b80477d3e0999b4d5d7d2 ] When enabled, KASAN enlarges function's stack-frames. Pushing quite a few over the current threshold. This can mainly be seen on 32-bit architectures where the present limit (when !GCC) is a lowly 1024-Bytes. Bug: 261962742 Link: https://lkml.kernel.org/r/20221125120750.3537134-3-lee@kernel.org Signed-off-by: Lee Jones <lee@kernel.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@gmail.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Tom Rix <trix@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Change-Id: I505a5187220b426fe49c0f15bf1704198082f63d Signed-off-by: Lee Jones <joneslee@google.com> |
||
|
Lee Jones
|
20fb10aa4c |
UPSTREAM: bpf: Ensure correct locking around vulnerable function find_vpid()
[ Upstream commit 83c10cc362d91c0d8d25e60779ee52fdbbf3894d ]
The documentation for find_vpid() clearly states:
"Must be called with the tasklist_lock or rcu_read_lock() held."
Presently we do neither for find_vpid() instance in bpf_task_fd_query().
Add proper rcu_read_lock/unlock() to fix the issue.
Bug: 232939090
Fixes:
|
||
Hyunwoo Kim
|
0ec485223d |
UPSTREAM: HID: roccat: Fix use-after-free in roccat_read()
[ Upstream commit cacdb14b1c8d3804a3a7d31773bc7569837b71a4 ]
roccat_report_event() is responsible for registering
roccat-related reports in struct roccat_device.
int roccat_report_event(int minor, u8 const *data)
{
struct roccat_device *device;
struct roccat_reader *reader;
struct roccat_report *report;
uint8_t *new_value;
device = devices[minor];
new_value = kmemdup(data, device->report_size, GFP_ATOMIC);
if (!new_value)
return -ENOMEM;
report = &device->cbuf[device->cbuf_end];
/* passing NULL is safe */
kfree(report->value);
...
The registered report is stored in the struct roccat_device member
"struct roccat_report cbuf[ROCCAT_CBUF_SIZE];".
If more reports are received than the "ROCCAT_CBUF_SIZE" value,
kfree() the saved report from cbuf[0] and allocates a new reprot.
Since there is no lock when this kfree() is performed,
kfree() can be performed even while reading the saved report.
static ssize_t roccat_read(struct file *file, char __user *buffer,
size_t count, loff_t *ppos)
{
struct roccat_reader *reader = file->private_data;
struct roccat_device *device = reader->device;
struct roccat_report *report;
ssize_t retval = 0, len;
DECLARE_WAITQUEUE(wait, current);
mutex_lock(&device->cbuf_lock);
...
report = &device->cbuf[reader->cbuf_start];
/*
* If report is larger than requested amount of data, rest of report
* is lost!
*/
len = device->report_size > count ? count : device->report_size;
if (copy_to_user(buffer, report->value, len)) {
retval = -EFAULT;
goto exit_unlock;
}
...
The roccat_read() function receives the device->cbuf report and
delivers it to the user through copy_to_user().
If the N+ROCCAT_CBUF_SIZE th report is received while copying of
the Nth report->value is in progress, the pointer that copy_to_user()
is working on is kfree()ed and UAF read may occur. (race condition)
Since the device node of this driver does not set separate permissions,
this is not a security vulnerability, but because it is used for
requesting screen display of profile or dpi settings,
a user using the roccat device can apply udev to this device node or
There is a possibility to use it by giving.
Bug: 251067658
Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I90b24df9216ab87a4fec0ab06fa52e7b1eb97fd1
|
||
Charan Teja Kalla
|
cbbd724281 |
ANDROID: arm64: mm: perform clean & invalidation in __dma_map_area
commit c50f11c6196f ("arm64: mm: Don't invalidate FROM_DEVICE buffers at
start of DMA transfer") break assumptions of some device drivers about
invalidation that happens as part of __dma_map_area(DMA_FROM_DEVICE). An
example include drivers using dmabuf API dma_buf_begin_cpu_access() and
dma_buf_end_cpu_access() to achieve buffer invalidation. Fix this breakage
by replacing clean with clean and invalidation in __dma_map_area() for
DMA inbound case.
Bug: 260978220
Change-Id: Id1a2750c2036de693cd52e8f7316f1d820b5a262
Fixes: c50f11c6196f ("arm64: mm: Don't invalidate FROM_DEVICE buffers at start of DMA transfer")
Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>
Signed-off-by: Shiraz Hashim <quic_shashim@quicinc.com>
Signed-off-by: Prakash Gupta <quic_guptap@quicinc.com>
Signed-off-by: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
|
||
Greg Kroah-Hartman
|
4338018da7 |
Merge tag 'android11-5.4.219_r00' into android11-5.4
This is the merge of the upstream LTS release of 5.4.219 into the android11-5.4 branch. It contains the following commits: |
||
Wenchao Chen
|
a6768f02c5 |
UPSTREAM: mmc: hsq: Fix data stomping during mmc recovery
The block device uses multiple queues to access emmc. There will be up to 3
requests in the hsq of the host. The current code will check whether there
is a request doing recovery before entering the queue, but it will not check
whether there is a request when the lock is issued. The request is in recovery
mode. If there is a request in recovery, then a read and write request is
initiated at this time, and the conflict between the request and the recovery
request will cause the data to be trampled.
Bug: 254441685
Signed-off-by: Wenchao Chen <wenchao.chen@unisoc.com>
Fixes: 511ce378e16f ("mmc: Add MMC host software queue support")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220916090506.10662-1-wenchao.chen666@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit e7afa79a3b35a27a046a2139f8b20bd6b98155c2)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I031ad3f8e41937a6285926f9b87592f510ba9d7c
|
||
Michael Wu
|
c08e708d2b |
UPSTREAM: pinctrl: sunxi: Fix name for A100 R_PIO
The name of A100 R_PIO driver should be sun50i-a100-r-pinctrl,
not sun50iw10p1-r-pinctrl.
Bug: 254441685
Fixes: 473436e7647d6 ("pinctrl: sunxi: add support for the Allwinner A100 pin controller")
Signed-off-by: Michael Wu <michael@allwinnertech.com>
Acked-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20220819024541.74191-1-michael@allwinnertech.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 76648c867c6c03b8a468d9c9222025873ecc613d)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I0499eb9db03b7b1c267c722b7f620e427d207850
|
||
Adrian Hunter
|
b45868d624 |
BACKPORT: mmc: core: Fix UHS-I SD 1.8V workaround branch
When introduced, upon success, the 1.8V fixup workaround in
mmc_sd_init_card() would branch to practically the end of the function, to
a label named "done". Unfortunately, perhaps due to the label name, over
time new code has been added that really should have come after "done" not
before it. Let's fix the problem by moving the label to the correct place
and rename it "cont".
Bug: 254441685
Fixes: 045d705dc1fb ("mmc: core: Enable the MMC host software queue for the SD card")
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Seunghui Lee <sh043.lee@samsung.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220815073321.63382-2-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit 15c56208c79c340686869c31595c209d1431c5e8)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I95b5445f74710ac4623611efb7f3cba59b2264a9
|
||
Luiz Augusto von Dentz
|
4f0ce36d86 |
UPSTREAM: Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm regression
The patch d0be8347c623: "Bluetooth: L2CAP: Fix use-after-free caused
by l2cap_chan_put" from Jul 21, 2022, leads to the following Smatch
static checker warning:
net/bluetooth/l2cap_core.c:1977 l2cap_global_chan_by_psm()
error: we previously assumed 'c' could be null (see line 1996)
Bug: 254441685
Fixes: d0be8347c623 ("Bluetooth: L2CAP: Fix use-after-free caused by l2cap_chan_put")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
(cherry picked from commit 332f1795ca202489c665a75e62e18ff6284de077)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I20b471b7348f5907427918792e77fa7543da51a4
|
||
Johannes Berg
|
624ab3a0c0 |
UPSTREAM: wifi: mac80211_hwsim: set virtio device ready in probe()
Just like a similar commit to arch/um/drivers/virt-pci.c, call
virtio_device_ready() to make this driver work after commit
b4ec69d7e09 ("virtio: harden vring IRQ"), since the driver uses
the virtqueues in the probe function. (The virtio core sets
the device ready when probe returns.)
Bug: 254441685
Fixes: 8b4ec69d7e09 ("virtio: harden vring IRQ")
Fixes: 5d44fe7c9808 ("mac80211_hwsim: add frame transmission support over virtio")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Link: https://lore.kernel.org/r/20220613210401.327958-1-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
(cherry picked from commit 3f3558c8054f82950b6decf928738306f556edf3)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Ia813ad70f2aa9908d8756bcfe9be17f86a0f5ec2
|
||
Eric Biggers
|
de960e4e26 |
BACKPORT: f2fs: don't use casefolded comparison for "." and ".."
Tryng to rename a directory that has all following properties fails with
EINVAL and triggers the 'WARN_ON_ONCE(!fscrypt_has_encryption_key(dir))'
in f2fs_match_ci_name():
- The directory is casefolded
- The directory is encrypted
- The directory's encryption key is not yet set up
- The parent directory is *not* encrypted
The problem is incorrect handling of the lookup of ".." to get the
parent reference to update. fscrypt_setup_filename() treats ".." (and
".") specially, as it's never encrypted. It's passed through as-is, and
setting up the directory's key is not attempted. As the name isn't a
no-key name, f2fs treats it as a "normal" name and attempts a casefolded
comparison. That breaks the assumption of the WARN_ON_ONCE() in
f2fs_match_ci_name() which assumes that for encrypted directories,
casefolded comparisons only happen when the directory's key is set up.
We could just remove this WARN_ON_ONCE(). However, since casefolding is
always a no-op on "." and ".." anyway, let's instead just not casefold
these names. This results in the standard bytewise comparison.
Bug: 254441685
Fixes: 7ad08a58bf67 ("f2fs: Handle casefolding with Encryption")
Cc: <stable@vger.kernel.org> # v5.11+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit b5639bb4313b9d455fc9fc4768d23a5e4ca8cb9d)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Ib4b2519957e016898655936fc6137dd411b5b40c
|
||
Dong Aisheng
|
c219b2d3f5 |
UPSTREAM: Revert "mm/cma.c: remove redundant cma_mutex lock"
This reverts commit a4efc174b382fcdb which introduced a regression issue
that when there're multiple processes allocating dma memory in parallel by
calling dma_alloc_coherent(), it may fail sometimes as follows:
Error log:
cma: cma_alloc: linux,cma: alloc failed, req-size: 148 pages, ret: -16
cma: number of available pages:
3@125+20@172+12@236+4@380+32@736+17@2287+23@2473+20@36076+99@40477+108@40852+44@41108+20@41196+108@41364+108@41620+
108@42900+108@43156+483@44061+1763@45341+1440@47712+20@49324+20@49388+5076@49452+2304@55040+35@58141+20@58220+20@58284+
7188@58348+84@66220+7276@66452+227@74525+6371@75549=> 33161 free of 81920 total pages
When issue happened, we saw there were still 33161 pages (129M) free CMA
memory and a lot available free slots for 148 pages in CMA bitmap that we
want to allocate.
When dumping memory info, we found that there was also ~342M normal
memory, but only 1352K CMA memory left in buddy system while a lot of
pageblocks were isolated.
Memory info log:
Normal free:351096kB min:30000kB low:37500kB high:45000kB reserved_highatomic:0KB
active_anon:98060kB inactive_anon:98948kB active_file:60864kB inactive_file:31776kB
unevictable:0kB writepending:0kB present:1048576kB managed:1018328kB mlocked:0kB
bounce:0kB free_pcp:220kB local_pcp:192kB free_cma:1352kB lowmem_reserve[]: 0 0 0
Normal: 78*4kB (UECI) 1772*8kB (UMECI) 1335*16kB (UMECI) 360*32kB (UMECI) 65*64kB (UMCI)
36*128kB (UMECI) 16*256kB (UMCI) 6*512kB (EI) 8*1024kB (UEI) 4*2048kB (MI) 8*4096kB (EI)
8*8192kB (UI) 3*16384kB (EI) 8*32768kB (M) = 489288kB
The root cause of this issue is that since commit a4efc174b382 ("mm/cma.c:
remove redundant cma_mutex lock"), CMA supports concurrent memory
allocation. It's possible that the memory range process A trying to alloc
has already been isolated by the allocation of process B during memory
migration.
The problem here is that the memory range isolated during one allocation
by start_isolate_page_range() could be much bigger than the real size we
want to alloc due to the range is aligned to MAX_ORDER_NR_PAGES.
Taking an ARMv7 platform with 1G memory as an example, when
MAX_ORDER_NR_PAGES is big (e.g. 32M with max_order 14) and CMA memory is
relatively small (e.g. 128M), there're only 4 MAX_ORDER slot, then it's
very easy that all CMA memory may have already been isolated by other
processes when one trying to allocate memory using dma_alloc_coherent().
Since current CMA code will only scan one time of whole available CMA
memory, then dma_alloc_coherent() may easy fail due to contention with
other processes.
This patch simply falls back to the original method that using cma_mutex
to make alloc_contig_range() run sequentially to avoid the issue.
Bug: 254441685
Link: https://lkml.kernel.org/r/20220509094551.3596244-1-aisheng.dong@nxp.com
Link: https://lore.kernel.org/all/20220315144521.3810298-2-aisheng.dong@nxp.com/
Fixes: a4efc174b382 ("mm/cma.c: remove redundant cma_mutex lock")
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Acked-by: David Hildenbrand <david@redhat.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Lecopzer Chen <lecopzer.chen@mediatek.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: <stable@vger.kernel.org> [5.11+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 60a60e32cf91169840abcb4a80f0b0df31708ba7)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Ie0bcde1f809dbaf34d4cf56d564c3c4a76be2931
|
||
Sven Peter
|
bcbaf126b8 |
UPSTREAM: usb: dwc3: Try usb-role-switch first in dwc3_drd_init
If the PHY controller node has a "port" dwc3 tries to find an
extcon device even when "usb-role-switch" is present. This happens
because dwc3_get_extcon() sees that "port" node and then calls
extcon_find_edev_by_node() which will always return EPROBE_DEFER
in that case.
On the other hand, even if an extcon was present and dwc3_get_extcon()
was successful it would still be ignored in favor of "usb-role-switch".
Let's just first check if "usb-role-switch" is configured in the device
tree and directly use it instead and only try to look for an extcon
device otherwise.
Bug: 254441685
Fixes: 8a0a13799744 ("usb: dwc3: Registering a role switch in the DRD code.")
Cc: stable <stable@kernel.org>
Signed-off-by: Sven Peter <sven@svenpeter.dev>
Link: https://lore.kernel.org/r/20220411155300.9766-1-sven@svenpeter.dev
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit ab7aa2866d295438dc60522f85c5421c6b4f1507)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I394fbcaf90a5a37b3a22c309dd46fd46d7510442
|
||
Heikki Krogerus
|
2117e7c78a |
BACKPORT: usb: typec: ucsi: Fix reuse of completion structure
The role swapping completion variable is reused, so it needs to be reinitialised every time. Otherwise it will be marked as done after the first time it's used and completing immediately. Bug: 254441685 Link: https://lore.kernel.org/linux-usb/20220325203959.GA19752@jackp-linux.qualcomm.com/ Fixes: 6df475f804e6 ("usb: typec: ucsi: Start using struct typec_operations") Cc: stable@vger.kernel.org Reported-and-suggested-by: Jack Pham <quic_jackp@quicinc.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20220405134824.68067-2-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit e25adcca917d7e4cdc1dc6444d0692ffda7594bf) Signed-off-by: Lee Jones <joneslee@google.com> Change-Id: I2213ab8733a17495198c09fbf990ecc9de991ab2 |
||
Tung Nguyen
|
ef283814b2 |
BACKPORT: tipc: fix incorrect order of state message data sanity check
When receiving a state message, function tipc_link_validate_msg()
is called to validate its header portion. Then, its data portion
is validated before it can be accessed correctly. However, current
data sanity check is done after the message header is accessed to
update some link variables.
This commit fixes this issue by moving the data sanity check to
the beginning of state message handling and right after the header
sanity check.
Bug: 254441685
Fixes: 9aa422ad3266 ("tipc: improve size validations for received domain records")
Acked-by: Jon Maloy <jmaloy@redhat.com>
Signed-off-by: Tung Nguyen <tung.q.nguyen@dektech.com.au>
Link: https://lore.kernel.org/r/20220308021200.9245-1-tung.q.nguyen@dektech.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit c79fcc27be90b308b3fa90811aefafdd4078668c)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: If6cff72e268879445b388c957810263c59488718
|
||
lena wang
|
c5f9da53b8 |
UPSTREAM: net: fix up skbs delta_truesize in UDP GRO frag_list
The truesize for a UDP GRO packet is added by main skb and skbs in main
skb's frag_list:
skb_gro_receive_list
p->truesize += skb->truesize;
The commit 53475c5dd856 ("net: fix use-after-free when UDP GRO with
shared fraglist") introduced a truesize increase for frag_list skbs.
When uncloning skb, it will call pskb_expand_head and trusesize for
frag_list skbs may increase. This can occur when allocators uses
__netdev_alloc_skb and not jump into __alloc_skb. This flow does not
use ksize(len) to calculate truesize while pskb_expand_head uses.
skb_segment_list
err = skb_unclone(nskb, GFP_ATOMIC);
pskb_expand_head
if (!skb->sk || skb->destructor == sock_edemux)
skb->truesize += size - osize;
If we uses increased truesize adding as delta_truesize, it will be
larger than before and even larger than previous total truesize value
if skbs in frag_list are abundant. The main skb truesize will become
smaller and even a minus value or a huge value for an unsigned int
parameter. Then the following memory check will drop this abnormal skb.
To avoid this error we should use the original truesize to segment the
main skb.
Bug: 254441685
Fixes: 53475c5dd856 ("net: fix use-after-free when UDP GRO with shared fraglist")
Signed-off-by: lena wang <lena.wang@mediatek.com>
Acked-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/1646133431-8948-1-git-send-email-lena.wang@mediatek.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 224102de2ff105a2c05695e66a08f4b5b6b2d19c)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Id29a1108ec7fa4d50992236c291bb143688d4332
|
||
Michal Koutný
|
f644f48276 |
UPSTREAM: cgroup-v1: Correct privileges check in release_agent writes
The idea is to check: a) the owning user_ns of cgroup_ns, b)
capabilities in init_user_ns.
The commit 24f600856418 ("cgroup-v1: Require capabilities to set
release_agent") got this wrong in the write handler of release_agent
since it checked user_ns of the opener (may be different from the owning
user_ns of cgroup_ns).
Secondly, to avoid possibly confused deputy, the capability of the
opener must be checked.
Bug: 254441685
Fixes: 24f600856418 ("cgroup-v1: Require capabilities to set release_agent")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/stable/20220216121142.GB30035@blackbody.suse.cz/
Signed-off-by: Michal Koutný <mkoutny@suse.com>
Reviewed-by: Masami Ichikawa(CIP) <masami.ichikawa@cybertrust.co.jp>
Signed-off-by: Tejun Heo <tj@kernel.org>
(cherry picked from commit 467a726b754f474936980da793b4ff2ec3e382a7)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I486cd82ec93faca71107dcdc21de6f8aa422daf5
|
||
|
Linus Torvalds
|
cb59d054a9 |
UPSTREAM: mm: don't try to NUMA-migrate COW pages that have other uses
Oded Gabbay reports that enabling NUMA balancing causes corruption with
his Gaudi accelerator test load:
"All the details are in the bug, but the bottom line is that somehow,
this patch causes corruption when the numa balancing feature is
enabled AND we don't use process affinity AND we use GUP to pin pages
so our accelerator can DMA to/from system memory.
Either disabling numa balancing, using process affinity to bind to
specific numa-node or reverting this patch causes the bug to
disappear"
and Oded bisected the issue to commit 09854ba94c6a ("mm: do_wp_page()
simplification").
Now, the NUMA balancing shouldn't actually be changing the writability
of a page, and as such shouldn't matter for COW. But it appears it
does. Suspicious.
However, regardless of that, the condition for enabling NUMA faults in
change_pte_range() is nonsensical. It uses "page_mapcount(page)" to
decide if a COW page should be NUMA-protected or not, and that makes
absolutely no sense.
The number of mappings a page has is irrelevant: not only does GUP get a
reference to a page as in Oded's case, but the other mappings migth be
paged out and the only reference to them would be in the page count.
Since we should never try to NUMA-balance a page that we can't move
anyway due to other references, just fix the code to use 'page_count()'.
Oded confirms that that fixes his issue.
Now, this does imply that something in NUMA balancing ends up changing
page protections (other than the obvious one of making the page
inaccessible to get the NUMA faulting information). Otherwise the COW
simplification wouldn't matter - since doing the GUP on the page would
make sure it's writable.
The cause of that permission change would be good to figure out too,
since it clearly results in spurious COW events - but fixing the
nonsensical test that just happened to work before is obviously the
CorrectThing(tm) to do regardless.
Bug: 254441685
Fixes: 09854ba94c6a ("mm: do_wp_page() simplification")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215616
Link: https://lore.kernel.org/all/CAFCwf10eNmwq2wD71xjUhqkvv5+_pJMR1nPug2RqNDcFT4H86Q@mail.gmail.com/
Reported-and-tested-by: Oded Gabbay <oded.gabbay@gmail.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Peter Xu <peterx@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 80d47f5de5e311cbc0d01ebb6ee684e8f4c196c6)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I490544efe86c2c8bc9d297135bad7d2ceab4686e
|
||
Jann Horn
|
e4d47f2da1 |
UPSTREAM: usb: raw-gadget: fix handling of dual-direction-capable endpoints
Under dummy_hcd, every available endpoint is *either* IN or OUT capable.
But with some real hardware, there are endpoints that support both IN and
OUT. In particular, the PLX 2380 has four available endpoints that each
support both IN and OUT.
raw-gadget currently gets confused and thinks that any endpoint that is
usable as an IN endpoint can never be used as an OUT endpoint.
Fix it by looking at the direction in the configured endpoint descriptor
instead of looking at the hardware capabilities.
With this change, I can use the PLX 2380 with raw-gadget.
Bug: 254441685
Fixes: f2c2e717642c ("usb: gadget: add raw-gadget interface")
Cc: stable <stable@vger.kernel.org>
Tested-by: Andrey Konovalov <andreyknvl@gmail.com>
Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
Signed-off-by: Jann Horn <jannh@google.com>
Link: https://lore.kernel.org/r/20220126205214.2149936-1-jannh@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 292d2c82b105d92082c2120a44a58de9767e44f1)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I2c6dc54803a9c619dc0ba144df5e374d02f6cf3f
|
||
Christian Göttsche
|
2119237920 |
UPSTREAM: selinux: check return value of sel_make_avc_files
sel_make_avc_files() might fail and return a negative errno value on
memory allocation failures. Re-add the check of the return value,
dropped in 66f8e2f03c02 ("selinux: sidtab reverse lookup hash table").
Reported by clang-analyzer:
security/selinux/selinuxfs.c:2129:2: warning: Value stored to
'ret' is never read [deadcode.DeadStores]
ret = sel_make_avc_files(dentry);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~
Bug: 254441685
Fixes: 66f8e2f03c02 ("selinux: sidtab reverse lookup hash table")
Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
[PM: description line wrapping, added proper commit ref]
Signed-off-by: Paul Moore <paul@paul-moore.com>
(cherry picked from commit bcb62828e3e8c813b6613db6eb7fd9657db248fc)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Id75241f6c1c3b501bda6160cee9be1a9c3b83fd3
|
||
Randy Dunlap
|
517330573a |
UPSTREAM: usb: musb: select GENERIC_PHY instead of depending on it
The kconfig symbol GENERIC_PHY says:
All the users of this framework should select this config.
and around 136 out of 138 drivers do so, so change USB_MUSB_MEDIATEK
to do so also.
This (also) fixes a long circular dependency problem for an upcoming
patch.
Bug: 254441685
Fixes: 0990366bab3c ("usb: musb: Add support for MediaTek musb controller")
Cc: Bin Liu <b-liu@ti.com>
Cc: Min Guo <min.guo@mediatek.com>
Cc: Yonglong Wu <yonglong.wu@mediatek.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-mediatek@lists.infradead.org
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20211005235747.5588-1-rdunlap@infradead.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit fde1fbedbaed4e76cef4600d775b185f59b9b568)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I02720a673793a41ac939d3a909b131fc1d060df4
|
||
Zhen Lei
|
e233e13e47 |
BACKPORT: driver core: Fix error return code in really_probe()
In the case of error handling, the error code returned by the subfunction should be propagated instead of 0. Bug: 254441685 Fixes: |
||
|
Eric Biggers
|
fb4622ee74 |
UPSTREAM: fscrypt: fix derivation of SipHash keys on big endian CPUs
Typically, the cryptographic APIs that fscrypt uses take keys as byte
arrays, which avoids endianness issues. However, siphash_key_t is an
exception. It is defined as 'u64 key[2];', i.e. the 128-bit key is
expected to be given directly as two 64-bit words in CPU endianness.
fscrypt_derive_dirhash_key() and fscrypt_setup_iv_ino_lblk_32_key()
forgot to take this into account. Therefore, the SipHash keys used to
index encrypted+casefolded directories differ on big endian vs. little
endian platforms, as do the SipHash keys used to hash inode numbers for
IV_INO_LBLK_32-encrypted directories. This makes such directories
non-portable between these platforms.
Fix this by always using the little endian order. This is a breaking
change for big endian platforms, but this should be fine in practice
since these features (encrypt+casefold support, and the IV_INO_LBLK_32
flag) aren't known to actually be used on any big endian platforms yet.
Bug: 254441685
Fixes: aa408f835d02 ("fscrypt: derive dirhash key for casefolded directories")
Fixes: e3b1078bedd3 ("fscrypt: add support for IV_INO_LBLK_32 policies")
Cc: <stable@vger.kernel.org> # v5.6+
Link: https://lore.kernel.org/r/20210605075033.54424-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 2fc2b430f559fdf32d5d1dd5ceaa40e12fb77bdf)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I03555845a827b693fadaf1d61aa3977cd4ed9ecd
|
||
|
Eric Biggers
|
c8bc35f2f6 |
BACKPORT: fscrypt: rename FS_KEY_DERIVATION_NONCE_SIZE
The name "FS_KEY_DERIVATION_NONCE_SIZE" is a bit outdated since due to the addition of FSCRYPT_POLICY_FLAG_DIRECT_KEY, the file nonce may now be used as a tweak instead of for key derivation. Also, we're now prefixing the fscrypt constants with "FSCRYPT_" instead of "FS_". Therefore, rename this constant to FSCRYPT_FILE_NONCE_SIZE. Bug: 254441685 Link: https://lore.kernel.org/r/20200708215722.147154-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com> [Lee: Back-ported to solve a dependency issue] (cherry picked from commit 1d6217a4f9905917ee63315c8ea3d63833792f51) Signed-off-by: Lee Jones <joneslee@google.com> Change-Id: I5eae506505d9432b95dabf620b79a6b8ca1e0d6a |
||
Jason A. Donenfeld
|
0aad586104 |
UPSTREAM: socionext: account for napi_gro_receive never returning GRO_DROP
The napi_gro_receive function no longer returns GRO_DROP ever, making
handling GRO_DROP dead code. This commit removes that dead code.
Further, it's not even clear that device drivers have any business in
taking action after passing off received packets; that's arguably out of
their hands.
Bug: 254441685
Fixes: 6570bc79c0df ("net: core: use listified Rx for GRO_NORMAL in napi_gro_receive()")
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 0c5378f9d5003334775ea0e5e9934976aa4a1b66)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Ic0e73a7ecd9ee0265459aea3f99895c9bb3d92ce
|
||
Lorenzo Bianconi
|
38f38545f7 |
UPSTREAM: net: socionext: netsec: fix xdp stats accounting
Increment netdev rx counters even for XDP_DROP verdict. Report even tx bytes for xdp buffers (TYPE_NETSEC_XDP_TX or TYPE_NETSEC_XDP_NDO). Moreover account pending buffer length in netsec_xdp_queue_one as it is done for skb counterpart Bug: 254441685 Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> [Lee: Back-ported to solve a dependency] (cherry picked from commit 0c5378f9d5003334775ea0e5e9934976aa4a1b66) Signed-off-by: Lee Jones <joneslee@google.com> Change-Id: Ia512f11529436aca74c23e70eb4edb8ee54e3fa3 |
||
Alessio Balsini
|
202bfe2b1f |
BACKPORT: fs: align IOCB_* flags with RWF_* flags
We have a set of flags that are shared between the two and inherired
in kiocb_set_rw_flags(), but we check and set these individually.
Reorder the IOCB flags so that the bottom part of the space is synced
with the RWF flag space, and then we can do them all in one mask and
set operation.
The only exception is RWF_SYNC, which needs to mark IOCB_SYNC and
IOCB_DSYNC. Do that one separately.
This shaves 15 bytes of text from kiocb_set_rw_flags() for me.
In Android this is required by the FUSE passthrough patches as
8bcc2d697908 ("FROMLIST: fs: Generic function to convert iocb to rw
flags") relies on the alignment of RWF and IOCB flags.
Bug: 254441685
(cherry picked from commit ce71bfea207b4d7c21d36f24ec37618ffcea1da8)
Suggested-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Change-Id: Ib6316ae5cb3f8a14fabef5492e79783c9e6d3c4d
Signed-off-by: Alessio Balsini <balsini@google.com>
Signed-off-by: Lee Jones <joneslee@google.com>
|
||
|
Hyunwoo Kim
|
141f8d76b3 |
UPSTREAM: efi: capsule-loader: Fix use-after-free in efi_capsule_write
commit 9cb636b5f6a8cc6d1b50809ec8f8d33ae0c84c95 upstream. A race condition may occur if the user calls close() on another thread during a write() operation on the device node of the efi capsule. This is a race condition that occurs between the efi_capsule_write() and efi_capsule_flush() functions of efi_capsule_fops, which ultimately results in UAF. So, the page freeing process is modified to be done in efi_capsule_release() instead of efi_capsule_flush(). Bug: 246690517 Cc: <stable@vger.kernel.org> # v4.9+ Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com> Link: https://lore.kernel.org/all/20220907102920.GA88602@ubuntu/ Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Lee Jones <joneslee@google.com> Change-Id: I6b11df91a87c027ebed4a7b239610a9b9e28cec0 |
||
Ard Biesheuvel
|
d4d1f95c4b |
BACKPORT: ARM: 9039/1: assembler: generalize byte swapping macro into rev_l
Take the 4 instruction byte swapping sequence from the decompressor's head.S, and turn it into a rev_l GAS macro for general use. While at it, make it use the 'rev' instruction when compiling for v6 or later. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> (cherry picked from commit 6468e898c67b905ec0f95d9678929135bcaf7f67) (resolved conflict due to different patch context, caused by missing other macros in assembler.h) Bug: 178411248 Change-Id: I8433e97d2880f75cace215f1a8daadec7f29929c Signed-off-by: Eric Biggers <ebiggers@google.com> |
||
Geert Uytterhoeven
|
28066cfbc9 |
BACKPORT: ARM: 9035/1: uncompress: Add be32tocpu macro
DTB stores all values as 32-bit big-endian integers. Add a macro to convert such values to native CPU endianness, to reduce duplication. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> (cherry picked from commit 0557ac83fd1a0a7cd6909665bad50006507115a0) (resolved conflict due to different patch context, caused by missing "ARM: 9010/1: uncompress: Print the location of appended DTB") Bug: 178411248 Change-Id: I0807f36352dbfd5f5808959e358a7469dc9753bb Signed-off-by: Eric Biggers <ebiggers@google.com> |
||
Sai Prakash Ranjan
|
cc190ff2f8 |
UPSTREAM: drm/meson: Fix overflow implicit truncation warnings
[ Upstream commit 98692f52c588225034cbff458622c2c06dfcb544 ]
Fix -Woverflow warnings for drm/meson driver which is a result
of moving arm64 custom MMIO accessor macros to asm-generic function
implementations giving a bonus type-checking now and uncovering these
overflow warnings.
drivers/gpu/drm/meson/meson_viu.c: In function ‘meson_viu_init’:
drivers/gpu/drm/meson/meson_registers.h:1826:48: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
#define VIU_OSD_BLEND_REORDER(dest, src) ((src) << (dest * 4))
^
drivers/gpu/drm/meson/meson_viu.c:472:18: note: in expansion of macro ‘VIU_OSD_BLEND_REORDER’
writel_relaxed(VIU_OSD_BLEND_REORDER(0, 1) |
^~~~~~~~~~~~~~~~~~~~~
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Sai Prakash Ranjan <quic_saipraka@quicinc.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fixes:
|
||
|
Sai Prakash Ranjan
|
0d0c1b2686 |
UPSTREAM: irqchip/tegra: Fix overflow implicit truncation warnings
[ Upstream commit 443685992bda9bb4f8b17fc02c9f6c60e62b1461 ]
Fix -Woverflow warnings for tegra irqchip driver which is a result
of moving arm64 custom MMIO accessor macros to asm-generic function
implementations giving a bonus type-checking now and uncovering these
overflow warnings.
drivers/irqchip/irq-tegra.c: In function ‘tegra_ictlr_suspend’:
drivers/irqchip/irq-tegra.c:151:18: warning: large integer implicitly truncated to unsigned type [-Woverflow]
writel_relaxed(~0ul, ictlr + ICTLR_COP_IER_CLR);
^
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Sai Prakash Ranjan <quic_saipraka@quicinc.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Cc: Marc Zyngier <maz@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fixes:
|