On 31/01/2018 15:18, Jim Mattson wrote:
>> but save_spec_ctrl_on_exit is also set for L2 write. So once L2 writes
>> to it, this condition will be true and then the bitmap will be updated.
> So if L1 or any L2 writes to the MSR, then save_spec_ctrl_on_exit is
> set to true, even if the MSR permissi
On 01/31/2018 09:28 PM, Konrad Rzeszutek Wilk wrote:
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index d46a61b..2e4e8af 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2285,6 +2285,7 @@ static void vmx_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
if (per_cpu(current_vmc
From: Markus Elfring
Date: Wed, 31 Jan 2018 21:36:53 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/iio/gyro/hid-sensor-gyro-3d.c | 4 +---
1 file changed, 1 inse
On 01/31/2018 07:27 AM, Masahiro Yamada wrote:
> 2018-01-31 18:34 GMT+09:00 Ulf Magnusson :
>> This patchset first removes all blank help texts from Kconfig files for all
>> arches, and then makes Kconfig print a warning for blank help texts.
>>
>> All patches can be applied independently, but to a
On Mon, Nov 27, 2017 at 12:42 AM, Wu Hao wrote:
Hi Hao,
Just fix the SPDX, otherwise it looks good.
> This patch adds fpga region platform driver for FPGA Management Engine.
> It register an fpga region with given fpga manager / bridge device.
>
> Signed-off-by: Tim Whisonant
> Signed-off-by:
Andy Lutomirski wrote:
>
>
>> On Jan 31, 2018, at 12:11 PM, Nadav Amit wrote:
>>
>> The TLB invalidation info is allocated on the stack, which might cause
>> it to be unaligned. Since this information may be transferred to
>> different cores for TLB shootdown, this might result in an addition
On 01/31/2018 12:48 PM, Nadav Amit wrote:
>>> On Jan 31, 2018, at 12:11 PM, Nadav Amit wrote:
>>>
>>> The TLB invalidation info is allocated on the stack, which might cause
>>> it to be unaligned. Since this information may be transferred to
>>> different cores for TLB shootdown, this might result
From: Goffredo Baroncelli
The function inode_cmp_iversion{+raw} is counter-intuitive, because it
returns true when the counters are different and false when these are equal.
Rename it to inode_eq_iversion{+raw}, which will returns true when
the counters are equal and false otherwise.
Signed-off
Dave Hansen wrote:
> On 01/31/2018 12:48 PM, Nadav Amit wrote:
On Jan 31, 2018, at 12:11 PM, Nadav Amit wrote:
The TLB invalidation info is allocated on the stack, which might cause
it to be unaligned. Since this information may be transferred to
different cores for TLB
You seem to be making the assumption that there is one L2. What if
there are 100 L2s, and only one has write-access to IA32_SPEC_CTRL? Or
what if there once was such an L2, but it's been gone for months? The
current mechanism penalizes *all* L2s if any L2, ever, has
write-access to IA32_SPEC_CTRL.
+jasow...@redhat.com
On Mon, Jan 22, 2018 at 11:58:02AM -0800, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> 8dd903d2cf7b6dfe98be7c19f891882583c7266e (Fri Jan 19 23:20:00 2018 +)
> Merge tag 'scsi-fixes' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/
On Wed, Jan 31, 2018 at 09:55:13PM +, Vadim Pasternak wrote:
> Add hotplug platform driver un-registration in case regmap cache
> synchronization failed. In such case hotplug platform driver registration
> should be rolled back.
Queued up, thanks Vadim.
--
Darren Hart
VMware Open Source Tech
On 31/01/2018 15:54, Jim Mattson wrote:
> You seem to be making the assumption that there is one L2. What if
> there are 100 L2s, and only one has write-access to IA32_SPEC_CTRL? Or
> what if there once was such an L2, but it's been gone for months? The
> current mechanism penalizes *all* L2s if an
The TLB invalidation info is allocated on the stack, which might cause
it to be unaligned. Since this information may be transferred to
different cores for TLB shootdown, this might result in an additional
cache-line bouncing between the cores.
We do not use __cacheline_aligned() since it also def
On 01/31/2018 12:11 PM, Nadav Amit wrote:
> The TLB invalidation info is allocated on the stack, which might cause
> it to be unaligned. Since this information may be transferred to
> different cores for TLB shootdown, this might result in an additional
> cache-line bouncing between the cores.
>
>
On Wed, Jan 31, 2018 at 12:48 PM, Nadav Amit wrote:
> Andy Lutomirski wrote:
>
>>
>>
>>> On Jan 31, 2018, at 12:11 PM, Nadav Amit wrote:
>>>
>>> The TLB invalidation info is allocated on the stack, which might cause
>>> it to be unaligned. Since this information may be transferred to
>>> differe
> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Wednesday, January 31, 2018 11:00 PM
> To: Vadim Pasternak
> Cc: andy.shevche...@gmail.com; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; j...@resnulli.us
>
Changelog:
v1 - v2
Added struct page poisoning checking in order to verify that
struct pages are never accessed until initialized during memory
hotplug
Pavel Tatashin (2):
mm: uninitialized struct page poisoning sanity checking
mm, memory_hotplug: optimize memor
On Wed, Jan 31, 2018 at 1:00 PM, Nadav Amit wrote:
> The TLB invalidation info is allocated on the stack, which might cause
> it to be unaligned. Since this information may be transferred to
> different cores for TLB shootdown, this might result in an additional
> cache-line bouncing between the c
This patch was inspired by the discussion of this problem:
http://lkml.kernel.org/r/20180130083006.gb1...@in.ibm.com
Currently, during memory hotplugging we traverse struct pages several
times:
1. memset(0) in sparse_add_one_section()
2. loop in __add_section() to set do: set_page_node(page, nid)
On Wed, Jan 31, 2018 at 1:00 PM, Paolo Bonzini wrote:
> Yes, but how would moving the field into struct loaded_vmcs do anything?
> Only vmon/vmoff would change anything in vmx->nested.vmcs02.
My suggestion was that nested_vmx_merge_msr_bitmap should set the
vmcs02 version of save_spec_ctrl_on_e
During boot we poison struct page memory in order to ensure that no one is
accessing this memory until the struct pages are initialized in
__init_single_page().
This patch adds more scrutiny to this checking, by making sure that flags
do not equal to poison pattern when the are accessed. The patte
On Sat, Dec 09, 2017 at 02:40:00AM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 328b4ed93b69a6f2083d52f31a240a09e5de386a
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console ou
Dave Hansen wrote:
> On 01/31/2018 12:11 PM, Nadav Amit wrote:
>> The TLB invalidation info is allocated on the stack, which might cause
>> it to be unaligned. Since this information may be transferred to
>> different cores for TLB shootdown, this might result in an additional
>> cache-line bounc
Group together the calls to alloc_vmcs and loaded_vmcs_init. Soon we'll also
allocate an MSR bitmap there.
Cc: sta...@vger.kernel.org # prereq for Spectre mitigation
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/vmx.c | 36 ++--
1 file changed, 22 insertion
David and others,
the following changes since commit ba804bb4b72e57374b5f567b783aa0298fba0ce6:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-01-26
09:03:16 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/virt/kvm/kvm.git msr-bitmaps
for yo
Place the MSR bitmap in struct loaded_vmcs, and update it in place
every time the x2apic or APICv state can change. This is rare and
the loop can handle 64 MSRs per iteration, in a similar fashion as
nested_vmx_prepare_msr_bitmap.
This prepares for choosing, on a per-VM basis, whether to intercep
From: Jim Mattson
The potential performance advantages of a vmcs02 pool have never been
realized. To simplify the code, eliminate the pool. Instead, a single
vmcs02 is allocated per VCPU when the VCPU enters VMX operation.
Cc: sta...@vger.kernel.org # prereq for Spectre mitigation
Signed-o
From: Markus Elfring
Date: Wed, 31 Jan 2018 21:57:50 +0100
Omit an extra message for a memory allocation failure in these functions.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/iio/adc/at91_adc.c | 1 -
drivers/iio/adc/max1027.c | 4 +--
> From: Long Li
> Sent: Wednesday, January 31, 2018 12:23 PM
> To: Michael Kelley (EOSG) ; KY Srinivasan
> ; Stephen Hemminger ;
> martin.peter...@oracle.com; de...@linuxdriverproject.org;
> linux-kernel@vger.kernel.org;
> linux-s...@vger.kernel.org; James E . J . Bottomley
> Subject: RE: [PATCH
On Wed, Jan 31, 2018 at 1:09 PM, Nadav Amit wrote:
> Dave Hansen wrote:
>
>> On 01/31/2018 12:11 PM, Nadav Amit wrote:
>>> The TLB invalidation info is allocated on the stack, which might cause
>>> it to be unaligned. Since this information may be transferred to
>>> different cores for TLB shootd
Andy Lutomirski wrote:
> On Wed, Jan 31, 2018 at 1:09 PM, Nadav Amit wrote:
>> Dave Hansen wrote:
>>
>>> On 01/31/2018 12:11 PM, Nadav Amit wrote:
The TLB invalidation info is allocated on the stack, which might cause
it to be unaligned. Since this information may be transferred to
>
The following changes since commit f1ee616214cb22410e939d963bbb2349c2570f02:
VFS: don't keep disconnected dentries on d_anon (2017-12-25 20:22:07 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.dcache
for you to fetch changes u
On Wed, Jan 31, 2018 at 12:21 PM, David Woodhouse wrote:
> Reading and writing this MSR is expensive. And if it's yielded to the
> guest in the MSR bitmap, that means we have to save its value on vmexit
> and set it back to zero.
Agreed. But my point is that if it's not yielded to the guest in t
I accidentally removed ML/cc before, re-adding.
On 31.01.2018 10:57, Boris Brezillon wrote:
> On Wed, 31 Jan 2018 10:19:05 +0100
> ste...@agner.ch wrote:
>
>> On 30.01.2018 14:23, Boris Brezillon wrote:
>> > Hi Stefan,
>> >
>> > On Mon, 29 Jan 2018 15:44:40 +0100
>> > Stefan Agner wrote:
>> >
>>
The TLB invalidation info is allocated on the stack, which might cause
it to be unaligned. Since this information may be transferred to
different cores for TLB shootdown, this may cause an additional cache
line to become shared. While the overhead is likely to be small, the
fix is simple.
We do no
On Wed, 2018-01-31 at 13:05 -0800, Jim Mattson wrote:
> On Wed, Jan 31, 2018 at 1:00 PM, Paolo Bonzini wrote:
>
> > Yes, but how would moving the field into struct loaded_vmcs do anything?
> > Only vmon/vmoff would change anything in vmx->nested.vmcs02.
>
> My suggestion was that nested_vmx_mer
On Sun, Jan 28, 2018 at 3:41 PM, James Morris wrote:
>
> Note that individual trees may also be pulled via:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
> next-integrity
> next-smack
> next-tpm
So I did that, because it makes it easier and m
> Subject: RE: [PATCH 1/1] scsi: storvsc: Spread interrupts when picking a
> channel for I/O requests
>
> > From: Long Li
> > Sent: Wednesday, January 31, 2018 12:23 PM
> > To: Michael Kelley (EOSG) ; KY
> > Srinivasan ; Stephen Hemminger
> > ; martin.peter...@oracle.com;
> > de...@linuxdriverproj
It's linux/uaccess.h, damnit... Oh, well - eventually they'll stop
cropping up...
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kerne
From: Markus Elfring
Date: Wed, 31 Jan 2018 22:20:56 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/iio/accel/hid-sensor-accel-3d.c | 6 ++
1 file changed, 2
Get rid of "is it an iovec or an entire array?" flags in there -
just use iov_iter. Simplifies the living hell out of that code...
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repositor
This file had several naming inconsistencies for eSDHC:
- the instances were named sometimes SDn, sometimes SDHCn, whereas they
are named ESDHCn in the reference manual, e.g.:
MX25_PAD_SD1_CMD__SD1_CMD
MX25_PAD_D15__SDHC1_DAT7
- the data ports were named sometimes DATAn, sometimes DA
The eSDHC does not work properly if the SION bit is not set for the
bidirectional CMD signal, whatever the eSDHC instance and the selected
pad. Therefore, setting SION is mandatory for all eSDHC CMD ports. Do
this for MX25_PAD_*__ESDHCn_CMD in imx25-pinfunc.h in order to enforce
this behavior for a
On Wed, Jan 31, 2018 at 08:26:14PM +0200, Andy Shevchenko wrote:
> Remove code duplication by converting driver to pure ACPI one.
+Rafael
I don't see any reason *not* to do this, it seems the acpi driver model provides
some of the boilerplate stuff we were doing manually before as a platform
devi
On Wed, 31 Jan 2018, Linus Torvalds wrote:
> On Sun, Jan 28, 2018 at 3:41 PM, James Morris wrote:
> >
> > Note that individual trees may also be pulled via:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
> > next-integrity
> > next-smack
> >
On 31/01/2018 16:05, Jim Mattson wrote:
> On Wed, Jan 31, 2018 at 1:00 PM, Paolo Bonzini wrote:
>
>> Yes, but how would moving the field into struct loaded_vmcs do anything?
>> Only vmon/vmoff would change anything in vmx->nested.vmcs02.
>
> My suggestion was that nested_vmx_merge_msr_bitmap sh
On 01/31/18 12:05, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> Create a cache of the nodes that contain a phandle property. Use this
> cache to find the node for a given phandle value instead of scanning
> the devicetree to find the node. If the phandle value is not found
> in the ca
Hi Joe,
Can I please bother you with a maintainer question. I know everyone is
super busy right now, I'm asking for a smidgen of your time instead of
doing it wrong and taking up some of Linus' time since it's merge window
and all that.
I have the checkpatch set queued ready to do a GIT PULL to
Hi Philipp,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.15 next-20180126]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/com
On Wed, Jan 31, 2018 at 1:42 PM, Paolo Bonzini wrote:
> Can we just say it sucks to be L2 too? :) Because in the end as long as
> no one ever writes to spec_ctrl, everybody is happy.
Unfortunately, quite a few OS vendors shipped IBRS-based mitigations
earlier this month. (Has Redhat stopped wri
On Thu, Jan 25, 2018 at 12:03:02PM -0500, David Miller wrote:
> From: Roman Gushchin
> Date: Thu, 25 Jan 2018 00:19:11 +
>
> > @@ -476,6 +477,10 @@ struct sock *inet_csk_accept(struct sock *sk, int
> > flags, int *err, bool kern)
> > spin_unlock_bh(&queue->fastopenq.lock);
> >
On Fri, Jan 26, 2018 at 01:33:04PM +0300, Evgenii Shatokhin wrote:
> >+ The callbacks from the replaced patches are not called. It would be
> > pretty hard to define a reasonable semantic and implement it.
>
> At least, it surely simplifies error handling, if these callbacks are not
> cal
On Wed, Jan 31, 2018 at 09:43:09PM +0100, Goffredo Baroncelli wrote:
> The function inode_cmp_iversion{+raw} is counter-intuitive, because it
> returns true when the counters are different and false when these are equal.
>
> Rename it to inode_eq_iversion{+raw}, which will returns true when
> the
On 01/31, Chao Yu wrote:
> On 2018/1/31 11:49, Jaegeuk Kim wrote:
> > On 01/31, Chao Yu wrote:
> >> On 2018/1/31 10:36, Jaegeuk Kim wrote:
> >>> On 01/31, Chao Yu wrote:
> On 2018/1/31 9:35, Jaegeuk Kim wrote:
> > On 01/29, Chao Yu wrote:
> >> Add missing sanity check for quota sysfile
On 31/01/2018 16:53, Jim Mattson wrote:
> On Wed, Jan 31, 2018 at 1:42 PM, Paolo Bonzini wrote:
>
>> Can we just say it sucks to be L2 too? :) Because in the end as long as
>> no one ever writes to spec_ctrl, everybody is happy.
>
> Unfortunately, quite a few OS vendors shipped IBRS-based mitig
On Wed, 2018-01-31 at 13:53 -0800, Jim Mattson wrote:
> On Wed, Jan 31, 2018 at 1:42 PM, Paolo Bonzini wrote:
>
> > Can we just say it sucks to be L2 too? :) Because in the end as long as
> > no one ever writes to spec_ctrl, everybody is happy.
>
> Unfortunately, quite a few OS vendors shippe
On Wed, 2018-01-31 at 13:18 -0800, Jim Mattson wrote:
> On Wed, Jan 31, 2018 at 12:21 PM, David Woodhouse wrote:
>
> >
> > Reading and writing this MSR is expensive. And if it's yielded to the
> > guest in the MSR bitmap, that means we have to save its value on vmexit
> > and set it back to ze
On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:
> On 01/30/2018 03:46 PM, Mimi Zohar wrote:
> > Commit 16203a7a9422 ("initmpfs: make rootfs use tmpfs when CONFIG_TMPFS
> > enabled") introduced using tmpfs as the rootfs filesystem. The use of
> > tmpfs is limited to systems that do not specif
On Wed, Jan 31, 2018 at 1:59 PM, David Woodhouse wrote:
> I'm actually working on IBRS_ALL at the moment.
>
> I was tempted to *not* let the guests turn it off. Expose SPEC_CTRL but
> just make it a no-op.
Maybe we could convince Intel to add a LOCK bit to IA32_SPEC_CTRL like
the one in IA32_FEAT
On Fri, Jan 26, 2018 at 11:23:26AM +0100, Petr Mladek wrote:
> So, we are talking about a lot of rather non-trivial code.
> IMHO, it might be easier to run just the callbacks from
> the new patch. In reality, the author should always know
> what it might be replacing and what needs to be done.
>
>
On 01/30/2018 09:03 AM, Petr Mladek wrote:
> On Fri 2018-01-26 14:29:36, Evgenii Shatokhin wrote:
>>
>> In my experience, it was quite convenient sometimes to just "replace all
>> binary patches the user currently has loaded with this single one". No
>> matter what these original binary patches did
On Wed, 2018-01-31 at 14:06 -0800, Jim Mattson wrote:
> On Wed, Jan 31, 2018 at 1:59 PM, David Woodhouse wrote:
> > I'm actually working on IBRS_ALL at the moment.
> >
> > I was tempted to *not* let the guests turn it off. Expose SPEC_CTRL but
> > just make it a no-op.
>
> Maybe we could convin
On 01/31, Chao Yu wrote:
> On 2018/1/31 10:02, Jaegeuk Kim wrote:
> > What if we want to add more entries in addition to node_checksum? Do we have
> > to add a new feature flag at every time? How about adding a layout value
> > instead
>
> Hmm.. for previous implementation, IMO, we'd better add a
On Wed, Jan 31, 2018 at 2:10 PM, David Woodhouse wrote:
>
> Given that IBRS_ALL is supposed to be a sanely-performing option, I'd
> rather convince Intel to just make it unconditional. If they've added
> the appropriate tagging to the BTB, why even *have* this deliberately
> insecure mode when IBR
On Wed, Jan 31, 2018 at 7:35 PM, Benoît Thébaudeau
wrote:
> This file had several naming inconsistencies for eSDHC:
> - the instances were named sometimes SDn, sometimes SDHCn, whereas they
>are named ESDHCn in the reference manual, e.g.:
> MX25_PAD_SD1_CMD__SD1_CMD
> MX25_PAD_D15__
On 01/31/2018 10:55 PM, Matthew Wilcox wrote:
> On Wed, Jan 31, 2018 at 09:43:09PM +0100, Goffredo Baroncelli wrote:
>> The function inode_cmp_iversion{+raw} is counter-intuitive, because it
>> returns true when the counters are different and false when these are equal.
>>
>> Rename it to inode_eq_
Hi Jaegeuk,
On Tue, 30 Jan 2018 16:25:35 -0800 Jaegeuk Kim wrote:
>
> On 01/31, Stephen Rothwell wrote:
> >
> > On Tue, 30 Jan 2018 14:32:20 -0800 Jaegeuk Kim wrote:
> > >
> > > Could you please consider the below pull request?
> > >
> > > Thanks,
> > >
> > > The following changes since com
Hi Hyunchul,
I've added the policy in the Doc as wel.
Thanks,
On 01/31, Hyunchul Lee wrote:
> From: Hyunchul Lee
>
> Signed-off-by: Hyunchul Lee
> ---
> Documentation/filesystems/f2fs.txt | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/filesystems/f2fs.txt
> b/
On Wed, Jan 17, 2018 at 07:55:27PM +, James Hogan wrote:
> On Wed, Jan 17, 2018 at 07:56:38PM +0100, Corentin Labbe wrote:
> > MIPS_GENERIC select some options with condition on BIG_ENDIAN which do
> > not exists.
> > Replace BIG_ENDIAN by CPU_BIG_ENDIAN which is the correct kconfig name.
> > N
From: Eric Dumazet
Some devices (like mlx4) try hard to allocate memory on selected
NUMA node, but it turns out intel_alloc_coherent() is not NUMA
aware yet.
Note that dma_generic_alloc_coherent() in arch/x86/kernel/pci-dma.c
gets this right.
Signed-off-by: Eric Dumazet
Cc: Benjamin Serebrin
On Thu, 2018-02-01 at 08:46 +1100, Tobin C. Harding wrote:
> Hi Joe,
>
> Can I please bother you with a maintainer question. I know everyone is
> super busy right now, I'm asking for a smidgen of your time instead of
> doing it wrong and taking up some of Linus' time since it's merge window
> and
Hi Philipp,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on robh/for-next]
[also build test WARNING on v4.15 next-20180126]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/l
On 01/31/2018 09:18 PM, Jim Mattson wrote:
On Wed, Jan 31, 2018 at 12:01 PM, KarimAllah Ahmed wrote:
but save_spec_ctrl_on_exit is also set for L2 write. So once L2 writes
to it, this condition will be true and then the bitmap will be updated.
So if L1 or any L2 writes to the MSR, then save_
On Wed, Jan 31, 2018 at 08:31:38AM +0100, Marcus Folkesson wrote:
> Hi Andy,
>
> On Wed, Jan 31, 2018 at 03:07:26PM +0900, Andi Shyti wrote:
> > Hi Dmitry,
> >
> > > > -/*
> > > > - * Copyright (C) 2012 Samsung Electronics Co.Ltd
> > > > - * Author: Joonyoung Shim
> > > > - *
> > > > - * This pr
> On Jan 31, 2018, at 2:06 PM, Jim Mattson wrote:
>
>> On Wed, Jan 31, 2018 at 1:59 PM, David Woodhouse wrote:
>> I'm actually working on IBRS_ALL at the moment.
>>
>> I was tempted to *not* let the guests turn it off. Expose SPEC_CTRL but
>> just make it a no-op.
>
> Maybe we could convince
Hi Karim
On Wed, Jan 31, 2018 at 08:37:46PM +0100, KarimAllah Ahmed wrote:
> [ Based on a patch from Ashok Raj ]
>
> Add direct access to MSR_IA32_SPEC_CTRL for guests. This is needed for
> guests that will only mitigate Spectre V2 through IBRS+IBPB and will not
> be using a retpoline+IBPB based
On Tue, 9 Jan 2018 02:10:50 -0800 Yu Zhao wrote:
> On Tue, Jan 09, 2018 at 09:46:22AM +0100, Michal Hocko wrote:
> > On Mon 08-01-18 14:56:32, Yu Zhao wrote:
> > > We don't want to expose page before it's properly setup. During
> > > page setup, we may call page_add_new_anon_rmap() which uses non
Now that release_pages is scaling better with concurrent removals from
the LRU, the performance results (included below) showed increased
contention on lru_lock in the add-to-LRU path.
To alleviate some of this contention, do more work outside the LRU lock.
Prepare a local list of pages to be spli
A common case in release_pages is for the 'pages' list to be in roughly
the same order as they are in their LRU. With LRU batch locking, when a
sentinel page is removed, an adjacent non-sentinel page must be promoted
to a sentinel page to follow the locking scheme. So we can get behavior
where ne
For the purposes of this prototype, copy the body of pagevec_lru_move_fn
into __pagevec_lru_add so that it can be modified to use the batch
locking API while leaving all other callers of pagevec_lru_move_fn
unaffected.
Signed-off-by: Daniel Jordan
---
mm/swap.c | 24 +++-
1 f
Introduce LRU batch locking in release_pages. This is the code path
where I see lru_lock contention most often, so this is the one I used in
this prototype.
Signed-off-by: Daniel Jordan
---
mm/swap.c | 45 +
1 file changed, 17 insertions(+), 28 deleti
Use the heavy locking API for now to allow us to focus on the path we're
measuring to prove the concept--the release_pages path. In that path,
LRU batch locking will be used, but everywhere else will be heavy.
For now, exclude compaction since this would be a nontrivial
refactoring. We can deal
These will use the lru_batch_locks in a later series.
Signed-off-by: Daniel Jordan
---
mm/swap.c | 18 --
mm/vmscan.c | 4 ++--
2 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/mm/swap.c b/mm/swap.c
index c4ca7e1c7c03..cf6a59f2cad6 100644
--- a/mm/swap.c
+++ b/
Add the LRU batch locking API's themselves. This adds the final piece
of infrastructure necessary for locking batches on an LRU list.
The API's lock a specific page on the LRU list, taking only the
appropriate LRU batch lock for a non-sentinel page and taking the
node's/memcg's lru_lock in additi
Add information about the first and last LRU batches in struct lruvec.
lruvec's list_head is replaced with a pseudo struct page to avoid
special-casing LRU batch handling at the front or back of the LRU. This
pseudo page has its own lru_batch and lru_sentinel fields so that the
same code that dea
On Wed, 31 Jan 2018 12:16:49 +0100
Mohammed Gamal wrote:
> On Tue, 2018-01-30 at 11:29 -0800, Stephen Hemminger wrote:
> > On Tue, 23 Jan 2018 10:34:04 +0100
> > Mohammed Gamal wrote:
> >
> > > Split each of the functions into two for each of send/recv buffers
> > >
> > > Signed-off-by: Moha
Change the add/delete/move LRU API's in mm_inline.h to account for LRU
batching. Now when a page is added to the front of the LRU, it's
assigned a batch number that's used to decide which spinlock in the
lru_batch_lock array to take when removing that page from the LRU. Each
newly-added page is a
This is a temporary hack to avoid the non-trivial refactoring of the
compaction code that takes lru_lock in this prototype. This refactoring
can be done later.
Signed-off-by: Daniel Jordan
---
mm/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/mm/Kconfig b/mm/Kconfig
index 03ff7703d3
From: Aaron Lu
---
include/linux/mmzone.h | 2 ++
kernel/sysctl.c| 9 +
mm/page_alloc.c| 40 +++-
3 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 67f2e3c38939..c0552
lru_lock, a per-node* spinlock that protects an LRU list, is one of the
hottest locks in the kernel. On some workloads on large machines, it
shows up at the top of lock_stat.
One way to improve lru_lock scalability is to introduce an array of locks,
with each lock protecting certain batches of LR
Add heavy locking API's for the few cases that a thread needs exclusive
access to an LRU list. This locks lru_lock as well as every lock in
lru_batch_locks.
This API will be used often at first, in scaffolding code, to ease the
transition from using lru_lock to the batch locking scheme. Later it
This patch simply adds the array of locks and struct page fields.
Ignore for now where the struct page fields are: we need to find a place
to put them that doesn't enlarge the struct.
Signed-off-by: Daniel Jordan
---
include/linux/mm_types.h | 5 +
include/linux/mmzone.h | 7 +++
mm/pa
On Fri, Dec 22, 2017 at 2:45 AM, Wu Hao wrote:
>> > >
>> > > I see that the port code is included as part of the enumeration code.
>> > > This is not very future-proofed, if a different port needs to be
>> > > supported.
>> > >
>> > > The port is a FPGA fabric based bridge with expanded functiona
On Wed, Jan 31, 2018 at 02:48:56PM -0800, Joe Perches wrote:
> On Thu, 2018-02-01 at 08:46 +1100, Tobin C. Harding wrote:
> > Hi Joe,
> >
> > Can I please bother you with a maintainer question. I know everyone is
> > super busy right now, I'm asking for a smidgen of your time instead of
> > doing
Hi all,
On Thu, 25 Jan 2018 14:31:55 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the vfs tree got a conflict in:
>
> fs/dcache.c
>
> between commit:
>
> f9c34674bc60 ("vfs: factor out helpers d_instantiate_anon() and
> d_alloc_anon()")
>
> from the overlayfs tree and c
On 01/30/2018 07:59 PM, Josh Poimboeuf wrote:
> On Tue, Jan 30, 2018 at 01:23:17PM -0800, Tim Chen wrote:
>> On 01/30/2018 09:48 AM, Josh Poimboeuf wrote:
>>> On Mon, Jan 29, 2018 at 10:04:47PM +, David Woodhouse wrote:
From: Tim Chen
Flush indirect branches when switching into
On 01/31/2018 04:07 PM, Mimi Zohar wrote:
> On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I
> configured in tmpfs and am using rootfs but I want that
rootfs
>> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does
>> it?)
>
> I must be missing something.
26b259ab4fe8 ("Merge remote-tracking branch 'lorenzo/pci/dwc' into next")
I have used the pci tree from next-20180131 for today.
--
Cheers,
Stephen Rothwell
On Wed, Jan 31, 2018 at 11:08:22AM +0100, Peter Zijlstra wrote:
> On Wed, Jan 31, 2018 at 10:00:06AM +0100, Ingo Molnar wrote:
> > - Similary, some of the high level descriptions in tools/memory-model/README
> > should probably propagated into the source code files as well: for example
> > both
501 - 600 of 704 matches
Mail list logo
