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
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
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 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.
Cap the
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
On Thu, Jul 04, 2019 at 05:15:57PM -0700, Joe Perches wrote:
> On Thu, 2019-07-04 at 13:46 -0700, Joe Perches wrote:
> > On Thu, 2019-07-04 at 11:24 +0530, Nitin Gote wrote:
> > > Added warnings in checkpatch.pl script to :
> > >
> > > 1. Deprecate strcpy() in favor of strscpy().
> > > 2.
Em Mon, Jul 22, 2019 at 05:54:17PM +0200, Jiri Olsa escreveu:
> On Mon, Jul 22, 2019 at 09:39:24AM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Sun, Jul 21, 2019 at 01:24:10PM +0200, Jiri Olsa escreveu:
> > > Adding empty libperf.a under toos/perf/lib and
> > > linking it with perf.
> >
> > So,
This series is part of a tree-wide movement to replace the I2C API call
'i2c_new_dummy' which returns NULL with its new counterpart returning an
ERRPTR.
The series was generated with coccinelle (audited afterwards, of course) and
build tested by me and by buildbot. No tests on HW have been
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/media/i2c/ad9389b.c | 6 +++---
1 file changed, 3 insertions(+), 3
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/media/dvb-frontends/mn88443x.c | 6 +++---
1 file changed, 3
This series is part of a tree-wide movement to replace the I2C API call
'i2c_new_dummy' which returns NULL with its new counterpart returning an
ERRPTR.
The series was generated with coccinelle (audited afterwards, of course) and
build tested by me and by buildbot. No tests on HW have been
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/extcon/extcon-max77843.c | 6 +++---
1 file changed, 3
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/media/i2c/adv7180.c | 12 ++--
1 file changed, 6
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/hwmon/asb100.c | 12 ++--
1 file changed, 6 insertions(+),
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/hwmon/smm665.c | 6 +++---
1 file changed, 3 insertions(+), 3
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/mfd/88pm860x-core.c | 6 +++---
1 file changed, 3 insertions(+), 3
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/mfd/88pm800.c | 12 ++--
1 file changed, 6 insertions(+),
This series is part of a tree-wide movement to replace the I2C API call
'i2c_new_dummy' which returns NULL with its new counterpart returning an
ERRPTR.
The series was generated with coccinelle (audited afterwards, of course) and
build tested by me and by buildbot. No tests on HW have been
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/rtc/rtc-s5m.c | 6 +++---
1 file changed, 3 insertions(+), 3
This series is part of a tree-wide movement to replace the I2C API call
'i2c_new_dummy' which returns NULL with its new counterpart returning an
ERRPTR.
The series was generated with coccinelle (audited afterwards, of course) and
build tested by me and by buildbot. No tests on HW have been
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/mfd/ab3100-core.c | 6 +++---
1 file changed, 3 insertions(+), 3
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/rtc/rtc-max77686.c | 6 +++---
1 file changed, 3 insertions(+), 3
This series is part of a tree-wide movement to replace the I2C API call
'i2c_new_dummy' which returns NULL with its new counterpart returning an
ERRPTR.
The series was generated with coccinelle (audited afterwards, of course) and
build tested by me and by buildbot. No tests on HW have been
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/misc/eeprom/max6875.c | 6 +++---
1 file changed, 3 insertions(+),
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/rtc/rtc-isl12026.c | 6 +++---
1 file changed, 3 insertions(+), 3
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/rtc/rtc-s35390a.c | 6 +++---
1 file changed, 3 insertions(+), 3
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/media/usb/go7007/s2250-board.c | 6 +++---
1 file changed, 3
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/misc/eeprom/ee1004.c | 6 +++---
1 file changed, 3 insertions(+),
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/media/dvb-frontends/mn88473.c | 12 ++--
1 file changed, 6
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/mfd/max14577.c | 6 +++---
1 file changed, 3 insertions(+), 3
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/mfd/da9150-core.c | 6 +++---
1 file changed, 3 insertions(+), 3
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/mfd/bcm590xx.c | 6 +++---
1 file changed, 3 insertions(+), 3
Move from i2c_new_dummy() to i2c_new_dummy_device(). So, we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Only build tested. Part of a tree-wide move to deprecate
i2c_new_dummy().
drivers/net/ethernet/sfc/falcon/falcon_boards.c | 14 +++---
1 file
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/iio/pressure/hp03.c | 6 +++---
1 file changed, 3 insertions(+), 3
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/mfd/max8925-i2c.c | 12 ++--
1 file changed, 6
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/mfd/palmas.c | 6 +++---
1 file changed, 3 insertions(+), 3
i2c_new_dummy() can fail returning a NULL pointer. The code does not
bail out in this case and the returned pointer is blindly used. Convert
to devm_i2c_new_dummy_device() which returns an ERR_PTR and also bail
out when failing the validity check.
Signed-off-by: Wolfram Sang
---
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/mfd/max8997.c | 18 +-
1 file changed, 9
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/mfd/max8998.c | 6 +++---
1 file changed, 3 insertions(+), 3
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/hwmon/w83781d.c | 6 +++---
1 file changed, 3 insertions(+), 3
This series is part of a tree-wide movement to replace the I2C API call
'i2c_new_dummy' which returns NULL with its new counterpart returning an
ERRPTR.
The series was generated with coccinelle (audited afterwards, of course) and
build tested by me and by buildbot. No tests on HW have been
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/iio/light/veml6070.c | 6 +++---
1 file changed, 3 insertions(+),
This series is part of a tree-wide movement to replace the I2C API call
'i2c_new_dummy' which returns NULL with its new counterpart returning an
ERRPTR.
The series was generated with coccinelle (audited afterwards, of course) and
build tested by me and by buildbot. No tests on HW have been
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/mfd/max8907.c | 6 +++---
1 file changed, 3 insertions(+), 3
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/mfd/max77843.c | 6 +++---
1 file changed, 3 insertions(+), 3
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/mfd/twl-core.c | 6 +++---
1 file changed, 3 insertions(+), 3
Move from i2c_new_dummy() to devm_i2c_new_dummy_device(). So, we now get
an ERRPTR which we use in error handling and we can skip removal of the
created devices.
Signed-off-by: Wolfram Sang
---
Only build tested. Part of a tree-wide move to deprecate
i2c_new_dummy().
drivers/mfd/tps80031.c |
From: Wolfram Sang
This series is part of a tree-wide movement to replace the I2C API call
'i2c_new_dummy' which returns NULL with its new counterpart returning an
ERRPTR.
It was manually converted and only build tested (by me and buildbot). A
small cleanup was added while working on this
The "free memory" comment is obsolete since 2013 and the other ones
explain the obvious. Just remove the comments.
Signed-off-by: Wolfram Sang
---
drivers/media/i2c/ir-kbd-i2c.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/media/i2c/ir-kbd-i2c.c
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/iio/light/cm36651.c | 12 ++--
1 file changed, 6
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/mfd/max77693.c | 12 ++--
1 file changed, 6 insertions(+),
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/media/dvb-frontends/mn88472.c | 12 ++--
1 file changed, 6
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/media/i2c/adv7511-v4l2.c | 18 +-
1 file changed,
In the general move to have i2c_new_*_device functions which return
ERR_PTR instead of NULL, this patch converts i2c_new_secondary_device().
There are only few users, so this patch converts the I2C core and all
users in one go. The function gets renamed to i2c_new_ancillary_device()
so
Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an
ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. Build tested by me and buildbot. Not tested on HW.
drivers/media/dvb-frontends/cxd2820r_core.c | 6 +++---
1 file changed, 3
On Mon, Jul 22, 2019 at 01:41:20PM +0200, Arnd Bergmann wrote:
> The combination of KASAN_STACK and GCC_PLUGIN_STRUCTLEAK_BYREF
> leads to much larger kernel stack usage, as seen from the warnings
> about functions that now exceed the 2048 byte limit:
>
> drivers/media/i2c/tvp5150.c:253:1: error:
On Mon, 2019-07-22 at 10:36 -0600, stillcompil...@gmail.com wrote:
> On HP spectre x360 convertible the message:
> hid-sensor-hub 001F:8087:0AC2.0002: hid_field_extract() called with n (192) >
> 32! (kworker/1:2)
> is continually printed many times per second, crowding out all other kernel
>
On Thu, Jul 18, 2019 at 03:46:46PM +0800, Coly Li wrote:
> On 2019/7/16 6:47 下午, Coly Li wrote:
> > Hi Kent,
> >
> > On 2019/6/11 3:14 上午, Kent Overstreet wrote:
> >> Signed-off-by: Kent Overstreet
> > Acked-by: Coly Li
> >
> > And also I receive report for suspicious closure race condition in
On Sun, Jul 21, 2019 at 11:19 PM Segher Boessenkool
wrote:
>
> On Sun, Jul 21, 2019 at 07:41:40PM -0700, Nathan Chancellor wrote:
> > Hi Segher,
> >
> > On Sun, Jul 21, 2019 at 01:01:50PM -0500, Segher Boessenkool wrote:
> > > On Sun, Jul 21, 2019 at 12:58:46AM -0700, Nathan Chancellor wrote:
> >
On Fri, Jul 19, 2019 at 01:40:13PM -0400, Andy Lutomirski wrote:
> > On Jul 19, 2019, at 1:03 PM, Sean Christopherson
> > wrote:
> >
> > The generic vDSO implementation, starting with commit
> >
> > 7ac870747988 ("x86/vdso: Switch to generic vDSO implementation")
> >
> > breaks
On Mon, Jul 22, 2019 at 5:23 PM Alexander Potapenko wrote:
> On Mon, Jul 22, 2019 at 4:26 PM Arnd Bergmann wrote:
> > On Mon, Jul 22, 2019 at 3:43 PM Alexander Potapenko
> > wrote:
> > > On Mon, Jul 22, 2019 at 1:41 PM Arnd Bergmann wrote:
> > Doesn't that just limit the usefulness of KASAN,
On Wed, Jul 10, 2019 at 09:55:12AM -0600, Rob Herring wrote:
> On Wed, Jul 3, 2019 at 5:23 PM Matthias Kaehlcke wrote:
> >
> > Hi Florian,
> >
> > On Wed, Jul 03, 2019 at 02:37:47PM -0700, Florian Fainelli wrote:
> > > On 7/3/19 12:37 PM, Matthias Kaehlcke wrote:
> > > > The LED behavior of some
In addition, it seems that svm_page_enc_status_hc() accepts 'gpa',
'npages', 'enc' directly from the guest, and so these can take
arbitrary values. A very large 'npages' could lead to an int overflow
in 'gfn_end = gfn_start + npages', making gfn_end < gfn_start. This
could an OOB access in the
On Mon, 2019-07-22 at 10:36 -0600, stillcompil...@gmail.com wrote:
> From: Joshua Clayton
>
> Make available printk_once variants to hid_warn() etc
>
> Signed-off-by: Joshua Clayton
This seems OK, but I suggest a slightly different style:
> diff --git a/include/linux/hid.h
On Sat, 13 Jul 2019 11:46:31 +0800, Icenowy Zheng wrote:
> Allwinner V3 has the same main die with V3s, but with more pins wired.
> There's a I2S bus on V3 that is not available on V3s.
>
> Add the V3-only peripheral's clocks and reset to the V3s CCU driver,
> bound to a new V3 compatible string.
Hi,
On 2019-07-05 18:09, Colin Ian King wrote:
> Static analysis on today's linux-next has found a potential error in the
> following commit:
>
> commit 280e54c9f614c88292685383cf2d65057586e9fb
> Author: Andrzej Pietrasiewicz
> Date: Thu Jun 7 13:06:08 2018 +0200
>
> drm/exynos: scaler:
wakeup_abort_count and wakeup_count sysfs entries print the
same (wakeup_count) attribute. This patch removes the duplicate
wakeup_abort_count sysfs entry.
Signed-off-by: Ravi Chandra Sadineni
---
Documentation/ABI/testing/sysfs-devices-power | 25 ++-
drivers/base/power/sysfs.c
On Wed, Jul 17, 2019 at 05:18:52PM +0800, YueHaibing wrote:
> Fix sparse warnings:
>
> lib/zstd/compress.c:2252:6: warning:
> symbol 'ZSTD_compressBlock_greedy_extDict' was not declared. Should it be
> static?
> lib/zstd/compress.c:2982:14: warning:
> symbol 'ZSTD_createCStream_advanced' was
DT nodes should be ordered by address, then node name, and finally label.
The msm8998 dtsi does not follow this, so clean it up by reordering the
nodes. While we are at it, extend the addresses to be fully 32-bits wide
so that ordering is easy to determine when adding new nodes. Also, two
or so
only got a partial panic, but when I threw 5.3-rc1 on a linode vm,
it hit this:
bus_add_driver+0x1a9/0x1c0
? scsi_init_sysctl+0x22/0x22
driver_register+0x6b/0xa6
? scsi_init_sysctl+0x22/0x22
init+0x86/0xcc
do_one_initcall+0x69/0x334
kernel_init_freeable+0x367/0x3ff
? rest_init+0x247/0x247
The pull request you sent on Sun, 21 Jul 2019 21:13:21 -0700 (PDT):
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git refs/heads/master
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/83768245a3b158b96d33012b22ab01d193afb2da
Thank you!
--
Deet-doot-dot,
The pull request you sent on Mon, 22 Jul 2019 18:23:38 +0200 (CEST):
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> sched-urgent-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7b5cf701ea9c395c792e2a7e3b7caf4c68b87721
Thank you!
--
The pull request you sent on Mon, 22 Jul 2019 16:22:41 +0200:
> g...@gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux
> tags/for-linus-20190722
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/44b912cd0b5596c5ae8ae857bd1d5ff83ed5
Thank you!
--
The pull request you sent on Mon, 22 Jul 2019 08:58:06 -0300:
> git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
> tags/media/v5.3-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c92f0380673bd295c9ac73030a17c16b9df3e702
Thank you!
--
On Mon, Jul 22, 2019 at 09:27:08AM -0700, Linus Torvalds wrote:
> On Mon, Jul 22, 2019 at 7:26 AM Christian Brauner
> wrote:
> >
> > This contains a fix for pidfd polling. It ensures that the task's exit
> > state is visible to all waiters:
>
> Hmm.
>
> I've pulled this, but the exit_state
On Mon, Jul 22, 2019 at 07:35:03AM -0700, Mark Balantzyan wrote:
> Hello all,
>
> I had previously submitted 2 patches attempting to fix the data race
> condition in alim1535_wdt.c as part of my work with individuals on the
> Linux Driver Verification project. I am including the original patch
>
From: Joshua Clayton
Make available printk_once variants to hid_warn() etc
Signed-off-by: Joshua Clayton
---
include/linux/hid.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index d770ab1a0479..5b239712c902 100644
---
From: Joshua Clayton
On HP spectre x360 convertible the message:
hid-sensor-hub 001F:8087:0AC2.0002: hid_field_extract() called with n (192) >
32! (kworker/1:2)
is continually printed many times per second, crowding out all other kernel logs
Protect dmesg by printing the warning only one time.
On Mon, Jul 22, 2019 at 09:25:51AM -0700, Paul E. McKenney wrote:
> On Mon, Jul 22, 2019 at 12:13:40PM -0400, Michael S. Tsirkin wrote:
> > On Mon, Jul 22, 2019 at 08:55:34AM -0700, Paul E. McKenney wrote:
> > > On Mon, Jul 22, 2019 at 11:47:24AM -0400, Michael S. Tsirkin wrote:
> > > > On Mon,
On Mon, Jul 22, 2019 at 03:47:44PM +0300, Alexandru Ardelean wrote:
> Some devices like the ADIS16460 IMU require a longer period between
> transfers, i.e. between when the CS is de-asserted and re-asserted. The
> default value of 10us is not enough. This change makes the delay
> configurable for
On Mon, Jul 22, 2019 at 7:26 AM Christian Brauner wrote:
>
> This contains a fix for pidfd polling. It ensures that the task's exit
> state is visible to all waiters:
Hmm.
I've pulled this, but the exit_state thing has been very fragile
before, and I'm not entirely happy with how this just
Static analysis identified that index comparison against ITS entries in
iort_dev_find_its_id() is off by one.
Update the comparison condition and clarify the resulting error
message.
Fixes: 4bf2efd26d76 ("ACPI: Add new IORT functions to support MSI domain
handling")
Link:
On Mon, Jul 22, 2019 at 12:13:40PM -0400, Michael S. Tsirkin wrote:
> On Mon, Jul 22, 2019 at 08:55:34AM -0700, Paul E. McKenney wrote:
> > On Mon, Jul 22, 2019 at 11:47:24AM -0400, Michael S. Tsirkin wrote:
> > > On Mon, Jul 22, 2019 at 11:14:39AM -0400, Joel Fernandes wrote:
> > > > [snip]
> > >
This is really helpful and thank you for taking the initiative! I've
no real feedback other than to offer support.
We've been looking in this direction to avoid memory overhead in:
https://github.com/google/perf_data_converter
Some use cases:
1) streaming protobuf rather than perf.data files,
2)
Linus,
please pull the latest sched-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-for-linus
up to: b8d3349803ba: sched/rt, Kconfig: Unbreak def/oldconfig with
CONFIG_PREEMPT=y
The PREEMPT_RT stub config renamed PREEMPT to
On 7/22/19 3:57 AM, Dmitry Osipenko wrote:
22.07.2019 13:13, Marc Zyngier пишет:
On 22/07/2019 10:54, Dmitry Osipenko wrote:
21.07.2019 22:40, Sowjanya Komatineni пишет:
Tegra210 platforms use sc7 entry firmware to program Tegra LP0/SC7 entry
sequence and sc7 entry firmware is run from
On Fri, Jul 19 2019 at 12:20 -0600, Stephen Boyd wrote:
Quoting Lina Iyer (2019-07-01 08:29:06)
From: "Raju P.L.S.S.S.N"
tcs->lock was introduced to serialize access with in TCS group. But
even without tcs->lock, drv->lock is serving the same purpose. So
use a single drv->lock.
Isn't the
On Mon, Jul 22, 2019 at 01:04:48PM -0300, Jason Gunthorpe wrote:
> On Mon, Jul 22, 2019 at 08:52:35AM -0700, Paul E. McKenney wrote:
> > So why then is there a problem?
>
> I'm not sure there is a real problem, I thought Michael was just
> asking how to design with RCU in the case where the user
On Mon, Jul 22, 2019 at 01:04:48PM -0300, Jason Gunthorpe wrote:
> On Mon, Jul 22, 2019 at 08:52:35AM -0700, Paul E. McKenney wrote:
> > So why then is there a problem?
>
> I'm not sure there is a real problem, I thought Michael was just
> asking how to design with RCU in the case where the user
While loading fw crashdump in function fw_crash_buffer_show(),
left bytes in one dma chunk was not checked, if copying size
over it, overflow access will cause kernel panic.
Signed-off-by: Junxiao Bi
---
drivers/scsi/megaraid/megaraid_sas_base.c | 3 +++
1 file changed, 3 insertions(+)
diff
Commit 36a2ba07757d ("ACPI/IORT: Reject platform device creation on NUMA
node mapping failure") introduced a local variable 'node' in
arm_smmu_v3_set_proximity() that shadows the struct acpi_iort_node
pointer function parameter.
Execution was unaffected but it is prone to errors and can lead
to
On Mon, Jul 22, 2019 at 08:55:34AM -0700, Paul E. McKenney wrote:
> On Mon, Jul 22, 2019 at 11:47:24AM -0400, Michael S. Tsirkin wrote:
> > On Mon, Jul 22, 2019 at 11:14:39AM -0400, Joel Fernandes wrote:
> > > [snip]
> > > > > Would it make sense to have call_rcu() check to see if there are many
>
+++ Martin Kaiser [22/07/19 12:13 +0200]:
Dear all,
I run next-20190722 on an arm imx25 system and came across an issue that might
be worth reporting. I am no sure to whom, though. Please let me know if I got
that wrong.
Loading a module, no matter which one, causes a segfault and a dump
+++ Bartosz Golaszewski [22/07/19 14:12 +0200]:
Hi,
with v5.3-rc1 I'm hitting the following BUG() when trying to load the
gpio-backlight module:
kernel BUG at kernel/module.c:1919!
Internal error: Oops - BUG: 0 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 1 Comm: systemd Tainted: GW
On 22/07/2019 16:34, Thomas Gleixner wrote:
John,
Hi Thomas,
On Mon, 22 Jul 2019, John Garry wrote:
On 22/07/2019 15:41, Marc Zyngier wrote:
On 22/07/2019 15:14, John Garry wrote:
I have a question on commit cbf866a6 ("genirq: Let irq thread follow
the effective hard irq affinity"),
On Mon, Jul 22, 2019 at 08:52:35AM -0700, Paul E. McKenney wrote:
> So why then is there a problem?
I'm not sure there is a real problem, I thought Michael was just
asking how to design with RCU in the case where the user controls the
kfree_rcu??
Sounds like the answer is "don't worry about it"
Dear Eric,
Sorry for the late reply.
On 5/29/19 6:00 PM, Eric Dumazet wrote:
> On Wed, May 29, 2019 at 7:49 AM Paul Menzel wrote:
>> On 05/28/19 19:18, Eric Dumazet wrote:
>>> On 5/28/19 8:42 AM, Paul Menzel wrote:
>>
Occasionally, Linux outputs the message below on the workstation Dell
On Mon, Jul 22, 2019 at 11:00:10AM -0400, Steven Rostedt wrote:
> On Mon, 22 Jul 2019 13:42:02 +0100
> Catalin Marinas wrote:
>
> > > I agree with Masami, that the selftest actually caught a bug here. I
> > > think the arch code may need to change as the purpose of Masami's
> > > changes was to
On Mon, Jul 22, 2019 at 11:47:24AM -0400, Michael S. Tsirkin wrote:
> On Mon, Jul 22, 2019 at 11:14:39AM -0400, Joel Fernandes wrote:
> > [snip]
> > > > Would it make sense to have call_rcu() check to see if there are many
> > > > outstanding requests on this CPU and if so process them before
> >
On Mon, Jul 22, 2019 at 09:39:24AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Sun, Jul 21, 2019 at 01:24:10PM +0200, Jiri Olsa escreveu:
> > Adding empty libperf.a under toos/perf/lib and
> > linking it with perf.
>
> So, I noticed you created a subdirectory under tools/perf/, while I
> first
501 - 600 of 1164 matches
Mail list logo
