RE: [PATCH -v3 00/10] THP swap: Delay splitting THP during swapping out

>> >> - Avoid CPU time for splitting, collapsing THP across swap out/in. > >Yes, if you want, please give us how bad it is. > It could be pretty bad. In an experiment with THP turned on and we enter swap, 50% of the cpu are spent in the page compaction path. So if we could deal with units of

RE: [PATCH -v3 00/10] THP swap: Delay splitting THP during swapping out

>> >> - Avoid CPU time for splitting, collapsing THP across swap out/in. > >Yes, if you want, please give us how bad it is. > It could be pretty bad. In an experiment with THP turned on and we enter swap, 50% of the cpu are spent in the page compaction path. So if we could deal with units of

Re: [PATCH v2] bnx2: Reset device during driver initialization

On 09/13/16 at 11:25am, David Miller wrote: > > Just to be clear, I did actually apply this v2 of the patch > rather than the initial version.:) Thanks a lot!

Re: [PATCH v2] bnx2: Reset device during driver initialization

On 09/13/16 at 11:25am, David Miller wrote: > > Just to be clear, I did actually apply this v2 of the patch > rather than the initial version.:) Thanks a lot!

Re: [PATCH v2 26/33] Task fork and exit for rdtgroup

On Tue, Sep 13, 2016 at 04:13:04PM -0700, Dave Hansen wrote: > Yikes, is this a new global lock and possible atomic_inc() on a shared > variable in the fork() path? Has there been any performance or > scalability testing done on this code? > > That mutex could be a disaster for fork() once the

Re: [PATCH v2 26/33] Task fork and exit for rdtgroup

On Tue, Sep 13, 2016 at 04:13:04PM -0700, Dave Hansen wrote: > Yikes, is this a new global lock and possible atomic_inc() on a shared > variable in the fork() path? Has there been any performance or > scalability testing done on this code? > > That mutex could be a disaster for fork() once the

Re: [PATCH 1/2] PCI: save and restore device state during bus reset

On 9/13/2016 7:20 PM, Sinan Kaya wrote: > On 9/13/2016 5:53 PM, Bjorn Helgaas wrote: >>> + pci_bus_restore(dev->bus); >> This path eventually writes the Bridge Control register: >> >> pci_reset_bridge_secondary_bus >> pcibios_reset_secondary_bus >> pci_reset_secondary_bus >>

Re: [PATCH 1/2] PCI: save and restore device state during bus reset

On 9/13/2016 7:20 PM, Sinan Kaya wrote: > On 9/13/2016 5:53 PM, Bjorn Helgaas wrote: >>> + pci_bus_restore(dev->bus); >> This path eventually writes the Bridge Control register: >> >> pci_reset_bridge_secondary_bus >> pcibios_reset_secondary_bus >> pci_reset_secondary_bus >>

Re: [PATCH V5] perf tools: adding support for address filters

On Tue, 13 Sep 2016 08:18:10 -0600 Mathieu Poirier wrote: > On 13 September 2016 at 04:01, Adrian Hunter wrote: > > On 12/09/16 20:53, Mathieu Poirier wrote: > >> This patch makes it possible to use the current filter > >> framework with

Re: [PATCH V5] perf tools: adding support for address filters

On Tue, 13 Sep 2016 08:18:10 -0600 Mathieu Poirier wrote: > On 13 September 2016 at 04:01, Adrian Hunter wrote: > > On 12/09/16 20:53, Mathieu Poirier wrote: > >> This patch makes it possible to use the current filter > >> framework with address filters. That way address filters for > >> HW

Re: [PATCH 1/2] PCI: save and restore device state during bus reset

On 9/13/2016 5:53 PM, Bjorn Helgaas wrote: >> +pci_bus_restore(dev->bus); > This path eventually writes the Bridge Control register: > > pci_reset_bridge_secondary_bus > pcibios_reset_secondary_bus > pci_reset_secondary_bus > pci_write_config_word(dev, PCI_BRIDGE_CONTROL,

Re: [PATCH 1/2] PCI: save and restore device state during bus reset

On 9/13/2016 5:53 PM, Bjorn Helgaas wrote: >> +pci_bus_restore(dev->bus); > This path eventually writes the Bridge Control register: > > pci_reset_bridge_secondary_bus > pcibios_reset_secondary_bus > pci_reset_secondary_bus > pci_write_config_word(dev, PCI_BRIDGE_CONTROL,

Re: [PATCH v2 26/33] Task fork and exit for rdtgroup

On 09/08/2016 02:57 AM, Fenghua Yu wrote: > +void rdtgroup_fork(struct task_struct *child) > +{ > + struct rdtgroup *rdtgrp; > + > + INIT_LIST_HEAD(>rg_list); > + if (!rdtgroup_mounted) > + return; > + > + mutex_lock(_mutex); > + > + rdtgrp = current->rdtgroup; > +

Re: [PATCH v2 26/33] Task fork and exit for rdtgroup

On 09/08/2016 02:57 AM, Fenghua Yu wrote: > +void rdtgroup_fork(struct task_struct *child) > +{ > + struct rdtgroup *rdtgrp; > + > + INIT_LIST_HEAD(>rg_list); > + if (!rdtgroup_mounted) > + return; > + > + mutex_lock(_mutex); > + > + rdtgrp = current->rdtgroup; > +

Re: [RFC/RFT][PATCH v2 0/7] Functional dependencies between devices

On Tuesday, September 13, 2016 07:57:31 PM Lukas Wunner wrote: > On Sun, Sep 11, 2016 at 12:04:36AM +0200, Rafael J. Wysocki wrote: > > On Sat, Sep 10, 2016 at 1:39 PM, Lukas Wunner wrote: > > > On Thu, Sep 08, 2016 at 11:25:44PM +0200, Rafael J. Wysocki wrote: > > >> As

Re: [RFC/RFT][PATCH v2 0/7] Functional dependencies between devices

On Tuesday, September 13, 2016 07:57:31 PM Lukas Wunner wrote: > On Sun, Sep 11, 2016 at 12:04:36AM +0200, Rafael J. Wysocki wrote: > > On Sat, Sep 10, 2016 at 1:39 PM, Lukas Wunner wrote: > > > On Thu, Sep 08, 2016 at 11:25:44PM +0200, Rafael J. Wysocki wrote: > > >> As discussed in the recent

[PATCH] usb: chipidea: Properly mark little endian descriptors

The DMA descriptors are little endian, and we do a pretty good job of handling them with the proper le32_to_cpu() markings, but we don't actually mark them as __le32. This means checkers like sparse can't easily find new bugs. Let's mark the members of structures properly and fix the few places

[PATCH] usb: chipidea: Properly mark little endian descriptors

The DMA descriptors are little endian, and we do a pretty good job of handling them with the proper le32_to_cpu() markings, but we don't actually mark them as __le32. This means checkers like sparse can't easily find new bugs. Let's mark the members of structures properly and fix the few places

Re: [PATCH v2 07/33] x86/intel_rdt: Add support for Cache Allocation detection

On 09/13/2016 03:52 PM, Luck, Tony wrote: > On Tue, Sep 13, 2016 at 03:40:18PM -0700, Dave Hansen wrote: >> Are you sure you don't want to add RDT to disabled-features.h? You have >> a config option for it, so it seems like you should also be able to >> optimize some of these checks away when the

Re: [PATCH v2 07/33] x86/intel_rdt: Add support for Cache Allocation detection

On 09/13/2016 03:52 PM, Luck, Tony wrote: > On Tue, Sep 13, 2016 at 03:40:18PM -0700, Dave Hansen wrote: >> Are you sure you don't want to add RDT to disabled-features.h? You have >> a config option for it, so it seems like you should also be able to >> optimize some of these checks away when the

Re: [PATCH v2 22/33] x86/intel_rdt.c: Extend RDT to per cache and per resources

On 09/08/2016 02:57 AM, Fenghua Yu wrote: > +static int __init rdt_setup(char *str) > +{ > + char *tok; > + > + while ((tok = strsep(, ",")) != NULL) { > + if (!*tok) > + return -EINVAL; > + > + if (strcmp(tok, "simulate_cat_l3") == 0) { > +

Re: [PATCH v2 22/33] x86/intel_rdt.c: Extend RDT to per cache and per resources

On 09/08/2016 02:57 AM, Fenghua Yu wrote: > +static int __init rdt_setup(char *str) > +{ > + char *tok; > + > + while ((tok = strsep(, ",")) != NULL) { > + if (!*tok) > + return -EINVAL; > + > + if (strcmp(tok, "simulate_cat_l3") == 0) { > +

Re: [PATCH v5] lib/bitmap.c: enhance bitmap syntax

On Sun, 11 Sep 2016 10:40:29 +0300 Noam Camus wrote: > From: Noam Camus > > Today there are platforms with many CPUs (up to 4K). > Trying to boot only part of the CPUs may result in too long string. > > For example lets take NPS platform that is part

Re: [PATCH v5] lib/bitmap.c: enhance bitmap syntax

On Sun, 11 Sep 2016 10:40:29 +0300 Noam Camus wrote: > From: Noam Camus > > Today there are platforms with many CPUs (up to 4K). > Trying to boot only part of the CPUs may result in too long string. > > For example lets take NPS platform that is part of arch/arc. > This platform have SMP

Re: [PATCH v2 07/33] x86/intel_rdt: Add support for Cache Allocation detection

On Tue, Sep 13, 2016 at 03:40:18PM -0700, Dave Hansen wrote: > Are you sure you don't want to add RDT to disabled-features.h? You have > a config option for it, so it seems like you should also be able to > optimize some of these checks away when the config option is off. Makefile looks like

Re: [PATCH v2 07/33] x86/intel_rdt: Add support for Cache Allocation detection

On Tue, Sep 13, 2016 at 03:40:18PM -0700, Dave Hansen wrote: > Are you sure you don't want to add RDT to disabled-features.h? You have > a config option for it, so it seems like you should also be able to > optimize some of these checks away when the config option is off. Makefile looks like

Re: [PATCH 2/2] PCI: add CRS support to error handling path

On 9/13/2016 5:47 PM, Bjorn Helgaas wrote: > On Tue, Sep 13, 2016 at 05:04:49PM -0400, Sinan Kaya wrote: >> On 9/13/2016 4:01 PM, Bjorn Helgaas wrote: >>> On Thu, Sep 01, 2016 at 07:00:01PM -0400, Sinan Kaya wrote: The PCIE spec allows an endpoint device to extend the initialization time

Re: [PATCH 2/2] PCI: add CRS support to error handling path

On 9/13/2016 5:47 PM, Bjorn Helgaas wrote: > On Tue, Sep 13, 2016 at 05:04:49PM -0400, Sinan Kaya wrote: >> On 9/13/2016 4:01 PM, Bjorn Helgaas wrote: >>> On Thu, Sep 01, 2016 at 07:00:01PM -0400, Sinan Kaya wrote: The PCIE spec allows an endpoint device to extend the initialization time

[PATCH net-next 4/4] rxrpc: Add IPv6 support

Add IPv6 support to AF_RXRPC. With this, AF_RXRPC sockets can be created: service = socket(AF_RXRPC, SOCK_DGRAM, PF_INET6); instead of: service = socket(AF_RXRPC, SOCK_DGRAM, PF_INET); The AFS filesystem doesn't support IPv6 at the moment, though, since that requires upgrades

[PATCH net-next 2/4] rxrpc: Don't specify protocol to when creating transport socket

Pass 0 as the protocol argument when creating the transport socket rather than IPPROTO_UDP. Signed-off-by: David Howells --- net/rxrpc/local_object.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/rxrpc/local_object.c

[PATCH net-next 3/4] rxrpc: Use rxrpc_extract_addr_from_skb() rather than doing this manually

There are two places that want to transmit a packet in response to one just received and manually pick the address to reply to out of the sk_buff. Make them use rxrpc_extract_addr_from_skb() instead so that IPv6 is handled automatically. Signed-off-by: David Howells ---

[PATCH net-next 4/4] rxrpc: Add IPv6 support

Add IPv6 support to AF_RXRPC. With this, AF_RXRPC sockets can be created: service = socket(AF_RXRPC, SOCK_DGRAM, PF_INET6); instead of: service = socket(AF_RXRPC, SOCK_DGRAM, PF_INET); The AFS filesystem doesn't support IPv6 at the moment, though, since that requires upgrades

[PATCH net-next 2/4] rxrpc: Don't specify protocol to when creating transport socket

Pass 0 as the protocol argument when creating the transport socket rather than IPPROTO_UDP. Signed-off-by: David Howells --- net/rxrpc/local_object.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/rxrpc/local_object.c b/net/rxrpc/local_object.c index

[PATCH net-next 3/4] rxrpc: Use rxrpc_extract_addr_from_skb() rather than doing this manually

There are two places that want to transmit a packet in response to one just received and manually pick the address to reply to out of the sk_buff. Make them use rxrpc_extract_addr_from_skb() instead so that IPv6 is handled automatically. Signed-off-by: David Howells --- net/rxrpc/local_event.c

[PATCH net-next 1/4] rxrpc: Create an address for sendmsg() to bind unbound socket with

Create an address for sendmsg() to bind unbound socket with rather than using a completely blank address otherwise the transport socket creation will fail because it will try to use address family 0. We use the address family specified in the protocol argument when the AF_RXRPC socket was created

[PATCH net-next 1/4] rxrpc: Create an address for sendmsg() to bind unbound socket with

Create an address for sendmsg() to bind unbound socket with rather than using a completely blank address otherwise the transport socket creation will fail because it will try to use address family 0. We use the address family specified in the protocol argument when the AF_RXRPC socket was created

[PATCH net-next 0/4] rxrpc: Support IPv6

://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git rxrpc-rewrite-20160913-2 David --- David Howells (4): rxrpc: Create an address for sendmsg() to bind unbound socket with rxrpc: Don't specify protocol to when creating transport socket rxrpc: Use

[PATCH net-next 0/4] rxrpc: Support IPv6

://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git rxrpc-rewrite-20160913-2 David --- David Howells (4): rxrpc: Create an address for sendmsg() to bind unbound socket with rxrpc: Don't specify protocol to when creating transport socket rxrpc: Use

Re: [PATCH v2 07/33] x86/intel_rdt: Add support for Cache Allocation detection

On 09/08/2016 02:57 AM, Fenghua Yu wrote: > --- a/arch/x86/include/asm/disabled-features.h > +++ b/arch/x86/include/asm/disabled-features.h > @@ -57,6 +57,7 @@ > #define DISABLED_MASK15 0 > #define DISABLED_MASK16 (DISABLE_PKU|DISABLE_OSPKE) > #define DISABLED_MASK17 0 > -#define

Re: [PATCH v2 07/33] x86/intel_rdt: Add support for Cache Allocation detection

On 09/08/2016 02:57 AM, Fenghua Yu wrote: > --- a/arch/x86/include/asm/disabled-features.h > +++ b/arch/x86/include/asm/disabled-features.h > @@ -57,6 +57,7 @@ > #define DISABLED_MASK15 0 > #define DISABLED_MASK16 (DISABLE_PKU|DISABLE_OSPKE) > #define DISABLED_MASK17 0 > -#define

[PATCH] ARC: module: provide linker script to discard debug sections

The module .ko files seem to bloated due to lot of needless sections, most of which come due to -gdwarf-2 toggle (needed in turn to get .debug_frame which kernel stack unwinder usese). However there's no reason for the other .debug_* sections, so discard them using arch specific linker script

[PATCH] ARC: module: provide linker script to discard debug sections

The module .ko files seem to bloated due to lot of needless sections, most of which come due to -gdwarf-2 toggle (needed in turn to get .debug_frame which kernel stack unwinder usese). However there's no reason for the other .debug_* sections, so discard them using arch specific linker script

Re: [PATCH v4 2/5] ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support

On Sun, Sep 11, 2016 at 3:30 PM, Jagan Teki wrote: > + reg_3p3v: regulator-3p3v { > + compatible = "regulator-fixed"; > + regulator-name = "3P3V"; > + regulator-min-microvolt = <330>; > +

Re: [PATCH v4 2/5] ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support

On Sun, Sep 11, 2016 at 3:30 PM, Jagan Teki wrote: > + reg_3p3v: regulator-3p3v { > + compatible = "regulator-fixed"; > + regulator-name = "3P3V"; > + regulator-min-microvolt = <330>; > + regulator-max-microvolt = <330>; > +

Re: [PATCH 2/2] staging: slicoss: slicoss.c: fix different address space sparse warnings

Hi Peng, [auto build test WARNING on staging/staging-testing] [also build test WARNING on next-20160913] [cannot apply to v4.8-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=a

Re: [RFC/RFT][PATCH v2 0/7] Functional dependencies between devices

On Tuesday, September 13, 2016 11:58:56 AM Marek Szyprowski wrote: > Hi Rafael, > > > On 2016-09-08 23:25, Rafael J. Wysocki wrote: > > Hi Everyone, > > > > This is a refresh of the functional dependencies series that I posted last > > year and which has picked up by Marek quite recently. For

Re: [PATCH 2/2] staging: slicoss: slicoss.c: fix different address space sparse warnings

Hi Peng, [auto build test WARNING on staging/staging-testing] [also build test WARNING on next-20160913] [cannot apply to v4.8-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=a

Re: [RFC/RFT][PATCH v2 0/7] Functional dependencies between devices

On Tuesday, September 13, 2016 11:58:56 AM Marek Szyprowski wrote: > Hi Rafael, > > > On 2016-09-08 23:25, Rafael J. Wysocki wrote: > > Hi Everyone, > > > > This is a refresh of the functional dependencies series that I posted last > > year and which has picked up by Marek quite recently. For

Re: drivers/usb/musb/tusb6010.c:142:21: error: 'USB_INDEX' undeclared

* Bin Liu [160908 11:26]: > On Thu, Sep 08, 2016 at 10:45:21AM -0700, Tony Lindgren wrote: > > --- a/drivers/usb/musb/Kconfig > > +++ b/drivers/usb/musb/Kconfig > > @@ -87,7 +87,7 @@ config USB_MUSB_DA8XX > > config USB_MUSB_TUSB6010 > > tristate "TUSB6010" > > depends on

Re: drivers/usb/musb/tusb6010.c:142:21: error: 'USB_INDEX' undeclared

* Bin Liu [160908 11:26]: > On Thu, Sep 08, 2016 at 10:45:21AM -0700, Tony Lindgren wrote: > > --- a/drivers/usb/musb/Kconfig > > +++ b/drivers/usb/musb/Kconfig > > @@ -87,7 +87,7 @@ config USB_MUSB_DA8XX > > config USB_MUSB_TUSB6010 > > tristate "TUSB6010" > > depends on HAS_IOMEM > > -

Re: [RESEND RFC PATCH 0/5] platform drivers for UP Board

On 09/13/2016 10:42 AM, Andy Shevchenko wrote: > On Mon, 2016-07-04 at 17:07 +0100, Dan O'Donovan wrote: >> [Re-sending to a wider audience suggested by Darren Hart] >> >> The UP Board is a new SBC based on the Intel Atom X5-Z8350 "Cherry >> Trail" SoC and features a 40-pin I/O pin header and

Re: [RESEND RFC PATCH 0/5] platform drivers for UP Board

On 09/13/2016 10:42 AM, Andy Shevchenko wrote: > On Mon, 2016-07-04 at 17:07 +0100, Dan O'Donovan wrote: >> [Re-sending to a wider audience suggested by Darren Hart] >> >> The UP Board is a new SBC based on the Intel Atom X5-Z8350 "Cherry >> Trail" SoC and features a 40-pin I/O pin header and

Re: [PATCH 03/21] ARM: OMAP: wakeupgen: Convert to hotplug state machine

* Sebastian Andrzej Siewior [160906 10:06]: > Install the callbacks via the state machine. Assuming this will get merged with the series: Acked-by: Tony Lindgren If you want me to pick it, please let me know. Regards, Tony

Re: [PATCH 03/21] ARM: OMAP: wakeupgen: Convert to hotplug state machine

* Sebastian Andrzej Siewior [160906 10:06]: > Install the callbacks via the state machine. Assuming this will get merged with the series: Acked-by: Tony Lindgren If you want me to pick it, please let me know. Regards, Tony

Re: [v11, 5/8] soc: fsl: add GUTS driver for QorIQ platforms

On Tue, 2016-09-13 at 07:23 +, Y.B. Lu wrote: > > > > > > -Original Message- > > From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- > > ow...@vger.kernel.org] On Behalf Of Scott Wood > > Sent: Tuesday, September 13, 2016 7:25 AM > > To: Y.B. Lu; linux-...@vger.kernel.org;

Re: [v11, 5/8] soc: fsl: add GUTS driver for QorIQ platforms

On Tue, 2016-09-13 at 07:23 +, Y.B. Lu wrote: > > > > > > -Original Message- > > From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- > > ow...@vger.kernel.org] On Behalf Of Scott Wood > > Sent: Tuesday, September 13, 2016 7:25 AM > > To: Y.B. Lu; linux-...@vger.kernel.org;

[PATCH net-next 08/10] rxrpc: Adjust the call ref tracepoint to show kernel API refs

Adjust the call ref tracepoint to show references held on a call by the kernel API separately as much as possible and add an additional trace to at the allocation point from the preallocation buffer for an incoming call. Note that this doesn't show the allocation of a client call for the kernel

[PATCH net-next 06/10] rxrpc: Use skb->len not skb->data_len

skb->len should be used rather than skb->data_len when referring to the amount of data in a packet. This will only cause a malfunction in the following cases: (1) We receive a jumbo packet (validation and splitting both are wrong). (2) We see if there's extra ACK info in an ACK packet (we

[PATCH net-next 08/10] rxrpc: Adjust the call ref tracepoint to show kernel API refs

Adjust the call ref tracepoint to show references held on a call by the kernel API separately as much as possible and add an additional trace to at the allocation point from the preallocation buffer for an incoming call. Note that this doesn't show the allocation of a client call for the kernel

[PATCH net-next 06/10] rxrpc: Use skb->len not skb->data_len

skb->len should be used rather than skb->data_len when referring to the amount of data in a packet. This will only cause a malfunction in the following cases: (1) We receive a jumbo packet (validation and splitting both are wrong). (2) We see if there's extra ACK info in an ACK packet (we

[PATCH net-next 01/10] rxrpc: Make sure we initialise the peer hash key

Peer records created for incoming connections weren't getting their hash key set. This meant that incoming calls wouldn't see more than one DATA packet - which is not a problem for AFS CM calls with small request data blobs. Signed-off-by: David Howells ---

[PATCH net-next 10/10] rxrpc: Correctly initialise, limit and transmit call->rx_winsize

call->rx_winsize should be initialised to the sysctl setting and the sysctl setting should be limited to the maximum we want to permit. Further, we need to place this in the ACK info instead of the sysctl setting. Furthermore, discard the idea of accepting the subpackets of a jumbo packet that

[PATCH net-next 07/10] rxrpc: Allow tx_winsize to grow in response to an ACK

Allow tx_winsize to grow when the ACK info packet shows a larger receive window at the other end rather than only permitting it to shrink. Signed-off-by: David Howells --- net/rxrpc/input.c |8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git

[PATCH net-next 01/10] rxrpc: Make sure we initialise the peer hash key

Peer records created for incoming connections weren't getting their hash key set. This meant that incoming calls wouldn't see more than one DATA packet - which is not a problem for AFS CM calls with small request data blobs. Signed-off-by: David Howells --- net/rxrpc/peer_object.c |2 +-

[PATCH net-next 10/10] rxrpc: Correctly initialise, limit and transmit call->rx_winsize

call->rx_winsize should be initialised to the sysctl setting and the sysctl setting should be limited to the maximum we want to permit. Further, we need to place this in the ACK info instead of the sysctl setting. Furthermore, discard the idea of accepting the subpackets of a jumbo packet that

[PATCH net-next 07/10] rxrpc: Allow tx_winsize to grow in response to an ACK

Allow tx_winsize to grow when the ACK info packet shows a larger receive window at the other end rather than only permitting it to shrink. Signed-off-by: David Howells --- net/rxrpc/input.c |8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/net/rxrpc/input.c

[PATCH net-next 04/10] rxrpc: Requeue call for recvmsg if more data

rxrpc_recvmsg() needs to make sure that the call it has just been processing gets requeued for further attention if the buffer has been filled and there's more data to be consumed. The softirq producer only queues the call and wakes the socket if it fills the first slot in the window, so

[PATCH net-next 05/10] rxrpc: Add missing unlock in rxrpc_call_accept()

Add a missing unlock in rxrpc_call_accept() in the path taken if there's no call to wake up. Signed-off-by: David Howells --- net/rxrpc/call_accept.c |8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/net/rxrpc/call_accept.c

[PATCH net-next 09/10] rxrpc: Fix prealloc refcounting

The preallocated call buffer holds a ref on the calls within that buffer. The ref was being released in the wrong place - it worked okay for incoming calls to the AFS cache manager service, but doesn't work right for incoming calls to a userspace service. Instead of releasing an extra ref service

[PATCH net-next 04/10] rxrpc: Requeue call for recvmsg if more data

rxrpc_recvmsg() needs to make sure that the call it has just been processing gets requeued for further attention if the buffer has been filled and there's more data to be consumed. The softirq producer only queues the call and wakes the socket if it fills the first slot in the window, so

[PATCH net-next 05/10] rxrpc: Add missing unlock in rxrpc_call_accept()

Add a missing unlock in rxrpc_call_accept() in the path taken if there's no call to wake up. Signed-off-by: David Howells --- net/rxrpc/call_accept.c |8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/net/rxrpc/call_accept.c b/net/rxrpc/call_accept.c index

[PATCH net-next 09/10] rxrpc: Fix prealloc refcounting

The preallocated call buffer holds a ref on the calls within that buffer. The ref was being released in the wrong place - it worked okay for incoming calls to the AFS cache manager service, but doesn't work right for incoming calls to a userspace service. Instead of releasing an extra ref service

[PATCH net-next 02/10] rxrpc: Add missing wakeup on Tx window rotation

We need to wake up the sender when Tx window rotation due to an incoming ACK makes space in the buffer otherwise the sender is liable to just hang endlessly. This problem isn't noticeable if the Tx phase transfers no more than will fit in a single window or the Tx window rotates fast enough that

[PATCH net-next 02/10] rxrpc: Add missing wakeup on Tx window rotation

We need to wake up the sender when Tx window rotation due to an incoming ACK makes space in the buffer otherwise the sender is liable to just hang endlessly. This problem isn't noticeable if the Tx phase transfers no more than will fit in a single window or the Tx window rotates fast enough that

[PATCH net-next 00/10] rxrpc: Miscellaneous fixes

/scm/linux/kernel/git/dhowells/linux-fs.git rxrpc-rewrite-20160913-1 David --- David Howells (10): rxrpc: Make sure we initialise the peer hash key rxrpc: Add missing wakeup on Tx window rotation rxrpc: The IDLE ACK packet should use rxrpc_idle_ack_delay rxrpc

[PATCH net-next 03/10] rxrpc: The IDLE ACK packet should use rxrpc_idle_ack_delay

The IDLE ACK packet should use the rxrpc_idle_ack_delay setting when the timer is set for it. Signed-off-by: David Howells --- net/rxrpc/call_event.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/rxrpc/call_event.c b/net/rxrpc/call_event.c

[PATCH net-next 00/10] rxrpc: Miscellaneous fixes

/scm/linux/kernel/git/dhowells/linux-fs.git rxrpc-rewrite-20160913-1 David --- David Howells (10): rxrpc: Make sure we initialise the peer hash key rxrpc: Add missing wakeup on Tx window rotation rxrpc: The IDLE ACK packet should use rxrpc_idle_ack_delay rxrpc

[PATCH net-next 03/10] rxrpc: The IDLE ACK packet should use rxrpc_idle_ack_delay

The IDLE ACK packet should use the rxrpc_idle_ack_delay setting when the timer is set for it. Signed-off-by: David Howells --- net/rxrpc/call_event.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/rxrpc/call_event.c b/net/rxrpc/call_event.c index

Re: [PATCH] vfio: platform: mark symbols static where possible

On Thu, 1 Sep 2016 19:15:35 +0800 Baoyou Xie wrote: > We get a few warnings when building kernel with W=1: > drivers/vfio/platform/vfio_platform_common.c:76:5: warning: no previous > prototype for 'vfio_platform_acpi_call_reset' [-Wmissing-prototypes] >

Re: [PATCH] vfio: platform: mark symbols static where possible

On Thu, 1 Sep 2016 19:15:35 +0800 Baoyou Xie wrote: > We get a few warnings when building kernel with W=1: > drivers/vfio/platform/vfio_platform_common.c:76:5: warning: no previous > prototype for 'vfio_platform_acpi_call_reset' [-Wmissing-prototypes] >

Re: [patch v4] i2c: mux: mellanox: add driver

It's shaping up, a few last nitpicks... On 2016-09-13 16:38, vad...@mellanox.com wrote: > From: Vadim Pasternak > > This driver allows I2C routing controlled through CPLD select registers on > wide range of Mellanox systems (CPLD Lattice device). s/wide/a wide/ But is it

Re: [patch v4] i2c: mux: mellanox: add driver

It's shaping up, a few last nitpicks... On 2016-09-13 16:38, vad...@mellanox.com wrote: > From: Vadim Pasternak > > This driver allows I2C routing controlled through CPLD select registers on > wide range of Mellanox systems (CPLD Lattice device). s/wide/a wide/ But is it really still "a wide

[tip:x86/cleanups] x86: Clean up various simple wrapper functions

Commit-ID: f148b41e8b2e114d0aba023adf326b03368f3246 Gitweb: http://git.kernel.org/tip/f148b41e8b2e114d0aba023adf326b03368f3246 Author: Masahiro Yamada AuthorDate: Sun, 11 Sep 2016 14:58:21 +0900 Committer: Ingo Molnar CommitDate: Tue, 13

[tip:x86/cleanups] x86: Clean up various simple wrapper functions

Commit-ID: f148b41e8b2e114d0aba023adf326b03368f3246 Gitweb: http://git.kernel.org/tip/f148b41e8b2e114d0aba023adf326b03368f3246 Author: Masahiro Yamada AuthorDate: Sun, 11 Sep 2016 14:58:21 +0900 Committer: Ingo Molnar CommitDate: Tue, 13 Sep 2016 20:42:58 +0200 x86: Clean up various

[tip:x86/asm] x86/entry/64: Clean up and document espfix64 stack setup

Commit-ID: 85063fac1f72419eec4349621fe829b07f9acb1e Gitweb: http://git.kernel.org/tip/85063fac1f72419eec4349621fe829b07f9acb1e Author: Andy Lutomirski AuthorDate: Mon, 12 Sep 2016 15:05:51 -0700 Committer: Ingo Molnar CommitDate: Tue, 13 Sep 2016

[tip:x86/asm] x86/entry/64: Clean up and document espfix64 stack setup

Commit-ID: 85063fac1f72419eec4349621fe829b07f9acb1e Gitweb: http://git.kernel.org/tip/85063fac1f72419eec4349621fe829b07f9acb1e Author: Andy Lutomirski AuthorDate: Mon, 12 Sep 2016 15:05:51 -0700 Committer: Ingo Molnar CommitDate: Tue, 13 Sep 2016 20:34:16 +0200 x86/entry/64: Clean up

[tip:x86/asm] selftests/x86/sigreturn: Use CX, not AX, as the scratch register

Commit-ID: 1ef0199a1a698d82ecd39d11d1daa3f4ab006c75 Gitweb: http://git.kernel.org/tip/1ef0199a1a698d82ecd39d11d1daa3f4ab006c75 Author: Andy Lutomirski AuthorDate: Mon, 12 Sep 2016 15:05:50 -0700 Committer: Ingo Molnar CommitDate: Tue, 13 Sep 2016

[tip:x86/asm] selftests/x86/sigreturn: Use CX, not AX, as the scratch register

Commit-ID: 1ef0199a1a698d82ecd39d11d1daa3f4ab006c75 Gitweb: http://git.kernel.org/tip/1ef0199a1a698d82ecd39d11d1daa3f4ab006c75 Author: Andy Lutomirski AuthorDate: Mon, 12 Sep 2016 15:05:50 -0700 Committer: Ingo Molnar CommitDate: Tue, 13 Sep 2016 20:34:15 +0200

[tip:sched/core] sched/numa, mm: Revert to checking pmd/pte_write instead of VMA flags

Commit-ID: d59dc7bcfa649ef2128a76b6487b16f4b3f14d23 Gitweb: http://git.kernel.org/tip/d59dc7bcfa649ef2128a76b6487b16f4b3f14d23 Author: Rik van Riel AuthorDate: Thu, 8 Sep 2016 21:30:53 -0400 Committer: Ingo Molnar CommitDate: Tue, 13 Sep 2016 20:31:33

[tip:sched/core] sched/numa, mm: Revert to checking pmd/pte_write instead of VMA flags

Commit-ID: d59dc7bcfa649ef2128a76b6487b16f4b3f14d23 Gitweb: http://git.kernel.org/tip/d59dc7bcfa649ef2128a76b6487b16f4b3f14d23 Author: Rik van Riel AuthorDate: Thu, 8 Sep 2016 21:30:53 -0400 Committer: Ingo Molnar CommitDate: Tue, 13 Sep 2016 20:31:33 +0200 sched/numa, mm: Revert to

Re: [PATCH] ARM: dts: omap3-gta04: reduce panel backlight PWM frequency to 83Hz

* H. Nikolaus Schaller [160910 02:10]: > > Am 10.09.2016 um 10:20 schrieb Matthijs van Duin > > : > > But with the patch submitted, I just want to give the dts of a single > device I have even designed a more reasonable value than in current >

Re: [PATCH] ARM: dts: omap3-gta04: reduce panel backlight PWM frequency to 83Hz

* H. Nikolaus Schaller [160910 02:10]: > > Am 10.09.2016 um 10:20 schrieb Matthijs van Duin > > : > > But with the patch submitted, I just want to give the dts of a single > device I have even designed a more reasonable value than in current > linux/master and don't really want to make it a

Re: [PATCH V2 0/2] ARM: dts: Introduce support for rev BeagleBoard-X15 B1

* Nishanth Menon [160902 10:14]: > Hi, > > Please find the series to cleanup and support Production version of > Beagleboard-X15 rev B1 support. Applying into omap-for-v4.9/dt thanks. Tony

Re: [PATCH V2 0/2] ARM: dts: Introduce support for rev BeagleBoard-X15 B1

* Nishanth Menon [160902 10:14]: > Hi, > > Please find the series to cleanup and support Production version of > Beagleboard-X15 rev B1 support. Applying into omap-for-v4.9/dt thanks. Tony

Re: [PATCH 4/4] cpuidle/menu: add per cpu pm_qos_resume_latency consideration

On Tuesday, September 13, 2016 10:02:49 PM Alex Shi wrote: > Hi Daniel & Rafael, > > Any comments on this patch? I actually am not sure about the whole series. I know your motivation, but honestly the changes here may not be the best way to achieve what you need. You may think that the changes

Re: [PATCH 4/4] cpuidle/menu: add per cpu pm_qos_resume_latency consideration

On Tuesday, September 13, 2016 10:02:49 PM Alex Shi wrote: > Hi Daniel & Rafael, > > Any comments on this patch? I actually am not sure about the whole series. I know your motivation, but honestly the changes here may not be the best way to achieve what you need. You may think that the changes

Re: [PATCH net-next 2/2] net: deprecate eth_change_mtu, remove usage

Hi Jarod, [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/Jarod-Wilson/net-centralize-net_device-min-max-MTU-checking/20160913-042130 config: mips-xway_defconfig (attached as .config) compiler: mips-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609

Re: [PATCH net-next 2/2] net: deprecate eth_change_mtu, remove usage

Hi Jarod, [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/Jarod-Wilson/net-centralize-net_device-min-max-MTU-checking/20160913-042130 config: mips-xway_defconfig (attached as .config) compiler: mips-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609

Re: ptrace group stop signal number not reset before PTRACE_INTERRUPT is delivered?

Hi Oleg, I have another obscure ptrace question which seems somewhat related, so let me ask it here. Consider this: ``` static int sigchld_counter = 0; void sigchld_handler(int sig) { (void)sig; sigchld_counter++; } int main(void) { signal(SIGCHLD, sigchld_handler); pid_t child; if

Re: ptrace group stop signal number not reset before PTRACE_INTERRUPT is delivered?

Hi Oleg, I have another obscure ptrace question which seems somewhat related, so let me ask it here. Consider this: ``` static int sigchld_counter = 0; void sigchld_handler(int sig) { (void)sig; sigchld_counter++; } int main(void) { signal(SIGCHLD, sigchld_handler); pid_t child; if

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