Re: [PATCH] Force cppc_cpufreq to report values in KHz to fix user space reporting

Hi Al, [auto build test WARNING on pm/linux-next] [also build test WARNING on v4.6-rc3 next-20160415] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Al-Stone/Force-cppc_cpufreq-to-report

Re: [PATCH] Force cppc_cpufreq to report values in KHz to fix user space reporting

Hi Al, [auto build test WARNING on pm/linux-next] [also build test WARNING on v4.6-rc3 next-20160415] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Al-Stone/Force-cppc_cpufreq-to-report

[PATCH] kernfs_path_from_node_locked: don't overwrite nlen

We've calculated @len to be the bytes we need for '/..' entries from @kn_from to the common ancestor, and calculated @nlen to be the extra bytes we need to get from the common ancestor to @kn_to. We use them as such at the end. But in the loop copying the actual entries, we overwrite @nlen. Use

[PATCH] kernfs_path_from_node_locked: don't overwrite nlen

We've calculated @len to be the bytes we need for '/..' entries from @kn_from to the common ancestor, and calculated @nlen to be the extra bytes we need to get from the common ancestor to @kn_to. We use them as such at the end. But in the loop copying the actual entries, we overwrite @nlen. Use

Re: [PATCH v11 0/3] printk: Make printk() completely async

On Sat, 2016-04-16 at 11:55 +0900, Sergey Senozhatsky wrote: > On (04/08/16 02:31), Sergey Senozhatsky wrote: > > > > Hello, > > > > This patch set makes printk() completely asynchronous: new messages > > are getting upended to the kernel printk buffer, but instead of 'direct' > > printing the

Re: [PATCH v11 0/3] printk: Make printk() completely async

On Sat, 2016-04-16 at 11:55 +0900, Sergey Senozhatsky wrote: > On (04/08/16 02:31), Sergey Senozhatsky wrote: > > > > Hello, > > > > This patch set makes printk() completely asynchronous: new messages > > are getting upended to the kernel printk buffer, but instead of 'direct' > > printing the

Re: [PATCH v3 08/15] dmaengine: dw: revisit data_width property

On Fri, Apr 15, 2016 at 03:45:34PM +0300, Andy Shevchenko wrote: > On Wed, 2016-04-13 at 17:40 +0100, Mark Brown wrote: > > On Wed, Apr 13, 2016 at 07:21:53PM +0300, Andy Shevchenko wrote: > > > > > > On Wed, 2016-04-13 at 21:47 +0530, Vinod Koul wrote: > > > > > > > > On Wed, Apr 13, 2016 at

Re: [PATCH v3 08/15] dmaengine: dw: revisit data_width property

On Fri, Apr 15, 2016 at 03:45:34PM +0300, Andy Shevchenko wrote: > On Wed, 2016-04-13 at 17:40 +0100, Mark Brown wrote: > > On Wed, Apr 13, 2016 at 07:21:53PM +0300, Andy Shevchenko wrote: > > > > > > On Wed, 2016-04-13 at 21:47 +0530, Vinod Koul wrote: > > > > > > > > On Wed, Apr 13, 2016 at

Re: [PATCH] dmaengine: pxa: handle bus errors

On Thu, Apr 14, 2016 at 08:23:26PM +0200, Robert Jarzmik wrote: > Vinod Koul writes: > > > On Mon, Mar 28, 2016 at 11:32:24PM +0200, Robert Jarzmik wrote: > >> In the current state, upon bus error the driver will spin endlessly, > >> relaunching the last tx, which will fail

Re: [PATCH] dmaengine: pxa: handle bus errors

On Thu, Apr 14, 2016 at 08:23:26PM +0200, Robert Jarzmik wrote: > Vinod Koul writes: > > > On Mon, Mar 28, 2016 at 11:32:24PM +0200, Robert Jarzmik wrote: > >> In the current state, upon bus error the driver will spin endlessly, > >> relaunching the last tx, which will fail again and again : >

Re: [PATCH v3 0/2] Align mmap address for DAX pmd mappings

On Thu, 14 Apr 2016 10:48:29 -0600 Toshi Kani wrote: > When CONFIG_FS_DAX_PMD is set, DAX supports mmap() using pmd page > size. This feature relies on both mmap virtual address and FS > block (i.e. physical address) to be aligned by the pmd page size. > Users can use mkfs

Re: [PATCH v3 0/2] Align mmap address for DAX pmd mappings

On Thu, 14 Apr 2016 10:48:29 -0600 Toshi Kani wrote: > When CONFIG_FS_DAX_PMD is set, DAX supports mmap() using pmd page > size. This feature relies on both mmap virtual address and FS > block (i.e. physical address) to be aligned by the pmd page size. > Users can use mkfs options to specify FS

Re: [PATCH 09/10] huge pagecache: mmap_sem is unlocked when truncation splits pmd

On Thu, 14 Apr 2016 13:39:22 -0400 Matthew Wilcox wrote: > On Tue, Apr 05, 2016 at 01:55:23PM -0700, Hugh Dickins wrote: > > zap_pmd_range()'s CONFIG_DEBUG_VM !rwsem_is_locked(_sem) BUG() > > will be invalid with huge pagecache, in whatever way it is implemented: > >

Re: [PATCH 09/10] huge pagecache: mmap_sem is unlocked when truncation splits pmd

On Thu, 14 Apr 2016 13:39:22 -0400 Matthew Wilcox wrote: > On Tue, Apr 05, 2016 at 01:55:23PM -0700, Hugh Dickins wrote: > > zap_pmd_range()'s CONFIG_DEBUG_VM !rwsem_is_locked(_sem) BUG() > > will be invalid with huge pagecache, in whatever way it is implemented: > > truncation of a

Re: [PATCH 2/2] rtlwifi: Fix reusable codes in core.c

Julian Calaby writes: > Hi Kalle, > > On Sat, Apr 16, 2016 at 4:25 AM, Kalle Valo wrote: >> Byeoungwook Kim writes: >> >>> rtl_*_delay() functions were reused same codes about addr variable. >>> So i have converted to

Re: [PATCH 2/2] rtlwifi: Fix reusable codes in core.c

Julian Calaby writes: > Hi Kalle, > > On Sat, Apr 16, 2016 at 4:25 AM, Kalle Valo wrote: >> Byeoungwook Kim writes: >> >>> rtl_*_delay() functions were reused same codes about addr variable. >>> So i have converted to rtl_addr_delay() from code about addr variable. >>> >>> Signed-off-by:

Re: [PATCH v3] i2c: mediatek: i2c multi transfer optimization

On Tue, 2016-04-12 at 23:13 +0200, Wolfram Sang wrote: > Hi, > > thanks for the submission! > > On Tue, Mar 08, 2016 at 02:23:51AM +0800, Liguo Zhang wrote: > > Signal complete() in the i2c irq handler after one transfer done, > > and then wait_for_completion_timeout() will return, this

Re: [PATCH v3] i2c: mediatek: i2c multi transfer optimization

On Tue, 2016-04-12 at 23:13 +0200, Wolfram Sang wrote: > Hi, > > thanks for the submission! > > On Tue, Mar 08, 2016 at 02:23:51AM +0800, Liguo Zhang wrote: > > Signal complete() in the i2c irq handler after one transfer done, > > and then wait_for_completion_timeout() will return, this

Re: [PATCH 15/15] parallel lookups: actual switch to rwsem

On Fri, Apr 15, 2016 at 09:02:06PM -0600, Andreas Dilger wrote: > Wouldn't it make sense to have helpers like "inode_read_lock(inode)" or > similar, > so that it is consistent with other parts of the code and easier to find? > It's a bit strange to have the filesystems use "inode_lock()" and

Re: [PATCH 15/15] parallel lookups: actual switch to rwsem

On Fri, Apr 15, 2016 at 09:02:06PM -0600, Andreas Dilger wrote: > Wouldn't it make sense to have helpers like "inode_read_lock(inode)" or > similar, > so that it is consistent with other parts of the code and easier to find? > It's a bit strange to have the filesystems use "inode_lock()" and

[PATCH] mm: Do not discard partial pages with POSIX_FADV_DONTNEED

From: Oleg Drokin I noticed that the logic in fadvise64_64 syscall is incorrect for partial pages. While first page of the region is correctly skipped if it is partial, the last page of the region is mistakenly discarded. This leads to problems for applications that read

[PATCH] mm: Do not discard partial pages with POSIX_FADV_DONTNEED

From: Oleg Drokin I noticed that the logic in fadvise64_64 syscall is incorrect for partial pages. While first page of the region is correctly skipped if it is partial, the last page of the region is mistakenly discarded. This leads to problems for applications that read data in non-page-aligned

Re: [PATCHSET][RFC][CFT] parallel lookups

On Fri, Apr 15, 2016 at 09:02:02PM -0600, Andreas Dilger wrote: > Looks very interesting, and long awaited. How do you see the parallel > operations moving forward? Staying as lookup only, or moving on to parallel > modifications as well? lookup + readdir. Not even atomic_open at this point,

Re: [PATCHSET][RFC][CFT] parallel lookups

On Fri, Apr 15, 2016 at 09:02:02PM -0600, Andreas Dilger wrote: > Looks very interesting, and long awaited. How do you see the parallel > operations moving forward? Staying as lookup only, or moving on to parallel > modifications as well? lookup + readdir. Not even atomic_open at this point,

Re: [PATCHSET][RFC][CFT] parallel lookups

On Apr 15, 2016, at 6:52 PM, Al Viro wrote: > > The thing appears to be working. It's in vfs.git#work.lookups; the > last 5 commits are the infrastructure (fs/namei.c and fs/dcache.c; no changes > in fs/*/*) + actual switch to rwsem. > > The missing bits:

Re: [PATCH 15/15] parallel lookups: actual switch to rwsem

On Apr 15, 2016, at 6:55 PM, Al Viro wrote: > > From: Al Viro > > ta-da! > > The main issue is the lack of down_write_killable(), so the places > like readdir.c switched to plain inode_lock(); once killable > variants of rwsem primitives

Re: [PATCHSET][RFC][CFT] parallel lookups

On Apr 15, 2016, at 6:52 PM, Al Viro wrote: > > The thing appears to be working. It's in vfs.git#work.lookups; the > last 5 commits are the infrastructure (fs/namei.c and fs/dcache.c; no changes > in fs/*/*) + actual switch to rwsem. > > The missing bits: down_write_killable()

Re: [PATCH 15/15] parallel lookups: actual switch to rwsem

On Apr 15, 2016, at 6:55 PM, Al Viro wrote: > > From: Al Viro > > ta-da! > > The main issue is the lack of down_write_killable(), so the places > like readdir.c switched to plain inode_lock(); once killable > variants of rwsem primitives appear, that'll be dealt with. > > lockdep side also

Re: [PATCH v11 0/3] printk: Make printk() completely async

On (04/08/16 02:31), Sergey Senozhatsky wrote: > Hello, > > This patch set makes printk() completely asynchronous: new messages > are getting upended to the kernel printk buffer, but instead of 'direct' > printing the actual print job is performed by a dedicated kthread. > This has the advantage

Re: [PATCH v11 0/3] printk: Make printk() completely async

On (04/08/16 02:31), Sergey Senozhatsky wrote: > Hello, > > This patch set makes printk() completely asynchronous: new messages > are getting upended to the kernel printk buffer, but instead of 'direct' > printing the actual print job is performed by a dedicated kthread. > This has the advantage

Re: [PATCH 2/2] rtlwifi: Fix reusable codes in core.c

Hi Kalle, On Sat, Apr 16, 2016 at 4:25 AM, Kalle Valo wrote: > Byeoungwook Kim writes: > >> rtl_*_delay() functions were reused same codes about addr variable. >> So i have converted to rtl_addr_delay() from code about addr variable. >> >>

Re: [PATCH 2/2] rtlwifi: Fix reusable codes in core.c

Hi Kalle, On Sat, Apr 16, 2016 at 4:25 AM, Kalle Valo wrote: > Byeoungwook Kim writes: > >> rtl_*_delay() functions were reused same codes about addr variable. >> So i have converted to rtl_addr_delay() from code about addr variable. >> >> Signed-off-by: Byeoungwook Kim >> Reviewed-by: Julian

Re: [PATCHv2]brd: set max_discard_sectors properly

> - blk_queue_max_discard_sectors(brd->brd_queue, UINT_MAX); > + blk_queue_max_discard_sectors(brd->brd_queue, UINT_MAX >> 9); Shouldn't we fix the issue by capping to UINT_MAX >> 9 inside blk_queue_max_discard_sectors? That way we'll prevent against having issues like this in any other

Re: [PATCHv2]brd: set max_discard_sectors properly

> - blk_queue_max_discard_sectors(brd->brd_queue, UINT_MAX); > + blk_queue_max_discard_sectors(brd->brd_queue, UINT_MAX >> 9); Shouldn't we fix the issue by capping to UINT_MAX >> 9 inside blk_queue_max_discard_sectors? That way we'll prevent against having issues like this in any other

[PATCH 3/8] genirq: add a helper spread an affinity mask for MSI/MSI-X vectors

Signed-off-by: Christoph Hellwig --- include/linux/interrupt.h | 10 + kernel/irq/Makefile | 1 + kernel/irq/affinity.c | 54 +++ 3 files changed, 65 insertions(+) create mode 100644 kernel/irq/affinity.c diff --git

[PATCH 3/8] genirq: add a helper spread an affinity mask for MSI/MSI-X vectors

Signed-off-by: Christoph Hellwig --- include/linux/interrupt.h | 10 + kernel/irq/Makefile | 1 + kernel/irq/affinity.c | 54 +++ 3 files changed, 65 insertions(+) create mode 100644 kernel/irq/affinity.c diff --git

[PATCH 5/8] blk-mq: allow the driver to pass in an affinity mask

Allow drivers to pass in the affinity mask from the generic interrupt layer, and spread queues based on that. If the driver doesn't pass in a mask we will create it using the genirq helper. As this helper was modelled after the blk-mq algorithm there should be no change in behavior. XXX: Just

[PATCH 5/8] blk-mq: allow the driver to pass in an affinity mask

Allow drivers to pass in the affinity mask from the generic interrupt layer, and spread queues based on that. If the driver doesn't pass in a mask we will create it using the genirq helper. As this helper was modelled after the blk-mq algorithm there should be no change in behavior. XXX: Just

[PATCH 7/8] pci: spread interrupt vectors in pci_alloc_irq_vectors

Set the affinity_mask before allocating vectors. And for now we also need a little hack after allocation, hopefully someone smarter than me can move this into the core code. Signed-off-by: Christoph Hellwig --- drivers/pci/irq.c | 16 +++- 1 file changed, 15

[PATCH 8/8] nvme: switch to use pci_alloc_irq_vectors

Signed-off-by: Christoph Hellwig --- drivers/nvme/host/pci.c | 88 + 1 file changed, 23 insertions(+), 65 deletions(-) diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index ff3c8d7..82730bf 100644 ---

[PATCH 2/8] genirq: Make use of dev->irq_affinity

From: Thomas Gleixner This allows optimized interrupt allocation and affinity settings for multi queue devices MSI-X interrupts. If the device holds a pointer to a cpumask, then this mask is used to: - allocate the interrupt descriptor on the proper nodes - set the

[PATCH 7/8] pci: spread interrupt vectors in pci_alloc_irq_vectors

Set the affinity_mask before allocating vectors. And for now we also need a little hack after allocation, hopefully someone smarter than me can move this into the core code. Signed-off-by: Christoph Hellwig --- drivers/pci/irq.c | 16 +++- 1 file changed, 15 insertions(+), 1

[PATCH 8/8] nvme: switch to use pci_alloc_irq_vectors

Signed-off-by: Christoph Hellwig --- drivers/nvme/host/pci.c | 88 + 1 file changed, 23 insertions(+), 65 deletions(-) diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index ff3c8d7..82730bf 100644 --- a/drivers/nvme/host/pci.c +++

[PATCH 2/8] genirq: Make use of dev->irq_affinity

From: Thomas Gleixner This allows optimized interrupt allocation and affinity settings for multi queue devices MSI-X interrupts. If the device holds a pointer to a cpumask, then this mask is used to: - allocate the interrupt descriptor on the proper nodes - set the default interrupt

[PATCH 1/8] device: Add irq affinity hint cpumask pointer

From: Thomas Gleixner This optional cpumask will be used by the irq core code to optimize interrupt allocation and affinity setup for multiqueue devices. Signed-off-by: Thomas Gleixner --- include/linux/device.h | 4 1 file changed, 4 insertions(+)

[PATCH 1/8] device: Add irq affinity hint cpumask pointer

From: Thomas Gleixner This optional cpumask will be used by the irq core code to optimize interrupt allocation and affinity setup for multiqueue devices. Signed-off-by: Thomas Gleixner --- include/linux/device.h | 4 1 file changed, 4 insertions(+) diff --git a/include/linux/device.h

[PATCH 6/8] pci: provide sensible irq vector alloc/free routines

Hide all the MSI-X vs MSI vs legacy bullshit, and provide an array of interrupt vectors in the pci_dev structure, and ensure we get proper interrupt affinity by default. Signed-off-by: Christoph Hellwig --- drivers/pci/irq.c | 89

[PATCH 4/8] genirq: add a helper to program the pre-set affinity mask into the controller

Signed-off-by: Christoph Hellwig --- include/linux/interrupt.h | 2 ++ kernel/irq/manage.c | 14 ++ 2 files changed, 16 insertions(+) diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h index 67bc1e1f..ae345da 100644 --- a/include/linux/interrupt.h

RFC: automatic interrupt affinity for MSI/MSI-X capable devices

This series enhances the irq and PCI code to allow spreading around MSI and MSI-X vectors so that they have per-cpu affinity if possible, or at least per-node. For that it takes the algorithm from blk-mq, moves it to a common place, and makes it available through a vastly simplified PCI interrupt

[PATCH 4/8] genirq: add a helper to program the pre-set affinity mask into the controller

Signed-off-by: Christoph Hellwig --- include/linux/interrupt.h | 2 ++ kernel/irq/manage.c | 14 ++ 2 files changed, 16 insertions(+) diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h index 67bc1e1f..ae345da 100644 --- a/include/linux/interrupt.h +++

RFC: automatic interrupt affinity for MSI/MSI-X capable devices

This series enhances the irq and PCI code to allow spreading around MSI and MSI-X vectors so that they have per-cpu affinity if possible, or at least per-node. For that it takes the algorithm from blk-mq, moves it to a common place, and makes it available through a vastly simplified PCI interrupt

[PATCH 6/8] pci: provide sensible irq vector alloc/free routines

Hide all the MSI-X vs MSI vs legacy bullshit, and provide an array of interrupt vectors in the pci_dev structure, and ensure we get proper interrupt affinity by default. Signed-off-by: Christoph Hellwig --- drivers/pci/irq.c | 89 -

[PATCH] xen/x86: don't lose event interrupts

On slow platforms with unreliable TSC, such as QEMU emulated machines, it is possible for the kernel to request the next event in the past. In that case, in the current implementation of xen_vcpuop_clockevent, we simply return -ETIME. To be precise the Xen returns -ETIME and we pass it on. However

[PATCH] xen/x86: don't lose event interrupts

On slow platforms with unreliable TSC, such as QEMU emulated machines, it is possible for the kernel to request the next event in the past. In that case, in the current implementation of xen_vcpuop_clockevent, we simply return -ETIME. To be precise the Xen returns -ETIME and we pass it on. However

pmd_set_huge and ACPI warnings

Not sure if this is the right place to post. If it is not please direct me to where I should go. I am running x86_64 kernel 4.4.6 on an Intel Xeon D system. This is an SOC system that includes dual 10G ethernet using the ixgbe driver. I have also tested this on kernels 4.2 through 4.6rc3 with

pmd_set_huge and ACPI warnings

Not sure if this is the right place to post. If it is not please direct me to where I should go. I am running x86_64 kernel 4.4.6 on an Intel Xeon D system. This is an SOC system that includes dual 10G ethernet using the ixgbe driver. I have also tested this on kernels 4.2 through 4.6rc3 with

Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled

On 01/29, Stefan Agner wrote: > If a clock gets enabled early during boot time, it can lead to a PLL > startup. The wait_lock function makes sure that the PLL is really > stareted up before it gets used. However, the function sleeps which > leads to scheduling and an error: > bad: scheduling from

Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled

On 01/29, Stefan Agner wrote: > If a clock gets enabled early during boot time, it can lead to a PLL > startup. The wait_lock function makes sure that the PLL is really > stareted up before it gets used. However, the function sleeps which > leads to scheduling and an error: > bad: scheduling from

[PATCH 05/15] orangefs: don't open-code inode_lock/inode_unlock

From: Al Viro Signed-off-by: Al Viro --- fs/orangefs/file.c| 4 ++-- fs/orangefs/orangefs-kernel.h | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/orangefs/file.c b/fs/orangefs/file.c index

[PATCH 07/15] reconnect_one(): use lookup_one_len_unlocked()

From: Al Viro ... and explain the non-obvious logics in case when lookup yields a different dentry. Signed-off-by: Al Viro --- fs/exportfs/expfs.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git

[PATCH 05/15] orangefs: don't open-code inode_lock/inode_unlock

From: Al Viro Signed-off-by: Al Viro --- fs/orangefs/file.c| 4 ++-- fs/orangefs/orangefs-kernel.h | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/orangefs/file.c b/fs/orangefs/file.c index ae92795..491e82c 100644 --- a/fs/orangefs/file.c +++

[PATCH 07/15] reconnect_one(): use lookup_one_len_unlocked()

From: Al Viro ... and explain the non-obvious logics in case when lookup yields a different dentry. Signed-off-by: Al Viro --- fs/exportfs/expfs.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/fs/exportfs/expfs.c b/fs/exportfs/expfs.c index c46f1a1..402c5ca

[PATCH 10/15] __d_add(): don't drop/regain ->d_lock

From: Al Viro Signed-off-by: Al Viro --- fs/dcache.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/fs/dcache.c b/fs/dcache.c index e9de4d9..33cad8a 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -2363,11

[PATCH 08/15] ovl_lookup_real(): use lookup_one_len_unlocked()

From: Al Viro Signed-off-by: Al Viro --- fs/overlayfs/super.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c index 14cab38..4c26225 100644 --- a/fs/overlayfs/super.c +++

[PATCH 09/15] lookup_slow(): bugger off on IS_DEADDIR() from the very beginning

From: Al Viro Signed-off-by: Al Viro --- fs/namei.c | 23 +-- 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/fs/namei.c b/fs/namei.c index c0d551f..6fb33a7 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -1603,8

[PATCH 06/15] reiserfs: open-code reiserfs_mutex_lock_safe() in reiserfs_unpack()

From: Al Viro ... and have it use inode_lock() Signed-off-by: Al Viro --- fs/reiserfs/ioctl.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/fs/reiserfs/ioctl.c b/fs/reiserfs/ioctl.c index 036a1fc..f49afe7 100644 ---

[PATCH 10/15] __d_add(): don't drop/regain ->d_lock

From: Al Viro Signed-off-by: Al Viro --- fs/dcache.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/fs/dcache.c b/fs/dcache.c index e9de4d9..33cad8a 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -2363,11 +2363,19 @@ EXPORT_SYMBOL(d_rehash); static inline

[PATCH 08/15] ovl_lookup_real(): use lookup_one_len_unlocked()

From: Al Viro Signed-off-by: Al Viro --- fs/overlayfs/super.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c index 14cab38..4c26225 100644 --- a/fs/overlayfs/super.c +++ b/fs/overlayfs/super.c @@ -378,9 +378,7 @@ static inline

[PATCH 09/15] lookup_slow(): bugger off on IS_DEADDIR() from the very beginning

From: Al Viro Signed-off-by: Al Viro --- fs/namei.c | 23 +-- 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/fs/namei.c b/fs/namei.c index c0d551f..6fb33a7 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -1603,8 +1603,15 @@ static struct dentry

[PATCH 06/15] reiserfs: open-code reiserfs_mutex_lock_safe() in reiserfs_unpack()

From: Al Viro ... and have it use inode_lock() Signed-off-by: Al Viro --- fs/reiserfs/ioctl.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/fs/reiserfs/ioctl.c b/fs/reiserfs/ioctl.c index 036a1fc..f49afe7 100644 --- a/fs/reiserfs/ioctl.c +++ b/fs/reiserfs/ioctl.c @@

[PATCH 15/15] parallel lookups: actual switch to rwsem

From: Al Viro ta-da! The main issue is the lack of down_write_killable(), so the places like readdir.c switched to plain inode_lock(); once killable variants of rwsem primitives appear, that'll be dealt with. lockdep side also might need more work Signed-off-by: Al

[PATCH 11/15] beginning of transition to parallel lookups - marking in-lookup dentries

From: Al Viro marked as such when (would be) parallel lookup is about to pass them to actual ->lookup(); unmarked when * __d_add() is about to make it hashed, positive or not. * __d_move() (from d_splice_alias(), directly or via __d_unalias()) puts a

[PATCH 15/15] parallel lookups: actual switch to rwsem

From: Al Viro ta-da! The main issue is the lack of down_write_killable(), so the places like readdir.c switched to plain inode_lock(); once killable variants of rwsem primitives appear, that'll be dealt with. lockdep side also might need more work Signed-off-by: Al Viro --- fs/btrfs/ioctl.c

[PATCH 11/15] beginning of transition to parallel lookups - marking in-lookup dentries

From: Al Viro marked as such when (would be) parallel lookup is about to pass them to actual ->lookup(); unmarked when * __d_add() is about to make it hashed, positive or not. * __d_move() (from d_splice_alias(), directly or via __d_unalias()) puts a preexisting dentry in its

[PATCH 13/15] parallel lookups machinery, part 3

From: Al Viro We will need to be able to check if there is an in-lookup dentry with matching parent/name. Right now it's impossible, but as soon as start locking directories shared such beasts will appear. Add a secondary hash for locating those. Hash chains go

[PATCH 14/15] parallel lookups machinery, part 4 (and last)

From: Al Viro If we *do* run into an in-lookup match, we need to wait for it to cease being in-lookup. Fortunately, we do have unused space in in-lookup dentries - d_lru is never looked at until it stops being in-lookup. So we can stash a pointer to wait_queue_head

[PATCH 12/15] parallel lookups machinery, part 2

From: Al Viro We'll need to verify that there's neither a hashed nor in-lookup dentry with desired parent/name before adding to in-lookup set. One possible solution would be to hold the parent's ->d_lock through both checks, but while the in-lookup set is relatively

[PATCH 14/15] parallel lookups machinery, part 4 (and last)

From: Al Viro If we *do* run into an in-lookup match, we need to wait for it to cease being in-lookup. Fortunately, we do have unused space in in-lookup dentries - d_lru is never looked at until it stops being in-lookup. So we can stash a pointer to wait_queue_head from stack frame of the

[PATCH 12/15] parallel lookups machinery, part 2

From: Al Viro We'll need to verify that there's neither a hashed nor in-lookup dentry with desired parent/name before adding to in-lookup set. One possible solution would be to hold the parent's ->d_lock through both checks, but while the in-lookup set is relatively small at any time, dcache is

[PATCH 13/15] parallel lookups machinery, part 3

From: Al Viro We will need to be able to check if there is an in-lookup dentry with matching parent/name. Right now it's impossible, but as soon as start locking directories shared such beasts will appear. Add a secondary hash for locating those. Hash chains go through the same space where

[PATCH 02/15] kernfs: use lookup_one_len_unlocked()

From: Al Viro Signed-off-by: Al Viro --- fs/kernfs/mount.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/fs/kernfs/mount.c b/fs/kernfs/mount.c index b67dbcc..e006d30 100644 --- a/fs/kernfs/mount.c +++

[PATCH 01/15] security_d_instantiate(): move to the point prior to attaching dentry to inode

From: Al Viro Signed-off-by: Al Viro --- fs/dcache.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/fs/dcache.c b/fs/dcache.c index 32ceae3..e9de4d9 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -1772,11

[PATCH 03/15] configfs_detach_prep(): make sure that wait_mutex won't go away

From: Al Viro grab a reference to dentry we'd got the sucker from, and return that dentry via *wait, rather than just returning the address of ->i_mutex. Signed-off-by: Al Viro --- fs/configfs/dir.c | 17 + 1 file changed, 9

[PATCH 02/15] kernfs: use lookup_one_len_unlocked()

From: Al Viro Signed-off-by: Al Viro --- fs/kernfs/mount.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/fs/kernfs/mount.c b/fs/kernfs/mount.c index b67dbcc..e006d30 100644 --- a/fs/kernfs/mount.c +++ b/fs/kernfs/mount.c @@ -120,9 +120,8 @@ struct dentry

[PATCH 01/15] security_d_instantiate(): move to the point prior to attaching dentry to inode

From: Al Viro Signed-off-by: Al Viro --- fs/dcache.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/fs/dcache.c b/fs/dcache.c index 32ceae3..e9de4d9 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -1772,11 +1772,11 @@ void d_instantiate(struct dentry *entry,

[PATCH 03/15] configfs_detach_prep(): make sure that wait_mutex won't go away

From: Al Viro grab a reference to dentry we'd got the sucker from, and return that dentry via *wait, rather than just returning the address of ->i_mutex. Signed-off-by: Al Viro --- fs/configfs/dir.c | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git

[PATCH 04/15] ocfs2: don't open-code inode_lock/inode_unlock

From: Al Viro Signed-off-by: Al Viro --- fs/ocfs2/aops.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/ocfs2/aops.c b/fs/ocfs2/aops.c index 1581240..f048a33 100644 --- a/fs/ocfs2/aops.c +++ b/fs/ocfs2/aops.c @@

[PATCH 04/15] ocfs2: don't open-code inode_lock/inode_unlock

From: Al Viro Signed-off-by: Al Viro --- fs/ocfs2/aops.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/ocfs2/aops.c b/fs/ocfs2/aops.c index 1581240..f048a33 100644 --- a/fs/ocfs2/aops.c +++ b/fs/ocfs2/aops.c @@ -2311,7 +2311,7 @@ static void

RE: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

> -Original Message- > From: KY Srinivasan > Sent: Friday, April 15, 2016 9:01 AM > To: 'Alexander Duyck' > Cc: David Miller ; Netdev > ; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org; o...@aepfle.de;

RE: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

> -Original Message- > From: KY Srinivasan > Sent: Friday, April 15, 2016 9:01 AM > To: 'Alexander Duyck' > Cc: David Miller ; Netdev > ; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org; o...@aepfle.de; Robo Bot > ; Jason Wang ; > e...@mellanox.com; ja...@mellanox.com;

[PATCHSET][RFC][CFT] parallel lookups

The thing appears to be working. It's in vfs.git#work.lookups; the last 5 commits are the infrastructure (fs/namei.c and fs/dcache.c; no changes in fs/*/*) + actual switch to rwsem. The missing bits: down_write_killable() (there had been a series posted introducing just that; for

[PATCHSET][RFC][CFT] parallel lookups

The thing appears to be working. It's in vfs.git#work.lookups; the last 5 commits are the infrastructure (fs/namei.c and fs/dcache.c; no changes in fs/*/*) + actual switch to rwsem. The missing bits: down_write_killable() (there had been a series posted introducing just that; for

Re: [PATCH] clk: ti: dra7-atl-clock: Fix of_node reference counting

On 03/11, Peter Ujfalusi wrote: > of_find_node_by_name() will call of_node_put() on the node so we need to > get it first to avoid warnings. > The cfg_node needs to be put after we have finished processing the > properties. > > Signed-off-by: Peter Ujfalusi > --- Applied

Re: [PATCH] clk: ti: dra7-atl-clock: Fix of_node reference counting

On 03/11, Peter Ujfalusi wrote: > of_find_node_by_name() will call of_node_put() on the node so we need to > get it first to avoid warnings. > The cfg_node needs to be put after we have finished processing the > properties. > > Signed-off-by: Peter Ujfalusi > --- Applied to clk-next --

Re: [PATCH 1/5] clk: ti: am335x/am4372: Add tbclk to pwm node

On 03/07, Franklin S Cooper Jr wrote: > Add tblck to the pwm nodes. This insures that the ehrpwm driver has access > to the time-based clk. > > Do not remove similar entries for ehrpwm node. Later patches will switch > from using ehrpwm node name to pwm. But to maintain ABI compatibility we >

Re: [PATCH 1/5] clk: ti: am335x/am4372: Add tbclk to pwm node

On 03/07, Franklin S Cooper Jr wrote: > Add tblck to the pwm nodes. This insures that the ehrpwm driver has access > to the time-based clk. > > Do not remove similar entries for ehrpwm node. Later patches will switch > from using ehrpwm node name to pwm. But to maintain ABI compatibility we >

Re: [RESEND PATCH v10 2/6] clk: hisilicon: add CRG driver for hi3519 soc

On 04/15, Jiancheng Xue wrote: > Hi, > > On 2016/3/31 16:10, Jiancheng Xue wrote: > > From: Jiancheng Xue > > > > The CRG(Clock and Reset Generator) block provides clock > > and reset signals for other modules in hi3519 soc. > > > > Signed-off-by: Jiancheng Xue

Re: [RESEND PATCH v10 2/6] clk: hisilicon: add CRG driver for hi3519 soc

On 04/15, Jiancheng Xue wrote: > Hi, > > On 2016/3/31 16:10, Jiancheng Xue wrote: > > From: Jiancheng Xue > > > > The CRG(Clock and Reset Generator) block provides clock > > and reset signals for other modules in hi3519 soc. > > > > Signed-off-by: Jiancheng Xue > > Acked-by: Rob Herring > >

Re: [RESEND PATCH v10 2/6] clk: hisilicon: add CRG driver for hi3519 soc

On 03/31, Jiancheng Xue wrote: > diff --git a/drivers/clk/hisilicon/clk-hi3519.c > b/drivers/clk/hisilicon/clk-hi3519.c > new file mode 100644 > index 000..ee9df82 > --- /dev/null > +++ b/drivers/clk/hisilicon/clk-hi3519.c > @@ -0,0 +1,129 @@ > +/* > + * Hi3519 Clock Driver > + * > + *

Re: [RESEND PATCH v10 2/6] clk: hisilicon: add CRG driver for hi3519 soc

On 03/31, Jiancheng Xue wrote: > diff --git a/drivers/clk/hisilicon/clk-hi3519.c > b/drivers/clk/hisilicon/clk-hi3519.c > new file mode 100644 > index 000..ee9df82 > --- /dev/null > +++ b/drivers/clk/hisilicon/clk-hi3519.c > @@ -0,0 +1,129 @@ > +/* > + * Hi3519 Clock Driver > + * > + *

  1   2   3   4   5   6   7   8   9   10   >