[PATCH] KVM: x86: Remove redundant and incorrect cpl check on task-switch

[Nadav Amit]

Task-switch emulation checks the privilage level prior to performing the
task-switch.  This check is incorrect in the case of task-gates, in which the
tss.dpl is ignored, and can cause superfluous exceptions.  Moreover this check
is unnecassary, since the CPU checks the privilage levels prior to exiting.
Intel SDM 25.4.2 says "If CALL or JMP accesses a TSS descriptor directly
outside IA-32e mode, privilege levels are checked on the TSS descriptor" prior
to exiting.  AMD 15.14.1 says "The intercept is checked before the task switch
takes place but after the incoming TSS and task gate (if one was involved) have
been checked for correctness."

This patch removes the CPL checks for CALL and JMP.

Signed-off-by: Nadav Amit 
---
 arch/x86/kvm/emulate.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 56657b0..a9b2bd6 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -2698,7 +2698,8 @@ static int emulator_do_task_switch(struct 
x86_emulate_ctxt *ctxt,
 *
 * 1. jmp/call/int to task gate: Check against DPL of the task gate
 * 2. Exception/IRQ/iret: No check is performed
-* 3. jmp/call to TSS: Check against DPL of the TSS
+* 3. jmp/call to TSS/task-gate: No check is performed since the
+*hardware checks it before exiting.
 */
if (reason == TASK_SWITCH_GATE) {
if (idt_index != -1) {
@@ -2715,13 +2716,8 @@ static int emulator_do_task_switch(struct 
x86_emulate_ctxt *ctxt,
if ((tss_selector & 3) > dpl || ops->cpl(ctxt) > dpl)
return emulate_gp(ctxt, (idt_index << 3) | 0x2);
}
-   } else if (reason != TASK_SWITCH_IRET) {
-   int dpl = next_tss_desc.dpl;
-   if ((tss_selector & 3) > dpl || ops->cpl(ctxt) > dpl)
-   return emulate_gp(ctxt, tss_selector);
}
 
-
desc_limit = desc_limit_scaled(&next_tss_desc);
if (!next_tss_desc.p ||
((desc_limit < 0x67 && (next_tss_desc.type & 8)) ||
-- 
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: [RFC PATCH v1 13/70] x86, x2apic_cluster: _FROZEN Cleanup

[Chen, Gong]

On Wed, Jul 23, 2014 at 10:36:28PM +0200, Borislav Petkov wrote:
>   /*
>* At CPU state changes, update the x2apic cluster sibling info.
>*/
> @@ -151,9 +166,14 @@ static int
>  update_clusterinfo(struct notifier_block *nfb, unsigned long action, void 
> *hcpu)
>  {
>   unsigned int this_cpu = (unsigned long)hcpu;
> - unsigned int cpu;
>   int err = 0;
>  
> + if (action & CPU_TASKS_FROZEN) {
> + if ((action & ~CPU_TASKS_FROZEN) == CPU_UP_CANCELED)
> + __update_clusterinfo(this_cpu);
> + return NOTIFY_OK;
> + }
> +
Hi, Boris

Here you assume once the action contains FROZEN flag, it will return
NOTIFY_OK. It looks like not quite comply with original logic. Once
new FROZEN logic is added, we have to update this code again. How
about using following code snippet:

+   if ((action & CPU_TASKS_FROZEN) &&
+   ((action & ~CPU_TASKS_FROZEN) == CPU_UP_CANCELED)) {
+   __update_clusterinfo(this_cpu);
+   return NOTIFY_OK;
+   }
+



signature.asc
Description: Digital signature

Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

[Jakub Jelinek]

On Tue, Jul 29, 2014 at 06:49:09PM -0700, Greg Kroah-Hartman wrote:
> 3.15-stable review patch.  If anyone has any objections, please let me know.

IMNSHO this is a too big hammer approach.  The bug happened on a single
file only (right?), so if anything, IMHO it could be disabled for that
single file only, and better do it only for compilers with the bug.
If there are wrong code bugs with -O2 (we've fixed many in the past), you
also don't turn off -O2 everywhere, similarly for -Os or any other options.
Disabling it just in case the same bug happens elsewhere when it actually
took 5 years before the bug caused miscompilation of something is too
defensive.  We had at least 15 other wrong-code bugfixes just in between
4.9.0 and 4.9.1.  -fvar-tracking-assignments doesn't make a small difference
in debug info, but significant for optimized code.
If you build the kernel without and with -fno-var-tracking-assignments,
you can use e.g. the dwlocstat tool to see what kind of difference it makes
for the kernel in particular in variable debug info coverage.
> 
> --- a/Makefile
> +++ b/Makefile
> @@ -669,6 +669,8 @@ KBUILD_CFLAGS += -fomit-frame-pointer
>  endif
>  endif
>  
> +KBUILD_CFLAGS   += $(call cc-option, -fno-var-tracking-assignments)
> +
>  ifdef CONFIG_DEBUG_INFO
>  KBUILD_CFLAGS+= -g
>  KBUILD_AFLAGS+= -Wa,--gdwarf-2
> 

Jakub
--
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] f2fs: remove redundant lines in allocate_data_block

[Dongho Sim]

There are redundant lines in allocate_data_block.

In this function, we call refresh_sit_entry with old seg and old curseg.
After that, we call locate_dirty_segment with old curseg.

But, the new address is always allocated from old curseg and
we call locate_dirty_segment with old curseg in refresh_sit_entry.
So, we do not need to call locate_dirty_segment with old curseg again.

We've discussed like below:

Jaegeuk said:
 "When considering SSR, we need to take care of the following scenario.
  - old segno : X
  - new address : Z
  - old curseg : Y
  This means, a new block is supposed to be written to Z from X.
  And Z is newly allocated in the same path from Y.

  In that case, we should trigger locate_dirty_segment for Y, since
  it was a current_segment and can be dirty owing to SSR.
  But that was not included in the dirty list."

Changman said:
 "We already choosed old curseg(Y) and then we allocate new address(Z) from old
  curseg(Y). After that we call refresh_sit_entry(old address, new address).
  In the funcation, we call locate_dirty_segment with old seg and old curseg.
  So calling locate_dirty_segment after refresh_sit_entry again is redundant."

Jaegeuk said:
 "Right. The new address is always allocated from old_curseg."

Signed-off-by: Dongho Sim 
---
 fs/f2fs/segment.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 8a6e57d..7af4a8d 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -973,14 +973,12 @@ void allocate_data_block(struct f2fs_sb_info *sbi, struct 
page *page,
 {
struct sit_info *sit_i = SIT_I(sbi);
struct curseg_info *curseg;
-   unsigned int old_cursegno;
 
curseg = CURSEG_I(sbi, type);
 
mutex_lock(&curseg->curseg_mutex);
 
*new_blkaddr = NEXT_FREE_BLKADDR(sbi, curseg);
-   old_cursegno = curseg->segno;
 
/*
 * __add_sum_entry should be resided under the curseg_mutex
@@ -1001,7 +999,6 @@ void allocate_data_block(struct f2fs_sb_info *sbi, struct 
page *page,
 * since SSR needs latest valid block information.
 */
refresh_sit_entry(sbi, old_blkaddr, *new_blkaddr);
-   locate_dirty_segment(sbi, old_cursegno);
 
mutex_unlock(&sit_i->sentry_lock);
 
-- 
1.9.1

Re: [PATCH RFC tip/core/rcu 1/9] rcu: Add call_rcu_tasks()

[Lai Jiangshan]

On 07/29/2014 06:56 AM, Paul E. McKenney wrote:

> + /*
> +  * Each pass through the following loop scans the list
> +  * of holdout tasks, removing any that are no longer
> +  * holdouts.  When the list is empty, we are done.
> +  */
> + while (!list_empty(&rcu_tasks_holdouts)) {
> + schedule_timeout_interruptible(HZ / 10);
> + flush_signals(current);
> + rcu_read_lock();
> + list_for_each_entry_rcu(t, &rcu_tasks_holdouts,
> + rcu_tasks_holdout_list) {
> + if (smp_load_acquire(&t->rcu_tasks_holdout))
> + continue;
> + list_del_init(&t->rcu_tasks_holdout_list);
> + /* @@@ need to check for usermode on CPU. */
> + }
> + rcu_read_unlock();

Maybe I missed something. The task @t may already exited and we access to
the stale memory here if without patch 8/9.
--
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] PM / sleep: Rename symbols, functions and variables related to sleep

[Pavel Machek]

On Wed 2014-07-30 01:41:25, Rafael J. Wysocki wrote:
> On Monday, July 28, 2014 01:13:56 AM Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki 
> > 
> > The names of several symbols, data types, functions and variables
> > related to system sleep states are confusing and don't reflect the
> > real behavior of those states correctly.
> > 
> > First of all, there generally are two sleep states that require
> > platform support and one sleep state that is platform-independent.
> > The first two of them are currently known as MEM and STANDBY,
> > although these names really only match what the states do on full
> > hardware ACPI compliant systems.  MEM in particular is supposed
> > to mean "suspend-to-RAM", but in fact it means "the deepest sleep
> > state available with platform support".  The definition of STANDBY
> > is even more arbitrary.
> > 
> > Moreover, the remaining sleep state that doesn't need platform support
> > is currently called FREEZE, which leads to double confusion with the
> > process freezer (used during transitions to all sleep states) and
> > with the freeze stage of processing devices during hibernation.
> > 
> > For these reasons, rename the PM_SUSPEND_MEM, PM_SUSPEND_STANDBY
> > and PM_SUSPEND_FREEZE symbols to PM_SUSPEND_PLATFORM_DEEP,
> > PM_SUSPEND_PLATFORM_SHALLOW and PM_SUSPEND_IDLE_SLEEP, respectively,
> > everywhere and rename data types, functions and variables related to
> > those states to match the new names of the symbols.
> > 
> > This is a semi-mechanical replacement of names and it should not lead
> > to any functional differences.
> > 
> > Signed-off-by: Rafael J. Wysocki 
> 
> OK, any comments or objections anyone?
> 
> Or should I just make it a non-RFC and apply it?

I don't really like the new names, and I'm not sure if I like
direction this is heading. At least on ACPI machines, S1 and S3 is
different -- different parts of hardware will stay powered on.

So if you want to charge your cellphone with machine suspended, you
want S1... and you don't want S1/S3 to change names. (Ok, this is not
what you are doing now, but what you plan AFAICT.)

> > For these reasons, rename the PM_SUSPEND_MEM, PM_SUSPEND_STANDBY
> > and PM_SUSPEND_FREEZE symbols to PM_SUSPEND_PLATFORM_DEEP,
> > PM_SUSPEND_PLATFORM_SHALLOW and PM_SUSPEND_IDLE_SLEEP, respectively,

I'm not sure why you want to mention "platform there", AFAICT better
names would be

PM_SUSPEND_DEEP, PM_SUSPEND_SHALLOW, PM_IDLE_SLEEP.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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] video: fbdev: intelfb: intelfb_i2c.c: Cleaning up variable that is never used

[Pavel Machek]

On Sat 2014-07-05 14:24:08, Rickard Strandqvist wrote:
> From: Rickard Strandqvist 
> 
> Variable ar assigned a value that is never used.
> I have also removed all the code that thereby serves no purpose.
> 
> This was found using a static code analysis program called cppcheck

Are you sure this is the right fix?

Do we need to read the register in case we don't care about return
value?


> index 3300bd3..4df2f1f 100644
> --- a/drivers/video/fbdev/intelfb/intelfb_i2c.c
> +++ b/drivers/video/fbdev/intelfb/intelfb_i2c.c
> @@ -55,22 +55,20 @@ static void intelfb_gpio_setscl(void *data, int state)
>  {
>   struct intelfb_i2c_chan *chan = data;
>   struct intelfb_info *dinfo = chan->dinfo;
> - u32 val;
>  
>   OUTREG(chan->reg, (state ? SCL_VAL_OUT : 0) |
>  SCL_DIR | SCL_DIR_MASK | SCL_VAL_MASK);
> - val = INREG(chan->reg);
> + INREG(chan->reg);
>  }

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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 0/2] usb: fix controller-PHY binding for OMAP3 platform

[Tony Lindgren]

* Felipe Balbi  [140729 09:42]:
> Hi,
> 
> On Tue, Jul 29, 2014 at 02:38:24PM +0200, Laurent Pinchart wrote:
> > On Wednesday 23 July 2014 14:29:36 Kishon Vijay Abraham I wrote:
> > > On Monday 21 July 2014 08:45 PM, Felipe Balbi wrote:
> > > > On Mon, Jul 21, 2014 at 05:04:57PM +0200, Laurent Pinchart wrote:
> > > >> Hi Felipe,
> > > >> 
> > > >> What happened to these two patches ?
> > > > 
> > > > looks like I lost them.
> > > > 
> > > >> On Monday 16 December 2013 17:48:29 Felipe Balbi wrote:
> > > >>> On Mon, Dec 16, 2013 at 02:38:27PM -0800, Tony Lindgren wrote:
> > >  * Felipe Balbi  [131216 13:31]:
> > > > On Mon, Dec 16, 2013 at 09:23:43PM +0530, Kishon Vijay Abraham I 
> > wrote:
> > > >> After the platform devices are created using PLATFORM_DEVID_AUTO, 
> > > >> the
> > > >> device names given in usb_bind_phy (in board file) does not match
> > > >> with the actual device name causing the USB PHY library not to 
> > > >> return
> > > >> the PHY reference when the MUSB controller request for the PHY in 
> > > >> the
> > > >> non-dt boot case.
> > > >> So removed creating platform devices using PLATFORM_DEVID_AUTO in
> > > >> omap2430.c.
> > > >> 
> > > >> Did enumeration testing in omap3 beagle.
> > > >> 
> > > >> Changes from v2:
> > > >> * Fixed the commit log
> > > >> 
> > > >> Changes from v1:
> > > >> * refreshed to the latested mainline kernel
> > > >> * added musb_put_id from omap2430 remove.
> > > > 
> > > > Tony, how do you want to handle this ? You want me to provide you a
> > > > branch which we both merge ?
> > >  
> > >  Yes that would be great thanks. For the mach-omap2 touching parts:
> > >  
> > >  Acked-by: Tony Lindgren 
> > > >>> 
> > > >>> Here it is, let me know if you prefer a signed tag:
> > > >>> 
> > > >>> The following changes since commit 
> > 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
> > > >>>   Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
> > > >>> 
> > > >>> are available in the git repository at:
> > > >>>   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
> > > >>> 
> > > >>> usb-phy-binding-omap3
> > > >>> 
> > > >>> for you to fetch changes up to 
> > > >>> 23ada3130cf4e56acb86fdff4c26113188d52d18:
> > > >>>   arm: omap: remove *.auto* from device names given in usb_bind_phy
> > > >>> 
> > > >>> (2013-12-16 17:44:43 -0600)
> > > >>> 
> > > >>> 
> > > >>> 
> > > >>> Kishon Vijay Abraham I (2):
> > > >>>   usb: musb: omap: remove using PLATFORM_DEVID_AUTO in omap2430.c
> > > >>>   arm: omap: remove *.auto* from device names given in 
> > > >>> usb_bind_phy
> > > > 
> > > > Kishon, are these still valid ?
> > > 
> > > Looks like board-2430sdp.c got removed. Apart from that the reset of the
> > > patch series is still applicable for non-dt boot.
> > 
> > Felipe, do you plan to apply the patch without the baord-2430sdp.c change, 
> > or 
> > would you like Kishon to rebase and resubmit it ?
> 
> Not sure if Tony still wants board-* modifications. Tony ?

Well omap2 is DT only already, so sounds like you can just ignore
board-2430sdp.c as it no longer exists.

If there are other minimal board-*.c file changes needed, then that's
fine as long as they fix things or are needed to keep things working.

Regards,

Tony

--
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 00/11] Refactor MSI to support Non-PCI device

[Jiang Liu]

On 2014/7/30 10:45, Yijing Wang wrote:
> On 2014/7/29 22:08, Arnd Bergmann wrote:
>> On Saturday 26 July 2014 11:08:37 Yijing Wang wrote:
>>> The series is a draft of generic MSI driver that supports PCI
>>> and Non-PCI device which have MSI capability. If you're not interested
>>> it, sorry for the noise.
>>
>> I've finally managed to take some time to look at the series. Overall,
>> the concept looks good to me, and the patches look very well implemented.
>>
>> The part I'm not sure about is the interface we want to end up with
>> at the end of the series. More on that below
> 
> Hi Arnd,
>Thanks for your review and comments very much!
> Please refer the inline comments.
> 
>>
>>> The series is based on Linux-3.16-rc1.
>>>
>>> MSI was introduced in PCI Spec 2.2. Currently, kernel MSI 
>>> driver codes are bonding with PCI device. Because MSI has a lot
>>> advantages in design. More and more non-PCI devices want to
>>> use MSI as their default interrupt. The existing MSI device
>>> include HPET. HPET driver provide its own MSI code to initialize
>>> and process MSI interrupts. In the latest GIC v3 spec, legacy device
>>> can deliver MSI by the help of a relay device named consolidator.
>>> Consolidator can translate the legacy interrupts connected to it
>>> to MSI/MSI-X. And new non-PCI device will be designed to 
>>> support MSI in future. So make the MSI driver code be generic will 
>>> help the non-PCI device use MSI more simply.
>>>
>>> The new data struct for generic MSI driver.
>>> struct msi_irqs {
>>> u8 msi_enabled:1; /* Enable flag */
>>> u8 msix_enabled:1;
>>> struct list_head msi_list; /* MSI desc list */
>>> void *data; /* help to find the MSI device */
>>> struct msi_ops *ops; /* MSI device specific hook */
>>> };
>>> struct msi_irqs is used to manage MSI related informations. Every device 
>>> supports
>>> MSI should contain this data struct and allocate it.
>>
>> I think you should have a stronger association with the 'struct
>> device' here. Can you replace the 'void *data' with 'struct device *dev'?
> 
> Actually, I used the struct device *dev in my first draft, finally, I replaced
> it with void *data, because some MSI devices don't have a struct device *dev,
> like the existing hpet device, dmar msi device, and OF device, like the ARM 
> consolidator.
> 
> Of course, we can make the MSI devices have their own struct device, and 
> register to
> device tree, eg, add a class device named MSI_DEV. But I'm not sure whether 
> it is appropriate.
> 
>>
>> The other part I'm not completely sure about is how you want to
>> have MSIs map into normal IRQ descriptors. At the moment, all
>> MSI users are based on IRQ numbers, but this has known scalability problems.
> 
> Hmmm, I still use the IRQ number to map the MSIs to IRQ description.
> I'm sorry, I don't understand you meaning.
> What are the scalability problems you mentioned ?
We have soft limitation of nr_irqs or hard limitation NR_IRQS,
we couldn't allocate as much irq number as we need in some cases,
such as to support MSI-x.

> For device drivers, they always process interrupt in two steps.
> If irq is the legacy interrupt, drivers will first
> use the irq_of_parse_and_map() or pci_enable_device() to parse and get the 
> IRQ number.
> Then drivers will call the request_irq() to register the interrupt handler.
> If irq is MSIs, first call pci_enable_msi/x() to get the IRQ number and then 
> call
> request_irq() to register interrupt handler.
> 
>> I wonder if we can do the interface in a way that
>> hides the interrupt number from generic device drivers and just
>> passes a 'struct irq_desc'. Note that there are long-term plans to
>> get rid of IRQ numbers entirely, but those plans have existed for
>> a long time already without anybody seriously addressing the device
>> driver interfaces so far, so it might never really happen.
>>
> 
> Maybe this is a huge work, now hundreds drivers use the IRQ number, so maybe 
> we can consider
> this in a separate title.
> 
>>> struct msi_ops {
>>> struct msi_desc *(*msi_setup_entry)(struct msi_irqs *msi, struct 
>>> msi_desc *entry);
>>> int msix_setup_entries(struct msi_irqs *msi, struct msix_entry 
>>> *entries);
>>> u32 (*msi_mask_irq)(struct msi_desc *desc, u32 mask, u32 flag);
>>> u32 (*msix_mask_irq)(struct msi_desc *desc, u32 flag);
>>> void (*msi_read_message)(struct msi_desc *desc, struct msi_msg 
>>> *msg);
>>> void (*msi_write_message)(struct msi_desc *desc, struct msi_msg 
>>> *msg);
>>> void (*msi_set_intx)(struct msi_irqs *msi, int enable);
>>> };
>>> struct msi_ops provides several hook functions, generic MSI driver will call
>>> the hook functions to access device specific registers. PCI devices will 
>>> share
>>> the same msi_ops, because they have the same way to access MSI hardware 
>>> registers.
>>>
>>> Generic MSI layer export msi_capability_init() and msix_capabil

Re: [PATCH v2 05/29] nios2: Memory management

[Ley Foon Tan]

On Mon, Jul 28, 2014 at 10:59 PM, Geert Uytterhoeven
 wrote:
> On Tue, Jul 15, 2014 at 10:45 AM, Ley Foon Tan  wrote:
>> --- /dev/null
>> +++ b/arch/nios2/include/asm/mmu.h
>> @@ -0,0 +1,18 @@
>> +/*
>> + * Copyright (C) 2010 Tobias Klauser 
>> + * Copyright (C) 2004 Microtronix Datacom Ltd.
>> + *
>> + * Taken from m68knommu.
>> + *
>> + * This file is subject to the terms and conditions of the GNU General 
>> Public
>> + * License. See the file "COPYING" in the main directory of this archive
>> + * for more details.
>> + */
>> +
>> +#ifndef _ASM_NIOS2_MMU_H
>> +#define _ASM_NIOS2_MMU_H
>> +
>> +/* Default "unsigned long" context */
>> +typedef unsigned long mm_context_t;
>> +
>> +#endif /* _ASM_NIOS2_MMU_H */
>
> Any chance you can use mmu.h from asm-generic instead?
> It uses a struct with a single "unsigned long end_brk" member (unless
> CONFIG_BINFMT_ELF_FDPIC is defined).
>From asm-generic/mmu.h, it is for nommu implementations.
So, I will keep this as it is now.

Thanks.

Regards
Ley Foon
--
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/2 v4] sched: Rewrite per entity runnable load average tracking

[Yuyang Du]

On Tue, Jul 29, 2014 at 03:17:29PM +0200, Vincent Guittot wrote:
> >>
> >> IMHO, we should apply the same policy than the one i mentioned for
> >> task. So the load_avg of an entity or a cfs_rq will not be disturbed
> >> by an old but no more valid weight
> >>
> >
> > Well, I see your point. But the problem is what matters is load_avg vs. 
> > load_avg, not a
> > load_avg itself. So, if load_avg1 discards old weight if weight is changed, 
> > but load_avg2
> > has no weight changed or has weight changed, the comparison load_avg1 vs. 
> > load_avg2 is not
> > fair, but too impacted by the new weight. The point is, we count in 
> > history, so connt in the
> > real history, which is the whole point of why we count the history. Make 
> > sense?
> 
> IIUC, you want to soften the impact of weight change on cfs_rq-> load_avg ?
> 

Yes, that would be the effect.

Isn't the entire effort starting from PJT and Ben up to now to soften the 
extremely
dynamic changes (runnable or not, weight change, etc)? Assume task does not 
change
weight much, but group entity does as Peter mentioned.

--
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] ASoC: max98090 not need to return fail if fail to request hpdet irq.

[Jarkko Nikula]

On 07/30/2014 04:50 AM, jianqun wrote:

From: xujianqun 

Since hardware may not MUST to use IRQ pin of max98090 as jack detect, the
driver can work well without it, can report jack trigger to CPU by a GPIO.

But here driver will register fail caused by failed to request irq.

Signed-off-by: xujianqun 
---
  sound/soc/codecs/max98090.c |2 ++
  1 file changed, 2 insertions(+)

diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
index 566919c..bc124ff 100644
--- a/sound/soc/codecs/max98090.c
+++ b/sound/soc/codecs/max98090.c
@@ -2515,6 +2515,8 @@ static int max98090_probe(struct snd_soc_codec *codec)
  
  	max98090_add_widgets(codec);
  
+	return 0;

+
  err_access:
return ret;
  }
I would say it's better to call request_threaded_irq() conditionally 
when max98090->irq is valid in the same max98090_probe(). Also code 
should return instantly in case of request_threaded_irq() fails for 
valid irq.


Now code is still printing needless error message in case max98090->irq 
is invalid or not specified and continue probing in case 
request_threaded_irq() fails for valid irq.


--
Jarkko
--
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] scsi: qla4xxx: ql4_mbx.c: Cleaning up missing null-terminate in conjunction with strncpy

[Nilesh Javali]

Acked-By: Nilesh Javali 


-Original Message-
From: Rickard Strandqvist [mailto:rickard_strandqv...@spectrumdigital.se] 
Sent: Sunday, July 27, 2014 8:28 PM
To: Vikas Chaudhary; Dept-Eng iSCSI Driver
Cc: Rickard Strandqvist; James E.J. Bottomley; linux-scsi; linux-kernel
Subject: [PATCH] scsi: qla4xxx: ql4_mbx.c: Cleaning up missing null-terminate 
in conjunction with strncpy

Replacing strncpy with strlcpy to avoid strings that lacks null terminate.
And in some cases modified to copy one character less than the overall length, 
as the entire area is already zeroed.

Signed-off-by: Rickard Strandqvist 
---
 drivers/scsi/qla4xxx/ql4_mbx.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/qla4xxx/ql4_mbx.c b/drivers/scsi/qla4xxx/ql4_mbx.c 
index 0a3312c..2b2756e 100644
--- a/drivers/scsi/qla4xxx/ql4_mbx.c
+++ b/drivers/scsi/qla4xxx/ql4_mbx.c
@@ -1620,8 +1620,8 @@ int qla4xxx_get_chap(struct scsi_qla_host *ha, char 
*username, char *password,
goto exit_get_chap;
}
 
-   strncpy(password, chap_table->secret, QL4_CHAP_MAX_SECRET_LEN);
-   strncpy(username, chap_table->name, QL4_CHAP_MAX_NAME_LEN);
+   strlcpy(password, chap_table->secret, QL4_CHAP_MAX_SECRET_LEN);
+   strlcpy(username, chap_table->name, QL4_CHAP_MAX_NAME_LEN);
chap_table->cookie = __constant_cpu_to_le16(CHAP_VALID_COOKIE);
 
 exit_get_chap:
@@ -1663,8 +1663,8 @@ int qla4xxx_set_chap(struct scsi_qla_host *ha, char 
*username, char *password,
else
chap_table->flags |= BIT_7; /* local */
chap_table->secret_len = strlen(password);
-   strncpy(chap_table->secret, password, MAX_CHAP_SECRET_LEN);
-   strncpy(chap_table->name, username, MAX_CHAP_NAME_LEN);
+   strncpy(chap_table->secret, password, MAX_CHAP_SECRET_LEN - 1);
+   strncpy(chap_table->name, username, MAX_CHAP_NAME_LEN - 1);
chap_table->cookie = __constant_cpu_to_le16(CHAP_VALID_COOKIE);
 
if (is_qla40XX(ha)) {
@@ -1742,8 +1742,8 @@ int qla4xxx_get_uni_chap_at_index(struct scsi_qla_host 
*ha, char *username,
goto exit_unlock_uni_chap;
}
 
-   strncpy(password, chap_table->secret, MAX_CHAP_SECRET_LEN);
-   strncpy(username, chap_table->name, MAX_CHAP_NAME_LEN);
+   strlcpy(password, chap_table->secret, MAX_CHAP_SECRET_LEN);
+   strlcpy(username, chap_table->name, MAX_CHAP_NAME_LEN);
 
rval = QLA_SUCCESS;
 
@@ -2295,7 +2295,7 @@ int qla4_8xxx_set_param(struct scsi_qla_host *ha, int 
param)
if (param == SET_DRVR_VERSION) {
mbox_cmd[1] = SET_DRVR_VERSION;
strncpy((char *)&mbox_cmd[2], QLA4XXX_DRIVER_VERSION,
-   MAX_DRVR_VER_LEN);
+   MAX_DRVR_VER_LEN - 1);
} else {
ql4_printk(KERN_ERR, ha, "%s: invalid parameter 0x%x\n",
   __func__, param);
--
1.7.10.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: [RFC PATCHv2 00/11] Adding FreeBSD's Capsicum security framework

[Eric W. Biederman]

I have cut this down to just focus on O_BENEATH openat case.

David Drysdale  writes:

> On Mon, Jul 28, 2014 at 10:13 PM, Eric W. Biederman
>  wrote:

>> Nope.  What you can implement today if you want fine grained limitations
>> like this is to create a mount namespace with exactly the subdirectory
>> tree you want to allow access to and to return a file descriptor that
>> points into that mount namespace.  (When complete the only user of that
>> mount namespace would be your file descriptor).
>
> How does that solve the particular example I mentioned?  The DFD
> within the mount namespace will still allow any operation on any file
> that's already in the subdirectory -- or am I misunderstanding
> something?

The goal was to bound the DFD to the directory and all of it's
subdirectories such that openat(dfd, "../../..") would open
the dfd, and that further opens of other directories would also not
allow you to escape.

Since the mount namespace only contains the choosen directory and it's
subdirectories that works easily and trivially.

So while you can indeed perform any file operation on that dfd who
cares because none of those operations can get you anywhere you aren't
supposed to be.

My point was that you can as granular as you would like by binding a dfd
to a mount namespace instead of binding a process to a mount namespace,
and the code already exists and is being maintained.

So while things are not packaged in the form that has been requested it
looks to me as if the functionality for directories already exists
within the Linux kernel.

Eric
--
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] scsi: qla4xxx: ql4_os.c: Cleaning up missing null-terminate in conjunction with strncpy

[Nilesh Javali]

Acked-By: Nilesh Javali 


-Original Message-
From: Rickard Strandqvist [mailto:rickard_strandqv...@spectrumdigital.se] 
Sent: Saturday, July 26, 2014 8:20 PM
To: Vikas Chaudhary; Dept-Eng iSCSI Driver
Cc: Rickard Strandqvist; James E.J. Bottomley; linux-scsi; linux-kernel
Subject: [PATCH] scsi: qla4xxx: ql4_os.c: Cleaning up missing null-terminate in 
conjunction with strncpy

Replacing strncpy with strlcpy to avoid strings that lacks null terminate.

Signed-off-by: Rickard Strandqvist 
---
 drivers/scsi/qla4xxx/ql4_os.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c 
index 3202063..a07c53e 100644
--- a/drivers/scsi/qla4xxx/ql4_os.c
+++ b/drivers/scsi/qla4xxx/ql4_os.c
@@ -756,9 +756,9 @@ static int qla4xxx_get_chap_list(struct Scsi_Host *shost, 
uint16_t chap_tbl_idx,
continue;
 
chap_rec->chap_tbl_idx = i;
-   strncpy(chap_rec->username, chap_table->name,
+   strlcpy(chap_rec->username, chap_table->name,
ISCSI_CHAP_AUTH_NAME_MAX_LEN);
-   strncpy(chap_rec->password, chap_table->secret,
+   strlcpy(chap_rec->password, chap_table->secret,
QL4_CHAP_MAX_SECRET_LEN);
chap_rec->password_length = chap_table->secret_len;
 
@@ -6027,8 +6027,8 @@ static int qla4xxx_get_bidi_chap(struct scsi_qla_host 
*ha, char *username,
if (!(chap_table->flags & BIT_6)) /* Not BIDI */
continue;
 
-   strncpy(password, chap_table->secret, QL4_CHAP_MAX_SECRET_LEN);
-   strncpy(username, chap_table->name, QL4_CHAP_MAX_NAME_LEN);
+   strlcpy(password, chap_table->secret, QL4_CHAP_MAX_SECRET_LEN);
+   strlcpy(username, chap_table->name, QL4_CHAP_MAX_NAME_LEN);
ret = 0;
break;
}
@@ -6258,8 +6258,8 @@ static void qla4xxx_get_param_ddb(struct ddb_entry 
*ddb_entry,
 
tddb->tpgt = sess->tpgt;
tddb->port = conn->persistent_port;
-   strncpy(tddb->iscsi_name, sess->targetname, ISCSI_NAME_SIZE);
-   strncpy(tddb->ip_addr, conn->persistent_address, DDB_IPADDR_LEN);
+   strlcpy(tddb->iscsi_name, sess->targetname, ISCSI_NAME_SIZE);
+   strlcpy(tddb->ip_addr, conn->persistent_address, DDB_IPADDR_LEN);
 }
 
 static void qla4xxx_convert_param_ddb(struct dev_db_entry *fw_ddb_entry, @@ 
-7764,7 +7764,7 @@ static int qla4xxx_sysfs_ddb_logout(struct 
iscsi_bus_flash_session *fnode_sess,
goto exit_ddb_logout;
}
 
-   strncpy(flash_tddb->iscsi_name, fnode_sess->targetname,
+   strlcpy(flash_tddb->iscsi_name, fnode_sess->targetname,
ISCSI_NAME_SIZE);
 
if (!strncmp(fnode_sess->portal_type, PORTAL_TYPE_IPV6, 4))
--
1.7.10.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/

ACPI/cpu hotplug: possible lockdep

[Gu Zheng]

Hi Rafael,
A lockdep warning occurs when hot removing a cpu via sysfs:
echo 1 > /sys/bus/acpi/devices/LNXCPU\:02/eject
The kernel is latest upstream, and the test box is a kvm vm,
detail info as following.

[  221.755113] ==
[  221.756189] [ INFO: possible circular locking dependency detected ]
[  221.756189] 3.16.0-rc7+ #118 Not tainted
[  221.756189] ---
[  221.756189] kworker/u8:3/62 is trying to acquire lock:
[  221.756189]  (s_active#50){.+}, at: [] 
kernfs_remove_by_name_ns+0x70/0x8c
[  221.756189] 
[  221.756189] but task is already holding lock:
[  221.756189]  (cpu_hotplug.lock#2){+.+.+.}, at: [] 
cpu_hotplug_begin+0x4f/0x79
[  221.756189] 
[  221.756189] which lock already depends on the new lock.
[  221.756189] 
[  221.756189] 
[  221.756189] the existing dependency chain (in reverse order) is:
[  221.756189] 
-> #3 (cpu_hotplug.lock#2){+.+.+.}:
[  221.756189][] lock_acquire+0xdb/0x101
[  221.756189][] mutex_lock_nested+0x6d/0x37a
[  221.756189][] cpu_hotplug_begin+0x4f/0x79
[  221.756189][] _cpu_up+0x35/0x126
[  221.756189][] cpu_up+0x6f/0x81
[  221.756189][] smp_init+0x4e/0x89
[  221.756189][] kernel_init_freeable+0x13d/0x24b
[  221.756189][] kernel_init+0xe/0xdf
[  221.756189][] ret_from_fork+0x7c/0xb0
[  221.756189] 
-> #2 (cpu_hotplug.lock){++}:
[  221.756189][] lock_acquire+0xdb/0x101
[  221.756189][] cpu_hotplug_begin+0x41/0x79
[  221.756189][] _cpu_up+0x35/0x126
[  221.756189][] cpu_up+0x6f/0x81
[  221.756189][] smp_init+0x4e/0x89
[  221.756189][] kernel_init_freeable+0x13d/0x24b
[  221.819219][] kernel_init+0xe/0xdf
[  221.819219][] ret_from_fork+0x7c/0xb0
[  221.819219] 
[  221.819219] -> #1 (cpu_add_remove_lock){+.+.+.}:
[  221.819219][] lock_acquire+0xdb/0x101
[  221.819219][] _raw_spin_lock_irqsave+0x4d/0x87
[  221.819219][] __delete_object+0x8e/0xab
[  221.819219][] delete_object_full+0x22/0x2e
[  221.819219][] kmemleak_free+0x56/0x77
[  221.819219][] slab_free_hook+0x1e/0x5b
[  221.819219][] kfree+0xac/0x111
[  221.819219][] acpi_hotplug_work_fn+0x28/0x2d
[  221.819219][] process_one_work+0x207/0x375
[  221.819219][] worker_thread+0x2bd/0x329
[  221.819219][] kthread+0xba/0xc2
[  221.819219][] ret_from_fork+0x7c/0xb0
[  221.819219] 
[  221.819219] -> #0 (s_active#50){.+}:
[  221.819219][] __lock_acquire+0xb3b/0xe41
[  221.819219][] lock_acquire+0xdb/0x101
[  221.819219][] __kernfs_remove+0x169/0x2be
[  221.819219][] kernfs_remove_by_name_ns+0x70/0x8c
[  221.819219][] sysfs_remove_file_ns+0x15/0x17
[  221.819219][] device_remove_file+0x19/0x1b
[  221.819219][] device_remove_attrs+0x2e/0x68
[  221.819219][] device_del+0x128/0x187
[  221.819219][] device_unregister+0x48/0x54
[  221.819219][] unregister_cpu+0x39/0x55
[  221.819219][] arch_unregister_cpu+0x23/0x28
[  221.819219][] acpi_processor_remove+0x91/0xca
[  221.819219][] acpi_bus_trim+0x5a/0x8d
[  221.819219][] acpi_device_hotplug+0x301/0x3ff
[  221.819219][] acpi_hotplug_work_fn+0x20/0x2d
[  221.819219][] process_one_work+0x207/0x375
[  221.819219][] worker_thread+0x2bd/0x329
[  221.819219][] kthread+0xba/0xc2
[  221.819219][] ret_from_fork+0x7c/0xb0
[  221.819219] 
[  221.819219] other info that might help us debug this:
[  221.819219] 
[  221.819219] Chain exists of:
[  221.819219]   s_active#50 --> cpu_hotplug.lock --> cpu_hotplug.lock#2
[  221.819219] 
[  221.819219]  Possible unsafe locking scenario:
[  221.819219] 
[  221.819219]CPU0CPU1
[  221.819219]
[  221.819219]   lock(cpu_hotplug.lock#2);
[  221.819219]lock(cpu_hotplug.lock);
[  221.819219]lock(cpu_hotplug.lock#2);
[  221.819219]   lock(s_active#50);
[  221.819219] 
[  221.819219]  *** DEADLOCK ***
[  221.819219] 
[  221.819219] 7 locks held by kworker/u8:3/62:
[  221.819219]  #0:  ("kacpi_hotplug"){.+.+.+}, at: [] 
process_one_work+0x15f/0x375
[  221.819219]  #1:  ((&hpw->work)){+.+.+.}, at: [] 
process_one_work+0x15f/0x375
[  221.819219]  #2:  (device_hotplug_lock){+.+.+.}, at: [] 
lock_device_hotplug+0x17/0x19
[  221.819219]  #3:  (acpi_scan_lock){+.+.+.}, at: [] 
acpi_device_hotplug+0x2d/0x3ff
[  221.819219]  #4:  (cpu_add_remove_lock){+.+.+.}, at: [] 
cpu_maps_update_begin+0x17/0x19
[  221.819219]  #5:  (cpu_hotplug.lock){++}, at: [] 
cpu_hotplug_begin+0x5/0x79
[  221.819219]  #6:  (cpu_hotplug.lock#2){+.+.+.}, at: [] 
cpu_hotplug_begin+0x4f/0x79
[  221.819219] 
[  221.819219] stack backtrace:
[  221.819219] CPU: 1 PID: 62 Comm: kworker/u8:

Re: [RFC][PATCH] PM / sleep: Rename symbols, functions and variables related to sleep

[Zhang Rui]

On Wed, 2014-07-30 at 01:41 +0200, Rafael J. Wysocki wrote:
> On Monday, July 28, 2014 01:13:56 AM Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki 
> > 
> > The names of several symbols, data types, functions and variables
> > related to system sleep states are confusing and don't reflect the
> > real behavior of those states correctly.
> > 
> > First of all, there generally are two sleep states that require
> > platform support and one sleep state that is platform-independent.
> > The first two of them are currently known as MEM and STANDBY,
> > although these names really only match what the states do on full
> > hardware ACPI compliant systems.  MEM in particular is supposed
> > to mean "suspend-to-RAM", but in fact it means "the deepest sleep
> > state available with platform support".  The definition of STANDBY
> > is even more arbitrary.
> > 
> > Moreover, the remaining sleep state that doesn't need platform support
> > is currently called FREEZE, which leads to double confusion with the
> > process freezer (used during transitions to all sleep states) and
> > with the freeze stage of processing devices during hibernation.
> > 
> > For these reasons, rename the PM_SUSPEND_MEM, PM_SUSPEND_STANDBY
> > and PM_SUSPEND_FREEZE symbols to PM_SUSPEND_PLATFORM_DEEP,
> > PM_SUSPEND_PLATFORM_SHALLOW and PM_SUSPEND_IDLE_SLEEP, respectively,
> > everywhere and rename data types, functions and variables related to
> > those states to match the new names of the symbols.
> > 
> > This is a semi-mechanical replacement of names and it should not lead
> > to any functional differences.
> > 
> > Signed-off-by: Rafael J. Wysocki 
> 
> OK, any comments or objections anyone?
> 
> Or should I just make it a non-RFC and apply it?
> 
I'm okay with this patch.

Acked-by: Zhang Rui 

thanks,
rui
> Rafael
> 
> 
> > ---
> >  arch/arm/mach-at91/pm.c   |   10 +--
> >  arch/arm/mach-davinci/pm.c|6 +-
> >  arch/arm/mach-exynos/pm.c |2 
> >  arch/arm/mach-highbank/pm.c   |2 
> >  arch/arm/mach-imx/mach-mx31ads.c  |8 +--
> >  arch/arm/mach-imx/pm-imx27.c  |4 -
> >  arch/arm/mach-imx/pm-imx5.c   |   12 ++--
> >  arch/arm/mach-imx/pm-imx6.c   |4 -
> >  arch/arm/mach-kirkwood/pm.c   |4 -
> >  arch/arm/mach-lpc32xx/pm.c|2 
> >  arch/arm/mach-mmp/pm-mmp2.c   |3 -
> >  arch/arm/mach-mmp/pm-pxa910.c |3 -
> >  arch/arm/mach-mvebu/kirkwood-pm.c |4 -
> >  arch/arm/mach-mxs/pm.c|4 -
> >  arch/arm/mach-omap1/pm.c  |6 +-
> >  arch/arm/mach-omap2/pm.c  |6 +-
> >  arch/arm/mach-prima2/pm.c |4 -
> >  arch/arm/mach-pxa/pm.c|4 -
> >  arch/arm/mach-pxa/pxa25x.c|4 -
> >  arch/arm/mach-pxa/pxa27x.c|   10 ++-
> >  arch/arm/mach-pxa/pxa3xx.c|7 +-
> >  arch/arm/mach-pxa/sharpsl_pm.c|2 
> >  arch/arm/mach-pxa/z2.c|2 
> >  arch/arm/mach-s3c64xx/mach-smdk6410.c |2 
> >  arch/arm/mach-sa1100/pm.c |2 
> >  arch/arm/mach-shmobile/suspend.c  |2 
> >  arch/arm/mach-tegra/pm.c  |2 
> >  arch/arm/mach-ux500/pm.c  |3 -
> >  arch/arm/plat-samsung/pm.c|2 
> >  arch/avr32/mach-at32ap/pm-at32ap700x.S|2 
> >  arch/avr32/mach-at32ap/pm.c   |8 +--
> >  arch/blackfin/mach-bf609/pm.c |2 
> >  arch/blackfin/mach-common/pm.c|   12 ++--
> >  arch/mips/alchemy/devboards/pm.c  |2 
> >  arch/mips/jz4740/pm.c |2 
> >  arch/mips/loongson/common/pm.c|4 -
> >  arch/powerpc/platforms/52xx/lite5200_pm.c |   12 ++--
> >  arch/powerpc/platforms/52xx/mpc52xx_pm.c  |2 
> >  arch/powerpc/platforms/83xx/suspend.c |   11 ++--
> >  arch/powerpc/platforms/pseries/suspend.c  |6 +-
> >  arch/powerpc/sysdev/fsl_pmc.c |2 
> >  arch/powerpc/sysdev/ppc4xx_cpm.c  |8 +--
> >  arch/sh/boards/mach-hp6xx/pm.c|2 
> >  arch/sh/kernel/cpu/shmobile/pm.c  |2 
> >  arch/unicore32/kernel/pm.c|4 -
> >  arch/unicore32/kernel/puv3-core.c |4 -
> >  arch/x86/platform/olpc/olpc-xo1-pm.c  |4 -
> >  drivers/acpi/sleep.c  |   24 -
> >  drivers/base/power/wakeup.c   |4 -
> >  drivers/char/apm-emulation.c  |6 +-
> >  drivers/macintosh/via-pmu.c   |4 -
> >  drivers/regulator/core.c  |4 -
> >  include/linux/pm.h|4 -
> >  include/linux/suspend.h   |   26 -
> >  kernel/power/hibernate.c  |2 
> >  kernel/power/suspend.c|   79 
> > ++

[PATCH] VFS: allow ->d_manage() to declare -EISDIR in rcu_walk mode.

[NeilBrown]

In REF-walk mode, ->d_manage can return -EISDIR to indicate
that the dentry is not really a mount trap (or even a mount point)
and that any mounts or any DCACHE_NEED_AUTOMOUNT flag should be
ignored.

RCU-walk mode doesn't currently support this, so if there is a dentry
with DCACHE_NEED_AUTOMOUNT set but which shouldn't be a mount-trap,
lookup_fast() will always drop in REF-walk mode.

With this patch, an -EISDIR from ->d_manage will always cause mounts
and automounts to be ignored, both in REF-walk and RCU-walk.

Cc: Ian Kent 
Signed-off-by: NeilBrown 

---
Hi Al,
 this patch is needed before I can make autofs4 fully support RCU-walk.
There are cases currently were directories have DCACHE_NEED_AUTOMOUNT but for 
which
no automount is required.

Thanks,
NeilBrown


diff --git a/Documentation/filesystems/vfs.txt 
b/Documentation/filesystems/vfs.txt
index a1d0d7a30165..61d65cc65c54 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -1053,7 +1053,8 @@ struct dentry_operations {
If the 'rcu_walk' parameter is true, then the caller is doing a
pathwalk in RCU-walk mode.  Sleeping is not permitted in this mode,
and the caller can be asked to leave it and call again by returning
-   -ECHILD.
+   -ECHILD.  -EISDIR may also be returned to tell pathwalk to
+   ignore d_automount or any mounts.
 
This function is only used if DCACHE_MANAGE_TRANSIT is set on the
dentry being transited from.
diff --git a/fs/namei.c b/fs/namei.c
index 985c6f368485..0abfea5697e0 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1091,10 +1091,10 @@ int follow_down_one(struct path *path)
 }
 EXPORT_SYMBOL(follow_down_one);
 
-static inline bool managed_dentry_might_block(struct dentry *dentry)
+static inline int managed_dentry_rcu(struct dentry *dentry)
 {
-   return (dentry->d_flags & DCACHE_MANAGE_TRANSIT &&
-   dentry->d_op->d_manage(dentry, true) < 0);
+   return (dentry->d_flags & DCACHE_MANAGE_TRANSIT) ?
+   dentry->d_op->d_manage(dentry, true) : 0;
 }
 
 /*
@@ -1110,11 +1110,16 @@ static bool __follow_mount_rcu(struct nameidata *nd, 
struct path *path,
 * Don't forget we might have a non-mountpoint managed dentry
 * that wants to block transit.
 */
-   if (unlikely(managed_dentry_might_block(path->dentry)))
+   switch (managed_dentry_rcu(path->dentry)) {
+   case -ECHILD:
+   default:
return false;
+   case -EISDIR:
+   return true;
+   }
 
if (!d_mountpoint(path->dentry))
-   return true;
+   return !(path->dentry->d_flags & DCACHE_NEED_AUTOMOUNT);
 
mounted = __lookup_mnt(path->mnt, path->dentry);
if (!mounted)
@@ -1130,7 +1135,8 @@ static bool __follow_mount_rcu(struct nameidata *nd, 
struct path *path,
 */
*inode = path->dentry->d_inode;
}
-   return read_seqretry(&mount_lock, nd->m_seq);
+   return read_seqretry(&mount_lock, nd->m_seq) &&
+   !(path->dentry->d_flags & DCACHE_NEED_AUTOMOUNT);
 }
 
 static int follow_dotdot_rcu(struct nameidata *nd)
@@ -1402,11 +1408,8 @@ static int lookup_fast(struct nameidata *nd,
}
path->mnt = mnt;
path->dentry = dentry;
-   if (unlikely(!__follow_mount_rcu(nd, path, inode)))
-   goto unlazy;
-   if (unlikely(path->dentry->d_flags & DCACHE_NEED_AUTOMOUNT))
-   goto unlazy;
-   return 0;
+   if (likely(__follow_mount_rcu(nd, path, inode)))
+   return 0;
 unlazy:
if (unlazy_walk(nd, dentry))
return -ECHILD;


signature.asc
Description: PGP signature

Re: use IORESOURCE_REG resource type for non-translatable addresses in DT

[Stephen Boyd]

On 07/29, Rob Herring wrote:
> On Tue, Jul 29, 2014 at 8:07 PM, Stephen Boyd  wrote:
> > On 07/29/14 16:45, Grant Likely wrote:
> >> On Tue, 29 Jul 2014 17:06:42 +0300, Stanimir Varbanov 
> >>  wrote:
> >>>
> >>> This was just an example. Of course it has many issues and probaly it is
> >>> wrong:) The main goal was to understand does IORESOURCE_REG resource
> >>> type and parsing the *reg* properties for non-translatable addresses are
> >>> feasible. And also does it acceptable by community and OF platform
> >>> maintainers.
> >> The use case is actually very different from of_address_to_resource or
> >> of_get_address() because those APIs explicitly return physical memory
> >> addresses from the CPU perspective. It makes more sense to create a new
> >> API that doesn't attempt to translate the reg address. Alternately, a
> >> new API that only translates upto a given parent node.
> >
> > The most important thing is that platform_get_resource{_by_name}(&pdev,
> > IORESOURCE_REG, n) returns the reg property and optional size encoded
> > into a struct resource. I think Rob is suggesting we circumvent the
> > entire of_address_to_resource() path and do some if
> > (IS_ENABLED(CONFIG_OF) && type == IORESOURCE_REG) check in
> > platform_get_resource() to package up the reg property into a struct
> > resource. That should work.
> 
> No, I'm saying why are you using platform_get_resource at all and
> adding a new resource type? I don't see any advantage.

First off, the resource type is not new. IORESOURCE_REG has
existed for two years (see commit 72dcb1197228 "resources: Add
register address resource type, 2012-08-07").

The main advantage is allowing things like
platform_get_resource_by_name() and platform_get_resource() to
work seamlessly with devicetree. If we don't have this, drivers
are going to open code their reg property parsing and possibly
reg-names parsing. There are a handful of drivers that would be
doing this duplicate work.

Sure, we could consolidate them into an OF helper function, but
then these are the only platform drivers that are getting their
reg properties via a special non-translatable address function.
The drivers don't care that they're using non-translateable
addresses as long as they can pass the address returned from
platform_get_resource() to their regmap and do I/O. The drivers
are written under the assumption that they're a sub-device of
some parent device (in this case a PMIC) and so they assume that
the regmap has already been setup for them.

> 
> You might as well do of_property_read_u32 in the below example.
> 

Fair enough. The example is probably too simple. Things are
sometimes slightly more complicated and a simple
of_property_read_u32() isn't going to work in the case of
multiple reg values or when reg-names is in play.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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 29/35] arm: omap: intc: switch over to linear irq domain

[Tony Lindgren]

* Felipe Balbi  [140729 09:36]:
> Hi,
> 
> On Tue, Jul 29, 2014 at 10:40:57AM -0500, Felipe Balbi wrote:
> > On Tue, Jul 29, 2014 at 08:20:52AM -0700, Tony Lindgren wrote:
> > > * Felipe Balbi  [140729 07:18]:
> > > > Hi,
> > > > 
> > > > On Tue, Jul 29, 2014 at 05:14:25AM -0700, Tony Lindgren wrote:
> > > > > * Felipe Balbi  [140728 14:19]:
> > > > > > now that we don't need to support legacy board-files,
> > > > > > we can completely switch over to a linear irq domain
> > > > > > and make use of irq_alloc_domain_generic_chips() to
> > > > > > allocate all generic irq chips for us.
> > > > > 
> > > > > This patch seems to somehow break off-idle for omap3 
> > > > > where it no longer wakes up.
> > > > 
> > > > Sure your bisection is correct ? This patch just switches from legacy
> > > > irq domain to linear irq domain.
> > > 
> > > Yes, I tried it a few times. Just enabling
> > > retention idle hangs too with this patch.
> > > 
> > > Maybe it's omap3_prcm_irq_setup that relies on
> > > 11 + OMAP_INTC_START? There may be other such issues
> > 
> > lol.
> > 
> > OMAP4 has the same nonsense.
> 
> made me think why (if) OMAP4 works with that same setup. Does wake from
> OFF work with OMAP4 ?

Not without similar changes, omap4+ has the same issue.. There's a RFC
series from Nishant to fix some of this, and Tero is moving the PRCM
into a driver.
 
> Anyway, here's a quick little hack to check if that's the reason for the
> regression:

OK yeah that's along the same lines with Nishant's RFC series in thread
"[RFC PATCH 0/7] ARM: OMAP4+: PRM: minor cleanups and dt support of
interrupts"

FYI, it did not compile, needs to include linux/of_irq.h. But yes,
it fixes the regression for me, Also now the whole series works for
me :)

Regards,

Tony

 
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index ff953c9..c234b98 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -97,6 +97,7 @@
>   prm: prm@48306000 {
>   compatible = "ti,omap3-prm";
>   reg = <0x48306000 0x4000>;
> + interrupts = <11>;
>  
>   prm_clocks: clocks {
>   #address-cells = <1>;
> diff --git a/arch/arm/mach-omap2/prm_common.c 
> b/arch/arm/mach-omap2/prm_common.c
> index 25e8b82..3d11377 100644
> --- a/arch/arm/mach-omap2/prm_common.c
> +++ b/arch/arm/mach-omap2/prm_common.c
> @@ -242,6 +242,11 @@ void omap_prcm_irq_complete(void)
>   prcm_irq_setup->restore_irqen(prcm_irq_setup->saved_mask);
>  }
>  
> +static struct of_device_id tmp[] = {
> + { .compatible = "ti,omap3-prm" },
> + { }
> +};
> +
>  /**
>   * omap_prcm_register_chain_handler - initializes the prcm chained interrupt
>   * handler based on provided parameters
> @@ -254,17 +259,24 @@ void omap_prcm_irq_complete(void)
>   */
>  int omap_prcm_register_chain_handler(struct omap_prcm_irq_setup *irq_setup)
>  {
> + struct device_node *node;
>   int nr_regs;
>   u32 mask[OMAP_PRCM_MAX_NR_PENDING_REG];
>   int offset, i;
> + int irq;
>   struct irq_chip_generic *gc;
>   struct irq_chip_type *ct;
>  
>   if (!irq_setup)
>   return -EINVAL;
>  
> + irq = irq_setup->irq;
>   nr_regs = irq_setup->nr_regs;
>  
> + node = of_find_matching_node(NULL, tmp);
> + if (node)
> + irq = of_irq_get(node, 0);
> +
>   if (prcm_irq_setup) {
>   pr_err("PRCM: already initialized; won't reinitialize\n");
>   return -EINVAL;
> @@ -298,7 +310,7 @@ int omap_prcm_register_chain_handler(struct 
> omap_prcm_irq_setup *irq_setup)
>   1 << (offset & 0x1f);
>   }
>  
> - irq_set_chained_handler(irq_setup->irq, omap_prcm_irq_handler);
> + irq_set_chained_handler(irq, omap_prcm_irq_handler);
>  
>   irq_setup->base_irq = irq_alloc_descs(-1, 0, irq_setup->nr_regs * 32,
>   0);
> 
> -- 
> balbi


--
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] clk: ti: clk-7xx: Correct ABE DPLL configuration

[Peter Ujfalusi]

On 07/29/2014 07:12 PM, Mike Turquette wrote:
>> Oh yea, seems this got lost into the myriad of branches I have. I can push
>> this on top of my for-v3.17/ti-clk-drv if you like.
> 
> That is the easiest thing for me. I think that Peter wanted to take
> this as a fix for 3.16 though. Peter is that correct?

Yes, it would have been better to have it in 3.16 along with the DRA7 ATL
clock driver. W/O this patch the ATL will not going to be usable since the ABE
DPLL is set too high to be usable for it's purpose.

-- 
Péter
--
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: [perf/x86/RAPL] BUG: unable to handle kernel NULL pointer dereference at 00000028

[Fengguang Wu]

On Wed, Jul 30, 2014 at 06:45:58AM +0200, Stephane Eranian wrote:
> On Wed, Jul 30, 2014 at 6:00 AM, Fengguang Wu  wrote:
> > Greetings,
> >
> > 0day kernel testing robot got the below dmesg and the first bad commit is
> >
> Is this booting a guest kernel or native?

It's a guest kernel.

> What is the  host CPU?

The host CPU is E5-2680, Sandy Bridge-EP.

Thanks,
Fengguang

> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > commit 4788e5b4b2338f85fa42a712a182d8afd65d7c58
> > Author: Stephane Eranian 
> > AuthorDate: Tue Nov 12 17:58:50 2013 +0100
> > Commit: Ingo Molnar 
> > CommitDate: Wed Nov 27 11:16:40 2013 +0100
> >
> > perf/x86: Add Intel RAPL PMU support
> >
> > This patch adds a new uncore PMU to expose the Intel
> > RAPL energy consumption counters. Up to 3 counters,
> > each counting a particular RAPL event are exposed.
> >
> > The RAPL counters are available on Intel SandyBridge,
> > IvyBridge, Haswell. The server skus add a 3rd counter.
> >
> > The following events are available and exposed in sysfs:
> >
> >   - power/energy-cores: power consumption of all cores on socket
> >   - power/energy-pkg: power consumption of all cores + LLc cache
> >   - power/energy-dram: power consumption of DRAM (servers only)
> >
> > For each event both the unit (Joules) and scale (2^-32 J)
> > is exposed in sysfs for use by perf stat and other tools.
> > The files are:
> >
> > /sys/devices/power/events/energy-*.unit
> > /sys/devices/power/events/energy-*.scale
> >
> > The RAPL PMU is uncore by nature and is implemented such
> > that it only works in system-wide mode. Measuring only
> > one CPU per socket is sufficient. The /sys/devices/power/cpumask
> > file can be used by tools to figure out which CPUs to monitor
> > by default. For instance, on a 2-socket system, 2 CPUs
> > (one on each socket) will be shown.
> >
> > All the counters measure in the same unit (exposed via sysfs).
> > The perf_events API exposes all RAPL counters as 64-bit integers
> > counting in unit of 1/2^32 Joules (about 0.23 nJ). User level tools
> > must convert the counts by multiplying them by 2^-32 to obtain
> > Joules. The reason for this is that the kernel avoids
> > doing floating point math whenever possible because it is
> > expensive (user floating-point state must be saved). The method
> > used avoids kernel floating-point usage. There is no loss of
> > precision. Thanks to PeterZ for suggesting this approach.
> >
> > To convert the raw count in Watt:
> >W = C * 2.3 / (1e10 * time)
> > or ldexp(C, -32).
> >
> > RAPL PMU is a new standalone PMU which registers with the
> > perf_event core subsystem. The PMU type (attr->type) is
> > dynamically allocated and is available from /sys/device/power/type.
> >
> > Sampling is not supported by the RAPL PMU. There is no
> > privilege level filtering either.
> >
> > Signed-off-by: Stephane Eranian 
> > Reviewed-by: Maria Dimakopoulou 
> > Reviewed-by: Andi Kleen 
> > Signed-off-by: Peter Zijlstra 
> > Cc: a...@redhat.com
> > Cc: jo...@redhat.com
> > Cc: zheng.z@intel.com
> > Cc: b...@alien8.de
> > Link: 
> > http://lkml.kernel.org/r/1384275531-10892-4-git-send-email-eran...@google.com
> > Signed-off-by: Ingo Molnar 
> >
> > +---+++---+
> > |   | 410136f5dd | 
> > 4788e5b4b2 | next-20140724 |
> > +---+++---+
> > | boot_successes| 1000   | 
> > 751| 78|
> > | boot_failures | 0  | 
> > 149| 3 |
> > | BUG:unable_to_handle_kernel_NULL_pointer_dereference  | 0  | 
> > 132| 2 |
> > | Oops  | 0  | 
> > 132| 2 |
> > | EIP_is_at_rapl_pmu_init   | 0  | 
> > 132|   |
> > | Kernel_panic-not_syncing:Attempted_to_kill_init_exitcode= | 0  | 
> > 132| 2 |
> > | backtrace:rapl_pmu_init   | 0  | 
> > 132|   |
> > | backtrace:kernel_init_freeable| 0  | 
> > 132| 2 |
> > | BUG:kernel_boot_hang  | 0  | 
> > 17 | 1 |
> > | EIP_is_at_validate_chain  | 0  | 
> > 0  | 2 |
> > | backtrace:free_reserved_area  | 0  | 
> > 0  | 2   

[PATCH] input: ads7846: Release resources on failure for clean exit

[Pramod Gurav]

From: Pramod Gurav 

Input device must be released(input_free_device) when ads7846_probe_dt
fails. This fixes the same by releasing resources on failure.

CC: Dmitry Torokhov 
CC: Lejun Zhu 
CC: Sachin Kamat 

Signed-off-by: Pramod Gurav 
---
 drivers/input/touchscreen/ads7846.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/input/touchscreen/ads7846.c 
b/drivers/input/touchscreen/ads7846.c
index da201b8..e57ba52 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -1302,8 +1302,10 @@ static int ads7846_probe(struct spi_device *spi)
pdata = dev_get_platdata(&spi->dev);
if (!pdata) {
pdata = ads7846_probe_dt(&spi->dev);
-   if (IS_ERR(pdata))
-   return PTR_ERR(pdata);
+   if (IS_ERR(pdata)) {
+   err = PTR_ERR(pdata);
+   goto err_free_mem;
+   }
}
 
ts->model = pdata->model ? : 7846;
-- 
1.7.9.5

--
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/6] MAINTAINERS: Update DMA BUFFER SHARING patterns

[Sumit Semwal]

Hi Joe!

On 30 July 2014 09:08, Joe Perches  wrote:
> One pattern per F: line please...
Thanks for catching this;
Acked-by: Sumit Semwal 
>
> Signed-off-by: Joe Perches 
> CC: Sumit Semwal 
> ---
>  MAINTAINERS | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5e5478b..66d5894 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2941,7 +2941,9 @@ L:linux-me...@vger.kernel.org
>  L: dri-de...@lists.freedesktop.org
>  L: linaro-mm-...@lists.linaro.org
>  F: drivers/dma-buf/
> -F: include/linux/dma-buf* include/linux/reservation.h 
> include/linux/*fence.h
> +F: include/linux/dma-buf*
> +F: include/linux/reservation.h
> +F: include/linux/*fence.h
>  F: Documentation/dma-buf-sharing.txt
>  T: git git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git
>
> --
> 1.8.1.2.459.gbcd45b4.dirty
>


Best regards,
~Sumit.
--
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 RESEND 3/4] drivers: dma-coherent: add initialization from device tree

[Marek Szyprowski]

Hello,

On 2014-07-29 23:54, Grant Likely wrote:

On Mon, 14 Jul 2014 10:28:06 +0200, Marek Szyprowski  
wrote:

Initialization procedure of dma coherent pool has been split into two
parts, so memory pool can now be initialized without assigning to
particular struct device. Then initialized region can be assigned to
more than one struct device. To protect from concurent allocations from
different devices, a spinlock has been added to dma_coherent_mem
structure. The last part of this patch adds support for handling
'shared-dma-pool' reserved-memory device tree nodes.

Signed-off-by: Marek Szyprowski 

I think this looks okay. It isn't in my area of expertise though.
Comments below.


---
  drivers/base/dma-coherent.c | 137 ++--
  1 file changed, 118 insertions(+), 19 deletions(-)

diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
index 7d6e84a51424..7185a4f247e1 100644
--- a/drivers/base/dma-coherent.c
+++ b/drivers/base/dma-coherent.c
@@ -14,11 +14,14 @@ struct dma_coherent_mem {
int size;
int flags;
unsigned long   *bitmap;
+   spinlock_t  spinlock;
  };
  
-int dma_declare_coherent_memory(struct device *dev, phys_addr_t phys_addr,

-   dma_addr_t device_addr, size_t size, int flags)
+static int dma_init_coherent_memory(phys_addr_t phys_addr, dma_addr_t 
device_addr,
+size_t size, int flags,
+struct dma_coherent_mem **mem)

This is a bit odd. Why wouldn't you return the dma_mem pointer directly
instead of passing in a **mem argument?


Because this function (as a direct successor of 
dma_declare_coherent_memory) doesn't
return typical error codes, but some custom values like DMA_MEMORY_MAP, 
DMA_MEMORY_IO
or zero (which means failure). I wanted to avoid confusion with typical 
error
handling path and IS_ERR/ERR_PTR usage used widely in other functions. 
This probably
should be unified with the rest of kernel some day, but right now I 
wanted to keep

the patch simple and easy to review.


  {
+   struct dma_coherent_mem *dma_mem = NULL;
void __iomem *mem_base = NULL;
int pages = size >> PAGE_SHIFT;
int bitmap_size = BITS_TO_LONGS(pages) * sizeof(long);
@@ -27,27 +30,26 @@ int dma_declare_coherent_memory(struct device *dev, 
phys_addr_t phys_addr,
goto out;
if (!size)
goto out;
-   if (dev->dma_mem)
-   goto out;
-
-   /* FIXME: this routine just ignores DMA_MEMORY_INCLUDES_CHILDREN */
  
  	mem_base = ioremap(phys_addr, size);

if (!mem_base)
goto out;
  
-	dev->dma_mem = kzalloc(sizeof(struct dma_coherent_mem), GFP_KERNEL);

-   if (!dev->dma_mem)
+   dma_mem = kzalloc(sizeof(struct dma_coherent_mem), GFP_KERNEL);
+   if (!dma_mem)
goto out;
-   dev->dma_mem->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
-   if (!dev->dma_mem->bitmap)
+   dma_mem->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
+   if (!dma_mem->bitmap)
goto free1_out;
  
-	dev->dma_mem->virt_base = mem_base;

-   dev->dma_mem->device_base = device_addr;
-   dev->dma_mem->pfn_base = PFN_DOWN(phys_addr);
-   dev->dma_mem->size = pages;
-   dev->dma_mem->flags = flags;
+   dma_mem->virt_base = mem_base;
+   dma_mem->device_base = device_addr;
+   dma_mem->pfn_base = PFN_DOWN(phys_addr);
+   dma_mem->size = pages;
+   dma_mem->flags = flags;
+   spin_lock_init(&dma_mem->spinlock);
+
+   *mem = dma_mem;
  
  	if (flags & DMA_MEMORY_MAP)

return DMA_MEMORY_MAP;
@@ -55,12 +57,51 @@ int dma_declare_coherent_memory(struct device *dev, 
phys_addr_t phys_addr,
return DMA_MEMORY_IO;
  
   free1_out:

-   kfree(dev->dma_mem);
+   kfree(dma_mem);
   out:
if (mem_base)
iounmap(mem_base);
return 0;
  }
+
+static void dma_release_coherent_memory(struct dma_coherent_mem *mem)
+{
+   if (!mem)
+   return;
+   iounmap(mem->virt_base);
+   kfree(mem->bitmap);
+   kfree(mem);
+}
+
+static int dma_assign_coherent_memory(struct device *dev,
+ struct dma_coherent_mem *mem)
+{
+   if (dev->dma_mem)
+   return -EBUSY;
+
+   dev->dma_mem = mem;
+   /* FIXME: this routine just ignores DMA_MEMORY_INCLUDES_CHILDREN */
+
+   return 0;
+}
+
+int dma_declare_coherent_memory(struct device *dev, phys_addr_t phys_addr,
+   dma_addr_t device_addr, size_t size, int flags)
+{
+   struct dma_coherent_mem *mem;
+   int ret;
+
+   ret = dma_init_coherent_memory(phys_addr, device_addr, size, flags,
+  &mem);
+   if (ret == 0)
+   return 0;
+
+   if (dma_assign_coherent_memory(dev, mem) == 0)
+   return ret;
+
+   d

Re: Open-ended task In kernel

[sanjeev sharma]

Thanks greg

so I need to find issue myself and then start from there.Do we have
some link somewhere open-ended task is captured.

Regards
Sanjeev Sharma

On Tue, Jul 29, 2014 at 8:44 PM, gregkh  wrote:
> On Tue, Jul 29, 2014 at 12:46:46PM +0530, sanjeev sharma wrote:
>> Hello All,
>>
>> I have started recently in contributing into Linux kernel and submitted 
>> patches
>> in staging directory and now I want to do outside staging directory specially
>> in main kernel and driver part.Do we have anything in Linux kernel i.e some
>> specific areas which I can looked upon.I think we should have some list of
>> open-point where people can contribute.
>>
>> If anyone has some information,please share on mailing list so that I can 
>> focus
>> myself in correct direction.
>
> Yes, I know lots of "open ended" tasks in the kernel.
>
> But just because I, or someone else, writes them down doesn't mean that
> you will want to do them, or be sucessful at them.
>
> My suggestion always is, "Find something that bothers you, fix it, and
> go from there."  And if you can't find a problem with the kernel on your
> machine, then you really aren't looking hard enough.
>
> Best of luck,
>
> 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: Bug on Kernel 3.16 r6: Sound and Buffering in Clementine with Files are Transferring to Music Directory

[Nick Krause]

On Tue, Jul 29, 2014 at 1:34 PM, Nick Krause  wrote:
> On Tue, Jul 29, 2014 at 1:02 PM, Nick Krause  wrote:
>> On Tue, Jul 29, 2014 at 11:42 AM,   wrote:
>>> On 2014-07-28 22:57, Nick Krause wrote:
r the hang, so doing a bisect might lead us to some innocent commit.
>> I have run the rsync + snapshot job several times here now, and no hang.
>>

 Seems after changing my settings in Clementine it works but it
 now seems to need to buffer 10 seconds versus 4 seconds
 from before.
>>>
>>>
>>> Nick,
>>> For the record you can also use something like ionice to avoid these sorts
>>> of annoyances. See: https://bbs.archlinux.org/viewtopic.php?id=176711
>>> Matt Joras
>>
>> Thanks Matt,
>> Seems weird through that sound buffering is needed more, thanks for
>> the advice through.
>> Regards Nick
>
> Matt,
> After doing more testing this is definitely a bug as no matter what
> buffer size this
> seems to be an issue my music stalls when moving music into the directory
> of the music I am listening to and this didn't happen when I was running stock
> Ubuntu kernels.
> Regards Nick

Seems to be an issue with Ubuntu.
Regards Nick
--
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: Work Queue for btrfs compression writes

[Nick Krause]

On Wed, Jul 30, 2014 at 12:37 AM, Gareth Pye  wrote:
> You've been replied to politely, now listen and do or shut up.
>
>
> On Wed, Jul 30, 2014 at 1:54 PM, Nick Krause  wrote:
>>
>> Hey Guys ,
>> I am new to   reading  and writing  kernel code.I got interested in
>> writing code for btrfs as it seems to
>> need more work then other file systems and this seems other then
>> drivers, a good use of time on my part.
>> I interested in helping improving the compression of btrfs by using  a
>> set of threads using work queues like XFS
>> or reads and keeping the page cache after reading compressed blocks as
>> these seem to be a great way to improve
>> on  compression performance mostly with large partitions of compressed
>> data. I am not asking you to write the code
>> for me but as I am new a little guidance and help would be greatly
>> appreciated as this seems like too much work for just a newbie.
>> Thanks A lot,
>> Nick
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
>
> --
> Gareth Pye
> Level 2 Judge, Melbourne, Australia
> Australian MTG Forum: mtgau.com
> gar...@cerberos.id.au - www.rockpaperdynamite.wordpress.com
> "Dear God, I would like to file a bug report"

Gareth
I am asking for advice on not writing the code but can someone please
test this for me as I don't have many hard drives lying around. In addition
I am new to btrfs , so I would like to known if this is a good idea or should
I just drop it?
Nick
--
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/

[RESEND PATCH] mmc: core: Remove fixed voltage regulator logic

[Tim Kryger]

There is no need for regulator consumers to include special logic for
fixed voltage regulators as they support regulator_set_voltage() just
like their non-fixed regulator counterparts.

Signed-off-by: Tim Kryger 
---

Since this eliminates logic that was concealing a bug in how the SDHCI
driver was setting ocr_avail, it is important that the following patch
to fix that bug be taken first.  Fortunately, it is already queued.

  https://lkml.org/lkml/2014/6/13/451

 drivers/mmc/core/core.c |8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 7dc0c85..e56375c 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1280,15 +1280,7 @@ int mmc_regulator_set_ocr(struct mmc_host *mmc,
max_uV = min_uV + 100 * 1000;
}
 
-   /*
-* If we're using a fixed/static regulator, don't call
-* regulator_set_voltage; it would fail.
-*/
voltage = regulator_get_voltage(supply);
-
-   if (!regulator_can_change_voltage(supply))
-   min_uV = max_uV = voltage;
-
if (voltage < 0)
result = voltage;
else if (voltage < min_uV || voltage > max_uV)
-- 
1.7.9.5

--
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: [perf/x86/RAPL] BUG: unable to handle kernel NULL pointer dereference at 00000028

[Stephane Eranian]

On Wed, Jul 30, 2014 at 6:00 AM, Fengguang Wu  wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
Is this booting a guest kernel or native?
What is the  host CPU?

> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> commit 4788e5b4b2338f85fa42a712a182d8afd65d7c58
> Author: Stephane Eranian 
> AuthorDate: Tue Nov 12 17:58:50 2013 +0100
> Commit: Ingo Molnar 
> CommitDate: Wed Nov 27 11:16:40 2013 +0100
>
> perf/x86: Add Intel RAPL PMU support
>
> This patch adds a new uncore PMU to expose the Intel
> RAPL energy consumption counters. Up to 3 counters,
> each counting a particular RAPL event are exposed.
>
> The RAPL counters are available on Intel SandyBridge,
> IvyBridge, Haswell. The server skus add a 3rd counter.
>
> The following events are available and exposed in sysfs:
>
>   - power/energy-cores: power consumption of all cores on socket
>   - power/energy-pkg: power consumption of all cores + LLc cache
>   - power/energy-dram: power consumption of DRAM (servers only)
>
> For each event both the unit (Joules) and scale (2^-32 J)
> is exposed in sysfs for use by perf stat and other tools.
> The files are:
>
> /sys/devices/power/events/energy-*.unit
> /sys/devices/power/events/energy-*.scale
>
> The RAPL PMU is uncore by nature and is implemented such
> that it only works in system-wide mode. Measuring only
> one CPU per socket is sufficient. The /sys/devices/power/cpumask
> file can be used by tools to figure out which CPUs to monitor
> by default. For instance, on a 2-socket system, 2 CPUs
> (one on each socket) will be shown.
>
> All the counters measure in the same unit (exposed via sysfs).
> The perf_events API exposes all RAPL counters as 64-bit integers
> counting in unit of 1/2^32 Joules (about 0.23 nJ). User level tools
> must convert the counts by multiplying them by 2^-32 to obtain
> Joules. The reason for this is that the kernel avoids
> doing floating point math whenever possible because it is
> expensive (user floating-point state must be saved). The method
> used avoids kernel floating-point usage. There is no loss of
> precision. Thanks to PeterZ for suggesting this approach.
>
> To convert the raw count in Watt:
>W = C * 2.3 / (1e10 * time)
> or ldexp(C, -32).
>
> RAPL PMU is a new standalone PMU which registers with the
> perf_event core subsystem. The PMU type (attr->type) is
> dynamically allocated and is available from /sys/device/power/type.
>
> Sampling is not supported by the RAPL PMU. There is no
> privilege level filtering either.
>
> Signed-off-by: Stephane Eranian 
> Reviewed-by: Maria Dimakopoulou 
> Reviewed-by: Andi Kleen 
> Signed-off-by: Peter Zijlstra 
> Cc: a...@redhat.com
> Cc: jo...@redhat.com
> Cc: zheng.z@intel.com
> Cc: b...@alien8.de
> Link: 
> http://lkml.kernel.org/r/1384275531-10892-4-git-send-email-eran...@google.com
> Signed-off-by: Ingo Molnar 
>
> +---+++---+
> |   | 410136f5dd | 
> 4788e5b4b2 | next-20140724 |
> +---+++---+
> | boot_successes| 1000   | 
> 751| 78|
> | boot_failures | 0  | 
> 149| 3 |
> | BUG:unable_to_handle_kernel_NULL_pointer_dereference  | 0  | 
> 132| 2 |
> | Oops  | 0  | 
> 132| 2 |
> | EIP_is_at_rapl_pmu_init   | 0  | 
> 132|   |
> | Kernel_panic-not_syncing:Attempted_to_kill_init_exitcode= | 0  | 
> 132| 2 |
> | backtrace:rapl_pmu_init   | 0  | 
> 132|   |
> | backtrace:kernel_init_freeable| 0  | 
> 132| 2 |
> | BUG:kernel_boot_hang  | 0  | 17 
> | 1 |
> | EIP_is_at_validate_chain  | 0  | 0  
> | 2 |
> | backtrace:free_reserved_area  | 0  | 0  
> | 2 |
> | backtrace:free_init_pages | 0  | 0  
> | 2 |
> | backtrace:populate_rootfs | 0  | 0  
> | 2 |
> +---+++---+
>
> [0.613305] 

Re: [PATCH 11/11] seccomp: Add tgid and tid into seccomp_data

[Andy Lutomirski]

On Tue, Jul 29, 2014 at 9:08 PM, Eric W. Biederman
 wrote:
> Andy Lutomirski  writes:
>
>> On Mon, Jul 28, 2014 at 2:18 PM, Eric W. Biederman
>>  wrote:
>>> Andy Lutomirski  writes:
>>>
 [cc: Eric Biederman]

>>>
 Can we do one better and add a flag to prevent any non-self pid
 lookups?  This might actually be easy on top of the pid namespace work
 (e.g. we could change the way that find_task_by_vpid works).

 It's far from just being signals.  There's access_process_vm, ptrace,
 all the signal functions, clock_gettime (see CPUCLOCK_PID -- yes, this
 is ridiculous), and probably some others that I've forgotten about or
 never noticed in the first place.
>>>
>>> So here is the practical question.
>>>
>>> Are these processes that only can send signals to their thread group
>>> allowed to call fork()?
>>>
>>>
>>> If fork is allowed and all pid lookups are restricted to their own
>>> thread group that wait, waitpid, and all of the rest of the wait family
>>> will never return the pids of their children, and zombies will
>>> accumulate.  Aka the semantics are fundamentally broken.
>>
>> Good point.
>>
>> I can imagine at least three ways that fork() could continue working, though:
>>
>> 1. Allow lookups of immediate children, too.  (I don't love this one.)
>> 2. Allow non-self pids to be translated in but not out.  This way
>> P_ALL will continue working.
>> 3. Have the kernel treat any PID-restricted process as though it were 
>> NOCLDWAIT.
>>
>> I think I like #3.  Thoughts?
>>
>>>
>>> If fork is not allowed pid namespaces already solve this problem.
>>
>> PID namespaces are fairly heavyweight.  Julien pointed out that using
>> PID namespaces requires a bunch of dummy PID 1 processes.
>
> Only if you can't tolerate init exiting.  The reasoning with respect to
> signals and signals being ignored was wrong.  And if you only have one
> process you care about and no children to worry about neither the
> difference in signal handling nor the world dies whe init exits applies.

Can you elaborate?  It seems entirely plausible to me that there are
programs that won't work right as PID 1 without considerable
adaptation.

>
> Therefore given what I have read described pid namespaces are a trivial
> solution to this problem space.

pid namespaces also won't work in the context of Capsicum unless you
want every single Capsicum process to be its own pid namespace.  Also,
pid namespaces don't offer any way to protect children from parents.

--Andy
--
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 07/17] ACPICA: Utilities: Fix local printf issue.

[Lv Zheng]

The bug can be reproduced by using a format that do not have the width.prec
specified after a format that have the width.prec specified. The second
formatted output will be wrong. The root cause is acpi_ut_vsnprintf()
doesn't reset the specifiers to the default values.

This patch fixes this issue. BZ 1094. Reported by Yizhe Wang, fixed by
Lv Zheng.

Since acpi_ut_vprintf() is only enabled for specific OSPM now, this patch
doesn't affect Linux kernel.

Reference: https://bugs.acpica.org/show_bug.cgi?id=1094
Reported-and-tested-by: Yizhe Wang 
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
---
 drivers/acpi/acpica/utprint.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/acpi/acpica/utprint.c b/drivers/acpi/acpica/utprint.c
index 080e22a..0ce3f5a 100644
--- a/drivers/acpi/acpica/utprint.c
+++ b/drivers/acpi/acpica/utprint.c
@@ -401,6 +401,7 @@ acpi_ut_vsnprintf(char *string,
 
/* Process width */
 
+   width = -1;
if (ACPI_IS_DIGIT(*format)) {
format = acpi_ut_scan_number(format, &number);
width = (s32) number;
@@ -415,6 +416,7 @@ acpi_ut_vsnprintf(char *string,
 
/* Process precision */
 
+   precision = -1;
if (*format == '.') {
++format;
if (ACPI_IS_DIGIT(*format)) {
@@ -431,6 +433,7 @@ acpi_ut_vsnprintf(char *string,
 
/* Process qualifier */
 
+   qualifier = -1;
if (*format == 'h' || *format == 'l' || *format == 'L') {
qualifier = *format;
++format;
-- 
1.7.10

--
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 05/17] ACPICA: Remove some extraneous printf arguments.

[Lv Zheng]

From: Sascha Wildner 

Arguments that have no associated % format specifier.
Apparently these are not caught by any current compilers.
ACPICA BZ 1090. Sascha Wildner.

Currently this patch only affects applications under the
toos/power/acpi folder.

Reference: https://bugs.acpica.org/show_bug.cgi?id=1090
Signed-off-by: Sascha Wildner 
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/exdump.c   |6 +++---
 drivers/acpi/acpica/utfileio.c |3 +--
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/acpica/exdump.c b/drivers/acpi/acpica/exdump.c
index 925202a..0f23c3f 100644
--- a/drivers/acpi/acpica/exdump.c
+++ b/drivers/acpi/acpica/exdump.c
@@ -494,7 +494,7 @@ acpi_ex_dump_object(union acpi_operand_object *obj_desc,
}
}
 
-   acpi_os_printf("\n", next);
+   acpi_os_printf("\n");
break;
 
case ACPI_EXD_HDLR_LIST:
@@ -528,7 +528,7 @@ acpi_ex_dump_object(union acpi_operand_object *obj_desc,
}
}
 
-   acpi_os_printf("\n", next);
+   acpi_os_printf("\n");
break;
 
case ACPI_EXD_RGN_LIST:
@@ -562,7 +562,7 @@ acpi_ex_dump_object(union acpi_operand_object *obj_desc,
}
}
 
-   acpi_os_printf("\n", next);
+   acpi_os_printf("\n");
break;
 
case ACPI_EXD_NODE:
diff --git a/drivers/acpi/acpica/utfileio.c b/drivers/acpi/acpica/utfileio.c
index bdf9914..4e263a8 100644
--- a/drivers/acpi/acpica/utfileio.c
+++ b/drivers/acpi/acpica/utfileio.c
@@ -201,8 +201,7 @@ acpi_ut_read_table(FILE * fp,
status = fl_check_for_ascii(fp, NULL, FALSE);
if (ACPI_SUCCESS(status)) {
acpi_os_printf
-   ("File appears to be ASCII only, must be 
binary\n",
-table_header.length, file_size);
+   ("File appears to be ASCII only, must be 
binary\n");
}
 #endif
return (AE_BAD_HEADER);
-- 
1.7.10

--
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 10/17] ACPICA: ACPI 5.1: Support for the _DSD predefined name.

[Lv Zheng]

From: "David E. Box" 

Adds full support for _DSD. David Box.

Signed-off-by: David E. Box 
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/acpredef.h |   13 -
 include/acpi/acnames.h |1 +
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/acpica/acpredef.h b/drivers/acpi/acpica/acpredef.h
index bd08817..c5bfadf 100644
--- a/drivers/acpi/acpica/acpredef.h
+++ b/drivers/acpi/acpica/acpredef.h
@@ -105,6 +105,11 @@
  *  count = 0 (optional)
  *  (Used for _DLM)
  *
+ * ACPI_PTYPE2_UUID_PAIR: Each subpackage is preceded by a UUID Buffer. The 
UUID
+ *  defines the format of the package. Zero-length parent package is
+ *  allowed.
+ *  (Used for _DSD)
+ *
  */
 
 enum acpi_return_package_types {
@@ -117,7 +122,8 @@ enum acpi_return_package_types {
ACPI_PTYPE2_FIXED = 7,
ACPI_PTYPE2_MIN = 8,
ACPI_PTYPE2_REV_FIXED = 9,
-   ACPI_PTYPE2_FIX_VAR = 10
+   ACPI_PTYPE2_FIX_VAR = 10,
+   ACPI_PTYPE2_UUID_PAIR = 11
 };
 
 /* Support macros for users of the predefined info table */
@@ -436,6 +442,11 @@ const union acpi_predefined_info 
acpi_gbl_predefined_methods[] = {
{{"_DOS", METHOD_1ARGS(ACPI_TYPE_INTEGER),
  METHOD_NO_RETURN_VALUE}},
 
+   {{"_DSD", METHOD_0ARGS,
+ METHOD_RETURNS(ACPI_RTYPE_PACKAGE)}}, /* Variable-length (Pkgs) each: 
1 Buf, 1 Pkg */
+   PACKAGE_INFO(ACPI_PTYPE2_UUID_PAIR, ACPI_RTYPE_BUFFER, 1,
+ACPI_RTYPE_PACKAGE, 1, 0),
+
{{"_DSM",
  METHOD_4ARGS(ACPI_TYPE_BUFFER, ACPI_TYPE_INTEGER, ACPI_TYPE_INTEGER,
   ACPI_TYPE_PACKAGE),
diff --git a/include/acpi/acnames.h b/include/acpi/acnames.h
index 3dd6e83..c728113 100644
--- a/include/acpi/acnames.h
+++ b/include/acpi/acnames.h
@@ -55,6 +55,7 @@
 #define METHOD_NAME__HID"_HID"
 #define METHOD_NAME__INI"_INI"
 #define METHOD_NAME__PLD"_PLD"
+#define METHOD_NAME__DSD"_DSD"
 #define METHOD_NAME__PRS"_PRS"
 #define METHOD_NAME__PRT"_PRT"
 #define METHOD_NAME__PRW"_PRW"
-- 
1.7.10

--
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 11/17] ACPICA: ACPI 5.1: New notify value for System Affinity Update.

[Lv Zheng]

From: Bob Moore 

New value for the Notify() operator.

Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/utdecode.c |5 +++--
 include/acpi/actypes.h |3 ++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/acpica/utdecode.c b/drivers/acpi/acpica/utdecode.c
index 98f5418..40e923e 100644
--- a/drivers/acpi/acpica/utdecode.c
+++ b/drivers/acpi/acpica/utdecode.c
@@ -448,7 +448,8 @@ static const char *acpi_gbl_generic_notify[ACPI_NOTIFY_MAX 
+ 1] = {
/* 09 */ "Device PLD Check",
/* 0A */ "Reserved",
/* 0B */ "System Locality Update",
-   /* 0C */ "Shutdown Request"
+   /* 0C */ "Shutdown Request",
+   /* 0D */ "System Resource Affinity Update"
 };
 
 static const char *acpi_gbl_device_notify[4] = {
@@ -475,7 +476,7 @@ static const char *acpi_gbl_thermal_notify[4] = {
 const char *acpi_ut_get_notify_name(u32 notify_value, acpi_object_type type)
 {
 
-   /* 00 - 0C are common to all object types */
+   /* 00 - 0D are common to all object types */
 
if (notify_value <= ACPI_NOTIFY_MAX) {
return (acpi_gbl_generic_notify[notify_value]);
diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h
index 4d9b29c..ac03ec8 100644
--- a/include/acpi/actypes.h
+++ b/include/acpi/actypes.h
@@ -612,8 +612,9 @@ typedef u64 acpi_integer;
 #define ACPI_NOTIFY_RESERVED(u8) 0x0A
 #define ACPI_NOTIFY_LOCALITY_UPDATE (u8) 0x0B
 #define ACPI_NOTIFY_SHUTDOWN_REQUEST(u8) 0x0C
+#define ACPI_NOTIFY_AFFINITY_UPDATE (u8) 0x0D
 
-#define ACPI_NOTIFY_MAX 0x0C
+#define ACPI_NOTIFY_MAX 0x0D
 
 /*
  * Types associated with ACPI names and objects. The first group of
-- 
1.7.10

--
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 16/17] ACPICA: ACPI 5.1: Update for PCCT table changes.

[Lv Zheng]

From: Bob Moore 

One new subtable.

Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 include/acpi/actbl3.h |   25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/include/acpi/actbl3.h b/include/acpi/actbl3.h
index 41ad964..787bcc8 100644
--- a/include/acpi/actbl3.h
+++ b/include/acpi/actbl3.h
@@ -448,7 +448,8 @@ struct acpi_table_pcct {
 
 enum acpi_pcct_type {
ACPI_PCCT_TYPE_GENERIC_SUBSPACE = 0,
-   ACPI_PCCT_TYPE_RESERVED = 1 /* 1 and greater are reserved */
+   ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE = 1,
+   ACPI_PCCT_TYPE_RESERVED = 2 /* 2 and greater are reserved */
 };
 
 /*
@@ -470,6 +471,28 @@ struct acpi_pcct_subspace {
u16 min_turnaround_time;
 };
 
+/* 1: HW-reduced Communications Subspace (ACPI 5.1) */
+
+struct acpi_pcct_hw_reduced {
+   struct acpi_subtable_header header;
+   u32 doorbell_interrupt;
+   u8 flags;
+   u8 reserved;
+   u64 base_address;
+   u64 length;
+   struct acpi_generic_address doorbell_register;
+   u64 preserve_mask;
+   u64 write_mask;
+   u32 latency;
+   u32 max_access_rate;
+   u16 min_turnaround_time;
+};
+
+/* Values for doorbell flags above */
+
+#define ACPI_PCCT_INTERRUPT_POLARITY(1)
+#define ACPI_PCCT_INTERRUPT_MODE(1<<1)
+
 /*
  * PCC memory structures (not part of the ACPI table)
  */
-- 
1.7.10

--
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 17/17] ACPICA: Update version to 20140724.

[Lv Zheng]

From: Bob Moore 

Version 20140724.

Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 include/acpi/acpixf.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
index c3f38bc..b7c89d4 100644
--- a/include/acpi/acpixf.h
+++ b/include/acpi/acpixf.h
@@ -46,7 +46,7 @@
 
 /* Current ACPICA subsystem version in MMDD format */
 
-#define ACPI_CA_VERSION 0x20140627
+#define ACPI_CA_VERSION 0x20140724
 
 #include 
 #include 
-- 
1.7.10

--
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 14/17] ACPICA/ARM: ACPI 5.1: Update for MADT changes.

[Lv Zheng]

From: Tomasz Nowicki 

New subtables and changes to other subtables. Tomasz Nowicki.
tomasz.nowi...@linaro.org

Signed-off-by: Tomasz Nowicki 
Signed-off-by: Hanjun Guo 
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 include/acpi/actbl1.h |   44 +---
 1 file changed, 41 insertions(+), 3 deletions(-)

diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
index 9613e8e..7626bfe 100644
--- a/include/acpi/actbl1.h
+++ b/include/acpi/actbl1.h
@@ -671,7 +671,9 @@ enum acpi_madt_type {
ACPI_MADT_TYPE_LOCAL_X2APIC_NMI = 10,
ACPI_MADT_TYPE_GENERIC_INTERRUPT = 11,
ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR = 12,
-   ACPI_MADT_TYPE_RESERVED = 13/* 13 and greater are reserved */
+   ACPI_MADT_TYPE_GENERIC_MSI_FRAME = 13,
+   ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR = 14,
+   ACPI_MADT_TYPE_RESERVED = 15/* 15 and greater are reserved */
 };
 
 /*
@@ -797,15 +799,26 @@ struct acpi_madt_local_x2apic_nmi {
 struct acpi_madt_generic_interrupt {
struct acpi_subtable_header header;
u16 reserved;   /* reserved - must be zero */
-   u32 gic_id;
+   u32 cpu_interface_number;
u32 uid;
u32 flags;
u32 parking_version;
u32 performance_interrupt;
u64 parked_address;
u64 base_address;
+   u64 gicv_base_address;
+   u64 gich_base_address;
+   u32 vgic_interrupt;
+   u64 gicr_base_address;
+   u64 arm_mpidr;
 };
 
+/* Masks for Flags field above */
+
+/* ACPI_MADT_ENABLED(1)  Processor is usable if set */
+#define ACPI_MADT_PERFORMANCE_IRQ_MODE  (1<<1) /* 01: Performance Interrupt 
Mode */
+#define ACPI_MADT_VGIC_IRQ_MODE (1<<2) /* 02: VGIC Maintenance 
Interrupt mode */
+
 /* 12: Generic Distributor (ACPI 5.0) */
 
 struct acpi_madt_generic_distributor {
@@ -817,11 +830,36 @@ struct acpi_madt_generic_distributor {
u32 reserved2;  /* reserved - must be zero */
 };
 
+/* 13: Generic MSI Frame (ACPI 5.1) */
+
+struct acpi_madt_generic_msi_frame {
+   struct acpi_subtable_header header;
+   u16 reserved;   /* reserved - must be zero */
+   u32 msi_frame_id;
+   u64 base_address;
+   u32 flags;
+   u16 spi_count;
+   u16 spi_base;
+};
+
+/* Masks for Flags field above */
+
+#define ACPI_MADT_OVERRIDE_SPI_VALUES   (1)
+
+/* 14: Generic Redistributor (ACPI 5.1) */
+
+struct acpi_madt_generic_redistributor {
+   struct acpi_subtable_header header;
+   u16 reserved;   /* reserved - must be zero */
+   u64 base_address;
+   u32 length;
+};
+
 /*
  * Common flags fields for MADT subtables
  */
 
-/* MADT Local APIC flags (lapic_flags) and GIC flags */
+/* MADT Local APIC flags */
 
 #define ACPI_MADT_ENABLED   (1)/* 00: Processor is usable if 
set */
 
-- 
1.7.10

--
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 12/17] ACPICA: ACPI 5.1: Support for the _CCA predifined name.

[Lv Zheng]

From: Bob Moore 

Full support for _CCA.

Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/acpredef.h |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/acpi/acpica/acpredef.h b/drivers/acpi/acpica/acpredef.h
index c5bfadf..bd3908d 100644
--- a/drivers/acpi/acpica/acpredef.h
+++ b/drivers/acpi/acpica/acpredef.h
@@ -370,6 +370,9 @@ const union acpi_predefined_info 
acpi_gbl_predefined_methods[] = {
{{"_CBA", METHOD_0ARGS,
  METHOD_RETURNS(ACPI_RTYPE_INTEGER)}}, /* See PCI firmware spec 3.0 */
 
+   {{"_CCA", METHOD_0ARGS,
+ METHOD_RETURNS(ACPI_RTYPE_INTEGER)}}, /* ACPI 5.1 */
+
{{"_CDM", METHOD_0ARGS,
  METHOD_RETURNS(ACPI_RTYPE_INTEGER)}},
 
-- 
1.7.10

--
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 13/17] ACPICA/ARM: ACPI 5.1: Update for FADT changes.

[Lv Zheng]

From: Graeme Gregory 

Adds ARM flags and FADT minor revision. Graeme Gregory.
graeme.greg...@linaro.org

Signed-off-by: Graeme Gregory 
Signed-off-by: Hanjun Guo 
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 include/acpi/actbl.h |   12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/include/acpi/actbl.h b/include/acpi/actbl.h
index 1cc7ef1..bee19d8 100644
--- a/include/acpi/actbl.h
+++ b/include/acpi/actbl.h
@@ -270,7 +270,8 @@ struct acpi_table_fadt {
u32 flags;  /* Miscellaneous flag bits (see below for 
individual flags) */
struct acpi_generic_address reset_register; /* 64-bit address of 
the Reset register */
u8 reset_value; /* Value to write to the reset_register port to 
reset the system */
-   u8 reserved4[3];/* Reserved, must be zero */
+   u16 arm_boot_flags; /* ARM-Specific Boot Flags (see below for 
individual flags) (ACPI 5.1) */
+   u8 minor_revision;  /* FADT Minor Revision (ACPI 5.1) */
u64 Xfacs;  /* 64-bit physical address of FACS */
u64 Xdsdt;  /* 64-bit physical address of DSDT */
struct acpi_generic_address xpm1a_event_block;  /* 64-bit Extended 
Power Mgt 1a Event Reg Blk address */
@@ -285,7 +286,7 @@ struct acpi_table_fadt {
struct acpi_generic_address sleep_status;   /* 64-bit Sleep Status 
register (ACPI 5.0) */
 };
 
-/* Masks for FADT Boot Architecture Flags (boot_flags) [Vx]=Introduced in this 
FADT revision */
+/* Masks for FADT IA-PC Boot Architecture Flags (boot_flags) [Vx]=Introduced 
in this FADT revision */
 
 #define ACPI_FADT_LEGACY_DEVICES(1)/* 00: [V2] System has LPC or 
ISA bus devices */
 #define ACPI_FADT_8042  (1<<1) /* 01: [V3] System has an 8042 
controller on port 60/64 */
@@ -296,6 +297,11 @@ struct acpi_table_fadt {
 
 #define FADT2_REVISION_ID   3
 
+/* Masks for FADT ARM Boot Architecture Flags (arm_boot_flags) ACPI 5.1 */
+
+#define ACPI_FADT_PSCI_COMPLIANT(1)/* 00: [V5+] PSCI 0.2+ is 
implemented */
+#define ACPI_FADT_PSCI_USE_HVC  (1<<1) /* 01: [V5+] HVC must be used 
instead of SMC as the PSCI conduit */
+
 /* Masks for FADT flags */
 
 #define ACPI_FADT_WBINVD(1)/* 00: [V1] The WBINVD 
instruction works properly */
@@ -399,7 +405,7 @@ struct acpi_table_desc {
  * FADT V5  size: 0x10C
  */
 #define ACPI_FADT_V1_SIZE   (u32) (ACPI_FADT_OFFSET (flags) + 4)
-#define ACPI_FADT_V2_SIZE   (u32) (ACPI_FADT_OFFSET (reserved4[0]) + 3)
+#define ACPI_FADT_V2_SIZE   (u32) (ACPI_FADT_OFFSET (minor_revision) + 1)
 #define ACPI_FADT_V3_SIZE   (u32) (ACPI_FADT_OFFSET (sleep_control))
 #define ACPI_FADT_V5_SIZE   (u32) (sizeof (struct acpi_table_fadt))
 
-- 
1.7.10

--
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 08/17] ACPICA: acpihelp: Add UUID support, restructure some existing files.

[Lv Zheng]

From: Bob Moore 

This adds a -u option to acpi_help to display all known ACPI UUIDs.
Some existing files in the core code have been restructured.
Three new files.

[zetalog: changing drivers/acpi/acpica/Makefile accordingly]

Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/Makefile   |8 +++-
 drivers/acpi/acpica/aclocal.h  |5 ++
 drivers/acpi/acpica/acutils.h  |9 
 drivers/acpi/acpica/utdecode.c |   27 ---
 drivers/acpi/acpica/uthex.c|  100 
 drivers/acpi/acpica/utuuid.c   |   96 ++
 6 files changed, 217 insertions(+), 28 deletions(-)
 create mode 100644 drivers/acpi/acpica/uthex.c
 create mode 100644 drivers/acpi/acpica/utuuid.c

diff --git a/drivers/acpi/acpica/Makefile b/drivers/acpi/acpica/Makefile
index 4be4cc94..c1a9635 100644
--- a/drivers/acpi/acpica/Makefile
+++ b/drivers/acpi/acpica/Makefile
@@ -157,6 +157,7 @@ acpi-y +=   \
uterror.o   \
uteval.o\
utglobal.o  \
+   uthex.o \
utids.o \
utinit.o\
utlock.o\
@@ -175,5 +176,10 @@ acpi-y +=  \
utxferror.o \
utxfmutex.o
 
-acpi-$(ACPI_FUTURE_USAGE) += utfileio.o utprint.o uttrack.o utcache.o
+acpi-$(ACPI_FUTURE_USAGE) +=   \
+   utcache.o   \
+   utfileio.o  \
+   utprint.o   \
+   uttrack.o   \
+   utuuid.o
 
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 4c9fd7c..1f9aba5 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -1155,4 +1155,9 @@ struct ah_device_id {
char *description;
 };
 
+struct ah_uuid {
+   char *description;
+   char *string;
+};
+
 #endif /* __ACLOCAL_H__ */
diff --git a/drivers/acpi/acpica/acutils.h b/drivers/acpi/acpica/acutils.h
index ed614f4..486d342 100644
--- a/drivers/acpi/acpica/acutils.h
+++ b/drivers/acpi/acpica/acutils.h
@@ -194,6 +194,8 @@ char *acpi_ut_get_event_name(u32 event_id);
 
 char acpi_ut_hex_to_ascii_char(u64 integer, u32 position);
 
+u8 acpi_ut_ascii_char_to_hex(int hex_char);
+
 u8 acpi_ut_valid_object_type(acpi_object_type type);
 
 /*
@@ -759,6 +761,8 @@ const struct ah_predefined_name 
*acpi_ah_match_predefined_name(char *nameseg);
 
 const struct ah_device_id *acpi_ah_match_hardware_id(char *hid);
 
+const char *acpi_ah_match_uuid(u8 *data);
+
 /*
  * utprint - printf/vprintf output functions
  */
@@ -778,4 +782,9 @@ int acpi_ut_file_vprintf(ACPI_FILE file, const char 
*format, va_list args);
 int acpi_ut_file_printf(ACPI_FILE file, const char *format, ...);
 #endif
 
+/*
+ * utuuid -- UUID support functions
+ */
+void acpi_ut_convert_string_to_uuid(char *in_string, u8 *uuid_buffer);
+
 #endif /* _ACUTILS_H */
diff --git a/drivers/acpi/acpica/utdecode.c b/drivers/acpi/acpica/utdecode.c
index 90ec37c..98f5418 100644
--- a/drivers/acpi/acpica/utdecode.c
+++ b/drivers/acpi/acpica/utdecode.c
@@ -88,33 +88,6 @@ const u8 acpi_gbl_ns_properties[ACPI_NUM_NS_TYPES] = {
 
 
/***
  *
- * FUNCTION:acpi_ut_hex_to_ascii_char
- *
- * PARAMETERS:  integer - Contains the hex digit
- *  position- bit position of the digit within the
- *integer (multiple of 4)
- *
- * RETURN:  The converted Ascii character
- *
- * DESCRIPTION: Convert a hex digit to an Ascii character
- *
- 
**/
-
-/* Hex to ASCII conversion table */
-
-static const char acpi_gbl_hex_to_ascii[] = {
-   '0', '1', '2', '3', '4', '5', '6', '7',
-   '8', '9', 'A', 'B', 'C', 'D', 'E', 'F'
-};
-
-char acpi_ut_hex_to_ascii_char(u64 integer, u32 position)
-{
-
-   return (acpi_gbl_hex_to_ascii[(integer >> position) & 0xF]);
-}
-
-/***
- *
  * FUNCTION:acpi_ut_get_region_name
  *
  * PARAMETERS:  Space ID- ID for the region
diff --git a/drivers/acpi/acpica/uthex.c b/drivers/acpi/acpica/uthex.c
new file mode 100644
index 000..9afa944
--- /dev/null
+++ b/drivers/acpi/acpica/uthex.c
@@ -0,0 +1,100 @@
+/**
+ *
+ * Module Name: uthex -- Hex/ASCII support functions
+ *
+ */
+
+/*
+ * Copyright (C) 2000 - 2014, Intel Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, and the following d

[PATCH 15/17] ACPICA/ARM: ACPI 5.1: Update for GTDT table changes.

[Lv Zheng]

From: Tomasz Nowicki 

New fields and new subtables. Tomasz Nowicki.
tomasz.nowi...@linaro.org

Signed-off-by: Tomasz Nowicki 
Signed-off-by: Hanjun Guo 
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 include/acpi/actbl3.h |   93 +
 1 file changed, 78 insertions(+), 15 deletions(-)

diff --git a/include/acpi/actbl3.h b/include/acpi/actbl3.h
index c2295cc..41ad964 100644
--- a/include/acpi/actbl3.h
+++ b/include/acpi/actbl3.h
@@ -241,33 +241,96 @@ struct acpi_s3pt_suspend {
 
 
/***
  *
- * GTDT - Generic Timer Description Table (ACPI 5.0)
- *Version 1
+ * GTDT - Generic Timer Description Table (ACPI 5.1)
+ *Version 2
  *
  
**/
 
 struct acpi_table_gtdt {
struct acpi_table_header header;/* Common ACPI table header */
-   u64 address;
-   u32 flags;
-   u32 secure_pl1_interrupt;
-   u32 secure_pl1_flags;
-   u32 non_secure_pl1_interrupt;
-   u32 non_secure_pl1_flags;
+   u64 counter_block_addresss;
+   u32 reserved;
+   u32 secure_el1_interrupt;
+   u32 secure_el1_flags;
+   u32 non_secure_el1_interrupt;
+   u32 non_secure_el1_flags;
u32 virtual_timer_interrupt;
u32 virtual_timer_flags;
-   u32 non_secure_pl2_interrupt;
-   u32 non_secure_pl2_flags;
+   u32 non_secure_el2_interrupt;
+   u32 non_secure_el2_flags;
+   u64 counter_read_block_address;
+   u32 platform_timer_count;
+   u32 platform_timer_offset;
 };
 
-/* Values for Flags field above */
+/* Flag Definitions: Timer Block Physical Timers and Virtual timers */
+
+#define ACPI_GTDT_INTERRUPT_MODE(1)
+#define ACPI_GTDT_INTERRUPT_POLARITY(1<<1)
+#define ACPI_GTDT_ALWAYS_ON (1<<2)
+
+/* Common GTDT subtable header */
+
+struct acpi_gtdt_header {
+   u8 type;
+   u16 length;
+};
+
+/* Values for GTDT subtable type above */
+
+enum acpi_gtdt_type {
+   ACPI_GTDT_TYPE_TIMER_BLOCK = 0,
+   ACPI_GTDT_TYPE_WATCHDOG = 1,
+   ACPI_GTDT_TYPE_RESERVED = 2 /* 2 and greater are reserved */
+};
 
-#define ACPI_GTDT_MAPPED_BLOCK_PRESENT  1
+/* GTDT Subtables, correspond to Type in struct acpi_gtdt_header */
+
+/* 0: Generic Timer Block */
+
+struct acpi_gtdt_timer_block {
+   struct acpi_gtdt_header header;
+   u8 reserved;
+   u64 block_address;
+   u32 timer_count;
+   u32 timer_offset;
+};
+
+/* Timer Sub-Structure, one per timer */
+
+struct acpi_gtdt_timer_entry {
+   u8 frame_number;
+   u8 reserved[3];
+   u64 base_address;
+   u64 el0_base_address;
+   u32 timer_interrupt;
+   u32 timer_flags;
+   u32 virtual_timer_interrupt;
+   u32 virtual_timer_flags;
+   u32 common_flags;
+};
+
+/* Flag Definitions: common_flags above */
+
+#define ACPI_GTDT_GT_IS_SECURE_TIMER(1)
+#define ACPI_GTDT_GT_ALWAYS_ON  (1<<1)
+
+/* 1: SBSA Generic Watchdog Structure */
+
+struct acpi_gtdt_watchdog {
+   struct acpi_gtdt_header header;
+   u8 reserved;
+   u64 refresh_frame_address;
+   u64 control_frame_address;
+   u32 timer_interrupt;
+   u32 timer_flags;
+};
 
-/* Values for all "TimerFlags" fields above */
+/* Flag Definitions: timer_flags above */
 
-#define ACPI_GTDT_INTERRUPT_MODE1
-#define ACPI_GTDT_INTERRUPT_POLARITY2
+#define ACPI_GTDT_WATCHDOG_IRQ_MODE (1)
+#define ACPI_GTDT_WATCHDOG_IRQ_POLARITY (1<<1)
+#define ACPI_GTDT_WATCHDOG_SECURE   (1<<2)
 
 
/***
  *
-- 
1.7.10

--
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 01/17] ACPICA: Work around an ancient GCC bug.

[Lv Zheng]

From: Bob Moore 

warning: cast from function call of type 'char *' to non-matching type 'long 
unsigned int'

Since acpi_ut_format_number() hasn't been enabled for the Linux kernel,
this patch doesn't affect the Linux kernel.

Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/utprint.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/acpica/utprint.c b/drivers/acpi/acpica/utprint.c
index 1031164..080e22a 100644
--- a/drivers/acpi/acpica/utprint.c
+++ b/drivers/acpi/acpica/utprint.c
@@ -242,6 +242,7 @@ static char *acpi_ut_format_number(char *string,
   u64 number,
   u8 base, s32 width, s32 precision, u8 type)
 {
+   char *pos;
char sign;
char zero;
u8 need_prefix;
@@ -289,9 +290,8 @@ static char *acpi_ut_format_number(char *string,
 
/* Generate full string in reverse order */
 
-   i = ACPI_PTR_DIFF(acpi_ut_put_number
- (reversed_string, number, base, upper),
- reversed_string);
+   pos = acpi_ut_put_number(reversed_string, number, base, upper);
+   i = ACPI_PTR_DIFF(pos, reversed_string);
 
/* Printing 100 using %2d gives "100", not "00" */
 
-- 
1.7.10

--
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 04/17] ACPICA: Update for comments/formatting. No functional changes.

[Lv Zheng]

From: Bob Moore 

Fix some issues detected by acpisrc utility.

Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/exfield.c |   22 ++
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/acpi/acpica/exfield.c b/drivers/acpi/acpica/exfield.c
index 1ff42c0..6907ce0 100644
--- a/drivers/acpi/acpica/exfield.c
+++ b/drivers/acpi/acpica/exfield.c
@@ -186,12 +186,11 @@ acpi_ex_read_data_from_field(struct acpi_walk_state * 
walk_state,
  
access_length);
 
/*
-* Add additional 2 bytes for modeled 
generic_serial_bus data buffer:
-* typedef struct {
-* BYTEStatus; // Byte 0 of the data buffer
-* BYTELength; // Byte 1 of the data buffer
-* BYTE[x-1]Data; // Bytes 2-x of the arbitrary 
length data buffer,
-* }
+* Add additional 2 bytes for the generic_serial_bus 
data buffer:
+*
+* Status;  (Byte 0 of the data buffer)
+* Length;  (Byte 1 of the data buffer)
+* Data[x-1];   (Bytes 2-x of the arbitrary length 
data buffer)
 */
length += 2;
function = ACPI_READ | (accessor_type << 16);
@@ -368,12 +367,11 @@ acpi_ex_write_data_to_field(union acpi_operand_object 
*source_desc,
  
access_length);
 
/*
-* Add additional 2 bytes for modeled 
generic_serial_bus data buffer:
-* typedef struct {
-* BYTEStatus; // Byte 0 of the data buffer
-* BYTELength; // Byte 1 of the data buffer
-* BYTE[x-1]Data; // Bytes 2-x of the arbitrary 
length data buffer,
-* }
+* Add additional 2 bytes for the generic_serial_bus 
data buffer:
+*
+* Status;  (Byte 0 of the data buffer)
+* Length;  (Byte 1 of the data buffer)
+* Data[x-1];   (Bytes 2-x of the arbitrary length 
data buffer)
 */
length += 2;
function = ACPI_WRITE | (accessor_type << 16);
-- 
1.7.10

--
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 03/17] ACPICA: Disassembler: Add support for the ToUUID opererator (macro).

[Lv Zheng]

From: Bob Moore 

This change adds support to disassemble a UUID back to the original
ToUUID operator. It will detect a UUID within a standard AML Buffer.
Also, a description of the UUID is emitted for "known" UUIDs, defined
as UUIDs that are defined in the ACPI specification.

Since this is a change for disassembler which is not shipped in the
Linux kernel, the Linux kernel is not affected.

Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/aclocal.h |   13 +++--
 include/acpi/acconfig.h   |   18 ++
 2 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 91f801a..4c9fd7c 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -730,12 +730,13 @@ union acpi_parse_value {
 #define ACPI_DASM_STRING0x02   /* Buffer is a ASCII string */
 #define ACPI_DASM_UNICODE   0x03   /* Buffer is a Unicode string */
 #define ACPI_DASM_PLD_METHOD0x04   /* Buffer is a _PLD method 
bit-packed buffer */
-#define ACPI_DASM_EISAID0x05   /* Integer is an EISAID */
-#define ACPI_DASM_MATCHOP   0x06   /* Parent opcode is a Match() 
operator */
-#define ACPI_DASM_LNOT_PREFIX   0x07   /* Start of a Lnot_equal (etc.) 
pair of opcodes */
-#define ACPI_DASM_LNOT_SUFFIX   0x08   /* End  of a Lnot_equal (etc.) 
pair of opcodes */
-#define ACPI_DASM_HID_STRING0x09   /* String is a _HID or _CID */
-#define ACPI_DASM_IGNORE0x0A   /* Not used at this time */
+#define ACPI_DASM_UUID  0x05   /* Buffer is a UUID/GUID */
+#define ACPI_DASM_EISAID0x06   /* Integer is an EISAID */
+#define ACPI_DASM_MATCHOP   0x07   /* Parent opcode is a Match() 
operator */
+#define ACPI_DASM_LNOT_PREFIX   0x08   /* Start of a Lnot_equal (etc.) 
pair of opcodes */
+#define ACPI_DASM_LNOT_SUFFIX   0x09   /* End  of a Lnot_equal (etc.) 
pair of opcodes */
+#define ACPI_DASM_HID_STRING0x0A   /* String is a _HID or _CID */
+#define ACPI_DASM_IGNORE0x0B   /* Not used at this time */
 
 /*
  * Generic operation (for example:  If, While, Store)
diff --git a/include/acpi/acconfig.h b/include/acpi/acconfig.h
index 932a60d..5a0a3e5 100644
--- a/include/acpi/acconfig.h
+++ b/include/acpi/acconfig.h
@@ -219,6 +219,24 @@
 
 /**
  *
+ * Miscellaneous constants
+ *
+ */
+
+/* UUID constants */
+
+#define UUID_BUFFER_LENGTH  16 /* Length of UUID in memory */
+#define UUID_STRING_LENGTH  36 /* Total length of a UUID string */
+
+/* Positions for required hyphens (dashes) in UUID strings */
+
+#define UUID_HYPHEN1_OFFSET 8
+#define UUID_HYPHEN2_OFFSET 13
+#define UUID_HYPHEN3_OFFSET 18
+#define UUID_HYPHEN4_OFFSET 23
+
+/**
+ *
  * ACPI AML Debugger
  *
  */
-- 
1.7.10

--
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 09/17] ACPICA: Debug object: Add current value of Timer() to debug line prefix.

[Lv Zheng]

From: Bob Moore 

Simplifies timing of things like control method execution.

[zetalog: fixing 64-bit division link error]

Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/exdebug.c |   11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/acpica/exdebug.c b/drivers/acpi/acpica/exdebug.c
index 4cfc3d3..6fbfad4 100644
--- a/drivers/acpi/acpica/exdebug.c
+++ b/drivers/acpi/acpica/exdebug.c
@@ -75,6 +75,7 @@ acpi_ex_do_debug_object(union acpi_operand_object 
*source_desc,
u32 level, u32 index)
 {
u32 i;
+   u32 timer;
 
ACPI_FUNCTION_TRACE_PTR(ex_do_debug_object, source_desc);
 
@@ -86,11 +87,19 @@ acpi_ex_do_debug_object(union acpi_operand_object 
*source_desc,
}
 
/*
+* We will emit the current timer value (in microseconds) with each
+* debug output. Only need the lower 26 bits. This allows for 67
+* million microseconds or 67 seconds before rollover.
+*/
+   timer = ((u32)acpi_os_get_timer() / 10);/* (100 nanoseconds to 
microseconds) */
+   timer &= 0x03FF;
+
+   /*
 * Print line header as long as we are not in the middle of an
 * object display
 */
if (!((level > 0) && index == 0)) {
-   acpi_os_printf("[ACPI Debug] %*s", level, " ");
+   acpi_os_printf("[ACPI Debug %.8u] %*s", timer, level, " ");
}
 
/* Display the index for package output only */
-- 
1.7.10

--
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 06/17] ACPICA: Tables: Update for DMAR table changes.

[Lv Zheng]

From: Bob Moore 

Update table compiler and disassembler for new DMAR fields introduced
in Sept. 2013.
Note that Linux DMAR users need to be updated after applying this change.

[zetalog: changing drivers/iommu/dmar.c accordingly]

Cc: David Woodhouse 
Cc: io...@lists.linux-foundation.org
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 drivers/iommu/dmar.c  |   28 ++--
 include/acpi/actbl2.h |   14 +++---
 2 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 9a4f05e..bbe33a8 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -84,7 +84,7 @@ void *dmar_alloc_dev_scope(void *start, void *end, int *cnt)
*cnt = 0;
while (start < end) {
scope = start;
-   if (scope->entry_type == ACPI_DMAR_SCOPE_TYPE_ACPI ||
+   if (scope->entry_type == ACPI_DMAR_SCOPE_TYPE_NAMESPACE ||
scope->entry_type == ACPI_DMAR_SCOPE_TYPE_ENDPOINT ||
scope->entry_type == ACPI_DMAR_SCOPE_TYPE_BRIDGE)
(*cnt)++;
@@ -380,7 +380,7 @@ static int __init dmar_parse_one_andd(struct 
acpi_dmar_header *header)
struct acpi_dmar_andd *andd = (void *)header;
 
/* Check for NUL termination within the designated length */
-   if (strnlen(andd->object_name, header->length - 8) == header->length - 
8) {
+   if (strnlen(andd->device_name, header->length - 8) == header->length - 
8) {
WARN_TAINT(1, TAINT_FIRMWARE_WORKAROUND,
   "Your BIOS is broken; ANDD object name is not 
NUL-terminated\n"
   "BIOS vendor: %s; Ver: %s; Product Version: %s\n",
@@ -390,7 +390,7 @@ static int __init dmar_parse_one_andd(struct 
acpi_dmar_header *header)
return -EINVAL;
}
pr_info("ANDD device: %x name: %s\n", andd->device_number,
-   andd->object_name);
+   andd->device_name);
 
return 0;
 }
@@ -448,17 +448,17 @@ dmar_table_print_dmar_entry(struct acpi_dmar_header 
*header)
(unsigned long long)rmrr->base_address,
(unsigned long long)rmrr->end_address);
break;
-   case ACPI_DMAR_TYPE_ATSR:
+   case ACPI_DMAR_TYPE_ROOT_ATS:
atsr = container_of(header, struct acpi_dmar_atsr, header);
pr_info("ATSR flags: %#x\n", atsr->flags);
break;
-   case ACPI_DMAR_HARDWARE_AFFINITY:
+   case ACPI_DMAR_TYPE_HARDWARE_AFFINITY:
rhsa = container_of(header, struct acpi_dmar_rhsa, header);
pr_info("RHSA base: %#016Lx proximity domain: %#x\n",
   (unsigned long long)rhsa->base_address,
   rhsa->proximity_domain);
break;
-   case ACPI_DMAR_TYPE_ANDD:
+   case ACPI_DMAR_TYPE_NAMESPACE:
/* We don't print this here because we need to sanity-check
   it first. So print it in dmar_parse_one_andd() instead. */
break;
@@ -539,15 +539,15 @@ parse_dmar_table(void)
case ACPI_DMAR_TYPE_RESERVED_MEMORY:
ret = dmar_parse_one_rmrr(entry_header);
break;
-   case ACPI_DMAR_TYPE_ATSR:
+   case ACPI_DMAR_TYPE_ROOT_ATS:
ret = dmar_parse_one_atsr(entry_header);
break;
-   case ACPI_DMAR_HARDWARE_AFFINITY:
+   case ACPI_DMAR_TYPE_HARDWARE_AFFINITY:
 #ifdef CONFIG_ACPI_NUMA
ret = dmar_parse_one_rhsa(entry_header);
 #endif
break;
-   case ACPI_DMAR_TYPE_ANDD:
+   case ACPI_DMAR_TYPE_NAMESPACE:
ret = dmar_parse_one_andd(entry_header);
break;
default:
@@ -631,7 +631,7 @@ static void __init dmar_acpi_insert_dev_scope(u8 
device_number,
for (scope = (void *)(drhd + 1);
 (unsigned long)scope < ((unsigned long)drhd) + 
drhd->header.length;
 scope = ((void *)scope) + scope->length) {
-   if (scope->entry_type != ACPI_DMAR_SCOPE_TYPE_ACPI)
+   if (scope->entry_type != ACPI_DMAR_SCOPE_TYPE_NAMESPACE)
continue;
if (scope->enumeration_id != device_number)
continue;
@@ -666,21 +666,21 @@ static int __init dmar_acpi_dev_scope_init(void)
for (andd = (void *)dmar_tbl + sizeof(struct acpi_table_dmar);
 ((unsigned long)andd) < ((unsigned long)dmar_tbl) + 
dmar_tbl->length;
 andd = ((void *)andd) + andd->header.length) {
-   if (andd->header.type == ACPI_DMAR_TYPE_ANDD) {
+   if (andd->header.type == ACPI_DMAR_TYPE_NAMESPACE) {
acpi_handle h;

[PATCH 02/17] ACPICA: Remove a redundant cast to acpi_size for ACPI_OFFSET() macro.

[Lv Zheng]

From: Bob Moore 

It is already casted to acpi_size by ACPI_PTR_DIFF() macro.

Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 include/acpi/actypes.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h
index 608a040..4d9b29c 100644
--- a/include/acpi/actypes.h
+++ b/include/acpi/actypes.h
@@ -517,7 +517,7 @@ typedef u64 acpi_integer;
 
 #define ACPI_TO_POINTER(i)  ACPI_ADD_PTR (void, (void *) 
NULL,(acpi_size) i)
 #define ACPI_TO_INTEGER(p)  ACPI_PTR_DIFF (p, (void *) NULL)
-#define ACPI_OFFSET(d, f)   (acpi_size) ACPI_PTR_DIFF (&(((d 
*)0)->f), (void *) NULL)
+#define ACPI_OFFSET(d, f)   ACPI_PTR_DIFF (&(((d *) 0)->f), (void 
*) NULL)
 #define ACPI_PHYSADDR_TO_PTR(i) ACPI_TO_POINTER(i)
 #define ACPI_PTR_TO_PHYSADDR(i) ACPI_TO_INTEGER(i)
 
-- 
1.7.10

--
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 00/17] ACPICA: 20140724 Release

[Lv Zheng]

The 20140724 ACPICA kernel-resident subsystem updates are linuxized based
on the pm/linux-next branch to form this patchset.

The patchset has passed the following build/boot tests.
Build tests are performed as follows:
1. i386 + default + COFNIG_ACPI=y
2. i386 + allyes + CONFIG_ACPI=y
3. i386 + default + COFNIG_ACPI=n
4. i386 + allyes + CONFIG_ACPI=n
5. x86_64 + default + COFNIG_ACPI=y
6. x86_64 + allyes + CONFIG_ACPI=y
7. x86_64 + default + COFNIG_ACPI=n
8. x86_64 + allyes + CONFIG_ACPI=n
Boot tests are performed as follows:
1. i386 + default + COFNIG_ACPI=y
2. x86_64 + default + COFNIG_ACPI=y
Where:
1. i386: machine named as "Dell Inspiron Mini 1010"
2. x86_64: machine named as "HP Compaq 8200 Elite SFF PC"
3. default: kernel configuration with following items enabled:
   All hardware drivers related to the machines of i386/x86_64
   All drivers/acpi configurations
   All platform drivers

The divergences checking result:
Before applying:
  861 lines
After applying:
  848 lines

Bob Moore (11):
  ACPICA: Work around an ancient GCC bug.
  ACPICA: Remove a redundant cast to acpi_size for ACPI_OFFSET() macro.
  ACPICA: Disassembler: Add support for the ToUUID opererator (macro).
  ACPICA: Update for comments/formatting. No functional changes.
  ACPICA: Tables: Update for DMAR table changes.
  ACPICA: acpihelp: Add UUID support, restructure some existing files.
  ACPICA: Debug object: Add current value of Timer() to debug line
prefix.
  ACPICA: ACPI 5.1: New notify value for System Affinity Update.
  ACPICA: ACPI 5.1: Support for the _CCA predifined name.
  ACPICA: ACPI 5.1: Update for PCCT table changes.
  ACPICA: Update version to 20140724.

David E. Box (1):
  ACPICA: ACPI 5.1: Support for the _DSD predefined name.

Graeme Gregory (1):
  ACPICA/ARM: ACPI 5.1: Update for FADT changes.

Lv Zheng (1):
  ACPICA: Utilities: Fix local printf issue.

Sascha Wildner (1):
  ACPICA: Remove some extraneous printf arguments.

Tomasz Nowicki (2):
  ACPICA/ARM: ACPI 5.1: Update for MADT changes.
  ACPICA/ARM: ACPI 5.1: Update for GTDT table changes.

 drivers/acpi/acpica/Makefile   |8 ++-
 drivers/acpi/acpica/aclocal.h  |   18 --
 drivers/acpi/acpica/acpredef.h |   16 +-
 drivers/acpi/acpica/acutils.h  |9 +++
 drivers/acpi/acpica/exdebug.c  |   11 +++-
 drivers/acpi/acpica/exdump.c   |6 +-
 drivers/acpi/acpica/exfield.c  |   22 
 drivers/acpi/acpica/utdecode.c |   32 +--
 drivers/acpi/acpica/utfileio.c |3 +-
 drivers/acpi/acpica/uthex.c|  100 ++
 drivers/acpi/acpica/utprint.c  |9 ++-
 drivers/acpi/acpica/utuuid.c   |   96 
 drivers/iommu/dmar.c   |   28 +-
 include/acpi/acconfig.h|   18 ++
 include/acpi/acnames.h |1 +
 include/acpi/acpixf.h  |2 +-
 include/acpi/actbl.h   |   12 +++-
 include/acpi/actbl1.h  |   44 ++-
 include/acpi/actbl2.h  |   14 ++---
 include/acpi/actbl3.h  |  118 ++--
 include/acpi/actypes.h |5 +-
 21 files changed, 468 insertions(+), 104 deletions(-)
 create mode 100644 drivers/acpi/acpica/uthex.c
 create mode 100644 drivers/acpi/acpica/utuuid.c

-- 
1.7.10

--
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 11/11] seccomp: Add tgid and tid into seccomp_data

[Eric W. Biederman]

Andy Lutomirski  writes:

> On Mon, Jul 28, 2014 at 2:18 PM, Eric W. Biederman
>  wrote:
>> Andy Lutomirski  writes:
>>
>>> [cc: Eric Biederman]
>>>
>>
>>> Can we do one better and add a flag to prevent any non-self pid
>>> lookups?  This might actually be easy on top of the pid namespace work
>>> (e.g. we could change the way that find_task_by_vpid works).
>>>
>>> It's far from just being signals.  There's access_process_vm, ptrace,
>>> all the signal functions, clock_gettime (see CPUCLOCK_PID -- yes, this
>>> is ridiculous), and probably some others that I've forgotten about or
>>> never noticed in the first place.
>>
>> So here is the practical question.
>>
>> Are these processes that only can send signals to their thread group
>> allowed to call fork()?
>>
>>
>> If fork is allowed and all pid lookups are restricted to their own
>> thread group that wait, waitpid, and all of the rest of the wait family
>> will never return the pids of their children, and zombies will
>> accumulate.  Aka the semantics are fundamentally broken.
>
> Good point.
>
> I can imagine at least three ways that fork() could continue working, though:
>
> 1. Allow lookups of immediate children, too.  (I don't love this one.)
> 2. Allow non-self pids to be translated in but not out.  This way
> P_ALL will continue working.
> 3. Have the kernel treat any PID-restricted process as though it were 
> NOCLDWAIT.
>
> I think I like #3.  Thoughts?
>
>>
>> If fork is not allowed pid namespaces already solve this problem.
>
> PID namespaces are fairly heavyweight.  Julien pointed out that using
> PID namespaces requires a bunch of dummy PID 1 processes.

Only if you can't tolerate init exiting.  The reasoning with respect to
signals and signals being ignored was wrong.  And if you only have one
process you care about and no children to worry about neither the
difference in signal handling nor the world dies whe init exits applies.

Therefore given what I have read described pid namespaces are a trivial
solution to this problem space.

Eric

--
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] mmc: mmci: Add qcom dml support to the driver.

[Srinivas Kandagatla]

If its not too late, is it possible to queue this patch for v3.17?


---
srini

On 29/07/14 03:50, Srinivas Kandagatla wrote:

On Qualcomm APQ8064 SOCs, SD card controller has an additional glue
called DML (Data Mover Local/Lite) to assist dma transfers.
This hardware needs to be setup before any dma transfer is requested.
DML itself is not a DMA engine, its just a gule between the SD card
controller and dma controller.

Most of this code has been ported from qualcomm's 3.4 kernel.

This patch adds the code necessary to intialize the hardware and setup
before doing any dma transfers.

Reviewed-by: Linus Walleij 
Signed-off-by: Srinivas Kandagatla 
---
Changes since v3:
   - moved copyright from Code Aurora to Linux Foundation, as
 suggested by Stephen B.

Changes since v2:
   - copied missing memory barriers from 3.4 driver, spotted by Stephen B.
   - removed unecessary braceses spotted by Stephen B.
   - copied exact copyright year from 3.4 kernel.

Changes since v1:
- Added licence text as spotted by Stephen B.
- Simplified dma channel lookup as suggested by Stephen B.
- Removed unnecessary parens spotted by Stephen B.
- in general some cleanup done.

Changes since RFC:
 - Moved qcom_dml.* to mmci_qcom_dml.* as suggested by Linus W.
 - added BAM DMA dependency in Kconfig as suggested by Linus W.

  drivers/mmc/host/Kconfig |  11 +++
  drivers/mmc/host/Makefile|   1 +
  drivers/mmc/host/mmci.c  |  18 +++-
  drivers/mmc/host/mmci_qcom_dml.c | 177 +++
  drivers/mmc/host/mmci_qcom_dml.h |  31 +++
  5 files changed, 237 insertions(+), 1 deletion(-)
  create mode 100644 drivers/mmc/host/mmci_qcom_dml.c
  create mode 100644 drivers/mmc/host/mmci_qcom_dml.h

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index a565254..3d9b84d 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -14,6 +14,17 @@ config MMC_ARMMMCI

  If unsure, say N.

+config MMC_QCOM_DML
+   tristate "Qualcomm Data Mover for SD Card Controller"
+   depends on MMC_ARMMMCI && QCOM_BAM_DMA
+   default y
+   help
+ This selects the Qualcomm Data Mover lite/local on SD Card controller.
+ This option will enable the dma to work correctly, if you are using
+ Qcom SOCs and MMC, you would probably need this option to get DMA 
working.
+
+ if unsure, say N.
+
  config MMC_PXA
tristate "Intel PXA25x/26x/27x Multimedia Card Interface support"
depends on ARCH_PXA
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 7f81ddf..344c870 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -3,6 +3,7 @@
  #

  obj-$(CONFIG_MMC_ARMMMCI) += mmci.o
+obj-$(CONFIG_MMC_QCOM_DML) += mmci_qcom_dml.o
  obj-$(CONFIG_MMC_PXA) += pxamci.o
  obj-$(CONFIG_MMC_MXC) += mxcmmc.o
  obj-$(CONFIG_MMC_MXS) += mxs-mmc.o
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index b66b351..9059570 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -43,6 +43,7 @@
  #include 

  #include "mmci.h"
+#include "mmci_qcom_dml.h"

  #define DRIVER_NAME "mmci-pl18x"

@@ -74,6 +75,7 @@ static unsigned int fmax = 515633;
   * @pwrreg_nopower: bits in MMCIPOWER don't controls ext. power supply
   * @explicit_mclk_control: enable explicit mclk control in driver.
   * @qcom_fifo: enables qcom specific fifo pio read logic.
+ * @qcom_dml: enables qcom specific dma glue for dma transfers.
   */
  struct variant_data {
unsigned intclkreg;
@@ -97,6 +99,7 @@ struct variant_data {
boolpwrreg_nopower;
boolexplicit_mclk_control;
boolqcom_fifo;
+   boolqcom_dml;
  };

  static struct variant_data variant_arm = {
@@ -205,6 +208,7 @@ static struct variant_data variant_qcom = {
.f_max  = 20800,
.explicit_mclk_control  = true,
.qcom_fifo  = true,
+   .qcom_dml   = true,
  };

  static int mmci_card_busy(struct mmc_host *mmc)
@@ -418,6 +422,7 @@ static void mmci_dma_setup(struct mmci_host *host)
  {
const char *rxname, *txname;
dma_cap_mask_t mask;
+   struct variant_data *variant = host->variant;

host->dma_rx_channel = dma_request_slave_channel(mmc_dev(host->mmc), 
"rx");
host->dma_tx_channel = dma_request_slave_channel(mmc_dev(host->mmc), 
"tx");
@@ -468,6 +473,10 @@ static void mmci_dma_setup(struct mmci_host *host)
if (max_seg_size < host->mmc->max_seg_size)
host->mmc->max_seg_size = max_seg_size;
}
+
+   if (variant->qcom_dml && host->dma_rx_channel && host->dma_tx_channel)
+   if (dml_hw_init(host, host->mmc->parent->of_node))
+   variant->qcom_dml = false;
  }

  /*
@@ -569,6 +578,7 @@ static int 

Re: [PATCH 11/11] seccomp: Add tgid and tid into seccomp_data

[Andy Lutomirski]

On Mon, Jul 28, 2014 at 2:18 PM, Eric W. Biederman
 wrote:
> Andy Lutomirski  writes:
>
>> [cc: Eric Biederman]
>>
>
>> Can we do one better and add a flag to prevent any non-self pid
>> lookups?  This might actually be easy on top of the pid namespace work
>> (e.g. we could change the way that find_task_by_vpid works).
>>
>> It's far from just being signals.  There's access_process_vm, ptrace,
>> all the signal functions, clock_gettime (see CPUCLOCK_PID -- yes, this
>> is ridiculous), and probably some others that I've forgotten about or
>> never noticed in the first place.
>
> So here is the practical question.
>
> Are these processes that only can send signals to their thread group
> allowed to call fork()?
>
>
> If fork is allowed and all pid lookups are restricted to their own
> thread group that wait, waitpid, and all of the rest of the wait family
> will never return the pids of their children, and zombies will
> accumulate.  Aka the semantics are fundamentally broken.

Good point.

I can imagine at least three ways that fork() could continue working, though:

1. Allow lookups of immediate children, too.  (I don't love this one.)
2. Allow non-self pids to be translated in but not out.  This way
P_ALL will continue working.
3. Have the kernel treat any PID-restricted process as though it were NOCLDWAIT.

I think I like #3.  Thoughts?

>
> If fork is not allowed pid namespaces already solve this problem.

PID namespaces are fairly heavyweight.  Julien pointed out that using
PID namespaces requires a bunch of dummy PID 1 processes.

--Andy
--
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/

Work Queue for btrfs compression writes

[Nick Krause]

Hey Guys ,
I am new to   reading  and writing  kernel code.I got interested in
writing code for btrfs as it seems to
need more work then other file systems and this seems other then
drivers, a good use of time on my part.
I interested in helping improving the compression of btrfs by using  a
set of threads using work queues like XFS
or reads and keeping the page cache after reading compressed blocks as
these seem to be a great way to improve
on  compression performance mostly with large partitions of compressed
data. I am not asking you to write the code
for me but as I am new a little guidance and help would be greatly
appreciated as this seems like too much work for just a newbie.
Thanks A lot,
Nick
--
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/

[vmstat] kernel BUG at mm/vmstat.c:1278!

[Fengguang Wu]

Greetings,

0day kernel testing robot got the below dmesg and the first bad commit is

git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 6e0a6b18b63e2c0a45ff47ab633dd6f3ad417453
Author: Christoph Lameter 
AuthorDate: Wed Jul 23 09:11:43 2014 +1000
Commit: Stephen Rothwell 
CommitDate: Wed Jul 23 09:11:43 2014 +1000

vmstat: On demand vmstat workers V8

vmstat workers are used for folding counter differentials into the zone,
per node and global counters at certain time intervals.  They currently
run at defined intervals on all processors which will cause some holdoff
for processors that need minimal intrusion by the OS.

The current vmstat_update mechanism depends on a deferrable timer firing
every other second by default which registers a work queue item that runs
on the local CPU, with the result that we have 1 interrupt and one
additional schedulable task on each CPU every 2 seconds If a workload
indeed causes VM activity or multiple tasks are running on a CPU, then
there are probably bigger issues to deal with.

However, some workloads dedicate a CPU for a single CPU bound task.  This
is done in high performance computing, in high frequency financial
applications, in networking (Intel DPDK, EZchip NPS) and with the advent
of systems with more and more CPUs over time, this may become more and
more common to do since when one has enough CPUs one cares less about
efficiently sharing a CPU with other tasks and more about efficiently
monopolizing a CPU per task.

The difference of having this timer firing and workqueue kernel thread
scheduled per second can be enormous.  An artificial test measuring the
worst case time to do a simple "i++" in an endless loop on a bare metal
system and under Linux on an isolated CPU with dynticks and with and
without this patch, have Linux match the bare metal performance (~700
cycles) with this patch and loose by couple of orders of magnitude (~200k
cycles) without it[*].  The loss occurs for something that just calculates
statistics.  For networking applications, for example, this could be the
difference between dropping packets or sustaining line rate.

Statistics are important and useful, but it would be great if there would
be a way to not cause statistics gathering produce a huge performance
difference.  This patche does just that.

This patch creates a vmstat shepherd worker that monitors the per cpu
differentials on all processors.  If there are differentials on a
processor then a vmstat worker local to the processors with the
differentials is created.  That worker will then start folding the diffs
in regular intervals.  Should the worker find that there is no work to be
done then it will make the shepherd worker monitor the differentials
again.

With this patch it is possible then to have periods longer than
2 seconds without any OS event on a "cpu" (hardware thread).

The patch shows a very minor increased in system performance.

hackbench -s 512 -l 2000 -g 15 -f 25 -P

Results before the patch:

Running in process mode with 15 groups using 50 file descriptors each (== 
750 tasks)
Each sender will pass 2000 messages of 512 bytes
Time: 4.992
Running in process mode with 15 groups using 50 file descriptors each (== 
750 tasks)
Each sender will pass 2000 messages of 512 bytes
Time: 4.971
Running in process mode with 15 groups using 50 file descriptors each (== 
750 tasks)
Each sender will pass 2000 messages of 512 bytes
Time: 5.063

Hackbench after the patch:

Running in process mode with 15 groups using 50 file descriptors each (== 
750 tasks)
Each sender will pass 2000 messages of 512 bytes
Time: 4.973
Running in process mode with 15 groups using 50 file descriptors each (== 
750 tasks)
Each sender will pass 2000 messages of 512 bytes
Time: 4.990
Running in process mode with 15 groups using 50 file descriptors each (== 
750 tasks)
Each sender will pass 2000 messages of 512 bytes
Time: 4.993

Signed-off-by: Christoph Lameter 
Reviewed-by: Gilad Ben-Yossef 
Cc: Frederic Weisbecker 
Cc: Thomas Gleixner 
Cc: Tejun Heo 
Cc: John Stultz 
Cc: Mike Frysinger 
Cc: Minchan Kim 
Cc: Hakan Akkan 
Cc: Max Krasnyansky 
Cc: "Paul E. McKenney" 
Cc: Hugh Dickins 
Cc: Viresh Kumar 
Cc: H. Peter Anvin 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Signed-off-by: Andrew Morton 

++++---+
|| 4020841d46 | 6e0a6b18b6 | 
next-20140725 |
++++---+
| boot_successes | 1114 

Re: [PATCH RFC 2/2 V2] workqueue: use dedicated creater kthread for all pools

[Tejun Heo]

On Wed, Jul 30, 2014 at 11:46:02AM +0800, Lai Jiangshan wrote:
> It add complexity to other things but not the code.  The code is simplified.

How?  It can simply repeat kthread_create() until it succeeds with
msleep() inbetween.  How can that be more complex than what's
implemented now?

> And failed pool is much fewer than creation which is completely coincidental,
> and after cooldown time, the other pool may also create worker.

I don't follow the above at all.  Can you please elaborate?

Thanks.

-- 
tejun
--
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 RFC 2/2 V2] workqueue: use dedicated creater kthread for all pools

[Lai Jiangshan]

On 07/30/2014 11:23 AM, Tejun Heo wrote:
> Hello, Lai.
> 
> On Wed, Jul 30, 2014 at 08:32:51AM +0800, Lai Jiangshan wrote:
>>> Why?  Just sleep and retry?  What's the point of requeueing?
>>
>> Accepted your comments except this one which may need to discuss
>> for an additional round.  Requeueing passes the retry to the
>> kthread_worker and gives a change to the other pools which are also
>> creating worker.
> 
> But why is that a good idea?  The fact that creation of a worker for a
> specific pool is completely coincidental.  The failed pool itself
> isn't inherently blameable.  It was just unlucky and moving onto a
> different pool doesn't improve the chance of success in any way.  The
> only thing requeueing achieves is punishing the unlucky one by putting
> it at the back of the queue while adding complexity.

It add complexity to other things but not the code.  The code is simplified.

And failed pool is much fewer than creation which is completely coincidental,
and after cooldown time, the other pool may also create worker.

Thanks,
Lai

> 
>> This patch will be deferred until 3.19 due to some unbound patches
>> are ready soon.
> 
> We're too late for this merge window anyway.  This is a pretty
> pervasive change after all.
> 
> 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: [GIT] Networking

[David Miller]

From: Stephen Rothwell 
Date: Wed, 30 Jul 2014 10:36:28 +1000

> On Tue, 29 Jul 2014 16:55:32 -0700 (PDT) David Miller  
> wrote:
>>
>> Oliver Neukum (2):
>>   cdc_subset: deal with a device that needs reset for timeout
> 
> This commit causes a build failure on arm (at least).  See my
> linux-next email about this.

Linus can you just revert that commit after you pull from me for now?

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 v2 13/29] nios2: DMA mapping API

[Ley Foon Tan]

On Thu, Jul 24, 2014 at 8:05 PM, Arnd Bergmann  wrote:
>> I have spent some times look at other architectures and below is what
>> I found. Please correct me if I am wrong, especially
>> for_device():DMA_FROM_DEVICE.
>>
>> _for_cpu():
>> case DMA_BIDIRECTIONAL:
>> case DMA_FROM_DEVICE:
>>  /* invalidate cache */
>> break;
>> case DMA_TO_DEVICE:
>>/* do nothing */
>> break;
>
> This seems fine: for a FROM_DEVICE mapping, we have flushed all
> dirty entries during the _for_device or the map operation,
> so if any clean entries are around, they need to be invalidated
> in order to read the data from the device.
>
> for TO_DEVICE, we don't care about the cache, because we are
> going to overwrite the data, and we don't need to do anything.
Okay.

>
>> -
>> _for_device():
>> case DMA_BIDIRECTIONAL:
>> case DMA_TO_DEVICE:
>>  /* flush and invalidate cache */
>> break;
>> case DMA_FROM_DEVICE:
>>  /* should we invalidate cache or do nothing? */
>> break;
>
> You actually don't need to invalidate the TO_DEVICE mappings
> in both _for_device and _for_cpu. You have to flush them
> in for_device, and you have to invalidate them at least once,
> but don't need to invalidate them again in for_cpu if you have
> done that already in for_device and your CPU does not do any
> speculative prefetches that might populate the dcache.
Nios2 processor doesn't have flush-cache-only instruction. Its flush
instruction will do 2 operations, flush and invalidate cache.


> In case of for_device FROM_DEVICE, you have to invalidate or
> flush the caches to ensure that no dirty cache lines are
> written to memory, but only if your CPU has a write-back
> cache rather than write-through.
Nios2 has a write-back cache. So, will do invalidate cache here.

> For bidirectional mappings, you may have to flush and invalidate.
To confirm, do you mean bidirectional for both for_device and for_cpu?

Thanks.

Regards
Ley Foon
--
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/6] MAINTAINERS: Update patterns

[Joe Perches]

Miscellaneous collection of MAINTAINER pattern updates

Joe Perches (6):
  MAINTAINERS: Update DMA BUFFER SHARING patterns
  MAINTAINERS: Update usb/gadget patterns
  MAINTAINERS: Update go7007 pattern
  MAINTAINERS: Update solo6x10 patterns
  MAINTAINERS: Update samsung pinctrl patterns
  MAINTAINERS: Update nomadik patterns

 MAINTAINERS | 46 +-
 1 file changed, 25 insertions(+), 21 deletions(-)

-- 
1.8.1.2.459.gbcd45b4.dirty

--
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: One bug of SDHCI driver

[Jaehoon Chung]

Hi, Zhonghui.

On 07/30/2014 11:47 AM, Fu, Zhonghui wrote:
> 
> Hi,
> 
> In the resume function, SDIO irq must be enabled, or the interrupts from 
> devices on SDIO bus can't be acknowledged. I also uploaded this new patch to 
> https://bugzilla.kernel.org/show_bug.cgi?id=80151.
> Could you please help to review it?
> 
> 
> 
> 
> Thanks,
> Zhonghui
> 
> On 2014/7/24 23:27, Fu, Zhonghui wrote:
>> Hi,
>>
>> Any comments for this new patch?
>>
>> Thanks,
>> Zhonghui
>> On 2014/7/20 22:51, Fu, Zhonghui wrote:
>>> Hi,
>>>
>>> Chris' patch is not enough to fix this bug. I made a patch as follows and 
>>> verified it can work.  Could you please give out some comments about this 
>>> patch?
>>>
>>>
>>> Thanks,
>>> Zhonghui
>>>
>>> >From 72d6f5b56fa04290fd3a055ade1d89e7c8d4 Mon Sep 17 00:00:00 2001
>>> From: Fu Zhonghui 
>>> Date: Sun, 20 Jul 2014 22:29:53 +0800
>>> Subject: [PATCH] mmc: core: sdio: Fix unconditional wake_up_process() on 
>>> sdio thread
>>>
>>> 781e989cf59 ("mmc: sdhci: convert to new SDIO IRQ handling") and
>>> bf3b5ec66bd ("mmc: sdio_irq: rework sdio irq handling") disabled
>>> the use of our own custom threaded IRQ handler, but left in an
>>> unconditional wake_up_process() on that handler at resume-time.
>>>
>>> Signed-off-by: Fu Zhonghui 
>>> ---
>>>  drivers/mmc/core/sdio.c |   14 --
>>>  1 files changed, 12 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
>>> index e636d9e..8369e56 100644
>>> --- a/drivers/mmc/core/sdio.c
>>> +++ b/drivers/mmc/core/sdio.c
>>> @@ -992,8 +992,18 @@ static int mmc_sdio_resume(struct mmc_host *host)
>>> }
>>> }
>>>  
>>> -   if (!err && host->sdio_irqs)
>>> -   wake_up_process(host->sdio_irq_thread);
>>> +   if (!err && host->sdio_irqs) {
>>> +   if (!(host->caps2 & MMC_CAP2_SDIO_IRQ_NOTHREAD)) {
>>> +   wake_up_process(host->sdio_irq_thread);
>>> +   } else {
>>> +   mmc_release_host(host);
>>> +   mmc_host_clk_hold(host);
>>> +   host->ops->enable_sdio_irq(host, 1);
>>> +   mmc_host_clk_release(host);
>>> +   mmc_claim_host(host);
>>> +   }
>>> +   }
If you enable the sdio_irq, I think it needs to check whether MMC_CAP_SDIO_IRQ 
is set or not.


Best Regards,
Jaehoon Chung
>>> +
>>> mmc_release_host(host);
>>>  
>>> host->pm_flags &= ~MMC_PM_KEEP_POWER;
>>> -- 1.7.1
>>>
>>>
>>>
>>> On 2014/7/15 12:40, Jaehoon Chung wrote:
 From: Chris Ball 
 Subject: [PATCH] mmc: core: sdio: Fix unconditional wake_up_process() on 
 sdio thread

 781e989cf59 ("mmc: sdhci: convert to new SDIO IRQ handling") and
 bf3b5ec66bd ("mmc: sdio_irq: rework sdio irq handling") disabled
 the use of our own custom threaded IRQ handler, but left in an
 unconditional wake_up_process() on that handler at resume-time.

 Reported-by: Fu, Zhonghui 
 [Patch suggested by Jaehoon Chung]
 Signed-off-by: Chris Ball 
 ---
  drivers/mmc/core/sdio.c |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
 index e636d9e..11cc4e0 100644
 --- a/drivers/mmc/core/sdio.c
 +++ b/drivers/mmc/core/sdio.c
 @@ -992,7 +992,8 @@ static int mmc_sdio_resume(struct mmc_host *host)
}
}
  
 -  if (!err && host->sdio_irqs)
 +  if (!err && host->sdio_irqs &&
 +  !(host->caps2 & MMC_CAP2_SDIO_IRQ_NOTHREAD))
wake_up_process(host->sdio_irq_thread);
mmc_release_host(host);
  
>>> --
>>> 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/
>> --
>> 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/
> 

--
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/6] MAINTAINERS: Update go7007 pattern

[Joe Perches]

Commit 7955f03d18d1 ("[media] go7007: move out of staging into
drivers/media/usb") moved the files, update the pattern.

Signed-off-by: Joe Perches 
cc: Hans Verkuil 
---
 MAINTAINERS | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6033aaf..3960ba8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3997,6 +3997,12 @@ F:   Documentation/isdn/README.gigaset
 F: drivers/isdn/gigaset/
 F: include/uapi/linux/gigaset_dev.h
 
+GO7007 MPEG CODEC
+M: Hans Verkuil 
+L: linux-me...@vger.kernel.org
+S: Maintained
+F: drivers/media/usb/go7007/
+
 GPIO SUBSYSTEM
 M: Linus Walleij 
 M: Alexandre Courbot 
@@ -8603,11 +8609,6 @@ M:   Marek Belisko 
 S: Odd Fixes
 F: drivers/staging/ft1000/
 
-STAGING - GO7007 MPEG CODEC
-M: Hans Verkuil 
-S: Maintained
-F: drivers/staging/media/go7007/
-
 STAGING - INDUSTRIAL IO
 M: Jonathan Cameron 
 L: linux-...@vger.kernel.org
-- 
1.8.1.2.459.gbcd45b4.dirty

--
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/6] MAINTAINERS: Update DMA BUFFER SHARING patterns

[Joe Perches]

One pattern per F: line please...

Signed-off-by: Joe Perches 
CC: Sumit Semwal 
---
 MAINTAINERS | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5e5478b..66d5894 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2941,7 +2941,9 @@ L:linux-me...@vger.kernel.org
 L: dri-de...@lists.freedesktop.org
 L: linaro-mm-...@lists.linaro.org
 F: drivers/dma-buf/
-F: include/linux/dma-buf* include/linux/reservation.h 
include/linux/*fence.h
+F: include/linux/dma-buf*
+F: include/linux/reservation.h
+F: include/linux/*fence.h
 F: Documentation/dma-buf-sharing.txt
 T: git git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git
 
-- 
1.8.1.2.459.gbcd45b4.dirty

--
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 5/6] MAINTAINERS: Update samsung pinctrl patterns

[Joe Perches]

commit ebe629a39e04 ("pinctrl: samsung: Group all drivers in a sub-dir")
moved the files, update the patterns.

Signed-off-by: Joe Perches 
---
 MAINTAINERS | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8ed337c..70f157e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6989,9 +6989,7 @@ M:Thomas Abraham 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
 S: Maintained
-F: drivers/pinctrl/pinctrl-exynos.*
-F: drivers/pinctrl/pinctrl-s3c*
-F: drivers/pinctrl/pinctrl-samsung.*
+F: drivers/pinctrl/samsung/
 
 PIN CONTROLLER - ST SPEAR
 M: Viresh Kumar 
-- 
1.8.1.2.459.gbcd45b4.dirty

--
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/6] MAINTAINERS: Update solo6x10 patterns

[Joe Perches]

commit 28cae868cd24 ("[media] solo6x10: move out of staging into
drivers/media/pci") moved the files, update the patterns.

Signed-off-by: Joe Perches 
cc: Ismael Luceno 
cc: Hans Verkuil 
---
 MAINTAINERS | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3960ba8..8ed337c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8403,6 +8403,12 @@ M:   Chris Boot 
 S: Maintained
 F: drivers/leds/leds-net48xx.c
 
+SOFTLOGIC 6x10 MPEG CODEC
+M: Ismael Luceno 
+L: linux-me...@vger.kernel.org
+S: Supported
+F: drivers/media/pci/solo6x10/
+
 SOFTWARE RAID (Multiple Disks) SUPPORT
 M: Neil Brown 
 L: linux-r...@vger.kernel.org
@@ -8666,11 +8672,6 @@ M:   Christopher Harrer 
 S: Odd Fixes
 F: drivers/staging/slicoss/
 
-STAGING - SOFTLOGIC 6x10 MPEG CODEC
-M: Ismael Luceno 
-S: Supported
-F: drivers/staging/media/solo6x10/
-
 STAGING - SPEAKUP CONSOLE SPEECH DRIVER
 M: William Hubbs 
 M: Chris Brannon 
-- 
1.8.1.2.459.gbcd45b4.dirty

--
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 6/6] MAINTAINERS: Update nomadik patterns

[Joe Perches]

commit 3a19805920f1 ("pinctrl: nomadik: move all Nomadik drivers to subdir")
move the files, update the patterns

Signed-off-by: Joe Perches 
cc: Linus Walleij 
cc: Alessandro Rubini 
---
 MAINTAINERS | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 70f157e..09603b9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1155,6 +1155,7 @@ M:Linus Walleij 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
 F: arch/arm/mach-nomadik/
+F: drivers/pinctrl/nomadik/
 F: drivers/i2c/busses/i2c-nomadik.c
 T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git
 
@@ -1432,7 +1433,8 @@ F:drivers/mfd/abx500*
 F: drivers/mfd/ab8500*
 F: drivers/mfd/dbx500*
 F: drivers/mfd/db8500*
-F: drivers/pinctrl/pinctrl-nomadik*
+F: drivers/pinctrl/nomadik/pinctrl-ab*
+F: drivers/pinctrl/nomadik/pinctrl-nomadik*
 F: drivers/rtc/rtc-ab8500.c
 F: drivers/rtc/rtc-pl031.c
 T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
-- 
1.8.1.2.459.gbcd45b4.dirty

--
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/6] MAINTAINERS: Update usb/gadget patterns

[Joe Perches]

Several commits have moved files around, update the section patterns.

Signed-off-by: Joe Perches 
cc: Thomas Dahlmann 
cc: Nicolas Ferre 
cc: Li Yang 
cc: Eric Miao 
cc: Russell King 
cc: Haojian Zhuang 
cc: Laurent Pinchart 
cc: Andrzej Pietrasiewicz 
---
 MAINTAINERS | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 66d5894..6033aaf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -596,7 +596,7 @@ AMD GEODE CS5536 USB DEVICE CONTROLLER DRIVER
 M: Thomas Dahlmann 
 L: linux-ge...@lists.infradead.org (moderated for non-subscribers)
 S: Supported
-F: drivers/usb/gadget/amd5536udc.*
+F: drivers/usb/gadget/udc/amd5536udc.*
 
 AMD GEODE PROCESSOR/CHIPSET SUPPORT
 P: Andres Salomon 
@@ -1688,7 +1688,7 @@ ATMEL USBA UDC DRIVER
 M: Nicolas Ferre 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Supported
-F: drivers/usb/gadget/atmel_usba_udc.*
+F: drivers/usb/gadget/udc/atmel_usba_udc.*
 
 ATMEL WIRELESS DRIVER
 M: Simon Kelley 
@@ -3798,7 +3798,7 @@ M:Li Yang 
 L: linux-...@vger.kernel.org
 L: linuxppc-...@lists.ozlabs.org
 S: Maintained
-F: drivers/usb/gadget/fsl*
+F: drivers/usb/gadget/udc/fsl*
 
 FREESCALE QUICC ENGINE UCC ETHERNET DRIVER
 M: Li Yang 
@@ -7232,7 +7232,7 @@ S:Maintained
 F: arch/arm/mach-pxa/
 F: drivers/pcmcia/pxa2xx*
 F: drivers/spi/spi-pxa2xx*
-F: drivers/usb/gadget/pxa2*
+F: drivers/usb/gadget/udc/pxa2*
 F: include/sound/pxa2xx-lib.h
 F: sound/arm/pxa*
 F: sound/soc/pxa/
@@ -9576,8 +9576,8 @@ USB WEBCAM GADGET
 M: Laurent Pinchart 
 L: linux-...@vger.kernel.org
 S: Maintained
-F: drivers/usb/gadget/*uvc*.c
-F: drivers/usb/gadget/webcam.c
+F: drivers/usb/gadget/function/*uvc*.c
+F: drivers/usb/gadget/legacy/webcam.c
 
 USB WIRELESS RNDIS DRIVER (rndis_wlan)
 M: Jussi Kivilinna 
-- 
1.8.1.2.459.gbcd45b4.dirty

--
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 resend #7] fcntl-linux.h: add new definitions and manual updates for open file description locks

[Carlos O'Donell]

On 07/23/2014 02:21 PM, Jeff Layton wrote:
> From: Jeff Layton 

Thanks for resending. Sorry for the delay.

Your use of 3 different emails caused me to miss the recent
resends. That's my fault and tied to the way I'm tracking
everything from patchwork using the first email you used.

I am assuming that this work is under Red Hat's copyright
status since you submitted it originally from @redhat.com.

I've committed this to trunk with small tweaks and the following
NEWS entry:

* Support for file description locks is added to systems running the
  Linux kernel. The standard file locking interfaces are extended to
  operate on file descriptions, not file descriptors, via the use of
  F_OFD_GETLK, F_OFD_SETLK, and F_OFD_SETLKW. File description locks
  are associated with an open file instead of a process.

This will be in 2.20 when we cut the branch.
 
> Open file description locks have been merged into the Linux kernel for
> v3.15.  Add the appropriate command-value definitions and an update to
> the manual that describes their usage.
> 
> ChangeLog:
> 
> 2014-04-24  Jeff Layton  
> 
>   [BZ#16839]
>   * manual/llio.texi: add section about open file description locks
> 
>   * manual/examples/ofdlocks.c:
> example of open file description lock usage
> 
>   * sysdeps/unix/sysv/linux/bits/fcntl-linux.h:
> (F_OFD_GETLK, F_OFD_SETLK, F_OFD_SETLKW): New macros.

I simplified it a bit.

A space in the ChangeLog indicates a distinct commit, which this is not,
so I lump them together.

This is what went in:

2014-07-29  Jeff Layton  

[BZ #16839]
* manual/llio.texi: Add section about open file description locks.
* manual/examples/ofdlocks.c: Example of open file description
lock usage.
* sysdeps/unix/sysv/linux/bits/fcntl-linux.h: Define F_OFD_GETLK,
F_OFD_SETLK, and F_OFD_SETLKW.

As the committer I added #16839 to the fixed bug list following:

https://sourceware.org/glibc/wiki/Committer%20checklist

> ---
>  manual/examples/ofdlocks.c |  77 +
>  manual/llio.texi   | 241 
> -
>  sysdeps/unix/sysv/linux/bits/fcntl-linux.h |  17 ++
>  3 files changed, 332 insertions(+), 3 deletions(-)
>  create mode 100644 manual/examples/ofdlocks.c
> 
> diff --git a/manual/examples/ofdlocks.c b/manual/examples/ofdlocks.c
> new file mode 100644
> index ..85e193cdabe6
> --- /dev/null
> +++ b/manual/examples/ofdlocks.c
> @@ -0,0 +1,77 @@
> +/* Open File Description Locks Usage Example
> +   Copyright (C) 1991-2014 Free Software Foundation, Inc.
> +
> +   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.
> +
> +   You should have received a copy of the GNU General Public License
> +   along with this program; if not, see .
> +*/
> +
> +#define _GNU_SOURCE
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define FILENAME "/tmp/foo"
> +#define NUM_THREADS  3
> +#define ITERATIONS   5
> +
> +void *
> +thread_start (void *arg)
> +{
> +  int i, fd, len;
> +  long tid = (long) arg;
> +  char buf[256];
> +  struct flock lck = {
> +.l_whence = SEEK_SET,
> +.l_start = 0,
> +.l_len = 1,
> +  };
> +
> +  fd = open ("/tmp/foo", O_RDWR | O_CREAT, 0666);
> +
> +  for (i = 0; i < ITERATIONS; i++)
> +{
> +  lck.l_type = F_WRLCK;
> +  fcntl (fd, F_OFD_SETLKW, &lck);
> +
> +  len = sprintf (buf, "%d: tid=%ld fd=%d\n", i, tid, fd);
> +
> +  lseek (fd, 0, SEEK_END);
> +  write (fd, buf, len);
> +  fsync (fd);
> +
> +  lck.l_type = F_UNLCK;
> +  fcntl (fd, F_OFD_SETLK, &lck);
> +
> +  /* sleep to ensure lock is yielded to another thread */
> +  usleep (1);
> +}
> +  pthread_exit (NULL);
> +}
> +
> +int
> +main (int argc, char **argv)
> +{
> +  long i;
> +  pthread_t threads[NUM_THREADS];
> +
> +  truncate (FILENAME, 0);
> +
> +  for (i = 0; i < NUM_THREADS; i++)
> +pthread_create (&threads[i], NULL, thread_start, (void *) i);
> +
> +  pthread_exit (NULL);
> +  return 0;
> +}
> diff --git a/manual/llio.texi b/manual/llio.texi
> index 6f8adfc607d7..864060dc7140 100644
> --- a/manual/llio.texi
> +++ b/manual/llio.texi
> @@ -57,6 +57,10 @@ directly.)
>   flags associated with open files.
>  * File Locks::  Fcntl commands for implementing
>   file locking.
> +* Open File Description Locks:: Fcn

[LKP] [net] 8f61059a96c: +55.7% netperf.Throughput_Mbps

[Aaron Lu]

FYI, we noticed the below changes on

git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 8f61059a96c2a29c1cc5a39dfe23d06ef5b4b065 ("net: sctp: improve timer 
slack calculation for transport HBs")

test case: lkp-wsx02/netperf/300s-200%-10K-SCTP_STREAM_MANY

eb1ac820c61d0d8  8f61059a96c2a29c1cc5a39df  
---  -  
  1349 ~ 2% +55.7%   2101 ~ 1%  TOTAL netperf.Throughput_Mbps
170805 ~12%+398.9% 852164 ~14%  TOTAL cpuidle.C1-NHM.usage
  4.18 ~ 5%-100.0%   0.00 ~ 0%  TOTAL 
perf-profile.cpu-cycles._raw_spin_lock_irqsave.mod_timer.sctp_transport_reset_timers.sctp_outq_flush.sctp_outq_uncork
  4.42 ~ 2% -99.5%   0.02 ~18%  TOTAL 
perf-profile.cpu-cycles.lock_timer_base.isra.34.mod_timer.sctp_transport_reset_timers.sctp_outq_flush.sctp_outq_uncork
 10.60 ~ 2% -99.7%   0.03 ~14%  TOTAL 
perf-profile.cpu-cycles.sctp_transport_timeout.sctp_transport_reset_timers.sctp_outq_flush.sctp_outq_uncork.sctp_cmd_interpreter
  1.77 ~ 4% -78.8%   0.38 ~ 4%  TOTAL 
perf-profile.cpu-cycles.sctp_outq_flush.sctp_outq_uncork.sctp_cmd_interpreter.sctp_do_sm.sctp_assoc_bh_rcv
  3.42 ~11%+196.0%  10.11 ~ 5%  TOTAL 
perf-profile.cpu-cycles._raw_spin_lock.free_one_page.__free_pages_ok.__free_pages.__free_kmem_pages
  3.52 ~10%+174.1%   9.64 ~ 6%  TOTAL 
perf-profile.cpu-cycles._raw_spin_lock_irqsave.get_page_from_freelist.__alloc_pages_nodemask.alloc_kmem_pages_node.kmalloc_large_node
  14540720 ~17%+162.1%   38114453 ~15%  TOTAL cpuidle.C1-NHM.time
  18604327 ~ 7% -43.0%   10606401 ~12%  TOTAL cpuidle.C1E-NHM.time
   5.4e+09 ~ 2% +55.7%  8.406e+09 ~ 1%  TOTAL proc-vmstat.pgfree
  5.29e+09 ~ 2% +55.4%   8.22e+09 ~ 1%  TOTAL proc-vmstat.pgalloc_normal
  0.17 ~10% +52.9%   0.27 ~21%  TOTAL turbostat.%c1
  1294 ~ 4% -17.2%   1071 ~11%  TOTAL 
numa-vmstat.node0.nr_page_table_pages
  5176 ~ 4% -17.2%   4288 ~11%  TOTAL numa-meminfo.node0.PageTables
  1.58 ~ 3% +20.3%   1.90 ~ 0%  TOTAL 
perf-profile.cpu-cycles.get_page_from_freelist.__alloc_pages_nodemask.alloc_kmem_pages_node.kmalloc_large_node.__kmalloc_node_track_caller
  2.60 ~ 1% +16.3%   3.02 ~ 1%  TOTAL 
perf-profile.cpu-cycles.memcpy.sctp_packet_transmit_chunk.sctp_outq_flush.sctp_outq_uncork.sctp_cmd_interpreter
  6.49 ~ 0% +12.8%   7.32 ~ 2%  TOTAL 
perf-profile.cpu-cycles.copy_user_generic_string.skb_copy_datagram_iovec.sctp_recvmsg.sock_common_recvmsg.sock_recvmsg
 11700 ~ 4% +18.7%  13891 ~ 7%  TOTAL proc-vmstat.pgmigrate_success
 11700 ~ 4% +18.7%  13891 ~ 7%  TOTAL 
proc-vmstat.numa_pages_migrated
139702 ~ 1% +16.3% 162521 ~ 5%  TOTAL proc-vmstat.numa_hint_faults
   977 ~ 2% +16.0%   1133 ~ 8%  TOTAL proc-vmstat.pgmigrate_fail
  6.81 ~ 0% +12.2%   7.64 ~ 2%  TOTAL 
perf-profile.cpu-cycles.copy_user_generic_string.sctp_user_addto_chunk.sctp_datamsg_from_user.sctp_sendmsg.inet_sendmsg
  4.98 ~ 0% +11.8%   5.57 ~ 2%  TOTAL 
perf-profile.cpu-cycles.memcpy.sctp_outq_flush.sctp_outq_uncork.sctp_cmd_interpreter.sctp_do_sm
160357 ~ 1% +14.2% 183117 ~ 4%  TOTAL proc-vmstat.numa_pte_updates
  1653 ~ 3%  -8.5%   1512 ~ 4%  TOTAL 
numa-vmstat.node0.nr_alloc_batch
310335 ~ 2% +55.9% 483905 ~ 1%  TOTAL vmstat.system.cs

Legend:
~XX%- stddev percent
[+-]XX% - change percent


  netperf.Throughput_Mbps

  2300 ++---+
  2200 O+OO O  O|
   |  O  O OO OO O OO O O O   O  OO |
  2100 ++O  O  O  O O  O O  |
  2000 ++O  |
   |   O|
  1900 ++   |
  1800 ++   |
  1700 ++   |
   ||
  1600 ++   |
  1500 ++   |
   |*.  |
  1400 *+**.*.**.*. *.**.*.**.*.**.*.**.*. *.**. .**.*. : *.**.*. .*.**.|
  1300 ++--*--*-*--*-**-**--*


  vmstat.system.cs

  65 ++-+
 |  |
  60 ++O  

Re: [PATCH] x86, efi: print debug values in Kib not MB

[Steven Noonan]

On Tue, Jul 29, 2014 at 3:54 PM, Prarit Bhargava  wrote:
>
>
> On 07/29/2014 06:36 PM, Borislav Petkov wrote:
>> On Tue, Jul 29, 2014 at 06:32:56PM -0400, Prarit Bhargava wrote:
>>> and it was best to keep the code simple with a KiB.
>>
>> You're missing the point - the output doesn't get simple with KiB. Read
>> the example I just gave you!
>>
>> (13893632kiB) is actively *not* helping when one looks at it!
>
> I did get your point and I'm (politely) disagreeing with it.  Your case ONLY
> works if the number is _exactly_ 13GB.  What if it is 13.5?  Then we're still
> rounding off and reporting 14GB.  Which, if this code is meant for debug, 
> makes
> no sense to me.  Why round it off?
>

I think if it was being represented in procfs or sysfs, we'd need to
be extremely specific to make it machine-readable, but for a
human-readable printk, it makes sense to me to print it in the smaller
unit size until the value is in tens of the next higher unit size
(e.g. print in KiB until 10+MiB, print in MiB until 10+GiB).
--
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 RFC 2/2 V2] workqueue: use dedicated creater kthread for all pools

[Tejun Heo]

Hello, Lai.

On Wed, Jul 30, 2014 at 08:32:51AM +0800, Lai Jiangshan wrote:
> > Why?  Just sleep and retry?  What's the point of requeueing?
> 
> Accepted your comments except this one which may need to discuss
> for an additional round.  Requeueing passes the retry to the
> kthread_worker and gives a change to the other pools which are also
> creating worker.

But why is that a good idea?  The fact that creation of a worker for a
specific pool is completely coincidental.  The failed pool itself
isn't inherently blameable.  It was just unlucky and moving onto a
different pool doesn't improve the chance of success in any way.  The
only thing requeueing achieves is punishing the unlucky one by putting
it at the back of the queue while adding complexity.

> This patch will be deferred until 3.19 due to some unbound patches
> are ready soon.

We're too late for this merge window anyway.  This is a pretty
pervasive change after all.

Thanks.

-- 
tejun
--
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: [f2fs-dev] [PATCH 08/11] f2fs: fix wrong condition for unlikely

[Jaegeuk Kim]

On Wed, Jul 30, 2014 at 09:44:43AM +0800, Chao Yu wrote:
> Hi Jaegeuk,
> 
> > -Original Message-
> > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > Sent: Saturday, July 26, 2014 6:47 AM
> > To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> > linux-f2fs-de...@lists.sourceforge.net
> > Cc: Jaegeuk Kim
> > Subject: [f2fs-dev] [PATCH 08/11] f2fs: fix wrong condition for unlikely
> > 
> > This patch fixes the wrongly used unlikely condition.
> > 
> > Signed-off-by: Jaegeuk Kim 
> > ---
> >  fs/f2fs/checkpoint.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> > index 42a16c1..36b0d47 100644
> > --- a/fs/f2fs/checkpoint.c
> > +++ b/fs/f2fs/checkpoint.c
> > @@ -932,7 +932,7 @@ static void do_checkpoint(struct f2fs_sb_info *sbi, 
> > bool is_umount)
> > /* Here, we only have one bio having CP pack */
> > sync_meta_pages(sbi, META_FLUSH, LONG_MAX);
> > 
> > -   if (unlikely(!is_set_ckpt_flags(ckpt, CP_ERROR_FLAG))) {
> > +   if (!is_set_ckpt_flags(ckpt, CP_ERROR_FLAG)) {
> 
> Maybe use likely(!is_set_ckpt_flags(ckpt, CP_ERROR_FLAG)) or
> 
> if (unlikely(is_set_ckpt_flags(ckpt, CP_ERROR_FLAG)))
>   return;
> 
> is more appropriate. How do you think?

Currently I'd like to put this without any likely or unlikely.
Best thing is to measure some performance how this would make effect on.
Until then, it'd be better to do without it, since apparently this should
not be unlikely.

How about you?
Can we compare both of them explicitly?

Thanks,

> 
> > clear_prefree_segments(sbi);
> > release_dirty_inode(sbi);
> > F2FS_RESET_SB_DIRT(sbi);
> > --
> > 1.8.5.2 (Apple Git-48)
> > 
> > 
> > --
> > Want fast and easy access to all the code in your enterprise? Index and
> > search up to 200,000 lines of code with a free copy of Black Duck
> > Code Sight - the same software that powers the world's largest code
> > search on Ohloh, the Black Duck Open Hub! Try it now.
> > http://p.sf.net/sfu/bds
> > ___
> > Linux-f2fs-devel mailing list
> > linux-f2fs-de...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
--
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: [f2fs-dev] [PATCH 07/11] f2fs: enable in-place-update for fdatasync

[Jaegeuk Kim]

On Wed, Jul 30, 2014 at 10:45:38AM +0800, Chao Yu wrote:
> Hi Jaegeuk Changman,
> 
> > -Original Message-
> > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > Sent: Wednesday, July 30, 2014 9:08 AM
> > To: Changman Lee
> > Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-f2fs-de...@lists.sourceforge.net
> > Subject: Re: [f2fs-dev] [PATCH 07/11] f2fs: enable in-place-update for 
> > fdatasync
> > 
> > On Wed, Jul 30, 2014 at 08:54:55AM +0900, Changman Lee wrote:
> > > On Tue, Jul 29, 2014 at 05:22:15AM -0700, Jaegeuk Kim wrote:
> > > > Hi Changman,
> > > >
> > > > On Tue, Jul 29, 2014 at 09:41:11AM +0900, Changman Lee wrote:
> > > > > Hi Jaegeuk,
> > > > >
> > > > > On Fri, Jul 25, 2014 at 03:47:21PM -0700, Jaegeuk Kim wrote:
> > > > > > This patch enforces in-place-updates only when fdatasync is 
> > > > > > requested.
> > > > > > If we adopt this in-place-updates for the fdatasync, we can skip to 
> > > > > > write the
> > > > > > recovery information.
> > > > >
> > > > > But, as you know, random write occurs when changing into 
> > > > > in-place-updates.
> > > > > It will degrade write performance. Is there any case in-place-updates 
> > > > > is
> > > > > better, except recovery or high utilization?
> > > >
> > > > As I described, you can easily imagine, if users requested small amount 
> > > > of data
> > > > writes with fdatasync, we should do data writes + node writes.
> > > > But, if we can do in-place-update, we don't need to write node blocks.
> > > > Surely it triggers random writes, however, the amount of data is preety 
> > > > small
> > > > and the device handles them very fast by its inside cache, so that it 
> > > > can
> > > > enhance the performance.
> > > >
> > > > Thanks,
> > >
> > > Partially agree. Sometimes, I see that SSR shows lower performance than
> > > IPU. One of the reasons might be node writes.
> > 
> > What did you mean? That's why I consider IPU eagarly instead of SSR and LFS
> > under the very strict cases.
> > 
> > > Anyway, if so, we should know total dirty pages for fdatasync and it's 
> > > very
> > > tunable according to a random write performance of device.
> > 
> > Agreed. We can do that either by comparing the number of dirty pages,
> > additional data/node writes, and cost of checkpoint at the same time.
> > And there is another thing is that we need to consider the number of
> > waiting time for end_io.
> > I'll look into this at some time.
> 
> Agreed, but please additionally consider that the number we got is not highly
> accurate because without protection of ->i_mutex writer could generate more
> dirty pages.

Right, but IMO, it doesn't need to get correct numbers.
Just for reference is enough.
Sort of trade-offs. :)

Thanks,

> 
> > 
> > Thanks,
> > 
> > >
> > > Thanks,
> > >
> > > >
> > > > >
> > > > > Thanks
> > > > >
> > > > > >
> > > > > > Signed-off-by: Jaegeuk Kim 
> > > > > > ---
> > > > > >  fs/f2fs/f2fs.h| 1 +
> > > > > >  fs/f2fs/file.c| 7 +++
> > > > > >  fs/f2fs/segment.h | 4 
> > > > > >  3 files changed, 12 insertions(+)
> > > > > >
> > > > > > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > > > > > index ab36025..8f8685e 100644
> > > > > > --- a/fs/f2fs/f2fs.h
> > > > > > +++ b/fs/f2fs/f2fs.h
> > > > > > @@ -998,6 +998,7 @@ enum {
> > > > > > FI_INLINE_DATA, /* used for inline data*/
> > > > > > FI_APPEND_WRITE,/* inode has appended data */
> > > > > > FI_UPDATE_WRITE,/* inode has in-place-update data */
> > > > > > +   FI_NEED_IPU,/* used fo ipu for fdatasync */
> > > > > >  };
> > > > > >
> > > > > >  static inline void set_inode_flag(struct f2fs_inode_info *fi, int 
> > > > > > flag)
> > > > > > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> > > > > > index 121689a..e339856 100644
> > > > > > --- a/fs/f2fs/file.c
> > > > > > +++ b/fs/f2fs/file.c
> > > > > > @@ -127,11 +127,18 @@ int f2fs_sync_file(struct file *file, loff_t 
> > > > > > start, loff_t end,
> > int datasync)
> > > > > > return 0;
> > > > > >
> > > > > > trace_f2fs_sync_file_enter(inode);
> > > > > > +
> > > > > > +   /* if fdatasync is triggered, let's do in-place-update */
> > > > > > +   if (datasync)
> > > > > > +   set_inode_flag(fi, FI_NEED_IPU);
> > > > > > +
> > > > > > ret = filemap_write_and_wait_range(inode->i_mapping, start, 
> > > > > > end);
> > > > > > if (ret) {
> > > > > > trace_f2fs_sync_file_exit(inode, need_cp, datasync, 
> > > > > > ret);
> > > > > > return ret;
> > > > > > }
> > > > > > +   if (datasync)
> > > > > > +   clear_inode_flag(fi, FI_NEED_IPU);
> > > > > >
> > > > > > /*
> > > > > >  * if there is no written data, don't waste time to write 
> > > > > > recovery info.
> > > > > > diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
> > > > > > index ee5c75e..55973f7 100644
> > > > > > --- a/fs/f2fs/segment.h
> > > > > > +++ b/fs/f2fs/segment.h
> > > > > > @@ -486,6 +486,10 @@ 

Re: [f2fs-dev] [PATCH 07/11] f2fs: enable in-place-update for fdatasync

[Jaegeuk Kim]

On Wed, Jul 30, 2014 at 10:56:31AM +0900, Changman Lee wrote:
> On Tue, Jul 29, 2014 at 06:08:21PM -0700, Jaegeuk Kim wrote:
> > On Wed, Jul 30, 2014 at 08:54:55AM +0900, Changman Lee wrote:
> > > On Tue, Jul 29, 2014 at 05:22:15AM -0700, Jaegeuk Kim wrote:
> > > > Hi Changman,
> > > > 
> > > > On Tue, Jul 29, 2014 at 09:41:11AM +0900, Changman Lee wrote:
> > > > > Hi Jaegeuk,
> > > > > 
> > > > > On Fri, Jul 25, 2014 at 03:47:21PM -0700, Jaegeuk Kim wrote:
> > > > > > This patch enforces in-place-updates only when fdatasync is 
> > > > > > requested.
> > > > > > If we adopt this in-place-updates for the fdatasync, we can skip to 
> > > > > > write the
> > > > > > recovery information.
> > > > > 
> > > > > But, as you know, random write occurs when changing into 
> > > > > in-place-updates.
> > > > > It will degrade write performance. Is there any case in-place-updates 
> > > > > is
> > > > > better, except recovery or high utilization?
> > > > 
> > > > As I described, you can easily imagine, if users requested small amount 
> > > > of data
> > > > writes with fdatasync, we should do data writes + node writes.
> > > > But, if we can do in-place-update, we don't need to write node blocks.
> > > > Surely it triggers random writes, however, the amount of data is preety 
> > > > small
> > > > and the device handles them very fast by its inside cache, so that it 
> > > > can
> > > > enhance the performance.
> > > > 
> > > > Thanks,
> > > 
> > > Partially agree. Sometimes, I see that SSR shows lower performance than
> > > IPU. One of the reasons might be node writes.
> > 
> > What did you mean? That's why I consider IPU eagarly instead of SSR and LFS
> > under the very strict cases.
> > 
> 
> Okay, I understood your intention.
> This discussion seems to be far from this thread a litte bit.
> Background I told as above is that I got better number from IPU when I
> tested fio under fragmentation by varmail and dd; and utilization about 93%.
> The result of perf shows f2fs spends the most cpu time searching victim
> in SSR mode. And f2fs had to write node data additionaly.

How about trying to reduce the cpu time at that moment?
And, as you know, f2fs already has such kind of triggering facility with sysfs.

> I think this condition could be one of the strict case as you told.
> 
> Thanks,
> 
> > > Anyway, if so, we should know total dirty pages for fdatasync and it's 
> > > very
> > > tunable according to a random write performance of device.
> > 
> > Agreed. We can do that either by comparing the number of dirty pages,
> > additional data/node writes, and cost of checkpoint at the same time.
> > And there is another thing is that we need to consider the number of
> > waiting time for end_io.
> > I'll look into this at some time.
> > 
> > Thanks,
> > 
> > > 
> > > Thanks,
> > > 
> > > > 
> > > > > 
> > > > > Thanks
> > > > > 
> > > > > > 
> > > > > > Signed-off-by: Jaegeuk Kim 
> > > > > > ---
> > > > > >  fs/f2fs/f2fs.h| 1 +
> > > > > >  fs/f2fs/file.c| 7 +++
> > > > > >  fs/f2fs/segment.h | 4 
> > > > > >  3 files changed, 12 insertions(+)
> > > > > > 
> > > > > > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > > > > > index ab36025..8f8685e 100644
> > > > > > --- a/fs/f2fs/f2fs.h
> > > > > > +++ b/fs/f2fs/f2fs.h
> > > > > > @@ -998,6 +998,7 @@ enum {
> > > > > > FI_INLINE_DATA, /* used for inline data*/
> > > > > > FI_APPEND_WRITE,/* inode has appended data */
> > > > > > FI_UPDATE_WRITE,/* inode has in-place-update data */
> > > > > > +   FI_NEED_IPU,/* used fo ipu for fdatasync */
> > > > > >  };
> > > > > >  
> > > > > >  static inline void set_inode_flag(struct f2fs_inode_info *fi, int 
> > > > > > flag)
> > > > > > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> > > > > > index 121689a..e339856 100644
> > > > > > --- a/fs/f2fs/file.c
> > > > > > +++ b/fs/f2fs/file.c
> > > > > > @@ -127,11 +127,18 @@ int f2fs_sync_file(struct file *file, loff_t 
> > > > > > start, loff_t end, int datasync)
> > > > > > return 0;
> > > > > >  
> > > > > > trace_f2fs_sync_file_enter(inode);
> > > > > > +
> > > > > > +   /* if fdatasync is triggered, let's do in-place-update */
> > > > > > +   if (datasync)
> > > > > > +   set_inode_flag(fi, FI_NEED_IPU);
> > > > > > +
> > > > > > ret = filemap_write_and_wait_range(inode->i_mapping, start, 
> > > > > > end);
> > > > > > if (ret) {
> > > > > > trace_f2fs_sync_file_exit(inode, need_cp, datasync, 
> > > > > > ret);
> > > > > > return ret;
> > > > > > }
> > > > > > +   if (datasync)
> > > > > > +   clear_inode_flag(fi, FI_NEED_IPU);
> > > > > >  
> > > > > > /*
> > > > > >  * if there is no written data, don't waste time to write 
> > > > > > recovery info.
> > > > > > diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
> > > > > > index ee5c75e..55973f7 100644
> > > > > > --- a/fs/f2fs/segment.h
> > > > > > +++ b/fs/f2fs/segment.h
> > > > > > @

Re: vmstat: On demand vmstat workers V8

[Lai Jiangshan]

On 07/29/2014 11:39 PM, Christoph Lameter wrote:
> On Tue, 29 Jul 2014, Tejun Heo wrote:
> 
>> Hmmm, well, then it's something else.  Either a bug in workqueue or in
>> the caller.  Given the track record, the latter is more likely.
>> e.g. it looks kinda suspicious that the work func is cleared after
>> cancel_delayed_work_sync() is called.  What happens if somebody tries
>> to schedule it inbetween?
> 
> Here is yet another patch to also address this idea:
> 
> Subject: vmstat: Clear the work.func before cancelling delayed work
> 
> Looks strange to me but Tejun thinks this could do some good.
> If this really is the right thing to do then cancel_delayed_work should
> zap the work func itselt I think.
> 
> Signed-off-by: Christoph Lameter 
> 
> 
> Index: linux/mm/vmstat.c
> ===
> --- linux.orig/mm/vmstat.c2014-07-29 10:22:45.073884943 -0500
> +++ linux/mm/vmstat.c 2014-07-29 10:34:45.083369228 -0500
> @@ -1277,8 +1277,8 @@ static int vmstat_cpuup_callback(struct
>   break;
>   case CPU_DOWN_PREPARE:
>   case CPU_DOWN_PREPARE_FROZEN:
> - cancel_delayed_work_sync(&per_cpu(vmstat_work, cpu));
>   per_cpu(vmstat_work, cpu).work.func = NULL;
> + cancel_delayed_work_sync(&per_cpu(vmstat_work, cpu));

I think we should just remove "per_cpu(vmstat_work, cpu).work.func = NULL;"

>   break;
>   case CPU_DOWN_FAILED:
>   case CPU_DOWN_FAILED_FROZEN:
> .
> 

--
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: linux-next: build failure after merge of the tip tree

[John Stultz]

On 07/29/2014 04:56 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 25 Jul 2014 14:45:22 +1000 Stephen Rothwell
 wrote:
>>
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> arch/powerpc/kernel/time.c:743:6: error: conflicting types for
'update_vsyscall_old'
>>  void update_vsyscall_old(struct timespec *wall_time, struct timespec
*wtm,
>>   ^
>> In file included from arch/powerpc/kernel/time.c:77:0:
>> include/linux/timekeeper_internal.h:114:13: note: previous
declaration of 'update_vsyscall_old' was here
>>  extern void update_vsyscall_old(struct timespec *ts, struct timespec
*wtm,
>>  ^
>>
>> Caused by commit 4a0e637738f0 ("clocksource: Get rid of cycle_last").
>>
>> I have used the tip tree from next-20140724 for today.
>
> Ping?
So I sent a fix for this the other day ([PATCH] timekeeping: Fixup typo
in update_vsyscall_old definition), but I've not heard anything from
anyone on it.


thanks
-john

--
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] ASoC: fsl_spdif: Add stream names for DPCM usage

[Nicolin Chen]

DPCM needs extra dapm routes in the machine driver to route audio
between Front-End and Back-End. In order to differ the stream names
in the route map from CODECs, we here add specific stream names to
SPDIF driver so that we can implement ASRC via DPCM to it.

Signed-off-by: Nicolin Chen 
---
 sound/soc/fsl/fsl_spdif.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
index 495b9f3..70acfe4 100644
--- a/sound/soc/fsl/fsl_spdif.c
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -975,12 +975,14 @@ static int fsl_spdif_dai_probe(struct snd_soc_dai *dai)
 static struct snd_soc_dai_driver fsl_spdif_dai = {
.probe = &fsl_spdif_dai_probe,
.playback = {
+   .stream_name = "CPU-Playback",
.channels_min = 2,
.channels_max = 2,
.rates = FSL_SPDIF_RATES_PLAYBACK,
.formats = FSL_SPDIF_FORMATS_PLAYBACK,
},
.capture = {
+   .stream_name = "CPU-Capture",
.channels_min = 2,
.channels_max = 2,
.rates = FSL_SPDIF_RATES_CAPTURE,
-- 
1.8.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 2/4] ASoC: fsl_sai: Add stream names for DPCM usage

[Nicolin Chen]

DPCM needs extra dapm routes in the machine driver to route audio
between Front-End and Back-End. In order to differ the stream names
in the route map from CODECs, we here add specific stream names to
SAI driver so that we can implement ASRC via DPCM to it.

Signed-off-by: Nicolin Chen 
---
 sound/soc/fsl/fsl_sai.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 364410b..faa0497 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -455,12 +455,14 @@ static int fsl_sai_dai_probe(struct snd_soc_dai *cpu_dai)
 static struct snd_soc_dai_driver fsl_sai_dai = {
.probe = fsl_sai_dai_probe,
.playback = {
+   .stream_name = "CPU-Playback",
.channels_min = 1,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_96000,
.formats = FSL_SAI_FORMATS,
},
.capture = {
+   .stream_name = "CPU-Capture",
.channels_min = 1,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_96000,
-- 
1.8.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 1/4] ASoC: fsl_esai: Add stream names for DPCM usage

[Nicolin Chen]

DPCM needs extra dapm routes in the machine driver to route audio
between Front-End and Back-End. In order to differ the stream names
in the route map from CODECs, we here add specific stream names to
ESAI driver so that we can implement ASRC via DPCM to it.

Signed-off-by: Nicolin Chen 
---
 sound/soc/fsl/fsl_esai.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index d719caf..72d154e 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -624,12 +624,14 @@ static int fsl_esai_dai_probe(struct snd_soc_dai *dai)
 static struct snd_soc_dai_driver fsl_esai_dai = {
.probe = fsl_esai_dai_probe,
.playback = {
+   .stream_name = "CPU-Playback",
.channels_min = 1,
.channels_max = 12,
.rates = FSL_ESAI_RATES,
.formats = FSL_ESAI_FORMATS,
},
.capture = {
+   .stream_name = "CPU-Capture",
.channels_min = 1,
.channels_max = 8,
.rates = FSL_ESAI_RATES,
-- 
1.8.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 4/4] ASoC: fsl_ssi: Add stream names for DPCM usage

[Nicolin Chen]

DPCM needs extra dapm routes in the machine driver to route audio
between Front-End and Back-End. In order to differ the stream names
in the route map from CODECs, we here add specific stream names to
SSI driver so that we can implement ASRC via DPCM to it.

Signed-off-by: Nicolin Chen 
---
 sound/soc/fsl/fsl_ssi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 3043d57..87eb577 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1032,12 +1032,14 @@ static const struct snd_soc_dai_ops fsl_ssi_dai_ops = {
 static struct snd_soc_dai_driver fsl_ssi_dai_template = {
.probe = fsl_ssi_dai_probe,
.playback = {
+   .stream_name = "CPU-Playback",
.channels_min = 1,
.channels_max = 2,
.rates = FSLSSI_I2S_RATES,
.formats = FSLSSI_I2S_FORMATS,
},
.capture = {
+   .stream_name = "CPU-Capture",
.channels_min = 1,
.channels_max = 2,
.rates = FSLSSI_I2S_RATES,
-- 
1.8.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 0/4] ASoC: fsl: Add stream names to CPU DAI drivers for DPCM

[Nicolin Chen]

DPCM needs extra dapm routes in the machine driver to route audio
between Front-End and Back-End. In order to differ the stream names
in the route map from CODECs, we here add specific stream names to
all Freescale ASoC CPU DAI drivers so that we can implement ASRC via
DPCM to each of them.

Document for DPCM: ./Documentation/sound/alsa/soc/DPCM.txt

Nicolin Chen (4):
  ASoC: fsl_esai: Add stream names for DPCM usage
  ASoC: fsl_sai: Add stream names for DPCM usage
  ASoC: fsl_spdif: Add stream names for DPCM usage
  ASoC: fsl_ssi: Add stream names for DPCM usage

 sound/soc/fsl/fsl_esai.c  | 2 ++
 sound/soc/fsl/fsl_sai.c   | 2 ++
 sound/soc/fsl/fsl_spdif.c | 2 ++
 sound/soc/fsl/fsl_ssi.c   | 2 ++
 4 files changed, 8 insertions(+)

-- 
1.8.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: vmstat: On demand vmstat workers V8

[Lai Jiangshan]

On 07/11/2014 11:17 PM, Christoph Lameter wrote:
> On Fri, 11 Jul 2014, Frederic Weisbecker wrote:
> 
>>> Converted what? We still need to keep a cpumask around that tells us which
>>> processor have vmstat running and which do not.
>>>
>>
>> Converted to cpumask_var_t.
>>
>> I mean we spent dozens emails on that...
> 
> 
> Oh there is this outstanding fix, right.
> 
> 
> Subject: on demand vmstat: Do not open code alloc_cpumask_var
> 
> Signed-off-by: Christoph Lameter 
> 
> Index: linux/mm/vmstat.c
> ===
> --- linux.orig/mm/vmstat.c2014-07-11 10:15:55.356856916 -0500
> +++ linux/mm/vmstat.c 2014-07-11 10:15:55.352856994 -0500
> @@ -1244,7 +1244,7 @@
>  #ifdef CONFIG_SMP
>  static DEFINE_PER_CPU(struct delayed_work, vmstat_work);
>  int sysctl_stat_interval __read_mostly = HZ;
> -struct cpumask *cpu_stat_off;
> +cpumask_var_t cpu_stat_off;
> 
>  static void vmstat_update(struct work_struct *w)
>  {
> @@ -1338,7 +1338,8 @@
>   INIT_DEFERRABLE_WORK(per_cpu_ptr(&vmstat_work, cpu),
>   vmstat_update);
> 
> - cpu_stat_off = kmalloc(cpumask_size(), GFP_KERNEL);
> + if (!alloc_cpumask_var(&cpu_stat_off, GFP_KERNEL))
> + BUG();

BUG_ON(!alloc_cpumask_var(&cpu_stat_off, GFP_KERNEL));

>   cpumask_copy(cpu_stat_off, cpu_online_mask);
> 
>   schedule_delayed_work(&shepherd,
> --
> 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/
> .
> 

--
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: vmstat: On demand vmstat workers V8

[Lai Jiangshan]

If I understand the semantics of the cpu_stat_off correctly, please read.

cpu_stat_off = a set of such CPU: the cpu is online && vmstat_work is off
I consider some code forget to guarantee each cpu in cpu_stat_off is online.

Thanks,
Lai

On 07/10/2014 10:04 PM, Christoph Lameter wrote:

> +
> +/*
> + * Shepherd worker thread that checks the
> + * differentials of processors that have their worker
> + * threads for vm statistics updates disabled because of
> + * inactivity.
> + */
> +static void vmstat_shepherd(struct work_struct *w);
> +
> +static DECLARE_DELAYED_WORK(shepherd, vmstat_shepherd);
> +
> +static void vmstat_shepherd(struct work_struct *w)
> +{
> + int cpu;
> +
> + /* Check processors whose vmstat worker threads have been disabled */

I think the bug is here, it re-queues the per_cpu(vmstat_work, cpu) which is 
offline
(after vmstat_cpuup_callback(CPU_DOWN_PREPARE).  And cpu_stat_off is accessed 
without
proper lock.

I suggest to use get_cpu_online() or a new cpu_stat_off_mutex to protect it.


get_cpu_online(); /* mutex_lock(&cpu_stat_off_mutex); */
for_each_cpu(cpu, cpu_stat_off)
if (need_update(cpu) &&
cpumask_test_and_clear_cpu(cpu, cpu_stat_off))

schedule_delayed_work_on(cpu, &per_cpu(vmstat_work, 
cpu),
__round_jiffies_relative(sysctl_stat_interval, 
cpu));
put_cpu_online(); /* mutex_unlock(&cpu_stat_off_mutex); */



> +
> +
> + schedule_delayed_work(&shepherd,
>   round_jiffies_relative(sysctl_stat_interval));
> +
>  }
> 
> -static void start_cpu_timer(int cpu)
> +static void __init start_shepherd_timer(void)
>  {
> - struct delayed_work *work = &per_cpu(vmstat_work, cpu);
> + int cpu;
> +
> + for_each_possible_cpu(cpu)
> + INIT_DEFERRABLE_WORK(per_cpu_ptr(&vmstat_work, cpu),
> + vmstat_update);
> +
> + cpu_stat_off = kmalloc(cpumask_size(), GFP_KERNEL);
> + cpumask_copy(cpu_stat_off, cpu_online_mask);
> 
> - INIT_DEFERRABLE_WORK(work, vmstat_update);
> - schedule_delayed_work_on(cpu, work, __round_jiffies_relative(HZ, cpu));
> + schedule_delayed_work(&shepherd,
> + round_jiffies_relative(sysctl_stat_interval));
>  }
> 
>  static void vmstat_cpu_dead(int node)
> @@ -1272,17 +1373,17 @@ static int vmstat_cpuup_callback(struct
>   case CPU_ONLINE:
>   case CPU_ONLINE_FROZEN:
>   refresh_zone_stat_thresholds();
> - start_cpu_timer(cpu);
>   node_set_state(cpu_to_node(cpu), N_CPU);
> + cpumask_set_cpu(cpu, cpu_stat_off);
>   break;
>   case CPU_DOWN_PREPARE:
>   case CPU_DOWN_PREPARE_FROZEN:
> - cancel_delayed_work_sync(&per_cpu(vmstat_work, cpu));
> - per_cpu(vmstat_work, cpu).work.func = NULL;
> + if (!cpumask_test_and_set_cpu(cpu, cpu_stat_off))
> + cancel_delayed_work_sync(&per_cpu(vmstat_work, cpu));

It is suggest that cancel_delayed_work_sync(&per_cpu(vmstat_work, cpu)) should
be called unconditionally.  And the cpu should be cleared from cpu_stat_off.
(you set it, it is BUG according to vmstat_shepherd() and the semantics of the
cpu_stat_off).

/* mutex_lock(&cpu_stat_off_mutex); */
/*if you use cpu_stat_off_mutex instead of get_cpu_online() */
cancel_delayed_work_sync(&per_cpu(vmstat_work, cpu));
cpumask_clear_cpu(cpu, cpu_stat_off);
/* mutex_unlock(&cpu_stat_off_mutex); */

/* don't forget to use cpu_stat_off_mutex on other place for
   accessing to cpu_stat_off except the one in vmstat_update() which
   is protected by cancel_delayed_work_sync() + other stuffs
   please also update that comments and keep that VM_BUG_ON() */


>   break;
>   case CPU_DOWN_FAILED:
>   case CPU_DOWN_FAILED_FROZEN:
> - start_cpu_timer(cpu);
> + cpumask_set_cpu(cpu, cpu_stat_off);
>   break;
>   case CPU_DEAD:
>   case CPU_DEAD_FROZEN:
> @@ -1302,15 +1403,10 @@ static struct notifier_block vmstat_noti
>  static int __init setup_vmstat(void)
>  {
>  #ifdef CONFIG_SMP
> - int cpu;
> -
>   cpu_notifier_register_begin();
>   __register_cpu_notifier(&vmstat_notifier);
> 
> - for_each_online_cpu(cpu) {
> - start_cpu_timer(cpu);
> - node_set_state(cpu_to_node(cpu), N_CPU);
> - }
> + start_shepherd_timer();
>   cpu_notifier_register_done();
>  #endif
>  #ifdef CONFIG_PROC_FS
> --
> 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/
> .
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More ma

Re: use IORESOURCE_REG resource type for non-translatable addresses in DT

[Rob Herring]

On Tue, Jul 29, 2014 at 8:07 PM, Stephen Boyd  wrote:
> On 07/29/14 16:45, Grant Likely wrote:
>> On Tue, 29 Jul 2014 17:06:42 +0300, Stanimir Varbanov  
>> wrote:
>>>
>>> This was just an example. Of course it has many issues and probaly it is
>>> wrong:) The main goal was to understand does IORESOURCE_REG resource
>>> type and parsing the *reg* properties for non-translatable addresses are
>>> feasible. And also does it acceptable by community and OF platform
>>> maintainers.
>> The use case is actually very different from of_address_to_resource or
>> of_get_address() because those APIs explicitly return physical memory
>> addresses from the CPU perspective. It makes more sense to create a new
>> API that doesn't attempt to translate the reg address. Alternately, a
>> new API that only translates upto a given parent node.
>
> The most important thing is that platform_get_resource{_by_name}(&pdev,
> IORESOURCE_REG, n) returns the reg property and optional size encoded
> into a struct resource. I think Rob is suggesting we circumvent the
> entire of_address_to_resource() path and do some if
> (IS_ENABLED(CONFIG_OF) && type == IORESOURCE_REG) check in
> platform_get_resource() to package up the reg property into a struct
> resource. That should work.

No, I'm saying why are you using platform_get_resource at all and
adding a new resource type? I don't see any advantage.

You might as well do of_property_read_u32 in the below example.

Rob

> It sounds like you think partially translating addresses is risky
> though. Fair enough. Perhaps we should call WARN() if someone tries to
> call platform_get_resource() with IORESOURCE_REG and the parent node has
> a ranges property that isn't a one-to-one conversion. That way if we
> want to do something like this we can.
>
> pmic@0 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0>;
>
> regulators {
> ranges;
> #address-cells = <1>;
> #size-cells = <0>;
>
> regulator@40 {
> reg = <0x40>;
> };
>
> regulator@50 {
> reg = <0x50>;
> }
> };
> };
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
>
--
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: [f2fs-dev] [PATCH 07/11] f2fs: enable in-place-update for fdatasync

[Chao Yu]

Hi Jaegeuk Changman,

> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Wednesday, July 30, 2014 9:08 AM
> To: Changman Lee
> Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Subject: Re: [f2fs-dev] [PATCH 07/11] f2fs: enable in-place-update for 
> fdatasync
> 
> On Wed, Jul 30, 2014 at 08:54:55AM +0900, Changman Lee wrote:
> > On Tue, Jul 29, 2014 at 05:22:15AM -0700, Jaegeuk Kim wrote:
> > > Hi Changman,
> > >
> > > On Tue, Jul 29, 2014 at 09:41:11AM +0900, Changman Lee wrote:
> > > > Hi Jaegeuk,
> > > >
> > > > On Fri, Jul 25, 2014 at 03:47:21PM -0700, Jaegeuk Kim wrote:
> > > > > This patch enforces in-place-updates only when fdatasync is requested.
> > > > > If we adopt this in-place-updates for the fdatasync, we can skip to 
> > > > > write the
> > > > > recovery information.
> > > >
> > > > But, as you know, random write occurs when changing into 
> > > > in-place-updates.
> > > > It will degrade write performance. Is there any case in-place-updates is
> > > > better, except recovery or high utilization?
> > >
> > > As I described, you can easily imagine, if users requested small amount 
> > > of data
> > > writes with fdatasync, we should do data writes + node writes.
> > > But, if we can do in-place-update, we don't need to write node blocks.
> > > Surely it triggers random writes, however, the amount of data is preety 
> > > small
> > > and the device handles them very fast by its inside cache, so that it can
> > > enhance the performance.
> > >
> > > Thanks,
> >
> > Partially agree. Sometimes, I see that SSR shows lower performance than
> > IPU. One of the reasons might be node writes.
> 
> What did you mean? That's why I consider IPU eagarly instead of SSR and LFS
> under the very strict cases.
> 
> > Anyway, if so, we should know total dirty pages for fdatasync and it's very
> > tunable according to a random write performance of device.
> 
> Agreed. We can do that either by comparing the number of dirty pages,
> additional data/node writes, and cost of checkpoint at the same time.
> And there is another thing is that we need to consider the number of
> waiting time for end_io.
> I'll look into this at some time.

Agreed, but please additionally consider that the number we got is not highly
accurate because without protection of ->i_mutex writer could generate more
dirty pages.

> 
> Thanks,
> 
> >
> > Thanks,
> >
> > >
> > > >
> > > > Thanks
> > > >
> > > > >
> > > > > Signed-off-by: Jaegeuk Kim 
> > > > > ---
> > > > >  fs/f2fs/f2fs.h| 1 +
> > > > >  fs/f2fs/file.c| 7 +++
> > > > >  fs/f2fs/segment.h | 4 
> > > > >  3 files changed, 12 insertions(+)
> > > > >
> > > > > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > > > > index ab36025..8f8685e 100644
> > > > > --- a/fs/f2fs/f2fs.h
> > > > > +++ b/fs/f2fs/f2fs.h
> > > > > @@ -998,6 +998,7 @@ enum {
> > > > >   FI_INLINE_DATA, /* used for inline data*/
> > > > >   FI_APPEND_WRITE,/* inode has appended data */
> > > > >   FI_UPDATE_WRITE,/* inode has in-place-update data */
> > > > > + FI_NEED_IPU,/* used fo ipu for fdatasync */
> > > > >  };
> > > > >
> > > > >  static inline void set_inode_flag(struct f2fs_inode_info *fi, int 
> > > > > flag)
> > > > > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> > > > > index 121689a..e339856 100644
> > > > > --- a/fs/f2fs/file.c
> > > > > +++ b/fs/f2fs/file.c
> > > > > @@ -127,11 +127,18 @@ int f2fs_sync_file(struct file *file, loff_t 
> > > > > start, loff_t end,
> int datasync)
> > > > >   return 0;
> > > > >
> > > > >   trace_f2fs_sync_file_enter(inode);
> > > > > +
> > > > > + /* if fdatasync is triggered, let's do in-place-update */
> > > > > + if (datasync)
> > > > > + set_inode_flag(fi, FI_NEED_IPU);
> > > > > +
> > > > >   ret = filemap_write_and_wait_range(inode->i_mapping, start, 
> > > > > end);
> > > > >   if (ret) {
> > > > >   trace_f2fs_sync_file_exit(inode, need_cp, datasync, 
> > > > > ret);
> > > > >   return ret;
> > > > >   }
> > > > > + if (datasync)
> > > > > + clear_inode_flag(fi, FI_NEED_IPU);
> > > > >
> > > > >   /*
> > > > >* if there is no written data, don't waste time to write 
> > > > > recovery info.
> > > > > diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
> > > > > index ee5c75e..55973f7 100644
> > > > > --- a/fs/f2fs/segment.h
> > > > > +++ b/fs/f2fs/segment.h
> > > > > @@ -486,6 +486,10 @@ static inline bool need_inplace_update(struct 
> > > > > inode *inode)
> > > > >   if (S_ISDIR(inode->i_mode))
> > > > >   return false;
> > > > >
> > > > > + /* this is only set during fdatasync */
> > > > > + if (is_inode_flag_set(F2FS_I(inode), FI_NEED_IPU))
> > > > > + return true;
> > > > > +
> > > > >   switch (SM_I(sbi)->ipu_policy) {
> > > > >   case F2FS_IPU_FORCE:
> > > 

Re: [RFC PATCH 00/11] Refactor MSI to support Non-PCI device

[Yijing Wang]

On 2014/7/29 22:08, Arnd Bergmann wrote:
> On Saturday 26 July 2014 11:08:37 Yijing Wang wrote:
>> The series is a draft of generic MSI driver that supports PCI
>> and Non-PCI device which have MSI capability. If you're not interested
>> it, sorry for the noise.
> 
> I've finally managed to take some time to look at the series. Overall,
> the concept looks good to me, and the patches look very well implemented.
> 
> The part I'm not sure about is the interface we want to end up with
> at the end of the series. More on that below

Hi Arnd,
   Thanks for your review and comments very much!
Please refer the inline comments.

> 
>> The series is based on Linux-3.16-rc1.
>>
>> MSI was introduced in PCI Spec 2.2. Currently, kernel MSI 
>> driver codes are bonding with PCI device. Because MSI has a lot
>> advantages in design. More and more non-PCI devices want to
>> use MSI as their default interrupt. The existing MSI device
>> include HPET. HPET driver provide its own MSI code to initialize
>> and process MSI interrupts. In the latest GIC v3 spec, legacy device
>> can deliver MSI by the help of a relay device named consolidator.
>> Consolidator can translate the legacy interrupts connected to it
>> to MSI/MSI-X. And new non-PCI device will be designed to 
>> support MSI in future. So make the MSI driver code be generic will 
>> help the non-PCI device use MSI more simply.
>>
>> The new data struct for generic MSI driver.
>> struct msi_irqs {
>> u8 msi_enabled:1; /* Enable flag */
>> u8 msix_enabled:1;
>> struct list_head msi_list; /* MSI desc list */
>> void *data; /* help to find the MSI device */
>> struct msi_ops *ops; /* MSI device specific hook */
>> };
>> struct msi_irqs is used to manage MSI related informations. Every device 
>> supports
>> MSI should contain this data struct and allocate it.
> 
> I think you should have a stronger association with the 'struct
> device' here. Can you replace the 'void *data' with 'struct device *dev'?

Actually, I used the struct device *dev in my first draft, finally, I replaced
it with void *data, because some MSI devices don't have a struct device *dev,
like the existing hpet device, dmar msi device, and OF device, like the ARM 
consolidator.

Of course, we can make the MSI devices have their own struct device, and 
register to
device tree, eg, add a class device named MSI_DEV. But I'm not sure whether it 
is appropriate.

> 
> The other part I'm not completely sure about is how you want to
> have MSIs map into normal IRQ descriptors. At the moment, all
> MSI users are based on IRQ numbers, but this has known scalability problems.

Hmmm, I still use the IRQ number to map the MSIs to IRQ description.
I'm sorry, I don't understand you meaning.
What are the scalability problems you mentioned ?
For device drivers, they always process interrupt in two steps.
If irq is the legacy interrupt, drivers will first
use the irq_of_parse_and_map() or pci_enable_device() to parse and get the IRQ 
number.
Then drivers will call the request_irq() to register the interrupt handler.
If irq is MSIs, first call pci_enable_msi/x() to get the IRQ number and then 
call
request_irq() to register interrupt handler.

> I wonder if we can do the interface in a way that
> hides the interrupt number from generic device drivers and just
> passes a 'struct irq_desc'. Note that there are long-term plans to
> get rid of IRQ numbers entirely, but those plans have existed for
> a long time already without anybody seriously addressing the device
> driver interfaces so far, so it might never really happen.
> 

Maybe this is a huge work, now hundreds drivers use the IRQ number, so maybe we 
can consider
this in a separate title.

>> struct msi_ops {
>> struct msi_desc *(*msi_setup_entry)(struct msi_irqs *msi, struct 
>> msi_desc *entry);
>> int msix_setup_entries(struct msi_irqs *msi, struct msix_entry 
>> *entries);
>> u32 (*msi_mask_irq)(struct msi_desc *desc, u32 mask, u32 flag);
>> u32 (*msix_mask_irq)(struct msi_desc *desc, u32 flag);
>> void (*msi_read_message)(struct msi_desc *desc, struct msi_msg *msg);
>> void (*msi_write_message)(struct msi_desc *desc, struct msi_msg 
>> *msg);
>> void (*msi_set_intx)(struct msi_irqs *msi, int enable);
>> };
>> struct msi_ops provides several hook functions, generic MSI driver will call
>> the hook functions to access device specific registers. PCI devices will 
>> share
>> the same msi_ops, because they have the same way to access MSI hardware 
>> registers.
>>
>> Generic MSI layer export msi_capability_init() and msix_capability_init() 
>> functions
>> to drivers. msi/x_capability_init() will initialize MSI capability data 
>> struct msi_desc
>> and alloc the irq, then write the msi address/data value to hardware 
>> registers.
>>
>> This series only did compile test, we will test it in x86 and arm platform 
>> later.
> 
> For the generic drivers, I don'

Re: [PATCH] ARM: imx: clk-vf610: introduce clks_init_on

[Shawn Guo]

On Tue, Jul 29, 2014 at 04:20:28PM +0200, Stefan Agner wrote:
> At the end of the boot process, the clock framework might disable
> required main PLL's. So far, this was no issue since drivers
> requested clocks, which are descended of the main PLL's (e.g.
> pll1_pfd1, which provides the system clock).
> 
> To archive the full 500MHz system clock, DDR clock need to be a
> descendant of PLL2 rather than PLL1 (DDRC_CLK_SEL set to 0). The
> bootloader sets up the clocks accordingly before making use of
> DDR at all. However, in Linux, there is no driver using PLL2,
> which lead to PLL2 being disabled by the clock framework.
> 
> With this patch, we make sure that the main system clock and the
> DDR clock are initially enabled and are kept enabled.
> 
> Signed-off-by: Stefan Agner 

Applied, 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: [RESEND RFC V2] devicetree: Dialog Semiconductor consolidate existing vendor prefixes to standardise on 'dlg'

[Simon Horman]

On Mon, Jul 28, 2014 at 09:53:56AM +, Opensource [Steve Twiss] wrote:
> On 25 July 2014 08:00, Lee Jones wrote:
> 
> >On Thu, 24 Jul 2014, Opensource [Steve Twiss] wrote:
> >> From: Steve Twiss 
> >>
> >> This patch series updates the device tree vendor prefix for
> >> Dialog Semiconductor.
> >>
> >> Various methods are currently used throughout the kernel: 'diasemi',
> >> 'dialog' and 'dlg'. Others have also been suggested.
> >>
> >> This patch set aims to consolidate the usage of the vendor prefix to
> >> use a common standard. The prefix 'dlg' is used.
> >>
> >>
> >> Signed-off-by: Steve Twiss 
> >
> >Didn't I Ack the MFD parts already?
> >
> 
> Yes -- certainly.
>  (I should have put them in the main body of the e-mail shouldn't I ..?)
> 
> I just need the SHMobile responses now.
> I will try to make contact with those guys this week.

Hi Steve,

I apologise for not noticing this earlier:
I am entirely unsure how I missed it.

In principle I am fine with this change so long as it does not
introduce any backwards-compatibility problems. In particular removing
compatibility strings that may already be in use by DTB blobs in the wild.

For SH Mobile it seems that Lager and Koelsch were using "diasemi,da9210"
which is unsupported by the driver at this time. So it seems there is no
backwards-compatibility problem there. I'm less sure about other aspects of
the patch. And I'm also less concerned about them.

I do have a slight preference for SH Mobile changes to go through my
renesas tree rather than elsewhere (as part of a more global change)
principally to try to avoid the possibility of conflicts. The SH Mobile dts
files in question are often updated. And for example I notice some fuzz
when applying this patch on top of the next-20140729 tag of linux-next.

If you were to break out the SH Mobile portion of this patch I would be
happy to take it once the driver portion is accepted.  That said, I do see
that everyone else has acked the change so clearly this is not an issue
from their point of view. So I will not complain if you decide not to break
the patch up (though please note my warning about possible conflicts).

In the case where you do not want to split up the patch:
Acked-by: Simon Horman 

> I have the following Acks so far.
> 
> >From: Rob Herring on 21 July 2014 16:43
> >I'm okay with this, but it also needs acks from i.MX and SHMobile
> >folks as it could break out of tree users.
> >  Acked-by: Rob Herring 
> 
> >From: Shawn Guo on 22 July 2014 02:38
> >arch/arm/boot/dts/imx53-smd.dts|  2 +-
> >arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi   |  2 +-
> >  Acked-by: Shawn Guo 
> 
> >From: Lee Jones on 22 July 2014 08:09
> >For the MFD changes:
> >  Acked-by: Lee Jones 
> 
> and
> 
> >From: Philipp Zabel on 24 July 2014 20:44
> >  Acked-by: Philipp Zabel 
--
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] drivers: staging: vt6655: ioctl.c - missing __user annotation

[Anil Shashikumar Belur]

On Tuesday 29 July 2014 02:47 PM, Dan Carpenter wrote:
> On Tue, Jul 29, 2014 at 10:05:38AM +0200, Tobias Klauser wrote:
>
>> Wouldn't it be better to annotate the data member in struct tagSCmdRequest
>> with __user instead of introducing all these casts?

Hi,

Yes, having the data member annotated as '__user' in 'struct
tagSCmdRequest' looks like a much cleaner way for fixing these warnings.
I will re-work on this patch this patch and submit again.

Thanks,
Anil
--
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 2/4] driver core: enable drivers to use deferred probefrom init

[Tetsuo Handa]

Luis R. Rodriguez wrote:
> Tetsuo is it possible / desirable to allow tasks to not kill unless the
> reason is OOM ? Its unclear if this was discussed before, sorry if it was,
> have just been a bit busy today to review the archive / discussions on this.

Are we aware that the 10 seconds timeout after SIGKILL is not the duration
between the beginning of module loading and the end of kthread_create() but
the duration to wait for kthreadd to create a new kernel thread?

If the kthreadd is unable to create a new kernel thread within 10 seconds,
something very bad is happening. For example, memory allocation deadlock
sequence shown below might be happening.

 (1) process1 holds a mutex using mutex_lock().
 (2) process1 calls kthread_create() and enters into killable wait state
 at wait_for_completion_killable().
 (3) kthreadd calls kernel_thread() and enters into oom-killable busy loop
 due to out of memory at alloc_pages_nodemask().
 (4) process2 is chosen by the OOM killer, but process2 is unable to
 terminate because process2 is waiting in unkillable state at
 mutex_lock() which was held by process1 at (1).
 (5) kthreadd continues busy loop because process2 does not release memory
 and the OOM killer does not kill more processes.
 (6) process1 continues waiting in oom-killable state because process1 is
 not chosen by the OOM killer.

See? The system will remain unresponding unless somebody releases memory
that is enough for kthreadd to complete. We cannot teach process1 that
process1 needs to give up waiting for kthreadd and call mutex_unlock()
in order to allow process2 to terminate. Also, we cannot teach the OOM
killer that process1 needs to be oom-killed after process2 is oom-killed.

Making the 10 seconds timeout after SIGKILL longer is safe.
Changing it to no-timeout-unless-oom-killed is unsafe.
--
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/

linux-next: manual merge of the pm tree with the arm-soc tree

[Stephen Rothwell]

Hi Rafael,

Today's linux-next merge of the pm tree got a conflict in
drivers/cpuidle/Kconfig.arm between commit 2aaafcdb6883 ("cpuidle:
big.LITTLE: Add ARCH_EXYNOS entry in config") from the arm-soc tree and
commit 6ee7f5dd57fc ("cpuidle: big_little: Fix build error") from the
pm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/cpuidle/Kconfig.arm
index 33fc0ff0af1c,a186dec8e5df..
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@@ -1,9 -1,16 +1,10 @@@
  #
  # ARM CPU Idle drivers
  #
 -config ARM_ARMADA_370_XP_CPUIDLE
 -  bool "CPU Idle Driver for Armada 370/XP family processors"
 -  depends on ARCH_MVEBU
 -  help
 -Select this to enable cpuidle on Armada 370/XP processors.
 -
  config ARM_BIG_LITTLE_CPUIDLE
bool "Support for ARM big.LITTLE processors"
 -  depends on ARCH_VEXPRESS_TC2_PM
 +  depends on ARCH_VEXPRESS_TC2_PM || ARCH_EXYNOS
+   depends on MCPM
select ARM_CPU_SUSPEND
select CPU_IDLE_MULTIPLE_DRIVERS
help


signature.asc
Description: PGP signature

Re: [LKP] [drm/i915] WARNING: CPU: 3 PID: 248 at drivers/gpu/drm/i915/intel_pm.c:6427 check_power_well_state+0x60/0x90 [i915]()

[Aaron Lu]

On 07/29/2014 07:10 PM, Daniel Vetter wrote:
> On Tue, Jul 29, 2014 at 12:14 PM, Ville Syrjälä
>  wrote:
>> On Tue, Jul 29, 2014 at 10:43:02AM +0800, Aaron Lu wrote:
>>> FYI, we noticed the below changes on
>>>
>>> git://people.freedesktop.org/~danvet/drm colder-fusion
>>
>> Does it happen on -nightly too?
> 
> git://anongit.freedesktop.org/drm-intel

With this git tree, do we still need to watch the old one? Or they serve
different purpose?

Thanks,
Aaron

> 
> Not sure whether you guys have that branch, since this is the first
> time I've received a report from LKP.
> -Daniel
> 
>>
>>> commit 571484b4d8c2f23feebcd7e0d9259174650b5da0 ("drm/i915: Add chv cmnlane 
>>> power wells")
>>>
>>> +-+++
>>> | | ad593b242a | 571484b4d8 |
>>> +-+++
>>> | boot_successes  | 10 | 10 |
>>> | early-boot-hang | 1  | 1  |
>>> +-+++
>>>
>>>
>>> [   11.884746] fbcon: inteldrmfb (fb0) is primary device
>>> [   12.012144] [drm:vlv_set_power_well] *ERROR* timout setting power well 
>>> state 0300 ()
>>> [   12.012146] [ cut here ]
>>> [   12.012179] WARNING: CPU: 3 PID: 248 at 
>>> drivers/gpu/drm/i915/intel_pm.c:6427 check_power_well_state+0x60/0x90 
>>> [i915]()
>>> [   12.012180] state mismatch for 'dpio-common-d' (always_on 0 hw state 1 
>>> use-count 0 disable_power_well 1
>>> [   12.012189] Modules linked in: ata_generic(+) snd_hda_intel(+) 
>>> snd_hda_controller i915(+) snd_hda_codec firewire_ohci video firewire_core 
>>> drm_kms_helper nuvoton_cir crc_itu_t pata_acpi snd_hwdep ahci serio_raw 
>>> snd_pcm libahci snd_timer parport_pc snd floppy(+) parport pcspkr libata 
>>> rc_core soundcore i2c_i801 drm
>>> [   12.012191] CPU: 3 PID: 248 Comm: modprobe Not tainted 
>>> 3.16.0-rc7-02031-g4efe1515 #1
>>> [   12.012192] Hardware name:  /DQ67SW, BIOS 
>>> SWQ6710H.86A.0047.2011.0222.1058 02/22/2011
>>> [   12.012194]  0009 88007fabb2f8 8182e6de 
>>> 88007fabb340
>>> [   12.012195]  88007fabb330 8106d0ed a0294860 
>>> a0294860
>>> [   12.012196]  0100 88007f0e8568 88007f0e 
>>> 88007fabb390
>>> [   12.012197] Call Trace:
>>> [   12.012201]  [] dump_stack+0x4d/0x66
>>> [   12.012204]  [] warn_slowpath_common+0x7d/0xa0
>>> [   12.012206]  [] warn_slowpath_fmt+0x4c/0x50
>>> [   12.012218]  [] ? vlv_power_well_enabled+0x7d/0xa0 
>>> [i915]
>>> [   12.012228]  [] check_power_well_state+0x60/0x90 [i915]
>>> [   12.012241]  [] intel_display_power_put+0xe5/0x160 
>>> [i915]
>>> [   12.012259]  [] intel_display_set_init_power+0x2a/0x50 
>>> [i915]
>>> [   12.012273]  [] 
>>> modeset_update_crtc_power_domains+0xf2/0x150 [i915]
>>> [   12.012286]  [] snb_modeset_global_resources+0xe/0x10 
>>> [i915]
>>> [   12.012297]  [] __intel_set_mode+0x5d8/0xab0 [i915]
>>> [   12.012310]  [] intel_set_mode+0x16/0x30 [i915]
>>> [   12.012321]  [] intel_crtc_set_config+0x91c/0xe50 
>>> [i915]
>>> [   12.012333]  [] drm_mode_set_config_internal+0x64/0xf0 
>>> [drm]
>>> [   12.012338]  [] restore_fbdev_mode+0xb3/0xe0 
>>> [drm_kms_helper]
>>> [   12.012341]  [] 
>>> drm_fb_helper_restore_fbdev_mode_unlocked+0x23/0x40 [drm_kms_helper]
>>> [   12.012344]  [] drm_fb_helper_set_par+0x28/0x70 
>>> [drm_kms_helper]
>>> [   12.012359]  [] intel_fbdev_set_par+0x1a/0x60 [i915]
>>> [   12.012361]  [] fbcon_init+0x4f4/0x580
>>> [   12.012363]  [] visual_init+0xb8/0x120
>>> [   12.012365]  [] do_bind_con_driver+0x163/0x330
>>> [   12.012367]  [] do_take_over_console+0x114/0x1c0
>>> [   12.012368]  [] do_fbcon_takeover+0x63/0xd0
>>> [   12.012369]  [] fbcon_event_notify+0x68d/0x7e0
>>> [   12.012371]  [] notifier_call_chain+0x4c/0x70
>>> [   12.012373]  [] 
>>> __blocking_notifier_call_chain+0x4d/0x70
>>> [   12.012374]  [] blocking_notifier_call_chain+0x16/0x20
>>> [   12.012376]  [] fb_notifier_call_chain+0x1b/0x20
>>> [   12.012378]  [] register_framebuffer+0x1e6/0x320
>>> [   12.012381]  [] 
>>> drm_fb_helper_initial_config+0x2fe/0x4b0 [drm_kms_helper]
>>> [   12.012394]  [] ? gen6_write32+0x6a/0x120 [i915]
>>> [   12.012408]  [] intel_fbdev_initial_config+0x1f/0x30 
>>> [i915]
>>> [   12.012424]  [] i915_driver_load+0xfbd/0x1050 [i915]
>>> [   12.012427]  [] ? kobject_uevent_env+0x178/0x690
>>> [   12.012429]  [] ? get_device+0x17/0x30
>>> [   12.012431]  [] ? klist_class_dev_get+0x15/0x20
>>> [   12.012433]  [] ? klist_add_tail+0x3a/0x40
>>> [   12.012434]  [] ? device_add+0x1f9/0x610
>>> [   12.012442]  [] ? drm_sysfs_device_add+0xd6/0x120 [drm]
>>> [   12.012448]  [] drm_dev_register+0xad/0x100 [drm]
>>> [   12.012455]  [] drm_get_pci_dev+0x8f/0x1f0 [drm]
>>> [   12.012467]  [] i915_pci_probe+0x3b/0x60 [i915]
>>> [   12.012469]  [] local_pci_probe+0x45/0xa0
>>> [   12.012470]  [] ? pci_match_device+0xe5/0x110
>>> [   12.012472]  [] pci_device_probe+0xd1/0x13

[PATCH 3.4 06/10] mm: hugetlb: fix copy_hugetlb_page_range()

[Greg Kroah-Hartman]

3.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Naoya Horiguchi 

commit 0253d634e0803a8376a0d88efee0bf523d8673f9 upstream.

Commit 4a705fef9862 ("hugetlb: fix copy_hugetlb_page_range() to handle
migration/hwpoisoned entry") changed the order of
huge_ptep_set_wrprotect() and huge_ptep_get(), which leads to breakage
in some workloads like hugepage-backed heap allocation via libhugetlbfs.
This patch fixes it.

The test program for the problem is shown below:

  $ cat heap.c
  #include 
  #include 
  #include 

  #define HPS 0x20

  int main() {
int i;
char *p = malloc(HPS);
memset(p, '1', HPS);
for (i = 0; i < 5; i++) {
if (!fork()) {
memset(p, '2', HPS);
p = malloc(HPS);
memset(p, '3', HPS);
free(p);
return 0;
}
}
sleep(1);
free(p);
return 0;
  }

  $ export HUGETLB_MORECORE=yes ; export HUGETLB_NO_PREFAULT= ; hugectl --heap 
./heap

Fixes 4a705fef9862 ("hugetlb: fix copy_hugetlb_page_range() to handle
migration/hwpoisoned entry"), so is applicable to -stable kernels which
include it.

Signed-off-by: Naoya Horiguchi 
Reported-by: Guillaume Morin 
Suggested-by: Guillaume Morin 
Acked-by: Hugh Dickins 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 mm/hugetlb.c |1 +
 1 file changed, 1 insertion(+)

--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2348,6 +2348,7 @@ int copy_hugetlb_page_range(struct mm_st
} else {
if (cow)
huge_ptep_set_wrprotect(src, addr, src_pte);
+   entry = huge_ptep_get(src_pte);
ptepage = pte_page(entry);
get_page(ptepage);
page_dup_rmap(ptepage);


--
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 02/10] libata: support the ata host which implements a queue depth less than 32

[Greg Kroah-Hartman]

3.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Kevin Hao 

commit 1871ee134b73fb4cadab75752a7152ed2813c751 upstream.

The sata on fsl mpc8315e is broken after the commit 8a4aeec8d2d6
("libata/ahci: accommodate tag ordered controllers"). The reason is
that the ata controller on this SoC only implement a queue depth of
16. When issuing the commands in tag order, all the commands in tag
16 ~ 31 are mapped to tag 0 unconditionally and then causes the sata
malfunction. It makes no senses to use a 32 queue in software while
the hardware has less queue depth. So consider the queue depth
implemented by the hardware when requesting a command tag.

Fixes: 8a4aeec8d2d6 ("libata/ahci: accommodate tag ordered controllers")
Signed-off-by: Kevin Hao 
Acked-by: Dan Williams 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/ata/libata-core.c |   22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4693,6 +4693,10 @@ void swap_buf_le16(u16 *buf, unsigned in
  * ata_qc_new - Request an available ATA command, for queueing
  * @ap: target port
  *
+ * Some ATA host controllers may implement a queue depth which is less
+ * than ATA_MAX_QUEUE. So we shouldn't allocate a tag which is beyond
+ * the hardware limitation.
+ *
  * LOCKING:
  * None.
  */
@@ -4700,14 +4704,16 @@ void swap_buf_le16(u16 *buf, unsigned in
 static struct ata_queued_cmd *ata_qc_new(struct ata_port *ap)
 {
struct ata_queued_cmd *qc = NULL;
-   unsigned int i, tag;
+   unsigned int i, tag, max_queue;
+
+   max_queue = ap->scsi_host->can_queue;
 
/* no command while frozen */
if (unlikely(ap->pflags & ATA_PFLAG_FROZEN))
return NULL;
 
-   for (i = 0; i < ATA_MAX_QUEUE; i++) {
-   tag = (i + ap->last_tag + 1) % ATA_MAX_QUEUE;
+   for (i = 0, tag = ap->last_tag + 1; i < max_queue; i++, tag++) {
+   tag = tag < max_queue ? tag : 0;
 
/* the last tag is reserved for internal command. */
if (tag == ATA_TAG_INTERNAL)
@@ -6041,6 +6047,16 @@ int ata_host_register(struct ata_host *h
 {
int i, rc;
 
+   /*
+* The max queue supported by hardware must not be greater than
+* ATA_MAX_QUEUE.
+*/
+   if (sht->can_queue > ATA_MAX_QUEUE) {
+   dev_err(host->dev, "BUG: the hardware max queue is too 
large\n");
+   WARN_ON(1);
+   return -EINVAL;
+   }
+
/* host must have been started */
if (!(host->flags & ATA_HOST_STARTED)) {
dev_err(host->dev, "BUG: trying to register unstarted host\n");


--
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: [LKP] [sched/numa] a43455a1d57: +94.1% proc-vmstat.numa_hint_faults_local

[Aaron Lu]

On Tue, Jul 29, 2014 at 04:04:37PM -0400, Rik van Riel wrote:
> On Tue, 29 Jul 2014 10:17:12 +0200
> Peter Zijlstra  wrote:
> 
> > > +#define NUMA_SCALE 1000
> > > +#define NUMA_MOVE_THRESH 50
> > 
> > Please make that 1024, there's no reason not to use power of two here.
> > This base 10 factor thing annoyed me no end already, its time for it to
> > die.
> 
> That's easy enough.  However, it would be good to know whether
> this actually helps with the regression Aaron found :)

Sorry for the delay.

I applied the last patch and queued the hackbench job to the ivb42 test
machine for it to run 5 times, and here is the result(regarding the
proc-vmstat.numa_hint_faults_local field):
173565
201262
192317
198342
198595
avg:
192816

It seems it is still very big than previous kernels.

BTW, to highlight changes, we only include metrics that have changed a
lot in the report, which means, for metrics that don't show in the
report, it means it doesn't change much. But just in case, here is the
throughput metric regarding commit a43455a1d(compared to its parent):

ebe06187bf2aec1   a43455a1d572daf7b730fe12e  
---   -  
118881 ~ 0%+1.2%120325 ~ 0% ivb42/hackbench/50%-threads-pipe
 78410 ~ 0%+0.6% 78857 ~ 0% 
lkp-snb01/hackbench/50%-threads-socket
197292 ~ 0%+1.0%199182 ~ 0% TOTAL hackbench.throughput

Feel free to let me know if you need more information.

Thanks,
Aaron

> 
> ---8<---
> 
> Subject: sched,numa: prevent task moves with marginal benefit
> 
> Commit a43455a1d57 makes task_numa_migrate() always check the
> preferred node for task placement. This is causing a performance
> regression with hackbench, as well as SPECjbb2005.
> 
> Tracing task_numa_compare() with a single instance of SPECjbb2005
> on a 4 node system, I have seen several thread swaps with tiny
> improvements. 
> 
> It appears that the hysteresis code that was added to task_numa_compare
> is not doing what we needed it to do, and a simple threshold could be
> better.
> 
> Aaron, does this patch help, or am I barking up the wrong tree?
> 
> Reported-by: Aaron Lu 
> Reported-by: Jirka Hladky 
> Signed-off-by: Rik van Riel 
> ---
>  kernel/sched/fair.c | 24 +++-
>  1 file changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 4f5e3c2..9bd283b 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -924,10 +924,12 @@ static inline unsigned long group_faults_cpu(struct 
> numa_group *group, int nid)
>  
>  /*
>   * These return the fraction of accesses done by a particular task, or
> - * task group, on a particular numa node.  The group weight is given a
> - * larger multiplier, in order to group tasks together that are almost
> - * evenly spread out between numa nodes.
> + * task group, on a particular numa node.  The NUMA move threshold
> + * prevents task moves with marginal improvement, and is set to 5%.
>   */
> +#define NUMA_SCALE 1024
> +#define NUMA_MOVE_THRESH (5 * NUMA_SCALE / 100)
> +
>  static inline unsigned long task_weight(struct task_struct *p, int nid)
>  {
>   unsigned long total_faults;
> @@ -940,7 +942,7 @@ static inline unsigned long task_weight(struct 
> task_struct *p, int nid)
>   if (!total_faults)
>   return 0;
>  
> - return 1000 * task_faults(p, nid) / total_faults;
> + return NUMA_SCALE * task_faults(p, nid) / total_faults;
>  }
>  
>  static inline unsigned long group_weight(struct task_struct *p, int nid)
> @@ -948,7 +950,7 @@ static inline unsigned long group_weight(struct 
> task_struct *p, int nid)
>   if (!p->numa_group || !p->numa_group->total_faults)
>   return 0;
>  
> - return 1000 * group_faults(p, nid) / p->numa_group->total_faults;
> + return NUMA_SCALE * group_faults(p, nid) / p->numa_group->total_faults;
>  }
>  
>  bool should_numa_migrate_memory(struct task_struct *p, struct page * page,
> @@ -1181,11 +1183,11 @@ static void task_numa_compare(struct task_numa_env 
> *env,
>   imp = taskimp + task_weight(cur, env->src_nid) -
> task_weight(cur, env->dst_nid);
>   /*
> -  * Add some hysteresis to prevent swapping the
> -  * tasks within a group over tiny differences.
> +  * Do not swap tasks within a group around unless
> +  * there is a significant improvement.
>*/
> - if (cur->numa_group)
> - imp -= imp/16;
> + if (cur->numa_group && imp < NUMA_MOVE_THRESH)
> + goto unlock;
>   } else {
>   /*
>* Compare the group weights. If a task is all by
> @@ -1205,6 +1207,10 @@ static void task_numa_compare(struct task_numa_env 
> *env,
>   goto unlock;
>  
>   if

[PATCH 3.4 09/10] introduce SIZE_MAX

[Greg Kroah-Hartman]

3.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Xi Wang 

commit a3860c1c5dd1137db23d7786d284939c5761d517 upstream.

ULONG_MAX is often used to check for integer overflow when calculating
allocation size.  While ULONG_MAX happens to work on most systems, there
is no guarantee that `size_t' must be the same size as `long'.

This patch introduces SIZE_MAX, the maximum value of `size_t', to improve
portability and readability for allocation size validation.

Signed-off-by: Xi Wang 
Acked-by: Alex Elder 
Cc: David Airlie 
Cc: Pekka Enberg 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Cc: Qiang Huang 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/ceph/snap.c |2 +-
 include/drm/drm_mem_util.h |4 ++--
 include/linux/kernel.h |1 +
 include/linux/slab.h   |2 +-
 4 files changed, 5 insertions(+), 4 deletions(-)

--- a/fs/ceph/snap.c
+++ b/fs/ceph/snap.c
@@ -331,7 +331,7 @@ static int build_snap_context(struct cep
 
/* alloc new snap context */
err = -ENOMEM;
-   if (num > (ULONG_MAX - sizeof(*snapc)) / sizeof(u64))
+   if (num > (SIZE_MAX - sizeof(*snapc)) / sizeof(u64))
goto fail;
snapc = kzalloc(sizeof(*snapc) + num*sizeof(u64), GFP_NOFS);
if (!snapc)
--- a/include/drm/drm_mem_util.h
+++ b/include/drm/drm_mem_util.h
@@ -31,7 +31,7 @@
 
 static __inline__ void *drm_calloc_large(size_t nmemb, size_t size)
 {
-   if (size != 0 && nmemb > ULONG_MAX / size)
+   if (size != 0 && nmemb > SIZE_MAX / size)
return NULL;
 
if (size * nmemb <= PAGE_SIZE)
@@ -44,7 +44,7 @@ static __inline__ void *drm_calloc_large
 /* Modeled after cairo's malloc_ab, it's like calloc but without the zeroing. 
*/
 static __inline__ void *drm_malloc_ab(size_t nmemb, size_t size)
 {
-   if (size != 0 && nmemb > ULONG_MAX / size)
+   if (size != 0 && nmemb > SIZE_MAX / size)
return NULL;
 
if (size * nmemb <= PAGE_SIZE)
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -35,6 +35,7 @@
 #define LLONG_MAX  ((long long)(~0ULL>>1))
 #define LLONG_MIN  (-LLONG_MAX - 1)
 #define ULLONG_MAX (~0ULL)
+#define SIZE_MAX   (~(size_t)0)
 
 #define STACK_MAGIC0xdeadbeef
 
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -242,7 +242,7 @@ size_t ksize(const void *);
  */
 static inline void *kmalloc_array(size_t n, size_t size, gfp_t flags)
 {
-   if (size != 0 && n > ULONG_MAX / size)
+   if (size != 0 && n > SIZE_MAX / size)
return NULL;
return __kmalloc(n * size, flags);
 }


--
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 08/10] s390/ptrace: fix PSW mask check

[Greg Kroah-Hartman]

3.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Martin Schwidefsky 

commit dab6cf55f81a6e16b8147aed9a843e1691dcd318 upstream.

The PSW mask check of the PTRACE_POKEUSR_AREA command is incorrect.
The PSW_MASK_USER define contains the PSW_MASK_ASC bits, the ptrace
interface accepts all combinations for the address-space-control
bits. To protect the kernel space the PSW mask check in ptrace needs
to reject the address-space-control bit combination for home space.

Fixes CVE-2014-3534

Signed-off-by: Martin Schwidefsky 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/s390/kernel/ptrace.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/arch/s390/kernel/ptrace.c
+++ b/arch/s390/kernel/ptrace.c
@@ -292,7 +292,9 @@ static int __poke_user(struct task_struc
 * psw and gprs are stored on the stack
 */
if (addr == (addr_t) &dummy->regs.psw.mask &&
-   ((data & ~PSW_MASK_USER) != psw_user_bits ||
+   (((data^psw_user_bits) & ~PSW_MASK_USER) ||
+(((data^psw_user_bits) & PSW_MASK_ASC) &&
+ ((data|psw_user_bits) & PSW_MASK_ASC) == PSW_MASK_ASC) ||
 ((data & PSW_MASK_EA) && !(data & PSW_MASK_BA
/* Invalid psw mask. */
return -EINVAL;
@@ -595,7 +597,10 @@ static int __poke_user_compat(struct tas
 */
if (addr == (addr_t) &dummy32->regs.psw.mask) {
/* Build a 64 bit psw mask from 31 bit mask. */
-   if ((tmp & ~PSW32_MASK_USER) != psw32_user_bits)
+   if (((tmp^psw32_user_bits) & ~PSW32_MASK_USER) ||
+   (((tmp^psw32_user_bits) & PSW32_MASK_ASC) &&
+((tmp|psw32_user_bits) & PSW32_MASK_ASC)
+== PSW32_MASK_ASC))
/* Invalid psw mask. */
return -EINVAL;
regs->psw.mask = (regs->psw.mask & ~PSW_MASK_USER) |


--
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 03/10] libata: introduce ata_host->n_tags to avoid oops on SAS controllers

[Greg Kroah-Hartman]

3.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Tejun Heo 

commit 1a112d10f03e83fb3a2fdc4c9165865dec8a3ca6 upstream.

1871ee134b73 ("libata: support the ata host which implements a queue
depth less than 32") directly used ata_port->scsi_host->can_queue from
ata_qc_new() to determine the number of tags supported by the host;
unfortunately, SAS controllers doing SATA don't initialize ->scsi_host
leading to the following oops.

 BUG: unable to handle kernel NULL pointer dereference at 0058
 IP: [] ata_qc_new_init+0x188/0x1b0
 PGD 0
 Oops: 0002 [#1] SMP
 Modules linked in: isci libsas scsi_transport_sas mgag200 drm_kms_helper ttm
 CPU: 1 PID: 518 Comm: udevd Not tainted 3.16.0-rc6+ #62
 Hardware name: Intel Corporation S2600CO/S2600CO, BIOS 
SE5C600.86B.02.02.0002.122320131210 12/23/2013
 task: 880c1a00b280 ti: 88061a00 task.ti: 88061a00
 RIP: 0010:[]  [] 
ata_qc_new_init+0x188/0x1b0
 RSP: 0018:88061a003ae8  EFLAGS: 00010012
 RAX: 0001 RBX: 88000241ca80 RCX: 00fa
 RDX: 0020 RSI: 0020 RDI: 8806194aa298
 RBP: 88061a003ae8 R08: 8806194a8000 R09: 
 R10:  R11: 88000241ca80 R12: 88061ad58200
 R13: 8806194aa298 R14: 814e67a0 R15: 8806194a8000
 FS:  7f3ad7fe3840() GS:88062762() knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2: 0058 CR3: 00061a118000 CR4: 001407e0
 Stack:
  88061a003b20 814e96e1 88000241ca80 88061ad58200
  8800b6bf6000 880c1c988000 880619903850 88061a003b68
  a0056ce1 88061a003b48 13d6e6f8 88000241ca80
 Call Trace:
  [] ata_sas_queuecmd+0xa1/0x430
  [] sas_queuecommand+0x191/0x220 [libsas]
  [] scsi_dispatch_cmd+0x10e/0x300 [] 
scsi_request_fn+0x2f5/0x550
  [] __blk_run_queue+0x33/0x40
  [] queue_unplugged+0x2a/0x90
  [] blk_flush_plug_list+0x1b4/0x210
  [] blk_finish_plug+0x14/0x50
  [] __do_page_cache_readahead+0x198/0x1f0
  [] force_page_cache_readahead+0x31/0x50
  [] page_cache_sync_readahead+0x3e/0x50
  [] generic_file_read_iter+0x496/0x5a0
  [] blkdev_read_iter+0x37/0x40
  [] new_sync_read+0x7e/0xb0
  [] vfs_read+0x94/0x170
  [] SyS_read+0x46/0xb0
  [] ? SyS_lseek+0x91/0xb0
  [] system_call_fastpath+0x16/0x1b
 Code: 00 00 00 88 50 29 83 7f 08 01 19 d2 83 e2 f0 83 ea 50 88 50 34 c6 81 1d 
02 00 00 40 c6 81 17 02 00 00 00 5d c3 66 0f 1f 44 00 00 <89> 14 25 58 00 00 00

Fix it by introducing ata_host->n_tags which is initialized to
ATA_MAX_QUEUE - 1 in ata_host_init() for SAS controllers and set to
scsi_host_template->can_queue in ata_host_register() for !SAS ones.
As SAS hosts are never registered, this will give them the same
ATA_MAX_QUEUE - 1 as before.  Note that we can't use
scsi_host->can_queue directly for SAS hosts anyway as they can go
higher than the libata maximum.

Signed-off-by: Tejun Heo 
Reported-by: Mike Qiu 
Reported-by: Jesse Brandeburg 
Reported-by: Peter Hurley 
Reported-by: Peter Zijlstra 
Tested-by: Alexey Kardashevskiy 
Fixes: 1871ee134b73 ("libata: support the ata host which implements a queue 
depth less than 32")
Cc: Kevin Hao 
Cc: Dan Williams 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/ata/libata-core.c |   16 
 include/linux/libata.h|1 +
 2 files changed, 5 insertions(+), 12 deletions(-)

--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4704,9 +4704,8 @@ void swap_buf_le16(u16 *buf, unsigned in
 static struct ata_queued_cmd *ata_qc_new(struct ata_port *ap)
 {
struct ata_queued_cmd *qc = NULL;
-   unsigned int i, tag, max_queue;
-
-   max_queue = ap->scsi_host->can_queue;
+   unsigned int max_queue = ap->host->n_tags;
+   unsigned int i, tag;
 
/* no command while frozen */
if (unlikely(ap->pflags & ATA_PFLAG_FROZEN))
@@ -5965,6 +5964,7 @@ void ata_host_init(struct ata_host *host
 {
spin_lock_init(&host->lock);
mutex_init(&host->eh_mutex);
+   host->n_tags = ATA_MAX_QUEUE - 1;
host->dev = dev;
host->flags = flags;
host->ops = ops;
@@ -6047,15 +6047,7 @@ int ata_host_register(struct ata_host *h
 {
int i, rc;
 
-   /*
-* The max queue supported by hardware must not be greater than
-* ATA_MAX_QUEUE.
-*/
-   if (sht->can_queue > ATA_MAX_QUEUE) {
-   dev_err(host->dev, "BUG: the hardware max queue is too 
large\n");
-   WARN_ON(1);
-   return -EINVAL;
-   }
+   host->n_tags = clamp(sht->can_queue, 1, ATA_MAX_QUEUE - 1);
 
/* host must have been started */
if (!(host->flags & ATA_HOST_STARTED)) {
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -539,6 +539,7 @@ struct ata_host {
struct device   *dev;
void __iomem * const*iomap;
unsigned intn_ports;
+ 

[PATCH 3.4 01/10] block: dont assume last put of shared tags is for the host

[Greg Kroah-Hartman]

3.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Christoph Hellwig 

commit d45b3279a5a2252cafcd665bbf2db8c9b31ef783 upstream.

There is no inherent reason why the last put of a tag structure must be
the one for the Scsi_Host, as device model objects can be held for
arbitrary periods.  Merge blk_free_tags and __blk_free_tags into a single
funtion that just release a references and get rid of the BUG() when the
host reference wasn't the last.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

---
 block/blk-tag.c |   33 +++--
 1 file changed, 7 insertions(+), 26 deletions(-)

--- a/block/blk-tag.c
+++ b/block/blk-tag.c
@@ -27,18 +27,15 @@ struct request *blk_queue_find_tag(struc
 EXPORT_SYMBOL(blk_queue_find_tag);
 
 /**
- * __blk_free_tags - release a given set of tag maintenance info
+ * blk_free_tags - release a given set of tag maintenance info
  * @bqt:   the tag map to free
  *
- * Tries to free the specified @bqt.  Returns true if it was
- * actually freed and false if there are still references using it
+ * Drop the reference count on @bqt and frees it when the last reference
+ * is dropped.
  */
-static int __blk_free_tags(struct blk_queue_tag *bqt)
+void blk_free_tags(struct blk_queue_tag *bqt)
 {
-   int retval;
-
-   retval = atomic_dec_and_test(&bqt->refcnt);
-   if (retval) {
+   if (atomic_dec_and_test(&bqt->refcnt)) {
BUG_ON(find_first_bit(bqt->tag_map, bqt->max_depth) <
bqt->max_depth);
 
@@ -50,9 +47,8 @@ static int __blk_free_tags(struct blk_qu
 
kfree(bqt);
}
-
-   return retval;
 }
+EXPORT_SYMBOL(blk_free_tags);
 
 /**
  * __blk_queue_free_tags - release tag maintenance info
@@ -69,28 +65,13 @@ void __blk_queue_free_tags(struct reques
if (!bqt)
return;
 
-   __blk_free_tags(bqt);
+   blk_free_tags(bqt);
 
q->queue_tags = NULL;
queue_flag_clear_unlocked(QUEUE_FLAG_QUEUED, q);
 }
 
 /**
- * blk_free_tags - release a given set of tag maintenance info
- * @bqt:   the tag map to free
- *
- * For externally managed @bqt frees the map.  Callers of this
- * function must guarantee to have released all the queues that
- * might have been using this tag map.
- */
-void blk_free_tags(struct blk_queue_tag *bqt)
-{
-   if (unlikely(!__blk_free_tags(bqt)))
-   BUG();
-}
-EXPORT_SYMBOL(blk_free_tags);
-
-/**
  * blk_queue_free_tags - release tag maintenance info
  * @q:  the request queue for the device
  *


--
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 10/10] mm: kmemleak: avoid false negatives on vmalloced objects

[Greg Kroah-Hartman]

3.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Catalin Marinas 

commit 7f88f88f83ed609650a01b18572e605ea50cd163 upstream.

Commit 248ac0e1943a ("mm/vmalloc: remove guard page from between vmap
blocks") had the side effect of making vmap_area.va_end member point to
the next vmap_area.va_start.  This was creating an artificial reference
to vmalloc'ed objects and kmemleak was rarely reporting vmalloc() leaks.

This patch marks the vmap_area containing pointers explicitly and
reduces the min ref_count to 2 as vm_struct still contains a reference
to the vmalloc'ed object.  The kmemleak add_scan_area() function has
been improved to allow a SIZE_MAX argument covering the rest of the
object (for simpler calling sites).

Signed-off-by: Catalin Marinas 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[hq: Backported to 3.4: Adjust context]
Signed-off-by: Qiang Huang 
Signed-off-by: Greg Kroah-Hartman 


---
 mm/kmemleak.c |4 +++-
 mm/vmalloc.c  |   14 ++
 2 files changed, 13 insertions(+), 5 deletions(-)

--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -750,7 +750,9 @@ static void add_scan_area(unsigned long
}
 
spin_lock_irqsave(&object->lock, flags);
-   if (ptr + size > object->pointer + object->size) {
+   if (size == SIZE_MAX) {
+   size = object->pointer + object->size - ptr;
+   } else if (ptr + size > object->pointer + object->size) {
kmemleak_warn("Scan area larger than object 0x%08lx\n", ptr);
dump_object_info(object);
kmem_cache_free(scan_area_cache, area);
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -349,6 +349,12 @@ static struct vmap_area *alloc_vmap_area
if (unlikely(!va))
return ERR_PTR(-ENOMEM);
 
+   /*
+* Only scan the relevant parts containing pointers to other objects
+* to avoid false negatives.
+*/
+   kmemleak_scan_area(&va->rb_node, SIZE_MAX, gfp_mask & GFP_RECLAIM_MASK);
+
 retry:
spin_lock(&vmap_area_lock);
/*
@@ -1669,11 +1675,11 @@ void *__vmalloc_node_range(unsigned long
insert_vmalloc_vmlist(area);
 
/*
-* A ref_count = 3 is needed because the vm_struct and vmap_area
-* structures allocated in the __get_vm_area_node() function contain
-* references to the virtual address of the vmalloc'ed block.
+* A ref_count = 2 is needed because vm_struct allocated in
+* __get_vm_area_node() contains a reference to the virtual address of
+* the vmalloc'ed block.
 */
-   kmemleak_alloc(addr, real_size, 3, gfp_mask);
+   kmemleak_alloc(addr, real_size, 2, gfp_mask);
 
return addr;
 


--
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 04/10] ahci: add support for the Promise FastTrak TX8660 SATA HBA (ahci mode)

[Greg Kroah-Hartman]

3.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Romain Degez 

commit b32bfc06aefab61acc872dec3222624e6cd867ed upstream.

Add support of the Promise FastTrak TX8660 SATA HBA in ahci mode by
registering the board in the ahci_pci_tbl[].

Note: this HBA also provide a hardware RAID mode when activated in
BIOS but specific drivers from the manufacturer are required in this
case.

Signed-off-by: Romain Degez 
Tested-by: Romain Degez 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/ata/ahci.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -446,6 +446,7 @@ static const struct pci_device_id ahci_p
 
/* Promise */
{ PCI_VDEVICE(PROMISE, 0x3f20), board_ahci },   /* PDC42819 */
+   { PCI_VDEVICE(PROMISE, 0x3781), board_ahci },   /* FastTrak TX8660 
ahci-mode */
 
/* Asmedia */
{ PCI_VDEVICE(ASMEDIA, 0x0601), board_ahci },   /* ASM1060 */


--
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/