There are currently no tests for ALU64 shift operations when the shift
amount is 0. This adds 6 new tests to make sure they are equivalent
to a no-op. The x32 JIT had such bugs that could have been caught by
these tests.
Cc: Xi Wang
Signed-off-by: Luke Nelson
---
The current x32 BPF JIT does not correctly compile shift operations when
the immediate shift amount is 0. The expected behavior is for this to
be a no-op.
The following program demonstrates the bug. The expexceted result is 1,
but the current JITed code returns 2.
r0 = 1
r1 = 1
r1 <<= 0
The current x32 BPF JIT for shift operations is not correct when the
shift amount in a register is 0. The expected behavior is a no-op, whereas
the current implementation changes bits in the destination register.
The following example demonstrates the bug. The expected result of this
program is
From: Guo Ren
These codes are copied from glibc/string directory, they are the generic
implementation for string operations. We may further optimize them with
assembly code in the future.
In fact these code isn't tested enough for kernel, but we've tested them
on glibc and it seems good. We
Removed duplicate headers which are included twice.
Signed-off-by: Souptick Joarder
Reviewed-by: Mukesh Ojha
---
tools/perf/util/data.c | 1 -
tools/perf/util/get_current_dir_name.c | 1 -
tools/perf/util/stat-display.c | 1 -
3 files changed, 3 deletions(-)
diff --git
On Sat, Jun 29, 2019 at 05:08:44AM +0100, Al Viro wrote:
> > The reason we don't hit that problem with regular memory shrinker is
> > this:
> > unregister_shrinker(>s_shrink);
> > fs->kill_sb(s);
> > in deactivate_locked_super(). IOW, shrinker for this fs is gone
>
On Thu, Apr 11, 2019 at 10:02:00PM +0100, Al Viro wrote:
> Aaaarrgghhh... No, we can't. Look: we get one candidate dentry in isolate
> phase. We put it into shrink list. umount(2) comes and calls
> shrink_dcache_for_umount(), which calls shrink_dcache_parent(root).
> In the meanwhile,
On 2019/6/28 3:52, Atish Patra wrote:
> Both RISC-V & ARM64 are using cpu-map device tree to describe
> their cpu topology. It's better to move the relevant code to
> a common place instead of duplicate code.
>
> To: Will Deacon
> To: Catalin Marinas
Using Cc: is better.
> Signed-off-by:
Hi,
This patch breaks rcar-vin. I'm sorry I did not find out before it was
merged as a8fa55078a7784a9 ("media: v4l2-subdev: Verify arguments in
v4l2_subdev_call()").
The problem is that rcar-vin calls enum_mbus_code in its bound callback.
At this point call_enum_mbus_code() is invoked which
To support CPU hotplug, we need to implement 'acpi_(un)map_cpu()' and
'arch_(un)register_cpu()' for ARM64. These functions are called in
'acpi_processor_hotadd_init()/acpi_processor_remove()' when the CPU is hot
added into or hot removed from the system.
Signed-off-by: Xiongfeng Wang
---
When we scan all the acpi namespace node in
acpi_scan_init()->acpi_bus_scan(), we evaluate '_STA' method for processor
type node to determine whether the device is present. But processors can
also be declared via ASL Device statement. ACPI 6.3 spec specifically
says that the Processor statement is
We set 'cpu_possible_mask' based on the enabled GICC node in MADT. If
the GICC node is disabled, we will skip initializing the kernel data
structure for that CPU.
To support CPU hotplug, we need to initialize some CPU related data
structure in advance. This patch mark all the GICC nodes as
This patchset mark all the GICC node in MADT as possible CPUs even though it
is disabled. But only those enabled GICC node are marked as present CPUs.
So that kernel will initialize some CPU related data structure in advance before
the CPU is actually hot added into the system. This patchset also
Remove duplicated include.
Signed-off-by: YueHaibing
---
sound/soc/codecs/cs47l35.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sound/soc/codecs/cs47l35.c b/sound/soc/codecs/cs47l35.c
index 511d0d6fa962..e3585c1dab3d 100644
--- a/sound/soc/codecs/cs47l35.c
+++
On 6/29/19 1:05 AM, David Ahern wrote:
> On 6/28/19 3:06 AM, Miaohe Lin wrote:
> > diff --git a/net/ipv6/netfilter/ip6t_rpfilter.c
> > b/net/ipv6/netfilter/ip6t_rpfilter.c
> > index 6bcaf7357183..3c4a1772c15f 100644
> > --- a/net/ipv6/netfilter/ip6t_rpfilter.c
> > +++
syzbot has bisected this bug to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend
Date: Sat Jun 30 13:17:47 2018 +
bpf: sockhash fix omitted bucket lock in sock_close
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=16aac819a0
start commit:
Sorry, the third patch can't be applied to the lastest kernel. I will send
another
version and attach the method to test this patchset.
On 2019/6/28 19:13, Xiongfeng Wang wrote:
> This patchset mark all the GICC node in MADT as possible CPUs even though it
> is disabled. But only those enabled
On Jun 28, 2019, at 3:55 PM, Sasha Levin wrote:
> What's the upstream commit id?
The commit wasn't needed upstream, as I only sent the original patch after
79e7fff47b7b ("net: remove support for per driver ndo_busy_poll()") had
made the fix unnecessary in Linus' tree.
May've gotten lost in the
On Fri, 10 May 2019 12:33:18 +0200
Sebastian Andrzej Siewior wrote:
> On 2019-05-09 14:33:20 [-0500], miny...@acm.org wrote:
> > From: Corey Minyard
> >
> > The function call do_wait_for_common() has a race condition that
> > can result in lockups waiting for completions. Adding the thread
>
If MTD_NAND_JZ4780 is y and MTD_NAND_JZ4780_BCH is m,
which select CONFIG_MTD_NAND_INGENIC_ECC to m, building fails:
drivers/mtd/nand/raw/ingenic/ingenic_nand.o: In function `ingenic_nand_remove':
ingenic_nand.c:(.text+0x177): undefined reference to `ingenic_ecc_release'
On 6/25/19 10:06 PM, Viresh Kumar wrote:
We try to find an idle CPU to run the next task, but in case we don't
find an idle CPU it is better to pick a CPU which will run the task the
soonest, for performance reason.
A CPU which isn't idle but has only SCHED_IDLE activity queued on it
should
On 2019/6/29 2:47, Willem de Bruijn wrote:
> On Fri, Jun 28, 2019 at 7:53 AM Huazhong Tan wrote:
>>
>> From: Yunsheng Lin
>>
>> Currently when TC num is one, the DCB will be disabled no matter if
>> pfc_en is non-zero or not.
>>
>> This patch enables the DCB if pfc_en is non-zero, even when TC
Hello Saravana,
On 6/27/19 7:22 PM, Saravana Kannan wrote:
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 04ad312fd85b..8d690fa0f47c 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -61,6 +61,72 @@ struct platform_device *of_find_device_by_node(struct
These changes are intended to make the RB_DECLARE_CALLBACKS macro
more generic (allowing the aubmented subtree information to be a struct
instead of a scalar) and tweak the macro arguments to be more similar
to INTERVAL_TREE_DEFINE().
Michel Lespinasse (2):
augmented rbtree: add comments for
- Change the definition of the RBCOMPUTE function. The propagate
callback repeatedly calls RBCOMPUTE as it moves from leaf to root.
it wants to stop recomputing once the augmented subtree information
doesn't change. This was previously checked using the == operator,
but that only works
Add a short comment summarizing the arguments to RB_DECLARE_CALLBACKS.
The arguments are also now capitalized. This copies the style of the
INTERVAL_TREE_DEFINE macro.
No functional changes in this commit, only comments and capitalization.
Signed-off-by: Michel Lespinasse
---
On Fri, Jun 28, 2019 at 10:55:14AM -0700, Guenter Roeck wrote:
> On Thu, Jun 27, 2019 at 12:53:38PM +0800, Wu Hao wrote:
> > This patch adds support for power management private feature under
> > FPGA Management Engine (FME). This private feature driver registers
> > a hwmon for power
Hi Heiko, Kishon,
I'll try to pick up this patch.
Some comments below, just for self-reference.
On Wed, 2019-06-26 at 12:32 -0300, Ezequiel Garcia wrote:
> On Wed, 2019-05-15 at 18:20 -0400, Gaël PORTAY wrote:
> > From: Enric Balletbo i Serra
> >
> > The OTG disconnection event is generated
Hi Enric,
On Fri, 28 Jun 2019 18:56:56 +0200 Enric Balletbo i Serra
wrote:
>
> Hmm, I just applied this patch on top of linux-next and it build with
> allmodconfig on x86_64
>
> I am wondering if the build was done without this commit, which is in
> chrome-platform for-next branch. Could be
His e-mail address @imgtec.com is no more, and when I contacted him
on his private email about it, he told me to drop him from MAINTAINERS.
Signed-off-by: Paul Cercueil
---
MAINTAINERS | 5 -
1 file changed, 5 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index
Hi Suwan,
On 6/21/19 11:45 AM, Suwan Kim wrote:
vhci doesn’t do dma for remote device. Actually, the real dma
operation is done by network card driver. So, vhci doesn’t use and
need dma address of transfer buffer of urb.
When vhci supports SG, it is useful to use native SG list instead
of
Hi Linus,
Please pull some fixes for ARC.
Thx,
-Vineet
->
The following changes since commit d1fdb6d8f6a4109a4263176c84b899076a5f8008:
Linux 5.2-rc4 (2019-06-08 20:24:46 -0700)
are available in the git repository at:
On Fri, Jun 28, 2019 at 07:12:41PM -0400, Joel Fernandes wrote:
> On Fri, Jun 28, 2019 at 03:25:47PM -0700, Paul E. McKenney wrote:
> > On Fri, Jun 28, 2019 at 05:40:18PM -0400, Joel Fernandes wrote:
> > > Hi Paul,
> > >
> > > On Fri, Jun 28, 2019 at 01:04:23PM -0700, Paul E. McKenney wrote:
> >
One simple fix for a driver use after free.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Jan Kara (1):
scsi: vmw_pscsi: Fix use-after-free in pvscsi_queue_lck()
And the diffstat:
drivers/scsi/vmw_pvscsi.c |
On 6/28/19 3:38 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20190627:
>
on x86_64:
when CONFIG_OF is not set/enabled, but
CONFIG_NVMEM_REBOOT_MODE=m selects REBOOT_MODE:
CC [M] drivers/power/reset/reboot-mode.o
../drivers/power/reset/reboot-mode.c: In function
On Fri, Jun 28, 2019 at 10:32:01AM -0400, Johannes Weiner wrote:
> On Fri, Jun 28, 2019 at 07:16:27PM +0800, Kuo-Hsin Yang wrote:
> > When file refaults are detected and there are many inactive file pages,
> > the system never reclaim anonymous pages, the file pages are dropped
> > aggressively
On Fri, Jun 28, 2019 at 10:22:52AM -0400, Johannes Weiner wrote:
> Hi Minchan,
>
> On Fri, Jun 28, 2019 at 03:51:38PM +0900, Minchan Kim wrote:
> > On Thu, Jun 27, 2019 at 02:41:23PM -0400, Johannes Weiner wrote:
> > > On Wed, Jun 19, 2019 at 04:08:35PM +0800, Kuo-Hsin Yang wrote:
> > > > Fixes:
writes:
> From: Ryder Lee
>
> This adds basic support for MT7629 reference board.
>
> Signed-off-by: Ryder Lee
Just noticing this is not upstream yet.
I did a basic boot test to ramdisk on the mt7629-rfb board donated for
kernelCI (thanks MediaTek!) and it boots just fine.
Tested-by: Kevin
On Fri, Jun 28, 2019 at 03:25:47PM -0700, Paul E. McKenney wrote:
> On Fri, Jun 28, 2019 at 05:40:18PM -0400, Joel Fernandes wrote:
> > Hi Paul,
> >
> > On Fri, Jun 28, 2019 at 01:04:23PM -0700, Paul E. McKenney wrote:
> > [snip]
> > > > > > Commit
> > > > > > - 23634ebc1d946 ("rcu: Check for
From: Andi Kleen
perf stat -M metrics relies on weak groups to reject unschedulable groups
and run them as non-groups.
This uses the group validation code in the kernel. Unfortunately
that code doesn't take pinned events, such as the NMI watchdog, into
account. So some groups can pass
On 6/28/19 5:05 AM, Dmitry Osipenko wrote:
28.06.2019 14:56, Dmitry Osipenko пишет:
28.06.2019 5:12, Sowjanya Komatineni пишет:
This patch adds support for Tegra pinctrl driver suspend and resume.
During suspend, context of all pinctrl registers are stored and
on resume they are all
On 6/18/19 9:16 AM, Vineet Gupta wrote:
> On 6/14/19 9:41 AM, Eugeniy Paltsev wrote:
>> Implement jump label patching for ARC. Jump labels provide
>> an interface to generate dynamic branches using
>> self-modifying code.
>>
>> This allows us to implement conditional branches where
>> changing
On Wed, Jun 26, 2019 at 5:49 PM Sasha Levin wrote:
>
> From: Takashi Iwai
>
> [ Upstream commit 685c9b7750bfacd6fc1db50d86579980593b7869 ]
>
> Currently mwifiex_update_bss_desc_with_ie() implicitly assumes that
> the source descriptor entries contain the enough size for each type
> and performs
On Fri, Jun 28, 2019 at 06:34:58PM +0200, Matteo Croce wrote:
Hi,
Is there any reason for this panic fix not being applied in stable?
https://lore.kernel.org/netdev/20180313053248.13654-1-jelsas...@appneta.com/T/
What's the upstream commit id?
--
Thanks,
Sasha
Linus,
The following changes since commit 4b972a01a7da614b4796475f933094751a295a2f:
Linux 5.2-rc6 (2019-06-22 16:01:36 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
tags/riscv-for-v5.2/fixes-rc7
for you to fetch changes up to
On 6/28/19 4:54 AM, Srikar Dronamraju wrote:
* subhra mazumdar [2019-06-26 18:29:15]:
Rotate the cpu search window for better spread of threads. This will ensure
an idle cpu will quickly be found if one exists.
While rotating the cpu search window is good, not sure if this can find a
idle
On 6/28/19 12:01 PM, Parth Shah wrote:
On 6/27/19 6:59 AM, subhra mazumdar wrote:
Use SIS_CORE to disable idle core search. For some workloads
select_idle_core becomes a scalability bottleneck, removing it improves
throughput. Also there are workloads where disabling it can hurt latency,
so
Hello Alexey,
Thanks for reviewing this patch!
Alexey Kardashevskiy writes:
> On 21/05/2019 14:49, Thiago Jung Bauermann wrote:
>> @@ -1707,6 +1723,43 @@ static void __init prom_close_stdin(void)
>> }
>> }
>>
>> +#ifdef CONFIG_PPC_SVM
>> +static int prom_rtas_os_term_hcall(uint64_t
On Fri, Jun 28, 2019 at 10:45:42AM +1000, Dave Chinner wrote:
> On Tue, Jun 25, 2019 at 12:10:20PM +0200, Christoph Hellwig wrote:
> > On Tue, Jun 25, 2019 at 09:43:04AM +1000, Dave Chinner wrote:
> > > I'm a little concerned this is going to limit what we can do
> > > with the XFS IO path because
On 6/28/19 11:47 AM, Parth Shah wrote:
On 6/27/19 6:59 AM, subhra mazumdar wrote:
Put upper and lower limit on cpu search of select_idle_cpu. The lower limit
is amount of cpus in a core while upper limit is twice that. This ensures
for any architecture we will usually search beyond a core.
On Fri, Jun 28, 2019 at 05:40:18PM -0400, Joel Fernandes wrote:
> Hi Paul,
>
> On Fri, Jun 28, 2019 at 01:04:23PM -0700, Paul E. McKenney wrote:
> [snip]
> > > > > Commit
> > > > > - 23634ebc1d946 ("rcu: Check for wakeup-safe conditions in
> > > > >rcu_read_unlock_special()") does not trigger
On 6/28/19 11:36 AM, Parth Shah wrote:
Hi Subhra,
I ran your patch series on IBM POWER systems and this is what I have observed.
On 6/27/19 6:59 AM, subhra mazumdar wrote:
Rotate the cpu search window for better spread of threads. This will ensure
an idle cpu will quickly be found if one
From: Andi Kleen
- Fix a typo in the man page
- Fix a tip that doesn't make any sense.
Signed-off-by: Andi Kleen
---
tools/perf/Documentation/perf-report.txt | 2 +-
tools/perf/Documentation/tips.txt| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
From: Andi Kleen
The Memory_BW metric generates groups including duration_time,
which maps to a software event.
For some reason this makes the group always not count.
Always put duration_time outside a group when generating metrics.
It's always the same time, so no need to group it.
From: Andi Kleen
When printing the metrics raw, don't print : after the metricgroups.
This helps the command line completion to complete those too.
Signed-off-by: Andi Kleen
---
tools/perf/util/metricgroup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Andi Kleen
- Add a missing filter for the DRAM_Latency / DRAM_Parallel_Reads metrics
- Remove the useless PMM_* metrics from Skylake
Signed-off-by: Andi Kleen
---
.../arch/x86/cascadelakex/clx-metrics.json| 4 ++--
.../arch/x86/skylakex/skx-metrics.json| 22
Hi Davidlohr,
On Fri, Jun 28, 2019 at 9:56 AM Davidlohr Bueso wrote:
> I think this makes sense, and is more along the lines of the augmented
> cached doing the static inline instead of separate instantiations of the
> calls.
Thanks for the review.
> >Change-Id:
On Thu, 2019-06-27 at 15:06 -0700, Nathan Huckleberry wrote:
> drivers/clk/clk-qoriq.c:138:38: warning: unused variable
> 'p5020_cmux_grp1' [-Wunused-const-variable] static const struct
> clockgen_muxinfo p5020_cmux_grp1
>
> drivers/clk/clk-qoriq.c:146:38: warning: unused variable
>
From: Kim Phillips
Fill in the L3 performance event select register ThreadMask
bitfield, to enable per hardware thread accounting.
Signed-off-by: Kim Phillips
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Thomas
From: Kim Phillips
Commit d7cbbe49a930 ("perf/x86/amd/uncore: Set ThreadMask and SliceMask
for L3 Cache perf events") enables L3 PMC events for all threads and
slices by writing 1s in ChL3PmcCfg (L3 PMC PERF_CTL) register fields.
Those bitfields overlap with high order event select bits in the
From: Maxime Chevallier
Date: Tue, 25 Jun 2019 14:04:12 +0200
> I see that this patch was set as "Accepted" on patchwork, but hasn't
> made it to -net, I was wondering if this patch slipped through the
> cracks :)
>
> https://patchwork.ozlabs.org/patch/1119311/
It should really be there now.
Hi Paul,
On Fri, Jun 28, 2019 at 01:04:23PM -0700, Paul E. McKenney wrote:
[snip]
> > > > Commit
> > > > - 23634ebc1d946 ("rcu: Check for wakeup-safe conditions in
> > > >rcu_read_unlock_special()") does not trigger the bug within 94
> > > >attempts.
> > > >
> > > > - 48d07c04b4cc1
On 26.6.2019 10.55, Vinod Koul wrote:
Instead of using register values and fields lets define them and
use in the driver.
Signed-off-by: Vinod Koul
Cc: Yoshihiro Shimoda
Cc: Christian Lamparter
Tested-by: Christian Lamparter
---
drivers/usb/host/xhci-pci.c | 60
On 26.6.2019 10.55, Vinod Koul wrote:
From: Christian Lamparter
This patch adds a firmware loader for the uPD720201K8-711-BAC-A
and uPD720202K8-711-BAA-A variant. Both of these chips are listed
in Renesas' R19UH0078EJ0500 Rev.5.00 "User's Manual: Hardware" as
devices which need the firmware
From: Christian Brauner
Date: Mon, 24 Jun 2019 15:29:23 +0200
> Tools such as vpnc try to flush routes when run inside network
> namespaces by writing 1 into /proc/sys/net/ipv4/route/flush. This
> currently does not work because flush is not enabled in non-initial
> network namespaces.
> Since
On 28/06/2019 15:36, Mark Brown wrote:
> On Thu, Jun 27, 2019 at 02:16:39PM +0100, Colin King wrote:
>> From: Colin Ian King
>>
>> Currently the LP87565_DEVICE_TYPE_LP87561_Q1 case does not have a
>> break statement, causing it to fall through to a dev_err message.
>> Fix this by adding in the
My setup includes Linux kernel repository and Buildroot.
I build Linux kernel with make O= and then
when I try to build perf by running
make -j1 V=1 JOBS=1 \
-C \
CROSS_COMPILE=".../i586-buildroot-linux-uclibc-" \
DESTDIR="..."
Клиентские базы! Email: proda...@armyspy.com Узнайте подробнее!
On Fri, 7 Jun 2019, Anup Patel wrote:
> Currently, the setup_bootmem() reserves memory from RAM start to the
> kernel end. This prevents us from exploring ways to use the RAM below
> (or before) the kernel start hence this patch updates setup_bootmem()
> to only reserve memory from the kernel
On 6/28/19 3:38 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20190627:
>
> New tree: arm-soc-fixes
>
> The net-next tree lost its build failure. It also gained a conflict
> against the net tree.
>
> The battery tree gained conflicts against the mfd and pci trees. It also
> gained
Sometimes the hierarchical load of a sched_entity needs to be calculated.
Rename task_h_load to task_se_h_load, and directly pass a sched_entity to
that function.
Move the function declaration up above where it will be used later.
No functional changes.
Signed-off-by: Rik van Riel
---
The way the time slice length is currently calculated, not only do high
priority tasks get longer time slices than low priority tasks, but due
to fixed point math, low priority tasks could end up with a zero length
time slice. This can lead to cache thrashing and other inefficiencies.
Simplify
Reducing the overhead of the CPU controller is achieved by not walking
all the sched_entities every time a task is enqueued or dequeued.
One of the things being checked every single time is whether the cfs_rq
is on the rq->leaf_cfs_rq_list.
By only removing a cfs_rq from the list once it no
Remove some fields from /proc/sched_debug that are removed from
sched_entity in a subsequent patch, and add h_load, which comes in
very handy to debug CPU controller weight distribution.
Signed-off-by: Rik van Riel
---
kernel/sched/debug.c | 11 ++-
1 file changed, 2 insertions(+), 9
Refactor enqueue_entity, dequeue_entity, and update_load_avg, in order
to split out the things we still want to happen at every level in the
cgroup hierarchy with a flat runqueue from the things we only need to
happen once.
No functional changes.
Signed-off-by: Rik van Riel
---
Use an explicit "cfs_rq of parent sched_entity" helper in a few
strategic places, where cfs_rq_of(se) may no longer point at the
right runqueue once we flatten the hierarchical cgroup runqueues.
No functional change.
Signed-off-by: Rik van Riel
---
kernel/sched/fair.c | 17 +
1
Add helper functions to make the flattened runqueue patch a little smaller.
The task_se_h_weight function is similar to task_se_h_load, but scales the
task weight by the group weight, without taking the task's duty cycle into
account.
The task_se_in_cgroup helper is functionally identical to
The current implementation of the CPU controller uses hierarchical
runqueues, where on wakeup a task is enqueued on its group's runqueue,
the group is enqueued on the runqueue of the group above it, etc.
This increases a fairly large amount of overhead for workloads that
do a lot of wakeups a
The runnable_load magic is used to quickly propagate information about
runnable tasks up the hierarchy of runqueues. The runnable_load_avg is
mostly used for the load balancing code, which only examines the value at
the root cfs_rq.
Redefine the root cfs_rq runnable_load_avg to be the sum of
Since only the root cfs_rq runnable_load_avg field is used any more,
we can move the field from struct sched_avg, which every sched_entity
has one of, directly into the struct cfs_rq, of which we have way fewer.
No functional changes.
Suggested-by: Dietmar Eggemann
Signed-off-by: Rik van Riel
Flatten the hierarchical runqueues into just the per CPU rq.cfs runqueue.
Iteration of the sched_entity hierarchy is rate limited to once per jiffy
per sched_entity, which is a smaller change than it seems, because load
average adjustments were already rate limited to once per jiffy before this
On Fri, Jun 28, 2019 at 05:50:03PM +0100, Mark Rutland wrote:
> > + /*
> > +* Wake any perf_event_free_task() waiting for this event to be
> > +* freed.
> > +*/
> > + smp_mb(); /* pairs with wait_var_event() */
> > +
On 09:08-20190628, Keerthy wrote:
[..]
> > > + select GPIO_SYSFS
> > > + select GPIO_DAVINCI
> >
> >
> > Could you help explain the logic of doing this? commit message is
> > basically the diff in English. To me, this does NOT make sense.
> &
On Wed, Jun 26, 2019 at 7:02 PM Paul Walmsley wrote:
>
> On Wed, 26 Jun 2019, Rob Herring wrote:
>
> > Matching on the 'cpus' node was a bad choice because the schema is
> > incorrectly applied to non-Arm cpus nodes. As we now have a common cpus
> > schema which checks the general structure, it
On Thu, Jun 27, 2019 at 11:49 PM Viresh Kumar wrote:
>
> On 26-06-19, 11:10, Saravana Kannan wrote:
> > On Tue, Jun 25, 2019 at 11:32 PM Viresh Kumar
> > wrote:
>
> > > So, when a CPU changes frequency, we must change the performance state
> > > of PM domain and change frequency/bw of the cache
Quoting Mike Looijmans (2019-06-27 23:42:03)
> On 27-06-19 23:06, Stephen Boyd wrote:
> > Quoting Mike Looijmans (2019-05-17 06:23:52)
> >> Adds a driver for the Si5341 and Si5340 chips. The driver does not fully
> >> support all features of these chips, but allows the chip to be used
> >> without
On Fri, Jun 28, 2019 at 02:37:24PM -0500, Scott Wood wrote:
> On Thu, 2019-06-27 at 17:52 -0700, Paul E. McKenney wrote:
> > On Thu, Jun 27, 2019 at 05:46:27PM -0500, Scott Wood wrote:
> > > On Thu, 2019-06-27 at 13:50 -0700, Paul E. McKenney wrote:
> > > > If by IPI-to-self you mean the IRQ work
On 06/28, Andrii Nakryiko wrote:
> On Thu, Jun 27, 2019 at 7:38 PM Stanislav Fomichev wrote:
> >
> > On 06/27, Andrii Nakryiko wrote:
> > > On Thu, Jun 27, 2019 at 10:29 AM Stanislav Fomichev
> > > wrote:
> > > >
> > > > On 06/27, Stanislav Fomichev wrote:
> > > > > On 06/27, kernel test robot
On Fri, Jun 28, 2019 at 03:29:23PM -0400, Joel Fernandes wrote:
> On Fri, Jun 28, 2019 at 11:22:16AM -0700, Paul E. McKenney wrote:
> > On Fri, Jun 28, 2019 at 07:45:45PM +0200, Sebastian Andrzej Siewior wrote:
> > > On 2019-06-28 10:30:11 [-0700], Paul E. McKenney wrote:
> > > > > I believe the
On Fri, Jun 28, 2019 at 03:24:07PM -0400, Joel Fernandes wrote:
> On Fri, Jun 28, 2019 at 11:52:19AM -0700, Paul E. McKenney wrote:
> > On Fri, Jun 28, 2019 at 08:40:26PM +0200, Sebastian Andrzej Siewior wrote:
> > > On 2019-06-28 08:30:50 [-0700], Paul E. McKenney wrote:
> > > > On Fri, Jun 28,
On Fri, 2019-06-28 at 16:15 +0200, Peter Zijlstra wrote:
> On Thu, Jun 27, 2019 at 01:36:12PM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 27, 2019 at 03:17:27PM -0500, Scott Wood wrote:
> > > On Thu, 2019-06-27 at 11:41 -0700, Paul E. McKenney wrote:
> > > > Of course, unconditionally refusing
On Tue, Jun 25, 2019 at 11:28 AM Dave Hansen wrote:
>
> On 6/19/19 3:33 PM, Alexander Duyck wrote:
> > In order to support page aeration it will be necessary to store and
> > retrieve the migratetype of a page. To enable that I am moving the set and
> > get operations for pcppage_migratetype into
Le jeu. 27 juin 2019 à 18:40, Miquel Raynal
a écrit :
Hi Paul,
Miquel Raynal wrote on Mon, 17 Jun 2019
14:16:59 +0200:
Hello,
Arnd Bergmann wrote on Mon, 17 Jun 2019 14:12:48
+0200:
> On Mon, Jun 17, 2019 at 1:24 PM Paul Cercueil
wrote:
>
> > I think there's a better way to
On Fri, Jun 28, 2019 at 8:41 AM Arnd Bergmann wrote:
>
> An earlier patch I sent reduced the stack usage enough to get
> below the warning limit, and I could show this was safe, but with
> GCC_PLUGIN_STRUCTLEAK_BYREF_ALL, it gets worse again because large stack
> variables in the same function no
On Fri, Jun 28, 2019 at 8:40 AM Arnd Bergmann wrote:
>
> With the new CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL option, the stack
> usage in the ipvs debug output grows because each instance of
> IP_VS_DBG_BUF() now has its own buffer of 160 bytes that add up
> rather than reusing the stack slots:
>
Create list of compatible device ids to be matched with those stated in
the device tree.
Signed-off-by: Bárbara Fernandes
Signed-off-by: Wilson Sales
Co-developed by: Wilson Sales
---
drivers/staging/iio/adc/ad7192.c | 12
1 file changed, 12 insertions(+)
diff --git
On Tue, Jun 25, 2019 at 12:56 AM David Hildenbrand wrote:
>
> On 20.06.19 00:33, Alexander Duyck wrote:
> > From: Alexander Duyck
> >
> > This patch is meant to move the head/tail adding logic out of the shuffle
> > code and into the __free_one_page function since ultimately that is where
> > it
On Fri, Jun 28, 2019 at 03:34:42PM -0400, Joel Fernandes (Google) wrote:
> struct pid's count is an atomic_t field used as a refcount. Use
> refcount_t for it which is basically atomic_t but does additional
> checking to prevent use-after-free bugs.
>
> For memory ordering, the only change is
syzbot has bisected this bug to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend
Date: Sat Jun 30 13:17:47 2018 +
bpf: sockhash fix omitted bucket lock in sock_close
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14436833a0
start commit:
On Thu, 2019-06-27 at 17:52 -0700, Paul E. McKenney wrote:
> On Thu, Jun 27, 2019 at 05:46:27PM -0500, Scott Wood wrote:
> > On Thu, 2019-06-27 at 13:50 -0700, Paul E. McKenney wrote:
> > > If by IPI-to-self you mean the IRQ work trick, that isn't implemented
> > > across all architectures yet, is
1 - 100 of 763 matches
Mail list logo
