__bpf_skb_max_len(skb) is used from:
bpf_skb_adjust_room
__bpf_skb_change_tail
__bpf_skb_change_head
but in the case of forwarding we're likely calling these functions
during receive processing on ingress and bpf_redirect()'ing at
a later point in time to egress on another interface, thus these
mtu checks are for the wrong device (input instead of output).
This is particularly problematic if we're receiving on an L3 1500 mtu
cellular interface, trying to add an L2 header and forwarding to
an L3 mtu 1500 mtu wifi/ethernet device (which is thus L2 1514).
The mtu check prevents us from adding the 14 byte ethernet header prior
to forwarding the packet.
After the packet has already been redirected, we'd need to add
an additional 2nd ebpf program on the target device's egress tc hook,
but then we'd also see non-redirected traffic and have no easy
way to tell apart normal egress with ethernet header packets
from forwarded ethernet headerless packets.
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Link: https://patchwork.ozlabs.org/project/netdev/patch/20200507023606.111650-1-zenczykowski@gmail.com/
But note that a more thorough solution will be pursued.
Bug: 149816401
Change-Id: If55a144d7822e23bce85f65897bca7de4e0f9b24
With the removal of sdcardfs, a number of vfs functions got removed as
well (crazy "2" naming), so update the abi definitions so that all is
good with the build system.
Leaf changes summary: 3 artifacts changed
Changed leaf types summary: 2 leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 1 Changed, 0 Added variable
1 Changed variable:
[C] 'const inode_operations simple_dir_inode_operations' was changed at libfs.c:239:1:
type of variable changed:
'struct dentry_operations at dcache.h:139:1' changed:
type size hasn't changed
1 data member deletion:
'void (const path*, path*)* dentry_operations::d_canonical_path', at offset 832 (in bits) at dcache.h:154:1
2917 impacted interfaces:
'struct inode_operations at fs.h:1924:1' changed:
type size hasn't changed
2 data member deletions:
'int (vfsmount*, inode*, int)* inode_operations::permission2', at offset 192 (in bits) at fs.h:1928:1
'int (vfsmount*, dentry*, iattr*)* inode_operations::setattr2', at offset 960 (in bits) at fs.h:1943:1
2917 impacted interfaces:
Bug: 157700134
Cc: Daniel Rosenberg <drosen@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5d3eea60252118212fd50353db3007cefc66715e
This reverts commit c0dbfed5ff as it is
not needed now that sdcardfs is gone.
Bug: 157700134
Cc: Daniel Rosenberg <drosen@google.com>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Alistair Strachan <astrachan@google.com>
Cc: Yongqin Liu <yongqin.liu@linaro.org>
Cc: Daniel Rosenberg <drosen@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ia738ff19487e2e3e129d2ef17ef1f28f777bf306
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
These symbols are not needed to be whitelisted anymore now that sdcardfs
is removed from the system.
Bug: 157700134
Cc: Daniel Rosenberg <drosen@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ib714633fe60846970ef20989745de5d011fef7fb
This reverts commit 044366659c as it is no
longer needed that sdcardfs is removed.
Bug: 157700134
Cc: Daniel Rosenberg <drosen@google.com>
Cc: Yongqin Liu <yongqin.liu@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I721aa74cca4afccd7628ef3728d5fbfc43050e9e
This reverts commit 4fd07efd90 as it is no
longer needed because sdcardfs is gone.
Bug: 157700134
Cc: Daniel Rosenberg <drosen@google.com>
Cc: Amit Pundir <amit.pundir@linaro.org>
Cc: Alistair Strachan <astrachan@google.com>
Cc: Yongqin Liu <yongqin.liu@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ic48212d19abc161e6f77b1bd659878e20a830448
This reverts commit b05bef535d as there is
no need for it as sdcardfs is now gone.
Bug: 157700134
Cc: Daniel Rosenberg <drosen@google.com>
Cc: Alistair Strachan <astrachan@google.com>
Cc: Yongqin Liu <yongqin.liu@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I7c9e868d641d6e3e07d36a9a2cbe97a9b01f0ef4
This reverts commit 4d53a0405c as sdcardfs
is no longer in the tree.
Bug: 157700134
Cc: Alistair Strachan <astrachan@google.com>
Cc: Yongqin Liu <yongqin.liu@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ifed0002912a8fe53ede93b7b47c6efdf9d5d8460
It's no longer needed on Android devices, so remove sdcardfs core code,
and a bunch of exports that were only added so that it could be built as
a module.
Bug: 157700134
Cc: Daniel Rosenberg <drosen@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I2b5c1103a79c07dcbd7273b42ac4b7ddf4615d38
When SYNC_STATE_ONLY support was added in commit 05ef983e0d65 ("driver
core: Add device link support for SYNC_STATE_ONLY flag"),
SYNC_STATE_ONLY links were treated similar to STATELESS links in terms
of not blocking consumer probe if the supplier hasn't probed yet.
That caused a SYNC_STATE_ONLY device link's status to not get updated.
Since SYNC_STATE_ONLY device link is no longer useful once the
consumer probes, commit 21c27f06587d ("driver core: Fix
SYNC_STATE_ONLY device link implementation") addresses the status
update issue by deleting the SYNC_STATE_ONLY device link instead of
complicating the status update code.
However, there are still some cases where we need to update the status
of a SYNC_STATE_ONLY device link. This is because a SYNC_STATE_ONLY
device link can later get converted into a normal MANAGED device link
when a normal MANAGED device link is created between a supplier and
consumer that already have a SYNC_STATE_ONLY device link between them.
If a SYNC_STATE_ONLY device link's status isn't maintained correctly
till it's converted to a normal MANAGED device link, then the normal
MANAGED device link will end up with a wrong link status. This can cause
a warning stack trace[1] when the consumer device probes successfully.
This commit fixes the SYNC_STATE_ONLY device link status update issue
where it wouldn't transition correctly from DL_STATE_DORMANT or
DL_STATE_AVAILABLE to DL_STATE_CONSUMER_PROBE. It also resets the status
back to DL_STATE_DORMANT or DL_STATE_AVAILABLE if the consumer probe
fails.
[1] - https://lore.kernel.org/lkml/20200522204120.3b3c9ed6@apollo/
Fixes: 05ef983e0d65 ("driver core: Add device link support for SYNC_STATE_ONLY flag")
Fixes: 21c27f06587d ("driver core: Fix SYNC_STATE_ONLY device link implementation")
Reported-by: Michael Walle <michael@walle.cc>
Tested-by: Michael Walle <michael@walle.cc>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Reviewed-by: Rafael J. Wysocki <rrafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/20200526220928.49939-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 8c3e315d4296421cd26b3300ee0ac117f0877f20
https: //git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-next)
Bug: 157103558
Signed-off-by: Saravana Kannan <saravanak@google.com>
Change-Id: I2885b65d2bbea5b55ac438d933b31b679817bd06
Commit 21c27f06587d ("driver core: Fix SYNC_STATE_ONLY device link
implementation") didn't completely fix STATELESS + SYNC_STATE_ONLY
handling.
What looks like an optimization in that commit is actually a bug that
causes an if condition to always take the else path. This prevents
reordering of devices in the dpm_list when a DL_FLAG_STATELESS device
link is create on top of an existing DL_FLAG_SYNC_STATE_ONLY device
link.
Fixes: 21c27f06587d ("driver core: Fix SYNC_STATE_ONLY device link implementation")
Signed-off-by: Saravana Kannan <saravanak@google.com>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/20200520043626.181820-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 44e960490ddf868fc9135151c4a658936e771dc2)
Bug: 157103558
Signed-off-by: Saravana Kannan <saravanak@google.com>
Change-Id: I6cd908eb4b29b1058018bfb906cb508fb3ca710f
When SYNC_STATE_ONLY support was added in commit 05ef983e0d65 ("driver
core: Add device link support for SYNC_STATE_ONLY flag"),
device_link_add() incorrectly skipped adding the new SYNC_STATE_ONLY
device link to the supplier's and consumer's "device link" list.
This causes multiple issues:
- The device link is lost forever from driver core if the caller
didn't keep track of it (caller typically isn't expected to). This is
a memory leak.
- The device link is also never visible to any other code path after
device_link_add() returns.
If we fix the "device link" list handling, that exposes a bunch of
issues.
1. The device link "status" state management code rightfully doesn't
handle the case where a DL_FLAG_MANAGED device link exists between a
supplier and consumer, but the consumer manages to probe successfully
before the supplier. The addition of DL_FLAG_SYNC_STATE_ONLY links break
this assumption. This causes device_links_driver_bound() to throw a
warning when this happens.
Since DL_FLAG_SYNC_STATE_ONLY device links are mainly used for creating
proxy device links for child device dependencies and aren't useful once
the consumer device probes successfully, this patch just deletes
DL_FLAG_SYNC_STATE_ONLY device links once its consumer device probes.
This way, we avoid the warning, free up some memory and avoid
complicating the device links "status" state management code.
2. Creating a DL_FLAG_STATELESS device link between two devices that
already have a DL_FLAG_SYNC_STATE_ONLY device link will result in the
DL_FLAG_STATELESS flag not getting set correctly. This patch also fixes
this.
Lastly, this patch also fixes minor whitespace issues.
Cc: stable@vger.kernel.org
Fixes: 05ef983e0d65 ("driver core: Add device link support for SYNC_STATE_ONLY flag")
Signed-off-by: Saravana Kannan <saravanak@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/20200519063000.128819-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 21c27f06587d2c18150d27ca2382a509ec55c482)
Bug: 157103558
Signed-off-by: Saravana Kannan <saravanak@google.com>
Change-Id: Icb091de185c7efbb7db0ec86267675ac0472f379
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl7Oi20ACgkQONu9yGCS
aT4ipBAA1Kqh2mLEcDBISubrU4CuOl/iHmkCXyF1FeF9+vJKz25whbfYO/FNYweP
2HYxGyuqLTQ0OnsfrXeEoImlxdAcWp3TjAFPgJdonLBvnVDmvlPe6Pzk1NRPhvce
zU/Y1leE+LoQ7xDfICPJ9BwuwwYTRzRqMQHmIuVlsHLSiN+rextPj6vkzD+7h4ux
i9VKoDvzmWuLrHmc9RYNoGxuZ5tGogBaCxI8tnzHGcm21bNVvsKZiANQ2J+6G2bJ
sJwqq5tH2gZ6cJxmJ1tVyMbXLIJanNKLeBC5sDQN4rss9pU4gtyEARqVG+9RlglQ
FeSlBuoaISJYYejo6aSH7nw81bTQrXexd0sH94qYqnqPlZo+OXN8vxHTaIapYEfd
fjqyEblZXqpnMNVQcZOxbrYaefuIrZ9Q8pWUFTwVj34P8RNJLBIvg5gy2dlRvHbC
PGLJewOXySZaXVpD5gFU349L32d4QPw9MmMU5php+LOl4idN8RlVY0pOaUuO0idH
ewO+6vijLgHq/5HBO6BBToRlNUvLauoUeAaQwoHfPiuuYnGGFCZ9GEjPRsHnCBok
IAKQ2Uj+IqlMy7gKVtG1ryekil7TVktrZQ1JBokRLWQPZiED84r7P1lQqPaH/4f4
GFFRhx3tekJs4LMMUEaUR019Q9ZcQMWkikT1/HpVOYUjQd55pc4=
=jmiq
-----END PGP SIGNATURE-----
Merge 5.4.43 into android-5.4-stable
Changes in 5.4.43
i2c: dev: Fix the race between the release of i2c_dev and cdev
KVM: SVM: Fix potential memory leak in svm_cpu_init()
ima: Set file->f_mode instead of file->f_flags in ima_calc_file_hash()
evm: Check also if *tfm is an error pointer in init_desc()
ima: Fix return value of ima_write_policy()
ubifs: fix wrong use of crypto_shash_descsize()
ACPI: EC: PM: Avoid flushing EC work when EC GPE is inactive
mtd: spinand: Propagate ECC information to the MTD structure
fix multiplication overflow in copy_fdtable()
ubifs: remove broken lazytime support
i2c: fix missing pm_runtime_put_sync in i2c_device_probe
iommu/amd: Fix over-read of ACPI UID from IVRS table
evm: Fix a small race in init_desc()
i2c: mux: demux-pinctrl: Fix an error handling path in 'i2c_demux_pinctrl_probe()'
ubi: Fix seq_file usage in detailed_erase_block_info debugfs file
afs: Don't unlock fetched data pages until the op completes successfully
mtd: Fix mtd not registered due to nvmem name collision
kbuild: avoid concurrency issue in parallel building dtbs and dtbs_check
net: drop_monitor: use IS_REACHABLE() to guard net_dm_hw_report()
gcc-common.h: Update for GCC 10
HID: multitouch: add eGalaxTouch P80H84 support
HID: alps: Add AUI1657 device ID
HID: alps: ALPS_1657 is too specific; use U1_UNICORN_LEGACY instead
scsi: qla2xxx: Fix hang when issuing nvme disconnect-all in NPIV
scsi: qla2xxx: Delete all sessions before unregister local nvme port
configfs: fix config_item refcnt leak in configfs_rmdir()
vhost/vsock: fix packet delivery order to monitoring devices
aquantia: Fix the media type of AQC100 ethernet controller in the driver
component: Silence bind error on -EPROBE_DEFER
net/ena: Fix build warning in ena_xdp_set()
scsi: ibmvscsi: Fix WARN_ON during event pool release
HID: i2c-hid: reset Synaptics SYNA2393 on resume
x86/mm/cpa: Flush direct map alias during cpa
ibmvnic: Skip fatal error reset after passive init
ftrace/selftest: make unresolved cases cause failure if --fail-unresolved set
x86/apic: Move TSC deadline timer debug printk
gtp: set NLM_F_MULTI flag in gtp_genl_dump_pdp()
HID: quirks: Add HID_QUIRK_NO_INIT_REPORTS quirk for Dell K12A keyboard-dock
ceph: fix double unlock in handle_cap_export()
stmmac: fix pointer check after utilization in stmmac_interrupt
USB: core: Fix misleading driver bug report
platform/x86: asus-nb-wmi: Do not load on Asus T100TA and T200TA
iommu/amd: Call domain_flush_complete() in update_domain()
drm/amd/display: Prevent dpcd reads with passive dongles
KVM: selftests: Fix build for evmcs.h
ARM: futex: Address build warning
scripts/gdb: repair rb_first() and rb_last()
ALSA: hda - constify and cleanup static NodeID tables
ALSA: hda: patch_realtek: fix empty macro usage in if block
ALSA: hda: Manage concurrent reg access more properly
ALSA: hda/realtek - Add supported new mute Led for HP
ALSA: hda/realtek - Add HP new mute led supported for ALC236
ALSA: hda/realtek: Add quirk for Samsung Notebook
ALSA: hda/realtek - Enable headset mic of ASUS GL503VM with ALC295
ALSA: hda/realtek - Enable headset mic of ASUS UX550GE with ALC295
ALSA: hda/realtek: Enable headset mic of ASUS UX581LV with ALC295
KVM: x86: Fix pkru save/restore when guest CR4.PKE=0, move it to x86.c
ALSA: iec1712: Initialize STDSP24 properly when using the model=staudio option
ALSA: pcm: fix incorrect hw_base increase
ALSA: hda/realtek - Fix silent output on Gigabyte X570 Aorus Xtreme
ALSA: hda/realtek - Add more fixup entries for Clevo machines
scsi: qla2xxx: Do not log message when reading port speed via sysfs
scsi: target: Put lun_ref at end of tmr processing
arm64: Fix PTRACE_SYSEMU semantics
drm/etnaviv: fix perfmon domain interation
apparmor: Fix use-after-free in aa_audit_rule_init
apparmor: fix potential label refcnt leak in aa_change_profile
apparmor: Fix aa_label refcnt leak in policy_update
dmaengine: tegra210-adma: Fix an error handling path in 'tegra_adma_probe()'
drm/etnaviv: Fix a leak in submit_pin_objects()
dmaengine: dmatest: Restore default for channel
dmaengine: owl: Use correct lock in owl_dma_get_pchan()
vsprintf: don't obfuscate NULL and error pointers
drm/i915/gvt: Init DPLL/DDI vreg for virtual display instead of inheritance.
drm/i915: Propagate error from completed fences
powerpc: Remove STRICT_KERNEL_RWX incompatibility with RELOCATABLE
powerpc/64s: Disable STRICT_KERNEL_RWX
bpf: Avoid setting bpf insns pages read-only when prog is jited
kbuild: Remove debug info from kallsyms linking
Revert "gfs2: Don't demote a glock until its revokes are written"
media: fdp1: Fix R-Car M3-N naming in debug message
staging: iio: ad2s1210: Fix SPI reading
staging: kpc2000: fix error return code in kp2000_pcie_probe()
staging: greybus: Fix uninitialized scalar variable
iio: sca3000: Remove an erroneous 'get_device()'
iio: dac: vf610: Fix an error handling path in 'vf610_dac_probe()'
iio: adc: ti-ads8344: Fix channel selection
misc: rtsx: Add short delay after exit from ASPM
tty: serial: add missing spin_lock_init for SiFive serial console
mei: release me_cl object reference
ipack: tpci200: fix error return code in tpci200_register()
s390/pci: Fix s390_mmio_read/write with MIO
s390/kaslr: add support for R_390_JMP_SLOT relocation type
device-dax: don't leak kernel memory to user space after unloading kmem
rapidio: fix an error in get_user_pages_fast() error handling
kasan: disable branch tracing for core runtime
rxrpc: Fix the excessive initial retransmission timeout
rxrpc: Fix a memory leak in rxkad_verify_response()
s390/kexec_file: fix initrd location for kdump kernel
flow_dissector: Drop BPF flow dissector prog ref on netns cleanup
x86/unwind/orc: Fix unwind_get_return_address_ptr() for inactive tasks
iio: adc: stm32-adc: Use dma_request_chan() instead dma_request_slave_channel()
iio: adc: stm32-adc: fix device used to request dma
iio: adc: stm32-dfsdm: Use dma_request_chan() instead dma_request_slave_channel()
iio: adc: stm32-dfsdm: fix device used to request dma
rxrpc: Trace discarded ACKs
rxrpc: Fix ack discard
tpm: check event log version before reading final events
sched/fair: Reorder enqueue/dequeue_task_fair path
sched/fair: Fix reordering of enqueue/dequeue_task_fair()
sched/fair: Fix enqueue_task_fair() warning some more
Linux 5.4.43
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I1582df67569f34c4455c482ed0eaf10fc1a34e03
This reverts commit ab185e45f637ba0b0239268f1130890c8837981d.
This change used the PageChecked flag to mark the Merkle tree as
checked. However, f2fs uses this internally. This caused file system
hangs on devices after installs.
Test: incfs_test passes, installs no longer hang
Bug: 157589629
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I980a700d65eb4f4a77434715d61dda4b8e80658c
* aosp/upstream-f2fs-stable-linux-5.4.y:
f2fs: flush dirty meta pages when flushing them
f2fs: fix checkpoint=disable:%u%%
f2fs: rework filename handling
f2fs: split f2fs_d_compare() from f2fs_match_name()
f2fs: don't leak filename in f2fs_try_convert_inline_dir()
f2fs: fix missing check for f2fs_unlock_op
f2fs: fix quota_sync failure due to f2fs_lock_op
f2fs: support read iostat
f2fs: Fix the accounting of dcc->undiscard_blks
f2fs: fix to handle error path of f2fs_ra_meta_pages()
f2fs: report the discard cmd errors properly
f2fs: fix long latency due to discard during umount
f2fs: add tracepoint for f2fs iostat
f2fs: introduce sysfs/data_io_flag to attach REQ_META/FUA
ubifs: wire up FS_IOC_GET_ENCRYPTION_NONCE
f2fs: wire up FS_IOC_GET_ENCRYPTION_NONCE
ext4: wire up FS_IOC_GET_ENCRYPTION_NONCE
fscrypt: add FS_IOC_GET_ENCRYPTION_NONCE ioctl
f2fs: keep inline_data when compression conversion
f2fs: fix to disable compression on directory
f2fs: add missing CONFIG_F2FS_FS_COMPRESSION
f2fs: switch discard_policy.timeout to bool type
f2fs: fix to verify tpage before releasing in f2fs_free_dic()
f2fs: show compression in statx
f2fs: clean up dic->tpages assignment
f2fs: compress: support zstd compress algorithm
f2fs: compress: add .{init,destroy}_decompress_ctx callback
f2fs: compress: fix to call missing destroy_compress_ctx()
f2fs: change default compression algorithm
f2fs: clean up {cic,dic}.ref handling
f2fs: fix to use f2fs_readpage_limit() in f2fs_read_multi_pages()
f2fs: xattr.h: Make stub helpers inline
f2fs: fix to avoid double unlock
f2fs: fix potential .flags overflow on 32bit architecture
f2fs: fix NULL pointer dereference in f2fs_verity_work()
f2fs: fix to clear PG_error if fsverity failed
f2fs: don't call fscrypt_get_encryption_info() explicitly in f2fs_tmpfile()
f2fs: don't trigger data flush in foreground operation
f2fs: fix NULL pointer dereference in f2fs_write_begin()
f2fs: clean up f2fs_may_encrypt()
f2fs: fix to avoid potential deadlock
f2fs: don't change inode status under page lock
f2fs: fix potential deadlock on compressed quota file
f2fs: delete DIO read lock
f2fs: don't mark compressed inode dirty during f2fs_iget()
f2fs: fix to account compressed blocks in f2fs_compressed_blocks()
f2fs: xattr.h: Replace zero-length array with flexible-array member
f2fs: fix to update f2fs_super_block fields under sb_lock
f2fs: Add a new CP flag to help fsck fix resize SPO issues
f2fs: Fix mount failure due to SPO after a successful online resize FS
f2fs: use kmem_cache pool during inline xattr lookups
f2fs: skip migration only when BG_GC is called
f2fs: fix to show tracepoint correctly
f2fs: avoid __GFP_NOFAIL in f2fs_bio_alloc
f2fs: introduce F2FS_IOC_GET_COMPRESS_BLOCKS
f2fs: fix to avoid triggering IO in write path
f2fs: add prefix for f2fs slab cache name
f2fs: introduce DEFAULT_IO_TIMEOUT
f2fs: skip GC when section is full
f2fs: add migration count iff migration happens
f2fs: clean up bggc mount option
f2fs: clean up lfs/adaptive mount option
f2fs: fix to show norecovery mount option
f2fs: clean up parameter of macro XATTR_SIZE()
f2fs: clean up codes with {f2fs_,}data_blkaddr()
f2fs: show mounted time
f2fs: Use scnprintf() for avoiding potential buffer overflow
f2fs: allow to clear F2FS_COMPR_FL flag
f2fs: fix to check dirty pages during compressed inode conversion
f2fs: fix to account compressed inode correctly
f2fs: fix wrong check on F2FS_IOC_FSSETXATTR
f2fs: fix to avoid use-after-free in f2fs_write_multi_pages()
f2fs: fix to avoid using uninitialized variable
f2fs: fix inconsistent comments
f2fs: remove i_sem lock coverage in f2fs_setxattr()
f2fs: cover last_disk_size update with spinlock
f2fs: fix to check i_compr_blocks correctly
f2fs: fix to avoid potential deadlock
f2fs: add missing function name in kernel message
f2fs: recycle unused compress_data.chksum feild
f2fs: fix to avoid NULL pointer dereference
f2fs: fix leaking uninitialized memory in compressed clusters
f2fs: fix the panic in do_checkpoint()
f2fs: fix to wait all node page writeback
mm/swapfile.c: move inode_lock out of claim_swapfile
fscrypt: don't evict dirty inodes after removing key
Conflicts:
Documentation/ABI/testing/sysfs-fs-f2fs
fs/f2fs/checkpoint.c
fs/f2fs/compress.c
fs/f2fs/data.c
fs/f2fs/dir.c
fs/f2fs/f2fs.h
fs/f2fs/hash.c
fs/f2fs/inline.c
fs/f2fs/namei.c
Change-Id: Ib5ceb0f2f076d6c215d4c0c6262f3c1d41cde7c8
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Checked the variable in f2fs-stable, I think there was a mistake to remove this
line. Let's remove this to sync with -stable.
Bug: 155529912
Fixes: 09be9006b383 ("Merge 5.4.36 into android-5.4")
Change-Id: I27af455f0c59924d122a782669bac741bd9a82ea
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
[ Upstream commit b34cb07dde7c2346dec73d053ce926aeaa087303 ]
sched/fair: Fix enqueue_task_fair warning some more
The recent patch, fe61468b2cb (sched/fair: Fix enqueue_task_fair warning)
did not fully resolve the issues with the rq->tmp_alone_branch !=
&rq->leaf_cfs_rq_list warning in enqueue_task_fair. There is a case where
the first for_each_sched_entity loop exits due to on_rq, having incompletely
updated the list. In this case the second for_each_sched_entity loop can
further modify se. The later code to fix up the list management fails to do
what is needed because se does not point to the sched_entity which broke out
of the first loop. The list is not fixed up because the throttled parent was
already added back to the list by a task enqueue in a parallel child hierarchy.
Address this by calling list_add_leaf_cfs_rq if there are throttled parents
while doing the second for_each_sched_entity loop.
Fixes: fe61468b2cb ("sched/fair: Fix enqueue_task_fair warning")
Suggested-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Phil Auld <pauld@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
Link: https://lkml.kernel.org/r/20200512135222.GC2201@lorien.usersys.redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 5ab297bab984310267734dfbcc8104566658ebef ]
Even when a cgroup is throttled, the group se of a child cgroup can still
be enqueued and its gse->on_rq stays true. When a task is enqueued on such
child, we still have to update the load_avg and increase
h_nr_running of the throttled cfs. Nevertheless, the 1st
for_each_sched_entity() loop is skipped because of gse->on_rq == true and the
2nd loop because the cfs is throttled whereas we have to update both
load_avg with the old h_nr_running and increase h_nr_running in such case.
The same sequence can happen during dequeue when se moves to parent before
breaking in the 1st loop.
Note that the update of load_avg will effectively happen only once in order
to sync up to the throttled time. Next call for updating load_avg will stop
early because the clock stays unchanged.
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Fixes: 6d4d22468dae ("sched/fair: Reorder enqueue/dequeue_task_fair path")
Link: https://lkml.kernel.org/r/20200306084208.12583-1-vincent.guittot@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 6d4d22468dae3d8757af9f8b81b848a76ef4409d ]
The walk through the cgroup hierarchy during the enqueue/dequeue of a task
is split in 2 distinct parts for throttled cfs_rq without any added value
but making code less readable.
Change the code ordering such that everything related to a cfs_rq
(throttled or not) will be done in the same loop.
In addition, the same steps ordering is used when updating a cfs_rq:
- update_load_avg
- update_cfs_group
- update *h_nr_running
This reordering enables the use of h_nr_running in PELT algorithm.
No functional and performance changes are expected and have been noticed
during tests.
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: "Dietmar Eggemann <dietmar.eggemann@arm.com>"
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Phil Auld <pauld@redhat.com>
Cc: Hillf Danton <hdanton@sina.com>
Link: https://lore.kernel.org/r/20200224095223.13361-5-mgorman@techsingularity.net
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit b4f1874c62168159fdb419ced4afc77c1b51c475 ]
This fixes the boot issues since 5.3 on several Dell models when the TPM
is enabled. Depending on the exact grub binary, booting the kernel would
freeze early, or just report an error parsing the final events log.
We get an event log in the SHA-1 format, which doesn't have a
tcg_efi_specid_event_head in the first event, and there is a final events
table which doesn't match the crypto agile format.
__calc_tpm2_event_size reads bad "count" and "efispecid->num_algs", and
either fails, or loops long enough for the machine to be appear frozen.
So we now only parse the final events table, which is per the spec always
supposed to be in the crypto agile format, when we got a event log in this
format.
Fixes: c46f340569 ("tpm: Reserve the TPM final events table")
Fixes: 166a2809d6 ("tpm: Don't duplicate events from the final event log in the TCG2 log")
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1779611
Signed-off-by: Loïc Yhuel <loic.yhuel@gmail.com>
Link: https://lore.kernel.org/r/20200512040113.277768-1-loic.yhuel@gmail.com
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: Matthew Garrett <mjg59@google.com>
[ardb: warn when final events table is missing or in the wrong format]
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 441fdee1eaf050ef0040bde0d7af075c1c6a6d8b ]
The Rx protocol has a "previousPacket" field in it that is not handled in
the same way by all protocol implementations. Sometimes it contains the
serial number of the last DATA packet received, sometimes the sequence
number of the last DATA packet received and sometimes the highest sequence
number so far received.
AF_RXRPC is using this to weed out ACKs that are out of date (it's possible
for ACK packets to get reordered on the wire), but this does not work with
OpenAFS which will just stick the sequence number of the last packet seen
into previousPacket.
The issue being seen is that big AFS FS.StoreData RPC (eg. of ~256MiB) are
timing out when partly sent. A trace was captured, with an additional
tracepoint to show ACKs being discarded in rxrpc_input_ack(). Here's an
excerpt showing the problem.
52873.203230: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 0002449c q=00024499 fl=09
A DATA packet with sequence number 00024499 has been transmitted (the "q="
field).
...
52873.243296: rxrpc_rx_ack: c=000004ae 00012a2b DLY r=00024499 f=00024497 p=00024496 n=0
52873.243376: rxrpc_rx_ack: c=000004ae 00012a2c IDL r=0002449b f=00024499 p=00024498 n=0
52873.243383: rxrpc_rx_ack: c=000004ae 00012a2d OOS r=0002449d f=00024499 p=0002449a n=2
The Out-Of-Sequence ACK indicates that the server didn't see DATA sequence
number 00024499, but did see seq 0002449a (previousPacket, shown as "p=",
skipped the number, but firstPacket, "f=", which shows the bottom of the
window is set at that point).
52873.252663: rxrpc_retransmit: c=000004ae q=24499 a=02 xp=14581537
52873.252664: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 000244bc q=00024499 fl=0b *RETRANS*
The packet has been retransmitted. Retransmission recurs until the peer
says it got the packet.
52873.271013: rxrpc_rx_ack: c=000004ae 00012a31 OOS r=000244a1 f=00024499 p=0002449e n=6
More OOS ACKs indicate that the other packets that are already in the
transmission pipeline are being received. The specific-ACK list is up to 6
ACKs and NAKs.
...
52873.284792: rxrpc_rx_ack: c=000004ae 00012a49 OOS r=000244b9 f=00024499 p=000244b6 n=30
52873.284802: rxrpc_retransmit: c=000004ae q=24499 a=0a xp=63505500
52873.284804: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 000244c2 q=00024499 fl=0b *RETRANS*
52873.287468: rxrpc_rx_ack: c=000004ae 00012a4a OOS r=000244ba f=00024499 p=000244b7 n=31
52873.287478: rxrpc_rx_ack: c=000004ae 00012a4b OOS r=000244bb f=00024499 p=000244b8 n=32
At this point, the server's receive window is full (n=32) with presumably 1
NAK'd packet and 31 ACK'd packets. We can't transmit any more packets.
52873.287488: rxrpc_retransmit: c=000004ae q=24499 a=0a xp=61327980
52873.287489: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 000244c3 q=00024499 fl=0b *RETRANS*
52873.293850: rxrpc_rx_ack: c=000004ae 00012a4c DLY r=000244bc f=000244a0 p=00024499 n=25
And now we've received an ACK indicating that a DATA retransmission was
received. 7 packets have been processed (the occupied part of the window
moved, as indicated by f= and n=).
52873.293853: rxrpc_rx_discard_ack: c=000004ae r=00012a4c 000244a0<00024499 00024499<000244b8
However, the DLY ACK gets discarded because its previousPacket has gone
backwards (from p=000244b8, in the ACK at 52873.287478 to p=00024499 in the
ACK at 52873.293850).
We then end up in a continuous cycle of retransmit/discard. kafs fails to
update its window because it's discarding the ACKs and can't transmit an
extra packet that would clear the issue because the window is full.
OpenAFS doesn't change the previousPacket value in the ACKs because no new
DATA packets are received with a different previousPacket number.
Fix this by altering the discard check to only discard an ACK based on
previousPacket if there was no advance in the firstPacket. This allows us
to transmit a new packet which will cause previousPacket to advance in the
next ACK.
The check, however, needs to allow for the possibility that previousPacket
may actually have had the serial number placed in it instead - in which
case it will go outside the window and we should ignore it.
Fixes: 1a2391c30c ("rxrpc: Fix detection of out of order acks")
Reported-by: Dave Botsch <botsch@cnf.cornell.edu>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit d1f129470e6cb79b8b97fecd12689f6eb49e27fe ]
Add a tracepoint to track received ACKs that are discarded due to being
outside of the Tx window.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit b455d06e6fb3c035711e8aab1ca18082ccb15d87 ]
DMA channel request should use device struct from platform device struct.
Currently it's using iio device struct. But at this stage when probing,
device struct isn't yet registered (e.g. device_register is done in
iio_device_register). Since commit 71723a96b8b1 ("dmaengine: Create
symlinks between DMA channels and slaves"), a warning message is printed
as the links in sysfs can't be created, due to device isn't yet registered:
- Cannot create DMA slave symlink
- Cannot create DMA dma:rx symlink
Fix this by using device struct from platform device to request dma chan.
Fixes: eca949800d ("IIO: ADC: add stm32 DFSDM support for PDM microphone")
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit a9ab624edd9186fbad734cfe5d606a6da3ca34db ]
dma_request_slave_channel() is a wrapper on top of dma_request_chan()
eating up the error code.
By using dma_request_chan() directly the driver can support deferred
probing against DMA.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Olivier Moysan <olivier.moysan@st.com>
Acked-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 52cd91c27f3908b88e8b25aed4a4d20660abcc45 ]
DMA channel request should use device struct from platform device struct.
Currently it's using iio device struct. But at this stage when probing,
device struct isn't yet registered (e.g. device_register is done in
iio_device_register). Since commit 71723a96b8b1 ("dmaengine: Create
symlinks between DMA channels and slaves"), a warning message is printed
as the links in sysfs can't be created, due to device isn't yet registered:
- Cannot create DMA slave symlink
- Cannot create DMA dma:rx symlink
Fix this by using device struct from platform device to request dma chan.
Fixes: 2763ea0585 ("iio: adc: stm32: add optional dma support")
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 735404b846dffcb320264f62b76e6f70012214dd ]
dma_request_slave_channel() is a wrapper on top of dma_request_chan()
eating up the error code.
By using dma_request_chan() directly the driver can support deferred
probing against DMA.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 187b96db5ca79423618dfa29a05c438c34f9e1f0 upstream.
Normally, show_trace_log_lvl() scans the stack, looking for text
addresses to print. In parallel, it unwinds the stack with
unwind_next_frame(). If the stack address matches the pointer returned
by unwind_get_return_address_ptr() for the current frame, the text
address is printed normally without a question mark. Otherwise it's
considered a breadcrumb (potentially from a previous call path) and it's
printed with a question mark to indicate that the address is unreliable
and typically can be ignored.
Since the following commit:
f1d9a2abff66 ("x86/unwind/orc: Don't skip the first frame for inactive tasks")
... for inactive tasks, show_trace_log_lvl() prints *only* unreliable
addresses (prepended with '?').
That happens because, for the first frame of an inactive task,
unwind_get_return_address_ptr() returns the wrong return address
pointer: one word *below* the task stack pointer. show_trace_log_lvl()
starts scanning at the stack pointer itself, so it never finds the first
'reliable' address, causing only guesses to being printed.
The first frame of an inactive task isn't a normal stack frame. It's
actually just an instance of 'struct inactive_task_frame' which is left
behind by __switch_to_asm(). Now that this inactive frame is actually
exposed to callers, fix unwind_get_return_address_ptr() to interpret it
properly.
Fixes: f1d9a2abff66 ("x86/unwind/orc: Don't skip the first frame for inactive tasks")
Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20200522135435.vbxs7umku5pyrdbk@treble
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5cf65922bb15279402e1e19b5ee8c51d618fa51f upstream.
When attaching a flow dissector program to a network namespace with
bpf(BPF_PROG_ATTACH, ...) we grab a reference to bpf_prog.
If netns gets destroyed while a flow dissector is still attached, and there
are no other references to the prog, we leak the reference and the program
remains loaded.
Leak can be reproduced by running flow dissector tests from selftests/bpf:
# bpftool prog list
# ./test_flow_dissector.sh
...
selftests: test_flow_dissector [PASS]
# bpftool prog list
4: flow_dissector name _dissect tag e314084d332a5338 gpl
loaded_at 2020-05-20T18:50:53+0200 uid 0
xlated 552B jited 355B memlock 4096B map_ids 3,4
btf_id 4
#
Fix it by detaching the flow dissector program when netns is going away.
Fixes: d58e468b11 ("flow_dissector: implements flow dissector BPF hook")
Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Link: https://lore.kernel.org/bpf/20200521083435.560256-1-jakub@cloudflare.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 70b690547d5ea1a3d135a4cc39cd1e08246d0c3a upstream.
initrd_start must not point at the location the initrd is loaded into
the crashkernel memory but at the location it will be after the
crashkernel memory is swapped with the memory at 0.
Fixes: ee337f5469 ("s390/kexec_file: Add crash support to image loader")
Reported-by: Lianbo Jiang <lijiang@redhat.com>
Signed-off-by: Philipp Rudo <prudo@linux.ibm.com>
Tested-by: Lianbo Jiang <lijiang@redhat.com>
Link: https://lore.kernel.org/r/20200512193956.15ae3f23@laptop2-ibm.local
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f45d01f4f30b53c3a0a1c6c1c154acb7ff74ab9f upstream.
A ticket was not released after a call of the function
"rxkad_decrypt_ticket" failed. Thus replace the jump target
"temporary_error_free_resp" by "temporary_error_free_ticket".
Fixes: 8c2f826dc3 ("rxrpc: Don't put crypto buffers on the stack")
Signed-off-by: Qiushi Wu <wu000273@umn.edu>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Markus Elfring <Markus.Elfring@web.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c410bf01933e5e09d142c66c3df9ad470a7eec13 upstream.
rxrpc currently uses a fixed 4s retransmission timeout until the RTT is
sufficiently sampled. This can cause problems with some fileservers with
calls to the cache manager in the afs filesystem being dropped from the
fileserver because a packet goes missing and the retransmission timeout is
greater than the call expiry timeout.
Fix this by:
(1) Copying the RTT/RTO calculation code from Linux's TCP implementation
and altering it to fit rxrpc.
(2) Altering the various users of the RTT to make use of the new SRTT
value.
(3) Replacing the use of rxrpc_resend_timeout to use the calculated RTO
value instead (which is needed in jiffies), along with a backoff.
Notes:
(1) rxrpc provides RTT samples by matching the serial numbers on outgoing
DATA packets that have the RXRPC_REQUEST_ACK set and PING ACK packets
against the reference serial number in incoming REQUESTED ACK and
PING-RESPONSE ACK packets.
(2) Each packet that is transmitted on an rxrpc connection gets a new
per-connection serial number, even for retransmissions, so an ACK can
be cross-referenced to a specific trigger packet. This allows RTT
information to be drawn from retransmitted DATA packets also.
(3) rxrpc maintains the RTT/RTO state on the rxrpc_peer record rather than
on an rxrpc_call because many RPC calls won't live long enough to
generate more than one sample.
(4) The calculated SRTT value is in units of 8ths of a microsecond rather
than nanoseconds.
The (S)RTT and RTO values are displayed in /proc/net/rxrpc/peers.
Fixes: 17926a7932 ([AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both"")
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 33cd65e73abd693c00c4156cf23677c453b41b3b upstream.
During early boot, while KASAN is not yet initialized, it is possible to
enter reporting code-path and end up in kasan_report().
While uninitialized, the branch there prevents generating any reports,
however, under certain circumstances when branches are being traced
(TRACE_BRANCH_PROFILING), we may recurse deep enough to cause kernel
reboots without warning.
To prevent similar issues in future, we should disable branch tracing
for the core runtime.
[elver@google.com: remove duplicate DISABLE_BRANCH_PROFILING, per Qian Cai]
Link: https://lore.kernel.org/lkml/20200517011732.GE24705@shao2-debian/
Link: http://lkml.kernel.org/r/20200522075207.157349-1-elver@google.com
Reported-by: kernel test robot <rong.a.chen@intel.com>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Andrey Konovalov <andreyknvl@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Qian Cai <cai@lca.pw>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r//20200517011732.GE24705@shao2-debian/
Link: http://lkml.kernel.org/r/20200519182459.87166-1-elver@google.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ffca476a0a8d26de767cc41d62b8ca7f540ecfdd upstream.
In the case of get_user_pages_fast() returning fewer pages than
requested, rio_dma_transfer() does not quite do the right thing. It
attempts to release all the pages that were requested, rather than just
the pages that were pinned.
Fix the error handling so that only the pages that were successfully
pinned are released.
Fixes: e8de370188 ("rapidio: add mport char device driver")
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Alexandre Bounine <alex.bou9@gmail.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20200517235620.205225-2-jhubbard@nvidia.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 60858c00e5f018eda711a3aa84cf62214ef62d61 upstream.
Assume we have kmem configured and loaded:
[root@localhost ~]# cat /proc/iomem
...
140000000-33fffffff : Persistent Memory$
140000000-1481fffff : namespace0.0
150000000-33fffffff : dax0.0
150000000-33fffffff : System RAM
Assume we try to unload kmem. This force-unloading will work, even if
memory cannot get removed from the system.
[root@localhost ~]# rmmod kmem
[ 86.380228] removing memory fails, because memory [0x0000000150000000-0x0000000157ffffff] is onlined
...
[ 86.431225] kmem dax0.0: DAX region [mem 0x150000000-0x33fffffff] cannot be hotremoved until the next reboot
Now, we can reconfigure the namespace:
[root@localhost ~]# ndctl create-namespace --force --reconfig=namespace0.0 --mode=devdax
[ 131.409351] nd_pmem namespace0.0: could not reserve region [mem 0x140000000-0x33fffffff]dax
[ 131.410147] nd_pmem: probe of namespace0.0 failed with error -16namespace0.0 --mode=devdax
...
This fails as expected due to the busy memory resource, and the memory
cannot be used. However, the dax0.0 device is removed, and along its
name.
The name of the memory resource now points at freed memory (name of the
device):
[root@localhost ~]# cat /proc/iomem
...
140000000-33fffffff : Persistent Memory
140000000-1481fffff : namespace0.0
150000000-33fffffff : �_�^7_��/_��wR��WQ���^��� ...
150000000-33fffffff : System RAM
We have to make sure to duplicate the string. While at it, remove the
superfluous setting of the name and fixup a stale comment.
Fixes: 9f960da72b ("device-dax: "Hotremove" persistent memory that is used like normal RAM")
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: <stable@vger.kernel.org> [5.3]
Link: http://lkml.kernel.org/r/20200508084217.9160-2-david@redhat.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4c1cbcbd6c56c79de2c07159be4f55386bb0bef2 upstream.
With certain kernel configurations, the R_390_JMP_SLOT relocation type
might be generated, which is not expected by the KASLR relocation code,
and the kernel stops with the message "Unknown relocation type".
This was found with a zfcpdump kernel config, where CONFIG_MODULES=n
and CONFIG_VFIO=n. In that case, symbol_get() is used on undefined
__weak symbols in virt/kvm/vfio.c, which results in the generation
of R_390_JMP_SLOT relocation types.
Fix this by handling R_390_JMP_SLOT similar to R_390_GLOB_DAT.
Fixes: 805bc0bc23 ("s390/kernel: build a relocatable kernel")
Cc: <stable@vger.kernel.org> # v5.2+
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f058599e22d59e594e5aae1dc10560568d8f4a8b upstream.
The s390_mmio_read/write syscalls are currently broken when running with
MIO.
The new pcistb_mio/pcstg_mio/pcilg_mio instructions are executed
similiarly to normal load/store instructions and do address translation
in the current address space. That means inside the kernel they are
aware of mappings into kernel address space while outside the kernel
they use user space mappings (usually created through mmap'ing a PCI
device file).
Now when existing user space applications use the s390_pci_mmio_write
and s390_pci_mmio_read syscalls, they pass I/O addresses that are mapped
into user space so as to be usable with the new instructions without
needing a syscall. Accessing these addresses with the old instructions
as done currently leads to a kernel panic.
Also, for such a user space mapping there may not exist an equivalent
kernel space mapping which means we can't just use the new instructions
in kernel space.
Instead of replicating user mappings in the kernel which then might
collide with other mappings, we can conceptually execute the new
instructions as if executed by the user space application using the
secondary address space. This even allows us to directly store to the
user pointer without the need for copy_to/from_user().
Cc: stable@vger.kernel.org
Fixes: 71ba41c9b1 ("s390/pci: provide support for MIO instructions")
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 133317479f0324f6faaf797c4f5f3e9b1b36ce35 upstream.
Fix to return negative error code -ENOMEM from the ioremap() error handling
case instead of 0, as done elsewhere in this function.
Fixes: 43986798fd ("ipack: add error handling for ioremap_nocache")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Link: https://lore.kernel.org/r/20200507094237.13599-1-weiyongjun1@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fc9c03ce30f79b71807961bfcb42be191af79873 upstream.
Allow me_cl object to be freed by releasing the reference
that was acquired by one of the search functions:
__mei_me_cl_by_uuid_id() or __mei_me_cl_by_uuid()
Cc: <stable@vger.kernel.org>
Reported-by: 亿一 <teroincn@gmail.com>
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Link: https://lore.kernel.org/r/20200512223140.32186-1-tomas.winkler@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 17b4efdf4e4867079012a48ca10d965fe9d68822 upstream.
An uninitialised spin lock for sifive serial console raises a bad
magic spin_lock error as reported and discussed here [1].
Initialising the spin lock resolves the issue.
The fix is tested on HiFive Unleashed A00 board with Linux 5.7-rc4
and OpenSBI v0.7
[1] https://lore.kernel.org/linux-riscv/b9fe49483a903f404e7acc15a6efbef756db28ae.camel@wdc.com
Fixes: 45c054d081 ("tty: serial: add driver for the SiFive UART")
Reported-by: Atish Patra <Atish.Patra@wdc.com>
Signed-off-by: Sagar Shrikant Kadam <sagar.kadam@sifive.com>
Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1589019852-21505-2-git-send-email-sagar.kadam@sifive.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7a839dbab1be59f5ed3b3b046de29e166784c9b4 upstream.
DMA transfers to and from the SD card stall for 10 seconds and run into
timeout on RTS5260 card readers after ASPM was enabled.
Adding a short msleep after disabling ASPM fixes the issue on several
Dell Precision 7530/7540 systems I tested.
This function is only called when waking up after the chip went into
power-save after not transferring data for a few seconds. The added
msleep does therefore not change anything in data transfer speed or
induce any excessive waiting while data transfers are running, or the
chip is sleeping. Only the transition from sleep to active is affected.
Signed-off-by: Klaus Doth <kdlnx@doth.eu>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/4434eaa7-2ee3-a560-faee-6cee63ebd6d4@doth.eu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bcfa1e253d2e329e1ebab5c89f3c73f6dd17606c upstream.
During initial submission the selection of the channel was done using
the scan_index member of the iio_chan_spec structure. It was an abuse
because this member is supposed to be used with a buffer so it was
removed.
However there was still the need to be able to known how to select a
channel, the correct member to store this information is address.
Thanks to this it is possible to select any other channel than the
channel 0.
Fixes: 8dd2d7c0fe ("iio: adc: Add driver for the TI ADS8344 A/DC chips")
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 928edefbc18cd8433f7df235c6e09a9306e7d580 upstream.
This looks really unusual to have a 'get_device()' hidden in a 'dev_err()'
call.
Remove it.
While at it add a missing \n at the end of the message.
Fixes: 574fb258d6 ("Staging: IIO: VTI sca3000 series accelerometer driver (spi)")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 34625c1931f8204c234c532b446b9f53c69f4b68 upstream.
In the "gb_tty_set_termios" function the "newline" variable is declared
but not initialized. So the "flow_control" member is not initialized and
the OR / AND operations with itself results in an undefined value in
this member.
The purpose of the code is to set the flow control type, so remove the
OR / AND self operator and set the value directly.
Addresses-Coverity-ID: 1374016 ("Uninitialized scalar variable")
Fixes: e55c25206d ("greybus: uart: Handle CRTSCTS flag in termios")
Signed-off-by: Oscar Carter <oscar.carter@gmx.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200510101426.23631-1-oscar.carter@gmx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b17884ccf29e127b16bba6aea1438c851c9f5af1 upstream.
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function. Also
removed var 'rv' since we can use 'err' instead.
Fixes: 7dc7967fc3 ("staging: kpc2000: add initial set of Daktronics drivers")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20200506134735.102041-1-weiyongjun1@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5e4f99a6b788047b0b8a7496c2e0c8f372f6edf2 upstream.
If the serial interface is used, the 8-bit address should be latched using
the rising edge of the WR/FSYNC signal.
This basically means that a CS change is required between the first byte
sent, and the second one.
This change splits the single-transfer transfer of 2 bytes into 2 transfers
with a single byte, and CS change in-between.
Note fixes tag is not accurate, but reflects a point beyond which there
are too many refactors to make backporting straight forward.
Fixes: b19e9ad5e2 ("staging:iio:resolver:ad2s1210 general driver cleanup.")
Signed-off-by: Dragos Bogdan <dragos.bogdan@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit b14c94908b1b884276a6608dea3d0b1b510338b7 ]
This reverts commit df5db5f9ee112e76b5202fbc331f990a0fc316d6.
This patch fixes a regression: patch df5db5f9ee112 allowed function
run_queue() to bypass its call to do_xmote() if revokes were queued for
the glock. That's wrong because its call to do_xmote() is what is
responsible for calling the go_sync() glops functions to sync both
the ail list and any revokes queued for it. By bypassing the call,
gfs2 could get into a stand-off where the glock could not be demoted
until its revokes are written back, but the revokes would not be
written back because do_xmote() was never called.
It "sort of" works, however, because there are other mechanisms like
the log flush daemon (logd) that can sync the ail items and revokes,
if it deems it necessary. The problem is: without file system pressure,
it might never deem it necessary.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
