On 18.07.18 11:40, Joerg Roedel wrote:
From: Joerg Roedel
It can happen that we enter the kernel from kernel-mode and
on the entry-stack. The most common way this happens is when
we get an exception while loading the user-space segment
registers on the kernel-to-userspace exit path.
The
On 18.07.18 11:40, Joerg Roedel wrote:
From: Joerg Roedel
It can happen that we enter the kernel from kernel-mode and
on the entry-stack. The most common way this happens is when
we get an exception while loading the user-space segment
registers on the kernel-to-userspace exit path.
The
Quoting Stephen Boyd (2018-08-31 10:45:30)
> Quoting Alexandre Belloni (2018-08-16 04:47:55)
> > On 27/07/2018 10:03:22-0700, Stephen Boyd wrote:
> > > Quoting Alexandre Belloni (2018-07-17 15:27:41)
> > > > This is the promised rework of the at91 PMC clocks driver. It is mainly
> > > > necessary
Quoting Stephen Boyd (2018-08-31 10:45:30)
> Quoting Alexandre Belloni (2018-08-16 04:47:55)
> > On 27/07/2018 10:03:22-0700, Stephen Boyd wrote:
> > > Quoting Alexandre Belloni (2018-07-17 15:27:41)
> > > > This is the promised rework of the at91 PMC clocks driver. It is mainly
> > > > necessary
On Fri, Oct 12, 2018 at 2:35 AM Jann Horn wrote:
> On Fri, Oct 12, 2018 at 1:40 AM Rick Edgecombe
> wrote:
> > This introduces a new rlimit, RLIMIT_MODSPACE, which limits the amount of
> > module space a user can use. The intention is to be able to limit module
> > space
> > allocations that
On Fri, Oct 12, 2018 at 2:35 AM Jann Horn wrote:
> On Fri, Oct 12, 2018 at 1:40 AM Rick Edgecombe
> wrote:
> > This introduces a new rlimit, RLIMIT_MODSPACE, which limits the amount of
> > module space a user can use. The intention is to be able to limit module
> > space
> > allocations that
On Fri, 12 Oct 2018 11:21:28 -0700
Andy Lutomirski wrote:
> On Fri, Oct 12, 2018 at 9:26 AM Steven Rostedt wrote:
> >
> >
> > Anyone have any issues with this patch?
> >
>
> I'm conceptually okay with it. That being said,
> regs_within_kernel_stack(), which you're indirectly using, is
>
On Fri, 12 Oct 2018 11:21:28 -0700
Andy Lutomirski wrote:
> On Fri, Oct 12, 2018 at 9:26 AM Steven Rostedt wrote:
> >
> >
> > Anyone have any issues with this patch?
> >
>
> I'm conceptually okay with it. That being said,
> regs_within_kernel_stack(), which you're indirectly using, is
>
On Fri 2018-10-12 20:10:11, Pavel Machek wrote:
> Hi!
>
> > > > So what came in between -next20181005 and the first bad one?
> > > > kernel/sched/*
> > > > being the first place to look at.
> > >
> > > kernel/sched does not seem to contain anything too scary.
> > >
> > > I know that
On Fri 2018-10-12 20:10:11, Pavel Machek wrote:
> Hi!
>
> > > > So what came in between -next20181005 and the first bad one?
> > > > kernel/sched/*
> > > > being the first place to look at.
> > >
> > > kernel/sched does not seem to contain anything too scary.
> > >
> > > I know that
On Fri, Oct 12, 2018 at 9:26 AM Steven Rostedt wrote:
>
>
> Anyone have any issues with this patch?
>
I'm conceptually okay with it. That being said,
regs_within_kernel_stack(), which you're indirectly using, is
off-by-a-few. And updating it to use probe_kernel_read() might be
nice for
On Fri, Oct 12, 2018 at 9:26 AM Steven Rostedt wrote:
>
>
> Anyone have any issues with this patch?
>
I'm conceptually okay with it. That being said,
regs_within_kernel_stack(), which you're indirectly using, is
off-by-a-few. And updating it to use probe_kernel_read() might be
nice for
On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> From: Rik van Riel
>
> copy_fpstate_to_sigframe() has two callers and both invoke the function only
> if
> fpu->initialized is set. So the check in the function for ->initialized makes
> no sense. It might be a relict from the lazy-FPU
On Fri, Aug 24, 2018 at 03:25:42PM -0400, jgli...@redhat.com wrote:
> From: Jérôme Glisse
>
> Few fixes that only affect HMM users. Improve the synchronization call
> back so that we match was other mmu_notifier listener do and add proper
> support to the new blockable flags in the process.
>
>
On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> From: Rik van Riel
>
> copy_fpstate_to_sigframe() has two callers and both invoke the function only
> if
> fpu->initialized is set. So the check in the function for ->initialized makes
> no sense. It might be a relict from the lazy-FPU
On Fri, Aug 24, 2018 at 03:25:42PM -0400, jgli...@redhat.com wrote:
> From: Jérôme Glisse
>
> Few fixes that only affect HMM users. Improve the synchronization call
> back so that we match was other mmu_notifier listener do and add proper
> support to the new blockable flags in the process.
>
>
On Fri, Oct 12, 2018 at 10:49:31AM -0700, Dan Williams wrote:
> [ apologies for the resend, script error ]
>
> Changes since v6 [1]:
> * Rebase on next-20181008 and fixup conflicts with the xarray conversion
> and hotplug optimizations
> * It has soaked on a 0day visible branch for a few days
On Fri, Oct 12, 2018 at 10:49:31AM -0700, Dan Williams wrote:
> [ apologies for the resend, script error ]
>
> Changes since v6 [1]:
> * Rebase on next-20181008 and fixup conflicts with the xarray conversion
> and hotplug optimizations
> * It has soaked on a 0day visible branch for a few days
On Fri, Oct 12, 2018 at 08:10:11PM +0200, Pavel Machek wrote:
> And the winner is...
>
> [1be3f247c2882a82279cbcf43717581ea943b692] x86/mm: Avoid VLA in
> pgd_alloc()
That should be fixed now:
https://git.kernel.org/tip/184d47f0fd365108bd06ab26cdb3450b716269fd
--
Regards/Gruss,
Boris.
On Fri, Oct 12, 2018 at 08:10:11PM +0200, Pavel Machek wrote:
> And the winner is...
>
> [1be3f247c2882a82279cbcf43717581ea943b692] x86/mm: Avoid VLA in
> pgd_alloc()
That should be fixed now:
https://git.kernel.org/tip/184d47f0fd365108bd06ab26cdb3450b716269fd
--
Regards/Gruss,
Boris.
On Thu, Oct 11, 2018 at 7:02 AM Arnd Bergmann wrote:
>
> On 10/10/18, Krzysztof Kozlowski wrote:
> > Hi,
> >
> > On top of previous pull request.
> >
> >
> > Samsung mach/soc changes for v4.20, second round
> >
> > 1. Disable
On Thu, Oct 11, 2018 at 7:02 AM Arnd Bergmann wrote:
>
> On 10/10/18, Krzysztof Kozlowski wrote:
> > Hi,
> >
> > On top of previous pull request.
> >
> >
> > Samsung mach/soc changes for v4.20, second round
> >
> > 1. Disable
From: Jérôme Glisse
Inside set_pmd_migration_entry() we are holding page table locks and
thus we can not sleep so we can not call invalidate_range_start/end()
So remove call to mmu_notifier_invalidate_range_start/end() because
they are call inside the function calling set_pmd_migration_entry()
On 10/12/2018 04:31 AM, Jordan Glover wrote:
> ‐‐‐ Original Message ‐‐‐
> On Friday, October 12, 2018 2:26 AM, John Johansen
> wrote:
>
>> On 10/11/2018 04:53 PM, Jordan Glover wrote:
>>
>>> ‐‐‐ Original Message ‐‐‐
>>> On Friday, October 12, 2018 1:09 AM, Kees Cook
From: Jérôme Glisse
Inside set_pmd_migration_entry() we are holding page table locks and
thus we can not sleep so we can not call invalidate_range_start/end()
So remove call to mmu_notifier_invalidate_range_start/end() because
they are call inside the function calling set_pmd_migration_entry()
On 10/12/2018 04:31 AM, Jordan Glover wrote:
> ‐‐‐ Original Message ‐‐‐
> On Friday, October 12, 2018 2:26 AM, John Johansen
> wrote:
>
>> On 10/11/2018 04:53 PM, Jordan Glover wrote:
>>
>>> ‐‐‐ Original Message ‐‐‐
>>> On Friday, October 12, 2018 1:09 AM, Kees Cook
Hi!
> > > So what came in between -next20181005 and the first bad one?
> > > kernel/sched/*
> > > being the first place to look at.
> >
> > kernel/sched does not seem to contain anything too scary.
> >
> > I know that -next20181005 works ok, and I know -next20181010 is
> > bad. Is there easy
Hi!
> > > So what came in between -next20181005 and the first bad one?
> > > kernel/sched/*
> > > being the first place to look at.
> >
> > kernel/sched does not seem to contain anything too scary.
> >
> > I know that -next20181005 works ok, and I know -next20181010 is
> > bad. Is there easy
On 10/12/2018 7:55 PM, Sudeep Holla wrote:
On Thu, Oct 11, 2018 at 02:50:54AM +0530, Raju P.L.S.S.S.N wrote:
Use cpu hotplug callback mechanism to attach/dettach the cpu in
the cpu power domain. During cpu hotplug callback registration,
the starting callback is invoked on all online cpus. So
On 10/12/2018 7:55 PM, Sudeep Holla wrote:
On Thu, Oct 11, 2018 at 02:50:54AM +0530, Raju P.L.S.S.S.N wrote:
Use cpu hotplug callback mechanism to attach/dettach the cpu in
the cpu power domain. During cpu hotplug callback registration,
the starting callback is invoked on all online cpus. So
On Fri, Oct 12, 2018 at 10:51 AM Dave Hansen
wrote:
>
> On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> > From: Rik van Riel
> >
> > While most of a task's FPU state is only needed in user space,
> > the protection keys need to be in place immediately after a
> > context switch.
> >
>
On Fri, Oct 12, 2018 at 10:51 AM Dave Hansen
wrote:
>
> On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> > From: Rik van Riel
> >
> > While most of a task's FPU state is only needed in user space,
> > the protection keys need to be in place immediately after a
> > context switch.
> >
>
On 10/11/2018 4:38 PM, Sudeep Holla wrote:
On Thu, Oct 11, 2018 at 02:50:52AM +0530, Raju P.L.S.S.S.N wrote:
Add device binding documentation for Qualcomm Technology Inc's cpu
domain driver. The driver is used for managing system sleep activities
that are required when application processor
On 10/11/2018 4:38 PM, Sudeep Holla wrote:
On Thu, Oct 11, 2018 at 02:50:52AM +0530, Raju P.L.S.S.S.N wrote:
Add device binding documentation for Qualcomm Technology Inc's cpu
domain driver. The driver is used for managing system sleep activities
that are required when application processor
On Fri, Oct 12, 2018 at 10:58 AM Dave Hansen
wrote:
>
> On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> > The fpu->initialized flag should not be changed underneath us. This might
> > be a
> > fallout during the removal of the LazyFPU support. The FPU is marked
> > initialized as soon
On Fri, Oct 12, 2018 at 10:58 AM Dave Hansen
wrote:
>
> On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> > The fpu->initialized flag should not be changed underneath us. This might
> > be a
> > fallout during the removal of the LazyFPU support. The FPU is marked
> > initialized as soon
Hi!
> > >>> Signed-off-by: Dan Murphy
> > >>
> > >> NAK.
> > >
> > > Thanks for the NAK.
> > >
> > > This NAK was NAK'd by other maintainer in the V2 RFC patchset
> > >
> > > https://lore.kernel.org/patchwork/patch/993171/
> >
> > I confirm. LM3697 is a standalone device and not a cell of
Hi!
> > >>> Signed-off-by: Dan Murphy
> > >>
> > >> NAK.
> > >
> > > Thanks for the NAK.
> > >
> > > This NAK was NAK'd by other maintainer in the V2 RFC patchset
> > >
> > > https://lore.kernel.org/patchwork/patch/993171/
> >
> > I confirm. LM3697 is a standalone device and not a cell of
The routines hmm_devmem_add(), and hmm_devmem_add_resource() duplicated
devm_memremap_pages() and are now simple now wrappers around the core
facility to inject a dev_pagemap instance into the global pgmap_radix
and hook page-idle events. The devm_memremap_pages() interface is base
infrastructure
On 10/12/2018 8:03 PM, Sudeep Holla wrote:
On Thu, Oct 11, 2018 at 02:50:51AM +0530, Raju P.L.S.S.S.N wrote:
RPMH based targets require that the sleep and wake state request votes
be sent during system low power mode entry. The votes help reduce the
power consumption when the AP is not using
From: "Kirill A. Shutemov"
Date: Fri, 12 Oct 2018 14:30:56 +0300
> I looked into the code more and noticed move_pte() helper called from
> move_ptes(). It changes PTE entry to suite new address.
>
> It is only defined in non-trivial way on Sparc. I don't know much about
> Sparc and it's hard
On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen
wrote:
>
> On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> > The PKRU value is not set for kernel threads because they do not have
> > the ->initialized value set. As a result the kernel thread has a random
> > PKRU value set which it
The routines hmm_devmem_add(), and hmm_devmem_add_resource() duplicated
devm_memremap_pages() and are now simple now wrappers around the core
facility to inject a dev_pagemap instance into the global pgmap_radix
and hook page-idle events. The devm_memremap_pages() interface is base
infrastructure
On 10/12/2018 8:03 PM, Sudeep Holla wrote:
On Thu, Oct 11, 2018 at 02:50:51AM +0530, Raju P.L.S.S.S.N wrote:
RPMH based targets require that the sleep and wake state request votes
be sent during system low power mode entry. The votes help reduce the
power consumption when the AP is not using
From: "Kirill A. Shutemov"
Date: Fri, 12 Oct 2018 14:30:56 +0300
> I looked into the code more and noticed move_pte() helper called from
> move_ptes(). It changes PTE entry to suite new address.
>
> It is only defined in non-trivial way on Sparc. I don't know much about
> Sparc and it's hard
On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen
wrote:
>
> On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> > The PKRU value is not set for kernel threads because they do not have
> > the ->initialized value set. As a result the kernel thread has a random
> > PKRU value set which it
devm semantics arrange for resources to be torn down when
device-driver-probe fails or when device-driver-release completes.
Similar to devm_memremap_pages() there is no need to support an explicit
remove operation when the users properly adhere to devm semantics.
Note that devm_kzalloc()
devm semantics arrange for resources to be torn down when
device-driver-probe fails or when device-driver-release completes.
Similar to devm_memremap_pages() there is no need to support an explicit
remove operation when the users properly adhere to devm semantics.
Note that devm_kzalloc()
On 10/10/2018 05:09 PM, Subhra Mazumdar wrote:
> Hi,
>
> I was following the Coscheduling patch discussion on lkml and Peter mentioned
> he had a patch series. I found the following on github.
>
> https://github.com/pdxChen/gang/commits/sched_1.23-loadbal
>
> I would like to test this with
Commit e8d513483300 "memremap: change devm_memremap_pages interface to
use struct dev_pagemap" refactored devm_memremap_pages() to allow a
dev_pagemap instance to be supplied. Passing in a dev_pagemap interface
simplifies the design of pgmap type drivers in that they can rely on
container_of() to
Given the fact that devm_memremap_pages() requires a percpu_ref that is
torn down by devm_memremap_pages_release() the current support for
mapping RAM is broken.
Support for remapping "System RAM" has been broken since the beginning
and there is no existing user of this this code path, so just
On 10/10/2018 05:09 PM, Subhra Mazumdar wrote:
> Hi,
>
> I was following the Coscheduling patch discussion on lkml and Peter mentioned
> he had a patch series. I found the following on github.
>
> https://github.com/pdxChen/gang/commits/sched_1.23-loadbal
>
> I would like to test this with
Commit e8d513483300 "memremap: change devm_memremap_pages interface to
use struct dev_pagemap" refactored devm_memremap_pages() to allow a
dev_pagemap instance to be supplied. Passing in a dev_pagemap interface
simplifies the design of pgmap type drivers in that they can rely on
container_of() to
Given the fact that devm_memremap_pages() requires a percpu_ref that is
torn down by devm_memremap_pages_release() the current support for
mapping RAM is broken.
Support for remapping "System RAM" has been broken since the beginning
and there is no existing user of this this code path, so just
The last step before devm_memremap_pages() returns success is to
allocate a release action, devm_memremap_pages_release(), to tear the
entire setup down. However, the result from devm_add_action() is not
checked.
Checking the error from devm_add_action() is not enough. The api
currently relies on
In preparation for consolidating all ZONE_DEVICE enabling via
devm_memremap_pages(), teach it how to handle the constraints of
MEMORY_DEVICE_PRIVATE ranges.
Reviewed-by: Jérôme Glisse
[jglisse: call move_pfn_range_to_zone for MEMORY_DEVICE_PRIVATE]
Acked-by: Christoph Hellwig
Reported-by: Logan
The last step before devm_memremap_pages() returns success is to
allocate a release action, devm_memremap_pages_release(), to tear the
entire setup down. However, the result from devm_add_action() is not
checked.
Checking the error from devm_add_action() is not enough. The api
currently relies on
In preparation for consolidating all ZONE_DEVICE enabling via
devm_memremap_pages(), teach it how to handle the constraints of
MEMORY_DEVICE_PRIVATE ranges.
Reviewed-by: Jérôme Glisse
[jglisse: call move_pfn_range_to_zone for MEMORY_DEVICE_PRIVATE]
Acked-by: Christoph Hellwig
Reported-by: Logan
[ apologies for the resend, script error ]
Changes since v6 [1]:
* Rebase on next-20181008 and fixup conflicts with the xarray conversion
and hotplug optimizations
* It has soaked on a 0day visible branch for a few days without any
reports.
[1]: https://lkml.org/lkml/2018/9/13/104
---
Hi
devm_memremap_pages() is a facility that can create struct page entries
for any arbitrary range and give drivers the ability to subvert core
aspects of page management.
Specifically the facility is tightly integrated with the kernel's memory
hotplug functionality. It injects an altmap argument
devm_memremap_pages() is a facility that can create struct page entries
for any arbitrary range and give drivers the ability to subvert core
aspects of page management.
Specifically the facility is tightly integrated with the kernel's memory
hotplug functionality. It injects an altmap argument
[ apologies for the resend, script error ]
Changes since v6 [1]:
* Rebase on next-20181008 and fixup conflicts with the xarray conversion
and hotplug optimizations
* It has soaked on a 0day visible branch for a few days without any
reports.
[1]: https://lkml.org/lkml/2018/9/13/104
---
Hi
Changes since v6 [1]:
* Rebase on next-20181008 and fixup conflicts with the xarray conversion
and hotplug optimizations
* It has soaked on a 0day visible branch for a few days without any
reports.
[1]: https://lkml.org/lkml/2018/9/13/104
---
Hi Andrew,
Jérôme has reviewed the cleanups,
devm_memremap_pages() is a facility that can create struct page entries
for any arbitrary range and give drivers the ability to subvert core
aspects of page management.
Specifically the facility is tightly integrated with the kernel's memory
hotplug functionality. It injects an altmap argument
Changes since v6 [1]:
* Rebase on next-20181008 and fixup conflicts with the xarray conversion
and hotplug optimizations
* It has soaked on a 0day visible branch for a few days without any
reports.
[1]: https://lkml.org/lkml/2018/9/13/104
---
Hi Andrew,
Jérôme has reviewed the cleanups,
devm_memremap_pages() is a facility that can create struct page entries
for any arbitrary range and give drivers the ability to subvert core
aspects of page management.
Specifically the facility is tightly integrated with the kernel's memory
hotplug functionality. It injects an altmap argument
On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> The fpu->initialized flag should not be changed underneath us. This might be a
> fallout during the removal of the LazyFPU support. The FPU is marked
> initialized as soon as the state has been set to an initial value. It does not
> signal
On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> The fpu->initialized flag should not be changed underneath us. This might be a
> fallout during the removal of the LazyFPU support. The FPU is marked
> initialized as soon as the state has been set to an initial value. It does not
> signal
On Fri, Oct 12, 2018 at 01:35:19PM -0400, Jerome Glisse wrote:
> On Fri, Oct 12, 2018 at 01:24:22PM -0400, Andrea Arcangeli wrote:
> > Hello,
> >
> > On Fri, Oct 12, 2018 at 12:20:54PM -0400, Zi Yan wrote:
> > > On 12 Oct 2018, at 12:09, jgli...@redhat.com wrote:
> > >
> > > > From: Jérôme
On Fri, Oct 12, 2018 at 01:35:19PM -0400, Jerome Glisse wrote:
> On Fri, Oct 12, 2018 at 01:24:22PM -0400, Andrea Arcangeli wrote:
> > Hello,
> >
> > On Fri, Oct 12, 2018 at 12:20:54PM -0400, Zi Yan wrote:
> > > On 12 Oct 2018, at 12:09, jgli...@redhat.com wrote:
> > >
> > > > From: Jérôme
On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> The variable init_pkru_value isn't used outside of this file.
> Make init_pkru_value static.
>
> Signed-off-by: Sebastian Andrzej Siewior
Looks good.
Acked-by: Dave Hansen
On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> The variable init_pkru_value isn't used outside of this file.
> Make init_pkru_value static.
>
> Signed-off-by: Sebastian Andrzej Siewior
Looks good.
Acked-by: Dave Hansen
On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> The PKRU value is not set for kernel threads because they do not have
> the ->initialized value set. As a result the kernel thread has a random
> PKRU value set which it inherits from the previous task.
> It has been suggested by Paolo
On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> The PKRU value is not set for kernel threads because they do not have
> the ->initialized value set. As a result the kernel thread has a random
> PKRU value set which it inherits from the previous task.
> It has been suggested by Paolo
Quoting Weiyi Lu (2018-09-20 02:57:27)
> For some MT2712 projects, audpll could select another reference
> clock source if there exists an extra Crystal Oscillators than
> the default clk26m XTAL.
> Declare with the property "mediatek,refclk-aud" to switch
> the audpll reference clock.
> And also
On Fri, Oct 12 2018 at 11:35 -0600, Sudeep Holla wrote:
On Thu, Oct 11, 2018 at 02:50:55AM +0530, Raju P.L.S.S.S.N wrote:
Add cpu power domain support
Signed-off-by: Raju P.L.S.S.S.N
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git
Quoting Weiyi Lu (2018-09-20 02:57:27)
> For some MT2712 projects, audpll could select another reference
> clock source if there exists an extra Crystal Oscillators than
> the default clk26m XTAL.
> Declare with the property "mediatek,refclk-aud" to switch
> the audpll reference clock.
> And also
On Fri, Oct 12 2018 at 11:35 -0600, Sudeep Holla wrote:
On Thu, Oct 11, 2018 at 02:50:55AM +0530, Raju P.L.S.S.S.N wrote:
Add cpu power domain support
Signed-off-by: Raju P.L.S.S.S.N
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git
On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> From: Rik van Riel
>
> While most of a task's FPU state is only needed in user space,
> the protection keys need to be in place immediately after a
> context switch.
>
> The reason is that any accesses to userspace memory while running
On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> From: Rik van Riel
>
> While most of a task's FPU state is only needed in user space,
> the protection keys need to be in place immediately after a
> context switch.
>
> The reason is that any accesses to userspace memory while running
On Thu, Oct 11, 2018 at 05:35:02PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.133 release.
> There are 35 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Oct 11, 2018 at 05:35:02PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.133 release.
> There are 35 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
Quoting Bartosz Golaszewski (2018-09-20 05:59:54)
> 2018-08-28 11:33 GMT+02:00 Bartosz Golaszewski :
> > This series implements devm_kstrdup_const() together with some
> > prerequisite changes and uses it in pmc-atom driver.
> >
> > v1 -> v2:
> > - fixed the changelog in the patch implementing
Quoting Bartosz Golaszewski (2018-09-20 05:59:54)
> 2018-08-28 11:33 GMT+02:00 Bartosz Golaszewski :
> > This series implements devm_kstrdup_const() together with some
> > prerequisite changes and uses it in pmc-atom driver.
> >
> > v1 -> v2:
> > - fixed the changelog in the patch implementing
> -Original Message-
> From: Dennis Gilmore
> Sent: Friday, October 12, 2018 8:39 AM
> To: Pandruvada, Srinivas
> Cc: linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org; Limonciello,
> Mario
> Subject: Re: issues with suspend on Dell XPS 13 2-in-1
>
It appears I'm being added to
> -Original Message-
> From: Dennis Gilmore
> Sent: Friday, October 12, 2018 8:39 AM
> To: Pandruvada, Srinivas
> Cc: linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org; Limonciello,
> Mario
> Subject: Re: issues with suspend on Dell XPS 13 2-in-1
>
It appears I'm being added to
+Rob
Quoting Gregory CLEMENT (2018-09-22 11:17:09)
> diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> index 4a65e4e830aa..27c840e91abe 100644
> --- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> +++
+Rob
Quoting Gregory CLEMENT (2018-09-22 11:17:09)
> diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> index 4a65e4e830aa..27c840e91abe 100644
> --- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> +++
Quoting Taniya Das (2018-10-09 23:12:27)
>
>
> On 10/10/2018 2:22 AM, Stephen Boyd wrote:
> > Quoting Taniya Das (2018-10-09 10:26:38)
> >> Hello Stephen,
> >>
> >> On 10/8/2018 8:14 AM, Stephen Boyd wrote:
> >>> Quoting Taniya Das (2018-10-04 05:02:26)
> Add support for the lpass clock
Quoting Taniya Das (2018-10-09 23:12:27)
>
>
> On 10/10/2018 2:22 AM, Stephen Boyd wrote:
> > Quoting Taniya Das (2018-10-09 10:26:38)
> >> Hello Stephen,
> >>
> >> On 10/8/2018 8:14 AM, Stephen Boyd wrote:
> >>> Quoting Taniya Das (2018-10-04 05:02:26)
> Add support for the lpass clock
On Fri, Oct 12, 2018 at 01:24:22PM -0400, Andrea Arcangeli wrote:
> Hello,
>
> On Fri, Oct 12, 2018 at 12:20:54PM -0400, Zi Yan wrote:
> > On 12 Oct 2018, at 12:09, jgli...@redhat.com wrote:
> >
> > > From: Jérôme Glisse
> > >
> > > Inside set_pmd_migration_entry() we are holding page table
On Fri, Oct 12, 2018 at 01:24:22PM -0400, Andrea Arcangeli wrote:
> Hello,
>
> On Fri, Oct 12, 2018 at 12:20:54PM -0400, Zi Yan wrote:
> > On 12 Oct 2018, at 12:09, jgli...@redhat.com wrote:
> >
> > > From: Jérôme Glisse
> > >
> > > Inside set_pmd_migration_entry() we are holding page table
On Thu, Oct 11, 2018 at 02:50:55AM +0530, Raju P.L.S.S.S.N wrote:
> Add cpu power domain support
>
> Signed-off-by: Raju P.L.S.S.S.N
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>
On Thu, Oct 11, 2018 at 02:50:55AM +0530, Raju P.L.S.S.S.N wrote:
> Add cpu power domain support
>
> Signed-off-by: Raju P.L.S.S.S.N
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>
Getting pages from ZONE_DEVICE memory needs to check the backing device's
live-ness, which is tracked in the device's dev_pagemap metadata. This
metadata is stored in a radix tree and looking it up adds measurable
software overhead.
This patch avoids repeating this relatively costly operation
Getting pages from ZONE_DEVICE memory needs to check the backing device's
live-ness, which is tracked in the device's dev_pagemap metadata. This
metadata is stored in a radix tree and looking it up adds measurable
software overhead.
This patch avoids repeating this relatively costly operation
Hi,
On 12.10.2018 19:30, Andi Kleen wrote:
>> 4. Results
>> - Without this optimization, the guest pmi handling time is
>> ~450 ns, and the max sampling rate is reduced to 250.
>> - With this optimization, the guest pmi handling time is ~9000 ns
>> (i.e. 1 / 500 of the
Hi,
On 12.10.2018 19:30, Andi Kleen wrote:
>> 4. Results
>> - Without this optimization, the guest pmi handling time is
>> ~450 ns, and the max sampling rate is reduced to 250.
>> - With this optimization, the guest pmi handling time is ~9000 ns
>> (i.e. 1 / 500 of the
Hi Nick,
So maybe I'm misunderstanding something, but the issue seems to be that
unsigned char is promoted to 'unsigned char *' by Clang and probably
unsigned int or int by gcc.
No. This is extremely well defined behavior in C. In C, integral
types are NEVER promoted to pointer to integer
Hi Nick,
So maybe I'm misunderstanding something, but the issue seems to be that
unsigned char is promoted to 'unsigned char *' by Clang and probably
unsigned int or int by gcc.
No. This is extremely well defined behavior in C. In C, integral
types are NEVER promoted to pointer to integer
201 - 300 of 1114 matches
Mail list logo
