- May 26, 2021
-
-
Qiuxu Zhuo authoredmainline inclusion from mainline-v4.20-rc1 commit 93ac5754 category: feature bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=44 CVE: NA ----------------------------------------------- Current coding style is to use the BIT_ULL() macro. [ bp: Align the MCG_STATUS defines vertically too. ] Signed-off-by:
Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Aristeu Rozanski <aris@redhat.com>
Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Cc: linux-edac@vger.kernel.org
Cc: x86@kernel.org
Link: https://lkml.kernel.org/r/20180925000127.GA5998@agluck-desk
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
Reviewed-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Fenghua Yu authored
mainline inclusion from mainline-v5.3-rc1 commit b302e4b1 category: feature bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=44 CVE: NA ----------------------------------------------- AVX512 BFLOAT16 instructions support 16-bit BFLOAT16 floating-point format (BF16) for deep learning optimization. BF16 is a short version of 32-bit single-precision floating-point format (FP32) and has several advantages over 16-bit half-precision floating-point format (FP16). BF16 keeps FP32 accumulation after multiplication without loss of precision, offers more than enough range for deep learning training tasks, and doesn't need to handle hardware exception. AVX512 BFLOAT16 instructions are enumerated in CPUID.7.1:EAX[bit 5] AVX512_BF16. CPUID.7.1:EAX contains only feature bits. Reuse the currently empty word 12 as a pure features word to hold the feature bits including AVX512_BF16. Detailed information of the CPUID bit and AVX512 BFLOAT16 instructions can be found in the latest Intel Architecture Instruction Set Extensions and Future Features Programming Reference. [ bp: Check CPUID(7) subleaf validity before accessing subleaf 1. ] Signed-off-by:
Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "Chang S. Bae" <chang.seok.bae@intel.com>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jann Horn <jannh@google.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nadav Amit <namit@vmware.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Pavel Tatashin <pasha.tatashin@oracle.com>
Cc: Peter Feiner <pfeiner@google.com>
Cc: Radim Krcmar <rkrcmar@redhat.com>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Cc: "Ravi V Shankar" <ravi.v.shankar@intel.com>
Cc: Robert Hoo <robert.hu@linux.intel.com>
Cc: "Sean J Christopherson" <sean.j.christopherson@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Thomas Lendacky <Thomas.Lendacky@amd.com>
Cc: x86 <x86@kernel.org>
Link: https://lkml.kernel.org/r/1560794416-217638-3-git-send-email-fenghua.yu@intel.com
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
Reviewed-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Yang Yingliang authored
mainline inclusion from mainline-v5.13-rc3 commit 4d1cd3b2c5c1c32826454de3a18c6183238d47ed category: bugfix bugzilla: NA CVE: NA ------------------------------------------------- Fix the link error by adding '-static': gcc -Wall -Wl,-z,max-page-size=0x1000 -pie load_address.c -o /home/yang/linux/tools/testing/selftests/exec/load_address_4096 /usr/bin/ld: /tmp/ccopEGun.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `stderr@@GLIBC_2.17' which may bind externally can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /tmp/ccopEGun.o(.text+0x158): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol `stderr@@GLIBC_2.17' /usr/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status make: *** [Makefile:25: tools/testing/selftests/exec/load_address_4096] Error 1 Link: https://lkml.kernel.org/r/20210514092422.2367367-1-yangyingliang@huawei.com Fixes: 206e22f0 ("tools/testing/selftests: add self-test for verifying load alignment") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
Cc: Chris Kennelly <ckennelly@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Jian Cheng <cj.chengjian@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Trond Myklebust authored
mainline inclusion from mainline-v5.5-rc1 commit e6237b6f category: bugfix bugzilla: NA CVE: NA -------------------------------- NFSv2, v3 and NFSv4 servers often have duplicate replay caches that look at the source port when deciding whether or not an RPC call is a replay of a previous call. This requires clients to perform strange TCP gymnastics in order to ensure that when they reconnect to the server, they bind to the same source port. NFSv4.1 and NFSv4.2 have sessions that provide proper replay semantics, that do not look at the source port of the connection. This patch therefore ensures they can ignore the rebind requirement. Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com>
Conflicts:
fs/lockd/host.c
fs/nfs/client.c
fs/nfs/nfs4client.c
include/linux/nfs_fs_sb.h
include/linux/sunrpc/clnt.h
Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Reviewed-by: Yue Haibin... -
Thomas Gleixner authored
mainline inclusion from mainline-5.7 commit da90921a category: bugfix bugzilla: NA CVE: NA ------------------------------------------------- The code sets IRQS_REPLAY unconditionally whether the resend happens or not. That doesn't have bad side effects right now, but inconsistent state is always a latent source of problems. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
Acked-by: Marc Zyngier <maz@kernel.org>
Link: https://lkml.kernel.org/r/20200306130623.882129117@linutronix.de
Signed-off-by: Liao Chang <liaochang1@huawei.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Thomas Gleixner authored
mainline inclusion from mainline-5.7 commit 1f85b1f5 category: bugfix bugzilla: NA CVE: NA ------------------------------------------------- In preparation for an interrupt injection interface which can be used safely by error injection mechanisms. e.g. PCI-E/ AER, add a return value to check_irq_resend() so errors can be propagated to the caller. Split out the software resend code so the ugly #ifdef in check_irq_resend() goes away and the whole thing becomes readable. Fix up the caller in debugfs. The caller in irq_startup() does not care about the return value as this is unconditionally invoked for all interrupts and the resend is best effort anyway. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
Acked-by: Marc Zyngier <maz@kernel.org>
Link: https://lkml.kernel.org/r/20200306130623.775200917@linutronix.de
Signed-off-by: Liao Chang <liaochang1@huawei.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
-
- May 24, 2021
-
-
Valentin Schneider authored
mainline inclusion from mainline-5.10 commit 1b57d91b category: bugfix bugzilla: NA CVE: NA ------------------------------------------------- The GIC irqchips can now use a HW resend when a retrigger is invoked by check_irq_resend(). However, should the HW resend fail, check_irq_resend() will still attempt to trigger a SW resend, which is still a bad idea for the GICs. Prevent this from happening by setting IRQD_HANDLE_ENFORCE_IRQCTX on all GIC IRQs. Technically per-cpu IRQs do not need this, as their flow handlers never set IRQS_PENDING, but this aligns all IRQs wrt context enforcement: this also forces all GIC IRQ handling to happen in IRQ context (as defined by in_irq()). Signed-off-by:
Valentin Schneider <valentin.schneider@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200730170321.31228-3-valentin.schneider@arm.com
Signed-off-by: Liao Chang <liaochang1@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Marc Zyngier authored
mainline inclusion from mainline-5.10 commit 5f774f5e category: bugfix bugzilla: NA CVE: NA ------------------------------------------------- It is pretty easy to provide a retrigger callback for the ITS, as it we already have the required support in terms of irq_set_irqchip_state(). Note that this only works for device-generated LPIs, and not the GICv4 doorbells, which should never have to be retriggered anyway. Reviewed-by:
Valentin Schneider <valentin.schneider@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Liao Chang <liaochang1@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Valentin Schneider authored
mainline inclusion from mainline-5.10 commit 17f644e9 category: bugfix bugzilla: NA CVE: NA ------------------------------------------------- While digging around IRQCHIP_EOI_IF_HANDLED and irq/resend.c, it has come to my attention that the IRQ resend situation seems a bit precarious for the GIC(s). When marking an IRQ with IRQS_PENDING, handle_fasteoi_irq() will bail out and issue an irq_eoi(). Should the IRQ in question be re-enabled, check_irq_resend() will trigger a SW resend, which will go through the flow handler again and issue *another* irq_eoi() on the *same* IRQ activation. This is something the GIC spec clearly describes as a bad idea: any EOI must match a previous ACK. Implement irq_chip.irq_retrigger() for the GIC chips by setting the GIC pending bit of the relevant IRQ. After being called by check_irq_resend(), this will eventually trigger a *new* interrupt which we will handle as usual. Signed-off-by:
Valentin Schneider <valentin.schneider@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200730170321.31228-2-valentin.schneider@arm.com
Signed-off-by: Liao Chang <liaochang1@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Marc Zyngier authored
mainline inclusion from mainline-5.10 commit cd1752d3 category: bugfix bugzilla: NA CVE: NA ------------------------------------------------- On resending an interrupt, we only check the outermost irqchip for a irq_retrigger callback. However, this callback could be implemented at an inner level. Use irq_chip_retrigger_hierarchy() in this case. Reviewed-by:
Valentin Schneider <valentin.schneider@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Liao Chang <liaochang1@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Thomas Gleixner authored
mainline inclusion from mainline-5.7 commit c16816ac category: bugfix bugzilla: NA CVE: NA ------------------------------------------------- In general calling generic_handle_irq() with interrupts disabled from non interrupt context is harmless. For some interrupt controllers like the x86 trainwrecks this is outright dangerous as it might corrupt state if an interrupt affinity change is pending. Add infrastructure which allows to mark interrupts as unsafe and catch such usage in generic_handle_irq(). Reported-by:
<sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Marc Zyngier <maz@kernel.org>
Link: https://lkml.kernel.org/r/20200306130623.590923677@linutronix.de
Signed-off-by: Liao Chang <liaochang1@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Zhang Yi authored
hulk inclusion category: bugfix bugzilla: 50788 CVE: NA --------------------------- Now that we can be sure the journal is aborted once a buffer has failed to be written back to disk, we can remove the journal abort logic in jbd2_journal_try_to_free_buffers() which was introduced in c044f3d8 ("jbd2: abort journal if free a async write error metadata buffer"), because it may cost and propably is not safe. Signed-off-by:
Zhang Yi <yi.zhang@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Reviewed-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Zhang Yi authored
hulk inclusion category: bugfix bugzilla: 50788 CVE: NA --------------------------- Although we merged c044f3d8 ("jbd2: abort journal if free a async write error metadata buffer"), there is a race between jbd2_journal_try_to_free_buffers() and jbd2_journal_destroy(), so the jbd2_log_do_checkpoint() may still fail to detect the buffer write io error flag which may lead to filesystem inconsistency. jbd2_journal_try_to_free_buffers() ext4_put_super() jbd2_journal_destroy() __jbd2_journal_remove_checkpoint() detect buffer write error jbd2_log_do_checkpoint() jbd2_cleanup_journal_tail() <--- lead to inconsistency jbd2_journal_abort() Fix this issue by introducing a new atomic flag which only have one JBD2_CHECKPOINT_IO_ERROR bit now, and set it in __jbd2_journal_remove_checkpoint() when freeing a checkpoint buffer which has write_io_error flag. Then jbd2_journal_destroy() will detect this mark and abort the journal to prevent updating log tail. Signed-off-by:
Zhang Yi <yi.zhang@huawei.com>
Reviewed-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Reviewed-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Zhang Yi authored
hulk inclusion category: bugfix bugzilla: 50788 CVE: NA --------------------------- The 'out' lable just return the 'ret' value and seems not required, so remove this label and switch to return appropriate value immediately. This patch also do some minor cleanup, no logical change. Signed-off-by:
Zhang Yi <yi.zhang@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
-
- May 22, 2021
-
-
Shile Zhang authored
mainline inclusion from mainline-v5.6-rc1 commit f14bf6a3 category: feature bugzilla: NA CVE: NA ------------------------------------------------- Now that the orc_unwind and orc_unwind_ip tables are sorted at build time, remove the boot time sorting pass. No change in functionality. [ mingo: Rewrote the changelog and code comments. ] Signed-off-by:
Shile Zhang <shile.zhang@linux.alibaba.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kbuild@vger.kernel.org
Link: https://lkml.kernel.org/r/20191204004633.88660-8-shile.zhang@linux.alibaba.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Jian Cheng <cj.chengjian@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Shile Zhang authored
mainline inclusion from mainline-v5.6-rc1 commit 57fa1899 category: feature bugzilla: NA CVE: NA ------------------------------------------------- The ORC unwinder has two tables: .orc_unwind_ip and .orc_unwind, which need to be sorted for binary search. Previously this sorting was done during bootup. Sort them at build time to speed up booting. Add the ORC tables sorting in a parallel build process to speed up the build. [ mingo: Rewrote the changelog and fixed some comments. ] Suggested-by:
Andy Lutomirski <luto@amacapital.net>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Shile Zhang <shile.zhang@linux.alibaba.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: linux-kbuild@vger.kernel.or... -
Shile Zhang authored
mainline inclusion from mainline-v5.6-rc1 commit 10916706 category: feature bugzilla: NA CVE: NA ------------------------------------------------- Use a more generic name for additional table sorting usecases, such as the upcoming ORC table sorting feature. This tool is not tied to exception table sorting anymore. No functional changes intended. [ mingo: Rewrote the changelog. ] Signed-off-by:
Shile Zhang <shile.zhang@linux.alibaba.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: linux-kbuild@vger.kernel.org
Link: https://lkml.kernel.org/r/20191204004633.88660-6-shile.zhang@linux.alibaba.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Conflicts:
scripts/link-vmlinux.sh
scripts/Makefile
scripts/.gitignore
arch/x86/Kconfig
arch/microblaze/Kconfig
arch/xtensa/Kconfig
arch/parisc/Kconfig
arch/powerpc/Kconfig
arch/arc/Kconfig
arch/mips/Kconfig
arch/arm/Kconfig
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Jian Cheng <cj.chengjian@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Shile Zhang authored
mainline inclusion from mainline-v5.6-rc1 commit 57cafdf2 category: feature bugzilla: NA CVE: NA ------------------------------------------------- Refine the loop, naming and code structure, make the code more readable and extendable. No functional changes intended. Signed-off-by:
Shile Zhang <shile.zhang@linux.alibaba.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: linux-kbuild@vger.kernel.org
Link: https://lkml.kernel.org/r/20191204004633.88660-5-shile.zhang@linux.alibaba.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Jian Cheng <cj.chengjian@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Shile Zhang authored
mainline inclusion from mainline-v5.6-rc1 commit abe4f92c category: feature bugzilla: NA CVE: NA ------------------------------------------------- Signed-off-by:
Shile Zhang <shile.zhang@linux.alibaba.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: linux-kbuild@vger.kernel.org
Link: https://lkml.kernel.org/r/20191204004633.88660-4-shile.zhang@linux.alibaba.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Jian Cheng <cj.chengjian@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Shile Zhang authored
mainline inclusion from mainline-v5.6-rc1 commit 6402e141 category: feature bugzilla: NA CVE: NA ------------------------------------------------- Fix various style errors and inconsistencies, no functional changes intended. Signed-off-by:
Shile Zhang <shile.zhang@linux.alibaba.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: linux-kbuild@vger.kernel.org
Link: https://lkml.kernel.org/r/20191204004633.88660-3-shile.zhang@linux.alibaba.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Jian Cheng <cj.chengjian@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Shile Zhang authored
mainline inclusion from mainline-v5.6-rc1 commit 3c47b787 category: feature bugzilla: NA CVE: NA ------------------------------------------------- The scripts/sortextable.c code has originally copied some code from scripts/recordmount.c, which used the same setjmp/longjmp method to manage control flow. Meanwhile recordmcount has improved its error handling via: 3f1df120 ("recordmcount: Rewrite error/success handling"). So rewrite this part of sortextable as well to get rid of the setjmp/longjmp kludges, with additional refactoring, to make it more readable and easier to extend. No functional changes intended. [ mingo: Rewrote the changelog. ] Signed-off-by:
Shile Zhang <shile.zhang@linux.alibaba.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: linux-kbuild@vger.kernel.org
Link: https://lkml.kernel.org/r/20191204004633.88660-2-shile.zhang@linux.alibaba.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Jian Cheng <cj.chengjian@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Thomas Gleixner authored
mainline inclusion from mainline-v5.2-rc4 commit 4317cf95 category: feature bugzilla: NA CVE: NA ------------------------------------------------- Based on 1 normalized pattern(s): licensed under the gnu general public license version 2 gplv2 extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 5 file(s). Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Armijn Hemel <armijn@tjaldur.nl>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190531081036.993848054@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Jian Cheng <cj.chengjian@huawei.com>
Signed-off-by: Yang Yingliang <yangyingl... -
Ye Bin authored
hulk inclusion category: bugfix bugzilla: 51854 CVE: NA ------------------------------------------------- We got follow bug_on when run fsstress with injecting IO fault: [130747.323114] kernel BUG at fs/ext4/extents_status.c:762! [130747.323117] Internal error: Oops - BUG: 0 [#1] SMP ...... [130747.334329] Call trace: [130747.334553] ext4_es_cache_extent+0x150/0x168 [ext4] [130747.334975] ext4_cache_extents+0x64/0xe8 [ext4] [130747.335368] ext4_find_extent+0x300/0x330 [ext4] [130747.335759] ext4_ext_map_blocks+0x74/0x1178 [ext4] [130747.336179] ext4_map_blocks+0x2f4/0x5f0 [ext4] [130747.336567] ext4_mpage_readpages+0x4a8/0x7a8 [ext4] [130747.336995] ext4_readpage+0x54/0x100 [ext4] [130747.337359] generic_file_buffered_read+0x410/0xae8 [130747.337767] generic_file_read_iter+0x114/0x190 [130747.338152] ext4_file_read_iter+0x5c/0x140 [ext4] [130747.338556] __vfs_read+0x11c/0x188 [130747.338851] vfs_read+0x94/0x150 [130747.3...
-
Ye Bin authored
hulk inclusion category: bugfix bugzilla: 51854 CVE: NA ------------------------------------------------- This reverts commit 5446b76c34ed8875ba05a61fccfe838a98193791. Signed-off-by:
Ye Bin <yebin10@huawei.com>
Reviewed-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Donald Buczek authored
mainline inclusion from mainline-v5.3-rc1 commit 5b596830 category: bugfix bugzilla: NA CVE: NA -------------------------------- RFC 7530 requires us to refetch the lease time attribute once a new clientID is established. This is already implemented for the nfs4.1(+) clients by nfs41_init_clientid, which calls nfs41_finish_session_reset, which calls nfs4_setup_state_renewal. To make nfs4_setup_state_renewal available for nfs4.0, move it further to the top of the source file to include it regardles of CONFIG_NFS_V4_1 and to save a forward declaration. Call nfs4_setup_state_renewal from nfs4_init_clientid. Signed-off-by:
Donald Buczek <buczek@molgen.mpg.de>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Donald Buczek authored
mainline inclusion from mainline-v5.3-rc1 commit ea51efaa category: bugfix bugzilla: NA CVE: NA -------------------------------- The function nfs41_setup_state_renewal is useful to the nfs 4.0 client as well, so rename the function to nfs4_setup_state_renewal. Signed-off-by:
Donald Buczek <buczek@molgen.mpg.de>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Donald Buczek authored
mainline inclusion from mainline-v5.3-rc1 commit 0efb01b2 category: bugfix bugzilla: NA CVE: NA -------------------------------- Compile nfs4_proc_get_lease_time, enc_get_lease_time and dec_get_lease_time for nfs4.0. Use nfs4_sequence_done instead of nfs41_sequence_done in nfs4_proc_get_lease_time, Signed-off-by:
Donald Buczek <buczek@molgen.mpg.de>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Conflicts:
fs/nfs/nfs4_fs.h
Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Donald Buczek authored
mainline inclusion from mainline-v5.3-rc1 commit 2eaf426d category: bugfix bugzilla: NA CVE: NA -------------------------------- The debug message of decode_attr_lease_time incorrectly says "file size". Fix it to "lease time". Signed-off-by:
Donald Buczek <buczek@molgen.mpg.de>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Zhang Yi authored
hulk inclusion category: bugfix bugzilla: 51864 CVE: NA --------------------------- In ext4_orphan_cleanup(), if ext4_truncate() failed to get a transaction handle, it didn't remove the inode from the in-core orphan list, which may probably trigger below error dump in ext4_destroy_inode() during the final iput() and could lead to memory corruption on the later orphan list changes. EXT4-fs (sda): Inode 6291467 (00000000b8247c67): orphan list check failed! 00000000b8247c67: 0001f30a 00000004 00000000 00000023 ............#... 00000000e24cde71: 00000006 014082a3 00000000 00000000 ......@......... 0000000072c6a5ee: 00000000 00000000 00000000 00000000 ................ ... This patch fix this by cleanup in-core orphan list manually if ext4_truncate() return error. Signed-off-by:
Zhang Yi <yi.zhang@huawei.com>
Signed-off-by: yangerkun <yangerkun@huawei.com>
Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
Reviewed-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Lin Ma authored
mainline inclusion from mainline-v5.13-rc1 commit e2cb6b891ad2b8caa9131e3be70f45243df82a80 category: bugfix bugzilla: NA CVE: CVE-2021-32399 -------------------------------- There is a possible race condition vulnerability between issuing a HCI command and removing the cont. Specifically, functions hci_req_sync() and hci_dev_do_close() can race each other like below: thread-A in hci_req_sync() | thread-B in hci_dev_do_close() | hci_req_sync_lock(hdev); test_bit(HCI_UP, &hdev->flags); | ... | test_and_clear_bit(HCI_UP, &hdev->flags) hci_req_sync_lock(hdev); | | In this commit we alter the sequence in function hci_req_sync(). Hence, the thread-A cannot issue th. Signed-off-by:Lin Ma <linma@zju.edu.cn>
Cc: Marcel Holtmann <marcel@holtmann.org>
Fixes: 7c6a329e ("[Bluetooth] Fix regression from using default li...
-
- May 21, 2021
-
-
Jingxian He authored
hulk inclusion category: feature bugzilla: 48159 CVE: N/A ------------------------------ Enhance variables check and sync for pin mem as followings: 1) Remove unused variable in set_fork_pid; 2) Remove unused calling of access_ok, which is called in copy_from_user; 3) Enhance page_map_entry_start check in pin_mem_area; 4) Keep get_page_map_info and create_page_map_info for internal use, and increase get_page_map_info_by_pid and create_page_map_info_by_pid for external use, which is protected by spinlock; 5) Use spin_lock_irqsave instead of spin_lock. Signed-off-by:
Jingxian He <hejingxian@huawei.com>
Reviewed-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Cheng Jian <cj.chengjian@huawei.com> -
Nick Gasson authored
mainline inclusion from mainline-v5.7 commit 1e4bd2ae category: bugfix bugzilla: NA CVE: NA ------------------------------------------------- Fix an issue where addresses in the DWARF line table are offset by -0x40 (GEN_ELF_TEXT_OFFSET). This can be seen with `objdump -S` on the ELF files after perf inject. Committer notes: Ian added this in his Acked-by reply: --- Without too much knowledge this looks good to me. The original code came from oprofile's jit support: https://sourceforge.net/p/oprofile/oprofile/ci/master/tree/opjitconv/debug_line.c#l325 --- Signed-off-by:
Nick Gasson <nick.gasson@arm.com>
Acked-by: Ian Rogers <irogers@google.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lore.kernel.org/lkml/20200528051916.6722-1-nick.gasson@arm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Zhichang Yuan <er... -
Nick Gasson authored
mainline inclusion from mainline-v5.7 commit 7d7e503c category: bugfix bugzilla: NA CVE: NA ------------------------------------------------- For each PC/BCI pair in the JVMTI compiler inlining record table, the jitdump plugin emits debug line table entries for every source line in the method preceding that BCI. Instead only emit one source line per PC/BCI pair. Reported by Ian Rogers. This reduces the .dump size for SPECjbb from ~230MB to ~40MB. Signed-off-by:
Nick Gasson <nick.gasson@arm.com>
Acked-by: Ian Rogers <irogers@google.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lore.kernel.org/lkml/20200528054049.13662-1-nick.gasson@arm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Zhichang Yuan <erik.yuan@arm.com>
Reviewed-by: Yang Jihong <yangjihong1@huawei.com>
Signed-off-by: Cheng Jian <cj.chengjian@huawei.com> -
Nick Gasson authored
mainline inclusion from mainline-v5.7 commit 0bdf3181 category: bugfix bugzilla: NA CVE: NA ------------------------------------------------- For a Java method signature like: Ljava/lang/AbstractStringBuilder;appendChars(Ljava/lang/String;II)V The demangler produces: void class java.lang.AbstractStringBuilder.appendChars(class java.lang., shorttring., int, int) The arguments should be (java.lang.String, int, int) but the demangler interprets the "S" in String as the type code for "short". Correct this and two other minor things: - There is no "bool" type in Java, should be "boolean". - The demangler prepends "class" to every Java class name. This is not standard Java syntax and it wastes a lot of horizontal space if the signature is long. Remove this as there isn't any ambiguity between class names and primitives. Committer notes: This was split from a larger patch that also added a java demangler 'perf test' entry, that, before this patch shows the error being fixed by it: $ perf test java 65: Demangle Java : FAILED! $ perf test -v java Couldn't bump rlimit(MEMLOCK), failures may take place when creating BPF maps, etc 65: Demangle Java : --- start --- test child forked, pid 307264 FAILED: Ljava/lang/StringLatin1;equals([B[B)Z: bool class java.lang.StringLatin1.equals(byte[], byte[]) != boolean java.lang.StringLatin1.equals(byte[], byte[]) FAILED: Ljava/util/zip/ZipUtils;CENSIZ([BI)J: long class java.util.zip.ZipUtils.CENSIZ(byte[], int) != long java.util.zip.ZipUtils.CENSIZ(byte[], int) FAILED: Ljava/util/regex/Pattern$BmpCharProperty;match(Ljava/util/regex/Matcher;ILjava/lang/CharSequence;)Z: bool class java.util.regex.Pattern$BmpCharProperty.match(class java.util.regex.Matcher., int, class java.lang., charhar, shortequence) != boolean java.util.regex.Pattern$BmpCharProperty.match(java.util.regex.Matcher, int, java.lang.CharSequence) FAILED: Ljava/lang/AbstractStringBuilder;appendChars(Ljava/lang/String;II)V: void class java.lang.AbstractStringBuilder.appendChars(class java.lang., shorttring., int, int) != void java.lang.AbstractStringBuilder.appendChars(java.lang.String, int, int) FAILED: Ljava/lang/Object;<init>()V: void class java.lang.Object<init>() != void java.lang.Object<init>() test child finished with -1 ---- end ---- Demangle Java: FAILED! $ After applying this patch: $ perf test java 65: Demangle Java : Ok $ Signed-off-by:
Nick Gasson <nick.gasson@arm.com>
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Tested-by: Ian Rogers <irogers@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lore.kernel.org/lkml/20200427061520.24905-4-nick.gasson@arm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Zhichang Yuan <erik.yuan@arm.com>
Reviewed-by: Yang Jihong <yangjihong1@huawei.com>
Signed-off-by: Cheng Jian <cj.chengjian@huawei.com> -
Nick Gasson authored
mainline inclusion from mainline-v5.7 commit 525c821d category: bugfix bugzilla: NA CVE: NA ------------------------------------------------- Split from a larger patch that was also fixing a problem with the java demangler, so, before applying that patch we see: $ perf test java 65: Demangle Java : FAILED! $ perf test -v java 65: Demangle Java : --- start --- test child forked, pid 307264 FAILED: Ljava/lang/StringLatin1;equals([B[B)Z: bool class java.lang.StringLatin1.equals(byte[], byte[]) != boolean java.lang.StringLatin1.equals(byte[], byte[]) FAILED: Ljava/util/zip/ZipUtils;CENSIZ([BI)J: long class java.util.zip.ZipUtils.CENSIZ(byte[], int) != long java.util.zip.ZipUtils.CENSIZ(byte[], int) FAILED: Ljava/util/regex/Pattern$BmpCharProperty;match(Ljava/util/regex/Matcher;ILjava/lang/CharSequence;)Z: bool class java.util.regex.Pattern$BmpCharProperty.match(class java.util.regex.Matcher., int, class java.lang., charhar, shortequence) != boolean java.util.regex.Pattern$BmpCharProperty.match(java.util.regex.Matcher, int, java.lang.CharSequence) FAILED: Ljava/lang/AbstractStringBuilder;appendChars(Ljava/lang/String;II)V: void class java.lang.AbstractStringBuilder.appendChars(class java.lang., shorttring., int, int) != void java.lang.AbstractStringBuilder.appendChars(java.lang.String, int, int) FAILED: Ljava/lang/Object;<init>()V: void class java.lang.Object<init>() != void java.lang.Object<init>() test child finished with -1 ---- end ---- Demangle Java: FAILED! $ Next patch should fix this. Signed-off-by:
Nick Gasson <nick.gasson@arm.com>
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Tested-by: Ian Rogers <irogers@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lore.kernel.org/lkml/20200427061520.24905-4-nick.gasson@arm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Zhichang Yuan <erik.yuan@arm.com>
Reviewed-by: Yang Jihong <yangjihong1@huawei.com>
Signed-off-by: Cheng Jian <cj.chengjian@huawei.com> -
Nick Gasson authored
mainline inclusion from mainline-v5.7 commit 959f8ed4 category: bugfix bugzilla: NA CVE: NA ------------------------------------------------- If the Java sources are compiled with -g:none to disable debug information the perf JVMTI plugin reports a lot of errors like: java: GetLineNumberTable failed with JVMTI_ERROR_ABSENT_INFORMATION java: GetLineNumberTable failed with JVMTI_ERROR_ABSENT_INFORMATION java: GetLineNumberTable failed with JVMTI_ERROR_ABSENT_INFORMATION java: GetLineNumberTable failed with JVMTI_ERROR_ABSENT_INFORMATION java: GetLineNumberTable failed with JVMTI_ERROR_ABSENT_INFORMATION Instead if GetLineNumberTable returns JVMTI_ERROR_ABSENT_INFORMATION simply skip emitting line number information for that method. Unlike the previous patch these errors don't affect the jitdump generation, they just generate a lot of noise. Similarly for native methods which also don't have line tables. Signed-off-by:
Nick Gasson <nick.gasson@arm.com>
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lore.kernel.org/lkml/20200427061520.24905-3-nick.gasson@arm.com
[ Moved || operator to the end of the line, not at the start of 2nd if condition ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Zhichang Yuan <erik.yuan@arm.com>
Reviewed-by: Yang Jihong <yangjihong1@huawei.com>
Signed-off-by: Cheng Jian <cj.chengjian@huawei.com> -
Nick Gasson authored
mainline inclusion from mainline-v5.7 commit 953e9240 category: bugfix bugzilla: NA CVE: NA --------------------------- If a Java class is compiled with -g:none to omit debug information, the JVMTI plugin won't write jitdump entries for any method in this class and prints a lot of errors like: java: GetSourceFileName failed with JVMTI_ERROR_ABSENT_INFORMATION The call to GetSourceFileName is used to derive the file name `fn`, but this value is not actually used since commit ca58d7e6 ("perf jvmti: Generate correct debug information for inlined code") which moved the file name lookup into fill_source_filenames(). So the call to GetSourceFileName and related code can be safely removed. Signed-off-by:
Nick Gasson <nick.gasson@arm.com>
Reviewed-by: Ian Rogers <irogers@google.com>
Tested-by: Ian Rogers <irogers@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lore.kernel.org/lkml/20200427061520.24905-2-nick.gasson@arm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Zhichang Yuan <erik.yuan@arm.com>
Reviewed-by: Yang Jihong <yangjihong1@huawei.com>
Signed-off-by: Cheng Jian <cj.chengjian@huawei.com>
-
- May 18, 2021
-
-
Daniel Borkmann authored
mainline inclusion from mainline-v5.13-rc1 commit 801c6058d14a82179a7ee17a4b532cac6fad067f category: bugfix bugzilla: NA CVE: CVE-2021-31829 -------------------------------- The current implemented mechanisms to mitigate data disclosure under speculation mainly address stack and map value oob access from the speculative domain. However, Piotr discovered that uninitialized BPF stack is not protected yet, and thus old data from the kernel stack, potentially including addresses of kernel structures, could still be extracted from that 512 bytes large window. The BPF stack is special compared to map values since it's not zero initialized for every program invocation, whereas map values /are/ zero initialized upon their initial allocation and thus cannot leak any prior data in either domain. In the non-speculative domain, the verifier ensures that every stack slot read must have a prior stack slot write by the BPF program to avoid such data leaking...
-
Daniel Borkmann authored
stable inclusion from linux-4.19.190 commit 0e2dfdc74a7f4036127356d42ea59388f153f42c -------------------------------- commit b9b34ddbe2076ade359cd5ce7537d5ed019e9807 upstream. The negation logic for the case where the off_reg is sitting in the dst register is not correct given then we cannot just invert the add to a sub or vice versa. As a fix, perform the final bitwise and-op unconditionally into AX from the off_reg, then move the pointer from the src to dst and finally use AX as the source for the original pointer arithmetic operation such that the inversion yields a correct result. The single non-AX mov in between is possible given constant blinding is retaining it as it's not an immediate based operation. Fixes: 979d63d5 ("bpf: prevent out of bounds speculation on pointer arithmetic") Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Piotr Krysiuk <piotras@gmail.com>
Reviewed-by: Piotr Krysiuk <piotras@gmail.com>
Reviewed-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
-
- May 17, 2021
-
-
Coly Li authored
mainline inclusion from mainline-v5.6-rc1 commit 038ba8cc category: bugfix bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=26 CVE: NA ----------------------------------------------- In year 2007 high performance SSD was still expensive, in order to save more space for real workload or meta data, the readahead I/Os for non-meta data was bypassed and not cached on SSD. In now days, SSD price drops a lot and people can find larger size SSD with more comfortable price. It is unncessary to alway bypass normal readahead I/Os to save SSD space for now. This patch adds options for readahead data cache policies via sysfs file /sys/block/bcache<N>/readahead_cache_policy, the options are, - "all": cache all readahead data I/Os. - "meta-only": only cache meta data, and bypass other regular I/Os. If users want to make bcache continue to only cache readahead request for metadata and bypass regular data readahead, please set "meta-only" to this sysfs file. By default, bcache will back to cache all read- ahead requests now. Cc: stable@vger.kernel.org Signed-off-by:
Coly Li <colyli@suse.de>
Acked-by: Eric Wheeler <bcache@linux.ewheeler.net>
Cc: Michael Lyle <mlyle@lyle.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Li Ruilin <liruilin4@huawei.com>
Reviewed-by: Peng Junyi <pengjunyi1@huawei.com>
Acked-by: Xie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Cheng Jian <cj.chengjian@huawei.com>
-