On Tue, Jun 26, 2018 at 2:48 AM, Paolo Abeni wrote:
> Hi,
>
> On Mon, 25 Jun 2018 11:21:38 -0700 Kees Cook wrote:
>> On Mon, Jun 25, 2018 at 8:08 AM, Chris von Recklinghausen
>> wrote:
>> > Enabling HARDENED_USER_COPY causes measurable regressions in the
>> > networking performances, up to 8% un
On 26/06/18 17:15, Alexandre Belloni wrote:
> Hi,
>
> On 26/06/2018 16:51:40+0100, Jon Hunter wrote:
>>> rtc: tps6586x: let the core handle rtc range
>>
>> Sorry I am missing the original mail with the above change, but I
>> have noticed on v4.18-rc1 that rtc wake-ups from suspend are no
>
BMC firmware should support some multi-master use cases such as multi-node,
IPMB, BMC-ME link and so on but the current ASPEED I2C driver is a bit
unstable for the multi-master use case. So this patch improves ASPEED I2C
driver to support the multi-master use case stably.
Changes:
* Added XFER_MOD
On 06/26/2018 06:24 AM, Janosch Frank wrote:
> Use huge_ptep_get to translate huge ptes to normal ptes so we can
> check them with the huge_pte_* functions. Otherwise some architectures
> will check the wrong values and will not wait for userspace to bring
> in the memory.
>
> Signed-off-by: Janos
On Wed, Jun 13, 2018 at 01:04:47PM +0530, Radhey Shyam Pandey wrote:
> The AXI VDMA core supports Vertical flip in S2MM path when Enable
> Vertical Flip (Advanced tab) is selected. To allow vertical flip
> programming define an optional 'xlnx,enable-vert-flip' channel
> child node property.
>
> Si
Hi Andy,
Thanks for the review!
On Mon, Jun 25, 2018 at 12:38:50PM +0300, Andy Shevchenko wrote:
> On Sat, Jun 23, 2018 at 7:11 PM, Manivannan Sadhasivam
> wrote:
> > Add Actions Semi OWL family S900 I2C driver.
> >
> > Signed-off-by: Manivannan Sadhasivam
> > ---
> > drivers/i2c/busses/Kconfi
On Thu, Jun 21, 2018 at 08:27:41PM +0900, Tetsuo Handa wrote:
> On 2018/06/21 7:36, David Rientjes wrote:
> >> @@ -1010,6 +1010,33 @@ int unregister_oom_notifier(struct notifier_block
> >> *nb)
> >> EXPORT_SYMBOL_GPL(unregister_oom_notifier);
> >>
> >> /**
> >> + * try_oom_notifier - Try to re
On Tue, 26 Jun 2018 15:57:39 +0200 Vlastimil Babka wrote:
> On 06/22/2018 06:28 PM, Michal Hocko wrote:
> > From: Michal Hocko
> >
> > There is no real reason to blow up just because the caller doesn't know
> > that __get_free_pages cannot return highmem pages. Simply fix that up
> > silently.
On 06/26/2018 11:50 AM, Kees Cook wrote:
> On Mon, Jun 25, 2018 at 5:54 PM, Gustavo A. R. Silva
> wrote:
>>
>>
>> On 06/25/2018 06:06 PM, Kees Cook wrote:
>>> On Mon, Jun 25, 2018 at 2:23 PM, Joe Perches wrote:
warning-3 += -Wswitch-default
>>>
>>> This reminds me, though. Should _this_
On Mon, Jun 25, 2018 at 08:47:40AM -0700, Andy Lutomirski wrote:
> On Sun, Jun 24, 2018 at 10:41 PM Naresh Kamboju
> wrote:
> >
> > Kselftest test case mov_ss_trap_64 is causing kernel panic on
> > qemu-system-x86_64 and PASS on real x86_64 hardware.
> >
> > Test code snippet,
> > main() {
> > <>
These three lines make up what msleep() already does, i.e. setting the
task to uninterruptible, sleeping for so many jiffies, and then
schedule() already puts the task state back to TASK_RUNNING when it
returns. Make things clearer by just calling msleep() instead.
Cc: Thierry Escande
Signed-off-
On 2018-06-26 21:14, Tyler Baicar wrote:
lspci uses abbreviated naming for AER error strings. Adopt the
same naming convention for the AER printing so they match.
Signed-off-by: Tyler Baicar
---
drivers/pci/pcie/aer.c | 46
+++---
1 file changed, 23 in
On Mon, Jun 25, 2018 at 05:34:52PM -0700, Paul E. McKenney wrote:
> If any scheduling-clock interrupt interrupts an RCU-preempt read-side
> critical section, the interrupted task's ->rcu_read_unlock_special.b.need_qs
> field is set. This causes the outermost rcu_read_unlock() to incur the
> extra
Without special fail-safe quiescent-state-propagation checks, grace-period
hangs can result from the following scenario:
1. CPU 1 goes offline.
2. Because CPU 1 is the only CPU in the system blocking the current
grace period, as soon as rcu_cleanup_dying_idle_cpu()'s call to
This commit updates dump_blkd_tasks() to print out quiescent-state
bitmasks for the rcu_node structures further up the tree. This
information helps debugging of interactions between CPU-hotplug
operations and RCU grace-period initialization.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree_p
Consider the following sequence of events in a PREEMPT=y kernel:
1. All CPUs corresponding to a given rcu_node structure go offline.
A new grace period starts just after the CPU-hotplug code path
does its synchronize_rcu() for the last CPU, so at least this
CPU is pres
Now that quiescent states for newly offlined CPUs are reported either
when that CPU goes offline or at the end of grace-period initialization,
the CPU-hotplug failsafe in the force-quiescent-state code path is no
longer needed.
This commit therefore removes this failsafe.
Signed-off-by: Paul E. M
Currently, rcu_init_new_rnp() walks up the rcu_node combining tree,
setting bits in the ->qsmaskinit fields on the way up. It walks up
unconditionally, regardless of the initial state of these bits. This is
OK because only the corresponding RCU grace-period kthread ever tests
or sets these bits d
On Tue, Jun 19, 2018 at 12:21:05PM +0100, Lorenzo Pieralisi wrote:
> Commit 51bc085d6454 ("PCI: Improve host drivers compile test coverage")
> added configuration options to allow PCI host controller drivers to be
> compile tested on all architectures.
>
> Some host controller drivers (eg PCIE_ALT
CPUs are expected to report quiescent states when coming online and
when going offline, and grace-period initialization is supposed to
handle any race conditions where a CPU's ->qsmask bit is set just after
it goes offline. This commit adds diagnostics for the case where an
offline CPU nevertheles
The rcu_lockdep_current_cpu_online() function currently checks only the
RCU-sched data structures to determine whether or not RCU believes that a
given CPU is offline. Unfortunately, there are multiple flavors of RCU,
which means that there is a short window of time during which the various
flavor
If rcu_report_unblock_qs_rnp() is invoked on something other than
preemptible RCU or if there are still preempted tasks blocking the
current grace period, something went badly wrong in the caller.
This commit therefore adds WARN_ON_ONCE() to these conditions, but
leaving the legitimate reason for e
Commit 0aa04b055e71 ("rcu: Process offlining and onlining only at
grace-period start") deferred handling of CPU-hotplug events until the
start of the next grace period, but consider the following sequence
of events:
1. A task is preempted within an RCU-preempt read-side critical
secti
This commit gets rid of the smp_wmb() in record_gp_stall_check_time()
in favor of an smp_store_release().
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index d526c2125564..78dd96
Now that quiescent-state reporting is fully event-driven, this commit
removes the check for a lost quiescent state from force_qs_rnp().
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/kernel/rcu/tree.c b/
Consider the following sequence of events in a PREEMPT=y kernel:
1. All but one of the CPUs corresponding to a given leaf rcu_node
structure go offline. Each of these CPUs clears its bit in that
structure's ->qsmaskinitnext field.
2. A new grace period starts, and rcu_g
Grace-period initialization first processes any recent CPU-hotplug
operations, and then initializes state for the new grace period. These
two phases of initialization are currently not distinguished in debug
prints, but the distinction is valuable in a number of debug situations.
This commit there
Interactions between CPU-hotplug operations and grace-period
initialization can result in dump_blkd_tasks(). One of the first
debugging actions in this case is to search back in dmesg to work
out which of the affected rcu_node structure's CPUs are online and to
determine the last CPU-hotplug opera
Consider the following sequence of events in a PREEMPT=y kernel:
1. All CPUs corresponding to a given leaf rcu_node structure are
offline.
2. The first phase of the rcu_gp_init() function's grace-period
initialization runs, and sets that rcu_node structure's
->qs
Jann,
> As Al Viro noted in commit 128394eff343 ("sg_write()/bsg_write() is
> not fit to be called under KERNEL_DS"), sg improperly accesses
> userspace memory outside the provided buffer, permitting kernel memory
> corruption via splice(). But it doesn't just do it on ->write(), also
> on ->re
Some RCU bugs have been sensitive to the frequency of CPU-hotplug
operations, which have been gradually increased over time. But this
frequency is now at the one-second lower limit that can be specified using
the rcutorture.onoff_interval kernel parameter. This commit therefore
changes the units
Without special fail-safe quiescent-state-propagation checks, grace-period
hangs can result from the following scenario:
1. A task running on a given CPU is preempted in its RCU read-side
critical section.
2. That CPU goes offline, and there are now no online CPUs
corres
at 4:00 PM, Nadav Amit wrote:
> All of these patches are intended for 4.18:
>
> - Patches 1-5 are bug fixes.
> - Patch 6 changes the GPL comment. It is actually required just to
> remove the maintainers list from the source file (since it has
> changed).
> - Patch 7 is an update to the maintai
On Tue, Jun 26, 2018 at 04:22:00PM +0200, Rafael J. Wysocki wrote:
> On Tue, Jun 26, 2018 at 4:01 PM, Bjorn Helgaas wrote:
> > On Tue, Jun 26, 2018 at 12:06:01PM +0200, Rafael J. Wysocki wrote:
> >> From: Rafael J. Wysocki
> >> + /*
> >> + * In some cases (eg. Samsung 305V4A) leaving a
The force_qs_rnp() function checks for ->qsmask being all zero, that is,
all CPUs for the current rcu_node structure having already passed through
quiescent states. But with RCU-preempt, this is not sufficient to report
quiescent states further up the tree, so there are further checks that
can ini
[hopefully fixed the 'mm' recipient]
On Tue, 2018-06-26 at 09:54 -0700, Kees Cook wrote:
> On Tue, Jun 26, 2018 at 2:48 AM, Paolo Abeni wrote:
> > With CONFIG_HARDENED_USERCOPY=y, perf shows ~6% of CPU time spent
> > cumulatively in __check_object_size (~4%) and __virt_addr_valid (~2%).
>
> Are
Back in the old days, when grace-period initialization blocked CPU
hotplug, the ->qsmaskinit mask was indeed updated at the time that
a given CPU went offline. However, with the deferral of these updates
until the beginning of the next grace period in commit 0aa04b055e71
("rcu: Process offlining a
The main race with the early part of grace-period initialization appears
to be with CPU hotplug. To more fully open this race window, this commit
moves the rcu_gp_slow() from the beginning of the early initialization
loop to follow that loop, thus widening the race window, especially for
the rcu_n
This commit fixes a typo and adds some additional debugging to the
message emitted when a task blocking the current grace period is listed
as blocking it when either that grace period ends or the next grace
period begins. This commit also reformats the console message for
readability.
Signed-off-
On Mon, Jun 25, 2018 at 05:35:02PM -0700, Paul E. McKenney wrote:
> From: "Joel Fernandes (Google)"
>
> rcu_seq_snap may be tricky to decipher. Lets document how it works with
> an example to make it easier.
Since you had me looking at them functions; why isn't rcu_seq_snap()
using smp_load_acqu
RCU should only be waiting on CPUs that were online at the time that the
current grace period started. Failure to abide by this rule can result
in confusing splats during grace-period cleanup and initialization.
This commit therefore adds a check to RCU-preempt's preempted-task
queuing that checks
Hi All,
On 2018/6/21 17:20, Wei Xu wrote:
Hi James,
On 2018/6/21 9:38, James Morse wrote:
Hi Will, Wei,
On 20/06/18 17:25, Wei Xu wrote:
On 2018/6/20 23:54, James Morse wrote:
I have disabled CONFIG_ARM64_RAS_EXTN and reverted that commit.
But I still got the stack overflow issue sometimes.
On Tue, Jun 26, 2018 at 8:01 PM, Manivannan Sadhasivam
wrote:
> On Mon, Jun 25, 2018 at 12:38:50PM +0300, Andy Shevchenko wrote:
>> On Sat, Jun 23, 2018 at 7:11 PM, Manivannan Sadhasivam
>> wrote:
>> > +#define OWL_I2C_REG_CTL(0x)
>> > +#define OWL_I2C_REG_CLKDIV (0x0004)
On Tue, 2018-06-26 at 09:59 -0600, Mathieu Poirier wrote:
> On Mon, Jun 25, 2018 at 09:23:51AM -0700, Joe Perches wrote:
> > On Mon, 2018-06-25 at 12:22 +0100, Suzuki K Poulose wrote:
> > > Add the initial support for Coresight Address Translation Unit, which
> > > augments the TMC in Coresight SoC
On Tue, Jun 26, 2018 at 7:14 PM, Bjorn Helgaas wrote:
> On Tue, Jun 26, 2018 at 04:22:00PM +0200, Rafael J. Wysocki wrote:
>> On Tue, Jun 26, 2018 at 4:01 PM, Bjorn Helgaas wrote:
>> > On Tue, Jun 26, 2018 at 12:06:01PM +0200, Rafael J. Wysocki wrote:
>> >> From: Rafael J. Wysocki
>
>> >> +
Rather than accessing the TPM functions by passing a NULL pointer for
the tpm_chip, which causes a lookup for a suitable chip every time, get a
hold of a tpm_chip and access the TPM functions using it.
Signed-off-by: Stefan Berger
Acked-by: Jarkko Sakkinen
---
security/integrity/ima/ima.h
This series of patches converts IMA's usage of the tpm_chip to find a TPM
chip initially and use it until the machine is shut down. To do this we need
to introduce a kref for the tpm_chip that IMA and all other users of a
tpm_chip hold onto until they don't need the TPM chip anymore.
Stefan
v
Get rid of ima_used_chip and use ima_tpm_chip variable instead for
determining whether to use the TPM chip.
Signed-off-by: Stefan Berger
Acked-by: Jarkko Sakkinen
---
security/integrity/ima/ima.h| 1 -
security/integrity/ima/ima_crypto.c | 2 +-
security/integrity/ima/ima_init.c | 7 +
Rename tpm_chip_find_get() to tpm_find_get_ops() to more closely match
the tpm_put_ops() counter part.
Signed-off-by: Stefan Berger
Tested-by: Jarkko Sakkinen
Reviewed-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-chip.c | 9 ++---
drivers/char/tpm/tpm-interface.c | 14 +++---
Implement tpm_default_chip() to find the first TPM chip and return it to
the caller while increasing the reference count on its device. This
function can be used by other subsystems, such as IMA, to find the system's
default TPM chip and use it for all subsequent TPM operations.
Signed-off-by: Ste
Convert tpm_find_get_ops() to use tpm_default_chip() in case no chip
is passed in.
Signed-off-by: Stefan Berger
Reviewed-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-chip.c | 32 +---
1 file changed, 13 insertions(+), 19 deletions(-)
diff --git a/drivers/char/tpm/tp
Hi,
On 26.06.2018 18:36, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> To enable per-PMU access controls in a following patch first move all call
> sites of perf_paranoid_kernel() to after the event has been created.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Thomas Gleixner
> Cc: Peter Zijls
Hi,
On 26.06.2018 18:36, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> For situations where sysadmins might want to allow different level of
> access control for different PMUs, we start creating per-PMU
> perf_event_paranoid controls in sysfs.
>
> These work in equivalent fashion as the exi
Jonathan Cameron writes:
[...]
>
> I'll test it when back in the office, but I had a similar issue with
> memory only nodes when I moved the SRAT listing for cpus from the 4
> 4th mode to the 3rd node to fake some memory I could hot unplug.
> This gave a memory only node for the last node on the
Jonathan Cameron writes:
[...]
>
> I'll test it when back in the office, but I had a similar issue with
> memory only nodes when I moved the SRAT listing for cpus from the 4
> 4th mode to the 3rd node to fake some memory I could hot unplug.
> This gave a memory only node for the last node on the
On Tue, Jun 26, 2018 at 2:37 AM, Stephen Boyd wrote:
> Quoting Sudeep Holla (2018-06-25 10:15:45)
>>
>>
>> On 25/06/18 17:37, Stephen Boyd wrote:
>> > Quoting Rafael J. Wysocki (2018-06-16 08:50:18)
>> >> On Fri, Jun 15, 2018 at 7:43 PM, Stephen Boyd wrote:
>> >>>
>> >>> Is this for clk_enable/di
In the quest to remove all stack VLA usage from the kernel[1], this moves
the stack buffer used during decompression to be allocated externally.
The existing "dest_max_index" used in the VLA is bounded by cb_max_page.
cb_max_page is bounded by max_page, and max_page is bounded by nr_pages.
Since nr
In the quest to remove all stack VLA usage from the kernel[1], this series
removes all the VLAs in use in fs/ntfs/. A couple strategies are used,
and are detailed in the individual patches.
As far as I can tell, -mm was the last place to take NTFS-specific
patches, so I'm aiming this series at And
In the quest to remove all stack VLA usage from the kernel[1], this
allocates the maximum size stack buffer. Existing checks already require
that blocksize >= NTFS_BLOCK_SIZE and mft_record_size <= PAGE_SIZE, so
max_bhs can be at most PAGE_SIZE / NTFS_BLOCK_SIZE. Sanity checks are
added for robustn
On Tue, Jun 26, 2018 at 11:14 AM, Michael Straube
wrote:
> Using is_broadcast_ether_addr() and is_zero_ether_addr() instead of
> testing each byte of the mac[] array for 0xff and 0x00 shortens the
> code and improves readability.
>
> If np == NULL, of_get_property() returns NULL, hence the "np" ch
In the quest to remove all stack VLA usage from the kernel[1], this
uses the maximum size needed on the stack and adds a sanity check for
robustness: index.block_size cannot be larger than PAGE_SIZE nor less
than NTFS_BLOCK_SIZE.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=q
On 06/26/2018 07:22 AM, Kirill A. Shutemov wrote:
> Add new config option to enabled/disable Multi-Key Total Memory
> Encryption support.
>
> MKTME uses MEMORY_PHYSICAL_PADDING to reserve enough space in per-KeyID
> direct mappings for memory hotplug.
>
> Signed-off-by: Kirill A. Shutemov
> ---
On Mon, Jun 25, 2018 at 05:35:02PM -0700, Paul E. McKenney wrote:
> +/*
> + * rcu_seq_snap - Take a snapshot of the update side's sequence number.
> + *
> + * This function returns the earliest value of the grace-period sequence
> number
> + * that will indicate that a full grace period has elapse
Song noticed switch_mm_irqs_off taking a lot of CPU time in recent
kernels, using 1.9% of a 48 CPU system during a netperf run. Digging
into the profile, the atomic operations in cpumask_clear_cpu and
cpumask_set_cpu are responsible for about half of that CPU use.
However, the CPUs running netperf
CPUs in !is_lazy have either received TLB flush IPIs earlier on during
the munmap (when the user memory was unmapped), or have context switched
and reloaded during that stage of the munmap.
Page table free TLB flushes only need to be sent to CPUs in lazy TLB
mode, which TLB contents might not yet
Andy discovered that speculative memory accesses while in lazy
TLB mode can crash a system, when a CPU tries to dereference a
speculative access using memory contents that used to be valid
page table memory, but have since been reused for something else
and point into la-la land.
The latter proble
Lazy TLB mode can result in an idle CPU being woken up by a TLB flush,
when all it really needs to do is reload %CR3 at the next context switch,
assuming no page table pages got freed.
Memory ordering is used to prevent race conditions between switch_mm_irqs_off,
which checks whether .tlb_gen chan
Song noticed switch_mm_irqs_off taking a lot of CPU time in recent
kernels,using 1.8% of a 48 CPU system during a netperf to localhost run.
Digging into the profile, we noticed that cpumask_clear_cpu and
cpumask_set_cpu together take about half of the CPU time taken by
switch_mm_irqs_off.
However,
The mm_struct always contains a cpumask bitmap, regardless of
CONFIG_CPUMASK_OFFSTACK. That means the first step can be to
simplify things, and simply have one bitmask at the end of the
mm_struct for the mm_cpumask.
This does necessitate moving everything else in mm_struct into
an anonymous sub-st
Now that CPUs in lazy TLB mode no longer receive TLB shootdown IPIs, except
at page table freeing time, and idle CPUs will no longer get shootdown IPIs
for things like mprotect and madvise, we can always use lazy TLB mode.
Signed-off-by: Rik van Riel
Tested-by: Song Liu
---
arch/x86/include/asm
On Tue, Jun 26, 2018 at 11:14 AM, Michael Straube
wrote:
> Use ether_addr_copy() instead of memcpy() to copy the mac address.
>
Suggested-by ?
Btw, ensure that the source and destination buffers are aligned to u16
as required by API.
(It applies to all changes to ether_*addr_*() replacements)
On Tue, Jun 26, 2018 at 11:14 AM, Michael Straube
wrote:
> Use the mac_pton() helper to convert the mac address string.
>
> The functions key_char2num() and key_2char2num() are not used
> anywhere else and can be removed.
>
> This also has the benefit of validating the input since mac_pton()
> ret
On Tue, Jun 26, 2018 at 10:28 AM, Dmitry Vyukov wrote:
> From: Dmitry Vyukov
>
> KERN_CONT leads to split lines in kernel output
> and complicates useful changes to printk like
> printing context before each line.
>
> Only acceptable use of continuations is basically
> boot-time testing.
>
> Get
Hi Andy,
I would like to make the behavior rseq on compat tasks more robust
by ensuring that kernel/rseq.c:rseq_get_rseq_cs() clears the high
bits of rseq_cs->abort_ip, rseq_cs->start_ip and
rseq_cs->post_commit_offset when a 32-bit binary is run on a 64-bit
kernel.
The intent here is that if use
Add support for the tas5707 audio power amplifier.
Signed-off-by: Jerome Brunet
---
sound/soc/codecs/Kconfig | 5 ++-
sound/soc/codecs/tas571x.c | 110 +
sound/soc/codecs/tas571x.h | 16 +++
3 files changed, 130 insertions(+), 1 deletion(-)
d
Add the tas5707 to the available compatibles of the tas571x driver
Signed-off-by: Jerome Brunet
---
Documentation/devicetree/bindings/sound/tas571x.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/sound/tas571x.txt
b/Documentation/devicetree/bindings/sou
This patchset extends the tas571x driver to support the tas5707
audio power amplifier.
Jerome Brunet (2):
ASoC: tas571x: add tas5707 compatible
ASoC: tas517x: add tas5707 support
.../devicetree/bindings/sound/tas571x.txt | 1 +
sound/soc/codecs/Kconfig |
Hi,
On Mon, Jun 25, 2018 at 11:13:04PM +0900, Masahiro Yamada wrote:
> Hi Arnd, Olof,
>
> Please pull some fixes of ARM UniPhier platform.
>
>
>
> The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
>
> Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
>
> are available i
On Tue, Jun 26, 2018 at 10:10:39AM -0700, Paul E. McKenney wrote:
> diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
> index 3def94fc9c74..6683da6e4ecc 100644
> --- a/kernel/rcu/tree.h
> +++ b/kernel/rcu/tree.h
> @@ -363,6 +363,10 @@ struct rcu_state {
> const char *name;
On Mon, 2018-06-25 at 20:16 +0200, Jann Horn wrote:
> On Mon, Jun 25, 2018 at 6:41 PM Al Viro wrote:
> >
> > On Mon, Jun 25, 2018 at 06:34:10PM +0200, Jann Horn wrote:
> >
> > > + char tmp[32];
> > >
> > > - if (namelen > 32)
> > > + if (namelen < 0 || namelen > 32)
> > >
On Tue, Jun 26, 2018 at 06:32:55PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 26, 2018 at 06:16:04PM +0200, Anna-Maria Gleixner wrote:
> > Hi,
> >
> > during rcu torture tests (TREE04 and TREE07) I noticed, that a
> > WARN_ON_ONCE() in sched core triggers on a recent 4.18-rc2 based
> > kernel (6f0
Hi Wei,
On Wed, Jun 27, 2018 at 01:16:44AM +0800, Wei Xu wrote:
> Today I tried the kernel 4.18-rc2(defconfig, no change on top) with qemu
> 2.12.0.
> The guest sometimes still failed to boot. But the crash reason is different.
> Could you please share any hint?
> Thanks!
>
> The guest boot log i
On Tue, Jun 26, 2018 at 10:10:39AM -0700, Paul E. McKenney wrote:
> Without special fail-safe quiescent-state-propagation checks, grace-period
> hangs can result from the following scenario:
>
> 1.CPU 1 goes offline.
>
> 2.Because CPU 1 is the only CPU in the system blocking the current
>
The attached dmesg contains non printable chars 0x01 33 around "ACPI BIOS Error
(bug): Could not resolve" which is a new issue compared to the dmesg of 4.17.2
System is a stable hardened Gentoo Linux at a ThinkPad T440s.
--
Toralf
PGP C4EACDDE 0076E94E
dmesg-4.17.3
Description: Binary data
On Tue, Jun 26, 2018 at 07:08:12PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 25, 2018 at 05:34:52PM -0700, Paul E. McKenney wrote:
> > If any scheduling-clock interrupt interrupts an RCU-preempt read-side
> > critical section, the interrupted task's ->rcu_read_unlock_special.b.need_qs
> > field is
On Mon, Jun 25, 2018 at 10:49 PM Amir Goldstein wrote:
>
...
>
> The verb 'unuse' takes an argument memcg and 'uses' it - too weird.
> You can use 'override'/'revert' verbs like override_creds or just call
> memalloc_use_memcg(old_memcg) since there is no reference taken
> anyway in use_memcg and
Hi Abhishek,
On Wed, 20 Jun 2018 12:57:41 +0530, Abhishek Sahu
wrote:
> NAND parts can have bitflips in an erased page due to the
> process technology used. In this case, QCOM NAND controller
> is not able to identify that page as an erased page.
> Currently the driver calls nand_check_erased_ec
On Tue, Jun 26, 2018 at 07:14:54PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 25, 2018 at 05:35:02PM -0700, Paul E. McKenney wrote:
> > From: "Joel Fernandes (Google)"
> >
> > rcu_seq_snap may be tricky to decipher. Lets document how it works with
> > an example to make it easier.
>
> Since you
On Tue, Jun 26, 2018 at 07:30:55PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 25, 2018 at 05:35:02PM -0700, Paul E. McKenney wrote:
> > +/*
> > + * rcu_seq_snap - Take a snapshot of the update side's sequence number.
> > + *
> > + * This function returns the earliest value of the grace-period seque
Hi Masahiro,
On Tue, 26 Jun 2018 11:38:21 +0900, Masahiro Yamada
wrote:
> 2018-06-25 23:55 GMT+09:00 Boris Brezillon :
> > On Mon, 25 Jun 2018 09:50:18 -0500
> > Dinh Nguyen wrote:
> >
> >> On 06/22/2018 10:58 AM, Richard Weinberger wrote:
> >> > Masahiro,
> >> >
> >> > Am Freitag, 22. Juni
On Tue, Jun 26, 2018 at 09:49:49AM -0600, Rob Herring wrote:
> On Mon, Jun 25, 2018 at 2:03 PM Matthias Kaehlcke wrote:
> >
> > On Mon, Jun 25, 2018 at 11:50:37AM -0700, Matthias Kaehlcke wrote:
> > > Hi Rob,
> > >
> > > On Mon, Jun 25, 2018 at 09:33:41AM -0600, Rob Herring wrote:
> > > > On Wed,
Hi,
On Tue, Jun 26, 2018 at 8:02 AM, Mark Brown wrote:
> On Tue, Jun 26, 2018 at 08:00:29AM -0700, Doug Anderson wrote:
>> On Tue, Jun 26, 2018 at 5:07 AM, Mark Brown wrote:
>
>> > Please do not submit new versions of already applied patches, please
>> > submit incremental updates to the existin
On Tue, Jun 26, 2018 at 07:44:24PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 26, 2018 at 10:10:39AM -0700, Paul E. McKenney wrote:
> > diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
> > index 3def94fc9c74..6683da6e4ecc 100644
> > --- a/kernel/rcu/tree.h
> > +++ b/kernel/rcu/tree.h
> > @@ -363,
On Tue, Jun 26, 2018 at 10:47 AM Robert Jarzmik wrote:
>
> The RTC controller is fed by an external fixed 32kHz clock. Yet the
> driver wants to acquire this clock, even though it doesn't make any use
> of it, ie. doesn't get the rate to make calculation.
>
> Therefore, add the dummy clock in the
OSes have additional maintainers that should be cc'd on patches or may
want to circulate internal patches.
Parse the .get_maintainer.MAINTAINERS file. Entries in the file
can begin with a '+' to indicate the email and list entries should be
added to the exiting MAINTAINERS output, or a '-' to ind
On Tue, Jun 26, 2018 at 07:51:19PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 26, 2018 at 10:10:39AM -0700, Paul E. McKenney wrote:
> > Without special fail-safe quiescent-state-propagation checks, grace-period
> > hangs can result from the following scenario:
> >
> > 1. CPU 1 goes offline.
> >
On Sun, Jun 24, 2018 at 12:46:59AM +0200, Martin Blumenstingl wrote:
> Hello Yixun, Hello Liang,
>
> I have a few small comments inline below
> additionally I tried to explain the reason behind
> "amlogic,mmc-syscon", clkin0 and clkin1 so Rob (or the devicetree
> maintainers in general) can give f
Hi Peter,
On 26/06/18 17:43, Peter Zijlstra wrote:
> On Tue, Jun 26, 2018 at 05:20:45PM +0100, Allan Xavier wrote:
>> 0500 g F .text 0034 nmi_panic
>> 0528 l F .text 000c nmi_panic.cold.7
>>
>> This doesn't happen with -freorder-functions i
On Tue, Jun 26, 2018 at 10:43:31AM +0530, Balakrishna Godavarthi wrote:
> Hi Matthias,
>
> On 2018-06-26 05:35, Matthias Kaehlcke wrote:
> > On Mon, Jun 25, 2018 at 04:43:54PM -0700, Matthias Kaehlcke wrote:
> > > This is a nice improvement, a few remaining questions inline.
> > >
> > > On Mon, J
On 06/26/2018 01:23 PM, Stefan Berger wrote:
Convert tpm_find_get_ops() to use tpm_default_chip() in case no chip
is passed in.
Signed-off-by: Stefan Berger
Reviewed-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-chip.c | 32 +---
1 file changed, 13 insertions(+),
401 - 500 of 735 matches
Mail list logo
