From: Todd Poynor
Trivial typo and whitespace fixes.
Signed-off-by: Zhongze Hu
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/apex_driver.c | 2 +-
drivers/staging/gasket/gasket_core.h | 2 +-
drivers/staging/gasket/gasket_page_table.c | 2 +-
3 files changed, 3
From: Todd Poynor
Various fixes mainly from the chromium review of the gasket and apex
drivers. More to come.
Various (18):
staging: gasket: remove X86 Kconfig restriction
MAINTAINERS: Add maintainer for drivers/staging/gasket
staging: gasket: typo and whitespace cleanups
staging:
From: Todd Poynor
The gasket and apex drivers are to be used on other architectures
besides X86.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/gasket/Kconfig b/drivers/staging/gasket/Kconfig
From: Todd Poynor
g_mutex held across pci_unregister_driver() call, also held in
gasket_pci_remove(), which deadlocks.
Reported-by: Dmitry Torokhov
Signed-off-by: Zhongze Hu
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 7 ++-
1 file changed, 2 insertions(+), 5
From: Todd Poynor
Remove device registration on class creation fail.
Hold mutex around device removal updates for proper ordering of
updates.
Signed-off-by: Zhongze Hu
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 8 +++-
1 file changed, 7 insertions(+), 1
From: Todd Poynor
Various fixes mainly from the chromium review of the gasket and apex
drivers. More to come.
Various (18):
staging: gasket: remove X86 Kconfig restriction
MAINTAINERS: Add maintainer for drivers/staging/gasket
staging: gasket: typo and whitespace cleanups
staging:
From: Todd Poynor
The gasket and apex drivers are to be used on other architectures
besides X86.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/gasket/Kconfig b/drivers/staging/gasket/Kconfig
From: Todd Poynor
g_mutex held across pci_unregister_driver() call, also held in
gasket_pci_remove(), which deadlocks.
Reported-by: Dmitry Torokhov
Signed-off-by: Zhongze Hu
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 7 ++-
1 file changed, 2 insertions(+), 5
From: Todd Poynor
Remove device registration on class creation fail.
Hold mutex around device removal updates for proper ordering of
updates.
Signed-off-by: Zhongze Hu
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 8 +++-
1 file changed, 7 insertions(+), 1
From: Todd Poynor
Trivial typo and whitespace fixes.
Signed-off-by: Zhongze Hu
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/apex_driver.c | 2 +-
drivers/staging/gasket/gasket_core.h | 2 +-
drivers/staging/gasket/gasket_page_table.c | 2 +-
3 files changed, 3
From: Todd Poynor
Todd Poynor will be a maintainer of the Gasket
and Apex drivers.
Signed-off-by: Todd Poynor
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 562ee1e1cfd6..8f44e7bed49e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5968,6
From: Todd Poynor
Todd Poynor will be a maintainer of the Gasket
and Apex drivers.
Signed-off-by: Todd Poynor
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 562ee1e1cfd6..8f44e7bed49e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5968,6
From: Todd Poynor
Remove unnecessary variable.
Bail out if no physical device.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/gasket/gasket_core.c
From: Todd Poynor
Cleanups to error codes, code style, error conditions, etc.
Reported-by: Guenter Roeck
Signed-off-by: Simon Que
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/apex.h | 7 ++-
drivers/staging/gasket/apex_driver.c | 50 -
From: Todd Poynor
Always allow root to open device for writing.
Drop special-casing of ioctl permissions for root vs. owner.
Reported-by: Dmitry Torokhov
Signed-off-by: Zhongze Hu
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/apex_driver.c | 9 +++--
From: Todd Poynor
gasket_mmap_has_permissions() should return a boolean value.
Signed-off-by: Zhongze Hu
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/gasket/gasket_core.c
From: Todd Poynor
If device reset callback returns an error, error out at the gasket
level.
Reported-by: Dmitry Torokhov
Signed-off-by: Zhongze Hu
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
From: Todd Poynor
Remove extraneous statement in gasket_config_coherent_allocator()
Reported-by: Dmitry Torokhov
Signed-off-by: Zhongze Hu
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_ioctl.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git
From: Todd Poynor
For sparse checking.
Reported-by: Dmitry Torokhov
Signed-off-by: Zhongze Hu
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/apex_driver.c | 12 ++---
drivers/staging/gasket/gasket_core.c | 6 ++-
drivers/staging/gasket/gasket_core.h | 4 +-
From: Todd Poynor
Remove unnecessary variable.
Bail out if no physical device.
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/gasket/gasket_core.c
From: Todd Poynor
Cleanups to error codes, code style, error conditions, etc.
Reported-by: Guenter Roeck
Signed-off-by: Simon Que
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/apex.h | 7 ++-
drivers/staging/gasket/apex_driver.c | 50 -
From: Todd Poynor
Always allow root to open device for writing.
Drop special-casing of ioctl permissions for root vs. owner.
Reported-by: Dmitry Torokhov
Signed-off-by: Zhongze Hu
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/apex_driver.c | 9 +++--
From: Todd Poynor
gasket_mmap_has_permissions() should return a boolean value.
Signed-off-by: Zhongze Hu
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/gasket/gasket_core.c
From: Todd Poynor
If device reset callback returns an error, error out at the gasket
level.
Reported-by: Dmitry Torokhov
Signed-off-by: Zhongze Hu
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
From: Todd Poynor
Remove extraneous statement in gasket_config_coherent_allocator()
Reported-by: Dmitry Torokhov
Signed-off-by: Zhongze Hu
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_ioctl.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git
From: Todd Poynor
For sparse checking.
Reported-by: Dmitry Torokhov
Signed-off-by: Zhongze Hu
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/apex_driver.c | 12 ++---
drivers/staging/gasket/gasket_core.c | 6 ++-
drivers/staging/gasket/gasket_core.h | 4 +-
From: Todd Poynor
Minor fixups to error codes and error handling in gasket core.
No device reset callback registered is not an error condition.
Signed-off-by: Simon Que
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 13 +
1 file changed, 5 insertions(+), 8
From: Todd Poynor
coherent address mappings aren't backed by a struct page, don't need to
be released, and don't count as an active page in the page table
bookkeeping.
Signed-off-by: Simon Que
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_page_table.c | 2 +-
1 file changed, 1
From: Todd Poynor
Minor fixups to error codes and error handling in gasket core.
No device reset callback registered is not an error condition.
Signed-off-by: Simon Que
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 13 +
1 file changed, 5 insertions(+), 8
From: Todd Poynor
coherent address mappings aren't backed by a struct page, don't need to
be released, and don't count as an active page in the page table
bookkeeping.
Signed-off-by: Simon Que
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_page_table.c | 2 +-
1 file changed, 1
On Fri, Jul 13, 2018 at 04:31:02PM -0700, Andy Lutomirski wrote:
> What you're really doing is keeping it available for an extra flag.
> Please update the comment as such. But see below.
Thanks, will do.
> > +.macro PARANOID_EXIT_TO_KERNEL_MODE
> > +
> > + /*
> > +* Test if we
On Fri, Jul 13, 2018 at 04:31:02PM -0700, Andy Lutomirski wrote:
> What you're really doing is keeping it available for an extra flag.
> Please update the comment as such. But see below.
Thanks, will do.
> > +.macro PARANOID_EXIT_TO_KERNEL_MODE
> > +
> > + /*
> > +* Test if we
On Fri, Jul 13, 2018 at 10:28:50AM -0700, Andy Lutomirski wrote:
> On Wed, Jul 11, 2018 at 4:29 AM, Joerg Roedel wrote:
> > From: Joerg Roedel
> >
> > Add a config option that enabled code to check that we enter
> > and leave the kernel with the correct cr3. This is needed
> > because we have no
On Fri, Jul 13, 2018 at 10:28:50AM -0700, Andy Lutomirski wrote:
> On Wed, Jul 11, 2018 at 4:29 AM, Joerg Roedel wrote:
> > From: Joerg Roedel
> >
> > Add a config option that enabled code to check that we enter
> > and leave the kernel with the correct cr3. This is needed
> > because we have no
On Fri, Jul 13, 2018 at 11:59:44AM -0700, Andy Lutomirski wrote:
> On Wed, Jul 11, 2018 at 4:29 AM, Joerg Roedel wrote:
> > From: Joerg Roedel
> >
> > Warn the user in case the performance can be significantly
> > improved by switching to a 64-bit kernel.
>
> ...
>
> > +#ifdef CONFIG_X86_32
>
On Fri, Jul 13, 2018 at 11:59:44AM -0700, Andy Lutomirski wrote:
> On Wed, Jul 11, 2018 at 4:29 AM, Joerg Roedel wrote:
> > From: Joerg Roedel
> >
> > Warn the user in case the performance can be significantly
> > improved by switching to a 64-bit kernel.
>
> ...
>
> > +#ifdef CONFIG_X86_32
>
On Fri, Jul 13, 2018 at 04:21:45PM -0700, Andy Lutomirski wrote:
> On Wed, Jul 11, 2018 at 4:29 AM, Joerg Roedel wrote:
> > From: Joerg Roedel
> >
> > The mapping for entry-text might have changed in the kernel
> > after it was cloned to the user page-table. Clone again
> > to update the user
On Fri, Jul 13, 2018 at 04:21:45PM -0700, Andy Lutomirski wrote:
> On Wed, Jul 11, 2018 at 4:29 AM, Joerg Roedel wrote:
> > From: Joerg Roedel
> >
> > The mapping for entry-text might have changed in the kernel
> > after it was cloned to the user page-table. Clone again
> > to update the user
On Fri, Jul 13, 2018 at 1:55 PM, Andrew Morton
wrote:
> On Thu, 12 Jul 2018 11:33:33 -0500 ebied...@xmission.com (Eric W. Biederman)
> wrote:
>> What is the value of disabling this functionality ever?
>>
>> Is there any reason why we don't just delete CONFIG_CHECKPOINT_RESTORE
>> entirely?
>
>
On Fri, Jul 13, 2018 at 1:55 PM, Andrew Morton
wrote:
> On Thu, 12 Jul 2018 11:33:33 -0500 ebied...@xmission.com (Eric W. Biederman)
> wrote:
>> What is the value of disabling this functionality ever?
>>
>> Is there any reason why we don't just delete CONFIG_CHECKPOINT_RESTORE
>> entirely?
>
>
On 07/12/2018 12:59 PM, Kees Cook wrote:
> Looks like the adjusted syntax wasn't fully build tested. This fixes
> failures with powerpc builds:
>
> drivers/mmc/host/mxcmmc.c: In function ‘mxcmci_swap_buffers’:
> drivers/mmc/host/mxcmmc.c:296:51: error: expected ‘)’ before ‘;’ token
>void *buf
On 07/12/2018 12:59 PM, Kees Cook wrote:
> Looks like the adjusted syntax wasn't fully build tested. This fixes
> failures with powerpc builds:
>
> drivers/mmc/host/mxcmmc.c: In function ‘mxcmci_swap_buffers’:
> drivers/mmc/host/mxcmmc.c:296:51: error: expected ‘)’ before ‘;’ token
>void *buf
Dave Hansen writes:
>> +/*
>> + * At most times, fine grained cluster lock is sufficient to protect
>
> Can we call out those times, please?
To protect si->swap_map[], if HDD, si->lock is used, otherwise cluster
lock is used. "at most times" is ambiguous here, I will fix it.
>> + * the
Dave Hansen writes:
>> +/*
>> + * At most times, fine grained cluster lock is sufficient to protect
>
> Can we call out those times, please?
To protect si->swap_map[], if HDD, si->lock is used, otherwise cluster
lock is used. "at most times" is ambiguous here, I will fix it.
>> + * the
Hi Amit,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on agross/for-next]
[also build test ERROR on v4.18-rc4 next-20180713]
[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
Hi Amit,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on agross/for-next]
[also build test ERROR on v4.18-rc4 next-20180713]
[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
On Fri, Jul 13, 2018 at 6:51 PM Alan Stern wrote:
>
> The point being that the scenarios under discussion in this thread all
> fall most definitely into the "Non-standard usage; you'd better know
> exactly what you're doing" category.
Well, yes and no.
The thing is, people expected unlock+lock
On Fri, Jul 13, 2018 at 6:51 PM Alan Stern wrote:
>
> The point being that the scenarios under discussion in this thread all
> fall most definitely into the "Non-standard usage; you'd better know
> exactly what you're doing" category.
Well, yes and no.
The thing is, people expected unlock+lock
Hi all,
On Fri, 13 Jul 2018 18:41:40 -0700 Randy Dunlap wrote:
>
> On 07/13/2018 04:51 PM, a...@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2018-07-13-16-51 has been uploaded to
> >
> >http://www.ozlabs.org/~akpm/mmotm/
> >
> > mmotm-readme.txt says
> >
> > README for
Hi all,
On Fri, 13 Jul 2018 18:41:40 -0700 Randy Dunlap wrote:
>
> On 07/13/2018 04:51 PM, a...@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2018-07-13-16-51 has been uploaded to
> >
> >http://www.ozlabs.org/~akpm/mmotm/
> >
> > mmotm-readme.txt says
> >
> > README for
Hi Jacek,
On 14 July 2018 at 04:07, Jacek Anaszewski wrote:
> Hi Baolin,
>
> Thank you for the update.
>
>
> On 07/13/2018 08:21 AM, Baolin Wang wrote:
>>
>> From: Bjorn Andersson
>>
>> Some LED controllers have support for autonomously controlling
>> brightness over time, according to some
Hi Jacek,
On 14 July 2018 at 04:07, Jacek Anaszewski wrote:
> Hi Baolin,
>
> Thank you for the update.
>
>
> On 07/13/2018 08:21 AM, Baolin Wang wrote:
>>
>> From: Bjorn Andersson
>>
>> Some LED controllers have support for autonomously controlling
>> brightness over time, according to some
We disabled CPUID-based TSC calibration on SKX in December for several reasons.
If you still have it enabled, you need this patch:
commit b511203093489eb1829cb4de86e8214752205ac6
x86/tsc: Fix erroneous TSC rate on Skylake Xeon
If you are referring to another platform that has CPUID-TSC
We disabled CPUID-based TSC calibration on SKX in December for several reasons.
If you still have it enabled, you need this patch:
commit b511203093489eb1829cb4de86e8214752205ac6
x86/tsc: Fix erroneous TSC rate on Skylake Xeon
If you are referring to another platform that has CPUID-TSC
I'm not at all convinced that this is the problem, but the series here
will give a better diagnostic if the issue really is an IRQ stack
overflow:
https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/guard_pages
(link currently broken. should work soon.)
I'm not at all convinced that this is the problem, but the series here
will give a better diagnostic if the issue really is an IRQ stack
overflow:
https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/guard_pages
(link currently broken. should work soon.)
On i.MX6SL EVK board, the MX6SL_PAD_KEY_ROW5 pin is
used as lcd 3v3 regulator control pin, need to make
sure MX6SL_PAD_KEY_ROW5 is muxed as GPIO function
for controlling lcd 3v3 regulator.
Signed-off-by: Anson Huang
---
change since V1:
using a separate pin group for lcd regulator
On i.MX6SL EVK board, the MX6SL_PAD_KEY_ROW5 pin is
used as lcd 3v3 regulator control pin, need to make
sure MX6SL_PAD_KEY_ROW5 is muxed as GPIO function
for controlling lcd 3v3 regulator.
Signed-off-by: Anson Huang
---
change since V1:
using a separate pin group for lcd regulator
Hi, Fabio
Anson Huang
Best Regards!
> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: Saturday, July 14, 2018 2:34 AM
> To: Anson Huang
> Cc: Linus Walleij ; open list:GPIO SUBSYSTEM
> ; linux-kernel ;
> dl-linux-imx
> Subject: Re: [PATCH] gpio: mxc: add
Hi, Fabio
Anson Huang
Best Regards!
> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: Saturday, July 14, 2018 2:34 AM
> To: Anson Huang
> Cc: Linus Walleij ; open list:GPIO SUBSYSTEM
> ; linux-kernel ;
> dl-linux-imx
> Subject: Re: [PATCH] gpio: mxc: add
On Fri, 13 Jul 2018, Andrea Parri wrote:
> On Fri, Jul 13, 2018 at 10:16:48AM -0700, Linus Torvalds wrote:
> > On Fri, Jul 13, 2018 at 2:34 AM Will Deacon wrote:
> > >
> > > And, since we're stating preferences, I'll reiterate my preference
> > > towards:
> > >
> > > * RCsc unlock/lock
On Fri, 13 Jul 2018, Andrea Parri wrote:
> On Fri, Jul 13, 2018 at 10:16:48AM -0700, Linus Torvalds wrote:
> > On Fri, Jul 13, 2018 at 2:34 AM Will Deacon wrote:
> > >
> > > And, since we're stating preferences, I'll reiterate my preference
> > > towards:
> > >
> > > * RCsc unlock/lock
Introduce bindings for RPMh regulator devices found on some
Qualcomm Technlogies, Inc. SoCs. These devices allow a given
processor within the SoC to make PMIC regulator requests which
are aggregated within the RPMh hardware block along with requests
from other processors in the SoC to determine
Add the QCOM RPMh regulator driver to manage PMIC regulators
which are controlled via RPMh on some Qualcomm Technologies, Inc.
SoCs. RPMh is a hardware block which contains several
accelerators which are used to manage various hardware resources
that are shared between the processors of the SoC.
This patch series adds a driver and device tree binding documentation for
PMIC regulator control via Resource Power Manager-hardened (RPMh) on some
Qualcomm Technologies, Inc. SoCs such as SDM845. RPMh is a hardware block
which contains several accelerators which are used to manage various
Introduce bindings for RPMh regulator devices found on some
Qualcomm Technlogies, Inc. SoCs. These devices allow a given
processor within the SoC to make PMIC regulator requests which
are aggregated within the RPMh hardware block along with requests
from other processors in the SoC to determine
Add the QCOM RPMh regulator driver to manage PMIC regulators
which are controlled via RPMh on some Qualcomm Technologies, Inc.
SoCs. RPMh is a hardware block which contains several
accelerators which are used to manage various hardware resources
that are shared between the processors of the SoC.
This patch series adds a driver and device tree binding documentation for
PMIC regulator control via Resource Power Manager-hardened (RPMh) on some
Qualcomm Technologies, Inc. SoCs such as SDM845. RPMh is a hardware block
which contains several accelerators which are used to manage various
On 07/13/2018 04:51 PM, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2018-07-13-16-51 has been uploaded to
>
>http://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of
On 07/13/2018 04:51 PM, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2018-07-13-16-51 has been uploaded to
>
>http://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of
Hi Amit,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on agross/for-next]
[also build test ERROR on v4.18-rc4 next-20180713]
[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
Hi Amit,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on agross/for-next]
[also build test ERROR on v4.18-rc4 next-20180713]
[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
On 07/13/2018 06:51 PM, Thomas Gleixner wrote:
> On Wed, 11 Jul 2018, Pavel Tatashin wrote:
>
>>> So this still will have some overhead when kvmclock is not in use, but
>>> bringing it down to zero would be a massive trainwreck and even more
>>> indirections.
>>
>> Hi Thomas,
>>
>> In my
On 07/13/2018 06:51 PM, Thomas Gleixner wrote:
> On Wed, 11 Jul 2018, Pavel Tatashin wrote:
>
>>> So this still will have some overhead when kvmclock is not in use, but
>>> bringing it down to zero would be a massive trainwreck and even more
>>> indirections.
>>
>> Hi Thomas,
>>
>> In my
On Fri, 2018-07-13 at 14:51 -0400, Don Zickus wrote:
> On Fri, Jul 06, 2018 at 03:14:28PM -0700, Joe Perches wrote:
> > On Fri, 2018-07-06 at 15:09 -0700, Joe Perches wrote:
> > > On Fri, 2018-07-06 at 17:58 -0400, Don Zickus wrote:
> > > > We have an internal use case of multiple MAINTAINER
On Fri, 2018-07-13 at 14:51 -0400, Don Zickus wrote:
> On Fri, Jul 06, 2018 at 03:14:28PM -0700, Joe Perches wrote:
> > On Fri, 2018-07-06 at 15:09 -0700, Joe Perches wrote:
> > > On Fri, 2018-07-06 at 17:58 -0400, Don Zickus wrote:
> > > > We have an internal use case of multiple MAINTAINER
On Fri, 2018-07-13 at 16:28 -0700, pher...@codeaurora.org wrote:
> On 2018-07-13 14:46, Joe Perches wrote:
> > On Fri, 2018-07-13 at 14:40 -0700, Prakruthi Deepak Heragu wrote:
> > > Commit text is almost always necessary to explain why a change is
> > > needed.
> >
> > This bit seems sensible,
On Fri, 2018-07-13 at 16:28 -0700, pher...@codeaurora.org wrote:
> On 2018-07-13 14:46, Joe Perches wrote:
> > On Fri, 2018-07-13 at 14:40 -0700, Prakruthi Deepak Heragu wrote:
> > > Commit text is almost always necessary to explain why a change is
> > > needed.
> >
> > This bit seems sensible,
The mm-of-the-moment snapshot 2018-07-13-16-51 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
The mm-of-the-moment snapshot 2018-07-13-16-51 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
When a CX5 device is configured in dual-port RoCE mode, after creating
many VFs against port 1, creating the same number of VFs against port 2
will flood kernel/syslog with something like
"mlx5_*:mlx5_ib_bind_slave_port:4266:(pid 5269): port 2 already
affiliated."
So basically, when traversing
When a CX5 device is configured in dual-port RoCE mode, after creating
many VFs against port 1, creating the same number of VFs against port 2
will flood kernel/syslog with something like
"mlx5_*:mlx5_ib_bind_slave_port:4266:(pid 5269): port 2 already
affiliated."
So basically, when traversing
On Fri, Jul 13, 2018 at 3:49 PM, Johannes Weiner wrote:
> On Fri, Jul 13, 2018 at 03:13:07PM -0700, Suren Baghdasaryan wrote:
>> On Thu, Jul 12, 2018 at 10:29 AM, Johannes Weiner wrote:
>> > might want to know about and react to stall states before they have
>> > even concluded (e.g. a prolonged
On Fri, Jul 13, 2018 at 3:49 PM, Johannes Weiner wrote:
> On Fri, Jul 13, 2018 at 03:13:07PM -0700, Suren Baghdasaryan wrote:
>> On Thu, Jul 12, 2018 at 10:29 AM, Johannes Weiner wrote:
>> > might want to know about and react to stall states before they have
>> > even concluded (e.g. a prolonged
On Wed, Jul 11, 2018 at 4:29 AM, 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
On Wed, Jul 11, 2018 at 4:29 AM, 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
On 2018-07-13 14:46, Joe Perches wrote:
On Fri, 2018-07-13 at 14:40 -0700, Prakruthi Deepak Heragu wrote:
Commit text is almost always necessary to explain why a change is
needed.
This bit seems sensible, but perhaps it should just count the
number of lines after the end of email headers and
On 2018-07-13 14:46, Joe Perches wrote:
On Fri, 2018-07-13 at 14:40 -0700, Prakruthi Deepak Heragu wrote:
Commit text is almost always necessary to explain why a change is
needed.
This bit seems sensible, but perhaps it should just count the
number of lines after the end of email headers and
On Wed, Jul 11, 2018 at 4:29 AM, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Mapping the kernel text area to user-space makes only sense
> if it has the same permissions as in the kernel page-table.
> If permissions are different this will cause a TLB reload
> when using the kernel page-table,
On Wed, Jul 11, 2018 at 4:29 AM, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Mapping the kernel text area to user-space makes only sense
> if it has the same permissions as in the kernel page-table.
> If permissions are different this will cause a TLB reload
> when using the kernel page-table,
On Wed, Jul 11, 2018 at 4:29 AM, Joerg Roedel wrote:
> From: Joerg Roedel
>
> The mapping for entry-text might have changed in the kernel
> after it was cloned to the user page-table. Clone again
> to update the user page-table to bring the mapping in sync
> with the kernel again.
Can't we just
On Wed, Jul 11, 2018 at 4:29 AM, Joerg Roedel wrote:
> From: Joerg Roedel
>
> The mapping for entry-text might have changed in the kernel
> after it was cloned to the user page-table. Clone again
> to update the user page-table to bring the mapping in sync
> with the kernel again.
Can't we just
On Wed, Jul 11, 2018 at 4:29 AM, Joerg Roedel wrote:
> From: Joerg Roedel
>
> This splits out the mapping sanity check and the actual
> mapping of the LDT to user-space from the map_ldt_struct()
> function in a way so that it is re-usable for PAE paging.
>
Reviewed-by: Andy Lutomirski
On Wed, Jul 11, 2018 at 4:29 AM, Joerg Roedel wrote:
> From: Joerg Roedel
>
> This splits out the mapping sanity check and the actual
> mapping of the LDT to user-space from the map_ldt_struct()
> function in a way so that it is re-usable for PAE paging.
>
Reviewed-by: Andy Lutomirski
On Fri, Jul 13, 2018 at 10:19 AM, Andy Lutomirski wrote:
> On Fri, Jul 13, 2018 at 2:48 AM, Joerg Roedel wrote:
>> On Thu, Jul 12, 2018 at 01:49:13PM -0700, Andy Lutomirski wrote:
>>> > On Jul 11, 2018, at 4:29 AM, Joerg Roedel wrote:
>>> >/* Offset from the sysenter stack to tss.sp0 */
>>>
On Fri, Jul 13, 2018 at 10:19 AM, Andy Lutomirski wrote:
> On Fri, Jul 13, 2018 at 2:48 AM, Joerg Roedel wrote:
>> On Thu, Jul 12, 2018 at 01:49:13PM -0700, Andy Lutomirski wrote:
>>> > On Jul 11, 2018, at 4:29 AM, Joerg Roedel wrote:
>>> >/* Offset from the sysenter stack to tss.sp0 */
>>>
With the current implementation of the cgroup-aware oom killer,
memory.oom_group defines two behaviors:
- consider the footprint of the "group" consisting of the mem cgroup
itself and all descendants for comparison with other cgroups, and
- when selected as the victim mem cgroup, kill all
One of the three significant concerns brought up about the cgroup aware
oom killer is that its decisionmaking is completely evaded by creating
subcontainers and attaching processes such that the ancestor's usage does
not exceed another cgroup on the system.
Consider the example from the previous
and extends
it to be generally useful outside of very specialized usecases.
It eliminates the mount option for the cgroup aware oom killer entirely
since it is now enabled through the root mem cgroup's oom policy.
---
v3:
- Rebased to next-20180713
v2:
- Rebased to next-20180322
- Fixed
Now that each mem cgroup on the system has a memory.oom_policy tunable to
specify oom kill selection behavior, remove the needless "groupoom" mount
option that requires (1) the entire system to be forced, perhaps
unnecessarily, perhaps unexpectedly, into a single oom policy that
differs from the
1 - 100 of 944 matches
Mail list logo
