- 04 Apr, 2023 1 commit
-
-
Roberto Sassu authored
Reiserfs sets a security xattr at inode creation time in two stages: first, it calls reiserfs_security_init() to obtain the xattr from active LSMs; then, it calls reiserfs_security_write() to actually write that xattr. Unfortunately, it seems there is a wrong expectation that LSMs provide the full xattr name in the form 'security.<suffix>'. However, LSMs always provided just the suffix, causing reiserfs to not write the xattr at all (if the suffix is shorter than the prefix), or to write an xattr with the wrong name. Add a temporary buffer in reiserfs_security_write(), and write to it the full xattr name, before passing it to reiserfs_xattr_set_handle(). Also replace the name length check with a check that the full xattr name is not larger than XATTR_NAME_MAX. Cc: stable@vger.kernel.org # v2.6.x Fixes: 57fe60df ("reiserfs: add atomic addition of selinux attributes during inode creation") Signed-off-by:
Roberto Sassu <roberto.sassu@huawei.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
- 23 Mar, 2023 3 commits
-
-
Roberto Sassu authored
As the remaining two users reiserfs and ocfs2 switched to security_inode_init_security(), security_old_inode_init_security() can be now removed. Out-of-tree kernel modules should switch to security_inode_init_security() too. Signed-off-by:
Roberto Sassu <roberto.sassu@huawei.com> Reviewed-by:
Casey Schaufler <casey@schaufler-ca.com> Reviewed-by:
Mimi Zohar <zohar@linux.ibm.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Roberto Sassu authored
In preparation for removing security_old_inode_init_security(), switch to security_inode_init_security(). Extend the existing ocfs2_initxattrs() to take the ocfs2_security_xattr_info structure from fs_info, and populate the name/value/len triple with the first xattr provided by LSMs. As fs_info was not used before, ocfs2_initxattrs() can now handle the case of replicating the behavior of security_old_inode_init_security(), i.e. just obtaining the xattr, in addition to setting all xattrs provided by LSMs. Supporting multiple xattrs is not currently supported where security_old_inode_init_security() was called (mknod, symlink), as it requires non-trivial changes that can be done at a later time. Like for reiserfs, even if EVM is invoked, it will not provide an xattr (if it is not the first to set it, its xattr will be discarded; if it is the first, it does not have xattrs to calculate the HMAC on). Finally, since security_inode_init_security(), unlike security_old_inode_init_security(), returns zero instead of -EOPNOTSUPP if no xattrs were provided by LSMs or if inodes are private, additionally check in ocfs2_init_security_get() if the xattr name is set. If not, act as if security_old_inode_init_security() returned -EOPNOTSUPP, and set si->enable to zero to notify to the functions following ocfs2_init_security_get() that no xattrs are available. Signed-off-by:
Roberto Sassu <roberto.sassu@huawei.com> Reviewed-by:
Casey Schaufler <casey@schaufler-ca.com> Acked-by:
Joseph Qi <joseph.qi@linux.alibaba.com> Reviewed-by:
Mimi Zohar <zohar@linux.ibm.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Roberto Sassu authored
In preparation for removing security_old_inode_init_security(), switch to security_inode_init_security(). Commit 572302af ("reiserfs: Add missing calls to reiserfs_security_free()") fixed possible memory leaks and another issue related to adding an xattr at inode creation time. Define the initxattrs callback reiserfs_initxattrs(), to populate the name/value/len triple in the reiserfs_security_handle() with the first xattr provided by LSMs. Make a copy of the xattr value, as security_inode_init_security() frees it. After the call to security_inode_init_security(), remove the check for returning -EOPNOTSUPP, as security_inode_init_security() changes it to zero. Multiple xattrs are currently not supported, as the reiserfs_security_handle structure is exported to user space. As a consequence, even if EVM is invoked, it will not provide an xattr (if it is not the first to set it, its xattr will be discarded; if it is the first, it does not have xattrs to calculate the HMAC on). Signed-off-by:
Roberto Sassu <roberto.sassu@huawei.com> Reviewed-by:
Casey Schaufler <casey@schaufler-ca.com> Reviewed-by:
Mimi Zohar <zohar@linux.ibm.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
- 10 Mar, 2023 3 commits
-
-
Roberto Sassu authored
Remove 'integrity' from the list of LSMs in Kconfig, as it is no longer necessary. Since the recent change (set order to LSM_ORDER_LAST), the 'integrity' LSM is always enabled (if selected in the kernel configuration). Signed-off-by:
Roberto Sassu <roberto.sassu@huawei.com> Acked-by:
Mimi Zohar <zohar@linux.ibm.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Roberto Sassu authored
With the recent introduction of LSM_ORDER_LAST, the 'integrity' LSM is always initialized (if selected in the kernel configuration) and the iint_cache is always created (the kernel panics on error). Thus, the additional check of iint_cache in integrity_inode_get() is no longer necessary. If the 'integrity' LSM is not selected in the kernel configuration, integrity_inode_get() just returns NULL. This reverts commit 92063f3c. Signed-off-by:
Roberto Sassu <roberto.sassu@huawei.com> Acked-by:
Mimi Zohar <zohar@linux.ibm.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Roberto Sassu authored
Introduce LSM_ORDER_LAST, to satisfy the requirement of LSMs needing to be last, e.g. the 'integrity' LSM, without changing the kernel command line or configuration. Also, set this order for the 'integrity' LSM. While not enforced, this is the only LSM expected to use it. Similarly to LSM_ORDER_FIRST, LSMs with LSM_ORDER_LAST are always enabled and put at the end of the LSM list, if selected in the kernel configuration. Setting one of these orders alone, does not cause the LSMs to be selected and compiled built-in in the kernel. Finally, for LSM_ORDER_MUTABLE LSMs, set the found variable to true if an LSM is found, regardless of its order. In this way, the kernel would not wrongly report that the LSM is not built-in in the kernel if its order is LSM_ORDER_LAST. Fixes: 79f7865d ("LSM: Introduce "lsm=" for boottime LSM selection") Signed-off-by:
Roberto Sassu <roberto.sassu@huawei.com> Acked-by:
Mimi Zohar <zohar@linux.ibm.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
- 08 Mar, 2023 3 commits
-
-
Kamalesh Babulal authored
Fix the stale cgroup.c path in the devcgroup_css_alloc() description. Signed-off-by:
Kamalesh Babulal <kamalesh.babulal@oracle.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
There is no good reason for why the "_buffer" parameter needs an underscore, get rid of it. Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
- 06 Mar, 2023 22 commits
-
-
Paul Moore authored
As we were already making massive changes to security/security.c by moving all of the function header comments above the function definitions, let's take the opportunity to fix various style crimes. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
This patch relocates the LSM hook function comments to the function definitions, in keeping with the current kernel conventions. This should make the hook descriptions more easily discoverable and easier to maintain. While formatting changes have been done to better fit the kernel-doc style, content changes have been kept to a minimum and limited to text which was obviously incorrect and/or outdated. It is expected the future patches will improve the quality of the function header comments. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
This patch relocates the LSM hook function comments to the function definitions, in keeping with the current kernel conventions. This should make the hook descriptions more easily discoverable and easier to maintain. While formatting changes have been done to better fit the kernel-doc style, content changes have been kept to a minimum and limited to text which was obviously incorrect and/or outdated. It is expected the future patches will improve the quality of the function header comments. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
This patch relocates the LSM hook function comments to the function definitions, in keeping with the current kernel conventions. This should make the hook descriptions more easily discoverable and easier to maintain. While formatting changes have been done to better fit the kernel-doc style, content changes have been kept to a minimum and limited to text which was obviously incorrect and/or outdated. It is expected the future patches will improve the quality of the function header comments. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
This patch relocates the LSM hook function comments to the function definitions, in keeping with the current kernel conventions. This should make the hook descriptions more easily discoverable and easier to maintain. While formatting changes have been done to better fit the kernel-doc style, content changes have been kept to a minimum and limited to text which was obviously incorrect and/or outdated. It is expected the future patches will improve the quality of the function header comments. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
This patch relocates the LSM hook function comments to the function definitions, in keeping with the current kernel conventions. This should make the hook descriptions more easily discoverable and easier to maintain. While formatting changes have been done to better fit the kernel-doc style, content changes have been kept to a minimum and limited to text which was obviously incorrect and/or outdated. It is expected the future patches will improve the quality of the function header comments. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
This patch relocates the LSM hook function comments to the function definitions, in keeping with the current kernel conventions. This should make the hook descriptions more easily discoverable and easier to maintain. While formatting changes have been done to better fit the kernel-doc style, content changes have been kept to a minimum and limited to text which was obviously incorrect and/or outdated. It is expected the future patches will improve the quality of the function header comments. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
This patch relocates the LSM hook function comments to the function definitions, in keeping with the current kernel conventions. This should make the hook descriptions more easily discoverable and easier to maintain. While formatting changes have been done to better fit the kernel-doc style, content changes have been kept to a minimum and limited to text which was obviously incorrect and/or outdated. It is expected the future patches will improve the quality of the function header comments. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
This patch relocates the LSM hook function comments to the function definitions, in keeping with the current kernel conventions. This should make the hook descriptions more easily discoverable and easier to maintain. While formatting changes have been done to better fit the kernel-doc style, content changes have been kept to a minimum and limited to text which was obviously incorrect and/or outdated. It is expected the future patches will improve the quality of the function header comments. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
This patch relocates the LSM hook function comments to the function definitions, in keeping with the current kernel conventions. This should make the hook descriptions more easily discoverable and easier to maintain. While formatting changes have been done to better fit the kernel-doc style, content changes have been kept to a minimum and limited to text which was obviously incorrect and/or outdated. It is expected the future patches will improve the quality of the function header comments. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
This patch relocates the LSM hook function comments to the function definitions, in keeping with the current kernel conventions. This should make the hook descriptions more easily discoverable and easier to maintain. While formatting changes have been done to better fit the kernel-doc style, content changes have been kept to a minimum and limited to text which was obviously incorrect and/or outdated. It is expected the future patches will improve the quality of the function header comments. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
This patch relocates the LSM hook function comments to the function definitions, in keeping with the current kernel conventions. This should make the hook descriptions more easily discoverable and easier to maintain. While formatting changes have been done to better fit the kernel-doc style, content changes have been kept to a minimum and limited to text which was obviously incorrect and/or outdated. It is expected the future patches will improve the quality of the function header comments. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
This patch relocates the LSM hook function comments to the function definitions, in keeping with the current kernel conventions. This should make the hook descriptions more easily discoverable and easier to maintain. While formatting changes have been done to better fit the kernel-doc style, content changes have been kept to a minimum and limited to text which was obviously incorrect and/or outdated. It is expected the future patches will improve the quality of the function header comments. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
This patch relocates the LSM hook function comments to the function definitions, in keeping with the current kernel conventions. This should make the hook descriptions more easily discoverable and easier to maintain. While formatting changes have been done to better fit the kernel-doc style, content changes have been kept to a minimum and limited to text which was obviously incorrect and/or outdated. It is expected the future patches will improve the quality of the function header comments. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
This patch relocates the LSM hook function comments to the function definitions, in keeping with the current kernel conventions. This should make the hook descriptions more easily discoverable and easier to maintain. While formatting changes have been done to better fit the kernel-doc style, content changes have been kept to a minimum and limited to text which was obviously incorrect and/or outdated. It is expected the future patches will improve the quality of the function header comments. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
This patch relocates the LSM hook function comments to the function definitions, in keeping with the current kernel conventions. This should make the hook descriptions more easily discoverable and easier to maintain. While formatting changes have been done to better fit the kernel-doc style, content changes have been kept to a minimum and limited to text which was obviously incorrect and/or outdated. It is expected the future patches will improve the quality of the function header comments. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
This patch relocates the LSM hook function comments to the function definitions, in keeping with the current kernel conventions. This should make the hook descriptions more easily discoverable and easier to maintain. While formatting changes have been done to better fit the kernel-doc style, content changes have been kept to a minimum and limited to text which was obviously incorrect and/or outdated. It is expected the future patches will improve the quality of the function header comments. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
This patch relocates the LSM hook function comments to the function definitions, in keeping with the current kernel conventions. This should make the hook descriptions more easily discoverable and easier to maintain. While formatting changes have been done to better fit the kernel-doc style, content changes have been kept to a minimum and limited to text which was obviously incorrect and/or outdated. It is expected the future patches will improve the quality of the function header comments. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
This patch relocates the LSM hook function comments to the function definitions, in keeping with the current kernel conventions. This should make the hook descriptions more easily discoverable and easier to maintain. While formatting changes have been done to better fit the kernel-doc style, content changes have been kept to a minimum and limited to text which was obviously incorrect and/or outdated. It is expected the future patches will improve the quality of the function header comments. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
This patch relocates the LSM hook function comments to the function definitions, in keeping with the current kernel conventions. This should make the hook descriptions more easily discoverable and easier to maintain. While formatting changes have been done to better fit the kernel-doc style, content changes have been kept to a minimum and limited to text which was obviously incorrect and/or outdated. It is expected the future patches will improve the quality of the function header comments. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
This patch relocates the LSM hook function comments to the function definitions, in keeping with the current kernel conventions. This should make the hook descriptions more easily discoverable and easier to maintain. While formatting changes have been done to better fit the kernel-doc style, content changes have been kept to a minimum and limited to text which was obviously incorrect and/or outdated. It is expected the future patches will improve the quality of the function header comments. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
Paul Moore authored
This patch relocates the LSM hook function comments to the function definitions, in keeping with the current kernel conventions. This should make the hook descriptions more easily discoverable and easier to maintain. While formatting changes have been done to better fit the kernel-doc style, content changes have been kept to a minimum and limited to text which was obviously incorrect and/or outdated. It is expected the future patches will improve the quality of the function header comments. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
- 05 Mar, 2023 8 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
Commit aa47a7c2 ("lib/cpumask: deprecate nr_cpumask_bits") resulted in the cpumask operations potentially becoming hugely less efficient, because suddenly the cpumask was always considered to be variable-sized. The optimization was then later added back in a limited form by commit 6f9c07be ("lib/cpumask: add FORCE_NR_CPUS config option"), but that FORCE_NR_CPUS option is not useful in a generic kernel and more of a special case for embedded situations with fixed hardware. Instead, just re-introduce the optimization, with some changes. Instead of depending on CPUMASK_OFFSTACK being false, and then always using the full constant cpumask width, this introduces three different cpumask "sizes": - the exact size (nr_cpumask_bits) remains identical to nr_cpu_ids. This is used for situations where we should use the exact size. - the "small" size (small_cpumask_bits) is the NR_CPUS constant if it fits in a single word and the bitmap operations thus end up able to trigger the "small_const_nbits()" optimizations. This is used for the operations that have optimized single-word cases that get inlined, notably the bit find and scanning functions. - the "large" size (large_cpumask_bits) is the NR_CPUS constant if it is an sufficiently small constant that makes simple "copy" and "clear" operations more efficient. This is arbitrarily set at four words or less. As a an example of this situation, without this fixed size optimization, cpumask_clear() will generate code like movl nr_cpu_ids(%rip), %edx addq $63, %rdx shrq $3, %rdx andl $-8, %edx callq memset@PLT on x86-64, because it would calculate the "exact" number of longwords that need to be cleared. In contrast, with this patch, using a MAX_CPU of 64 (which is quite a reasonable value to use), the above becomes a single movq $0,cpumask instruction instead, because instead of caring to figure out exactly how many CPU's the system has, it just knows that the cpumask will be a single word and can just clear it all. Note that this does end up tightening the rules a bit from the original version in another way: operations that set bits in the cpumask are now limited to the actual nr_cpu_ids limit, whereas we used to do the nr_cpumask_bits thing almost everywhere in the cpumask code. But if you just clear bits, or scan for bits, we can use the simpler compile-time constants. In the process, remove 'cpumask_complement()' and 'for_each_cpu_not()' which were not useful, and which fundamentally have to be limited to 'nr_cpu_ids'. Better remove them now than have somebody introduce use of them later. Of course, on x86-64 with MAXSMP there is no sane small compile-time constant for the cpumask sizes, and we end up using the actual CPU bits, and will generate the above kind of horrors regardless. Please don't use MAXSMP unless you really expect to have machines with thousands of cores. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Linus Torvalds authored
Pull crypto fix from Herbert Xu: "Fix a regression in the caam driver" * tag 'v6.3-p2' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: caam - Fix edesc/iv ordering mixup
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 updates from Thomas Gleixner: "A small set of updates for x86: - Return -EIO instead of success when the certificate buffer for SEV guests is not large enough - Allow STIPB to be enabled with legacy IBSR. Legacy IBRS is cleared on return to userspace for performance reasons, but the leaves user space vulnerable to cross-thread attacks which STIBP prevents. Update the documentation accordingly" * tag 'x86-urgent-2023-03-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: virt/sev-guest: Return -EIO if certificate buffer is not large enough Documentation/hw-vuln: Document the interaction between IBRS and STIBP x86/speculation: Allow enabling STIBP with legacy IBRS
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irq updates from Thomas Gleixner: "A set of updates for the interrupt susbsystem: - Prevent possible NULL pointer derefences in irq_data_get_affinity_mask() and irq_domain_create_hierarchy() - Take the per device MSI lock before invoking code which relies on it being hold - Make sure that MSI descriptors are unreferenced before freeing them. This was overlooked when the platform MSI code was converted to use core infrastructure and results in a fals positive warning - Remove dead code in the MSI subsystem - Clarify the documentation for pci_msix_free_irq() - More kobj_type constification" * tag 'irq-urgent-2023-03-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: genirq/msi, platform-msi: Ensure that MSI descriptors are unreferenced genirq/msi: Drop dead domain name assignment irqdomain: Add missing NULL pointer check in irq_domain_create_hierarchy() genirq/irqdesc: Make kobj_type structures constant PCI/MSI: Clarify usage of pci_msix_free_irq() genirq/msi: Take the per-device MSI lock before validating the control structure genirq/ipi: Fix NULL pointer deref in irq_data_get_affinity_mask()
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull vfs update from Al Viro: "Adding Christian Brauner as VFS co-maintainer" * tag 'pull-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: Adding VFS co-maintainer
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull VM_FAULT_RETRY fixes from Al Viro: "Some of the page fault handlers do not deal with the following case correctly: - handle_mm_fault() has returned VM_FAULT_RETRY - there is a pending fatal signal - fault had happened in kernel mode Correct action in such case is not "return unconditionally" - fatal signals are handled only upon return to userland and something like copy_to_user() would end up retrying the faulting instruction and triggering the same fault again and again. What we need to do in such case is to make the caller to treat that as failed uaccess attempt - handle exception if there is an exception handler for faulting instruction or oops if there isn't one. Over the years some architectures had been fixed and now are handling that case properly; some still do not. This series should fix the remaining ones. Status: - m68k, riscv, hexagon, parisc: tested/acked by maintainers. - alpha, sparc32, sparc64: tested locally - bug has been reproduced on the unpatched kernel and verified to be fixed by this series. - ia64, microblaze, nios2, openrisc: build, but otherwise completely untested" * tag 'pull-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: openrisc: fix livelock in uaccess nios2: fix livelock in uaccess microblaze: fix livelock in uaccess ia64: fix livelock in uaccess sparc: fix livelock in uaccess alpha: fix livelock in uaccess parisc: fix livelock in uaccess hexagon: fix livelock in uaccess riscv: fix livelock in uaccess m68k: fix livelock in uaccess
-
Masahiro Yamada authored
include/linux/compiler-intel.h had no update in the past 3 years. We often forget about the third C compiler to build the kernel. For example, commit a0a12c3e ("asm goto: eradicate CC_HAS_ASM_GOTO") only mentioned GCC and Clang. init/Kconfig defines CC_IS_GCC and CC_IS_CLANG but not CC_IS_ICC, and nobody has reported any issue. I guess the Intel Compiler support is broken, and nobody is caring about it. Harald Arnesen pointed out ICC (classic Intel C/C++ compiler) is deprecated: $ icc -v icc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is deprecated and will be removed from product release in the second half of 2023. The Intel(R) oneAPI DPC++/C++ Compiler (ICX) is the recommended compiler moving forward. Please transition to use this compiler. Use '-diag-disable=10441' to disable this message. icc version 2021.7.0 (gcc version 12.1.0 compatibility) Arnd Bergmann provided a link to the article, "Intel C/C++ compilers complete adoption of LLVM". lib/zstd/common/compiler.h and lib/zstd/compress/zstd_fast.c were kept untouched for better sync with https://github.com/facebook/zstd Link: https://www.intel.com/content/www/us/en/developer/articles/technical/adoption-of-llvm-complete-icx.htmlSigned-off-by:
Masahiro Yamada <masahiroy@kernel.org> Acked-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Reviewed-by:
Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Miguel Ojeda <ojeda@kernel.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-