Use the gpiod interface instead of the deprecated
old non-descriptor interface.
Signed-off-by: Nishad Kamdar
---
Changes in v2:
- Move comment to the same line as to what it applies to.
---
drivers/staging/greybus/arche-platform.c | 119 ---
1 file changed, 41
Use the gpiod interface instead of the deprecated
old non-descriptor interface.
Signed-off-by: Nishad Kamdar
---
Changes in v2:
- Move comment to the same line as to what it applies to.
---
drivers/staging/greybus/arche-platform.c | 119 ---
1 file changed, 41
On Fri, Nov 16, 2018 at 05:06:22PM +0100, Johan Hovold wrote:
> On Fri, Nov 16, 2018 at 08:47:44PM +0530, Nishad Kamdar wrote:
> > Use the gpiod interface instead of the deprecated
> > old non-descriptor interface.
> >
> > Signed-off-by: Nishad Kamdar
> > ---
>
> Always include a change log
On Fri, Nov 16, 2018 at 05:06:22PM +0100, Johan Hovold wrote:
> On Fri, Nov 16, 2018 at 08:47:44PM +0530, Nishad Kamdar wrote:
> > Use the gpiod interface instead of the deprecated
> > old non-descriptor interface.
> >
> > Signed-off-by: Nishad Kamdar
> > ---
>
> Always include a change log
On 11/16/18 at 10:14am, Michal Hocko wrote:
> Could you try to apply this debugging patch on top please? It will dump
> stack trace for each reference count elevation for one page that fails
> to migrate after multiple passes.
Thanks, applied and fixed two code issues. The dmesg has been sent to
On 11/16/18 at 10:14am, Michal Hocko wrote:
> Could you try to apply this debugging patch on top please? It will dump
> stack trace for each reference count elevation for one page that fails
> to migrate after multiple passes.
Thanks, applied and fixed two code issues. The dmesg has been sent to
The compiler has no way to know that rsize 1 or 2 are the only valid
values. Also simplify the code a bit with early return.
The warning was:
drivers/spi/spi-npcm-pspi.c:215:6: warning: 'val' may be used uninitialized in
this function [-Wmaybe-uninitialized]
Signed-off-by: Olof Johansson
---
The compiler has no way to know that rsize 1 or 2 are the only valid
values. Also simplify the code a bit with early return.
The warning was:
drivers/spi/spi-npcm-pspi.c:215:6: warning: 'val' may be used uninitialized in
this function [-Wmaybe-uninitialized]
Signed-off-by: Olof Johansson
---
PAGE_READ is used by RISC-V arch code included through mm headers,
and it makes sense to bring in a prefix on these in the driver.
drivers/mtd/nand/raw/qcom_nandc.c:153: warning: "PAGE_READ" redefined
#define PAGE_READ 0x2
In file included from include/linux/memremap.h:7,
from
PAGE_READ is used by RISC-V arch code included through mm headers,
and it makes sense to bring in a prefix on these in the driver.
drivers/mtd/nand/raw/qcom_nandc.c:153: warning: "PAGE_READ" redefined
#define PAGE_READ 0x2
In file included from include/linux/memremap.h:7,
from
On Sat, Nov 17, 2018 at 2:43 AM Palmer Dabbelt wrote:
>
> On Sun, 11 Nov 2018 21:55:15 PST (-0800), a...@brainfault.org wrote:
> > This patch extends Linux RISC-V build system to build and install:
> > Image - Flat uncompressed kernel image
> > Image.gz - Flat and GZip compressed kernel image
> >
On Sat, Nov 17, 2018 at 2:43 AM Palmer Dabbelt wrote:
>
> On Sun, 11 Nov 2018 21:55:15 PST (-0800), a...@brainfault.org wrote:
> > This patch extends Linux RISC-V build system to build and install:
> > Image - Flat uncompressed kernel image
> > Image.gz - Flat and GZip compressed kernel image
> >
On Sun, Nov 11, 2018 at 9:48 AM Jonathan Cameron wrote:
>
> On Fri, 9 Nov 2018 20:00:42 -0200
> Matheus Tavares wrote:
>
> > This patch adds the device tree binding documentation for the ad2s90
> > resolver-to-digital converter.
> >
> > Signed-off-by: Matheus Tavares
> > ---
> >
The patch
ASoC: rt5663: Add documentation for power supply support
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours)
The patch
spi: pxa2xx: Fix '"CONFIG_OF" is not defined' warning
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
On Sun, Nov 11, 2018 at 9:48 AM Jonathan Cameron wrote:
>
> On Fri, 9 Nov 2018 20:00:42 -0200
> Matheus Tavares wrote:
>
> > This patch adds the device tree binding documentation for the ad2s90
> > resolver-to-digital converter.
> >
> > Signed-off-by: Matheus Tavares
> > ---
> >
The patch
ASoC: rt5663: Add documentation for power supply support
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours)
The patch
spi: pxa2xx: Fix '"CONFIG_OF" is not defined' warning
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
The patch
ASoC: tlv320dac33: clean up indentation, remove extraneous tab
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
ASoC: arizona: fix indentation issue with return statement
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
ASoC: tlv320aic31xx: asihpi: clean up indentation, remove extraneous tab
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in
The patch
ASoC: tlv320dac33: clean up indentation, remove extraneous tab
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
ASoC: arizona: fix indentation issue with return statement
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
ASoC: tlv320aic31xx: asihpi: clean up indentation, remove extraneous tab
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in
The patch
ASoC: amd: fix spelling mistake "Inavlid" -> "Invalid"
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours)
The patch
ASoC: rt5663: Fix error handling of regulator_set_load
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours)
The patch
ASoC: qcom: clean up indentation, remove extraneous tab
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours)
The patch
ASoC: amd: fix spelling mistake "Inavlid" -> "Invalid"
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours)
The patch
ASoC: rt5663: Fix error handling of regulator_set_load
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours)
The patch
ASoC: qcom: clean up indentation, remove extraneous tab
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours)
The stub implementation of _set_load() returns a mode value which is
within the bounds of valid return codes for success (the documentation
just says that failures are negative error codes) but not sensible or
what the actual implementation does. Fix it to just return 0.
Reported-by: Cheng-Yi
The stub implementation of _set_load() returns a mode value which is
within the bounds of valid return codes for success (the documentation
just says that failures are negative error codes) but not sensible or
what the actual implementation does. Fix it to just return 0.
Reported-by: Cheng-Yi
On Fri, Nov 16, 2018 at 05:28:56PM +0800, Cheng-Yi Chiang wrote:
> The default implementation of regulator_set_load returns
> REGULATOR_MODE_NORMAL, which is positive.
The stub does indeed do that however that just looks like a bug - the
actual implementation returns 0 on success and the other
On Fri, Nov 16, 2018 at 05:28:56PM +0800, Cheng-Yi Chiang wrote:
> The default implementation of regulator_set_load returns
> REGULATOR_MODE_NORMAL, which is positive.
The stub does indeed do that however that just looks like a bug - the
actual implementation returns 0 on success and the other
On Fri, Nov 16, 2018 at 10:45:22PM +0800, Shawn Guo wrote:
> On Fri, Nov 16, 2018 at 11:25:07AM +0100, Clément Péron wrote:
> > It's still quite new for me to submit patch, but if this patch should
> > be sent to ASoC maintainer maybe there is a line missing in the
> > MAINTAINERS file no ?
>
On Fri, Nov 16, 2018 at 10:45:22PM +0800, Shawn Guo wrote:
> On Fri, Nov 16, 2018 at 11:25:07AM +0100, Clément Péron wrote:
> > It's still quite new for me to submit patch, but if this patch should
> > be sent to ASoC maintainer maybe there is a line missing in the
> > MAINTAINERS file no ?
>
On Thu, Nov 8, 2018 at 11:32 AM Palmer Dabbelt wrote:
>
> On Thu, 08 Nov 2018 11:07:00 PST (-0800), david.abdurachma...@gmail.com wrote:
> > Fixes warning: 'struct module' declared inside parameter list will not be
> > visible outside of this definition or declaration
> >
> > Signed-off-by: David
On Thu, Nov 8, 2018 at 11:32 AM Palmer Dabbelt wrote:
>
> On Thu, 08 Nov 2018 11:07:00 PST (-0800), david.abdurachma...@gmail.com wrote:
> > Fixes warning: 'struct module' declared inside parameter list will not be
> > visible outside of this definition or declaration
> >
> > Signed-off-by: David
Hi Finn,
Am 17.11.2018 um 11:49 schrieb Finn Thain:
On Fri, 16 Nov 2018, Russell King - ARM Linux wrote:
The EBSA110 is probably in a similar boat - I don't remember whether it
had 16MB or 32MB as the maximal amount of memory, but memory was getting
tight with some kernels even running a
Hi Finn,
Am 17.11.2018 um 11:49 schrieb Finn Thain:
On Fri, 16 Nov 2018, Russell King - ARM Linux wrote:
The EBSA110 is probably in a similar boat - I don't remember whether it
had 16MB or 32MB as the maximal amount of memory, but memory was getting
tight with some kernels even running a
On Fri, Nov 16, 2018 at 6:27 PM Will Deacon wrote:
>
> Hi Olof,
>
> On Fri, Nov 16, 2018 at 05:54:56PM -0800, Olof Johansson wrote:
> > Makes sparse happy. Before:
> >
> > arch/arm64/include/asm/sysreg.h:471:42: warning: constant
> > 0x is so big it is unsigned long
> >
On Fri, Nov 16, 2018 at 6:27 PM Will Deacon wrote:
>
> Hi Olof,
>
> On Fri, Nov 16, 2018 at 05:54:56PM -0800, Olof Johansson wrote:
> > Makes sparse happy. Before:
> >
> > arch/arm64/include/asm/sysreg.h:471:42: warning: constant
> > 0x is so big it is unsigned long
> >
On Fri, Nov 16, 2018 at 05:33:35PM -0800, Wengang Wang wrote:
>The this_cpu_cmpxchg makes the do-while loop pass as long as the
>s->cpu_slab->partial as the same value. It doesn't care what happened to
>that slab. Interrupt is not disabled, and new alloc/free can happen in the
>interrupt handlers.
On Fri, Nov 16, 2018 at 05:33:35PM -0800, Wengang Wang wrote:
>The this_cpu_cmpxchg makes the do-while loop pass as long as the
>s->cpu_slab->partial as the same value. It doesn't care what happened to
>that slab. Interrupt is not disabled, and new alloc/free can happen in the
>interrupt handlers.
On Mon, Nov 12, 2018 at 1:27 PM Robert Deal
wrote:
>
> Reformat arguments in a few functions in gasket_page_table.c to better
> follow linux kernel formatting standards.
>
> Signed-off-by: Robert Deal
> ---
> drivers/staging/gasket/gasket_page_table.c | 24 ++
> 1 file
On Mon, Nov 12, 2018 at 1:27 PM Robert Deal
wrote:
>
> Reformat arguments in a few functions in gasket_page_table.c to better
> follow linux kernel formatting standards.
>
> Signed-off-by: Robert Deal
> ---
> drivers/staging/gasket/gasket_page_table.c | 24 ++
> 1 file
On Thu, Nov 8, 2018 at 11:02 AM David Abdurachmanov
wrote:
>
> Marcin Juszkiewicz reported issues while generating syscall table for riscv
> using 4.20-rc1. The patch refactors our unistd.h files to match some other
> architectures.
>
> - Add asm/unistd.h UAPI header, which has
On Thu, Nov 8, 2018 at 11:02 AM David Abdurachmanov
wrote:
>
> Marcin Juszkiewicz reported issues while generating syscall table for riscv
> using 4.20-rc1. The patch refactors our unistd.h files to match some other
> architectures.
>
> - Add asm/unistd.h UAPI header, which has
The checks to cpu_smt_control outside of kernel/cpu.c can be converted
to use cpu_smt_enabled key to run SMT specific code.
Save the export of cpu_smt_control and convert usage of cpu_smt_control
to cpu_smt_enabled outside of kernel/cpu.c.
Signed-off-by: Tim Chen
---
arch/x86/kernel/cpu/bugs.c
The checks to cpu_smt_control outside of kernel/cpu.c can be converted
to use cpu_smt_enabled key to run SMT specific code.
Save the export of cpu_smt_control and convert usage of cpu_smt_control
to cpu_smt_enabled outside of kernel/cpu.c.
Signed-off-by: Tim Chen
---
arch/x86/kernel/cpu/bugs.c
In later code, STIBP will be turned on/off in the context switch code
path when SMT is enabled. Checks for SMT is best
avoided on such hot paths.
Create cpu_smt_enabled static key to turn on such SMT specific code
statically.
This key is set in code under hot plug, so it is limited in
scope to
STIBP is not needed when enhanced IBRS is used for Spectre V2 mitigation.
A CPU feature flag to indicate that enhanced IBRS is used will be handy
for skipping STIBP for this case.
Add X86_FEATURE_USE_IBRS_ENHANCED feature bit to indicate
enhanced IBRS is used for Spectre V2 mitigation.
STIBP is not needed when enhanced IBRS is used for Spectre V2 mitigation.
A CPU feature flag to indicate that enhanced IBRS is used will be handy
for skipping STIBP for this case.
Add X86_FEATURE_USE_IBRS_ENHANCED feature bit to indicate
enhanced IBRS is used for Spectre V2 mitigation.
In later code, STIBP will be turned on/off in the context switch code
path when SMT is enabled. Checks for SMT is best
avoided on such hot paths.
Create cpu_smt_enabled static key to turn on such SMT specific code
statically.
This key is set in code under hot plug, so it is limited in
scope to
Add new protection modes for Spectre v2 mitigations against
Spectre v2 attacks on user processes. There are three modes:
strict mode:
In this mode, IBPB and STIBP are deployed full
time to protect all processes.
lite mode:
In this mode, IBPB and STIBP are
Remove unnecessary ret variable in cpu_show_common() to make the
code more concise.
Signed-off-by: Tim Chen
---
arch/x86/kernel/cpu/bugs.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 5ac7070..84e3579
If STIBP is used all the time, tasks that do not need STIBP
protection will get unnecessarily slowed down by STIBP.
To apply STIBP only to tasks that need it, a new task TIF_STIBP flag is
created. A x86 CPU uses STIBP only for tasks labeled with TIF_STIBP.
During context switch, this flag is
During context switch, the SSBD bit in SPEC_CTRL MSR is updated according
to changes in TIF_SSBD flag in the current and next running task.
Currently, only the bit controlling speculative store in SPEC_CTRL MSR
is updated and the related update functions all have "speculative_store"
or "ssb" in
Create PRCTL interface to restrict an application's indirect branch
speculation. This will protect the application against spectre v2 attack
from another application.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIR_BRANCH, 0, 0, 0);
When a task is made non-dumpable, a higher level of security is implied
implicitly as its memory is imposed with access restriction. Many
daemons touching sensitive data (e.g. sshd) make theselves non-dumpable.
Such tasks should have speculative execution restricted to protect them
from attacks
The logic to detect whether there's a change in the previous
and next task's flag relevant to update speculation control
MSRs are spread out across multiple functions.
Consolidate all checks needed for updating speculation
control MSRs to __speculation_ctrl_update().
This makes it easy to pick
Create PRCTL interface to restrict an application's indirect branch
speculation. This will protect the application against spectre v2 attack
from another application.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIR_BRANCH, 0, 0, 0);
When a task is made non-dumpable, a higher level of security is implied
implicitly as its memory is imposed with access restriction. Many
daemons touching sensitive data (e.g. sshd) make theselves non-dumpable.
Such tasks should have speculative execution restricted to protect them
from attacks
The logic to detect whether there's a change in the previous
and next task's flag relevant to update speculation control
MSRs are spread out across multiple functions.
Consolidate all checks needed for updating speculation
control MSRs to __speculation_ctrl_update().
This makes it easy to pick
Add new protection modes for Spectre v2 mitigations against
Spectre v2 attacks on user processes. There are three modes:
strict mode:
In this mode, IBPB and STIBP are deployed full
time to protect all processes.
lite mode:
In this mode, IBPB and STIBP are
Remove unnecessary ret variable in cpu_show_common() to make the
code more concise.
Signed-off-by: Tim Chen
---
arch/x86/kernel/cpu/bugs.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 5ac7070..84e3579
If STIBP is used all the time, tasks that do not need STIBP
protection will get unnecessarily slowed down by STIBP.
To apply STIBP only to tasks that need it, a new task TIF_STIBP flag is
created. A x86 CPU uses STIBP only for tasks labeled with TIF_STIBP.
During context switch, this flag is
During context switch, the SSBD bit in SPEC_CTRL MSR is updated according
to changes in TIF_SSBD flag in the current and next running task.
Currently, only the bit controlling speculative store in SPEC_CTRL MSR
is updated and the related update functions all have "speculative_store"
or "ssb" in
The previous version of this series had a patch to apply TIF_STIBP updates
to all threads affected by a dumpability change, and keeping all the CPUs'
SPEC CTRL MSRs in sync with running task's TIF_STIBP.
However, this feature adds much overhead and complexities
for little gain. Normally a task
Remove unnecessary else statement in spectre_v2_parse_cmdline()
to save a indentation level.
Signed-off-by: Tim Chen
---
arch/x86/kernel/cpu/bugs.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c
When a task changes its dumpability, arch_update_spec_ctrl_restriction()
is called to place restriction on the task's speculative execution
according to dumpability changes.
Implements arch_update_spec_restriction() for x86. Use STIBP to
restrict speculative execution when running a task set to
The thread info flags are currently randomly distributed in the header
file arch/x86/include/asm/thread_info.h.
Group TIF flags together according to the following categories:
operation mode, syscall mode, pending work, task status and security
status.
Signed-off-by: Tim Chen
---
The previous version of this series had a patch to apply TIF_STIBP updates
to all threads affected by a dumpability change, and keeping all the CPUs'
SPEC CTRL MSRs in sync with running task's TIF_STIBP.
However, this feature adds much overhead and complexities
for little gain. Normally a task
Remove unnecessary else statement in spectre_v2_parse_cmdline()
to save a indentation level.
Signed-off-by: Tim Chen
---
arch/x86/kernel/cpu/bugs.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c
When a task changes its dumpability, arch_update_spec_ctrl_restriction()
is called to place restriction on the task's speculative execution
according to dumpability changes.
Implements arch_update_spec_restriction() for x86. Use STIBP to
restrict speculative execution when running a task set to
The thread info flags are currently randomly distributed in the header
file arch/x86/include/asm/thread_info.h.
Group TIF flags together according to the following categories:
operation mode, syscall mode, pending work, task status and security
status.
Signed-off-by: Tim Chen
---
The comment to TIF_SSBD uses the obsoleted name
"Reduced Data Speculation".
Update comment use the correct name
"Speculative store bypass disable".
Signed-off-by: Tim Chen
---
arch/x86/include/asm/thread_info.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The Spectre V2 printout in cpu_show_common() handles conditionals for the
various mitigation methods directly in the sprintf() argument list. That's
hard to read and will become unreadable if more complex decisions need to
be made for a particular method.
Move the conditionals for STIBP and IBPB
If enhanced IBRS is engaged, STIBP is redundant in mitigating Spectre
v2 user space exploits from hyperthread sibling.
Disable STIBP when enhanced IBRS is used.
Signed-off-by: Tim Chen
---
arch/x86/kernel/cpu/bugs.c | 11 +++
1 file changed, 11 insertions(+)
diff --git
The comment to TIF_SSBD uses the obsoleted name
"Reduced Data Speculation".
Update comment use the correct name
"Speculative store bypass disable".
Signed-off-by: Tim Chen
---
arch/x86/include/asm/thread_info.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The Spectre V2 printout in cpu_show_common() handles conditionals for the
various mitigation methods directly in the sprintf() argument list. That's
hard to read and will become unreadable if more complex decisions need to
be made for a particular method.
Move the conditionals for STIBP and IBPB
If enhanced IBRS is engaged, STIBP is redundant in mitigating Spectre
v2 user space exploits from hyperthread sibling.
Disable STIBP when enhanced IBRS is used.
Signed-off-by: Tim Chen
---
arch/x86/kernel/cpu/bugs.c | 11 +++
1 file changed, 11 insertions(+)
diff --git
Hi Olof,
On Fri, Nov 16, 2018 at 05:54:56PM -0800, Olof Johansson wrote:
> Makes sparse happy. Before:
>
> arch/arm64/include/asm/sysreg.h:471:42: warning: constant 0x
> is so big it is unsigned long
> arch/arm64/include/asm/sysreg.h:512:42: warning: constant 0x
Hi Olof,
On Fri, Nov 16, 2018 at 05:54:56PM -0800, Olof Johansson wrote:
> Makes sparse happy. Before:
>
> arch/arm64/include/asm/sysreg.h:471:42: warning: constant 0x
> is so big it is unsigned long
> arch/arm64/include/asm/sysreg.h:512:42: warning: constant 0x
On Fri, Nov 16, 2018 at 09:40:45AM +0100, Michal Simek wrote:
> On 09. 11. 18 16:36, Nathan Chancellor wrote:
> > On Fri, Nov 09, 2018 at 10:33:00AM +0100, Michal Simek wrote:
> >> On 08. 11. 18 16:01, Nathan Chancellor wrote:
> >>> On Thu, Nov 08, 2018 at 07:45:42AM +0100, Michal Simek wrote:
>
On Fri, Nov 16, 2018 at 09:40:45AM +0100, Michal Simek wrote:
> On 09. 11. 18 16:36, Nathan Chancellor wrote:
> > On Fri, Nov 09, 2018 at 10:33:00AM +0100, Michal Simek wrote:
> >> On 08. 11. 18 16:01, Nathan Chancellor wrote:
> >>> On Thu, Nov 08, 2018 at 07:45:42AM +0100, Michal Simek wrote:
>
Makes sparse happy. Before:
arch/arm64/include/asm/sysreg.h:471:42: warning: constant 0x is
so big it is unsigned long
arch/arm64/include/asm/sysreg.h:512:42: warning: constant 0x is
so big it is unsigned long
Signed-off-by: Olof Johansson
---
Makes sparse happy. Before:
arch/arm64/include/asm/sysreg.h:471:42: warning: constant 0x is
so big it is unsigned long
arch/arm64/include/asm/sysreg.h:512:42: warning: constant 0x is
so big it is unsigned long
Signed-off-by: Olof Johansson
---
The this_cpu_cmpxchg makes the do-while loop pass as long as the
s->cpu_slab->partial as the same value. It doesn't care what happened to
that slab. Interrupt is not disabled, and new alloc/free can happen in the
interrupt handlers. Theoretically, after we have a reference to the it,
stored in
The this_cpu_cmpxchg makes the do-while loop pass as long as the
s->cpu_slab->partial as the same value. It doesn't care what happened to
that slab. Interrupt is not disabled, and new alloc/free can happen in the
interrupt handlers. Theoretically, after we have a reference to the it,
stored in
On Fri, Nov 09, 2018 at 10:35:33AM +0100, Johannes Berg wrote:
> From: Johannes Berg
>
> __is_constexpr() is a work of art, understandable only to the most
> respected wizards of C. Even sparse doesn't seem to belong to that
> group and warns that there's an "expression using sizeof(void)".
>
>
On Fri, Nov 09, 2018 at 10:35:33AM +0100, Johannes Berg wrote:
> From: Johannes Berg
>
> __is_constexpr() is a work of art, understandable only to the most
> respected wizards of C. Even sparse doesn't seem to belong to that
> group and warns that there's an "expression using sizeof(void)".
>
>
On Fri, Nov 09, 2018 at 10:35:32AM +0100, Johannes Berg wrote:
> From: Johannes Berg
>
> Sparse doesn't support all the overflow builtins, so just hide
> them from it to avoid lots of warnings/errors reported by it.
The development version of sparse support these builtins
since their
On Fri, Nov 09, 2018 at 10:35:32AM +0100, Johannes Berg wrote:
> From: Johannes Berg
>
> Sparse doesn't support all the overflow builtins, so just hide
> them from it to avoid lots of warnings/errors reported by it.
The development version of sparse support these builtins
since their
This patchset implements freezer for cgroup v2.
It provides similar functionality as v1 freezer, but the interface
conforms to the cgroup v2 interface design principles, and it
provides a better user experience: tasks can be killed, ptrace works,
there is no separate controller, which has to be
This patchset implements freezer for cgroup v2.
It provides similar functionality as v1 freezer, but the interface
conforms to the cgroup v2 interface design principles, and it
provides a better user experience: tasks can be killed, ptrace works,
there is no separate controller, which has to be
The helper is identical to the existing cgroup_task_count()
except it doesn't take the css_set_lock by itself, assuming
that the caller does.
Also, move cgroup_task_count() implementation into
kernel/cgroup/cgroup.c, as there is nothing specific to cgroup v1.
Signed-off-by: Roman Gushchin
Cc:
The helper is identical to the existing cgroup_task_count()
except it doesn't take the css_set_lock by itself, assuming
that the caller does.
Also, move cgroup_task_count() implementation into
kernel/cgroup/cgroup.c, as there is nothing specific to cgroup v1.
Signed-off-by: Roman Gushchin
Cc:
Now the number of descendant cgroups and the number of dying
descendant cgroups are synchronized using the cgroup_mutex.
The number of descendant cgroups will be required by the cgroup v2
freezer, which will use it to determine if a cgroup is frozen
(depending on total number of descendants and
Now the number of descendant cgroups and the number of dying
descendant cgroups are synchronized using the cgroup_mutex.
The number of descendant cgroups will be required by the cgroup v2
freezer, which will use it to determine if a cgroup is frozen
(depending on total number of descendants and
1 - 100 of 936 matches
Mail list logo
