This deliberately changes the behavior of the per-cpuset
cpus file to not be effected by hotplug. When a cpu is offlined,
it will be removed from the cpuset/cpus file. When a cpu is onlined,
if the cpuset originally requested that that cpu was part of the cpuset,
that cpu will be restored to the cpuset. The cpus files still
have to be hierachical, but the ranges no longer have to be out of
the currently online cpus, just the physically present cpus.
Bug: 120444281
Change-Id: I22cdf33e7d312117bcefba1aeb0125e1ada289a9
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
[AmitP: Refactored original changes to align with upstream commit
201af4c0fa ("cgroup: move cgroup files under kernel/cgroup/")]
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
This adds a counter to the taskstats extended accounting fields, which
tracks the number of times fsync is called, and then plumbs it through
to the uid_sys_stats driver.
Bug: 120442023
Change-Id: I6c138de5b2332eea70f57e098134d1d141247b3f
Signed-off-by: Jin Qian <jinqian@google.com>
[AmitP: Refactored changes to align with changes from upstream commit
9a07000400 ("sched/headers: Move CONFIG_TASK_XACCT bits from <linux/sched.h> to <linux/sched/xacct.h>")]
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
[tkjos: Needed for storaged fsync accounting ("storaged --uid" and
"storaged --task").]
[astrachan: This is modifying a userspace interface and should probably
be reworked]
Signed-off-by: Alistair Strachan <astrachan@google.com>
IO usages are accounted in foreground and background buckets.
For each uid, io usage is calculated in two steps.
delta = current total of all uid tasks - previus total
current bucket += delta
Bucket is determined by current uid stat. Userspace writes to
/proc/uid_procstat/set <uid> <stat> when uid stat is updated.
/proc/uid_io/stats shows IO usage in this format.
<uid> <foreground IO> <background IO>
Bug: 34198239
Bug: 120442023
Change-Id: Ib8bebda53e7a56f45ea3eb0ec9a3153d44188102
Signed-off-by: Jin Qian <jinqian@google.com>
[connoro: Used by storaged.]
[astrachan: Note: this version does not track fsync syscalls; this is
implemented in a follow up due to the fact it depends on
modifications to the task_xacct feature.]
[astrachan: Folded in the following changes:
e003a91d8f42 ("ANDROID: uid_sys_stats: allow writing same state")
89b984bf2efd ("ANDROID: uid_sys_stats: fix negative write bytes.")
bb5ee21cc4dd ("ANDROID: uid_sys_stats: change to use rt_mutex")
9297d5a160c7 ("ANDROID: uid_sys_stats: reduce update_io_stats overhead")
89402d07fe91 ("ANDROID: uid_sys_stats: defer io stats calulation for dead tasks")
6dc5d8173a8c ("ANDROID: uid_sys_stats: check previous uid_entry before call find_or_register_uid")
0ca2ece8f7ec ("ANDROID: uid_sys_stats: log task io with a debug flag")
c9c096ef0e67 ("ANDROID: uid_sys_stats: Copy task_struct comm field to bigger buffer")]
Signed-off-by: Alistair Strachan <astrachan@google.com>
Adds proc files /proc/uid_cputime/show_uid_stat and
/proc/uid_cputime/remove_uid_range.
show_uid_stat lists the total utime and stime for the active as well as
terminated processes for each of the uids.
Writing a range of uids to remove_uid_range will delete the accounting
for all the uids within that range.
Bug: 120442023
Change-Id: I21d9210379da730b33ddc1a0ea663c8c9d2ac15b
Signed-off-by: Jin Qian <jinqian@google.com>
[AmitP: Refactored the original patch because upstream commit
605dc2b31a ("tsacct: Convert obsolete cputime type to nsecs")
made cputime_t type obsolete, so use u64 nanoseconds directly instead.
Also folded following android-4.9 changes into this patch
48a9906c0f ("ANDROID: proc: uid_cputime: create uids from kuids")
453ac31cab ("ANDROID: proc: uid_cputime: fix show_uid_stat permission")]
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
[connoro: Used by batterystats.]
[astrachan: Folded in the file/kconfig rename and the following changes:
da3687fbc393 ("ANDROID: uid_cputime: fix cputime overflow")
71e3eb512d00 ("ANDROID: uid_cputime: Iterates over all the threads instead of processes.")
c65f0080c300 ("ANDROID: uid_cputime: Check for the range while removing range of UIDs.")
c8212458e3a5 ("ANDROID: uid_sys_stats: fix access of task_uid(task)")
bb5ee21cc4dd ("ANDROID: uid_sys_stats: change to use rt_mutex")
6dc5d8173a8c ("ANDROID: uid_sys_stats: check previous uid_entry before call find_or_register_uid")
82b9872b3894 ("ANDROID: uid_sys_stats: Replace tasklist lock with RCU in uid_cputime_show")]
Signed-off-by: Alistair Strachan <astrachan@google.com>
Used to prevent remounting MMC on suspend/resume.
Bug: 120441127
Change-Id: I20821a82831b07ca037973d5d92e832372c6b583
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
This driver presents a standard USB audio class interface to the host
and an ALSA PCM device to userspace
Bug: 78114713
Bug: 120441124
[badhri: f_audio_source is being migrated to userspace.]
Change-Id: If16b14a5ff27045f9cb2daaf1ae9195c5eeab7d0
Signed-off-by: Mike Lockwood <lockwood@google.com>
[AmitP: Folded following android-4.9 commit changes into this patch
Parts of e275439310 ("ANDROID: usb: gadget: Fixes and hacks to make android usb gadget compile on 3.8")
i6d9285e2574a ("ANDROID: usb: gadget: f_audio_source:replace deprecated API")]
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
[astrachan: Folded the following changes into this patch:
ddfd0c4070c1 ("ANDROID: usb: gadget: f_audio_source: Move to USB_FUNCTION API")
a3ab81aaa19e ("ANDROID: usb: gadget: f_audio_source: Move gadget functions code")
2095c953d894 ("ANDROID: usb: gadget: f_audio_source: change max ISO packet size")
8671b3e53638 ("ANDROID: usb: gadget: f_audio_source: Fixed USB Audio Class Interface Descriptor")
af98f36edbe2 ("ANDROID: usb: gadget: f_audio_source: disable the CPU C-states upon playback")
a830751a338e ("CHROMIUM: usb: gadget: f_audio_source: add .free_func callback")]
Signed-off-by: Alistair Strachan <astrachan@google.com>
Android frameworks relies on the alsa
config reported by the f_midi device.
Bug: 111003288
Bug: 120441124
Change-Id: I0695e00b166fd953f50acea93802245b0d5a5240
[badhri: The framework should be moved away from this]
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
USB accessory mode allows users to connect USB host hardware
specifically designed for Android-powered devices. The accessories
must adhere to the Android accessory protocol outlined in the
http://accessories.android.com documentation. This allows
Android devices that cannot act as a USB host to still interact with
USB hardware. When an Android device is in USB accessory mode, the
attached Android USB accessory acts as the host, provides power
to the USB bus, and enumerates connected devices.
Bug: 63740241
Bug: 120441124
Change-Id: I67964b50d278f3c0471d47efbb7b0973a3502681
[badhri: f_accessory is being migrated to userspace.]
Signed-off-by: Mike Lockwood <lockwood@android.com>
[AmitP: Folded following android-4.9 commit changes into this patch
ceb2f0aac6 ("ANDROID: usb: gadget: accessory: Fix section mismatch")
Parts of e275439310 ("ANDROID: usb: gadget: Fixes and hacks to make android usb gadget compile on 3.8")
1b07ec7515 ("ANDROID: drivers: usb: gadget: 64-bit related type fixes")]
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
[astrachan: Folded the following changes into this patch:
9d5891d516e2 ("ANDROID: usb: gadget: f_accessory: Add ACCESSORY_SET_AUDIO_MODE control request and ioctl")
dc66cfce9622 ("ANDROID: usb: gadget: f_accessory: Add support for HID input devices")
5f1ac9c2871b ("ANDROID: usb: gadget: f_accessory: move userspace interface to uapi")
9a6241722cd8 ("ANDROID: usb: gadget: f_accessory: Enabled Zero Length Packet (ZLP) for acc_write")
31a0ecd5a825 ("ANDROID: usb: gadget: f_accessory: check for accessory device before disconnecting HIDs")
580721fa6cbc ("ANDROID: usb: gadget: f_accessory: Migrate to USB_FUNCTION API")
7f407172fb28 ("ANDROID: usb: gadget: f_accessory: Fix for UsbAccessory clean unbind.")
ebc98ac5a22f ("ANDROID: usb: gadget: f_accessory: fix false disconnect due to a signal sent to the reading process")
71c6dc5ffdab ("ANDROID: usb: gadget: f_accessory: assign no-op request complete callbacks")
675047ee68e9 ("ANDROID: usb: gadget: f_accessory: Move gadget functions code")
b2bedaa5c7df ("CHROMIUM: usb: gadget: f_accessory: add .raw_request callback")]
Signed-off-by: Alistair Strachan <astrachan@google.com>
Android frameworks (UsbDeviceManager) relies on gadget state exported
through device attributes. This CL adds the device attribute to export
USB gadget state.
Bug: 68755607
Bug: 120441124
Change-Id: Id0391810d75b58c579610fbec6e37ab22f28886d
[badhri: Migrate to using udc uevents from upstream sysfs.]
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
[AmitP: Folded following android-4.9 commit changes into this patch
Parts of e45c769fa7 ("ANDROID: usb: gadget: cleanup: fix unused variable and function warnings")
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Added a device attribute to android_device to
determine USB_GADGET's state
Bug: 68755607
Bug: 120441124
Change-Id: I17f8903120df96bf2f4bf441940b53a87b818230
[badhri: Migrate to using udc uevents from upstream sysfs.]
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Added create_function_device to create child
function devices for USB gadget functions.
Android UsbDeviceManager relies on communicating
to the devices created by the gadget functions
to implement functions such as audio_source.
Bug: 63740241
Bug: 68755607
Bug: 78114713
Bug: 120441124
Change-Id: I0df9ad86ac32d8cdacdea164e9fed49891b45fc2
[badhri: This is a supporting patch for other patches which have
replacements pipelined. It can be dropped when those
implementations land.]
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Android userspace UsbDeviceManager relies on the
uevents generated by the composition driver to
generate user notifications. This CL adds uevents
to be generated whenever USB changes its state
i.e. connected, disconnected, configured.
This CL also intercepts the setup requests from
the usb_core anb routes it to the specific
usb function if required.
Bug: 68755607
Bug: 120441124
Change-Id: Ib3d3a78255a532f7449dac286f776c2966caf8c1
[badhri: Migrate to using udc uevents from upstream sysfs.]
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
[AmitP: Folded following android-4.9 commit changes into this patch
9214c899f7 ("ANDROID: usb: gadget: configfs: handle gadget reset request for android")]
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
[astrachan: Folded change 5c899c9fd75d ("ANDROID: usb: gadget: configfs:
fix null ptr in android_disconnect") into this patch]
Signed-off-by: Alistair Strachan <astrachan@google.com>
Add a pointer to the usb_function inside the
usb_function_instance structure to service
functions specific setup requests even before
the function gets added to the usb_gadget
Bug: 63740241
Bug: 68755607
Bug: 78114713
Bug: 120441124
Change-Id: I6f457006f6c5516cc6986ec2acdf5b1ecf259d0c
[badhri: This is a supporting patch for other patches which have
replacements pipelined. It can be dropped when those
implementations land.]
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Userspace processes often have multiple allocators that each do
anonymous mmaps to get memory. When examining memory usage of
individual processes or systems as a whole, it is useful to be
able to break down the various heaps that were allocated by
each layer and examine their size, RSS, and physical memory
usage.
This patch adds a user pointer to the shared union in
vm_area_struct that points to a null terminated string inside
the user process containing a name for the vma. vmas that
point to the same address will be merged, but vmas that
point to equivalent strings at different addresses will
not be merged.
Userspace can set the name for a region of memory by calling
prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, start, len, (unsigned long)name);
Setting the name to NULL clears it.
The names of named anonymous vmas are shown in /proc/pid/maps
as [anon:<name>] and in /proc/pid/smaps in a new "Name" field
that is only present for named vmas. If the userspace pointer
is no longer valid all or part of the name will be replaced
with "<fault>".
The idea to store a userspace pointer to reduce the complexity
within mm (at the expense of the complexity of reading
/proc/pid/mem) came from Dave Hansen. This results in no
runtime overhead in the mm subsystem other than comparing
the anon_name pointers when considering vma merging. The pointer
is stored in a union with fieds that are only used on file-backed
mappings, so it does not increase memory usage.
Includes fix from Jed Davis <jld@mozilla.com> for typo in
prctl_set_vma_anon_name, which could attempt to set the name
across two vmas at the same time due to a typo, which might
corrupt the vma list. Fix it to use tmp instead of end to limit
the name setting to a single vma at a time.
Bug: 120441514
Change-Id: I9aa7b6b5ef536cd780599ba4e2fba8ceebe8b59f
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
[AmitP: Fix get_user_pages_remote() call to align with upstream commit
5b56d49fc3 ("mm: add locked parameter to get_user_pages_remote()")]
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Avoid waking up every thread sleeping in an epoll_wait call during
suspend and resume by calling a freezable blocking call. Previous
patches modified the freezer to avoid sending wakeups to threads
that are blocked in freezable blocking calls.
This call was selected to be converted to a freezable call because
it doesn't hold any locks or release any resources when interrupted
that might be needed by another freezing task or a kernel driver
during suspend, and is a common site where idle userspace tasks are
blocked.
Bug: 77139736
Bug: 120440023
Change-Id: I848d08d28c89302fd42bbbdfa76489a474ab27bf
[ccross: This was upstream (https://lkml.org/lkml/2013/5/6/823), but
reverted because it reportedly caused memory corruption on
32-bit x86 (https://patchwork.kernel.org/patch/3162301/).]
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The old logic assumes CMDLINE_FROM_BOOTLOADER vs. CMDLINE_FORCE and
ignores CMDLINE_EXTEND. Here's the old logic:
- CONFIG_CMDLINE_FORCE=true
CONFIG_CMDLINE
- dt bootargs=non-empty:
dt bootargs
- dt bootargs=empty, @data is non-empty string
@data is left unchanged
- dt bootargs=empty, @data is empty string
CONFIG_CMDLINE (or "" if that's not defined)
The new logic is now documented in of_fdt.h and is copied here for
reference:
- CONFIG_CMDLINE_FORCE=true
CONFIG_CMDLINE
- CONFIG_CMDLINE_EXTEND=true, @data is non-empty string
@data + dt bootargs (even if dt bootargs are empty)
- CONFIG_CMDLINE_EXTEND=true, @data is empty string
CONFIG_CMDLINE + dt bootargs (even if dt bootargs are empty)
- CMDLINE_FROM_BOOTLOADER=true, dt bootargs=non-empty:
dt bootargs
- CMDLINE_FROM_BOOTLOADER=true, dt bootargs=empty, @data is non-empty string
@data is left unchanged
- CMDLINE_FROM_BOOTLOADER=true, dt bootargs=empty, @data is empty string
CONFIG_CMDLINE (or "" if that's not defined)
Signed-off-by: Doug Anderson <dianders@chromium.org>
CC: devicetree-discuss@lists.ozlabs.org
CC: Grant Likely <grant.likely@secretlab.ca>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Rob Herring <rob.herring@calxeda.com>
Bug: 120440972
Change-Id: I40ace250847f813358125dfcaa8998fd32cf7ea3
Signed-off-by: Colin Cross <ccross@android.com>
[AmitP: Folded following android-4.9 commit changes into this patch
e820270abb ("ANDROID: of: fix CONFIG_CMDLINE_EXTEND")
9a4a740554 ("ANDROID: of: Fix build warnings")]
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Copy the config choice for CONFIG_CMDLINE_EXTEND from
arch/arm/Kconfig, including CONFIG_CMDLINE_FROM_BOOTLOADER
as the default. These will be used by drivers/of/fdt.c.
Bug: 120440972
Change-Id: I8416038498ddf8fc1e99ab06109825eb1492aa7f
Signed-off-by: Colin Cross <ccross@android.com>
Previously receiver buffer auto-tuning starts after receiving
one advertised window amount of data. After the initial receiver
buffer was raised by patch a337531b94 ("tcp: up initial rmem to
128KB and SYN rwin to around 64KB"), the reciver buffer may take
too long to start raising. To address this issue, this patch lowers
the initial bytes expected to receive roughly the expected sender's
initial window.
Fixes: a337531b94 ("tcp: up initial rmem to 128KB and SYN rwin to around 64KB")
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Wei Wang <weiwan@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 041a14d267)
Signed-off-by: Chenbo Feng <fengc@google.com>
This patch is backported from 4.20 to allow us to drop "ANDROID: net:
ipv4: tcp: add a sysctl to config the tcp_default_init_rwnd"
Bug: 118591209
Test: net_test sock_diag_test.py
Change-Id: Ifff58b0b86a816a66d5a0bd77b57d6eedeaafa3b
Previously TCP initial receive buffer is ~87KB by default and
the initial receive window is ~29KB (20 MSS). This patch changes
the two numbers to 128KB and ~64KB (rounding down to the multiples
of MSS) respectively. The patch also simplifies the calculations s.t.
the two numbers are directly controlled by sysctl tcp_rmem[1]:
1) Initial receiver buffer budget (sk_rcvbuf): while this should
be configured via sysctl tcp_rmem[1], previously tcp_fixup_rcvbuf()
always override and set a larger size when a new connection
establishes.
2) Initial receive window in SYN: previously it is set to 20
packets if MSS <= 1460. The number 20 was based on the initial
congestion window of 10: the receiver needs twice amount to
avoid being limited by the receive window upon out-of-order
delivery in the first window burst. But since this only
applies if the receiving MSS <= 1460, connection using large MTU
(e.g. to utilize receiver zero-copy) may be limited by the
receive window.
With this patch TCP memory configuration is more straight-forward and
more properly sized to modern high-speed networks by default. Several
popular stacks have been announcing 64KB rwin in SYNs as well.
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Wei Wang <weiwan@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit a337531b94)
Signed-off-by: Chenbo Feng <fengc@google.com>
This patch is backported from 4.20 to allow us to drop "ANDROID: net:
ipv4: tcp: add a sysctl to config the tcp_default_init_rwnd"
Bug: 118591209
Test: net_test sock_diag_test.py
Change-Id: I7c38947205001912891750870d103b7268b44828
When using the PF_KEY interface, SHA-256 hashes are hardcoded to
use 96-bit truncation. This is a violation of RFC4868, which
specifies 128-bit truncation, but will not be fixed upstream due
to backwards compatibility concerns and because the PF_KEY
interface is deprecated in favour of netlink XFRM (which allows
the app to specify an arbitrary truncation length).
Change the hardcoded truncation length from 96 to 128 so that
PF_KEY apps such as racoon will work with standards-compliant VPN
servers.
Bug: 34114242
Bug: 120440497
Change-Id: Ie46bff4b6358f18117d0be241171d677d31d33f7
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Provides build coverage for features coming from eas-dev. For now, make
this specific to the arm64 defconfig.
Bug: 118439987
Bug: 120439617
Test: make ARCH=arm64 cuttlefish_defconfig && make ARCH=arm64
Change-Id: Id018290a2d38631b4b88f15ee7a1a85fcce25798
Signed-off-by: Alistair Strachan <astrachan@google.com>
A ~10% regression has been reported for UnixBench's execl throughput
test by Aaron Lu and Ye Xiaolong:
https://lkml.org/lkml/2018/10/30/765
That test is pretty simple, it does a "recursive" execve() syscall on the
same binary. Starting from the syscall, this sequence is possible:
do_execve()
do_execveat_common()
__do_execve_file()
sched_exec()
select_task_rq_fair() <==| Task already enqueued
find_idlest_cpu()
find_idlest_group()
capacity_spare_wake() <==| Functions not called from
cpu_util_wake() | the wakeup path
which means we can end up calling cpu_util_wake() not only from the
"wakeup path", as its name would suggest. Indeed, the task doing an
execve() syscall is already enqueued on the CPU we want to get the
cpu_util_wake() for.
The estimated utilization for a CPU computed in cpu_util_wake() was
written under the assumption that function can be called only from the
wakeup path. If instead the task is already enqueued, we end up with a
utilization which does not remove the current task's contribution from
the estimated utilization of the CPU.
This will wrongly assume a reduced spare capacity on the current CPU and
increase the chances to migrate the task on execve.
The regression is tracked down to:
commit d519329f72 ("sched/fair: Update util_est only on util_avg updates")
because in that patch we turn on by default the UTIL_EST sched feature.
However, the real issue is introduced by:
commit f9be3e5961 ("sched/fair: Use util_est in LB and WU paths")
Let's fix this by ensuring to always discount the task estimated
utilization from the CPU's estimated utilization when the task is also
the current one. The same benchmark of the bug report, executed on a
dual socket 40 CPUs Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz machine,
reports these "Execl Throughput" figures (higher the better):
mainline : 48136.5 lps
mainline+fix : 55376.5 lps
which correspond to a 15% speedup.
Moreover, since {cpu_util,capacity_spare}_wake() are not really only
used from the wakeup path, let's remove this ambiguity by using a better
matching name: {cpu_util,capacity_spare}_without().
Since we are at that, let's also improve the existing documentation.
Reported-by: Aaron Lu <aaron.lu@intel.com>
Reported-by: Ye Xiaolong <xiaolong.ye@intel.com>
Tested-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Perret <quentin.perret@arm.com>
Cc: Steve Muckle <smuckle@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Todd Kjos <tkjos@google.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Fixes: f9be3e5961 (sched/fair: Use util_est in LB and WU paths)
Link: https://lore.kernel.org/lkml/20181025093100.GB13236@e110439-lin/
Signed-off-by: Ingo Molnar <mingo@kernel.org>
[
backported to android-4.19 from c469933e77 in tip/sched/urgent
propagated renaming of cpu_util_wake() into find_best_target()
the only other callsite we have in the android kernel.
]
Bug: 120440300
Change-Id: I6dca1ed09cb34b7b8d9d75c33088a402aa3b7b24
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Add defconfigs for x86_64 and arm64 for the cuttlefish virtual device
platform. This change also add the build.config files needed by the
kernel/build project.
Bug: 120439617
Test: make ARCH=x86_64 x86_64_cuttlefish_defconfig && make ARCH=x86_64
Test: make ARCH=arm64 cuttlefish_defconfig && make ARCH=arm64
Change-Id: I61bde941e8cfef2dd83cb4ff040f7380922cc44e
Signed-off-by: Alistair Strachan <astrachan@google.com>
Android has an unusual setup where the kernel needs to target
[arch]-linux-gnu to avoid Android userspace-specific flags and
optimizations, but AOSP doesn't ship a matching binutils.
Add a new variable CLANG_TRIPLE which can override the "-target" triple
used to compile the kernel, while using a different CROSS_COMPILE to
pick the binutils/gcc installation. For Android you'd do something
like:
export CLANG_TRIPLE=aarch64-linux-gnu-
export CROSS_COMPILE=aarch64-linux-android-
If you don't need something like this, leave CLANG_TRIPLE unset and it
will default to CROSS_COMPILE.
Change-Id: I85d63599c6ab8ed458071cdf9197d85b1f7f150b
Signed-off-by: Greg Hackmann <ghackmann@google.com>
[astrachan: Added a script to check for incorrectly falling back to the
default when CLANG_TRIPLE is unset]
Bug: 118439987
Bug: 120440614
Test: make CLANG_TRIPLE=x86_64-linux-gnu CC=clang
Signed-off-by: Alistair Strachan <astrachan@google.com>
While we wait for a clang prebuilt with asm-goto support, we have
removed the kbuild's detection of a clang without asm-goto (the
kernel builds fine without it), so we don't need to see the same
warning about not having the compiler feature fill the kernel build
log, which potentially hides other issues.
This patch should be reverted when the new clang prebuilt lands and
we have reverted the other reverts.
Bug: 120440614
Test: make ARCH=x86_64 x86_64_cuttlefish_defconfig && make ARCH=x86_64
Change-Id: I26aee5b9dd291f27b950dee4b0c64471d972ddb5
Signed-off-by: Alistair Strachan <astrachan@google.com>
This reverts commit e501ce957a.
This change broke building the x86_64 kernel with clang. The kernel
still builds and works fine without asm-goto support. Revert this
change to unblock testing clang kernels on cuttlefish.
Bug: 120440614
Change-Id: Ib32498acc0596264f8cd15de0b603579dd643dd7
Signed-off-by: Alistair Strachan <astrachan@google.com>
This reverts commit 829fe4aa9a.
This change builds on top of another change which we are reverting.
Revert it too, to avoid a conflict.
Bug: 120440614
Change-Id: I23fd0ebda98eb2646efdcfdfa06bb6ab627ba471
Signed-off-by: Alistair Strachan <astrachan@google.com>
commit 473f0a763d upstream.
According to vendor sdk, vco calibration has to be executed
for each channel configuration whereas mcu calibration has to be
performed during channel scanning. This patch fixes the mt76x0
monitor mode issue since in that configuration vco calibration
was never executed
Fixes: 10de7a8b4a ("mt76x0: phy files")
Tested-by: Sid Hayn <sidhayn@gmail.com>
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7e241f647d upstream.
skb_can_coalesce() allows coalescing neighboring slab objects into
a single frag:
return page == skb_frag_page(frag) &&
off == frag->page_offset + skb_frag_size(frag);
ceph_tcp_sendpage() can be handed slab pages. One example of this is
XFS: it passes down sector sized slab objects for its metadata I/O. If
the kernel client is co-located on the OSD node, the skb may go through
loopback and pop on the receive side with the exact same set of frags.
When tcp_recvmsg() attempts to copy out such a frag, hardened usercopy
complains because the size exceeds the object's allocated size:
usercopy: kernel memory exposure attempt detected from ffff9ba917f20a00 (kmalloc-512) (1024 bytes)
Although skb_can_coalesce() could be taught to return false if the
resulting frag would cross a slab object boundary, we already have
a fallback for non-refcounted pages. Utilize it for slab pages too.
Cc: stable@vger.kernel.org # 4.8+
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fb862c3b19 upstream.
The PixArt OEM mice are known for disconnecting every minute in
runlevel 1 or 3 if they are not always polled. So add quirk
ALWAYS_POLL for two Primax mice as well.
0x4e22 is the Dell MS111-P and 0x4d0f is the unbranded HP Portia
mouse HP 697738-001. Both were built until approx. 2014.
Those were the standard mice from those vendors and are still
around - even as new old stock.
Reference: https://github.com/sriemer/fix-linux-mouse/issues/11
Signed-off-by: Sebastian Parschauer <sparschauer@suse.de>
CC: stable@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8c01db7619 upstream.
When a UHID_CREATE command is written to the uhid char device, a
copy_from_user() is done from a user pointer embedded in the command.
When the address limit is KERNEL_DS, e.g. as is the case during
sys_sendfile(), this can read from kernel memory. Alternatively,
information can be leaked from a setuid binary that is tricked to write
to the file descriptor. Therefore, forbid UHID_CREATE in these cases.
No other commands in uhid_char_write() are affected by this bug and
UHID_CREATE is marked as "obsolete", so apply the restriction to
UHID_CREATE only rather than to uhid_char_write() entirely.
Thanks to Dmitry Vyukov for adding uhid definitions to syzkaller and to
Jann Horn for commit 9da3f2b740 ("x86/fault: BUG() when uaccess
helpers fault on kernel addresses"), allowing this bug to be found.
Reported-by: syzbot+72473edc9bf4eb1c6556@syzkaller.appspotmail.com
Fixes: d365c6cfd3 ("HID: uhid: add UHID_CREATE and UHID_DESTROY events")
Cc: <stable@vger.kernel.org> # v3.6+
Cc: Jann Horn <jannh@google.com>
Cc: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Jann Horn <jannh@google.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2bbb5fa374 upstream.
Many HP AMD based laptops contain an SMB0001 device like this:
Device (SMBD)
{
Name (_HID, "SMB0001") // _HID: Hardware ID
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
IO (Decode16,
0x0B20, // Range Minimum
0x0B20, // Range Maximum
0x20, // Alignment
0x20, // Length
)
IRQ (Level, ActiveLow, Shared, )
{7}
})
}
The legacy style IRQ resource here causes acpi_dev_get_irqresource() to
be called with legacy=true and this message to show in dmesg:
ACPI: IRQ 7 override to edge, high
This causes issues when later on the AMD0030 GPIO device gets enumerated:
Device (GPIO)
{
Name (_HID, "AMDI0030") // _HID: Hardware ID
Name (_CID, "AMDI0030") // _CID: Compatible ID
Name (_UID, Zero) // _UID: Unique ID
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (RBUF, ResourceTemplate ()
{
Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
{
0x00000007,
}
Memory32Fixed (ReadWrite,
0xFED81500, // Address Base
0x00000400, // Address Length
)
})
Return (RBUF) /* \_SB_.GPIO._CRS.RBUF */
}
}
Now acpi_dev_get_irqresource() gets called with legacy=false, but because
of the earlier override of the trigger-type acpi_register_gsi() returns
-EBUSY (because we try to register the same interrupt with a different
trigger-type) and we end up setting IORESOURCE_DISABLED in the flags.
The setting of IORESOURCE_DISABLED causes platform_get_irq() to call
acpi_irq_get() which is not implemented on x86 and returns -EINVAL.
resulting in the following in dmesg:
amd_gpio AMDI0030:00: Failed to get gpio IRQ: -22
amd_gpio: probe of AMDI0030:00 failed with error -22
The SMB0001 is a "virtual" device in the sense that the only way the OS
interacts with it is through calling a couple of methods to do SMBus
transfers. As such it is weird that it has IO and IRQ resources at all,
because the driver for it is not expected to ever access the hardware
directly.
The Linux driver for the SMB0001 device directly binds to the acpi_device
through the acpi_bus, so we do not need to instantiate a platform_device
for this ACPI device. This commit adds the SMB0001 HID to the
forbidden_id_list, avoiding the instantiating of a platform_device for it.
Not instantiating a platform_device means we will no longer call
acpi_dev_get_irqresource() for the legacy IRQ resource fixing the probe of
the AMDI0030 device failing.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1644013
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198715
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199523
Reported-by: Lukas Kahnert <openproggerfreak@gmail.com>
Tested-by: Marc <suaefar@googlemail.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fee05f455c upstream.
req.gid can be indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
vers/misc/sgi-gru/grukdump.c:200 gru_dump_chiplet_request() warn:
potential spectre issue 'gru_base' [w]
Fix this by sanitizing req.gid before calling macro GID_TO_GRU, which
uses it to index gru_base.
Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5d1e9c2212 upstream.
Use the new of_get_compatible_child() helper to lookup the nfc child
node instead of using of_find_compatible_node(), which searches the
entire tree from a given start node and thus can return an unrelated
(i.e. non-child) node.
This also addresses a potential use-after-free (e.g. after probe
deferral) as the tree-wide helper drops a reference to its first
argument (i.e. the node of the device being probed).
While at it, also fix a related nfc-node reference leak.
Fixes: f88fc122cc ("mtd: nand: Cleanup/rework the atmel_nand driver")
Cc: stable <stable@vger.kernel.org> # 4.11
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Josh Wu <rainyfeeling@outlook.com>
Cc: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1decef3704 upstream.
Passing a timeout of zero to the synchronous serdev_device_write()
helper does currently not imply to wait forever (unlike passing zero to
serdev_device_wait_until_sent()). Instead, if there's insufficient
room in the write buffer, we'd end up with an incomplete write.
Fixes: d2efbbd18b ("gnss: add driver for sirfstar-based receivers")
Cc: stable <stable@vger.kernel.org> # 4.19
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 56a6c72683 upstream.
Passing a timeout of zero to the synchronous serdev_device_write()
helper does currently not imply to wait forever (unlike passing zero to
serdev_device_wait_until_sent()). Instead, if there's insufficient
room in the write buffer, we'd end up with an incomplete write.
Fixes: 37768b054f ("gnss: add generic serial driver")
Cc: stable <stable@vger.kernel.org> # 4.19
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7c97301285 upstream.
After building the kernel with Clang, the following section mismatch
warning appears:
WARNING: vmlinux.o(.text+0x3bf19a6): Section mismatch in reference from
the function ssc_probe() to the function
.init.text:atmel_ssc_get_driver_data()
The function ssc_probe() references
the function __init atmel_ssc_get_driver_data().
This is often because ssc_probe lacks a __init
annotation or the annotation of atmel_ssc_get_driver_data is wrong.
Remove __init from atmel_ssc_get_driver_data to get rid of the mismatch.
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a771125776 upstream.
Following on from this patch: https://lkml.org/lkml/2017/11/3/516,
Corsair K70 LUX RGB keyboards also require the DELAY_INIT quirk to
start correctly at boot.
Dmesg output:
usb 1-6: string descriptor 0 read error: -110
usb 1-6: New USB device found, idVendor=1b1c, idProduct=1b33
usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-6: can't set config #1, error -110
Signed-off-by: Emmanuel Pescosta <emmanuelpescosta099@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 781f0766cc upstream.
Devices connected under Terminus Technology Inc. Hub (1a40:0101) may
fail to work after the system resumes from suspend:
[ 206.063325] usb 3-2.4: reset full-speed USB device number 4 using xhci_hcd
[ 206.143691] usb 3-2.4: device descriptor read/64, error -32
[ 206.351671] usb 3-2.4: device descriptor read/64, error -32
Info for this hub:
T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=480 MxCh= 4
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=1a40 ProdID=0101 Rev=01.11
S: Product=USB 2.0 Hub
C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
Some expirements indicate that the USB devices connected to the hub are
innocent, it's the hub itself is to blame. The hub needs extra delay
time after it resets its port.
Hence wait for extra delay, if the device is connected to this quirky
hub.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
