Hi all,
Friendly ping:
Who can take this?
On 2019/4/24 10:17, Yue Haibing wrote:
> From: YueHaibing
>
> rtas_parse_epow_errlog() should pass 'modifier' to
> handle_system_shutdown, because event modifier only use
> bottom 4 bits.
>
> Fixes: 55fc0c561742 ("powerpc/pseries: Parse and handle EPO
From: Neeraj Upadhyay
The dump_blkd_tasks() function dumps at most 10 blocked tasks, ignoring
the value of the ncheck parameter. This commit therefore substitutes
the value of ncheck for the hard-coded value of 10. Because all callers
currently pass 10 as the number, this patch does not change
From: Waiman Long
When debugging options are turned on, the rcu_read_lock() function
might not be inlined. This results in lockdep's print_lock() function
printing "rcu_read_lock+0x0/0x70" instead of rcu_read_lock()'s caller.
For example:
[ 10.579995] =
[ 10.58403
On Thu, May 30, 2019 at 05:47:55PM +0300, Vladimir Oltean wrote:
> Yes, they don't identify the original frame.
> The hardware's line of thinking seems to be "The meta frame is sent
> immediately after the trapped frame that triggered the action." (quote
> from https://www.nxp.com/docs/en/user-guid
Hello!
This series provides SRCU updates:
1. Allocate per-CPU data for DEFINE_SRCU() in modules.
2. Remove unused vmlinux srcu linker entries, courtesy of Joel Fernandes.
3. Make srcu_struct ptr array as read-only, courtesy of Joel Fernandes.
4. Make __call_srcu static, cou
On 5/30/19 10:31 AM, Andy Lutomirski wrote:
Hi all-
After an offline discussion with Sean yesterday, here are some updates
to the user API parts of my proposal.
Unfortunately, Sean convinced me that MAXPERM doesn't work the way I
described it because, for SGX2, the enclave loader won't know at
From: "Joel Fernandes (Google)"
The SRCU for modules optimization (commit title "srcu: Allocate per-CPU
data for DEFINE_SRCU() in modules") introduced vmlinux linker entries
which is unused since it applies only to the built-in vmlinux. So remove
it to prevent any space usage due to the 8 byte al
From: Jiang Biao
Because __call_srcu() is not used outside kernel/rcu/srcutree.c,
this commit makes it static.
Signed-off-by: Jiang Biao
Signed-off-by: Paul E. McKenney
---
kernel/rcu/srcutree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/rcu/srcutree.c b/ke
On Thu, 30 May 2019 at 16:34, Herbert Xu wrote:
>
> On Thu, May 30, 2019 at 04:31:09PM +0200, Ard Biesheuvel wrote:
> >
> > This might work:
>
> Looks good to me.
>
Thanks Herbert,
But given your remark regarding CBC being the only algo that has this
requirement, I wonder if this might be suffic
On Thu, May 30, 2019 at 05:57:30PM +0300, Vladimir Oltean wrote:
> On Thu, 30 May 2019 at 17:30, Richard Cochran
> wrote:
> >
> > Not necessarily. If two frames that arrive at nearly the same time
> > get their timestamps mixed up, that would be enough to break the time
> > values but without br
Adding DEFINE_SRCU() or DEFINE_STATIC_SRCU() to a loadable module requires
that the size of the reserved region be increased, which is not something
we want to be doing all that often. One approach would be to require
that loadable modules define an srcu_struct and invoke init_srcu_struct()
from t
From: "Joel Fernandes (Google)"
Since commit title ("srcu: Allocate per-CPU data for DEFINE_SRCU() in
modules"), modules that call DEFINE_{STATIC,}SRCU will have a new array
of srcu_struct pointers, which is used by srcu code to initialize and
clean up these structures and save valuable per-cpu r
Without optimization, both save_stack_trace_tsk and __save_stack_trace
will have stacktrace information in ARM32.
In this situation, "data.skip += 2" operation will skip the first two layers,
which may make the stacktrace strange and different from other architectures.
A simple example is as foll
On Tue, May 14, 2019 at 01:35:05PM +0800, Ley Foon Tan wrote:
> On Wed, Apr 24, 2019 at 12:57 PM Ley Foon Tan wrote:
> >
> > Altera PCIe Rootport IP is a soft IP and is only available after
> > FPGA image is programmed.
> >
> > Make driver modulable to support use case FPGA image is programmed
> >
Hello!
This series contains flavor-consolidation updates to RCU-sync:
1. Kill rcu_sync_type/gp_type, courtesy of Oleg Nesterov.
2. Use DEFINE_STATIC_PERCPU_RWSEM() to initialize dup_mmap_sem in
uprobes, courtesy of Oleg Nesterov.
3. Add DEFINE_PERCPU_RWSEM(), use it to in
Em Thu, 30 May 2019 08:54:04 -0600
Jonathan Corbet escreveu:
> On Wed, 29 May 2019 22:53:05 -0300
> Mauro Carvalho Chehab wrote:
>
> > > Yup. The point is that I see the sphinx-build output *in the docs-build
> > > output", not when I run it standalone (where it does the expected thing).
> >
From: Oleg Nesterov
With this patch rcu_sync has a single state variable and the transition rules
become really simple:
GP_IDLE - owned by the first rcu_sync_enter() which moves it to
GP_ENTER - owned by rcu-callback which moves it to
GP_PASSED - owned by the last rc
On Wed, Apr 24, 2019 at 12:57:15PM +0800, Ley Foon Tan wrote:
> Altera MSI IP is a soft IP and is only available after
> FPGA image is programmed.
>
> Make driver modulable to support use case FPGA image is programmed
> after kernel is booted. User proram FPGA image in kernel then only load
> MSI
From: Oleg Nesterov
Use DEFINE_STATIC_PERCPU_RWSEM() to initialize dup_mmap_sem.
Signed-off-by: Oleg Nesterov
Reviewed-by: Ingo Molnar
Signed-off-by: Paul E. McKenney
---
kernel/events/uprobes.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/kernel/events/uprobes.c b/
From: Oleg Nesterov
Turn DEFINE_STATIC_PERCPU_RWSEM() into __DEFINE_PERCPU_RWSEM() with the
additional "is_static" argument to introduce DEFINE_PERCPU_RWSEM().
Change cgroup.c to use DEFINE_PERCPU_RWSEM(cgroup_threadgroup_rwsem).
Signed-off-by: Oleg Nesterov
Reviewed-by: Ingo Molnar
Signed-of
From: Oleg Nesterov
Now that the RCU flavors have been consolidated, rcu_sync_type makes no
sense because none of internal update functions aside from .held() depend
on gp_type. This commit therefore removes this field and consolidates
the relevant code.
Signed-off-by: Oleg Nesterov
[ paulmck:
Update the documentation to reflect the new naming scheme with
latest changes.
Reported-by: Leo Yan
Cc: Mathieu Poirier
Cc: Jonathan Corbet
Signed-off-by: Suzuki K Poulose
---
Documentation/trace/coresight.txt | 34 +++---
1 file changed, 19 insertions(+), 15 delet
Hi Anshuman,
>From reviwing the below, I can see some major issues that need to be
addressed, which I've commented on below.
Andrew, please do not pick up this patch.
On Wed, May 29, 2019 at 02:46:27PM +0530, Anshuman Khandual wrote:
> The arch code for hot-remove must tear down portions of the
Friendly ping...
On 2019/4/18 21:36, Yue Haibing wrote:
> From: YueHaibing
>
> Fix sparse warning:
>
> drivers/phy/ti/phy-am654-serdes.c:250:12: warning:
> symbol 'serdes_am654_xlate' was not declared. Should it be static?
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
> ---
> dri
On Thu, May 30, 2019 at 4:52 AM Ondrej Mosnacek wrote:
>
> On Thu, May 30, 2019 at 10:51 AM Gen Zhang wrote:
> > In selinux_sb_eat_lsm_opts(), 'arg' is allocated by kmemdup_nul(). It
> > returns NULL when fails. So 'arg' should be checked.
> >
> > Signed-off-by: Gen Zhang
> > Fixes: 99dbbb593fe6
On Thu, May 30, 2019 at 10:20:11AM -0400, Neil Horman wrote:
> On Wed, May 29, 2019 at 08:37:57PM -0300, Marcelo Ricardo Leitner wrote:
> > On Wed, May 29, 2019 at 03:07:09PM -0400, Neil Horman wrote:
> > > --- a/net/sctp/sm_make_chunk.c
> > > +++ b/net/sctp/sm_make_chunk.c
> > > @@ -2419,9 +2419,1
Because TREE01 can end up running more vCPUs that physical CPUs,
hammering these shortchanged CPUs with tight loops containing call_rcu()
invocations seems a bit like overkill. This commit therefore exempts
TREE01 from rcutorture's forward-progress testing.
Signed-off-by: Paul E. McKenney
---
t
Signed-off-by: Paul E. McKenney
---
kernel/rcu/rcutorture.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 6b803fb2f7ca..89be0f492f78 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -1060,8 +1060
In !PREEMPT kernels, cond_resched() is a no-op. In NO_HZ_FULL kernels,
in-kernel execution (such as that of rcutorture's kthreads) might extend
indefinitely without the scheduler gaining the aid of a scheduling-clock
interrupt. This combination can make the interaction of an rcutorture
forward-pr
Currently qemu output appears on standard output, but is inaccessible
later on. This commit therefore captures this output and causes
kvm-recheck.sh to output this output if QEMU gave a non-zero non-137
exit code. (And exit code of 137 indicates that QEMU was killed, in
which case we want to know
Hello!
This series contains torture-test updates:
1. Make jitter.sh select from only online CPUs, courtesy of
Joel Fernandes.
2. Add cpu0 to the set of CPUs to add jitter, courtesy of Joel
Fernandes.
3. Add cond_resched() to forward-progress free-up loop.
4.
Signed-off-by: Paul E. McKenney
---
tools/testing/selftests/rcutorture/bin/kvm.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/rcutorture/bin/kvm.sh
b/tools/testing/selftests/rcutorture/bin/kvm.sh
index 8f1e337b9b54..3b4868906794 100755
--- a/tools/testing/selfte
The stutter_wait() function is supposed to return true if it actually
waits and false otherwise, but it instead unconditionally returns false.
Which hides a bug in rcu_torture_writer() that fails to account for
the fact that one of the rcu_tortures[] array elements will normally be
referenced by rc
The current rcutorture scripts unconditionally do "make clean", which is
a good way of getting the needed testing done despite any imperfections in
Makefile dependency tracking. However, this can be a bit irritating when
repeatedly running a single scenario after small changes, for example,
when d
From: Sebastian Andrzej Siewior
In one of my rcutorture tests the TSC clocksource got marked unstable
due to a large difference in the TSC value. I'm not sure if the guest
run for a long time with disabled interrupts or if the host was very
busy and didn't schedule the guest for some time.
I too
From: "Joel Fernandes (Google)"
The rcutorture jitter.sh script selects a random CPU but does not check
if it is offline or online. This leads to taskset errors many times. On
my machine, hyper threading is disabled so half the cores are offline
causing taskset errors a lot of times. Let us fix t
From: "Joel Fernandes (Google)"
jitter.sh currently does not add CPU0 to the list of CPUs for adding of
jitter. Let us add it to this list even when it is not hot-pluggable.
Signed-off-by: Joel Fernandes (Google)
Signed-off-by: Paul E. McKenney
---
tools/testing/selftests/rcutorture/bin/jitte
When trace_printk() is used, a message including "BUG" is printed to
the console, which fools the rcutorture scripting into believing that
the corresponding test scenario failed. This commit therefore filters
out this particular instance of "BUG", thus avoiding the false-positive
test-failure repo
This commit provides a rudimentary Makefile that runs a 10-minute
rcutorture test on scenario TREE01. This must be run on a system capable
of spawning virtual machines and with everything installed to permit
building Linux kernels.
Reported-by: Shuah Khan
Signed-off-by: Paul E. McKenney
---
to
This commit causes both kvm-find-errors.sh and kvm-recheck.sh to provide
an exit status based on whether or not errors were located. In the
case of kvm-recheck.sh, this will be the error status of the last run.
This change allows these commands to be used in scripting and Makefiles
to automaticall
After the end of each stutter pause interval, the rcu_torture_writer()
kthread checks to be sure that all prior callbacks have completed so
that all the test structures have been freed. This works fine except
for tasks RCU, in which grace periods can take one good long time.
This commit therefore
Currently, rcutorture will use relatively few CPUs to build the kernel
on a busy system, which is often as it should be. However, if the user
has used the --cpus argument to dedicate a specified number of CPUs to
this torture test, it would be good if the kernel build also made use
of them. This
From: Eric W. Biederman
> Sent: 30 May 2019 14:01
> Oleg Nesterov writes:
>
> > Al, Linus, Eric, please help.
> >
> > The previous discussion was very confusing, we simply can not understand
> > each
> > other.
> >
> > To me everything looks very simple and clear, but perhaps I missed something
Once removed, an rcu_torture element can be deferred-freed by a chain
of call_rcu() invocations, with each callback invoking another round of
call_rcu() until either a fixed number of call_rcu() invocations have
been chained or until the test ends. This means that if the test ends,
some of the rcu
Various security techniques can obfuscate pointer printouts on the
console. Unfortunately, rcutorture relies on either "null" or all zeroes
to identify the last few statistics printouts at the end of the test.
These need to be identified because failing to do so will results in
false-positive comp
Currently, the inter-stutter interval is the same as the stutter duration,
that is, whatever number of jiffies is passed into torture_stutter_init().
This has worked well for quite some time, but the addition of
forward-progress testing to rcutorture can delay processes for several
seconds, which c
I have been showing off a trivial RCU implementation for non-preemptive
environments for some time now:
#define rcu_read_lock()
#define rcu_read_unlock()
#define rcu_dereference(p) READ_ONCE(p)
#define rcu_assign_pointer(p, v) smp_store_release(&(p), (v))
vo
For historical reasons, rcutorture places its build products in a
tools/testing/selftests/rcutorture/b1 directory using the O= kbuild
command-line argument. However, doing this requires that the source
directory be pristine: Not just "make clean" pristine, but instead "make
mrproper" (or, equivale
The rcu_torture_fwd_prog_cbfree() function frees callbacks used during
rcutorture's call_rcu() forward-progress test, but does so in a tight
loop. This could cause problems given a very long list of callbacks to be
freed, and actual testing produces lists with as many as 25M callbacks.
This commit
On Thu, 30 May 2019 at 18:06, Richard Cochran wrote:
>
> On Thu, May 30, 2019 at 05:57:30PM +0300, Vladimir Oltean wrote:
> > On Thu, 30 May 2019 at 17:30, Richard Cochran
> > wrote:
> > >
> > > Not necessarily. If two frames that arrive at nearly the same time
> > > get their timestamps mixed
Hi Eric,
On Thu, May 30, 2019 at 05:21:40AM -0700, Eric Dumazet wrote:
> On Thu, May 30, 2019 at 3:31 AM Feng Tang wrote:
> >
> > On Wed, Apr 03, 2019 at 02:34:36PM +0800, kernel test robot wrote:
> > > Greeting,
> > >
> > > FYI, we noticed a -25.7% regression of netperf.Throughput_Mbps due to
>
On Fri, May 24, 2019 at 02:07:25PM +0800, Ley Foon Tan wrote:
> This fix issue when access config from PCIe switch.
>
> Stratix 10 PCIe controller does not support Type 1 to Type 0 conversion
> as previous version (V1) does.
>
> The PCIe controller need to send Type 0 config TLP if the targeting
On Wed, May 29, 2019 at 03:47:08PM -0500, Dan Murphy wrote:
> On 5/29/19 10:10 AM, Mark Brown wrote:
> > On Wed, May 29, 2019 at 06:51:32AM -0500, Dan Murphy wrote:
> > > Although I don't disagree with you I don't see how the interface is
> > > fragile
> > > with only these 3 regulators defined.
The fragmentation code tries to parse the header options in order
to figure out where to insert the fragment option. Since nexthdr points
to an invalid option, the calculation of the size of the network header
can made to be much larger than the linear section of the skb and data
is read outside o
On 5/30/19 4:28 AM, Paolo Bonzini wrote:
+static const struct blk_mq_ops scsi_mq_ops_no_commit = {
+ .get_budget = scsi_mq_get_budget,
+ .put_budget = scsi_mq_put_budget,
+ .queue_rq = scsi_queue_rq,
+ .complete = scsi_softirq_done,
+ .timeout
ebied...@xmission.com (Eric W. Biederman) writes:
> Which means I believe we have a semantically valid change in behavior
> that is causing a regression.
I haven't made a survey of all of the functions yet but
fucntions return -ENORESTARTNOHAND will never return -EINTR and are
immune from this pr
On Thu 30-05-19 14:57:46, Yang Shi wrote:
> Hi folks,
>
>
> As what we discussed about page demotion for PMEM at LSF/MM, the demotion
> should respect to the mempolicy and allowed mems of the process which the
> page (anonymous page only for now) belongs to.
cpusets memory mask (aka mems_allowed
From: Vincenzo Frascino On Thursday, May 30, 2019
7:16 AM
>
> The x86 vDSO library requires some adaptations to take advantage of the
> newly introduced generic vDSO library.
>
> Introduce the following changes:
> - Modification of vdso.c to be compliant with the common vdso datapage
> - Use
> On May 30, 2019, at 8:38 AM, Eric W. Biederman wrote:
>
> ebied...@xmission.com (Eric W. Biederman) writes:
>
>> Which means I believe we have a semantically valid change in behavior
>> that is causing a regression.
>
> I haven't made a survey of all of the functions yet but
> fucntions return -
On Wed, May 29, 2019 at 07:52:32AM -0500, Bjorn Helgaas wrote:
> On Wed, May 29, 2019 at 11:43:52AM +0200, Niklas Cassel wrote:
> > Currently, there is only a 1 ms sleep after asserting PERST.
> >
> > Reading the datasheets for different endpoints, some require PERST to be
> > asserted for 10 ms i
Hi Robin,
On 10/05/2019 11:38, Robin Murphy wrote:
Hi Suzuki,
On 10/05/2019 10:31, Suzuki K Poulose wrote:
Instead of using smp_processor_id() to figure out the node,
use the numa_node_id() for the current CPU node to avoid
splats like :
diff --git a/drivers/hwtracing/coresight/coresight
On Thu, 30 May 2019 11:16:22 +0200,
kernelci.org bot wrote:
>
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * This automated bisection report was sent to you on the basis *
> * that you may be involved with the breaking commit it has *
> * found. No manual investigat
On Wed, May 29, 2019 at 11:43:52AM +0200, Niklas Cassel wrote:
> Currently, there is only a 1 ms sleep after asserting PERST.
>
> Reading the datasheets for different endpoints, some require PERST to be
> asserted for 10 ms in order for the endpoint to perform a reset, others
> require it to be as
On 30/05/19 17:36, Bart Van Assche wrote:
> On 5/30/19 4:28 AM, Paolo Bonzini wrote:
>> +static const struct blk_mq_ops scsi_mq_ops_no_commit = {
>> + .get_budget = scsi_mq_get_budget,
>> + .put_budget = scsi_mq_put_budget,
>> + .queue_rq = scsi_queue_rq,
>> + .complete = sc
From: Colin Ian King
The variable err is initialized with a value that is never read
and err is reassigned a few statements later. This initialization
is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
net/ipv4/nexthop.c | 2 +-
1 file chang
When a new control group is created __init_one_rdt_domain() walks all
the other closids to calculate the sets of used and unused bits.
If it discovers a pseudo_locksetup group, it breaks out of the loop.
This means any later closid doesn't get its used bits added to used_b.
These bits will then ge
On 05/30, Eric W. Biederman wrote:
>
> Oleg Nesterov writes:
>
> > Al, Linus, Eric, please help.
> >
> > The previous discussion was very confusing, we simply can not understand
> > each
> > other.
> >
> > To me everything looks very simple and clear, but perhaps I missed something
> > obvious? P
On Thu, May 30, 2019 at 02:27:28PM +0800, Hsin-Yi Wang wrote:
> On Fri, May 10, 2019 at 9:27 PM michael.kao wrote:
>
> > +
> > + tzts1: tzts1 {
> > + polling-delay-passive = <0>;
> > + polling-delay = <0>;
> > +
On 05/30, Eric W. Biederman wrote:
>
> ebied...@xmission.com (Eric W. Biederman) writes:
>
> > Which means I believe we have a semantically valid change in behavior
> > that is causing a regression.
>
> I haven't made a survey of all of the functions yet but
> fucntions return -ENORESTARTNOHAND wil
On 5/29/19 11:21 PM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20190529:
>
on i386 or x86_64:
when CONFIG_PROC_SYSCTL is not set/enabled:
ld: drivers/base/firmware_loader/fallback_table.o:(.data+0x1c): undefined
reference to `sysctl_vals'
ld: drivers/base/firmware_loader/fallback_tab
The cacheinfo structures are alloced/freed by cpu online/offline
callbacks. Originally these were only used by sysfs to expose the
cache topology to user space. Without any in-kernel dependencies
CPUHP_AP_ONLINE_DYN was an appropriate choice.
resctrl has started using these structures to identify
Hi Linus,
The fixes are still trickling in for arm64, but the only really significant
one here is actually fixing a regression in the botched module relocation
range checking merged for -rc2. Hopefully we've nailed it this time.
Please pull.
Thanks,
Will
--->8
The following changes since comm
On 05/30, David Laight wrote:
>
> 4) As an optimisation a signal that arrives after the timer
>expires, but before the mask is restored can be 'deemed'
>to have happened before the timeout expired and EINTR
>returned.
This is what pselect/ppoll already does.
Oleg.
On Thu, May 30, 2019 at 8:04 AM Stephen Smalley wrote:
>
> On 5/30/19 10:31 AM, Andy Lutomirski wrote:
> > Hi all-
> >
> > After an offline discussion with Sean yesterday, here are some updates
> > to the user API parts of my proposal.
> >
> > Unfortunately, Sean convinced me that MAXPERM doesn't
Are there any objections or feedback on the proposed fix below? This
is kind of a serious regression.
On Fri, May 24, 2019 at 01:39:00PM -0400, Johannes Weiner wrote:
> From 63a0dbc571ff38f7c072c62d6bc28192debe37ac Mon Sep 17 00:00:00 2001
> From: Johannes Weiner
> Date: Fri, 24 May 2019 10:12:46
On Thu, May 23, 2019 at 01:28:44PM -0700, Alexei Starovoitov wrote:
> On Thu, May 23, 2019 at 01:16:08AM -0400, Kris Van Hees wrote:
> > On Wed, May 22, 2019 at 01:16:25PM -0700, Alexei Starovoitov wrote:
> > > On Wed, May 22, 2019 at 12:12:53AM -0400, Kris Van Hees wrote:
> > > >
> > > > Could yo
On Wed, May 29, 2019 at 10:52 PM Chris Chiu wrote:
> You mean moving the ratr_index to be the 4th function parameter of
> update_rate_mask which has 2 candidates rtl8xxxu_update_rate_mask
> and rtl8xxxu_gen2_update_rate_mask? I was planning to keep the
> rtl8xxxu_update_rate_mask the same because
On Thu, May 30, 2019 at 1:02 AM Minchan Kim wrote:
>
> On Thu, May 30, 2019 at 08:57:55AM +0200, Michal Hocko wrote:
> > On Thu 30-05-19 11:17:48, Minchan Kim wrote:
> > > On Wed, May 29, 2019 at 12:33:52PM +0200, Michal Hocko wrote:
> > > > On Wed 29-05-19 03:08:32, Daniel Colascione wrote:
> > >
On Fri, May 24, 2019 at 11:50:41AM -0700, Alan Mikhak wrote:
> Hi Kishon,
>
> Yes. This change is still applicable even when the platform specifies
> that it only supports 64-bit BARs by setting the bar_fixed_64bit
> member of epc_features.
>
> The issue being fixed is this: If the 'continue' sta
On Thu, May 30, 2019 at 11:06:39PM +0800, l00383200 wrote:
> Without optimization, both save_stack_trace_tsk and __save_stack_trace
> will have stacktrace information in ARM32.
>
> In this situation, "data.skip += 2" operation will skip the first two layers,
> which may make the stacktrace strange
From: Eric W. Biederman
> Sent: 30 May 2019 16:38
> ebied...@xmission.com (Eric W. Biederman) writes:
>
> > Which means I believe we have a semantically valid change in behavior
> > that is causing a regression.
>
> I haven't made a survey of all of the functions yet but
> fucntions return -ENORE
On Thu, 30 May 2019 at 08:48, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 5.0.20 release.
> There are 346 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Res
On 30.05.2019 16:13, Arnaldo Carvalho de Melo wrote:
> Em Thu, May 30, 2019 at 11:24:49AM +0300, Alexey Budankov escreveu:
>> On 29.05.2019 22:25, Arnaldo Carvalho de Melo wrote:
>>> Em Wed, May 29, 2019 at 05:30:49PM +0300, Alexey Budankov escreveu:
>>
+++ b/tools/perf/util/evsel.c
+#
On Thu, 30 May 2019 at 08:59, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.9.180 release.
> There are 128 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Re
From: Colin Ian King
The variable bud is initialized with the value 'LAST' which is never
read and bud is reassigned later on the return from the call to the
function handle_to_buddy. This initialization is redundant and
can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin I
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
test
head: 685a26bc60076305987bf06cfd1269e5e4094c73
commit: 685a26bc60076305987bf06cfd1269e5e4094c73 [69/69] rcu/nocb: Avoid
->nocb_lock capture by corresponding CPU
config: x86_64-randconfig-x009-201921 (attached as
On 30/05/2019 05:09, Palmer Dabbelt wrote:
[...]
>
> Sorry I missed this the first time around.
>
> Reviewed-by: Palmer Dabbelt
>
> Do you want this through the RISC-V tree, or are you going to take it?
Thanks! It's a standalone change so this would be fine through your tree.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
test
head: 77ef1b88654653681661fb0ce7cc1d6e712a409f
commit: 6ad9e6bcf543a758d4b7323cb2909ebd66f39ee4 [70/72] fixup! rcu/nocb: Avoid
->nocb_lock capture by corresponding CPU
config: alpha-allmodconfig (attached as .con
On 5/14/19 5:29 PM, Vineet Gupta wrote:
> In case of successful page fault handling, this patch releases mmap_sem
> before updating the perf stat event for major/minor faults. So even
> though the contention reduction is NOT supe rhigh, it is still an
> improvement.
This patch causes regression: L
On Thu, May 30, 2019 at 05:39:33PM +0300, Alexander Filippov wrote:
> VESNIN is an OpenPower machine with an Aspeed 2400 BMC SoC manufactured
> by YADRO.
>
> Signed-off-by: Alexander Filippov
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/aspeed-bmc-opp-vesnin.d
Instead of using smp_processor_id() to figure out the node,
use the numa_node_id() for the current CPU node to avoid
splats like :
BUG: using smp_processor_id() in preemptible [] code: perf/1743
caller is alloc_etr_buf.isra.6+0x80/0xa0
CPU: 1 PID: 1743 Comm: perf Not tainted 5.1.0-rc6-1
We find the current CPU using smp_processor_id() if the event is not bound
to a CPU, to find the node for memory allocation. Use the safe
numa_node_id() instead, to avoid BUG(). e.g:
BUG: using smp_processor_id() in preemptible [] code: perf/2544
caller is tmc_alloc_etf_buffer+0x5c/0x60
We find the current CPU using smp_processor_id() if the event is not bound
to a CPU, to find the node for memory allocation. Use the safe
numa_node_id() instead, to avoid BUG(). e.g:
BUG: using smp_processor_id() in preemptible [] code: perf/2544
Fixes: 2997aa4063d97fdb39 ("coresight: et
We find the current CPU using smp_processor_id() if the event is not bound
to a CPU, to find the node for memory allocation. Use the safe
numa_node_id() instead, to avoid BUG().
BUG: using smp_processor_id() in preemptible [] code: perf/1743
caller is tmc_alloc_etr_buffer+0x1bc/0x1f0
CP
We have a few places where we call smp_processor_id() from preemptible
contexts during the perf buffer handling. We do this to figure out the
numa node for the allocation in case the event is not CPU bound. Use
numa_node_id() instead in such cases to avoid a splat.
Changes since V2:
- Use NUMA_NO
On 5/29/19 2:17 AM, Hans de Goede wrote:
...
> Dave, can you try building your initrd without the hid-logitech-dj module
> included in the initrd?
I did this on a vanilla 5.2-rc2 kernel (without the reverts) and still
experienced the boot hang while the device was inserted.
> Also can you check i
drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of
`dma_alloc_coherent' from incompatible pointer type
[-Werror=incompatible-pointer-types]
This is fixed by
firmware: qcom_scm: Use proper types for dma mappings
but this is not present in all relevant stable branches.
We curr
On Thu, May 30, 2019 at 8:48 AM Deepa Dinamani wrote:
>
> > On May 30, 2019, at 8:38 AM, Eric W. Biederman
> > wrote:
> >
> > ebied...@xmission.com (Eric W. Biederman) writes:
> >
> >> Which means I believe we have a semantically valid change in behavior
> >> that is causing a regression.
> >
>
On Thu, May 30, 2019 at 09:13:39AM +, Tony W Wang-oc wrote:
> On Thu, May 30, 2019, Tony W Wang-oc wrote:
> > Hi Ashok,
> > I have two questions about this patch, could you help to check:
> >
> > 1, for broadcast #MC exceptions, this patch seems require #MC exception
> > errors
> > set MCG_STA
On many boards, communication between the kernel and the Embedded
Controller happens over an LPC bus. In these cases, the kernel config
CONFIG_CROS_EC_LPC is enabled. Some of these LPC boards contain a
Microchip Embedded Controller (MEC) that is different from the regular
EC. On these devices, the
401 - 500 of 952 matches
Mail list logo
