Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

On 04/30/2016 02:36 PM, Vijay Pandurangan wrote: On Sat, Apr 30, 2016 at 5:29 PM, Ben Greear wrote: On 04/30/2016 02:13 PM, Vijay Pandurangan wrote: On Sat, Apr 30, 2016 at 4:59 PM, Ben Greear wrote: On 04/30/2016 12:54 PM, Tom

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

On 04/30/2016 02:36 PM, Vijay Pandurangan wrote: On Sat, Apr 30, 2016 at 5:29 PM, Ben Greear wrote: On 04/30/2016 02:13 PM, Vijay Pandurangan wrote: On Sat, Apr 30, 2016 at 4:59 PM, Ben Greear wrote: On 04/30/2016 12:54 PM, Tom Herbert wrote: We've put considerable effort into

RE: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover

> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Saturday, April 30, 2016 2:05 PM > To: KY Srinivasan > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; > o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com; >

RE: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover

> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Saturday, April 30, 2016 2:05 PM > To: KY Srinivasan > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; > o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com; > jasow...@redhat.com >

RE: [PATCH 1/3] Drivers: hv: balloon: don't crash when memory is added in non-sorted order

> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Saturday, April 30, 2016 2:03 PM > To: KY Srinivasan > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; > o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com; >

RE: [PATCH 1/3] Drivers: hv: balloon: don't crash when memory is added in non-sorted order

> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Saturday, April 30, 2016 2:03 PM > To: KY Srinivasan > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; > o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com; > jasow...@redhat.com >

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

On Sat, Apr 30, 2016 at 5:29 PM, Ben Greear wrote: > > > On 04/30/2016 02:13 PM, Vijay Pandurangan wrote: >> >> On Sat, Apr 30, 2016 at 4:59 PM, Ben Greear >> wrote: >>> >>> >>> >>> On 04/30/2016 12:54 PM, Tom Herbert wrote: We've

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

On Sat, Apr 30, 2016 at 5:29 PM, Ben Greear wrote: > > > On 04/30/2016 02:13 PM, Vijay Pandurangan wrote: >> >> On Sat, Apr 30, 2016 at 4:59 PM, Ben Greear >> wrote: >>> >>> >>> >>> On 04/30/2016 12:54 PM, Tom Herbert wrote: We've put considerable effort into cleaning up the

[PATCH 2/4] staging: i4l: act2000: do not assign in if

It is not the kernel coding style to assign values to some variable in if statement. Split them up into different statements. Signed-off-by: Sudip Mukherjee --- drivers/staging/i4l/act2000/act2000_isa.c | 9 ++--- 1 file changed, 6 insertions(+), 3

[PATCH 2/4] staging: i4l: act2000: do not assign in if

It is not the kernel coding style to assign values to some variable in if statement. Split them up into different statements. Signed-off-by: Sudip Mukherjee --- drivers/staging/i4l/act2000/act2000_isa.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git

[PATCH 4/4] staging: i4l: act2000: remove extra space

It is not kernel coding style to give an extra space after a cast. We get warned about it by checkpatch. Signed-off-by: Sudip Mukherjee --- drivers/staging/i4l/act2000/act2000_isa.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git

[PATCH 1/4] staging: i4l: act2000: fix use of return

checkpatch warns that return is not a function and as such the brace after it is not required. Signed-off-by: Sudip Mukherjee --- drivers/staging/i4l/act2000/act2000_isa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 3/4] staging: i4l: act2000: remove blank line after brace

checkpatch complains about an extra blank line after an opening brace. Signed-off-by: Sudip Mukherjee --- drivers/staging/i4l/act2000/act2000_isa.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/i4l/act2000/act2000_isa.c

[PATCH 4/4] staging: i4l: act2000: remove extra space

It is not kernel coding style to give an extra space after a cast. We get warned about it by checkpatch. Signed-off-by: Sudip Mukherjee --- drivers/staging/i4l/act2000/act2000_isa.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git

[PATCH 1/4] staging: i4l: act2000: fix use of return

checkpatch warns that return is not a function and as such the brace after it is not required. Signed-off-by: Sudip Mukherjee --- drivers/staging/i4l/act2000/act2000_isa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/i4l/act2000/act2000_isa.c

[PATCH 3/4] staging: i4l: act2000: remove blank line after brace

checkpatch complains about an extra blank line after an opening brace. Signed-off-by: Sudip Mukherjee --- drivers/staging/i4l/act2000/act2000_isa.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/i4l/act2000/act2000_isa.c b/drivers/staging/i4l/act2000/act2000_isa.c index

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

On 04/30/2016 02:13 PM, Vijay Pandurangan wrote: On Sat, Apr 30, 2016 at 4:59 PM, Ben Greear wrote: On 04/30/2016 12:54 PM, Tom Herbert wrote: We've put considerable effort into cleaning up the checksum interface to make it as unambiguous as possible, please be

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

On 04/30/2016 02:13 PM, Vijay Pandurangan wrote: On Sat, Apr 30, 2016 at 4:59 PM, Ben Greear wrote: On 04/30/2016 12:54 PM, Tom Herbert wrote: We've put considerable effort into cleaning up the checksum interface to make it as unambiguous as possible, please be very careful to follow it.

[RFC PATCH 6/7] ASoC: mioa701_wm9713: convert to new ac97 bus

Convert to the new auto-probing ac97 bus, which changes the device name. Signed-off-by: Robert Jarzmik --- sound/soc/pxa/mioa701_wm9713.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/pxa/mioa701_wm9713.c

[RFC PATCH 6/7] ASoC: mioa701_wm9713: convert to new ac97 bus

Convert to the new auto-probing ac97 bus, which changes the device name. Signed-off-by: Robert Jarzmik --- sound/soc/pxa/mioa701_wm9713.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/pxa/mioa701_wm9713.c b/sound/soc/pxa/mioa701_wm9713.c index

Re: [Cluster-devel] [PATCH 0/2] scop GFP_NOFS api

On Fri, Apr 29 2016, Steven Whitehouse wrote: > Hi, > > On 29/04/16 06:35, NeilBrown wrote: >> If we could similarly move evict() into kswapd (and I believe we can) >> then most file systems would do nothing in reclaim context that >> interferes with allocation context. > evict() is an issue, but

Re: [Cluster-devel] [PATCH 0/2] scop GFP_NOFS api

On Fri, Apr 29 2016, Steven Whitehouse wrote: > Hi, > > On 29/04/16 06:35, NeilBrown wrote: >> If we could similarly move evict() into kswapd (and I believe we can) >> then most file systems would do nothing in reclaim context that >> interferes with allocation context. > evict() is an issue, but

[RFC PATCH 5/7] ARM: pxa: mioa701 remove wm9713 from platform devices

As the ac97 autoprobing is introduced, remove the manually added wm9713 device. Signed-off-by: Robert Jarzmik --- arch/arm/mach-pxa/mioa701.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-pxa/mioa701.c b/arch/arm/mach-pxa/mioa701.c index

Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

(Pulling in efifb maintainer, Peter) On Fri, 29 Apr, at 06:31:19PM, Bjorn Helgaas wrote: > > The efifb.c driver doesn't do anything at all with PCI (it includes > linux/pci.h, but probably doesn't need it). That's part of what I'm > suggesting -- if it *did* register as a PCI device driver,

[RFC PATCH 5/7] ARM: pxa: mioa701 remove wm9713 from platform devices

As the ac97 autoprobing is introduced, remove the manually added wm9713 device. Signed-off-by: Robert Jarzmik --- arch/arm/mach-pxa/mioa701.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-pxa/mioa701.c b/arch/arm/mach-pxa/mioa701.c index 38a96a193dc4..e69e20febf83 100644 ---

Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

(Pulling in efifb maintainer, Peter) On Fri, 29 Apr, at 06:31:19PM, Bjorn Helgaas wrote: > > The efifb.c driver doesn't do anything at all with PCI (it includes > linux/pci.h, but probably doesn't need it). That's part of what I'm > suggesting -- if it *did* register as a PCI device driver,

[RFC PATCH 3/7] ASoC: wm9713: add ac97 new bus support

Add support for the new ac97 bus model, where devices are automatically discovered on AC-Links. Signed-off-by: Robert Jarzmik --- sound/soc/codecs/wm9713.c | 62 ++- 1 file changed, 56 insertions(+), 6 deletions(-) diff --git

[RFC PATCH 4/7] ASoC: pxa: switch to new ac97 bus support

Switch to the new ac97 bus support in sound/ac97 instead of the legacy snd_ac97 one. Signed-off-by: Robert Jarzmik --- include/sound/pxa2xx-lib.h | 14 -- sound/arm/Kconfig | 1 - sound/arm/pxa2xx-ac97-lib.c | 31 +++

[RFC PATCH 2/7] ALSA: ac97: add an ac97 bus

AC97 is a bus for sound usage. It enables for a AC97 AC-Link to link one controller to 0 to 4 AC97 codecs. The goal of this new implementation is to implement a device/driver model for AC97, with an automatic scan of the bus and automatic discovery of AC97 codec devices. Signed-off-by: Robert

[RFC PATCH 3/7] ASoC: wm9713: add ac97 new bus support

Add support for the new ac97 bus model, where devices are automatically discovered on AC-Links. Signed-off-by: Robert Jarzmik --- sound/soc/codecs/wm9713.c | 62 ++- 1 file changed, 56 insertions(+), 6 deletions(-) diff --git

[RFC PATCH 4/7] ASoC: pxa: switch to new ac97 bus support

Switch to the new ac97 bus support in sound/ac97 instead of the legacy snd_ac97 one. Signed-off-by: Robert Jarzmik --- include/sound/pxa2xx-lib.h | 14 -- sound/arm/Kconfig | 1 - sound/arm/pxa2xx-ac97-lib.c | 31 +++ sound/soc/pxa/Kconfig

[RFC PATCH 2/7] ALSA: ac97: add an ac97 bus

AC97 is a bus for sound usage. It enables for a AC97 AC-Link to link one controller to 0 to 4 AC97 codecs. The goal of this new implementation is to implement a device/driver model for AC97, with an automatic scan of the bus and automatic discovery of AC97 codec devices. Signed-off-by: Robert

[RFC PATCH 7/7] ASoC: add new ac97 bus support

Add the new ac97 bus support, with ac97 bus automatic probing. Signed-off-by: Robert Jarzmik --- sound/Kconfig | 7 +++ sound/Makefile| 1 + sound/soc/Kconfig | 4 3 files changed, 12 insertions(+) diff --git a/sound/Kconfig b/sound/Kconfig index

[RFC PATCH 1/7] ALSA: ac97: split out the generic ac97 registers

Split out from the ac97_codec.h the ac97 generic registers, which can be used by a codec, typically a generic ac97 codec, and by the ac97 bus, to scan an ac97 AC-Link. Signed-off-by: Robert Jarzmik --- include/sound/ac97/regs.h | 262

[RFC PATCH 0/7] AC97 device/driver model revamp

It all started in the pxa device-tree submission here : https://lkml.org/lkml/2016/2/25/965 It will be maintained in : git fetch https://github.com/rjarzmik/linux.git work/ac97 And now it transformed into this RFC, which would bring a ground for AC'97 devices closer to the linux

[RFC PATCH 7/7] ASoC: add new ac97 bus support

Add the new ac97 bus support, with ac97 bus automatic probing. Signed-off-by: Robert Jarzmik --- sound/Kconfig | 7 +++ sound/Makefile| 1 + sound/soc/Kconfig | 4 3 files changed, 12 insertions(+) diff --git a/sound/Kconfig b/sound/Kconfig index 5a240e050ae6..83d67eae3580

[RFC PATCH 1/7] ALSA: ac97: split out the generic ac97 registers

Split out from the ac97_codec.h the ac97 generic registers, which can be used by a codec, typically a generic ac97 codec, and by the ac97 bus, to scan an ac97 AC-Link. Signed-off-by: Robert Jarzmik --- include/sound/ac97/regs.h | 262 +

[RFC PATCH 0/7] AC97 device/driver model revamp

It all started in the pxa device-tree submission here : https://lkml.org/lkml/2016/2/25/965 It will be maintained in : git fetch https://github.com/rjarzmik/linux.git work/ac97 And now it transformed into this RFC, which would bring a ground for AC'97 devices closer to the linux

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

On Sat, Apr 30, 2016 at 4:59 PM, Ben Greear wrote: > > > On 04/30/2016 12:54 PM, Tom Herbert wrote: >> >> We've put considerable effort into cleaning up the checksum interface >> to make it as unambiguous as possible, please be very careful to >> follow it. Broken

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

On Sat, Apr 30, 2016 at 4:59 PM, Ben Greear wrote: > > > On 04/30/2016 12:54 PM, Tom Herbert wrote: >> >> We've put considerable effort into cleaning up the checksum interface >> to make it as unambiguous as possible, please be very careful to >> follow it. Broken checksum processing is really

Re: [RFC][PATCH 0/6] Enhanced file stat system call

On Fri, 2016-04-29 at 13:57 +0100, David Howells wrote: > Implement a new system call to provide enhanced file stats.  The patches can > be found here: > > > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=xstat > > > === > DESCRIPTION > === > >

Re: [RFC][PATCH 0/6] Enhanced file stat system call

On Fri, 2016-04-29 at 13:57 +0100, David Howells wrote: > Implement a new system call to provide enhanced file stats.  The patches can > be found here: > > > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=xstat > > > === > DESCRIPTION > === > >

Re: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover

On Tue, Apr 05, 2016 at 04:57:40PM -0700, K. Y. Srinivasan wrote: > From: Vitaly Kuznetsov > > Hyper-V VMs can be replicated to another hosts and there is a feature to > set different IP for replicas, it is called 'Failover TCP/IP'. When > such guest starts Hyper-V host

Re: [PATCH 1/8] Drivers: hv: kvp: fix IP Failover

On Tue, Apr 05, 2016 at 04:57:40PM -0700, K. Y. Srinivasan wrote: > From: Vitaly Kuznetsov > > Hyper-V VMs can be replicated to another hosts and there is a feature to > set different IP for replicas, it is called 'Failover TCP/IP'. When > such guest starts Hyper-V host sends it

[PATCH] libnvdimm, pfn: fix memmap reservation sizing

When configuring a pfn-device instance to allocate the memmap array it needs to account for the fact that vmemmap_populate_hugepages() allocates struct page blocks in HPAGE_SIZE chunks. We need to align the reserved area size to 2MB otherwise arch_add_memory() runs out of memory while

[PATCH] libnvdimm, pfn: fix memmap reservation sizing

When configuring a pfn-device instance to allocate the memmap array it needs to account for the fact that vmemmap_populate_hugepages() allocates struct page blocks in HPAGE_SIZE chunks. We need to align the reserved area size to 2MB otherwise arch_add_memory() runs out of memory while

Re: [PATCH 1/3] Drivers: hv: balloon: don't crash when memory is added in non-sorted order

On Fri, Apr 29, 2016 at 11:45:17AM -0700, K. Y. Srinivasan wrote: > From: Vitaly Kuznetsov > > When we iterate through all HA regions in handle_pg_range() we have an > assumption that all these regions are sorted in the list and the > 'start_pfn >= has->end_pfn' check is

Re: [PATCH 1/3] Drivers: hv: balloon: don't crash when memory is added in non-sorted order

On Fri, Apr 29, 2016 at 11:45:17AM -0700, K. Y. Srinivasan wrote: > From: Vitaly Kuznetsov > > When we iterate through all HA regions in handle_pg_range() we have an > assumption that all these regions are sorted in the list and the > 'start_pfn >= has->end_pfn' check is enough to find the

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

On 04/30/2016 12:54 PM, Tom Herbert wrote: We've put considerable effort into cleaning up the checksum interface to make it as unambiguous as possible, please be very careful to follow it. Broken checksum processing is really hard to detect and debug. CHECKSUM_UNNECESSARY means that some

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

On 04/30/2016 12:54 PM, Tom Herbert wrote: We've put considerable effort into cleaning up the checksum interface to make it as unambiguous as possible, please be very careful to follow it. Broken checksum processing is really hard to detect and debug. CHECKSUM_UNNECESSARY means that some

Re: [PATCH] parport: parport_pc: PCI SIO access should also depend on SIO option

On Wed, Apr 20, 2016 at 01:09:51PM +0530, Sudip Mukherjee wrote: > From: "Maciej S. Szmigiero" > > CONFIG_PARPORT_PC_SUPERIO toggles Super IO chip support in parport_pc > code, however only code accessing SIO chip via ISA (or LPC) bus was > conditional on it. > >

Re: [PATCH] parport: parport_pc: PCI SIO access should also depend on SIO option

On Wed, Apr 20, 2016 at 01:09:51PM +0530, Sudip Mukherjee wrote: > From: "Maciej S. Szmigiero" > > CONFIG_PARPORT_PC_SUPERIO toggles Super IO chip support in parport_pc > code, however only code accessing SIO chip via ISA (or LPC) bus was > conditional on it. > > This patch makes SIO chip

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

Thomas Gleixner wrote: > I'll send a patch to replace hash_64 and hash_32. Before you do that, could we look for a way to tweak the constants in the existing hash? It seems the basic "take the high bits of x * K" algorithm is actually a decent hash function if K is chosen properly, and has a

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

Thomas Gleixner wrote: > I'll send a patch to replace hash_64 and hash_32. Before you do that, could we look for a way to tweak the constants in the existing hash? It seems the basic "take the high bits of x * K" algorithm is actually a decent hash function if K is chosen properly, and has a

[PATCH 1/1] gpio: xgene: Enable ACPI support for X-Gene GFC GPIO driver

This patch enables ACPI support for X-Gene GFC GPIO driver. Signed-off-by: Duc Dang --- drivers/gpio/gpio-xgene.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/gpio/gpio-xgene.c b/drivers/gpio/gpio-xgene.c index 0dc9161..c00c408 100644 ---

[PATCH 1/1] gpio: xgene: Enable ACPI support for X-Gene GFC GPIO driver

This patch enables ACPI support for X-Gene GFC GPIO driver. Signed-off-by: Duc Dang --- drivers/gpio/gpio-xgene.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/gpio/gpio-xgene.c b/drivers/gpio/gpio-xgene.c index 0dc9161..c00c408 100644 --- a/drivers/gpio/gpio-xgene.c +++

Re: [PATCH] scripts/dtc: Update to upstream version 53bf130b1cdd

On Fri, Apr 29, 2016 at 3:51 AM, Geert Uytterhoeven wrote: > Hi Rob, > > On Tue, Mar 8, 2016 at 9:00 AM, Rob Herring wrote: >> On Mon, Mar 7, 2016 at 5:27 AM, Geert Uytterhoeven >> wrote: >>> On Fri, Mar 4, 2016 at 4:13 PM, Rob

Re: [PATCH] scripts/dtc: Update to upstream version 53bf130b1cdd

On Fri, Apr 29, 2016 at 3:51 AM, Geert Uytterhoeven wrote: > Hi Rob, > > On Tue, Mar 8, 2016 at 9:00 AM, Rob Herring wrote: >> On Mon, Mar 7, 2016 at 5:27 AM, Geert Uytterhoeven >> wrote: >>> On Fri, Mar 4, 2016 at 4:13 PM, Rob Herring wrote: Sync to upstream dtc commit 53bf130b1cdd

Re: efi_enabled(EFI_PARAVIRT) use

On Sat, 30 Apr, at 10:14:42PM, Shannon Zhao wrote: > Sure. How should I add this change? Rework this patch or add new one on > top of it? Rework this patch, please. > Yes, in this patch we could set EFI_RUNTIME_SERVICES flag in > fdt_find_hyper_node instead of setting EFI_PARAVIRT flag, and

Re: efi_enabled(EFI_PARAVIRT) use

On Sat, 30 Apr, at 10:14:42PM, Shannon Zhao wrote: > Sure. How should I add this change? Rework this patch or add new one on > top of it? Rework this patch, please. > Yes, in this patch we could set EFI_RUNTIME_SERVICES flag in > fdt_find_hyper_node instead of setting EFI_PARAVIRT flag, and

Re: [PATCH] scripts/dtc: dt_to_config - report kernel config options for a devicetree

On Fri, Apr 29, 2016 at 1:39 AM, Gaurav Minocha wrote: > On Thu, Apr 28, 2016 at 3:32 PM, Rob Herring wrote: >> On Thu, Apr 28, 2016 at 4:46 PM, Frank Rowand wrote: >>> From: Frank Rowand >>> >>>

Re: [PATCH] scripts/dtc: dt_to_config - report kernel config options for a devicetree

On Fri, Apr 29, 2016 at 1:39 AM, Gaurav Minocha wrote: > On Thu, Apr 28, 2016 at 3:32 PM, Rob Herring wrote: >> On Thu, Apr 28, 2016 at 4:46 PM, Frank Rowand wrote: >>> From: Frank Rowand >>> >>> Determining which kernel config options need to be enabled for a >>> given devicetree can be a

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

[oops – resending this because I was using gmail in HTML mode before by accident] There was a discussion on a separate thread about this. I agree with Sabrina fully. I believe veth should provide an abstraction layer that correctly emulates a physical network in all ways. Consider an environment

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

[oops – resending this because I was using gmail in HTML mode before by accident] There was a discussion on a separate thread about this. I agree with Sabrina fully. I believe veth should provide an abstraction layer that correctly emulates a physical network in all ways. Consider an environment

Re: [PATCH] efibc: avoid stack overflow warning

On Fri, 29 Apr, at 07:48:31PM, Arnd Bergmann wrote: > gcc complains about a newly added file for the EFI Bootloader Control: > > drivers/firmware/efi/efibc.c: In function 'efibc_set_variable': > drivers/firmware/efi/efibc.c:53:1: error: the frame size of 2272 bytes is > larger than 1024 bytes

Re: [PATCH] efibc: avoid stack overflow warning

On Fri, 29 Apr, at 07:48:31PM, Arnd Bergmann wrote: > gcc complains about a newly added file for the EFI Bootloader Control: > > drivers/firmware/efi/efibc.c: In function 'efibc_set_variable': > drivers/firmware/efi/efibc.c:53:1: error: the frame size of 2272 bytes is > larger than 1024 bytes

[PATCH] vfs: use RCU_INIT_POINTER when NULLing

It is always safe to use RCU_INIT_POINTER to NULL a pointer. This results in slightly smaller/faster code. The following semantic patch used: @@ @@ - rcu_assign_pointer + RCU_INIT_POINTER (..., NULL) Signed-off-by: Muhammad Falak R Wani --- fs/file.c | 6 +++--- 1

[PATCH] vfs: use RCU_INIT_POINTER when NULLing

It is always safe to use RCU_INIT_POINTER to NULL a pointer. This results in slightly smaller/faster code. The following semantic patch used: @@ @@ - rcu_assign_pointer + RCU_INIT_POINTER (..., NULL) Signed-off-by: Muhammad Falak R Wani --- fs/file.c | 6 +++--- 1 file changed, 3

Re: [tip:efi/core] efibc: Add EFI Bootloader Control module

On Fri, 29 Apr, at 03:53:39PM, Jeremy Compostella wrote: > From ef3a2941769e59b11d1ec36117209dc4c90c7cf9 Mon Sep 17 00:00:00 2001 > From: Jeremy Compostella > Date: Fri, 29 Apr 2016 15:29:59 +0200 > Subject: [PATCH] efibc: fix excessive stack footprint warning > >

Re: [tip:efi/core] efibc: Add EFI Bootloader Control module

On Fri, 29 Apr, at 03:53:39PM, Jeremy Compostella wrote: > From ef3a2941769e59b11d1ec36117209dc4c90c7cf9 Mon Sep 17 00:00:00 2001 > From: Jeremy Compostella > Date: Fri, 29 Apr 2016 15:29:59 +0200 > Subject: [PATCH] efibc: fix excessive stack footprint warning > > Use dynamic memory allocation

Re: [PATCH 1/3] phy: rockchip-usb: should be a child device of the GRF

Hi Kishon, Am Dienstag, 19. April 2016, 08:13:47 schrieb Heiko Stübner: > Hi Kishon. > > Am Donnerstag, 31. März 2016, 15:43:30 schrieb Heiko Stuebner: > > The usb-phy is fully enclosed in the general register files (GRF). > > Therefore as seen from the device-tree it shouldn't be a separate > >

Re: [PATCH 1/3] phy: rockchip-usb: should be a child device of the GRF

Hi Kishon, Am Dienstag, 19. April 2016, 08:13:47 schrieb Heiko Stübner: > Hi Kishon. > > Am Donnerstag, 31. März 2016, 15:43:30 schrieb Heiko Stuebner: > > The usb-phy is fully enclosed in the general register files (GRF). > > Therefore as seen from the device-tree it shouldn't be a separate > >

Re: ERROR: "vring_del_virtqueue" [drivers/misc/mic/vop/vop.ko] undefined!

On 04/30/16 11:56, Sudeep Dutt wrote: > On Sat, 2016-04-30 at 09:49 -0700, Randy Dunlap wrote: >> On 04/18/16 08:05, kbuild test robot wrote: >>> Hi Sudeep, >>> >>> FYI, the error/warning still remains. >> >> and still happens in linux-next-20160428... >> > > The patch to fix this build failure

Re: ERROR: "vring_del_virtqueue" [drivers/misc/mic/vop/vop.ko] undefined!

On 04/30/16 11:56, Sudeep Dutt wrote: > On Sat, 2016-04-30 at 09:49 -0700, Randy Dunlap wrote: >> On 04/18/16 08:05, kbuild test robot wrote: >>> Hi Sudeep, >>> >>> FYI, the error/warning still remains. >> >> and still happens in linux-next-20160428... >> > > The patch to fix this build failure

Re: [tip:efi/core] efibc: Add EFI Bootloader Control module

On Sat, 30 Apr, at 10:33:32AM, Jeremy Compostella wrote: > Ingo Molnar writes: > > > > Hm, can reboot notifiers do non-atomic allocations? > The reboot notifier chain is a blocking notifier chain. AFAIK, it > allows non-atomic allocation, right ? I would assume so, yes. > >

Re: [tip:efi/core] efibc: Add EFI Bootloader Control module

On Sat, 30 Apr, at 10:33:32AM, Jeremy Compostella wrote: > Ingo Molnar writes: > > > > Hm, can reboot notifiers do non-atomic allocations? > The reboot notifier chain is a blocking notifier chain. AFAIK, it > allows non-atomic allocation, right ? I would assume so, yes. > > Why is efivar_entry

Re: [PATCH v2] lib: make sg_pool tristate instead of bool

[Re: [PATCH v2] lib: make sg_pool tristate instead of bool] On 28/04/2016 (Thu 08:51) Christoph Hellwig wrote: > On Wed, Apr 27, 2016 at 07:54:19PM -0400, Martin K. Petersen wrote: > > Somebody please review... > > The patch is useless, we should just ignore it. I'll be the 1st to admit the

Re: [PATCH v2] lib: make sg_pool tristate instead of bool

[Re: [PATCH v2] lib: make sg_pool tristate instead of bool] On 28/04/2016 (Thu 08:51) Christoph Hellwig wrote: > On Wed, Apr 27, 2016 at 07:54:19PM -0400, Martin K. Petersen wrote: > > Somebody please review... > > The patch is useless, we should just ignore it. I'll be the 1st to admit the

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

We've put considerable effort into cleaning up the checksum interface to make it as unambiguous as possible, please be very careful to follow it. Broken checksum processing is really hard to detect and debug. CHECKSUM_UNNECESSARY means that some number of _specific_ checksums (indicated by

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

We've put considerable effort into cleaning up the checksum interface to make it as unambiguous as possible, please be very careful to follow it. Broken checksum processing is really hard to detect and debug. CHECKSUM_UNNECESSARY means that some number of _specific_ checksums (indicated by

Re: __napi_alloc_skb failures locking up the box

On Sat, 2016-04-30 at 22:24 +0300, Aaro Koskinen wrote: > Hi, > > I have old NAS box (Thecus N2100) with 512 MB RAM, where rsync from NFS -> > disk reliably results in temporary out-of-memory conditions. > > When this happens the dmesg gets flooded with below logs. If the serial > console

Re: __napi_alloc_skb failures locking up the box

On Sat, 2016-04-30 at 22:24 +0300, Aaro Koskinen wrote: > Hi, > > I have old NAS box (Thecus N2100) with 512 MB RAM, where rsync from NFS -> > disk reliably results in temporary out-of-memory conditions. > > When this happens the dmesg gets flooded with below logs. If the serial > console

Re: [PATCH 3.16 000/217] 3.16.35-rc1 review

On Thu, 2016-04-28 at 21:16 -0700, Guenter Roeck wrote: > On 04/26/2016 04:02 PM, Ben Hutchings wrote: > > > > This is the start of the stable review cycle for the 3.16.35 release. > > There are 217 patches in this series, which will be posted as responses > > to this one.  If anyone has any

Re: [PATCH 3.16 000/217] 3.16.35-rc1 review

On Thu, 2016-04-28 at 21:16 -0700, Guenter Roeck wrote: > On 04/26/2016 04:02 PM, Ben Hutchings wrote: > > > > This is the start of the stable review cycle for the 3.16.35 release. > > There are 217 patches in this series, which will be posted as responses > > to this one.  If anyone has any

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

On 04/30/2016 11:33 AM, Ben Hutchings wrote: On Thu, 2016-04-28 at 12:29 +0200, Sabrina Dubroca wrote: Hello, http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=commitdiff;h=8153e983c0e5eba1aafe1fc296248ed2a553f1ac;hp=454b07405d694dad52e7f41af5816eed0190da8a Actually, no, this is not

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

On 04/30/2016 11:33 AM, Ben Hutchings wrote: On Thu, 2016-04-28 at 12:29 +0200, Sabrina Dubroca wrote: Hello, http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=commitdiff;h=8153e983c0e5eba1aafe1fc296248ed2a553f1ac;hp=454b07405d694dad52e7f41af5816eed0190da8a Actually, no, this is not

Re: [PATCH 3.16 106/217] sd: disable discard_zeroes_data for UNMAP

On Fri, 2016-04-29 at 01:00 -0300, Rafael David Tinoco wrote: > Actually, It was an objection. [...] OK, then I'll drop all these commits from the queue: 7985090aa020 sd: disable discard_zeroes_data for UNMAP 397737223c59 sd: Make discard granularity match logical block size when LBPRZ=1

Re: [PATCH 3.16 106/217] sd: disable discard_zeroes_data for UNMAP

On Fri, 2016-04-29 at 01:00 -0300, Rafael David Tinoco wrote: > Actually, It was an objection. [...] OK, then I'll drop all these commits from the queue: 7985090aa020 sd: disable discard_zeroes_data for UNMAP 397737223c59 sd: Make discard granularity match logical block size when LBPRZ=1

__napi_alloc_skb failures locking up the box

Hi, I have old NAS box (Thecus N2100) with 512 MB RAM, where rsync from NFS -> disk reliably results in temporary out-of-memory conditions. When this happens the dmesg gets flooded with below logs. If the serial console logging is enabled, this will lock up the box completely and the backup is

__napi_alloc_skb failures locking up the box

Hi, I have old NAS box (Thecus N2100) with 512 MB RAM, where rsync from NFS -> disk reliably results in temporary out-of-memory conditions. When this happens the dmesg gets flooded with below logs. If the serial console logging is enabled, this will lock up the box completely and the backup is

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

On Thu, 2016-04-28 at 12:29 +0200, Sabrina Dubroca wrote: > Hello, > > 2016-04-27, 17:14:44 -0700, Ben Greear wrote: > > > > On 04/27/2016 05:00 PM, Hannes Frederic Sowa wrote: > > > > > > Hi Ben, > > > > > > On Wed, Apr 27, 2016, at 20:07, Ben Hutchings wrote: > > > > > > > > On Wed,

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

On Thu, 2016-04-28 at 12:29 +0200, Sabrina Dubroca wrote: > Hello, > > 2016-04-27, 17:14:44 -0700, Ben Greear wrote: > > > > On 04/27/2016 05:00 PM, Hannes Frederic Sowa wrote: > > > > > > Hi Ben, > > > > > > On Wed, Apr 27, 2016, at 20:07, Ben Hutchings wrote: > > > > > > > > On Wed,

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

On Thu, 2016-04-28 at 06:45 -0700, Ben Greear wrote: > > On 04/28/2016 03:29 AM, Sabrina Dubroca wrote: [...] > > Your use case is invalid, it just happened to work because of a > > bug.  If you want the stack to fill checksums so that you want capture > > and reinject packets, you have to

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

On Thu, 2016-04-28 at 06:45 -0700, Ben Greear wrote: > > On 04/28/2016 03:29 AM, Sabrina Dubroca wrote: [...] > > Your use case is invalid, it just happened to work because of a > > bug.  If you want the stack to fill checksums so that you want capture > > and reinject packets, you have to

Re: [PATCH] Cleanup __pvclock_read_cycles to remove useless variables

On Sat, Apr 30, 2016 at 10:47:49AM -0700, Andy Lutomirski wrote: > Take a look at vread_pvclock. I decided that __pvclock_read_cycles > was too ugly to use and was very slow and I just gave up and rewrote > it. Should we kill __pvclock_read_cycles in favor of vread_pvclock? It looks doable at a

Re: [PATCH] Cleanup __pvclock_read_cycles to remove useless variables

On Sat, Apr 30, 2016 at 10:47:49AM -0700, Andy Lutomirski wrote: > Take a look at vread_pvclock. I decided that __pvclock_read_cycles > was too ugly to use and was very slow and I just gave up and rewrote > it. Should we kill __pvclock_read_cycles in favor of vread_pvclock? It looks doable at a

[PATCH v2] rtc: stmp3xxx: print message on error

stmp3xxx_wdt_register() can fail as platform_device_alloc() or platform_device_add() can fail. But when it fails it failed silently. Lets print out an error message on failure so that user will atlest know that there was some error. Signed-off-by: Sudip Mukherjee

[PATCH v2] rtc: stmp3xxx: print message on error

stmp3xxx_wdt_register() can fail as platform_device_alloc() or platform_device_add() can fail. But when it fails it failed silently. Lets print out an error message on failure so that user will atlest know that there was some error. Signed-off-by: Sudip Mukherjee --- v1 - returned error while

[PATCH] drm/amdgpu: Replace rcu_assign_pointer() with RCU_INIT_POINTER()

The rcu_assign_pointer() ensures that the initialization of a structure is carried out before storing a pointer to that structre. It is always safe to use RCU_INIT_POINTER() to NULL a pointer, instead of rcu_assign_pointer(). This results in slightly smaller/faster code. The following semantic

[PATCH] drm/amdgpu: Replace rcu_assign_pointer() with RCU_INIT_POINTER()

The rcu_assign_pointer() ensures that the initialization of a structure is carried out before storing a pointer to that structre. It is always safe to use RCU_INIT_POINTER() to NULL a pointer, instead of rcu_assign_pointer(). This results in slightly smaller/faster code. The following semantic

<    1   2   3   4   >