* Drew Fustini [210325 00:25]:
> Based on linux-gpio discussion [1], it is best practice to make the
> gpio-line-names unique. Generic names like "[ethernet]" are replaced
> with the name of the unique signal on the AM3358 SoC ball corresponding
> to the gpio line. "[NC]" is also renamed to the
* Stephen Boyd [210330 02:25]:
> Quoting Dario Binacchi (2021-03-29 09:42:17)
> >
> > As reported by the TI spruh73x RM, MPU and LCD modules support spread
> > spectrum clocking (SSC) on their output clocks. SSC is used to spread
> > the spectral peaking of the clock to reduce any
On Tue, 30 Mar 2021 23:07:24 -0400, Cui GaoSheng wrote:
> Do a trivial typo fix.
> s/cachable/cacheable
Applied to for-next/seccomp, thanks!
[1/1] seccomp: Fix "cacheable" typo in comments
https://git.kernel.org/kees/c/a3fc712c5b37
--
Kees Cook
On Tue, Mar 30, 2021 at 11:06 PM Mark Brown wrote:
>
> On Tue, Mar 30, 2021 at 02:32:51PM +0800, Shengjiu Wang wrote:
>
> > +static const struct snd_kcontrol_new ak5552_snd_controls[] = {
> > + SOC_ENUM("AK5552 Monaural Mode", ak5552_mono_enum[0]),
> > + SOC_ENUM("AK5552 Digital Filter",
ORC Unwinder can not unwind if an optprobe trampoline is on the
stack because optprobe trampoline code has no ORC information.
This uses the ORC information on the template code of the
trampoline to adjust the sp register by ORC information and
extract the correct probed address from the optprobe
Add find_kprobe_{insn,optinsn}_slot_entry() functions to find
corresponding entry address of the kprobe instrurction buffer
which includes given address.
Signed-off-by: Masami Hiramatsu
---
include/linux/kprobes.h |8
kernel/kprobes.c| 25 ++---
2
As same as kretprobe_trampoline, move the optprobe template
code in the text for making ORC information on that.
Signed-off-by: Masami Hiramatsu
---
arch/x86/kernel/kprobes/opt.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git
Hello,
These patches fixes the ORC unwinder to unwind optprobe trampoline
code on the stack correctly.
This patchset is based on the kretporbe and stacktrace fix series v5
which I sent last week.
https://lore.kernel.org/bpf/161676170650.330141.6214727134265514123.stgit@devnote2/
Note that I
On Mon, 29 Mar 2021 20:36:35 +0800 qianjun.ker...@gmail.com wrote:
> From: jun qian
>
> In our project, Many business delays come from fork, so
> we started looking for the reason why fork is time-consuming.
> I used the ftrace with function_graph to trace the fork, found
> that the
Remove empty comment and fix checkpatch warnings:
WARNING: Block comments use * on subsequent lines
WARNING: Possible repeated word: 'very'
Signed-off-by: Deborah Brouwer
---
drivers/staging/rtl8723bs/core/rtw_xmit.c | 61 +++
1 file changed, 28 insertions(+), 33
On Mon, 29 Mar 2021 16:54:26 +0200 Andrey Konovalov
wrote:
> Looks like my patch "kasan: fix KASAN_STACK dependency for HW_TAGS"
> that was merged into 5.12-rc causes a build time warning:
>
> include/linux/kasan.h:333:30: warning: 'CONFIG_KASAN_STACK' is not
> defined, evaluates to 0
On Wednesday, 31 March 2021 5:18:56 PM NZDT Guo Ren wrote:
> > > [1]
> > > https://github.com/c-sky/csky-linux/commit/e837aad23148542771794d8a2fcc
> > > 52afd0fcbf88> >
> > > > It also seems that the current "amoswap" based implementation
> > > > would be reliable independent of
Multi-core SMP doesn't work on modern Intel CPUs (at least Comet Lake) without
x2apic. Unsure users should say Y.
Signed-off-by: Luke Dashjr
---
arch/x86/Kconfig | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 5e46d1b78a03d52306f21f77a4e4a144b6d31486
commit: ae999bb9a3399527bbe2c352191a0d49faa9c441 f2fs: change compr_blocks of
superblock info to 64bit
date: 7 months ago
config: um-randconfig-r023-20210330
allmodconfig
powerpc allnoconfig
x86_64 randconfig-a004-20210330
x86_64 randconfig-a003-20210330
x86_64 randconfig-a002-20210330
x86_64 randconfig-a001-20210330
x86_64 randconfig-a005-20210330
x86_64
On Wed, 31 Mar 2021 at 11:24, Sean Christopherson wrote:
>
> On Wed, Mar 31, 2021, Wanpeng Li wrote:
> > On Wed, 31 Mar 2021 at 10:32, Sean Christopherson wrote:
> > >
> > > Use GFP_KERNEL_ACCOUNT for the vCPU allocations, the vCPUs are very much
> > > tied to a single task/VM. For x86, the
From: Tao Ren
Currently the virtual port_dev device is passed to DMA API, and this is
wrong because the device passed to DMA API calls must be the actual
hardware device performing the DMA.
The patch replaces usb_gadget_map_request/usb_gadget_unmap_request APIs
with
On Tue, 30 Mar 2021 10:58:43 +0200 David Hildenbrand wrote:
> >
> > MAINTAINERS| 1 +
> > arch/alpha/include/uapi/asm/mman.h | 3 +
> > arch/mips/include/uapi/asm/mman.h | 3 +
> > arch/parisc/include/uapi/asm/mman.h| 3 +
> >
On Tue, Mar 30, 2021 at 9:45 PM Joel Stanley wrote:
>
> overlayfs using jffs2 as the upper filesystem would fail in some cases
> since moving to v5.10. The test case used was to run 'touch' on a file
> that exists in the lower fs, causing the modification time to be
> updated. It returns EINVAL
On Tue, Mar 30, 2021 at 09:43:20PM -0700, Andrew Morton wrote:
> On Tue, 30 Mar 2021 09:52:26 -0500 "Gustavo A. R. Silva"
> wrote:
>
> > Fix the following out-of-bounds warnings by enclosing
> > structure members file and finder into new struct info:
> >
> > fs/hfsplus/xattr.c:300:5: warning:
In f29b5f3e6fc0a, the script is update to support python3.
Fix the python interpreter update to python3.
Fixes: f29b5f3e6fc0a ("show_delta: Update script to support python3")
Signed-off-by: Wan Jiabing
---
scripts/show_delta | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
In __ufshcd_issue_tm_cmd(), it is not right to use hba->nutrs + req->tag as
the Task Tag in one TMR UPIU. Directly use req->tag as the Task Tag.
Fixes: e293313262d3 ("scsi: ufs: Fix broken task management command
implementation")
Reviewed-by: Bart Van Assche
Signed-off-by: Can Guo
---
ufshcd_tmc_handler() calls blk_mq_tagset_busy_iter(fn = ufshcd_compl_tm()),
but since blk_mq_tagset_busy_iter() only iterates over all reserved tags
and requests which are not in IDLE state, ufshcd_compl_tm() never gets a
chance to run. Thus, TMR always ends up with completion timeout. Fix it by
On Tue, 30 Mar 2021 09:52:26 -0500 "Gustavo A. R. Silva"
wrote:
> Fix the following out-of-bounds warnings by enclosing
> structure members file and finder into new struct info:
>
> fs/hfsplus/xattr.c:300:5: warning: 'memcpy' offset [65, 80] from the object
> at 'entry' is out of the bounds
On Mon, Mar 29, 2021 at 3:55 PM Kumar Kartikeya Dwivedi
wrote:
> diff --git a/net/sched/act_api.c b/net/sched/act_api.c
> index b919826939e0..43cceb924976 100644
> --- a/net/sched/act_api.c
> +++ b/net/sched/act_api.c
> @@ -1042,6 +1042,9 @@ struct tc_action *tcf_action_init_1(struct net *net,
>
Hi,
url:
https://github.com/0day-ci/linux/commits/glittao-gmail-com/kunit-add-a-KUnit-test-for-SLUB-debugging-functionality/20210330-200635
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
1e43c377a79f9189fea8f2711b399d4e8b4e609b
config: i386-randconfig-m021
329
> BAD: next-20210330
>
> steps to reproduce:
> ---
> # Boot linux next tag 20210330 on x86_64 machine
> # cd /opt/kselftests/default-in-kernel/
> # ./gpio-mockup.sh --> which is doing modprobe gpio-mockup
>
> Test log:
>
> # selfte
On Wed, Mar 31, 2021 at 10:43:36AM +0800, Aili Yao wrote:
> On Wed, 31 Mar 2021 01:52:59 + HORIGUCHI NAOYA(堀口 直也)
> wrote:
> > On Fri, Mar 26, 2021 at 03:22:49PM +0100, David Hildenbrand wrote:
> > > On 26.03.21 15:09, David Hildenbrand wrote:
> > > > On 22.03.21 12:33, Aili Yao wrote:
>
On Tue, Mar 30, 2021 at 07:04:30PM +0200, Paolo Bonzini wrote:
> On 30/03/21 17:26, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:93129492 Add linux-next specific files for 20210326
> > git tree: linux-next
> > console output:
On Tue, Mar 30, 2021 at 3:12 PM Arnd Bergmann wrote:
>
> On Tue, Mar 30, 2021 at 4:26 AM Guo Ren wrote:
> > On Mon, Mar 29, 2021 at 9:56 PM Arnd Bergmann wrote:
> > > On Mon, Mar 29, 2021 at 2:52 PM Guo Ren wrote:
> > > > On Mon, Mar 29, 2021 at 7:31 PM Peter Zijlstra
> > > > wrote:
> > > >
On Wednesday, 31 March 2021 2:56:38 PM AEDT John Hubbard wrote:
> On 3/30/21 3:56 PM, Alistair Popple wrote:
> ...
> >> +1 for renaming "munlock*" items to "mlock*", where applicable. good
grief.
> >
> > At least the situation was weird enough to prompt further investigation :)
> >
> > Renaming
On 3/30/21 8:56 PM, John Hubbard wrote:
On 3/30/21 3:56 PM, Alistair Popple wrote:
...
+1 for renaming "munlock*" items to "mlock*", where applicable. good grief.
At least the situation was weird enough to prompt further investigation :)
Renaming to mlock* doesn't feel like the right
> -Original Message-
> From: Ritesh Harjani
> Sent: Tuesday, March 23, 2021 11:48 PM
> Subject: Re: [PATCH v3 02/10] fsdax: Factor helper: dax_fault_actor()
>
>
>
> On 3/19/21 7:22 AM, Shiyang Ruan wrote:
> > The core logic in the two dax page fault functions is similar. So,
> > move
On 3/30/21 3:56 PM, Alistair Popple wrote:
...
+1 for renaming "munlock*" items to "mlock*", where applicable. good grief.
At least the situation was weird enough to prompt further investigation :)
Renaming to mlock* doesn't feel like the right solution to me either though. I
am not sure if
On Mon, Mar 29, 2021 at 07:12:55PM +0900, Hyunsoon Kim wrote:
> On Mon, Mar 29, 2021 at 09:34:31AM +0300, Leon Romanovsky wrote:
> > On Mon, Mar 29, 2021 at 02:29:10PM +0900, Hyunsoon Kim wrote:
> > > This patch allows programmer to avoid zero initialization on page
> > > allocation even when the
On Mon, Mar 29, 2021 at 08:17:35AM +0200, Christoph Hellwig wrote:
> On Sat, Mar 27, 2021 at 03:17:59PM -0700, Tao Ren wrote:
> > On Fri, Mar 26, 2021 at 01:05:26PM +0100, Christoph Hellwig wrote:
> > > On Fri, Mar 26, 2021 at 12:03:03PM +, Robin Murphy wrote:
> > > > This might happen to work
Fix the following whitescan warning:
Calling "zlib_inflateEnd()" is only useful for its return value,
which is ignored.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
fs/cramfs/uncompress.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/cramfs/uncompress.c
The helper routine hstate_next_node_to_alloc accesses and modifies the
hstate variable next_nid_to_alloc. The helper is used by the routines
alloc_pool_huge_page and adjust_pool_surplus. adjust_pool_surplus is
called with hugetlb_lock held. However, alloc_pool_huge_page can not
be called with
free_pool_huge_page was called with hugetlb_lock held. It would remove
a hugetlb page, and then free the corresponding pages to the lower level
allocators such as buddy. free_pool_huge_page was called in a loop to
remove hugetlb pages and these loops could hold the hugetlb_lock for a
Now that cma_release is non-blocking and irq safe, there is no need to
drop hugetlb_lock before calling.
Signed-off-by: Mike Kravetz
Acked-by: Roman Gushchin
Acked-by: Michal Hocko
---
mm/hugetlb.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index
Commit c77c0a8ac4c5 ("mm/hugetlb: defer freeing of huge pages if in
non-task context") was added to address the issue of free_huge_page
being called from irq context. That commit hands off free_huge_page
processing to a workqueue if !in_task. However, this doesn't cover
all the cases as pointed
The new remove_hugetlb_page() routine is designed to remove a hugetlb
page from hugetlbfs processing. It will remove the page from the active
or free list, update global counters and set the compound page
destructor to NULL so that PageHuge() will return false for the 'page'.
After this call, the
This effort is the result a recent bug report [1]. Syzbot found a
potential deadlock in the hugetlb put_page/free_huge_page_path.
WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
Since the free_huge_page_path already has code to 'hand off' page
free requests to a workqueue, a
With the introduction of remove_hugetlb_page(), there is no need for
update_and_free_page to hold the hugetlb lock. Change all callers to
drop the lock before calling.
With additional code modifications, this will allow loops which decrease
the huge page pool to drop the hugetlb_lock with each
cma_release is currently a sleepable operatation because the bitmap
manipulation is protected by cma->lock mutex. Hugetlb code which relies
on cma_release for CMA backed (giga) hugetlb pages, however, needs to be
irq safe.
The lock doesn't protect any sleepable operation so it can be changed to
a
Hi all,
After merging the drm-tegra tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
drivers/gpu/drm/tegra/dc.c: In function 'tegra_cursor_atomic_update':
drivers/gpu/drm/tegra/dc.c:883:6: warning: unused variable 'dma_mask'
[-Wunused-variable]
883 | u64
After making hugetlb lock irq safe and separating some functionality
done under the lock, add some lockdep_assert_held to help verify
locking.
Signed-off-by: Mike Kravetz
Acked-by: Michal Hocko
Reviewed-by: Miaohe Lin
Reviewed-by: Muchun Song
---
mm/hugetlb.c | 9 +
1 file changed, 9
Fix the following whitescan warning:
Calling "zlib_inflateEnd(>decomp_stream)" is only useful for its
return value, which is ignored.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
crypto/deflate.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/crypto/deflate.c
On Tue, Mar 30, 2021 at 05:10:04PM -0400, Johannes Weiner wrote:
> On Tue, Mar 30, 2021 at 11:34:11AM -0700, Shakeel Butt wrote:
> > On Tue, Mar 30, 2021 at 3:20 AM Muchun Song
> > wrote:
> > >
> > > Since the following patchsets applied. All the kernel memory are charged
> > > with the new APIs
From: Chunguang Xu
If delayacct is disabled, then delayacct_is_task_waiting_on_io()
always returns false, which causes the statistical value to be
wrong. Perhaps tsk->in_iowait is better.
Signed-off-by: Chunguang Xu
---
kernel/cgroup/cgroup-v1.c | 2 +-
1 file changed, 1 insertion(+), 1
From: Chunguang Xu
The existing data structure is not very convenient for
expansion, and part of the code can be saved. Here, try
to optimize, which can make the code more concise and
easy to expand.
Signed-off-by: Chunguang Xu
---
include/linux/delayacct.h | 139
From: Chunguang Xu
Many distributions do not install the getdelay tool by
default, similar to task_io_accounting, adding a proc
file to make access easier.
Signed-off-by: Chunguang Xu
---
fs/proc/base.c | 7 +++
kernel/delayacct.c | 41 +
2
On Wed, Mar 31, 2021, Wanpeng Li wrote:
> On Wed, 31 Mar 2021 at 10:32, Sean Christopherson wrote:
> >
> > Use GFP_KERNEL_ACCOUNT for the vCPU allocations, the vCPUs are very much
> > tied to a single task/VM. For x86, the allocations were accounted up
> > until the allocation code was moved to
Provide hooks to intercept bad usages of virt_to_phys() and
__pa_symbol() throughout the kernel. To make this possible, we need to
rename the current implement of virt_to_phys() into
__virt_to_phys_nodebug() and wrap it around depending on
CONFIG_DEBUG_VIRTUAL.
A similar thing is needed for
On 2021-03-31 09:18, Daejun Park wrote:
This patch supports the HPB 2.0.
The HPB 2.0 supports read of varying sizes from 4KB to 512KB.
In the case of Read (<= 32KB) is supported as single HPB read.
In the case of Read (36KB ~ 512KB) is supported by as a combination of
write buffer command and
Reject KVM_SEV_INIT and KVM_SEV_ES_INIT if they are attempted after one
or more vCPUs have been created. KVM assumes a VM is tagged SEV/SEV-ES
prior to vCPU creation, e.g. init_vmcb() needs to mark the VMCB as SEV
enabled, and svm_create_vcpu() needs to allocate the VMSA. At best,
creating vCPUs
Set sev->es_active only after the guts of KVM_SEV_ES_INIT succeeds. If
the command fails, e.g. because SEV is already active or there are no
available ASIDs, then es_active will be left set even though the VM is
not fully SEV-ES capable.
Refactor the code so that "es_active" is passed on the
Use the kvm_for_each_vcpu() helper to iterate over vCPUs when encrypting
VMSAs for SEV, which effectively switches to use online_vcpus instead of
created_vcpus. This fixes a possible null-pointer dereference as
created_vcpus does not guarantee a vCPU exists, since it is updated at
the very
Misc bug fixes in SEV/SEV-ES to protect against a malicious userspace.
All found by inspection, I didn't actually crash the host to to prove that
userspace could hose the kernel in any of these cases. Boot tested an SEV
guest, though the SEV-ES side of patch 2 is essentially untested as I
don't
On 2021/3/31 9:57, Jaegeuk Kim wrote:
On 03/27, Chao Yu wrote:
On 2021/3/27 9:52, Chao Yu wrote:
On 2021/3/27 1:30, Jaegeuk Kim wrote:
On 03/26, Chao Yu wrote:
On 2021/3/26 9:19, Jaegeuk Kim wrote:
On 03/26, Chao Yu wrote:
On 2021/3/25 9:59, Chao Yu wrote:
On 2021/3/25 6:44, Jaegeuk Kim
From: Chunyan Zhang
The second parameter of clk_get_optional() is "const char *", so use NULL
instead of integer 0 to fix a sparse warning like:
">> drivers/iommu/sprd-iommu.c:456:42: sparse: sparse: Using plain integer as
NULL pointer"
Also this patch changes to use the resource-managed
When we mount an unclean f2fs image in a readonly block device, let's
make mount() succeed only when there is no recoverable data in that
image, otherwise after mount(), file fsyned won't be recovered as user
expected.
Fixes: 938a184265d7 ("f2fs: give a warning only for readonly partition")
powerpc allnoconfig
x86_64 randconfig-a004-20210330
x86_64 randconfig-a003-20210330
x86_64 randconfig-a002-20210330
x86_64 randconfig-a001-20210330
x86_64 randconfig-a005-20210330
x86_64
-hfi_msgs.c:warning:array-subscript-is-above-array-bounds-of-u32-aka-unsigned-int
| `--
fs-hpfs-dir.c:warning:array-subscript-is-above-array-bounds-of-u8-aka-unsigned-char
|-- h8300-randconfig-c023-20210330
| `--
fs-hpfs-dir.c:warning:array-subscript-is-above-array-bounds-of-u8-aka-unsigned-char
|-- i386
Add a new sysfs group which has nodes to monitor data/request transfer
performance. This sysfs group has nodes showing total sectors/requests
transferred, total busy time spent and max/min/avg/sum latencies. This
group can be enhanced later to show more UFS driver layer performance
statistics data
Add a new sysfs group which has nodes to monitor data/request transfer
performance. This sysfs group has nodes showing total sectors/requests
transferred, total busy time spent and max/min/avg/sum latencies.
Signed-off-by: Can Guo
---
Documentation/ABI/testing/sysfs-driver-ufs | 126
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core
head: 883ccef355b910398b99dfaf96d40557479a7e9b
commit: 883ccef355b910398b99dfaf96d40557479a7e9b [2/2] genirq/irq_sim: Shrink
devm_irq_domain_create_sim()
config: arc-randconfig-m031-20210330 (attached as .config
the macro "PL353_SMC_ECC_MEMCFG_PGSIZE_MASK" should be 0x3,
according to the datasheet of pl353 smc
Signed-off-by: gexueyuan
---
drivers/memory/pl353-smc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memory/pl353-smc.c b/drivers/memory/pl353-smc.c
index
Do a trivial typo fix.
s/cachable/cacheable
Reported-by: Hulk Robot
Signed-off-by: Cui GaoSheng
---
kernel/seccomp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 1d60fc2c9987..1e63db4dbd9a 100644
--- a/kernel/seccomp.c
+++
From: Xuezhi Zhang
This adds a new module for the ST7789V controller with parameters for
the Waveshare 2inch LCD module.
Signed-off-by: Xuezhi Zhang
---
v2:change compatible value.
v3:change author name.
v4:delete a maintainer.
---
MAINTAINERS| 7 +
From: Xuezhi Zhang
Document support for the Waveshare 2inch LCD module display, which is a
240x320 2" TFT display driven by a Sitronix ST7789V TFT Controller.
Signed-off-by: Xuezhi Zhang
---
v2:change compatible value.
v3:change author name.
v4:delete a maintainer.
---
From: Xuezhi Zhang
This patch add support for Waveshare 2inch LCD module.
Xuezhi Zhang (2):
drm/tiny: add support for Waveshare 2inch LCD module
dt-bindings: display: sitronix,st7789v-dbi: Add Waveshare 2inch LCD
module
.../display/sitronix,st7789v-dbi.yaml | 72 +
These arguments are never modified so they can be marked const to
indicate as such.
Cc: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Jessica Yu
Cc: Evan Green
Cc: Hsin-Yi Wang
Signed-off-by: Stephen Boyd
---
lib/buildid.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
Add "auto" to the usage message so that it's a little clearer that you
can pass "auto" as the second argument. When passing "auto" the script
tries to find the base path automatically instead of requiring it be
passed on the commandline. Also use [] to indicate the
variable argument and that it is
We can use the vmlinux_build_id array here now instead of open coding
it. This mostly consolidates code.
Cc: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Jessica Yu
Cc: Evan Green
Cc: Hsin-Yi Wang
Cc: Dave Young
Cc: Baoquan He
Cc: Vivek Goyal
Cc:
Signed-off-by: Stephen Boyd
---
Kernel doc should use "Return:" instead of "Returns" to properly reflect
the return values.
Cc: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Jessica Yu
Cc: Evan Green
Cc: Hsin-Yi Wang
Signed-off-by: Stephen Boyd
---
lib/buildid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Let's use the new printk format to print the stacktrace entry when
printing a backtrace to the kernel logs. This will include any module's
build ID[1] in it so that offline/crash debugging can easily locate the
debuginfo for a module via something like debuginfod[2].
Cc: Thomas Gleixner
Cc: Ingo
Now that stacktraces contain the build ID information we can update this
script to use debuginfod-find to locate the debuginfo for the vmlinux
and modules automatically. This can replace the existing code that
requires specifying a path to vmlinux or tries to find the vmlinux and
modules
Sometimes if you're using tools that have linked things improperly or
have new features/sections that older tools don't expect you'll see
warnings printed to stderr. We don't really care about these warnings,
so let's just silence these messages to cleanup output of this script.
Cc: Jiri Olsa
Let's use the new printk format to print the stacktrace entry when
printing a backtrace to the kernel logs. This will include any module's
build ID[1] in it so that offline/crash debugging can easily locate the
debuginfo for a module via something like debuginfod[2].
Cc: Catalin Marinas
Cc: Will
Add the running kernel's build ID[1] to the stacktrace information
header. This makes it simpler for developers to locate the vmlinux with
full debuginfo for a particular kernel stacktrace. Combined with
scripts/decode_stracktrace.sh, a developer can download the correct
vmlinux from a
Let's make kernel stacktraces easier to identify by including the build
ID[1] of a module if the stacktrace is printing a symbol from a module.
This makes it simpler for developers to locate a kernel module's full
debuginfo for a particular stacktrace. Combined with
scripts/decode_stracktrace.sh,
Parse the kernel's build ID at initialization so that other code can
print a hex format string representation of the running kernel's build
ID. This will be used in the kdump and dump_stack code so that
developers can easily locate the vmlinux debug symbols for a
crash/stacktrace.
Cc: Jiri Olsa
This series adds the kernel's build ID[1] to the stacktrace header printed
in oops messages, warnings, etc. and the build ID for any module that
appears in the stacktrace after the module name. The goal is to make the
stacktrace more self-contained and descriptive by including the relevant
build
Add an API that can parse the build ID out of a buffer, instead of a
vma, to support printing a kernel module's build ID for stack traces.
Cc: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Jessica Yu
Cc: Evan Green
Cc: Hsin-Yi Wang
Signed-off-by: Stephen Boyd
---
include/linux/buildid.h | 1 +
On Wed, 31 Mar 2021 at 10:32, Sean Christopherson wrote:
>
> Use GFP_KERNEL_ACCOUNT for the vCPU allocations, the vCPUs are very much
> tied to a single task/VM. For x86, the allocations were accounted up
> until the allocation code was moved to common KVM. For all other
> architectures, vCPU
struct dc_state is declared twice. One has been
declared at 273rd line. Remove the duplicate.
Signed-off-by: Wan Jiabing
---
drivers/gpu/drm/amd/display/dc/dc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index
On Tue, Mar 30, 2021, Emanuele Giuseppe Esposito wrote:
> Calling the kvm KVM_GET_[SUPPORTED/EMULATED]_CPUID ioctl requires
> a nent field inside the kvm_cpuid2 struct to be big enough to contain
> all entries that will be set by kvm.
> Therefore if the nent field is too high, kvm will adjust it
On Wed, Mar 31, 2021 at 02:48:13AM +0530, Aditya Srivastava wrote:
> The opening comment mark '/**' is used for highlighting the beginning of
> kernel-doc comments.
> There are certain files in arch/x86/kernel/cpu/sgx, which follow this
> syntax, but the content inside does not comply with
On Tue, Mar 30, 2021 at 09:16:34AM -0400, Nayna Jain wrote:
> The "mrproper" target is still looking for build time generated keys in
> the kernel root directory instead of certs directory. Fix the path and
> remove the names of the files which are no longer generated.
>
> Fixes: cfc411e7fff3
On Tue, Mar 30, 2021 at 08:08:45AM +0200, Ricardo Ribalda wrote:
> ima_file_mprotect does not return EACCES but EPERM.
>
> Signed-off-by: Ricardo Ribalda
Acked-by: Jarkko Sakkinen
/Jarkko
> ---
> security/integrity/ima/ima_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
On Tue, Mar 30, 2021 at 06:30:22PM -0700, Hugh Dickins wrote:
> Running my usual tmpfs kernel builds swapping load, on Sunday's rc4-mm1
> mmotm (I never got to try rc3-mm1 but presume it behaved the same way),
> I hit clear_inode()'s BUG_ON(!mapping_empty(>i_data)); on two
> machines, within an
On 3/30/2021 6:44 PM, Lv Yunlong wrote:
In the first list_for_each_entry() macro of dma_async_device_register,
it gets the chan from list and calls __dma_async_device_channel_register
(..,chan). We can see that chan->local is allocated by alloc_percpu() and
it is freed chan->local by
On Tue, 30 Mar 2021 10:49:48 +0800 Ong Boon Leong wrote:
> + __netif_tx_lock(nq, cpu);
> + res = stmmac_xdp_xmit_xdpf(priv, queue, xdpf);
> + if (res == STMMAC_XDP_TX) {
> + stmmac_flush_tx_descriptors(priv, queue);
> + stmmac_tx_timer_arm(priv, queue);
> +
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 5e46d1b78a03d52306f21f77a4e4a144b6d31486
commit: a30cc14fe49c2d5913caf6b987d7cbd86c5e370b um: Don't use generic barrier.h
date: 1 year, 6 months ago
config: um-randconfig-r013-20210330 (attached as .config
Hi Casev:
A quote from the listen(2) man page on my Ubuntu system:
The backlog argument defines the maximum length to which
the queue of pending connections for sockfd may grow.
I think this implies that the 'backlog' must be greater than zero.
In the test source file
On Wed, 31 Mar 2021 01:52:59 +
HORIGUCHI NAOYA(堀口 直也) wrote:
> On Fri, Mar 26, 2021 at 03:22:49PM +0100, David Hildenbrand wrote:
> > On 26.03.21 15:09, David Hildenbrand wrote:
> > > On 22.03.21 12:33, Aili Yao wrote:
> > > > When we do coredump for user process signal, this may be one
On Tue, 30 Mar 2021 10:49:47 +0800 Ong Boon Leong wrote:
> + if (!skb) {
> + dma_sync_single_for_cpu(priv->device, buf->addr,
> + buf1_len, dma_dir);
> +
> + xdp.data = page_address(buf->page) +
On 3/29/21 7:21 PM, Muchun Song wrote:
> On Tue, Mar 30, 2021 at 7:24 AM Mike Kravetz wrote:
>>
>> With the introduction of remove_hugetlb_page(), there is no need for
>> update_and_free_page to hold the hugetlb lock. Change all callers to
>> drop the lock before calling.
>>
>> With additional
struct stmmac_safety_stats is declared twice. One has been
declared at 29th line. Remove the duplicate.
Signed-off-by: Wan Jiabing
---
drivers/net/ethernet/stmicro/stmmac/hwif.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h
1 - 100 of 1503 matches
Mail list logo
