Re: [PATCH 2/2] clk: fixed-rate: Remove export symbol on setup function

Hi Stephen, On Tue, Aug 16, 2016 at 7:31 PM, Stephen Boyd wrote: > On 08/16, Geert Uytterhoeven wrote: >> On Sat, Aug 13, 2016 at 3:50 AM, Stephen Boyd wrote: >> > This function is only called by builtin code, but we always >> > exported it and had

Re: [PATCH 2/2] clk: fixed-rate: Remove export symbol on setup function

Hi Stephen, On Tue, Aug 16, 2016 at 7:31 PM, Stephen Boyd wrote: > On 08/16, Geert Uytterhoeven wrote: >> On Sat, Aug 13, 2016 at 3:50 AM, Stephen Boyd wrote: >> > This function is only called by builtin code, but we always >> > exported it and had marked it as __init before commit >> >

Re: [PATCH 07/10] docs: sphinxify ubsan.txt and move it to dev-tools

On 08/09/2016 02:34 AM, Jonathan Corbet wrote: > Cc: Andrey Ryabinin > Signed-off-by: Jonathan Corbet > --- Acked-by: Andrey Ryabinin

Re: [PATCH 07/10] docs: sphinxify ubsan.txt and move it to dev-tools

On 08/09/2016 02:34 AM, Jonathan Corbet wrote: > Cc: Andrey Ryabinin > Signed-off-by: Jonathan Corbet > --- Acked-by: Andrey Ryabinin

[PATCH] cred: simpler, 1D supplementary groups

Current supplementary groups code can massively overallocate memory and is implemented in a way so that access to individual gid is done via 2D array. If number of gids is <= 32, memory allocation is more or less tolerable (140/148 bytes). But if it is not, code allocates full page (!) regardless

[PATCH] cred: simpler, 1D supplementary groups

Current supplementary groups code can massively overallocate memory and is implemented in a way so that access to individual gid is done via 2D array. If number of gids is <= 32, memory allocation is more or less tolerable (140/148 bytes). But if it is not, code allocates full page (!) regardless

Re: [PATCH] time: avoid undefined behaviour in ktime_add_safe()

On Fri, Aug 12, 2016 at 4:37 PM, Vegard Nossum wrote: > I ran into this: > > > > UBSAN: Undefined behaviour in kernel/time/hrtimer.c:310:16 > signed integer overflow: >

Re: [PATCH] time: avoid undefined behaviour in ktime_add_safe()

On Fri, Aug 12, 2016 at 4:37 PM, Vegard Nossum wrote: > I ran into this: > > > > UBSAN: Undefined behaviour in kernel/time/hrtimer.c:310:16 > signed integer overflow: > 9223372036854775807 + 5

Re: [Documentation] State of CPU controller in cgroup v2

On Aug 5, 2016 7:07 PM, "Tejun Heo" wrote: > > Hello, > > There have been several discussions around CPU controller support. > Unfortunately, no consensus was reached and cgroup v2 is sorely > lacking CPU controller support. This document includes summary of the > situation and

Re: [Documentation] State of CPU controller in cgroup v2

On Aug 5, 2016 7:07 PM, "Tejun Heo" wrote: > > Hello, > > There have been several discussions around CPU controller support. > Unfortunately, no consensus was reached and cgroup v2 is sorely > lacking CPU controller support. This document includes summary of the > situation and arguments along

Re: [PATCH v2 0/5] bug: Provide toggle for BUG on data corruption

On 08/16, Kees Cook wrote: > This adds a CONFIG to trigger BUG()s when the kernel encounters > unexpected data structure integrity as currently detected with > CONFIG_DEBUG_LIST. > > Specifically list operations have been a target for widening flaws to gain > "write anywhere" primitives for

Re: [PATCH v2 0/5] bug: Provide toggle for BUG on data corruption

On 08/16, Kees Cook wrote: > This adds a CONFIG to trigger BUG()s when the kernel encounters > unexpected data structure integrity as currently detected with > CONFIG_DEBUG_LIST. > > Specifically list operations have been a target for widening flaws to gain > "write anywhere" primitives for

Re: [PATCH] time: avoid undefined behaviour in timespec64_add_safe()

On Fri, Aug 12, 2016 at 11:14 AM, Vegard Nossum wrote: > I ran into this: > > > > UBSAN: Undefined behaviour in kernel/time/time.c:783:2 > signed integer overflow: > 5273 +

Re: [PATCH] time: avoid undefined behaviour in timespec64_add_safe()

On Fri, Aug 12, 2016 at 11:14 AM, Vegard Nossum wrote: > I ran into this: > > > > UBSAN: Undefined behaviour in kernel/time/time.c:783:2 > signed integer overflow: > 5273 + 9223372036854771711 cannot

Re: [PATCH v2] timekeeping: Prints the amounts of time spent during suspend

On Thu, Aug 11, 2016 at 2:35 PM, Ruchi Kandoi wrote: > This helps to keep track of real time while debugging using kernel logs. > > Cc: John Stultz > Signed-off-by: Ruchi Kandoi > --- > Changelog since v1: > - removed cross

Re: [PATCH v2] timekeeping: Prints the amounts of time spent during suspend

On Thu, Aug 11, 2016 at 2:35 PM, Ruchi Kandoi wrote: > This helps to keep track of real time while debugging using kernel logs. > > Cc: John Stultz > Signed-off-by: Ruchi Kandoi > --- > Changelog since v1: > - removed cross platform warnings. Queued for testing, targeting 4.9. thanks -john

Re: [PATCH v2] clocksource: Defer override invalidation unless clock is unstable

On Sat, Aug 6, 2016 at 9:07 AM, Kyle Walker wrote: > Clocksources don't get the VALID_FOR_HRES flag until they have been > checked by a watchdog. However, when using an override, the > clocksource_select logic will clear the override value if the > clocksource is not marked

Re: [PATCH v2] clocksource: Defer override invalidation unless clock is unstable

On Sat, Aug 6, 2016 at 9:07 AM, Kyle Walker wrote: > Clocksources don't get the VALID_FOR_HRES flag until they have been > checked by a watchdog. However, when using an override, the > clocksource_select logic will clear the override value if the > clocksource is not marked VALID_FOR_HRES during

Re: [PATCH] hrtimer: spelling fixes

On Thu, Jun 23, 2016 at 11:50 AM, Pratyush Patel wrote: > Signed-off-by: Pratyush Patel > --- > kernel/time/hrtimer.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/kernel/time/hrtimer.c

Re: [PATCH] hrtimer: spelling fixes

On Thu, Jun 23, 2016 at 11:50 AM, Pratyush Patel wrote: > Signed-off-by: Pratyush Patel > --- > kernel/time/hrtimer.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c > index e99df0f..c7f6f5b 100644 > ---

Re: RFC: Petition Intel/AMD to add POPF_IF insn

Well first of all you actually CCed AMDs graphics developers. So Alex and I can't say much about CPU optimizations. Additional to that a comment below. Am 17.08.2016 um 19:20 schrieb Denys Vlasenko: Last year, a proposal was floated to avoid costly POPF. In particular, each

Re: RFC: Petition Intel/AMD to add POPF_IF insn

Well first of all you actually CCed AMDs graphics developers. So Alex and I can't say much about CPU optimizations. Additional to that a comment below. Am 17.08.2016 um 19:20 schrieb Denys Vlasenko: Last year, a proposal was floated to avoid costly POPF. In particular, each

Re: [PATCH v4 25/26] time: Delete current_fs_time() function

On Sat, Aug 13, 2016 at 3:48 PM, Deepa Dinamani wrote: > All uses of the current_fs_time() function have been > replaced by other time interfaces. > > And, its use cases can be fulfilled by current_time() > or ktime_get_* variants. > > Signed-off-by: Deepa Dinamani

Re: [PATCH v4 25/26] time: Delete current_fs_time() function

On Sat, Aug 13, 2016 at 3:48 PM, Deepa Dinamani wrote: > All uses of the current_fs_time() function have been > replaced by other time interfaces. > > And, its use cases can be fulfilled by current_time() > or ktime_get_* variants. > > Signed-off-by: Deepa Dinamani > Reviewed-by: Arnd Bergmann

Re: 4.7.0-rc7 ext4 error in dx_probe

On Fri, Aug 05, 2016 at 08:11:36PM +0200, Johannes Stezenbach wrote: > On Fri, Aug 05, 2016 at 10:02:28AM -0700, Darrick J. Wong wrote: > > > > When you're back on 4.7, can you apply this patch[1] to see if it fixes > > the problem? I speculate that the new parallel dir lookup code enables > >

Re: 4.7.0-rc7 ext4 error in dx_probe

On Fri, Aug 05, 2016 at 08:11:36PM +0200, Johannes Stezenbach wrote: > On Fri, Aug 05, 2016 at 10:02:28AM -0700, Darrick J. Wong wrote: > > > > When you're back on 4.7, can you apply this patch[1] to see if it fixes > > the problem? I speculate that the new parallel dir lookup code enables > >

[PATCH v6 3/4] PCI: designware: Wait for iATU enable

From: Joao Pinto Add a loop with timeout to make sure the iATU is really enabled before subsequent config and I/O accesses. [bhelgaas: split to separate patch, use dev_err() instead of dev_dbg()] Signed-off-by: Joao Pinto Signed-off-by: Bjorn

[PATCH v6 1/4] PCI: designware: Return data directly from dw_pcie_readl_rc()

dw_pcie_readl_rc() reads a u32 value. Previously we stored that value in space supplied by the caller. Return the u32 value directly instead. This makes the calling code read better and makes it obvious that the caller need not initialize the storage. In the following example it isn't clear

Re: [PATCH] time: alarmtimer: Add the trcepoints for alarmtimer

On Fri, Aug 12, 2016 at 2:16 AM, Baolin Wang wrote: > For system debugging, we usually want to know who sets one alarm timer, the > time of the timer, when the timer started and fired and so on. > > Thus adding tracepoints can help us trace the alarmtimer information. > >

[PATCH v6 2/4] PCI: designware: Move link wait definitions to .c file

From: Joao Pinto Move the link wait sleep definitions to the .c file as suggested by Jisheng Zhang in a previous patch. Signed-off-by: Joao Pinto Signed-off-by: Bjorn Helgaas CC: Jisheng Zhang ---

[PATCH v6 3/4] PCI: designware: Wait for iATU enable

From: Joao Pinto Add a loop with timeout to make sure the iATU is really enabled before subsequent config and I/O accesses. [bhelgaas: split to separate patch, use dev_err() instead of dev_dbg()] Signed-off-by: Joao Pinto Signed-off-by: Bjorn Helgaas --- drivers/pci/host/pcie-designware.c |

[PATCH v6 1/4] PCI: designware: Return data directly from dw_pcie_readl_rc()

dw_pcie_readl_rc() reads a u32 value. Previously we stored that value in space supplied by the caller. Return the u32 value directly instead. This makes the calling code read better and makes it obvious that the caller need not initialize the storage. In the following example it isn't clear

Re: [PATCH] time: alarmtimer: Add the trcepoints for alarmtimer

On Fri, Aug 12, 2016 at 2:16 AM, Baolin Wang wrote: > For system debugging, we usually want to know who sets one alarm timer, the > time of the timer, when the timer started and fired and so on. > > Thus adding tracepoints can help us trace the alarmtimer information. > > Signed-off-by: Baolin

[PATCH v6 2/4] PCI: designware: Move link wait definitions to .c file

From: Joao Pinto Move the link wait sleep definitions to the .c file as suggested by Jisheng Zhang in a previous patch. Signed-off-by: Joao Pinto Signed-off-by: Bjorn Helgaas CC: Jisheng Zhang --- drivers/pci/host/pcie-designware.c |5 + drivers/pci/host/pcie-designware.h |5

[PATCH] tools lib: Reinstate strlcpy() header guard with __UCLIBC__

perf tools build in recent kernels spews splat when cross compiling with uClibc | CC util/alias.o | In file included from tools/perf/util/../ui/../util/cache.h:8:0, | from tools/perf/util/../ui/helpline.h:7, | from tools/perf/util/debug.h:8, |

[PATCH] tools lib: Reinstate strlcpy() header guard with __UCLIBC__

perf tools build in recent kernels spews splat when cross compiling with uClibc | CC util/alias.o | In file included from tools/perf/util/../ui/../util/cache.h:8:0, | from tools/perf/util/../ui/helpline.h:7, | from tools/perf/util/debug.h:8, |

[PATCH v6 4/4] PCI: designware: Add iATU Unroll feature

From: Joao Pinto Add support for the new iATU Unroll mechanism that will be used from Core version 4.80. The new Cores can support either iATU Unroll or the "old" iATU method, now called Legacy Mode. The driver is perfectly capable of performing well for both.

[PATCH v6 4/4] PCI: designware: Add iATU Unroll feature

From: Joao Pinto Add support for the new iATU Unroll mechanism that will be used from Core version 4.80. The new Cores can support either iATU Unroll or the "old" iATU method, now called Legacy Mode. The driver is perfectly capable of performing well for both. [bhelgaas: split ATU enable

[PATCH v6 0/4] pcie-designware: add iATU unroll feature

Original description from Joao: The new DWC PCIe Core version (4.80) implements iATU in a different way. This new mechanism is called iATU Unroll Mode. The Core still supports the "old" mechanism calling it Legacy Mode if configured to do so, but the standard way will be using Unroll.

Re: [PATCH v8 1/2] mtd: nand_bbt: Move BBT block selection logic out of write_bbt()

On Mon, 15 Aug 2016 18:22:01 -0500 Kyle Roeschley wrote: > From: Boris Brezillon > > This clarifies the write_bbt() by removing the write label and > clarifying the error/exit path. Applied both. Thanks, Boris > > Signed-off-by:

[PATCH v6 0/4] pcie-designware: add iATU unroll feature

Original description from Joao: The new DWC PCIe Core version (4.80) implements iATU in a different way. This new mechanism is called iATU Unroll Mode. The Core still supports the "old" mechanism calling it Legacy Mode if configured to do so, but the standard way will be using Unroll.

Re: [PATCH v8 1/2] mtd: nand_bbt: Move BBT block selection logic out of write_bbt()

On Mon, 15 Aug 2016 18:22:01 -0500 Kyle Roeschley wrote: > From: Boris Brezillon > > This clarifies the write_bbt() by removing the write label and > clarifying the error/exit path. Applied both. Thanks, Boris > > Signed-off-by: Boris Brezillon > Tested-by: Kyle Roeschley > --- > v8:

[PATCH v12 3/7] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

From: Matt Roper When we write watermark values to the hardware, those values are stored in dev_priv->wm.skl_hw. However with recent watermark changes, the results structure we're copying from only contains valid watermark and DDB values for the pipes that are

Re: [PACTH v9] stacktrace: Eliminate task stack trace duplication

On Wed, Aug 17, 2016 at 02:41:30PM -0400, Robert Foss wrote: > On 2016-08-17 02:06 PM, Josh Poimboeuf wrote: > > On Wed, Aug 17, 2016 at 01:40:33PM -0400, Robert Foss wrote: > > > On 2016-08-17 12:58 PM, Josh Poimboeuf wrote: > > > > On Wed, Aug 17, 2016 at 09:51:45AM -0400, Robert Foss wrote: > >

[PATCH v12 3/7] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

From: Matt Roper When we write watermark values to the hardware, those values are stored in dev_priv->wm.skl_hw. However with recent watermark changes, the results structure we're copying from only contains valid watermark and DDB values for the pipes that are actually changing; the values for

Re: [PACTH v9] stacktrace: Eliminate task stack trace duplication

On Wed, Aug 17, 2016 at 02:41:30PM -0400, Robert Foss wrote: > On 2016-08-17 02:06 PM, Josh Poimboeuf wrote: > > On Wed, Aug 17, 2016 at 01:40:33PM -0400, Robert Foss wrote: > > > On 2016-08-17 12:58 PM, Josh Poimboeuf wrote: > > > > On Wed, Aug 17, 2016 at 09:51:45AM -0400, Robert Foss wrote: > >

[PATCH v12 0/7] Finally fix watermarks

Patches that actually changed (please re-review: drm/i915/gen6+: Interpret mailbox error flags drm/i915/skl: Add support for the SAGV, fix underrun hangs drm/i915/skl: Update DDB values atomically with wms/plane attrs Everything else is the same. Updated version of

[PATCH v12 1/7] drm/i915/gen6+: Interpret mailbox error flags

In order to add proper support for the SAGV, we need to be able to know what the cause of a failure to change the SAGV through the pcode mailbox was. The reasoning for this is that some very early pre-release Skylake machines don't actually allow you to control the SAGV on them, and indicate an

[PATCH v12 0/7] Finally fix watermarks

Patches that actually changed (please re-review: drm/i915/gen6+: Interpret mailbox error flags drm/i915/skl: Add support for the SAGV, fix underrun hangs drm/i915/skl: Update DDB values atomically with wms/plane attrs Everything else is the same. Updated version of

[PATCH v12 1/7] drm/i915/gen6+: Interpret mailbox error flags

In order to add proper support for the SAGV, we need to be able to know what the cause of a failure to change the SAGV through the pcode mailbox was. The reasoning for this is that some very early pre-release Skylake machines don't actually allow you to control the SAGV on them, and indicate an

[PATCH v12 4/7] drm/i915/skl: Update plane watermarks atomically during plane updates

Thanks to Ville for suggesting this as a potential solution to pipe underruns on Skylake. On Skylake all of the registers for configuring planes, including the registers for configuring their watermarks, are double buffered. New values written to them won't take effect until said registers are

[PATCH v12 4/7] drm/i915/skl: Update plane watermarks atomically during plane updates

Thanks to Ville for suggesting this as a potential solution to pipe underruns on Skylake. On Skylake all of the registers for configuring planes, including the registers for configuring their watermarks, are double buffered. New values written to them won't take effect until said registers are

[PATCH v12 7/7] drm/i915/skl: Update DDB values atomically with wms/plane attrs

Now that we can hook into update_crtcs and control the order in which we update CRTCs at each modeset, we can finish the final step of fixing Skylake's watermark handling by performing DDB updates at the same time as plane updates and watermark updates. The first major change in this patch is

[PATCH v12 2/7] drm/i915/skl: Add support for the SAGV, fix underrun hangs

Since the watermark calculations for Skylake are still broken, we're apt to hitting underruns very easily under multi-monitor configurations. While it would be lovely if this was fixed, it's not. Another problem that's been coming from this however, is the mysterious issue of underruns causing

[PATCH v12 7/7] drm/i915/skl: Update DDB values atomically with wms/plane attrs

Now that we can hook into update_crtcs and control the order in which we update CRTCs at each modeset, we can finish the final step of fixing Skylake's watermark handling by performing DDB updates at the same time as plane updates and watermark updates. The first major change in this patch is

[PATCH v12 2/7] drm/i915/skl: Add support for the SAGV, fix underrun hangs

Since the watermark calculations for Skylake are still broken, we're apt to hitting underruns very easily under multi-monitor configurations. While it would be lovely if this was fixed, it's not. Another problem that's been coming from this however, is the mysterious issue of underruns causing

Re: [PATCH v5 0/3] pcie-designware: add iATU unroll feature

Hi Joao, On Wed, Aug 10, 2016 at 11:02:37AM +0100, Joao Pinto wrote: > The new DWC PCIe Core version (4.80) implements iATU in a different way. > This new mechanism is called iATU Unroll Mode. The Core still supports > the "old" mechanism calling it Legacy Mode if configured to do so, but > the

[PATCH v12 5/7] drm/i915/skl: Ensure pipes with changed wms get added to the state

If we're enabling a pipe, we'll need to modify the watermarks on all active planes. Since those planes won't be added to the state on their own, we need to add them ourselves. Signed-off-by: Lyude Reviewed-by: Matt Roper Cc: sta...@vger.kernel.org

Re: [PATCH v5 0/3] pcie-designware: add iATU unroll feature

Hi Joao, On Wed, Aug 10, 2016 at 11:02:37AM +0100, Joao Pinto wrote: > The new DWC PCIe Core version (4.80) implements iATU in a different way. > This new mechanism is called iATU Unroll Mode. The Core still supports > the "old" mechanism calling it Legacy Mode if configured to do so, but > the

[PATCH v12 5/7] drm/i915/skl: Ensure pipes with changed wms get added to the state

If we're enabling a pipe, we'll need to modify the watermarks on all active planes. Since those planes won't be added to the state on their own, we need to add them ourselves. Signed-off-by: Lyude Reviewed-by: Matt Roper Cc: sta...@vger.kernel.org Cc: Ville Syrjälä Cc: Daniel Vetter Cc:

[PATCH v12 6/7] drm/i915: Move CRTC updating in atomic_commit into it's own hook

Since we have to write ddb allocations at the same time as we do other plane updates, we're going to need to be able to control the order in which we execute modesets on each pipe. The easiest way to do this is to just factor this section of intel_atomic_commit_tail() (intel_atomic_commit() for

[PATCH v12 6/7] drm/i915: Move CRTC updating in atomic_commit into it's own hook

Since we have to write ddb allocations at the same time as we do other plane updates, we're going to need to be able to control the order in which we execute modesets on each pipe. The easiest way to do this is to just factor this section of intel_atomic_commit_tail() (intel_atomic_commit() for

Re: RFC: Petition Intel/AMD to add POPF_IF insn

On Wed, Aug 17, 2016 at 12:35 PM, Denys Vlasenko wrote: > > Experimentally, POPF is stupidly slow _always_. 6 cycles > even if none of the "scary" flags are changed. 6 cycles is nothing. That's basically the overhead of "oops, I need to use the microcode sequencer". One

Re: RFC: Petition Intel/AMD to add POPF_IF insn

On Wed, Aug 17, 2016 at 12:35 PM, Denys Vlasenko wrote: > > Experimentally, POPF is stupidly slow _always_. 6 cycles > even if none of the "scary" flags are changed. 6 cycles is nothing. That's basically the overhead of "oops, I need to use the microcode sequencer". One issue is that the intel

Re: [PATCH 2/2] pipe: make pipe user buffer limit checks more precise

On 08/17/2016 09:41 PM, Michael Kerrisk (man-pages) wrote: So, would that mean something like the following (where I've moved some checks from pipe_fcntl() to pipe_set_size()): [...] And, do you agree that something similar is required for alloc_pipe_info() when creating a pipe? Yeah, that

Re: [PATCH 2/2] pipe: make pipe user buffer limit checks more precise

On 08/17/2016 09:41 PM, Michael Kerrisk (man-pages) wrote: So, would that mean something like the following (where I've moved some checks from pipe_fcntl() to pipe_set_size()): [...] And, do you agree that something similar is required for alloc_pipe_info() when creating a pipe? Yeah, that

Re: [RFC PATCH 1/2] [media] vb2: defer sync buffers from vb2_buffer_done() with a workqueue

Hi Javier, On Wed, Aug 17, 2016 at 02:28:56PM -0400, Javier Martinez Canillas wrote: > The vb2_buffer_done() function can be called from interrupt context but it > currently calls the vb2 memory allocator .finish operation to sync buffers > and this can take a long time, so it's not suitable to

Re: [RFC PATCH 1/2] [media] vb2: defer sync buffers from vb2_buffer_done() with a workqueue

Hi Javier, On Wed, Aug 17, 2016 at 02:28:56PM -0400, Javier Martinez Canillas wrote: > The vb2_buffer_done() function can be called from interrupt context but it > currently calls the vb2 memory allocator .finish operation to sync buffers > and this can take a long time, so it's not suitable to

Re: RFC: Petition Intel/AMD to add POPF_IF insn

On Wed, Aug 17, 2016 at 12:26 PM, Denys Vlasenko wrote: > > Exactly. And more: All of which is ENTIRELY IRRELEVANT. The 2-page pseudo-code is about behavior. It's trivial to short-circuit. There are obvious optimizations, which involve just making the rare cases go slow and

Re: RFC: Petition Intel/AMD to add POPF_IF insn

On Wed, Aug 17, 2016 at 12:26 PM, Denys Vlasenko wrote: > > Exactly. And more: All of which is ENTIRELY IRRELEVANT. The 2-page pseudo-code is about behavior. It's trivial to short-circuit. There are obvious optimizations, which involve just making the rare cases go slow and have a trivial "if

Re: [PATCH 2/2] pipe: make pipe user buffer limit checks more precise

On 08/17/2016 10:02 AM, Michael Kerrisk (man-pages) wrote: On 08/17/2016 10:00 AM, Vegard Nossum wrote: Isn't there also a race where two or more concurrent pipe()/fnctl() calls can together push us over the limits before the accounting is done? I guess there is! I think there really ought

Re: [PATCH 2/2] pipe: make pipe user buffer limit checks more precise

On 08/17/2016 10:02 AM, Michael Kerrisk (man-pages) wrote: On 08/17/2016 10:00 AM, Vegard Nossum wrote: Isn't there also a race where two or more concurrent pipe()/fnctl() calls can together push us over the limits before the accounting is done? I guess there is! I think there really ought

Re: [PATCH 2/2] pipe: make pipe user buffer limit checks more precise

Hello Vegard, On 08/18/2016 07:34 AM, Vegard Nossum wrote: > On 08/17/2016 10:02 AM, Michael Kerrisk (man-pages) wrote: >> On 08/17/2016 10:00 AM, Vegard Nossum wrote: > Isn't there also a race where two or more concurrent pipe()/fnctl() > calls can together push us over the limits before

Re: [PATCH 2/2] pipe: make pipe user buffer limit checks more precise

Hello Vegard, On 08/18/2016 07:34 AM, Vegard Nossum wrote: > On 08/17/2016 10:02 AM, Michael Kerrisk (man-pages) wrote: >> On 08/17/2016 10:00 AM, Vegard Nossum wrote: > Isn't there also a race where two or more concurrent pipe()/fnctl() > calls can together push us over the limits before

Re: sched: current instead rq->current

On Mon, 2016-08-15 at 21:30 +0200, Colin Vidal wrote: > Hello, > > At the beginning of __schedule (kernel/sched/core.c), the current > task > is get with rq->curr. I try to to understand why not directly using > current instead? > > Since a runqueue is specific to a CPU, it dosen't make sense to

Re: sched: current instead rq->current

On Mon, 2016-08-15 at 21:30 +0200, Colin Vidal wrote: > Hello, > > At the beginning of __schedule (kernel/sched/core.c), the current > task > is get with rq->curr. I try to to understand why not directly using > current instead? > > Since a runqueue is specific to a CPU, it dosen't make sense to

Re: [PATCH v3 0/5] dts patches for qcom tsens support

On Wed, Aug 17, 2016 at 10:48:43AM +0530, Rajendra Nayak wrote: > Hey Andy, > > This is a respin of v2 with some minor fixes pointed out by Rob. > Please pull these in for 4.9 > > Thanks, > Rajendra I pulled these in. Andy

Re: [PATCH] timer: Make msleep(0) a nop

On Fri, Aug 12, 2016 at 1:40 AM, wrote: > From: Ville Syrjälä > > Thanks to the msecs_to_jiffies()+1 msleep(0) may actually sleep for up > to one jiffy. Presumably the caller should be satisfied if we "sleep" > for 0 jiffies instead

Re: [PATCH v3 0/5] dts patches for qcom tsens support

On Wed, Aug 17, 2016 at 10:48:43AM +0530, Rajendra Nayak wrote: > Hey Andy, > > This is a respin of v2 with some minor fixes pointed out by Rob. > Please pull these in for 4.9 > > Thanks, > Rajendra I pulled these in. Andy

Re: [PATCH] timer: Make msleep(0) a nop

On Fri, Aug 12, 2016 at 1:40 AM, wrote: > From: Ville Syrjälä > > Thanks to the msecs_to_jiffies()+1 msleep(0) may actually sleep for up > to one jiffy. Presumably the caller should be satisfied if we "sleep" > for 0 jiffies instead of 0-1 jiffies, so let's just turn msleep(0) > into a nop. > >

[PATCH] Fix /proc/stat freezes (was [PATCH v15] "task_isolation" mode)

On Tue, 16 Aug 2016, Chris Metcalf wrote: > - Dropped Christoph Lameter's patch to avoid scheduling the > clocksource watchdog on nohz cores; the recommendation is to just > boot with tsc=reliable for NOHZ in any case, if necessary. We also said that there should be a WARN_ON if tsc=reliable

[PATCH] Fix /proc/stat freezes (was [PATCH v15] "task_isolation" mode)

On Tue, 16 Aug 2016, Chris Metcalf wrote: > - Dropped Christoph Lameter's patch to avoid scheduling the > clocksource watchdog on nohz cores; the recommendation is to just > boot with tsc=reliable for NOHZ in any case, if necessary. We also said that there should be a WARN_ON if tsc=reliable

Re: RFC: Petition Intel/AMD to add POPF_IF insn

On Wed, Aug 17, 2016 at 12:32 PM, Linus Torvalds wrote: > > The 2-page pseudo-code is about behavior. It's trivial to > short-circuit. There are obvious optimizations, which involve just > making the rare cases go slow and have a trivial "if those bits didn't >

Re: RFC: Petition Intel/AMD to add POPF_IF insn

On Wed, Aug 17, 2016 at 12:32 PM, Linus Torvalds wrote: > > The 2-page pseudo-code is about behavior. It's trivial to > short-circuit. There are obvious optimizations, which involve just > making the rare cases go slow and have a trivial "if those bits didn't > change, don't go through the

Re: RFC: Petition Intel/AMD to add POPF_IF insn

On 08/17/2016 09:32 PM, Linus Torvalds wrote: On Wed, Aug 17, 2016 at 12:26 PM, Denys Vlasenko wrote: Exactly. And more: All of which is ENTIRELY IRRELEVANT. The 2-page pseudo-code is about behavior. It's trivial to short-circuit. There are obvious optimizations,

Re: RFC: Petition Intel/AMD to add POPF_IF insn

On 08/17/2016 09:32 PM, Linus Torvalds wrote: On Wed, Aug 17, 2016 at 12:26 PM, Denys Vlasenko wrote: Exactly. And more: All of which is ENTIRELY IRRELEVANT. The 2-page pseudo-code is about behavior. It's trivial to short-circuit. There are obvious optimizations, which involve just

Re: [PATCH tip/timers/core] uapi glibc compat: make linux/time.h compile after libc time.h files

On Wed, Aug 10, 2016 at 8:45 AM, Willem de Bruijn wrote: > From: Willem de Bruijn > > Add libc-compat workaround for definitions in linux/time.h that > duplicate those in libc time.h, sys/time.h and bits/time.h. > > With this change, userspace

Re: [PATCH tip/timers/core] uapi glibc compat: make linux/time.h compile after libc time.h files

On Wed, Aug 10, 2016 at 8:45 AM, Willem de Bruijn wrote: > From: Willem de Bruijn > > Add libc-compat workaround for definitions in linux/time.h that > duplicate those in libc time.h, sys/time.h and bits/time.h. > > With this change, userspace builds succeeds when linux/time.h is > included

Re: Use of copy_from_user in msm_gem_submit.c while holding a spin_lock

On Wed, Aug 17, 2016 at 03:24:38PM -0400, Rob Clark wrote: > hmm, looks like, at least on arm (not sure about arm64), > > #define __copy_from_user_inatomic __copy_from_user > > ie. copy_from_user() minus the access_ok() and memset in the > !access_ok() path.. but maybe what I want is just the >

Re: Use of copy_from_user in msm_gem_submit.c while holding a spin_lock

On Wed, Aug 17, 2016 at 03:24:38PM -0400, Rob Clark wrote: > hmm, looks like, at least on arm (not sure about arm64), > > #define __copy_from_user_inatomic __copy_from_user > > ie. copy_from_user() minus the access_ok() and memset in the > !access_ok() path.. but maybe what I want is just the >

Re: RFC: Petition Intel/AMD to add POPF_IF insn

On Wed, Aug 17, 2016 at 12:13 PM, Andy Lutomirski wrote: > > It wouldn't surprise me if that were easier said than done. popf > potentially changes AC, and AC affects address translation. Rigth. A lot of magical flags are in eflags, and popf *may* change them. But that's

Re: RFC: Petition Intel/AMD to add POPF_IF insn

On Wed, Aug 17, 2016 at 12:13 PM, Andy Lutomirski wrote: > > It wouldn't surprise me if that were easier said than done. popf > potentially changes AC, and AC affects address translation. Rigth. A lot of magical flags are in eflags, and popf *may* change them. But that's why it's slow today.

[RFC PATCH 3/5] Trigger Module.ksymb generation in Makefile

Trigger the generation of file scripts/Module.ksymb in Makefile by calling updated scripts/streamline_config.pl with corresponding parameter (--genmodulesymb). The file is generated at each compilation considering that associations may change after tree updates. This patch is part of a research

[RFC PATCH 1/5] Add generation of Module.symb in streamline_config

Add generation of ./scripts/Module.ksymb file containing associations of driver file names and corresponding CONFIG_* symbol: foo_KCONF=CONFIG_FOO This file will be further loaded by the Makefile as a configuration file: all foo_KCONF will be considered variables and all CONFIG_FOO will be their

[RFC PATCH 3/5] Trigger Module.ksymb generation in Makefile

Trigger the generation of file scripts/Module.ksymb in Makefile by calling updated scripts/streamline_config.pl with corresponding parameter (--genmodulesymb). The file is generated at each compilation considering that associations may change after tree updates. This patch is part of a research

[RFC PATCH 1/5] Add generation of Module.symb in streamline_config

Add generation of ./scripts/Module.ksymb file containing associations of driver file names and corresponding CONFIG_* symbol: foo_KCONF=CONFIG_FOO This file will be further loaded by the Makefile as a configuration file: all foo_KCONF will be considered variables and all CONFIG_FOO will be their

[RFC PATCH 0/5] Add CONFIG symbol as module attribute

This patchset implements dynamic pegging of kconfig symbol into driver modinfo section * updates streamline_config.pl to generate the auxiliary file scripts/mod/Module.ksymb containing associations of driver file names and corresponding kconfig symbols CONFIG_* * updates Makefiles to trigger

[RFC PATCH 4/5] Set KCONFIG_KSYMB as value for kconfig_ksymb module attribute

Update modpost to add in *.mod.c files generated for each module the setting of module attribute kernel_ksymb to value given by KBUILD_KSYMB macro. This patch is part of a research project within Google Summer of Code of porting 'make localmodconfig' for backported drivers. The goal is to enable

[RFC PATCH 5/5] Add kconf_symb as kernel module attribute

Add kconf_symbol attribute to kernel struct module. This patch is part of a research project within Google Summer of Code of porting 'make localmodconfig' for backported drivers. The goal is to enable each module to expose in /sys its corresponding CONFIG_* option. The value of this attribute

[RFC PATCH 4/5] Set KCONFIG_KSYMB as value for kconfig_ksymb module attribute

Update modpost to add in *.mod.c files generated for each module the setting of module attribute kernel_ksymb to value given by KBUILD_KSYMB macro. This patch is part of a research project within Google Summer of Code of porting 'make localmodconfig' for backported drivers. The goal is to enable

<    1   2   3   4   5   6   7   8   9   10   >