Hi,
On 14/09/2017 02:31, Sergey Senozhatsky wrote:
> Hi,
>
> On (09/13/17 18:56), Laurent Dufour wrote:
>> Hi Sergey,
>>
>> On 13/09/2017 13:53, Sergey Senozhatsky wrote:
>>> Hi,
>>>
>>> On (09/08/17 20:06), Laurent Dufour wrote:
> [..]
>>> ok, so what I got on my box is:
>>>
>>> vm_munmap() ->
On Thu, 2017-09-14 at 14:38 +1000, Balbir Singh wrote:
> On Fri, 8 Sep 2017 15:44:50 -0700
> Ram Pai wrote:
>
> > powerpc needs an additional vma bit to support 32 keys.
> > Till the additional vma bit lands in include/linux/mm.h
> > we have to define it in powerpc specific header file.
> > Th
Hi,
On (09/14/17 09:55), Laurent Dufour wrote:
[..]
> > so if there are two CPUs, one doing write_seqcount() and the other one
> > doing read_seqcount() then what can happen is something like this
> >
> > CPU0CPU1
> >
> >
On Fri, 2017-09-08 at 15:44 -0700, Ram Pai wrote:
> The second part of the PTE will hold
> (H_PAGE_F_SECOND|H_PAGE_F_GIX) at bit 60,61,62,63.
> NOTE: None of the bits in the secondary PTE were not used
> by 64k-HPTE backed PTE.
Have you measured the performance impact of this ? The second part of
On 14/09/2017 10:13, Sergey Senozhatsky wrote:
> Hi,
>
> On (09/14/17 09:55), Laurent Dufour wrote:
> [..]
>>> so if there are two CPUs, one doing write_seqcount() and the other one
>>> doing read_seqcount() then what can happen is something like this
>>>
>>> CPU0
On (09/14/17 10:58), Laurent Dufour wrote:
[..]
> That's right, but here this is the sequence counter mm->mm_seq, not the
> vm_seq one.
d'oh... you are right.
-ss
On 14/09/2017 11:11, Sergey Senozhatsky wrote:
> On (09/14/17 10:58), Laurent Dufour wrote:
> [..]
>> That's right, but here this is the sequence counter mm->mm_seq, not the
>> vm_seq one.
>
> d'oh... you are right.
So I'm doubting about the probability of a deadlock here, but I don't like
to se
Le 14/09/2017 à 01:51, Rob Landley a écrit :
From: Rob Landley
Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move
/dev/console open after devtmpfs mount.
Add workaround for Debian bug that was copied by Ubuntu.
Is that a bug only for Debian ? Why ?
Why should a Debian bug be fixed by a wor
From: Benjamin Herrenschmidt
> Sent: 14 September 2017 04:40
> On Thu, 2017-09-14 at 13:18 +1000, Alexey Kardashevskiy wrote:
> > On 14/09/17 13:07, Benjamin Herrenschmidt wrote:
> > > On Thu, 2017-09-14 at 12:45 +1000, Alexey Kardashevskiy wrote:
> > > > On 31/08/17 13:34, Alexey Kardashevskiy wro
On (09/14/17 11:15), Laurent Dufour wrote:
> On 14/09/2017 11:11, Sergey Senozhatsky wrote:
> > On (09/14/17 10:58), Laurent Dufour wrote:
> > [..]
> >> That's right, but here this is the sequence counter mm->mm_seq, not the
> >> vm_seq one.
> >
> > d'oh... you are right.
>
> So I'm doubting abo
On Thu, 14 Sep 2017 12:08:07 +0530
"Naveen N. Rao" wrote:
> On 2017/09/13 04:53PM, Masami Hiramatsu wrote:
> > On Thu, 14 Sep 2017 02:50:33 +0530
> > "Naveen N. Rao" wrote:
> >
> > > Currently, we disable instruction emulation if emulate_step() fails for
> > > any reason. However, such failures
On Thursday 14 September 2017 02:50 AM, Naveen N. Rao wrote:
Kamalesh pointed out that we are getting the below call traces with
livepatched functions when we enable CONFIG_PREEMPT:
[ 495.470721] BUG: using __this_cpu_read() in preemptible [] code:
cat/8394
[ 495.471167] caller is is_
On 2017/09/14 02:45AM, Masami Hiramatsu wrote:
> On Thu, 14 Sep 2017 12:08:07 +0530
> "Naveen N. Rao" wrote:
>
> > On 2017/09/13 04:53PM, Masami Hiramatsu wrote:
> > > On Thu, 14 Sep 2017 02:50:33 +0530
> > > "Naveen N. Rao" wrote:
> > >
> > > > Currently, we disable instruction emulation if em
On Thu, 2017-09-14 at 09:27 +, David Laight wrote:
> You can logically 'hotplug' PCI(e) on any system [1].
>
> The 'problem' is that whatever enumerates the PCI(e) at system
> powerup doesn't normally assign extra resources to bridges to allow
> for devices that aren't present at boot time.
>
On Thu, 14 Sep 2017 12:17:20 +0530
"Naveen N. Rao" wrote:
> On 2017/09/13 05:36PM, Masami Hiramatsu wrote:
> > On Thu, 14 Sep 2017 02:50:34 +0530
> > "Naveen N. Rao" wrote:
> >
> > > Kamalesh pointed out that we are getting the below call traces with
> > > livepatched functions when we enable C
There are two types of memory reservations firmware can ask the kernel
to make in the device tree: static and dynamic.
See Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
If you have greater than 16 entries in /reserved-memory (as we do on
POWER9 systems) you would get this s
On 2017/09/13 05:05PM, Masami Hiramatsu wrote:
> On Thu, 14 Sep 2017 02:50:35 +0530
> "Naveen N. Rao" wrote:
>
> > KPROBES_SANITY_TEST throws the below splat when CONFIG_PREEMPT is
> > enabled:
> >
> > [3.140410] Kprobe smoke test: started
> > [3.149680] DEBUG_LOCKS_WARN_ON(val > preempt
On Thu, 14 Sep 2017 15:55:39 +0530
"Naveen N. Rao" wrote:
> On 2017/09/13 05:05PM, Masami Hiramatsu wrote:
> > On Thu, 14 Sep 2017 02:50:35 +0530
> > "Naveen N. Rao" wrote:
> >
> > > KPROBES_SANITY_TEST throws the below splat when CONFIG_PREEMPT is
> > > enabled:
> > >
> > > [3.140410] Kpr
On Wed, 13 Sep 2017 02:05:53 +1000
Nicholas Piggin wrote:
> There are two complications. The first is that sreset from stop states
> come in with SRR1 set to do a powersave wakeup, with an sreset reason
> encoded.
>
> The second is that threads on the same core can't be signalled directly
> so w
Simple printk format warning for the the ucc registers address.
Signed-off-by: Valentin Longchamp
---
drivers/net/ethernet/freescale/ucc_geth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c
b/drivers/net/ethernet/freescale/ucc_geth
Hi,
Le 14/09/2017 à 14:05, Valentin Longchamp a écrit :
Simple printk format warning for the the ucc registers address.
Did you test your patch with mpc83xx_defconfig ?
I get a new warning with your patch:
CC drivers/net/ethernet/freescale/ucc_geth.o
In file included from ./include/li
On Thu, Aug 24, 2017 at 04:37:45PM -0400, Roy Pledge wrote:
> --- a/drivers/soc/fsl/qbman/bman_ccsr.c
> +++ b/drivers/soc/fsl/qbman/bman_ccsr.c
[...]
> @@ -201,6 +202,38 @@ static int fsl_bman_probe(struct platform_device *pdev)
> return -ENODEV;
> }
>
> + /*
> + * If
On Thu, Aug 24, 2017 at 04:37:47PM -0400, Roy Pledge wrote:
> Updates the QMan and BMan device tree bindings for reserved memory
> nodes. This makes the reserved memory allocation compatible with
> the shared-dma-pool usage.
>
> Signed-off-by: Roy Pledge
> ---
> Documentation/devicetree/bindings
On Thu, Aug 24, 2017 at 04:37:49PM -0400, Roy Pledge wrote:
> From: Claudiu Manoil
>
> Not relevant and arch dependent. Overkill for PPC.
>
> Signed-off-by: Claudiu Manoil
> Signed-off-by: Roy Pledge
> ---
> drivers/soc/fsl/qbman/dpaa_sys.h | 4
> 1 file changed, 4 deletions(-)
>
> diff
On Thu, Aug 24, 2017 at 04:37:51PM -0400, Roy Pledge wrote:
> diff --git a/drivers/soc/fsl/qbman/bman.c b/drivers/soc/fsl/qbman/bman.c
> index ff8998f..e31c843 100644
> --- a/drivers/soc/fsl/qbman/bman.c
> +++ b/drivers/soc/fsl/qbman/bman.c
> @@ -154,7 +154,7 @@ struct bm_mc {
> };
>
> struct b
Hi Christophe,
On Thu, 2017-09-14 at 15:24 +0200, Christophe LEROY wrote:
> Hi,
>
> Le 14/09/2017 à 14:05, Valentin Longchamp a écrit :
> > Simple printk format warning for the the ucc registers address.
>
> Did you test your patch with mpc83xx_defconfig ?
No I only tested on a 85xx where I had
On Thu, Sep 14, 2017 at 02:38:07PM +1000, Balbir Singh wrote:
> On Fri, 8 Sep 2017 15:44:50 -0700
> Ram Pai wrote:
>
> > powerpc needs an additional vma bit to support 32 keys.
> > Till the additional vma bit lands in include/linux/mm.h
> > we have to define it in powerpc specific header file.
On Thu, Sep 14, 2017 at 01:32:05PM +1000, Balbir Singh wrote:
> On Fri, 8 Sep 2017 15:44:49 -0700
> Ram Pai wrote:
>
> > Basic plumbing to initialize the pkey system.
> > Nothing is enabled yet. A later patch will enable it
> > ones all the infrastructure is in place.
> >
> > Signed-off
On Sat, 2017-09-09 at 14:59 +0200, Joakim Tjernlund wrote:
> On Sat, 2017-09-09 at 14:45 +0200, Joakim Tjernlund wrote:
> > On Fri, 2017-09-08 at 22:27 +, Leo Li wrote:
> > > > -Original Message-
> > > > From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> > > > Sent: Friday,
On Thu, Sep 14, 2017 at 01:22:27PM +1000, Balbir Singh wrote:
> On Fri, 8 Sep 2017 15:44:47 -0700
> Ram Pai wrote:
>
> > The H_PAGE_F_SECOND,H_PAGE_F_GIX are not in the 64K main-PTE.
> > capture these changes in the dump pte report.
> >
> > Reviewed-by: Aneesh Kumar K.V
> > Signed-off-by: Ram
On Thu, Sep 14, 2017 at 11:48:34AM +1000, Balbir Singh wrote:
> On Fri, 8 Sep 2017 15:44:45 -0700
> Ram Pai wrote:
>
> > We need PTE bits 3 ,4, 5, 6 and 57 to support protection-keys,
> > because these are the bits we want to consolidate on across all
> > configuration to support protection
On Wed, Sep 13, 2017 at 06:51:25PM -0500, Rob Landley wrote:
> From: Rob Landley
>
> Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move
> /dev/console open after devtmpfs mount.
>
> Add workaround for Debian bug that was copied by Ubuntu.
>
> Signed-off-by: Rob Landley
> ---
>
> v2 discussi
On Thu, Sep 14, 2017 at 11:44:49AM +1000, Balbir Singh wrote:
> On Fri, 8 Sep 2017 15:44:44 -0700
> Ram Pai wrote:
>
> > Rearrange 64K PTE bits to free up bits 3, 4, 5 and 6
> > in the 64K backed HPTE pages. This along with the earlier
> > patch will entirely free up the four bits from 64
On Thu, Sep 14, 2017 at 10:54:08AM -0700, Ram Pai wrote:
> On Thu, Sep 14, 2017 at 11:44:49AM +1000, Balbir Singh wrote:
> > On Fri, 8 Sep 2017 15:44:44 -0700
> > Ram Pai wrote:
> >
> > > Rearrange 64K PTE bits to free up bits 3, 4, 5 and 6
> > > in the 64K backed HPTE pages. This along wit
On 9/14/2017 9:49 AM, Catalin Marinas wrote:
> On Thu, Aug 24, 2017 at 04:37:49PM -0400, Roy Pledge wrote:
>> From: Claudiu Manoil
>>
>> Not relevant and arch dependent. Overkill for PPC.
>>
>> Signed-off-by: Claudiu Manoil
>> Signed-off-by: Roy Pledge
>> ---
>> drivers/soc/fsl/qbman/dpaa_sys.
On 9/14/2017 10:00 AM, Catalin Marinas wrote:
> On Thu, Aug 24, 2017 at 04:37:51PM -0400, Roy Pledge wrote:
>> diff --git a/drivers/soc/fsl/qbman/bman.c b/drivers/soc/fsl/qbman/bman.c
>> index ff8998f..e31c843 100644
>> --- a/drivers/soc/fsl/qbman/bman.c
>> +++ b/drivers/soc/fsl/qbman/bman.c
>> @@
Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT),
flags and other fields in "struct page"es are never changed prior to first
initializing struct pages by going through __init_single_page().
With deferred struct page feature enabled, however, we set fields in
register_page_bo
Add struct page zeroing as a part of initialization of other fields in
__init_single_page().
This single thread performance collected on: Intel(R) Xeon(R) CPU E7-8895
v3 @ 2.60GHz with 1T of memory (268400646 pages in 8 nodes):
BASEFIX
sparse_init 11.244671
Some memory is reserved but unavailable: not present in memblock.memory
(because not backed by physical pages), but present in memblock.reserved.
Such memory has backing struct pages, but they are not initialized by going
through __init_single_page().
In some cases these struct pages are accessed
Remove duplicating code by using common functions
vmemmap_pud_populate and vmemmap_pgd_populate.
Signed-off-by: Pavel Tatashin
Reviewed-by: Steven Sistare
Reviewed-by: Daniel Jordan
Reviewed-by: Bob Picco
Acked-by: David S. Miller
---
arch/sparc/mm/init_64.c | 23 ++-
1 f
vmemmap_alloc_block() will no longer zero the block, so zero memory
at its call sites for everything except struct pages. Struct page memory
is zero'd by struct page initialization.
Replace allocators in sprase-vmemmap to use the non-zeroing version. So,
we will get the performance improvement by
This patch fixes two issues in deferred_init_memmap
=
In deferred_init_memmap() where all deferred struct pages are initialized
we have a check like this:
if (page->flags) {
VM_BUG_ON(page_zone(page) != zone);
goto free_range;
}
This way we are checking if the current deferre
To optimize the performance of struct page initialization,
vmemmap_populate() will no longer zero memory.
We must explicitly zero the memory that is allocated by vmemmap_populate()
for kasan, as this memory does not go through struct page initialization
path.
Signed-off-by: Pavel Tatashin
Review
* A new variant of memblock_virt_alloc_* allocations:
memblock_virt_alloc_try_nid_raw()
- Does not zero the allocated memory
- Does not panic if request cannot be satisfied
* optimize early system hash allocations
Clients can call alloc_large_system_hash() with flag: HASH_ZERO to specify
To optimize the performance of struct page initialization,
vmemmap_populate() will no longer zero memory.
We must explicitly zero the memory that is allocated by vmemmap_populate()
for kasan, as this memory does not go through struct page initialization
path.
Signed-off-by: Pavel Tatashin
Review
Add an optimized mm_zero_struct_page(), so struct page's are zeroed without
calling memset(). We do eight to ten regular stores based on the size of
struct page. Compiler optimizes out the conditions of switch() statement.
SPARC-M6 with 15T of memory, single thread performance:
Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT),
flags and other fields in "struct page"es are never changed prior to first
initializing struct pages by going through __init_single_page().
With deferred struct page feature enabled there is a case where we set some
fields pr
Changelog:
v8 - v7
- Added Acked-by's from Dave Miller for SPARC changes
- Fixed a minor compiling issue on tile architecture reported by kbuild
v7 - v6
- Addressed comments from Michal Hocko
- memblock_discard() patch was removed from this series and integrated
separately
- Fixed bug reported b
Copy paste error, changing the subject for the header to v8 from v7.
On 09/14/2017 06:35 PM, Pavel Tatashin wrote:
Changelog:
v8 - v7
- Added Acked-by's from Dave Miller for SPARC changes
- Fixed a minor compiling issue on tile architecture reported by kbuild
v7 - v6
- Addressed comments from M
The following program causes a kernel oops:
#include
#include
#include
#include
#include
main()
{
int fd = open("/dev/kvm", O_RDWR);
ioctl(fd, KVM_CHECK_EXTENSION, KVM_CAP_PPC_HTM);
}
This happens because when using the global KVM fd with
KVM_CHECK_EXTENSION, kvm_vm_ioctl_check_exte
On Thu, Sep 14, 2017 at 11:56:25PM +0200, Greg Kurz wrote:
> The following program causes a kernel oops:
>
> #include
> #include
> #include
> #include
> #include
>
> main()
> {
> int fd = open("/dev/kvm", O_RDWR);
> ioctl(fd, KVM_CHECK_EXTENSION, KVM_CAP_PPC_HTM);
> }
>
> This happe
On Thu, Sep 14, 2017 at 06:35:16PM -0400, Pavel Tatashin wrote:
> To optimize the performance of struct page initialization,
> vmemmap_populate() will no longer zero memory.
>
> We must explicitly zero the memory that is allocated by vmemmap_populate()
> for kasan, as this memory does not go throu
On Wed, 2017-09-13 at 22:13 -0400, Gustavo Romero wrote:
> Commit cd63f3c ("powerpc/tm: Fix saving of TM SPRs in core dump")
> added code to access TM SPRs in flush_tmregs_to_thread(). However
> flush_tmregs_to_thread() does not check if TM feature is available on
> CPU before trying to access TM S
Hi Mark,
Thank you for looking at this. We can't do this because page table is
not set until cpu_replace_ttbr1() is called. So, we can't do memset() on
this memory until then.
Pasha
The vendor string for Microcrystal is microcrystal.
Signed-off-by: Alexandre Belloni
---
Documentation/devicetree/bindings/trivial-devices.txt | 2 +-
drivers/rtc/rtc-rv3029c2.c| 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicet
The rv3029 compatible is missing its vendor string, add it.
Also fix the node name to be a proper generic name.
Signed-off-by: Alexandre Belloni
---
arch/arm/boot/dts/usb_a9g20_common.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/usb_a9g20_common.
The proper compatible for rv3029 is microcrystal,rv3029.
Signed-off-by: Alexandre Belloni
---
arch/powerpc/boot/dts/digsy_mtc.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/dts/digsy_mtc.dts
b/arch/powerpc/boot/dts/digsy_mtc.dts
index c280e75c86bf..c39
On POWER9 DD2.1 and below, it's possible to get Machine Check
Exception (MCE) where only DSISR bit 33 is set. This will result in
the linux MCE handler seeing an unknown event, which triggers linux to
crash.
We change this by detecting unknown events in the MCE handler and
marking them as handled
POWER9 DD2.1 and earlier has an issue where some cache inhibited
vector load will return bad data. The workaround is two part, one
firmware/microcode part triggers HMI interrupts when hitting such
loads, the other part is this patch which then emulates the
instructions in Linux.
The affected instr
On POWER9 DD2.1 and below, sometimes on a Hypervisor Data Storage
Interrupt (HDSI) the HDSISR is not be updated at all.
To work around this we put a canary value into the HDSISR before
returning to a guest and then check for this canary when we take a
HDSI. If we find the canary on a HDSI, we know
Dang! The mail relay at OVH has blacklisted Paul's address :-\
: host smtp.samba.org[144.76.82.148] said: 550-blacklisted at
zen.spamhaus.org 550 https://www.spamhaus.org/sbl/query/SBL370982 (in reply
to RCPT TO command)
Cc'ing Paul at ozlabs.org
On Fri, 15 Sep 2017 10:48:39 +1000
David
uf_info.regs is resource_size_t i.e. phys_addr_t that can be either u32
or u64 according to CONFIG_PHYS_ADDR_T_64BIT.
The printk format is thus adaptet to u64 and the regs value cast to u64
to take both u32 and u64 into account.
Signed-off-by: Valentin Longchamp
---
drivers/net/ethernet/freesca
On Fri, 15 Sep 2017 07:52:49 +0200
Greg Kurz wrote:
> Dang! The mail relay at OVH has blacklisted Paul's address :-\
>
> : host smtp.samba.org[144.76.82.148] said: 550-blacklisted
> at
> zen.spamhaus.org 550 https://www.spamhaus.org/sbl/query/SBL370982 (in
> reply
> to RCPT TO command)
63 matches
Mail list logo
