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(>dev);
if (!pdata) {
pdata = ads7846_probe_dt(>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(_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,
+  );
+   if (ret == 0)
+   return 0;
+
+   if (dma_assign_coherent_memory(dev, mem) == 0)
+   return ret;
+
+   

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, );
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 

[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, );
> +
> +  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, );
> +
> +  /* 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 ([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:: Fcntl commands for 

[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(_cpu(vmstat_work, cpu));
>   per_cpu(vmstat_work, cpu).work.func = NULL;
> + cancel_delayed_work_sync(_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 = _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(_work, cpu),
>   vmstat_update);
> 
> - cpu_stat_off = kmalloc(cpumask_size(), GFP_KERNEL);
> + if (!alloc_cpumask_var(_stat_off, GFP_KERNEL))
> + BUG();

BUG_ON(!alloc_cpumask_var(_stat_off, GFP_KERNEL));

>   cpumask_copy(cpu_stat_off, cpu_online_mask);
> 
>   schedule_delayed_work(,
> --
> 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(_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, _cpu(vmstat_work, 
cpu),
__round_jiffies_relative(sysctl_stat_interval, 
cpu));
put_cpu_online(); /* mutex_unlock(_stat_off_mutex); */



> +
> +
> + schedule_delayed_work(,
>   round_jiffies_relative(sysctl_stat_interval));
> +
>  }
> 
> -static void start_cpu_timer(int cpu)
> +static void __init start_shepherd_timer(void)
>  {
> - struct delayed_work *work = _cpu(vmstat_work, cpu);
> + int cpu;
> +
> + for_each_possible_cpu(cpu)
> + INIT_DEFERRABLE_WORK(per_cpu_ptr(_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(,
> + 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(_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(_cpu(vmstat_work, cpu));

It is suggest that cancel_delayed_work_sync(_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(_stat_off_mutex); */
/*if you use cpu_stat_off_mutex instead of get_cpu_online() */
cancel_delayed_work_sync(_cpu(vmstat_work, cpu));
cpumask_clear_cpu(cpu, cpu_stat_off);
/* mutex_unlock(_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(_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 majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read 

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}(,
> 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 

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]  [] 

[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;
>  
>   

[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) >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) >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(>lock);
mutex_init(>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(>refcnt);
-   if (retval) {
+   if (atomic_dec_and_test(>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(>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(>rb_node, SIZE_MAX, gfp_mask & GFP_RECLAIM_MASK);
+
 retry:
spin_lock(_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/

[PATCH 3.10 02/21] media: tda10071: force modulation to QPSK on DVB-S

[Greg Kroah-Hartman]

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

--

From: Antti Palosaari 

commit db4175ae2095634dbecd4c847da439f9c83e1b3b upstream.

Only supported modulation for DVB-S is QPSK. Modulation parameter
contains invalid value for DVB-S on some cases, which leads driver
refusing tuning attempt. Due to that, hard code modulation to QPSK
in case of DVB-S.

Signed-off-by: Antti Palosaari 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/dvb-frontends/tda10071.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/drivers/media/dvb-frontends/tda10071.c
+++ b/drivers/media/dvb-frontends/tda10071.c
@@ -667,6 +667,7 @@ static int tda10071_set_frontend(struct
struct dtv_frontend_properties *c = >dtv_property_cache;
int ret, i;
u8 mode, rolloff, pilot, inversion, div;
+   fe_modulation_t modulation;
 
dev_dbg(>i2c->dev, "%s: delivery_system=%d modulation=%d " \
"frequency=%d symbol_rate=%d inversion=%d pilot=%d " \
@@ -701,10 +702,13 @@ static int tda10071_set_frontend(struct
 
switch (c->delivery_system) {
case SYS_DVBS:
+   modulation = QPSK;
rolloff = 0;
pilot = 2;
break;
case SYS_DVBS2:
+   modulation = c->modulation;
+
switch (c->rolloff) {
case ROLLOFF_20:
rolloff = 2;
@@ -749,7 +753,7 @@ static int tda10071_set_frontend(struct
 
for (i = 0, mode = 0xff; i < ARRAY_SIZE(TDA10071_MODCOD); i++) {
if (c->delivery_system == TDA10071_MODCOD[i].delivery_system &&
-   c->modulation == TDA10071_MODCOD[i].modulation &&
+   modulation == TDA10071_MODCOD[i].modulation &&
c->fec_inner == TDA10071_MODCOD[i].fec) {
mode = TDA10071_MODCOD[i].val;
dev_dbg(>i2c->dev, "%s: mode found=%02x\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/

[PATCH 3.10 03/21] block: provide compat ioctl for BLKZEROOUT

[Greg Kroah-Hartman]

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

--

From: Mikulas Patocka 

commit 3b3a1814d1703027f9867d0f5cbbfaf6c7482474 upstream.

This patch provides the compat BLKZEROOUT ioctl. The argument is a pointer
to two uint64_t values, so there is no need to translate it.

Signed-off-by: Mikulas Patocka 
Acked-by: Martin K. Petersen 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

---
 block/compat_ioctl.c |1 +
 1 file changed, 1 insertion(+)

--- a/block/compat_ioctl.c
+++ b/block/compat_ioctl.c
@@ -689,6 +689,7 @@ long compat_blkdev_ioctl(struct file *fi
case BLKROSET:
case BLKDISCARD:
case BLKSECDISCARD:
+   case BLKZEROOUT:
/*
 * the ones below are implemented in blkdev_locked_ioctl,
 * but we call blkdev_ioctl, which gets the lock for us


--
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.10 10/21] slab_common: Do not check for duplicate slab names

[Greg Kroah-Hartman]

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

--

From: Christoph Lameter 

commit 3e374919b314f20e2a04f641ebc1093d758f66a4 upstream.

SLUB can alias multiple slab kmem_create_requests to one slab cache to save
memory and increase the cache hotness. As a result the name of the slab can be
stale. Only check the name for duplicates if we are in debug mode where we do
not merge multiple caches.

This fixes the following problem reported by Jonathan Brassow:

  The problem with kmem_cache* is this:

  *) Assume CONFIG_SLUB is set
  1) kmem_cache_create(name="foo-a")
  - creates new kmem_cache structure
  2) kmem_cache_create(name="foo-b")
  - If identical cache characteristics, it will be merged with the previously
created cache associated with "foo-a".  The cache's refcount will be
incremented and an alias will be created via sysfs_slab_alias().
  3) kmem_cache_destroy()
  - Attempting to destroy cache associated with "foo-a", but instead the
refcount is simply decremented.  I don't even think the sysfs aliases are
ever removed...
  4) kmem_cache_create(name="foo-a")
  - This FAILS because kmem_cache_sanity_check colides with the existing
name ("foo-a") associated with the non-removed cache.

  This is a problem for RAID (specifically dm-raid) because the name used
  for the kmem_cache_create is ("raid%d-%p", level, mddev).  If the cache
  persists for long enough, the memory address of an old mddev will be
  reused for a new mddev - causing an identical formulation of the cache
  name.  Even though kmem_cache_destory had long ago been used to delete
  the old cache, the merging of caches has cause the name and cache of that
  old instance to be preserved and causes a colision (and thus failure) in
  kmem_cache_create().  I see this regularly in my testing.

Reported-by: Jonathan Brassow 
Signed-off-by: Christoph Lameter 
Signed-off-by: Pekka Enberg 
Signed-off-by: Greg Kroah-Hartman 

---
 mm/slab_common.c |2 ++
 1 file changed, 2 insertions(+)

--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -55,6 +55,7 @@ static int kmem_cache_sanity_check(struc
continue;
}
 
+#if !defined(CONFIG_SLUB) || !defined(CONFIG_SLUB_DEBUG_ON)
/*
 * For simplicity, we won't check this in the list of memcg
 * caches. We have control over memcg naming, and if there
@@ -68,6 +69,7 @@ static int kmem_cache_sanity_check(struc
s = NULL;
return -EINVAL;
}
+#endif
}
 
WARN_ON(strchr(name, ' ')); /* It confuses parsers */


--
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.10 04/21] block: dont assume last put of shared tags is for the host

[Greg Kroah-Hartman]

3.10-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(>refcnt);
-   if (retval) {
+   if (atomic_dec_and_test(>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.10 06/21] libata: introduce ata_host->n_tags to avoid oops on SAS controllers

[Greg Kroah-Hartman]

3.10-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
@@ -4769,9 +4769,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))
@@ -6079,6 +6078,7 @@ void ata_host_init(struct ata_host *host
 {
spin_lock_init(>lock);
mutex_init(>eh_mutex);
+   host->n_tags = ATA_MAX_QUEUE - 1;
host->dev = dev;
host->ops = ops;
 }
@@ -6160,15 +6160,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
@@ -547,6 +547,7 @@ struct ata_host {
struct device   *dev;
void __iomem * const*iomap;
unsigned intn_ports;
+   unsigned int

[PATCH 3.10 05/21] libata: support the ata host which implements a queue depth less than 32

[Greg Kroah-Hartman]

3.10-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
@@ -4758,6 +4758,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.
  */
@@ -4765,14 +4769,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)
@@ -6154,6 +6160,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/

[PATCH 3.10 07/21] ahci: add support for the Promise FastTrak TX8660 SATA HBA (ahci mode)

[Greg Kroah-Hartman]

3.10-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
@@ -455,6 +455,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/

[PATCH 3.10 08/21] blkcg: dont call into policy draining if root_blkg is already gone

[Greg Kroah-Hartman]

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

--

From: Tejun Heo 

commit 0b462c89e31f7eb6789713437eb551833ee16ff3 upstream.

While a queue is being destroyed, all the blkgs are destroyed and its
->root_blkg pointer is set to NULL.  If someone else starts to drain
while the queue is in this state, the following oops happens.

  NULL pointer dereference at 0028
  IP: [] blk_throtl_drain+0x84/0x230
  PGD e4a1067 PUD b773067 PMD 0
  Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
  Modules linked in: cfq_iosched(-) [last unloaded: cfq_iosched]
  CPU: 1 PID: 537 Comm: bash Not tainted 3.16.0-rc3-work+ #2
  Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  task: 88000e50 ti: 88000efd4000 task.ti: 88000efd4000
  RIP: 0010:[]  [] 
blk_throtl_drain+0x84/0x230
  RSP: 0018:88000efd7bf0  EFLAGS: 00010046
  RAX:  RBX: 880015091450 RCX: 0001
  RDX:  RSI:  RDI: 
  RBP: 88000efd7c10 R08:  R09: 0001
  R10: 88000e50 R11:  R12: 880015091450
  R13: 880015092e00 R14: 880015091d70 R15: 88001508fc28
  FS:  7f1332650740() GS:88001fa8() knlGS:
  CS:  0010 DS:  ES:  CR0: 8005003b
  CR2: 0028 CR3: 09446000 CR4: 06e0
  Stack:
   8144e8f6 880015091450  880015091d80
   88000efd7c28 8144ae2f 880015091450 88000efd7c58
   81427641 880015091450 82401f00 880015091450
  Call Trace:
   [] blkcg_drain_queue+0x1f/0x60
   [] __blk_drain_queue+0x71/0x180
   [] blk_queue_bypass_start+0x6e/0xb0
   [] blkcg_deactivate_policy+0x38/0x120
   [] blk_throtl_exit+0x34/0x50
   [] blkcg_exit_queue+0x35/0x40
   [] blk_release_queue+0x26/0xd0
   [] kobject_cleanup+0x38/0x70
   [] kobject_put+0x28/0x60
   [] blk_put_queue+0x15/0x20
   [] scsi_device_dev_release_usercontext+0x16b/0x1c0
   [] execute_in_process_context+0x89/0xa0
   [] scsi_device_dev_release+0x1c/0x20
   [] device_release+0x32/0xa0
   [] kobject_cleanup+0x38/0x70
   [] kobject_put+0x28/0x60
   [] put_device+0x17/0x20
   [] __scsi_remove_device+0xa9/0xe0
   [] scsi_remove_device+0x2b/0x40
   [] sdev_store_delete+0x27/0x30
   [] dev_attr_store+0x18/0x30
   [] sysfs_kf_write+0x3e/0x50
   [] kernfs_fop_write+0xe7/0x170
   [] vfs_write+0xaf/0x1d0
   [] SyS_write+0x4d/0xc0
   [] system_call_fastpath+0x16/0x1b

776687bce42b ("block, blk-mq: draining can't be skipped even if
bypass_depth was non-zero") made it easier to trigger this bug by
making blk_queue_bypass_start() drain even when it loses the first
bypass test to blk_cleanup_queue(); however, the bug has always been
there even before the commit as blk_queue_bypass_start() could race
against queue destruction, win the initial bypass test but perform the
actual draining after blk_cleanup_queue() already destroyed all blkgs.

Fix it by skippping calling into policy draining if all the blkgs are
already gone.

Signed-off-by: Tejun Heo 
Reported-by: Shirish Pargaonkar 
Reported-by: Sasha Levin 
Reported-by: Jet Chen 
Tested-by: Shirish Pargaonkar 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

---
 block/blk-cgroup.c |7 +++
 1 file changed, 7 insertions(+)

--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -876,6 +876,13 @@ void blkcg_drain_queue(struct request_qu
 {
lockdep_assert_held(q->queue_lock);
 
+   /*
+* @q could be exiting and already have destroyed all blkgs as
+* indicated by NULL root_blkg.  If so, don't confuse policies.
+*/
+   if (!q->root_blkg)
+   return;
+
blk_throtl_drain(q);
 }
 


--
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.10 01/21] media: hdpvr: fix two audio bugs

[Greg Kroah-Hartman]

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

--

From: Hans Verkuil 

commit 3445857b22eafb70a6ac258979e955b116bfd2c6 upstream.

When the audio encoding is changed the driver calls hdpvr_set_audio
with the current opt->audio_input value. However, that should have
been opt->audio_input + 1. So changing the audio encoding inadvertently
changes the input as well. This bug has always been there.

The second bug was introduced in kernel 3.10 and that broke the
default_audio_input module option handling: the audio encoding was
never switched to AC3 if default_audio_input was set to 2 (SPDIF input).

In addition, since starting with 3.10 the audio encoding is always set
at the start the first bug now always happens when the driver is loaded.
In the past this bug would only surface if the user would change the
audio encoding after the driver was loaded.

Also fixes a small trivial typo (bufffer -> buffer).

Signed-off-by: Hans Verkuil 
Reported-by: Scott Doty 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/usb/hdpvr/hdpvr-video.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/media/usb/hdpvr/hdpvr-video.c
+++ b/drivers/media/usb/hdpvr/hdpvr-video.c
@@ -81,7 +81,7 @@ static void hdpvr_read_bulk_callback(str
 }
 
 /*=*/
-/* bufffer bits */
+/* buffer bits */
 
 /* function expects dev->io_mutex to be hold by caller */
 int hdpvr_cancel_queue(struct hdpvr_device *dev)
@@ -921,7 +921,7 @@ static int hdpvr_s_ctrl(struct v4l2_ctrl
case V4L2_CID_MPEG_AUDIO_ENCODING:
if (dev->flags & HDPVR_FLAG_AC3_CAP) {
opt->audio_codec = ctrl->val;
-   return hdpvr_set_audio(dev, opt->audio_input,
+   return hdpvr_set_audio(dev, opt->audio_input + 1,
  opt->audio_codec);
}
return 0;
@@ -1191,7 +1191,7 @@ int hdpvr_register_videodev(struct hdpvr
v4l2_ctrl_new_std_menu(hdl, _ctrl_ops,
V4L2_CID_MPEG_AUDIO_ENCODING,
ac3 ? V4L2_MPEG_AUDIO_ENCODING_AC3 : 
V4L2_MPEG_AUDIO_ENCODING_AAC,
-   0x7, V4L2_MPEG_AUDIO_ENCODING_AAC);
+   0x7, ac3 ? dev->options.audio_codec : 
V4L2_MPEG_AUDIO_ENCODING_AAC);
v4l2_ctrl_new_std_menu(hdl, _ctrl_ops,
V4L2_CID_MPEG_VIDEO_ENCODING,
V4L2_MPEG_VIDEO_ENCODING_MPEG_4_AVC, 0x3,


--
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.10 09/21] tracing: Fix wraparound problems in "uptime" trace clock

[Greg Kroah-Hartman]

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

--

From: Tony Luck 

commit 58d4e21e50ff3cc57910a8abc20d7e14375d2f61 upstream.

The "uptime" trace clock added in:

commit 8aacf017b065a805d27467843490c976835eb4a5
tracing: Add "uptime" trace clock that uses jiffies

has wraparound problems when the system has been up more
than 1 hour 11 minutes and 34 seconds. It converts jiffies
to nanoseconds using:
(u64)jiffies_to_usecs(jiffy) * 1000ULL
but since jiffies_to_usecs() only returns a 32-bit value, it
truncates at 2^32 microseconds.  An additional problem on 32-bit
systems is that the argument is "unsigned long", so fixing the
return value only helps until 2^32 jiffies (49.7 days on a HZ=1000
system).

Avoid these problems by using jiffies_64 as our basis, and
not converting to nanoseconds (we do convert to clock_t because
user facing API must not be dependent on internal kernel
HZ values).

Link: 
http://lkml.kernel.org/p/99d63c5bfe9b320a3b428d773825a37095bf6a51.1405708254.git.tony.l...@intel.com

Fixes: 8aacf017b065 "tracing: Add "uptime" trace clock that uses jiffies"
Signed-off-by: Tony Luck 
Signed-off-by: Steven Rostedt 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/trace/trace.c   |2 +-
 kernel/trace/trace_clock.c |9 +
 2 files changed, 6 insertions(+), 5 deletions(-)

--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -741,7 +741,7 @@ static struct {
{ trace_clock_local,"local",1 },
{ trace_clock_global,   "global",   1 },
{ trace_clock_counter,  "counter",  0 },
-   { trace_clock_jiffies,  "uptime",   1 },
+   { trace_clock_jiffies,  "uptime",   0 },
{ trace_clock,  "perf", 1 },
ARCH_TRACE_CLOCKS
 };
--- a/kernel/trace/trace_clock.c
+++ b/kernel/trace/trace_clock.c
@@ -59,13 +59,14 @@ u64 notrace trace_clock(void)
 
 /*
  * trace_jiffy_clock(): Simply use jiffies as a clock counter.
+ * Note that this use of jiffies_64 is not completely safe on
+ * 32-bit systems. But the window is tiny, and the effect if
+ * we are affected is that we will have an obviously bogus
+ * timestamp on a trace event - i.e. not life threatening.
  */
 u64 notrace trace_clock_jiffies(void)
 {
-   u64 jiffy = jiffies - INITIAL_JIFFIES;
-
-   /* Return nsecs */
-   return (u64)jiffies_to_usecs(jiffy) * 1000ULL;
+   return jiffies_64_to_clock_t(jiffies_64 - INITIAL_JIFFIES);
 }
 
 /*


--
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.10 15/21] hwmon: (smsc47m192) Fix temperature limit and vrm write operations

[Greg Kroah-Hartman]

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

--

From: Guenter Roeck 

commit 043572d5444116b9d9ad8ae763cf069e7accbc30 upstream.

Temperature limit clamps are applied after converting the temperature
from milli-degrees C to degrees C, so either the clamp limit needs
to be specified in degrees C, not milli-degrees C, or clamping must
happen before converting to degrees C. Use the latter method to avoid
overflows.

vrm is an u8, so the written value needs to be limited to [0, 255].

Cc: Axel Lin 
Signed-off-by: Guenter Roeck 
Reviewed-by: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hwmon/smsc47m192.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/hwmon/smsc47m192.c
+++ b/drivers/hwmon/smsc47m192.c
@@ -86,7 +86,7 @@ static inline u8 IN_TO_REG(unsigned long
  */
 static inline s8 TEMP_TO_REG(int val)
 {
-   return clamp_val(SCALE(val, 1, 1000), -128000, 127000);
+   return SCALE(clamp_val(val, -128000, 127000), 1, 1000);
 }
 
 static inline int TEMP_FROM_REG(s8 val)
@@ -384,6 +384,8 @@ static ssize_t set_vrm(struct device *de
err = kstrtoul(buf, 10, );
if (err)
return err;
+   if (val > 255)
+   return -EINVAL;
 
data->vrm = val;
return count;


--
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.10 00/21] 3.10.51-stable review

[Greg Kroah-Hartman]

This is the start of the stable review cycle for the 3.10.51 release.
There are 21 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Fri Aug  1 01:48:18 UTC 2014.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.51-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman 
Linux 3.10.51-rc1

Zoltan Kiss 
core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors

Michael Brown 
x86/efi: Include a .bss section within the PE/COFF headers

Martin Schwidefsky 
s390/ptrace: fix PSW mask check

Linus Torvalds 
Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

Naoya Horiguchi 
mm: hugetlb: fix copy_hugetlb_page_range()

Sven Wegener 
x86_32, entry: Store badsys error code in %eax

Guenter Roeck 
hwmon: (smsc47m192) Fix temperature limit and vrm write operations

John David Anglin 
parisc: Remove SA_RESTORER define

Silesh C V 
coredump: fix the setting of PF_DUMPCORE

Dmitry Torokhov 
Input: fix defuzzing logic

Mikulas Patocka 
slab_common: fix the check for duplicate slab names

Christoph Lameter 
slab_common: Do not check for duplicate slab names

Tony Luck 
tracing: Fix wraparound problems in "uptime" trace clock

Tejun Heo 
blkcg: don't call into policy draining if root_blkg is already gone

Romain Degez 
ahci: add support for the Promise FastTrak TX8660 SATA HBA (ahci mode)

Tejun Heo 
libata: introduce ata_host->n_tags to avoid oops on SAS controllers

Kevin Hao 
libata: support the ata host which implements a queue depth less than 32

Christoph Hellwig 
block: don't assume last put of shared tags is for the host

Mikulas Patocka 
block: provide compat ioctl for BLKZEROOUT

Antti Palosaari 
media: tda10071: force modulation to QPSK on DVB-S

Hans Verkuil 
media: hdpvr: fix two audio bugs


-

Diffstat:

 Makefile   |  6 --
 arch/parisc/include/uapi/asm/signal.h  |  2 --
 arch/s390/kernel/ptrace.c  |  9 +++--
 arch/x86/boot/header.S | 26 
 arch/x86/boot/tools/build.c| 37 +++---
 arch/x86/kernel/entry_32.S |  9 +
 block/blk-cgroup.c |  7 +++
 block/blk-tag.c| 33 +++---
 block/compat_ioctl.c   |  1 +
 drivers/ata/ahci.c |  1 +
 drivers/ata/libata-core.c  | 12 +--
 drivers/hwmon/smsc47m192.c |  4 +++-
 drivers/input/input.c  |  6 --
 drivers/media/dvb-frontends/tda10071.c |  6 +-
 drivers/media/usb/hdpvr/hdpvr-video.c  |  6 +++---
 fs/coredump.c  |  2 +-
 include/linux/libata.h |  1 +
 kernel/trace/trace.c   |  2 +-
 kernel/trace/trace_clock.c |  9 +
 mm/hugetlb.c   |  1 +
 mm/slab_common.c   |  2 ++
 net/netfilter/nfnetlink_queue_core.c   | 29 ++
 22 files changed, 141 insertions(+), 70 deletions(-)


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

[PATCH 3.10 11/21] slab_common: fix the check for duplicate slab names

[Greg Kroah-Hartman]

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

--

From: Mikulas Patocka 

commit 694617474e33b8603fc76e090ed7d09376514b1a upstream.

The patch 3e374919b314f20e2a04f641ebc1093d758f66a4 is supposed to fix the
problem where kmem_cache_create incorrectly reports duplicate cache name
and fails. The problem is described in the header of that patch.

However, the patch doesn't really fix the problem because of these
reasons:

* the logic to test for debugging is reversed. It was intended to perform
  the check only if slub debugging is enabled (which implies that caches
  with the same parameters are not merged). Therefore, there should be
  #if !defined(CONFIG_SLUB) || defined(CONFIG_SLUB_DEBUG_ON)
  The current code has the condition reversed and performs the test if
  debugging is disabled.

* slub debugging may be enabled or disabled based on kernel command line,
  CONFIG_SLUB_DEBUG_ON is just the default settings. Therefore the test
  based on definition of CONFIG_SLUB_DEBUG_ON is unreliable.

This patch fixes the problem by removing the test
"!defined(CONFIG_SLUB_DEBUG_ON)". Therefore, duplicate names are never
checked if the SLUB allocator is used.

Note to stable kernel maintainers: when backporint this patch, please
backport also the patch 3e374919b314f20e2a04f641ebc1093d758f66a4.

Acked-by: David Rientjes 
Acked-by: Christoph Lameter 
Signed-off-by: Mikulas Patocka 
Signed-off-by: Pekka Enberg 
Signed-off-by: Greg Kroah-Hartman 

---
 mm/slab_common.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -55,7 +55,7 @@ static int kmem_cache_sanity_check(struc
continue;
}
 
-#if !defined(CONFIG_SLUB) || !defined(CONFIG_SLUB_DEBUG_ON)
+#if !defined(CONFIG_SLUB)
/*
 * For simplicity, we won't check this in the list of memcg
 * caches. We have control over memcg naming, and if there


--
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.10 16/21] x86_32, entry: Store badsys error code in %eax

[Greg Kroah-Hartman]

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

--

From: Sven Wegener 

commit 8142b215501f8b291a108a202b3a053a265b03dd upstream.

Commit 554086d ("x86_32, entry: Do syscall exit work on badsys
(CVE-2014-4508)") introduced a regression in the x86_32 syscall entry
code, resulting in syscall() not returning proper errors for undefined
syscalls on CPUs supporting the sysenter feature.

The following code:

> int result = syscall(666);
> printf("result=%d errno=%d error=%s\n", result, errno, strerror(errno));

results in:

> result=666 errno=0 error=Success

Obviously, the syscall return value is the called syscall number, but it
should have been an ENOSYS error. When run under ptrace it behaves
correctly, which makes it hard to debug in the wild:

> result=-1 errno=38 error=Function not implemented

The %eax register is the return value register. For debugging via ptrace
the syscall entry code stores the complete register context on the
stack. The badsys handlers only store the ENOSYS error code in the
ptrace register set and do not set %eax like a regular syscall handler
would. The old resume_userspace call chain contains code that clobbers
%eax and it restores %eax from the ptrace registers afterwards. The same
goes for the ptrace-enabled call chain. When ptrace is not used, the
syscall return value is the passed-in syscall number from the untouched
%eax register.

Use %eax as the return value register in syscall_badsys and
sysenter_badsys, like a real syscall handler does, and have the caller
push the value onto the stack for ptrace access.

Signed-off-by: Sven Wegener 
Link: 
http://lkml.kernel.org/r/alpine.lnx.2.11.1407221022380.31...@titan.int.lan.stealer.net
Reviewed-and-tested-by: Andy Lutomirski 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/entry_32.S |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -436,8 +436,8 @@ sysenter_do_call:
cmpl $(NR_syscalls), %eax
jae sysenter_badsys
call *sys_call_table(,%eax,4)
-   movl %eax,PT_EAX(%esp)
 sysenter_after_call:
+   movl %eax,PT_EAX(%esp)
LOCKDEP_SYS_EXIT
DISABLE_INTERRUPTS(CLBR_ANY)
TRACE_IRQS_OFF
@@ -517,6 +517,7 @@ ENTRY(system_call)
jae syscall_badsys
 syscall_call:
call *sys_call_table(,%eax,4)
+syscall_after_call:
movl %eax,PT_EAX(%esp)  # store the return value
 syscall_exit:
LOCKDEP_SYS_EXIT
@@ -686,12 +687,12 @@ syscall_fault:
 END(syscall_fault)
 
 syscall_badsys:
-   movl $-ENOSYS,PT_EAX(%esp)
-   jmp syscall_exit
+   movl $-ENOSYS,%eax
+   jmp syscall_after_call
 END(syscall_badsys)
 
 sysenter_badsys:
-   movl $-ENOSYS,PT_EAX(%esp)
+   movl $-ENOSYS,%eax
jmp sysenter_after_call
 END(syscall_badsys)
CFI_ENDPROC


--
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.10 14/21] parisc: Remove SA_RESTORER define

[Greg Kroah-Hartman]

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

--

From: John David Anglin 

commit 20dbea494543aefaace874cc3ec93a39b94b1ec4 upstream.

The sa_restorer field in struct sigaction is obsolete and no longer in
the parisc implementation.  However, the core code assumes the field is
present if SA_RESTORER is defined. So, the define needs to be removed.

Signed-off-by: John David Anglin 
Signed-off-by: Helge Deller 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/parisc/include/uapi/asm/signal.h |2 --
 1 file changed, 2 deletions(-)

--- a/arch/parisc/include/uapi/asm/signal.h
+++ b/arch/parisc/include/uapi/asm/signal.h
@@ -69,8 +69,6 @@
 #define SA_NOMASK  SA_NODEFER
 #define SA_ONESHOT SA_RESETHAND
 
-#define SA_RESTORER0x0400 /* obsolete -- ignored */
-
 #define MINSIGSTKSZ2048
 #define SIGSTKSZ   8192
 


--
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.10 12/21] Input: fix defuzzing logic

[Greg Kroah-Hartman]

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

--

From: Dmitry Torokhov 

commit 50c5d36dab930b1f1b1e3348b8608aa8b9ee7610 upstream.

We attempt to remove noise from coordinates reported by devices in
input_handle_abs_event(), unfortunately, unless we were dropping the
event altogether, we were ignoring the adjusted value and were passing
on the original value instead.

Reviewed-by: Andrew de los Reyes 
Reviewed-by: Benson Leung 
Reviewed-by: David Herrmann 
Reviewed-by: Henrik Rydberg 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/input/input.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -257,9 +257,10 @@ static int input_handle_abs_event(struct
 }
 
 static int input_get_disposition(struct input_dev *dev,
- unsigned int type, unsigned int code, int value)
+ unsigned int type, unsigned int code, int *pval)
 {
int disposition = INPUT_IGNORE_EVENT;
+   int value = *pval;
 
switch (type) {
 
@@ -357,6 +358,7 @@ static int input_get_disposition(struct
break;
}
 
+   *pval = value;
return disposition;
 }
 
@@ -365,7 +367,7 @@ static void input_handle_event(struct in
 {
int disposition;
 
-   disposition = input_get_disposition(dev, type, code, value);
+   disposition = input_get_disposition(dev, type, code, );
 
if ((disposition & INPUT_PASS_TO_DEVICE) && dev->event)
dev->event(dev, type, code, value);


--
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.10 17/21] mm: hugetlb: fix copy_hugetlb_page_range()

[Greg Kroah-Hartman]

3.10-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
@@ -2400,6 +2400,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.14 03/29] media: hdpvr: fix two audio bugs

[Greg Kroah-Hartman]

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

--

From: Hans Verkuil 

commit 3445857b22eafb70a6ac258979e955b116bfd2c6 upstream.

When the audio encoding is changed the driver calls hdpvr_set_audio
with the current opt->audio_input value. However, that should have
been opt->audio_input + 1. So changing the audio encoding inadvertently
changes the input as well. This bug has always been there.

The second bug was introduced in kernel 3.10 and that broke the
default_audio_input module option handling: the audio encoding was
never switched to AC3 if default_audio_input was set to 2 (SPDIF input).

In addition, since starting with 3.10 the audio encoding is always set
at the start the first bug now always happens when the driver is loaded.
In the past this bug would only surface if the user would change the
audio encoding after the driver was loaded.

Also fixes a small trivial typo (bufffer -> buffer).

Signed-off-by: Hans Verkuil 
Reported-by: Scott Doty 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/usb/hdpvr/hdpvr-video.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/media/usb/hdpvr/hdpvr-video.c
+++ b/drivers/media/usb/hdpvr/hdpvr-video.c
@@ -82,7 +82,7 @@ static void hdpvr_read_bulk_callback(str
 }
 
 /*=*/
-/* bufffer bits */
+/* buffer bits */
 
 /* function expects dev->io_mutex to be hold by caller */
 int hdpvr_cancel_queue(struct hdpvr_device *dev)
@@ -926,7 +926,7 @@ static int hdpvr_s_ctrl(struct v4l2_ctrl
case V4L2_CID_MPEG_AUDIO_ENCODING:
if (dev->flags & HDPVR_FLAG_AC3_CAP) {
opt->audio_codec = ctrl->val;
-   return hdpvr_set_audio(dev, opt->audio_input,
+   return hdpvr_set_audio(dev, opt->audio_input + 1,
  opt->audio_codec);
}
return 0;
@@ -1198,7 +1198,7 @@ int hdpvr_register_videodev(struct hdpvr
v4l2_ctrl_new_std_menu(hdl, _ctrl_ops,
V4L2_CID_MPEG_AUDIO_ENCODING,
ac3 ? V4L2_MPEG_AUDIO_ENCODING_AC3 : 
V4L2_MPEG_AUDIO_ENCODING_AAC,
-   0x7, V4L2_MPEG_AUDIO_ENCODING_AAC);
+   0x7, ac3 ? dev->options.audio_codec : 
V4L2_MPEG_AUDIO_ENCODING_AAC);
v4l2_ctrl_new_std_menu(hdl, _ctrl_ops,
V4L2_CID_MPEG_VIDEO_ENCODING,
V4L2_MPEG_VIDEO_ENCODING_MPEG_4_AVC, 0x3,


--
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.14 04/29] media: tda10071: force modulation to QPSK on DVB-S

[Greg Kroah-Hartman]

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

--

From: Antti Palosaari 

commit db4175ae2095634dbecd4c847da439f9c83e1b3b upstream.

Only supported modulation for DVB-S is QPSK. Modulation parameter
contains invalid value for DVB-S on some cases, which leads driver
refusing tuning attempt. Due to that, hard code modulation to QPSK
in case of DVB-S.

Signed-off-by: Antti Palosaari 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/dvb-frontends/tda10071.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/drivers/media/dvb-frontends/tda10071.c
+++ b/drivers/media/dvb-frontends/tda10071.c
@@ -667,6 +667,7 @@ static int tda10071_set_frontend(struct
struct dtv_frontend_properties *c = >dtv_property_cache;
int ret, i;
u8 mode, rolloff, pilot, inversion, div;
+   fe_modulation_t modulation;
 
dev_dbg(>i2c->dev, "%s: delivery_system=%d modulation=%d " \
"frequency=%d symbol_rate=%d inversion=%d pilot=%d " \
@@ -701,10 +702,13 @@ static int tda10071_set_frontend(struct
 
switch (c->delivery_system) {
case SYS_DVBS:
+   modulation = QPSK;
rolloff = 0;
pilot = 2;
break;
case SYS_DVBS2:
+   modulation = c->modulation;
+
switch (c->rolloff) {
case ROLLOFF_20:
rolloff = 2;
@@ -749,7 +753,7 @@ static int tda10071_set_frontend(struct
 
for (i = 0, mode = 0xff; i < ARRAY_SIZE(TDA10071_MODCOD); i++) {
if (c->delivery_system == TDA10071_MODCOD[i].delivery_system &&
-   c->modulation == TDA10071_MODCOD[i].modulation &&
+   modulation == TDA10071_MODCOD[i].modulation &&
c->fec_inner == TDA10071_MODCOD[i].fec) {
mode = TDA10071_MODCOD[i].val;
dev_dbg(>i2c->dev, "%s: mode found=%02x\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/

[PATCH 3.10 19/21] s390/ptrace: fix PSW mask check

[Greg Kroah-Hartman]

3.10-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
@@ -314,7 +314,9 @@ static int __poke_user(struct task_struc
 * psw and gprs are stored on the stack
 */
if (addr == (addr_t) >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;
@@ -627,7 +629,10 @@ static int __poke_user_compat(struct tas
 */
if (addr == (addr_t) >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/