- 23 May, 2022 17 commits
-
-
Ahmad Fatoum authored
The NXP Cryptographic Acceleration and Assurance Module (CAAM) can be used to protect user-defined data across system reboot: - When the system is fused and boots into secure state, the master key is a unique never-disclosed device-specific key - random key is encrypted by key derived from master key - data is encrypted using the random key - encrypted data and its encrypted random key are stored alongside - This blob can now be safely stored in non-volatile memory On next power-on: - blob is loaded into CAAM - CAAM writes decrypted data either into memory or key register Add functions to realize encrypting and decrypting into memory alongside the CAAM driver. They will be used in a later commit as a source for the trusted key seal/unseal mechanism. Reviewed-by:
David Gstir <david@sigma-star.at> Reviewed-by:
Pankaj Gupta <pankaj.gupta@nxp.com> Tested-by:
Tim Harvey <tharvey@gateworks.com> Tested-by:
Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Tested-by:
Pankaj Gupta <pankaj.gupta@nxp.com> Tested-by: Michael Walle <michael@walle.cc> # on ls1028a (non-E and E) Tested-by: John Ernberg <john.ernberg@actia.se> # iMX8QXP Signed-off-by:
Steffen Trumtrar <s.trumtrar@pengutronix.de> Signed-off-by:
Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org>
-
Ahmad Fatoum authored
Depending on SoC variant, a CAAM may be available, but with some futures fused out. The LS1028A (non-E) SoC is one such SoC and while it indicates BLOB support, BLOB operations will ultimately fail, because there is no AES support. Add a new blob_present member to reflect whether both BLOB support and the AES support it depends on is available. These will be used in a follow-up commit to allow blob driver initialization to error out on SoCs without the necessary hardware support instead of failing at runtime with a cryptic caam_jr 8020000.jr: 20000b0f: CCB: desc idx 11: : Invalid CHA selected. Co-developed-by:
Michael Walle <michael@walle.cc> Signed-off-by:
Michael Walle <michael@walle.cc> Tested-by: Michael Walle <michael@walle.cc> # on ls1028a (non-E and E) Signed-off-by:
Ahmad Fatoum <a.fatoum@pengutronix.de> Reviewed-by:
Pankaj Gupta <pankaj.gupta@nxp.com> Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org>
-
Ahmad Fatoum authored
The two existing trusted key sources don't make use of the kernel RNG, but instead let the hardware doing the sealing/unsealing also generate the random key material. However, both users and future backends may want to place less trust into the quality of the trust source's random number generator and instead reuse the kernel entropy pool, which can be seeded from multiple entropy sources. Make this possible by adding a new trusted.rng parameter, that will force use of the kernel RNG. In its absence, it's up to the trust source to decide, which random numbers to use, maintaining the existing behavior. Suggested-by:
Jarkko Sakkinen <jarkko@kernel.org> Acked-by:
Sumit Garg <sumit.garg@linaro.org> Acked-by:
Pankaj Gupta <pankaj.gupta@nxp.com> Reviewed-by:
David Gstir <david@sigma-star.at> Reviewed-by:
Pankaj Gupta <pankaj.gupta@nxp.com> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Tested-by:
Pankaj Gupta <pankaj.gupta@nxp.com> Tested-by: Michael Walle <michael@walle.cc> # on ls1028a (non-E and E) Tested-by: John Ernberg <john.ernberg@actia.se> # iMX8QXP Signed-off-by:
Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org>
-
Ahmad Fatoum authored
With recent rework, trusted keys are no longer limited to TPM as trust source. The Kconfig symbol is unchanged however leading to a few issues: - TCG_TPM is required, even if only TEE is to be used - Enabling TCG_TPM, but excluding it from available trusted sources is not possible - TEE=m && TRUSTED_KEYS=y will lead to TEE support being silently dropped, which is not the best user experience Remedy these issues by introducing two new boolean Kconfig symbols: TRUSTED_KEYS_TPM and TRUSTED_KEYS_TEE with the appropriate dependencies. Any new code depending on the TPM trusted key backend in particular or symbols exported by it will now need to explicitly state that it depends on TRUSTED_KEYS && TRUSTED_KEYS_TPM The latter to ensure the dependency is built and the former to ensure it's reachable for module builds. There are no such users yet. Reviewed-by:
Sumit Garg <sumit.garg@linaro.org> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Reviewed-by:
Pankaj Gupta <pankaj.gupta@nxp.com> Tested-by:
Pankaj Gupta <pankaj.gupta@nxp.com> Tested-by:
Andreas Rammhold <andreas@rammhold.de> Tested-by:
Tim Harvey <tharvey@gateworks.com> Tested-by: Michael Walle <michael@walle.cc> # on ls1028a (non-E and E) Tested-by: John Ernberg <john.ernberg@actia.se> # iMX8QXP Signed-off-by:
Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org>
-
Stefan Mahnke-Hartmann authored
TPM2_GetCapability with a capability that has the property type value of TPM_PT_TOTAL_COMMANDS returns a zero length list, when an Infineon TPM2 is in field upgrade mode. Since an Infineon TPM2.0 in field upgrade mode returns RC_SUCCESS on TPM2_Startup, the field upgrade mode has to be detected by TPM2_GetCapability. Signed-off-by:
Stefan Mahnke-Hartmann <stefan.mahnke-hartmann@infineon.com> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org>
-
Stefan Mahnke-Hartmann authored
Under certain conditions uninitialized memory will be accessed. As described by TCG Trusted Platform Module Library Specification, rev. 1.59 (Part 3: Commands), if a TPM2_GetCapability is received, requesting a capability, the TPM in field upgrade mode may return a zero length list. Check the property count in tpm2_get_tpm_pt(). Fixes: 2ab32411 ("tpm: migrate tpm2_get_tpm_pt() to use struct tpm_buf") Cc: stable@vger.kernel.org Signed-off-by:
Stefan Mahnke-Hartmann <stefan.mahnke-hartmann@infineon.com> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org>
-
Uwe Kleine-König authored
Returning an error value in an i2c remove callback results in an error message being emitted by the i2c core, but otherwise it doesn't make a difference. The device goes away anyhow and the devm cleanups are called. As tpm_cr50_i2c_remove() emits an error message already and the additional error message by the i2c core doesn't add any useful information, change the return value to zero to suppress this error message. Note that if i2c_clientdata is NULL, there is something really fishy. Assuming no memory corruption happened (then all bets are lost anyhow), tpm_cr50_i2c_remove() is only called after tpm_cr50_i2c_probe() returned successfully. So there was a tpm chip registered before and after tpm_cr50_i2c_remove() its privdata is freed but the associated character device isn't removed. If after that happened userspace accesses the character device it's likely that the freed memory is accessed. For that reason the warning message is made a bit more frightening. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org>
-
Jes B. Klinke authored
Accept one additional numerical value of DID:VID for next generation Google TPM with new firmware, to be used in future Chromebooks. The TPM with the new firmware has the code name TI50, and is going to use the same interfaces. Signed-off-by:
Jes B. Klinke <jbk@chromium.org> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org>
-
Johannes Holland authored
Only tpm_tis and tpm_tis_synquacer have a dedicated way to access multiple bytes at once, every other driver will just fall back to read_bytes/write_bytes. Therefore, remove the read16/read32/write32 calls and move their logic to read_bytes/write_bytes. Suggested-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Johannes Holland <johannes.holland@infineon.com> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org>
-
Xiu Jianfeng authored
Currently it returns zero when CRQ response timed out, it should return an error code instead. Fixes: d8d74ea3 ("tpm: ibmvtpm: Wait for buffer to be set before proceeding") Signed-off-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by:
Stefan Berger <stefanb@linux.ibm.com> Acked-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org>
-
Haowen Bai authored
Return boolean values ("true" or "false") instead of 1 or 0 from bool functions. Signed-off-by:
Haowen Bai <baihaowen@meizu.com> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org>
-
Mickaël Salaün authored
The blacklist_init() function calls panic() for memory allocation errors. This change documents the reason why we don't return -ENODEV. Link: https://lore.kernel.org/r/20220322111323.542184-2-mic@digikod.net Link: https://lore.kernel.org/r/YjeW2r6Wv55Du0bJ@iki.fiSuggested-by:
Paul Moore <paul@paul-moore.com> Reviewed-by:
Paul Moore <paul@paul-moore.com> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Mickaël Salaün <mic@linux.microsoft.com> Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org>
-
Mickaël Salaün authored
Add a kernel option SYSTEM_BLACKLIST_AUTH_UPDATE to enable the root user to dynamically add new keys to the blacklist keyring. This enables to invalidate new certificates, either from being loaded in a keyring, or from being trusted in a PKCS#7 certificate chain. This also enables to add new file hashes to be denied by the integrity infrastructure. Being able to untrust a certificate which could have normaly been trusted is a sensitive operation. This is why adding new hashes to the blacklist keyring is only allowed when these hashes are signed and vouched by the builtin trusted keyring. A blacklist hash is stored as a key description. The PKCS#7 signature of this description must be provided as the key payload. Marking a certificate as untrusted should be enforced while the system is running. It is then forbiden to remove such blacklist keys. Update blacklist keyring, blacklist key and revoked certificate access rights: * allows the root user to search for a specific blacklisted hash, which make sense because the descriptions are already viewable; * forbids key update (blacklist and asymmetric ones); * restricts kernel rights on the blacklist keyring to align with the root user rights. See help in tools/certs/print-cert-tbs-hash.sh . Cc: David Howells <dhowells@redhat.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Eric Snowberg <eric.snowberg@oracle.com> Cc: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Mickaël Salaün <mic@linux.microsoft.com> Link: https://lore.kernel.org/r/20210712170313.884724-6-mic@digikod.netReviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Tested-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org>
-
Mickaël Salaün authored
Add and use a check-blacklist-hashes.awk script to make sure that the builtin blacklist hashes set with CONFIG_SYSTEM_BLACKLIST_HASH_LIST will effectively be taken into account as blacklisted hashes. This is useful to debug invalid hash formats, and it make sure that previous hashes which could have been loaded in the kernel, but silently ignored, are now noticed and deal with by the user at kernel build time. This also prevent stricter blacklist key description checking (provided by following commits) to failed for builtin hashes. Update CONFIG_SYSTEM_BLACKLIST_HASH_LIST help to explain the content of a hash string and how to generate certificate ones. Cc: David Howells <dhowells@redhat.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Eric Snowberg <eric.snowberg@oracle.com> Cc: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Mickaël Salaün <mic@linux.microsoft.com> Link: https://lore.kernel.org/r/20210712170313.884724-3-mic@digikod.netReviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org>
-
Mickaël Salaün authored
Before exposing this new key type to user space, make sure that only meaningful blacklisted hashes are accepted. This is also checked for builtin blacklisted hashes, but a following commit make sure that the user will notice (at built time) and will fix the configuration if it already included errors. Check that a blacklist key description starts with a valid prefix and then a valid hexadecimal string. Cc: David Howells <dhowells@redhat.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Eric Snowberg <eric.snowberg@oracle.com> Signed-off-by:
Mickaël Salaün <mic@linux.microsoft.com> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Link: https://lore.kernel.org/r/20210712170313.884724-4-mic@digikod.netSigned-off-by:
Jarkko Sakkinen <jarkko@kernel.org>
-
Mickaël Salaün authored
Factor out the blacklist hash creation with the get_raw_hash() helper. This also centralize the "tbs" and "bin" prefixes and make them private, which help to manage them consistently. Cc: David Howells <dhowells@redhat.com> Cc: David S. Miller <davem@davemloft.net> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Eric Snowberg <eric.snowberg@oracle.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Mickaël Salaün <mic@linux.microsoft.com> Link: https://lore.kernel.org/r/20210712170313.884724-5-mic@digikod.netSigned-off-by:
Jarkko Sakkinen <jarkko@kernel.org>
-
Mickaël Salaün authored
Add a new helper print-cert-tbs-hash.sh to generate a TBSCertificate hash from a given certificate. This is useful to generate a blacklist key description used to forbid loading a specific certificate in a keyring, or to invalidate a certificate provided by a PKCS#7 file. This kind of hash formatting is required to populate the file pointed out by CONFIG_SYSTEM_BLACKLIST_HASH_LIST, but only the kernel code was available to understand how to effectively create such hash. Cc: David Howells <dhowells@redhat.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Eric Snowberg <eric.snowberg@oracle.com> Signed-off-by:
Mickaël Salaün <mic@linux.microsoft.com> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Link: https://lore.kernel.org/r/20210712170313.884724-2-mic@digikod.netSigned-off-by:
Jarkko Sakkinen <jarkko@kernel.org>
-
- 22 May, 2022 4 commits
-
-
Linus Torvalds authored
-
David Howells authored
If a callback break occurs (change notification), afs_getattr() needs to issue an FS.FetchStatus RPC operation to update the status of the file being examined by the stat-family of system calls. Fix afs_getattr() to do this if AFS_VNODE_CB_PROMISED has been cleared on a vnode by a callback break. Skip this if AT_STATX_DONT_SYNC is set. This can be tested by appending to a file on one AFS client and then using "stat -L" to examine its length on a machine running kafs. This can also be watched through tracing on the kafs machine. The callback break is seen: kworker/1:1-46 [001] ..... 978.910812: afs_cb_call: c=0000005f YFSCB.CallBack kworker/1:1-46 [001] ...1. 978.910829: afs_cb_break: 100058:23b4c:242d2c2 b=2 s=1 break-cb kworker/1:1-46 [001] ..... 978.911062: afs_call_done: c=0000005f ret=0 ab=0 [0000000082994ead] And then the stat command generated no traffic if unpatched, but with this change a call to fetch the status can be observed: stat-4471 [000] ..... 986.744122: afs_make_fs_call: c=000000ab 100058:023b4c:242d2c2 YFS.FetchStatus stat-4471 [000] ..... 986.745578: afs_call_done: c=000000ab ret=0 ab=0 [0000000087fc8c84] Fixes: 08e0e7c8 ("[AF_RXRPC]: Make the in-kernel AFS filesystem use AF_RXRPC.") Reported-by:
Markus Suvanto <markus.suvanto@gmail.com> Signed-off-by:
David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org Tested-by:
Markus Suvanto <markus.suvanto@gmail.com> Tested-by: kafs-testing+fedora34_64checkkafs-build-496@auristor.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=216010 Link: https://lore.kernel.org/r/165308359800.162686.14122417881564420962.stgit@warthog.procyon.org.uk/ # v1 Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxLinus Torvalds authored
Pull i2c fixes from Wolfram Sang: "Some I2C driver bugfixes for 5.18. Nothing spectacular but worth fixing" * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: drivers: i2c: thunderx: Allow driver to work with ACPI defined TWSI controllers i2c: ismt: Provide a DMA buffer for Interrupt Cause Logging i2c: mt7621: fix missing clk_disable_unprepare() on error in mtk_i2c_probe()
-
Linus Torvalds authored
Merge tag 'perf-tools-fixes-for-v5.18-2022-05-21' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux Pull perf tools fixes from Arnaldo Carvalho de Melo: - Fix and validate CPU map inputs in synthetic PERF_RECORD_STAT events in 'perf stat'. - Fix x86's arch__intr_reg_mask() for the hybrid platform. - Address 'perf bench numa' compiler error on s390. - Fix check for btf__load_from_kernel_by_id() in libbpf. - Fix "all PMU test" 'perf test' to skip hv_24x7/hv_gpci tests on powerpc. - Fix session topology test to skip the test in guest environment. - Skip BPF 'perf test' if clang is not present. - Avoid shell test description infinite loop in 'perf test'. - Fix Intel LBR callstack entries and nr print message. * tag 'perf-tools-fixes-for-v5.18-2022-05-21' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: perf session: Fix Intel LBR callstack entries and nr print message perf test bpf: Skip test if clang is not present perf test session topology: Fix test to skip the test in guest environment perf bench numa: Address compiler error on s390 perf test: Avoid shell test description infinite loop perf regs x86: Fix arch__intr_reg_mask() for the hybrid platform perf test: Fix "all PMU test" to skip hv_24x7/hv_gpci tests on powerpc perf stat: Fix and validate CPU map inputs in synthetic PERF_RECORD_STAT events perf build: Fix check for btf__load_from_kernel_by_id() in libbpf
-
- 21 May, 2022 15 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/inputLinus Torvalds authored
Pull input fixes from Dmitry Torokhov: "A small fixup to ili210x touchscreen driver, and updated maintainer entry for the device tree binding of Mediatek 6779 keypad: - fix reset timing of Ilitek touchscreens - update maintainer entry of DT binding of Mediatek 6779 keypad" * tag 'input-for-v5.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: ili210x - use one common reset implementation Input: ili210x - fix reset timing dt-bindings: input: mediatek,mt6779-keypad: update maintainer
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds authored
Pull SCSI fixes from James Bottomley: "Two patches, both in drivers. The iscsi one is fixing the cpumask issue you commented on and the ufs one is a late arriving fix for conditions that can occur in Host Performance Booster reads" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: ufs: core: Fix referencing invalid rsp field scsi: target: Fix incorrect use of cpumask_t
-
Chengdong Li authored
When generating callstack information from branch_stack(Intel LBR), the actual number of callstack entry should be bigger than the number of branch_stack, for example: branch_stack records: B() -> C() A() -> B() converted callstack records should be: C() B() A() though, the number of callstack equals to the number of branch stack plus 1. This patch fixes above issue in branch_stack__printf(). For example, # echo 'scale=2000; 4*a(1)' > cmd # perf record --call-graph lbr bc -l < cmd Before applying this patch, `perf script -D` output: 1220022677386876 0x2a40 [0xd8]: PERF_RECORD_SAMPLE(IP, 0x4002): 17990/17990: 0x40a6d6 period: 894172 addr: 0 ... LBR call chain: nr:8 ..... 0: fffffffffffffe00 ..... 1: 000000000040a410 ..... 2: 000000000040573c ..... 3: 0000000000408650 ..... 4: 00000000004022f2 ..... 5: 00000000004015f5 ..... 6: 00007f5ed6dcb553 ..... 7: 0000000000401698 ... FP chain: nr:2 ..... 0: fffffffffffffe00 ..... 1: 000000000040a6d8 ... branch callstack: nr:6 # which is not consistent with LBR records. ..... 0: 000000000040a410 ..... 1: 0000000000408650 # ditto ..... 2: 00000000004022f2 ..... 3: 00000000004015f5 ..... 4: 00007f5ed6dcb553 ..... 5: 0000000000401698 ... thread: bc:17990 ...... dso: /usr/bin/bc bc 17990 1220022.677386: 894172 cycles: 40a410 [unknown] (/usr/bin/bc) 40573c [unknown] (/usr/bin/bc) 408650 [unknown] (/usr/bin/bc) 4022f2 [unknown] (/usr/bin/bc) 4015f5 [unknown] (/usr/bin/bc) 7f5ed6dcb553 __libc_start_main+0xf3 (/usr/lib64/libc-2.17.so) 401698 [unknown] (/usr/bin/bc) After applied: 1220022677386876 0x2a40 [0xd8]: PERF_RECORD_SAMPLE(IP, 0x4002): 17990/17990: 0x40a6d6 period: 894172 addr: 0 ... LBR call chain: nr:8 ..... 0: fffffffffffffe00 ..... 1: 000000000040a410 ..... 2: 000000000040573c ..... 3: 0000000000408650 ..... 4: 00000000004022f2 ..... 5: 00000000004015f5 ..... 6: 00007f5ed6dcb553 ..... 7: 0000000000401698 ... FP chain: nr:2 ..... 0: fffffffffffffe00 ..... 1: 000000000040a6d8 ... branch callstack: nr:7 ..... 0: 000000000040a410 ..... 1: 000000000040573c ..... 2: 0000000000408650 ..... 3: 00000000004022f2 ..... 4: 00000000004015f5 ..... 5: 00007f5ed6dcb553 ..... 6: 0000000000401698 ... thread: bc:17990 ...... dso: /usr/bin/bc bc 17990 1220022.677386: 894172 cycles: 40a410 [unknown] (/usr/bin/bc) 40573c [unknown] (/usr/bin/bc) 408650 [unknown] (/usr/bin/bc) 4022f2 [unknown] (/usr/bin/bc) 4015f5 [unknown] (/usr/bin/bc) 7f5ed6dcb553 __libc_start_main+0xf3 (/usr/lib64/libc-2.17.so) 401698 [unknown] (/usr/bin/bc) Change from v1: - refined code style according to Jiri's review comments. Signed-off-by:
Chengdong Li <chengdongli@tencent.com> Acked-by:
Namhyung Kim <namhyung@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Alexey Bayduraev <alexey.v.bayduraev@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: German Gomez <german.gomez@arm.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Riccardo Mancini <rickyman7@gmail.com> Cc: likexu@tencent.com Link: https://lore.kernel.org/r/20220517015726.96131-1-chengdongli@tencent.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
Athira Rajeev authored
Perf BPF filter test fails in environment where "clang" is not installed. Test failure logs: <<>> 42: BPF filter : 42.1: Basic BPF filtering : Skip 42.2: BPF pinning : FAILED! 42.3: BPF prologue generation : FAILED! <<>> Enabling verbose option provided debug logs which says clang/llvm needs to be installed. Snippet of verbose logs: <<>> 42.2: BPF pinning : --- start --- test child forked, pid 61423 ERROR: unable to find clang. Hint: Try to install latest clang/llvm to support BPF. Check your $PATH <<logs_here>> Failed to compile test case: 'Basic BPF llvm compile' Unable to get BPF object, fix kbuild first test child finished with -1 ---- end ---- BPF filter subtest 2: FAILED! <<>> Here subtests, "BPF pinning" and "BPF prologue generation" failed and logs shows clang/llvm is needed. After installing clang, testcase passes. Reason on why subtest failure happens though logs has proper debug information: Main function __test__bpf calls test_llvm__fetch_bpf_obj by passing 4th argument as true ( 4th arguments maps to parameter "force" in test_llvm__fetch_bpf_obj ). But this will cause test_llvm__fetch_bpf_obj to skip the check for clang/llvm. Snippet of code part which checks for clang based on parameter "force" in test_llvm__fetch_bpf_obj: <<>> if (!force && (!llvm_param.user_set_param && <<>> Since force is set to "false", test won't get skipped and fails to compile test case. The BPF code compilation needs clang, So pass the fourth argument as "false" and also skip the test if reason for return is "TEST_SKIP" After the patch: <<>> 42: BPF filter : 42.1: Basic BPF filtering : Skip 42.2: BPF pinning : Skip 42.3: BPF prologue generation : Skip <<>> Fixes: ba1fae43 ("perf test: Add 'perf test BPF'") Reviewed-by:
Kajol Jain <kjain@linux.ibm.com> Signed-off-by:
Athira Jajeev <atrajeev@linux.vnet.ibm.com> Acked-by:
Ian Rogers <irogers@google.com> Cc: Disha Goel <disgoel@linux.vnet.ibm.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: linuxppc-dev@lists.ozlabs.org Cc: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nageswara R Sastry <rnsastry@linux.ibm.com> Cc: Wang Nan <wangnan0@huawei.com> Link: https://lore.kernel.org/r/20220511115438.84032-1-atrajeev@linux.vnet.ibm.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
Athira Rajeev authored
The session topology test fails in powerpc pSeries platform. Test logs: <<>> Session topology : FAILED! <<>> This testcases tests cpu topology by checking the core_id and socket_id stored in perf_env from perf session. The data from perf session is compared with the cpu topology information from "/sys/devices/system/cpu/cpuX/topology" like core_id, physical_package_id. In case of virtual environment, detail like physical_package_id is restricted to be exposed. Hence physical_package_id is set to -1. The testcase fails on such platforms since socket_id can't be fetched from topology info. Skip the testcase in powerpc if physical_package_id returns -1. Reviewed-by:
Kajol Jain <kjain@linux.ibm.com> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>--- Tested-by:
Disha Goel <disgoel@linux.vnet.ibm.com> Acked-by:
Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nageswara R Sastry <rnsastry@linux.ibm.com> Cc: linuxppc-dev@lists.ozlabs.org Link: https://lore.kernel.org/r/20220511114959.84002-1-atrajeev@linux.vnet.ibm.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
Thomas Richter authored
The compilation on s390 results in this error: # make DEBUG=y bench/numa.o ... bench/numa.c: In function ‘__bench_numa’: bench/numa.c:1749:81: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size between 10 and 20 [-Werror=format-truncation=] 1749 | snprintf(tname, sizeof(tname), "process%d:thread%d", p, t); ^~ ... bench/numa.c:1749:64: note: directive argument in the range [-2147483647, 2147483646] ... # The maximum length of the %d replacement is 11 characters because of the negative sign. Therefore extend the array by two more characters. Output after: # make DEBUG=y bench/numa.o > /dev/null 2>&1; ll bench/numa.o -rw-r--r-- 1 root root 418320 May 19 09:11 bench/numa.o # Fixes: 3aff8ba0 ("perf bench numa: Avoid possible truncation when using snprintf()") Suggested-by:
Namhyung Kim <namhyung@gmail.com> Signed-off-by:
Thomas Richter <tmricht@linux.ibm.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Sumanth Korikkar <sumanthk@linux.ibm.com> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Link: https://lore.kernel.org/r/20220520081158.2990006-1-tmricht@linux.ibm.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
Ian Rogers authored
for_each_shell_test() is already strict in expecting tests to be files and executable. It is sometimes possible when it iterates over all files that it finds one that is executable and lacks a newline character. When this happens the loop never terminates as it doesn't check for EOF. Add the EOF check to make this loop at least bounded by the file size. If the description is returned as NULL then also skip the test. Signed-off-by:
Ian Rogers <irogers@google.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Marco Elver <elver@google.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Riccardo Mancini <rickyman7@gmail.com> Cc: Sohaib Mohamed <sohaib.amhmd@gmail.com> Cc: Stephane Eranian <eranian@google.com> Link: https://lore.kernel.org/r/20220517204144.645913-1-irogers@google.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
Kan Liang authored
The X86 specific arch__intr_reg_mask() is to check whether the kernel and hardware can collect XMM registers. But it doesn't work on some hybrid platform. Without the patch on ADL-N: $ perf record -I? available registers: AX BX CX DX SI DI BP SP IP FLAGS CS SS R8 R9 R10 R11 R12 R13 R14 R15 The config of the test event doesn't contain the PMU information. The kernel may fail to initialize it on the correct hybrid PMU and return the wrong non-supported information. Add the PMU information into the config for the hybrid platform. The same register set is supported among different hybrid PMUs. Checking the first available one is good enough. With the patch on ADL-N: $ perf record -I? available registers: AX BX CX DX SI DI BP SP IP FLAGS CS SS R8 R9 R10 R11 R12 R13 R14 R15 XMM0 XMM1 XMM2 XMM3 XMM4 XMM5 XMM6 XMM7 XMM8 XMM9 XMM10 XMM11 XMM12 XMM13 XMM14 XMM15 Fixes: 6466ec14 ("perf regs x86: Add X86 specific arch__intr_reg_mask()") Reported-by:
Ammy Yi <ammy.yi@intel.com> Signed-off-by:
Kan Liang <kan.liang@linux.intel.com> Acked-by:
Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Xing Zhengjun <zhengjun.xing@linux.intel.com> Link: https://lore.kernel.org/r/20220518145125.1494156-1-kan.liang@linux.intel.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
Athira Rajeev authored
"perf all PMU test" picks the input events from "perf list --raw-dump pmu" list and runs "perf stat -e" for each of the event in the list. In case of powerpc, the PowerVM environment supports events from hv_24x7 and hv_gpci PMU which is of example format like below: - hv_24x7/CPM_ADJUNCT_INST,domain=?,core=?/ - hv_gpci/event,partition_id=?/ The value for "?" needs to be filled in depending on system and respective event. CPM_ADJUNCT_INST needs have core value and domain value. hv_gpci event needs partition_id. Similarly, there are other events for hv_24x7 and hv_gpci having "?" in event format. Hence skip these events on powerpc platform since values like partition_id, domain is specific to system and event. Fixes: 3d5ac9ef ("perf test: Workload test of all PMUs") Signed-off-by:
Athira Jajeev <atrajeev@linux.vnet.ibm.com> Acked-by:
Ian Rogers <irogers@google.com> Cc: Disha Goel <disgoel@linux.vnet.ibm.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kajol Jain <kjain@linux.ibm.com> Cc: linuxppc-dev@lists.ozlabs.org Cc: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nageswara R Sastry <rnsastry@linux.ibm.com> Link: https://lore.kernel.org/r/20220520101236.17249-1-atrajeev@linux.vnet.ibm.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
Piyush Malgujar authored
Due to i2c->adap.dev.fwnode not being set, ACPI_COMPANION() wasn't properly found for TWSI controllers. Signed-off-by:
Szymon Balcerak <sbalcerak@marvell.com> Signed-off-by:
Piyush Malgujar <pmalgujar@marvell.com> Signed-off-by:
Wolfram Sang <wsa@kernel.org>
-
Mika Westerberg authored
Before sending a MSI the hardware writes information pertinent to the interrupt cause to a memory location pointed by SMTICL register. This memory holds three double words where the least significant bit tells whether the interrupt cause of master/target/error is valid. The driver does not use this but we need to set it up because otherwise it will perform DMA write to the default address (0) and this will cause an IOMMU fault such as below: DMAR: DRHD: handling fault status reg 2 DMAR: [DMA Write] Request device [00:12.0] PASID ffffffff fault addr 0 [fault reason 05] PTE Write access is not set To prevent this from happening, provide a proper DMA buffer for this that then gets mapped by the IOMMU accordingly. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by:
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Wolfram Sang <wsa@kernel.org>
-
Yang Yingliang authored
Fix the missing clk_disable_unprepare() before return from mtk_i2c_probe() in the error handling case. Fixes: d04913ec ("i2c: mt7621: Add MediaTek MT7621/7628/7688 I2C driver") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Stefan Roese <sr@denx.de> Signed-off-by:
Wolfram Sang <wsa@kernel.org>
-
git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds authored
Pull kvm fixes from Paolo Bonzini: "ARM: - Correctly expose GICv3 support even if no irqchip is created so that userspace doesn't observe it changing pointlessly (fixing a regression with QEMU) - Don't issue a hypercall to set the id-mapped vectors when protected mode is enabled (fix for pKVM in combination with CPUs affected by Spectre-v3a) x86 (five oneliners, of which the most interesting two are): - a NULL pointer dereference on INVPCID executed with paging disabled, but only if KVM is using shadow paging - an incorrect bsearch comparison function which could truncate the result and apply PMU event filtering incorrectly. This one comes with a selftests update too" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID KVM: x86: hyper-v: fix type of valid_bank_mask KVM: Free new dirty bitmap if creating a new memslot fails KVM: eventfd: Fix false positive RCU usage warning selftests: kvm/x86: Verify the pmu event filter matches the correct event selftests: kvm/x86: Add the helper function create_pmu_event_filter kvm: x86/pmu: Fix the compare function used by the pmu event filter KVM: arm64: Don't hypercall before EL2 init KVM: arm64: vgic-v3: Consistently populate ID_AA64PFR0_EL1.GIC KVM: x86/mmu: Update number of zapped pages even if page list is stable
-
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linuxLinus Torvalds authored
Pull clk fixes from Stephen Boyd: "Three clk driver fixes to close out the release - Fix a divider calculation breaking boot on Broadcom bcm2835 - Fix HDMI output on Tanix TX6 mini board by reverting a patch - Fix clk_set_rate_range() calls on at91 by considering the range while calculating the divisor" * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: clk: at91: generated: consider range when calculating best rate Revert "clk: sunxi-ng: sun6i-rtc: Add support for H6" clk: bcm2835: fix bcm2835_clock_choose_div
-
git://anongit.freedesktop.org/drm/drmLinus Torvalds authored
Pull drm fixes from Dave Airlie: "Few final fixes for 5.18, one amdgpu, core dp mst leak fix, dma-buf two fixes, and i915 has a few fixes, one for a regression on older GM45 chipsets, dma-buf: - ioctl userspace use fix - fix dma-buf sysfs name generation core: - dp/mst leak fix amdgpu: - suspend/resume regression fix i915: - fix for #5806: GPU hangs and display artifacts on Intel GM45 - reject DMC with out-of-spec MMIO - correctly mark guilty contexts on GuC reset" * tag 'drm-fixes-2022-05-21' of git://anongit.freedesktop.org/drm/drm: drm/i915: Use i915_gem_object_ggtt_pin_ww for reloc_iomap drm/amd: Don't reset dGPUs if the system is going to s2idle drm/dp/mst: fix a possible memory leak in fetch_monitor_name() dma-buf: fix use of DMA_BUF_SET_NAME_{A,B} in userspace i915/guc/reset: Make __guc_reset_context aware of guilty engines drm/i915/dmc: Add MMIO range restrictions dma-buf: ensure unique directory name for dmabuf stats
-
- 20 May, 2022 4 commits
-
-
Dave Airlie authored
Merge tag 'drm-intel-fixes-2022-05-20' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - fix for #5806: GPU hangs and display artifacts on 5.18-rc3 on Intel GM45 - reject DMC with out-of-spec MMIO (Cc: stable) - correctly mark guilty contexts on GuC reset. Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/YocqqvG6PbYx3QgJ@jlahtine-mobl.ger.corp.intel.com
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
Fix for a memory leak in dp_mst, a (userspace) build fix for DMA_BUF_SET_NAME defines and a directory name generation fix for dmabuf stats Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220520072408.cpjzy2taugagvrh7@houat
-
Peter Zijlstra authored
Norbert reported that it's possible to race sys_perf_event_open() such that the looser ends up in another context from the group leader, triggering many WARNs. The move_group case checks for races against itself, but the !move_group case doesn't, seemingly relying on the previous group_leader->ctx == ctx check. However, that check is racy due to not holding any locks at that time. Therefore, re-check the result after acquiring locks and bailing if they no longer match. Additionally, clarify the not_move_group case from the move_group-vs-move_group race. Fixes: f63a8daa ("perf: Fix event->ctx locking") Reported-by:
Norbert Slusarek <nslusarek@gmx.net> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linuxLinus Torvalds authored
Pull gpio fixes from Bartosz Golaszewski: - fix bitops logic in gpio-vf610 - return an error if the user tries to use inverted polarity in gpio-mvebu * tag 'gpio-fixes-for-v5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpio: mvebu/pwm: Refuse requests with inverted polarity gpio: gpio-vf610: do not touch other bits when set the target bit
-