summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-05-20audit: add subj creds to NETFILTER_CFG record toRichard Guy Briggs
Some table unregister actions seem to be initiated by the kernel to garbage collect unused tables that are not initiated by any userspace actions. It was found to be necessary to add the subject credentials to cover this case to reveal the source of these actions. A sample record: The uid, auid, tty, ses and exe fields have not been included since they are in the SYSCALL record and contain nothing useful in the non-user context. Here are two sample orphaned records: type=NETFILTER_CFG msg=audit(2020-05-20 12:14:36.505:5) : table=filter family=ipv4 entries=0 op=register pid=1 subj=kernel comm=swapper/0 type=NETFILTER_CFG msg=audit(2020-05-20 12:15:27.701:301) : table=nat family=bridge entries=0 op=unregister pid=30 subj=system_u:system_r:kernel_t:s0 comm=kworker/u4:1 Signed-off-by: Richard Guy Briggs <rgb@redhat.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2020-05-20drm/amd/display: Defer cursor lock until after VUPDATENicholas Kazlauskas
[Why] We dropped the delay after changed the cursor functions locking the entire pipe to locking just the CURSOR registers to fix page flip stuttering - this introduced cursor stuttering instead, and an underflow issue. The cursor update can be delayed indefinitely if the cursor update repeatedly happens right around VUPDATE. The underflow issue can happen if we do a viewport update on a pipe on the same frame where a cursor update happens around VUPDATE - the old cursor registers are retained which can be in an invalid position. This can cause a pipe hang and indefinite underflow. [How] The complex, ideal solution to the problem would be a software triple buffering mechanism from the DM layer to program only one cursor update per frame just before VUPDATE. The simple workaround until we have that infrastructure in place is this change - bring back the delay until VUPDATE before locking, but with some corrections to the calculations. This didn't work for all timings before because the calculation for VUPDATE was wrong - it was using the offset from VSTARTUP instead and didn't correctly handle the case where VUPDATE could be in the back porch. Add a new hardware sequencer function to use the existing helper to calculate the real VUPDATE start and VUPDATE end - VUPDATE can last multiple lines after all. Change the udelay to incorporate the width of VUPDATE as well. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-05-20drm/amd/display: Remove dml_common_def fileRodrigo Siqueira
During the rework for removing the FPU issues, I found the following warning: [..] dml_common_defs.o: warning: objtool: dml_round()+0x9: FPU instruction outside of kernel_fpu_{begin,end}() This file has a single function that does not need to be in a specific file. This commit drop dml_common_defs file, and move dml_round function to dml_inline_defs. CC: Christian König <christian.koenig@amd.com> CC: Alexander Deucher <Alexander.Deucher@amd.com> CC: Peter Zijlstra <peterz@infradead.org> CC: Tony Cheng <tony.cheng@amd.com> CC: Harry Wentland <hwentlan@amd.com> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-05-20drm/amd/display: DP training to set properly SCRAMBLING_DISABLEVladimir Stempen
[Why] DP training sequence to set SCRAMBLING_DISABLE bit properly based on training pattern - per DP Spec. [How] Update dpcd_pattern.v1_4.SCRAMBLING_DISABLE with 1 for TPS1, TPS2, TPS3, but not for TPS4. Signed-off-by: Vladimir Stempen <vladimir.stempen@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-05-20Merge tag 'fixes-for-5.7-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux Pull MTD fixes from Richard Weinberger: - Fix a PM regression in brcmnand driver - Propagate ECC information correctly on SPI-NAND - Make sure no MTD name is used multiple time in nvmem * tag 'fixes-for-5.7-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: mtd:rawnand: brcmnand: Fix PM resume crash mtd: Fix mtd not registered due to nvmem name collision mtd: spinand: Propagate ECC information to the MTD structure
2020-05-20Merge tag 'for-linus-5.7-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs Pull UBI and UBIFS fixes from Richard Weinberger: - Correctly set next cursor for detailed_erase_block_info debugfs file - Don't use crypto_shash_descsize() for digest size in UBIFS - Remove broken lazytime support from UBIFS * tag 'for-linus-5.7-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs: ubi: Fix seq_file usage in detailed_erase_block_info debugfs file ubifs: fix wrong use of crypto_shash_descsize() ubifs: remove broken lazytime support
2020-05-20Merge tag 'for-linus-5.7-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml Pull UML fixes from Richard Weinberger: - Two missing includes which caused build issues on recent systems - Correctly set TRANS_GRE_LEN in our vector network driver * tag 'for-linus-5.7-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml: um: Fix typo in vector driver transport option definition um: syscall.c: include <asm/unistd.h> um: Fix xor.h include
2020-05-20Merge tag 'pm-5.7-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fix from Rafael Wysocki: "This makes a recently introduced suspend-to-idle wakeup issue on Dell XPS13 9360 go away" * tag 'pm-5.7-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: EC: PM: Avoid flushing EC work when EC GPE is inactive
2020-05-20Merge tag 'ovl-fixes-5.7-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs Pull overlayfs fixes from Miklos Szeredi: "Fix two bugs introduced in this cycle and one introduced in v5.5" * tag 'ovl-fixes-5.7-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs: ovl: potential crash in ovl_fid_to_fh() ovl: clear ATTR_OPEN from attr->ia_valid ovl: clear ATTR_FILE from attr->ia_valid
2020-05-20firmware: smccc: Add function to fetch SMCCC versionSudeep Holla
For backward compatibility reasons, PSCI maintains SMCCC version as SMCCC didn't provide ARM_SMCCC_VERSION_FUNC_ID until v1.1. PSCI initialises both the SMCCC version and conduit. Similar to the conduit, let us provide accessors to fetch the SMCCC version also so that other SMCCC v1.1+ features can use it. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Etienne Carriere <etienne.carriere@st.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Etienne Carriere <etienne.carriere@st.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20200518091222.27467-7-sudeep.holla@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2020-05-20firmware: smccc: Refactor SMCCC specific bits into separate fileSudeep Holla
In order to add newer SMCCC v1.1+ functionality and to avoid cluttering PSCI firmware driver with SMCCC bits, let us move the SMCCC specific details under drivers/firmware/smccc/smccc.c We can also drop conduit and smccc_version from psci_operations structure as SMCCC was the sole user and now it maintains those. No functionality change in this patch though. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Etienne Carriere <etienne.carriere@st.com> Reviewed-by: Etienne Carriere <etienne.carriere@st.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20200518091222.27467-6-sudeep.holla@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2020-05-20firmware: smccc: Drop smccc_version enum and use ARM_SMCCC_VERSION_1_x insteadSudeep Holla
Instead of maintaining 2 sets of enums/macros for tracking SMCCC version, let us drop smccc_version enum and use ARM_SMCCC_VERSION_1_x directly instead. This is in preparation to drop smccc_version here and move it separately under drivers/firmware/smccc. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Etienne Carriere <etienne.carriere@st.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Etienne Carriere <etienne.carriere@st.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20200518091222.27467-5-sudeep.holla@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2020-05-20firmware: smccc: Add the definition for SMCCCv1.2 version/error codesSudeep Holla
Add the definition for SMCCC v1.2 version and new error code added. While at it, also add a note that ARM DEN 0070A is deprecated and is now merged into the main SMCCC specification(ARM DEN 0028C). Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Etienne Carriere <etienne.carriere@st.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Etienne Carriere <etienne.carriere@st.com> Link: https://lore.kernel.org/r/20200518091222.27467-4-sudeep.holla@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2020-05-20firmware: smccc: Update link to latest SMCCC specificationSudeep Holla
The current link gets redirected to the revision B published in November 2016 though it actually points to the original revision A published in June 2013. Let us update the link to point to the latest version, so that it doesn't get stale anytime soon. Currently it points to v1.2 published in March 2020(i.e. DEN0028C). Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Etienne Carriere <etienne.carriere@st.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Etienne Carriere <etienne.carriere@st.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20200518091222.27467-3-sudeep.holla@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2020-05-20firmware: smccc: Add HAVE_ARM_SMCCC_DISCOVERY to identify SMCCC v1.1 and aboveSudeep Holla
SMCCC v1.0 lacked discoverability of version and features. To accelerate adoption of few mitigations and protect systems more rapidly from various vulnerability, PSCI v1.0 was updated to add SMCCC discovery mechanism though the PSCI firmware implementation of PSCI_FEATURES(SMCCC_VERSION) which returns success on firmware compliant to SMCCC v1.1 and above. This inturn makes SMCCC v1.1 and above dependent on ARM_PSCI_FW for backward compatibility. Let us introduce a new hidden config for the same to build more features on top of SMCCC v1.1 and above. While at it, also sort alphabetically the psci entry. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Etienne Carriere <etienne.carriere@st.com> Reviewed-by: Etienne Carriere <etienne.carriere@st.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20200518091222.27467-2-sudeep.holla@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2020-05-20pipe: Fix pipe_full() test in opipe_prep().Tetsuo Handa
syzbot is reporting that splice()ing from non-empty read side to already-full write side causes unkillable task, for opipe_prep() is by error not inverting pipe_full() test. CPU: 0 PID: 9460 Comm: syz-executor.5 Not tainted 5.6.0-rc3-next-20200228-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:rol32 include/linux/bitops.h:105 [inline] RIP: 0010:iterate_chain_key kernel/locking/lockdep.c:369 [inline] RIP: 0010:__lock_acquire+0x6a3/0x5270 kernel/locking/lockdep.c:4178 Call Trace: lock_acquire+0x197/0x420 kernel/locking/lockdep.c:4720 __mutex_lock_common kernel/locking/mutex.c:956 [inline] __mutex_lock+0x156/0x13c0 kernel/locking/mutex.c:1103 pipe_lock_nested fs/pipe.c:66 [inline] pipe_double_lock+0x1a0/0x1e0 fs/pipe.c:104 splice_pipe_to_pipe fs/splice.c:1562 [inline] do_splice+0x35f/0x1520 fs/splice.c:1141 __do_sys_splice fs/splice.c:1447 [inline] __se_sys_splice fs/splice.c:1427 [inline] __x64_sys_splice+0x2b5/0x320 fs/splice.c:1427 do_syscall_64+0xf6/0x790 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xbe Reported-by: syzbot+b48daca8639150bc5e73@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=9386d051e11e09973d5a4cf79af5e8cedf79386d Fixes: 8cefc107ca54c8b0 ("pipe: Use head and tail pointers for the ring, not cursor and length") Cc: stable@vger.kernel.org # 5.5+ Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-05-20ACPI/IORT: Fix PMCG node single ID mapping handlingTuan Phan
An IORT PMCG node can have no ID mapping if its overflow interrupt is wire based therefore the code that parses the PMCG node can not assume the node will always have a single mapping present at index 0. Fix iort_get_id_mapping_index() by checking for an overflow interrupt and mapping count. Fixes: 24e516049360 ("ACPI/IORT: Add support for PMCG") Signed-off-by: Tuan Phan <tuanphan@os.amperecomputing.com> Reviewed-by: Hanjun Guo <guoahanjun@huawei.com> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Link: https://lore.kernel.org/r/1589994787-28637-1-git-send-email-tuanphan@os.amperecomputing.com Signed-off-by: Will Deacon <will@kernel.org>
2020-05-20arm64/cpufeature: Drop open encodings while extracting parangeAnshuman Khandual
Currently there are multiple instances of parange feature width mask open encodings while fetching it's value. Even the width mask value (0x7) itself is not accurate. It should be (0xf) per ID_AA64MMFR0_EL1.PARange[3:0] as in ARM ARM (0487F.a). Replace them with cpuid_feature_extract_unsigned_field() which can extract given standard feature (4 bits width i.e 0xf mask) field. Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Marc Zyngier <maz@kernel.org> Cc: James Morse <james.morse@arm.com> Cc: kvmarm@lists.cs.columbia.edu Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Acked-by: Marc Zyngier <maz@kernel.org> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/1589360614-1164-1-git-send-email-anshuman.khandual@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2020-05-20spi: bcm2835: Tear down DMA before turning off SPI controllerLukas Wunner
On unbind of the BCM2835 SPI driver, the SPI controller is disabled first and the DMA channels are terminated and torn down afterwards. This seems backwards: In the theoretical case that DMA is active, it might try to fill the SPI FIFOs even after the controller has been disabled. Reverse the order, thereby mirroring what's done on ->probe(). Signed-off-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/ac79f1e3d6fd9a1f5e0cb4008c43b98ea70be3c2.1589557526.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-20efi/libstub: Use snprintf with %ls to convert the command lineArvind Sankar
Now we can use snprintf to do the UTF-16 to UTF-8 translation for the command line. Drop the special "zero" trick to handle an empty command line. This was unnecessary even before this since with options_chars == 0, efi_utf16_to_utf8 would not have accessed options at all. snprintf won't access it either with a precision of 0. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200518190716.751506-25-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-20efi/libstub: Get the exact UTF-8 lengthArvind Sankar
efi_convert_cmdline currently overestimates the length of the equivalent UTF-8 encoding. snprintf can now be used to do the conversion to UTF-8, however, it does not have a way to specify the size of the UTF-16 string, only the size of the resulting UTF-8 string. So in order to use it, we need to precalculate the exact UTF-8 size. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200518190716.751506-24-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-20efi/libstub: Use %ls for filenameArvind Sankar
efi_printk can now handle the UTF-16 filename, so print it using efi_err instead of a separate efi_char16_puts call. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200518190716.751506-23-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-20efi/libstub: Add UTF-8 decoding to efi_putsArvind Sankar
In order to be able to use the UTF-16 support added to vsprintf in the previous commit, enhance efi_puts to decode UTF-8 into UTF-16. Invalid UTF-8 encodings are passed through unchanged. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200518190716.751506-22-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-20efi/printf: Add support for wchar_t (UTF-16)Arvind Sankar
Support %lc and %ls to output UTF-16 strings (converted to UTF-8). Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200518190716.751506-21-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-20efi/gop: Add an option to list out the available GOP modesArvind Sankar
Add video=efifb:list option to list the modes that are available. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200518190716.751506-20-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-20efi/libstub: Add definitions for console input and eventsArvind Sankar
Add the required typedefs etc for using con_in's simple text input protocol, and for using the boottime event services. Also add the prototype for the "stall" boot service. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200518190716.751506-19-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-20efi/libstub: Implement printk-style loggingArvind Sankar
Use the efi_printk function in efi_info/efi_err, and add efi_debug. This allows formatted output at different log levels. Add the notion of a loglevel instead of just quiet/not-quiet, and parse the efi=debug kernel parameter in addition to quiet. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200520170223.GA3333632@rani.riverdale.lan/ Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-20Merge branch 'for-5.7' of ↵Mark Brown
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi into spi-5.8
2020-05-21drm/mediatek: Eliminate the magic number in array sizeBernard Zhao
Eiminate the magic number in array size, there macro defines in hdmi.h. Signed-off-by: Bernard Zhao <bernard@vivo.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2020-05-21drm/mediatek: Cleanup coding style in mediatek a bitBernard Zhao
This code change is to make code bit more readable. Signed-off-by: Bernard Zhao <bernard@vivo.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2020-05-21drm/mediatek: Stop iterating dma addresses when sg_dma_len() == 0Anand K Mistry
If dma_map_sg() merges pages when creating the mapping, only the first entries will have a valid sg_dma_address() and sg_dma_len(), followed by entries with sg_dma_len() == 0. Signed-off-by: Anand K Mistry <amistry@google.com> Signed-off-by: Anand K Mistry <amistry@chromium.org> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2020-05-20Merge series "MAINTAINER entries for few ROHM power devices" from Matti ↵Mark Brown
Vaittinen <matti.vaittinen@fi.rohmeurope.com>: Add maintainer entries to a few ROHM devices and Linear Ranges Linear Ranges helpers were refactored out of regulator core to lib so that other drivers could utilize them too. (I guess power/supply drivers and possibly clk drivers can benefit from them). As regulators is currently the main user it makes sense the changes to linear_ranges go through Mark's tree. During past two years few ROHM PMIC drivers have been added to mainstream. They deserve a supporter from ROHM side too :) Patch 1: Maintainer entries for few ROHM IC drivers Patch 2: Maintainer entry for linear ranges helpers --- Matti Vaittinen (2): MAINTAINERS: Add entry for ROHM power management ICs MAINTAINERS: Add maintainer entry for linear ranges helper MAINTAINERS | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) base-commit: b9bbe6ed63b2b9f2c9ee5cbd0f2c946a2723f4ce -- 2.21.0 -- Matti Vaittinen, Linux device drivers ROHM Semiconductors, Finland SWDC Kiviharjunlenkki 1E 90220 OULU FINLAND ~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~ Simon says - in Latin please. ~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~ Thanks to Simon Glass for the translation =]
2020-05-20MAINTAINERS: Add maintainer entry for linear ranges helperMatti Vaittinen
The linear ranges helpers were refactored out of regulator core for other drivers to enjoy. Add regulator maintainer Mark Brown as maintainer and myself as a reviewer. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/fbbbee249c6b9df3ba63bb51ea53526b22921e84.1589866138.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-20arm64/cpufeature: Validate hypervisor capabilities during CPU hotplugAnshuman Khandual
This validates hypervisor capabilities like VMID width, IPA range for any hot plug CPU against system finalized values. KVM's view of the IPA space is used while allowing a given CPU to come up. While here, it factors out get_vmid_bits() for general use. Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Marc Zyngier <maz@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: kvmarm@lists.cs.columbia.edu Cc: linux-kernel@vger.kernel.org Suggested-by: Suzuki Poulose <suzuki.poulose@arm.com> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1589248647-22925-1-git-send-email-anshuman.khandual@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2020-05-20io_uring: don't submit sqes when ctx->refs is dyingXiaoguang Wang
When IORING_SETUP_SQPOLL is enabled, io_ring_ctx_wait_and_kill() will wait for sq thread to idle by busy loop: while (ctx->sqo_thread && !wq_has_sleeper(&ctx->sqo_wait)) cond_resched(); Above loop isn't very CPU friendly, it may introduce a short cpu burst on the current cpu. If ctx->refs is dying, we forbid sq_thread from submitting any further SQEs. Instead they just get discarded when we exit. Signed-off-by: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-05-20rxrpc: Fix ack discardDavid Howells
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: 1a2391c30c0b ("rxrpc: Fix detection of out of order acks") Reported-by: Dave Botsch <botsch@cnf.cornell.edu> Signed-off-by: David Howells <dhowells@redhat.com>
2020-05-20rxrpc: Trace discarded ACKsDavid Howells
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>
2020-05-20objtool: Enable compilation of objtool for all architecturesMatt Helsley
Objtool currently only compiles for x86 architectures. This is fine as it presently does not support tooling for other architectures. However, we would like to be able to convert other kernel tools to run as objtool sub commands because they too process ELF object files. This will allow us to convert tools such as recordmcount to use objtool's ELF code. Since much of recordmcount's ELF code is copy-paste code to/from a variety of other kernel tools (look at modpost for example) this means that if we can convert recordmcount we can convert more. We define weak definitions for subcommand entry functions and other weak definitions for shared functions critical to building existing subcommands. These return 127 when the command is missing which signify tools that do not exist on all architectures. In this case the "check" and "orc" tools do not exist on all architectures so we only add them for x86. Future changes adding support for "check", to arm64 for example, can then modify the SUBCMD_CHECK variable when building for arm64. Objtool is not currently wired in to KConfig to be built for other architectures because it's not needed for those architectures and there are no commands it supports other than those for x86. As more command support is enabled on various architectures the necessary KConfig changes can be made (e.g. adding "STACK_VALIDATION") to trigger building objtool. [ jpoimboe: remove aliases, add __weak macro, add error messages ] Cc: Julien Thierry <jthierry@redhat.com> Signed-off-by: Matt Helsley <mhelsley@vmware.com> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
2020-05-20spi: bcm2835aux: Fix controller unregister orderLukas Wunner
The BCM2835aux SPI driver uses devm_spi_register_master() on bind. As a consequence, on unbind, __device_release_driver() first invokes bcm2835aux_spi_remove() before unregistering the SPI controller via devres_release_all(). This order is incorrect: bcm2835aux_spi_remove() turns off the SPI controller, including its interrupts and clock. The SPI controller is thus no longer usable. When the SPI controller is subsequently unregistered, it unbinds all its slave devices. If their drivers need to access the SPI bus, e.g. to quiesce their interrupts, unbinding will fail. As a rule, devm_spi_register_master() must not be used if the ->remove() hook performs teardown steps which shall be performed after unbinding of slaves. Fix by using the non-devm variant spi_register_master(). Note that the struct spi_master as well as the driver-private data are not freed until after bcm2835aux_spi_remove() has finished, so accessing them is safe. Fixes: 1ea29b39f4c8 ("spi: bcm2835aux: add bcm2835 auxiliary spi device driver") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org # v4.4+ Cc: Martin Sperl <kernel@martin.sperl.org> Link: https://lore.kernel.org/r/32f27f4d8242e4d75f9a53f7e8f1f77483b08669.1589557526.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-20spi: bcm2835: Fix controller unregister orderLukas Wunner
The BCM2835 SPI driver uses devm_spi_register_controller() on bind. As a consequence, on unbind, __device_release_driver() first invokes bcm2835_spi_remove() before unregistering the SPI controller via devres_release_all(). This order is incorrect: bcm2835_spi_remove() tears down the DMA channels and turns off the SPI controller, including its interrupts and clock. The SPI controller is thus no longer usable. When the SPI controller is subsequently unregistered, it unbinds all its slave devices. If their drivers need to access the SPI bus, e.g. to quiesce their interrupts, unbinding will fail. As a rule, devm_spi_register_controller() must not be used if the ->remove() hook performs teardown steps which shall be performed after unbinding of slaves. Fix by using the non-devm variant spi_register_controller(). Note that the struct spi_controller as well as the driver-private data are not freed until after bcm2835_spi_remove() has finished, so accessing them is safe. Fixes: 247263dba208 ("spi: bcm2835: use devm_spi_register_master()") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org # v3.13+ Link: https://lore.kernel.org/r/2397dd70cdbe95e0bc4da2b9fca0f31cb94e5aed.1589557526.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-20spi: Fix controller unregister orderLukas Wunner
When an SPI controller unregisters, it unbinds all its slave devices. For this, their drivers may need to access the SPI bus, e.g. to quiesce interrupts. However since commit ffbbdd21329f ("spi: create a message queueing infrastructure"), spi_destroy_queue() is executed before unbinding the slaves. It sets ctlr->running = false, thereby preventing SPI bus access and causing unbinding of slave devices to fail. Fix by unbinding slaves before calling spi_destroy_queue(). Fixes: ffbbdd21329f ("spi: create a message queueing infrastructure") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org # v3.4+ Cc: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/8aaf9d44c153fe233b17bc2dec4eb679898d7e7b.1589557526.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-20objtool: Move struct objtool_file into arch-independent headerMatt Helsley
The objtool_file structure describes the files objtool works on, is used by the check subcommand, and the check.h header is included by the orc subcommands so it's presently used by all subcommands. Since the structure will be useful in all subcommands besides check, and some subcommands may not want to include check.h to get the definition, split the structure out into a new header meant for use by all objtool subcommands. Signed-off-by: Matt Helsley <mhelsley@vmware.com> Reviewed-by: Julien Thierry <jthierry@redhat.com> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
2020-05-20objtool: Exit successfully when requesting helpMatt Helsley
When the user requests help it's not an error so do not exit with a non-zero exit code. This is not especially useful for a user but any script that might wish to check that objtool --help is at least available can't rely on the exit code to crudely check that, for example, building an objtool executable succeeds. Signed-off-by: Matt Helsley <mhelsley@vmware.com> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
2020-05-20objtool: Add check_kcov_mode() to the uaccess safelistJosh Poimboeuf
check_kcov_mode() is called by write_comp_data() and __sanitizer_cov_trace_pc(), which are already on the uaccess safe list. It's notrace and doesn't call out to anything else, so add it to the list too. This fixes the following warnings: kernel/kcov.o: warning: objtool: __sanitizer_cov_trace_pc()+0x15: call to check_kcov_mode() with UACCESS enabled kernel/kcov.o: warning: objtool: write_comp_data()+0x1b: call to check_kcov_mode() with UACCESS enabled Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
2020-05-20samples/ftrace: Fix asm function ELF annotationsJosh Poimboeuf
Enable objtool coverage for the sample ftrace modules by adding ELF annotations to the asm trampoline functions. samples/ftrace/ftrace-direct.o: warning: objtool: .text+0x0: unreachable instruction samples/ftrace/ftrace-direct-modify.o: warning: objtool: .text+0x0: unreachable instruction samples/ftrace/ftrace-direct-too.o: warning: objtool: .text+0x0: unreachable instruction Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
2020-05-20io_uring: reset -EBUSY error when io sq thread is waken upXiaoguang Wang
In io_sq_thread(), currently if we get an -EBUSY error and go to sleep, we will won't clear it again, which will result in io_sq_thread() will never have a chance to submit sqes again. Below test program test.c can reveal this bug: int main(int argc, char *argv[]) { struct io_uring ring; int i, fd, ret; struct io_uring_sqe *sqe; struct io_uring_cqe *cqe; struct iovec *iovecs; void *buf; struct io_uring_params p; if (argc < 2) { printf("%s: file\n", argv[0]); return 1; } memset(&p, 0, sizeof(p)); p.flags = IORING_SETUP_SQPOLL; ret = io_uring_queue_init_params(4, &ring, &p); if (ret < 0) { fprintf(stderr, "queue_init: %s\n", strerror(-ret)); return 1; } fd = open(argv[1], O_RDONLY | O_DIRECT); if (fd < 0) { perror("open"); return 1; } iovecs = calloc(10, sizeof(struct iovec)); for (i = 0; i < 10; i++) { if (posix_memalign(&buf, 4096, 4096)) return 1; iovecs[i].iov_base = buf; iovecs[i].iov_len = 4096; } ret = io_uring_register_files(&ring, &fd, 1); if (ret < 0) { fprintf(stderr, "%s: register %d\n", __FUNCTION__, ret); return ret; } for (i = 0; i < 10; i++) { sqe = io_uring_get_sqe(&ring); if (!sqe) break; io_uring_prep_readv(sqe, 0, &iovecs[i], 1, 0); sqe->flags |= IOSQE_FIXED_FILE; ret = io_uring_submit(&ring); sleep(1); printf("submit %d\n", i); } for (i = 0; i < 10; i++) { io_uring_wait_cqe(&ring, &cqe); printf("receive: %d\n", i); if (cqe->res != 4096) { fprintf(stderr, "ret=%d, wanted 4096\n", cqe->res); ret = 1; } io_uring_cqe_seen(&ring, cqe); } close(fd); io_uring_queue_exit(&ring); return 0; } sudo ./test testfile above command will hang on the tenth request, to fix this bug, when io sq_thread is waken up, we reset the variable 'ret' to be zero. Suggested-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-05-20usb: pulse8-cec: Switch to use %ptTAndy Shevchenko
Use %ptT instead of open coded variant to print content of time64_t type in human readable format. Link: https://lore.kernel.org/r/20200415170046.33374-4-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Rewieved-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Petr Mladek <pmladek@suse.com>
2020-05-20ARM: bcm2835: Switch to use %ptTAndy Shevchenko
Use %ptT instead of open coded variant to print content of time64_t type in human readable format. Link: https://lore.kernel.org/r/20200415170046.33374-3-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Rewieved-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Petr Mladek <pmladek@suse.com>
2020-05-20lib/vsprintf: Print time64_t in human readable formatAndy Shevchenko
There are users which print time and date represented by content of time64_t type in human readable format. Instead of open coding that each time introduce %ptT[dt][r] specifier. Few test cases for %ptT specifier has been added as well. Link: https://lore.kernel.org/r/20200415170046.33374-2-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Rewieved-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Petr Mladek <pmladek@suse.com>
2020-05-20Revert "powerpc/32s: reorder Linux PTE bits to better match Hash PTE bits."Christophe Leroy
This reverts commit 697ece78f8f749aeea40f2711389901f0974017a. The implementation of SWAP on powerpc requires page protection bits to not be one of the least significant PTE bits. Until the SWAP implementation is changed and this requirement voids, we have to keep at least _PAGE_RW outside of the 3 last bits. For now, revert to previous PTE bits order. A further rework may come later. Fixes: 697ece78f8f7 ("powerpc/32s: reorder Linux PTE bits to better match Hash PTE bits.") Reported-by: Rui Salvaterra <rsalvaterra@gmail.com> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/b34706f8de87f84d135abb5f3ede6b6f16fb1f41.1589969799.git.christophe.leroy@csgroup.eu
generated by cgit (git 2.34.1) at 2025-09-24 06:33:42 +0000