Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Tue, 2016-05-10 at 14:53 -0700, Eric Dumazet wrote: > On Tue, 2016-05-10 at 17:35 -0400, Rik van Riel wrote: > > > You might need another one of these in invoke_softirq() > > > > Excellent. > > I gave it a quick try (without your suggestion), and host seems to > survive a stress test. > >

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Tue, 2016-05-10 at 14:53 -0700, Eric Dumazet wrote: > On Tue, 2016-05-10 at 17:35 -0400, Rik van Riel wrote: > > > > > You might need another one of these in invoke_softirq() > > > Excellent. > > I gave it a quick try (without your suggestion), and host seems to > survive a stress test. >

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Tue, 2016-05-10 at 14:53 -0700, Eric Dumazet wrote: > On Tue, 2016-05-10 at 17:35 -0400, Rik van Riel wrote: > > > You might need another one of these in invoke_softirq() > > > > Excellent. > > I gave it a quick try (without your suggestion), and host seems to > survive a stress test. > >

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Tue, 2016-05-10 at 14:53 -0700, Eric Dumazet wrote: > On Tue, 2016-05-10 at 17:35 -0400, Rik van Riel wrote: > > > > > You might need another one of these in invoke_softirq() > > > Excellent. > > I gave it a quick try (without your suggestion), and host seems to > survive a stress test. >

Re: [PATCH] media: dvb_ringbuffer: Add memory barriers

Hi Mauro, thanks for looking after this patch. On 05/07/16 15:22, Mauro Carvalho Chehab wrote: Hi Soeren, Em Sun, 7 Feb 2016 20:22:36 +0100 Soeren Moch escreveu: On 27.12.2015 21:41, Soeren Moch wrote: Implement memory barriers according to

Re: [PATCH] media: dvb_ringbuffer: Add memory barriers

Hi Mauro, thanks for looking after this patch. On 05/07/16 15:22, Mauro Carvalho Chehab wrote: Hi Soeren, Em Sun, 7 Feb 2016 20:22:36 +0100 Soeren Moch escreveu: On 27.12.2015 21:41, Soeren Moch wrote: Implement memory barriers according to Documentation/circular-buffers.txt: - use

[PATCH BUGFIX V3] block: add missing group association in bio-cloning functions

When a bio is cloned, the newly created bio must be associated with the same blkcg as the original bio (if BLK_CGROUP is enabled). If this operation is not performed, then the new bio is not associated with any group, and the group of the current task is returned when the group of the bio is

[PATCH] arm64: dts: qcom: Add msm8916 PMU node

Add the PMU so we can get proper perf event support on this SoC. Signed-off-by: Stephen Boyd --- arch/arm64/boot/dts/qcom/msm8916.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi

[PATCH BUGFIX V3] block: add missing group association in bio-cloning functions

When a bio is cloned, the newly created bio must be associated with the same blkcg as the original bio (if BLK_CGROUP is enabled). If this operation is not performed, then the new bio is not associated with any group, and the group of the current task is returned when the group of the bio is

[PATCH] arm64: dts: qcom: Add msm8916 PMU node

Add the PMU so we can get proper perf event support on this SoC. Signed-off-by: Stephen Boyd --- arch/arm64/boot/dts/qcom/msm8916.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi index

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Tue, 2016-05-10 at 17:35 -0400, Rik van Riel wrote: > You might need another one of these in invoke_softirq() > Excellent. I gave it a quick try (without your suggestion), and host seems to survive a stress test. Of course we do have to fix these problems : [ 147.781629] NOHZ:

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Tue, 2016-05-10 at 17:35 -0400, Rik van Riel wrote: > You might need another one of these in invoke_softirq() > Excellent. I gave it a quick try (without your suggestion), and host seems to survive a stress test. Of course we do have to fix these problems : [ 147.781629] NOHZ:

Re: [PATCH 1/2] watchdog: cpwd: Use setup_timer()

On Fri, May 06, 2016 at 06:29:40PM +0530, Muhammad Falak R Wani wrote: > The function setup_timer combines the initialization of a timer with > the initialization of the timer's function and data fields. > The multiline code for timer initialization is now replaced > with function setup_timer. >

Re: [PATCH 2/2] watchdog: shwdt: Use setup_timer()

On Fri, May 06, 2016 at 06:29:41PM +0530, Muhammad Falak R Wani wrote: > The function setup_timer combines the initialization of a timer with > the initialization of the timer's function and data fields. > The multiline code for timer initialization is now replaced > with function setup_timer. >

Re: [PATCH 1/2] watchdog: cpwd: Use setup_timer()

On Fri, May 06, 2016 at 06:29:40PM +0530, Muhammad Falak R Wani wrote: > The function setup_timer combines the initialization of a timer with > the initialization of the timer's function and data fields. > The multiline code for timer initialization is now replaced > with function setup_timer. >

Re: [PATCH 2/2] watchdog: shwdt: Use setup_timer()

On Fri, May 06, 2016 at 06:29:41PM +0530, Muhammad Falak R Wani wrote: > The function setup_timer combines the initialization of a timer with > the initialization of the timer's function and data fields. > The multiline code for timer initialization is now replaced > with function setup_timer. >

Re: powerpc: Fix sstep compile on powerpcspe

On Thu, 2016-05-05 at 20:44:44 UTC, Lennart Sorensen wrote: > powerpc: Fix sstep compile on powerpcspe > > Commit be96f63375a14ee8e690856ac77e579c75bd0bae introduced ldarx and stdcx > into the instructions in sstep.c, which are not accepted by the assembler > on powerpcspe, but does seem to be

Re: powerpc: Fix sstep compile on powerpcspe

On Thu, 2016-05-05 at 20:44:44 UTC, Lennart Sorensen wrote: > powerpc: Fix sstep compile on powerpcspe > > Commit be96f63375a14ee8e690856ac77e579c75bd0bae introduced ldarx and stdcx > into the instructions in sstep.c, which are not accepted by the assembler > on powerpcspe, but does seem to be

Re: [kernel,v4,02/11] vfio/spapr: Relax the IOMMU compatibility check

On Fri, 2016-29-04 at 08:55:15 UTC, Alexey Kardashevskiy wrote: > We are going to have multiple different types of PHB on the same system > with POWER8 + NVLink and PHBs will have different IOMMU ops. However > we only really care about one callback - create_table - so we can > relax the

Re: [kernel,v4,02/11] vfio/spapr: Relax the IOMMU compatibility check

On Fri, 2016-29-04 at 08:55:15 UTC, Alexey Kardashevskiy wrote: > We are going to have multiple different types of PHB on the same system > with POWER8 + NVLink and PHBs will have different IOMMU ops. However > we only really care about one callback - create_table - so we can > relax the

Re: [PATCH v4 6/6] block: Update blkdev_dax_capable() for consistency

On Tue, 2016-05-10 at 12:49 -0700, Dan Williams wrote: > On Tue, May 10, 2016 at 9:23 AM, Toshi Kani wrote: > > > > blkdev_dax_capable() is similar to bdev_dax_supported(), but needs > > to remain as a separate interface for checking dax capability of > > a raw block device.

Re: [PATCH v4 6/6] block: Update blkdev_dax_capable() for consistency

On Tue, 2016-05-10 at 12:49 -0700, Dan Williams wrote: > On Tue, May 10, 2016 at 9:23 AM, Toshi Kani wrote: > > > > blkdev_dax_capable() is similar to bdev_dax_supported(), but needs > > to remain as a separate interface for checking dax capability of > > a raw block device. > > > > Rename and

Re: [PATCH BUGFIX V2] block: add missing group association in bio-cloning functions

Il 10/05/2016 23:34, Jeff Moyer ha scritto: Paolo Valente writes: diff --git a/block/bio.c b/block/bio.c index 807d25e..e9b136a 100644 --- a/block/bio.c +++ b/block/bio.c @@ -622,6 +622,8 @@ struct bio *bio_clone_fast(struct bio *bio, gfp_t gfp_mask, struct bio_set

Re: [PATCH BUGFIX V2] block: add missing group association in bio-cloning functions

Il 10/05/2016 23:34, Jeff Moyer ha scritto: Paolo Valente writes: diff --git a/block/bio.c b/block/bio.c index 807d25e..e9b136a 100644 --- a/block/bio.c +++ b/block/bio.c @@ -622,6 +622,8 @@ struct bio *bio_clone_fast(struct bio *bio, gfp_t gfp_mask, struct bio_set *bs) }

Re: [PATCH] [media] v4l2-async: Pass the v4l2_async_subdev to the unbind callback

Hello Alban, On 05/10/2016 09:19 AM, Alban Bedel wrote: > v4l2_async_cleanup() is always called before before calling the > unbind() callback. However v4l2_async_cleanup() clear the asd member, > so when calling the unbind() callback the v4l2_async_subdev is always > NULL. To fix this save the

Re: [PATCH] [media] v4l2-async: Pass the v4l2_async_subdev to the unbind callback

Hello Alban, On 05/10/2016 09:19 AM, Alban Bedel wrote: > v4l2_async_cleanup() is always called before before calling the > unbind() callback. However v4l2_async_cleanup() clear the asd member, > so when calling the unbind() callback the v4l2_async_subdev is always > NULL. To fix this save the

Re: [PATCH 1/6] f2fs: support in batch multi blocks preallocation

> > valid_block_count = > > - sbi->total_valid_block_count + (block_t)count; > > + sbi->total_valid_block_count + (block_t)(*count); > > if (unlikely(valid_block_count > sbi->user_block_count)) { > > - spin_unlock(>stat_lock); > > - return false; > >

Re: [PATCH 1/6] f2fs: support in batch multi blocks preallocation

> > valid_block_count = > > - sbi->total_valid_block_count + (block_t)count; > > + sbi->total_valid_block_count + (block_t)(*count); > > if (unlikely(valid_block_count > sbi->user_block_count)) { > > - spin_unlock(>stat_lock); > > - return false; > >

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Tue, 2016-05-10 at 14:31 -0700, Eric Dumazet wrote: > On Tue, 2016-05-10 at 14:09 -0700, Eric Dumazet wrote: > > > > On Tue, May 10, 2016 at 1:46 PM, Hannes Frederic Sowa > > wrote: > > > > > > > > I agree here, but I don't think this patch particularly is a lot

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Tue, 2016-05-10 at 14:31 -0700, Eric Dumazet wrote: > On Tue, 2016-05-10 at 14:09 -0700, Eric Dumazet wrote: > > > > On Tue, May 10, 2016 at 1:46 PM, Hannes Frederic Sowa > > wrote: > > > > > > > > I agree here, but I don't think this patch particularly is a lot > > > of > > > bloat and

Re: [PATCH BUGFIX V2] block: add missing group association in bio-cloning functions

Paolo Valente writes: > diff --git a/block/bio.c b/block/bio.c > index 807d25e..e9b136a 100644 > --- a/block/bio.c > +++ b/block/bio.c > @@ -622,6 +622,8 @@ struct bio *bio_clone_fast(struct bio *bio, gfp_t > gfp_mask, struct bio_set *bs) > } > } >

Re: [PATCH BUGFIX V2] block: add missing group association in bio-cloning functions

Paolo Valente writes: > diff --git a/block/bio.c b/block/bio.c > index 807d25e..e9b136a 100644 > --- a/block/bio.c > +++ b/block/bio.c > @@ -622,6 +622,8 @@ struct bio *bio_clone_fast(struct bio *bio, gfp_t > gfp_mask, struct bio_set *bs) > } > } > > +

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Tue, 2016-05-10 at 14:09 -0700, Eric Dumazet wrote: > On Tue, May 10, 2016 at 1:46 PM, Hannes Frederic Sowa > wrote: > > > I agree here, but I don't think this patch particularly is a lot of > > bloat and something very interesting people can play with and extend

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Tue, 2016-05-10 at 14:09 -0700, Eric Dumazet wrote: > On Tue, May 10, 2016 at 1:46 PM, Hannes Frederic Sowa > wrote: > > > I agree here, but I don't think this patch particularly is a lot of > > bloat and something very interesting people can play with and extend upon. > > > > Sure, very

Re: [PATCH net-next 2/2] net: dsa: mv88e6xxx: add STU capability

On Tue, May 10, 2016 at 03:44:29PM -0400, Vivien Didelot wrote: > Some switch models have a STU (per VLAN port state database). Add a new > capability flag to switches info, instead of checking their family. > > Also if the 6165 family has an STU, it must have a VTU, so add the >

Re: [PATCH net-next 2/2] net: dsa: mv88e6xxx: add STU capability

On Tue, May 10, 2016 at 03:44:29PM -0400, Vivien Didelot wrote: > Some switch models have a STU (per VLAN port state database). Add a new > capability flag to switches info, instead of checking their family. > > Also if the 6165 family has an STU, it must have a VTU, so add the >

[PATCH] kbuild: move -Wunused-const-variable to W=1 warning level

gcc-6 started warning by default about variables that are not used anywhere and that are marked 'const', generating many false positives in an allmodconfig build, e.g.: arch/arm/mach-davinci/board-da830-evm.c:282:20: warning: 'da830_evm_emif25_pins' defined but not used

[PATCH] kbuild: move -Wunused-const-variable to W=1 warning level

gcc-6 started warning by default about variables that are not used anywhere and that are marked 'const', generating many false positives in an allmodconfig build, e.g.: arch/arm/mach-davinci/board-da830-evm.c:282:20: warning: 'da830_evm_emif25_pins' defined but not used

Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: abstract VTU/STU data access

On Tue, May 10, 2016 at 03:44:28PM -0400, Vivien Didelot wrote: > Both VTU and STU operations use the same routine to access their > (common) data registers, with a different offset. > > Add VTU and STU specific read and write functions to the data registers > to abstract the required offset. >

Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: abstract VTU/STU data access

On Tue, May 10, 2016 at 03:44:28PM -0400, Vivien Didelot wrote: > Both VTU and STU operations use the same routine to access their > (common) data registers, with a different offset. > > Add VTU and STU specific read and write functions to the data registers > to abstract the required offset. >

Re: [PATCH v3 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On Tue, May 10, 2016 at 11:53 AM, Kees Cook wrote: > On Tue, May 3, 2016 at 12:31 PM, Thomas Garnier wrote: >> Randomizes the virtual address space of kernel memory sections (physical >> memory mapping, vmalloc & vmemmap) for x86_64. This security

Re: [PATCH v3 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On Tue, May 10, 2016 at 11:53 AM, Kees Cook wrote: > On Tue, May 3, 2016 at 12:31 PM, Thomas Garnier wrote: >> Randomizes the virtual address space of kernel memory sections (physical >> memory mapping, vmalloc & vmemmap) for x86_64. This security feature >> mitigates exploits relying on

Re: Getting rid of dynamic TASK_SIZE (on x86, at least)

On Tue, May 10, 2016 at 10:49 AM, Cyrill Gorcunov wrote: > On Tue, May 10, 2016 at 10:26:05AM -0700, Andy Lutomirski wrote: > ... >> >> >> >> It's annoying and ugly. It also makes the idea of doing 32-bit CRIU >> >> restore by starting in 64-bit mode and switching to 32-bit

Re: Getting rid of dynamic TASK_SIZE (on x86, at least)

On Tue, May 10, 2016 at 10:49 AM, Cyrill Gorcunov wrote: > On Tue, May 10, 2016 at 10:26:05AM -0700, Andy Lutomirski wrote: > ... >> >> >> >> It's annoying and ugly. It also makes the idea of doing 32-bit CRIU >> >> restore by starting in 64-bit mode and switching to 32-bit more >> >>

[PATCH] x86/mm: Switch from TASK_SIZE to TASK_SIZE_MAX in the page fault code

x86's page fault handlers had two TASK_SIZE uses that should have been TASK_SIZE_MAX. I don't think that either one had a visible effect, but this makes the code clearer and should save a few bytes of text. (And I eventually want to eradicate TASK_SIZE. This will help.) Reported-by: Cyrill

[PATCH] x86/mm: Switch from TASK_SIZE to TASK_SIZE_MAX in the page fault code

x86's page fault handlers had two TASK_SIZE uses that should have been TASK_SIZE_MAX. I don't think that either one had a visible effect, but this makes the code clearer and should save a few bytes of text. (And I eventually want to eradicate TASK_SIZE. This will help.) Reported-by: Cyrill

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Tue, May 10, 2016 at 1:46 PM, Hannes Frederic Sowa wrote: > I agree here, but I don't think this patch particularly is a lot of > bloat and something very interesting people can play with and extend upon. > Sure, very rarely patch authors think their stuff is

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Tue, May 10, 2016 at 1:46 PM, Hannes Frederic Sowa wrote: > I agree here, but I don't think this patch particularly is a lot of > bloat and something very interesting people can play with and extend upon. > Sure, very rarely patch authors think their stuff is bloat. I prefer to fix kernel

[PATCH 2/2] ARM: multi_v7_defconfig: Enable Exynos MFC driver as module

Exynos SoCs have a Multi Format Video Hardware Codec (MFC) IP block that can be used to {en,de}code video streams by hardware. Enable support for its driver as a module so the MFC can be tested. Signed-off-by: Javier Martinez Canillas --- This patch depends on

[PATCH 2/2] ARM: multi_v7_defconfig: Enable Exynos MFC driver as module

Exynos SoCs have a Multi Format Video Hardware Codec (MFC) IP block that can be used to {en,de}code video streams by hardware. Enable support for its driver as a module so the MFC can be tested. Signed-off-by: Javier Martinez Canillas --- This patch depends on

[PATCH 1/2] ARM: exynos_defconfig: Enable MFC driver as module

Exynos SoCs have a Multi Format Video Hardware Codec (MFC) IP block that can be used to {en,de}code video streams by hardware. Enable support for its driver as a module so the MFC can be tested. Signed-off-by: Javier Martinez Canillas --- This patch depends on

[PATCH 1/2] ARM: exynos_defconfig: Enable MFC driver as module

Exynos SoCs have a Multi Format Video Hardware Codec (MFC) IP block that can be used to {en,de}code video streams by hardware. Enable support for its driver as a module so the MFC can be tested. Signed-off-by: Javier Martinez Canillas --- This patch depends on

Re: [PATCH] pinctrl: rockchip: fix pull setting error for rk3399

Caesar / David, On Tue, May 10, 2016 at 4:14 AM, Caesar Wang wrote: > From: David Wu > > This patch fixes the pinctrl pull bias setting, since the pull up/down > setting is the contrary for gpio0. Commit message only mentions gpio0, but gpio2 is

Re: [PATCH] pinctrl: rockchip: fix pull setting error for rk3399

Caesar / David, On Tue, May 10, 2016 at 4:14 AM, Caesar Wang wrote: > From: David Wu > > This patch fixes the pinctrl pull bias setting, since the pull up/down > setting is the contrary for gpio0. Commit message only mentions gpio0, but gpio2 is also fixed in the commit. Please mention gpio2

[PATCH] x86/extable: ensure entries are swapped completely when sorting

The x86 exception table sorting was changed in commit 29934b0fb8ff ("x86/extable: use generic search and sort routines") to use the arch independent code in lib/extable.c. However, the patch was mangled somehow on its way into the kernel from the last version posted at [1]. The committed version

[PATCH] x86/extable: ensure entries are swapped completely when sorting

The x86 exception table sorting was changed in commit 29934b0fb8ff ("x86/extable: use generic search and sort routines") to use the arch independent code in lib/extable.c. However, the patch was mangled somehow on its way into the kernel from the last version posted at [1]. The committed version

Re: [PATCH BUGFIX V2] block: add missing group association in bio-cloning functions

On Tue, May 10, 2016 at 11:02:12PM +0200, Paolo Valente wrote: > When a bio is cloned, the newly created bio must be associated with > the same blkcg as the original bio (if BLK_CGROUP is enabled). If > this operation is not performed, then the new bio is not associated > with any group, and the

Re: [PATCH BUGFIX V2] block: add missing group association in bio-cloning functions

On Tue, May 10, 2016 at 11:02:12PM +0200, Paolo Valente wrote: > When a bio is cloned, the newly created bio must be associated with > the same blkcg as the original bio (if BLK_CGROUP is enabled). If > this operation is not performed, then the new bio is not associated > with any group, and the

[PATCH BUGFIX V2] block: add missing group association in bio-cloning functions

When a bio is cloned, the newly created bio must be associated with the same blkcg as the original bio (if BLK_CGROUP is enabled). If this operation is not performed, then the new bio is not associated with any group, and the group of the current task is returned when the group of the bio is

[PATCH BUGFIX V2] block: add missing group association in bio-cloning functions

When a bio is cloned, the newly created bio must be associated with the same blkcg as the original bio (if BLK_CGROUP is enabled). If this operation is not performed, then the new bio is not associated with any group, and the group of the current task is returned when the group of the bio is

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Tue, 2016-05-10 at 16:52 -0400, David Miller wrote: > From: Rik van Riel > Date: Tue, 10 May 2016 16:50:56 -0400 > > > On Tue, 2016-05-10 at 16:45 -0400, David Miller wrote: > >> From: Paolo Abeni > >> Date: Tue, 10 May 2016 22:22:50 +0200 > >>  > >> > On

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Tue, 2016-05-10 at 16:52 -0400, David Miller wrote: > From: Rik van Riel > Date: Tue, 10 May 2016 16:50:56 -0400 > > > On Tue, 2016-05-10 at 16:45 -0400, David Miller wrote: > >> From: Paolo Abeni > >> Date: Tue, 10 May 2016 22:22:50 +0200 > >>  > >> > On Tue, 2016-05-10 at 09:08 -0700, Eric

Re: [Intel-wired-lan] [PATCH] e1000e: prevent division by zero if TIMINCA is zero

On Fri, May 06, 2016 at 11:43:17PM +, Rustad, Mark D wrote: > Denys Vlasenko wrote: > > >Users report that under VMWare, er32(TIMINCA) returns zero. > >This causes division by zero at init time as follows: > > > > ==>incvalue = er32(TIMINCA) &

Re: [Intel-wired-lan] [PATCH] e1000e: prevent division by zero if TIMINCA is zero

On Fri, May 06, 2016 at 11:43:17PM +, Rustad, Mark D wrote: > Denys Vlasenko wrote: > > >Users report that under VMWare, er32(TIMINCA) returns zero. > >This causes division by zero at init time as follows: > > > > ==>incvalue = er32(TIMINCA) & E1000_TIMINCA_INCVALUE_MASK; > >

Re: [PATCH] x86/arch_prctl/64: restore accidentally removed put_cpu in ARCH_SET_GS

On Tue, May 10, 2016 at 1:56 PM, Mateusz Guzik wrote: > This fixes 731e33e39a5b95ad770 "Remove FSBASE/GSBASE < 4G optimization" Indeed. How did that survive lockdep? Acked-by: Andy Lutomirski > > Signed-off-by: Mateusz Guzik > --- >

Re: [PATCH] x86/arch_prctl/64: restore accidentally removed put_cpu in ARCH_SET_GS

On Tue, May 10, 2016 at 1:56 PM, Mateusz Guzik wrote: > This fixes 731e33e39a5b95ad770 "Remove FSBASE/GSBASE < 4G optimization" Indeed. How did that survive lockdep? Acked-by: Andy Lutomirski > > Signed-off-by: Mateusz Guzik > --- > arch/x86/kernel/process_64.c | 1 + > 1 file changed, 1

[PATCH] x86/arch_prctl/64: restore accidentally removed put_cpu in ARCH_SET_GS

This fixes 731e33e39a5b95ad770 "Remove FSBASE/GSBASE < 4G optimization" Signed-off-by: Mateusz Guzik --- arch/x86/kernel/process_64.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index 4285f6a..6b16c36 100644

[PATCH] x86/arch_prctl/64: restore accidentally removed put_cpu in ARCH_SET_GS

This fixes 731e33e39a5b95ad770 "Remove FSBASE/GSBASE < 4G optimization" Signed-off-by: Mateusz Guzik --- arch/x86/kernel/process_64.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index 4285f6a..6b16c36 100644 ---

Re: [PATCH 1/3] intel_pstate: Clarify average performance computation

On Tuesday, May 10, 2016 12:58:04 PM Srinivas Pandruvada wrote: > On Tue, 2016-05-10 at 21:21 +0200, Rafael J. Wysocki wrote: > > On Tue, May 10, 2016 at 3:18 AM, Srinivas Pandruvada > > wrote: > > > > > > On Sat, 2016-05-07 at 01:44 +0200, Rafael J. Wysocki

Re: [PATCH 1/3] intel_pstate: Clarify average performance computation

On Tuesday, May 10, 2016 12:58:04 PM Srinivas Pandruvada wrote: > On Tue, 2016-05-10 at 21:21 +0200, Rafael J. Wysocki wrote: > > On Tue, May 10, 2016 at 3:18 AM, Srinivas Pandruvada > > wrote: > > > > > > On Sat, 2016-05-07 at 01:44 +0200, Rafael J. Wysocki wrote: > > > > > > > > From: Rafael

Re: [RFC PATCH 0/2] net: threadable napi poll loop

From: Rik van Riel Date: Tue, 10 May 2016 16:50:56 -0400 > On Tue, 2016-05-10 at 16:45 -0400, David Miller wrote: >> From: Paolo Abeni >> Date: Tue, 10 May 2016 22:22:50 +0200 >> >> > On Tue, 2016-05-10 at 09:08 -0700, Eric Dumazet wrote: >> >> On Tue,

Re: [RFC PATCH 0/2] net: threadable napi poll loop

From: Rik van Riel Date: Tue, 10 May 2016 16:50:56 -0400 > On Tue, 2016-05-10 at 16:45 -0400, David Miller wrote: >> From: Paolo Abeni >> Date: Tue, 10 May 2016 22:22:50 +0200 >> >> > On Tue, 2016-05-10 at 09:08 -0700, Eric Dumazet wrote: >> >> On Tue, 2016-05-10 at 18:03 +0200, Paolo Abeni

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Tue, 2016-05-10 at 16:45 -0400, David Miller wrote: > From: Paolo Abeni > Date: Tue, 10 May 2016 22:22:50 +0200 > > > On Tue, 2016-05-10 at 09:08 -0700, Eric Dumazet wrote: > >> On Tue, 2016-05-10 at 18:03 +0200, Paolo Abeni wrote: > >>  > >> > If a single core host is

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Tue, 2016-05-10 at 16:45 -0400, David Miller wrote: > From: Paolo Abeni > Date: Tue, 10 May 2016 22:22:50 +0200 > > > On Tue, 2016-05-10 at 09:08 -0700, Eric Dumazet wrote: > >> On Tue, 2016-05-10 at 18:03 +0200, Paolo Abeni wrote: > >>  > >> > If a single core host is under network flood,

Re: [RFC PATCH 0/2] net: threadable napi poll loop

Hello, On 10.05.2016 16:29, Eric Dumazet wrote: > On Tue, 2016-05-10 at 16:11 +0200, Paolo Abeni wrote: >> Currently, the softirq loop can be scheduled both inside the ksofirqd kernel >> thread and inside any running process. This makes nearly impossible for the >> process scheduler to balance in

Re: [RFC PATCH 0/2] net: threadable napi poll loop

Hello, On 10.05.2016 16:29, Eric Dumazet wrote: > On Tue, 2016-05-10 at 16:11 +0200, Paolo Abeni wrote: >> Currently, the softirq loop can be scheduled both inside the ksofirqd kernel >> thread and inside any running process. This makes nearly impossible for the >> process scheduler to balance in

Re: [RFC PATCH 0/2] net: threadable napi poll loop

From: Paolo Abeni Date: Tue, 10 May 2016 22:22:50 +0200 > On Tue, 2016-05-10 at 09:08 -0700, Eric Dumazet wrote: >> On Tue, 2016-05-10 at 18:03 +0200, Paolo Abeni wrote: >> >> > If a single core host is under network flood, i.e. ksoftirqd is >> > scheduled and it eventually

Re: [RFC PATCH 0/2] net: threadable napi poll loop

From: Paolo Abeni Date: Tue, 10 May 2016 22:22:50 +0200 > On Tue, 2016-05-10 at 09:08 -0700, Eric Dumazet wrote: >> On Tue, 2016-05-10 at 18:03 +0200, Paolo Abeni wrote: >> >> > If a single core host is under network flood, i.e. ksoftirqd is >> > scheduled and it eventually (after processing

Re: [PATCH BUGFIX] block: add missing group association in bio-cloning functions

On Tue, May 10, 2016 at 10:23:41PM +0200, Paolo Valente wrote: > diff --git a/include/linux/bio.h b/include/linux/bio.h > index 6b7481f..a9ff116 100644 > --- a/include/linux/bio.h > +++ b/include/linux/bio.h > @@ -527,11 +527,13 @@ extern unsigned int bvec_nr_vecs(unsigned short idx); > int

Re: [PATCH BUGFIX] block: add missing group association in bio-cloning functions

On Tue, May 10, 2016 at 10:23:41PM +0200, Paolo Valente wrote: > diff --git a/include/linux/bio.h b/include/linux/bio.h > index 6b7481f..a9ff116 100644 > --- a/include/linux/bio.h > +++ b/include/linux/bio.h > @@ -527,11 +527,13 @@ extern unsigned int bvec_nr_vecs(unsigned short idx); > int

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Tue, 2016-05-10 at 17:57 +0200, Thomas Gleixner wrote: > On Tue, 10 May 2016, Paolo Abeni wrote: > > Nice patch set and very promising results! > > > At this point we are not really sure if we should go with this simpler > > approach by putting NAPI itself into kthreads or leverage the

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On Tue, 2016-05-10 at 17:57 +0200, Thomas Gleixner wrote: > On Tue, 10 May 2016, Paolo Abeni wrote: > > Nice patch set and very promising results! > > > At this point we are not really sure if we should go with this simpler > > approach by putting NAPI itself into kthreads or leverage the

Re: [PATCH 2/3] memory-hotplug: more general validation of zone during online

On Tue, May 10, 2016 at 11:08:56AM -0700, Yasuaki Ishimatsu wrote: On Mon, 9 May 2016 12:53:38 -0500 Reza Arbab wrote: * If X is lower than Y, the onlined memory must lie at the end of X. * If X is higher than Y, the onlined memory must lie at the start of X. If

Re: [PATCH 2/3] memory-hotplug: more general validation of zone during online

On Tue, May 10, 2016 at 11:08:56AM -0700, Yasuaki Ishimatsu wrote: On Mon, 9 May 2016 12:53:38 -0500 Reza Arbab wrote: * If X is lower than Y, the onlined memory must lie at the end of X. * If X is higher than Y, the onlined memory must lie at the start of X. If memory address has hole,

[tip:perf/core] perf tools: Remove xrealloc and ALLOC_GROW

Commit-ID: 452e84012595d681f254a3a0d733fb0b18ffaf42 Gitweb: http://git.kernel.org/tip/452e84012595d681f254a3a0d733fb0b18ffaf42 Author: Masami Hiramatsu AuthorDate: Tue, 10 May 2016 14:48:01 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Tue,

[tip:perf/core] perf tools: Remove xrealloc and ALLOC_GROW

Commit-ID: 452e84012595d681f254a3a0d733fb0b18ffaf42 Gitweb: http://git.kernel.org/tip/452e84012595d681f254a3a0d733fb0b18ffaf42 Author: Masami Hiramatsu AuthorDate: Tue, 10 May 2016 14:48:01 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Tue, 10 May 2016 11:58:27 -0300 perf

[tip:perf/core] perf help: Do not use ALLOC_GROW in add_cmd_list

Commit-ID: 682f4f035e0fcffce511fe77a02a0f19f0996d70 Gitweb: http://git.kernel.org/tip/682f4f035e0fcffce511fe77a02a0f19f0996d70 Author: Masami Hiramatsu AuthorDate: Tue, 10 May 2016 14:47:53 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Tue,

[tip:perf/core] perf help: Do not use ALLOC_GROW in add_cmd_list

Commit-ID: 682f4f035e0fcffce511fe77a02a0f19f0996d70 Gitweb: http://git.kernel.org/tip/682f4f035e0fcffce511fe77a02a0f19f0996d70 Author: Masami Hiramatsu AuthorDate: Tue, 10 May 2016 14:47:53 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Tue, 10 May 2016 11:58:09 -0300 perf

[tip:perf/core] perf pmu: Make pmu_formats_string to check return value of strbuf

Commit-ID: 11db4e29bb50442ecef2173f325b7be4e7790025 Gitweb: http://git.kernel.org/tip/11db4e29bb50442ecef2173f325b7be4e7790025 Author: Masami Hiramatsu AuthorDate: Tue, 10 May 2016 14:47:44 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Tue,

[tip:perf/core] perf pmu: Make pmu_formats_string to check return value of strbuf

Commit-ID: 11db4e29bb50442ecef2173f325b7be4e7790025 Gitweb: http://git.kernel.org/tip/11db4e29bb50442ecef2173f325b7be4e7790025 Author: Masami Hiramatsu AuthorDate: Tue, 10 May 2016 14:47:44 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Tue, 10 May 2016 11:57:52 -0300 perf pmu:

[tip:perf/core] perf header: Make topology checkers to check return value of strbuf

Commit-ID: 642aadaa320bf9466fd12e3c0903977410bcb731 Gitweb: http://git.kernel.org/tip/642aadaa320bf9466fd12e3c0903977410bcb731 Author: Masami Hiramatsu AuthorDate: Tue, 10 May 2016 14:47:35 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Tue,

[tip:perf/core] perf header: Make topology checkers to check return value of strbuf

Commit-ID: 642aadaa320bf9466fd12e3c0903977410bcb731 Gitweb: http://git.kernel.org/tip/642aadaa320bf9466fd12e3c0903977410bcb731 Author: Masami Hiramatsu AuthorDate: Tue, 10 May 2016 14:47:35 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Tue, 10 May 2016 11:57:22 -0300 perf

Re: Getting rid of dynamic TASK_SIZE (on x86, at least)

On May 10, 2016 11:21 AM, "Oleg Nesterov" wrote: > > On 05/10, Andy Lutomirski wrote: > > > > - xol_add_vma: This one is weird: uprobes really is doing something > > behind the task's back, and the addresses need to be consistent with > > the address width. I'm not quite sure

Re: Getting rid of dynamic TASK_SIZE (on x86, at least)

On May 10, 2016 11:21 AM, "Oleg Nesterov" wrote: > > On 05/10, Andy Lutomirski wrote: > > > > - xol_add_vma: This one is weird: uprobes really is doing something > > behind the task's back, and the addresses need to be consistent with > > the address width. I'm not quite sure what to do here. >

[tip:perf/core] perf tools: Make alias handler to check return value of strbuf

Commit-ID: 70a6898fdc11272249622f77b034f47f1e9adb35 Gitweb: http://git.kernel.org/tip/70a6898fdc11272249622f77b034f47f1e9adb35 Author: Masami Hiramatsu AuthorDate: Tue, 10 May 2016 14:47:26 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Tue,

[tip:perf/core] perf tools: Make alias handler to check return value of strbuf

Commit-ID: 70a6898fdc11272249622f77b034f47f1e9adb35 Gitweb: http://git.kernel.org/tip/70a6898fdc11272249622f77b034f47f1e9adb35 Author: Masami Hiramatsu AuthorDate: Tue, 10 May 2016 14:47:26 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Tue, 10 May 2016 11:56:52 -0300 perf

[tip:perf/core] perf probe: Check the return value of strbuf APIs

Commit-ID: bf4d5f25c90bf2eca8671f2fc4e3d15919cd7f9c Gitweb: http://git.kernel.org/tip/bf4d5f25c90bf2eca8671f2fc4e3d15919cd7f9c Author: Masami Hiramatsu AuthorDate: Tue, 10 May 2016 14:47:07 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Tue,

[tip:perf/core] perf help: Make check_emacsclient_version to check strbuf APIs

Commit-ID: b72ca4039099e953f1ea2dbd58c201b14feb6605 Gitweb: http://git.kernel.org/tip/b72ca4039099e953f1ea2dbd58c201b14feb6605 Author: Masami Hiramatsu AuthorDate: Tue, 10 May 2016 14:47:17 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Tue,

[tip:perf/core] perf probe: Check the return value of strbuf APIs

Commit-ID: bf4d5f25c90bf2eca8671f2fc4e3d15919cd7f9c Gitweb: http://git.kernel.org/tip/bf4d5f25c90bf2eca8671f2fc4e3d15919cd7f9c Author: Masami Hiramatsu AuthorDate: Tue, 10 May 2016 14:47:07 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Tue, 10 May 2016 11:53:34 -0300 perf

[tip:perf/core] perf help: Make check_emacsclient_version to check strbuf APIs

Commit-ID: b72ca4039099e953f1ea2dbd58c201b14feb6605 Gitweb: http://git.kernel.org/tip/b72ca4039099e953f1ea2dbd58c201b14feb6605 Author: Masami Hiramatsu AuthorDate: Tue, 10 May 2016 14:47:17 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Tue, 10 May 2016 11:56:14 -0300 perf

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