For now, only support set_memory_ro()/rw() which we need for
the stack protection in the next patch.
Bug: 176213565
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
(cherry picked from commit 963285b0b4)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I0e155cbad90a35cd495414475c16f37a60c4004d
If there is some kind of interrupt negotation or such then
it may happen that we send an update message multiple times,
avoid that in the interest of efficiency by storing the last
transmitted value and only sending a new update if it's not
the same as the last update.
Bug: 176213565
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
(cherry picked from commit 58b09f6869)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ie67941f51f7cb927cbef3515269661d4e27174b8
UML userspace fetches siginfo and passes it to signal handlers
in UML. This is needed only for some of the signals, because
key handlers like SIGIO make no use of this variable.
Bug: 176213565
Signed-off-by: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
(cherry picked from commit 3c6ac61bc9)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I1451aa9e6bb6354fbfc476a5eb2b2f0dc80b5cfe
With all the previous bits in place, we can now also support
suspend to RAM, in the sense that everything is suspended,
not just most, including userspace, processes like in s2idle.
Since um_idle_sleep() now waits forever, we can simply call
that to "suspend" the system.
As before, you can wake it up using SIGUSR1 since we're just
in a pause() call that only needs to return.
In order to implement selective resume from certain devices,
and not have any arbitrary device interrupt wake up, suspend
interrupts by removing SIGIO notification (O_ASYNC) from all
the FDs that are not supposed to wake up the system. However,
swap out the handler so we don't actually handle the SIGIO as
an interrupt.
Since we're in pause(), the mere act of receiving SIGIO wakes
us up, and then after things have been restored enough, re-set
O_ASYNC for all previously suspended FDs, reinstall the proper
SIGIO handler, and send SIGIO to self to process anything that
might now be pending.
Bug: 176213565
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
(cherry picked from commit a374b7cb1e)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ib255457aec8421e63d790022b98ded4e09dfa3b8
In order to be able to experiment with suspend in UML, add the
minimal work to be able to suspend (s2idle) an instance of UML,
and be able to wake it back up from that state with the USR1
signal sent to the main UML process.
Bug: 176213565
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
(cherry picked from commit 92dcd3d318)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I792845d02a9c558098cc40da1268a02806aae2d7
In time-travel mode, we've relied on read_persistent_clock64()
being called only once at system startup, but this is both the
right thing to call from the pseudo-RTC, and also gets called
by the timekeeping core during suspend/resume.
Thus, fix this to always fall make use of the time_travel_time
in any time-travel mode, initializing time_travel_start at boot
to the right value depending on the time-travel mode.
Bug: 176213565
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
(cherry picked from commit 2701c1bd91)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9956e6ddbd060795f72dd6543d3ab84a2bf66b21
There really is no reason to pass the amount of time we should
sleep, especially since it's just hard-coded to one second.
Additionally, one second isn't really all that long, and as we
are expecting to be woken up by a signal, we can sleep longer
and avoid doing some work every second, so replace the current
clock_nanosleep() with just an empty select() that can _only_
be woken up by a signal.
We can also remove the deliver_alarm() since we don't need to
do that when we got e.g. SIGIO that woke us up, and if we got
SIGALRM the signal handler will actually (have) run, so it's
just unnecessary extra work.
Similarly, in time-travel mode, just program the wakeup event
from idle to be S64_MAX, which is basically the most you could
ever simulate to. Of course, you should already have an event
in the list that's earlier and will cause a wakeup, normally
that's the regular timer interrupt, though in suspend it may
(later) also be an RTC event. Since actually getting to this
point would be a bug and you can't ever get out again, panic()
on it in the time control code.
Bug: 176213565
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
(cherry picked from commit 49da38a3ef)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I25f17aab00dc68ba78757df5d406e7e2edf617b0
Reduce dynamic allocations (and thereby cache misses) by simply
embedding the registration data for IRQs in the irq_entry, we
never supported these being really dynamic anyway as only one
was ever allowed ("Trying to reregister ...").
Lockless behaviour is preserved by removing the FD from the poll
set appropriately, but we use reg->events to indicate whether or
not this entry is used, rather than dynamically allocating them.
Also port the list of IRQ entries to list_head instead of the
current open-coded singly-linked list implementation, just for
sanity.
Bug: 176213565
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
(cherry picked from commit 3032b94587)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ia8165f6772d57a4510055d5096f96053a7315791
We don't actually use this in um_request_irq(), so it can
never be assigned. It's also not clear what that would be
useful for, so just remove it.
This results in quite a number of cleanups, all the way to
removing the "SIGIO on close" startup check, since the data
it assigns (pty_close_sigio) is not used anymore.
While at it, also make this an enum so we get a minimum of
type checking, and remove the IRQ_NONE hack in virtio since
we now no longer have the name twice.
Bug: 176213565
Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
(cherry picked from commit 2fccfcc0c7)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I53fac30f8791b68b003c86b7ffa6b9c2810382bc
We don't need an array of 4 entries to capture three and the
name 'MAX_IRQ_TYPE' really gets confusing as well. Remove it
and add a correct NUM_IRQ_TYPES, and use that correctly.
Bug: 176213565
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
(cherry picked from commit 0737402f42)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I3b1fda1f59db310bac3ce8db07658241ac267d18
This really shouldn't be called "irq_fd" since it doesn't
carry an fd. Well, it used to, apparently, but that struct
member is unused.
Rename it to "irq_reg" since it more accurately reflects a
registered interrupt, and remove the unused 'next' and 'fd'
members from the struct as well.
While at it, also move it to the implementation, it's not
used anywhere else, and the header file is shared with the
userspace components.
Bug: 176213565
Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
(cherry picked from commit 458e1f7da0)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I023d0cfc4f933b6808e61d2d964dabe24ee8f3eb
This separates the devices, which is better for debug and for
later suspend/resume and wakeup support, since there we'll
have to separate which IRQs can wake up the system and which
cannot.
Bug: 176213565
Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
(cherry picked from commit aaf5800e24)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I3d7f803cd662a2e36c40c4b670120047c19cc9a5
It's cumbersome and error-prone to keep adding fixed IRQ numbers,
and for proper device wakeup support for the virtio/vhost-user
support we need to have different IRQs for each device. Even if
in theory two IRQs (with and without wake) might be sufficient,
it's much easier to reason about it when we have dynamic number
assignment. It also makes it easier to add new devices that may
dynamically exist or depending on the configuration, etc.
Add support for this, up to 64 IRQs (the same limit as epoll FDs
we have right now). Since it's not easy to port all the existing
places to dynamic allocation (some data is statically initialized)
keep the low numbers are reserved for the existing hard-coded IRQ
numbers.
Bug: 176213565
Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
(cherry picked from commit 36d46a5907)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I02dd555a452942d8f7547f158a10d5372e7fa299
Adds the ability to set the UBD device serial number from the
commandline, disabling the serial number functionality by default.
In some cases it may be useful to set a serial to the UBD device, such
that downstream users (i.e. udev) can use this information to better
describe the hardware to the user from the UML cmdline. In our case we
use this parameter to create some entries under /dev/disk/by-ubd-id/
for each of the UBD devices passed through the UML cmdline.
Bug: 176213565
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
(cherry picked from commit ef3ba87cb7)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I6b5cd243dfdc1471f3a776780dd8bb1d6fd2a395
If we run out of space, return an error instead of 0.
Bug: 176213565
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
(cherry picked from commit d66c91836b)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I49c7b93b79f086ca21968c90b4e740048abe8e59
The signal.c can't use heap for bit data located on stack. However,
by default a compiler warns us about overstepping stack frame size
threshold:
arch/um/os-Linux/signal.c: In function ‘sig_handler_common’:
arch/um/os-Linux/signal.c:51:1: warning: the frame size of 2960 bytes is larger than 2048 bytes [-Wframe-larger-than=]
51 | }
| ^
arch/um/os-Linux/signal.c: In function ‘timer_real_alarm_handler’:
arch/um/os-Linux/signal.c:95:1: warning: the frame size of 2960 bytes is larger than 2048 bytes [-Wframe-larger-than=]
95 | }
| ^
Due to above increase stack frame size threshold explicitly for signal.c
to avoid unnecessary warning.
Bug: 176213565
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: David Gow <davidgow@google.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
(cherry picked from commit 517f60206e)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I8c46a93b315b65dbd2337a49655badde6810f3d1
Lockdep correctly complains that one shouldn't call um_free_irq()
with free_irq() inside under a spinlock since that will attempt
to acquire a mutex.
Rearrange the code to keep the list manipulations under the lock
while moving the actual freeing outside of it, to avoid this.
In particular, this removes the lockdep complaint at shutdown that
I was seeing with lockdep enabled.
Bug: 176213565
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-By: anton.ivanov@cambridgegreys.com
Signed-off-by: Richard Weinberger <richard@nod.at>
(cherry picked from commit f4ab7818ef)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I05c323dd19cf55273fc14adc36841e41207caeb3
Internally, UBD treats each physical IO segment as a separate command to
be submitted in the execution pipe. If the pipe returns a transient
error after a few segments have already been written, UBD will tell the
block layer to requeue the request, but there is no way to reclaim the
segments already submitted. When a new attempt to dispatch the request
is done, those segments already submitted will get duplicated, causing
the WARN_ON below in the best case, and potentially data corruption.
In my system, running a UML instance with 2GB of RAM and a 50M UBD disk,
I can reproduce the WARN_ON by simply running mkfs.fvat against the
disk on a freshly booted system.
There are a few ways to around this, like reducing the pressure on
the pipe by reducing the queue depth, which almost eliminates the
occurrence of the problem, increasing the pipe buffer size on the host
system, or by limiting the request to one physical segment, which causes
the block layer to submit way more requests to resolve a single
operation.
Instead, this patch modifies the format of a UBD command, such that all
segments are sent through a single element in the communication pipe,
turning the command submission atomic from the point of view of the
block layer. The new format has a variable size, depending on the
number of elements, and looks like this:
+------------+-----------+-----------+------------
| cmd_header | segment 0 | segment 1 | segment ...
+------------+-----------+-----------+------------
With this format, we push a pointer to cmd_header in the submission
pipe.
This has the advantage of reducing the memory footprint of executing a
single request, since it allow us to merge some fields in the header.
It is possible to reduce even further each segment memory footprint, by
merging bitmap_words and cow_offset, for instance, but this is not the
focus of this patch and is left as future work. One issue with the
patch is that for a big number of segments, we now perform one big
memory allocation instead of multiple small ones, but I wasn't able to
trigger any real issues or -ENOMEM because of this change, that wouldn't
be reproduced otherwise.
This was tested using fio with the verify-crc32 option, and by running
an ext4 filesystem over this UBD device.
The original WARN_ON was:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at lib/refcount.c:28 refcount_warn_saturate+0x13f/0x141
refcount_t: underflow; use-after-free.
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 5.5.0-rc6-00002-g2a5bb2cf75c8 #346
Stack:
6084eed0 6063dc77 00000009 6084ef60
00000000 604b8d9f 6084eee0 6063dcbc
6084ef40 6006ab8d e013d780 1c00000000
Call Trace:
[<600a0c1c>] ? printk+0x0/0x94
[<6004a888>] show_stack+0x13b/0x155
[<6063dc77>] ? dump_stack_print_info+0xdf/0xe8
[<604b8d9f>] ? refcount_warn_saturate+0x13f/0x141
[<6063dcbc>] dump_stack+0x2a/0x2c
[<6006ab8d>] __warn+0x107/0x134
[<6008da6c>] ? wake_up_process+0x17/0x19
[<60487628>] ? blk_queue_max_discard_sectors+0x0/0xd
[<6006b05f>] warn_slowpath_fmt+0xd1/0xdf
[<6006af8e>] ? warn_slowpath_fmt+0x0/0xdf
[<600acc14>] ? raw_read_seqcount_begin.constprop.0+0x0/0x15
[<600619ae>] ? os_nsecs+0x1d/0x2b
[<604b8d9f>] refcount_warn_saturate+0x13f/0x141
[<6048bc8f>] refcount_sub_and_test.constprop.0+0x2f/0x37
[<6048c8de>] blk_mq_free_request+0xf1/0x10d
[<6048ca06>] __blk_mq_end_request+0x10c/0x114
[<6005ac0f>] ubd_intr+0xb5/0x169
[<600a1a37>] __handle_irq_event_percpu+0x6b/0x17e
[<600a1b70>] handle_irq_event_percpu+0x26/0x69
[<600a1bd9>] handle_irq_event+0x26/0x34
[<600a1bb3>] ? handle_irq_event+0x0/0x34
[<600a5186>] ? unmask_irq+0x0/0x37
[<600a57e6>] handle_edge_irq+0xbc/0xd6
[<600a131a>] generic_handle_irq+0x21/0x29
[<60048f6e>] do_IRQ+0x39/0x54
[...]
---[ end trace c6e7444e55386c0f ]---
Bug: 176213565
Cc: Christopher Obbard <chris.obbard@collabora.com>
Reported-by: Martyn Welch <martyn@collabora.com>
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
Tested-by: Christopher Obbard <chris.obbard@collabora.com>
Acked-by: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
(cherry picked from commit fc6b6a872d)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5772030c5864103892cfb5e63b13650ddda5ccad
Since the time-travel rework, basic time-travel mode hasn't worked
properly, but there's no longer a need for this WARN_ON() so just
remove it and thereby fix things.
Bug: 176213565
Cc: stable@vger.kernel.org
Fixes: 4b786e24ca ("um: time-travel: Rewrite as an event scheduler")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
(cherry picked from commit ff9632d2a6)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iea83a52a7dff6514df64cbd35a71e6b2c186450d
asprintf is not compatible with the existing uml memory allocation
mechanism. Its use on the "user" side of UML results in a corrupt slab
state.
Bug: 176213565
Fixes: 0d4e5ac7e7 ("um: remove uses of variable length arrays")
Cc: stable@vger.kernel.org
Signed-off-by: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
(cherry picked from commit 97be7ceaf7)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Idfb7dead6024aabd84e374dd254b53e1165e59df
Commit 1967939462 ("Compiler Attributes: remove
CONFIG_ENABLE_MUST_CHECK") removed this config option, so also remove it
from the gki_defconfig files so that we can properly build things.
Fixes: 1967939462 ("Compiler Attributes: remove CONFIG_ENABLE_MUST_CHECK")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5e823676f5e68b373d7998b63a1c87af52c4a838
Changing some inline functions to use the new irq_check_status_bit
function out of line breaks calling them from loadable modules:
ERROR: modpost: "irq_check_status_bit" [drivers/perf/arm_spe_pmu.ko] undefined!
Export the function to make it work again. One can debate over
whether this should be EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL(),
as it could be called from any module before and making it GPL-only
changes behavior. However all other symbols in this file are
EXPORT_SYMBOL_GPL(), so I went with that for consistency.
Fixes: fdd0296304 ("genirq: Move status flag checks to core")
Link: https://lore.kernel.org/r/20201230154600.697832-1-arnd@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I4bc338352263445a2e3421e5116ead1c69c90768
Steps on the way to 5.11-rc1
Resolves merge issues in:
kernel/sched/sched.h
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: If5b00273202785ed39c5f46dfb92dd7791499cda
This reverts commit c25ce589dc.
Looks like some of the Android build systems do NOT have /usr/bin/env so
revert this change until that happens.
Specifically the following builds fail without this change reverted:
kernel_kasan_aarch64 on aosp_kernel-common-android-mainline
kernel_virt_kasan_aarch64 on aosp_kernel-common-android-mainline
kernel_virt_kasan_x86_64 on aosp_kernel-common-android-mainline
kernel_kasan_x86_64 on aosp_kernel-common-android-mainline
Fixes: c25ce589dc ("tweewide: Fix most Shebang lines")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I8077c5c1a4b9934f6d40aebb67212cc0b0f2513e
Steps on the way to 5.11-rc1
Resolves conflicts in:
scripts/mod/modpost.c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ie9f8da480668fbd2a47fd686c506bb538c8c024d
The vendor hook in find_energy_efficient_cpu() currently sees a
potentially stale task utilization. Make sure to sync it beforehand to
avoid any issues by moving the call at the top of the function. This
also ensures the check on task_fits_capacity() when the sync flag is set
sees an up-to-date task util.
Fixes: a9c5fcfe9c ("ANDROID: sched/fair: Have sync honor fits_capacity")
Fixes: 147a9b3d9e ("ANDROID: sched: Add vendor hooks for find_energy_efficient_cpu")
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: Ie9a6c89249a2aefbccced4786ce4d4728e39dd12
(cherry picked from commit eadbc20d0d)
Kernel stack violation when getting unit_descriptor/wb_buf_alloc_units from
rpmb lun. The reason is the unit descriptor length is different per LU.
The lengh of Normal LU is 45, while the one of rpmb LU is 35.
int ufshcd_read_desc_param(struct ufs_hba *hba, ...)
{
param_offset=41;
param_size=4;
buff_len=45;
...
buff_len=35 by rpmb LU;
if (is_kmalloc) {
/* Make sure we don't copy more data than available */
if (param_offset + param_size > buff_len)
param_size = buff_len - param_offset;
--> param_size = 250;
memcpy(param_read_buf, &desc_buf[param_offset], param_size);
--> memcpy(param_read_buf, desc_buf+41, 250);
[ 141.868974][ T9174] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: wb_buf_alloc_units_show+0x11c/0x11c
}
}
Bug: 174701661
Link: https://lore.kernel.org/linux-scsi/20210111095927.1830311-1-jaegeuk@kernel.org/
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Change-Id: I25205d465daa25b4bd330876ad05fcfd01195a56
When gate_work/ungate_work experience an error during hibern8_enter or exit
we can livelock:
ufshcd_err_handler()
ufshcd_scsi_block_requests()
ufshcd_reset_and_restore()
ufshcd_clear_ua_wluns() -> stuck
ufshcd_scsi_unblock_requests()
In order to avoid this, ufshcd_clear_ua_wluns() can be called per recovery
flows such as suspend/resume, link_recovery, and error_handler.
Bug: 175391270
(cherry picked from commit 4ee7ee530b git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git fixes)
Link: https://lore.kernel.org/r/20210107185316.788815-2-jaegeuk@kernel.org
Fixes: b56c9e4cdf ("FROMLIST: scsi: ufs: fix livelock of ufshcd_clear_ua_wluns")
Reviewed-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Change-Id: I16f41f552a0e4d6c93592b73cf7489fa1197a987
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Bug: 177075428
Test: incfs_test passes
atest GtsIncrementalInstallTestCases has only 8 failures
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I73accfc1982aec1cd7947996c25a23e4a97cfdac
I forgot to add static to a handful of dm-user function declarations.
Not sure how I missed these warnings the other times, but the 0-day
robot found them on android-mainline.
Reported-by: kernel test robot <lkp@intel.com>
Test: none
Fixes: 83bf345abc ("ANDROID: dm: dm-user: New target that proxies BIOs to userspace")
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Change-Id: If9cb2de117ff402c86902d0d2d6a2f0e28614c54
This reverts commit 421015713b.
Right now arm allmodconfig builds fail with:
FATAL: modpost: drivers/input/mousedev: sizeof(struct input_device_id)=164 is not a modulo of the size of section __mod_input__<identifier>_device_table=1216.
which seems to be caused by KASan, so disable it from ARM builds for now
until we figure it out.
Fixes: 421015713b ("ARM: 9017/2: Enable KASan for ARM")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ie9352cdad01e286ca981692666ceed8d10c9bc23
Enable the KUNIT core, which has a small ABI impact, and also the
DEBUGFS feature so that results can be reaped. This change does not
actually enable any KUNIT tests or the internal selftests, those must be
enabled by downstream builds.
Bug: 176228452
Change-Id: I2817cb1495fe7bf0485e63f877a68b1971e26cc5
Signed-off-by: Alistair Delva <adelva@google.com>
it use vb2_dma_contig_memops as default mem_ops in csi driver
drivers/media/platform/mxc/capture/mx6s_capture.c still not upstream to linux community.
q->mem_ops = &vb2_dma_contig_memops;
mem_ops is need in videobuf2-core.c to operate dma buffer.
videobuf2-dma-contig.c is common code which have no hardware involved
Bug: 160195378
Signed-off-by: zhang sanshan <pete.zhang@nxp.com>
Change-Id: Ib084ff96bd4f92aa36f8abb8d4b62a0e9be62e6c
CONFIG_MEMCG introduces overhead both in terms of memory usage as well
as in the minor page fault path and after moving to PSI it is currently
unused on non-Android Go devices. Disable it in GKI to avoid the overhead.
Bug: 169443770
Bug: 172296409
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I717c2a1bde6264285b86d583ae1a1007c36be223
Pull Kbuild fixes from Masahiro Yamada:
- Search for <ncurses.h> in the default header path of HOSTCC
- Tweak the option order to be kind to old BSD awk
- Remove 'kvmconfig' and 'xenconfig' shorthands
- Fix documentation
* tag 'kbuild-fixes-v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
Documentation: kbuild: Fix section reference
kconfig: remove 'kvmconfig' and 'xenconfig' shorthands
lib/raid6: Let $(UNROLL) rules work with macOS userland
kconfig: Support building mconf with vendor sysroot ncurses
kconfig: config script: add a little user help
MAINTAINERS: adjust GCC PLUGINS after gcc-plugin.sh removal
Pull SCSI fixes from James Bottomley:
"This is two driver fixes (megaraid_sas and hisi_sas).
The megaraid one is a revert of a previous revert of a cpu hotplug fix
which exposed a bug in the block layer which has been fixed in this
merge window.
The hisi_sas performance enhancement comes from switching to interrupt
managed completion queues, which depended on the addition of
devm_platform_get_irqs_affinity() which is now upstream via the irq
tree in the last merge window"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: hisi_sas: Expose HW queues for v2 hw
Revert "Revert "scsi: megaraid_sas: Added support for shared host tagset for cpuhotplug""
