Quoting Mike Looijmans (2019-06-27 04:38:16)
> On 26-06-19 23:24, Stephen Boyd wrote:
> > Sorry, I'm getting through my inbox pile and saw this one.
> >
> > Quoting Mike Looijmans (2019-04-30 22:46:55)
> >> On 30-04-19 02:17, Stephen Boyd wrote:
> >>>
> >>> Why can't that driver call
On Wed, Jun 19, 2019 at 12:49 PM David Howells wrote:
>
> Create key domain tags for network namespaces and make it possible to
> automatically tag keys that are used by networked services (e.g. AF_RXRPC,
> AFS, DNS) with the default network namespace if not set by the caller.
>
> This allows
On Thu, Jun 27, 2019 at 09:42:40AM -0400, Joel Fernandes wrote:
> On Thu, Jun 27, 2019 at 04:07:46PM +0900, Byungchul Park wrote:
> > Hello,
> >
> > I tested if the WARN_ON_ONCE() is fired with my box and it was ok.
>
> Looks pretty safe to me and nice clean up!
>
> Acked-by: Joel Fernandes
Quoting Mike Looijmans (2019-05-17 06:20:20)
> Adds the devicetree bindings for the Si5341 and Si5340 chips from
> Silicon Labs. These are multiple-input multiple-output clock
> synthesizers.
>
> Signed-off-by: Mike Looijmans
>
> ---
Applied to clk-next
On 6/27/19 10:20 AM, Tejun Heo wrote:
> Hello, Waiman.
>
> On Wed, Jun 26, 2019 at 12:56:14PM -0400, Waiman Long wrote:
>> With memory cgroup v1, there is a kmem.slabinfo file that can be
>> used to view what slabs are allocated to the memory cgroup. There
>> is currently no such equivalent in
The cpufreq_online and the cpufreq_offline [un]register the driver as
a cooling device. This is done if the driver is flagged as a cooling
device in addition with a IS_ENABLED macro to compile out the branching
code.
Group this test in a stub function added in the cpufreq header instead
of having
Currently the function cpufreq_cooling_register() returns a cooling
device pointer which is used back as a pointer to call the function
cpufreq_cooling_unregister(). Even if it is correct, it would make
sense to not leak the structure inside a cpufreq driver and keep the
code thermal code
It looks like after the changes in the patch the only reason for
returning (struct thermal_cooling_device *) from
cpufreq_cooling_register() is error checking, but it would be much
more straightforward to return int for this purpose.
Moreover, that would prevent the callers of it from doing
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 any support from the "clockbuilder pro" software.
>
> If the chip is preprogrammed, that is, you
On Thu, 27 Jun 2019, Peter Xu wrote:
> + * @TIMER_PINNED: A pinned timer will not be affected by any timer
> + * placement heuristics (like, NOHZ) and will always be run on the CPU
> + * when the timer was enqueued.
s/when/on which/
> + *
> + * Note: Because enqueuing of timers can actually
IRQ numbers are always positive, hence the corresponding variable should
be unsigned to keep types consistent. This is a minor change that cleans
up code a tad more.
Suggested-by: Thierry Reding
Acked-by: MyungJoo Ham
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 8
Now that all kHz-conversion related bugs are fixed, we can use the kHz
uniformly. This makes code cleaner and avoids integer divisions in the
code, which is useful in a case of Tegra30 that has Cortex A9 CPU that
doesn't support integer division instructions, hence all divisions are
actually made
The EMC clock rate rounding technically could fail, hence let's handle
the error cases properly.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/devfreq/tegra30-devfreq.c
Add debug messages to know about what's happening in hardware and how
driver reacts.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/devfreq/tegra30-devfreq.c
The memory activity counter may get a bit higher than a watermark which
is selected based on OPP that corresponds to a highest EMC rate, in this
case watermark is lower than the actual memory activity is and thus
results in unwanted "upper" interrupts.
Signed-off-by: Dmitry Osipenko
---
When CPU's memory activity is low or memory activity is high such that
CPU's frequency contribution to the boosting is not taken into account,
then there is no need to schedule devfreq's update. This eliminates
unnecessary CPU activity during of idling caused by the scheduled work.
Signed-off-by:
Debug messages create too much CPU and memory activity by themselves,
so it's difficult to debug lower rates and catch unwanted interrupts
that happen rarely. Tracepoints are ideal in that regards because they
do not contribute to the sampled date at all. This allowed me to catch
few problems
Potentially very high boosting could cause an integer overflow for a
highly clocked memory after conversion to MHz.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/devfreq/tegra30-devfreq.c
It's not very correct to include mod_devicetable.h for the OF device
drivers and of_device.h should be included instead.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/devfreq/tegra30-devfreq.c
The consecutive-down event tells that we should perform frequency
de-boosting, but boosting is in a reset state on start and hence the
event won't do anything useful for us and it will be just a dummy
interrupt request.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 1 -
There is no real need to keep interrupt always-enabled, will be nicer
to keep it disabled while governor is inactive.
Suggested-by: Thierry Reding
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 43 ---
1 file changed, 22 insertions(+), 21
I noticed that CPU may be crossing the dependency threshold very
frequently for some workloads and this results in a lot of interrupts
which could be avoided if MCALL client is keeping actual EMC frequency
at a higher rate.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c |
There is another kHz-conversion bug in the code, resulting in integer
overflow. Although, this time the resulting value is 4294966296 and it's
close to ULONG_MAX, which is okay in this case.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 2 +-
1 file changed, 1
Constify unmodifiable structs for consistency.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/devfreq/tegra30-devfreq.c
b/drivers/devfreq/tegra30-devfreq.c
index ecbd58504cd8..d3e117d827d2
I was contributing to the NVIDIA Tegra20+ devfreq drivers recently and
want to help keep them working and evolving in the future.
Signed-off-by: Dmitry Osipenko
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index
There is no need in a write-barrier now, given that interrupt masking is
handled by CPU's GIC now. Hence we know exactly that interrupt won't fire
after stopping the devfreq's governor. In other cases we don't care about
potential buffering of the writes to hardware and thus there is no need to
Governor could be stopped while boosting is active. We have assumption
that everything is reset on governor's restart, including the boosting
value, which was missed.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
There is no point in receiving of the notifications while governor is
stopped, let's keep them disabled like we do for the CPU freq-change
notifications. This also fixes a potential use-after-free bug if
notification happens after device's removal.
Signed-off-by: Dmitry Osipenko
---
Depending on a kernel's configuration, a single line functions may not be
inlined by compiler (like enabled ftracing for example). Let's inline such
functions explicitly for consistency.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 13 +++--
1 file changed, 7
Now that average-sustain coefficient / multiplier is gone, it won't hurt
to re-tune the boosting thresholds to get a bit harder boosting for MCALL
clients, resulting in a more reactive governing in a case of multimedia
applications usage like 3d / video.
Signed-off-by: Dmitry Osipenko
---
The CPU's client need to take into account that CPUFreq may change
while memory activity not, staying high. Thus an appropriate frequency
notifier should be used in addition to the clk-notifier.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra30-devfreq.c | 105
On Wed, Jun 26, 2019 at 04:52:36PM +0200, Sebastian Andrzej Siewior wrote:
> A small series of tiny cleanups.
Applied 1-2 to wq/for-5.3.
Thanks.
--
tejun
The current implementation is inaccurate and results in very intensive
interrupt activity, which neglects the whole idea of polling offload to
hardware. The reason of the shortcoming is that watermarks are not set
up correctly and this results in ACTMON constantly asking to change freq
and then
Hello,
This series addresses some additional review comments that were made by
Thierry Reding to [1] and makes several important changes to the driver,
fixing excessive interrupts activity. In the end I'm proposing myself as
a maintainer for the Tegra devfreq drivers.
[1]
Hi Evan, Lee,
Missatge de Evan Green del dia dj., 27 de juny
2019 a les 22:46:
>
> For ECs that support it, the EC returns the number of slp_s0
> transitions and whether or not there was a timeout in the resume
> response. Expose the last resume result to usermode via debugfs so
> that usermode
ahci libahci tg3 libphy libata firmware_class dm_mirror
dm_region_hash dm_log dm_mod
[ 1139.415595][ T5301] CPU: 67 PID: 5301 Comm: cat Not tainted 5.2.0-rc6-next-
20190627+ #19
[ 1139.415634][ T5301] NIP: c00d0d58 LR: c049aa18 CTR:
c00d0d50
[ 1139.415675][ T5301] REGS
Hi Stephen,
Miquel Raynal wrote on Thu, 27 Jun 2019
16:51:37 +0200:
> Hi Stephen,
>
> Stephen Rothwell wrote on Tue, 4 Jun 2019
> 10:54:18 +1000:
>
> > Hi all,
> >
> > Today's linux-next merge of the nand tree got a conflict in:
> >
> >
On Wed, 26 Jun 2019, Zhenzhong Duan wrote:
> This reverts commit ca5d376e17072c1b60c3fee66f3be58ef018952d.
>
> Commit 8990cac6e5ea ("x86/jump_label: Initialize static branching
> early") adds jump_label_init() call in setup_arch() to make static
> keys initialized early, so we could use the
Such as those produced by the `patch` utility. We already ignore *.orig
files, and there are currently no *.rej files in the tree at this time.
Signed-off-by: Nick Desaulniers
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index
On Thu, Jun 27, 2019 at 04:57:50PM -0400, Waiman Long wrote:
> On 6/26/19 4:19 PM, Roman Gushchin wrote:
> >>
> >> +#ifdef CONFIG_MEMCG_KMEM
> >> +static void kmem_cache_shrink_memcg(struct mem_cgroup *memcg,
> >> + void __maybe_unused *arg)
> >> +{
> >> + struct
On Thu, Jun 27, 2019 at 12:15 PM Nathan Chancellor
wrote:
>
> There are some people interested in experimenting with Clang's
> integrated assembler. To make it easy to do so without source
> modification, allow the user to specify 'AS=clang' as part of the
> make command to avoid adding
On Thu, Jun 27, 2019 at 11:02 PM Daniel Lezcano
wrote:
>
> The cpufreq_online and the cpufreq_offline [un]register the driver as
> a cooling device. This is done if the driver is flagged as a cooling
> device in addition with a IS_ENABLED macro to compile out the branching
> code.
>
> Group this
A timing hazard exists when an early fork/exec thread begins
exiting and sets its mm pointer to NULL while a separate core
tries to update the section information.
This commit ensures that the mm pointer is not NULL before
setting its section parameters. The arguments provided by
commit
Maya,
On Tue, 18 Jun 2019, Maya Nakamura wrote:
> diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> index 0e033ef11a9f..e8960a83add7 100644
> --- a/arch/x86/hyperv/hv_init.c
> +++ b/arch/x86/hyperv/hv_init.c
> @@ -37,6 +37,20 @@ EXPORT_SYMBOL_GPL(hyperv_pcpu_input_arg);
> u32
Hi Enric,
On Wed, Jun 26, 2019 at 1:34 PM Enric Balletbo i Serra
wrote:
>
> Hi Rajat,
>
> On 25/6/19 22:51, Rajat Jain wrote:
> > The lightbar driver never assigned the drvdata in probe method, and thus
> > causes a panic when it is accessed at the suspend time.
>
> Good catch, that's one of the
On Thu, Jun 27, 2019 at 11:23:09AM -0700, Darrick J. Wong wrote:
> On Thu, Jun 27, 2019 at 12:48:30PM +0200, Christoph Hellwig wrote:
> > There is no real problem merging ioends that go beyond i_size into an
> > ioend that doesn't. We just need to move the append transaction to the
> > base
On Thursday, June 13, 2019 6:59:51 PM CEST Andy Shevchenko wrote:
> The usual pattern to allocate the necessary space for an array of properties
> is
> to count them first by calling:
>
> count = device_property_read_uXX_array(dev, propname, NULL, 0);
> if (count < 0)
> return count;
>
group_index On Mon, Jun 24, 2019 at 12:55 AM Peter Zijlstra
wrote:
>
> On Fri, Jun 21, 2019 at 11:01:29AM -0700, Ian Rogers wrote:
> > On Fri, Jun 21, 2019 at 1:24 AM Peter Zijlstra wrote:
> > >
> > > On Sat, Jun 01, 2019 at 01:27:22AM -0700, Ian Rogers wrote:
> > > > @@ -3325,6 +3331,15 @@
The lightbar driver never assigned the drvdata in probe method, and
thus there is nothing there. Need to get the ec_dev from the parent's
drvdata.
Signed-off-by: Rajat Jain
---
drivers/platform/chrome/cros_ec_lightbar.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Commit-ID: 31a2fbb390fee4231281b939e1979e810f945415
Gitweb: https://git.kernel.org/tip/31a2fbb390fee4231281b939e1979e810f945415
Author: Dianzhang Chen
AuthorDate: Tue, 25 Jun 2019 23:30:17 +0800
Committer: Thomas Gleixner
CommitDate: Thu, 27 Jun 2019 23:48:04 +0200
x86/ptrace: Fix
On Thursday, June 20, 2019 5:05:46 AM CEST Viresh Kumar wrote:
> cpufreq_start_governor() is only called for !setpolicy case, checking it
> again is not required.
>
> Signed-off-by: Viresh Kumar
> ---
> drivers/cpufreq/cpufreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
Commit-ID: 993773d11d45c90cb1c6481c2638c3d9f092ea5b
Gitweb: https://git.kernel.org/tip/993773d11d45c90cb1c6481c2638c3d9f092ea5b
Author: Dianzhang Chen
AuthorDate: Wed, 26 Jun 2019 12:50:30 +0800
Committer: Thomas Gleixner
CommitDate: Thu, 27 Jun 2019 23:48:04 +0200
x86/tls: Fix
On Thursday, June 20, 2019 5:05:48 AM CEST Viresh Kumar wrote:
> For code consistency, use has_target() instead of !setpolicy everywhere,
> as it is already done at several places. Maybe we should also use
> "!has_target()" instead of "cpufreq_driver->setpolicy" where we need to
> check if the
On Wednesday, June 12, 2019 10:27:03 PM CEST Shuah Khan wrote:
> This is a multi-part message in MIME format.
> --DA1BC82BAC95C219E9AB2661
> Content-Type: text/plain; charset=utf-8; format=flowed
> Content-Transfer-Encoding: 7bit
>
> Hi Rafael,
>
> Please pull the following update
On Thu, Jun 27, 2019 at 8:59 AM Enric Balletbo i Serra
wrote:
>
> Hi,
>
> cc'ing Doug, Gwendal and Enrico that might be interested to give a review.
>
> This patch can be picked alone without 2/2, an is needed to have
> cros-ec-sensors
> legacy support on ARM (see [1] and [2])
>
> Jonathan, as
On Friday, May 24, 2019 12:44:18 PM CEST Mathieu Malaterre wrote:
> The declaration for pfn_is_nosave is only available in
> kernel/power/power.h. Since this function can be override in arch,
> expose it globally. Having a prototype will make sure to avoid warning
> (sometime treated as error with
On Friday, June 7, 2019 5:05:46 AM CEST Viresh Kumar wrote:
> On 06-06-19, 14:50, David Arcari wrote:
> > Make pcc_cpufreq_init() return error codes when the driver cannot be
> > registered. Otherwise the driver can shows up loaded via lsmod even
> > though it failed initialization. This is
On Friday, June 14, 2019 10:05:23 AM CEST Rajneesh Bhardwaj wrote:
> Enables support for ICL-NNPI, which is a neural network processor for deep
> learning inference. From RAPL point of view it is same as Ice Lake Mobile
> processor.
>
> Cc: "Rafael J. Wysocki"
> Cc: linux...@vger.kernel.org
>
Hi Jesper, thanks you remember about it.
I don't think that "create" and "free" routines paring looks "more
correct" together.
Maybe we can scale back your solution(?), via creating a page_pool_get()
and page_pool_put() API that can be used by your driver, to keep the
page_pool object after a
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=1436e7e9a0
start commit:
On 27 Jun 2019, at 3:15, Ilya Maximets wrote:
Device pointer stored in umem regardless of zero-copy mode,
so we heed to hold the device in all cases.
Fixes: c9b47cc1fabc ("xsk: fix bug when trying to use both copy and
zero-copy on one queue id")
Signed-off-by: Ilya Maximets
Acked-by:
On 27 Jun 2019, at 3:15, Ilya Maximets wrote:
Device that bound to XDP socket will not have zero refcount until the
userspace application will not close it. This leads to hang inside
'netdev_wait_allrefs()' if device unregistering requested:
# ip link del p1
< hang on recvmsg on netlink
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
'p5020_cmux_grp2' [-Wunused-const-variable] static const struct
clockgen_muxinfo
Willem de Bruijn wrote:
> > +#ifdef CONFIG_KEYS
> > +out_free_2:
> > + kmem_cache_free(net_cachep, net);
>
> needs
> net = NULL;
>
> to signal failure
>
> > +#endif
I've folded that into the patch and retagged, remerged and repushed.
David
On Thu, Jun 27, 2019 at 01:24:13PM -0700, Brian Vazquez wrote:
> This introduces a new command to retrieve a variable number of entries
> from a bpf map wrapping the existing bpf methods:
> map_get_next_key and map_lookup_elem
>
> Note that map_dump doesn't guarantee that reading the entire table
Commit-ID: d974ffcfb7447db5f29a4b662a3eaf99a4e1109e
Gitweb: https://git.kernel.org/tip/d974ffcfb7447db5f29a4b662a3eaf99a4e1109e
Author: Andy Lutomirski
AuthorDate: Wed, 26 Jun 2019 21:45:02 -0700
Committer: Thomas Gleixner
CommitDate: Fri, 28 Jun 2019 00:04:38 +0200
On Thu, Jun 27, 2019 at 01:24:11PM -0700, Brian Vazquez wrote:
> This introduces a new command to retrieve a variable number of entries
> from a bpf map.
>
> This new command can be executed from the existing BPF syscall as
> follows:
>
> err = bpf(BPF_MAP_DUMP, union bpf_attr *attr, u32 size)
Commit-ID: 918ce325098a4eef99daad7b6796da33cebaf03a
Gitweb: https://git.kernel.org/tip/918ce325098a4eef99daad7b6796da33cebaf03a
Author: Andy Lutomirski
AuthorDate: Wed, 26 Jun 2019 21:45:04 -0700
Committer: Thomas Gleixner
CommitDate: Fri, 28 Jun 2019 00:04:39 +0200
x86/vsyscall: Show
Reviewed-by: Gwendal Grignou
On Thu, Jun 27, 2019 at 2:47 PM Rajat Jain wrote:
>
> The lightbar driver never assigned the drvdata in probe method, and
> thus there is nothing there. Need to get the ec_dev from the parent's
> drvdata.
>
> Signed-off-by: Rajat Jain
> ---
>
Commit-ID: bd49e16e3339f052fae05fb3e955c5db0c9c6445
Gitweb: https://git.kernel.org/tip/bd49e16e3339f052fae05fb3e955c5db0c9c6445
Author: Andy Lutomirski
AuthorDate: Wed, 26 Jun 2019 21:45:03 -0700
Committer: Thomas Gleixner
CommitDate: Fri, 28 Jun 2019 00:04:38 +0200
x86/vsyscall: Add
Commit-ID: e0a446ce394a7915f2ffc03f9bb610c5ac4dbbf1
Gitweb: https://git.kernel.org/tip/e0a446ce394a7915f2ffc03f9bb610c5ac4dbbf1
Author: Andy Lutomirski
AuthorDate: Wed, 26 Jun 2019 21:45:05 -0700
Committer: Thomas Gleixner
CommitDate: Fri, 28 Jun 2019 00:04:39 +0200
x86/vsyscall:
Clang produces the following warning
drivers/clk/mediatek/clk-mt8516.c:234:27: warning: unused variable
'ddrphycfg_parents' [-Wunused-const-variable] static const char * const
ddrphycfg_parents[] __initconst = {
This variable has never been used. Deleting it to cleanup the warning.
Cc:
Commit-ID: b0386979867168575118501104f3d135067eab4f
Gitweb: https://git.kernel.org/tip/b0386979867168575118501104f3d135067eab4f
Author: Andy Lutomirski
AuthorDate: Wed, 26 Jun 2019 21:45:06 -0700
Committer: Thomas Gleixner
CommitDate: Fri, 28 Jun 2019 00:04:39 +0200
Commit-ID: 625b7b7f79c66626fb2b7687fc1a58309a57edd5
Gitweb: https://git.kernel.org/tip/625b7b7f79c66626fb2b7687fc1a58309a57edd5
Author: Andy Lutomirski
AuthorDate: Wed, 26 Jun 2019 21:45:07 -0700
Committer: Thomas Gleixner
CommitDate: Fri, 28 Jun 2019 00:04:39 +0200
x86/vsyscall:
Commit-ID: 441cedab2dfca18fe4983cbc795de04536ed421e
Gitweb: https://git.kernel.org/tip/441cedab2dfca18fe4983cbc795de04536ed421e
Author: Andy Lutomirski
AuthorDate: Wed, 26 Jun 2019 21:45:08 -0700
Committer: Thomas Gleixner
CommitDate: Fri, 28 Jun 2019 00:04:40 +0200
x86/vsyscall: Add
On Thu, 27 Jun 2019, Petr Mladek wrote:
> Fortunately, the problematic fix is needed only on x86_64. It is
> the only architecture that calls set_all_modules_text_rw()
> in ftrace path and supports livepatching at the same time.
>
> Therefore it is enough to move text_mutex handling from the
Commit-ID: 7f0a5e0755832301e7b010eab46fb715c483ba60
Gitweb: https://git.kernel.org/tip/7f0a5e0755832301e7b010eab46fb715c483ba60
Author: Andy Lutomirski
AuthorDate: Wed, 26 Jun 2019 21:45:09 -0700
Committer: Thomas Gleixner
CommitDate: Fri, 28 Jun 2019 00:04:40 +0200
selftests/x86: Add
From: Willem de Bruijn
One caller of gp8psk_power_ctrl fails to check the return value.
Syzbot KMSAN found a use of uninitialized data. This path is also
exercised when no such device exists, as in this cloud environment.
Argument status is not set if gp8psk_power_ctrl returns early.
Tests
Hello, Ingo,
This pull request contains the following changes:
1. RCU flavor consolidation cleanups and optmizations.
http://lkml.kernel.org/r/20190530145204.ga28...@linux.ibm.com
2. Documentation updates.
http://lkml.kernel.org/r/20190530145504.ga29...@linux.ibm.com
On Tue, 25 Jun 2019, Arnd Bergmann wrote:
> On Tue, Jun 25, 2019 at 10:19 AM Jason A. Donenfeld wrote:
> >
> > When Arnd and I discussed this prior, he thought it best that I separate
> > these two commits out into a separate patchset, because they might
> > require additional discussion or
Clang produces the following warning
drivers/clk/rockchip/clk-rv1108.c:125:7: warning: unused variable
'mux_pll_src_3plls_p' [-Wunused-const-variable]
PNAME(mux_pll_src_3plls_p) = { "apll", "gpll", "dpll" };
Looks like this variable was never used. Deleting it to remove the
warning.
Cc:
Commit-ID: 83f44ae0f8afcc9da659799db8693f74847e66b3
Gitweb: https://git.kernel.org/tip/83f44ae0f8afcc9da659799db8693f74847e66b3
Author: Song Liu
AuthorDate: Wed, 26 Jun 2019 19:33:52 -0500
Committer: Thomas Gleixner
CommitDate: Fri, 28 Jun 2019 00:11:20 +0200
perf/x86: Always store
Commit-ID: ae6a45a0868986f69039a2150d3b2b9ca294c378
Gitweb: https://git.kernel.org/tip/ae6a45a0868986f69039a2150d3b2b9ca294c378
Author: Josh Poimboeuf
AuthorDate: Wed, 26 Jun 2019 19:33:55 -0500
Committer: Thomas Gleixner
CommitDate: Fri, 28 Jun 2019 00:11:21 +0200
x86/unwind/orc:
On Tue, Jun 25, 2019 at 12:25:07PM +0200, Christoph Hellwig wrote:
> On Tue, Jun 25, 2019 at 09:15:23AM +1000, Dave Chinner wrote:
> > > So, uh, how much of a hit do we take for having to allocate a
> > > transaction for a file size extension? Particularly since we can
> > > combine those things
On 06/27/2019 03:45 AM, Stephen Rothwell wrote:
> Hi all,
>
> On Wed, 26 Jun 2019 16:36:50 -0700 Alexei Starovoitov
> wrote:
>>
>> On Wed, Jun 26, 2019 at 3:14 PM Roman Gushchin wrote:
>>>
>>> On Thu, Jun 27, 2019 at 08:05:21AM +1000, Stephen Rothwell wrote:
In commit
From: Andi Kleen
bison 3.4.1 complains during a perf build:
util/parse-events.y:1.1-12: warning: deprecated directive, use ‘%define
api.pure’ [-Wdeprecated]
1 | %pure-parser
| ^~~~
CC /home/andi/lsrc/obj-perf/ui/browsers/map.o
util/parse-events.y: warning: fix-its can
On Mon, Jun 24, 2019 at 08:02:58PM +0800, Zhenzhong Duan wrote:
With the boot parameter "hv_nopvspin" specified a Hyperv guest should
not make use of paravirt spinlocks, but behave as if running on bare
metal. This is not true, however, as the qspinlock code will fall back
to a test-and-set
On Thu, Jun 27, 2019 at 12:48:29PM +0200, Christoph Hellwig wrote:
> Instead of a magic flag for xfs_trans_alloc, just ensure all callers
> that can't relclaim through the file system use memalloc_nofs_save to
> set the per-task nofs flag.
>
> Signed-off-by: Christoph Hellwig
> ---
>
On Thu, Jun 27, 2019 at 3:22 PM 'Nathan Huckleberry' via Clang Built
Linux wrote:
>
> Clang produces the following warning
>
> drivers/clk/rockchip/clk-rv1108.c:125:7: warning: unused variable
> 'mux_pll_src_3plls_p' [-Wunused-const-variable]
> PNAME(mux_pll_src_3plls_p) = { "apll", "gpll",
On Tue, Jun 25, 2019 at 12:15:15PM +0200, Christoph Hellwig wrote:
> On Tue, Jun 25, 2019 at 09:49:21AM +1000, Dave Chinner wrote:
> > > +#undef TRACE_SYSTEM
> > > +#define TRACE_SYSTEM iomap
> >
> > Can you add a comment somewhere here that says these tracepoints are
> > volatile and we reserve
On Mon, 17 Jun 2019, Dmitry Safonov wrote:
> @@ -196,7 +196,16 @@ void set_hv_tscchange_cb(void (*cb)(void))
> /* Make sure callback is registered before we write to MSRs */
> wmb();
>
> + /*
> + * As reenlightenment vector is global, there is no difference which
> + *
On Fri, Jun 28, 2019 at 12:25:54AM +0200, Daniel Borkmann wrote:
> On 06/27/2019 03:45 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > On Wed, 26 Jun 2019 16:36:50 -0700 Alexei Starovoitov
> > wrote:
> >>
> >> On Wed, Jun 26, 2019 at 3:14 PM Roman Gushchin wrote:
> >>>
> >>> On Thu, Jun 27,
On Wed, 26 Jun 2019, Ingo Molnar wrote:
> * Thomas Gleixner wrote:
> > - evt->set_state_shutdown = hpet_msi_shutdown;
> > - evt->set_state_oneshot = hpet_msi_set_oneshot;
> > - evt->tick_resume = hpet_msi_resume;
> > - evt->set_next_event = hpet_msi_next_event;
> > +
On Thu, 2019-06-27 at 13:50 -0700, Paul E. McKenney wrote:
> On Thu, Jun 27, 2019 at 03:16:09PM -0500, Scott Wood wrote:
> > On Thu, 2019-06-27 at 11:00 -0700, Paul E. McKenney wrote:
> > > On Wed, Jun 26, 2019 at 11:49:16AM -0500, Scott Wood wrote:
> > > > >
> > > > > On Fri, 21 Jun 2019
Thanks a lot for fixing this Petr.
On Thu, Jun 27, 2019 at 10:13:34AM +0200, Petr Mladek wrote:
> @@ -35,6 +36,7 @@
>
> int ftrace_arch_code_modify_prepare(void)
> {
> + mutex_lock(_mutex);
> set_kernel_text_rw();
> set_all_modules_text_rw();
> return 0;
> @@ -44,6 +46,7
On Wed, 26 Jun 2019, Andy Lutomirski wrote:
> Since commit a6c19dfe3994 ("arm64,ia64,ppc,s390,sh,tile,um,x86,mm:
> remove default gate area"), which predates riscv's inclusion in
> Linux by almost three years, the default behavior wrt the gate area
> is sane. Remove riscv's gate area stubs.
>
>
On Fri, 28 Jun 2019, Thomas Gleixner wrote:
> On Wed, 26 Jun 2019, Ingo Molnar wrote:
> >
> > s/hpet_clkevt_msi_resume
> > /hpet_clkevt_tick_resume
> >
> > ... unless the name variations have some hidden purpose and meaning?
>
> Historical but we want to preserve some of the old stuff for
Userspace can use wakeup_sources debugfs node to plot history of suspend
blocking wakeup sources over device's boot cycle. This information can
then be used (1) for power-specific bug reporting and (2) towards
attributing battery consumption to specific processes over a period of
time.
However,
On Wed, Jun 26, 2019 at 5:04 PM Greg KH wrote:
>
> On Wed, Jun 26, 2019 at 03:48:58PM -0700, Tri Vo wrote:
> > On Tue, Jun 25, 2019 at 6:33 PM Tri Vo wrote:
> > >
> > > On Tue, Jun 25, 2019 at 6:12 PM Greg KH
> > > wrote:
> > > >
> > > > On Tue, Jun 25, 2019 at 05:54:49PM -0700, Tri Vo wrote:
On Wed, Jun 26, 2019 at 9:09 PM Stephen Rothwell wrote:
>
> Hi all,
>
> Today's linux-next merge of the mlx5-next tree got a conflict in:
>
> drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
>
> between commits:
>
> 955858009708 ("net/mlx5e: Fix number of vports for ingress ACL
>
701 - 800 of 1056 matches
Mail list logo
