The initial patch that added sync_state() support didn't handle the case
where a supplier has no consumers. This was because when a device is
successfully bound with a driver, only its suppliers were checked to see
if they are eligible to get a sync_state(). This is not sufficient for
devices that have no consumers but still need to do device state clean
up. So fix this.
Fixes: fc5a251d0f (driver core: Add sync_state driver/bus callback)
Signed-off-by: Saravana Kannan <saravanak@google.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200221080510.197337-2-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 21eb93f432
https: //git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-linus)
Bug: 150980623
Change-Id: I9bebc164f00d7797501f40080c12a04dbe3095b1
(cherry picked from commit a27e0934dec04ca9878e9cb7f99206bbb75f1f4d)
This is a necessary follow up to the first fix I proposed and we merged
in 2669b8b0c7 ("binder: prevent UAF for binderfs devices"). I have been
overly optimistic that the simple fix I proposed would work. But alas,
ihold() + iput() won't work since the inodes won't survive the
destruction of the superblock.
So all we get with my prior fix is a different race with a tinier
race-window but it doesn't solve the issue. Fwiw, the problem lies with
generic_shutdown_super(). It even has this cozy Al-style comment:
if (!list_empty(&sb->s_inodes)) {
printk("VFS: Busy inodes after unmount of %s. "
"Self-destruct in 5 seconds. Have a nice day...\n",
sb->s_id);
}
On binder_release(), binder_defer_work(proc, BINDER_DEFERRED_RELEASE) is
called which punts the actual cleanup operation to a workqueue. At some
point, binder_deferred_func() will be called which will end up calling
binder_deferred_release() which will retrieve and cleanup the
binder_context attach to this struct binder_proc.
If we trace back where this binder_context is attached to binder_proc we
see that it is set in binder_open() and is taken from the struct
binder_device it is associated with. This obviously assumes that the
struct binder_device that context is attached to is _never_ freed. While
that might be true for devtmpfs binder devices it is most certainly
wrong for binderfs binder devices.
So, assume binder_open() is called on a binderfs binder devices. We now
stash away the struct binder_context associated with that struct
binder_devices:
proc->context = &binder_dev->context;
/* binderfs stashes devices in i_private */
if (is_binderfs_device(nodp)) {
binder_dev = nodp->i_private;
info = nodp->i_sb->s_fs_info;
binder_binderfs_dir_entry_proc = info->proc_log_dir;
} else {
.
.
.
proc->context = &binder_dev->context;
Now let's assume that the binderfs instance for that binder devices is
shutdown via umount() and/or the mount namespace associated with it goes
away. As long as there is still an fd open for that binderfs binder
device things are fine. But let's assume we now close the last fd for
that binderfs binder device. Now binder_release() is called and punts to
the workqueue. Assume that the workqueue has quite a bit of stuff to do
and doesn't get to cleaning up the struct binder_proc and the associated
struct binder_context with it for that binderfs binder device right
away. In the meantime, the VFS is killing the super block and is
ultimately calling sb->evict_inode() which means it will call
binderfs_evict_inode() which does:
static void binderfs_evict_inode(struct inode *inode)
{
struct binder_device *device = inode->i_private;
struct binderfs_info *info = BINDERFS_I(inode);
clear_inode(inode);
if (!S_ISCHR(inode->i_mode) || !device)
return;
mutex_lock(&binderfs_minors_mutex);
--info->device_count;
ida_free(&binderfs_minors, device->miscdev.minor);
mutex_unlock(&binderfs_minors_mutex);
kfree(device->context.name);
kfree(device);
}
thereby freeing the struct binder_device including struct
binder_context.
Now the workqueue finally has time to get around to cleaning up struct
binder_proc and is now trying to access the associate struct
binder_context. Since it's already freed it will OOPs.
Fix this by introducing a refounct on binder devices.
This is an alternative fix to 51d8a7eca6 ("binder: prevent UAF read in
print_binder_transaction_log_entry()").
Fixes: 3ad20fe393 ("binder: implement binderfs")
Fixes: 2669b8b0c7 ("binder: prevent UAF for binderfs devices")
Fixes: 03e2e07e38 ("binder: Make transaction_log available in binderfs")
Related: 51d8a7eca6 ("binder: prevent UAF read in print_binder_transaction_log_entry()")
Cc: stable@vger.kernel.org
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Acked-by: Todd Kjos <tkjos@google.com>
Link: https://lore.kernel.org/r/20200303164340.670054-1-christian.brauner@ubuntu.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f0fe2c0f05)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I54a6c910002bf1077ba0c34c48fb96f4ffbf012e
On binder_release(), binder_defer_work(proc, BINDER_DEFERRED_RELEASE) is
called which punts the actual cleanup operation to a workqueue. At some
point, binder_deferred_func() will be called which will end up calling
binder_deferred_release() which will retrieve and cleanup the
binder_context attach to this struct binder_proc.
If we trace back where this binder_context is attached to binder_proc we
see that it is set in binder_open() and is taken from the struct
binder_device it is associated with. This obviously assumes that the
struct binder_device that context is attached to is _never_ freed. While
that might be true for devtmpfs binder devices it is most certainly
wrong for binderfs binder devices.
So, assume binder_open() is called on a binderfs binder devices. We now
stash away the struct binder_context associated with that struct
binder_devices:
proc->context = &binder_dev->context;
/* binderfs stashes devices in i_private */
if (is_binderfs_device(nodp)) {
binder_dev = nodp->i_private;
info = nodp->i_sb->s_fs_info;
binder_binderfs_dir_entry_proc = info->proc_log_dir;
} else {
.
.
.
proc->context = &binder_dev->context;
Now let's assume that the binderfs instance for that binder devices is
shutdown via umount() and/or the mount namespace associated with it goes
away. As long as there is still an fd open for that binderfs binder
device things are fine. But let's assume we now close the last fd for
that binderfs binder device. Now binder_release() is called and punts to
the workqueue. Assume that the workqueue has quite a bit of stuff to do
and doesn't get to cleaning up the struct binder_proc and the associated
struct binder_context with it for that binderfs binder device right
away. In the meantime, the VFS is killing the super block and is
ultimately calling sb->evict_inode() which means it will call
binderfs_evict_inode() which does:
static void binderfs_evict_inode(struct inode *inode)
{
struct binder_device *device = inode->i_private;
struct binderfs_info *info = BINDERFS_I(inode);
clear_inode(inode);
if (!S_ISCHR(inode->i_mode) || !device)
return;
mutex_lock(&binderfs_minors_mutex);
--info->device_count;
ida_free(&binderfs_minors, device->miscdev.minor);
mutex_unlock(&binderfs_minors_mutex);
kfree(device->context.name);
kfree(device);
}
thereby freeing the struct binder_device including struct
binder_context.
Now the workqueue finally has time to get around to cleaning up struct
binder_proc and is now trying to access the associate struct
binder_context. Since it's already freed it will OOPs.
Fix this by holding an additional reference to the inode that is only
released once the workqueue is done cleaning up struct binder_proc. This
is an easy alternative to introducing separate refcounting on struct
binder_device which we can always do later if it becomes necessary.
This is an alternative fix to 51d8a7eca6 ("binder: prevent UAF read in
print_binder_transaction_log_entry()").
Fixes: 3ad20fe393 ("binder: implement binderfs")
Fixes: 03e2e07e38 ("binder: Make transaction_log available in binderfs")
Related: 51d8a7eca6 ("binder: prevent UAF read in print_binder_transaction_log_entry()")
Cc: stable@vger.kernel.org
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 2669b8b0c7)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I047a1e360b4146872bbc1d206dce7a864bb4588b
This is needed to support the QCOM clk drivers as modules without
building them in. We need to fix this properly upstream.
Signed-off-by: Will McVicker <willmcvicker@google.com>
Bug: 150638698
Bug: 147895101
Change-Id: I69b59455e4e2d8ef3a183ee52a835ddb97360420
Some endpoint devices do not go into D3hot during suspend. By pass
auto suspend if device do not allow D3hot.
CRs-Fixed: 2418347
Bug: 150638680
Change-Id: Ida6e4a2b60b7d08932bfff79144afd67787ca0f2
Signed-off-by: Sujeev Dias <sdias@codeaurora.org>
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 02f0bed29fd81f0cd55a60c6460b82d69e630b4c)
Hierarchical IRQ domains can be used to stack different IRQ controllers
on top of each other. One specific use-case where this can be useful is
if a power management controller has top-level controls for wakeup
interrupts. In such cases, the power management controller can be a
parent to other interrupt controllers and program additional registers
when an IRQ has its wake capability enabled or disabled.
Bug: 150638297
Change-Id: I3f63cb13c0cd1b602d3205c40648d5e7d3c62d4d
Patch-mainline: https://lore.kernel.org/patchwork/patch/989528/
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked commit from 789fe8a323e13bf5b15cf667bb7876554506c739)
pinctrl-[0..n] property is used to point to pin controllers. However,
there are other pinctrl-* properties that don't point to suppliers. To
keep the parsing simple, for now, add support only for pinctrl-[0..3]
properties as there's only one or two devices in the tree that have more
than pinctrl-3.
Bug: 144864161
Signed-off-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 3579c811e2ef195ab0a1c452a3d8966af40bf731)
Change-Id: Ia063ffecc7429c77a9c9ff7c31c431167225a62f
A lot of "qcom," properties accidentally match some of the generic suffix
based DT properties. So, ignore all properties that start with "qcom,"
Bug: 144864161
Signed-off-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 68ef04dbaee376443a7d557c88ddd34dc0157919)
Change-Id: I8c8c6336cd4387ba51aaeaf447979eba27e0d5c0
This is 4.19 specific fix. Will not be needed for 5.x since we'll have
the interconnect framework and a proper common binding to use.
Bug: 143786221
Signed-off-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 3acde98f213562f891110bca4cfca155d27875a7)
Change-Id: I81f9969ef620cd63ca549c4ed90f5887de5b44fd
We want to allow compiling irqchip drivers as modules. So export the
necessary symbols.
Bug: 148105066
Change-Id: Id3de4b8451bed1af9b0afeb5863493697730acb6
Signed-off-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit cfc69e9b2fe82a46addfcb1912bd642456548baa)
Sometimes interrupts are routed from an interrupt controller to another
in no specific order. Having these in the drives makes it difficult to
maintain when the same drivers supports multiple variants with different
mapping. Also, specifying them in DT makes little sense with a
bunch of numbers like -
<0, 13>, <5, 32>,
It makes more sense when we can have the parent handle along with
interrupt specifiers for the incoming interrupt as well as that of the
outgoing interrupt like -
<22 0 &intc 36 0>,
<24 0 &intc 37 0>,
<26 0 &intc 38 0>,
And the interrupt specifiers can be interpreted using these properties -
irqdomain-map-mask = <0xff 0>;
irqdomain-map-pass-thru = <0 0xff>;
Let's add a helper function to parse this from DT.
Bug: 150637369
Change-Id: Idb3d698ff1d5353d8efc316e21700a1be4ffc542
Patch-mainline: https://lore.kernel.org/patchwork/patch/1026606
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 0303182e48222df84b24725a4ef16fbd5cecd09d)
These symbols are needed for modularizing pinctrl.
Signed-off-by: Will McVicker <willmcvicker@google.com>
Bug: 145771121
Test: compile, boot
Change-Id: I8693c3a41b5fcab05b8e4a8a82f4057205bafd3b
(cherry picked from commit 9d2cbb36a60747e885f77d776a3ec2bf7523e2e6)
On certain QTI chipsets some GPIOs are direct-connect interrupts
to the GIC.
Even when GPIOs are not used for interrupt generation and interrupt
line is disabled, it does not prevent interrupt to get pending at
GIC_ISPEND. When drivers call enable_irq unwanted interrupt occures.
Introduce irq_chip_get/set_parent_state calls to clear pending irq
which can get called within irq_enable of child irq chip to clear
any pending irq before enabling.
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Bug: 150233439
Change-Id: Ie8559657bd8da926cc741514809ffe9adbd73a80
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit d9233146224bdeec6a8a4cc684bec303e38fb9af)
We don't need this. So disable to improve the ABI diff with vendors.
Bug: 150898578
Test: build
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I16568f2a1a04a0e4733470f2a4f92a451729682a
SoCs may need to handle the case where the temperature is below the
timing closure temperatures of the logic. At low temperature, the timing
closures may not be met. The compensative action at such temperatures is
to increase the voltage, by switching to a higher OPP.
Thermal governors need to understand that the temperatures are
descending in order to correctly estimate the mitigative actions.
Change-Id: I56eb249a853d9c8ed9a96ff8a41a1ba87abb29f4
Bug: 149945768
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
(cherry picked commit from 8a12149c264c7b871932ad90f76e5981452bb4bb)
Signed-off-by: Hridya Valsaraju <hridya@google.com>
Update the whitelist for qcom SoCs.
Signed-off-by: Will McVicker <willmcvicker@google.com>
Bug: 150481249
Change-Id: Ibf82938f70bc5f26bae1ef828cf06117e9d61f88
This is a common config across many devices that we'd like to stablize.
Signed-off-by: Will McVicker <willmcvicker@google.com>
Bug: 150877929
Change-Id: Id56250664324ecbac2c1497ab5eb49c3306ee535
commit c29070e5b9 ("ANDROID: GKI: cma: redirect page allocation to
CMA") added the field cma_alloc to struct zone if CONFIG_CMA. However,
two references to cma_alloc were added in mm/page_alloc.c that
could be reached if CONFIG_MEMORY_ISOLATION and CONFIG_COMPACTION
are defined.
Fixes: c29070e5b9 ("ANDROID: GKI: cma: redirect page allocation to CMA")
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I3a4b803612084a070ba3cc0af11808bea20d324e
Some cases were reported on 3.18 where atomic unmovable allocations
of order 2 fails, but kswapd does not wakeup. And in such cases it
was seen that, when zone_watermark_ok check is performed to decide
whether to wake up kswapd, there were lot of CMA pages of order 2 and
above. This makes the watermark check succeed resulting in kswapd not
being woken up. But since these atomic unmovable allocations can't come
from CMA region, further atomic allocations keeps failing, without
kswapd trying to reclaim. Usually concurrent movable allocations result
in reclaim and improves the situtation, but the case reported was from
a network test which was resulting in only atomic skb allocations being
attempted. On 3.18 this was fixed by adding a cma free page counter and
accouting the cma free pages properly in watermark calculations.
Later this issue was indirectly fixed by the commit "mm, page_alloc:
only enforce watermarks for order-0 allocations".
But the commit "mm: add cma pcp list" brought the problem back because
it includes MIGRATE_CMA within MIGRATE_PCPTYPES, and thus watermark
check erroneously returns success for !ALLOC_CMA by finding free pages
in cma free list.
Change-Id: Id0e48b5c2f9deea93c5875c10d5ec72bd360df5f
Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
Bug: 150808082
Test: build
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I232e5379797ae946e15127852d31c2d29ca35b30
Added the clang compiler option -fno-sanitize-blacklist to the
CC_FLAGS_CFI variable.
Without this flag, the make dependecy list files produced by clang,
have the cfi_blacklist.txt as their first dependency. The dependecy
lists are produced by the -Wp,-MD,filename option (for example:
-Wp,-MD,mm/.mmap.o.d). The dependency lists are processed by the
scripts/basic/fixdeps.c program, and are transformed into the .o.cmd
files (for example: mm/.mmap.o.cmd). That file is meant to have the
source code of the file listed in the source_* make variable (for
example: source_mm/mmap.o). Instead of that that variable refers
to the full pathname to the cfi_blacklist.txt file. Furthermore, the
deps_* make variable is not supposed to include the source code file
but it does include it.
The cfi_blacklist.txt file is not required by the use of CFI for the
kernel, use of the -fno-sanitize-blacklist causes the .o.cmd file
to have the correct values in its source_* and dep_* variables.
Signed-off-by: Ramon Pantin <pantin@google.com>
Bug: 150504710
Test: interactively
Change-Id: Ia9ed73cb9739617a7c928b939cb4b3a6d77723b7
The tests for initializing a variable defined between a switch
statement's test and its first "case" statement are currently not
initialized in Clang[1] nor the proposed auto-initialization feature in
GCC.
We should retain the test (so that we can evaluate compiler fixes),
but mark it as an "expected fail". The rest of the kernel source will
be adjusted to avoid this corner case.
Also disable -Wswitch-unreachable for the test so that the intentionally
broken code won't trigger warnings for GCC (nor future Clang) when
initialization happens this unhandled place.
[1] https://bugs.llvm.org/show_bug.cgi?id=44916
Suggested-by: Alexander Potapenko <glider@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
[adelva: cherry picking to avoid boot test flakes]
Bug: 144999193
Link: https://lore.kernel.org/lkml/202002191358.2897A07C6@keescook/
Change-Id: I0e691f2299ab42526ea306a92551a1188c469136
Signed-off-by: Alistair Delva <adelva@google.com>
Changes in 4.19.108
irqchip/gic-v3-its: Fix misuse of GENMASK macro
iwlwifi: pcie: fix rb_allocator workqueue allocation
ipmi:ssif: Handle a possible NULL pointer reference
drm/msm: Set dma maximum segment size for mdss
dax: pass NOWAIT flag to iomap_apply
mac80211: consider more elements in parsing CRC
cfg80211: check wiphy driver existence for drvinfo report
s390/zcrypt: fix card and queue total counter wrap
qmi_wwan: re-add DW5821e pre-production variant
qmi_wwan: unconditionally reject 2 ep interfaces
ARM: dts: sti: fixup sound frame-inversion for stihxxx-b2120.dtsi
soc/tegra: fuse: Fix build with Tegra194 configuration
net: ena: fix potential crash when rxfh key is NULL
net: ena: fix uses of round_jiffies()
net: ena: add missing ethtool TX timestamping indication
net: ena: fix incorrect default RSS key
net: ena: rss: fix failure to get indirection table
net: ena: rss: store hash function as values and not bits
net: ena: fix incorrectly saving queue numbers when setting RSS indirection table
net: ena: ethtool: use correct value for crc32 hash
net: ena: ena-com.c: prevent NULL pointer dereference
cifs: Fix mode output in debugging statements
cfg80211: add missing policy for NL80211_ATTR_STATUS_CODE
sysrq: Restore original console_loglevel when sysrq disabled
sysrq: Remove duplicated sysrq message
net: fib_rules: Correctly set table field when table number exceeds 8 bits
net: mscc: fix in frame extraction
net: phy: restore mdio regs in the iproc mdio driver
net: sched: correct flower port blocking
nfc: pn544: Fix occasional HW initialization failure
sctp: move the format error check out of __sctp_sf_do_9_1_abort
ipv6: Fix route replacement with dev-only route
ipv6: Fix nlmsg_flags when splitting a multipath route
qede: Fix race between rdma destroy workqueue and link change event
net/tls: Fix to avoid gettig invalid tls record
ext4: potential crash on allocation error in ext4_alloc_flex_bg_array()
audit: fix error handling in audit_data_to_entry()
ACPICA: Introduce ACPI_ACCESS_BYTE_WIDTH() macro
ACPI: watchdog: Fix gas->access_width usage
KVM: VMX: check descriptor table exits on instruction emulation
HID: ite: Only bind to keyboard USB interface on Acer SW5-012 keyboard dock
HID: core: fix off-by-one memset in hid_report_raw_event()
HID: core: increase HID report buffer size to 8KiB
macintosh: therm_windtunnel: fix regression when instantiating devices
tracing: Disable trace_printk() on post poned tests
Revert "PM / devfreq: Modify the device name as devfreq(X) for sysfs"
amdgpu/gmc_v9: save/restore sdpif regs during S3
vhost: Check docket sk_family instead of call getname
HID: alps: Fix an error handling path in 'alps_input_configured()'
HID: hiddev: Fix race in in hiddev_disconnect()
MIPS: VPE: Fix a double free and a memory leak in 'release_vpe()'
i2c: altera: Fix potential integer overflow
i2c: jz4780: silence log flood on txabrt
drm/i915/gvt: Fix orphan vgpu dmabuf_objs' lifetime
drm/i915/gvt: Separate display reset from ALL_ENGINES reset
hv_netvsc: Fix unwanted wakeup in netvsc_attach()
usb: charger: assign specific number for enum value
s390/qeth: vnicc Fix EOPNOTSUPP precedence
net: netlink: cap max groups which will be considered in netlink_bind()
net: atlantic: fix use after free kasan warn
net: atlantic: fix potential error handling
net/smc: no peer ID in CLC decline for SMCD
net: ena: make ena rxfh support ETH_RSS_HASH_NO_CHANGE
namei: only return -ECHILD from follow_dotdot_rcu()
mwifiex: drop most magic numbers from mwifiex_process_tdls_action_frame()
mwifiex: delete unused mwifiex_get_intf_num()
KVM: SVM: Override default MMIO mask if memory encryption is enabled
KVM: Check for a bad hva before dropping into the ghc slow path
sched/fair: Optimize update_blocked_averages()
sched/fair: Fix O(nr_cgroups) in the load balancing path
perf stat: Use perf_evsel__is_clocki() for clock events
perf stat: Fix shadow stats for clock events
drivers: net: xgene: Fix the order of the arguments of 'alloc_etherdev_mqs()'
kprobes: Set unoptimized flag after unoptimizing code
pwm: omap-dmtimer: put_device() after of_find_device_by_node()
perf hists browser: Restore ESC as "Zoom out" of DSO/thread/etc
KVM: x86: Remove spurious kvm_mmu_unload() from vcpu destruction path
KVM: x86: Remove spurious clearing of async #PF MSR
thermal: brcmstb_thermal: Do not use DT coefficients
netfilter: nft_tunnel: no need to call htons() when dumping ports
netfilter: nf_flowtable: fix documentation
mm/huge_memory.c: use head to check huge zero page
mm, thp: fix defrag setting if newline is not used
audit: always check the netlink payload length in audit_receive_msg()
Linux 4.19.108
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ib98db500eded0a83d89c38900bbdf9ff5d6a37e0
commit f42f255265 upstream.
If thp defrag setting "defer" is used and a newline is *not* used when
writing to the sysfs file, this is interpreted as the "defer+madvise"
option.
This is because we do prefix matching and if five characters are written
without a newline, the current code ends up comparing to the first five
bytes of the "defer+madvise" option and using that instead.
Use the more appropriate sysfs_streq() that handles the trailing newline
for us. Since this doubles as a nice cleanup, do it in enabled_store()
as well.
The current implementation relies on prefix matching: the number of
bytes compared is either the number of bytes written or the length of
the option being compared. With a newline, "defer\n" does not match
"defer+"madvise"; without a newline, however, "defer" is considered to
match "defer+madvise" (prefix matching is only comparing the first five
bytes). End result is that writing "defer" is broken unless it has an
additional trailing character.
This means that writing "madv" in the past would match and set
"madvise". With strict checking, that no longer is the case but it is
unlikely anybody is currently doing this.
Link: http://lkml.kernel.org/r/alpine.DEB.2.21.2001171411020.56385@chino.kir.corp.google.com
Fixes: 21440d7eb9 ("mm, thp: add new defer+madvise defrag option")
Signed-off-by: David Rientjes <rientjes@google.com>
Suggested-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 78e06cf430 upstream.
In the flowtable documentation there is a missing semicolon, the command
as is would give this error:
nftables.conf:5:27-33: Error: syntax error, unexpected devices, expecting newline or semicolon
hook ingress priority 0 devices = { br0, pppoe-data };
^^^^^^^
nftables.conf:4:12-13: Error: invalid hook (null)
flowtable ft {
^^
Fixes: 19b351f16f ("netfilter: add flowtable documentation")
Signed-off-by: Matteo Croce <mcroce@redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e1ff6fc22f upstream.
At the time the brcmstb_thermal driver and its binding were merged, the
DT binding did not make the coefficients properties a mandatory one,
therefore all users of the brcmstb_thermal driver out there have a non
functional implementation with zero coefficients. Even if these
properties were provided, the formula used for computation is incorrect.
The coefficients are entirely process specific (right now, only 28nm is
supported) and not board or SoC specific, it is therefore appropriate to
hard code them in the driver given the compatibility string we are
probed with which has to be updated whenever a new process is
introduced.
We remove the existing coefficients definition since subsequent patches
are going to add support for a new process and will introduce new
coefficients as well.
Fixes: 9e03cf1b2d ("thermal: add brcmstb AVS TMON driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200114190607.29339-2-f.fainelli@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 208050dac5 upstream.
Remove a bogus clearing of apf.msr_val from kvm_arch_vcpu_destroy().
apf.msr_val is only set to a non-zero value by kvm_pv_enable_async_pf(),
which is only reachable by kvm_set_msr_common(), i.e. by writing
MSR_KVM_ASYNC_PF_EN. KVM does not autonomously write said MSR, i.e.
can only be written via KVM_SET_MSRS or KVM_RUN. Since KVM_SET_MSRS and
KVM_RUN are vcpu ioctls, they require a valid vcpu file descriptor.
kvm_arch_vcpu_destroy() is only called if KVM_CREATE_VCPU fails, and KVM
declares KVM_CREATE_VCPU successful once the vcpu fd is installed and
thus visible to userspace. Ergo, apf.msr_val cannot be non-zero when
kvm_arch_vcpu_destroy() is called.
Fixes: 344d9588a9 ("KVM: Add PV MSR to enable asynchronous page faults delivery.")
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9d979c7e6f upstream.
x86 does not load its MMU until KVM_RUN, which cannot be invoked until
after vCPU creation succeeds. Given that kvm_arch_vcpu_destroy() is
called if and only if vCPU creation fails, it is impossible for the MMU
to be loaded.
Note, the bogus kvm_mmu_unload() call was added during an unrelated
refactoring of vCPU allocation, i.e. was presumably added as an
opportunstic "fix" for a perceived leak.
Fixes: fb3f0f51d9 ("KVM: Dynamically allocate vcpus")
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c7cb3a1dd5 upstream.
This was found by coccicheck:
drivers/pwm/pwm-omap-dmtimer.c:304:2-8: ERROR: missing put_device;
call of_find_device_by_node on line 255, but without a corresponding
object release within this function.
Reported-by: Markus Elfring <elfring@users.sourceforge.net>
Fixes: 6604c6556d ("pwm: Add PWM driver for OMAP using dual-mode timers")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f66c0447cc upstream.
Set the unoptimized flag after confirming the code is completely
unoptimized. Without this fix, when a kprobe hits the intermediate
modified instruction (the first byte is replaced by an INT3, but
later bytes can still be a jump address operand) while unoptimizing,
it can return to the middle byte of the modified code, which causes
an invalid instruction exception in the kernel.
Usually, this is a rare case, but if we put a probe on the function
call while text patching, it always causes a kernel panic as below:
# echo p text_poke+5 > kprobe_events
# echo 1 > events/kprobes/enable
# echo 0 > events/kprobes/enable
invalid opcode: 0000 [#1] PREEMPT SMP PTI
RIP: 0010:text_poke+0x9/0x50
Call Trace:
arch_unoptimize_kprobe+0x22/0x28
arch_unoptimize_kprobes+0x39/0x87
kprobe_optimizer+0x6e/0x290
process_one_work+0x2a0/0x610
worker_thread+0x28/0x3d0
? process_one_work+0x610/0x610
kthread+0x10d/0x130
? kthread_park+0x80/0x80
ret_from_fork+0x3a/0x50
text_poke() is used for patching the code in optprobes.
This can happen even if we blacklist text_poke() and other functions,
because there is a small time window during which we show the intermediate
code to other CPUs.
[ mingo: Edited the changelog. ]
Tested-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bristot@redhat.com
Fixes: 6274de4984 ("kprobes: Support delayed unoptimizing")
Link: https://lkml.kernel.org/r/157483422375.25881.13508326028469515760.stgit@devnote2
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5a44c71ccd upstream.
'alloc_etherdev_mqs()' expects first 'tx', then 'rx'. The semantic here
looks reversed.
Reorder the arguments passed to 'alloc_etherdev_mqs()' in order to keep
the correct semantic.
In fact, this is a no-op because both XGENE_NUM_[RT]X_RING are 8.
Fixes: 107dec2749 ("drivers: net: xgene: Add support for multiple queues")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 31bc6aeaab upstream.
Removing a cfs_rq from rq->leaf_cfs_rq_list can break the parent/child
ordering of the list when it will be added back. In order to remove an
empty and fully decayed cfs_rq, we must remove its children too, so they
will be added back in the right order next time.
With a normal decay of PELT, a parent will be empty and fully decayed
if all children are empty and fully decayed too. In such a case, we just
have to ensure that the whole branch will be added when a new task is
enqueued. This is default behavior since :
commit f678331973 ("sched/fair: Fix insertion in rq->leaf_cfs_rq_list")
In case of throttling, the PELT of throttled cfs_rq will not be updated
whereas the parent will. This breaks the assumption made above unless we
remove the children of a cfs_rq that is throttled. Then, they will be
added back when unthrottled and a sched_entity will be enqueued.
As throttled cfs_rq are now removed from the list, we can remove the
associated test in update_blocked_averages().
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: sargun@sargun.me
Cc: tj@kernel.org
Cc: xiexiuqi@huawei.com
Cc: xiezhipeng1@huawei.com
Link: https://lkml.kernel.org/r/1549469662-13614-2-git-send-email-vincent.guittot@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Vishnu Rangayyan <vishnu.rangayyan@apple.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fcfbc61754 upstream.
When reading/writing using the guest/host cache, check for a bad hva
before checking for a NULL memslot, which triggers the slow path for
handing cross-page accesses. Because the memslot is nullified on error
by __kvm_gfn_to_hva_cache_init(), if the bad hva is encountered after
crossing into a new page, then the kvm_{read,write}_guest() slow path
could potentially write/access the first chunk prior to detecting the
bad hva.
Arguably, performing a partial access is semantically correct from an
architectural perspective, but that behavior is certainly not intended.
In the original implementation, memslot was not explicitly nullified
and therefore the partial access behavior varied based on whether the
memslot itself was null, or if the hva was simply bad. The current
behavior was introduced as a seemingly unintentional side effect in
commit f1b9dd5eb8 ("kvm: Disallow wraparound in
kvm_gfn_to_hva_cache_init"), which justified the change with "since some
callers don't check the return code from this function, it sit seems
prudent to clear ghc->memslot in the event of an error".
Regardless of intent, the partial access is dependent on _not_ checking
the result of the cache initialization, which is arguably a bug in its
own right, at best simply weird.
Fixes: 8f964525a1 ("KVM: Allow cross page reads and writes from cached translations.")
Cc: Jim Mattson <jmattson@google.com>
Cc: Andrew Honig <ahonig@google.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 52918ed5fc upstream.
The KVM MMIO support uses bit 51 as the reserved bit to cause nested page
faults when a guest performs MMIO. The AMD memory encryption support uses
a CPUID function to define the encryption bit position. Given this, it is
possible that these bits can conflict.
Use svm_hardware_setup() to override the MMIO mask if memory encryption
support is enabled. Various checks are performed to ensure that the mask
is properly defined and rsvd_bits() is used to generate the new mask (as
was done prior to the change that necessitated this patch).
Fixes: 28a1f3ac1d ("kvm: x86: Set highest physical address bits in non-present/reserved SPTEs")
Suggested-by: Sean Christopherson <sean.j.christopherson@intel.com>
Reviewed-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1c9f329b08 upstream.
Commit 7afb94da3c ("mwifiex: update set_mac_address logic") fixed the
only user of this function, partly because the author seems to have
noticed that, as written, it's on the borderline between highly
misleading and buggy.
Anyway, no sense in keeping dead code around: let's drop it.
Fixes: 7afb94da3c ("mwifiex: update set_mac_address logic")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 70e5b8f445 upstream.
Before commit 1e58252e33 ("mwifiex: Fix heap overflow in
mmwifiex_process_tdls_action_frame()"),
mwifiex_process_tdls_action_frame() already had too many magic numbers.
But this commit just added a ton more, in the name of checking for
buffer overflows. That seems like a really bad idea.
Let's make these magic numbers a little less magic, by
(a) factoring out 'pos[1]' as 'ie_len'
(b) using 'sizeof' on the appropriate source or destination fields where
possible, instead of bare numbers
(c) dropping redundant checks, per below.
Regarding redundant checks: the beginning of the loop has this:
if (pos + 2 + pos[1] > end)
break;
but then individual 'case's include stuff like this:
if (pos > end - 3)
return;
if (pos[1] != 1)
return;
Note that the second 'return' (validating the length, pos[1]) combined
with the above condition (ensuring 'pos + 2 + length' doesn't exceed
'end'), makes the first 'return' (whose 'if' can be reworded as 'pos >
end - pos[1] - 2') redundant. Rather than unwind the magic numbers
there, just drop those conditions.
Fixes: 1e58252e33 ("mwifiex: Fix heap overflow in mmwifiex_process_tdls_action_frame()")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2b98149c23 upstream.
It's over-zealous to return hard errors under RCU-walk here, given that
a REF-walk will be triggered for all other cases handling ".." under
RCU.
The original purpose of this check was to ensure that if a rename occurs
such that a directory is moved outside of the bind-mount which the
resolution started in, it would be detected and blocked to avoid being
able to mess with paths outside of the bind-mount. However, triggering a
new REF-walk is just as effective a solution.
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Fixes: 397d425dc2 ("vfs: Test for and handle paths that are unreachable from their mnt_root")
Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 470793a78c upstream.
As the name suggests ETH_RSS_HASH_NO_CHANGE is received upon changing
the key or indirection table using ethtool while keeping the same hash
function.
Also add a function for retrieving the current hash function from
the ena-com layer.
Fixes: 1738cd3ed3 ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)")
Signed-off-by: Sameeh Jubran <sameehj@amazon.com>
Signed-off-by: Saeed Bshara <saeedb@amazon.com>
Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
