> From: Andy Lutomirski
> > diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
> > @@ -518,3 +518,40 @@ int fpu__exception_code(struct fpu *fpu, int trap_nr)
..
> > +bool xfirstuse_event_handler(struct fpu *fpu)
> > +{
> > + bool handled = false;
> > + u64
Hit a warning:
WARNING: CPU: 1 PID: 241 at kernel/workqueue.c:1627
__queue_delayed_work+0x6d/0x90
with trace:
mod_delayed_work_on+0x59/0x90
nvmet_update_cc+0xee/0x100 [nvmet]
nvmet_execute_prop_set+0x72/0x80 [nvmet]
nvmet_tcp_try_recv_pdu+0x2f7/0x770 [nvmet_tcp]
Hi Diana,
On Tue, 13 Oct 2020 18:56:07 +0300 Diana Craciun OSS
wrote:
>
> Hi,
>
> How does it fail? What's the error?
Sorry about that:
drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c: In function
'vfio_fsl_mc_set_irq_trigger':
drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c:121:8: error: implicit
On 10/6/2020 6:20 AM, Daniel Lezcano wrote:
The dynamic thermal and power management is a technique to dynamically
adjust the power consumption of different devices in order to ensure a
global thermal constraint.
An userspace daemon is usually monitoring the temperature and the
power to take
On 10/13/2020 5:14 AM, Mauro Carvalho Chehab wrote:
> Changeset 410d06879c01 ("ice: add the DDP Track ID to devlink info")
> added description for a new devlink field, but forgot to add
> one of its columns, causing it to break:
>
> .../Documentation/networking/devlink/ice.rst:15:
>
> From: Andy Lutomirski
>
> > + /*
> > +* The caller may be under interrupt disabled condition. Ensure
> > interrupt
> > +* allowance before the memory allocation, which may involve with
> > page faults.
> > +*/
> > + local_irq_enable();
> ... you can't
On 13/10/2020 09:48, Hans de Goede wrote:
> On 10/12/20 9:39 PM, Enrico Weigelt, metux IT consult wrote:
>> On 22.09.20 00:17, Ed W wrote:
>>> Hi, I've been adding support for the PC Engines APU5 board, which is a
>>> variant of the APU 2-4
>>> boards
>>> with some nice features. The current
On 12/10/2020 20:39, Enrico Weigelt, metux IT consult wrote:
> On 22.09.20 00:17, Ed W wrote:
>> Hi, I've been adding support for the PC Engines APU5 board, which is a
>> variant of the APU 2-4 boards
>> with some nice features. The current platform driver for pcengines boards
>> has some
Hi Dan,
On Tue, Oct 13, 2020 at 01:03:13PM -0500, Dan Murphy wrote:
> On 10/9/20 7:12 AM, Dan Murphy wrote:
> > Fix the issue when 'i' is equal to array size then array index over
> > runs the array when checking for the watch dog value.
> >
> > This also fixes the uninitialized wd_reg_val if
On Tue, Oct 13, 2020 at 10:09:25PM +0100, Al Viro wrote:
> On Tue, Oct 13, 2020 at 04:06:08PM +0200, Giuseppe Scrivano wrote:
> > + spin_lock(_fds->file_lock);
> > + fdt = files_fdtable(cur_fds);
> > + cur_max = fdt->max_fds - 1;
> > + max_fd = min(max_fd,
On Tue, 13 Oct 2020 10:00:58 +0800
Tian Tao wrote:
> It is redundant to do irqsave and irqrestore in hardIRQ context.
But this function is also called from non-IRQ context. Thanks,
Alex
> Signed-off-by: Tian Tao
> ---
> drivers/vfio/platform/vfio_platform_irq.c | 5 ++---
> 1 file
Hi Dan,
On Tue, Oct 13, 2020 at 01:03:52PM -0500, Dan Murphy wrote:
> On 10/9/20 9:41 AM, Dan Murphy wrote:
> > Add the bindings for the bq25790.
>
> Also any updates on this series?
Sorry, It's not gonna make it into this merge window. I did not
yet fully review it and merge window is already
syzbot has found a reproducer for the following issue on:
HEAD commit:64a632da net: fec: Fix phy_device lookup for phy_reset_aft..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=11580c8050
kernel config:
Dne petek, 09. oktober 2020 ob 09:36:51 CEST je Maxime Ripard napisal(a):
> On Thu, Oct 08, 2020 at 10:00:06PM +0200, Clément Péron wrote:
> > Hi Maxime,
> >
> > Adding linux-sunxi and Jernej Skrabec to this discussion.
> >
> > On Thu, 8 Oct 2020 at 17:10, Maxime Ripard wrote:
> > >
> > > Hi
On Tue, Oct 13, 2020 at 11:04:21PM +0200, Rasmus Villemoes wrote:
> On 13/10/2020 22.54, Christian Brauner wrote:
> > On Tue, Oct 13, 2020 at 04:06:08PM +0200, Giuseppe Scrivano wrote:
> >
> > Hey Guiseppe,
> >
> > Thanks for the patch!
> >
> >> When the flag CLOSE_RANGE_CLOEXEC is set,
Hi,
On 13.10.2020 22:54, Jiri Olsa wrote:
> On Mon, Oct 12, 2020 at 11:54:24AM +0300, Alexey Budankov wrote:
>>
>> Output path of a trace file into raw dump (-D) @.
>> Print offset of PERF_RECORD_COMPRESSED record instead of zero for
>> decompressed records:
>> 0x22...@perf.data [0x30]: event:
On Tue, Oct 13, 2020 at 11:19:43AM +0800, Jinyang He wrote:
> Commit e7ae8d174eec ("MIPS: replace add_memory_region with memblock")
this commit just changed code and doesn't change the problem you want to
solve.
> replaced add_memory_region(, , BOOT_MEM_RAM) with memblock_add(). But
> it doesn't
On Tue, Oct 13, 2020 at 04:06:08PM +0200, Giuseppe Scrivano wrote:
> + spin_lock(_fds->file_lock);
> + fdt = files_fdtable(cur_fds);
> + cur_max = fdt->max_fds - 1;
> + max_fd = min(max_fd, cur_max);
> + while (fd <= max_fd)
> +
On Tue, Oct 13, 2020 at 01:49:01PM -0600, Jens Axboe wrote:
> On 10/13/20 1:46 PM, Linus Torvalds wrote:
> > On Mon, Oct 12, 2020 at 6:46 AM Jens Axboe wrote:
> >>
> >> Here are the io_uring updates for 5.10.
> >
> > Very strange. My clang build gives a warning I've never seen before:
> >
> >
On 13/10/2020 22.54, Christian Brauner wrote:
> On Tue, Oct 13, 2020 at 04:06:08PM +0200, Giuseppe Scrivano wrote:
>
> Hey Guiseppe,
>
> Thanks for the patch!
>
>> When the flag CLOSE_RANGE_CLOEXEC is set, close_range doesn't
>> immediately close the files but it sets the close-on-exec bit.
>
On 10/13/20 2:49 PM, Rasmus Villemoes wrote:
> On 13/10/2020 21.49, Jens Axboe wrote:
>> On 10/13/20 1:46 PM, Linus Torvalds wrote:
>>> On Mon, Oct 12, 2020 at 6:46 AM Jens Axboe wrote:
Here are the io_uring updates for 5.10.
>>>
>>> Very strange. My clang build gives a warning I've
On Tue, Oct 13, 2020 at 04:06:08PM +0200, Giuseppe Scrivano wrote:
Hey Guiseppe,
Thanks for the patch!
> When the flag CLOSE_RANGE_CLOEXEC is set, close_range doesn't
> immediately close the files but it sets the close-on-exec bit.
Hm, please expand on the use-cases a little here so people
On Tue, Oct 13, 2020 at 12:25:44PM +0100, Christoph Hellwig wrote:
> > - kaddr = kmap(pp);
> > + kaddr = kmap_thread(pp);
> > memcpy(kaddr, vip->vii_immed.vi_immed + offset, PAGE_SIZE);
> > - kunmap(pp);
> > + kunmap_thread(pp);
>
> You only Cced me on this particular patch, which
On Tue, Oct 13, 2020 at 09:01:49PM +0100, Al Viro wrote:
> On Tue, Oct 13, 2020 at 08:36:43PM +0100, Matthew Wilcox wrote:
>
> > static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned
> > int size)
> > {
> > char *vto = kmap_atomic(to);
> >
> > memcpy(vto, vfrom,
On 13/10/2020 21.49, Jens Axboe wrote:
> On 10/13/20 1:46 PM, Linus Torvalds wrote:
>> On Mon, Oct 12, 2020 at 6:46 AM Jens Axboe wrote:
>>>
>>> Here are the io_uring updates for 5.10.
>>
>> Very strange. My clang build gives a warning I've never seen before:
>>
>>
Hi Fabrizio,
Thank you for the patch.
On Tue, Oct 13, 2020 at 04:01:49PM +0100, Fabrizio Castro wrote:
> The r8a77965 (a.k.a. R-Car M3-N) device tree schema is
> compatible with the already documented R-Car Gen3 devices.
>
> Document r8a77965 support within renesas,drif.yaml.
>
>
On Tue, Oct 13, 2020 at 01:39:01PM -0700, Linus Torvalds wrote:
> Actually, I think you forgot to push out the updated thing, I still
> see the same contents of the pull.
Blergh, that tag is still pointing to the old branch:
Em Tue, 13 Oct 2020 09:34:04 -0700
"Paul E. McKenney" escreveu:
> On Tue, Oct 13, 2020 at 01:54:25PM +0200, Mauro Carvalho Chehab wrote:
> > Changeset 53c72b590b3a ("rcu/tree: cache specified number of objects")
> > added new members for struct kfree_rcu_cpu, but didn't add the
> > corresponding
On Tue, Oct 13, 2020 at 08:36:43PM +0100, Matthew Wilcox wrote:
> On Tue, Oct 13, 2020 at 11:44:29AM -0700, Dan Williams wrote:
> > On Fri, Oct 9, 2020 at 12:52 PM wrote:
> > >
> > > From: Ira Weiny
> > >
> > > The kmap() calls in this FS are localized to a single thread. To avoid
> > > the
The pull request you sent on Mon, 12 Oct 2020 13:05:57 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> tags/x86_asm_for_v5.10
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/029f56db6ac248769f2c260bfaf3c3c0e23e904c
Thank you!
--
Deet-doot-dot,
On Tue, 2020-10-13 at 22:41 +0200, Mauro Carvalho Chehab wrote:
> Em Tue, 13 Oct 2020 20:47:47 +0200
> Johannes Berg escreveu:
>
> > Thanks Mauro.
> >
> >
> > On Tue, 2020-10-13 at 13:54 +0200, Mauro Carvalho Chehab wrote:
> > > Changeset df78a0c0b67d ("nl80211: S1G band and channel
The 'reason' variable in module_sig_check() points to 3 strings across
the *switch* statement, all needlessly starting with the same text. Let's
put as much of the starting text as we can into the pr_notice() call (this
includes some rewording of the 1st message) -- it saves 37 bytes of object
The way the comments in the *switch* statement in module_sig_check() are
indented, it may seem they refer to the statements above them, not below.
Align the comments with the *case* and *default* labels below them, fixing
the comment style and adding article/dash, while at it...
Signed-off-by:
Em Tue, 13 Oct 2020 20:47:47 +0200
Johannes Berg escreveu:
> Thanks Mauro.
>
>
> On Tue, 2020-10-13 at 13:54 +0200, Mauro Carvalho Chehab wrote:
> > Changeset df78a0c0b67d ("nl80211: S1G band and channel definitions")
> > added a new parameter, but didn't add the corresponding kernel-doc
> >
On Tue, Oct 13, 2020 at 2:42 AM Borislav Petkov wrote:
>
> here's v2 of the x86/asm pull with only the __force_order patch so that
> it can go in now. The other one will be sorted out when the matter has
> been settled properly.
Actually, I think you forgot to push out the updated thing, I still
Here are 2 patches against the 'modules-next' branch of Jessica Yu's
'linux.git' repo.
I'm doing some little refactoring in module_sig_check()...
[1/2] module: merge repetitive strings in module_sig_check()
[2/2] module: unindent comments in module_sig_check()
Oops, hadn't finished the subject... :-/\
Here are 2 patches against the 'modules-next' branch of Jessica Yu's
'linux.git' repo.
I'm doing some little refactoring in module_sig_check()...
[1/2] module: merge repetitive strings in module_sig_check()
[2/2] module: unindent comments in module_sig_check()
The pull request you sent on Mon, 12 Oct 2020 07:48:15 -0600:
> git://git.kernel.dk/linux-block.git tags/libata-5.10-2020-10-12
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/79ec6d9cac46d59db9b006bc9cde2811ef365292
Thank you!
--
Deet-doot-dot, I am a bot.
Apologies, Sean.
I thought I had replied to this but found it instead in my drafts folder...
I've taken much of your feedback and incorporated that into the next
version of the patches that I submitted and updated this response based on
that, too.
On 9/15/20 7:19 PM, Sean Christopherson wrote:
Hi Yun,
On 12/10/2020 18:31, Yun Hsiang wrote:
> If the user wants to stop controlling uclamp and let the task inherit
> the value from the group, we need a method to reset.
>
> Add SCHED_FLAG_UTIL_CLAMP_RESET flag to allow the user to reset uclamp via
> sched_setattr syscall.
before we decide
Hello Johan,
On 10/13/20 7:34 PM, Johan Jonker wrote:
> Part 1 of 2 missing here.
Please complain to gmail then, given that patch 1 can be found on
https://lore.kernel.org/linux-arm-kernel/20201013161340.720403-2-...@kleine-koenig.org/.
> Submit all patches to all maintainers and mail lists.
>
On Mon, Oct 5, 2020 at 5:18 PM Atish Patra wrote:
>
> This series attempts to move the ARM64 numa implementation to common
> code so that RISC-V can leverage that as well instead of reimplementing
> it again.
>
> RISC-V specific bits are based on initial work done by Greentime Hu [1] but
>
It was <2020-04-30 czw 18:31>, when Łukasz Stelmach wrote:
> The value of kbuf->memsz may be different than kbuf->bufsz after calling
> kexec_add_buffer(). Hence both values should be logged.
>
> Fixes: ec2b9bfaac44e ("kexec_file: Change kexec_add_buffer to take kexec_buf
> as argument.")
>
On Tue, 13 Oct 2020, Jinyang He wrote:
> Commit e7ae8d174eec ("MIPS: replace add_memory_region with memblock")
> replaced add_memory_region(, , BOOT_MEM_RAM) with memblock_add(). But
> it doesn't work well on some platforms which have NUMA like Loongson64.
Please note this is not a full review,
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
f8eb8d1c6a853f617ca9ee233bb2d230401c5bdc
Hello!
On Monday 12 October 2020 12:46:32 Jerome Pouiller wrote:
> +#define SDIO_VENDOR_ID_SILABS0x
> +#define SDIO_DEVICE_ID_SILABS_WF200 0x1000
> +static const struct sdio_device_id wfx_sdio_ids[] = {
> + { SDIO_DEVICE(SDIO_VENDOR_ID_SILABS, SDIO_DEVICE_ID_SILABS_WF200) },
On Tue, 2020-10-13 at 15:57 -0400, Vivek Goyal wrote:
> Hmm..., So how do I reproduce it. Just run trinity as root and it will
> reproduce after some time?
Only need to run it as unprivileged user after mounting virtiofs on /tmp
(trinity will need to create and use files there) as many as CPUs as
Hi Linus,
Please pull the following Kselftest fixes update for Linux 5.10-rc1.
This kselftest fixes update consists of a selftests harness fix to
flush stdout before forking to avoid parent and child printing
duplicates messages. This is evident when test output is redirected
to a file.
The
On Fri, Oct 09, 2020 at 04:24:55PM -0700, Todd Kjos wrote:
> When releasing a thread todo list when tearing down
> a binder_proc, the following race was possible which
> could result in a use-after-free:
>
> 1. Thread 1: enter binder_release_work from binder_thread_release
> 2. Thread 2:
On Sat, Oct 10, 2020 at 12:19:14AM -0700, Andrei Vagin wrote:
> On Fri, Oct 09, 2020 at 03:28:15PM +0200, Christian Brauner wrote:
> > On Thu, Oct 08, 2020 at 07:39:42AM +0200, Michael Weiß wrote:
> > > getboottime64() provides the time stamp of system boot. In case of
> > > time namespaces, the
It was <2020-10-02 pią 22:36>, when Andrew Lunn wrote:
>> +static u32 ax88796c_get_link(struct net_device *ndev)
>> +{
>> +struct ax88796c_device *ax_local = to_ax88796c_device(ndev);
>> +
>> +mutex_lock(_local->spi_lock);
>> +
>> +phy_read_status(ndev->phydev);
>> +
>> +
It was <2020-10-03 sob 14:59>, when Heiner Kallweit wrote:
> On 02.10.2020 21:22, Łukasz Stelmach wrote:
>> ASIX AX88796[1] is a versatile ethernet adapter chip, that can be
>> connected to a CPU with a 8/16-bit bus or with an SPI. This driver
>> supports SPI connection.
>>
>> The driver has been
On Tue, Oct 13, 2020 at 08:36:43PM +0100, Matthew Wilcox wrote:
> static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned
> int size)
> {
> char *vto = kmap_atomic(to);
>
> memcpy(vto, vfrom, size);
> kunmap_atomic(vto);
> }
>
> in linux/highmem.h ?
You
gt; > [10580.142571][ T348] INFO: task trinity-c36:254165 blocked for more than
> > 123
> > +seconds.
> > [10580.143924][ T348] Tainted: G O 5.9.0-next-20201013+ #2
> > [10580.145158][ T348] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
On Mon, Oct 12, 2020 at 11:54:24AM +0300, Alexey Budankov wrote:
>
> Output path of a trace file into raw dump (-D) @.
> Print offset of PERF_RECORD_COMPRESSED record instead of zero for
> decompressed records:
> 0x22...@perf.data [0x30]: event: 9
> or
> 0x15c...@perf.data/data.7 [0x30]:
3
> +seconds.
> [10580.143924][ T348] Tainted: G O5.9.0-next-20201013+ #2
> [10580.145158][ T348] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> +disables this message.
> [10580.146636][ T348] task:trinity-c36 state:D stack:26704 pid:
On Tue, Oct 13, 2020 at 12:49 PM Jens Axboe wrote:
>
> What clang are you using?
I have a self-built clang version from their development tree, since
I've been using it for the "asm goto with outputs" testing.
But I bet this happens with just regular reasonably up-to-date clang too.
On 10/13/20 1:46 PM, Linus Torvalds wrote:
> On Mon, Oct 12, 2020 at 6:46 AM Jens Axboe wrote:
>>
>> Here are the io_uring updates for 5.10.
>
> Very strange. My clang build gives a warning I've never seen before:
>
>/tmp/io_uring-dd40c4.s:26476: Warning: ignoring changed section
>
wait, I think there's some confusion here. these patches have already been
pushed
On Tue, 2020-10-13 at 14:14 +0200, Mauro Carvalho Chehab wrote:
> The name of the argument is different, causing those warnings:
>
> ./drivers/gpu/drm/drm_edid.c:3754: warning: Function parameter or member
>
From: "Steven Rostedt (VMware)"
After having a typo for writing a histogram trigger.
Wrote:
echo 'hist:key=pid:ts=common_timestamp.usec' >
events/sched/sched_waking/trigger
Instead of:
echo 'hist:key=pid:ts=common_timestamp.usecs' >
events/sched/sched_waking/trigger
and the following
On Tue, 2020-10-13 at 19:17 +0200, Pavel Machek wrote:
> On Mon 2020-10-05 19:41:15, Joe Perches wrote:
> > This doesn't seem like a great idea to me.
> >
> > For my system I've got:
> >
> > /sys/devices/platform/Fixed MDIO bus.0/
> > /sys/bus/platform/drivers/int3401 thermal/
> >
The pull request you sent on Tue, 13 Oct 2020 19:36:15 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> tags/x86_urgent_for_v5.10-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/857d64485e7c920364688a8a6dd0ffe5774327b6
Thank you!
--
On Mon, Oct 12, 2020 at 6:46 AM Jens Axboe wrote:
>
> Here are the io_uring updates for 5.10.
Very strange. My clang build gives a warning I've never seen before:
/tmp/io_uring-dd40c4.s:26476: Warning: ignoring changed section
attributes for .data..read_mostly
and looking at what clang
The pull request you sent on Mon, 12 Oct 2020 07:46:45 -0600:
> git://git.kernel.dk/linux-block.git tags/io_uring-5.10-2020-10-12
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6ad4bf6ea1609fb539a62f10fca87ddbd53a0315
Thank you!
--
Deet-doot-dot, I am a bot.
On 10/07/2020 17.57, Matthew Wilcox wrote:
> On Fri, Jul 10, 2020 at 09:56:31AM +0200, Rasmus Villemoes wrote:
>> The ability to check open file descriptions for equality (without
>> resorting to unreliable fstat() and fcntl(F_GETFL) comparisons) can be
>> useful outside of the checkpoint/restore
On Tue, Oct 13, 2020 at 10:46:16AM -0700, Dave Hansen wrote:
> On 10/9/20 12:42 PM, ira.we...@intel.com wrote:
> > Protection Keys User (PKU) and Protection Keys Supervisor (PKS) work
> > in similar fashions and can share common defines.
>
> Could we be a bit less abstract? PKS and PKU each
On Fri, 9 Oct 2020, Axel Rasmussen wrote:
> It's common [1] to define tracepoint fields as "bool" when they contain
> a true / false value. Currently, defining a synthetic event with a
> "bool" field yields EINVAL. It's possible to work around this by using
> e.g. u8 (assuming sizeof(bool) is 1,
On Fri, 9 Oct 2020, Axel Rasmussen wrote:
> The goal of these tracepoints is to be able to debug lock contention
> issues. This lock is acquired on most (all?) mmap / munmap / page fault
> operations, so a multi-threaded process which does a lot of these can
> experience significant contention.
>
On Tue, Oct 13, 2020 at 12:37 PM Matthew Wilcox wrote:
>
> On Tue, Oct 13, 2020 at 11:44:29AM -0700, Dan Williams wrote:
> > On Fri, Oct 9, 2020 at 12:52 PM wrote:
> > >
> > > From: Ira Weiny
> > >
> > > The kmap() calls in this FS are localized to a single thread. To avoid
> > > the over head
On 10/12/20 11:27 AM, Miroslav Benes wrote:
> On Sat, 10 Oct 2020, Jens Axboe wrote:
>
>> On 10/9/20 9:21 AM, Jens Axboe wrote:
>>> On 10/9/20 2:01 AM, Miroslav Benes wrote:
On Thu, 8 Oct 2020, Oleg Nesterov wrote:
> On 10/05, Jens Axboe wrote:
>>
>> Hi,
>>
>> The
On Tue, Oct 13, 2020 at 11:44:29AM -0700, Dan Williams wrote:
> On Fri, Oct 9, 2020 at 12:52 PM wrote:
> >
> > From: Ira Weiny
> >
> > The kmap() calls in this FS are localized to a single thread. To avoid
> > the over head of global PKRS updates use the new kmap_thread() call.
> >
> > Cc:
On Tue, 2020-10-13 at 22:25 +0300, Jarkko Sakkinen wrote:
> On Tue, Oct 13, 2020 at 08:30:38AM -0700, Joe Perches wrote:
> > On Tue, 2020-10-13 at 13:46 +0300, Jarkko Sakkinen wrote:
> > > Use korg address as the main communications end point. Update the
> > > corresponding M-entries.
> >
> >
7146] Object f360132d: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b 6b 6b a5 kkk.
[19611.953114][T1717146] Redzone 83758aaa: bb bb bb bb bb bb bb bb
[19611.953146][T1717146] Padding cbb228a2: 5a 5a 5a 5a 5a 5a 5a 5a 5a
5a
On Tue, Oct 13, 2020 at 09:26:50AM -0700, Paul E. McKenney wrote:
> On Tue, Oct 13, 2020 at 01:25:44PM +0200, Peter Zijlstra wrote:
> > On Tue, Oct 13, 2020 at 12:44:50PM +0200, Peter Zijlstra wrote:
> > > On Tue, Oct 13, 2020 at 12:34:06PM +0200, Peter Zijlstra wrote:
> > > > On Mon, Oct 12, 2020
On Tue, 13 Oct 2020, Muchun Song wrote:
> Since commit:
>
> 991e7673859e ("mm: memcontrol: account kernel stack per node")
>
> There is no user of the mod_memcg_obj_state(). This patch just remove
> it. Also rework type of the idx parameter of the mod_objcg_state()
> from int to enum
On Tue, Oct 13, 2020 at 02:08:45PM -0500, David Lechner wrote:
> On 10/13/20 1:58 PM, William Breathitt Gray wrote:
> > On Mon, Oct 12, 2020 at 12:04:10PM -0500, David Lechner wrote:
> >> On 10/8/20 7:28 AM, William Breathitt Gray wrote:
> >>> On Thu, Oct 08, 2020 at 10:09:09AM +0200, Pavel Machek
Passing build_id object to dso__set_build_id, so it's easier
to initialize dos's build id object.
Acked-by: Ian Rogers
Signed-off-by: Jiri Olsa
---
tools/perf/util/dso.c| 4 ++--
tools/perf/util/dso.h| 2 +-
tools/perf/util/header.c | 4 +++-
We do not store size with build ids in perf data,
but there's enough space to do it. Adding misc bit
PERF_RECORD_MISC_BUILD_ID_SIZE to mark build id event
with size.
With this fix the dso with md5 build id will have correct
build id data and will be usable for debuginfod processing
if needed
Passing build_id object to dso__build_id_equal, so we can
properly check build id with different size than sha1.
Acked-by: Ian Rogers
Signed-off-by: Jiri Olsa
---
tools/perf/util/dso.c| 5 +++--
tools/perf/util/dso.h| 2 +-
tools/perf/util/symbol-elf.c | 8 ++--
With shorter md5 build ids we need to align their
paths properly with other build ids:
$ perf buildid-list
17f4e448cc746582ea1881528deb549f7fdb3fd5 [kernel.kallsyms]
a50e350e97c43b4708d09bcd85ebfff7 .../tools/perf/buildid-ex-md5
1805c738c8f3ec0f47b7ea09080c28f34d18a82b
On Tue, Oct 13, 2020 at 08:30:38AM -0700, Joe Perches wrote:
> On Tue, 2020-10-13 at 13:46 +0300, Jarkko Sakkinen wrote:
> > Use korg address as the main communications end point. Update the
> > corresponding M-entries.
>
> Maybe add an equivalent entry to .mailmap?
Ugh, neither has
Adding test for build id cache that adds binary
with sha1 and md5 build ids and verifies it's
added properly.
The test updates build id cache with perf record
and perf buildid-cache -a.
Acked-by: Ian Rogers
Signed-off-by: Jiri Olsa
---
tools/perf/tests/shell/buildid.sh | 101
Passing build id object to sysfs__read_build_id function,
so it can populate the size of the build_id object.
Acked-by: Ian Rogers
Signed-off-by: Jiri Olsa
---
tools/perf/util/build-id.c | 6 +++---
tools/perf/util/dso.c| 6 ++
tools/perf/util/symbol-elf.c | 11
Replace build_id byte array with struct build_id
object and all the code that references it.
The objective is to carry size together with build
id array, so it's better to keep both together.
This is preparatory change for following patches,
and there's no functional change.
Acked-by: Ian
Passing build_id object to filename__read_build_id function,
so it can populate the size of the build_id object.
Changing filename__read_build_id code for both elf/non-elf
code.
Acked-by: Ian Rogers
Signed-off-by: Jiri Olsa
---
tools/perf/bench/inject-buildid.c | 2 +-
Passing build_id object to build_id__sprintf function,
so it can operate with the proper size of build id.
This will create proper md5 build id readable names,
like following:
a50e350e97c43b4708d09bcd85ebfff7
instead of:
a50e350e97c43b4708d09bcd85ebfff7
Acked-by: Ian Rogers
Reviewed-by: Lyude Paul
Thanks for the fixes! I will go ahead and push 11 and 12 to drm-misc-next.
On Tue, 2020-10-13 at 14:14 +0200, Mauro Carvalho Chehab wrote:
> The name of the argument is different, causing those warnings:
>
> ./drivers/gpu/drm/drm_edid.c:3754: warning: Function
hi,
currently we support only one storage size (20 bytes) for build
ids. That fits for SHA1 build ids, but there can in theory be
any size. The gcc linker supports also MD5, which is 16 bytes.
Currently the MD5 build id will be stored in .debug cache with
additional zeros, like:
$ find
On 10/13/2020 11:10 PM, m...@chromium.org wrote:
On Tue, Oct 13, 2020 at 07:23:34PM +0530, Akhil P Oommen wrote:
On 10/12/2020 11:10 PM, m...@chromium.org wrote:
On Mon, Oct 12, 2020 at 07:03:51PM +0530, Akhil P Oommen wrote:
On 10/10/2020 12:06 AM, m...@chromium.org wrote:
Hi Akhil,
On
On Tue, 13 Oct 2020 18:06:51 +0300
Diana Craciun wrote:
> The FSL_MC_BUS on which the VFIO-FSL-MC driver is dependent on
> can be compiled on other architectures as well (not only ARM64)
> including 32 bit architectures.
> Include linux/io-64-nonatomic-hi-lo.h to make writeq/readq used
> in the
Reviewed-by: Lyude Paul
On Tue, 2020-10-13 at 14:14 +0200, Mauro Carvalho Chehab wrote:
> As warned by kernel-doc:
>
> ./drivers/gpu/drm/drm_dp_helper.c:385: warning: Function parameter or
> member 'type' not described in 'drm_dp_downstream_is_type'
>
On Tue, 13 Oct 2020 18:56:07 +0300
Diana Craciun OSS wrote:
> Hi,
>
> How does it fail? What's the error?
>
> Thanks,
> Diana
>
>
> On 10/13/2020 6:07 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the vfio tree, today's linux-next build (x86_64
> > allmodconfig) failed like
I'm having a problem with both the 5.8 and 5.9 kernels using the nouveau DRM
driver. I have a laptop with a VGA card (specs below) connected to a 5120x1440
screen. At boot time, the card correctly detects the screen, tries to allocate
fbdev fb0, then the video hangs completely for 15-30 seconds
On Tue, Oct 13, 2020 at 01:13:40PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Sep 30, 2020 at 07:15:04PM +0200, Jiri Olsa escreveu:
> > Adding test for build id cache that adds binary
> > with sha1 and md5 build ids and verifies it's
> > added properly.
> >
> > The test updates build id
On 10/13/20 6:14 AM, Mauro Carvalho Chehab wrote:
> As reported by kernel-doc:
> ./include/linux/blk-mq.h:267: warning: Function parameter or member
> 'active_queues_shared_sbitmap' not described in 'blk_mq_tag_set'
>
> There is now a new member for struct blk_mq_tag_set. Add a
>
3
> +seconds.
> [10580.143924][ T348] Tainted: G O5.9.0-next-20201013+ #2
> [10580.145158][ T348] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> +disables this message.
> [10580.146636][ T348] task:trinity-c36 state:D stack:26704 pid:
Em Mon, Oct 12, 2020 at 08:59:36AM +1100, Stephen Rothwell escreveu:
> Hi all,
>
> On Fri, 9 Oct 2020 14:41:11 +0200 Jiri Olsa wrote:
> >
> > On Fri, Oct 09, 2020 at 02:25:23PM +0200, Vasily Gorbik wrote:
> > > Currently BUILD_BUG() macro is expanded to smth like the following:
> > >do {
> >
On 10/13/20 1:58 PM, William Breathitt Gray wrote:
On Mon, Oct 12, 2020 at 12:04:10PM -0500, David Lechner wrote:
On 10/8/20 7:28 AM, William Breathitt Gray wrote:
On Thu, Oct 08, 2020 at 10:09:09AM +0200, Pavel Machek wrote:
Hi!
+int main(void)
+{
+struct
Em Fri, Oct 09, 2020 at 02:41:11PM +0200, Jiri Olsa escreveu:
> On Fri, Oct 09, 2020 at 02:25:23PM +0200, Vasily Gorbik wrote:
> > Currently BUILD_BUG() macro is expanded to smth like the following:
> >do {
> >extern void __compiletime_assert_0(void)
> >
201 - 300 of 1032 matches
Mail list logo
