[patch 2/2] dma: ipu: Consolidate duplicated irq handlers

[Thomas Gleixner]

The functions irq_irq_err and ipu_irq_fn are identical plus/minus the
comments. Remove one.

Signed-off-by: Thomas Gleixner 
Cc: Vinod Koul 
Cc: Dan Williams 
Cc: dmaeng...@vger.kernel.org
---
 drivers/dma/ipu/ipu_irq.c |   46 --
 1 file changed, 4 insertions(+), 42 deletions(-)

Index: linux-next/drivers/dma/ipu/ipu_irq.c
===
--- linux-next.orig/drivers/dma/ipu/ipu_irq.c
+++ linux-next/drivers/dma/ipu/ipu_irq.c
@@ -265,8 +265,8 @@ int ipu_irq_unmap(unsigned int source)
return ret;
 }
 
-/* Chained IRQ handler for IPU error interrupt */
-static void ipu_irq_err(unsigned int __irq, struct irq_desc *desc)
+/* Chained IRQ handler for IPU function and error interrupt */
+static void ipu_irq_handler(unsigned int __irq, struct irq_desc *desc)
 {
struct ipu *ipu = irq_desc_get_handler_data(desc);
u32 status;
@@ -307,44 +307,6 @@ static void ipu_irq_err(unsigned int __i
}
 }
 
-/* Chained IRQ handler for IPU function interrupt */
-static void ipu_irq_fn(unsigned int __irq, struct irq_desc *desc)
-{
-   struct ipu *ipu = irq_desc_get_handler_data(desc);
-   u32 status;
-   int i, line;
-
-   for (i = 0; i < IPU_IRQ_NR_FN_BANKS; i++) {
-   struct ipu_irq_bank *bank = irq_bank + i;
-
-   raw_spin_lock(&bank_lock);
-   status = ipu_read_reg(ipu, bank->status);
-   /* Not clearing all interrupts, see above */
-   status &= ipu_read_reg(ipu, bank->control);
-   raw_spin_unlock(&bank_lock);
-   while ((line = ffs(status))) {
-   struct ipu_irq_map *map;
-   unsigned int irq;
-
-   line--;
-   status &= ~(1UL << line);
-
-   raw_spin_lock(&bank_lock);
-   map = src2map(32 * i + line);
-   if (map)
-   irq = map->irq;
-   raw_spin_unlock(&bank_lock);
-
-   if (!map) {
-   pr_err("IPU: Interrupt on unmapped source %u 
bank %d\n",
-  line, i);
-   continue;
-   }
-   generic_handle_irq(irq);
-   }
-   }
-}
-
 static struct irq_chip ipu_irq_chip = {
.name   = "ipu_irq",
.irq_ack= ipu_irq_ack,
@@ -384,9 +346,9 @@ int __init ipu_irq_attach_irq(struct ipu
 #endif
}
 
-   irq_set_chained_handler_and_data(ipu->irq_fn, ipu_irq_fn, ipu);
+   irq_set_chained_handler_and_data(ipu->irq_fn, ipu_irq_handler, ipu);
 
-   irq_set_chained_handler_and_data(ipu->irq_err, ipu_irq_err, ipu);
+   irq_set_chained_handler_and_data(ipu->irq_err, ipu_irq_handler, ipu);
 
ipu->irq_base = irq_base;
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 0/2] dma: ipu: Preparation for API change and consolidation

[Thomas Gleixner]

The first patch prepares the interrupt handlers for removal of the irq
argument.

While doing that I noticed that the handler functions are
identical. Consolidate them.

Thanks,

tglx

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 1/2] dma: ipu: Prepare irq handlers for irq argument removal

[Thomas Gleixner]

The irq argument of most interrupt flow handlers is unused or merily
used instead of a local variable. The handlers which need the irq
argument can retrieve the irq number from the irq descriptor.

Search and update was done with coccinelle and the invaluable help of
Julia Lawall.

Signed-off-by: Thomas Gleixner 
Cc: Julia Lawall 
Cc: Vinod Koul 
Cc: Dan Williams 
Cc: dmaeng...@vger.kernel.org
---
 drivers/dma/ipu/ipu_irq.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

Index: linux-next/drivers/dma/ipu/ipu_irq.c
===
--- linux-next.orig/drivers/dma/ipu/ipu_irq.c
+++ linux-next/drivers/dma/ipu/ipu_irq.c
@@ -266,7 +266,7 @@ int ipu_irq_unmap(unsigned int source)
 }
 
 /* Chained IRQ handler for IPU error interrupt */
-static void ipu_irq_err(unsigned int irq, struct irq_desc *desc)
+static void ipu_irq_err(unsigned int __irq, struct irq_desc *desc)
 {
struct ipu *ipu = irq_desc_get_handler_data(desc);
u32 status;
@@ -286,6 +286,7 @@ static void ipu_irq_err(unsigned int irq
raw_spin_unlock(&bank_lock);
while ((line = ffs(status))) {
struct ipu_irq_map *map;
+   unsigned int irq;
 
line--;
status &= ~(1UL << line);
@@ -307,7 +308,7 @@ static void ipu_irq_err(unsigned int irq
 }
 
 /* Chained IRQ handler for IPU function interrupt */
-static void ipu_irq_fn(unsigned int irq, struct irq_desc *desc)
+static void ipu_irq_fn(unsigned int __irq, struct irq_desc *desc)
 {
struct ipu *ipu = irq_desc_get_handler_data(desc);
u32 status;
@@ -323,6 +324,7 @@ static void ipu_irq_fn(unsigned int irq,
raw_spin_unlock(&bank_lock);
while ((line = ffs(status))) {
struct ipu_irq_map *map;
+   unsigned int irq;
 
line--;
status &= ~(1UL << line);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.14 000/125] 3.14.49-stable review

[Sudip Mukherjee]

On Fri, Jul 31, 2015 at 12:40:00PM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.14.49 release.
> There are 125 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Aug  2 19:40:05 UTC 2015.
> Anything received after that time might be too late.
Compiled and booted on x86_32.

While kselftest got a report of segmentation fault and in dmesg:
psock_fanout[2509]: segfault at 401fd000 ip 080492ab sp bfc40cd0 error 4
in psock_fanout[8048000+2000]

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] kthread: Export kthread functions

[yalin wang]

> 在 2015年7月31日，22:14，Thomas Gleixner  写道：
> 
> 
> On Fri, 31 Jul 2015, Thomas Gleixner wrote:
> 
>> On Fri, 31 Jul 2015, yalin wang wrote:
>>> it is optimised to 2 instructions ,
>>> 
>>> this is my patch, hope can be merged :
>> 
>> We are not exposing the internals of kthread management. Period.
> 
> And your 'optimization' is completely bogus:
> 
> Before your modification:
> 
> size kernel/built-in.o
> 
>   text   data bss dec hex filename
> 1091514141498  341928 1574940  18081c ../build/kernel/built-in.o
> 
> After:
> 
>   text   data bss dec hex filename
> 1091664  141498  341928 1575090  1808b2   ../build/kernel/built-in.o
> 
> That's an increase of text size by 150 byte. Interesting optimization.
> 
> Thanks,
> 
>   tglx
> 
> 
strange,  this is my test result:

size   built-in.o*
  text data bss dec hex filename
74393750786   56008  850731   cfb2b built-in.o// with the patch
74406950786   56008  850863   cfbaf built-in.o_old  // with out the patch

you can see text size is reduced.
in addition, because we don’t use EXPORT_SYMBOLS() for inline function,
some data can also be removed,

[27] __ksymtab_strings PROGBITS   000a7fe0
  3907     A   0 0 1
0x3907

[27] __ksymtab_strings PROGBITS   000a8020
  392f     A   0 0 1
0x392f

you can see after apply the patch, this string section is also reduced,
but size command output seems not calculate these special section,
there are lots of special sections in linux kernel image,
i think size command is not suitable to calculate kernel image, maybe it just
calculate formal section which name like   .data  .text   etc..

Thanks--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.14 000/125] 3.14.49-stable review

[Sudip Mukherjee]

On Sat, Aug 01, 2015 at 12:39:25PM +0530, Sudip Mukherjee wrote:
> On Fri, Jul 31, 2015 at 12:40:00PM -0700, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.14.49 release.
> > There are 125 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Aug  2 19:40:05 UTC 2015.
> > Anything received after that time might be too late.
> Compiled and booted on x86_32.
> 
> While kselftest got a report of segmentation fault and in dmesg:
> psock_fanout[2509]: segfault at 401fd000 ip 080492ab sp bfc40cd0 error 4
>   in psock_fanout[8048000+2000]

Missed a clarification, kselftest is not there. ran the tests with:
sudo make -C tools/testing/selftests run_tests

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] kthread: Export kthread functions

[Thomas Gleixner]

On Sat, 1 Aug 2015, yalin wang wrote:
> size   built-in.o*
>   text   data bss dec hex filename
> 743937  50786   56008  850731   cfb2b built-in.o// with the 
> patch
> 744069  50786   56008  850863   cfbaf built-in.o_old  // with out the 
> patch

Not all architectures/compilers are giving the same results.

> i think size command is not suitable to calculate kernel image, maybe it just
> calculate formal section which name like   .data  .text   etc..

Nonsense. .text is .text no matter what.

Anyway, it's not going to change.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: v4.2-rc dcache regression, probably 75a6f82a0d10

[Al Viro]

On Fri, Jul 31, 2015 at 03:52:38PM -0700, Linus Torvalds wrote:

> Is that correct? Maybe, I haven't checked. And maybe it's a big bad
> bug. Regardless, it sure as hell isn't just changing the order of the
> access to those fields. That "DCACHE_ENTRY_TYPE | DCACHE_FALLTHRU"
> clearing came from __d_instantiate(), but now it hits __d_obtain_alias
> too.

Actually, the shit had hit the fan earlier.  Look: in
commit b18825a7c8e37a7cf6abb97a12a6ad71af160de7
Author: David Howells 
Date:   Thu Sep 12 19:22:53 2013 +0100

VFS: Put a small type field into struct dentry::d_flags

we have this:
@@ -1823,7 +1794,7 @@ static int link_path_walk(const char *name, struct 
nameidata *nd)
if (err)
return err;
}
-   if (!can_lookup(nd->inode)) {
+   if (!d_is_directory(nd->path.dentry)) {
err = -ENOTDIR; 
break;
}

And that has turned the check done to an inode that *was* ours at some
point (i.e. fetching it had been followed by checking that ->d_seq had
been still valid) into something completely unprotected.  Suppose we
are in lazy mode and somebody had evicted nd->path.dentry after we'd looked
it up and before that check.  Sure, its ->d_seq had been bumped by that,
and we would've failed anyway.  With ECHILD.  Which, unlike ENOTDIR, is
"repeat in non-lazy mode".

AFAICS, that's where the problem is.  It affects only RCU mode and only
the places where dentry isn't pinned.  That place in link_path_walk() is
trivial - we just need to do
if (unlikely(!d_can_lookup(nd->path.dentry))) {
if (nd->flags & LOOKUP_RCU) {
if (unlazy_walk(nd, NULL, 0))
return -ECHILD;
}
return -ENOTDIR;
}
there.  AFAICS, other places of that sort are not a problem anymore.

Folks, could you check if this fixes the problems you are seeing?

diff --git a/fs/namei.c b/fs/namei.c
index ae4e4c1..b16c3a7 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1954,7 +1954,11 @@ OK:
continue;
}
}
-   if (unlikely(!d_can_lookup(nd->path.dentry)))
+   if (unlikely(!d_can_lookup(nd->path.dentry))) {
+   if (nd->flags & LOOKUP_RCU) {
+   if (unlazy_walk(nd, NULL, 0))
+   return -ECHILD;
+   }
return -ENOTDIR;
}
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 3/5] ARM: Exynos: switch to using generic cpufreq driver for Exynos4x12

[Krzysztof Kozlowski]

W dniu 01.08.2015 o 03:49, Bartlomiej Zolnierkiewicz pisze:
> The new CPU clock type allows the use of generic CPUfreq driver.
> Switch Exynos4x12 to using generic cpufreq driver.
> 
> Also make CPUFREQ_DT config option select Exynos thermal driver
> if Exynos platform support is enabled.

Why? I think this wasn't in your previous patch.

Best regards,
Krzysztof


> 
> Please also note that the switch to use the generic cpufreq-dt
> driver fixes the minor issue present with the old code (support
> for 'boost' mode in the exynos-cpufreq driver was enabled for
> all supported SoCs even though 'boost' frequency was provided
> only for Exynos4x12 ones).
> 
> Cc: Tomasz Figa 
> Cc: Kukjin Kim 
> Cc: Thomas Abraham 
> Cc: Javier Martinez Canillas 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
>  arch/arm/mach-exynos/exynos.c | 2 ++
>  drivers/cpufreq/Kconfig   | 1 +
>  2 files changed, 3 insertions(+)
> 
> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
> index 77ac021..1c47aee 100644
> --- a/arch/arm/mach-exynos/exynos.c
> +++ b/arch/arm/mach-exynos/exynos.c
> @@ -227,6 +227,8 @@ static void __init exynos_init_irq(void)
>  static const struct of_device_id exynos_cpufreq_matches[] = {
>   { .compatible = "samsung,exynos3250", .data = "cpufreq-dt" },
>   { .compatible = "samsung,exynos4210", .data = "cpufreq-dt" },
> + { .compatible = "samsung,exynos4212", .data = "cpufreq-dt" },
> + { .compatible = "samsung,exynos4412", .data = "cpufreq-dt" },
>   { .compatible = "samsung,exynos5250", .data = "cpufreq-dt" },
>   { /* sentinel */ }
>  };
> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> index 659879a..bf6d596 100644
> --- a/drivers/cpufreq/Kconfig
> +++ b/drivers/cpufreq/Kconfig
> @@ -191,6 +191,7 @@ config CPUFREQ_DT
>   # if CPU_THERMAL is on and THERMAL=m, CPUFREQ_DT cannot be =y:
>   depends on !CPU_THERMAL || THERMAL
>   select PM_OPP
> + select EXYNOS_THERMAL if ARCH_EXYNOS
>   help
> This adds a generic DT based cpufreq driver for frequency management.
> It supports both uniprocessor (UP) and symmetric multiprocessor (SMP)
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [tip:x86/asm] x86/vm86: Clean up vm86.h includes

[Ingo Molnar]

* Brian Gerst  wrote:

> On Fri, Jul 31, 2015 at 10:04 AM, tip-bot for Brian Gerst
>  wrote:
> > Commit-ID:  ba3e127ec105e790eeec4034d9769e018e4a1b54
> > Gitweb: 
> > http://git.kernel.org/tip/ba3e127ec105e790eeec4034d9769e018e4a1b54
> > Author: Brian Gerst 
> > AuthorDate: Wed, 29 Jul 2015 01:41:21 -0400
> > Committer:  Ingo Molnar 
> > CommitDate: Fri, 31 Jul 2015 13:31:10 +0200
> >
> > x86/vm86: Clean up vm86.h includes
> >
> > vm86.h was being implicitly included in alot of places via
> > processor.h, which in turn got it from math_emu.h.  Break that
> > chain and explicitly include vm86.h in all files that need it.
> > Also remove unused vm86 field from math_emu_info.
> >
> > Signed-off-by: Brian Gerst 
> > Cc: Andy Lutomirski 
> > Cc: Borislav Petkov 
> > Cc: Denys Vlasenko 
> > Cc: H. Peter Anvin 
> > Cc: Linus Torvalds 
> > Cc: Peter Zijlstra 
> > Cc: Thomas Gleixner 
> > Link: 
> > http://lkml.kernel.org/r/1438148483-11932-7-git-send-email-brge...@gmail.com
> > [ Fixed build failure. ]
> > Signed-off-by: Ingo Molnar 
> 
> 
> > diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
> > index f35ed53..d4cda5e 100644
> > --- a/drivers/scsi/dpt_i2o.c
> > +++ b/drivers/scsi/dpt_i2o.c
> > @@ -1924,6 +1924,9 @@ static void adpt_alpha_info(sysInfo_S* si)
> >  #endif
> >
> >  #if defined __i386__
> > +
> > +#include 
> > +
> >  static void adpt_i386_info(sysInfo_S* si)
> >  {
> > // This is all the info we need for now
> 
> It would have been better to just remove the the CPU_* defines from
> this driver.  boot_cpu_data.x86 is simply the family ID from CPUID,
> and nowhere else uses defines like this.

Please send a followup patch for that.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.10 00/89] 3.10.85-stable review

[Sudip Mukherjee]

On Fri, Jul 31, 2015 at 12:40:42PM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.85 release.
> There are 89 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Aug  2 19:40:13 UTC 2015.
> Anything received after that time might be too late.
Compiled and booted on x86_32. No errors in dmesg.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] x86 fixes

[Ingo Molnar]

Linus,

Please pull the latest x86-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
x86-urgent-for-linus

   # HEAD: 37868fe113ff2ba814b3b4eb12df214df555f8dc x86/ldt: Make modify_ldt 
synchronous

Fallout from the recent NMI fixes: make x86 LDT handling more robust.
Also some EFI fixes.

  out-of-topic modifications in x86-urgent-for-linus:
  -
  drivers/firmware/efi/efi.c # 9115c7589b11: efi: Check for NULL efi 
kern

 Thanks,

Ingo

-->
Andy Lutomirski (2):
  x86/xen: Probe target addresses in set_aliased_prot() before the hypercall
  x86/ldt: Make modify_ldt synchronous

Dmitry Skorodumov (1):
  x86/efi: Use all 64 bit of efi_memmap in setup_e820()

Jiang Liu (1):
  x86/irq: Use the caller provided polarity setting in mp_check_pin_attr()

Ricardo Neri (1):
  efi: Check for NULL efi kernel parameters


 arch/x86/boot/compressed/eboot.c   |   4 +
 arch/x86/include/asm/desc.h|  15 ---
 arch/x86/include/asm/mmu.h |   3 +-
 arch/x86/include/asm/mmu_context.h |  54 +++-
 arch/x86/kernel/apic/io_apic.c |   2 +-
 arch/x86/kernel/cpu/common.c   |   4 +-
 arch/x86/kernel/cpu/perf_event.c   |  12 +-
 arch/x86/kernel/ldt.c  | 262 -
 arch/x86/kernel/process_64.c   |   4 +-
 arch/x86/kernel/step.c |   6 +-
 arch/x86/platform/efi/efi.c|   5 +
 arch/x86/power/cpu.c   |   3 +-
 arch/x86/xen/enlighten.c   |  40 ++
 drivers/firmware/efi/efi.c |   5 +
 14 files changed, 265 insertions(+), 154 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 2c82bd150d43..7d69afd8b6fa 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -1193,6 +1193,10 @@ static efi_status_t setup_e820(struct boot_params 
*params,
unsigned int e820_type = 0;
unsigned long m = efi->efi_memmap;
 
+#ifdef CONFIG_X86_64
+   m |= (u64)efi->efi_memmap_hi << 32;
+#endif
+
d = (efi_memory_desc_t *)(m + (i * efi->efi_memdesc_size));
switch (d->type) {
case EFI_RESERVED_TYPE:
diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index a0bf89fd2647..4e10d73cf018 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -280,21 +280,6 @@ static inline void clear_LDT(void)
set_ldt(NULL, 0);
 }
 
-/*
- * load one particular LDT into the current CPU
- */
-static inline void load_LDT_nolock(mm_context_t *pc)
-{
-   set_ldt(pc->ldt, pc->size);
-}
-
-static inline void load_LDT(mm_context_t *pc)
-{
-   preempt_disable();
-   load_LDT_nolock(pc);
-   preempt_enable();
-}
-
 static inline unsigned long get_desc_base(const struct desc_struct *desc)
 {
return (unsigned)(desc->base0 | ((desc->base1) << 16) | ((desc->base2) 
<< 24));
diff --git a/arch/x86/include/asm/mmu.h b/arch/x86/include/asm/mmu.h
index 09b9620a73b4..364d27481a52 100644
--- a/arch/x86/include/asm/mmu.h
+++ b/arch/x86/include/asm/mmu.h
@@ -9,8 +9,7 @@
  * we put the segment information here.
  */
 typedef struct {
-   void *ldt;
-   int size;
+   struct ldt_struct *ldt;
 
 #ifdef CONFIG_X86_64
/* True if mm supports a task running in 32 bit compatibility mode. */
diff --git a/arch/x86/include/asm/mmu_context.h 
b/arch/x86/include/asm/mmu_context.h
index 804a3a6030ca..984abfe47edc 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -34,6 +34,50 @@ static inline void load_mm_cr4(struct mm_struct *mm) {}
 #endif
 
 /*
+ * ldt_structs can be allocated, used, and freed, but they are never
+ * modified while live.
+ */
+struct ldt_struct {
+   /*
+* Xen requires page-aligned LDTs with special permissions.  This is
+* needed to prevent us from installing evil descriptors such as
+* call gates.  On native, we could merge the ldt_struct and LDT
+* allocations, but it's not worth trying to optimize.
+*/
+   struct desc_struct *entries;
+   int size;
+};
+
+static inline void load_mm_ldt(struct mm_struct *mm)
+{
+   struct ldt_struct *ldt;
+
+   /* lockless_dereference synchronizes with smp_store_release */
+   ldt = lockless_dereference(mm->context.ldt);
+
+   /*
+* Any change to mm->context.ldt is followed by an IPI to all
+* CPUs with the mm active.  The LDT will not be freed until
+* after the IPI is handled by all such CPUs.  This means that,
+* if the ldt_struct changes before we return, the values we see
+* will be safe, and the new values will be loaded before we run
+* any user code.
+*
+* NB: don't try to convert this to use RCU without extreme care.
+* We would still need IRQs off, because we d

!

[Rita]

When and What time can i Call you? Respond ASAP
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Git pull] irq updates for 4.2

[Thomas Gleixner]

Linus,

please pull the latest irq-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
irq-urgent-for-linus

Just two updates to the maintainers file.

Thanks,

tglx

-->
Thomas Gleixner (2):
  MAINTAINERS: Appoint Marc Zyngier as irqchips co-maintainer
  MAINTAINERS: Appoint Jiang and Marc as irqdomain maintainers


 MAINTAINERS | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9289ecb57b68..a9ae6c105520 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5600,6 +5600,7 @@ F:kernel/irq/
 IRQCHIP DRIVERS
 M: Thomas Gleixner 
 M: Jason Cooper 
+M: Marc Zyngier 
 L: linux-kernel@vger.kernel.org
 S: Maintained
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core
@@ -5608,11 +5609,14 @@ F:  
Documentation/devicetree/bindings/interrupt-controller/
 F: drivers/irqchip/
 
 IRQ DOMAINS (IRQ NUMBER MAPPING LIBRARY)
-M: Benjamin Herrenschmidt 
+M: Jiang Liu 
+M: Marc Zyngier 
 S: Maintained
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core
 F: Documentation/IRQ-domain.txt
 F: include/linux/irqdomain.h
 F: kernel/irq/irqdomain.c
+F: kernel/irq/msi.c
 
 ISAPNP
 M: Jaroslav Kysela 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] arm64:change jump_label to use branch instruction, not use NOP instr

[yalin wang]

> 在 2015年7月31日，18:14，Will Deacon  写道：
> 
> On Fri, Jul 31, 2015 at 10:33:55AM +0100, Peter Zijlstra wrote:
>> On Fri, Jul 31, 2015 at 05:25:02PM +0800, yalin wang wrote:
 On Jul 31, 2015, at 15:52, Peter Zijlstra  wrote:
 On Fri, Jul 31, 2015 at 03:41:37PM +0800, yalin wang wrote:
> This change a little arch_static_branch(), use b . + 4 for false
> return, why? According to aarch64 TRM, if both source and dest
> instr are branch instr, can patch the instr directly, don't need
> all cpu to do ISB for sync, this means we can call
> aarch64_insn_patch_text_nosync() during patch_text(),
> will improve the performance when change a static_key.
 
 This doesn't parse.. What?
 
 Also, this conflicts with the jump label patches I've got.
>>> 
>>> this is arch depend , you can see aarch64_insn_patch_text( ) for more info,
>>> if aarch64_insn_hotpatch_safe() is true, will patch the text directly.
>> 
>> So I patched all arches, including aargh64.
>> 
>>> what is your git branch base? i make the patch based on linux-next branch,
>>> maybe a little delay than yours , could you share your branch git address?
>>> i can make a new based on yours .
>> 
>> https://git.kernel.org/cgit/linux/kernel/git/peterz/queue.git/log/?h=locking/jump_label
>> 
>> Don't actually use that branch for anything permanent, this is throw-away
>> git stuff.
>> 
>> But you're replacing a NOP with an unconditional branch to the next
>> instruction? I suppose I'll leave that to Will and co.. I just had
>> trouble understanding your Changelog -- also I was very much not awake
>> yet.
> 
> Optimising the (hopefully rare) patching operation but having a potential
> impact on the runtime code (assumedly a hotpath) seems completely backwards
> to me.
> 
> Yalin, do you have a reason for this change or did you just notice that
> paragraph in the architecture and decide to apply it here?
> 
in fact, i don’t have any special reason to must change like this, just found 
we can do this when i read
AARCH64 TRM,  then i make this patch :)


> Even then, I think there are technical issues with the proposal, since
> we could get spurious execution of the old code without 
> explicitsynchronisation (see the kick_all_cpus_sync() call in
> aarch64_insn_patch_text).
i think jump_label code don’t have responsibility to make sure the sync with 
other cores,
if it is not safe to execute old and new patch code on different cores, the 
caller should 
do this sync, he can cancel  a work_struct  /  cu_sync()  or some thing like 
this,
i have a look at the software implementation (!HAVE_JUMP_LABEL) ,
it also doesn’t do any sync, just atomic_inc()  and return directly .

if the ARCH technology concern is not a matter, i think we can apply it  :) 

in fact , i have another solution for jump_label, i see we calculate the jump 
instruction every time ,
why  not let the compiler do this during compile time , during run time , we 
just need swap it with NOP 
instruction,  and by this method, we don’t need store target address in struct 
jump_entry ,
it can save some space ,

this is my patch for this method :
—
yalin@ubuntu:~/linux-next$ git diff
diff --git a/arch/arm64/include/asm/jump_label.h 
b/arch/arm64/include/asm/jump_label.h
index 1b5e0e8..c040cd3 100644
--- a/arch/arm64/include/asm/jump_label.h
+++ b/arch/arm64/include/asm/jump_label.h
@@ -28,16 +28,17 @@
 
 static __always_inline bool arch_static_branch(struct static_key *key, bool 
branch)
 {
-   asm goto("1: nop\n\t"
+   asm goto("1: b %l[l_no]\n\t"
 ".pushsection __jump_table,  \"aw\"\n\t"
 ".align 3\n\t"
-".quad 1b, %l[l_yes], %c0\n\t"
+".word %c0 - 1b\n\t"
+"nop\n\t"
+".quad %c0\n\t"
 ".popsection\n\t"
-:  :  "i"(&((char *)key)[branch]) :  : l_yes);
-
-   return false;
-l_yes:
+:  :  "i"(&((char *)key)[branch]) :  : l_no);
return true;
+l_no:
+   return false;
 }
 
 static __always_inline bool arch_static_branch_jump(struct static_key *key, 
bool branch)
@@ -45,10 +46,11 @@ static __always_inline bool arch_static_branch_jump(struct 
static_key *key, bool
asm goto("1: b %l[l_yes]\n\t"
 ".pushsection __jump_table,  \"aw\"\n\t"
 ".align 3\n\t"
-".quad 1b, %l[l_yes], %c0\n\t"
+".word %c0 - 1b\n\t"
+"nop\n\t"
+".quad %c0\n\t"
 ".popsection\n\t"
 :  :  "i"(&((char *)key)[branch]) :  : l_yes);
-
return false;
 l_yes:
return true;
@@ -57,8 +59,8 @@ l_yes:
 typedef u64 jump_label_t;
 
 struct jump_entry {
-   jump_label_t code;
-   jump_label_t target;
+   s32 offset;
+   u32 insn;
jump_label_t key;
...skipping...
@@ -45,10 +46,11 @@ static __always_inline bool arch_static_branch_jump(struct 
static_key *key, bool
asm goto("1: b %

[tip:timers/core] clockevents: Drop redundant cpumask check in tick_check_new_device()

[tip-bot for Luiz Capitulino]

Commit-ID:  d74892c5b291c0010295d26d6b1e11cd70451722
Gitweb: http://git.kernel.org/tip/d74892c5b291c0010295d26d6b1e11cd70451722
Author: Luiz Capitulino 
AuthorDate: Wed, 29 Jul 2015 15:14:17 -0400
Committer:  Thomas Gleixner 
CommitDate: Sat, 1 Aug 2015 12:00:13 +0200

clockevents: Drop redundant cpumask check in tick_check_new_device()

The same check is performed by tick_check_percpu().

Signed-off-by: Luiz Capitulino 
Link: http://lkml.kernel.org/r/20150729151417.069d1...@redhat.com
Signed-off-by: Thomas Gleixner 
---
 kernel/time/tick-common.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index f8bf475..d11c55b 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -304,9 +304,6 @@ void tick_check_new_device(struct clock_event_device 
*newdev)
int cpu;
 
cpu = smp_processor_id();
-   if (!cpumask_test_cpu(cpu, newdev->cpumask))
-   goto out_bc;
-
td = &per_cpu(tick_cpu_device, cpu);
curdev = td->evtdev;
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: serialize LVTT and TSC_DEADLINE write

[Thomas Gleixner]

On Fri, 31 Jul 2015, Shaohua Li wrote:
> @@ -336,6 +336,22 @@ static void __setup_APIC_LVTT(unsigned int clocks, int 
> oneshot, int irqen)
>   apic_write(APIC_LVTT, lvtt_value);
>  
>   if (lvtt_value & APIC_LVT_TIMER_TSCDEADLINE) {
> + u64 msr;
> +
> + /*
> +  * See Intel SDM: TSC-Deadline Mode chapter. In xAPIC mode,
> +  * writing APIC LVTT and TSC_DEADLINE MSR isn't serialized.
> +  * This uses the algorithm described in Intel SDM to serialize
> +  * the two writes
> +  * */
> + while (1) {
> + wrmsrl(MSR_IA32_TSC_DEADLINE, -1L);
> + rdmsrl(MSR_IA32_TSC_DEADLINE, msr);
> + if (msr)
> + break;
> + }
> + wrmsrl(MSR_IA32_TSC_DEADLINE, 0);


I think this is exceptionally silly. A proper fence after the
apic_write() should have the same effect.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] linux-next: drivers: staging: most: Fix return value

[Christian Gromm]

On Fri, 31 Jul 2015 22:18:17 +0200
Michael Hornung  wrote:

> * Fix sparse warning "Using plain integer as NULL pointer"
> 
> Signed-off-by: Michael Hornung 
Acked-by: Christian Gromm 
> ---
>  drivers/staging/most/aim-network/networking.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/most/aim-network/networking.c 
> b/drivers/staging/most/aim-network/networking.c
> index 4639c49..c8ab239 100644
> --- a/drivers/staging/most/aim-network/networking.c
> +++ b/drivers/staging/most/aim-network/networking.c
> @@ -311,7 +311,7 @@ static struct net_dev_context *get_net_dev_context(
>   }
>   }
>   spin_unlock(&list_lock);
> - return 0;
> + return NULL;
>  }
>  
>  static int aim_probe_channel(struct most_interface *iface, int channel_idx,

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Nokia N900 - audio TPA6130A2 problems

[Pali Rohár]

On Saturday 25 July 2015 15:17:13 Lars-Peter Clausen wrote:
> On 07/25/2015 12:28 PM, Pali Rohár wrote:
> > Hello,
> > 
> > sometimes after rebooting Nokia N900 initializing alsa audio fails.
> > Here output from dmesg log when it happen:
> > 
> > [6.925140] tpa6130a2 2-0060: Write failed
> > [6.929534] tpa6130a2 2-0060: Failed to initialize chip
> > [6.935272] tpa6130a2: probe of 2-0060 failed with error -121
> > [7.624237] rx51-audio n900-audio: Failed to add TPA6130A2
> > controls [7.635101] rx51-audio n900-audio: ASoC: failed to
> > init TLV320AIC34: -19 [7.645874] rx51-audio n900-audio: ASoC:
> > failed to instantiate card -19 [7.665740] rx51-audio
> > n900-audio: snd_soc_register_card failed (-19) [8.063049] ALSA
> > device list:
> > [8.070343]   No soundcards found.
> > 
> > Any idea what to do?
> 
> Looks like the chip is not responding. Try to add a small delay after
> powerup to give the device to be fully ready, something like the
> following:
> 
> --- a/sound/soc/codecs/tpa6130a2.c
> +++ b/sound/soc/codecs/tpa6130a2.c
> @@ -152,6 +152,8 @@ static int tpa6130a2_power(u8 power)
>   if (data->power_gpio >= 0)
>   gpio_set_value(data->power_gpio, 1);
> 
> + msleep(5);
> +
>   data->power_state = 1;
>   ret = tpa6130a2_initialize();
>   if (ret < 0) {


Hello, your patch did not helped. Problem is still there...

Now I found another problem:
[   28.102233] omap_i2c 48072000.i2c: controller timed out

Anyway, if you are interested here is full dmesg log:

[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 4.2.0-rc2+ (pali@Pali-Latitude) (gcc version 4.6.3 
(Ubuntu/Linaro 4.6.3-1ubuntu5) ) #368 
PREEMPT Sat Aug 1 12:07:46 CEST 2015
[0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing 
instruction cache
[0.00] Machine model: Nokia N900
[0.00] Memory policy: Data cache writeback
[0.00] On node 0 totalpages: 65280
[0.00] free_area_init_node: node 0, pgdat c069a40c, node_mem_map 
cfcf9000
[0.00]   Normal zone: 512 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 65280 pages, LIFO batch:15
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 64768
[0.00] Kernel command line: rootdelay root=/dev/ram0 log_buf_len=20M
[0.00] log_buf_len: 33554432 bytes
[0.00] early log buf free: 64332(98%)
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Memory: 203424K/261120K available (4443K kernel code, 308K 
rwdata, 1720K rodata, 264K init, 266K bss, 
57696K reserved, 0K cma-reserved, 0K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xd080 - 0xff00   ( 744 MB)
[0.00] lowmem  : 0xc000 - 0xd000   ( 256 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc060d0c8   (6165 kB)
[0.00]   .init : 0xc060e000 - 0xc065   ( 264 kB)
[0.00]   .data : 0xc065 - 0xc069d3dc   ( 309 kB)
[0.00].bss : 0xc069d3dc - 0xc06dfc4c   ( 267 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] Preemptible hierarchical RCU implementation.
[0.00]  Build-time adjustment of leaf fanout to 32.
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 
interrupts
[0.00] Clocking rate (Crystal/Core/MPU): 19.2/332/500 MHz
[0.00] OMAP clockevent source: timer1 at 32768 Hz
[0.00] clocksource: 32k_counter: mask: 0x max_cycles: 
0x, max_idle_ns: 58327039986419 ns
[0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 
6553584741ns
[0.00] OMAP clocksource: 32k_counter at 32768 Hz
[0.000305] Console: colour dummy device 80x30
[0.001586] console [tty0] enabled
[0.001647] Calibrating delay loop... 496.43 BogoMIPS (lpj=2482176)
[0.048828] pid_max: default: 32768 minimum: 301
[0.048980] Security Framework initialized
[0.049102] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0

Re: v4.2-rc dcache regression, probably 75a6f82a0d10

[Dominique Martinet]

Al Viro wrote on Sat, Aug 01, 2015:
> And that has turned the check done to an inode that *was* ours at some
> point (i.e. fetching it had been followed by checking that ->d_seq had
> been still valid) into something completely unprotected.  Suppose we
> are in lazy mode and somebody had evicted nd->path.dentry after we'd looked
> it up and before that check.  Sure, its ->d_seq had been bumped by that,
> and we would've failed anyway.  With ECHILD.  Which, unlike ENOTDIR, is
> "repeat in non-lazy mode".

That sounds like a good find, I was looking at how to claim/protect the
entry somehow as well but I just have no idea...

> Folks, could you check if this fixes the problems you are seeing?
> 
> diff --git a/fs/namei.c b/fs/namei.c
> index ae4e4c1..b16c3a7 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -1954,7 +1954,11 @@ OK:
>   continue;
>   }
>   }
> - if (unlikely(!d_can_lookup(nd->path.dentry)))
> + if (unlikely(!d_can_lookup(nd->path.dentry))) {
> + if (nd->flags & LOOKUP_RCU) {
> + if (unlazy_walk(nd, NULL, 0))
> + return -ECHILD;
> + }
>   return -ENOTDIR;
>   }
>  }

Unfortunately, still happens for me.

I had to adapt a bit because using an old kernel (4bf46a272), will try
again with a recent master to doublecheck, but I had a break on
the "if (nd->flags & LOOKUP_RCU)" check:
 - sometimes fails without ever hitting the check. I think this fixes
the "ENOTDIR" I had described, but there's at least another way to
fail?
 - When we do hit it, we're into LOOKUP_RCU at this point alright,
unlazy_walk fails and we try again without RCU -- can confirm the
recovery process goes OK (well, that it went OK at least once)


Thanks,
-- 
Dominique
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 03/11] ocfs2: Less checks in ocfs2_rename() after error detection

[SF Markus Elfring]

>> From: Markus Elfring 
>> Date: Sat, 4 Jul 2015 15:30:18 +0200
>>
>> Skip checks for a few variables in three error handling cases within
>> the ocfs2_rename() function by adjustment of a few jump targets
>> according to the Linux coding style convention.
>>
>> Signed-off-by: Markus Elfring 
> 
> I don't think this is an improvement.

How do you think about the other update suggestions from this patch series?

Can the corresponding source code review be continued?

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/5] ARM: dts: Exynos4x12: add CPU OPP and regulator supply property

[Viresh Kumar]

On 31-07-15, 20:49, Bartlomiej Zolnierkiewicz wrote:
> For Exynos4x12 platforms, add CPU operating points (using
> opp-v2 bindings) and CPU regulator supply properties for
> migrating from Exynos specific cpufreq driver to using
> generic cpufreq driver.
> 
> Based on the earlier work by Thomas Abraham.
> 
> Cc: Kukjin Kim 
> Cc: Doug Anderson 
> Cc: Andreas Faerber 
> Cc: Thomas Abraham 
> Reviewed-by: Javier Martinez Canillas 
> Reviewed-by: Krzysztof Kozlowski 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
>  arch/arm/boot/dts/exynos4212.dtsi   | 81 
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi |  4 ++
>  arch/arm/boot/dts/exynos4412-origen.dts |  4 ++
>  arch/arm/boot/dts/exynos4412-trats2.dts |  4 ++
>  arch/arm/boot/dts/exynos4412.dtsi   | 83 
> +
>  5 files changed, 176 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos4212.dtsi 
> b/arch/arm/boot/dts/exynos4212.dtsi
> index d9c8efee..5389011 100644
> --- a/arch/arm/boot/dts/exynos4212.dtsi
> +++ b/arch/arm/boot/dts/exynos4212.dtsi
> @@ -30,6 +30,9 @@
>   device_type = "cpu";
>   compatible = "arm,cortex-a9";
>   reg = <0xA00>;
> + clocks = <&clock CLK_ARM_CLK>;
> + clock-names = "cpu";
> + operating-points-v2 = <&cpu0_opp_table>;
>   cooling-min-level = <13>;
>   cooling-max-level = <7>;
>   #cooling-cells = <2>; /* min followed by max */
> @@ -39,6 +42,84 @@
>   device_type = "cpu";
>   compatible = "arm,cortex-a9";
>   reg = <0xA01>;
> + operating-points-v2 = <&cpu0_opp_table>;
> + };
> + };
> +
> + cpu0_opp_table: opp_table0 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <90>;
> + clock-latency-ns = <20>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <3>;
> + opp-microvolt = <90>;
> + clock-latency-ns = <20>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <4>;
> + opp-microvolt = <925000>;
> + clock-latency-ns = <20>;
> + };
> + opp03 {
> + opp-hz = /bits/ 64 <5>;
> + opp-microvolt = <95>;
> + clock-latency-ns = <20>;
> + };
> + opp04 {
> + opp-hz = /bits/ 64 <6>;
> + opp-microvolt = <975000>;
> + clock-latency-ns = <20>;
> + };
> + opp05 {
> + opp-hz = /bits/ 64 <7>;
> + opp-microvolt = <987500>;
> + clock-latency-ns = <20>;
> + };
> + opp06 {
> + opp-hz = /bits/ 64 <8>;
> + opp-microvolt = <100>;
> + clock-latency-ns = <20>;
> + };
> + opp07 {
> + opp-hz = /bits/ 64 <9>;
> + opp-microvolt = <1037500>;
> + clock-latency-ns = <20>;
> + };
> + opp08 {
> + opp-hz = /bits/ 64 <10>;
> + opp-microvolt = <1087500>;
> + clock-latency-ns = <20>;
> + };
> + opp09 {
> + opp-hz = /bits/ 64 <11>;
> + opp-microvolt = <1137500>;
> + clock-latency-ns = <20>;
> + };
> + opp10 {
> + opp-hz = /bits/ 64 <12>;
> + opp-microvolt = <1187500>;
> + clock-latency-ns = <20>;
> + };
> + opp11 {
> + opp-hz = /bits/ 64 <13>;
> + opp-microvolt = <125>;
> + clock-latency-ns = <20>;
> + };
> + opp12 {
> + opp-hz = /bits/ 64 <14>;
> + opp-microvolt = <1287500>;
> + clock-latency-ns = <20>;
> + };
> + opp13 {
> + opp-hz = /bits/ 64 <15>;
> + opp-microvolt = <135>;
> + clock-latency-ns = <20>;
> + turbo-mode;
>   };
>   };
>  };

I'm lovin' it :)

Acked-by: Viresh Kumar 

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-k

Re: [PATCH v3 4/5] cpufreq: exynos: remove Exynos4x12 specific cpufreq driver support

[Viresh Kumar]

Cc'ing Rafael, please keep him in loop for such patches and better use
get_maintainers to get the cc list automatically.

On 31-07-15, 20:49, Bartlomiej Zolnierkiewicz wrote:
> Exynos4x12 based platforms have switched over to use generic
> cpufreq driver for cpufreq functionality.  So the Exynos
> specific cpufreq support for these platforms can be removed.
> 
> Also once Exynos4x12 based platforms support have been removed
> the shared exynos-cpufreq driver is no longer needed and can
> be deleted.
> 
> Based on the earlier work by Thomas Abraham.
> 
> Cc: Viresh Kumar 
> Cc: Thomas Abraham 
> Reviewed-by: Javier Martinez Canillas 
> Reviewed-by: Krzysztof Kozlowski 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
>  drivers/cpufreq/Kconfig.arm  |  38 --
>  drivers/cpufreq/Makefile |   2 -
>  drivers/cpufreq/exynos-cpufreq.c | 236 
> ---
>  drivers/cpufreq/exynos-cpufreq.h |  72 ---
>  drivers/cpufreq/exynos4x12-cpufreq.c | 236 
> ---
>  5 files changed, 584 deletions(-)
>  delete mode 100644 drivers/cpufreq/exynos-cpufreq.c
>  delete mode 100644 drivers/cpufreq/exynos-cpufreq.h
>  delete mode 100644 drivers/cpufreq/exynos4x12-cpufreq.c

Acked-by: Viresh Kumar 

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: v4.2-rc dcache regression, probably 75a6f82a0d10

[Dominique Martinet]

Dominique Martinet wrote on Sat, Aug 01, 2015:
> I had to adapt a bit because using an old kernel (4bf46a272), will try
> again with a recent master to doublecheck

There have been more changes than what I thought, can't seem to
reproduce in a while on linus' HEAD with that fix (it fell in that
check quite a few times already).

I'll let test run all weekend to be safe, but it looks good to me!

-- 
Dominique
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 6/6] stop_machine: kill stop_cpus_lock and lg_double_lock/unlock()

[Oleg Nesterov]

Hi Peter,

Thanks for looking. I'll try to reply on Monday, just one note...

On 07/30, Peter Zijlstra wrote:
>
> On Tue, Jul 21, 2015 at 09:22:47PM +0200, Oleg Nesterov wrote:
>
> > +static int cpu_stop_queue_two_works(int cpu1, struct cpu_stop_work *work1,
> > +   int cpu2, struct cpu_stop_work *work2)
> > +{
> > +   struct cpu_stopper *stopper1 = per_cpu_ptr(&cpu_stopper, cpu1);
> > +   struct cpu_stopper *stopper2 = per_cpu_ptr(&cpu_stopper, cpu2);
> > +   int err;
> > +retry:
> > +   spin_lock_irq(&stopper1->lock);
> > +   spin_lock_nested(&stopper2->lock, SINGLE_DEPTH_NESTING);
> > +   /*
> > +* If we observe both CPUs active we know _cpu_down() cannot yet have
> > +* queued its stop_machine works and therefore ours will get executed
> > +* first. Or its not either one of our CPUs that's getting unplugged,
> > +* in which case we don't care.
> > +*/
> > +   err = -ENOENT;
> > +   if (!cpu_active(cpu1) || !cpu_active(cpu2))
> > +   goto unlock;
> > +
> > +   WARN_ON(!stopper1->enabled || !stopper2->enabled);
> > +   /*
> > +* Ensure that if we race with stop_cpus() the stoppers won't
> > +* get queued up in reverse order, leading to system deadlock.
> > +*/
> > +   err = -EDEADLK;
> > +   if (stop_work_pending(stopper1) != stop_work_pending(stopper2))
> > +   goto unlock;
>
> You could DoS/false positive this by running stop_one_cpu() in a loop,
> and thereby 'always' having work pending on one but not the other.

IIRC no. I am pretty sure stop_one_cpu() doesn't use stopper->stop_work,
only stop_machine() does.

Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] regmap: remove redundant $(CONFIG_REGMAP) in Makefile

[Mark Brown]

On Sat, Aug 01, 2015 at 04:42:27AM +0900, Masahiro Yamada wrote:
> Kbuild descends into drivers/base/regmap/ only when CONFIG_REGMAP
> is enabled. (see drivers/base/Makefile)
> 
> $(CONFIG_REGMAP) in drivers/base/regmap/Makefile always evaluates
> to 'y'.

> -obj-$(CONFIG_REGMAP) += regmap.o regcache.o
> -obj-$(CONFIG_REGMAP) += regcache-rbtree.o regcache-lzo.o regcache-flat.o
> +obj-y += regmap.o regcache.o
> +obj-y += regcache-rbtree.o regcache-lzo.o regcache-flat.o
>  obj-$(CONFIG_DEBUG_FS) += regmap-debugfs.o
>  obj-$(CONFIG_REGMAP_AC97) += regmap-ac97.o
>  obj-$(CONFIG_REGMAP_I2C) += regmap-i2c.o

OTOH it does make the Makefile look a bit neater to have everything
selected by config option...  is there a practical cost here?


signature.asc
Description: Digital signature

Re: [PATCH v3 5/5] cpufreq: remove no longer needed CPU_FREQ_BOOST_SW config option

[Viresh Kumar]

On 31-07-15, 20:49, Bartlomiej Zolnierkiewicz wrote:
> Remove no longer needed CPU_FREQ_BOOST_SW config option.
> 
> As a result scaling_boost_freqs sysfs attribute is available
> when cpufreq-dt driver is used and boost support is enabled.
> 
> Cc: Viresh Kumar 
> Cc: Thomas Abraham 
> Cc: Javier Martinez Canillas 
> Cc: Krzysztof Kozlowski 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
>  drivers/cpufreq/Kconfig  | 4 
>  drivers/cpufreq/freq_table.c | 2 --
>  2 files changed, 6 deletions(-)
> 
> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> index bf6d596..de00a52 100644
> --- a/drivers/cpufreq/Kconfig
> +++ b/drivers/cpufreq/Kconfig
> @@ -21,10 +21,6 @@ if CPU_FREQ
>  config CPU_FREQ_GOV_COMMON
>   bool
>  
> -config CPU_FREQ_BOOST_SW
> - bool
> - depends on THERMAL
> -
>  config CPU_FREQ_STAT
>   tristate "CPU frequency translation statistics"
>   default y
> diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
> index a8f1daf..4c5de5b 100644
> --- a/drivers/cpufreq/freq_table.c
> +++ b/drivers/cpufreq/freq_table.c
> @@ -293,9 +293,7 @@ EXPORT_SYMBOL_GPL(cpufreq_freq_attr_scaling_boost_freqs);
>  
>  struct freq_attr *cpufreq_generic_attr[] = {
>   &cpufreq_freq_attr_scaling_available_freqs,
> -#ifdef CONFIG_CPU_FREQ_BOOST_SW
>   &cpufreq_freq_attr_scaling_boost_freqs,
> -#endif
>   NULL,
>  };
>  EXPORT_SYMBOL_GPL(cpufreq_generic_attr);

So, this will start appearing for all platforms that use cpufreq_generic_attr
and that may not be the right thing. We may only want to show boost frequencies
only if the driver supports it.

@Rafael: What do you say?

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 3/5] ARM: Exynos: switch to using generic cpufreq driver for Exynos4x12

[Viresh Kumar]

On 31-07-15, 20:49, Bartlomiej Zolnierkiewicz wrote:
> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> index 659879a..bf6d596 100644
> --- a/drivers/cpufreq/Kconfig
> +++ b/drivers/cpufreq/Kconfig
> @@ -191,6 +191,7 @@ config CPUFREQ_DT
>   # if CPU_THERMAL is on and THERMAL=m, CPUFREQ_DT cannot be =y:
>   depends on !CPU_THERMAL || THERMAL
>   select PM_OPP
> + select EXYNOS_THERMAL if ARCH_EXYNOS
>   help
> This adds a generic DT based cpufreq driver for frequency management.
> It supports both uniprocessor (UP) and symmetric multiprocessor (SMP)

No, we shouldn't pollute generic Kconfig options with platform specific stuff.
Why don't you enable thermal in your .config?

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 14/15] mm: Drop unlikely before IS_ERR(_OR_NULL)

[Viresh Kumar]

On 31-07-15, 11:00, Joe Perches wrote:
> On Fri, 2015-07-31 at 16:36 +0530, Viresh Kumar wrote:
> > On 31-07-15, 03:28, Joe Perches wrote:
> > > If it's all fixed, then it's unlikely to be needed in checkpatch.
> > 
> > I thought checkpatch is more about not committing new mistakes, rather than
> > finding them in old code.
> 
> True, but checkpatch is more about style than substance.
> 
> There are a lot of things that _could_ be added to the script
> but don't have to be because of relative rarity.
> 
> The unanswered fundamental though is whether the unlikely use
> in #define IS_ERR_VALUE is useful.
> 
> include/linux/err.h:21:#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned 
> long)-MAX_ERRNO)
> 
> How often does using unlikely here make the code smaller/faster
> with more recent compilers than gcc 3.4?  Or even using gcc 3.4.

No idea :)


-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Applied "regulator: fan53555: Export I2C module alias information" to the regulator tree

[Mark Brown]

The patch

   regulator: fan53555: Export I2C module alias information

has been applied to the regulator tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From e80c47bd738badeaa70b1114d4cd75f892672bd3 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas 
Date: Thu, 30 Jul 2015 18:18:40 +0200
Subject: [PATCH] regulator: fan53555: Export I2C module alias information

The I2C core always reports the MODALIAS uevent as "i2c:
Signed-off-by: Mark Brown 
---
 drivers/regulator/fan53555.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/regulator/fan53555.c b/drivers/regulator/fan53555.c
index 4286568..4940e82 100644
--- a/drivers/regulator/fan53555.c
+++ b/drivers/regulator/fan53555.c
@@ -439,6 +439,7 @@ static const struct i2c_device_id fan53555_id[] = {
},
{ },
 };
+MODULE_DEVICE_TABLE(i2c, fan53555_id);
 
 static struct i2c_driver fan53555_regulator_driver = {
.driver = {
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] scripts/kernel-doc Allow struct arguments documentation in struct body

[Jonathan Corbet]

On Fri, 31 Jul 2015 18:06:45 -0300
Danilo Cesar Lemes de Paula  wrote:

> Describing arguments at top of a struct definition works fine
> for small/medium size structs, but it definitely doesn't work well
> for struct with a huge list of elements.
> 
> Keeping the arguments list inside the struct body makes it easier
> to maintain the documentation.

Interesting approach.  I think it could make sense, but I fear pushback
from a subset of maintainers refusing to accept this mode.  I wonder what
it would take to get a consensus on allowing these in-struct comments?

I'm wondering if we need a kernel summit session on commenting
conventions, markdown-in-kerneldoc, etc?  Maybe I'll stick a proposal out
there.

Thanks,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 05/15] drivers: input: Drop unlikely before IS_ERR(_OR_NULL)

[Viresh Kumar]

On 31-07-15, 09:58, Dmitry Torokhov wrote:
> On Fri, Jul 31, 2015 at 02:08:25PM +0530, Viresh Kumar wrote:
> > IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there
> > is no need to do that again from its callers. Drop it.
> 
> I'd rather keep it as it documents the expected behavior and double
> unlikely should work just fine.

TBH, I don't really agree that it is there for documentation. The only purpose
of such compiler flags is to try make code more efficient.

Anyway, I got to this series as someone asked me to fix this for one of my
patches which used unlikely(IS_ERR_OR_NULL()). And so I thought about fixing all
sites that are doing double unlikely (that shouldn't hurt for sure).

I will leave it to you.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] thermal/cpu_cooling: remove local cooling state variable

[Viresh Kumar]

On 31-07-15, 08:30, Radivoje Jovanovic wrote:
> I just looked over the notifier in the current upstream (my patch was
> made on our production kernel which is 3.14 and has old notifier
> implementation with notifier_device in place) and I see your point.

That's disappointing. You were expected to check if the same problem
exists in mainline.

> I agree with you that this patch is trivial for the current
> implementation since the notifier, as it is currently, will enforce
> cpu_cooling policy change at every CPUFREQ_ADJUST which would cause
> problems in our current implementation. In our implementation there is
> a cpufreq driver that will also change policies during CPUFREQ_ADJUST,
> once the request comes from the underlying FW so there would be a fight
> who gets there first since cpu_cooling will change the policy in
> CPUFREQ_ADJUST notifier_chain and the driver would do the same thing.
> It seems to me that better implementation of the cpu_cooling notifer
> would be to keep the flag and change the policy in CPUFREQ_ADJUST only
> when the change was requested by cpu_cooling, and update the current
> state of cpufreq_cooling_device during CPUFREQ_NOTIFY event.
> What do you think?

I think the way cpu-cooling is written today, is an *ugly* hack. We hack
the notifier to change policy->max and no one is notified for it.

That's crap.

I would rather get some help from cpufreq core on that. Which can
provide some APIs to take care of thermal considerations.

Okay, I push that to my todo list. Will keep you all posted.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs

[Viresh Kumar]

On 31-07-15, 09:37, Stephen Boyd wrote:
> Do we need vendor specific properties for that though?

Sorry Lee :), but this is exactly why I wanted this thread to exist. We must and
should do this in a generic enough way.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 20/26] clk: spear: Convert to clk_hw based provider APIs

[Viresh Kumar]

On 31-07-15, 10:04, Stephen Boyd wrote:
> We're removing struct clk from the clk provider API, so switch
> this code to using the clk_hw based provider APIs.
> 
> Cc: Viresh Kumar 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/clk/spear/clk-vco-pll.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/spear/clk-vco-pll.c b/drivers/clk/spear/clk-vco-pll.c
> index 1b9b65bca51e..185b294c923b 100644
> --- a/drivers/clk/spear/clk-vco-pll.c
> +++ b/drivers/clk/spear/clk-vco-pll.c
> @@ -87,7 +87,7 @@ static long clk_pll_round_rate_index(struct clk_hw *hw, 
> unsigned long drate,
>   struct clk_pll *pll = to_clk_pll(hw);
>   unsigned long prev_rate, vco_prev_rate, rate = 0;
>   unsigned long vco_parent_rate =
> - __clk_get_rate(__clk_get_parent(__clk_get_parent(hw->clk)));
> + clk_hw_get_rate(clk_hw_get_parent(clk_hw_get_parent(hw)));

Acked-by: Viresh Kumar 

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 05/15] drivers: input: Drop unlikely before IS_ERR(_OR_NULL)

[Pali Rohár]

On Saturday 01 August 2015 13:22:51 Viresh Kumar wrote:
> On 31-07-15, 09:58, Dmitry Torokhov wrote:
> > On Fri, Jul 31, 2015 at 02:08:25PM +0530, Viresh Kumar wrote:
> > > IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and
> > > there is no need to do that again from its callers. Drop it.
> > 
> > I'd rather keep it as it documents the expected behavior and double
> > unlikely should work just fine.
> 
> TBH, I don't really agree that it is there for documentation. The
> only purpose of such compiler flags is to try make code more
> efficient.
> 
> Anyway, I got to this series as someone asked me to fix this for one
> of my patches which used unlikely(IS_ERR_OR_NULL()). And so I
> thought about fixing all sites that are doing double unlikely (that
> shouldn't hurt for sure).
> 
> I will leave it to you.

I think that unlikely() macro here make code more readable. Yes, it is 
also for compiler optimization, but also for me it looks like Clean Code 
pattern  -- is not it?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] HID: hid-input: Fix accessing freed memory during driver unbind

[Jiri Kosina]

On Wed, 29 Jul 2015, Dmitry Torokhov wrote:

> > Another and less intrusive fix would be:
> > 
> > char *name = dev->battery->desc->name;
> > struct power_supply_desc *psy_desc = dev->battery->desc;
> > power_supply_unregister(dev->battery);
> > kfree(name);
> > kfree(psy_desc);
> 
> I would much rather prefer this to the other version as it does not
> leave memory hanging around, potentially indefinitely, but ultimately it
> is up to Jiri. 

I must have been in some broken state of mind when applying the original 
one, thanks a lot for catching my brainfart, Dmitry!

Kryzstof, could you please send me properly formatted patch with the 
above, on top of your previous fix?

Thanks.

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [4.2-rc4] acpi|drm|i915: circular locking dependency: acpi_video_get_backlight_type

[Sedat Dilek]

On Mon, Jul 27, 2015 at 12:33 AM, Sedat Dilek  wrote:
> Hi,
>
> this my first build of a 4.2-rcN Linux-kernel and I see this...
>

Just FYI:

I am *not* seeing this with drm-intel-nightly from below url.

Also, I plan to test Linux v4.2-rc5.

- Sedat -

[1] 
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/
[2] 
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/linux-image-4.2.0-994-generic_4.2.0-994.201508010158_amd64.deb

> [   24.001043] [drm] Memory usable by graphics device = 2048M
> [   24.001118] [drm] Replacing VGA console driver
> [   24.011642] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [   24.011646] [drm] Driver supports precise vblank timestamp query.
> [   24.012480] vgaarb: device changed decodes:
> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> [   24.028005]
> [   24.028014] ==
> [   24.028020] [ INFO: possible circular locking dependency detected ]
> [   24.028027] 4.2.0-rc4-1-iniza-small #1 Not tainted
> [   24.028032] ---
> [   24.028038] modprobe/740 is trying to acquire lock:
> [   24.028043]  (init_mutex){+.+.+.}, at: []
> acpi_video_get_backlight_type+0x17/0x164 [video]
> [   24.028060]
> [   24.028060] but task is already holding lock:
> [   24.028068]  (&(&backlight_notifier)->rwsem){..}, at:
> [] __blocking_notifier_call_chain+0x39/0x70
> [   24.028083]
> [   24.028083] which lock already depends on the new lock.
> [   24.028083]
> [   24.028095]
> [   24.028095] the existing dependency chain (in reverse order) is:
> [   24.028103]
> [   24.028103] -> #1 (&(&backlight_notifier)->rwsem){..}:
> [   24.028113][] lock_acquire+0xcf/0x280
> [   24.028121][] down_write+0x49/0x80
> [   24.028129][]
> blocking_notifier_chain_register+0x21/0xb0
> [   24.028138][] 
> backlight_register_notifier+0x18/0x20
> [   24.028147][]
> acpi_video_get_backlight_type+0xfa/0x164 [video]
> [   24.028158][] 0xa00a20e9
> [   24.028164][] do_one_initcall+0x88/0x1c0
> [   24.028172][] do_init_module+0x61/0x1ec
> [   24.028179][] load_module+0x2008/0x25c0
> [   24.028187][] SyS_init_module+0x126/0x140
> [   24.028194][] entry_SYSCALL_64_fastpath+0x16/0x7a
> [   24.028202]
> [   24.028202] -> #0 (init_mutex){+.+.+.}:
> [   24.028211][] __lock_acquire+0x1f5d/0x21c0
> [   24.028218][] lock_acquire+0xcf/0x280
> [   24.028225][] mutex_lock_nested+0x65/0x3c0
> [   24.028233][]
> acpi_video_get_backlight_type+0x17/0x164 [video]
> [   24.028243][]
> acpi_video_backlight_notify+0x19/0x2f [video]
> [   24.028253][] notifier_call_chain+0x5d/0x80
> [   24.028260][]
> __blocking_notifier_call_chain+0x51/0x70
> [   24.028269][]
> blocking_notifier_call_chain+0x16/0x20
> [   24.028278][] 
> backlight_device_register+0x197/0x240
> [   24.028286][]
> intel_backlight_register+0xb3/0x180 [i915]
> [   24.028336][]
> intel_modeset_gem_init+0x176/0x190 [i915]
> [   24.028371][] i915_driver_load+0xf12/0x14d0 
> [i915]
> [   24.028406][] drm_dev_register+0xb1/0x100 [drm]
> [   24.028425][] drm_get_pci_dev+0x8d/0x1e0 [drm]
> [   24.028439][] i915_pci_probe+0x3b/0x60 [i915]
> [   24.028463][] local_pci_probe+0x45/0xa0
> [   24.028470][] pci_device_probe+0xcd/0x120
> [   24.028477][] driver_probe_device+0x136/0x2e0
> [   24.028485][] __driver_attach+0x94/0xa0
> [   24.028491][] bus_for_each_dev+0x66/0xa0
> [   24.028499][] driver_attach+0x1e/0x20
> [   24.028506][] bus_add_driver+0x1b8/0x230
> [   24.028513][] driver_register+0x60/0xe0
> [   24.028520][] __pci_register_driver+0x64/0x70
> [   24.028527][] drm_pci_init+0xe0/0x110 [drm]
> [   24.028540][] i915_init+0xa0/0xa8 [i915]
> [   24.028563][] do_one_initcall+0x88/0x1c0
> [   24.028570][] do_init_module+0x61/0x1ec
> [   24.028577][] load_module+0x2008/0x25c0
> [   24.028584][] SyS_init_module+0x126/0x140
> [   24.028591][] entry_SYSCALL_64_fastpath+0x16/0x7a
> [   24.028598]
> [   24.028598] other info that might help us debug this:
> [   24.028598]
> [   24.028609]  Possible unsafe locking scenario:
> [   24.028609]
> [   24.028617]CPU0CPU1
> [   24.028622]
> [   24.028627]   lock(&(&backlight_notifier)->rwsem);
> [   24.028633]lock(init_mutex);
> [   24.028639]
> lock(&(&backlight_notifier)->rwsem);
> [   24.028648]   lock(init_mutex);
> [   24.028654]
> [   24.028654]  *** DEADLOCK ***
> [   24.028654]
> [   24.028664] 4 locks held by modprobe/740:
> [   24.028669]  #0:  (&dev->mutex){..}, at: []
> __driver_attach+0x4b/0xa0
> [   2

[Patch v3 1/2] tracing: allow disabling compilation of specific trace systems

[Tal Shorer]

Allow a trace events header file to disable compilation of its
trace events by defining the preprocessor macro NOTRACE.

This could be done, for example, according to a Kconfig option.

Signed-off-by: Tal Shorer 
---
 include/linux/tracepoint.h   | 17 ++---
 include/trace/define_trace.h |  2 +-
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index a5f7f3e..afada36 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -111,7 +111,18 @@ extern void syscall_unregfunc(void);
 #define TP_ARGS(args...)   args
 #define TP_CONDITION(args...)  args
 
-#ifdef CONFIG_TRACEPOINTS
+/*
+ * Individual subsystem my have a separate configuration to
+ * enable their tracepoints. By default, this file will create
+ * the tracepoints if CONFIG_TRACEPOINT is defined. If a subsystem
+ * wants to be able to disable its tracepoints from being created
+ * it can define NOTRACE before including the tracepoint headers.
+ */
+#if defined(CONFIG_TRACEPOINTS) && !defined(NOTRACE)
+#define TRACEPOINTS_ENABLED
+#endif
+
+#ifdef TRACEPOINTS_ENABLED
 
 /*
  * it_func[0] is never NULL because there is at least one element in the array
@@ -234,7 +245,7 @@ extern void syscall_unregfunc(void);
 #define EXPORT_TRACEPOINT_SYMBOL(name) \
EXPORT_SYMBOL(__tracepoint_##name)
 
-#else /* !CONFIG_TRACEPOINTS */
+#else /* !TRACEPOINTS_ENABLED */
 #define __DECLARE_TRACE(name, proto, args, cond, data_proto, data_args) \
static inline void trace_##name(proto)  \
{ } \
@@ -266,7 +277,7 @@ extern void syscall_unregfunc(void);
 #define EXPORT_TRACEPOINT_SYMBOL_GPL(name)
 #define EXPORT_TRACEPOINT_SYMBOL(name)
 
-#endif /* CONFIG_TRACEPOINTS */
+#endif /* TRACEPOINTS_ENABLED */
 
 #ifdef CONFIG_TRACING
 /**
diff --git a/include/trace/define_trace.h b/include/trace/define_trace.h
index 09b3880..2d8639e 100644
--- a/include/trace/define_trace.h
+++ b/include/trace/define_trace.h
@@ -86,7 +86,7 @@
 #undef DECLARE_TRACE
 #define DECLARE_TRACE(name, proto, args)
 
-#ifdef CONFIG_EVENT_TRACING
+#ifdef TRACEPOINTS_ENABLED
 #include 
 #include 
 #endif
-- 
2.4.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Patch v3 2/2] tracing: gpio: add Kconfig option for enabling/disabling trace events

[Tal Shorer]

Add a new options to trace Kconfig, CONFIG_TRACING_EVENTS_GPIO, that is
used for enabling/disabling compilation of gpio function trace events.

Signed-off-by: Tal Shorer 
Acked-by: Linus Walleij 
---
 include/trace/events/gpio.h | 4 
 kernel/trace/Kconfig| 7 +++
 2 files changed, 11 insertions(+)

diff --git a/include/trace/events/gpio.h b/include/trace/events/gpio.h
index 927a8ad..2da73b9 100644
--- a/include/trace/events/gpio.h
+++ b/include/trace/events/gpio.h
@@ -1,6 +1,10 @@
 #undef TRACE_SYSTEM
 #define TRACE_SYSTEM gpio
 
+#ifndef CONFIG_TRACING_EVENTS_GPIO
+#define NOTRACE
+#endif
+
 #if !defined(_TRACE_GPIO_H) || defined(TRACE_HEADER_MULTI_READ)
 #define _TRACE_GPIO_H
 
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 3b9a48a..67a1731 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -635,6 +635,13 @@ config TRACE_ENUM_MAP_FILE
 
If unsure, say N
 
+config TRACING_EVENTS_GPIO
+   bool "Trace gpio events"
+   depends on GPIOLIB
+   default y
+   help
+ Enable tracing events for gpio subsystem
+
 endif # FTRACE
 
 endif # TRACING_SUPPORT
-- 
2.4.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Patch v3 0/2] tracing: allow disabling compilation of specific trace systems

[Tal Shorer]

Currently, enabling CONFIG_TRACING on a system comes as all-or-nothing:
either tracepoints for all subsystems are compiled (with CONFIG_TRACING)
or none of them are (without it).

This caused me an unacceptable performance penalty (obviously SOME penalty
was expected, but not one so severe) which made me revert the changes in
configuration.

The first patch in this series modifies the files that actually define the
tracepoint to look for a preprocessor macro NOTRACE and define nops (as if
CONFIG_TRACING was not set) instead of them.

The second patch provides an example of how I see this working, with the
gpio subsystem as the example for absolutely no reason.



Changelog:

v2:
- A comment in tracepoint.h explaining NOTRACE and its use
- Avoid duplication of the test for both NOTRACE and a config option by
defining TRACEPOINTS_ENABLED when both are present and using that to check
whether or not to define tracepoints

v3:
- Fix Patch 1/2 to apply to changes in include/trace/define_trace.h
- Add Linus Walleij's ack to Patch 2/2
- Move the Kconfig option from drivers/gpio/Kconfig to kernel/trace/Kconfig
This was done to group up all TRACING_EVENTS_* options together in the
future to ease disabling everything you don't need.

Tal Shorer (2):
  tracing: allow disabling compilation of specific trace systems
  tracing: gpio: add Kconfig option for enabling/disabling trace events

 include/linux/tracepoint.h   | 17 ++---
 include/trace/define_trace.h |  2 +-
 include/trace/events/gpio.h  |  4 
 kernel/trace/Kconfig |  7 +++
 4 files changed, 26 insertions(+), 4 deletions(-)

-- 
2.4.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] regmap: remove redundant $(CONFIG_REGMAP) in Makefile

[Masahiro Yamada]

Hi Mark,


2015-08-01 19:59 GMT+09:00 Mark Brown :
> On Sat, Aug 01, 2015 at 04:42:27AM +0900, Masahiro Yamada wrote:
>> Kbuild descends into drivers/base/regmap/ only when CONFIG_REGMAP
>> is enabled. (see drivers/base/Makefile)
>>
>> $(CONFIG_REGMAP) in drivers/base/regmap/Makefile always evaluates
>> to 'y'.
>
>> -obj-$(CONFIG_REGMAP) += regmap.o regcache.o
>> -obj-$(CONFIG_REGMAP) += regcache-rbtree.o regcache-lzo.o regcache-flat.o
>> +obj-y += regmap.o regcache.o
>> +obj-y += regcache-rbtree.o regcache-lzo.o regcache-flat.o
>>  obj-$(CONFIG_DEBUG_FS) += regmap-debugfs.o
>>  obj-$(CONFIG_REGMAP_AC97) += regmap-ac97.o
>>  obj-$(CONFIG_REGMAP_I2C) += regmap-i2c.o
>
> OTOH it does make the Makefile look a bit neater to have everything
> selected by config option...  is there a practical cost here?


Almost no cost.

We can save expanding $(CONFIG_REGMAP),
but it is practically unnoticeable.

Please feel free to ignore this patch if you do not like it.



-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

!

[Rita]

When and What time can i Call you? Respond ASAP
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] scripts/kernel-doc Allow struct arguments documentation in struct body

[Laurent Pinchart]

Hi Jon,

On Saturday 01 August 2015 13:22:10 Jonathan Corbet wrote:
> On Fri, 31 Jul 2015 18:06:45 -0300 Danilo Cesar Lemes de Paula wrote:
> > Describing arguments at top of a struct definition works fine
> > for small/medium size structs, but it definitely doesn't work well
> > for struct with a huge list of elements.
> > 
> > Keeping the arguments list inside the struct body makes it easier
> > to maintain the documentation.
> 
> Interesting approach.  I think it could make sense, but I fear pushback
> from a subset of maintainers refusing to accept this mode.  I wonder what
> it would take to get a consensus on allowing these in-struct comments?
> 
> I'm wondering if we need a kernel summit session on commenting
> conventions, markdown-in-kerneldoc, etc?  Maybe I'll stick a proposal out
> there.

The topic of documentation has been raised in the mail thread of the kernel 
recruitment proposal for the kernel summit. I believe it's an important one, 
and I will be very interested in contributing if it is discussed as a separate 
topic.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Input: drivers/joystick: use parallel port device model

[Sudip Mukherjee]

On Fri, Jul 31, 2015 at 01:43:06PM -0700, Dmitry Torokhov wrote:
> On Fri, Jul 31, 2015 at 01:36:18PM -0700, Greg KH wrote:
> > On Fri, Jul 31, 2015 at 11:04:26PM +0530, Sudip Mukherjee wrote:
> > > On Fri, Jul 31, 2015 at 09:54:27AM -0700, Dmitry Torokhov wrote:
> > > > On Fri, Jul 31, 2015 at 03:45:25PM +0530, Sudip Mukherjee wrote:
> > > > > On Thu, Jul 30, 2015 at 09:53:23AM -0700, Dmitry Torokhov wrote:
> > > > > > Hi Sudip,
> > > > > Hi Dmitry,
> > > > > > 
> > > > > > On Thu, Jul 30, 2015 at 07:36:34PM +0530, Sudip Mukherjee wrote:

> > > > 
> > > > No, unfortunately I do not.
> > > > 
> > > > Since neither of us can test the change what is the benefit of doing the
> > > > conversion? What will be gained by doing it? Are there plans for parport
> > > > subsystem to remove the old style initialization?
> > > Yes, that is the plan. Well, if you are not comfortable with introducing
> > > attach and detach functions then this can be done in another way where
> > > there will be very minimum change in the code. But I will prefer to have
> > > attach and detach then it can take advantage of the hotplug feature.
> > > Adding Greg in To: list for his comments.
> > 
> > Converting to the "new" api is the end goal here, no need to keep the
> > old one around anymore.
> 
> OK, then I guess we can do the conversion right (dropping db9_base
> module-global) and see if anyone screams at us.
I am working on it now to remove db9_base. But in the detach callback we
will get struct parport * and from parport to get a pardevice we need to
get it from port->physport->devices. Since it is having PARPORT_FLAG_EXCL
it is ok, but should we really depend on and work with the internal data
structures of the parport rather than working with the exported api?

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/4] watchdog: avoid races in watchdog_nmi_{en|disable} functions

[Ulrich Obergfell]

Originally watchdog_nmi_enable(cpu) and watchdog_nmi_disable(cpu) were
only called in watchdog thread context. However, the following commits
utilize these functions outside of watchdog thread context too.

  commit 9809b18fcf6b8d8ec4d3643677345907e6b50eca
  Author: Michal Hocko 
  Date:   Tue Sep 24 15:27:30 2013 -0700

  watchdog: update watchdog_thresh properly

  commit b3738d29323344da3017a91010530cf3a58590fc
  Author: Stephane Eranian 
  Date:   Mon Nov 17 20:07:03 2014 +0100

  watchdog: Add watchdog enable/disable all functions

Hence, it is now possible that these functions execute concurrently with
the same 'cpu' argument. This concurrency is problematic because per-cpu
'watchdog_ev' can be accessed/modified without adequate synchronization.

The patch series aims to address the above problem. However, instead of
introducing locks to protect per-cpu 'watchdog_ev' a different approach
is taken: Invoke these functions by parking and unparking the watchdog
threads (to ensure they are always called in watchdog thread context).

  static struct smp_hotplug_thread watchdog_threads = {
   ...
  .park   = watchdog_disable, // calls watchdog_nmi_disable()
  .unpark = watchdog_enable,  // calls watchdog_nmi_enable()
  };

Both previously mentioned commits call these functions in a similar way
and thus in principle contain some duplicate code. The patch series also
avoids this duplication by providing a commonly usable mechanism.

- Patch 1/4 introduces the watchdog_{park|unpark}_threads functions that
  park/unpark all watchdog threads specified in 'watchdog_cpumask'. They
  are intended to be called inside of kernel/watchdog.c only.

- Patch 2/4 introduces the watchdog_{suspend|resume} functions which can
  be utilized by external callers to deactivate the hard and soft lockup
  detector temporarily.

- Patch 3/4 utilizes watchdog_{park|unpark}_threads to replace some code
  that was introduced by commit 9809b18fcf6b8d8ec4d3643677345907e6b50eca.

- Patch 4/4 utilizes watchdog_{suspend|resume} to replace some code that
  was introduced by commit b3738d29323344da3017a91010530cf3a58590fc.

A few corner cases should be mentioned here for completeness.

- kthread_park() of watchdog/N could hang if cpu N is already locked up.
  However, if watchdog is enabled the lockup will be detected anyway.

- kthread_unpark() of watchdog/N could hang if cpu N got locked up after
  kthread_park(). The occurrence of this scenario should be _very_ rare
  in practice, in particular because it is not expected that temporary
  deactivation will happen frequently, and if it happens at all it is
  expected that the duration of deactivation will be short.

Ulrich Obergfell (4):
  watchdog: introduce watchdog_park_threads() and
watchdog_unpark_threads()
  watchdog: introduce watchdog_suspend() and watchdog_resume()
  watchdog: use park/unpark functions in update_watchdog_all_cpus()
  watchdog: use suspend/resume interface in fixup_ht_bug()

 arch/x86/kernel/cpu/perf_event_intel.c |   9 +-
 include/linux/nmi.h|   2 +
 include/linux/watchdog.h   |   8 --
 kernel/watchdog.c  | 157 +++--
 4 files changed, 100 insertions(+), 76 deletions(-)

-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/4] watchdog: introduce watchdog_suspend() and watchdog_resume()

[Ulrich Obergfell]

This interface can be utilized to deactivate the hard and soft lockup
detector temporarily. Callers are expected to minimize the duration of
deactivation. Multiple deactivations are allowed to occur in parallel
but should be rare in practice.

Signed-off-by: Ulrich Obergfell 
---
 include/linux/nmi.h |  2 ++
 kernel/watchdog.c   | 65 +
 2 files changed, 67 insertions(+)

diff --git a/include/linux/nmi.h b/include/linux/nmi.h
index f94da0e..60050c2 100644
--- a/include/linux/nmi.h
+++ b/include/linux/nmi.h
@@ -80,6 +80,8 @@ extern int proc_watchdog_thresh(struct ctl_table *, int ,
void __user *, size_t *, loff_t *);
 extern int proc_watchdog_cpumask(struct ctl_table *, int,
 void __user *, size_t *, loff_t *);
+extern int watchdog_suspend(void);
+extern void watchdog_resume(void);
 #endif
 
 #ifdef CONFIG_HAVE_ACPI_APEI_NMI
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 5571f20..98d44b1 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -67,6 +67,7 @@ unsigned long *watchdog_cpumask_bits = 
cpumask_bits(&watchdog_cpumask);
 #define for_each_watchdog_cpu(cpu) \
for_each_cpu_and((cpu), cpu_online_mask, &watchdog_cpumask)
 
+static int __read_mostly watchdog_suspended = 0;
 static int __read_mostly watchdog_running;
 static u64 __read_mostly sample_period;
 
@@ -702,6 +703,50 @@ static void watchdog_unpark_threads(void)
put_online_cpus();
 }
 
+/*
+ * Suspend the hard and soft lockup detector by parking the watchdog threads.
+ */
+int watchdog_suspend(void)
+{
+   int ret = 0;
+
+   mutex_lock(&watchdog_proc_mutex);
+   /*
+* Multiple suspend requests can be active in parallel (counted by
+* the 'watchdog_suspended' variable). If the watchdog threads are
+* running, the first caller takes care that they will be parked.
+* The state of 'watchdog_running' cannot change while a suspend
+* request is active (see related changes in 'proc' handlers).
+*/
+   if (watchdog_running && !watchdog_suspended)
+   ret = watchdog_park_threads();
+
+   if (ret == 0)
+   watchdog_suspended++;
+
+   mutex_unlock(&watchdog_proc_mutex);
+
+   return ret;
+}
+
+/*
+ * Resume the hard and soft lockup detector by unparking the watchdog threads.
+ */
+void watchdog_resume(void)
+{
+   mutex_lock(&watchdog_proc_mutex);
+
+   watchdog_suspended--;
+   /*
+* The watchdog threads are unparked if they were previously running
+* and if there is no more active suspend request.
+*/
+   if (watchdog_running && !watchdog_suspended)
+   watchdog_unpark_threads();
+
+   mutex_unlock(&watchdog_proc_mutex);
+}
+
 static void restart_watchdog_hrtimer(void *info)
 {
struct hrtimer *hrtimer = raw_cpu_ptr(&watchdog_hrtimer);
@@ -823,6 +868,12 @@ static int proc_watchdog_common(int which, struct 
ctl_table *table, int write,
 
mutex_lock(&watchdog_proc_mutex);
 
+   if (watchdog_suspended) {
+   /* no parameter changes allowed while watchdog is suspended */
+   err = -EAGAIN;
+   goto out;
+   }
+
/*
 * If the parameter is being read return the state of the corresponding
 * bit(s) in 'watchdog_enabled', else update 'watchdog_enabled' and the
@@ -908,6 +959,12 @@ int proc_watchdog_thresh(struct ctl_table *table, int 
write,
 
mutex_lock(&watchdog_proc_mutex);
 
+   if (watchdog_suspended) {
+   /* no parameter changes allowed while watchdog is suspended */
+   err = -EAGAIN;
+   goto out;
+   }
+
old = ACCESS_ONCE(watchdog_thresh);
err = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
 
@@ -939,6 +996,13 @@ int proc_watchdog_cpumask(struct ctl_table *table, int 
write,
int err;
 
mutex_lock(&watchdog_proc_mutex);
+
+   if (watchdog_suspended) {
+   /* no parameter changes allowed while watchdog is suspended */
+   err = -EAGAIN;
+   goto out;
+   }
+
err = proc_do_large_bitmap(table, write, buffer, lenp, ppos);
if (!err && write) {
/* Remove impossible cpus to keep sysctl output cleaner. */
@@ -956,6 +1020,7 @@ int proc_watchdog_cpumask(struct ctl_table *table, int 
write,
pr_err("cpumask update failed\n");
}
}
+out:
mutex_unlock(&watchdog_proc_mutex);
return err;
 }
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/4] watchdog: use park/unpark functions in update_watchdog_all_cpus()

[Ulrich Obergfell]

Remove update_watchdog() and restart_watchdog_hrtimer() since these
functions are no longer needed. Changes of parameters such as the
sample period are honored at the time when the watchdog threads are
being unparked.

Signed-off-by: Ulrich Obergfell 
---
 kernel/watchdog.c | 40 ++--
 1 file changed, 2 insertions(+), 38 deletions(-)

diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 98d44b1..3618e93 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -747,46 +747,10 @@ void watchdog_resume(void)
mutex_unlock(&watchdog_proc_mutex);
 }
 
-static void restart_watchdog_hrtimer(void *info)
-{
-   struct hrtimer *hrtimer = raw_cpu_ptr(&watchdog_hrtimer);
-   int ret;
-
-   /*
-* No need to cancel and restart hrtimer if it is currently executing
-* because it will reprogram itself with the new period now.
-* We should never see it unqueued here because we are running per-cpu
-* with interrupts disabled.
-*/
-   ret = hrtimer_try_to_cancel(hrtimer);
-   if (ret == 1)
-   hrtimer_start(hrtimer, ns_to_ktime(sample_period),
-   HRTIMER_MODE_REL_PINNED);
-}
-
-static void update_watchdog(int cpu)
-{
-   /*
-* Make sure that perf event counter will adopt to a new
-* sampling period. Updating the sampling period directly would
-* be much nicer but we do not have an API for that now so
-* let's use a big hammer.
-* Hrtimer will adopt the new period on the next tick but this
-* might be late already so we have to restart the timer as well.
-*/
-   watchdog_nmi_disable(cpu);
-   smp_call_function_single(cpu, restart_watchdog_hrtimer, NULL, 1);
-   watchdog_nmi_enable(cpu);
-}
-
 static void update_watchdog_all_cpus(void)
 {
-   int cpu;
-
-   get_online_cpus();
-   for_each_watchdog_cpu(cpu)
-   update_watchdog(cpu);
-   put_online_cpus();
+   watchdog_park_threads();
+   watchdog_unpark_threads();
 }
 
 static int watchdog_enable_all_cpus(void)
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/4] watchdog: use suspend/resume interface in fixup_ht_bug()

[Ulrich Obergfell]

Remove watchdog_nmi_disable_all() and watchdog_nmi_enable_all()
since these functions are no longer needed. If a subsystem has a
need to deactivate the watchdog temporarily, it should utilize the
watchdog_suspend() and watchdog_resume() functions.

Signed-off-by: Ulrich Obergfell 
---
 arch/x86/kernel/cpu/perf_event_intel.c |  9 +---
 include/linux/watchdog.h   |  8 ---
 kernel/watchdog.c  | 38 --
 3 files changed, 6 insertions(+), 49 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event_intel.c 
b/arch/x86/kernel/cpu/perf_event_intel.c
index b9826a9..d4e1b0c 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include 
@@ -3368,7 +3368,10 @@ static __init int fixup_ht_bug(void)
return 0;
}
 
-   watchdog_nmi_disable_all();
+   if (watchdog_suspend() != 0) {
+   pr_info("failed to disable PMU erratum BJ122, BV98, HSD29 
workaround\n");
+   return 0;
+   }
 
x86_pmu.flags &= ~(PMU_FL_EXCL_CNTRS | PMU_FL_EXCL_ENABLED);
 
@@ -3376,7 +3379,7 @@ static __init int fixup_ht_bug(void)
x86_pmu.commit_scheduling = NULL;
x86_pmu.stop_scheduling = NULL;
 
-   watchdog_nmi_enable_all();
+   watchdog_resume();
 
get_online_cpus();
 
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index f47fead..d74a0e9 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -140,12 +140,4 @@ extern int watchdog_init_timeout(struct watchdog_device 
*wdd,
 extern int watchdog_register_device(struct watchdog_device *);
 extern void watchdog_unregister_device(struct watchdog_device *);
 
-#ifdef CONFIG_HARDLOCKUP_DETECTOR
-void watchdog_nmi_disable_all(void);
-void watchdog_nmi_enable_all(void);
-#else
-static inline void watchdog_nmi_disable_all(void) {}
-static inline void watchdog_nmi_enable_all(void) {}
-#endif
-
 #endif  /* ifndef _LINUX_WATCHDOG_H */
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 3618e93..bf751ef 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -614,47 +614,9 @@ static void watchdog_nmi_disable(unsigned int cpu)
cpu0_err = 0;
}
 }
-
-void watchdog_nmi_enable_all(void)
-{
-   int cpu;
-
-   mutex_lock(&watchdog_proc_mutex);
-
-   if (!(watchdog_enabled & NMI_WATCHDOG_ENABLED))
-   goto unlock;
-
-   get_online_cpus();
-   for_each_watchdog_cpu(cpu)
-   watchdog_nmi_enable(cpu);
-   put_online_cpus();
-
-unlock:
-   mutex_unlock(&watchdog_proc_mutex);
-}
-
-void watchdog_nmi_disable_all(void)
-{
-   int cpu;
-
-   mutex_lock(&watchdog_proc_mutex);
-
-   if (!watchdog_running)
-   goto unlock;
-
-   get_online_cpus();
-   for_each_watchdog_cpu(cpu)
-   watchdog_nmi_disable(cpu);
-   put_online_cpus();
-
-unlock:
-   mutex_unlock(&watchdog_proc_mutex);
-}
 #else
 static int watchdog_nmi_enable(unsigned int cpu) { return 0; }
 static void watchdog_nmi_disable(unsigned int cpu) { return; }
-void watchdog_nmi_enable_all(void) {}
-void watchdog_nmi_disable_all(void) {}
 #endif /* CONFIG_HARDLOCKUP_DETECTOR */
 
 static struct smp_hotplug_thread watchdog_threads = {
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] watchdog: introduce watchdog_park_threads() and watchdog_unpark_threads()

[Ulrich Obergfell]

These functions are intended to be used only from inside kernel/watchdog.c
to park/unpark all watchdog threads that are specified in watchdog_cpumask.

Signed-off-by: Ulrich Obergfell 
---
 kernel/watchdog.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index a6ffa43..5571f20 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * The run state of the lockup detectors is controlled by the content of the
@@ -666,6 +667,41 @@ static struct smp_hotplug_thread watchdog_threads = {
.unpark = watchdog_enable,
 };
 
+/*
+ * park all watchdog threads that are specified in 'watchdog_cpumask'
+ */
+static int watchdog_park_threads(void)
+{
+   int cpu, ret = 0;
+
+   get_online_cpus();
+   for_each_watchdog_cpu(cpu) {
+   ret = kthread_park(per_cpu(softlockup_watchdog, cpu));
+   if (ret)
+   break;
+   }
+   if (ret) {
+   for_each_watchdog_cpu(cpu)
+   kthread_unpark(per_cpu(softlockup_watchdog, cpu));
+   }
+   put_online_cpus();
+
+   return ret;
+}
+
+/*
+ * unpark all watchdog threads that are specified in 'watchdog_cpumask'
+ */
+static void watchdog_unpark_threads(void)
+{
+   int cpu;
+
+   get_online_cpus();
+   for_each_watchdog_cpu(cpu)
+   kthread_unpark(per_cpu(softlockup_watchdog, cpu));
+   put_online_cpus();
+}
+
 static void restart_watchdog_hrtimer(void *info)
 {
struct hrtimer *hrtimer = raw_cpu_ptr(&watchdog_hrtimer);
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] watchdog: Fix race on single cpu boot

[Ulrich Obergfell]

Don,

> Uli privately has been working on a patchset that cleans up a bunch of these
> race conditions.  We believe it should cover this case.  It uses the
> proc_mutex to synchronize everything.
>
> I think he is reaching out to you.  If you could try his patchset to see if
> it fixes things, it might be a cleaner approach than what you are doing.
>
> 
>
> Ok, I was poked on IRC and you have already done this and it passed your
> testcase.  Let me get Uli to post his patches. :-)
>
> Cheers,
> Don

I posted the patch set here:

  https://lkml.org/lkml/2015/8/1/64
  https://lkml.org/lkml/2015/8/1/65
  https://lkml.org/lkml/2015/8/1/66
  https://lkml.org/lkml/2015/8/1/67
  https://lkml.org/lkml/2015/8/1/68

Regards,

Uli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v2] lib: scatterlist: add sg splitting function

[Robert Jarzmik]

Sometimes a scatter-gather has to be split into several chunks, or sub scatter
lists. This happens for example if a scatter list will be handled by multiple
DMA channels, each one filling a part of it.

A concrete example comes with the media V4L2 API, where the scatter list is
allocated from userspace to hold an image, regardless of the knowledge of how
many DMAs will fill it :
 - in a simple RGB565 case, one DMA will pump data from the camera ISP to memory
 - in the trickier YUV422 case, 3 DMAs will pump data from the camera ISP pipes,
   one for pipe Y, one for pipe U and one for pipe V

For these cases, it is necessary to split the original scatter list into
multiple scatter lists, which is the purpose of this patch.

The guarantees that are required for this patch are :
 - the intersection of spans of any couple of resulting scatter lists is empty
 - the union of spans of all resulting scatter lists is a subrange of the span
   of the original scatter list
 - if streaming DMA API operations (mapping, unmapping) should not happen both
   on both the resulting and the original scatter list. It's either the first or
   the later ones.
 - the caller is reponsible to call kfree() on the resulting scatterlists

Signed-off-by: Robert Jarzmik 

---
Since v1: Russell's review
 - address both the sg_phys case and sg_dma_address case (aka mapped
   case)
   => this should take care of IOMMU coalescing
 - add a way to return the new mapped lengths of resulting scatterlists
 - add bound checks (EINVAL) for corner cases :
 - skip > sum(sgi->length) or
   skip > sum(sg_dma_len(sgi))
 - sum(sizei) > skip + sum(sgi->length) or
   sum(sizei) > skip + sum(sg_dma_len(sgi))
 - fixed algorithm for single sgi split into multiple sg entries
   (case where very small sizes, ie. size0+size1+size2 < sg0_length)

Russell, this new attempt still aims at having both unmapped and mapped
cases covered. As my understanding of coalescing might still be
partial, please point me out the defects.

And I'm not sure I have properly addressed this comment of yours :
"I'm not sure that there's any requirement for dma_map_sg() to mark
the new end of the scatterlist as that'd result in information loss
when subsequently unmapping.".
I think marking the last sg entry (ie. the one for physical addresses,
not the last of the mapped ones) is correct in the v2 patch, but I might
oversee something, just for confirmation it is addressed.

One last point is that if this attempt is correct enough, I still need
some automation testing passed on it, as there are a lot of
possibilities between input parameters (skip, sizes[], in) which would
need some proper testing.

Memo of people to ask:
To: Russell King - ARM Linux 
To: Jens Axboe 
To: Guennadi Liakhovetski 
To: Andrew Morton 
To: Mauro Carvalho Chehab 
Cc: linux-me...@vger.kernel.org

squash! lib: scatterlist: add sg splitting function
---
 include/linux/scatterlist.h |   5 ++
 lib/scatterlist.c   | 189 
 2 files changed, 194 insertions(+)

diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 9b1ef0c820a7..5fa4ab1a4605 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -251,6 +251,11 @@ struct scatterlist *sg_next(struct scatterlist *);
 struct scatterlist *sg_last(struct scatterlist *s, unsigned int);
 void sg_init_table(struct scatterlist *, unsigned int);
 void sg_init_one(struct scatterlist *, const void *, unsigned int);
+int sg_split(struct scatterlist *in, const int in_mapped_nents,
+const off_t skip, const int nb_splits,
+const size_t *split_sizes,
+struct scatterlist **out, int *out_mapped_nents,
+gfp_t gfp_mask);
 
 typedef struct scatterlist *(sg_alloc_fn)(unsigned int, gfp_t);
 typedef void (sg_free_fn)(struct scatterlist *, unsigned int);
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index d105a9f56878..325f831bda47 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -759,3 +759,192 @@ size_t sg_pcopy_to_buffer(struct scatterlist *sgl, 
unsigned int nents,
return sg_copy_buffer(sgl, nents, buf, buflen, skip, true);
 }
 EXPORT_SYMBOL(sg_pcopy_to_buffer);
+
+struct sg_splitter {
+   struct scatterlist *in_sg0;
+   int nents;
+   off_t skip_sg0;
+   unsigned int length_last_sg;
+
+   struct scatterlist *out_sg;
+};
+
+static int sg_calculate_split(struct scatterlist *in, int nents, int nb_splits,
+ off_t skip, const size_t *sizes,
+ struct sg_splitter *splitters, bool mapped)
+{
+   int i, rjk = nb_splits;
+   unsigned int sglen;
+   size_t size = sizes[0], len;
+   struct sg_splitter *curr = splitters;
+   struct scatterlist *sg;
+
+   for (i = 0; i < nb_splits; i++) {
+   splitters[i].in_sg0 = NULL;
+   splitters[i].nents = 0;
+   }
+
+   for_each_sg(in, sg, nents,

Re: [PATCH v2] kthread: Export kthread functions

[Neil Horman]

On Sat, Aug 01, 2015 at 03:12:42PM +0800, yalin wang wrote:
> 
> > 在 2015年7月31日，22:14，Thomas Gleixner  写道：
> > 
> > 
> > On Fri, 31 Jul 2015, Thomas Gleixner wrote:
> > 
> >> On Fri, 31 Jul 2015, yalin wang wrote:
> >>> it is optimised to 2 instructions ,
> >>> 
> >>> this is my patch, hope can be merged :
> >> 
> >> We are not exposing the internals of kthread management. Period.
> > 
> > And your 'optimization' is completely bogus:
> > 
> > Before your modification:
> > 
> > size kernel/built-in.o
> > 
> >   text data bss dec hex filename
> > 1091514  141498  341928 1574940  18081c ../build/kernel/built-in.o
> > 
> > After:
> > 
> >   text data bss dec hex filename
> > 1091664  141498  341928 1575090  1808b2 ../build/kernel/built-in.o
> > 
> > That's an increase of text size by 150 byte. Interesting optimization.
> > 
> > Thanks,
> > 
> > tglx
> > 
> > 
> strange,  this is my test result:
> 
> size   built-in.o*
>   text   data bss dec hex filename
> 743937  50786   56008  850731   cfb2b built-in.o// with the 
> patch
> 744069  50786   56008  850863   cfbaf built-in.o_old  // with out the 
> patch
> 
So you're willing to expose the internals of kthread_park in exchange for the
hope of saving 132 bytes of text.

Thats just dumb.  I agree with tglx, this shouldn't change.

Neil

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ACPI: fix acpi_debugfs_init prototype

[Nicolas Iooss]

acpi_debugfs_init function is declared with return type int in
drivers/acpi/internal.h when CONFIG_DEBUG_FS is enabled, but its
definition in drivers/acpi/debugfs.c has return type void. This is due
to commit aecad432fd68 ("ACPI: Cleanup custom_method debug stuff"),
which changed the return type from int to void without updating the
declaration.

Fix this inconsistency by updating acpi_debugfs_init prototype.  While
at it, include internal.h in debugfs.c so that the compiler can check
that the declaration and definition remain compatible.

Signed-off-by: Nicolas Iooss 
---
 drivers/acpi/debugfs.c  | 2 ++
 drivers/acpi/internal.h | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/debugfs.c b/drivers/acpi/debugfs.c
index 6b1919f6bd82..68bb305b977f 100644
--- a/drivers/acpi/debugfs.c
+++ b/drivers/acpi/debugfs.c
@@ -7,6 +7,8 @@
 #include 
 #include 
 
+#include "internal.h"
+
 #define _COMPONENT ACPI_SYSTEM_COMPONENT
 ACPI_MODULE_NAME("debugfs");
 
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 4683a96932b9..4b348df3056d 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -70,7 +70,7 @@ void acpi_scan_hotplug_enabled(struct acpi_hotplug_profile 
*hotplug, bool val);
 
 #ifdef CONFIG_DEBUG_FS
 extern struct dentry *acpi_debugfs_dir;
-int acpi_debugfs_init(void);
+void acpi_debugfs_init(void);
 #else
 static inline void acpi_debugfs_init(void) { return; }
 #endif
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drm/amdgpu: increment queue when iterating on this variable.

[Nicolas Iooss]

gfx_v7_0_print_status contains a for loop on variable queue which does
not update this variable between each iteration.  This is bug is
reported by clang while building allmodconfig LLVMLinux on x86_64:

drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:5126:19: error: variable
'queue' used in loop condition not modified in loop body
[-Werror,-Wloop-analysis]
for (queue = 0; queue < 8; i++) {
^

Fix this by incrementing variable queue instead of i in this loop.

Signed-off-by: Nicolas Iooss 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
index 2db6ab0a543d..5c03420ca5dc 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
@@ -5122,7 +5122,7 @@ static void gfx_v7_0_print_status(void *handle)
dev_info(adev->dev, "  CP_HPD_EOP_CONTROL=0x%08X\n",
 RREG32(mmCP_HPD_EOP_CONTROL));
 
-   for (queue = 0; queue < 8; i++) {
+   for (queue = 0; queue < 8; queue++) {
cik_srbm_select(adev, me, pipe, queue, 0);
dev_info(adev->dev, "  queue: %d\n", queue);
dev_info(adev->dev, "  CP_PQ_WPTR_POLL_CNTL=0x%08X\n",
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] NFC: nxp-nci: Include unaligned.h instead of access_ok.h

[Guenter Roeck]

Directly including access_ok.h can result in the following compile errors
if an architecture such as ia64 does not support direct unaligned accesses.

include/linux/unaligned/access_ok.h:7:19: error:
redefinition of 'get_unaligned_le16'
include/linux/unaligned/le_struct.h:6:19: note:
previous definition of 'get_unaligned_le16' was here
include/linux/unaligned/access_ok.h:12:19: error:
redefinition of 'get_unaligned_le32'
include/linux/unaligned/le_struct.h:11:19: note:
previous definition of 'get_unaligned_le32' was here

Include asm/unaligned.h instead and let the architecture decide which
access functions to use.

Cc: Clément Perrochaud 
Cc: Samuel Ortiz 
Signed-off-by: Guenter Roeck 
---
 drivers/nfc/nxp-nci/firmware.c | 2 +-
 drivers/nfc/nxp-nci/i2c.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/nfc/nxp-nci/firmware.c b/drivers/nfc/nxp-nci/firmware.c
index 5291797324ba..553011f58339 100644
--- a/drivers/nfc/nxp-nci/firmware.c
+++ b/drivers/nfc/nxp-nci/firmware.c
@@ -24,7 +24,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "nxp-nci.h"
 
diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
index 2f77f1d03638..5907e7a727a1 100644
--- a/drivers/nfc/nxp-nci/i2c.c
+++ b/drivers/nfc/nxp-nci/i2c.c
@@ -36,7 +36,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] lustre: Include unaligned.h instead of access_ok.h

[Guenter Roeck]

Including access_ok.h causes the ia64:allmodconfig build (and maybe others)
to fail with

include/linux/unaligned/le_struct.h:6:19: error:
redefinition of 'get_unaligned_le16'
include/linux/unaligned/access_ok.h:7:19: note:
previous definition of 'get_unaligned_le16' was here
include/linux/unaligned/le_struct.h:26:20: error:
redefinition of 'put_unaligned_le32'
include/linux/unaligned/access_ok.h:42:20: note:
previous definition of 'put_unaligned_le32' was here
include/linux/unaligned/le_struct.h:31:20: error:
redefinition of 'put_unaligned_le64'
include/linux/unaligned/access_ok.h:47:20: note:
previous definition of 'put_unaligned_le64' was here

Include unaligned.h instead and leave it up to the architecture to decide
how to implement unaligned accesses.

Fixes: 8c4f136497315 ("Staging: lustre: Use put_unaligned_le64")
Cc: Vaishali Thakkar 
Signed-off-by: Guenter Roeck 
---
 drivers/staging/lustre/lustre/obdclass/debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/debug.c 
b/drivers/staging/lustre/lustre/obdclass/debug.c
index 9c934e6d2ea1..c61add46b426 100644
--- a/drivers/staging/lustre/lustre/obdclass/debug.c
+++ b/drivers/staging/lustre/lustre/obdclass/debug.c
@@ -40,7 +40,7 @@
 
 #define DEBUG_SUBSYSTEM D_OTHER
 
-#include 
+#include 
 
 #include "../include/obd_support.h"
 #include "../include/lustre_debug.h"
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/4] watchdog: introduce watchdog_suspend() and watchdog_resume()

[Guenter Roeck]

On Sat, Aug 01, 2015 at 02:49:23PM +0200, Ulrich Obergfell wrote:
> This interface can be utilized to deactivate the hard and soft lockup
> detector temporarily. Callers are expected to minimize the duration of
> deactivation. Multiple deactivations are allowed to occur in parallel
> but should be rare in practice.
> 
> Signed-off-by: Ulrich Obergfell 
> ---
>  include/linux/nmi.h |  2 ++
>  kernel/watchdog.c   | 65 
> +
>  2 files changed, 67 insertions(+)
> 
> diff --git a/include/linux/nmi.h b/include/linux/nmi.h
> index f94da0e..60050c2 100644
> --- a/include/linux/nmi.h
> +++ b/include/linux/nmi.h
> @@ -80,6 +80,8 @@ extern int proc_watchdog_thresh(struct ctl_table *, int ,
>   void __user *, size_t *, loff_t *);
>  extern int proc_watchdog_cpumask(struct ctl_table *, int,
>void __user *, size_t *, loff_t *);
> +extern int watchdog_suspend(void);
> +extern void watchdog_resume(void);

How about nmi_watchdog_enable() and nmi_watchdog_disable() to avoid confusion
with the watchdog subsystem ?

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [tip:x86/mm] x86/mm/mtrr: Clean up mtrr_type_lookup()

[Luis R. Rodriguez]

On Fri, Jul 31, 2015 at 05:27:13PM +0200, Borislav Petkov wrote:
> On Fri, Jul 31, 2015 at 05:08:06PM +0200, Peter Zijlstra wrote:
> > But its things like set_memory_XX(), and afaict that's all buggy against
> > MTRR modifications.
> 
> I think the idea is to not do any MTRR modifications at some point:
> 
> From Documentation/x86/pat.txt:
> 
> "... Ideally mtrr_add() usage will be phased out in favor of
> arch_phys_wc_add() which will be a no-op on PAT enabled systems. The
> region over which a arch_phys_wc_add() is made, should already have been
> ioremapped with WC attributes or PAT entries, this can be done by using
> ioremap_wc() / set_memory_wc()."

I need to update this documentation to remove set_memory_wc() there as we've
learned with the MTRR --> PAT conversion that set_memory_wc() cannot be used on
IO memory, it can only be used for RAM. I am not sure if I would call it being
broken that you cannot use set_memory_*() for IO memory that may have been by
design.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/4] watchdog: introduce watchdog_suspend() and watchdog_resume()

[Ulrich Obergfell]

> - Original Message -
> From: "Guenter Roeck" 
> ...
> Subject: Re: [PATCH 2/4] watchdog: introduce watchdog_suspend() and 
> watchdog_resume()
>
> On Sat, Aug 01, 2015 at 02:49:23PM +0200, Ulrich Obergfell wrote:
>> This interface can be utilized to deactivate the hard and soft lockup
>> detector temporarily. Callers are expected to minimize the duration of
>> deactivation. Multiple deactivations are allowed to occur in parallel
>> but should be rare in practice.
>> 
>> Signed-off-by: Ulrich Obergfell 
>> ---
>>  include/linux/nmi.h |  2 ++
>>  kernel/watchdog.c   | 65 
>> +
>>  2 files changed, 67 insertions(+)
>> 
>> diff --git a/include/linux/nmi.h b/include/linux/nmi.h
>> index f94da0e..60050c2 100644
>> --- a/include/linux/nmi.h
>> +++ b/include/linux/nmi.h
>> @@ -80,6 +80,8 @@ extern int proc_watchdog_thresh(struct ctl_table *, int ,
>>  void __user *, size_t *, loff_t *);
>>  extern int proc_watchdog_cpumask(struct ctl_table *, int,
>>   void __user *, size_t *, loff_t *);
>> +extern int watchdog_suspend(void);
>> +extern void watchdog_resume(void);
>
> How about nmi_watchdog_enable() and nmi_watchdog_disable() to avoid confusion
> with the watchdog subsystem ?

Guenter,

Good point. However, I would like to avoid the 'nmi_' prefix in the
function names as it could be misleading. watchdog_{suspend|resume}
affect both -the hard and soft lockup detector- so I think function
names like

  lockup_detector_suspend()  instead of watchdog_suspend()
  lockup_detector_resume()   instead of watchdog_resume()

would summarize better what these functions are intended to be used
for. The above names would also be consistent with the existing name
 
  lockup_detector_init()

Many Thanks,

Uli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/4] watchdog: introduce watchdog_suspend() and watchdog_resume()

[Guenter Roeck]

On Sat, Aug 01, 2015 at 10:39:22AM -0400, Ulrich Obergfell wrote:
> > - Original Message -
> > From: "Guenter Roeck" 
> > ...
> > Subject: Re: [PATCH 2/4] watchdog: introduce watchdog_suspend() and 
> > watchdog_resume()
> >
> > On Sat, Aug 01, 2015 at 02:49:23PM +0200, Ulrich Obergfell wrote:
> >> This interface can be utilized to deactivate the hard and soft lockup
> >> detector temporarily. Callers are expected to minimize the duration of
> >> deactivation. Multiple deactivations are allowed to occur in parallel
> >> but should be rare in practice.
> >> 
> >> Signed-off-by: Ulrich Obergfell 
> >> ---
> >>  include/linux/nmi.h |  2 ++
> >>  kernel/watchdog.c   | 65 
> >> +
> >>  2 files changed, 67 insertions(+)
> >> 
> >> diff --git a/include/linux/nmi.h b/include/linux/nmi.h
> >> index f94da0e..60050c2 100644
> >> --- a/include/linux/nmi.h
> >> +++ b/include/linux/nmi.h
> >> @@ -80,6 +80,8 @@ extern int proc_watchdog_thresh(struct ctl_table *, int ,
> >>void __user *, size_t *, loff_t *);
> >>  extern int proc_watchdog_cpumask(struct ctl_table *, int,
> >> void __user *, size_t *, loff_t *);
> >> +extern int watchdog_suspend(void);
> >> +extern void watchdog_resume(void);
> >
> > How about nmi_watchdog_enable() and nmi_watchdog_disable() to avoid 
> > confusion
> > with the watchdog subsystem ?
> 
> Guenter,
> 
> Good point. However, I would like to avoid the 'nmi_' prefix in the
> function names as it could be misleading. watchdog_{suspend|resume}
> affect both -the hard and soft lockup detector- so I think function
> names like
> 
>   lockup_detector_suspend()  instead of watchdog_suspend()
>   lockup_detector_resume()   instead of watchdog_resume()
> 
> would summarize better what these functions are intended to be used
> for. The above names would also be consistent with the existing name
>  
>   lockup_detector_init()
> 
Makes sense.

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] serial: etraxfs-uart: use mctrl_gpio helpers for handling modem signals

[Guenter Roeck]

On Sat, Jul 25, 2015 at 02:02:46AM +0200, Niklas Cassel wrote:
> In order to use the mctrl_gpio helpers, we change the DT bindings:
> ri-gpios renamed to rng-gpios. cd-gpios renamed to dcd-gpios.
> However, no in-tree dts/dtsi specifies these, so no worries.
> 
> Signed-off-by: Niklas Cassel 

Acked-by: Guenter Roeck 
Tested-by: Guenter Roeck 

Any chance to get this into -next ? The problem it fixes
still causes my crisv32 qemu tests to fail.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] serial: etraxfs-uart: remove empty functions

[Guenter Roeck]

On Sat, Jul 25, 2015 at 02:00:40AM +0200, Niklas Cassel wrote:
> Implementing enable_ms is optional by serial_core.
> check_modem_status is just an empty local function.
> 
> Signed-off-by: Niklas Cassel 

Reviewed-by: Guenter Roeck 
Tested-by: Guenter Roeck 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 3/9] arm: twr-k70f120m: clock driver for Kinetis SoC

[Paul Osmialowski]

Hi Mike,

On Fri, 31 Jul 2015, Michael Turquette wrote:

> Quoting Paul Osmialowski (2015-07-30 14:40:48)
> > Hi Mike,
> > 
> > I encountered some trouble while I tried to implement code fitting to DTS 
> > that you proposed. SIM_CLKDIVx are SIM device registers, not MCG. 
> > Therefore, in MCG device code I won't be able to figure out clock rate 
> > for outputed clocks unles I try to access SIM registers from MCG driver - 
> 
> Right, the MCG driver will only know the rates of the clocks that it
> outputs, namely:
> 
> MCGIRCLK
> MCGFFCLK
> MCGOUTCLK
> MCGFLLCLK
> MCGPLL0CLK
> MCGPLL1CLK
> 
> The naming scheme in the TRM is a bit unfortunate; it looks like some of
> the clock outputs coming out of SIM also retain the MCG* names.

I wonder if I really need to implement support for all of these clocks 
while to run Linux on this board reference 2.6 kernel uses only MCGOUTCLK 
(and for this, it never considers FLL as a source). 
I can also provide support for MCGPLL0CLK and MCGPLL1CLK as well since 
their rates are computed as a byproduct while determining rate of 
MCGOUTCLK. I may define constants for all of them in related header file, 
but I'm thinking about leaving most of implementations as TBD - otherwise 
I doubt I'll be ever able to test that my driver fully works.

> 
> Why is clock-cells zero? I think the MCG block outputs all of the clocks
> that I listed above? As such they should be addressable as <&mcg N> by
> any downstream users.
> 

Ok, will be 1, to distinguish between MCGOUTCLK, MCGPLL0CLK, MCGPLL1CLK.


> > reg = <0x40064000 0x14>;
> > clocks = <&osc0>, <&osc1>, <&rtc>;
> > clock-names = "osc0", "osc1", "rtc";
> 
> Are the oscN and rtc clocks modeled as fixed-rate clocks in DT?
> 

Yes, I skipped the part above soc during copy-paste.

> It looks like the SIM block should also consume:
> 
> MCGFLLCLK
> MCGIRCLK
> MCGFFCLK
> MCGPLL0CLK
> MCGPLL1CLK
> OSC0ERCLK
> OSC1ERCLK
> OSC032KCLK
> RTCCLK (I made that name up)
> 
> The mcg clocks should come out of the mcg node. It looks like you
> already modeled oscN and rtc clocks, which is great. There are some
> gates after these clocks (e.g. OSC0ERCLK). I wonder if those gates are
> actually in the osc IP block or if they actually live in SIM. More on
> that below...
> 
> Well they certainly can be exposed if you need them to be. If a device
> driver wants to get the core clock and set it's rate then it should be
> able to with something like <&sim CORE_CLK>.
> 

Ok, the user of the clock does not relly need to know whether it is clock 
device or a clock gate - fortunately, I already learnt how to implement 
such thing.

> > 
> > Also note that fec (ethernet device) driver is connected directly to osc0 
> > (though clock gate, you can see this CG attached to osc0 on the diagram 
> > too) - to control this gate I need to access SIM device registers, so it 
> > should be covered by the same fsl,kinetis-sim driver.
> 
> Do you mean the SIM_SOPT2 register? It looks like the connection is not
> "direct", as the osc0 signal feeds into the SIM block and the gate there
> controls it.  Perhaps the diagram is incorrect by placing the CG block
> inside osc0? It looks like you correctly modeled this relationship in
> the sim node.

In order to enable network device, bit 0 of SIM_SCGC2 must be set for RMII 
mode to work, and according to what I see on the page 228 of the reference
manual, it is osc0 clock behind this gate.

In the context of network device, I would need to read SIM_SOPT2 to 
determine clock source for IEEE 1588 timestamp while implementing PTP 
support - which currently I don't have in my plans, network device can do 
without it.

Thanks,
Paul

> 
> Besides my annoying questions above this binding is starting to shape up
> very well. Thanks for your patience!
> 
> Regards,
> Mike
> 
> > 
> > On Wed, 29 Jul 2015, Michael Turquette wrote:
> > 
> > > Quoting Paul Osmialowski (2015-07-28 13:30:17)
> > > > Hi Mike,
> > > > 
> > > > My trouble is that now I'm dealing with two conradictory opinions on 
> > > > how 
> > > > this driver should be written. The one you presented in your previous 
> > > > post 
> > > > assumes that there will be a header file with defines shared between 
> > > > the 
> > > > clock driver and DTS, also with clock gating details hidden behind some 
> > > > additional level of indirection, e.g.:
> > > > 
> > > > clocks = <&sim SIM_SCGC4_UART1_CLK>;
> > > > 
> > > > Note that I've been through this at the very beginning, though the 
> > > > names 
> > > > I used have been bit different, e.g.:
> > > > 
> > > > #define KINETIS_CG_UART1   KINETIS_MKCG(3, 11) /* SIM_SCGC4[11] 
> > > > */
> > > > 
> > > > This was rejected with a comment by Arnd:
> > > > 
> > > > Instead of using a triple indirection here, just put the tuples
> > > > in the DT directly using #clock-cells=<2>, and get rid of both this
> > > > header file and the dt-bindings/clock/kin

Re: [PATCH] Staging:wilc1000 :Remove typedef from struct

[Greg Kroah-Hartman]

On Sat, Aug 01, 2015 at 10:25:26AM +0530, Sudip Mukherjee wrote:
> On Fri, Jul 31, 2015 at 01:52:13PM -0700, Greg Kroah-Hartman wrote:
> > On Fri, Jul 31, 2015 at 11:08:47AM +0530, Shraddha Barke wrote:
> > > This patch fixes the following checkpatch.pl warning:
> > > 
> > > WARNING: do not add new typedefs
> > > 
> > > Signed-off-by: Shraddha Barke 
> > > ---
> 
> > > -typedef enum {
> > > +enum {
> > >   CLASS1_FRAME_TYPE  = 0x00,
> > >   CLASS2_FRAME_TYPE  = 0x01,
> > >   CLASS3_FRAME_TYPE  = 0x02,
> > 
> > Did you test-build this change?
> This enum is not used anywhere. So did not affect the build.

Then it should be deleted :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: v4.2-rc dcache regression, probably 75a6f82a0d10

[Linus Torvalds]

On Sat, Aug 1, 2015 at 12:26 AM, Al Viro  wrote:
>
> Actually, the shit had hit the fan earlier.  Look: in
> commit b18825a7c8e37a7cf6abb97a12a6ad71af160de7
> Author: David Howells 
> Date:   Thu Sep 12 19:22:53 2013 +0100
>
> VFS: Put a small type field into struct dentry::d_flags
>
> we have this:
>
> -   if (!can_lookup(nd->inode)) {
> +   if (!d_is_directory(nd->path.dentry)) {

Ahh. That's subtle, yes. Inodes are stable in ways that dentries
aren't. And the reason why Dominique bisected it to 4bf46a272647 would
seem to be that while dentries aren't really stable, the dentry flags
generally don't change. But dentry_iput() changed to actually clear
the type when clearing the inode, so that probably added a few cases
where it went from "stable in practice" to be more easily triggered.

Your patch looks obviously correct, with the slight worry that there
might be other cases of this.

> there.  AFAICS, other places of that sort are not a problem anymore.

Al, do you plan a pull request? It would be good to get this into rc5
(tomorrow) regardless of whether there might be other issues lurking
too.

   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] slave dmaengine fixes for 4.2-rc5

[Vinod Koul]

Hi Linus,

Here is the first fixes request for 4.2

  We had a regression due to reuse of descriptor so we have reverted that.
  Rest are driver fixes:
 at_hdmac and at_xdmac for residue, trannfer width, and channel config
 pl330 final fix for dma fails and overflow issue
 xgene resouce map fix
 mv_xor big endian op fix

So, please PULL for dmaengine updates for 4.2-rc5 from

  git://git.infradead.org/users/vkoul/slave-dma.git tags/dmaengine-fix-4.2-rc5

for you to fetch changes up to 8c8fe97b2b8a216523e2faf1ccca66ddab634e3e:

  Revert "dmaengine: virt-dma: don't always free descriptor upon completion" 
(2015-07-31 20:33:43 +0530)


dmaengine fixes for 4.2-rc5

  We had a regression due to reuse of descriptor so we have reverted that.
  Rest are driver fixes
 at_hdmac and at_xdmac for residue, trannfer width, and channel config
 pl330 final fix for dma fails and overflow issue
 xgene resouce map fix
 mv_xor big endian op fix


Cyrille Pitchen (2):
  dmaengine: at_hdmac: fix residue computation
  dmaengine: at_xdmac: fix transfer data width in at_xdmac_prep_slave_sg()

Jun Nie (1):
  Revert "dmaengine: virt-dma: don't always free descriptor upon completion"

Krzysztof Kozlowski (2):
  dmaengine: pl330: Fix overflow when reporting residue in memcpy
  dmaengine: pl330: Really fix choppy sound because of wrong residue 
calculation

Ludovic Desroches (1):
  dmaengine: at_xdmac: fix bug about channel configuration

Rameshwar Prasad Sahu (1):
  dmaengine: xgene-dma: Fix the resource map to handle overlapping

Thomas Petazzoni (1):
  dmaengine: mv_xor: fix big endian operation in register mode

 .../devicetree/bindings/dma/apm-xgene-dma.txt  |   2 +-
 arch/arm64/boot/dts/apm/apm-storm.dtsi |   2 +-
 drivers/dma/at_hdmac.c | 132 ++---
 drivers/dma/at_hdmac_regs.h|   3 +-
 drivers/dma/at_xdmac.c |  26 ++--
 drivers/dma/mv_xor.c   |   9 +-
 drivers/dma/pl330.c|   3 +-
 drivers/dma/virt-dma.c |  19 +--
 drivers/dma/virt-dma.h |  13 +-
 drivers/dma/xgene-dma.c|   3 +
 10 files changed, 121 insertions(+), 91 deletions(-)

-- 
~Vinod


signature.asc
Description: Digital signature

Re: [PATCH] watchdog: Fix race on single cpu boot

[Peter Zijlstra]

On Sat, Aug 01, 2015 at 09:05:52AM -0400, Ulrich Obergfell wrote:
> 
> Don,
> 
> > Uli privately has been working on a patchset that cleans up a bunch of these
> > race conditions.  We believe it should cover this case.  It uses the
> > proc_mutex to synchronize everything.
> >
> > I think he is reaching out to you.  If you could try his patchset to see if
> > it fixes things, it might be a cleaner approach than what you are doing.
> >
> > 
> >
> > Ok, I was poked on IRC and you have already done this and it passed your
> > testcase.  Let me get Uli to post his patches. :-)
> >
> > Cheers,
> > Don
> 
> I posted the patch set here:
> 
>   https://lkml.org/lkml/2015/8/1/64
>   https://lkml.org/lkml/2015/8/1/65
>   https://lkml.org/lkml/2015/8/1/66
>   https://lkml.org/lkml/2015/8/1/67
>   https://lkml.org/lkml/2015/8/1/68

If only you didn't use lkml.org links, that site is flaky beyond
unusable.

Please use lkml.kernel.org/r/$msgid, that way people actually have a
chance of getting a working link and/or finding it in their local
archive.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [tip:x86/mm] x86/mm/mtrr: Clean up mtrr_type_lookup()

[Borislav Petkov]

On Sat, Aug 01, 2015 at 04:28:20PM +0200, Luis R. Rodriguez wrote:
> I need to update this documentation to remove set_memory_wc() there as we've
> learned with the MTRR --> PAT conversion that set_memory_wc() cannot be used 
> on
> IO memory, it can only be used for RAM. I am not sure if I would call it being
> broken that you cannot use set_memory_*() for IO memory that may have been by
> design.

Well, it doesn't really make sense to write-combine IO memory, does it?
My simplistic impression is that an IO range behind which there's a
device, cannot stomach any caching of IO as all commands/data accesses
need to happen as they get issued...

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios

[Mike Snitzer]

On Sat, Aug 01 2015 at  2:58am -0400,
Ming Lin  wrote:

> On Fri, 2015-07-31 at 17:38 -0400, Mike Snitzer wrote:
> > 
> > OK, once setup, to run the 2 tests in question directly you'd do
> > something like:
> > 
> > dmtest run --suite thin-provisioning -n discard_a_fragmented_device
> > 
> > dmtest run --suite thin-provisioning -n 
> > discard_fully_provisioned_device_benchmark
> > 
> > Again, these tests pass without this patchset.
> 
> It's caused by patch 4.
> When discard size >=4G, the bio->bi_iter.bi_size overflows.

Thanks for tracking this down!

> Below is the new patch.
> 
> Christoph,
> Could you also help to review it?
> 
> Now we still do "misaligned" check in blkdev_issue_discard().
> So the same code in blk_bio_discard_split() was removed.

But I don't agree with this approach.  One of the most meaningful
benefits of late bio splitting is the upper layers shouldn't _need_ to
depend on the intermediate devices' queue_limits being stacked properly.
Your solution to mix discard granularity/alignment checks at the upper
layer(s) but then split based on max_discard_sectors at the lower layer
defeats that benefit for discards.

This will translate to all intermediate layers that might split
discards needing to worry about granularity/alignment
too (e.g. how dm-thinp will have to care because it must generate
discard mappings with associated bios based on how blocks were mapped to
thinp).

Also, it is unfortunate that IO that doesn't have a payload is being
artificially split simply because bio->bi_iter.bi_size is 32bits.

Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [tip:x86/mm] x86/mm/mtrr: Clean up mtrr_type_lookup()

[Linus Torvalds]

On Sat, Aug 1, 2015 at 9:33 AM, Borislav Petkov  wrote:
>
> Well, it doesn't really make sense to write-combine IO memory, does it?

Quite the reverse.

It makes no sense to write-combine normal memory (RAM), because caches
work and sane memory is always cache-coherent. So marking regular
memory write-combining is a sign of crap hardware (which admittedly
exists all too much, but hopefully goes away).

In contrast, marking MMIO memory write-combining is not a sign of crap
hardware - it's just a sign of things like frame buffers on the card
etc. Which very much wants write combining. So WC for MMIO at least
makes sense.

Yes, yes, I realize that "crap hardware" may actually be the more
common case, but still..

 Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86: use WRITE_ONCE/READ_ONCE in smp_store_release/smp_load_acquire

[Andrey Konovalov]

Replace ACCESS_ONCE() macro in smp_store_release() and smp_load_acquire()
from arch/x86/include/asm/barrier.h with WRITE_ONCE() and READ_ONCE() since
ACCESS_ONCE does not work reliably on non-scalar types.

WRITE_ONCE() and READ_ONCE() were introduced in the commits 230fa253df63
("kernel: Provide READ_ONCE and ASSIGN_ONCE") and 43239cbe79fc ("kernel:
Change ASSIGN_ONCE(val, x) to WRITE_ONCE(x, val)").

Signed-off-by: Andrey Konovalov 
---
 arch/x86/include/asm/barrier.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
index e51a8f8..d2bcfbe 100644
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -57,12 +57,12 @@
 do {   \
compiletime_assert_atomic_type(*p); \
smp_mb();   \
-   ACCESS_ONCE(*p) = (v);  \
+   WRITE_ONCE(*p, v);  \
 } while (0)
 
 #define smp_load_acquire(p)\
 ({ \
-   typeof(*p) ___p1 = ACCESS_ONCE(*p); \
+   typeof(*p) ___p1 = READ_ONCE(*p);   \
compiletime_assert_atomic_type(*p); \
smp_mb();   \
___p1;  \
@@ -74,12 +74,12 @@ do {
\
 do {   \
compiletime_assert_atomic_type(*p); \
barrier();  \
-   ACCESS_ONCE(*p) = (v);  \
+   WRITE_ONCE(*p, v);  \
 } while (0)
 
 #define smp_load_acquire(p)\
 ({ \
-   typeof(*p) ___p1 = ACCESS_ONCE(*p); \
+   typeof(*p) ___p1 = READ_ONCE(*p);   \
compiletime_assert_atomic_type(*p); \
barrier();  \
___p1;  \
-- 
2.5.0.rc2.392.g76e840b

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [tip:x86/mm] x86/mm/mtrr: Clean up mtrr_type_lookup()

[Borislav Petkov]

On Sat, Aug 01, 2015 at 09:39:07AM -0700, Linus Torvalds wrote:
> Quite the reverse.
> 
> It makes no sense to write-combine normal memory (RAM), because caches
> work and sane memory is always cache-coherent. So marking regular
> memory write-combining is a sign of crap hardware (which admittedly
> exists all too much, but hopefully goes away).
> 
> In contrast, marking MMIO memory write-combining is not a sign of crap
> hardware - it's just a sign of things like frame buffers on the card
> etc. Which very much wants write combining. So WC for MMIO at least
> makes sense.
> 
> Yes, yes, I realize that "crap hardware" may actually be the more
> common case, but still..

Hmm, ok.

My simplistic mental picture while thinking of this is the IO range
where you send the commands to the device and you don't really want to
delay those but they should reach the device as they get issued.

OTOH, your example with frame buffers really wants to WC because sending
down each write separately is plain dumb.

Ok, I see, so it can make sense to have WC IO memory, depending on the
range and what you're going to use it for, I guess...

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: use WRITE_ONCE/READ_ONCE in smp_store_release/smp_load_acquire

[Borislav Petkov]

On Sat, Aug 01, 2015 at 06:45:34PM +0200, Andrey Konovalov wrote:
> Replace ACCESS_ONCE() macro in smp_store_release() and smp_load_acquire()
> from arch/x86/include/asm/barrier.h with WRITE_ONCE() and READ_ONCE() since
> ACCESS_ONCE does not work reliably on non-scalar types.
> 
> WRITE_ONCE() and READ_ONCE() were introduced in the commits 230fa253df63
> ("kernel: Provide READ_ONCE and ASSIGN_ONCE") and 43239cbe79fc ("kernel:
> Change ASSIGN_ONCE(val, x) to WRITE_ONCE(x, val)").

You actually forgot to CC the author. Let me add some more people to CC,
in addition.

> Signed-off-by: Andrey Konovalov 
> ---
>  arch/x86/include/asm/barrier.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
> index e51a8f8..d2bcfbe 100644
> --- a/arch/x86/include/asm/barrier.h
> +++ b/arch/x86/include/asm/barrier.h
> @@ -57,12 +57,12 @@
>  do { \
>   compiletime_assert_atomic_type(*p); \
>   smp_mb();   \
> - ACCESS_ONCE(*p) = (v);  \
> + WRITE_ONCE(*p, v);  \
>  } while (0)
>  
>  #define smp_load_acquire(p)  \
>  ({   \
> - typeof(*p) ___p1 = ACCESS_ONCE(*p); \
> + typeof(*p) ___p1 = READ_ONCE(*p);   \
>   compiletime_assert_atomic_type(*p); \
>   smp_mb();   \
>   ___p1;  \
> @@ -74,12 +74,12 @@ do {  
> \
>  do { \
>   compiletime_assert_atomic_type(*p); \
>   barrier();  \
> - ACCESS_ONCE(*p) = (v);  \
> + WRITE_ONCE(*p, v);  \
>  } while (0)
>  
>  #define smp_load_acquire(p)  \
>  ({   \
> - typeof(*p) ___p1 = ACCESS_ONCE(*p); \
> + typeof(*p) ___p1 = READ_ONCE(*p);   \
>   compiletime_assert_atomic_type(*p); \
>   barrier();  \
>   ___p1;  \
> -- 
> 2.5.0.rc2.392.g76e840b
> 

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/7] Initial support for user namespace owned mounts

[Amir Goldstein]

On Fri, Jul 31, 2015 at 10:56 PM, Casey Schaufler
 wrote:
> On 7/31/2015 1:11 AM, Amir Goldstein wrote:
>> On Thu, Jul 30, 2015 at 6:33 PM, Casey Schaufler  
>> wrote:
>>> On 7/30/2015 7:47 AM, Amir Goldstein wrote:
 On Thu, Jul 30, 2015 at 4:55 PM, Seth Forshee
  wrote:
> On Thu, Jul 30, 2015 at 07:24:11AM +0300, Amir Goldstein wrote:
>> On Tue, Jul 28, 2015 at 11:40 PM, Seth Forshee
>>  wrote:
>>> On Wed, Jul 22, 2015 at 05:05:17PM -0700, Casey Schaufler wrote:
> This is what I currently think you want for user ns mounts:
>
>  1. smk_root and smk_default are assigned the label of the backing
> device.
>> Seth,
>>
>> There were 2 main concerns discussed in this thread:
>> 1. trusting LSM labels outside the namespace
>> 2. trusting the content of the image file/loopdev
>>
>> While your approach addresses the first concern, I suspect it may be 
>> placing
>> an obstacle in a way for resolving the second concern.
>>
>> A viable security policy to mitigate the second concern could be:
>> - Allow only trusted programs (e.g. mkfs, fsck) to write to 'Loopback' 
>> images
>> - Allow mount only of 'Loopback' images
>>
>> This should allow the system as a whole to trust unprivileged mounts 
>> based on
>> the trust of the entities that had raw access the the fs layout.
> You don't really say what you mean by "trusted" programs. In a container
> context I'd have to assume that you mean suid-root or similar programs
> shared into the container by the host. In that case is any new kernel
> functionality even required?
 Sorry I was not clear. I will try to explain better.
 I meant that the programs are "trusted" by the LSM security policy.
 I envisioned a system where unprivileged user is allowed to spawn
 a container which contains "trusted" programs (e.g. mkfs) that are labeled
 as 'FileSystemTools' by the admin of the host.
 FileSystemTools are allowed to write into Loopback labeled files.
>>> You could do this on a Smack based system. It would require
>>> CAP_MAC_ADMIN and CAP_MAC_OVERRIDE to set up. You would need
>>> to set some SMACK64EXEC labels on your FileSystemTools, and
>>> they would have to be written as carefully as the would if they
>>> had "more" privilege. You'd need to designate a repository for
>>> your loopback files. On the whole, it would be unattractive.
>>> I will pass on providing the details for fear someone will like
>>> it well enough to implement.
>>>
> That also doesn't work for some of our use cases, where we'd like to be
> able to do something like "mount -o loop foo.img /mnt/foo" in an
> unprivileged container where foo.img is not created on the local machine
> and not fully under control of the host environment.
 That use case will not be addressed by the policy I suggested,
 but the more common case of:
 - create a loopback file
 - mkfs
 - mount
 will be addressed.

 So if the (host) admin of the system trusts that unprivileged user cannot 
 create
 a malicious fs layout using mkfs and fsck alone, then the system is
 relatively safe
 mounting (non fuse) file systems from loopback files.
 IMHO, this statement is going to be easier for Ted to sign.
>>> But that sort of defeats the purpose of unprivileged mounts.
>>> Or rather, you're trying to place restrictions on what an
>>> unprivileged user can do without calling the ability to
>>> violate those restrictions "privilege".
>> I don't understand your concern.
>
> My concern is that you're playing a shell game. Allow unprivileged
> mounts, but only of things that where created using privilege. How
> is that better than requiring privilege to do the mount?

To me, the ability of an admin to delegate permissions to unprivileged
user to mkfs/fsck/mount "trusted" loopdevs, sounds very useful.
But I am not going to argue that use case any further.

I do agree that it would have been much better if user namespace
could allow unprivileged mounts of certain non FUSE file systems
without relying on specially crafted security policies, but I do not
see how that can happen.


>
>> I am saying that LSM can come to the rescue, in a use case that
>> many have been considering as unsolvable (i.e. the loopback tampering).
>>
>> Yes, I am trying to place restrictions on what an unprivileged user can do.
>> As it stands right now, user is about to gain the ability to mount FUSE.
>> With some extra care on crafting the policy and without any extra code,
>> user can gain the ability to mount "trusted loopback files".
>> It does not solve all use cases, but it does solve a handful.
>
> As I said, you can do this, but it will be ugly, and people won't
> understand how to use it correctly. The distance between the "trusted"
> creation of the filesystem and the "untrusted" mount is too great.
> Plus, there are too many ways

Re: [tip:x86/mm] x86/mm/mtrr: Clean up mtrr_type_lookup()

[Linus Torvalds]

On Sat, Aug 1, 2015 at 9:49 AM, Borislav Petkov  wrote:
>
> My simplistic mental picture while thinking of this is the IO range
> where you send the commands to the device and you don't really want to
> delay those but they should reach the device as they get issued.

Well, even for command streams, people often do go for a
write-combining approach, simply because it is *so* much more
efficient on the bus to buffer and burst things. The interface is set
up to not really "combine" things in the over-writing sense, but just
in the "combine continuous writes into bigger buffers on the CPU, and
then write it out as efficiently as possible" sense.

Of course, the device (and the driver) has to be designed properly for
that, and it makes sense only with certain kinds of models, but it can
actually be much more efficient to make the device interface be
something like "write 32-byte command packets to a circular
write-combining buffer" than it is to do things other ways. Back in
the days, that was one of the most efficient ways to try to fill up
the PCI bandwidth.

There are other approaches too, of course, with the modern variation
tending to be "the device does all real accesses by reading over DMA,
and the only time you use IO accesses is for setup and as a 'start
your DMA transfers now' kind of interface". But write-combining MMIO
used to be a very common model for high-performace IO not that long
ago, because DMA didn't actually use to be all that efficient at all
(nasty behavior with caches and snooping etc back before the memory
controller was on-die and DMA accesses snooped caches directly). So
the "DMA is efficient even for smaller things" thing is relatively
recent.

 Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: v4.2-rc dcache regression, probably 75a6f82a0d10

[Al Viro]

On Sat, Aug 01, 2015 at 09:09:24AM -0700, Linus Torvalds wrote:
> On Sat, Aug 1, 2015 at 12:26 AM, Al Viro  wrote:
> >
> > Actually, the shit had hit the fan earlier.  Look: in
> > commit b18825a7c8e37a7cf6abb97a12a6ad71af160de7
> > Author: David Howells 
> > Date:   Thu Sep 12 19:22:53 2013 +0100
> >
> > VFS: Put a small type field into struct dentry::d_flags
> >
> > we have this:
> >
> > -   if (!can_lookup(nd->inode)) {
> > +   if (!d_is_directory(nd->path.dentry)) {
> 
> Ahh. That's subtle, yes. Inodes are stable in ways that dentries
> aren't. And the reason why Dominique bisected it to 4bf46a272647 would
> seem to be that while dentries aren't really stable, the dentry flags
> generally don't change. But dentry_iput() changed to actually clear
> the type when clearing the inode, so that probably added a few cases
> where it went from "stable in practice" to be more easily triggered.
> 
> Your patch looks obviously correct, with the slight worry that there
> might be other cases of this.
> 
> > there.  AFAICS, other places of that sort are not a problem anymore.
> 
> Al, do you plan a pull request? It would be good to get this into rc5
> (tomorrow) regardless of whether there might be other issues lurking
> too.

Will do later today.  -stable branches will be interesting, though ;-/

Al, still digging through the loads of fun stuff in l-k mailbox...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] regulator: axp20x: Add module alias

[Ian Campbell]

This allows the module to be autoloaded.

Together with 07949bf9c63c ("cpufreq: dt: allow driver to boot
automatically") this is sufficient to allow a modular kernel (such
as Debian's) to enable cpufreq on a Cubietruck.

Signed-off-by: Ian Campbell 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Chen-Yu Tsai 
Cc: Maxime Ripard 
Cc: linux-su...@googlegroups.com
---
v2: Submit properly.
---
 drivers/regulator/axp20x-regulator.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index e4331f5..2c82131 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -264,3 +264,4 @@ module_platform_driver(axp20x_regulator_driver);
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Carlo Caione ");
 MODULE_DESCRIPTION("Regulator Driver for AXP20X PMIC");
+MODULE_ALIAS("platform:axp20x-regulator");
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: use WRITE_ONCE/READ_ONCE in smp_store_release/smp_load_acquire

[Peter Zijlstra]

On Sat, Aug 01, 2015 at 06:45:34PM +0200, Andrey Konovalov wrote:
> Replace ACCESS_ONCE() macro in smp_store_release() and smp_load_acquire()
> from arch/x86/include/asm/barrier.h with WRITE_ONCE() and READ_ONCE() since
> ACCESS_ONCE does not work reliably on non-scalar types.
> 
> WRITE_ONCE() and READ_ONCE() were introduced in the commits 230fa253df63
> ("kernel: Provide READ_ONCE and ASSIGN_ONCE") and 43239cbe79fc ("kernel:
> Change ASSIGN_ONCE(val, x) to WRITE_ONCE(x, val)").

Please do all relevant archs.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 4/6] scsi: ufs: prevent IRQ handler accessing already freed hostdata

[Akinobu Mita]

As UFS driver registers IRQ handler as a shared IRQ, when
CONFIG_DEBUG_SHIRQ=y, an extra call will be made while unregistering
the IRQ handler.  Unfortunately, the extra call will accesses already
freed hostdata.  This is because devm_request_irq() is used to register
IRQ handler so that it will be unregistered automatically on driver
remove, but the hostdata has already been freed at this time.

This fixes it by explicitly registering/unregistering IRQ handler on
driver probe/remove.

Signed-off-by: Akinobu Mita 
Cc: Vinayak Holikatti 
Cc: "James E.J. Bottomley" 
Cc: Christoph Hellwig 
Cc: Dolev Raviv 
Cc: Sujit Reddy Thumma 
Cc: Subhash Jadavani 
Cc: Hannes Reinecke 
Cc: Sahitya Tummala 
Cc: Yaniv Gardi 
Cc: linux-s...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/scsi/ufs/ufshcd.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index e25f919..d425816 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5361,6 +5361,7 @@ void ufshcd_remove(struct ufs_hba *hba)
scsi_remove_host(hba->host);
/* disable interrupts */
ufshcd_disable_intr(hba, hba->intr_mask);
+   ufshcd_disable_irq(hba);
ufshcd_hba_stop(hba);
 
ufshcd_exit_clk_gating(hba);
@@ -5611,13 +5612,9 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem 
*mmio_base, unsigned int irq)
 
ufshcd_init_clk_gating(hba);
/* IRQ registration */
-   err = devm_request_irq(dev, irq, ufshcd_intr, IRQF_SHARED, UFSHCD, hba);
-   if (err) {
-   dev_err(hba->dev, "request irq failed\n");
+   err = ufshcd_enable_irq(hba);
+   if (err)
goto exit_gating;
-   } else {
-   hba->is_irq_enabled = true;
-   }
 
/* Enable SCSI tag mapping */
err = scsi_init_shared_tag_map(host, host->can_queue);
@@ -5668,9 +5665,9 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem 
*mmio_base, unsigned int irq)
 out_remove_scsi_host:
scsi_remove_host(hba->host);
 exit_gating:
+   ufshcd_disable_irq(hba);
ufshcd_exit_clk_gating(hba);
 out_disable:
-   hba->is_irq_enabled = false;
ufshcd_hba_exit(hba);
 out_error:
scsi_host_put(host);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/7] locking/pvqspinlock: Unconditional PV kick with _Q_SLOW_VAL

[Davidlohr Bueso]

On Fri, 2015-07-31 at 22:21 -0400, Waiman Long wrote:
> The smp_store_release() is not a full barrier. In order to avoid missed
> wakeup, we may need to add memory barrier around locked and cpu state
> variables adding to complexity. As the chance of spurious wakeup is very
> low, it is easier and safer to just do an unconditional kick at unlock
> time.
> 
> Signed-off-by: Waiman Long 

Please keep tags from previous versions ;)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

drivres/hv

[K. Y. Srinivasan]

 
Greg, over the last two months we have sent numerous Hyper-V patches and
these are yet to be comitted (all review comments have been addressed
for these patches). Please let me know if I should resend these patches.

Regards,

K. Y

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: drivres/hv

[Greg KH]

On Sat, Aug 01, 2015 at 12:46:10PM -0700, K. Y. Srinivasan wrote:
>  
> Greg, over the last two months we have sent numerous Hyper-V patches and
> these are yet to be comitted (all review comments have been addressed
> for these patches). Please let me know if I should resend these patches.

They are in my queue, I've been slow at getting to them, sorry.  If you
want to resend them so that I know exactly which ones to apply, instead
of having to dig through the different 'resend' and 'v2' series, that
would be most appreciated.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: drivres/hv

[KY Srinivasan]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Saturday, August 1, 2015 11:36 AM
> To: KY Srinivasan 
> Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com;
> jasow...@redhat.com
> Subject: Re: drivres/hv
> 
> On Sat, Aug 01, 2015 at 12:46:10PM -0700, K. Y. Srinivasan wrote:
> >
> > Greg, over the last two months we have sent numerous Hyper-V patches
> and
> > these are yet to be comitted (all review comments have been addressed
> > for these patches). Please let me know if I should resend these patches.
> 
> They are in my queue, I've been slow at getting to them, sorry.  If you
> want to resend them so that I know exactly which ones to apply, instead
> of having to dig through the different 'resend' and 'v2' series, that
> would be most appreciated.

Thanks Greg; I can understand. I will send them out right away as one large set.

Regards,

K. Y
> 
> thanks,
> 
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/4] Shared vhost design

[Bandan Das]

Eyal Moscovici  writes:
...
>
> We can start to implement polling, but I am unsure if the cgroups 
> integration 
> will be sufficient. The polling vhost thread should be scheduled all
> the time and just moving it from one cgroup to the other wont be 
> sufficient. 
> I think it needs a deeper integration to the point where either we have a 
> vhost thread for each cgroup or the vhost thread enforces the cgroup 
> policies over its polled VM guests.

Agreed, what we have with cgroups is not sufficient. I am waiting
for Tejun et al to comment on our approach :) Michael mentioned whether
it's possible to integrate cgroups into workgroups which I think is a more
generic and the preferred solution. I just don't know yet how easy/difficult
it is to implement this with the new cgroups unified hierarchy.


BTW, I am working on the numbers you had asked for. Honestly, I think the
cost of cgroups could be similar to running a vhost thread/guest since
that is how cgroups integration currently works. But it's good to have the
numbers before us. 

>> 
>> So simple polling by vhost is kind of ok for some guests, but I think to
>> really make it work for a reasonably wide selection of guests/workloads
>> you need to combine it with 1. polling the NIC - it makes no sense to me
>> to only poll one side of the equation; and probably 2. - polling in
>> guest.
>> 
>
> I agree that we need polling on the NIC which could probably be achieved 
> by using
> the polling interface introduced in kernel 3.11: 
> http://lwn.net/Articles/551284/
> although I never tried using it myself.
> About your point about polling inside the guest, I think it is orthogonal 
> to polling
> in the host.
>
>
> Eyal Moscovici
> HL-Cloud Infrastructure Solutions
> IBM Haifa Research Lab
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.2 058/221] debugfs: leave freeing a symlink body until inode eviction

[Ben Hutchings]

On Tue, 2015-06-16 at 17:33 +0100, Luis Henriques wrote:
> On Tue, May 05, 2015 at 02:16:39AM +0100, Ben Hutchings wrote:
[...]
> > [bwh: Backported to 3.2:
> >  - Plumb in debugfs_super_operations, which we didn't previously 
> > define
> 
> It looks like this is introducing a regression[1].  Basically, simply
> running df shows an error:
> 
>   df: `/sys/kernel/debug': Function not implemented
> 
> Doing 'strace df' shows the following:
> 
>   statfs64("/sys/kernel/debug", 84, 0xbfddc6bc) = -1 ENOSYS (Function 
> not implemented)
> 
> A quick test shows that adding '.statfs = simple_statfs' in the
> debugfs_super_operations struct fixes the problem, but I'm not sure
> that's the right thing to do.
[...]

It looks right to me.  I've queued up this change; thanks a lot.

Ben.

-- 
Ben Hutchings
One of the nice things about standards is that there are so many of them.



signature.asc
Description: This is a digitally signed message part

Re: [PATCH net-next 1/9] openvswitch: Scrub packet in ovs_vport_receive()

[Thomas Graf]

On 07/31/15 at 10:51am, Joe Stringer wrote:
> On 31 July 2015 at 07:34, Hannes Frederic Sowa  wrote:
> > In general, this shouldn't be necessary as the packet should already be
> > scrubbed before they arrive here.
> >
> > Could you maybe add a WARN_ON and check how those skbs with conntrack
> > data traverse the stack? I also didn't understand why make it dependent
> > on the socket.
> 
> OK, sure. One case I could think of is with an OVS internal port in
> another namespace, directly attached to the bridge. I'll have a play
> around with WARN_ON and see if I can come up with something more
> trimmed down.

The OVS internal port will definitely pass through an unscrubbed
packet across namespaces. I think the proper thing to do would be
to scrub but conditionally keep metadata.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V4 (was V6) 1/2] audit: eliminate unnecessary extra layer of watch references

[Richard Guy Briggs]

The audit watch count was imbalanced, adding an unnecessary layer of watch
references.  Only add the second reference when it is added to a parent.

Signed-off-by: Richard Guy Briggs 
---
 kernel/audit_watch.c |5 ++---
 kernel/auditfilter.c |   16 +++-
 2 files changed, 5 insertions(+), 16 deletions(-)

diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index 6e30024..f33f54c 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -203,7 +203,6 @@ int audit_to_watch(struct audit_krule *krule, char *path, 
int len, u32 op)
if (IS_ERR(watch))
return PTR_ERR(watch);
 
-   audit_get_watch(watch);
krule->watch = watch;
 
return 0;
@@ -387,8 +386,7 @@ static void audit_add_to_parent(struct audit_krule *krule,
 
watch_found = 1;
 
-   /* put krule's and initial refs to temporary watch */
-   audit_put_watch(watch);
+   /* put krule's ref to temporary watch */
audit_put_watch(watch);
 
audit_get_watch(w);
@@ -400,6 +398,7 @@ static void audit_add_to_parent(struct audit_krule *krule,
audit_get_parent(parent);
watch->parent = parent;
 
+   audit_get_watch(watch);
list_add(&watch->wlist, &parent->watches);
}
list_add(&krule->rlist, &watch->rules);
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index 72e1660..4cb9b44 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -549,8 +549,6 @@ exit_nofree:
return entry;
 
 exit_free:
-   if (entry->rule.watch)
-   audit_put_watch(entry->rule.watch); /* matches initial get */
if (entry->rule.tree)
audit_put_tree(entry->rule.tree); /* that's the temporary one */
audit_free_rule(entry);
@@ -881,7 +879,7 @@ static inline int audit_add_rule(struct audit_entry *entry)
/* normally audit_add_tree_rule() will free it on failure */
if (tree)
audit_put_tree(tree);
-   goto error;
+   return err;
}
 
if (watch) {
@@ -895,14 +893,14 @@ static inline int audit_add_rule(struct audit_entry 
*entry)
 */
if (tree)
audit_put_tree(tree);
-   goto error;
+   return err;
}
}
if (tree) {
err = audit_add_tree_rule(&entry->rule);
if (err) {
mutex_unlock(&audit_filter_mutex);
-   goto error;
+   return err;
}
}
 
@@ -933,11 +931,6 @@ static inline int audit_add_rule(struct audit_entry *entry)
 #endif
mutex_unlock(&audit_filter_mutex);
 
-   return 0;
-
-error:
-   if (watch)
-   audit_put_watch(watch); /* tmp watch, matches initial get */
return err;
 }
 
@@ -945,7 +938,6 @@ error:
 static inline int audit_del_rule(struct audit_entry *entry)
 {
struct audit_entry  *e;
-   struct audit_watch *watch = entry->rule.watch;
struct audit_tree *tree = entry->rule.tree;
struct list_head *list;
int ret = 0;
@@ -986,8 +978,6 @@ static inline int audit_del_rule(struct audit_entry *entry)
mutex_unlock(&audit_filter_mutex);
 
 out:
-   if (watch)
-   audit_put_watch(watch); /* match initial get */
if (tree)
audit_put_tree(tree);   /* that's the temporary one */
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V4 (was V6) 2/2] audit: eliminate unnecessary extra layer of watch parent references

[Richard Guy Briggs]

The audit watch parent count was imbalanced, adding an unnecessary layer of
watch parent references.  Decrement the additional parent reference when a
watch is reused, already having a reference to the parent.

audit_find_parent() gets a reference to the parent, if the parent is
already known.  This additional parental reference is not needed if the
watch is subsequently found by audit_add_to_parent(), and consumed if
the watch does not already exist, so we need to put the parent if the
watch is found, and do nothing if this new watch is added to the parent.

If the parent wasn't already known, it is created with a refcount of 1
and added to the audit_watch_group, then incremented by one to be
subsequently consumed by the newly created watch in
audit_add_to_parent().

The rule points to the watch, not to the parent, so the rule's refcount
gets bumped, not the parent's.

See LKML, 2015-07-16

Signed-off-by: Richard Guy Briggs 
---
 kernel/audit_watch.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index f33f54c..8f123d7 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -391,11 +391,12 @@ static void audit_add_to_parent(struct audit_krule *krule,
 
audit_get_watch(w);
krule->watch = watch = w;
+
+   audit_put_parent(parent);
break;
}
 
if (!watch_found) {
-   audit_get_parent(parent);
watch->parent = parent;
 
audit_get_watch(watch);
@@ -436,9 +437,6 @@ int audit_add_watch(struct audit_krule *krule, struct 
list_head **list)
 
audit_add_to_parent(krule, parent);
 
-   /* match get in audit_find_parent or audit_init_parent */
-   audit_put_parent(parent);
-
h = audit_hash_ino((u32)watch->ino);
*list = &audit_inode_hash[h];
 error:
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V4 (was V6) 0/2] audit: rebalance and remove extra layers of watch references

[Richard Guy Briggs]

While working on the audit by executable path feature, it was discovered that
watches and parent references were slightly imbalanced and deeper than
necessary.

Only bump up references when they are actually used and decrease when removed.


v4: Eliminate unnecessary gotos and call return directly.
Expand patch description with answer to mailing list query.


Richard Guy Briggs (2):
  audit: eliminate unnecessary extra layer of watch references
  audit: eliminate unnecessary extra layer of watch parent references

 kernel/audit_watch.c |   11 ---
 kernel/auditfilter.c |   16 +++-
 2 files changed, 7 insertions(+), 20 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V4 (was V6)] audit: use macros for unset inode and device values

[Richard Guy Briggs]

Signed-off-by: Richard Guy Briggs 
---
 include/uapi/linux/audit.h |2 ++
 kernel/audit.c |2 +-
 kernel/audit_watch.c   |8 
 kernel/auditsc.c   |6 +++---
 4 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index d3475e1..971df22 100644
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -440,6 +440,8 @@ struct audit_tty_status {
 };
 
 #define AUDIT_UID_UNSET (unsigned int)-1
+#define AUDIT_INO_UNSET (unsigned long)-1
+#define AUDIT_DEV_UNSET (unsigned)-1
 
 /* audit_rule_data supports filter rules with both integer and string
  * fields.  It corresponds with AUDIT_ADD_RULE, AUDIT_DEL_RULE and
diff --git a/kernel/audit.c b/kernel/audit.c
index 1c13e42..d546003 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1761,7 +1761,7 @@ void audit_log_name(struct audit_context *context, struct 
audit_names *n,
} else
audit_log_format(ab, " name=(null)");
 
-   if (n->ino != (unsigned long)-1)
+   if (n->ino != AUDIT_INO_UNSET)
audit_log_format(ab, " inode=%lu"
 " dev=%02x:%02x mode=%#ho"
 " ouid=%u ogid=%u rdev=%02x:%02x",
diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index 8f123d7..c668bfc 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -138,7 +138,7 @@ char *audit_watch_path(struct audit_watch *watch)
 
 int audit_watch_compare(struct audit_watch *watch, unsigned long ino, dev_t 
dev)
 {
-   return (watch->ino != (unsigned long)-1) &&
+   return (watch->ino != AUDIT_INO_UNSET) &&
(watch->ino == ino) &&
(watch->dev == dev);
 }
@@ -179,8 +179,8 @@ static struct audit_watch *audit_init_watch(char *path)
INIT_LIST_HEAD(&watch->rules);
atomic_set(&watch->count, 1);
watch->path = path;
-   watch->dev = (dev_t)-1;
-   watch->ino = (unsigned long)-1;
+   watch->dev = AUDIT_DEV_UNSET;
+   watch->ino = AUDIT_INO_UNSET;
 
return watch;
 }
@@ -493,7 +493,7 @@ static int audit_watch_handle_event(struct fsnotify_group 
*group,
if (mask & (FS_CREATE|FS_MOVED_TO) && inode)
audit_update_watch(parent, dname, inode->i_sb->s_dev, 
inode->i_ino, 0);
else if (mask & (FS_DELETE|FS_MOVED_FROM))
-   audit_update_watch(parent, dname, (dev_t)-1, (unsigned long)-1, 
1);
+   audit_update_watch(parent, dname, AUDIT_DEV_UNSET, 
AUDIT_INO_UNSET, 1);
else if (mask & (FS_DELETE_SELF|FS_UNMOUNT|FS_MOVE_SELF))
audit_remove_parent_watches(parent);
 
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 9fb9d1c..701ea5c 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -180,7 +180,7 @@ static int audit_match_filetype(struct audit_context *ctx, 
int val)
return 0;
 
list_for_each_entry(n, &ctx->names_list, list) {
-   if ((n->ino != -1) &&
+   if ((n->ino != AUDIT_INO_UNSET) &&
((n->mode & S_IFMT) == mode))
return 1;
}
@@ -1683,7 +1683,7 @@ static struct audit_names *audit_alloc_name(struct 
audit_context *context,
aname->should_free = true;
}
 
-   aname->ino = (unsigned long)-1;
+   aname->ino = AUDIT_INO_UNSET;
aname->type = type;
list_add_tail(&aname->list, &context->names_list);
 
@@ -1925,7 +1925,7 @@ void __audit_inode_child(const struct inode *parent,
if (inode)
audit_copy_inode(found_child, dentry, inode);
else
-   found_child->ino = (unsigned long)-1;
+   found_child->ino = AUDIT_INO_UNSET;
 }
 EXPORT_SYMBOL_GPL(__audit_inode_child);
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V4 (was V6)] audit: macros to replace unset inode and device values

[Richard Guy Briggs]

This is a patch to clean up a number of places were casted magic numbers are
used to represent unset inode and device numbers inpreparation for the audit by
executable path patch set.

Richard Guy Briggs (1):
  audit: use macros for unset inode and device values

 include/uapi/linux/audit.h |2 ++
 kernel/audit.c |2 +-
 kernel/audit_watch.c   |8 
 kernel/auditsc.c   |6 +++---
 4 files changed, 10 insertions(+), 8 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V4 (was V6)] generalize audit_del_rule

[Richard Guy Briggs]

This patch was split out from the audit by executable path patch set due to the
potential to use it elsewhere.

In particular, some questions came up while assessing the potential for code
reuse:

Why does audit_remove_parent_watches() not call audit_del_rule() for
each entry found?
Is audit_signals not properly decremented?
Is audit_n_rules not properly decremented?

Why does kill_rules() not call audit_del_rule() for each entry found?
Is audit_signals not properly decremented?
Is audit_n_rules not properly decremented?


Richard Guy Briggs (1):
  audit: save signal match info in case entry passed in is the one
deleted

 kernel/auditfilter.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V4 (was V6)] audit: save signal match info in case entry passed in is the one deleted

[Richard Guy Briggs]

Move the access to the entry for audit_match_signal() to the beginning of the
function in case the entry found is the same one passed in.  This will enable
it to be used by audit_remove_mark_rule().

Signed-off-by: Richard Guy Briggs 
---
 kernel/auditfilter.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index 4cb9b44..afb63b3 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -943,6 +943,7 @@ static inline int audit_del_rule(struct audit_entry *entry)
int ret = 0;
 #ifdef CONFIG_AUDITSYSCALL
int dont_count = 0;
+   int match_signal = !audit_match_signal(entry);
 
/* If either of these, don't count towards total */
if (entry->rule.listnr == AUDIT_FILTER_USER ||
@@ -972,7 +973,7 @@ static inline int audit_del_rule(struct audit_entry *entry)
if (!dont_count)
audit_n_rules--;
 
-   if (!audit_match_signal(entry))
+   if (match_signal)
audit_signals--;
 #endif
mutex_unlock(&audit_filter_mutex);
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V7 1/3] audit: clean simple fsnotify implementation

[Richard Guy Briggs]

This is to be used to audit by executable path rules, but audit watches should
be able to share this code eventually.

At the moment the audit watch code is a lot more complex.  That code only
creates one fsnotify watch per parent directory.  That 'audit_parent' in
turn has a list of 'audit_watches' which contain the name, ino, dev of
the specific object we care about.  This just creates one fsnotify watch
per object we care about.  So if you watch 100 inodes in /etc this code
will create 100 fsnotify watches on /etc.  The audit_watch code will
instead create 1 fsnotify watch on /etc (the audit_parent) and then 100
individual watches chained from that fsnotify mark.

We should be able to convert the audit_watch code to do one fsnotify
mark per watch and simplify things/remove a whole lot of code.  After
that conversion we should be able to convert the audit_fsnotify code to
support that hierarchy if the optimization is necessary.

Move the access to the entry for audit_match_signal() to the beginning of
the audit_del_rule() function in case the entry found is the same one passed
in.  This will enable it to be used by audit_autoremove_mark_rule(),
kill_rules() and audit_remove_parent_watches().

This is a heavily modified and merged version of two patches originally
submitted by Eric Paris.

Cc: Peter Moody 
Cc: Eric Paris 
Signed-off-by: Richard Guy Briggs 
---
 kernel/Makefile |2 +-
 kernel/audit.h  |   14 +++
 kernel/audit_fsnotify.c |  215 +++
 kernel/auditfilter.c|2 +-
 4 files changed, 231 insertions(+), 2 deletions(-)
 create mode 100644 kernel/audit_fsnotify.c

diff --git a/kernel/Makefile b/kernel/Makefile
index 60c302c..58b5b52 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -64,7 +64,7 @@ obj-$(CONFIG_SMP) += stop_machine.o
 obj-$(CONFIG_KPROBES_SANITY_TEST) += test_kprobes.o
 obj-$(CONFIG_AUDIT) += audit.o auditfilter.o
 obj-$(CONFIG_AUDITSYSCALL) += auditsc.o
-obj-$(CONFIG_AUDIT_WATCH) += audit_watch.o
+obj-$(CONFIG_AUDIT_WATCH) += audit_watch.o audit_fsnotify.o
 obj-$(CONFIG_AUDIT_TREE) += audit_tree.o
 obj-$(CONFIG_GCOV_KERNEL) += gcov/
 obj-$(CONFIG_KPROBES) += kprobes.o
diff --git a/kernel/audit.h b/kernel/audit.h
index d641f9b..46d10dd 100644
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -50,6 +50,7 @@ enum audit_state {
 
 /* Rule lists */
 struct audit_watch;
+struct audit_fsnotify_mark;
 struct audit_tree;
 struct audit_chunk;
 
@@ -252,6 +253,7 @@ struct audit_net {
 extern int selinux_audit_rule_update(void);
 
 extern struct mutex audit_filter_mutex;
+extern int audit_del_rule(struct audit_entry *);
 extern void audit_free_rule_rcu(struct rcu_head *);
 extern struct list_head audit_filter_list[];
 
@@ -269,6 +271,13 @@ extern int audit_add_watch(struct audit_krule *krule, 
struct list_head **list);
 extern void audit_remove_watch_rule(struct audit_krule *krule);
 extern char *audit_watch_path(struct audit_watch *watch);
 extern int audit_watch_compare(struct audit_watch *watch, unsigned long ino, 
dev_t dev);
+
+extern struct audit_fsnotify_mark *audit_alloc_mark(struct audit_krule *krule, 
char *pathname, int len);
+extern char *audit_mark_path(struct audit_fsnotify_mark *mark);
+extern void audit_remove_mark(struct audit_fsnotify_mark *audit_mark);
+extern void audit_remove_mark_rule(struct audit_krule *krule);
+extern int audit_mark_compare(struct audit_fsnotify_mark *mark, unsigned long 
ino, dev_t dev);
+
 #else
 #define audit_put_watch(w) {}
 #define audit_get_watch(w) {}
@@ -278,6 +287,11 @@ extern int audit_watch_compare(struct audit_watch *watch, 
unsigned long ino, dev
 #define audit_watch_path(w) ""
 #define audit_watch_compare(w, i, d) 0
 
+#define audit_alloc_mark(k, p, l) (ERR_PTR(-EINVAL))
+#define audit_mark_path(m) ""
+#define audit_remove_mark(m)
+#define audit_remove_mark_rule(k)
+#define audit_mark_compare(m, i, d) 0
 #endif /* CONFIG_AUDIT_WATCH */
 
 #ifdef CONFIG_AUDIT_TREE
diff --git a/kernel/audit_fsnotify.c b/kernel/audit_fsnotify.c
new file mode 100644
index 000..654c6c7
--- /dev/null
+++ b/kernel/audit_fsnotify.c
@@ -0,0 +1,215 @@
+/* audit_fsnotify.c -- tracking inodes
+ *
+ * Copyright 2003-2009,2014-2015 Red Hat, Inc.
+ * Copyright 2005 Hewlett-Packard Development Company, L.P.
+ * Copyright 2005 IBM Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "audit.h"
+
+/*
+ * th

[PATCH V7 3/3] audit: add audit by children of executable path

[Richard Guy Briggs]

This adds the ability to audit the actions of children of a not-yet-running
process.

This is a split-out of a heavily modified version of a patch originally
submitted by Eric Paris with some ideas from Peter Moody.

Cc: Peter Moody 
Cc: Eric Paris 
Signed-off-by: Richard Guy Briggs 
---
 include/uapi/linux/audit.h |1 +
 kernel/auditfilter.c   |5 +
 kernel/auditsc.c   |   11 +++
 3 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index e2ca600..55a8dec 100644
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -267,6 +267,7 @@
 #define AUDIT_OBJ_GID  110
 #define AUDIT_FIELD_COMPARE111
 #define AUDIT_EXE  112
+#define AUDIT_EXE_CHILDREN 113
 
 #define AUDIT_ARG0  200
 #define AUDIT_ARG1  (AUDIT_ARG0+1)
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index fa3672b..e8bb735 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -406,6 +406,7 @@ static int audit_field_valid(struct audit_entry *entry, 
struct audit_field *f)
return -EINVAL;
break;
case AUDIT_EXE:
+   case AUDIT_EXE_CHILDREN:
if (f->op != Audit_equal)
return -EINVAL;
if (entry->rule.listnr != AUDIT_FILTER_EXIT)
@@ -547,6 +548,7 @@ static struct audit_entry *audit_data_to_entry(struct 
audit_rule_data *data,
entry->rule.filterkey = str;
break;
case AUDIT_EXE:
+   case AUDIT_EXE_CHILDREN:
if (entry->rule.exe || f->val > PATH_MAX)
goto exit_free;
str = audit_unpack_string(&bufp, &remain, f->val);
@@ -643,6 +645,7 @@ static struct audit_rule_data *audit_krule_to_data(struct 
audit_krule *krule)
audit_pack_string(&bufp, krule->filterkey);
break;
case AUDIT_EXE:
+   case AUDIT_EXE_CHILDREN:
data->buflen += data->values[i] =
audit_pack_string(&bufp, 
audit_mark_path(krule->exe));
break;
@@ -710,6 +713,7 @@ static int audit_compare_rule(struct audit_krule *a, struct 
audit_krule *b)
return 1;
break;
case AUDIT_EXE:
+   case AUDIT_EXE_CHILDREN:
/* both paths exist based on above type compare */
if (strcmp(audit_mark_path(a->exe),
   audit_mark_path(b->exe)))
@@ -838,6 +842,7 @@ struct audit_entry *audit_dupe_rule(struct audit_krule *old)
new->filterkey = fk;
break;
case AUDIT_EXE:
+   case AUDIT_EXE_CHILDREN:
err = audit_dupe_exe(new, old);
break;
}
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index e9bac2b..4f2b515 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -469,6 +469,17 @@ static int audit_filter_rules(struct task_struct *tsk,
case AUDIT_EXE:
result = audit_exe_compare(tsk, rule->exe);
break;
+   case AUDIT_EXE_CHILDREN:
+   {
+   struct task_struct *ptsk;
+   for (ptsk = tsk; ptsk->parent->pid > 0; ptsk = 
find_task_by_vpid(ptsk->parent->pid)) {
+   if (audit_exe_compare(ptsk, rule->exe)) {
+   ++result;
+   break;
+   }
+   }
+   }
+   break;
case AUDIT_UID:
result = audit_uid_comparator(cred->uid, f->op, f->uid);
break;
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V7 0/3] audit by executable name

[Richard Guy Briggs]

Please see the accompanying userspace patchset:
https://www.redhat.com/archives/linux-audit/2015-July/thread.html
[[PATCH V2] 0/2] Log on the future execution of a path
The userspace interface is not expected to change appreciably unless something
important has been overlooked.  Setting and deleting rules works as expected.

If the path does not exist at rule creation time, it will be re-evaluated every
time there is a change to the parent directory at which point the change in
device and inode will be noted.


Here's a sample run:
Test for addition, trigger and deletion of tree executable rule:
# auditctl -a always,exit -S all -F dir=/tmp -F exe=/usr/bin/touch -F 
key=exetest_tree

time->Sat Jul 11 10:41:50 2015
type=CONFIG_CHANGE msg=audit(1436629310.720:44711): auid=0 ses=1 
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op="add_rule" 
key="exetest_tree" list=4 res=1


# /usr/bin/touch /tmp/test

time->Sat Jul 11 10:41:50 2015
type=PROCTITLE msg=audit(1436629310.757:44712): 
proctitle=2F7573722F62696E2F746F756368002F746D702F74657374
type=PATH msg=audit(1436629310.757:44712): item=1 name="/tmp/test" inode=166932 
dev=00:24 mode=0100644 ouid=0 ogid=0 rdev=00:00 
obj=unconfined_u:object_r:user_tmp_t:s0 nametype=CREATE
type=PATH msg=audit(1436629310.757:44712): item=0 name="/tmp/" inode=11525 
dev=00:24 mode=041777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmp_t:s0 
nametype=PARENT
type=CWD msg=audit(1436629310.757:44712):  cwd="/root"
type=SYSCALL msg=audit(1436629310.757:44712): arch=c03e syscall=2 
success=yes exit=3 a0=7ffdee2f9e27 a1=941 a2=1b6 a3=691 items=2 ppid=17655 
pid=17762 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 
tty=ttyS0 ses=1 comm="touch" exe="/usr/bin/touch" 
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="exetest_tree"


# auditctl -d always,exit -S all -F dir=/tmp -F exe=/usr/bin/touch -F 
key=exetest_tree

time->Sat Jul 11 10:41:50 2015
type=CONFIG_CHANGE msg=audit(1436629310.839:44713): auid=0 ses=1 
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op="remove_rule" 
key="exetest_tree" list=4 res=1



Revision history:
v7: Add Audit Feature Bitmap macro AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH to
  AUDIT_FEATURE_BITMAP_ALL.
Split out new patch to use macros for unset inode and device values.
Remove BUG() usage in stubs.
Rename audit_mark_free() to audit_fsnotify_mark_free().
Remove unused audit_get_mark() and audit_put_mark() functions.
Rework ino and dev comparisons and assignments, using macros and existing
  funcs and eliminating temp variables.
Move audit_update_mark() above its first usage.
Move contents of kernel/audit_exe.c to kernel/audit_watch.c.
Merge patch 3 with 1, merge patch 4 with 1 and 3 and rewrite the patch 
descriptions.
Split out patch to audit by executable children.

v6: Explicitly declare prototypes as external.
Rename audit_dup_exe() to audit_dupe_exe() consistent with rule, watch, 
lsm_field.
Rebased on v4.1.
Rename audit_remove_mark_rule() called from audit_mark_handle_event() to
  audit_autoremove_mark_rule() to avoid confusion with
  audit_remove_{watch,tree}_rule() usage.
Add audit_remove_mark_rule() to provide similar interface as
  audit_remove_{watch,tree}_rule().
Simplify stubs to defines.
Rename audit_free_fsnotify_mark() to audit_fsnotify_free_mark() in keeping 
with
  the naming convention of inotify_free_mark(), dnotify_free_mark(),
  fanotify_free_mark(), audit_watch_free_mark().
Return -ENOMEM rather than null in case of memory allocation failure for
  audit_mark in audit_alloc_mark().
Rename audit_free_mark() to audit_mark_free() to avoid association with
  {i,d,fa}notify_free_mark() and audit_watch_free_mark().
Clean up exe with similar interface as watch and tree.
Clean up audit exe mark just before audit_free_rule() rather than in it to
  avoid mutex in software interrupt context.
Fixed bug in audit_dupe_exe() that returned error rather than valid pointer.

v5: Revert patch "Let audit_free_rule() take care of calling
audit_remove_mark()." since it caused a group mark deadlock.
https://www.redhat.com/archives/linux-audit/2014-October/msg00024.html

v4: Re-order and squash down fixups
Fix audit_dup_exe() to copy pathname string before calling 
audit_alloc_mark().
https://www.redhat.com/archives/linux-audit/2014-August/msg00065.html

v3: Rationalize and rename some function names and clean up get/put and free 
code.
Rename several "watch" references to "mark".
Rename audit_remove_rule() to audit_remove_mark_rule().
Let audit_free_rule() take care of calling audit_remove_mark().
Put audit_alloc_mark() arguments in same order as watch, tree and inode.
Move the access to the entry for audit_match_signal() to the beginning
 of the function in case the entry found is the same one pass

[PATCH V7 2/3] audit: implement audit by executable

[Richard Guy Briggs]

This adds the ability audit the actions of a not-yet-running process.

This patch implements the ability to filter on the executable path.  Instead of
just hard coding the ino and dev of the executable we care about at the moment
the rule is inserted into the kernel, use the new audit_fsnotify
infrastructure to manage this dynamically.  This means that if the filename
does not yet exist but the containing directory does, or if the inode in
question is unlinked and creat'd (aka updated) the rule will just continue to
work.  If the containing directory is moved or deleted or the filesystem is
unmounted, the rule is deleted automatically.  A future enhancement would be to
have the rule survive across directory disruptions.

This is a heavily modified version of a patch originally submitted by Eric
Paris with some ideas from Peter Moody.

Cc: Peter Moody 
Cc: Eric Paris 
Signed-off-by: Richard Guy Briggs 
---
 include/linux/audit.h  |1 +
 include/uapi/linux/audit.h |5 +++-
 kernel/audit.h |4 +++
 kernel/audit_tree.c|2 +
 kernel/audit_watch.c   |   31 +
 kernel/auditfilter.c   |   53 +++-
 kernel/auditsc.c   |3 ++
 7 files changed, 97 insertions(+), 2 deletions(-)

diff --git a/include/linux/audit.h b/include/linux/audit.h
index c2e7e3a..aee456f 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -59,6 +59,7 @@ struct audit_krule {
struct audit_field  *inode_f; /* quick access to an inode field */
struct audit_watch  *watch; /* associated watch */
struct audit_tree   *tree;  /* associated watched tree */
+   struct audit_fsnotify_mark  *exe;
struct list_headrlist;  /* entry in audit_{watch,tree}.rules 
list */
struct list_headlist;   /* for AUDIT_LIST* purposes only */
u64 prio;
diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index 971df22..e2ca600 100644
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -266,6 +266,7 @@
 #define AUDIT_OBJ_UID  109
 #define AUDIT_OBJ_GID  110
 #define AUDIT_FIELD_COMPARE111
+#define AUDIT_EXE  112
 
 #define AUDIT_ARG0  200
 #define AUDIT_ARG1  (AUDIT_ARG0+1)
@@ -324,8 +325,10 @@ enum {
 
 #define AUDIT_FEATURE_BITMAP_BACKLOG_LIMIT 0x0001
 #define AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME 0x0002
+#define AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH   0x0004
 #define AUDIT_FEATURE_BITMAP_ALL (AUDIT_FEATURE_BITMAP_BACKLOG_LIMIT | \
- AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME)
+ AUDIT_FEATURE_BITMAP_BACKLOG_WAIT_TIME | \
+ AUDIT_FEATURE_BITMAP_EXECUTABLE_PATH )
 
 /* deprecated: AUDIT_VERSION_* */
 #define AUDIT_VERSION_LATEST   AUDIT_FEATURE_BITMAP_ALL
diff --git a/kernel/audit.h b/kernel/audit.h
index 46d10dd..dadf86a 100644
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -277,6 +277,8 @@ extern char *audit_mark_path(struct audit_fsnotify_mark 
*mark);
 extern void audit_remove_mark(struct audit_fsnotify_mark *audit_mark);
 extern void audit_remove_mark_rule(struct audit_krule *krule);
 extern int audit_mark_compare(struct audit_fsnotify_mark *mark, unsigned long 
ino, dev_t dev);
+extern int audit_dupe_exe(struct audit_krule *new, struct audit_krule *old);
+extern int audit_exe_compare(struct task_struct *tsk, struct 
audit_fsnotify_mark *mark);
 
 #else
 #define audit_put_watch(w) {}
@@ -292,6 +294,8 @@ extern int audit_mark_compare(struct audit_fsnotify_mark 
*mark, unsigned long in
 #define audit_remove_mark(m)
 #define audit_remove_mark_rule(k)
 #define audit_mark_compare(m, i, d) 0
+#define audit_exe_compare(t, m) (-EINVAL)
+#define audit_dupe_exe(n, o) (-EINVAL)
 #endif /* CONFIG_AUDIT_WATCH */
 
 #ifdef CONFIG_AUDIT_TREE
diff --git a/kernel/audit_tree.c b/kernel/audit_tree.c
index b0f9877..94ecdab 100644
--- a/kernel/audit_tree.c
+++ b/kernel/audit_tree.c
@@ -479,6 +479,8 @@ static void kill_rules(struct audit_tree *tree)
if (rule->tree) {
/* not a half-baked one */
audit_tree_log_remove_rule(rule);
+   if (entry->rule.exe)
+   audit_remove_mark(entry->rule.exe);
rule->tree = NULL;
list_del_rcu(&entry->list);
list_del(&entry->rule.list);
diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index c668bfc..1255dbf 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -312,6 +312,8 @@ static void audit_update_watch(struct audit_parent *parent,
list_replace(&oentry->rule.list,
 &nentry->rule.list);
}
+   if (oentry->rule.exe)
+   audit_remove

Re: [PATCH v3 1/8] i2c: core: Add support for best effort block read emulation

[Wolfram Sang]

> > I wonder what devices do if you do a word read beyond their end address?
> > Perhaps in odd cases we should always fall back to byte reads?
> 
> In my tests I can read beyond the end address, but I cannot be sure if this 
> is OK for all
> devices. This was actually a suggestion from Wolfram for v1, but maybe I'm 
> missing
> something.
> 
> Wolfram, is it safe to read one byte beyond the end address or should I 
> better use
> only byte reads for odd lengths?

Well, from a device perspective, it is probably better to be safe than
sorry and fall back to a single byte read. That means, however, that we
need READ_WORD_DATA and READ_BYTE_DATA to be supported by the adapter.
Should be OK, I don't think there are adapters which can only read words.

> > > + */
> > > +s32 i2c_smbus_read_i2c_block_data_or_emulated(const struct i2c_client 
> > > *client,
> > > +   u8 command, u8 length, u8 *values)
> > > +{
> > > + u8 i;
> > > + int status;
> > > +
> > > + if (length > I2C_SMBUS_BLOCK_MAX)
> > > + length = I2C_SMBUS_BLOCK_MAX;
> > > +
> > > + if (i2c_check_functionality(client->adapter,
> > > + I2C_FUNC_SMBUS_READ_I2C_BLOCK)) {
> > > + return i2c_smbus_read_i2c_block_data(client, command,
> > > +  length, values);

I am not very strict with the 80 char limit. I'd think the code is more
readable if the two statements above would be oneliners. And for some
other lines later as well.

> > > + } else if (i2c_check_functionality(client->adapter,

No need for else since we return in the above if anyhow.

> > > +I2C_FUNC_SMBUS_READ_WORD_DATA)) {
> > > + for (i = 0; i < length; i += 2) {
> > > + status = i2c_smbus_read_word_data(client, command + i);
> > > + if (status < 0)
> > > + return status;
> > > + values[i] = status & 0xff;
> > > + if ((i + 1) < length)
> > > + values[i + 1] = status >> 8;
> > > + }
> > > + if (i > length)
> > > + return length;
> > > + return i;
> > > + } else if (i2c_check_functionality(client->adapter,
> > > +I2C_FUNC_SMBUS_READ_BYTE_DATA)) {
> > > + for (i = 0; i < length; i++) {
> > > + status = i2c_smbus_read_byte_data(client, command + i);
> > > + if (status < 0)
> > > + return status;
> > > + values[i] = status;
> > > + }
> > > + return i;
> > > + }
> > > +
> > > + dev_err(&client->adapter->dev, "Unsupported transactions: %d,%d,%d\n",
> > > + I2C_SMBUS_I2C_BLOCK_DATA, I2C_SMBUS_WORD_DATA,
> > > + I2C_SMBUS_BYTE_DATA);

I don't think the %d printouts are useful. Just say that the adapter
lacks support for needed transactions. And I think the device which
reports the error should be the client device, no?

Thanks,

   Wolfram



signature.asc
Description: Digital signature

Re: [PATCH v3 2/8] eeprom: at24: use i2c_smbus_read_i2c_block_data_or_emulated

[Wolfram Sang]

> + if (at24->use_smbus) {
> + status =
> + i2c_smbus_read_i2c_block_data_or_emulated(client,
> +   offset,
> +   count,
> +   buf);

Please ignore checkpatch warnings for this one and find a nice readable
way to squeeze that into two lines.



signature.asc
Description: Digital signature