On 6/22/20 5:30 PM, John Hubbard wrote:
On 2020-06-22 16:38, Ralph Campbell wrote:
The OpenCL function clEnqueueSVMMigrateMem(), without any flags, will
migrate memory in the given address range to device private memory. The
source pages might already have been migrated to device private
On 2020-06-22 20:17, Frank Rowand wrote:
> On 2020-06-22 17:23, Frank Rowand wrote:
>> On 2020-06-22 14:11, Lee Jones wrote:
>>> On Mon, 22 Jun 2020, Frank Rowand wrote:
>>>
On 2020-06-22 10:10, Lee Jones wrote:
> On Mon, 22 Jun 2020, Frank Rowand wrote:
>
>> On 2020-06-22 03:50,
On Mon, 2020-06-22 at 22:10 +0900, Alexandre Courbot wrote:
> On Fri, Jun 19, 2020 at 3:59 PM Tiffany Lin wrote:
> >
> > On Wed, 2020-05-20 at 17:27 +0900, Alexandre Courbot wrote:
> > > vidioc_try_fmt() does clamp height and width when called on the OUTPUT
> > > queue, so clamping them prior to
After commit 42acb06b01b1 ("drm: pahole struct drm_display_mode"), clang
warns:
drivers/gpu/drm/omapdrm/omap_connector.c:92:39: warning: braces around
scalar initializer [-Wbraced-scalar-init]
struct drm_display_mode new_mode = { { 0 } };
On Fri, Jun 19, 2020 at 02:20:01PM -0700, Douglas Anderson wrote:
> On a Chromebook I'm working on I noticed a big (~1 second) delay
> during bootup where nothing was happening. Right around this big
> delay there were messages about the TPM:
>
> [2.311352] tpm_tis_spi spi0.0: TPM ready IRQ
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_drv.h
between commit:
7fb81e9d8073 ("drm/i915: Use drmm_add_final_kfree")
from Linus' tree and commit:
8a25c4be583d ("drm/i915/params: switch to device specific parameters")
from the
On Tue, Jun 23, 2020 at 11:12 AM Alexey Kardashevskiy wrote:
>
> On 23/06/2020 04:59, Leonardo Bras wrote:
> >
> >> Also, despite this particular file, the "pdn" name is usually used for
> >> struct pci_dn (not device_node), let's keep it that way.
> >
> > Sure, I got confused for some time about
Unless there are any remaining objections to these patches, what are
the next steps towards getting these merged? Sorry, I'm not familiar
with the workflow for contributing patches to Linux.
Thanks,
David
On Tue, Jun 9, 2020 at 6:53 PM Michael S. Tsirkin wrote:
>
> On Tue, Jun 09, 2020 at
On Tue, Jun 23, 2020 at 09:21:28AM +0800, Xiaoyao Li wrote:
> On 6/23/2020 8:51 AM, Sean Christopherson wrote:
> >Remove support for context switching between the guest's and host's
> >desired UMWAIT_CONTROL. Propagating the guest's value to hardware isn't
> >required for correct functionality,
On Mon, 2020-06-22 at 21:44 +0900, Alexandre Courbot wrote:
> On Fri, Jun 19, 2020 at 4:26 PM Tiffany Lin wrote:
> >
> > On Wed, 2020-05-20 at 17:27 +0900, Alexandre Courbot wrote:
> > > Different chips have different supported bitrate ranges. Move the list
> > > of supported formats to the
When loading a module, module_frob_arch_sections() tries to figure out
the number of PLTs that'll be needed to handle all the RELAs. While
doing this, it tries to dedupe PLT allocations for multiple
R_AARCH64_CALL26 relocations to the same symbol. It does the same for
R_AARCH64_JUMP26 relocations.
On Fri, Jun 19, 2020 at 02:59:22PM +0200, David Hildenbrand wrote:
>Commit e900a918b098 ("mm: shuffle initial free memory to improve
>memory-side-cache utilization") promised "autodetection of a
>memory-side-cache (to be added in a follow-on patch)" over a year ago.
>
>The original series included
On 6/23/2020 12:22 AM, Matthew Wilcox wrote:
> It's been about 22 years since I contributed the patch which added
> support for the Acorn extensions ;-) But I'm pretty sure that it's not
> possible to have an Acorn CD-ROM that is also an HSF CD-ROM. That is,
> all Acorn formatted CD-ROMs are
On 6/23/2020 8:51 AM, Sean Christopherson wrote:
Remove support for context switching between the guest's and host's
desired UMWAIT_CONTROL. Propagating the guest's value to hardware isn't
required for correct functionality, e.g. KVM intercepts reads and writes
to the MSR, and the latency
On Mon, Jun 22, 2020 at 4:03 PM Bjorn Andersson
wrote:
>
> The SM8250 pinctrl driver provides pin configuration, pin muxing and
> GPIO pin control for many pins on the SM8250 SoC.
>
> Signed-off-by: Bjorn Andersson
Looks sane to me.
Reviewed-by: Jeffrey Hugo
Hi Nathan,
Thank you for the patch.
On Mon, Jun 22, 2020 at 04:47:39PM -0700, Nathan Chancellor wrote:
> After mm.h was removed from the asm-generic version of cacheflush.h,
> s390 allyesconfig shows several warnings of the following nature:
>
> In file included from
David
On 6/22/20 5:40 PM, David Miller wrote:
From: Dan Murphy
Date: Fri, 19 Jun 2020 11:18:10 -0500
+s32 phy_get_internal_delay(struct phy_device *phydev, struct device *dev,
+ const int *delay_values, int size, bool is_rx)
+{
+ int i;
+ s32 delay;
David
Thanks for the review
On 6/22/20 5:40 PM, David Miller wrote:
From: Dan Murphy
Date: Fri, 19 Jun 2020 11:18:09 -0500
@@ -162,6 +162,19 @@ properties:
description:
Specifies a reference to a node representing a SFP cage.
+
+ rx-internal-delay-ps:
Do you really want
On 2020-06-22 17:23, Frank Rowand wrote:
> On 2020-06-22 14:11, Lee Jones wrote:
>> On Mon, 22 Jun 2020, Frank Rowand wrote:
>>
>>> On 2020-06-22 10:10, Lee Jones wrote:
On Mon, 22 Jun 2020, Frank Rowand wrote:
> On 2020-06-22 03:50, Lee Jones wrote:
>> On Thu, 18 Jun 2020, Frank
On Tue, Jun 23, 2020 at 02:23:53AM +0200, Paolo Bonzini wrote:
> On 22/06/20 21:18, Sean Christopherson wrote:
> > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > index fdd05c233308..fa5bd3f987dd 100644
> > --- a/arch/x86/kvm/mmu/mmu.c
> > +++ b/arch/x86/kvm/mmu/mmu.c
> > @@
On 23/06/2020 04:59, Leonardo Bras wrote:
> Hello Alexey, thanks for the feedback!
>
> On Mon, 2020-06-22 at 20:02 +1000, Alexey Kardashevskiy wrote:
>>
>> On 19/06/2020 15:06, Leonardo Bras wrote:
>>> Move the window-removing part of remove_ddw into a new function
>>> (remove_dma_window), so
On 23/06/2020 04:58, Leonardo Bras wrote:
> Hello Alexey, thanks for the feedback!
>
> On Mon, 2020-06-22 at 20:02 +1000, Alexey Kardashevskiy wrote:
>>
>> On 19/06/2020 15:06, Leonardo Bras wrote:
>>> Platforms supporting the DDW option starting with LoPAR level 2.7 implement
>>>
On 23/06/2020 04:58, Leonardo Bras wrote:
> Hello Alexey, thank you for the feedback!
>
> On Mon, 2020-06-22 at 20:02 +1000, Alexey Kardashevskiy wrote:
>>
>> On 19/06/2020 15:06, Leonardo Bras wrote:
>>> From LoPAR level 2.8, "ibm,ddw-extensions" index 3 can make the number of
>>> outputs
On 23/06/2020 04:59, Leonardo Bras wrote:
> Hello Alexey, thanks for the feedback!
>
> On Mon, 2020-06-22 at 20:02 +1000, Alexey Kardashevskiy wrote:
>>
>> On 19/06/2020 15:06, Leonardo Bras wrote:
>>> On LoPAR "DMA Window Manipulation Calls", it's recommended to remove the
>>> default DMA
://github.com/0day-ci/linux/commits/John-Garry/iommu-arm-smmu-v3-Improve-cmdq-lock-efficiency/20200623-013438
base: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next
config: arm64-randconfig-c024-20200622 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
If you fix
Currently there is a single notification chain which is called whenever any
remoteproc shuts down. This leads to all the listeners being notified, and
is not an optimal design as kernel drivers might only be interested in
listening to notifications from a particular remoteproc. Create a global
This set of patches gives kernel client drivers the ability to register
for a particular remoteproc's SSR notifications. Also the notifications
are extended to before/after-powerup/shutdown stages.
It also fixes the bug where clients need to register for notifications
again if the platform driver
The SSR subdevice only adds callback for the unprepare event. Add callbacks
for prepare, start and prepare events. The client driver for a particular
remoteproc might be interested in knowing the status of the remoteproc
while undergoing SSR, not just when the remoteproc has finished shutting
When CONFIG_PM and CONFIG_PM_SLEEP are unset, the following warnings
occur:
drivers/mailbox/imx-mailbox.c:638:12: warning: 'imx_mu_runtime_resume'
defined but not used [-Wunused-function]
638 | static int imx_mu_runtime_resume(struct device *dev)
|^
On 6/22/20 7:45 PM, Nitesh Narayan Lal wrote:
>
> Testing
> ===
> * Patch 1:
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/xfrm/xfrm_device.c
between commit:
94579ac3f6d0 ("xfrm: Fix double ESP trailer insertion in IPsec crypto
offload.")
from the net tree and commit:
272c2330adc9 ("xfrm: bail early on slave pass over skb")
from
On Tue, Jun 23, 2020 at 03:56:53AM +0300, Jarkko Sakkinen wrote:
> On Fri, Jun 19, 2020 at 11:14:20AM -0400, Stefan Berger wrote:
> > On 4/2/20 3:21 PM, Jarkko Sakkinen wrote:
> > > On Wed, Apr 01, 2020 at 11:05:36AM +0200, Rafael J. Wysocki wrote:
> > > > On Wed, Apr 1, 2020 at 10:37 AM Jarkko
On Fri, Jun 19, 2020 at 05:55:19PM +0200, Rafael J. Wysocki wrote:
> On Fri, Jun 19, 2020 at 5:14 PM Stefan Berger wrote:
> >
> > On 4/2/20 3:21 PM, Jarkko Sakkinen wrote:
> > > On Wed, Apr 01, 2020 at 11:05:36AM +0200, Rafael J. Wysocki wrote:
> > >> On Wed, Apr 1, 2020 at 10:37 AM Jarkko
On 2020-06-22 16:38, Ralph Campbell wrote:
The functions nvkm_vmm_ctor() and nvkm_mmu_ptp_get() are not called outside
of the file defining them so make them static.
Signed-off-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c | 2 +-
On Mon, Jun 22, 2020 at 05:47:19PM -0700, Shakeel Butt wrote:
> On Mon, Jun 22, 2020 at 5:22 PM wrote:
> >
> > From: "Paul E. McKenney"
> >
> > A large process running on a heavily loaded system can encounter the
> > following RCU CPU stall warning:
> >
> > rcu: INFO: rcu_sched self-detected
On Fri, Jun 19, 2020 at 11:14:20AM -0400, Stefan Berger wrote:
> On 4/2/20 3:21 PM, Jarkko Sakkinen wrote:
> > On Wed, Apr 01, 2020 at 11:05:36AM +0200, Rafael J. Wysocki wrote:
> > > On Wed, Apr 1, 2020 at 10:37 AM Jarkko Sakkinen
> > > wrote:
> > > > On Tue, Mar 31, 2020 at 05:49:49PM -0400,
On 23/06/20 02:51, Sean Christopherson wrote:
> Remove support for context switching between the guest's and host's
> desired UMWAIT_CONTROL. Propagating the guest's value to hardware isn't
> required for correct functionality, e.g. KVM intercepts reads and writes
> to the MSR, and the latency
On Mon, Jun 22, 2020 at 08:05:10PM -0400, Arvind Sankar wrote:
> But I still don't see anything _stopping_ the compiler from optimizing
> this better in the future. The "=m" is not a barrier: it just informs
> the compiler that the asm produces an output value in *ptr (and no other
> outputs). If
On 6/22/2020 5:32 PM, Tyler Hicks wrote:
> Ask the LSM to free its audit rule rather than directly calling kfree().
> Both AppArmor and SELinux do additional work in their audit_rule_free()
> hooks. Fix memory leaks by allowing the LSMs to perform necessary work.
>
> Fixes: b16942455193 ("ima: use
Hi Matthias,
On Mon, 2020-06-22 at 19:08 +0200, Matthias Brugger wrote:
>
> On 22/06/2020 18:12, Dennis-YC Hsieh wrote:
> > Hi Matthias,
> >
> > On Mon, 2020-06-22 at 17:54 +0200, Matthias Brugger wrote:
> >>
> >> On 22/06/2020 17:36, Dennis-YC Hsieh wrote:
> >>> Hi Matthias,
> >>>
> >>>
From: "Joel Fernandes (Google)"
This commit cites a pertinent RCU-related litmus test.
Co-developed-by: Joel Fernandes (Google)
Co-developed-by: Akira Yokosawa
[Alan: grammar nit]
[ paulmck: Update commit log and title per Akira feedback. ]
Suggested-by: Alan Stern
Signed-off-by: Joel
From: Boqun Feng
We already use a litmus test in atomic_t.txt to describe the behavior of
an atomic_set() with the an atomic RMW, so add it into atomic-tests
directory to make it easily accessible for anyone who cares about the
semantics of our atomic APIs.
Besides currently the litmus test
From: "Joel Fernandes (Google)"
This commit adds Joel Fernandes as official LKMM reviewer.
Acked-by: Boqun Feng
Acked-by: Andrea Parri
Signed-off-by: Joel Fernandes (Google)
[ paulmck: Apply Joe Perches alphabetization feedback. ]
Signed-off-by: Paul E. McKenney
---
MAINTAINERS | 2 ++
1
Am 21.06.20 um 01:32 schrieb Andreas Färber:
diff --git a/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
new file mode 100644
index ..8c5b6fc7b8eb
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
[...]
+ {
+ uart0: serial0@800
From: "Paul E. McKenney"
This commit updates the list of LKMM-related publications in
Documentation/references.txt.
Signed-off-by: Paul E. McKenney
Acked-by: Andrea Parri
---
tools/memory-model/Documentation/references.txt | 21 +++--
1 file changed, 19 insertions(+), 2
Clang warns:
drivers/infiniband/hw/hfi1/qp.c:198:9: warning: implicit conversion from
enumeration type 'enum opa_mtu' to different enumeration type 'enum
ib_mtu' [-Wenum-conversion]
mtu = OPA_MTU_8192;
~ ^~~~
1 warning generated.
enum opa_mtu extends
On 23/06/20 01:47, Andy Lutomirski wrote:
> I believe that Xen does this. Linux does not.) For a guest to
> actually be functional in this case, the guest needs to make sure
> that it is not setting bits that are not, in fact, reserved on the
> CPU. This means the guest needs to check
From: Boqun Feng
We already use a litmus test in atomic_t.txt to describe atomic RMW +
smp_mb__after_atomic() is stronger than acquire (both the read and the
write parts are ordered). So make it a litmus test in atomic-tests
directory, so that people can access the litmus easily.
Additionally,
From: Boqun Feng
According to Luc, atomic_add_unless() is directly provided by herd7,
therefore it can be used in litmus tests. So change the limitation
section in README to unlimit the use of atomic_add_unless().
Cc: Luc Maranget
Acked-by: Andrea Parri
Reviewed-by: Joel Fernandes (Google)
From: "Joel Fernandes (Google)"
This adds an example for the important RCU grace period guarantee, which
shows an RCU reader can never span a grace period.
Acked-by: Andrea Parri
Signed-off-by: Joel Fernandes (Google)
Signed-off-by: Paul E. McKenney
---
From: Akira Yokosawa
Where Documentation/litmus-tests/README lists RCU litmus tests,
Documentation/litmus-tests/atomic/README lists atomic litmus tests.
For symmetry, merge the latter into former, with some context
adjustment in the introduction.
Acked-by: Andrea Parri
Acked-by: Joel Fernandes
From: "Joel Fernandes (Google)"
This adds an example for the important RCU grace period guarantee, which
shows an RCU reader can never span a grace period.
Acked-by: Andrea Parri
Signed-off-by: Joel Fernandes (Google)
Signed-off-by: Paul E. McKenney
---
Documentation/litmus-tests/README
From: Mauro Carvalho Chehab
As we moved those files to core-api, fix references to point
to their newer locations.
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Paul E. McKenney
---
Documentation/memory-barriers.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
On Mon, Jun 22, 2020 at 04:35:05PM +0200, Andreas Gruenbacher wrote:
> On Mon, Jun 22, 2020 at 2:32 AM Dave Chinner wrote:
> > On Fri, Jun 19, 2020 at 08:50:36AM -0700, Matthew Wilcox wrote:
> > >
> > > This patch lifts the IOCB_CACHED idea expressed by Andreas to the VFS.
> > > The advantage of
From: Akira Yokosawa
klitmus7 is independent of the memory model but depends on the
build-target kernel release.
It occasionally lost compatibility due to kernel API changes [1, 2, 3].
It was remedied in a backwards-compatible manner respectively [4, 5, 6].
Reflect this fact in README.
[1]:
From: Akira Yokosawa
The name of litmus test doesn't match the one described below.
Fix the name of litmus test.
Acked-by: Andrea Parri
Acked-by: Joel Fernandes (Google)
Signed-off-by: Akira Yokosawa
Signed-off-by: Paul E. McKenney
---
tools/memory-model/Documentation/recipes.txt | 2 +-
1
From: Marco Elver
The definition of "conflict" should not include the type of access nor
whether the accesses are concurrent or not, which this patch addresses.
The definition of "data race" remains unchanged.
The definition of "conflict" as we know it and is cited by various
papers on memory
From: Boqun Feng
Although we have atomic_t.txt and its friends to describe the semantics
of atomic APIs and lib/atomic64_test.c for build testing and testing in
UP mode, the tests for our atomic APIs in real SMP mode are still
missing. Since now we have the LKMM tool in kernel and litmus tests
On 2020-06-22 16:38, Ralph Campbell wrote:
The patch to add zero page migration to GPU memory inadvertantly included
inadvertently
part of a future change which broke normal page migration to GPU memory
by copying too much data and corrupting GPU memory.
Fix this by only copying one page
Remove support for context switching between the guest's and host's
desired UMWAIT_CONTROL. Propagating the guest's value to hardware isn't
required for correct functionality, e.g. KVM intercepts reads and writes
to the MSR, and the latency effects of the settings controlled by the
MSR are not
Hello!
This series contains updates to the Linux-kernel memory model:
1. tools/memory-model: Add recent references.
2. tools/memory-model: Fix "conflict" definition, courtesy of
Marco Elver.
3. Documentation: LKMM: Add litmus test for RCU GP guarantee where
On Sat, Jun 13, 2020 at 4:36 AM Wolfram Sang wrote:
>
> I2C has quite some patches for you this time. I hope it is the move to
> per-driver-maintainers which is now showing results. We will see.
>
> Big news is two new drivers (Nuvoton NPCM and Qualcomm CCI), larger
> refactoring of the
On Thu, Jun 18, 2020 at 09:56:13AM +0200, Jens Wiklander wrote:
> On Thu, Jun 18, 2020 at 02:37:55AM +0300, Jarkko Sakkinen wrote:
> > On Tue, Jun 16, 2020 at 10:29:07AM +0200, Jens Wiklander wrote:
> > > Hi Maxim and Jarkko,
> > >
> > > On Mon, Jun 15, 2020 at 05:32:40PM +0300, Maxim Uvarov
On Fri, Jun 19, 2020 at 01:30:40PM +1000, David Gibson wrote:
> The tpm2_get_cc_attrs_tbl() call will result in TPM commands being issued,
> which will need the use of the internal command/response buffer. But,
> we're issuing this *before* we've waited to make sure that buffer is
> allocated.
>
On Sun, Jun 21, 2020 at 10:15:39PM -0700, Junxiao Bi wrote:
> On 6/20/20 9:27 AM, Matthew Wilcox wrote:
> > On Fri, Jun 19, 2020 at 05:42:45PM -0500, Eric W. Biederman wrote:
> > > Junxiao Bi writes:
> > > > Still high lock contention. Collect the following hot path.
> > > A different location
On Mon, Jun 22, 2020 at 5:22 PM wrote:
>
> From: "Paul E. McKenney"
>
> A large process running on a heavily loaded system can encounter the
> following RCU CPU stall warning:
>
> rcu: INFO: rcu_sched self-detected stall on CPU
> rcu: \x093-: (20998 ticks this GP)
From: "Paul E. McKenney"
KCSAN is now in mainline, so this commit removes the stubs for the
data_race(), ASSERT_EXCLUSIVE_WRITER(), and ASSERT_EXCLUSIVE_ACCESS()
macros.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/rcutorture.c | 13 -
1 file changed, 13 deletions(-)
diff --git
Problem
---
romfs sequential read performance has regressed very badly since
v3.10. Currently, reading a large file inside a romfs image is
up to 12x slower compared to reading the romfs image directly.
Benchmarks:
- use a romfs image which contains a single 250M file
- calculate the md5sum
The super_block fields s_blocksize and s_blocksize_bits always
reflect the actual configured blocksize for a filesystem.
Use these in all calculations where blocksize is required.
This allows us to easily change the blocksize in a later patch.
Note that I cannot determine what happens if
On Sun, 21 Jun 2020 at 17:34, Maxim Levitsky wrote:
>
> I started to see this warning recently:
>
>
> [ 474.827893] [ cut here ]
> [ 474.827894] WARNING: CPU: 28 PID: 3984 at kernel/rcu/tree.c:453
> rcu_is_cpu_rrupt_from_idle+0x29/0x40
> [ 474.827894] Modules linked
On Tue, 23 Jun 2020 08:47:06 +0900
Masami Hiramatsu wrote:
> On Mon, 22 Jun 2020 09:01:48 -0400
> Steven Rostedt wrote:
>
> > On Mon, 22 Jun 2020 08:27:53 +0800
> > Ming Lei wrote:
> >
> > > Can you kprobe guys improve the implementation for covering this case?
> > > For example, put probe
Tree: next-20200613
Cc: Al Viro
Cc: Deepa Dinamani
Cc: David Howells
Cc: "Darrick J. Wong"
Cc: Janos Farkas
Cc: Jeff Layton
To: linux-kernel@vger.kernel.org
Sven Van Asbroeck (2):
romfs: use s_blocksize(_bits) if CONFIG_BLOCK
romfs: address performance regression since v3.10
From: Qian Cai
cpa_4k_install could be accessed concurrently as noticed by KCSAN,
read to 0xaa59a000 of 8 bytes by interrupt on cpu 7:
cpa_inc_4k_install arch/x86/mm/pat/set_memory.c:131 [inline]
__change_page_attr+0x10cf/0x1840 arch/x86/mm/pat/set_memory.c:1514
From: Marco Elver
Rename 'test.c' to 'selftest.c' to better reflect its purpose (Kconfig
variable and code inside already match this). This is to avoid confusion
with the test suite module in 'kcsan-test.c'.
No functional change.
Signed-off-by: Marco Elver
Signed-off-by: Paul E. McKenney
---
From: Marco Elver
Add a test that KCSAN nor the compiler gets confused about accesses to
jiffies on different architectures.
Signed-off-by: Marco Elver
Signed-off-by: Paul E. McKenney
---
kernel/kcsan/kcsan-test.c | 23 +++
1 file changed, 23 insertions(+)
diff --git
Hello!
This series provides KCSAN updates:
1. Annotate a data race in vm_area_dup(), courtesy of Qian Cai.
2. x86/mm/pat: Mark an intentional data race, courtesy of Qian Cai.
3. Add ASSERT_EXCLUSIVE_ACCESS() to __list_splice_init_rcu().
4. Add test suite, courtesy of Marco
From: Qian Cai
The prev->next pointer can be accessed concurrently as noticed by KCSAN:
write (marked) to 0x9d3370dbbe40 of 8 bytes by task 3294 on cpu 107:
osq_lock+0x25f/0x350
osq_wait_next at kernel/locking/osq_lock.c:79
(inlined by) osq_lock at kernel/locking/osq_lock.c:185
From: "Paul E. McKenney"
After the sync() in __list_splice_init_rcu(), there should be no
readers traversing the old list. This commit therefore enlists the
help of KCSAN to verify this condition via a pair of calls to
ASSERT_EXCLUSIVE_ACCESS().
Signed-off-by: Paul E. McKenney
Cc: Marco Elver
From: Qian Cai
struct vm_area_struct could be accessed concurrently as noticed by
KCSAN,
write to 0x9cf8bba08ad8 of 8 bytes by task 14263 on cpu 35:
vma_interval_tree_insert+0x101/0x150:
rb_insert_augmented_cached at include/linux/rbtree_augmented.h:58
(inlined by)
From: Marco Elver
The functions here should not be forward declared for explicit use
elsewhere in the kernel, as they should only be emitted by the compiler
due to sanitizer instrumentation. Add forward declarations a line above
their definition to shut up warnings in W=1 builds.
Link:
From: Marco Elver
Remove existing special atomic rules from kcsan_is_atomic_special()
because they are no longer needed. Since we rely on the compiler
emitting instrumentation distinguishing volatile accesses, the rules
have become redundant.
Let's keep kcsan_is_atomic_special() around, so that
From: Marco Elver
This adds KCSAN test focusing on behaviour of the integrated runtime.
Tests various race scenarios, and verifies the reports generated to
console. Makes use of KUnit for test organization, and the Torture
framework for test thread control.
Signed-off-by: Marco Elver
Tree: next-20200613
Cc: Al Viro
Cc: Deepa Dinamani
Cc: David Howells
Cc: "Darrick J. Wong"
Cc: Janos Farkas
Cc: Jeff Layton
To: linux-kernel@vger.kernel.org
Sven Van Asbroeck (2):
romfs: use s_blocksize(_bits) if CONFIG_BLOCK
romfs: address performance regression since v3.10
On Mon, Jun 22, 2020 at 10:38:46AM +0200, Roger Pau Monné wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> On Fri, Jun 19, 2020 at 11:43:12PM +,
From: Marco Elver
Instead of __no_kcsan_or_inline, prefer '__no_kcsan inline' in test --
this is in case we decide to remove __no_kcsan_or_inline.
Suggested-by: Peter Zijlstra
Signed-off-by: Marco Elver
Signed-off-by: Paul E. McKenney
---
kernel/kcsan/kcsan-test.c | 4 ++--
1 file changed,
Problem
---
romfs sequential read performance has regressed very badly since
v3.10. Currently, reading a large file inside a romfs image is
up to 12x slower compared to reading the romfs image directly.
Benchmarks:
- use a romfs image which contains a single 250M file
- calculate the md5sum
The super_block fields s_blocksize and s_blocksize_bits always
reflect the actual configured blocksize for a filesystem.
Use these in all calculations where blocksize is required.
This allows us to easily change the blocksize in a later patch.
Note that I cannot determine what happens if
After mm.h was removed from the asm-generic version of cacheflush.h,
s390 allyesconfig shows several warnings of the following nature:
In file included from ./arch/s390/include/generated/asm/cacheflush.h:1,
from drivers/media/platform/omap3isp/isp.c:42:
Currently, cacheflush.h has to be included after mm.h to avoid several
-Wvisibility warnings:
$ clang -Wvisibility -fsyntax-only include/asm-generic/cacheflush.h
include/asm-generic/cacheflush.h:16:42: warning: declaration of 'struct
mm_struct' will not be visible outside of this function
Hi all,
These two patches are the culmination of the small discussion here:
https://lore.kernel.org/lkml/camuhmdvsdutoi5bugf9slqdgadwyl1+qalwskgin1teolgh...@mail.gmail.com/
I have fallen behind on fixing issues so sorry for not sending these
sooner and letting these warnings slip into mainline.
From: "Paul E. McKenney"
On some (probably misconfigured) systems, the torture-test scripting
will cause qemu to complain about missing EFI firmware, often because
qemu is trying to traverse broken symbolic links to find that firmware.
Which is a bit silly given that the default torture-test
From: "Paul E. McKenney"
Several variants of Linux-kernel RCU interact with task-exit processing,
including preemptible RCU, Tasks RCU, and Tasks Trace RCU. This commit
therefore adds testing of this interaction to rcutorture by adding
rcutorture.read_exit_burst and rcutorture.read_exit_delay
From: "Paul E. McKenney"
This commit adds a kvm-check-branches.sh script that takes a list
of commits and commit ranges and runs a short rcutorture test on all
scenarios on each specified commit. A summary is printed at the end, and
the script returns success if all rcutorture runs completed
From: "Paul E. McKenney"
Using --kcsan when the compiler does not support KCSAN results in this:
:CONFIG_KCSAN=y: improperly set
:CONFIG_KCSAN_REPORT_ONCE_IN_MS=10: improperly set
:CONFIG_KCSAN_VERBOSE=y: improperly set
:CONFIG_KCSAN_INTERRUPT_WATCHER=y: improperly set
Clean KCSAN run in
From: "Paul E. McKenney"
The torture-test recheck logic fails to set the configfile variable to
the current scenario, so this commit properly initializes this variable.
This change isn't critical given that all errors for a given scenario
follow that scenario's heading, but it is easier on the
From: "Paul E. McKenney"
The current console parsing assumes that console lines containing "!!!"
are statistics lines from which it can parse the number of rcutorture
too-short grace-period failures. This prints confusing output for
other problems, including memory exhaustion. This commit
From: "Paul E. McKenney"
Currently, the qemu command is constructed twice, once to dump it
to the qemu-cmd file and again to execute it. This is of course an
accident waiting to happen, but is done to ensure that the remainder
of the script has an accurate idea of the running qemu command's
From: Jules Irenge
Coccinelle reports a warning
WARNING: Assignment of 0/1 to bool variable
The root cause is that the variable lastphase is a bool, but is
initialised with integer 0. This commit therefore replaces the 0 with
a false.
Signed-off-by: Jules Irenge
Signed-off-by: Paul E.
From: "Paul E. McKenney"
Currently, the rcu_torture_current variable remains non-NULL until after
all readers have stopped. During this time, rcu_torture_stats_print()
will think that the test is still ongoing, which can result in confusing
dmesg output. This commit therefore NULLs
From: "Paul E. McKenney"
In the dim distant past, qemu commands needed to be run from the
rcutorture directory, but this is no longer the case. This commit
therefore removes the now-useless "cd $KVM" from the kvm-test-1-run.sh
script.
Signed-off-by: Paul E. McKenney
---
201 - 300 of 1749 matches
Mail list logo
