Merge tag 'for-linus-5.8b-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull xen fixes from Juergen Gross:
"One small cleanup patch for ARM and two patches for the xenbus driver
fixing latent problems (large stack allocations and bad return code
settings)"
* tag 'for-linus-5.8b-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
xen/xenbus: let xenbus_map_ring_valloc() return errno values only
xen/xenbus: avoid large structs and arrays on the stack
arm/xen: remove the unused macro GRANT_TABLE_PHYSADDR
Merge tag '5.8-rc3-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6
Pull cifs fixes from Steve French:
"Eight cifs/smb3 fixes, most when specifying the multiuser mount flag.
Five of the fixes are for stable"
* tag '5.8-rc3-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6:
cifs: prevent truncation from long to int in wait_for_free_credits
cifs: Fix the target file was deleted when rename failed.
SMB3: Honor 'posix' flag for multiuser mounts
SMB3: Honor 'handletimeout' flag for multiuser mounts
SMB3: Honor lease disabling for multiuser mounts
SMB3: Honor persistent/resilient handle flags for multiuser mounts
SMB3: Honor 'seal' flag for multiuser mounts
cifs: Display local UID details for SMB sessions in DebugData
Merge tag 'hwmon-for-v5.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
Pull hwmon fixes from Guenter Roeck:
- Fix typo in Kconfig SENSORS_IR35221 option
- Fix potential memory leak in acpi_power_meter_add()
- Make sure the OVERT mask is set correctly in max6697 driver
- In PMBus core, fix page vs. register when accessing fans
- Mark is_visible functions static in bt1-pvt driver
- Define Temp- and Volt-to-N poly as maybe-unused in bt1-pvt driver
* tag 'hwmon-for-v5.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
hwmon: (pmbus) fix a typo in Kconfig SENSORS_IR35221 option
hwmon: (acpi_power_meter) Fix potential memory leak in acpi_power_meter_add()
hwmon: (max6697) Make sure the OVERT mask is set correctly
hwmon: (pmbus) Fix page vs. register when accessing fans
hwmon: (bt1-pvt) Mark is_visible functions static
hwmon: (bt1-pvt) Define Temp- and Volt-to-N poly as maybe-unused
Merge misc fixes from Andrew Morton:
"Subsystems affected by this patch series: mm/hugetlb, samples, mm/cma,
mm/vmalloc, mm/pagealloc"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
mm/page_alloc: fix documentation error
vmalloc: fix the owner argument for the new __vmalloc_node_range callers
mm/cma.c: use exact_nid true to fix possible per-numa cma leak
samples/vfs: avoid warning in statx override
mm/hugetlb.c: fix pages per hugetlb calculation
Joel Savitz [Fri, 3 Jul 2020 22:15:30 +0000 (15:15 -0700)]
mm/page_alloc: fix documentation error
When I increased the upper bound of the min_free_kbytes value in a6f630e8bd84b ("mm/page_alloc: increase default min_free_kbytes bound") I
forgot to tweak the above comment to reflect the new value. This patch
fixes that mistake.
Signed-off-by: Joel Savitz <jsavitz@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: Matthew Wilcox <willy@infradead.org> Cc: Rafael Aquini <aquini@redhat.com> Cc: Fabrizio D'Angelo <fdangelo@redhat.com> Link: http://lkml.kernel.org/r/20200624221236.29560-1-jsavitz@redhat.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Barry Song [Fri, 3 Jul 2020 22:15:24 +0000 (15:15 -0700)]
mm/cma.c: use exact_nid true to fix possible per-numa cma leak
Calling cma_declare_contiguous_nid() with false exact_nid for per-numa
reservation can easily cause cma leak and various confusion. For example,
mm/hugetlb.c is trying to reserve per-numa cma for gigantic pages. But it
can easily leak cma and make users confused when system has memoryless
nodes.
In case the system has 4 numa nodes, and only numa node0 has memory. if
we set hugetlb_cma=4G in bootargs, mm/hugetlb.c will get 4 cma areas for 4
different numa nodes. since exact_nid=false in current code, all 4 numa
nodes will get cma successfully from node0, but hugetlb_cma[1 to 3] will
never be available to hugepage will only allocate memory from
hugetlb_cma[0].
In case the system has 4 numa nodes, both numa node0&2 has memory, other
nodes have no memory. if we set hugetlb_cma=4G in bootargs, mm/hugetlb.c
will get 4 cma areas for 4 different numa nodes. since exact_nid=false in
current code, all 4 numa nodes will get cma successfully from node0 or 2,
but hugetlb_cma[1] and [3] will never be available to hugepage as
mm/hugetlb.c will only allocate memory from hugetlb_cma[0] and
hugetlb_cma[2]. This causes permanent leak of the cma areas which are
supposed to be used by memoryless node.
Of cource we can workaround the issue by letting mm/hugetlb.c scan all cma
areas in alloc_gigantic_page() even node_mask includes node0 only. that
means when node_mask includes node0 only, we can get page from
hugetlb_cma[1] to hugetlb_cma[3]. But this will cause kernel crash in
free_gigantic_page() while it wants to free page by:
cma_release(hugetlb_cma[page_to_nid(page)], page, 1 << order)
On the other hand, exact_nid=false won't consider numa distance, it might
be not that useful to leverage cma areas on remote nodes. I feel it is
much simpler to make exact_nid true to make everything clear. After that,
memoryless nodes won't be able to reserve per-numa CMA from other nodes
which have memory.
Fixes: 0eeb7efcd4e6 ("mm: hugetlb: optionally allocate gigantic hugepages using cma") Signed-off-by: Barry Song <song.bao.hua@hisilicon.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Roman Gushchin <guro@fb.com> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Aslan Bakirov <aslan@fb.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: Andreas Schaufler <andreas.schaufler@gmx.de> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: Rik van Riel <riel@surriel.com> Cc: Joonsoo Kim <js1304@gmail.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/20200628074345.27228-1-song.bao.hua@hisilicon.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Something changed recently to uncover this warning:
samples/vfs/test-statx.c:24:15: warning: `struct foo' declared inside parameter list will not be visible outside of this definition or declaration
24 | #define statx foo
| ^~~
Which is due the use of "struct statx" (here, "struct foo") in a function
prototype argument list before it has been defined:
Add explicit struct before #include to avoid warning.
Fixes: 9754747fcf1a ("vfs: Add a sample program for the new mount API") Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: Miklos Szeredi <mszeredi@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: David Howells <dhowells@redhat.com> Link: http://lkml.kernel.org/r/202006282213.C516EA6@keescook Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Mike Kravetz [Fri, 3 Jul 2020 22:15:18 +0000 (15:15 -0700)]
mm/hugetlb.c: fix pages per hugetlb calculation
The routine hpage_nr_pages() was incorrectly used to calculate the number
of base pages in a hugetlb page. hpage_nr_pages is designed to be called
for THP pages and will return HPAGE_PMD_NR for hugetlb pages of any size.
Due to the context in which hpage_nr_pages was called, it is unlikely to
produce a user visible error. The routine with the incorrect call is only
exercised in the case of hugetlb memory error or migration. In addition,
this would need to be on an architecture which supports huge page sizes
less than PMD_SIZE. And, the vma containing the huge page would also need
to smaller than PMD_SIZE.
Fixes: e2f8b8a990f6 ("hugetlbfs: use i_mmap_rwsem for more pmd sharing synchronization") Reported-by: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Michal Hocko <mhocko@kernel.org> Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/20200629185003.97202-1-mike.kravetz@oracle.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge tag 'pci-v5.8-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
Pull PCI fix from Bjorn Helgaas:
"Fix a pcie_find_root_port() simplification that broke power management
because it didn't handle the edge case of finding the Root Port of a
Root Port itself (Mika Westerberg)""
* tag 'pci-v5.8-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
PCI: Make pcie_find_root_port() work for Root Ports
Merge tag 'acpi-5.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI updates from Rafael Wysocki:
"Add a new device ID for Intel Tiger Lake to the DPTF battery
participant driver (Srinivas Pandruvada) and fix the Tiger Lake fan
device ID (Sumeet Pawnikar)"
* tag 'acpi-5.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: fan: Fix Tiger Lake ACPI device ID
ACPI: DPTF: Add battery participant for TigerLake
Merge tag 'gfs2-v5.8-rc3.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2
Pull gfs2 fixes from Andreas Gruenbacher:
"Various gfs2 fixes"
* tag 'gfs2-v5.8-rc3.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2:
gfs2: The freeze glock should never be frozen
gfs2: When freezing gfs2, use GL_EXACT and not GL_NOCACHE
gfs2: read-only mounts should grab the sd_freeze_gl glock
gfs2: freeze should work on read-only mounts
gfs2: eliminate GIF_ORDERED in favor of list_empty
gfs2: Don't sleep during glock hash walk
gfs2: fix trans slab error when withdraw occurs inside log_flush
gfs2: Don't return NULL from gfs2_inode_lookup
exynos:
- error value and reference count fix
- error print removal
sun4i:
- remove HPD polling"
* tag 'drm-fixes-2020-07-03' of git://anongit.freedesktop.org/drm/drm: (22 commits)
drm/amdgpu: use %u rather than %d for sclk/mclk
drm/amdgpu/atomfirmware: fix vram_info fetching for renoir
drm/amd/display: Only revalidate bandwidth on medium and fast updates
drm: sun4i: hdmi: Remove extra HPD polling
drm/i915: Include asm sources for {ivb, hsw}_clear_kernel.c
drm/exynos: fix ref count leak in mic_pre_enable
drm/exynos: Properly propagate return value in drm_iommu_attach_device()
drm/exynos: Remove dev_err() on platform_get_irq() failure
drm/amd/powerplay: Fix NULL dereference in lock_bus() on Vega20 w/o RAS
dma-buf: Move dma_buf_release() from fops to dentry_ops
drm/msm: Fix up the rest of the messed up address sizes
drm/msm: Fix setup of a6xx create_address_space.
drm/msm: Fix address space size after refactor.
drm/i915/gvt: Use GFP_ATOMIC instead of GFP_KERNEL in atomic context
drm/i915/gvt: Fix incorrect check of enabled bits in mask registers
drm/i915/gvt: Fix two CFL MMIO handling caused by regression.
drm/i915/gvt: Add one missing MMIO handler for D_SKL_PLUS
drm/msm: Fix 0xfffflub in "Refactor address space initialization"
drm/msm/dpu: allow initialization of encoder locks during encoder init
drm/msm/dpu: fix error return code in dpu_encoder_init
...
Bob Peterson [Thu, 25 Jun 2020 19:42:17 +0000 (14:42 -0500)]
gfs2: The freeze glock should never be frozen
Before this patch, some gfs2 code locked the freeze glock with LM_FLAG_NOEXP
(Do not freeze) flag, and some did not. We never want to freeze the freeze
glock, so this patch makes it consistently use LM_FLAG_NOEXP always.
Bob Peterson [Thu, 25 Jun 2020 18:30:52 +0000 (13:30 -0500)]
gfs2: When freezing gfs2, use GL_EXACT and not GL_NOCACHE
Before this patch, the freeze code in gfs2 specified GL_NOCACHE in
several places. That's wrong because we always want to know the state
of whether the file system is frozen.
There was also a problem with freeze/thaw transitioning the glock from
frozen (EX) to thawed (SH) because gfs2 will normally grant glocks in EX
to processes that request it in SH mode, unless GL_EXACT is specified.
Therefore, the freeze/thaw code, which tried to reacquire the glock in
SH mode would get the glock in EX mode, and miss the transition from EX
to SH. That made it think the thaw had completed normally, but since the
glock was still cached in EX, other nodes could not freeze again.
This patch removes the GL_NOCACHE flag to allow the freeze glock to be
cached. It also adds the GL_EXACT flag so the glock is fully transitioned
from EX to SH, thereby allowing future freeze operations.
Bob Peterson [Thu, 25 Jun 2020 18:30:18 +0000 (13:30 -0500)]
gfs2: read-only mounts should grab the sd_freeze_gl glock
Before this patch, only read-write mounts would grab the freeze
glock in read-only mode, as part of gfs2_make_fs_rw. So the freeze
glock was never initialized. That meant requests to freeze, which
request the glock in EX, were granted without any state transition.
That meant you could mount a gfs2 file system, which is currently
frozen on a different cluster node, in read-only mode.
This patch makes read-only mounts lock the freeze glock in SH mode,
which will block for file systems that are frozen on another node.
Bob Peterson [Thu, 25 Jun 2020 18:29:44 +0000 (13:29 -0500)]
gfs2: freeze should work on read-only mounts
Before this patch, function freeze_go_sync, called when promoting
the freeze glock, was testing for the SDF_JOURNAL_LIVE superblock flag.
That's only set for read-write mounts. Read-only mounts don't use a
journal, so the bit is never set, so the freeze never happened.
This patch removes the check for SDF_JOURNAL_LIVE for freeze requests
but still checks it when deciding whether to flush a journal.
Bob Peterson [Wed, 17 Jun 2020 12:47:34 +0000 (07:47 -0500)]
gfs2: eliminate GIF_ORDERED in favor of list_empty
In several places, we used the GIF_ORDERED inode flag to determine
if an inode was on the ordered writes list. However, since we always
held the sd_ordered_lock spin_lock during the manipulation, we can
just as easily check list_empty(&ip->i_ordered) instead.
This allows us to keep more than one ordered writes list to make
journal writing improvements.
This patch eliminates GIF_ORDERED in favor of checking list_empty.
Merge tag 'm68knommu-for-v5.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu
Pull m68knommu mm fixes from Greg Ungerer:
"Two critical mm related fixes that affect booting of m68k/ColdFire
devices.
Both fix problems caused by recent system init memblock changes"
* tag 'm68knommu-for-v5.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu:
m68k: mm: fix node memblock init
m68k: nommu: register start of the memory with memblock
Merge tag 'devicetree-fixes-for-5.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
Pull devicetree fixes from Rob Herring:
- Sync dtc to upstream to pick up fixes for I2C bus checks and quiet
warnings
- Various fixes for DT binding check warnings
- A couple of build fixes/improvements for binding checks
- ReST formatting improvements for writing-schema.rst
- Document reference fixes
* tag 'devicetree-fixes-for-5.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
dt-bindings: clock: imx: Fix e-mail address
dt-bindings: thermal: k3: Fix the reg property
dt-bindings: thermal: Remove soc unit address
dt-bindings: display: arm: versatile: Pass the sysreg unit name
dt-bindings: usb: aspeed: Remove the leading zeroes
dt-bindings: copy process-schema-examples.yaml to process-schema.yaml
dt-bindings: do not build processed-schema.yaml for 'make dt_binding_check'
dt-bindings: fix error in 'make clean' after 'make dt_binding_check'
dt-bindings: mailbox: zynqmp_ipi: fix unit address
dt-bindings: bus: uniphier-system-bus: fix warning in example
scripts/dtc: Update to upstream version v1.6.0-11-g9d7888cbf19c
doc: devicetree: bindings: fix spelling mistake
docs: dt: minor adjustments at writing-schema.rst
dt: fix reference to olpc,xo1.75-ec.txt
dt: Fix broken references to renamed docs
dt: fix broken links due to txt->yaml renames
dt: update a reference for reneases pcar file renamed to yaml
Merge tag 'for-linus-2020-07-02' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux
Pull data race annotation from Christian Brauner:
"This contains an annotation patch for a data race in copy_process()
reported by KCSAN when reading and writing nr_threads.
The data race is intentional and benign. This is obvious from the
comment above the relevant code and based on general consensus when
discussing this issue. So simply using data_race() to annotate this as
an intentional race seems the best option"
* tag 'for-linus-2020-07-02' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux:
fork: annotate data race in copy_process()
Merge tag 'tpmdd-next-v5.8-rc4' of git://git.infradead.org/users/jjs/linux-tpmdd
Pull tpm fixes from Jarkko Sakkinen:
"These are just fixes for bugs found lately.
All of them are small scale things here and there, and all of them are
for previous kernel releases (the oldest appeared in v2.6.17)"
* tag 'tpmdd-next-v5.8-rc4' of git://git.infradead.org/users/jjs/linux-tpmdd:
tpm_tis: Remove the HID IFX0102
tpm_tis_spi: Prefer async probe
tpm: ibmvtpm: Wait for ready buffer before probing for TPM2 attributes
tpm/st33zp24: fix spelling mistake "drescription" -> "description"
tpm_tis: extra chip->ops check on error path in tpm_tis_core_init
tpm_tis_spi: Don't send anything during flow control
tpm: Fix TIS locality timeout problems
Merge tag 'linux-kselftest-fixes-5.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
Pull kselftest fixes from Shuah Khan:
"tpm test fixes from Jarkko Sakkinen"
* tag 'linux-kselftest-fixes-5.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest:
selftests: tpm: Use /bin/sh instead of /bin/bash
selftests: tpm: Use 'test -e' instead of 'test -f'
Revert "tpm: selftest: cleanup after unseal with wrong auth/policy test"
Merge tag 'linux-kselftest-kunit-fixes-5.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
Pull kunit fixes from Shuah Khan
"Fixes for build and run-times failures.
Also includes troubleshooting tips updates to kunit user
documentation"
* tag 'linux-kselftest-kunit-fixes-5.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest:
Documentation: kunit: Add some troubleshooting tips to the FAQ
kunit: kunit_tool: Fix invalid result when build fails
kunit: show error if kunit results are not present
kunit: kunit_config: Fix parsing of CONFIG options with space
Merge tag 'nfsd-5.8-1' of git://linux-nfs.org/~bfields/linux
Pull nfsd fixes from Bruce Fields:
"Fixes for a umask bug on exported filesystems lacking ACL support, a
leak and a module unloading bug in the /proc/fs/nfsd/clients/ code,
and a compile warning"
* tag 'nfsd-5.8-1' of git://linux-nfs.org/~bfields/linux:
SUNRPC: Add missing definition of ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE
nfsd: fix nfsdfs inode reference count leak
nfsd4: fix nfsdfs reference count loop
nfsd: apply umask on fs without ACL support
Merge tag 'block-5.8-2020-07-01' of git://git.kernel.dk/linux-block
Pull block fixes from Jens Axboe:
- Use kvfree_sensitive() for the block keyslot free (Eric)
- Sync blk-mq debugfs flags (Hou)
- Memory leak fix in virtio-blk error path (Hou)
* tag 'block-5.8-2020-07-01' of git://git.kernel.dk/linux-block:
virtio-blk: free vblk-vqs in error path of virtblk_probe()
block/keyslot-manager: use kvfree_sensitive()
blk-mq-debugfs: update blk_queue_flag_name[] accordingly for new flags
Merge tag 'io_uring-5.8-2020-07-01' of git://git.kernel.dk/linux-block
Pull io_uring fixes from Jens Axboe:
"One fix in here, for a regression in 5.7 where a task is waiting in
the kernel for a condition, but that condition won't become true until
task_work is run. And the task_work can't be run exactly because the
task is waiting in the kernel, so we'll never make any progress.
One example of that is registering an eventfd and queueing io_uring
work, and then the task goes and waits in eventfd read with the
expectation that it'll get woken (and read an event) when the io_uring
request completes. The io_uring request is finished through task_work,
which won't get run while the task is looping in eventfd read"
* tag 'io_uring-5.8-2020-07-01' of git://git.kernel.dk/linux-block:
io_uring: use signal based task_work running
task_work: teach task_work_add() to do signal_wake_up()
xen/xenbus: let xenbus_map_ring_valloc() return errno values only
Today xenbus_map_ring_valloc() can return either a negative errno
value (-ENOMEM or -EINVAL) or a grant status value. This is a mess as
e.g -ENOMEM and GNTST_eagain have the same numeric value.
Fix that by turning all grant mapping errors into -ENOENT. This is
no problem as all callers of xenbus_map_ring_valloc() only use the
return value to print an error message, and in case of mapping errors
the grant status value has already been printed by __xenbus_map_ring()
before.
xen/xenbus: avoid large structs and arrays on the stack
xenbus_map_ring_valloc() and its sub-functions are putting quite large
structs and arrays on the stack. This is problematic at runtime, but
might also result in build failures (e.g. with clang due to the option
-Werror,-Wframe-larger-than=... used).
Fix that by moving most of the data from the stack into a dynamically
allocated struct. Performance is no issue here, as
xenbus_map_ring_valloc() is used only when adding a new PV device to
a backend driver.
While at it move some duplicated code from pv/hvm specific mapping
functions to the single caller.
Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/20200701121638.19840-2-jgross@suse.com Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Jarkko Sakkinen [Thu, 25 Jun 2020 02:31:11 +0000 (05:31 +0300)]
tpm_tis: Remove the HID IFX0102
Acer C720 running Linux v5.3 reports this in klog:
tpm_tis: 1.2 TPM (device-id 0xB, rev-id 16)
tpm tpm0: tpm_try_transmit: send(): error -5
tpm tpm0: A TPM error (-5) occurred attempting to determine the timeouts
tpm_tis tpm_tis: Could not get TPM timeouts and durations
tpm_tis 00:08: 1.2 TPM (device-id 0xB, rev-id 16)
tpm tpm0: tpm_try_transmit: send(): error -5
tpm tpm0: A TPM error (-5) occurred attempting to determine the timeouts
tpm_tis 00:08: Could not get TPM timeouts and durations
ima: No TPM chip found, activating TPM-bypass!
tpm_inf_pnp 00:08: Found TPM with ID IFX0102
Douglas Anderson [Fri, 19 Jun 2020 21:20:01 +0000 (14:20 -0700)]
tpm_tis_spi: Prefer async probe
On a Chromebook I'm working on I noticed a big (~1 second) delay
during bootup where nothing was happening. Right around this big
delay there were messages about the TPM:
I put a few printouts in and saw that tpm_tis_spi_init() (specifically
tpm_chip_register() in that function) was taking the lion's share of
this time, though ~115 ms of the time was in cr50_print_fw_version().
Let's make a one-line change to prefer async probe for tpm_tis_spi.
There's no reason we need to block other drivers from probing while we
load.
NOTES:
* It's possible that other hardware runs through the init sequence
faster than Cr50 and this isn't such a big problem for them.
However, even if they are faster they are still doing _some_
transfers over a SPI bus so this should benefit everyone even if to
a lesser extent.
* It's possible that there are extra delays in the code that could be
optimized out. I didn't dig since once I enabled async probe they
no longer impacted me.
Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
David Gibson [Fri, 19 Jun 2020 03:30:40 +0000 (13:30 +1000)]
tpm: ibmvtpm: Wait for ready buffer before probing for TPM2 attributes
The tpm2_get_cc_attrs_tbl() call will result in TPM commands being issued,
which will need the use of the internal command/response buffer. But,
we're issuing this *before* we've waited to make sure that buffer is
allocated.
This can result in intermittent failures to probe if the hypervisor / TPM
implementation doesn't respond quickly enough. I find it fails almost
every time with an 8 vcpu guest under KVM with software emulated TPM.
To fix it, just move the tpm2_get_cc_attrs_tlb() call after the
existing code to wait for initialization, which will ensure the buffer
is allocated.
Fixes: d365e50ac125f ("tpm: ibmvtpm: Add support for TPM2") Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Douglas Anderson [Thu, 28 May 2020 22:19:30 +0000 (15:19 -0700)]
tpm_tis_spi: Don't send anything during flow control
During flow control we are just reading from the TPM, yet our spi_xfer
has the tx_buf and rx_buf both non-NULL which means we're requesting a
full duplex transfer.
SPI is always somewhat of a full duplex protocol anyway and in theory
the other side shouldn't really be looking at what we're sending it
during flow control, but it's still a bit ugly to be sending some
"random" data when we shouldn't.
The default tpm_tis_spi_flow_control() tries to address this by
setting 'phy->iobuf[0] = 0'. This partially avoids the problem of
sending "random" data, but since our tx_buf and rx_buf both point to
the same place I believe there is the potential of us sending the
TPM's previous byte back to it if we hit the retry loop.
Another flow control implementation, cr50_spi_flow_control(), doesn't
address this at all.
Let's clean this up and just make the tx_buf NULL before we call
flow_control(). Not only does this ensure that we're not sending any
"random" bytes but it also possibly could make the SPI controller
behave in a slightly more optimal way.
NOTE: no actual observed problems are fixed by this patch--it's was
just made based on code inspection.
Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
James Bottomley [Thu, 28 May 2020 18:10:57 +0000 (11:10 -0700)]
tpm: Fix TIS locality timeout problems
It has been reported that some TIS based TPMs are giving unexpected
errors when using the O_NONBLOCK path of the TPM device. The problem
is that some TPMs don't like it when you get and then relinquish a
locality (as the tpm_try_get_ops()/tpm_put_ops() pair does) without
sending a command. This currently happens all the time in the
O_NONBLOCK write path. Fix this by moving the tpm_try_get_ops()
further down the code to after the O_NONBLOCK determination is made.
This is safe because the priv->buffer_mutex still protects the priv
state being modified.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206275 Fixes: 085f24905ca2 ("tpm: fix invalid locking in NONBLOCKING mode") Reported-by: Mario Limonciello <Mario.Limonciello@dell.com> Tested-by: Alex Guzman <alex@guzman.io> Cc: stable@vger.kernel.org Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Ronnie Sahlberg [Thu, 2 Jul 2020 00:55:41 +0000 (10:55 +1000)]
cifs: prevent truncation from long to int in wait_for_free_credits
The wait_event_... defines evaluate to long so we should not assign it an int as this may truncate
the value.
Reported-by: Marshall Midden <marshallmidden@gmail.com> Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com> Signed-off-by: Steve French <stfrench@microsoft.com>
Zhang Xiaoxu [Mon, 29 Jun 2020 01:06:38 +0000 (21:06 -0400)]
cifs: Fix the target file was deleted when rename failed.
When xfstest generic/035, we found the target file was deleted
if the rename return -EACESS.
In cifs_rename2, we unlink the positive target dentry if rename
failed with EACESS or EEXIST, even if the target dentry is positived
before rename. Then the existing file was deleted.
We should just delete the target file which created during the
rename.
Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com> Cc: stable@vger.kernel.org Signed-off-by: Steve French <stfrench@microsoft.com> Reviewed-by: Aurelien Aptel <aaptel@suse.com>
Paul Aurich [Fri, 26 Jun 2020 19:58:09 +0000 (12:58 -0700)]
SMB3: Honor 'posix' flag for multiuser mounts
The flag from the primary tcon needs to be copied into the volume info
so that cifs_get_tcon will try to enable extensions on the per-user
tcon. At that point, since posix extensions must have already been
enabled on the superblock, don't try to needlessly adjust the mount
flags.
Fixes: 9244fc87510e ("smb3: Add posix create context for smb3.11 posix mounts") Fixes: 4d822ce24683 ("smb3: allow "posix" mount option to enable new SMB311 protocol extensions") Signed-off-by: Paul Aurich <paul@darkrain42.org> Signed-off-by: Steve French <stfrench@microsoft.com> Reviewed-by: Aurelien Aptel <aaptel@suse.com>
Paul Aurich [Fri, 26 Jun 2020 19:58:08 +0000 (12:58 -0700)]
SMB3: Honor 'handletimeout' flag for multiuser mounts
Fixes: 895c71aa1b73 ("SMB3: Allow persistent handle timeout to be configurable on mount") Signed-off-by: Paul Aurich <paul@darkrain42.org> CC: Stable <stable@vger.kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com> Reviewed-by: Aurelien Aptel <aaptel@suse.com>
Paul Aurich [Fri, 26 Jun 2020 19:58:06 +0000 (12:58 -0700)]
SMB3: Honor persistent/resilient handle flags for multiuser mounts
Without this:
- persistent handles will only be enabled for per-user tcons if the
server advertises the 'Continuous Availabity' capability
- resilient handles would never be enabled for per-user tcons
Signed-off-by: Paul Aurich <paul@darkrain42.org> CC: Stable <stable@vger.kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com> Reviewed-by: Aurelien Aptel <aaptel@suse.com>
Paul Aurich [Fri, 26 Jun 2020 19:58:05 +0000 (12:58 -0700)]
SMB3: Honor 'seal' flag for multiuser mounts
Ensure multiuser SMB3 mounts use encryption for all users' tcons if the
mount options are configured to require encryption. Without this, only
the primary tcon and IPC tcons are guaranteed to be encrypted. Per-user
tcons would only be encrypted if the server was configured to require
encryption.
Signed-off-by: Paul Aurich <paul@darkrain42.org> CC: Stable <stable@vger.kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com> Reviewed-by: Aurelien Aptel <aaptel@suse.com>
Merge tag 'hyperv-fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux
Pull hyperv fix from Wei Liu:
"One patch from Joseph to make panic reporting contain more useful
information"
* tag 'hyperv-fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux:
Drivers: hv: Change flag to write log level in panic msg to false
Alex Deucher [Thu, 25 Jun 2020 21:55:57 +0000 (17:55 -0400)]
drm/amdgpu/atomfirmware: fix vram_info fetching for renoir
Renoir uses integrated_system_info table v12. The table
has the same layout as v11 with respect to this data. Just
reuse the existing code for v12 for stable.
Fixes incorrectly reported vram info in the driver output.
Acked-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
Dave Airlie [Wed, 1 Jul 2020 05:40:52 +0000 (15:40 +1000)]
Merge tag 'exynos-drm-fixes-for-v5.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes
Two fixups
- It fixes wrong return value by returing proper error value instead of
fixed one.
- It fixes ref count leak in mic_pre_enable.
One cleanup
- It removes dev_err() call on platform_get_irq() failure because
platform_get_irq() call dev_err() itself on failure.
drm/amd/display: Only revalidate bandwidth on medium and fast updates
[Why]
Changes that are fast don't require updating DLG parameters making
this call unnecessary. Considering this is an expensive call it should
not be done on every flip.
DML touches clocks, p-state support, DLG params and a few other DC
internal flags and these aren't expected during fast. A hang has been
reported with this change when called on every flip which suggests that
modifying these fields is not recommended behavior on fast updates.
[How]
Guard the validation to only happen if update type isn't FAST.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1191 Fixes: c0bc058560ba49 ("drm/amd/display: Revalidate bandwidth before commiting DC updates") Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
Hou Tao [Mon, 15 Jun 2020 04:14:59 +0000 (12:14 +0800)]
virtio-blk: free vblk-vqs in error path of virtblk_probe()
Else there will be memory leak if alloc_disk() fails.
Fixes: c8e7ecf816a4 ("block: virtio-blk: support multi virt queues per virtio-blk device") Signed-off-by: Hou Tao <houtao1@huawei.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
Mika Westerberg [Mon, 22 Jun 2020 16:12:48 +0000 (19:12 +0300)]
PCI: Make pcie_find_root_port() work for Root Ports
Commit c32c30c154e4 ("PCI: Unify pcie_find_root_port() and
pci_find_pcie_root_port()") broke acpi_pci_bridge_d3() because calling
pcie_find_root_port() on a Root Port returned NULL when it should return
the Root Port, which in turn broke power management of PCIe hierarchies.
Rework pcie_find_root_port() so it returns its argument when it is already
a Root Port.
[bhelgaas: test device only once, test for PCIe] Fixes: c32c30c154e4 ("PCI: Unify pcie_find_root_port() and pci_find_pcie_root_port()") Link: https://lore.kernel.org/r/20200622161248.51099-1-mika.westerberg@linux.intel.com Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Linus Torvalds [Tue, 30 Jun 2020 19:35:11 +0000 (12:35 -0700)]
Merge tag 'exfat-for-5.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat
Pull exfat fixes from Namjae Jeon:
- Zero out unused characters of FileName field to avoid a complaint
from some fsck tool.
- Fix memory leak on error paths.
- Fix unnecessary VOL_DIRTY set when calling rmdir on non-empty
directory.
- Call sync_filesystem() for read-only remount (Fix generic/452 test in
xfstests)
- Add own fsync() to flush dirty metadata.
* tag 'exfat-for-5.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat:
exfat: flush dirty metadata in fsync
exfat: move setting VOL_DIRTY over exfat_remove_entries()
exfat: call sync_filesystem for read-only remount
exfat: add missing brelse() calls on error paths
exfat: Set the unused characters of FileName field to the value 0000h
Linus Torvalds [Tue, 30 Jun 2020 19:21:53 +0000 (12:21 -0700)]
Merge tag 'fixes-v5.8-rc3-a' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
Pull security subsystem fixes from James Morris:
"Two simple fixes for v5.8:
- Fix hook iteration and default value for inode_copy_up_xattr
(KP Singh)
- Fix the key_permission LSM hook function type (Sami Tolvanen)"
* tag 'fixes-v5.8-rc3-a' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
security: Fix hook iteration and default value for inode_copy_up_xattr
security: fix the key_permission LSM hook function type
Linus Torvalds [Tue, 30 Jun 2020 19:17:21 +0000 (12:17 -0700)]
Merge tag 'integrity-v5.8-fix-2' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity
Pull integrity updates from Mimi Zohar:
"Include PCRs 8 & 9 in per TPM 2.0 bank boot_aggregate calculation.
Prior to Linux 5.8 the SHA1 "boot_aggregate" value was padded with 0's
and extended into the other TPM 2.0 banks.
Included in the Linux 5.8 open window, TPM 2.0 PCR bank specific
"boot_aggregate" values (PCRs 0 - 7) are calculated and extended into the TPM banks.
Distro releases are now shipping grub2 with TPM support, which extend
PCRs 8 & 9. I'd like for PCRs 8 & 9 to be included in the new
"boot_aggregate" calculations.
For backwards compatibility, if the hash is SHA1, these new PCRs are
not included in the boot aggregate"
* tag 'integrity-v5.8-fix-2' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity:
ima: extend boot_aggregate with kernel measurements
Jens Axboe [Tue, 30 Jun 2020 18:39:05 +0000 (12:39 -0600)]
io_uring: use signal based task_work running
Since 5.7, we've been using task_work to trigger async running of
requests in the context of the original task. This generally works
great, but there's a case where if the task is currently blocked
in the kernel waiting on a condition to become true, it won't process
task_work. Even though the task is woken, it just checks whatever
condition it's waiting on, and goes back to sleep if it's still false.
This is a problem if that very condition only becomes true when that
task_work is run. An example of that is the task registering an eventfd
with io_uring, and it's now blocked waiting on an eventfd read. That
read could depend on a completion event, and that completion event
won't get trigged until task_work has been run.
Use the TWA_SIGNAL notification for task_work, so that we ensure that
the task always runs the work when queued.
Oleg Nesterov [Tue, 30 Jun 2020 15:32:54 +0000 (17:32 +0200)]
task_work: teach task_work_add() to do signal_wake_up()
So that the target task will exit the wait_event_interruptible-like
loop and call task_work_run() asap.
The patch turns "bool notify" into 0,TWA_RESUME,TWA_SIGNAL enum, the
new TWA_SIGNAL flag implies signal_wake_up(). However, it needs to
avoid the race with recalc_sigpending(), so the patch also adds the
new JOBCTL_TASK_WORK bit included in JOBCTL_PENDING_MASK.
TODO: once this patch is merged we need to change all current users
of task_work_add(notify = true) to use TWA_RESUME.
Fabio Estevam [Tue, 30 Jun 2020 12:18:04 +0000 (09:18 -0300)]
dt-bindings: thermal: Remove soc unit address
Remove the soc unit address to fix the following warnings seen with
'make dt_binding_check':
Documentation/devicetree/bindings/thermal/thermal-sensor.example.dts:22.20-49.11: Warning (unit_address_vs_reg): /example-0/soc@0: node has a unit name, but no reg or ranges property
Documentation/devicetree/bindings/thermal/thermal-zones.example.dts:23.20-50.11: Warning (unit_address_vs_reg): /example-0/soc@0: node has a unit name, but no reg or ranges property
Fabio Estevam [Mon, 29 Jun 2020 21:40:27 +0000 (18:40 -0300)]
dt-bindings: usb: aspeed: Remove the leading zeroes
Remove the leading zeroes to fix the following warning seen with
'make dt_binding_check':
Documentation/devicetree/bindings/usb/aspeed,usb-vhub.example.dts:37.33-42.23: Warning (unit_address_format): /example-0/usb-vhub@1e6a0000/vhub-strings/string@0409: unit name should not have leading 0s
Masahiro Yamada [Thu, 25 Jun 2020 17:04:33 +0000 (02:04 +0900)]
dt-bindings: copy process-schema-examples.yaml to process-schema.yaml
There are two processed schema files:
- processed-schema-examples.yaml
Used for 'make dt_binding_check'. This is always a full schema.
- processed-schema.yaml
Used for 'make dtbs_check'. This may be a full schema, or a smaller
subset if DT_SCHEMA_FILES is given by a user.
If DT_SCHEMA_FILES is not specified, they are the same. You can copy
the former to the latter instead of running dt-mk-schema twice. This
saves the cpu time a lot when you do 'make dt_binding_check dtbs_check'
because building the full schema takes a couple of seconds.
If DT_SCHEMA_FILES is specified, processed-schema.yaml is generated
based on the specified yaml files.
Masahiro Yamada [Thu, 25 Jun 2020 17:04:31 +0000 (02:04 +0900)]
dt-bindings: fix error in 'make clean' after 'make dt_binding_check'
We are having more and more schema files.
Commit f1843429c6e0 ("dt-bindings: Fix command line length limit
calling dt-mk-schema") fixed the 'Argument list too long' error of
the schema checks, but the same error happens while cleaning too.
'make clean' after 'make dt_binding_check' fails as follows:
$ make dt_binding_check
[ snip ]
$ make clean
make[2]: execvp: /bin/sh: Argument list too long
make[2]: *** [scripts/Makefile.clean:52: __clean] Error 127
make[1]: *** [scripts/Makefile.clean:66: Documentation/devicetree/bindings] Error 2
make: *** [Makefile:1763: _clean_Documentation] Error 2
'make dt_binding_check' generates so many .example.dts, .dt.yaml files,
which are passed to the 'rm' command when you run 'make clean'.
I added a small hack to use the 'find' command to clean up most of the
build artifacts before they are processed by scripts/Makefile.clean
In flush_delete_work, instead of flushing each individual pending
delayed work item, cancel and re-queue them for immediate execution.
The waiting isn't needed here because we're already waiting for all
queued work items to complete in gfs2_flush_delete_work. This makes the
code more efficient, but more importantly, it avoids sleeping during a
rhashtable walk, inside rcu_read_lock().
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Bob Peterson [Tue, 9 Jun 2020 13:55:11 +0000 (09:55 -0400)]
gfs2: fix trans slab error when withdraw occurs inside log_flush
Log flush operations (gfs2_log_flush()) can target a specific transaction.
But if the function encounters errors (e.g. io errors) and withdraws,
the transaction was only freed it if was queued to one of the ail lists.
If the withdraw occurred before the transaction was queued to the ail1
list, function ail_drain never freed it. The result was:
BUG gfs2_trans: Objects remaining in gfs2_trans on __kmem_cache_shutdown()
This patch makes log_flush() add the targeted transaction to the ail1
list so that function ail_drain() will find and free it properly.
Cc: stable@vger.kernel.org # v5.7+ Signed-off-by: Bob Peterson <rpeterso@redhat.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Callers expect gfs2_inode_lookup to return an inode pointer or ERR_PTR(error).
Commit fe2ca5d3afb3 caused it to return NULL instead of ERR_PTR(-ESTALE) in
some cases. Fix that.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: fe2ca5d3afb3 ("gfs2: Move inode generation number check into gfs2_inode_lookup") Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Chen-Yu Tsai [Mon, 29 Jun 2020 06:00:32 +0000 (14:00 +0800)]
drm: sun4i: hdmi: Remove extra HPD polling
The HPD sense mechanism in Allwinner's old HDMI encoder hardware is more
or less an input-only GPIO. Other GPIO-based HPD implementations
directly return the current state, instead of polling for a specific
state and returning the other if that times out.
Remove the I/O polling from sun4i_hdmi_connector_detect() and directly
return a known state based on the current reading. This also gets rid
of excessive CPU usage by kworker as reported on Stack Exchange [1] and
Armbian forums [2].
Xiaofei Tan [Sun, 28 Jun 2020 00:57:06 +0000 (08:57 +0800)]
arm/xen: remove the unused macro GRANT_TABLE_PHYSADDR
Fix the following sparse warning:
arch/arm64/xen/../../arm/xen/enlighten.c:244: warning: macro
"GRANT_TABLE_PHYSADDR" is not used [-Wunused-macros]
It is an isolated macro, and should be removed when its last user
was deleted in the following commit 8791ca795b38 ("arm/xen: Use
xen_xlate_map_ballooned_pages to setup grant table")
Jarkko Sakkinen [Mon, 22 Jun 2020 21:20:20 +0000 (00:20 +0300)]
Revert "tpm: selftest: cleanup after unseal with wrong auth/policy test"
The reverted commit illegitly uses tpm2-tools. External dependencies are
absolutely forbidden from these tests. There is also the problem that
clearing is not necessarily wanted behavior if the test/target computer is
not used only solely for testing.
Fixes: e015d0123c5b ("tpm: selftest: cleanup after unseal with wrong auth/policy test") Cc: Tadeusz Struk <tadeusz.struk@intel.com> Cc: stable@vger.kernel.org Cc: linux-integrity@vger.kernel.org Cc: linux-kselftest@vger.kernel.org Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Christophe Leroy [Mon, 15 Jun 2020 06:25:23 +0000 (06:25 +0000)]
SUNRPC: Add missing definition of ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE
Even if that's only a warning, not including asm/cacheflush.h
leads to svc_flush_bvec() being empty allthough powerpc defines
ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE.
CC net/sunrpc/svcsock.o
net/sunrpc/svcsock.c:227:5: warning: "ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE" is not defined [-Wundef]
#if ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE
^
Include linux/highmem.h so that asm/cacheflush.h will be included.
Reported-by: Christophe Leroy <christophe.leroy@csgroup.eu> Reported-by: kernel test robot <lkp@intel.com> Fixes: 257a978d11ed ("SUNRPC: Refactor svc_recvfrom()") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Acked-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
J. Bruce Fields [Wed, 24 Jun 2020 01:01:19 +0000 (21:01 -0400)]
nfsd: fix nfsdfs inode reference count leak
I don't understand this code well, but I'm seeing a warning about a
still-referenced inode on unmount, and every other similar filesystem
does a dput() here.
Fixes: 27f1686b579d ("nfsd: add nfsd/clients directory") Signed-off-by: J. Bruce Fields <bfields@redhat.com>
J. Bruce Fields [Tue, 23 Jun 2020 20:00:33 +0000 (16:00 -0400)]
nfsd4: fix nfsdfs reference count loop
We don't drop the reference on the nfsdfs filesystem with
mntput(nn->nfsd_mnt) until nfsd_exit_net(), but that won't be called
until the nfsd module's unloaded, and we can't unload the module as long
as there's a reference on nfsdfs. So this prevents module unloading.
Fixes: dfaa4071f312 ("nfsd: persist nfsd filesystem across mounts") Reported-and-Tested-by: Luo Xiaogang <lxgrxd@163.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Linus Torvalds [Mon, 29 Jun 2020 17:10:16 +0000 (10:10 -0700)]
Merge tag 'spi-fix-v5.8-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A batch of fixes for the Freescale DSPI driver fixing some serious
issues with removal of active devices and one resume case, plus a few
new PCI IDs for Intel platforms"
* tag 'spi-fix-v5.8-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: pxa2xx: Add support for Intel Tiger Lake PCH-H
spi: spi-fsl-dspi: Initialize completion before possible interrupt
spi: spi-fsl-dspi: Fix external abort on interrupt in resume or exit paths
spi: spi-fsl-dspi: Fix lockup if device is shutdown during SPI transfer
spi: spi-fsl-dspi: Fix lockup if device is removed during SPI transfer
Linus Torvalds [Mon, 29 Jun 2020 17:08:15 +0000 (10:08 -0700)]
Merge tag 'thermal-v5.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/thermal/linux
Pull thermal fixes from Daniel Lezcano:
- Fix undefined temperature if negative on the rcar_gen3 (Dien Pham)
- Fix wrong frequency converted from power for the cpufreq cooling
device (Finley Xiao)
- Fix compilation warnings by making functions static in the tsens
driver (Amit Kucheria)
- Fix return value of sprd_thm_probe for the Spreadtrum driver
(Tiezhu Yang)
- Fix bank number settings on the Mediatek mt8183 (Michael Kao)
- Fix missing of_node_put() at probe time i.MX (Anson Huang)
* tag 'thermal-v5.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/thermal/linux:
thermal/drivers/rcar_gen3: Fix undefined temperature if negative
thermal/drivers/cpufreq_cooling: Fix wrong frequency converted from power
thermal/drivers/tsens: Fix compilation warnings by making functions static
thermal/drivers/sprd: Fix return value of sprd_thm_probe()
thermal/drivers/mediatek: Fix bank number settings on mt8183
thermal/drivers: imx: Fix missing of_node_put() at probe time
Linus Torvalds [Mon, 29 Jun 2020 17:06:26 +0000 (10:06 -0700)]
Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
Pull crypto fixes from Herbert Xu:
"This fixes two race conditions, one in padata and one in af_alg"
* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
padata: upgrade smp_mb__after_atomic to smp_mb in padata_do_serial
crypto: af_alg - fix use-after-free in af_alg_accept() due to bh_lock_sock()
Mel Gorman [Mon, 29 Jun 2020 14:41:45 +0000 (15:41 +0100)]
Revert "fs: Do not check if there is a fsnotify watcher on pseudo inodes"
This reverts commit 4c43a1f12194 ("fs: Do not check if there is a
fsnotify watcher on pseudo inodes"). The commit intended to eliminate
fsnotify-related overhead for pseudo inodes but it is broken in
concept. inotify can receive events of pipe files under /proc/X/fd and
chromium relies on close and open events for sandboxing. Maxim Levitsky
reported the following
Chromium starts as a white rectangle, shows few white rectangles that
resemble its notifications and then crashes.
The stdout output from chromium:
[mlevitsk@starship ~]$chromium-freeworld
mesa: for the --simplifycfg-sink-common option: may only occur zero or one times!
mesa: for the --global-isel-abort option: may only occur zero or one times!
[3379:3379:0628/135151.440930:ERROR:browser_switcher_service.cc(238)] XXX Init()
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0072
Received signal 11 SEGV_MAPERR 0000004a9048
Crashes are not universal but even if chromium does not crash, it certainly
does not work properly. While filtering just modify and access might be
safe, the benefit is not worth the risk hence the revert.
Reported-by: Maxim Levitsky <mlevitsk@redhat.com> Fixes: 4c43a1f12194 ("fs: Do not check if there is a fsnotify watcher on pseudo inodes") Signed-off-by: Mel Gorman <mgorman@techsingularity.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Mike Rapoport [Wed, 17 Jun 2020 06:53:40 +0000 (09:53 +0300)]
m68k: nommu: register start of the memory with memblock
The m68k nommu setup code didn't register the beginning of the physical
memory with memblock because it was anyway occupied by the kernel. However,
commit 642b6dc1e1a0 ("mm: free_area_init: use maximal zone PFNs rather than
zone sizes") changed zones initialization to use memblock.memory to detect
the zone extents and this caused inconsistency between zone PFNs and the
actual PFNs:
Adjust the memory registration with memblock to include the beginning of
the physical memory and make sure that the area occupied by the kernel is
marked as reserved.
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Joseph Salisbury [Fri, 26 Jun 2020 22:28:17 +0000 (15:28 -0700)]
Drivers: hv: Change flag to write log level in panic msg to false
When the kernel panics, one page of kmsg data may be collected and sent to
Hyper-V to aid in diagnosing the failure. The collected kmsg data typically
contains 50 to 100 lines, each of which has a log level prefix that isn't
very useful from a diagnostic standpoint. So tell kmsg_dump_get_buffer()
to not include the log level, enabling more information that *is* useful to
fit in the page.
Requesting in stable kernels, since many kernels running in production are
stable releases.
Dien Pham [Thu, 25 Jun 2020 11:38:19 +0000 (20:38 +0900)]
thermal/drivers/rcar_gen3: Fix undefined temperature if negative
As description for DIV_ROUND_CLOSEST in file include/linux/kernel.h.
"Result is undefined for negative divisors if the dividend variable
type is unsigned and for negative dividends if the divisor variable
type is unsigned."
In current code, the FIXPT_DIV uses DIV_ROUND_CLOSEST but has not
checked sign of divisor before using. It makes undefined temperature
value in case the value is negative.
This patch fixes to satisfy DIV_ROUND_CLOSEST description
and fix bug too. Note that the variable name "reg" is not good
because it should be the same type as rcar_gen3_thermal_read().
However, it's better to rename the "reg" in a further patch as
cleanup.
Signed-off-by: Van Do <van.do.xw@renesas.com> Signed-off-by: Dien Pham <dien.pham.ry@renesas.com>
[shimoda: minor fixes, add Fixes tag] Fixes: e03ba1a5d111 ("thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver") Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Niklas Soderlund <niklas.soderlund+renesas@ragnatech.se> Tested-by: Niklas Soderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/1593085099-2057-1-git-send-email-yoshihiro.shimoda.uh@renesas.com
projects / kernel.git / log