[PATCH 03/14] mm/hmm: HMM should have a callback before MM is destroyed v2

From: Ralph Campbell The hmm_mirror_register() function registers a callback for when the CPU pagetable is modified. Normally, the device driver will call hmm_mirror_unregister() when the process using the device is finished. However, if the process exits uncleanly, the struct_mm can be

[PATCH 07/14] mm/hmm: use uint64_t for HMM pfn instead of defining hmm_pfn_t to ulong

From: Jérôme Glisse All device driver we care about are using 64bits page table entry. In order to match this and to avoid useless define convert all HMM pfn to directly use uint64_t. It is a first step on the road to allow driver to directly use pfn value return by HMM (saving memory and CPU

[PATCH 06/14] mm/hmm: remove HMM_PFN_READ flag and ignore peculiar architecture

From: Jérôme Glisse Only peculiar architecture allow write without read thus assume that any valid pfn do allow for read. Note we do not care for write only because it does make sense with thing like atomic compare and exchange or any other operations that allow you to get

[PATCH 05/14] mm/hmm: use struct for hmm_vma_fault(), hmm_vma_get_pfns() parameters

From: Jérôme Glisse Both hmm_vma_fault() and hmm_vma_get_pfns() were taking a hmm_range struct as parameter and were initializing that struct with others of their parameters. Have caller of those function do this as they are likely to already do and only pass this struct to

[PATCH 06/14] mm/hmm: remove HMM_PFN_READ flag and ignore peculiar architecture

From: Jérôme Glisse Only peculiar architecture allow write without read thus assume that any valid pfn do allow for read. Note we do not care for write only because it does make sense with thing like atomic compare and exchange or any other operations that allow you to get the memory value

[PATCH 05/14] mm/hmm: use struct for hmm_vma_fault(), hmm_vma_get_pfns() parameters

From: Jérôme Glisse Both hmm_vma_fault() and hmm_vma_get_pfns() were taking a hmm_range struct as parameter and were initializing that struct with others of their parameters. Have caller of those function do this as they are likely to already do and only pass this struct to both function this

[PATCH 09/14] mm/hmm: do not differentiate between empty entry or missing directory

From: Jérôme Glisse There is no point in differentiating between a range for which there is not even a directory (and thus entries) and empty entry (pte_none() or pmd_none() returns true). Simply drop the distinction ie remove HMM_PFN_EMPTY flag and merge now duplicate

[PATCH 09/14] mm/hmm: do not differentiate between empty entry or missing directory

From: Jérôme Glisse There is no point in differentiating between a range for which there is not even a directory (and thus entries) and empty entry (pte_none() or pmd_none() returns true). Simply drop the distinction ie remove HMM_PFN_EMPTY flag and merge now duplicate hmm_vma_walk_hole() and

[PATCH 08/14] mm/hmm: cleanup special vma handling (VM_SPECIAL)

From: Jérôme Glisse Special vma (one with any of the VM_SPECIAL flags) can not be access by device because there is no consistent model accross device drivers on those vma and their backing memory. This patch directly use hmm_range struct for hmm_pfns_special() argument as

[PATCH 01/14] mm/hmm: documentation editorial update to HMM documentation

From: Ralph Campbell This patch updates the documentation for HMM to fix minor typos and phrasing to be a bit more readable. Signed-off-by: Ralph Campbell Signed-off-by: Jérôme Glisse Cc: Stephen Bates Cc:

[PATCH 08/14] mm/hmm: cleanup special vma handling (VM_SPECIAL)

From: Jérôme Glisse Special vma (one with any of the VM_SPECIAL flags) can not be access by device because there is no consistent model accross device drivers on those vma and their backing memory. This patch directly use hmm_range struct for hmm_pfns_special() argument as it is always

[PATCH 01/14] mm/hmm: documentation editorial update to HMM documentation

From: Ralph Campbell This patch updates the documentation for HMM to fix minor typos and phrasing to be a bit more readable. Signed-off-by: Ralph Campbell Signed-off-by: Jérôme Glisse Cc: Stephen Bates Cc: Jason Gunthorpe Cc: Logan Gunthorpe Cc: Evgeny Baskakov Cc: Mark Hairgrove Cc:

[PATCH 02/14] mm/hmm: fix header file if/else/endif maze

From: Jérôme Glisse The #if/#else/#endif for IS_ENABLED(CONFIG_HMM) were wrong. Signed-off-by: Jérôme Glisse Acked-by: Balbir Singh Cc: sta...@vger.kernel.org Cc: Andrew Morton Cc: Ralph Campbell

[PATCH 02/14] mm/hmm: fix header file if/else/endif maze

From: Jérôme Glisse The #if/#else/#endif for IS_ENABLED(CONFIG_HMM) were wrong. Signed-off-by: Jérôme Glisse Acked-by: Balbir Singh Cc: sta...@vger.kernel.org Cc: Andrew Morton Cc: Ralph Campbell Cc: John Hubbard Cc: Evgeny Baskakov --- include/linux/hmm.h | 7 +++ 1 file changed, 3

[PATCH 0/4] hmm: fixes and documentations v2

From: Jérôme Glisse Removed pointless VM_BUG_ON() cced stable when appropriate and splitted the last patch into _many_ smaller patches to make it easier to review. The end result is same modulo comments i received so far and the extra documentation i added while splitting

[PATCH 0/4] hmm: fixes and documentations v2

From: Jérôme Glisse Removed pointless VM_BUG_ON() cced stable when appropriate and splitted the last patch into _many_ smaller patches to make it easier to review. The end result is same modulo comments i received so far and the extra documentation i added while splitting thing up. Below is

Re: [PATCH v9 13/61] xarray: Add documentation

On Tue, Mar 13, 2018 at 06:25:51AM -0700, Matthew Wilcox wrote: > From: Matthew Wilcox > > This is documentation on how to use the XArray, not details about its > internal implementation. > > Signed-off-by: Matthew Wilcox I'm just going to

Re: [PATCH v9 13/61] xarray: Add documentation

On Tue, Mar 13, 2018 at 06:25:51AM -0700, Matthew Wilcox wrote: > From: Matthew Wilcox > > This is documentation on how to use the XArray, not details about its > internal implementation. > > Signed-off-by: Matthew Wilcox I'm just going to assume you know what you are talking about here

Re: [PATCH v9 12/61] xarray: Define struct xa_node

On Tue, Mar 13, 2018 at 06:25:50AM -0700, Matthew Wilcox wrote: > From: Matthew Wilcox > > This is a direct replacement for struct radix_tree_node. A couple of > struct members have changed name, so convert those. Use a #define so > that radix tree users continue to

Re: [PATCH v9 12/61] xarray: Define struct xa_node

On Tue, Mar 13, 2018 at 06:25:50AM -0700, Matthew Wilcox wrote: > From: Matthew Wilcox > > This is a direct replacement for struct radix_tree_node. A couple of > struct members have changed name, so convert those. Use a #define so > that radix tree users continue to work without change. > >

Re: [PATCH 0/2] net: phy: relax error checking when creating sysfs link netdev->phydev

On March 16, 2018 11:42:21 AM PDT, Grygorii Strashko wrote: > > >On 03/16/2018 12:34 PM, Florian Fainelli wrote: >> >> >> On 03/16/2018 10:22 AM, Andrew Lunn wrote: >>> On Wed, Mar 14, 2018 at 05:26:22PM -0500, Grygorii Strashko wrote: Some ethernet drivers (like

Re: [PATCH 0/2] net: phy: relax error checking when creating sysfs link netdev->phydev

On March 16, 2018 11:42:21 AM PDT, Grygorii Strashko wrote: > > >On 03/16/2018 12:34 PM, Florian Fainelli wrote: >> >> >> On 03/16/2018 10:22 AM, Andrew Lunn wrote: >>> On Wed, Mar 14, 2018 at 05:26:22PM -0500, Grygorii Strashko wrote: Some ethernet drivers (like TI CPSW) may connect and

Re: [PATCH v6 15/15] xfs, dax: introduce xfs_break_dax_layouts()

Looks fine, Reviewed-by: Christoph Hellwig

Re: [PATCH v6 15/15] xfs, dax: introduce xfs_break_dax_layouts()

Looks fine, Reviewed-by: Christoph Hellwig

Re: [PATCH v6 12/15] xfs: require mmap lock for xfs_break_layouts()

On Fri, Mar 16, 2018 at 12:04 PM, Christoph Hellwig wrote: > On Thu, Mar 15, 2018 at 08:52:29AM -0700, Dan Williams wrote: >> In preparation for adding coordination between truncate operations and >> busy dax-pages, extend xfs_break_layouts() to assume it must be called >> with the

Re: [PATCH v6 12/15] xfs: require mmap lock for xfs_break_layouts()

On Fri, Mar 16, 2018 at 12:04 PM, Christoph Hellwig wrote: > On Thu, Mar 15, 2018 at 08:52:29AM -0700, Dan Williams wrote: >> In preparation for adding coordination between truncate operations and >> busy dax-pages, extend xfs_break_layouts() to assume it must be called >> with the mmap lock

Re: [PATCH v6 14/15] xfs: prepare xfs_break_layouts() for another layout type

Looks fine: Reviewed-by: Christoph Hellwig

Re: [PATCH v6 14/15] xfs: prepare xfs_break_layouts() for another layout type

Looks fine: Reviewed-by: Christoph Hellwig

Re: [PATCH v6 13/15] xfs: communicate lock drop events from xfs_break_layouts()

On Thu, Mar 15, 2018 at 08:52:39AM -0700, Dan Williams wrote: > In preparation for adding a new layout type, teach xfs_break_layouts() > to return a positive number if it needed to drop locks while trying to > break leases. For all layouts to be successfully broken each layout type > needs to be

Re: [PATCH v6 13/15] xfs: communicate lock drop events from xfs_break_layouts()

On Thu, Mar 15, 2018 at 08:52:39AM -0700, Dan Williams wrote: > In preparation for adding a new layout type, teach xfs_break_layouts() > to return a positive number if it needed to drop locks while trying to > break leases. For all layouts to be successfully broken each layout type > needs to be

Re: [PATCH v9 09/61] xarray: Replace exceptional entries

On Fri, Mar 16, 2018 at 02:53:50PM -0400, Josef Bacik wrote: > On Tue, Mar 13, 2018 at 06:25:47AM -0700, Matthew Wilcox wrote: > > @@ -453,18 +449,14 @@ int ida_get_new_above(struct ida *ida, int start, int > > *id) > > new += bit; > > if (new < 0) > >

Re: [PATCH v9 09/61] xarray: Replace exceptional entries

On Fri, Mar 16, 2018 at 02:53:50PM -0400, Josef Bacik wrote: > On Tue, Mar 13, 2018 at 06:25:47AM -0700, Matthew Wilcox wrote: > > @@ -453,18 +449,14 @@ int ida_get_new_above(struct ida *ida, int start, int > > *id) > > new += bit; > > if (new < 0) > >

Re: [PATCH v9 11/61] xarray: Add definition of struct xarray

On Tue, Mar 13, 2018 at 06:25:49AM -0700, Matthew Wilcox wrote: > From: Matthew Wilcox > > This is a direct replacement for struct radix_tree_root. Some of the > struct members have changed name; convert those, and use a #define so > that radix_tree users continue to

Re: [PATCH v9 11/61] xarray: Add definition of struct xarray

On Tue, Mar 13, 2018 at 06:25:49AM -0700, Matthew Wilcox wrote: > From: Matthew Wilcox > > This is a direct replacement for struct radix_tree_root. Some of the > struct members have changed name; convert those, and use a #define so > that radix_tree users continue to work without change. > >

Re: [PATCH v6 12/15] xfs: require mmap lock for xfs_break_layouts()

On Thu, Mar 15, 2018 at 08:52:29AM -0700, Dan Williams wrote: > In preparation for adding coordination between truncate operations and > busy dax-pages, extend xfs_break_layouts() to assume it must be called > with the mmap lock held. This locking scheme will be required for > coordinating the

Re: [PATCH v6 12/15] xfs: require mmap lock for xfs_break_layouts()

On Thu, Mar 15, 2018 at 08:52:29AM -0700, Dan Williams wrote: > In preparation for adding coordination between truncate operations and > busy dax-pages, extend xfs_break_layouts() to assume it must be called > with the mmap lock held. This locking scheme will be required for > coordinating the

Re: [PATCH v2 03/36] mm: use do_futex() instead of sys_futex() in mm_release()

On Fri, Mar 16, 2018 at 6:43 PM, Darren Hart wrote: > On Thu, Mar 15, 2018 at 08:04:56PM +0100, Dominik Brodowski wrote: >> sys_futex() is a wrapper to do_futex() which does not modify any >> values here: >> >> - uaddr, val and val3 are kept the same >> >> - op is masked

Re: [PATCH v2 03/36] mm: use do_futex() instead of sys_futex() in mm_release()

On Fri, Mar 16, 2018 at 6:43 PM, Darren Hart wrote: > On Thu, Mar 15, 2018 at 08:04:56PM +0100, Dominik Brodowski wrote: >> sys_futex() is a wrapper to do_futex() which does not modify any >> values here: >> >> - uaddr, val and val3 are kept the same >> >> - op is masked with FUTEX_CMD_MASK, but

Re: [PATCH 2/2] kprobe: fix: Add ftrace_ops_assist_func to kprobe blacklist

On Fri, 16 Mar 2018 13:53:01 -0400 (EDT) Mathieu Desnoyers wrote: > Would the general approach you envision be based on emitting all code > generated by compilation of all objects under kernel/tracing and > kernel/events into a specific "nokprobes" text section of

Re: [PATCH 2/2] kprobe: fix: Add ftrace_ops_assist_func to kprobe blacklist

On Fri, 16 Mar 2018 13:53:01 -0400 (EDT) Mathieu Desnoyers wrote: > Would the general approach you envision be based on emitting all code > generated by compilation of all objects under kernel/tracing and > kernel/events into a specific "nokprobes" text section of the kernel ? > Perhaps we could

Re: [PATCH v6 11/15] mm, fs, dax: handle layout changes to pinned dax mappings

Looks good (at least up to my comprehension of the mm code :)) Reviewed-by: Christoph Hellwig

Re: [PATCH v6 11/15] mm, fs, dax: handle layout changes to pinned dax mappings

Looks good (at least up to my comprehension of the mm code :)) Reviewed-by: Christoph Hellwig

Re: [PATCH 13/22] signal: Move addr_lsb into the _sigfault union for clarity

On 01/15/2018 04:40 PM, Eric W. Biederman wrote: > The addr_lsb fields is only valid and available when the > signal is SIGBUS and the si_code is BUS_MCEERR_AR or BUS_MCEERR_AO. > Document this with a comment and place the field in the _sigfault union > to make this clear. > > All of the fields

Re: [PATCH 13/22] signal: Move addr_lsb into the _sigfault union for clarity

On 01/15/2018 04:40 PM, Eric W. Biederman wrote: > The addr_lsb fields is only valid and available when the > signal is SIGBUS and the si_code is BUS_MCEERR_AR or BUS_MCEERR_AO. > Document this with a comment and place the field in the _sigfault union > to make this clear. > > All of the fields

Re: [PATCH v6 04/15] xfs, dax: introduce xfs_dax_aops

Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH v6 04/15] xfs, dax: introduce xfs_dax_aops

Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH v9 10/61] xarray: Change definition of sibling entries

On Tue, Mar 13, 2018 at 06:25:48AM -0700, Matthew Wilcox wrote: > From: Matthew Wilcox > > Instead of storing a pointer to the slot containing the canonical entry, > store the offset of the slot. Produces slightly more efficient code > (~300 bytes) and simplifies the

Re: [PATCH v9 10/61] xarray: Change definition of sibling entries

On Tue, Mar 13, 2018 at 06:25:48AM -0700, Matthew Wilcox wrote: > From: Matthew Wilcox > > Instead of storing a pointer to the slot containing the canonical entry, > store the offset of the slot. Produces slightly more efficient code > (~300 bytes) and simplifies the implementation. > >

Re: [PATCH v6 03/15] block, dax: remove dead code in blkdev_writepages()

Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH v6 03/15] block, dax: remove dead code in blkdev_writepages()

Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH v6 02/15] fs, dax: prepare for dax-specific address_space_operations

Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH v6 02/15] fs, dax: prepare for dax-specific address_space_operations

Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH v2 0/5] Allow compile-testing NO_DMA (core)

Thanks Geert, applied to the dma-mapping tree for 4.17.

Re: [PATCH v2 0/5] Allow compile-testing NO_DMA (core)

Thanks Geert, applied to the dma-mapping tree for 4.17.

Re: [PATCH net-next] net: ethernet: ti: cpsw: enable vlan rx vlan offload

On 03/16/2018 01:37 PM, David Miller wrote: From: Andrew Lunn Date: Fri, 16 Mar 2018 01:29:35 +0100 On Thu, Mar 15, 2018 at 03:15:50PM -0500, Grygorii Strashko wrote: In VLAN_AWARE mode CPSW can insert VLAN header encapsulation word on Host port 0 egress (RX) before the

Re: [PATCH net-next] net: ethernet: ti: cpsw: enable vlan rx vlan offload

On 03/16/2018 01:37 PM, David Miller wrote: From: Andrew Lunn Date: Fri, 16 Mar 2018 01:29:35 +0100 On Thu, Mar 15, 2018 at 03:15:50PM -0500, Grygorii Strashko wrote: In VLAN_AWARE mode CPSW can insert VLAN header encapsulation word on Host port 0 egress (RX) before the packet data if

Re: [PATCH v5 1/2] hwmon: (ucd9000) Add gpio chip interface

On Fri, Mar 16, 2018 at 01:39:48PM -0500, Eddie James wrote: > > > On 03/16/2018 08:40 AM, Guenter Roeck wrote: > >On 03/15/2018 03:21 PM, Eddie James wrote: > >>From: Christopher Bostic > >> > >>Add a struct gpio_chip and define some methods so that this device's >

Re: [PATCH v5 1/2] hwmon: (ucd9000) Add gpio chip interface

On Fri, Mar 16, 2018 at 01:39:48PM -0500, Eddie James wrote: > > > On 03/16/2018 08:40 AM, Guenter Roeck wrote: > >On 03/15/2018 03:21 PM, Eddie James wrote: > >>From: Christopher Bostic > >> > >>Add a struct gpio_chip and define some methods so that this device's > >>I/O can be accessed via

Re: [PATCH v9 09/61] xarray: Replace exceptional entries

On Tue, Mar 13, 2018 at 06:25:47AM -0700, Matthew Wilcox wrote: > From: Matthew Wilcox > > Introduce xarray value entries to replace the radix tree exceptional > entry code. This is a slight change in encoding to allow the use of an > extra bit (we can now store

Re: [PATCH v9 09/61] xarray: Replace exceptional entries

On Tue, Mar 13, 2018 at 06:25:47AM -0700, Matthew Wilcox wrote: > From: Matthew Wilcox > > Introduce xarray value entries to replace the radix tree exceptional > entry code. This is a slight change in encoding to allow the use of an > extra bit (we can now store BITS_PER_LONG - 1 bits in a

Re: [PATCH 4.14 064/109] dmaengine: bcm2835-dma: Use vchan_terminate_vdesc() instead of desc_free

On Fri, Mar 16, 2018 at 04:23:33PM +0100, Greg Kroah-Hartman wrote: > 4.14-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Peter Ujfalusi > > > [ Upstream commit de92436ac40ffe9933230aa503e24dbb5ede9201 ] > > To

Re: [PATCH 4.14 064/109] dmaengine: bcm2835-dma: Use vchan_terminate_vdesc() instead of desc_free

On Fri, Mar 16, 2018 at 04:23:33PM +0100, Greg Kroah-Hartman wrote: > 4.14-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Peter Ujfalusi > > > [ Upstream commit de92436ac40ffe9933230aa503e24dbb5ede9201 ] > > To avoid race with

Re: [PATCH][RFC] kernel.h: provide array iterator

On Fri, 2018-03-16 at 16:27 +0100, Rasmus Villemoes wrote: > On 2018-03-15 11:00, Kieran Bingham wrote: > > Simplify array iteration with a helper to iterate each entry in an array. > > Utilise the existing ARRAY_SIZE macro to identify the length of the array > > and pointer arithmetic to process

Re: [PATCH][RFC] kernel.h: provide array iterator

On Fri, 2018-03-16 at 16:27 +0100, Rasmus Villemoes wrote: > On 2018-03-15 11:00, Kieran Bingham wrote: > > Simplify array iteration with a helper to iterate each entry in an array. > > Utilise the existing ARRAY_SIZE macro to identify the length of the array > > and pointer arithmetic to process

Re: [PATCH v2 03/36] mm: use do_futex() instead of sys_futex() in mm_release()

On Thu, Mar 15, 2018 at 08:04:56PM +0100, Dominik Brodowski wrote: > sys_futex() is a wrapper to do_futex() which does not modify any > values here: > > - uaddr, val and val3 are kept the same > > - op is masked with FUTEX_CMD_MASK, but is always set to FUTEX_WAKE. > Therefore, val2 is always

Re: [PATCH v2 03/36] mm: use do_futex() instead of sys_futex() in mm_release()

On Thu, Mar 15, 2018 at 08:04:56PM +0100, Dominik Brodowski wrote: > sys_futex() is a wrapper to do_futex() which does not modify any > values here: > > - uaddr, val and val3 are kept the same > > - op is masked with FUTEX_CMD_MASK, but is always set to FUTEX_WAKE. > Therefore, val2 is always

Re: [PATCH 0/2] net: phy: relax error checking when creating sysfs link netdev->phydev

On 03/16/2018 12:34 PM, Florian Fainelli wrote: > > > On 03/16/2018 10:22 AM, Andrew Lunn wrote: >> On Wed, Mar 14, 2018 at 05:26:22PM -0500, Grygorii Strashko wrote: >>> Some ethernet drivers (like TI CPSW) may connect and manage >1 Net PHYs per >>> one netdevice, as result such drivers will

Re: [PATCH 0/2] net: phy: relax error checking when creating sysfs link netdev->phydev

On 03/16/2018 12:34 PM, Florian Fainelli wrote: > > > On 03/16/2018 10:22 AM, Andrew Lunn wrote: >> On Wed, Mar 14, 2018 at 05:26:22PM -0500, Grygorii Strashko wrote: >>> Some ethernet drivers (like TI CPSW) may connect and manage >1 Net PHYs per >>> one netdevice, as result such drivers will

Re: [PATCH v2] netns: send uevent messages

From: Christian Brauner Date: Fri, 16 Mar 2018 13:50:30 +0100 > +static int uevent_net_broadcast(struct sock *usk, struct sk_buff *skb, > + struct netlink_ext_ack *extack) > +{ > + int ret; > + /* u64 to chars: 2^64 - 1 = 21 chars

Re: [PATCH v2] netns: send uevent messages

From: Christian Brauner Date: Fri, 16 Mar 2018 13:50:30 +0100 > +static int uevent_net_broadcast(struct sock *usk, struct sk_buff *skb, > + struct netlink_ext_ack *extack) > +{ > + int ret; > + /* u64 to chars: 2^64 - 1 = 21 chars */ > + char

Re: [PATCH v5 1/2] hwmon: (ucd9000) Add gpio chip interface

On 03/16/2018 08:40 AM, Guenter Roeck wrote: On 03/15/2018 03:21 PM, Eddie James wrote: From: Christopher Bostic Add a struct gpio_chip and define some methods so that this device's I/O can be accessed via /sys/class/gpio. Sorry for not noticing earlier. The

Re: [PATCH v5 1/2] hwmon: (ucd9000) Add gpio chip interface

On 03/16/2018 08:40 AM, Guenter Roeck wrote: On 03/15/2018 03:21 PM, Eddie James wrote: From: Christopher Bostic Add a struct gpio_chip and define some methods so that this device's I/O can be accessed via /sys/class/gpio. Sorry for not noticing earlier. The 0day reports should be

Re: [PATCH] platform/x86: panasonic-laptop: add support to mute and hardware optical switch

On Fri, Mar 16, 2018 at 1:09 PM, Harald Welte wrote: > Hi Kenneth, > > thanks for your fix. I'm not currently using any Panasonic Laptop devices > anymore (After the CF-R series was discontinued), so I'm not able to properly > maintain this driver anymore. > > However, your

Re: [PATCH] platform/x86: panasonic-laptop: add support to mute and hardware optical switch

On Fri, Mar 16, 2018 at 1:09 PM, Harald Welte wrote: > Hi Kenneth, > > thanks for your fix. I'm not currently using any Panasonic Laptop devices > anymore (After the CF-R series was discontinued), so I'm not able to properly > maintain this driver anymore. > > However, your changes look sound to

Re: [PATCH 8/9] x86/dumpstack: Save first regs set for the executive summary

On Fri, Mar 16, 2018 at 06:45:29PM +0100, Borislav Petkov wrote: > > You're better off getting rid of the CR2 line from __show_regs(), > > because it can be dangerously confusing. It's not actually part of the > > saved register state at all, it's something entirely different. It's > > like

Re: [PATCH 8/9] x86/dumpstack: Save first regs set for the executive summary

On Fri, Mar 16, 2018 at 06:45:29PM +0100, Borislav Petkov wrote: > > You're better off getting rid of the CR2 line from __show_regs(), > > because it can be dangerously confusing. It's not actually part of the > > saved register state at all, it's something entirely different. It's > > like

Re: [PATCH net-next] net: ethernet: ti: cpsw: enable vlan rx vlan offload

From: Andrew Lunn Date: Fri, 16 Mar 2018 01:29:35 +0100 > On Thu, Mar 15, 2018 at 03:15:50PM -0500, Grygorii Strashko wrote: >> In VLAN_AWARE mode CPSW can insert VLAN header encapsulation word on Host >> port 0 egress (RX) before the packet data if RX_VLAN_ENCAP bit is set in >>

Re: [PATCH net-next] net: ethernet: ti: cpsw: enable vlan rx vlan offload

From: Andrew Lunn Date: Fri, 16 Mar 2018 01:29:35 +0100 > On Thu, Mar 15, 2018 at 03:15:50PM -0500, Grygorii Strashko wrote: >> In VLAN_AWARE mode CPSW can insert VLAN header encapsulation word on Host >> port 0 egress (RX) before the packet data if RX_VLAN_ENCAP bit is set in >> CPSW_CONTROL

Re: [PATCH v4 3/4] PCI: hv: Remove hbus->enum_sem

On Fri, Mar 16, 2018 at 05:41:27PM +, Dexuan Cui wrote: > > From: Lorenzo Pieralisi > > Sent: Friday, March 16, 2018 03:54 > > ... > > Dexuan, > > while applying/updating these patches I notice this one may be squashed > > into:

Re: [PATCH v4 3/4] PCI: hv: Remove hbus->enum_sem

On Fri, Mar 16, 2018 at 05:41:27PM +, Dexuan Cui wrote: > > From: Lorenzo Pieralisi > > Sent: Friday, March 16, 2018 03:54 > > ... > > Dexuan, > > while applying/updating these patches I notice this one may be squashed > > into: https://patchwork.ozlabs.org/patch/886266/ > > > > since they

Re: [PATCH -next 00/22] remove in-kernel syscall invocations (part 2 == netdev)

From: Dominik Brodowski Date: Fri, 16 Mar 2018 18:05:52 +0100 > The rationale of this change is described in patch 1 of part 1[*] as follows: > > The syscall entry points to the kernel defined by SYSCALL_DEFINEx() > and COMPAT_SYSCALL_DEFINEx() should

Re: [PATCH -next 00/22] remove in-kernel syscall invocations (part 2 == netdev)

From: Dominik Brodowski Date: Fri, 16 Mar 2018 18:05:52 +0100 > The rationale of this change is described in patch 1 of part 1[*] as follows: > > The syscall entry points to the kernel defined by SYSCALL_DEFINEx() > and COMPAT_SYSCALL_DEFINEx() should only be called from userspace >

Re: [PATCH v5 2/2] dt-bindings: introduce Command DB for QCOM SoCs

Quoting Lina Iyer (2018-03-14 10:13:30) > +Properties: > +- compatible: > + Usage: required > + Value type: > + Definition: Should be "qcom,cmd-db" > + > +- reg: > + Usage: required > + Value type: > + Definition: The register address that points to the

Re: [PATCH v5 2/2] dt-bindings: introduce Command DB for QCOM SoCs

Quoting Lina Iyer (2018-03-14 10:13:30) > +Properties: > +- compatible: > + Usage: required > + Value type: > + Definition: Should be "qcom,cmd-db" > + > +- reg: > + Usage: required > + Value type: > + Definition: The register address that points to the

RE: [PATCH] storvsc: Set up correct queue depth values for IDE devices

> > Subject: [PATCH] storvsc: Set up correct queue depth values for IDE > > devices > > > > From: Long Li > > > > Unlike SCSI and FC, we don't use multiple channels for IDE. So set > > queue depth correctly for IDE. > > > > Also set the correct cmd_per_lun for all devices. >

RE: [PATCH] storvsc: Set up correct queue depth values for IDE devices

> > Subject: [PATCH] storvsc: Set up correct queue depth values for IDE > > devices > > > > From: Long Li > > > > Unlike SCSI and FC, we don't use multiple channels for IDE. So set > > queue depth correctly for IDE. > > > > Also set the correct cmd_per_lun for all devices. > > > > Signed-off-by:

Re: [PATCH v4 2/2] dt-bindings: introduce Command DB for QCOM SoCs

Quoting Bjorn Andersson (2018-03-07 11:02:49) > On Tue 06 Mar 07:57 PST 2018, Lina Iyer wrote: > > > On Mon, Mar 05 2018 at 16:15 -0700, Bjorn Andersson wrote: > > > On Mon 26 Feb 09:58 PST 2018, Lina Iyer wrote: > > > > As such I think you should just describe only the 0x85fe + 0x2 > >

Re: [PATCH v4 2/2] dt-bindings: introduce Command DB for QCOM SoCs

Quoting Bjorn Andersson (2018-03-07 11:02:49) > On Tue 06 Mar 07:57 PST 2018, Lina Iyer wrote: > > > On Mon, Mar 05 2018 at 16:15 -0700, Bjorn Andersson wrote: > > > On Mon 26 Feb 09:58 PST 2018, Lina Iyer wrote: > > > > As such I think you should just describe only the 0x85fe + 0x2 > >

[PATCH] mm: add config for readahead window

From: Wei Wang Change VM_MAX_READAHEAD value from the default 128KB to a configurable value. This will allow the readahead window to grow to a maximum size bigger than 128KB during boot, which could benefit to sequential read throughput and thus boot performance. Signed-off-by:

[PATCH] mm: add config for readahead window

From: Wei Wang Change VM_MAX_READAHEAD value from the default 128KB to a configurable value. This will allow the readahead window to grow to a maximum size bigger than 128KB during boot, which could benefit to sequential read throughput and thus boot performance. Signed-off-by: Wei Wang ---

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On Thu, 2018-03-15 at 16:26 +0100, Petr Mladek wrote: > On Thu 2018-03-15 15:09:03, Andy Shevchenko wrote: > > On Wed, 2018-03-14 at 15:09 +0100, Petr Mladek wrote: > > > We already prevent crash when dereferencing some obviously broken > > > pointers. But the handling is not consistent. Sometimes

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On Thu, 2018-03-15 at 16:26 +0100, Petr Mladek wrote: > On Thu 2018-03-15 15:09:03, Andy Shevchenko wrote: > > On Wed, 2018-03-14 at 15:09 +0100, Petr Mladek wrote: > > > We already prevent crash when dereferencing some obviously broken > > > pointers. But the handling is not consistent. Sometimes

[PATCH v5 4/9] ipc: Clamp msgmni and shmmni to the real IPCMNI limit

A user can write arbitrary integer values to msgmni and shmmni sysctl parameters without getting error, but the actual limit is really IPCMNI (32k). This can mislead users as they think they can get a value that is not real. Enforcing the limit by failing the sysctl parameter write, however, can

[PATCH v5 4/9] ipc: Clamp msgmni and shmmni to the real IPCMNI limit

A user can write arbitrary integer values to msgmni and shmmni sysctl parameters without getting error, but the actual limit is really IPCMNI (32k). This can mislead users as they think they can get a value that is not real. Enforcing the limit by failing the sysctl parameter write, however, can

[PATCH v5 5/9] ipc: Clamp semmni to the real IPCMNI limit

For SysV semaphores, the semmni value is the last part of the 4-element sem number array. To make semmni behave in a similar way to msgmni and shmmni, we can't directly use the _minmax handler. Instead, a special sem specific handler is added to check the last argument to make sure that it is

[PATCH v5 5/9] ipc: Clamp semmni to the real IPCMNI limit

For SysV semaphores, the semmni value is the last part of the 4-element sem number array. To make semmni behave in a similar way to msgmni and shmmni, we can't directly use the _minmax handler. Instead, a special sem specific handler is added to check the last argument to make sure that it is

[PATCH v5 0/9] ipc: Clamp *mni to the real IPCMNI limit & increase that limit

v4->v5: - Revert the flags back to 16-bit so that there will be no change to the size of ctl_table. - Enhance the sysctl_check_flags() as requested by Luis to perform more checks to spot incorrect ctl_table entries. - Change the sysctl selftest to use dummy sysctls instead of production

[PATCH v5 0/9] ipc: Clamp *mni to the real IPCMNI limit & increase that limit

v4->v5: - Revert the flags back to 16-bit so that there will be no change to the size of ctl_table. - Enhance the sysctl_check_flags() as requested by Luis to perform more checks to spot incorrect ctl_table entries. - Change the sysctl selftest to use dummy sysctls instead of production

[PATCH v5 7/9] test_sysctl: Add ctl_table registration failure test

Incorrect sysctl tables are constructed and fed to the register_sysctl_table() function in the test_sysctl kernel module. The function is supposed to fail the registration of those tables or an error will be printed if no failure is returned. The registration failures will cause other warning and

[PATCH v5 8/9] ipc: Allow boot time extension of IPCMNI from 32k to 2M

The maximum number of unique System V IPC identifiers was limited to 32k. That limit should be big enough for most use cases. However, there are some users out there requesting for more. To satisfy the need of those users, a new boot time kernel option "ipcmni_extend" is added to extend the

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