Re: [PATCH V3 1/5] powerpc, perf: Add new BHRB related instructions for POWER8

[Anshuman Khandual]

On 04/22/2013 05:11 AM, Michael Ellerman wrote:
> On Thu, Apr 18, 2013 at 05:56:12PM +0530, Anshuman Khandual wrote:
>> This patch adds new POWER8 instruction encoding for reading
>> the BHRB buffer entries and also clearing it. Encoding for
>> "clrbhrb" instruction is straight forward.
> 
> Which is "clear branch history rolling buffer" ?
> 
>> But "mfbhrbe"
>> encoding involves reading a certain index of BHRB buffer
>> into a particular GPR register.
> 
> And "Move from branch history rolling buffer entry" ?
> 

Sure, would add these descriptions in the change log.

>> diff --git a/arch/powerpc/include/asm/ppc-opcode.h 
>> b/arch/powerpc/include/asm/ppc-opcode.h
>> index 8752bc8..93ae5a1 100644
>> --- a/arch/powerpc/include/asm/ppc-opcode.h
>> +++ b/arch/powerpc/include/asm/ppc-opcode.h
>> @@ -82,6 +82,7 @@
>>  #define __REGA0_R31 31
>>  
>>  /* sorted alphabetically */
>> +#define PPC_INST_BHRBE  0x7c00025c
> 
> I don't think you really need this, just use the literal value below.
> 
>> @@ -297,6 +298,12 @@
>>  #define PPC_NAP stringify_in_c(.long PPC_INST_NAP)
>>  #define PPC_SLEEP   stringify_in_c(.long PPC_INST_SLEEP)
>>  
>> +/* BHRB instructions */
>> +#define PPC_CLRBHRB stringify_in_c(.long 0x7c00035c)
>> +#define PPC_MFBHRBE(r, n)   stringify_in_c(.long PPC_INST_BHRBE | \
>> +__PPC_RS(r) | \
>> +(((n) & 0x1f) << 11))
> 
> Why are you not using ___PPC_RB(n) here ?
> 

I would replace __PPC_RS(r) with __PPC_RT(r) which makes more sense from
instruction encoding point of view.

Regards
Anshuman

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

Re: [PATCH 0/10] Reduce system disruption due to kswapd V2

[Zlatko Calusic]

On 22.04.2013 08:43, Simon Jeons wrote:

Hi Zlatko,
On 04/22/2013 02:37 PM, Zlatko Calusic wrote:

On 12.04.2013 22:07, Zlatko Calusic wrote:

On 12.04.2013 21:40, Mel Gorman wrote:

On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:

On 09.04.2013 13:06, Mel Gorman wrote:


- The only slightly negative thing I observed is that with the patch
applied kswapd burns 10x - 20x more CPU. So instead of about 15
seconds, it has now spent more than 4 minutes on one particular
machine with a quite steady load (after about 12 days of uptime).
Admittedly, that's still nothing too alarming, but...



Would you happen to know what circumstances trigger the higher CPU
usage?



Really nothing special. The server is lightly loaded, but it does enough
reading from the disk so that pagecache is mostly populated and page
reclaiming is active. So, kswapd is no doubt using CPU time gradually,
nothing extraordinary.

When I sent my reply yesterday, the server uptime was 12 days, and
kswapd had accumulated 4:28 CPU time. Now, approx 24 hours later (13
days uptime):

root23  0.0  0.0  0 0 ?SMar30   4:52
[kswapd0]

I will apply your v3 series soon and see if there's any improvement wrt
CPU usage, although as I said I don't see that as a big issue. It's
still only 0.013% of available CPU resources (dual core CPU).



JFTR, v3 kswapd uses about 15% more CPU time than v2. 2:50 kswapd CPU
time after 6 days 14h uptime.

And find attached another debugging graph that shows how ANON pages
are privileged in the ZONE_NORMAL on a 4GB machine. Take notice that
the number of pages in the ZONE_DMA32 is scaled (/5) to fit the graph
nicely.



Could you tell me how you draw this picture?



It's a home made server monitoring system. I just added the code needed 
to graph the size of active + inactive LRU lists, per zone and per type. 
Check out http://oss.oetiker.ch/rrdtool/


--
Zlatko

--
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] intel-iommu: Disable DMA Remapping when intel_iommu=off

[Wei Hu]

On Sun, Apr 21, 2013 at 10:31 PM, Takao Indoh
 wrote:
> (2013/04/20 15:58), Wei Hu wrote:
>> On a VT-d capable machine Linux will enable IOMMU by default. If it
>> then kexec's a second kernel with intel_iommu=off, this second kernel
>> will leave the DMA remapping engine on with no code handling it. The
>> symptom is at least USB and SATA drives stop working. This patch fixes
>> the problem by always disabling DMA remapping when intel_iommu=off.
>
> Even when second kernel boots up with intel_iommu=on, dma-remapping need
> to be disabled as well before it is initialized and enabled again in
> init_dmars(). So, how about something like this?
>
> for_each_drhd_unit(drhd) {
> struct dmar_drhd_unit *drhd;
> if (drhd->ignored)
> continue;
>
> iommu = drhd->iommu;
> if (iommu->gcmd & DMA_GCMD_TE)
> iommu_disable_translation(iommu);
> }
>
> Note, if you agree above code and fix your patch like this, you need
> additinal fix to set iommu->gcmd flag sinse gcmd is always zero here.
> See first hunk of this patch.
> https://lkml.org/lkml/2013/3/20/707

Thanks for your reply. I reviewed your patch. Are you suggesting
keeping your change to dmar.c, and moving your change to intel-iommu.c
(i.e. the code you just showed) up after the call to
dmar_table_init()?
--
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/2] smp: use '|=' for csd_lock

[Sedat Dilek]

On Mon, Apr 22, 2013 at 8:30 AM, Sedat Dilek  wrote:
> On Mon, Apr 22, 2013 at 8:22 AM, li guang  wrote:
>> 在 2013-04-22一的 08:18 +0200，Sedat Dilek写道：
>>> On Mon, Apr 22, 2013 at 7:47 AM, liguang  wrote:
>>> > originally, 'data->flags = CSD_FLAG_LOCK',
>>> > and we use 'data->flags &= ~CSD_FLAG_LOCK'
>>> > for csd_unlock, they are not symmetrix operations
>>> > so use '|=' instead of '='.
>>> > though, now data->flags only hold CSD_FLAG_LOCK,
>>> > it's not so meaningful to use '|=' to set 1 bit,
>>> > and '&= ~' to clear 1 bit.
>>> >
>>>
>>> Hi,
>>>
>>> what's the reason I got CCed on this two patches? The ipc-sem-next
>>> issue I reported?
>>

NOPE.
( I tried next-20130419 with 3 ipc-sem-next patches plus your two patches. )

- Sedat -

>> sorry,
>> just use the result of scripts/get_maintainer.pl
>>
>
> Hmm, really this script memyselfandI as a result?
>
>>>
>>> Against what tree are those patches?
>>> They are not compatible with Linux-Next (next-20130419).
>>
>> main
>>
>
> Andrew renamed data/csd,so it's only 1/2 needing a refresh.
> Testing...
>
> Regards,
> - Sedat -
>
>>>
>>> Thanks.
>>>
>>> Regards,
>>> - Sedat -
>>>
>>> [1] http://marc.info/?t=13663145795&r=1&w=2
>>>
>>> > Signed-off-by: liguang 
>>> > ---
>>> >  kernel/smp.c |2 +-
>>> >  1 files changed, 1 insertions(+), 1 deletions(-)
>>> >
>>> > diff --git a/kernel/smp.c b/kernel/smp.c
>>> > index 1818dc0..2d5deb4 100644
>>> > --- a/kernel/smp.c
>>> > +++ b/kernel/smp.c
>>> > @@ -109,7 +109,7 @@ static void csd_lock_wait(struct call_single_data 
>>> > *data)
>>> >  static void csd_lock(struct call_single_data *data)
>>> >  {
>>> > csd_lock_wait(data);
>>> > -   data->flags = CSD_FLAG_LOCK;
>>> > +   data->flags |= CSD_FLAG_LOCK;
>>> >
>>> > /*
>>> >  * prevent CPU from reordering the above assignment
>>> > --
>>> > 1.7.2.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 17/18] cpufreq: powerpc: move cpufreq driver to drivers/cpufreq

[Viresh Kumar]

On 9 April 2013 14:05, Viresh Kumar  wrote:
> On 5 April 2013 12:16, Viresh Kumar  wrote:
>> On 4 April 2013 18:24, Viresh Kumar  wrote:
>>> This patch moves cpufreq driver of powerpc platform to drivers/cpufreq.
>>>
>>> Cc: Benjamin Herrenschmidt 
>>> Cc: Paul Mackerras 
>>> Cc: Olof Johansson 
>>> Cc: linuxppc-...@lists.ozlabs.org
>>> Signed-off-by: Viresh Kumar 
>>> ---
>>> Compile Tested only.
>>>
>>>  arch/powerpc/platforms/Kconfig | 31 
>>> --
>>>  arch/powerpc/platforms/pasemi/Makefile |  1 -
>>>  arch/powerpc/platforms/powermac/Makefile   |  2 --
>>>  drivers/cpufreq/Kconfig.powerpc| 26 ++
>>>  drivers/cpufreq/Makefile   |  3 +++
>>>  .../cpufreq.c => drivers/cpufreq/pasemi-cpufreq.c  |  0
>>>  .../cpufreq/pmac32-cpufreq.c   |  0
>>>  .../cpufreq/pmac64-cpufreq.c   |  0
>>>  8 files changed, 29 insertions(+), 34 deletions(-)
>>>  rename arch/powerpc/platforms/pasemi/cpufreq.c => 
>>> drivers/cpufreq/pasemi-cpufreq.c (100%)
>>>  rename arch/powerpc/platforms/powermac/cpufreq_32.c => 
>>> drivers/cpufreq/pmac32-cpufreq.c (100%)
>>>  rename arch/powerpc/platforms/powermac/cpufreq_64.c => 
>>> drivers/cpufreq/pmac64-cpufreq.c (100%)
>>
>> Hi Deepthi,
>>
>> Can you help testing this please?
>
> Ping!!

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

Re: [PATCH 0/10] Reduce system disruption due to kswapd V2

[Simon Jeons]

Hi Zlatko,
On 04/22/2013 02:37 PM, Zlatko Calusic wrote:

On 12.04.2013 22:07, Zlatko Calusic wrote:

On 12.04.2013 21:40, Mel Gorman wrote:

On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:

On 09.04.2013 13:06, Mel Gorman wrote:


- The only slightly negative thing I observed is that with the patch
applied kswapd burns 10x - 20x more CPU. So instead of about 15
seconds, it has now spent more than 4 minutes on one particular
machine with a quite steady load (after about 12 days of uptime).
Admittedly, that's still nothing too alarming, but...



Would you happen to know what circumstances trigger the higher CPU
usage?



Really nothing special. The server is lightly loaded, but it does enough
reading from the disk so that pagecache is mostly populated and page
reclaiming is active. So, kswapd is no doubt using CPU time gradually,
nothing extraordinary.

When I sent my reply yesterday, the server uptime was 12 days, and
kswapd had accumulated 4:28 CPU time. Now, approx 24 hours later (13
days uptime):

root23  0.0  0.0  0 0 ?SMar30   4:52 
[kswapd0]


I will apply your v3 series soon and see if there's any improvement wrt
CPU usage, although as I said I don't see that as a big issue. It's
still only 0.013% of available CPU resources (dual core CPU).



JFTR, v3 kswapd uses about 15% more CPU time than v2. 2:50 kswapd CPU 
time after 6 days 14h uptime.


And find attached another debugging graph that shows how ANON pages 
are privileged in the ZONE_NORMAL on a 4GB machine. Take notice that 
the number of pages in the ZONE_DMA32 is scaled (/5) to fit the graph 
nicely.




Could you tell me how you draw this picture?

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

Re: [PATCH 0/10] Reduce system disruption due to kswapd V2

[Zlatko Calusic]

On 12.04.2013 22:07, Zlatko Calusic wrote:

On 12.04.2013 21:40, Mel Gorman wrote:

On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:

On 09.04.2013 13:06, Mel Gorman wrote:


- The only slightly negative thing I observed is that with the patch
applied kswapd burns 10x - 20x more CPU. So instead of about 15
seconds, it has now spent more than 4 minutes on one particular
machine with a quite steady load (after about 12 days of uptime).
Admittedly, that's still nothing too alarming, but...



Would you happen to know what circumstances trigger the higher CPU
usage?



Really nothing special. The server is lightly loaded, but it does enough
reading from the disk so that pagecache is mostly populated and page
reclaiming is active. So, kswapd is no doubt using CPU time gradually,
nothing extraordinary.

When I sent my reply yesterday, the server uptime was 12 days, and
kswapd had accumulated 4:28 CPU time. Now, approx 24 hours later (13
days uptime):

root23  0.0  0.0  0 0 ?SMar30   4:52 [kswapd0]

I will apply your v3 series soon and see if there's any improvement wrt
CPU usage, although as I said I don't see that as a big issue. It's
still only 0.013% of available CPU resources (dual core CPU).



JFTR, v3 kswapd uses about 15% more CPU time than v2. 2:50 kswapd CPU 
time after 6 days 14h uptime.


And find attached another debugging graph that shows how ANON pages are 
privileged in the ZONE_NORMAL on a 4GB machine. Take notice that the 
number of pages in the ZONE_DMA32 is scaled (/5) to fit the graph nicely.


--
Zlatko
<>

Re: [PATCH 1/2] smp: use '|=' for csd_lock

[Sedat Dilek]

On Mon, Apr 22, 2013 at 8:22 AM, li guang  wrote:
> 在 2013-04-22一的 08:18 +0200，Sedat Dilek写道：
>> On Mon, Apr 22, 2013 at 7:47 AM, liguang  wrote:
>> > originally, 'data->flags = CSD_FLAG_LOCK',
>> > and we use 'data->flags &= ~CSD_FLAG_LOCK'
>> > for csd_unlock, they are not symmetrix operations
>> > so use '|=' instead of '='.
>> > though, now data->flags only hold CSD_FLAG_LOCK,
>> > it's not so meaningful to use '|=' to set 1 bit,
>> > and '&= ~' to clear 1 bit.
>> >
>>
>> Hi,
>>
>> what's the reason I got CCed on this two patches? The ipc-sem-next
>> issue I reported?
>
> sorry,
> just use the result of scripts/get_maintainer.pl
>

Hmm, really this script memyselfandI as a result?

>>
>> Against what tree are those patches?
>> They are not compatible with Linux-Next (next-20130419).
>
> main
>

Andrew renamed data/csd,so it's only 1/2 needing a refresh.
Testing...

Regards,
- Sedat -

>>
>> Thanks.
>>
>> Regards,
>> - Sedat -
>>
>> [1] http://marc.info/?t=13663145795&r=1&w=2
>>
>> > Signed-off-by: liguang 
>> > ---
>> >  kernel/smp.c |2 +-
>> >  1 files changed, 1 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/kernel/smp.c b/kernel/smp.c
>> > index 1818dc0..2d5deb4 100644
>> > --- a/kernel/smp.c
>> > +++ b/kernel/smp.c
>> > @@ -109,7 +109,7 @@ static void csd_lock_wait(struct call_single_data 
>> > *data)
>> >  static void csd_lock(struct call_single_data *data)
>> >  {
>> > csd_lock_wait(data);
>> > -   data->flags = CSD_FLAG_LOCK;
>> > +   data->flags |= CSD_FLAG_LOCK;
>> >
>> > /*
>> >  * prevent CPU from reordering the above assignment
>> > --
>> > 1.7.2.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: mdadm raid1 regression

[Vasiliy Tolstov]

2013/4/22 NeilBrown :
>> Hello. I'm using linux 3.8.6 and mdadm 3.2.6 (from git).
>> I have many raid1 arrays that have data offset 2048 (metadata 1.2,
>> created with various mdadm versions but mostly 3.2.1 on linux 2.6.32).
>> If i create raid1 with never mdadm on 3.8.6 i have data offset 8192?? Why?
>
> More room for various useful things.
> In particular, if you one day want to convert this raid1 to a raid5, then
> having a bit of extra space at the front will mean you can avoid a 'backup
> file' and all the problems they cause (code for this isn't quite ready, but
> is getting there).
>

Very good news =)

>>
>> My problem:
>> Sometimes i'm doing mdadm --zero-superblock on both parts of array and
>> re-create it. On older systems i have no errors. On new (linux 3.8.6
>> and mdadm 3.2.6) i get corrupted ext3 fs and partition table. Why this
>> happening?
>
> Why are you doing that?

Our storage have two nodes each provides disk via srp to nodes. On
each node we create separate lvm (we not using clvm) and assemble md.
Sometimes we resize lvm and need to zero superblock, becouse sometimes
we can still have old mdadm data on lvm part (from previous user for
example). And then we add disk to raid we can get sometimes broken
data (invalid sync).

>
>> P.S. If i use mdadm 3.2.2 i get data offset 4096 that not breaks data,
>> but inconsistent with older versions.
>
> I suggest you use mdadm 3.2.2 then.

Yes, i'm already do that, but i think that lates mdadm version with
data-offset patches can solve my problems. Is that possible to correct
it behaviour and write in docs which data offset used in which version
of mdadm?

>
>> P.P.S. I'm try to specify --data-offset when create array but as i see
>> - its ignored and data offset still have 8192).
>
> I'll try to make sure that works correctly for the next release.
> Thanks for the report.
>
> NeilBrown

Thanks!

P.S. Very big thanks for all.


--
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru
jabber: v...@selfip.ru
--
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 0/5] dmaengine: add ACPI DMA helpers and use them in dw_dmac

[Vinod Koul]

On Tue, Apr 16, 2013 at 08:11:57PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, April 16, 2013 03:14:47 PM Andy Shevchenko wrote:
> > On Mon, 2013-04-15 at 22:06 +0530, Vinod Koul wrote: 
> > > On Tue, Apr 09, 2013 at 02:05:42PM +0300, Andy Shevchenko wrote:
> > > > There is a patch series which introduces ACPI DMA helpers in similar 
> > > > way like
> > > > we have for DeviceTree.
> > > > 
> > > > In addition it applies this to the first user, namely dw_dmac driver.
> > > Applied w/o 3 & 5.2 they failed, can you pls rebase and resend
> > > 
> > 
> > Actually those two (at least 5/5) can't be applied on top of slave-dma.
> > The patches requires slave-dma and linux-pm together. I heard it's
> > usually achieved by creating a specific branch in one subsystem
> > (linux-pm in our case) for another.
> > 
> > Rafael, what could we do here?
> 
> I suppose Vinod can pull from my acpi-lpss (which is guaranteed not to be
> rebased at this point) and apply the series on top of that.
Or I can wait for rc1 and apply afterwards...?
> 
> Thanks,
> Rafael
> 
> 
> > > > Since v1:
> > > >  - address one Vinod's comment
> > > >  - replace 5/6 & 6/6 by 5/5 from Rafael
> > > >  - tested on Intel Lynxpoint system
> > > > 
> > > > Andy Shevchenko (4):
> > > >   dma: acpi-dma: introduce ACPI DMA helpers
> > > >   dmaengine: call acpi_dma_request_slave_channel as well
> > > >   dma: acpi-dma: parse CSRT to extract additional resources
> > > >   dw_dmac: add ACPI support
> > > > 
> > > > Rafael J. Wysocki (1):
> > > >   ACPI / LPSS: add support of shared clock
> > > > 
> > > >  Documentation/acpi/enumeration.txt |  77 ++
> > > >  drivers/acpi/Makefile  |   1 -
> > > >  drivers/acpi/acpi_lpss.c   |  26 +-
> > > >  drivers/acpi/csrt.c| 159 
> > > >  drivers/acpi/internal.h|   1 -
> > > >  drivers/acpi/scan.c|   1 -
> > > >  drivers/clk/x86/clk-lpt.c  |  15 +-
> > > >  drivers/dma/Kconfig|   4 +
> > > >  drivers/dma/Makefile   |   1 +
> > > >  drivers/dma/acpi-dma.c | 445 
> > > > +
> > > >  drivers/dma/dmaengine.c|   6 +
> > > >  drivers/dma/dw_dmac.c  |  68 +++--
> > > >  drivers/dma/dw_dmac_regs.h |   1 -
> > > >  include/linux/acpi_dma.h   | 120 +
> > > >  include/linux/platform_data/clk-lpss.h |   5 +
> > > >  15 files changed, 741 insertions(+), 189 deletions(-)
> > > >  delete mode 100644 drivers/acpi/csrt.c
> > > >  create mode 100644 drivers/dma/acpi-dma.c
> > > >  create mode 100644 include/linux/acpi_dma.h
> > > > 
> > 
> > 
> -- 
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/2] smp: use '|=' for csd_lock

[li guang]

在 2013-04-22一的 08:18 +0200，Sedat Dilek写道：
> On Mon, Apr 22, 2013 at 7:47 AM, liguang  wrote:
> > originally, 'data->flags = CSD_FLAG_LOCK',
> > and we use 'data->flags &= ~CSD_FLAG_LOCK'
> > for csd_unlock, they are not symmetrix operations
> > so use '|=' instead of '='.
> > though, now data->flags only hold CSD_FLAG_LOCK,
> > it's not so meaningful to use '|=' to set 1 bit,
> > and '&= ~' to clear 1 bit.
> >
> 
> Hi,
> 
> what's the reason I got CCed on this two patches? The ipc-sem-next
> issue I reported?

sorry,
just use the result of scripts/get_maintainer.pl

> 
> Against what tree are those patches?
> They are not compatible with Linux-Next (next-20130419).

main

> 
> Thanks.
> 
> Regards,
> - Sedat -
> 
> [1] http://marc.info/?t=13663145795&r=1&w=2
> 
> > Signed-off-by: liguang 
> > ---
> >  kernel/smp.c |2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/kernel/smp.c b/kernel/smp.c
> > index 1818dc0..2d5deb4 100644
> > --- a/kernel/smp.c
> > +++ b/kernel/smp.c
> > @@ -109,7 +109,7 @@ static void csd_lock_wait(struct call_single_data *data)
> >  static void csd_lock(struct call_single_data *data)
> >  {
> > csd_lock_wait(data);
> > -   data->flags = CSD_FLAG_LOCK;
> > +   data->flags |= CSD_FLAG_LOCK;
> >
> > /*
> >  * prevent CPU from reordering the above assignment
> > --
> > 1.7.2.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 V4 3/4] block: queue work on unbound wq

[Viresh Kumar]

On 10 April 2013 00:00, Tejun Heo  wrote:
> On Tue, Apr 09, 2013 at 01:00:59PM +0530, Viresh Kumar wrote:

>> +#ifdef CONFIG_WQ_POWER_EFFICIENT
>> +static bool wq_power_efficient = 0;
>> +module_param_named(power_efficient, wq_power_efficient, bool, 0444);
>> +#endif
>
> I don't think we need to make the whole thing configurable.  Turning
> it off isn't gonna save much - my gut tells me it's gonna be four
> instructions. :)
>
> What I meant was that the default value for the parameter would
> probably be need to be configurable so that mobile people don't have
> to include the kernel param all the time or patch the kernel
> themselves.

I didn't get it completely.. Are you asking to set the default value
to 1 instead
to keep it enabled by default if config option is selected?
--
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] sched: wake-affine throttle

[Michael Wang]

Hi, Mike

Thanks for your reply :)

On 04/22/2013 01:27 PM, Mike Galbraith wrote:
> On Mon, 2013-04-22 at 12:21 +0800, Michael Wang wrote: 
>> On 04/10/2013 11:30 AM, Michael Wang wrote:
>>> Log since RFC:
>>> 1. Throttle only when wake-affine failed. (thanks to PeterZ)
>>> 2. Do throttle inside wake_affine(). (thanks to PeterZ)
>>> 3. Other small fix.
>>>
>>> Recently testing show that wake-affine stuff cause regression on pgbench, 
>>> the
>>> hiding rat was finally catched out.
>>>
>>> wake-affine stuff is always trying to pull wakee close to waker, by theory,
>>> this will benefit us if waker's cpu cached hot data for wakee, or the 
>>> extreme
>>> ping-pong case.
>>>
>>> However, the whole stuff is somewhat blindly, load balance is the only 
>>> factor
>>> to be guaranteed, and since the stuff itself is time-consuming, some 
>>> workload
>>> suffered, pgbench is just the one who has been found.
>>>
>>> Thus, throttle the wake-affine stuff for such workload is necessary.
>>>
>>> This patch introduced a new knob 'sysctl_sched_wake_affine_interval' with 
>>> the
>>> default value 1ms (default minimum balance interval), which means 
>>> wake-affine
>>> will keep silent for 1ms after it returned false.
>>>
>>> By turning the new knob, those workload who suffered will have the chance to
>>> stop the regression.
>>
>> I have tested the latest tip 3.9.0-rc7, huge regression on pgbench is
>> still there and this approach still works well, should we take the
>> action now?
> 
> (It's not a _regression_ per se, more of a long standing issue for this
> sort of load.  Not that the load cares much what we call the problem;)

Yeah, it's not general but for one kind of workload (or may be several),
compared with the world without wake-affine, I will call it the
regression caused by wake-affine on pgbench ;)

Regards,
Michael Wang

> 
>>
>> Regards,
>> Michael Wang
>>
>>>
>>> Test:
>>> Test with 12 cpu X86 server and tip 3.9.0-rc2.
>>>
>>> default
>>> base1ms interval 10ms interval   100ms interval
>>> | db_size | clients |  tps  |   |  tps  ||  tps  | |  
>>> tps  |
>>> +-+-+---+-  +---++---+ +---+
>>> | 21 MB   |   1 | 10572 |   | 10804 || 10802 | | 10801 |
>>> | 21 MB   |   2 | 21275 |   | 21533 || 21400 | | 21498 |
>>> | 21 MB   |   4 | 41866 |   | 42158 || 42410 | | 42306 |
>>> | 21 MB   |   8 | 53931 |   | 55796 || 58608 | +8.67%  | 59916 
>>> | +11.10%
>>> | 21 MB   |  12 | 50956 |   | 52266 || 54586 | +7.12%  | 55982 
>>> | +9.86%
>>> | 21 MB   |  16 | 49911 |   | 52862 | +5.91% | 55668 | +11.53% | 57255 
>>> | +14.71%
>>> | 21 MB   |  24 | 46046 |   | 48820 | +6.02% | 54269 | +17.86% | 58113 
>>> | +26.21%
>>> | 21 MB   |  32 | 43405 |   | 46635 | +7.44% | 53690 | +23.70% | 57729 
>>> | +33.00%
>>> | 7483 MB |   1 |  7734 |   |  8013 ||  8046 | |  7879 |
>>> | 7483 MB |   2 | 19375 |   | 19459 || 19448 | | 19421 |
>>> | 7483 MB |   4 | 37408 |   | 37780 || 37937 | | 37819 |
>>> | 7483 MB |   8 | 49033 |   | 50389 || 51636 | +5.31%  | 52294 
>>> | +6.65%
>>> | 7483 MB |  12 | 45525 |   | 47794 | +4.98% | 49828 | +9.45%  | 50571 
>>> | +11.08%
>>> | 7483 MB |  16 | 45731 |   | 47921 | +4.79% | 50203 | +9.78%  | 52033 
>>> | +13.78%
>>> | 7483 MB |  24 | 41533 |   | 44301 | +6.67% | 49697 | +19.66% | 53833 
>>> | +29.62%
>>> | 7483 MB |  32 | 36370 |   | 38301 | +5.31% | 48146 | +32.38% | 52795 
>>> | +45.16%
>>> | 15 GB   |   1 |  7576 |   |  7926 ||  7722 | |  7969 |
>>> | 15 GB   |   2 | 19157 |   | 19284 || 19294 | | 19304 |
>>> | 15 GB   |   4 | 37285 |   | 37539 || 37281 | | 37508 |
>>> | 15 GB   |   8 | 48718 |   | 49176 || 50836 | +4.35%  | 51239 
>>> | +5.17%
>>> | 15 GB   |  12 | 45167 |   | 47180 | +4.45% | 49206 | +8.94%  | 50126 
>>> | +10.98%
>>> | 15 GB   |  16 | 45270 |   | 47293 | +4.47% | 49638 | +9.65%  | 51748 
>>> | +14.31%
>>> | 15 GB   |  24 | 40984 |   | 43366 | +5.81% | 49356 | +20.43% | 53157 
>>> | +29.70%
>>> | 15 GB   |  32 | 35918 |   | 37632 | +4.77% | 47923 | +33.42% | 52241 
>>> | +45.45%
>>>
>>> Suggested-by: Peter Zijlstra 
>>> Signed-off-by: Michael Wang 
>>> ---
>>>  include/linux/sched.h |5 +
>>>  kernel/sched/fair.c   |   31 +++
>>>  kernel/sysctl.c   |   10 ++
>>>  3 files changed, 46 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/include/linux/sched.h b/include/linux/sched.h
>>> index d35d2b6..e9efd3a 100644
>>> --- a/include/linux/sched.h
>>> +++ b/include/linux/sched.h
>>> @@ -1197,6 +1197,10 @@ enum perf_event_task_context {
>>> perf_nr_task_contexts,
>>>  };
>>>
>>> +#ifdef CONFIG_SMP
>>> +extern unsigned int

Re: [PATCH 1/2] smp: use '|=' for csd_lock

[Sedat Dilek]

On Mon, Apr 22, 2013 at 7:47 AM, liguang  wrote:
> originally, 'data->flags = CSD_FLAG_LOCK',
> and we use 'data->flags &= ~CSD_FLAG_LOCK'
> for csd_unlock, they are not symmetrix operations
> so use '|=' instead of '='.
> though, now data->flags only hold CSD_FLAG_LOCK,
> it's not so meaningful to use '|=' to set 1 bit,
> and '&= ~' to clear 1 bit.
>

Hi,

what's the reason I got CCed on this two patches? The ipc-sem-next
issue I reported?

Against what tree are those patches?
They are not compatible with Linux-Next (next-20130419).

Thanks.

Regards,
- Sedat -

[1] http://marc.info/?t=13663145795&r=1&w=2

> Signed-off-by: liguang 
> ---
>  kernel/smp.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/smp.c b/kernel/smp.c
> index 1818dc0..2d5deb4 100644
> --- a/kernel/smp.c
> +++ b/kernel/smp.c
> @@ -109,7 +109,7 @@ static void csd_lock_wait(struct call_single_data *data)
>  static void csd_lock(struct call_single_data *data)
>  {
> csd_lock_wait(data);
> -   data->flags = CSD_FLAG_LOCK;
> +   data->flags |= CSD_FLAG_LOCK;
>
> /*
>  * prevent CPU from reordering the above assignment
> --
> 1.7.2.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: [RFC/PATCH 1/4] arm64: Provide default implementation for dma_{alloc, free}_attrs

[Lars-Peter Clausen]

On 04/22/2013 07:09 AM, Damian Hobson-Garcia wrote:
> Most architectures that define CONFIG_HAVE_DMA, have implementations for
> both dma_alloc_attrs() and dma_free_attrs().  All achitectures that do
> not define CONFIG_HAVE_DMA also have both of these definitions provided by
> dma-mapping-broken.h.
> 
> Add default implementations for these functions on arm64.
> 
> Signed-off-by: Damian Hobson-Garcia 
> ---
>  arch/arm64/include/asm/dma-mapping.h |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/dma-mapping.h 
> b/arch/arm64/include/asm/dma-mapping.h
> index 9947768..65ab181 100644
> --- a/arch/arm64/include/asm/dma-mapping.h
> +++ b/arch/arm64/include/asm/dma-mapping.h
> @@ -81,6 +81,9 @@ static inline void dma_mark_clean(void *addr, size_t size)
>  {
>  }
>  
> +#define dma_alloc_attrs(d, s, h, f, a) dma_alloc_coherent(d, s, h, f)
> +#define dma_free_attrs(d, s, h, f, a) dma_free_coherent(d, s, h, f)
> +
>  static inline void *dma_alloc_coherent(struct device *dev, size_t size,
>  dma_addr_t *dma_handle, gfp_t flags)
>  {

The other way around would be better, properly implement
dma_{alloc,free}_attrs and implement dma_{alloc,free}_coherent on top of
the. E.g. you are supposed to pass the attrs parameter to ops->alloc and
ops->free instead of NULL. And it will also allow us to move
dma_{alloc,free}_coherent to asm-generic/dma-mapping-common.h eventually.

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

RE: [RFC PATCH 0/2] cpufreq/regulator: Limit minimum voltage only

[Bedia, Vaibhav]

(removing Anil's email-id since it's no longer valid)

On Sat, Apr 20, 2013 at 05:54:10, Kondratiuk, Taras wrote:
> On 04/19/2013 07:21 PM, Nishanth Menon wrote:
> > On 14:55-20130419, Taras Kondratiuk wrote:
> >> Using a "voltage tolerance" for doing DVFS is not a proper way.
> >> It leads to a few issues:
> >> - voltage is limited to a narrow range near OPP voltage,
> >>   so other consumers of the same regulator can't set their own constraints
> >>   if they don't overlap with this narrow range. No ganged rails :(
> >> - usually OPP voltage is an absolute minimum voltage
> >>   necessary for correct work (not taking into account AVS).

The absolute minimum voltage part is not applicable for all SoCs.
In case of AM335x there a nominal voltage that is specified in the
OPP table and there's a plus/minus tolerance at the IO level within
which things are guaranteed to work. To lower the power consumption
we would want to go as low as possible without violating the
requirement at the SoC boundary level. I don't know how the OPP voltages
are speced for non TI devices but if there's a permissible range I guess
everyone would like to set the voltage near the lower end of the spectrum.

> >>   Applying plus/minus tolerance can lead to an unstable device.
> >>   For example omap-cpufreq has 4% tolerance configured,
> >>   so for OMAP4430 MPU OPP50 we get 0.984V instead of 1.025V. 

So if you set the tolerance to 0% instead of removing it completely
won't the problem go away?

> > there is a reason for this - board level IRDROP and the real PMIC
> > accuracy compared to the SoC assumption about the PMIC accuracy.
> 
> I don't see how current implementation of voltage-tolerance can help with 
> this.
> 

It does help (more below).

> >
> > That said, I had been always been a little confused with the usage
> > in AM335x. For that matter, I dont even think this is constrainted to
> > TI SoC usage, other SoCs also probably have the same pain.
> >
> > How does it actually work?
> 
> I think this is a question to Afzal as he is an original author
> of commit 42daffd2d6c665716d442d518022ecaad17ddf64 which later
> migrated to cpufreq-cpu0 driver.
> 
> I can only guess...
> Without tolerance cpufreq requests the same value for min_uV and max_uV.
> So regulator have to set an exact voltage value on the rail,
> which is not always possible if different PMICs can be used for the SoC.
> For example in v3.9-rc7 voltage-tolerance is used *only*
> in AM33xx which can use two PMICs: TPS65217 and TPS65910.
> These PMICs have different voltage steps so they can't set the same voltage.
> I think this was the reason for adding voltage-tolerance.
> 

The PMICs have the same step size of 12.5mV but unfortunately they don't have
a register setting to meet the nominal voltage requirement for all the OPPs.
As per the SoC datasheet, for OPP120 the nominal voltage is 1.26V but the 
closest
that the PMIC outputs can come is either 1.25V or 1.275V. Now i think there's
been some confusion in the implementation phase due to things like board level
IR drops and variations mentioned in the PMIC datasheets which has resulted in
the tolerance being used both in am33xx.dtsi and then again in the cpufreq 
driver.

Ignoring the PMIC variations and board level IR drops for moment, the way I 
think
it should have been done is - OPP entries have the nominal voltages and we 
specify
the tolerance either in % in the DT file. The cpufreq driver looks up the 
nominal
voltage from the OPP table and then requests the regulator framework to factor 
in
the tolerance and then select the lowest permissible voltage. 

> *But* there is a trick.
> If you compare MPU OPP voltages in AM335x datasheet and am33xx.dtsi
> you will see that am33xx.dtsi has already applied tolerance (2%) on top
> of nominal voltages.
> So final range passed to regulator is [Vnom; Vnom+2*tol]
> instead of [Vnom-tol; Vnom+tol].
> That's why it works for AM335x, but IMHO it is a hack.

I agree. It sort of ended up a hack that needs to be fixed by removing the
additional tolerance in am33xx.dtsi.

> That patch broke omap-cpufreq functionality, since mach-omap2/opp_data.c
> files doesn't have tolerance added on top of nominal voltages.
> 

Again, if you specify 0% as the tolerance this would be fine, no?

> regulator_set_voltage_min() should solve AM335x issue
> without introducing voltage-tolerance hack.

No, we want to pass on all the factors to be considered to the appropriate
framework which in this case is the regulator framework and let it decide
the min voltage. If you consider multiple users like ABB and AVS, I think
it makes much more sense to have the requirements from the different users
being passed on to the regulator framework and letting it decide what works
for all of them.

> Probably I need to add one more patch to the series which will remove
> voltage-tolerance from am335x.dtsi and set CPU voltages back to nominal.
> 
> >
> > Lets say ntarget/Vnom has PMIC tolerance of 5% (S

Re: [PATCH v3 1/6] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

Hi,

On Friday 19 April 2013 02:39 PM, Grant Likely wrote:

On Tue, 16 Apr 2013 15:48:07 +0530, Kishon Vijay Abraham I  
wrote:

On Tuesday 16 April 2013 01:20 AM, Grant Likely wrote:

On Mon, 15 Apr 2013 17:56:10 +0530, Kishon Vijay Abraham I  
wrote:

On Monday 15 April 2013 05:04 PM, Grant Likely wrote:

On Wed, 20 Mar 2013 14:42:00 +0530, Kishon Vijay Abraham I  
wrote:

We have decided not to implement the PHY layer as a separate bus layer.
The PHY provider can be part of any other bus. Making the PHY layer as a
bus will make the PHY provider to be part of multiple buses which will
lead to bad design. All we are trying to do here is keep the pool of PHY
devices under PHY class in this layer and help any controller that wants
to use the PHY to get it.


If you're using a class, then you already have your list of registered
phy devices! :-) No need to create another global list that you need to
manage.


right. We already use _class_dev_iter_ for finding the phy device.
.
.
+static struct phy *of_phy_lookup(struct device *dev, struct device_node
*node)
+{
+   struct phy *phy;
+   struct class_dev_iter iter;
+
+   class_dev_iter_init(&iter, phy_class, NULL, NULL);
+   while ((dev = class_dev_iter_next(&iter))) {
+   phy = container_of(dev, struct phy, dev);
+   if (node != phy->of_node)
+   continue;
+
+   class_dev_iter_exit(&iter);
+   return phy;
+   }
+
+   class_dev_iter_exit(&iter);
+   return ERR_PTR(-EPROBE_DEFER);
+}
.
.

however we can't get rid of the other list (phy_bind_list) where we
maintain the phy binding information. It's used for the non-dt boot case.


Why? If you're using a class, then it is always there. Why would non-DT
and DT be different in this regard? (more below)


Since there is at most a 1:N relationship between host controllers and
PHYs, there shouldn't be any need for a separate structure to describe
binding. Put the inding data into the struct phy itself. Each host
controller can have a list of phys that it is bound to.


No. Having the host controller to have a list of phys wont be a good
idea IMHO. The host controller is just an IP and the PHY to which it
will be connected can vary from board to board, platform to platform. So
ideally this binding should come from platform initialization code/dt data.


That is not what I mean. I mean the host controller instance should
contain a list of all the PHYs that are attached to it. There should not


Doesn't sound correct IMO. The host controller instance need not know
anything about the PHY instances that is connected to it. Think of it
similar to regulator, the controller wouldn't know which regulator it is
connected to, all it has to know is it just has a regulator connected to
it. It's up-to the regulator framework to give the controller the
correct regulator. It's similar here. It makes sense for me to keep a
list in the PHY framework in order for it to return the correct PHY (but
note that this list is not needed for dt boot).


With regulators and clocks it makes sense to have a global
registration place becase both implement an interconnected network
independent of the device that use them. (clocks depend on other clocks;
regulators depend on other regulators).

Phys are different. There is a 1:N relationship between host controllers
and phys, and you don't get a interconnected network of PHYs. Its a bad
idea to keep the binding data separate from the actual host controller
when there is nothing else that actually needs to use the data. It
creates a new set of data structures that need housekeeping to keep them
in sync with the actual device structures. It really is just a bad idea
and it becomes more difficult (in the non-DT case) to determine what
data is associated with a given host controller. You can't tell by
looking at the struct device.

Instead, for the non-DT case, do what we've always done for describing
connections. Put the phy reference into the host controllers
platform_data structure.
hmm... my only concern here is there is no way we can enforce the phy 
reference is added in the platform_data structure.

That is what it is there for. That completely

eliminates the need to housekeep a new set of data structures.


Ok. Makes sense.

Thanks
Kishon
--
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: Preemptable Ticket Spinlock

[Raghavendra K T]

On 04/22/2013 04:37 AM, Jiannan Ouyang wrote:

On Sun, Apr 21, 2013 at 5:12 PM, Rik van Riel  wrote:

Your algorithm is very clever, and very promising.

However, it does increase the size of the struct spinlock, and adds
an additional atomic operation to spin_unlock, neither of which I
suspect are necessary.

If we always incremented the ticket number by 2 (instead of 1), then
we could use the lower bit of the ticket number as the spinlock.

If we do NOT run virtualized, we simply increment the ticket by 2
in spin_unlock, and the code can remain otherwise the same.

If we do run virtualized, we take that spinlock after acquiring
the ticket (or timing out), just like in your code. In the
virtualized spin_unlock, we can then release the spinlock and
increment the ticket in one operation: by simply increasing the
ticket by 1.

In other words, we should be able to keep the overhead of this
to an absolute minimum, and keep spin_unlock to be always the
same cost it is today.

--
All rights reversed


Hi Rik,

Thanks for your feedback.

Yes I agree with you
- increase the size of struct spinlock is unnecessary
- your idea of utilize the lower bit and save one atomic operation
from unlock is cool!



Yes, +1. it is indeed a cool idea. Thanks to Jeremy.. and as Rik already 
mentioned it would also prevent the side effects of increasing
lock size. (It reminds my thought of encoding vcpuid in lock for pv 
spinlock)



I can come up with a updated patch soon.

--Jiannan




--
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 ftrace tree with Linus' tree

[Stephen Rothwell]

Hi Steven,

Today's linux-next merge of the ftrace tree got a conflict in
kernel/trace/ftrace.c between commit b67bfe0d42ca ("hlist: drop the node
parameter from iterators") from Linus' tree and commit f1943977e664
("tracing: Get rid of unneeded key calculation in ftrace_hash_move()")
and e1df4cb682ab ("ftrace: Fix function probe to only enable needed
functions") from the ftrace 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 kernel/trace/ftrace.c
index b3fde6d,9b44abb..000
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@@ -761,9 -755,10 +754,9 @@@ ftrace_find_profiled_func(struct ftrace
  {
struct ftrace_profile *rec;
struct hlist_head *hhd;
 -  struct hlist_node *n;
unsigned long key;
  
-   key = hash_long(ip, ftrace_profile_bits);
+   key = hash_long(ip, FTRACE_PROFILE_HASH_BITS);
hhd = &stat->hash[key];
  
if (hlist_empty(hhd))
@@@ -1371,11 -1354,7 +1363,7 @@@ ftrace_hash_move(struct ftrace_ops *ops
size = 1 << src->size_bits;
for (i = 0; i < size; i++) {
hhd = &src->buckets[i];
 -  hlist_for_each_entry_safe(entry, tp, tn, hhd, hlist) {
 +  hlist_for_each_entry_safe(entry, tn, hhd, hlist) {
-   if (bits > 0)
-   key = hash_long(entry->ip, bits);
-   else
-   key = 0;
remove_hash_entry(src, entry);
__add_hash_entry(new_hash, entry);
}
@@@ -3062,8 -3075,13 +3070,13 @@@ static voi
  __unregister_ftrace_function_probe(char *glob, struct ftrace_probe_ops *ops,
  void *data, int flags)
  {
+   struct ftrace_func_entry *rec_entry;
struct ftrace_func_probe *entry;
+   struct ftrace_func_probe *p;
+   struct ftrace_hash **orig_hash = &trace_probe_ops.filter_hash;
+   struct list_head free_list;
+   struct ftrace_hash *hash;
 -  struct hlist_node *n, *tmp;
 +  struct hlist_node *tmp;
char str[KSYM_SYMBOL_LEN];
int type = MATCH_FULL;
int i, len = 0;


pgppg9kraWYAR.pgp
Description: PGP signature

Re: Preemptable Ticket Spinlock

[Raghavendra K T]

On 04/21/2013 03:42 AM, Jiannan Ouyang wrote:

Hello Everyone,

I recently came up with a spinlock algorithm that can adapt to
preemption, which you may be interested in.


It is overall a great and clever idea as Rik mentioned already.

 The intuition is to

downgrade a fair lock to an unfair lock automatically upon preemption,
and preserve the fairness otherwise.


I also hope being little unfair, does not affect the original intention
of introducing ticket spinlocks too.
Some discussions were here long back in this thead,
https://lkml.org/lkml/2010/6/3/331

It is a guest side optimization,

and can be used as a complementary technique to host side optimizations
like co-scheduling and Pause-Loop Exiting.

In my experiments, it improves VM performance by 5:32X on average, when
running on a non paravirtual VMM, and by 7:91X when running on a VMM
that supports a paravirtual locking interface (using a pv preemptable
ticket spinlock), when executing a set of microbenchmarks as well as a
realistic e-commerce benchmark.


AFAIU, the experiments are on non PLE machines and it would be worth 
experimenting on PLE machines too. and also bigger machines.

(we may get some surprises there otherwise).
'll wait for your next iteration of the patches with "using lower bit"
changes.




A detailed algorithm description can be found in my VEE 2013 paper,
Preemptable Ticket Spinlocks: Improving Consolidated Performance in the
Cloud
Jiannan Ouyang, John R. Lange
ouyang,jackla...@cs.pitt.edu 
University of Pittsburgh
http://people.cs.pitt.edu/~ouyang/files/publication/preemptable_lock-ouyang-vee13.pdf

The patch is based on stock Linux kernel 3.5.0, and tested on kernel
3.4.41 as well.
http://www.cs.pitt.edu/~ouyang/files/preemptable_lock.tar.gz

Thanks
--Jiannan

I'm not familiar with patch over email, so I just paste it below, sorry
for the inconvenience.
==
diff --git a/arch/x86/include/asm/spinlock.h
b/arch/x86/include/asm/spinlock.h
index b315a33..895d3b3 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -48,18 +48,35 @@
   * in the high part, because a wide xadd increment of the low part
would carry
   * up and contaminate the high part.
   */
+#define TIMEOUT_UNIT (1<<14)


This value seem to be at the higher end. But I hope you have 
experimented enough to come up with this. Better again to test all these 
tunables?? on PLE machines too.



  static __always_inline void __ticket_spin_lock(arch_spinlock_t *lock)
  {
 register struct __raw_tickets inc = { .tail = 1 };
+   unsigned int timeout = 0;
+   __ticket_t current_head;

 inc = xadd(&lock->tickets, inc);
-
+   if (likely(inc.head == inc.tail))
+   goto spin;
+
+   timeout =  TIMEOUT_UNIT * (inc.tail - inc.head);
+   do {
+   current_head = ACCESS_ONCE(lock->tickets.head);
+   if (inc.tail <= current_head) {
+   goto spin;
+   } else if (inc.head != current_head) {
+   inc.head = current_head;
+   timeout =  TIMEOUT_UNIT * (inc.tail - inc.head);


Good idea indeed to base the loop on head and tail difference.. But for 
virtualization I believe this "directly proportional notion" is little 
tricky too.


--
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 4/6] arm: mach-omap2: remove "OMAP_DEVICE_NO_IDLE_ON_SUSPEND" check

[Sourav Poddar]

Hi Kevin,
On Friday 19 April 2013 08:22 PM, Kevin Hilman wrote:

Sourav Poddar  writes:

[...]


Yes, got your point. omap_device_idle should not be called only
for console uart.

Just did a quick testing by including the following hunk on top of my
patch series..

diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index c226946..7480e87 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -617,8 +617,10 @@ static int _od_suspend_noirq(struct device *dev)
 ret = pm_generic_suspend_noirq(dev);

 if (!ret&&  !pm_runtime_status_suspended(dev)) {
-   if (pm_generic_runtime_suspend(dev) == 0)
+   if (pm_generic_runtime_suspend(dev) == 0) {
+   omap_device_idle(pdev);
 od->flags |= OMAP_DEVICE_SUSPENDED;
+   }
 }

 return ret;
@@ -631,6 +633,7 @@ static int _od_resume_noirq(struct device *dev)

 if ((od->flags&  OMAP_DEVICE_SUSPENDED)&&
 !pm_runtime_status_suspended(dev)) {
+   omap_device_enable(pdev);
 od->flags&= ~OMAP_DEVICE_SUSPENDED;
 pm_generic_runtime_resume(dev);
 }
And found the wakeup from UART is no more functional.
So, the omap_device_idle gets called for console UART also, thereby
preventing the "no_idle_on_suspend" theory.

Hence, merely putting prepare/complete callback the way I did is not
helping.
We need to delete omap_device_idle also, which I agree is not correct.
So, we need a way to bypass this "omap_device_idle"
call for console UART. ?

OK, I see what's happening now.

How about this: rather than using prepare/complete callbacks, can you
use the runtime_suspend callback to return an error code during suspend?

Yes, that can be done.

(only for the console, and only when no_console_suspend is enabled, and
only during suspend)

Since _od_suspend_noirq checks to be sure the drivers ->runtime_suspend
callback succeeds before it calls omap_device_idle(), if you report a
failure, omap_device_idle will not be called.


True.

~Sourav

Kevin




--
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/2] smp: remove 'priv' of call_single_data

[liguang]

the 'priv' field seems a little redundant,
because we can pass data via 'info'.

Signed-off-by: liguang 
---
 include/linux/smp.h |1 -
 kernel/softirq.c|6 ++
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/include/linux/smp.h b/include/linux/smp.h
index 3e07a7d..e6564c1 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -20,7 +20,6 @@ struct call_single_data {
smp_call_func_t func;
void *info;
u16 flags;
-   u16 priv;
 };
 
 /* total number of cpus in this system (may exceed NR_CPUS) */
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 14d7758..aa82723 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -620,8 +620,7 @@ static void remote_softirq_receive(void *data)
unsigned long flags;
int softirq;
 
-   softirq = cp->priv;
-
+   softirq = *(int *)cp->info;
local_irq_save(flags);
__local_trigger(cp, softirq);
local_irq_restore(flags);
@@ -631,9 +630,8 @@ static int __try_remote_softirq(struct call_single_data 
*cp, int cpu, int softir
 {
if (cpu_online(cpu)) {
cp->func = remote_softirq_receive;
-   cp->info = cp;
+   cp->info = &softirq;
cp->flags = 0;
-   cp->priv = softirq;
 
__smp_call_function_single(cpu, cp, 0);
return 0;
-- 
1.7.2.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/

[PATCH 1/2] smp: use '|=' for csd_lock

[liguang]

originally, 'data->flags = CSD_FLAG_LOCK',
and we use 'data->flags &= ~CSD_FLAG_LOCK'
for csd_unlock, they are not symmetrix operations
so use '|=' instead of '='.
though, now data->flags only hold CSD_FLAG_LOCK,
it's not so meaningful to use '|=' to set 1 bit,
and '&= ~' to clear 1 bit.

Signed-off-by: liguang 
---
 kernel/smp.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/smp.c b/kernel/smp.c
index 1818dc0..2d5deb4 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -109,7 +109,7 @@ static void csd_lock_wait(struct call_single_data *data)
 static void csd_lock(struct call_single_data *data)
 {
csd_lock_wait(data);
-   data->flags = CSD_FLAG_LOCK;
+   data->flags |= CSD_FLAG_LOCK;
 
/*
 * prevent CPU from reordering the above assignment
-- 
1.7.2.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: [RFC PATCH v3 5/6] sched: pack the idle load balance

[Preeti U Murthy]

Hi Vincent,

On 04/05/2013 04:38 PM, Vincent Guittot wrote:
> Peter,
> 
> After some toughts about your comments,I can update the buddy cpu
> during ILB or periofdic LB to a new idle core and extend the packing
> mechanism  Does this additional mechanism sound better for you ?

If the primary goal of this patchset is to pack small tasks in fewer
power domains then why not see if the power aware scheduler patchset by
Alex does the same for you? The reason being:

a.The power aware scheduler also checks if a task is small enough to be
packed on a cpu which has just enough capacity to take on that
task(leader cpu). This cpu belongs to a scheduler group which is nearly
full(group_leader),so we end up packing tasks.

b.The overhead of assigning a buddy cpu gets eliminated because the best
cpu for packing is decided during wake up.

c.This is a scalable solution because if the leader cpu is busy,then any
other idle cpu from that group_leader is chosen.Eventually you end up
packing anyway.

The reason that I am suggesting this is that we could unify the power
awareness of the scheduler under one umbrella.And i believe that the
current power aware scheduler patchset is flexible enough to do this and
that we must cash in on it.

Thanks

Regards
Preeti U Murthy
> 
> Vincent
> 
> On 26 March 2013 15:42, Peter Zijlstra  wrote:
>> On Tue, 2013-03-26 at 15:03 +0100, Vincent Guittot wrote:
 But ha! here's your NO_HZ link.. but does the above DTRT and ensure
 that the ILB is a little core when possible?
>>>
>>> The loop looks for an idle CPU as close as possible to the buddy CPU
>>> and the buddy CPU is the 1st CPU has been chosen. So if your buddy is
>>> a little and there is an idle little, the ILB will be this idle
>>> little.
>>
>> Earlier you wrote:
>>
>>>   | Cluster 0   | Cluster 1   |
>>>   | CPU0 | CPU1 | CPU2 | CPU3 |
>>> ---
>>> buddy | CPU0 | CPU0 | CPU0 | CPU2 |
>>
>> So extrapolating that to a 4+4 big-little you'd get something like:
>>
>>   |   little  A9  ||   big A15 |
>>   | 0 | 1 | 2 | 3 || 4 | 5 | 6 | 7 |
>> --+---+---+---+---++---+---+---+---+
>> buddy | 0 | 0 | 0 | 0 || 0 | 4 | 4 | 4 |
>>
>> Right?
>>
>> So supposing the current ILB is 6, we'll only check 4, not 0-3, even
>> though there might be a perfectly idle cpu in there.
>>
>> Also, your scheme fails to pack when cpus 0,4 are filled, even when
>> there's idle cores around.
>>
>> If we'd use the ILB as packing cpu, we would simply select a next pack
>> target once the old one fills up.
>>
> 

--
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/3 v2] iommu: Move swap_pci_ref function to pci.h.

[Varun Sethi]

swap_pci_ref function is used by the IOMMU API code for swapping pci device
pointers, while determining the iommu group for the device.
Currently this function was being implemented for different IOMMU drivers.
This patch moves the function to a new file, drivers/iommu/pci.h so that the
implementation can be shared across various IOMMU drivers.

Signed-off-by: Varun Sethi 
---
v2 changes:
- created a new file drivers/iommu/pci.h.

 drivers/iommu/amd_iommu.c   |7 +--
 drivers/iommu/intel-iommu.c |7 +--
 drivers/iommu/pci.h |   29 +
 3 files changed, 31 insertions(+), 12 deletions(-)
 create mode 100644 drivers/iommu/pci.h

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index a7f6b04..2463464 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -46,6 +46,7 @@
 #include "amd_iommu_proto.h"
 #include "amd_iommu_types.h"
 #include "irq_remapping.h"
+#include "pci.h"
 
 #define CMD_SET_TYPE(cmd, t) ((cmd)->data[1] |= ((t) << 28))
 
@@ -263,12 +264,6 @@ static bool check_device(struct device *dev)
return true;
 }
 
-static void swap_pci_ref(struct pci_dev **from, struct pci_dev *to)
-{
-   pci_dev_put(*from);
-   *from = to;
-}
-
 static struct pci_bus *find_hosted_bus(struct pci_bus *bus)
 {
while (!bus->self) {
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 6e0b9ff..81ad7b8 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -47,6 +47,7 @@
 #include 
 
 #include "irq_remapping.h"
+#include "pci.h"
 
 #define ROOT_SIZE  VTD_PAGE_SIZE
 #define CONTEXT_SIZE   VTD_PAGE_SIZE
@@ -4137,12 +4138,6 @@ static int intel_iommu_domain_has_cap(struct 
iommu_domain *domain,
return 0;
 }
 
-static void swap_pci_ref(struct pci_dev **from, struct pci_dev *to)
-{
-   pci_dev_put(*from);
-   *from = to;
-}
-
 #define REQ_ACS_FLAGS  (PCI_ACS_SV | PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF)
 
 static int intel_iommu_add_device(struct device *dev)
diff --git a/drivers/iommu/pci.h b/drivers/iommu/pci.h
new file mode 100644
index 000..d460646
--- /dev/null
+++ b/drivers/iommu/pci.h
@@ -0,0 +1,29 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * 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, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ *
+ * Copyright (C) 2013 Red Hat, Inc.
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ */
+#ifndef __PCI_H
+#define __PCI_H
+
+/* Helper function for swapping pci device reference */
+static inline void swap_pci_ref(struct pci_dev **from, struct pci_dev *to)
+{
+   pci_dev_put(*from);
+   *from = to;
+}
+
+#endif  /* __PCI_H */
-- 
1.7.4.1


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

[PATCH 2/3 v13] iommu/fsl: Add additional iommu attributes required by the PAMU driver.

[Varun Sethi]

Added the following domain attributes for the FSL PAMU driver:
1. Added new iommu stash attribute, which allows setting of the
   LIODN specific stash id parameter through IOMMU API.
2. Added an attribute for enabling/disabling DMA to a particular
   memory window.
3. Added domain attribute to check for PAMUV1 specific constraints.

Signed-off-by: Varun Sethi 
---
v13 changes:
- created a new file include/linux/fsl_pamu_stash.h for stash
attributes.
v12 changes:
- Moved PAMU specifc stash ids and structures to PAMU header file.
- no change in v11.
- no change in v10.
 include/linux/fsl_pamu_stash.h |   39 +++
 include/linux/iommu.h  |   16 
 2 files changed, 55 insertions(+), 0 deletions(-)
 create mode 100644 include/linux/fsl_pamu_stash.h

diff --git a/include/linux/fsl_pamu_stash.h b/include/linux/fsl_pamu_stash.h
new file mode 100644
index 000..caa1b21
--- /dev/null
+++ b/include/linux/fsl_pamu_stash.h
@@ -0,0 +1,39 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * 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, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ *
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ */
+
+#ifndef __FSL_PAMU_STASH_H
+#define __FSL_PAMU_STASH_H
+
+/* cache stash targets */
+enum pamu_stash_target {
+   PAMU_ATTR_CACHE_L1 = 1,
+   PAMU_ATTR_CACHE_L2,
+   PAMU_ATTR_CACHE_L3,
+};
+
+/*
+ * This attribute allows configuring stashig specific parameters
+ * in the PAMU hardware.
+ */
+
+struct pamu_stash_attribute {
+   u32 cpu;/* cpu number */
+   u32 cache;  /* cache to stash to: L1,L2,L3 */
+};
+
+#endif  /* __FSL_PAMU_STASH_H */
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 2727810..c5dc2b9 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -57,10 +57,26 @@ struct iommu_domain {
 #define IOMMU_CAP_CACHE_COHERENCY  0x1
 #define IOMMU_CAP_INTR_REMAP   0x2 /* isolates device intrs */
 
+/*
+ * Following constraints are specifc to PAMUV1:
+ *  -aperture must be power of 2, and naturally aligned
+ *  -number of windows must be power of 2, and address space size
+ *   of each window is determined by aperture size / # of windows
+ *  -the actual size of the mapped region of a window must be power
+ *   of 2 starting with 4KB and physical address must be naturally
+ *   aligned.
+ * DOMAIN_ATTR_FSL_PAMUV1 corresponds to the above mentioned contraints.
+ * The caller can invoke iommu_domain_get_attr to check if the underlying
+ * iommu implementation supports these constraints.
+ */
+
 enum iommu_attr {
DOMAIN_ATTR_GEOMETRY,
DOMAIN_ATTR_PAGING,
DOMAIN_ATTR_WINDOWS,
+   DOMAIN_ATTR_PAMU_STASH,
+   DOMAIN_ATTR_PAMU_ENABLE,
+   DOMAIN_ATTR_FSL_PAMUV1,
DOMAIN_ATTR_MAX,
 };
 
-- 
1.7.4.1


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

Re: [PATCH RFC] media: videobuf2: fix the length check for mmap

[Prabhakar Lad]

On Fri, Apr 19, 2013 at 4:48 PM, Mauro Carvalho Chehab
 wrote:
> Em Fri, 19 Apr 2013 15:16:56 +0530
> Prabhakar lad  escreveu:
>
>> From: Lad, Prabhakar 
>>
>> From commit 068a0df76023926af958a336a78bef60468d2033
>> "[media] media: vb2: add length check for mmap"
>> patch verifies that the mmap() size requested by userspace
>> doesn't exceed the buffer size.
>>
>> As the mmap() size is rounded up to the next page boundary
>> the check will fail for buffer sizes that are not multiple
>> of the page size.
>>
>> This patch fixes the check by aligning the buffer size to page
>> size during the check. Alongside fixes the vmalloc allocator
>> to round up the size.
>>
>> Signed-off-by: Lad, Prabhakar 
>> Cc: Laurent Pinchart 
>> Cc: Marek Szyprowski 
>> Cc: Seung-Woo Kim 
>> Cc: Hans Verkuil 
>> Cc: Mauro Carvalho Chehab 
>> ---
>>  drivers/media/v4l2-core/videobuf2-core.c|2 +-
>>  drivers/media/v4l2-core/videobuf2-vmalloc.c |2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
>> b/drivers/media/v4l2-core/videobuf2-core.c
>> index 58c1744..223fcd4 100644
>> --- a/drivers/media/v4l2-core/videobuf2-core.c
>> +++ b/drivers/media/v4l2-core/videobuf2-core.c
>> @@ -1886,7 +1886,7 @@ int vb2_mmap(struct vb2_queue *q, struct 
>> vm_area_struct *vma)
>>
>>   vb = q->bufs[buffer];
>>
>> - if (vb->v4l2_planes[plane].length < (vma->vm_end - vma->vm_start)) {
>> + if (PAGE_ALIGN(vb->v4l2_planes[plane].length) < (vma->vm_end - 
>> vma->vm_start)) {
>>   dprintk(1, "Invalid length\n");
>>   return -EINVAL;
>>   }
>
> That is tricky, as it assumes that vb->v4l2_planes[plane].length was round
> up to PAGE_SIZE at each memops driver, but the vb2 core doesn't enforce it.
>
> IMO, it would be cleaner to round vb->v4l2_planes[plane].length up
> at VB2 core, before calling the memops alloc functions at the drivers.
>
> Also, VB2 is already complex enough to put it there without proper
> comments (and there's a minor codingstyle issue there: line is bigger
> than 80 cols).
>
>> diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c 
>> b/drivers/media/v4l2-core/videobuf2-vmalloc.c
>> index 313d977..bf3b95c 100644
>> --- a/drivers/media/v4l2-core/videobuf2-vmalloc.c
>> +++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c
>> @@ -44,7 +44,7 @@ static void *vb2_vmalloc_alloc(void *alloc_ctx, unsigned 
>> long size, gfp_t gfp_fl
>>   return NULL;
>>
>>   buf->size = size;
>> - buf->vaddr = vmalloc_user(buf->size);
>> + buf->vaddr = vmalloc_user(PAGE_ALIGN(buf->size));
>
> See? You needed to put an alignment here as well, not because vmalloc
> needs it, but because this is needed by VB2 core.
>
> Also, on the other drivers, buf->size is stored page aligned, while
> here, you're doing different, without any documented reason for doing
> that, instead of doing the same as on the other memops drivers.
>
> That mistake reflects, for example, when the driver prints the failure:
>
> if (!buf->vaddr) {
> pr_debug("vmalloc of size %ld failed\n", buf->size);
>
> as it will show a different size than what you actually required.
> As those memory starving errors can also produce a dump at the mm
> core, the size there won't match the size on the above printed message.
>
> Also, it is a very bad idea to delegate the core's requirement of
> do page alignment from the core to the memops drivers, as other
> patches may change the logic there, or a new memops could be added,
> and the same problem will hit again (and unnoticed, as the check
> routine do page alignments).
>
>>   buf->handler.refcount = &buf->refcount;
>>   buf->handler.put = vb2_vmalloc_put;
>>   buf->handler.arg = buf;
>
> IMO, a cleaner version would be the following (untested) code.
>
> -
>
> [media] videobuf2: fix the length check for mmap
>
> Memory maps typically require that the buffer size to be page
> aligned. Currently, two memops drivers do such alignment
> internally, but videobuf-vmalloc doesn't.
>
> Also, the buffer overflow check doesn't take it into account.
>
> So, instead of doing it at each memops driver, enforce it at
> VB2 core.
>
> Reported-by: Prabhakar lad 
> Signed-off-by: Mauro Carvalho Chehab 
>
Reported-and-tested-by: Lad, Prabhakar 

Regards,
--Prabhakar
--
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] intel-iommu: Disable DMA Remapping when intel_iommu=off

[Takao Indoh]

(2013/04/20 15:58), Wei Hu wrote:
> On a VT-d capable machine Linux will enable IOMMU by default. If it
> then kexec's a second kernel with intel_iommu=off, this second kernel
> will leave the DMA remapping engine on with no code handling it. The
> symptom is at least USB and SATA drives stop working. This patch fixes
> the problem by always disabling DMA remapping when intel_iommu=off.

Even when second kernel boots up with intel_iommu=on, dma-remapping need
to be disabled as well before it is initialized and enabled again in
init_dmars(). So, how about something like this?

for_each_drhd_unit(drhd) {
struct dmar_drhd_unit *drhd;
if (drhd->ignored)
continue;

iommu = drhd->iommu;
if (iommu->gcmd & DMA_GCMD_TE)
iommu_disable_translation(iommu);
}

Note, if you agree above code and fix your patch like this, you need
additinal fix to set iommu->gcmd flag sinse gcmd is always zero here.
See first hunk of this patch.
https://lkml.org/lkml/2013/3/20/707

Thanks,
Takao Indoh


> 
> Signed-off-by: Wei Hu 
> ---
>   drivers/iommu/intel-iommu.c |6 +-
>   1 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 0099667..0b8f8bb 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -3681,8 +3681,12 @@ int __init intel_iommu_init(void)
>   return  -ENODEV;
>   }
>   
> - if (no_iommu || dmar_disabled)
> + if (no_iommu || dmar_disabled) {
> + struct dmar_drhd_unit *drhd;
> + for_each_drhd_unit(drhd)
> + iommu_disable_translation(drhd->iommu);
>   return -ENODEV;
> + }
>   
>   if (iommu_init_mempool()) {
>   if (force_on)
> 

--
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] sched: wake-affine throttle

[Mike Galbraith]

On Mon, 2013-04-22 at 12:21 +0800, Michael Wang wrote: 
> On 04/10/2013 11:30 AM, Michael Wang wrote:
> > Log since RFC:
> > 1. Throttle only when wake-affine failed. (thanks to PeterZ)
> > 2. Do throttle inside wake_affine(). (thanks to PeterZ)
> > 3. Other small fix.
> > 
> > Recently testing show that wake-affine stuff cause regression on pgbench, 
> > the
> > hiding rat was finally catched out.
> > 
> > wake-affine stuff is always trying to pull wakee close to waker, by theory,
> > this will benefit us if waker's cpu cached hot data for wakee, or the 
> > extreme
> > ping-pong case.
> > 
> > However, the whole stuff is somewhat blindly, load balance is the only 
> > factor
> > to be guaranteed, and since the stuff itself is time-consuming, some 
> > workload
> > suffered, pgbench is just the one who has been found.
> > 
> > Thus, throttle the wake-affine stuff for such workload is necessary.
> > 
> > This patch introduced a new knob 'sysctl_sched_wake_affine_interval' with 
> > the
> > default value 1ms (default minimum balance interval), which means 
> > wake-affine
> > will keep silent for 1ms after it returned false.
> > 
> > By turning the new knob, those workload who suffered will have the chance to
> > stop the regression.
> 
> I have tested the latest tip 3.9.0-rc7, huge regression on pgbench is
> still there and this approach still works well, should we take the
> action now?

(It's not a _regression_ per se, more of a long standing issue for this
sort of load.  Not that the load cares much what we call the problem;)

> 
> Regards,
> Michael Wang
> 
> > 
> > Test:
> > Test with 12 cpu X86 server and tip 3.9.0-rc2.
> > 
> > default
> > base1ms interval 10ms interval   100ms interval
> > | db_size | clients |  tps  |   |  tps  ||  tps  | |  
> > tps  |
> > +-+-+---+-  +---++---+ +---+
> > | 21 MB   |   1 | 10572 |   | 10804 || 10802 | | 10801 |
> > | 21 MB   |   2 | 21275 |   | 21533 || 21400 | | 21498 |
> > | 21 MB   |   4 | 41866 |   | 42158 || 42410 | | 42306 |
> > | 21 MB   |   8 | 53931 |   | 55796 || 58608 | +8.67%  | 59916 
> > | +11.10%
> > | 21 MB   |  12 | 50956 |   | 52266 || 54586 | +7.12%  | 55982 
> > | +9.86%
> > | 21 MB   |  16 | 49911 |   | 52862 | +5.91% | 55668 | +11.53% | 57255 
> > | +14.71%
> > | 21 MB   |  24 | 46046 |   | 48820 | +6.02% | 54269 | +17.86% | 58113 
> > | +26.21%
> > | 21 MB   |  32 | 43405 |   | 46635 | +7.44% | 53690 | +23.70% | 57729 
> > | +33.00%
> > | 7483 MB |   1 |  7734 |   |  8013 ||  8046 | |  7879 |
> > | 7483 MB |   2 | 19375 |   | 19459 || 19448 | | 19421 |
> > | 7483 MB |   4 | 37408 |   | 37780 || 37937 | | 37819 |
> > | 7483 MB |   8 | 49033 |   | 50389 || 51636 | +5.31%  | 52294 
> > | +6.65%
> > | 7483 MB |  12 | 45525 |   | 47794 | +4.98% | 49828 | +9.45%  | 50571 
> > | +11.08%
> > | 7483 MB |  16 | 45731 |   | 47921 | +4.79% | 50203 | +9.78%  | 52033 
> > | +13.78%
> > | 7483 MB |  24 | 41533 |   | 44301 | +6.67% | 49697 | +19.66% | 53833 
> > | +29.62%
> > | 7483 MB |  32 | 36370 |   | 38301 | +5.31% | 48146 | +32.38% | 52795 
> > | +45.16%
> > | 15 GB   |   1 |  7576 |   |  7926 ||  7722 | |  7969 |
> > | 15 GB   |   2 | 19157 |   | 19284 || 19294 | | 19304 |
> > | 15 GB   |   4 | 37285 |   | 37539 || 37281 | | 37508 |
> > | 15 GB   |   8 | 48718 |   | 49176 || 50836 | +4.35%  | 51239 
> > | +5.17%
> > | 15 GB   |  12 | 45167 |   | 47180 | +4.45% | 49206 | +8.94%  | 50126 
> > | +10.98%
> > | 15 GB   |  16 | 45270 |   | 47293 | +4.47% | 49638 | +9.65%  | 51748 
> > | +14.31%
> > | 15 GB   |  24 | 40984 |   | 43366 | +5.81% | 49356 | +20.43% | 53157 
> > | +29.70%
> > | 15 GB   |  32 | 35918 |   | 37632 | +4.77% | 47923 | +33.42% | 52241 
> > | +45.45%
> > 
> > Suggested-by: Peter Zijlstra 
> > Signed-off-by: Michael Wang 
> > ---
> >  include/linux/sched.h |5 +
> >  kernel/sched/fair.c   |   31 +++
> >  kernel/sysctl.c   |   10 ++
> >  3 files changed, 46 insertions(+), 0 deletions(-)
> > 
> > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > index d35d2b6..e9efd3a 100644
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -1197,6 +1197,10 @@ enum perf_event_task_context {
> > perf_nr_task_contexts,
> >  };
> > 
> > +#ifdef CONFIG_SMP
> > +extern unsigned int sysctl_sched_wake_affine_interval;
> > +#endif
> > +
> >  struct task_struct {
> > volatile long state;/* -1 unrunnable, 0 runnable, >0 stopped */
> > void *stack;
> > @@ -1207,6 +1211,7 @@ struct task_struct {
> >  #ifdef CONFIG_SMP
> > struct llist_node wake_entry;
> > int

[RFC/PATCH 4/4] s390: Provide default implementation for dma_{alloc,free}_attrs

[Damian Hobson-Garcia]

Most architectures that define CONFIG_HAVE_DMA, have implementations for
both dma_alloc_attrs() and dma_free_attrs().  All achitectures that do
not define CONFIG_HAVE_DMA also have both of these definitions provided by
dma-mapping-broken.h.

Add default implementations for these functions on s390.

Signed-off-by: Damian Hobson-Garcia 
---
 arch/s390/include/asm/dma-mapping.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/s390/include/asm/dma-mapping.h 
b/arch/s390/include/asm/dma-mapping.h
index 9411db65..91f7312 100644
--- a/arch/s390/include/asm/dma-mapping.h
+++ b/arch/s390/include/asm/dma-mapping.h
@@ -55,6 +55,9 @@ static inline int dma_mapping_error(struct device *dev, 
dma_addr_t dma_addr)
return (dma_addr == 0UL);
 }
 
+#define dma_alloc_attrs(d, s, h, f, a) dma_alloc_coherent(d, s, h, f)
+#define dma_free_attrs(d, s, h, f, a) dma_free_coherent(d, s, h, f)
+
 static inline void *dma_alloc_coherent(struct device *dev, size_t size,
   dma_addr_t *dma_handle, gfp_t flag)
 {
-- 
1.7.5.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/

[RFC/PATCH 3/4] parisc: Provide default implementation for dma_{alloc,free}_attrs

[Damian Hobson-Garcia]

Most architectures that define CONFIG_HAVE_DMA, have implementations for
both dma_alloc_attrs() and dma_free_attrs().  All achitectures that do
not define CONFIG_HAVE_DMA also have both of these definitions provided by
dma-mapping-broken.h.

Add default implementations for these functions on parisc.

Signed-off-by: Damian Hobson-Garcia 
---
 arch/parisc/include/asm/dma-mapping.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/parisc/include/asm/dma-mapping.h 
b/arch/parisc/include/asm/dma-mapping.h
index 106b395..d0eae5f 100644
--- a/arch/parisc/include/asm/dma-mapping.h
+++ b/arch/parisc/include/asm/dma-mapping.h
@@ -46,6 +46,9 @@ extern struct hppa_dma_ops pcx_dma_ops;
 
 extern struct hppa_dma_ops *hppa_dma_ops;
 
+#define dma_alloc_attrs(d, s, h, f, a) dma_alloc_coherent(d, s, h, f)
+#define dma_free_attrs(d, s, h, f, a) dma_free_coherent(d, s, h, f)
+
 static inline void *
 dma_alloc_coherent(struct device *dev, size_t size, dma_addr_t *dma_handle,
   gfp_t flag)
-- 
1.7.5.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/

[RFC/PATCH 2/4] c6x: Provide default implementation for dma_{alloc,free}_attrs

[Damian Hobson-Garcia]

Most architectures that define CONFIG_HAVE_DMA, have implementations for
both dma_alloc_attrs() and dma_free_attrs().  All achitectures that do
not define CONFIG_HAVE_DMA also have both of these definitions provided by
dma-mapping-broken.h.

Add default implementations for these functions on c6x.

Signed-off-by: Damian Hobson-Garcia 
---
 arch/c6x/include/asm/dma-mapping.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/c6x/include/asm/dma-mapping.h 
b/arch/c6x/include/asm/dma-mapping.h
index 88bd0d8..8947605 100644
--- a/arch/c6x/include/asm/dma-mapping.h
+++ b/arch/c6x/include/asm/dma-mapping.h
@@ -89,6 +89,9 @@ extern void dma_free_coherent(struct device *, size_t, void 
*, dma_addr_t);
 #define dma_alloc_noncoherent(d, s, h, f) dma_alloc_coherent((d), (s), (h), 
(f))
 #define dma_free_noncoherent(d, s, v, h)  dma_free_coherent((d), (s), (v), (h))
 
+#define dma_alloc_attrs(d, s, h, f, a) dma_alloc_coherent(d, s, h, f)
+#define dma_free_attrs(d, s, h, f, a) dma_free_coherent(d, s, h, f)
+
 /* Not supported for now */
 static inline int dma_mmap_coherent(struct device *dev,
struct vm_area_struct *vma, void *cpu_addr,
-- 
1.7.5.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/

[RFC/PATCH 1/4] arm64: Provide default implementation for dma_{alloc,free}_attrs

[Damian Hobson-Garcia]

Most architectures that define CONFIG_HAVE_DMA, have implementations for
both dma_alloc_attrs() and dma_free_attrs().  All achitectures that do
not define CONFIG_HAVE_DMA also have both of these definitions provided by
dma-mapping-broken.h.

Add default implementations for these functions on arm64.

Signed-off-by: Damian Hobson-Garcia 
---
 arch/arm64/include/asm/dma-mapping.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/include/asm/dma-mapping.h 
b/arch/arm64/include/asm/dma-mapping.h
index 9947768..65ab181 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -81,6 +81,9 @@ static inline void dma_mark_clean(void *addr, size_t size)
 {
 }
 
+#define dma_alloc_attrs(d, s, h, f, a) dma_alloc_coherent(d, s, h, f)
+#define dma_free_attrs(d, s, h, f, a) dma_free_coherent(d, s, h, f)
+
 static inline void *dma_alloc_coherent(struct device *dev, size_t size,
   dma_addr_t *dma_handle, gfp_t flags)
 {
-- 
1.7.5.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] ARM64: kernel: compiling issue, define cmpxchg64 and cmpxchg64_local for outside using.

[Chen Gang]

  drivers use cmpxchg64, cmpxchg64_local ... to perform 64-bit operation,
  so they can cross 32-bit and 64-bit platforms (it is a standard way).


Signed-off-by: Chen Gang 
---
 arch/arm64/include/asm/cmpxchg.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h
index 968b5cb..8a8ce0e 100644
--- a/arch/arm64/include/asm/cmpxchg.h
+++ b/arch/arm64/include/asm/cmpxchg.h
@@ -170,4 +170,7 @@ static inline unsigned long __cmpxchg_mb(volatile void 
*ptr, unsigned long old,
   (unsigned long)(n),  \
   sizeof(*(ptr
 
+#define cmpxchg64(ptr,o,n) cmpxchg((ptr),(o),(n))
+#define cmpxchg64_local(ptr,o,n)   cmpxchg_local((ptr),(o),(n))
+
 #endif /* __ASM_CMPXCHG_H */
-- 
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Suggestion] ARM64: kernel: compiling issue, need implement cmpxchg64 with assembler language.

[Chen Gang]

On 2013年04月20日 15:32, Arnd Bergmann wrote:
> On Saturday 20 April 2013 10:28:55 Chen Gang wrote:
>>
>> ---patch 
>> begin--
>>
>> diff --git a/arch/arm64/include/asm/cmpxchg.h 
>> b/arch/arm64/include/asm/cmpxchg.h
>> index 968b5cb..b572d2b 100644
>> --- a/arch/arm64/include/asm/cmpxchg.h
>> +++ b/arch/arm64/include/asm/cmpxchg.h
>> @@ -170,4 +170,6 @@ static inline unsigned long __cmpxchg_mb(volatile void 
>> *ptr, unsigned long old,
>>(unsigned long)(n),  \
>>sizeof(*(ptr
>>  
>> +#define cmpxchg64(ptr,o,n) cmpxchg((ptr),(o),(n))
>> +
>>  #endif /* __ASM_CMPXCHG_H */
> 
> Yes, this looks good. Please provide the same for cmpxchg64_local.
> 

  ok, thanks, I will send related patch.


gchen.

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

[RFC/PATCH 0/4] dma-mapping: Define dma_{alloc,free}_attrs() for all archs

[Damian Hobson-Garcia]

Most architectures that define CONFIG_HAVE_DMA=y, have implementations for
both dma_alloc_attrs() and dma_free_attrs().  All achitectures that do
not define CONFIG_HAVE_DMA also have both of these definitions provided by
dma-mapping-broken.h.

Provide a default definition for the archs that define CONFIG_HAVE_DMA=y,
but have no implementation for dma_{alloc,free}_attrs() by simply calling
dma_{alloc,free}_coherent() and throwing away the attrs argument.

Damian Hobson-Garcia (4):
  Provide default implementation for dma_{alloc,free}_attrs on arm64
  Provide default implementation for dma_{alloc,free}_attrs on c6x
  Provide default implementation for dma_{alloc,free}_attrs on parisc
  Provide default implementation for dma_{alloc,free}_attrs on s390

 arch/arm64/include/asm/dma-mapping.h  |3 +++
 arch/c6x/include/asm/dma-mapping.h|3 +++
 arch/parisc/include/asm/dma-mapping.h |3 +++
 arch/s390/include/asm/dma-mapping.h   |3 +++
 4 files changed, 12 insertions(+), 0 deletions(-)

-- 
1.7.5.4

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

Re: [PATCH 0/3] Add boot_enable attribute to eMMC device for boot mode operation selection

[Namjae Jeon]

2013/4/19, Neil Armstrong :
> Since eMMC 4.3 a special boot mode operation was introduced to retrieve
> data from the eMMC device with a very simple procedure. Since the Linux
> kernel exports these device boot partitions, it may be useful to select
> the boot partition from the user space.
>
> The patch has been tested on a Toshiba eMMC conforming with eMMC 4.5
> specifications.
Hi Neil.
We can be enable boot partition using mmc-utils.
See this address.
https://git.kernel.org/cgit/linux/kernel/git/cjb/mmc-utils.git/commit/?id=7bd1320b2cb38f040ab5cf017d17e283496690bf

So, I don't think this patch is useful.
If you consider to be disable boot partition, you can try to update
mmc-utils base on the address I shared.

Thanks.
>
> Neil Armstrong (3):
>   Add BOOT_PARTITION_ENABLE definition to MMC EXT_CSD PART_CONFIG
>   Add boot_enable sysfs attribute to select MMC boot operation
> partition
>   Add Documentation for MMC boot_enable attribute
>
>  Documentation/mmc/mmc-dev-parts.txt |6 +++
>  drivers/mmc/card/block.c|   72
> ++-
>  include/linux/mmc/mmc.h |1 +
>  3 files changed, 78 insertions(+), 1 deletions(-)
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] X.509: Support parse long form of length octets in Authority Key Identifier

[joeyli]

於 一，2013-04-22 於 11:37 +0930，Rusty Russell 提到：
> "Lee, Chun-Yi"  writes:
> > From: Chun-Yi Lee 
> >
> > Per X.509 spec in 4.2.1.1 section, the structure of Authority Key
> > Identifier Extension is:
> >
> >AuthorityKeyIdentifier ::= SEQUENCE {
> >   keyIdentifier [0] KeyIdentifier   OPTIONAL,
> >   authorityCertIssuer   [1] GeneralNamesOPTIONAL,
> >   authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }
> >
> >KeyIdentifier ::= OCTET STRING
> >
> > When a certificate also provides
> > authorityCertIssuer and authorityCertSerialNumber then the length of
> > AuthorityKeyIdentifier SEQUENCE is likely to long form format.
> > e.g.
> >The example certificate demos/tunala/A-server.pem in openssl source:
> >
> > X509v3 Authority Key Identifier:
> > keyid:49:FB:45:72:12:C4:CC:E1:45:A1:D3:08:9E:95:C4:2C:6D:55:3F:17
> > DirName:/C=NZ/L=Wellington/O=Really Irresponsible Authorisation 
> > Authority (RIAA)/OU=Cert-stamping/CN=Jackov 
> > al-Trades/emailAddress=none@fake.domain
> > serial:00
> >
> > Current parsing rule of OID_authorityKeyIdentifier only take care the
> > short form format, it causes load certificate to modsign_keyring fail:
> >
> > [   12.061147] X.509: Extension: 47
> > [   12.075121] MODSIGN: Problem loading in-kernel X.509 certificate (-74)
> >
> > So, this patch add the parsing rule for support long form format against
> > Authority Key Identifier.
> >
> > v3:
> > Changed the size check in "Short Form length" case, we allow v[3] smaller
> > then (vlen - 4) because authorityCertIssuer and authorityCertSerialNumber
> > are also possible attach in AuthorityKeyIdentifier sequence.
> >
> > v2:
> >  - Removed comma from author's name.
> >  - Moved 'Short Form length' comment inside the if-body.
> >  - Changed the type of sub to size_t.
> >  - Use ASN1_INDEFINITE_LENGTH rather than writing 0x80 and 127.
> >  - Moved the key_len's value assignment before alter v.
> >  - Fixed the typo of octets.
> >  - Add 2 to v before entering the loop for calculate the length.
> >  - Removed the comment of check vlen.
> >
> > Cc: Rusty Russell 
> > Cc: Josh Boyer 
> > Cc: Randy Dunlap 
> > Cc: Herbert Xu 
> > Cc: "David S. Miller" 
> > Acked-by: David Howells 
> > Signed-off-by: Chun-Yi Lee 
> 
> Applied to modules-next.
> 
> Thanks,
> Rusty.
> 

Thanks for help!
Joey Lee


--
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] sched: wake-affine throttle

[Michael Wang]

On 04/10/2013 11:30 AM, Michael Wang wrote:
> Log since RFC:
>   1. Throttle only when wake-affine failed. (thanks to PeterZ)
>   2. Do throttle inside wake_affine(). (thanks to PeterZ)
>   3. Other small fix.
> 
> Recently testing show that wake-affine stuff cause regression on pgbench, the
> hiding rat was finally catched out.
> 
> wake-affine stuff is always trying to pull wakee close to waker, by theory,
> this will benefit us if waker's cpu cached hot data for wakee, or the extreme
> ping-pong case.
> 
> However, the whole stuff is somewhat blindly, load balance is the only factor
> to be guaranteed, and since the stuff itself is time-consuming, some workload
> suffered, pgbench is just the one who has been found.
> 
> Thus, throttle the wake-affine stuff for such workload is necessary.
> 
> This patch introduced a new knob 'sysctl_sched_wake_affine_interval' with the
> default value 1ms (default minimum balance interval), which means wake-affine
> will keep silent for 1ms after it returned false.
> 
> By turning the new knob, those workload who suffered will have the chance to
> stop the regression.

I have tested the latest tip 3.9.0-rc7, huge regression on pgbench is
still there and this approach still works well, should we take the
action now?

Regards,
Michael Wang

> 
> Test:
>   Test with 12 cpu X86 server and tip 3.9.0-rc2.
> 
>   default
>   base1ms interval 10ms interval   100ms interval
> | db_size | clients |  tps  | |  tps  ||  tps  | |  tps  |
> +-+-+---+-  +---++---+ +---+
> | 21 MB   |   1 | 10572 |   | 10804 || 10802 | | 10801 |
> | 21 MB   |   2 | 21275 |   | 21533 || 21400 | | 21498 |
> | 21 MB   |   4 | 41866 |   | 42158 || 42410 | | 42306 |
> | 21 MB   |   8 | 53931 |   | 55796 || 58608 | +8.67%  | 59916 | 
> +11.10%
> | 21 MB   |  12 | 50956 |   | 52266 || 54586 | +7.12%  | 55982 | 
> +9.86%
> | 21 MB   |  16 | 49911 |   | 52862 | +5.91% | 55668 | +11.53% | 57255 | 
> +14.71%
> | 21 MB   |  24 | 46046 |   | 48820 | +6.02% | 54269 | +17.86% | 58113 | 
> +26.21%
> | 21 MB   |  32 | 43405 |   | 46635 | +7.44% | 53690 | +23.70% | 57729 | 
> +33.00%
> | 7483 MB |   1 |  7734 |   |  8013 ||  8046 | |  7879 |
> | 7483 MB |   2 | 19375 |   | 19459 || 19448 | | 19421 |
> | 7483 MB |   4 | 37408 |   | 37780 || 37937 | | 37819 |
> | 7483 MB |   8 | 49033 |   | 50389 || 51636 | +5.31%  | 52294 | 
> +6.65%
> | 7483 MB |  12 | 45525 |   | 47794 | +4.98% | 49828 | +9.45%  | 50571 | 
> +11.08%
> | 7483 MB |  16 | 45731 |   | 47921 | +4.79% | 50203 | +9.78%  | 52033 | 
> +13.78%
> | 7483 MB |  24 | 41533 |   | 44301 | +6.67% | 49697 | +19.66% | 53833 | 
> +29.62%
> | 7483 MB |  32 | 36370 |   | 38301 | +5.31% | 48146 | +32.38% | 52795 | 
> +45.16%
> | 15 GB   |   1 |  7576 |   |  7926 ||  7722 | |  7969 |
> | 15 GB   |   2 | 19157 |   | 19284 || 19294 | | 19304 |
> | 15 GB   |   4 | 37285 |   | 37539 || 37281 | | 37508 |
> | 15 GB   |   8 | 48718 |   | 49176 || 50836 | +4.35%  | 51239 | 
> +5.17%
> | 15 GB   |  12 | 45167 |   | 47180 | +4.45% | 49206 | +8.94%  | 50126 | 
> +10.98%
> | 15 GB   |  16 | 45270 |   | 47293 | +4.47% | 49638 | +9.65%  | 51748 | 
> +14.31%
> | 15 GB   |  24 | 40984 |   | 43366 | +5.81% | 49356 | +20.43% | 53157 | 
> +29.70%
> | 15 GB   |  32 | 35918 |   | 37632 | +4.77% | 47923 | +33.42% | 52241 | 
> +45.45%
> 
> Suggested-by: Peter Zijlstra 
> Signed-off-by: Michael Wang 
> ---
>  include/linux/sched.h |5 +
>  kernel/sched/fair.c   |   31 +++
>  kernel/sysctl.c   |   10 ++
>  3 files changed, 46 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index d35d2b6..e9efd3a 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1197,6 +1197,10 @@ enum perf_event_task_context {
>   perf_nr_task_contexts,
>  };
> 
> +#ifdef CONFIG_SMP
> +extern unsigned int sysctl_sched_wake_affine_interval;
> +#endif
> +
>  struct task_struct {
>   volatile long state;/* -1 unrunnable, 0 runnable, >0 stopped */
>   void *stack;
> @@ -1207,6 +1211,7 @@ struct task_struct {
>  #ifdef CONFIG_SMP
>   struct llist_node wake_entry;
>   int on_cpu;
> + unsigned long next_wake_affine;
>  #endif
>   int on_rq;
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 7a33e59..68eedd7 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -3087,6 +3087,22 @@ static inline unsigned long effective_load(struct 
> task_group *tg, int cpu,
> 
>  #endif
> 
> +/*
> + * Default is 1ms, to prevent the wake_affine() stuff working too frequently.
> + 

Re: [PATCH v3] X.509: Support parse long form of length octets in Authority Key Identifier

[Rusty Russell]

"Lee, Chun-Yi"  writes:
> From: Chun-Yi Lee 
>
> Per X.509 spec in 4.2.1.1 section, the structure of Authority Key
> Identifier Extension is:
>
>AuthorityKeyIdentifier ::= SEQUENCE {
>   keyIdentifier [0] KeyIdentifier   OPTIONAL,
>   authorityCertIssuer   [1] GeneralNamesOPTIONAL,
>   authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }
>
>KeyIdentifier ::= OCTET STRING
>
> When a certificate also provides
> authorityCertIssuer and authorityCertSerialNumber then the length of
> AuthorityKeyIdentifier SEQUENCE is likely to long form format.
> e.g.
>The example certificate demos/tunala/A-server.pem in openssl source:
>
> X509v3 Authority Key Identifier:
> keyid:49:FB:45:72:12:C4:CC:E1:45:A1:D3:08:9E:95:C4:2C:6D:55:3F:17
> DirName:/C=NZ/L=Wellington/O=Really Irresponsible Authorisation Authority 
> (RIAA)/OU=Cert-stamping/CN=Jackov al-Trades/emailAddress=none@fake.domain
> serial:00
>
> Current parsing rule of OID_authorityKeyIdentifier only take care the
> short form format, it causes load certificate to modsign_keyring fail:
>
> [   12.061147] X.509: Extension: 47
> [   12.075121] MODSIGN: Problem loading in-kernel X.509 certificate (-74)
>
> So, this patch add the parsing rule for support long form format against
> Authority Key Identifier.
>
> v3:
> Changed the size check in "Short Form length" case, we allow v[3] smaller
> then (vlen - 4) because authorityCertIssuer and authorityCertSerialNumber
> are also possible attach in AuthorityKeyIdentifier sequence.
>
> v2:
>  - Removed comma from author's name.
>  - Moved 'Short Form length' comment inside the if-body.
>  - Changed the type of sub to size_t.
>  - Use ASN1_INDEFINITE_LENGTH rather than writing 0x80 and 127.
>  - Moved the key_len's value assignment before alter v.
>  - Fixed the typo of octets.
>  - Add 2 to v before entering the loop for calculate the length.
>  - Removed the comment of check vlen.
>
> Cc: Rusty Russell 
> Cc: Josh Boyer 
> Cc: Randy Dunlap 
> Cc: Herbert Xu 
> Cc: "David S. Miller" 
> Acked-by: David Howells 
> Signed-off-by: Chun-Yi Lee 

Applied to modules-next.

Thanks,
Rusty.
--
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 66/72] mtdchar: fix offset overflow detection

[Ben Hutchings]

On Thu, 2013-04-18 at 10:16 +0100, Luis Henriques wrote:
> 3.5.7.11 -stable review patch.  If anyone has any objections, please let me 
> know.
> 
> --
> 
> From: Linus Torvalds 
> 
> commit 9c603e53d380459fb62fec7cd085acb0b74ac18f upstream.
[...]

There are further problems with mtdchar_mmap(), and David recommended to
apply commit f5cf8f07423b 'mtd: Disable mtdchar mmap on MMU systems'
instead.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.


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

Re: [PATCH 35/72] KVM: x86: Convert MSR_KVM_SYSTEM_TIME to use gfn_to_hva_cache functions (CVE-2013-1797)

[Ben Hutchings]

On Thu, 2013-04-18 at 10:16 +0100, Luis Henriques wrote:
> 3.5.7.11 -stable review patch.  If anyone has any objections, please let me 
> know.
> 
> --
> 
> From: Andy Honig 
> 
> commit 0b79459b482e85cb7426aa7da683a9f2c97aeae1 upstream.
> 
> There is a potential use after free issue with the handling of
> MSR_KVM_SYSTEM_TIME.  If the guest specifies a GPA in a movable or removable
> memory such as frame buffers then KVM might continue to write to that
> address even after it's removed via KVM_SET_USER_MEMORY_REGION.  KVM pins
> the page in memory so it's unlikely to cause an issue, but if the user
> space component re-purposes the memory previously used for the guest, then
> the guest will be able to corrupt that memory.
> 
> Tested: Tested against kvmclock unit test
> 
> Signed-off-by: Andrew Honig 
> Signed-off-by: Marcelo Tosatti 
> [ luis: backported to 3.5:
>   - Adjust context
>   - Removed references to PVCLOCK_GUEST_STOPPED ]
> Signed-off-by: Luis Henriques 

This apparently needs to be followed by commit 8f964525a121 'KVM: Allow
cross page reads and writes from cached translations.', as some guests
don't follow the rules.

Ben.

> ---
>  arch/x86/include/asm/kvm_host.h |  4 ++--
>  arch/x86/kvm/x86.c  | 40 +++-
>  2 files changed, 17 insertions(+), 27 deletions(-)
> 
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index db7c1f2..9a50912 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -410,8 +410,8 @@ struct kvm_vcpu_arch {
>   gpa_t time;
>   struct pvclock_vcpu_time_info hv_clock;
>   unsigned int hw_tsc_khz;
> - unsigned int time_offset;
> - struct page *time_page;
> + struct gfn_to_hva_cache pv_time;
> + bool pv_time_enabled;
>  
>   struct {
>   u64 msr_val;
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index ad5cf4b..5b4ac78 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1118,7 +1118,6 @@ static int kvm_guest_time_update(struct kvm_vcpu *v)
>  {
>   unsigned long flags;
>   struct kvm_vcpu_arch *vcpu = &v->arch;
> - void *shared_kaddr;
>   unsigned long this_tsc_khz;
>   s64 kernel_ns, max_kernel_ns;
>   u64 tsc_timestamp;
> @@ -1154,7 +1153,7 @@ static int kvm_guest_time_update(struct kvm_vcpu *v)
>  
>   local_irq_restore(flags);
>  
> - if (!vcpu->time_page)
> + if (!vcpu->pv_time_enabled)
>   return 0;
>  
>   /*
> @@ -1212,14 +1211,9 @@ static int kvm_guest_time_update(struct kvm_vcpu *v)
>*/
>   vcpu->hv_clock.version += 2;
>  
> - shared_kaddr = kmap_atomic(vcpu->time_page);
> -
> - memcpy(shared_kaddr + vcpu->time_offset, &vcpu->hv_clock,
> -sizeof(vcpu->hv_clock));
> -
> - kunmap_atomic(shared_kaddr);
> -
> - mark_page_dirty(v->kvm, vcpu->time >> PAGE_SHIFT);
> + kvm_write_guest_cached(v->kvm, &vcpu->pv_time,
> + &vcpu->hv_clock,
> + sizeof(vcpu->hv_clock));
>   return 0;
>  }
>  
> @@ -1508,10 +1502,7 @@ static int kvm_pv_enable_async_pf(struct kvm_vcpu 
> *vcpu, u64 data)
>  
>  static void kvmclock_reset(struct kvm_vcpu *vcpu)
>  {
> - if (vcpu->arch.time_page) {
> - kvm_release_page_dirty(vcpu->arch.time_page);
> - vcpu->arch.time_page = NULL;
> - }
> + vcpu->arch.pv_time_enabled = false;
>  }
>  
>  static void accumulate_steal_time(struct kvm_vcpu *vcpu)
> @@ -1606,6 +1597,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, 
> u64 data)
>   break;
>   case MSR_KVM_SYSTEM_TIME_NEW:
>   case MSR_KVM_SYSTEM_TIME: {
> + u64 gpa_offset;
>   kvmclock_reset(vcpu);
>  
>   vcpu->arch.time = data;
> @@ -1615,21 +1607,18 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 
> msr, u64 data)
>   if (!(data & 1))
>   break;
>  
> - /* ...but clean it before doing the actual write */
> - vcpu->arch.time_offset = data & ~(PAGE_MASK | 1);
> + gpa_offset = data & ~(PAGE_MASK | 1);
>  
>   /* Check that the address is 32-byte aligned. */
> - if (vcpu->arch.time_offset &
> - (sizeof(struct pvclock_vcpu_time_info) - 1))
> + if (gpa_offset & (sizeof(struct pvclock_vcpu_time_info) - 1))
>   break;
>  
> - vcpu->arch.time_page =
> - gfn_to_page(vcpu->kvm, data >> PAGE_SHIFT);
> + if (kvm_gfn_to_hva_cache_init(vcpu->kvm,
> +  &vcpu->arch.pv_time, data & ~1ULL))
> + vcpu->arch.pv_time_enabled = false;
> + else
> + vcpu->arch.pv_time_enabled = true;
>  
> - if (is_error_page(vcpu->arch.time_page)) {
> - kvm_release_page_clean(vcpu->arch.t

Re: [PATCH] ext4: fix a big-endian bug when an extent is zeroed out

[CAI Qian]

Hi Ted,

- Original Message -
> From: "Theodore Ts'o" 
> To: "CAI Qian" 
> Cc: "Eric Whitney" , "Dmitry Monakhov" 
> , "Christian Kujau"
> nerdbynature.de>, "LKML" , "linux-s390" 
> , "Steve
> Best" , linux-e...@vger.kernel.org
> Sent: Saturday, April 20, 2013 11:19:45 PM
> Subject: Re: [PATCH] ext4: fix a big-endian bug when an extent is zeroed out
> 
> On Mon, Apr 08, 2013 at 11:05:11PM -0400, CAI Qian wrote:
> > I can help run xfstests for ext4 dev tree on x64, Power7, Z10 and
> > KVM platforms with back-storage like SAN/multipath, iSCSI and FCoE.
> > I plan to run this weekly and setup a wiki page to update the testing
> > status by every Friday.
> 
> Hi CAI,
> 
> Sorry for not getting back to you sooner; I was at Collaboration
> Summit and LSF/MM last week.
> 
> It would be great if you could help run xfstests on the ext4 dev tree
> on various platforms.  We don't have any coverage on Power7 or
> s390/Z10 at the moment, so that would be especially welcome.  Coverage
> on alternate storage backends can be interesting in finding timing
> problems so they would be valuable as well.
> 
> If you have any Itanium platforms, that would be great too, since we
> don't have that today.
Unfortunately, to get those ia64 up and running with the upstream kernel
required some significant efforts. I'd leave that for now until it is
something very important.
> 
> The various ext4 configurations which I test can be found in the
> kvm-autorun/conf directory in my xfstests-bld git repository:
> 
> git://git.kernel.org/pub/scm/fs/ext2/xfstests-bld.git
> 
> (This repository is a convenient setup to do build xfstests in a
> hermetic environment, and convenience scripts to run xfstests under
> kvm, and scripts on the host OS kick off the kvm test run and parse
> the test output afterwards.)
> 
> Thanks for offering to test the dev branch!
OK, will check with that. BTW, git.kernel.org is kind of broken for me
very often those days, as almost all my tests got this,
+ git clone http://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git -b dev
Cloning into 'ext4'...
fatal: The remote end hung up unexpectedly
fatal: recursion detected in die handler

Therefore, it is going to take a while to re-try later as the test systems
here always do testing from a clean environment, i.e., re-install OS, and
then re-clone the tree etc. :\
CAI Qian
> 
> - Ted
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] f2fs: add REQ_META about metadata requests for submit bio

[Namjae Jeon]

2013/4/22, Jaegeuk Kim :
> 2013-04-20 (토), 01:27 +0900, Namjae Jeon:
>> From: Namjae Jeon 
>>
>> Adding REQ_META for all the metadata requests can help in improving the
>> FS performance, if the underlying device supports TAGGING.
>> So, when considering the submit_bio path for all the f2fs requests. We
>> can
>> add REQ_META for all the META requests.
>> As a precursor to this change we considered the commit
>> 4265900e0be653f5b78baf2816857ef57cf1332f 'mmc: MMC-4.5 Data Tag Support'
>>
>> Signed-off-by: Namjae Jeon 
>> Signed-off-by: Amit Sahrawat 
>> ---
>>  fs/f2fs/segment.c |3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
>> index 1193a26..a2e5de7 100644
>> --- a/fs/f2fs/segment.c
>> +++ b/fs/f2fs/segment.c
>> @@ -689,6 +689,9 @@ static void do_submit_bio(struct f2fs_sb_info *sbi,
>>  if (type >= META_FLUSH)
>>  rw = WRITE_FLUSH_FUA;
>>
>> +if (type == META)
>
> Should be if (btype == META).
> Thanks,
Yes, Right :)
Thanks for fixing.
>
>> +rw |= REQ_META;
>> +
>>  if (sbi->bio[btype]) {
>>  struct bio_private *p = sbi->bio[btype]->bi_private;
>>  trace_f2fs_do_submit_bio(sbi->sb, btype, sync,
>
> --
> Jaegeuk Kim
> Samsung
>
--
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: build failure after merge of the net-next tree

[Stephen Rothwell]

Hi all,

After merging the net-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/net/ethernet/ibm/ehea/ehea_main.c: In function 'ehea_proc_rwqes':
drivers/net/ethernet/ibm/ehea/ehea_main.c:728:5: error: too few arguments to 
function '__vlan_hwaccel_put_tag'
include/linux/if_vlan.h:237:31: note: declared here

Caused by commit 86a9bad3ab6b ("net: vlan: add protocol argument to
packet tagging functions").  Grep is your friend.  :-(

drivers/net/ethernet/ibm/ehea/ehea_main.c: In function 'ehea_setup_single_port':
drivers/net/ethernet/ibm/ehea/ehea_main.c:3027:9: error: expected expression 
before '|' token

Caused by commit f646968f8f7c ("net: vlan: rename NETIF_F_HW_VLAN_*
feature flags to NETIF_F_HW_VLAN_CTAG_*").

I have used the net-net tree from next-20130419 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpIkYVh2on4e.pgp
Description: PGP signature

Re: [PATCH v2 06/15] powerpc/85xx: add support to JOG feature using cpufreq interface

[Viresh Kumar]

On Fri, Apr 19, 2013 at 4:17 PM, Zhao Chenhui
 wrote:
> diff --git a/drivers/cpufreq/mpc85xx-cpufreq.c 
> b/drivers/cpufreq/mpc85xx-cpufreq.c

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Would be better to keep them in alphabetical order, so that we don't add
anything twice.

> +static int mpc85xx_cpufreq_cpu_init(struct cpufreq_policy *policy)
> +{
> +   unsigned int i, cur_pll;
> +   int hw_cpu = get_hard_smp_processor_id(policy->cpu);
> +
> +   if (!cpu_present(policy->cpu))

This can't happen and so no need to check it.

> +   return -ENODEV;
> +
> +   /* the latency of a transition, the unit is ns */
> +   policy->cpuinfo.transition_latency = 2000;
> +
> +   cur_pll = get_pll(hw_cpu);
> +
> +   /* initialize frequency table */
> +   pr_debug("core%d frequency table:\n", hw_cpu);
> +   for (i = 0; mpc85xx_freqs[i].frequency != CPUFREQ_TABLE_END; i++) {
> +   if (mpc85xx_freqs[i].index <= max_pll[hw_cpu]) {
> +   /* The frequency unit is kHz. */
> +   mpc85xx_freqs[i].frequency =
> +   (sysfreq * mpc85xx_freqs[i].index / 2) / 1000;
> +   } else {
> +   mpc85xx_freqs[i].frequency = CPUFREQ_ENTRY_INVALID;
> +   }
> +
> +   pr_debug("%d: %dkHz\n", i, mpc85xx_freqs[i].frequency);
> +
> +   if (mpc85xx_freqs[i].index == cur_pll)
> +   policy->cur = mpc85xx_freqs[i].frequency;
> +   }
> +   pr_debug("current pll is at %d, and core freq is%d\n",
> +   cur_pll, policy->cur);
> +
> +   cpufreq_frequency_table_get_attr(mpc85xx_freqs, policy->cpu);
> +
> +   /*
> +* This ensures that policy->cpuinfo_min
> +* and policy->cpuinfo_max are set correctly.
> +*/
> +   return cpufreq_frequency_table_cpuinfo(policy, mpc85xx_freqs);

Call cpufreq_frequency_table_get_attr() at the end after above call is
successful.

> +}

> +static int mpc85xx_cpufreq_target(struct cpufreq_policy *policy,
> + unsigned int target_freq,
> + unsigned int relation)

merge above two lines.

> +{
> +   struct cpufreq_freqs freqs;
> +   unsigned int new;
> +   int ret = 0;
> +
> +   if (!set_pll)
> +   return -ENODEV;
> +
> +   cpufreq_frequency_table_target(policy,
> +  mpc85xx_freqs,
> +  target_freq,
> +  relation,
> +  &new);

same.. merge all above to put it in a single line.

> +   freqs.old = policy->cur;
> +   freqs.new = mpc85xx_freqs[new].frequency;
> +   freqs.cpu = policy->cpu;

not required now.

> +   mutex_lock(&mpc85xx_switch_mutex);
> +   cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);

ditto. Rebase over latest code from linux-next. This call has changed.

> +   ret = set_pll(policy->cpu, mpc85xx_freqs[new].index);
> +   if (!ret) {
> +   pr_info("cpufreq: Setting core%d frequency to %d kHz and PLL 
> ratio to %d:2\n",
> +policy->cpu, mpc85xx_freqs[new].frequency,
> +mpc85xx_freqs[new].index);
> +
> +   ppc_proc_freq = freqs.new * 1000ul;
> +   }
> +   cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
> +   mutex_unlock(&mpc85xx_switch_mutex);
> +
> +   return ret;
> +}

> +static int __init mpc85xx_jog_init(void)
> +{
> +   struct device_node *np;
> +   unsigned int svr;
> +
> +   np = of_find_matching_node(NULL, mpc85xx_jog_ids);
> +   if (!np)
> +   return -ENODEV;
> +
> +   guts = of_iomap(np, 0);
> +   if (!guts) {
> +   of_node_put(np);
> +   return -ENODEV;
> +   }
> +
> +   sysfreq = fsl_get_sys_freq();
> +
> +   if (of_device_is_compatible(np, "fsl,mpc8536-guts")) {
> +   svr = mfspr(SPRN_SVR);
> +   if ((svr & 0x7fff) == 0x10) {
> +   pr_err("MPC8536 Rev 1.0 does not support 
> cpufreq(JOG).\n");
> +   of_node_put(np);

unmap too??

> +   return -ENODEV;
> +   }
> +   mpc85xx_freqs = mpc8536_freqs_table;
> +   set_pll = mpc8536_set_pll;
> +   max_pll[0] = get_pll(0);
> +
> +   } else if (of_device_is_compatible(np, "fsl,p1022-guts")) {
> +   mpc85xx_freqs = p1022_freqs_table;
> +   set_pll = p1022_set_pll;
> +   max_pll[0] = get_pll(0);
> +   max_pll[1] = get_pll(1);
> +   }
> +
> +   pr_info("Freescale MPC85xx cpufreq(JOG) driver\n");
> +
> +   of_node_put(np);
> +   return cpufreq_register_driver(&mpc85xx_cpufreq_driver);
> +}
> +
> +device_initcall(mpc85xx_jog_in

Re: OOM-killer and strange RSS value in 3.9-rc7

[Han Pingtian]

On Sun, Apr 21, 2013 at 02:49:31AM +0200, Jiri Kosina wrote:
> On Wed, 17 Apr 2013, Han Pingtian wrote:
> 
> > > > On a power7 system, we have installed 3.9-rc7 and crash 6.1.6. If I run
> > > > something like "make -j 64" to compile linux kernel from source, sooner
> > > > or latter, oom-killer will be triggered. Before that, when I trying to
> > > > analyse the live system with crash, some processes' %MEM and RSS looks
> > > > too big:
> > > > 
> > > 
> > > Do you have the oom killer log from /var/log/messages with 
> > > /proc/sys/vm/oom_dump_tasks enabled?  Have you tried to reproduce this 
> > > issue with CONFIG_DEBUG_VM and CONFIG_DEBUG_PAGEALLOC enabled (you may 
> > > even want to consider CONFIG_KMEMLEAK)?
> > 
> > I have enabled CONFIG_KMEMLEAK and recompiled kernel. This is the
> > /sys/kernel/debug/kmemleak after the reboot. Please have a look. Thanks.
> 
> Either kmemleak is very wrong about some false positive in selinux, or 
> selinux is leaking memory quite heavily.
> 
> Could you try disabling selinux completely, to see if the leak goes away?
> 
Thanks your reply. We had disable selinux from the very beginning.

--
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: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Viresh Kumar]

On 22 April 2013 05:00, Rafael J. Wysocki  wrote:
> Applied to linux-pm.git/linux-next, although please check the result, because
> the patchwork version of the patch wasn't quite applicable and I fixed it up
> manually.

Yes it looks fine and that's why i have attached the patch with my
email earlier.
--
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: [PATCHv5 00/11] Remove ARM local timer API

[Barry Song]

> -Original Message-
> From: Stephen Boyd [mailto:sb...@codeaurora.org]
> Sent: Saturday, April 20, 2013 12:20 AM
> To: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org; linux-arm-...@vger.kernel.org; Mark
> Rutland; Marc Zyngier; Kukjin Kim; Barry Song; Daniel Walker; Bryan Huntsman;
> Tony Lindgren; John Stultz; Thomas Gleixner; Thomas Abraham
> Subject: [PATCHv5 00/11] Remove ARM local timer API
> 
> In light of Mark Rutland's recent work on divorcing the ARM architected
> timers from the ARM local timer API and introducing a generic arch hook for
> broadcast it seems that we should remove the local timer API entirely.
> Doing so will reduce the architecture dependencies of our timer drivers,
> reduce code in ARM core, and simplify timer drivers because they no longer
> go through an architecture layer that is essentially a hotplug notifier.
> 
> Previous attempts have been made[1] unsuccessfully. I'm hoping this can
> be accepted now so that we can clean up the timer drivers that are
> used in both UP and SMP situations. Right now these drivers have to ignore
> the timer setup callback on the boot CPU to avoid registering clockevents
> twice. This is not very symmetric and causes convuluted code that does
> the same thing in two places.
> 
> Patches based on next-20130418
> 
> I'm still looking for Acks/Tested-by on EXYNOS and PRIMA2.

Stephen, I hope I can give a test soon. But I have some others in higher 
priority now.

> [1] http://article.gmane.org/gmane.linux.ports.arm.kernel/145705

-barry


Member of the CSR plc group of companies. CSR plc registered in England and 
Wales, registered number 4187346, registered office Churchill House, Cambridge 
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at 
http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [RFC] arm64: Early printk support for virtio-mmio console devices.

[Anup Patel]

On 22 April 2013 06:51, Rusty Russell  wrote:
>
> Pranavkumar Sawargaonkar  writes:
> > On 18 April 2013 12:21, Rusty Russell  wrote:
> >>
> >> PranavkumarSawargaonkar  writes:
> >> > From: Pranavkumar Sawargaonkar 
> >> >
> >> > This patch implements early printk support for virtio-mmio console
> >> > devices without using any hypercalls.
> >>
> >> This makes some sense, though not sure that early console *read* makes
> >> much sense.  I can see the PCI version of this being useful as well.
> >
> > Read can be useful for "mach-virt" which will have only virtio console
> > as a console device. Then if someone wants to have UEFI or any other
> > boot-loader emulation, which expects user to input few things, in that
> > case read might become handy.
>
> But implementing virtio inside a bootloader has already been done for
> coreboot, for example.  A bootloader probably wants a virtio block
> device, so a console is trivial.
>
> A single writable field for debugging makes sense.  Anything more is far
> less certain.

The early read can be handy for bootloader who don't want to implement
complete VirtIO programming.

IMHO, early read would be totally optional for host and will not
introduce any new config register so it is good to have in VirtIO
console spec. Also, without early read the read behavior of early_rw
field would be undefined in VirtIO console spec.

>
> Thanks,
> Rusty.

Best Regards,
Anup
--
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 net-next tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
include/net/scm.h between commit 83f1b4ba917d ("net: fix incorrect
credentials passing") from Linus' tree and commit 6b0ee8c036ec ("scm:
Stop passing struct cred") from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).  I also applied the following merge fix patch (I am not
sure if this is correct, but it seems to be consistent):

From: Stephen Rothwell 
Date: Mon, 22 Apr 2013 13:06:10 +1000
Subject: [PATCH] net: af_unix fix for incorrect credentials passing

Signed-off-by: Stephen Rothwell 
---
 net/unix/af_unix.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 5ca1631..9efe011 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1414,7 +1414,7 @@ static void maybe_add_creds(struct sk_buff *skb, const 
struct socket *sock,
!other->sk_socket ||
test_bit(SOCK_PASSCRED, &other->sk_socket->flags)) {
UNIXCB(skb).pid  = get_pid(task_tgid(current));
-   current_euid_egid(&UNIXCB(skb).uid, &UNIXCB(skb).gid);
+   current_uid_gid(&UNIXCB(skb).uid, &UNIXCB(skb).gid);
}
 }
 
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc include/net/scm.h
index b117081,5a4c6a9..000
--- a/include/net/scm.h
+++ b/include/net/scm.h
@@@ -81,8 -75,10 +75,10 @@@ static __inline__ int scm_send(struct s
   struct scm_cookie *scm, bool forcecreds)
  {
memset(scm, 0, sizeof(*scm));
+   scm->creds.uid = INVALID_UID;
+   scm->creds.gid = INVALID_GID;
if (forcecreds)
-   scm_set_cred(scm, task_tgid(current), current_cred());
 -  scm_set_cred(scm, task_tgid(current), current_euid(), 
current_egid());
++  scm_set_cred(scm, task_tgid(current), current_uid(), 
current_gid());
unix_get_peersec_dgram(sock, scm);
if (msg->msg_controllen <= 0)
return 0;


pgpuUEqxoCit5.pgp
Description: PGP signature

linux-next: manual merge of the net-next tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/ipv4/tcp_input.c between commit 12fb3dd9dc3c ("tcp: call
tcp_replace_ts_recent() from tcp_ack()") from Linus' tree and commit
9b717a8d2450 ("tcp: TLP loss detection") from the net-next 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 net/ipv4/tcp_input.c
index 13b9c08,6d9ca35..000
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@@ -108,12 -107,10 +107,11 @@@ int sysctl_tcp_early_retrans __read_mos
  #define FLAG_DATA_SACKED  0x20 /* New SACK.   
*/
  #define FLAG_ECE  0x40 /* ECE in this ACK 
*/
  #define FLAG_SLOWPATH 0x100 /* Do not skip RFC checks for window 
update.*/
- #define FLAG_ONLY_ORIG_SACKED 0x200 /* SACKs only non-rexmit sent before RTO 
*/
+ #define FLAG_ORIG_SACK_ACKED  0x200 /* Never retransmitted data are (s)acked  
*/
  #define FLAG_SND_UNA_ADVANCED 0x400 /* Snd_una was changed (!= 
FLAG_DATA_ACKED) */
  #define FLAG_DSACKING_ACK 0x800 /* SACK blocks contained D-SACK info */
- #define FLAG_NONHEAD_RETRANS_ACKED0x1000 /* Non-head rexmitted data was 
ACKed */
  #define FLAG_SACK_RENEGING0x2000 /* snd_una advanced to a sacked seq */
 +#define FLAG_UPDATE_TS_RECENT 0x4000 /* tcp_replace_ts_recent() */
  
  #define FLAG_ACKED(FLAG_DATA_ACKED|FLAG_SYN_ACKED)
  #define FLAG_NOT_DUP  (FLAG_DATA|FLAG_WIN_UPDATE|FLAG_ACKED)
@@@ -3565,27 -3265,38 +3266,59 @@@ static void tcp_send_challenge_ack(stru
}
  }
  
 +static void tcp_store_ts_recent(struct tcp_sock *tp)
 +{
 +  tp->rx_opt.ts_recent = tp->rx_opt.rcv_tsval;
 +  tp->rx_opt.ts_recent_stamp = get_seconds();
 +}
 +
 +static void tcp_replace_ts_recent(struct tcp_sock *tp, u32 seq)
 +{
 +  if (tp->rx_opt.saw_tstamp && !after(seq, tp->rcv_wup)) {
 +  /* PAWS bug workaround wrt. ACK frames, the PAWS discard
 +   * extra check below makes sure this can only happen
 +   * for pure ACK frames.  -DaveM
 +   *
 +   * Not only, also it occurs for expired timestamps.
 +   */
 +
 +  if (tcp_paws_check(&tp->rx_opt, 0))
 +  tcp_store_ts_recent(tp);
 +  }
 +}
 +
+ /* This routine deals with acks during a TLP episode.
+  * Ref: loss detection algorithm in draft-dukkipati-tcpm-tcp-loss-probe.
+  */
+ static void tcp_process_tlp_ack(struct sock *sk, u32 ack, int flag)
+ {
+   struct tcp_sock *tp = tcp_sk(sk);
+   bool is_tlp_dupack = (ack == tp->tlp_high_seq) &&
+!(flag & (FLAG_SND_UNA_ADVANCED |
+  FLAG_NOT_DUP | FLAG_DATA_SACKED));
+ 
+   /* Mark the end of TLP episode on receiving TLP dupack or when
+* ack is after tlp_high_seq.
+*/
+   if (is_tlp_dupack) {
+   tp->tlp_high_seq = 0;
+   return;
+   }
+ 
+   if (after(ack, tp->tlp_high_seq)) {
+   tp->tlp_high_seq = 0;
+   /* Don't reduce cwnd if DSACK arrives for TLP retrans. */
+   if (!(flag & FLAG_DSACKING_ACK)) {
+   tcp_init_cwnd_reduction(sk, true);
+   tcp_set_ca_state(sk, TCP_CA_CWR);
+   tcp_end_cwnd_reduction(sk);
+   tcp_set_ca_state(sk, TCP_CA_Open);
+   NET_INC_STATS_BH(sock_net(sk),
+LINUX_MIB_TCPLOSSPROBERECOVERY);
+   }
+   }
+ }
+ 
  /* This routine deals with incoming acks, but not outgoing ones. */
  static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
  {


pgpK8cX9FlQK0.pgp
Description: PGP signature

PCB Solid Carbide Drills and Routers from China

[Archer]

Dear Manager,

We are a professional producer of tungsten carbide cutters.  Our products 
include standard solid PCB drills (dia 3.20mm-6.50mm) and special PCB drills 
with chip-removal groove and reground chisel edge (dia 1.5mm-6.5mm). 

By adopting a world famous brand of micro-grain tungsten carbide as the raw 
material and using internationally advanced coating equipment, our products are 
offered at a good price with long service life, high durability and precise 
concentricity. Our stable product quality and responsive after-sales services 
have won us good fame in this circle. 

Our products are widely recognized and extensively purchased by world-known PCB 
manufacturing groups and OEM factories like WUS Printed Circuit, Tripod (WUXI) 
Electronic, COMPEQ Manufacturing, etc. Meanwhile we also enjoy a stable market 
share in oversea markets including the U.S., Germany, Korea, Singapore, 
Thailand, Taiwan and Hong Kong of China.

You are welcome to call us for more details on cooperation and others.

--
Archer Hu
arc...@wilsonprecisiontool.com
Shanghai Well-Sun Precision Tool Co., Ltd
Add: No. 3 Building, No. 868 Zhenchen Rd, Baoshan District, Shanghai
Tel:021-36162006
Tex:021-36162016
Website: www.well-sun.net

Re: [PATCH v3 00/15] KVM: MMU: fast zap all shadow pages

[Xiao Guangrong]

On 04/21/2013 11:24 PM, Marcelo Tosatti wrote:
> On Sun, Apr 21, 2013 at 10:09:29PM +0800, Xiao Guangrong wrote:
>> On 04/21/2013 09:03 PM, Gleb Natapov wrote:
>>> On Tue, Apr 16, 2013 at 02:32:38PM +0800, Xiao Guangrong wrote:
 This patchset is based on my previous two patchset:
 [PATCH 0/2] KVM: x86: avoid potential soft lockup and unneeded mmu reload
 (https://lkml.org/lkml/2013/4/1/2)

 [PATCH v2 0/6] KVM: MMU: fast invalid all mmio sptes
 (https://lkml.org/lkml/2013/4/1/134)

 Changlog:
 V3:
   completely redesign the algorithm, please see below.

>>> This looks pretty complicated. Is it still needed in order to avoid soft
>>> lockups after "avoid potential soft lockup and unneeded mmu reload" patch?
>>
>> Yes.
>>
>> I discussed this point with Marcelo:
>>
>> ==
>> BTW, to my honest, i do not think spin_needbreak is a good way - it does
>> not fix the hot-lock contention and it just occupies more cpu time to avoid
>> possible soft lock-ups.
>>
>> Especially, zap-all-shadow-pages can let other vcpus fault and vcpus contest
>> mmu-lock, then zap-all-shadow-pages release mmu-lock and wait, other vcpus
>> create page tables again. zap-all-shadow-page need long time to be finished,
>> the worst case is, it can not completed forever on intensive vcpu and memory
>> usage.
>>
>> I still think the right way to fix this kind of thing is optimization for
>> mmu-lock.
>> ==
>>
>> Which parts scare you? Let's find a way to optimize for it. ;). For example,
>> if you do not like unmap_memslot_rmap_nolock(), we can simplify it - We can
>> use walk_shadow_page_lockless_begin() and walk_shadow_page_lockless_end() to
>> protect spte instead of kvm->being_unmaped_rmap.
>>
>> Thanks!
> 
> Xiao,
> 
> You can just remove all shadow rmaps now that you've agreed per-memslot
> flushes are not necessary. Which then gets rid of necessity for lockless 
> rmap accesses. Right?

Hi Marcelo,

I am worried about:

==
We can not release all rmaps. If we do this, ->invalidate_page and
->invalidate_range_start can not find any spte using the host page,
that means, Accessed/Dirty for host page is missing tracked.
(missing call kvm_set_pfn_accessed and kvm_set_pfn_dirty properly.)

[https://lkml.org/lkml/2013/4/18/358]
==

Do you think this is a issue? What's your idea?

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 2/2] f2fs: add REQ_META about metadata requests for submit bio

[Jaegeuk Kim]

2013-04-20 (토), 01:27 +0900, Namjae Jeon:
> From: Namjae Jeon 
> 
> Adding REQ_META for all the metadata requests can help in improving the
> FS performance, if the underlying device supports TAGGING.
> So, when considering the submit_bio path for all the f2fs requests. We can
> add REQ_META for all the META requests.
> As a precursor to this change we considered the commit
> 4265900e0be653f5b78baf2816857ef57cf1332f 'mmc: MMC-4.5 Data Tag Support'
> 
> Signed-off-by: Namjae Jeon 
> Signed-off-by: Amit Sahrawat 
> ---
>  fs/f2fs/segment.c |3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index 1193a26..a2e5de7 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -689,6 +689,9 @@ static void do_submit_bio(struct f2fs_sb_info *sbi,
>   if (type >= META_FLUSH)
>   rw = WRITE_FLUSH_FUA;
>  
> + if (type == META)

Should be if (btype == META).
Thanks,

> + rw |= REQ_META;
> +
>   if (sbi->bio[btype]) {
>   struct bio_private *p = sbi->bio[btype]->bi_private;
>   trace_f2fs_do_submit_bio(sbi->sb, btype, sync,

-- 
Jaegeuk Kim
Samsung


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

Re: [PATCH V3 1/5] powerpc, perf: Add new BHRB related instructions for POWER8

[Michael Neuling]

Michael Ellerman  wrote:

> On Mon, Apr 22, 2013 at 11:13:43AM +1000, Michael Neuling wrote:
> > Michael Ellerman  wrote:
> > 
> > > On Thu, Apr 18, 2013 at 05:56:12PM +0530, Anshuman Khandual wrote:
> > > > This patch adds new POWER8 instruction encoding for reading
> > > > the BHRB buffer entries and also clearing it. Encoding for
> > > > "clrbhrb" instruction is straight forward.
> > > 
> > > Which is "clear branch history rolling buffer" ?
> > > 
> > > > But "mfbhrbe"
> > > > encoding involves reading a certain index of BHRB buffer
> > > > into a particular GPR register.
> > > 
> > > And "Move from branch history rolling buffer entry" ?
> > > 
> > > > diff --git a/arch/powerpc/include/asm/ppc-opcode.h 
> > > > b/arch/powerpc/include/asm/ppc-opcode.h
> > > > index 8752bc8..93ae5a1 100644
> > > > --- a/arch/powerpc/include/asm/ppc-opcode.h
> > > > +++ b/arch/powerpc/include/asm/ppc-opcode.h
> > > > @@ -82,6 +82,7 @@
> > > >  #define__REGA0_R31 31
> > > >  
> > > >  /* sorted alphabetically */
> > > > +#define PPC_INST_BHRBE 0x7c00025c
> > > 
> > > I don't think you really need this, just use the literal value below.
> > 
> > The rest of the defines in this file do this, so Anshuman's right. 
> 
> I don't see the point, but sure let's be consistent. Though in that case
> he should do the same for PPC_CLRBHRB below.

Agreed.

Mikey

> 
> > > > @@ -297,6 +298,12 @@
> > > >  #define PPC_NAPstringify_in_c(.long 
> > > > PPC_INST_NAP)
> > > >  #define PPC_SLEEP  stringify_in_c(.long PPC_INST_SLEEP)
> > > >  
> > > > +/* BHRB instructions */
> > > > +#define PPC_CLRBHRBstringify_in_c(.long 0x7c00035c)
> > > > +#define PPC_MFBHRBE(r, n)  stringify_in_c(.long PPC_INST_BHRBE | \
> > > > +   __PPC_RS(r) | \
> > > > +   (((n) & 0x1f) 
> > > > << 11))
> > > 
> > > Why are you not using ___PPC_RB(n) here ?
> > 
> > Actually, this is wrong.  The number field should be 10 bits (0x3ff),
> > not 5 (0x1f)  Anshuman please fix.
> 
> ACK.
> 
> cheers
> 
--
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 net-next tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/intel/igb/igb_main.c between commit f9d40f6a9921
("igb: Revert support for build_skb in igb") from Linus' tree and commit
b980ac18c95f ("igb: Fix code comments and whitespace") from the net-next
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/net/ethernet/intel/igb/igb_main.c
index 64f7529,9bf08b9..000
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@@ -3350,11 -3387,25 +3387,11 @@@ void igb_configure_rx_ring(struct igb_a
wr32(E1000_RXDCTL(reg_idx), rxdctl);
  }
  
 -static void igb_set_rx_buffer_len(struct igb_adapter *adapter,
 -struct igb_ring *rx_ring)
 -{
 -#define IGB_MAX_BUILD_SKB_SIZE \
 -  (SKB_WITH_OVERHEAD(IGB_RX_BUFSZ) - \
 -   (NET_SKB_PAD + NET_IP_ALIGN + IGB_TS_HDR_LEN))
 -
 -  /* set build_skb flag */
 -  if (adapter->max_frame_size <= IGB_MAX_BUILD_SKB_SIZE)
 -  set_ring_build_skb_enabled(rx_ring);
 -  else
 -  clear_ring_build_skb_enabled(rx_ring);
 -}
 -
  /**
-  * igb_configure_rx - Configure receive Unit after Reset
-  * @adapter: board private structure
+  *  igb_configure_rx - Configure receive Unit after Reset
+  *  @adapter: board private structure
   *
-  * Configure the Rx unit of the MAC after a reset.
+  *  Configure the Rx unit of the MAC after a reset.
   **/
  static void igb_configure_rx(struct igb_adapter *adapter)
  {
@@@ -3365,12 -3416,16 +3402,13 @@@
  
/* set the correct pool for the PF default MAC address in entry 0 */
igb_rar_set_qsel(adapter, adapter->hw.mac.addr, 0,
-adapter->vfs_allocated_count);
+adapter->vfs_allocated_count);
  
/* Setup the HW Rx Head and Tail Descriptor Pointers and
-* the Base and Length of the Rx Descriptor Ring */
+* the Base and Length of the Rx Descriptor Ring
+*/
 -  for (i = 0; i < adapter->num_rx_queues; i++) {
 -  struct igb_ring *rx_ring = adapter->rx_ring[i];
 -  igb_set_rx_buffer_len(adapter, rx_ring);
 -  igb_configure_rx_ring(adapter, rx_ring);
 -  }
 +  for (i = 0; i < adapter->num_rx_queues; i++)
 +  igb_configure_rx_ring(adapter, adapter->rx_ring[i]);
  }
  
  /**
@@@ -6688,9 -6808,17 +6716,9 @@@ static bool igb_alloc_mapped_page(struc
return true;
  }
  
 -static inline unsigned int igb_rx_offset(struct igb_ring *rx_ring)
 -{
 -  if (ring_uses_build_skb(rx_ring))
 -  return NET_SKB_PAD + NET_IP_ALIGN;
 -  else
 -  return 0;
 -}
 -
  /**
-  * igb_alloc_rx_buffers - Replace used receive buffers; packet split
-  * @adapter: address of board private structure
+  *  igb_alloc_rx_buffers - Replace used receive buffers; packet split
+  *  @adapter: address of board private structure
   **/
  void igb_alloc_rx_buffers(struct igb_ring *rx_ring, u16 cleaned_count)
  {
@@@ -6710,11 -6838,12 +6738,10 @@@
if (!igb_alloc_mapped_page(rx_ring, bi))
break;
  
-   /*
-* Refresh the desc even if buffer_addrs didn't change
+   /* Refresh the desc even if buffer_addrs didn't change
 * because each write-back erases this info.
 */
 -  rx_desc->read.pkt_addr = cpu_to_le64(bi->dma +
 -   bi->page_offset +
 -   igb_rx_offset(rx_ring));
 +  rx_desc->read.pkt_addr = cpu_to_le64(bi->dma + bi->page_offset);
  
rx_desc++;
bi++;


pgpi0easM5F4d.pgp
Description: PGP signature

Re: [PATCH V3 1/5] powerpc, perf: Add new BHRB related instructions for POWER8

[Michael Ellerman]

On Mon, Apr 22, 2013 at 11:13:43AM +1000, Michael Neuling wrote:
> Michael Ellerman  wrote:
> 
> > On Thu, Apr 18, 2013 at 05:56:12PM +0530, Anshuman Khandual wrote:
> > > This patch adds new POWER8 instruction encoding for reading
> > > the BHRB buffer entries and also clearing it. Encoding for
> > > "clrbhrb" instruction is straight forward.
> > 
> > Which is "clear branch history rolling buffer" ?
> > 
> > > But "mfbhrbe"
> > > encoding involves reading a certain index of BHRB buffer
> > > into a particular GPR register.
> > 
> > And "Move from branch history rolling buffer entry" ?
> > 
> > > diff --git a/arch/powerpc/include/asm/ppc-opcode.h 
> > > b/arch/powerpc/include/asm/ppc-opcode.h
> > > index 8752bc8..93ae5a1 100644
> > > --- a/arch/powerpc/include/asm/ppc-opcode.h
> > > +++ b/arch/powerpc/include/asm/ppc-opcode.h
> > > @@ -82,6 +82,7 @@
> > >  #define  __REGA0_R31 31
> > >  
> > >  /* sorted alphabetically */
> > > +#define PPC_INST_BHRBE   0x7c00025c
> > 
> > I don't think you really need this, just use the literal value below.
> 
> The rest of the defines in this file do this, so Anshuman's right. 

I don't see the point, but sure let's be consistent. Though in that case
he should do the same for PPC_CLRBHRB below.

> > > @@ -297,6 +298,12 @@
> > >  #define PPC_NAP  stringify_in_c(.long PPC_INST_NAP)
> > >  #define PPC_SLEEPstringify_in_c(.long PPC_INST_SLEEP)
> > >  
> > > +/* BHRB instructions */
> > > +#define PPC_CLRBHRB  stringify_in_c(.long 0x7c00035c)
> > > +#define PPC_MFBHRBE(r, n)stringify_in_c(.long PPC_INST_BHRBE | \
> > > + __PPC_RS(r) | \
> > > + (((n) & 0x1f) << 11))
> > 
> > Why are you not using ___PPC_RB(n) here ?
> 
> Actually, this is wrong.  The number field should be 10 bits (0x3ff),
> not 5 (0x1f)  Anshuman please fix.

ACK.

cheers
--
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 net-next tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/emulex/benet/be_main.c between commit f11a869d4e38
("be2net: take care of __vlan_put_tag return value") from Linus' tree and
commit 86a9bad3ab6b ("net: vlan: add protocol argument to packet tagging
functions") from the net-next 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/net/ethernet/emulex/benet/be_main.c
index 2886c9b,811d0a4..000
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@@ -759,9 -771,8 +771,9 @@@ static struct sk_buff *be_insert_vlan_i
  
if (vlan_tx_tag_present(skb)) {
vlan_tag = be_get_tx_vlan_tag(adapter, skb);
-   skb = __vlan_put_tag(skb, vlan_tag);
 -  __vlan_put_tag(skb, htons(ETH_P_8021Q), vlan_tag);
 -  skb->vlan_tci = 0;
++  skb = __vlan_put_tag(skb, htons(ETH_P_8021Q), vlan_tag);
 +  if (skb)
 +  skb->vlan_tci = 0;
}
  
return skb;


pgpPZoyDbkLDI.pgp
Description: PGP signature

Re: [PATCH 00/30] thermal: cpu_cooling: code improvements

[amit daniel kachhap]

Hi Eduardo,

I looked at your whole series and they certainly looks useful, so for
the entire series,
Acked-by: Amit Daniel Kachhap 

Thanks,
Amit Daniel Kachhap

On Thu, Apr 18, 2013 at 2:02 AM, Eduardo Valentin
 wrote:
> On 17-04-2013 13:11, Eduardo Valentin wrote:
>>
>> Rui,
>
>
>
> Looks like I forgot to add the lists on patch 00. Doing so..
>>
>>
>> This is a series of patches to improve the code for cpu_cooling.
>> Majority of these changes are actually kernel-doc updates, as
>> they required to be revised. A part from these, there are some
>> changes regarding code style and readiness.
>>
>> Some may complain that these are a matter of taste, indeed.
>> But I tried to just be unbiased and just keep the changes related
>> to kernel-doc and checkpatch.pl. After this series, theses
>> tools should be generating decent output ;-).
>>
>> The remaining changes are actually a couple of fixes for defensive
>> coding. A part from updating the MAINTAINERS entry to cover cpu_cooling.
>>
>> This series has been tested on TI OMAP4430, together with the
>> thermal driver under staging tree.
>>
>> All these patches are based on current linux-next/master.
>>
>> They are also available here:
>>
>> All best,
>>
>> Eduardo Valentin (30):
>>thermal: cpu_cooling: remove unused headers
>>thermal: cpu_cooling: remove trailing white spaces
>>thermal: cpu_cooling: fix kernel_doc for cpufreq_cooling_device
>>thermal: cpu_cooling: use EXPORT_SYMBOL_GPL
>>thermal: cpu_cooling: remove compiler warning
>>thermal: cpu_cooling: standardize end of function
>>thermal: cpu_cooling: fix kernel doc for is_cpufreq_valid
>>thermal: cpu_cooling: add documentation for get_property
>>thermal: cpu_cooling: standardize comment style
>>thermal: cpu_cooling: align on open parenthesis
>>thermal: cpu_cooling: remove trailing blank line
>>thermal: cpu_cooling: document cpufreq_get_cooling_level
>>thermal: cpu_cooling: remove checkpatch.pl warning
>>thermal: cpu_cooling: improve documentation for get_cpu_frequency
>>thermal: cpu_cooling: update documentation for cpufreq_apply_cooling
>>thermal: cpu_cooling: update documentation for
>>  cpufreq_thermal_notifier
>>thermal: cpu_cooling: update Kconfig entry
>>thermal: cpu_cooling: alignment improvements
>>thermal: cpu_cooling: update documentation for cpufreq_get_max_state
>>thermal: cpu_cooling: update documentation for cpufreq_get_cur_state
>>thermal: cpu_cooling: update documentation for cpufreq_set_cur_state
>>thermal: cpu_cooling: update kernel-doc for cpufreq_cooling_register
>>thermal: cpu_cooling: update kernel-doc comment for
>>  cpufreq_cooling_unregister
>>thermal: cpu_cooling: use snprintf instead of sprintf
>>thermal: cpu_cooling: remove not needed curl brackets
>>thermal: cpu_cooling: remove unused symbols
>>thermal: cpu_cooling: add needed header for cpu_cooling.h
>>MAINTAINERS: update thermal entry by adding file cpu_cooling.h
>>thermal: cpu_cooling: remove unused symbols on cpu_cooling.h
>>thermal: cpu_cooling: improve line breaking
>>
>>   MAINTAINERS   |   1 +
>>   drivers/thermal/Kconfig   |   5 +-
>>   drivers/thermal/cpu_cooling.c | 156
>> ++
>>   include/linux/cpu_cooling.h   |  20 +++---
>>   4 files changed, 125 insertions(+), 57 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/
--
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: [NEW DRIVER V6 6/7] drivers/hwmon: DA9058 HWMON driver

[Guenter Roeck]

On Mon, Apr 22, 2013 at 01:14:26AM +, Opensource [Anthony Olech] wrote:
> > -Original Message-
> > From: Guenter Roeck [mailto:li...@roeck-us.net]
> > Sent: 20 April 2013 18:35
> > To: Lars-Peter Clausen
> > Cc: Opensource [Anthony Olech]; Jean Delvare; Mark Brown; Randy Dunlap;
> > lm-sens...@lm-sensors.org; LKML; David Dajun Chen
> > Subject: Re: [NEW DRIVER V6 6/7] drivers/hwmon: DA9058 HWMON driver
> > On Fri, Apr 19, 2013 at 08:25:02PM +0200, Lars-Peter Clausen wrote:
> > > Same comment as before, I'd like to see this using the generic IIO to
> > > HWMON bridge instead of recreating it.
> > ... and I agree. Seems we are getting more and more of those, and at some
> > point it makes really sense to find a generic solution.
> > Anthony, can you please look into that ?
> > Thanks,
> > Guenter
> 
> OK -- generic IIO to HWMON bridge
> 
> I will investigate - but if you know any prototypes or any useful starting 
> point could you let me know as I don't want to re-invent the wheel.
> 
The idea is that you would implement an IIO ADC driver (drivers/iio/adc has lots
of examples). The IIO to HWMON bridge already exists (drivers/hwmon/iio_hwmon.c
in linux-next or drivers/staging/iio/iio_hwmon.c in mainline). Setting it up
would then then a matter of platform data or device tree data.

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

RE: [RESEND][PATCH] ARM: PL011: add support for extended FIFO-size of PL011-r1p5

[Jongsung Kim]

Thank you for your comments, Russell. I'll happily apply your recommendation
just after it come up to the merge window. Or, do you want me to send it by now?

-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] 
Sent: Friday, April 19, 2013 11:18 PM
To: Jongsung Kim
Cc: gre...@linuxfoundation.org; jsl...@suse.cz; linux-ser...@vger.kernel.org;
linux-kernel@vger.kernel.org
Subject: Re: [RESEND][PATCH] ARM: PL011: add support for extended FIFO-size of
PL011-r1p5

On Mon, Apr 15, 2013 at 02:45:25PM +0900, Jongsung Kim wrote:
> The latest r1p5-revision of the ARM PL011 UART has 32-byte FIFOs,
> while all earlier ones have 16-byte FIFOs. This patch suggests
> a way to set the FIFO-size correctly & flexibly by using a member
> function named get_fifosize, rather than using the fifosize member
> variable. The function takes the UARTPeriphID, and returns the
> correct FIFO size.

Same comments as previous version.

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

Re: [PATCH 03/30] thermal: cpu_cooling: fix kernel_doc for cpufreq_cooling_device

[amit kachhap]

On Wed, Apr 17, 2013 at 10:41 PM, Eduardo Valentin
 wrote:
> Simple fixes for making kernel_doc happy about
> struct cpufreq_cooling_device. Includes also a minor
> spelling fix.
>
> Cc: Zhang Rui 
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin 

Reviewed-by: Amit Daniel Kachhap

Thanks,
Amit Daniel
> ---
>  drivers/thermal/cpu_cooling.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index d0d6a0c..7c0c05b 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -28,11 +28,11 @@
>  #include 
>
>  /**
> - * struct cpufreq_cooling_device
> + * struct cpufreq_cooling_device - data for cooling device with cpufreq
>   * @id: unique integer value corresponding to each cpufreq_cooling_device
>   * registered.
> - * @cool_dev: thermal_cooling_device pointer to keep track of the the
> - * egistered cooling device.
> + * @cool_dev: thermal_cooling_device pointer to keep track of the
> + * registered cooling device.
>   * @cpufreq_state: integer value representing the current state of cpufreq
>   * cooling devices.
>   * @cpufreq_val: integer value representing the absolute value of the clipped
> --
> 1.8.2.1.342.gfa7285d
>
> --
> 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: [PATCH 01/30] thermal: cpu_cooling: remove unused headers

[amit daniel kachhap]

Hi,

On Wed, Apr 17, 2013 at 10:41 PM, Eduardo Valentin
 wrote:
> As this code is not a module nor a platform device driver,
> this patch removes some unused header files.
>
> Cc: Zhang Rui 
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin 

Reviewed-by: Amit Daniel Kachhap

Thanks,
Amit Daniel
> ---
>  drivers/thermal/cpu_cooling.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 5f5c780..778c43d 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -20,10 +20,7 @@
>   *
>   * ~~
>   */
> -#include 
> -#include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> --
> 1.8.2.1.342.gfa7285d
>
> --
> 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 1/5] ibmebus: convert of_platform_driver to platform_driver

[Rob Herring]

From: Rob Herring 

ibmebus is the last remaining user of of_platform_driver and the
conversion to a regular platform driver is trivial.

Signed-off-by: Rob Herring 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Hoang-Nam Nguyen 
Cc: Christoph Raisch 
Cc: Roland Dreier 
Cc: Sean Hefty 
Cc: Hal Rosenstock 
Cc: Thadeu Lima de Souza Cascardo 
Cc: Grant Likely 
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-r...@vger.kernel.org
Cc: net...@vger.kernel.org
---
 arch/powerpc/include/asm/ibmebus.h|4 ++--
 arch/powerpc/kernel/ibmebus.c |   22 ++
 drivers/infiniband/hw/ehca/ehca_main.c|5 ++---
 drivers/net/ethernet/ibm/ehea/ehea_main.c |8 +++-
 4 files changed, 17 insertions(+), 22 deletions(-)

diff --git a/arch/powerpc/include/asm/ibmebus.h 
b/arch/powerpc/include/asm/ibmebus.h
index 1a9d9ae..088f95b 100644
--- a/arch/powerpc/include/asm/ibmebus.h
+++ b/arch/powerpc/include/asm/ibmebus.h
@@ -48,8 +48,8 @@
 
 extern struct bus_type ibmebus_bus_type;
 
-int ibmebus_register_driver(struct of_platform_driver *drv);
-void ibmebus_unregister_driver(struct of_platform_driver *drv);
+int ibmebus_register_driver(struct platform_driver *drv);
+void ibmebus_unregister_driver(struct platform_driver *drv);
 
 int ibmebus_request_irq(u32 ist, irq_handler_t handler,
unsigned long irq_flags, const char *devname,
diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
index 8220baa..16a7c23 100644
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -205,7 +205,7 @@ static int ibmebus_create_devices(const struct of_device_id 
*matches)
return ret;
 }
 
-int ibmebus_register_driver(struct of_platform_driver *drv)
+int ibmebus_register_driver(struct platform_driver *drv)
 {
/* If the driver uses devices that ibmebus doesn't know, add them */
ibmebus_create_devices(drv->driver.of_match_table);
@@ -215,7 +215,7 @@ int ibmebus_register_driver(struct of_platform_driver *drv)
 }
 EXPORT_SYMBOL(ibmebus_register_driver);
 
-void ibmebus_unregister_driver(struct of_platform_driver *drv)
+void ibmebus_unregister_driver(struct platform_driver *drv)
 {
driver_unregister(&drv->driver);
 }
@@ -338,11 +338,10 @@ static int ibmebus_bus_bus_match(struct device *dev, 
struct device_driver *drv)
 static int ibmebus_bus_device_probe(struct device *dev)
 {
int error = -ENODEV;
-   struct of_platform_driver *drv;
+   struct platform_driver *drv;
struct platform_device *of_dev;
-   const struct of_device_id *match;
 
-   drv = to_of_platform_driver(dev->driver);
+   drv = to_platform_driver(dev->driver);
of_dev = to_platform_device(dev);
 
if (!drv->probe)
@@ -350,9 +349,8 @@ static int ibmebus_bus_device_probe(struct device *dev)
 
of_dev_get(of_dev);
 
-   match = of_match_device(drv->driver.of_match_table, dev);
-   if (match)
-   error = drv->probe(of_dev, match);
+   if (of_driver_match_device(dev, dev->driver))
+   error = drv->probe(of_dev);
if (error)
of_dev_put(of_dev);
 
@@ -362,7 +360,7 @@ static int ibmebus_bus_device_probe(struct device *dev)
 static int ibmebus_bus_device_remove(struct device *dev)
 {
struct platform_device *of_dev = to_platform_device(dev);
-   struct of_platform_driver *drv = to_of_platform_driver(dev->driver);
+   struct platform_driver *drv = to_platform_driver(dev->driver);
 
if (dev->driver && drv->remove)
drv->remove(of_dev);
@@ -372,7 +370,7 @@ static int ibmebus_bus_device_remove(struct device *dev)
 static void ibmebus_bus_device_shutdown(struct device *dev)
 {
struct platform_device *of_dev = to_platform_device(dev);
-   struct of_platform_driver *drv = to_of_platform_driver(dev->driver);
+   struct platform_driver *drv = to_platform_driver(dev->driver);
 
if (dev->driver && drv->shutdown)
drv->shutdown(of_dev);
@@ -419,7 +417,7 @@ struct device_attribute ibmebus_bus_device_attrs[] = {
 static int ibmebus_bus_legacy_suspend(struct device *dev, pm_message_t mesg)
 {
struct platform_device *of_dev = to_platform_device(dev);
-   struct of_platform_driver *drv = to_of_platform_driver(dev->driver);
+   struct platform_driver *drv = to_platform_driver(dev->driver);
int ret = 0;
 
if (dev->driver && drv->suspend)
@@ -430,7 +428,7 @@ static int ibmebus_bus_legacy_suspend(struct device *dev, 
pm_message_t mesg)
 static int ibmebus_bus_legacy_resume(struct device *dev)
 {
struct platform_device *of_dev = to_platform_device(dev);
-   struct of_platform_driver *drv = to_of_platform_driver(dev->driver);
+   struct platform_driver *drv = to_platform_driver(dev->driver);
int ret = 0;
 
if (dev->driver && drv->resume)
diff --git a/drivers/infiniband/hw/ehca/ehca_main.c 
b/drivers/infiniband/hw/ehca/ehca_main.c
in

[PATCH 3/5] of: remove of_platform_driver

[Rob Herring]

From: Rob Herring 

The last user of of_platform_driver is converted to a regular
platform_driver, so of_platform_driver can be removed now.

Signed-off-by: Rob Herring 
Cc: Grant Likely 
---
 include/linux/of_platform.h |   21 -
 1 file changed, 21 deletions(-)

diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index 2a93b64..aa7eb02 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -53,27 +53,6 @@ struct of_dev_auxdata {
{ .compatible = _compat, .phys_addr = _phys, .name = _name, \
  .platform_data = _pdata }
 
-/**
- * of_platform_driver - Legacy of-aware driver for platform devices.
- *
- * An of_platform_driver driver is attached to a basic platform_device on
- * the ibm ebus (ibmebus_bus_type).
- */
-struct of_platform_driver
-{
-   int (*probe)(struct platform_device* dev,
-const struct of_device_id *match);
-   int (*remove)(struct platform_device* dev);
-
-   int (*suspend)(struct platform_device* dev, pm_message_t state);
-   int (*resume)(struct platform_device* dev);
-   int (*shutdown)(struct platform_device* dev);
-
-   struct device_driverdriver;
-};
-#defineto_of_platform_driver(drv) \
-   container_of(drv,struct of_platform_driver, driver)
-
 extern const struct of_device_id of_default_bus_match_table[];
 
 /* Platform drivers register/unregister */
-- 
1.7.10.4

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

[PATCH 2/5] driver core: move to_platform_driver to platform_device.h

[Rob Herring]

From: Rob Herring 

In converting the last remaining of_platform_driver (ibmebus) to a regular
platform driver, to_platform_driver is needed to replace
to_of_platform_driver.

Signed-off-by: Rob Herring 
Cc: Greg Kroah-Hartman 
Cc: Grant Likely 
---
 drivers/base/platform.c |3 ---
 include/linux/platform_device.h |3 +++
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index c0b8df3..819ecb0 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -29,9 +29,6 @@
 /* For automatically allocated device IDs */
 static DEFINE_IDA(platform_devid_ida);
 
-#define to_platform_driver(drv)(container_of((drv), struct 
platform_driver, \
-driver))
-
 struct device platform_bus = {
.init_name  = "platform",
 };
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index c082c71..6e4e096 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -176,6 +176,9 @@ struct platform_driver {
const struct platform_device_id *id_table;
 };
 
+#define to_platform_driver(drv)(container_of((drv), struct 
platform_driver, \
+driver))
+
 extern int platform_driver_register(struct platform_driver *);
 extern void platform_driver_unregister(struct platform_driver *);
 
-- 
1.7.10.4

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

[PATCH 0/5] of_platform_driver and OF_DEVICE removal

[Rob Herring]

From: Rob Herring 

This series is a relatively straight-forward removal of the last remaining
user of of_platform_driver (ibmebus) and removal of CONFIG_OF_DEVICE which
is always enabled when CONFIG_OF is enabled.

Compile tested on powerpc and sparc.

Rob

Rob Herring (5):
  ibmebus: convert of_platform_driver to platform_driver
  driver core: move to_platform_driver to platform_device.h
  of: remove of_platform_driver
  usb: chipidea: depend on CONFIG_OF instead of CONFIG_OF_DEVICE
  of: remove CONFIG_OF_DEVICE

 arch/powerpc/include/asm/ibmebus.h|4 ++--
 arch/powerpc/kernel/ibmebus.c |   22 ++---
 drivers/base/platform.c   |3 ---
 drivers/infiniband/hw/ehca/ehca_main.c|5 ++---
 drivers/net/ethernet/ibm/ehea/ehea_main.c |8 +++-
 drivers/of/Kconfig|3 ---
 drivers/of/Makefile   |3 +--
 drivers/usb/chipidea/Makefile |2 +-
 include/linux/of_device.h |6 +++---
 include/linux/of_platform.h   |   30 +
 include/linux/platform_device.h   |3 +++
 11 files changed, 26 insertions(+), 63 deletions(-)

-- 
1.7.10.4

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

[PATCH 4/5] usb: chipidea: depend on CONFIG_OF instead of CONFIG_OF_DEVICE

[Rob Herring]

From: Rob Herring 

CONFIG_OF_DEVICE is going away, so use CONFIG_OF instead. It does not
appear that CONFIG_OF_DEVICE was the correct dependency either.

Signed-off-by: Rob Herring 
Cc: Alexander Shishkin 
Cc: Greg Kroah-Hartman 
Cc: Grant Likely 
Cc: linux-...@vger.kernel.org
---
 drivers/usb/chipidea/Makefile |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index d92ca32..0895e3e 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -16,6 +16,6 @@ ifneq ($(CONFIG_PCI),)
obj-$(CONFIG_USB_CHIPIDEA)  += ci13xxx_pci.o
 endif
 
-ifneq ($(CONFIG_OF_DEVICE),)
+ifneq ($(CONFIG_OF),)
obj-$(CONFIG_USB_CHIPIDEA)  += ci13xxx_imx.o usbmisc_imx6q.o
 endif
-- 
1.7.10.4

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

[PATCH 5/5] of: remove CONFIG_OF_DEVICE

[Rob Herring]

From: Rob Herring 

CONFIG_OF_DEVICE is always selected when CONFIG_OF is enabled, so remove
it and simplify of_platform.h and of_device.h headers. This also fixes
!OF compiles using of_platform_populate.

Signed-off-by: Rob Herring 
Cc: Grant Likely 
---
 drivers/of/Kconfig  |3 ---
 drivers/of/Makefile |3 +--
 include/linux/of_device.h   |6 +++---
 include/linux/of_platform.h |9 +
 4 files changed, 5 insertions(+), 16 deletions(-)

diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index d37bfcf..80e5c13 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -48,9 +48,6 @@ config OF_IRQ
def_bool y
depends on !SPARC
 
-config OF_DEVICE
-   def_bool y
-
 config OF_I2C
def_tristate I2C
depends on I2C
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index e027f44..1f9c0c4 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -1,9 +1,8 @@
-obj-y = base.o
+obj-y = base.o device.o platform.o
 obj-$(CONFIG_OF_FLATTREE) += fdt.o
 obj-$(CONFIG_OF_PROMTREE) += pdt.o
 obj-$(CONFIG_OF_ADDRESS)  += address.o
 obj-$(CONFIG_OF_IRQ)+= irq.o
-obj-$(CONFIG_OF_DEVICE) += device.o platform.o
 obj-$(CONFIG_OF_I2C)   += of_i2c.o
 obj-$(CONFIG_OF_NET)   += of_net.o
 obj-$(CONFIG_OF_SELFTEST) += selftest.o
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index 901b743..9d27475 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -4,12 +4,12 @@
 #include 
 #include  /* temporary until merge */
 
-#ifdef CONFIG_OF_DEVICE
 #include 
 #include 
 
 struct device;
 
+#ifdef CONFIG_OF
 extern const struct of_device_id *of_match_device(
const struct of_device_id *matches, const struct device *dev);
 extern void of_device_make_bus_id(struct device *dev);
@@ -43,7 +43,7 @@ static inline void of_device_node_put(struct device *dev)
of_node_put(dev->of_node);
 }
 
-#else /* CONFIG_OF_DEVICE */
+#else /* CONFIG_OF */
 
 static inline int of_driver_match_device(struct device *dev,
 struct device_driver *drv)
@@ -67,6 +67,6 @@ static inline const struct of_device_id *of_match_device(
 {
return NULL;
 }
-#endif /* CONFIG_OF_DEVICE */
+#endif /* CONFIG_OF */
 
 #endif /* _LINUX_OF_DEVICE_H */
diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index aa7eb02..6b840f0 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -13,8 +13,6 @@
 
 #include 
 #include 
-
-#ifdef CONFIG_OF_DEVICE
 #include 
 #include 
 #include 
@@ -74,13 +72,8 @@ extern int of_platform_populate(struct device_node *root,
const struct of_device_id *matches,
const struct of_dev_auxdata *lookup,
struct device *parent);
-#endif /* CONFIG_OF_ADDRESS */
-
-#endif /* CONFIG_OF_DEVICE */
+#else
 
-#if !defined(CONFIG_OF_ADDRESS)
-struct of_dev_auxdata;
-struct device_node;
 static inline int of_platform_populate(struct device_node *root,
const struct of_device_id *matches,
const struct of_dev_auxdata *lookup,
-- 
1.7.10.4

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

Re: [PATCH v9 00/12] Driver for Si476x series of chips

[Andrey Smirnov]

On Sun, Apr 21, 2013 at 2:33 AM, Mauro Carvalho Chehab
 wrote:
> Em 21-04-2013 02:53, Andrey Smirnov escreveu:
>
>>> I applied all the MFD patches from this patchset (All 4 first ones), plus
>>> a
>>> follow up one for fixing the i2c related warning.
>>> I also squashed the REGMAP_I2C dependency into patch #4.
>>> It's all in mfd-next now, I'd appreciate if you could double check it's
>>> all
>>> fine.
>>
>>
>> I checked out latest
>> git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-next.git and
>> applied patches 5 - 10, 12. There doesn't seem to be any problems, so
>> I think MFD part of the driver is good to go.
>>
>>>
>>> Mauro will take the rest, we made sure there won't be any merge conflict
>>> between our trees.
>>
>>
>> Mauro, I am not sure if you need me to rebase any of the patches(it
>> doesn't seem like you had a chance to make any further changes related
>> to this driver in media tree), but if you do, ping me and I'll get on
>> it.
>
>
> No, I don't need. The V4L parts are on my experimental tree:
>
> http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/si476x
>
> I'll just merge it at the main tree or as a topic branch later today
> or (more likely) tomorrow.
>
> Please ping me today if you find anything wrong there.

It looks like everything is there(it's only one patch without mfd
part, after all) except patch #12
https://patchwork.kernel.org/patch/2461631/ of this patchset which is
a modified version of this guy
https://patchwork-mail.kernel.org/patch/2420751/

Other than that I think everything is fine.

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

Re: [RFC] arm64: Early printk support for virtio-mmio console devices.

[Rusty Russell]

Pranavkumar Sawargaonkar  writes:
> On 18 April 2013 12:21, Rusty Russell  wrote:
>>
>> PranavkumarSawargaonkar  writes:
>> > From: Pranavkumar Sawargaonkar 
>> >
>> > This patch implements early printk support for virtio-mmio console devices 
>> > without using any hypercalls.
>>
>> This makes some sense, though not sure that early console *read* makes
>> much sense.  I can see the PCI version of this being useful as well.
>
> Read can be useful for "mach-virt" which will have only virtio console
> as a console device. Then if someone wants to have UEFI or any other
> boot-loader emulation, which expects user to input few things, in that
> case read might become handy.

But implementing virtio inside a bootloader has already been done for
coreboot, for example.  A bootloader probably wants a virtio block
device, so a console is trivial.

A single writable field for debugging makes sense.  Anything more is far
less certain.

Thanks,
Rusty.
--
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: [ 10/11] mtdchar: fix offset overflow detection

[Ben Hutchings]

On Mon, 2013-04-15 at 21:55 +0100, David Woodhouse wrote:
> On Sun, 2013-04-14 at 19:17 -0700, Greg Kroah-Hartman wrote:
> > 3.0-stable review patch.  If anyone has any objections, please let me know.
> 
> Please use f5cf8f07423b2677cebebcebc863af77223a4972 instead (for 3.4
> too).

I've queued that up for 3.2, thanks.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.


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

Re: [PATCH 2/2] dma:of: Use a mutex to protect the of_dma_list

[Jon Hunter]

On 04/19/2013 06:13 PM, Arnd Bergmann wrote:
> On Saturday 20 April 2013, Jon Hunter wrote:
>> Change also means that of_dma_request_slave_channel() cannot be called
>> from a context where it is not possible to sleep too, right? May be
>> worth mentioning this in the changelog as well.
> 
> You already cannot do that, because it requires dma_list_mutex.

Right in the case where you use of_dma_simple_xlate(). However, someone
could implement whatever they wanted for the xlate. Probably not likely
as it needs to return struct dma_chan, but could be possible. That's
all. Not a big deal.

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

Re: [PATCH 2/2] dma:of: Use a mutex to protect the of_dma_list

[Jon Hunter]

On 04/20/2013 05:38 AM, Arnd Bergmann wrote:
> On Saturday 20 April 2013, Lars-Peter Clausen wrote:
>> On 04/20/2013 12:45 AM, Jon Hunter wrote:
>>> I think that there is a problem here. For controllers using the
>>> of_dma_simple_xlate(), this will call dma_request_channel() which also
>>> uses a mutex.
>>
>> That would only be a problem if it'd use the same mutex. Holding two mutexes 
>> at
>> the same time is not a problem per se.
>>
> 
> I guess Jon originlly tried it with a spinlock as the outer lock, which indeed
> does not work, but the new version does not have this problem.

Yes the spinlock was a problem and hence for the put/get functions. Ok
so that's fine then.

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

RE: [NEW DRIVER V6 6/7] drivers/hwmon: DA9058 HWMON driver

[Opensource [Anthony Olech]]

> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: 20 April 2013 18:35
> To: Lars-Peter Clausen
> Cc: Opensource [Anthony Olech]; Jean Delvare; Mark Brown; Randy Dunlap;
> lm-sens...@lm-sensors.org; LKML; David Dajun Chen
> Subject: Re: [NEW DRIVER V6 6/7] drivers/hwmon: DA9058 HWMON driver
> On Fri, Apr 19, 2013 at 08:25:02PM +0200, Lars-Peter Clausen wrote:
> > Same comment as before, I'd like to see this using the generic IIO to
> > HWMON bridge instead of recreating it.
> ... and I agree. Seems we are getting more and more of those, and at some
> point it makes really sense to find a generic solution.
> Anthony, can you please look into that ?
> Thanks,
> Guenter

OK -- generic IIO to HWMON bridge

I will investigate - but if you know any prototypes or any useful starting 
point could you let me know as I don't want to re-invent the wheel.

Thanks,

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

Re: [PATCH V3 1/5] powerpc, perf: Add new BHRB related instructions for POWER8

[Michael Neuling]

Michael Ellerman  wrote:

> On Thu, Apr 18, 2013 at 05:56:12PM +0530, Anshuman Khandual wrote:
> > This patch adds new POWER8 instruction encoding for reading
> > the BHRB buffer entries and also clearing it. Encoding for
> > "clrbhrb" instruction is straight forward.
> 
> Which is "clear branch history rolling buffer" ?
> 
> > But "mfbhrbe"
> > encoding involves reading a certain index of BHRB buffer
> > into a particular GPR register.
> 
> And "Move from branch history rolling buffer entry" ?
> 
> > diff --git a/arch/powerpc/include/asm/ppc-opcode.h 
> > b/arch/powerpc/include/asm/ppc-opcode.h
> > index 8752bc8..93ae5a1 100644
> > --- a/arch/powerpc/include/asm/ppc-opcode.h
> > +++ b/arch/powerpc/include/asm/ppc-opcode.h
> > @@ -82,6 +82,7 @@
> >  #define__REGA0_R31 31
> >  
> >  /* sorted alphabetically */
> > +#define PPC_INST_BHRBE 0x7c00025c
> 
> I don't think you really need this, just use the literal value below.

The rest of the defines in this file do this, so Anshuman's right. 

> > @@ -297,6 +298,12 @@
> >  #define PPC_NAPstringify_in_c(.long PPC_INST_NAP)
> >  #define PPC_SLEEP  stringify_in_c(.long PPC_INST_SLEEP)
> >  
> > +/* BHRB instructions */
> > +#define PPC_CLRBHRBstringify_in_c(.long 0x7c00035c)
> > +#define PPC_MFBHRBE(r, n)  stringify_in_c(.long PPC_INST_BHRBE | \
> > +   __PPC_RS(r) | \
> > +   (((n) & 0x1f) << 11))
> 
> Why are you not using ___PPC_RB(n) here ?

Actually, this is wrong.  The number field should be 10 bits (0x3ff),
not 5 (0x1f)  Anshuman please fix.  

Mikey
--
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/3] Tools: hv: fix warnings in hv_vss_daemon

[Greg KH]

On Sun, Apr 21, 2013 at 10:32:45PM +, KY Srinivasan wrote:
> 
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Friday, April 19, 2013 7:24 PM
> > To: Olaf Hering
> > Cc: KY Srinivasan; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH 1/3] Tools: hv: fix warnings in hv_vss_daemon
> > 
> > On Tue, Mar 26, 2013 at 04:28:27PM +0100, Olaf Hering wrote:
> > > This change fixes a few compile errors:
> > >
> > > hv_vss_daemon.c:64:15: warning: unknown escape sequence '\/'
> > > hv_vss_daemon.c:64:15: warning: unknown escape sequence '\/'
> > > hv_vss_daemon.c: In function 'vss_operate':
> > > hv_vss_daemon.c:66: warning: 'return' with no value, in function returning
> > non-void
> > > hv_vss_daemon.c: In function 'main':
> > > hv_vss_daemon.c:130: warning: ignoring return value of 'daemon', declared
> > with attribute warn_unused_result
> > > hv_vss_daemon.c: In function 'vss_operate':
> > > hv_vss_daemon.c:47: warning: 'fs_op' may be used uninitialized in this 
> > > function
> > >
> > > Signed-off-by: Olaf Hering 
> > 
> > For some reason, all of your hv tools patches ended up in my spam
> > filter.  KY, can you resend me any that I didn't apply, and you have
> > tested?
> 
> Greg,
> 
> I forwarded some patches from Olaf (I think Olaf is on vacation) that
> have not been applied. I had acked all these patches when Olaf sent
> them out initially.

Can you please resend them in a format that I can apply them in (hint,
I should never have to edit the patch by hand from you.)

thanks,

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

[PATCH V1] fs/buffer.c: Remove unnecessary init operation after, allocating buffer_head.

[majianpeng]

Because alloc 'struct buffer_head' using kmem_cache_zalloc,so it doesn't
need to call 'init_buffer(bh, NULL, NULL)' and other set-zero-operation.

Signed-off-by: Jianpeng Ma 
---
 fs/buffer.c   | 2 --
 fs/jbd/journal.c  | 2 --
 fs/jbd2/journal.c | 2 --
 3 files changed, 6 deletions(-)

diff --git a/fs/buffer.c b/fs/buffer.c
index b4dcb34..52b7739 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -865,8 +865,6 @@ try_again:
 
 /* Link the buffer to its page */
 set_bh_page(bh, page, offset);
-
-init_buffer(bh, NULL, NULL);
 }
 return head;
 /*
diff --git a/fs/jbd/journal.c b/fs/jbd/journal.c
index 81cc7ea..865c430 100644
--- a/fs/jbd/journal.c
+++ b/fs/jbd/journal.c
@@ -310,8 +310,6 @@ int journal_write_metadata_buffer(transaction_t 
*transaction,
 
 new_bh = alloc_buffer_head(GFP_NOFS|__GFP_NOFAIL);
 /* keep subsequent assertions sane */
-new_bh->b_state = 0;
-init_buffer(new_bh, NULL, NULL);
 atomic_set(&new_bh->b_count, 1);
 new_jh = journal_add_journal_head(new_bh);/* This sleeps */
 
diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index ed10991..8b220f1 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -367,8 +367,6 @@ retry_alloc:
 }
 
 /* keep subsequent assertions sane */
-new_bh->b_state = 0;
-init_buffer(new_bh, NULL, NULL);
 atomic_set(&new_bh->b_count, 1);
 new_jh = jbd2_journal_add_journal_head(new_bh);/* This sleeps */
 
-- 
1.8.2.rc2.4.g7799588

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

Re: [PATCH 3.8.y] drm/i915: add quirk to invert brightness on eMachines e725

[Ben Hutchings]

On Wed, 2013-04-10 at 12:37 +0300, Jani Nikula wrote:
> On Wed, 10 Apr 2013, Ben Hutchings  wrote:
> > I cherry-picked the following series for Debian:
> >
> > [pre-3.8]
> > 7bd90909bbf9 drm/i915: panel: invert brightness via parameter
> > 4dca20efb1a9 drm/i915: panel: invert brightness via quirk
> > 5a15ab5b93e4 drm/i915: panel: invert brightness acer aspire 5734z
> > 5f85f176c2f1 DRM/i915: Add QUIRK_INVERT_BRIGHTNESS for NCR machines.
> > [post-3.8]
> > 16032087 drm/i915: add quirk to invert brightness on eMachines G725
> > 01e3a8feb40e drm/i915: add quirk to invert brightness on eMachines e725
> > 5559ecadad5a drm/i915: add quirk to invert brightness on Packard Bell NCL20
> >
> > Should these all be applied to the various 3.x.y stable branches?
> 
> Acked-by: Jani Nikula 

Queued up for 3.2, thanks.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.


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

Re: [PATCH] fs/buffer.c: Remove the unnecessary init operation after allocating buffer_head.

[majianpeng]

On 04/19/2013 10:48 PM, Jan Kara wrote:
> On Fri 19-04-13 10:29:36, majianpeng wrote:
>> Because alloc struct buffer_head using kmem_cache_zalloc,so it's not need to
>> call 'init_buffer(bh, NULL, NULL)'.
>>
>> Signed-off-by: Jianpeng Ma 
>> ---
>>  fs/buffer.c   | 2 --
>>  fs/jbd/journal.c  | 1 -
>>  fs/jbd2/journal.c | 1 -
>>  3 files changed, 4 deletions(-)
>>
>> diff --git a/fs/buffer.c b/fs/buffer.c
>> index b4dcb34..52b7739 100644
>> --- a/fs/buffer.c
>> +++ b/fs/buffer.c
>> @@ -865,8 +865,6 @@ try_again:
>>  
>>  /* Link the buffer to its page */
>>  set_bh_page(bh, page, offset);
>> -
>> -init_buffer(bh, NULL, NULL);
>>  }
>>  return head;
>>  /*
>> diff --git a/fs/jbd/journal.c b/fs/jbd/journal.c
>> index 81cc7ea..0c3fe90 100644
>> --- a/fs/jbd/journal.c
>> +++ b/fs/jbd/journal.c
>> @@ -311,7 +311,6 @@ int journal_write_metadata_buffer(transaction_t 
>> *transaction,
>>  new_bh = alloc_buffer_head(GFP_NOFS|__GFP_NOFAIL);
>>  /* keep subsequent assertions sane */
>>  new_bh->b_state = 0;
>> -init_buffer(new_bh, NULL, NULL);
>   You can also remove b_state = 0 , can't you?
>
>>  atomic_set(&new_bh->b_count, 1);
>>  new_jh = journal_add_journal_head(new_bh);/* This sleeps */
>>  
>> diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
>> index ed10991..95120c6 100644
>> --- a/fs/jbd2/journal.c
>> +++ b/fs/jbd2/journal.c
>> @@ -368,7 +368,6 @@ retry_alloc:
>>  
>>  /* keep subsequent assertions sane */
>>  new_bh->b_state = 0;
>> -init_buffer(new_bh, NULL, NULL);
>   And the same here. Otherwise the patch looks OK.
>
>   Honza
Thanks your suggestions.I'll resend .

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

Re: [PATCH 3.8-stable] thermal: return an error on failure to register thermal

[Ben Hutchings]

On Wed, 2013-04-03 at 15:47 +0100, Luis Henriques wrote:
> On Wed, Apr 03, 2013 at 09:38:55AM +0900, Jonghwan Choi wrote:
> > 3.8-stable review patch.  If anyone has any objections, please let me know.
> 
> I believe this is applicable to all the other stable kernels.

Queued up for 3.2, thanks.

Ben.

> Cheers,
> --
> Luis
> 
> > 
> > --
> > 
> > From: "Richard Guy Briggs "
> > 
> > commit da28d966f6aa942ae836d09729f76a1647932309 upstream.
> > 
> > The return code from the registration of the thermal class is used to
> > unallocate resources, but this failure isn't passed back to the caller of
> > thermal_init.  Return this failure back to the caller.
> > 
> > This bug was introduced in changeset 4cb18728 which overwrote the return
> > code
> > when the variable was re-used to catch the return code of the registration
> > of
> > the genetlink thermal socket family.
> > 
> > Signed-off-by: Richard Guy Briggs 
> > Signed-off-by: Zhang Rui 
> > ---
> >  drivers/thermal/thermal_sys.c |1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> > index 6472e7e..1a19a2f 100644
> > --- a/drivers/thermal/thermal_sys.c
> > +++ b/drivers/thermal/thermal_sys.c
> > @@ -1875,6 +1875,7 @@ static int __init thermal_init(void)
> > idr_destroy(&thermal_cdev_idr);
> > mutex_destroy(&thermal_idr_lock);
> > mutex_destroy(&thermal_list_lock);
> > +   return result;
> > }
> > result = genetlink_init();
> > return result;
> > -- 
> > 1.7.9.5
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe stable" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.


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

RE: [PATCH v2] NMI: fix NMI period is not correct when cpu frequency changes issue.

[Pan, Zhenjie]

> I believe it mattered to the Chrome folks. They want the watchdog to be as
> tight as possible so the user experience isn't a hang but a quick reboot
> instead.  They like setting the watchdog to something like 2 seconds.
> 
> There was a patch a few months ago that tried to hack around this issue and I
> suggested this approach as a better solution.  I forgot what the original
> problem was.  Perhaps someone can jump in and explain the problem being
> solved (other than the watchdog isn't always 10 seconds)?
> 
> Cheers,
> Don

Yes, I also think the period is important sometimes.
As I mentioned before, the case I meet is:
When the system hang with interrupt disabled, we use NMI to detect.
Then it will find hard lockup and cause a panic.
Panic is very important for debug these kind of issues.

But if cpu frequency change, the period will be 2 times, 3 times even more.(if 
cpu can down from 2.0GHz to 200MHz, will be 10 times, it's a very big deviation)
This make watchdog reset happen before hard lockup detect.

Thanks
Pan Zhenjie
--
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: Crypto Fixes for 3.9

[Herbert Xu]

Hi Linus:

This push fixes a kernel memory leak in the algif interface.


Please pull from

git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git

or

master.kernel.org:/pub/scm/linux/kernel/git/herbert/crypto-2.6.git


Mathias Krause (1):
  crypto: algif - suppress sending source address information in recvmsg

 crypto/algif_hash.c |2 ++
 crypto/algif_skcipher.c |1 +
 2 files changed, 3 insertions(+), 0 deletions(-)
 
Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 00/15] KVM: MMU: fast zap all shadow pages

[Marcelo Tosatti]

On Sun, Apr 21, 2013 at 04:03:46PM +0300, Gleb Natapov wrote:
> On Tue, Apr 16, 2013 at 02:32:38PM +0800, Xiao Guangrong wrote:
> > This patchset is based on my previous two patchset:
> > [PATCH 0/2] KVM: x86: avoid potential soft lockup and unneeded mmu reload
> > (https://lkml.org/lkml/2013/4/1/2)
> > 
> > [PATCH v2 0/6] KVM: MMU: fast invalid all mmio sptes
> > (https://lkml.org/lkml/2013/4/1/134)
> > 
> > Changlog:
> > V3:
> >   completely redesign the algorithm, please see below.
> > 
> This looks pretty complicated. Is it still needed in order to avoid soft
> lockups after "avoid potential soft lockup and unneeded mmu reload" patch?

Do not want kvm_set_memory (cases: DELETE/MOVE/CREATES) to be
suspectible to:

vcpu 1  |   kvm_set_memory
create shadow page  
nuke shadow page
create shadow page
nuke shadow page

Which is guest triggerable behavior with spinlock preemption algorithm.

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

Re: [PATCH v3 00/15] KVM: MMU: fast zap all shadow pages

[Marcelo Tosatti]

On Sun, Apr 21, 2013 at 10:09:29PM +0800, Xiao Guangrong wrote:
> On 04/21/2013 09:03 PM, Gleb Natapov wrote:
> > On Tue, Apr 16, 2013 at 02:32:38PM +0800, Xiao Guangrong wrote:
> >> This patchset is based on my previous two patchset:
> >> [PATCH 0/2] KVM: x86: avoid potential soft lockup and unneeded mmu reload
> >> (https://lkml.org/lkml/2013/4/1/2)
> >>
> >> [PATCH v2 0/6] KVM: MMU: fast invalid all mmio sptes
> >> (https://lkml.org/lkml/2013/4/1/134)
> >>
> >> Changlog:
> >> V3:
> >>   completely redesign the algorithm, please see below.
> >>
> > This looks pretty complicated. Is it still needed in order to avoid soft
> > lockups after "avoid potential soft lockup and unneeded mmu reload" patch?
> 
> Yes.
> 
> I discussed this point with Marcelo:
> 
> ==
> BTW, to my honest, i do not think spin_needbreak is a good way - it does
> not fix the hot-lock contention and it just occupies more cpu time to avoid
> possible soft lock-ups.
> 
> Especially, zap-all-shadow-pages can let other vcpus fault and vcpus contest
> mmu-lock, then zap-all-shadow-pages release mmu-lock and wait, other vcpus
> create page tables again. zap-all-shadow-page need long time to be finished,
> the worst case is, it can not completed forever on intensive vcpu and memory
> usage.
> 
> I still think the right way to fix this kind of thing is optimization for
> mmu-lock.
> ==
> 
> Which parts scare you? Let's find a way to optimize for it. ;). For example,
> if you do not like unmap_memslot_rmap_nolock(), we can simplify it - We can
> use walk_shadow_page_lockless_begin() and walk_shadow_page_lockless_end() to
> protect spte instead of kvm->being_unmaped_rmap.
> 
> Thanks!

Xiao,

You can just remove all shadow rmaps now that you've agreed per-memslot
flushes are not necessary. Which then gets rid of necessity for lockless 
rmap accesses. Right?


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

Re: [PATCH v3 00/15] KVM: MMU: fast zap all shadow pages

[Marcelo Tosatti]

On Sun, Apr 21, 2013 at 12:27:51PM -0300, Marcelo Tosatti wrote:
> On Sun, Apr 21, 2013 at 04:03:46PM +0300, Gleb Natapov wrote:
> > On Tue, Apr 16, 2013 at 02:32:38PM +0800, Xiao Guangrong wrote:
> > > This patchset is based on my previous two patchset:
> > > [PATCH 0/2] KVM: x86: avoid potential soft lockup and unneeded mmu reload
> > > (https://lkml.org/lkml/2013/4/1/2)
> > > 
> > > [PATCH v2 0/6] KVM: MMU: fast invalid all mmio sptes
> > > (https://lkml.org/lkml/2013/4/1/134)
> > > 
> > > Changlog:
> > > V3:
> > >   completely redesign the algorithm, please see below.
> > > 
> > This looks pretty complicated. Is it still needed in order to avoid soft
> > lockups after "avoid potential soft lockup and unneeded mmu reload" patch?
> 
> Do not want kvm_set_memory (cases: DELETE/MOVE/CREATES) to be
> suspectible to:
> 
> vcpu 1|   kvm_set_memory
> create shadow page
>   nuke shadow page
> create shadow page
>   nuke shadow page
> 
> Which is guest triggerable behavior with spinlock preemption algorithm.

Not only guest triggerable as in the sense of a malicious guest, 
but condition above can be induced by host workload with non-malicious
guest system.

Also kvm_set_memory being relatively fast with huge memory guests
is nice (which is what Xiaos idea allows).


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

Re: [PATCH V3 1/5] powerpc, perf: Add new BHRB related instructions for POWER8

[Michael Ellerman]

On Thu, Apr 18, 2013 at 05:56:12PM +0530, Anshuman Khandual wrote:
> This patch adds new POWER8 instruction encoding for reading
> the BHRB buffer entries and also clearing it. Encoding for
> "clrbhrb" instruction is straight forward.

Which is "clear branch history rolling buffer" ?

> But "mfbhrbe"
> encoding involves reading a certain index of BHRB buffer
> into a particular GPR register.

And "Move from branch history rolling buffer entry" ?

> diff --git a/arch/powerpc/include/asm/ppc-opcode.h 
> b/arch/powerpc/include/asm/ppc-opcode.h
> index 8752bc8..93ae5a1 100644
> --- a/arch/powerpc/include/asm/ppc-opcode.h
> +++ b/arch/powerpc/include/asm/ppc-opcode.h
> @@ -82,6 +82,7 @@
>  #define  __REGA0_R31 31
>  
>  /* sorted alphabetically */
> +#define PPC_INST_BHRBE   0x7c00025c

I don't think you really need this, just use the literal value below.

> @@ -297,6 +298,12 @@
>  #define PPC_NAP  stringify_in_c(.long PPC_INST_NAP)
>  #define PPC_SLEEPstringify_in_c(.long PPC_INST_SLEEP)
>  
> +/* BHRB instructions */
> +#define PPC_CLRBHRB  stringify_in_c(.long 0x7c00035c)
> +#define PPC_MFBHRBE(r, n)stringify_in_c(.long PPC_INST_BHRBE | \
> + __PPC_RS(r) | \
> + (((n) & 0x1f) << 11))

Why are you not using ___PPC_RB(n) here ?

cheers
--
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/2] cpufreq: ARM big LITTLE: put DT nodes after using them

[Rafael J. Wysocki]

On Monday, April 15, 2013 12:35:24 PM Viresh Kumar wrote:
> DT nodes should be put using of_node_put() to balance their usage counts. This
> is not done properly in ARM's big LITTLE driver. Fix it.
> 
> Signed-off-by: Viresh Kumar 
> ---
> Hi Rafael,
> 
> These are fixes for 3.10

Both applied.

Thanks,
Rafael


>  drivers/cpufreq/arm_big_little_dt.c | 43 
> +
>  1 file changed, 29 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/cpufreq/arm_big_little_dt.c 
> b/drivers/cpufreq/arm_big_little_dt.c
> index 452ff46..44be311 100644
> --- a/drivers/cpufreq/arm_big_little_dt.c
> +++ b/drivers/cpufreq/arm_big_little_dt.c
> @@ -31,22 +31,28 @@
>  
>  static int dt_init_opp_table(struct device *cpu_dev)
>  {
> - struct device_node *np = NULL;
> + struct device_node *np, *parent;
>   int count = 0, ret;
>  
> - for_each_child_of_node(of_find_node_by_path("/cpus"), np) {
> + parent = of_find_node_by_path("/cpus");
> + if (!parent) {
> + pr_err("failed to find OF /cpus\n");
> + return -ENOENT;
> + }
> +
> + for_each_child_of_node(parent, np) {
>   if (count++ != cpu_dev->id)
>   continue;
> - if (!of_get_property(np, "operating-points", NULL))
> - return -ENODATA;
> -
> - cpu_dev->of_node = np;
> -
> - ret = of_init_opp_table(cpu_dev);
> - if (ret)
> - return ret;
> -
> - return 0;
> + if (!of_get_property(np, "operating-points", NULL)) {
> + ret = -ENODATA;
> + } else {
> + cpu_dev->of_node = np;
> + ret = of_init_opp_table(cpu_dev);
> + }
> + of_node_put(np);
> + of_node_put(parent);
> +
> + return ret;
>   }
>  
>   return -ENODEV;
> @@ -54,15 +60,24 @@ static int dt_init_opp_table(struct device *cpu_dev)
>  
>  static int dt_get_transition_latency(struct device *cpu_dev)
>  {
> - struct device_node *np = NULL;
> + struct device_node *np, *parent;
>   u32 transition_latency = CPUFREQ_ETERNAL;
>   int count = 0;
>  
> - for_each_child_of_node(of_find_node_by_path("/cpus"), np) {
> + parent = of_find_node_by_path("/cpus");
> + if (!parent) {
> + pr_err("failed to find OF /cpus\n");
> + return -ENOENT;
> + }
> +
> + for_each_child_of_node(parent, np) {
>   if (count++ != cpu_dev->id)
>   continue;
>  
>   of_property_read_u32(np, "clock-latency", &transition_latency);
> + of_node_put(np);
> + of_node_put(parent);
> +
>   return 0;
>   }
>  
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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] cpufreq: cpu0: Put cpu parent node after using it

[Rafael J. Wysocki]

On Tuesday, April 16, 2013 04:40:15 PM Shawn Guo wrote:
> On Mon, Apr 15, 2013 at 12:39:37PM +0530, Viresh Kumar wrote:
> > Parent node must be put after using it to balance its usage count. This was
> > missing in cpufreq-cpu0 driver. Fix it.
> > 
> > Signed-off-by: Viresh Kumar 
> 
> Acked-by: Shawn Guo 

Applied.

Thanks,
Rafael


> > ---
> >  drivers/cpufreq/cpufreq-cpu0.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> > index 31282fc..3ab8294 100644
> > --- a/drivers/cpufreq/cpufreq-cpu0.c
> > +++ b/drivers/cpufreq/cpufreq-cpu0.c
> > @@ -257,6 +257,7 @@ static int cpu0_cpufreq_probe(struct platform_device 
> > *pdev)
> > }
> >  
> > of_node_put(np);
> > +   of_node_put(parent);
> > return 0;
> >  
> >  out_free_table:
> 
> --
> To unsubscribe from this list: send the line "unsubscribe cpufreq" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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] cpufreq: exynos5440: Protect opp search calls with rcu lock

[Rafael J. Wysocki]

On Monday, April 15, 2013 11:54:47 AM Amit Daniel Kachhap wrote:
> As per the OPP library documentation(Documentation/power/opp.txt) all
> opp find/get calls should be protected by rcu locks.
> 
> Signed-off-by: Amit Daniel Kachhap 
> ---
> 
> This patch is created against linux-next tree and is suggested by
> Nishanth Menon. (https://lkml.org/lkml/2013/4/12/119)

Applied.

Thanks,
Rafael


>  drivers/cpufreq/exynos5440-cpufreq.c |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/cpufreq/exynos5440-cpufreq.c 
> b/drivers/cpufreq/exynos5440-cpufreq.c
> index ead7ed4..0c74018 100644
> --- a/drivers/cpufreq/exynos5440-cpufreq.c
> +++ b/drivers/cpufreq/exynos5440-cpufreq.c
> @@ -120,11 +120,13 @@ static int init_div_table(void)
>   int i = 0;
>   struct opp *opp;
>  
> + rcu_read_lock();
>   for (i = 0; freq_tbl[i].frequency != CPUFREQ_TABLE_END; i++) {
>  
>   opp = opp_find_freq_exact(dvfs_info->dev,
>   freq_tbl[i].frequency * 1000, true);
>   if (IS_ERR(opp)) {
> + rcu_read_unlock();
>   dev_err(dvfs_info->dev,
>   "failed to find valid OPP for %u KHZ\n",
>   freq_tbl[i].frequency);
> @@ -159,6 +161,7 @@ static int init_div_table(void)
>   __raw_writel(tmp, dvfs_info->base + XMU_PMU_P0_7 + 4 * i);
>   }
>  
> + rcu_read_unlock();
>   return 0;
>  }
>  
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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: Tree for Apr 9 [cpufreq: NULL pointer deref]

[Rafael J. Wysocki]

On Monday, April 15, 2013 10:52:28 PM Viresh Kumar wrote:
> On 15 April 2013 21:37, Dirk Brandewie  wrote:
> > If the intel_pstate driver is being used __cpufreq_governor() should NOT be
> > called intel_pstate does not implement the target() callback.
> >
> > Nathan's commit 5800043b2 changed the fence around the call to
> > __cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.
> 
> No it isn't.
> 
> > +   if (has_target)
> > __cpufreq_governor(data, CPUFREQ_GOV_STOP);
> 
> As it has taken care of this limitation.
> 
> BUT some of my earlier patches haven't. :(
> Here is the fix (Sedat please try this and give your tested-by, use the 
> attached
> patch as gmail might break what i am copying in mail)..
> 
> Sorry for being late in fixing this issue, i am still down with Tonsil 
> infection
> and fever.. Today only i got some power to fix it after seeing Dirk's mail.
> 
> Your tested-by may help me to recover quickly :)
> 
> @Rafael: I will probably be down for one more week and so not doing any
> reviews for now... I do check important mails sent directly to me though.
> 
> x--x--
> 
> From: Viresh Kumar 
> Date: Mon, 15 Apr 2013 22:43:57 +0530
> Subject: [PATCH] cpufreq: Don't call __cpufreq_governor() for drivers without
>  target()
> 
> Some cpufreq drivers implement their own governor and so don't need us to call
> generic governors interface via __cpufreq_governor(). Few recent commits 
> haven't
> obeyed this law well and we saw some regressions.
> 
> This patch tries to fix this issue.
> 
> Signed-off-by: Viresh Kumar 

Applied to linux-pm.git/linux-next, although please check the result, because
the patchwork version of the patch wasn't quite applicable and I fixed it up
manually.

Thanks,
Rafael


> ---
>  drivers/cpufreq/cpufreq.c | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 3564947..a6f6595 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -858,13 +858,18 @@ static int cpufreq_add_policy_cpu(unsigned int
> cpu, unsigned int sibling,
> struct device *dev)
>  {
>   struct cpufreq_policy *policy;
> - int ret = 0;
> + int ret = 0, has_target = 0;
>   unsigned long flags;
> 
>   policy = cpufreq_cpu_get(sibling);
>   WARN_ON(!policy);
> 
> - __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
> + rcu_read_lock();
> + has_target = !!rcu_dereference(cpufreq_driver)->target;
> + rcu_read_unlock();
> +
> + if (has_target)
> + __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
> 
>   lock_policy_rwsem_write(sibling);
> 
> @@ -877,8 +882,10 @@ static int cpufreq_add_policy_cpu(unsigned int
> cpu, unsigned int sibling,
> 
>   unlock_policy_rwsem_write(sibling);
> 
> - __cpufreq_governor(policy, CPUFREQ_GOV_START);
> - __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
> + if (has_target) {
> + __cpufreq_governor(policy, CPUFREQ_GOV_START);
> + __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
> + }
> 
>   ret = sysfs_create_link(&dev->kobj, &policy->kobj, "cpufreq");
>   if (ret) {
> @@ -1146,7 +1153,8 @@ static int __cpufreq_remove_dev(struct device
> *dev, struct subsys_interface *sif
> 
>   /* If cpu is last user of policy, free policy */
>   if (cpus == 1) {
> - __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
> + if (has_target)
> + __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
> 
>   lock_policy_rwsem_read(cpu);
>   kobj = &data->kobj;
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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] [media] uvcvideo: quirk PROBE_DEF for Dell Studio / OmniVision webcam

[Laurent Pinchart]

Hi Kamal,

On Wednesday 17 April 2013 09:38:43 Kamal Mostafa wrote:
> On Wed, 2013-04-17 at 01:05 +0200, Laurent Pinchart wrote:
> > Hi Kamal,
> > 
> > On Monday 15 April 2013 12:01:51 Kamal Mostafa wrote:
> > > BugLink: https://bugs.launchpad.net/bugs/1168430
> > > 
> > > OminiVision webcam 0x05a9:0x264a (in Dell Studio Hybrid 140g) needs the
> > > same UVC_QUIRK_PROBE_DEF as other OmniVision model to be recognized
> > > consistently.
> > > 
> > > Signed-off-by: Kamal Mostafa 
> > 
> > Thank you for the patch.
> > 
> > Acked-by: Laurent Pinchart 
> > 
> > I've taken the patch in my tree and will submit it upstream for v3.11.
> > 
> > Could you please try to get the full 'lsusb -v -d 05a9:264a' output from
> > the bug reporter ?
> 
> Thanks Laurent.  The requested lsusb dump is now available at
> https://launchpadlibrarian.net/137633994/lsusb-omnivision-264a.txt

Thank you for the information.

-- 
Regards,

Laurent Pinchart


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

Re: Preemptable Ticket Spinlock

[Jiannan Ouyang]

On Sun, Apr 21, 2013 at 5:12 PM, Rik van Riel  wrote:
> Your algorithm is very clever, and very promising.
>
> However, it does increase the size of the struct spinlock, and adds
> an additional atomic operation to spin_unlock, neither of which I
> suspect are necessary.
>
> If we always incremented the ticket number by 2 (instead of 1), then
> we could use the lower bit of the ticket number as the spinlock.
>
> If we do NOT run virtualized, we simply increment the ticket by 2
> in spin_unlock, and the code can remain otherwise the same.
>
> If we do run virtualized, we take that spinlock after acquiring
> the ticket (or timing out), just like in your code. In the
> virtualized spin_unlock, we can then release the spinlock and
> increment the ticket in one operation: by simply increasing the
> ticket by 1.
>
> In other words, we should be able to keep the overhead of this
> to an absolute minimum, and keep spin_unlock to be always the
> same cost it is today.
>
> --
> All rights reversed

Hi Rik,

Thanks for your feedback.

Yes I agree with you
- increase the size of struct spinlock is unnecessary
- your idea of utilize the lower bit and save one atomic operation
from unlock is cool!

I can come up with a updated patch soon.

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

Re: [PATCH] x86: Fix AMD K6 indirect call check v2

[Borislav Petkov]

On Sun, Apr 21, 2013 at 03:35:41PM -0700, H. Peter Anvin wrote:
> Looks like it is just trying to sense the bug... but then it doesn't
> actually do anything about it. At least it should taint the kernel.

Yeah, I was thinking of asking my old contacts about it but it is simply
not worth it. Those CPUs are on their way to the museum if they're not
there already.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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] media: videobuf2: fix the length check for mmap

[Laurent Pinchart]

Hi Mauro,

On Friday 19 April 2013 08:18:01 Mauro Carvalho Chehab wrote:
> Em Fri, 19 Apr 2013 15:16:56 +0530 Prabhakar lad escreveu:
> > From: Lad, Prabhakar 
> > 
> > From commit 068a0df76023926af958a336a78bef60468d2033
> > "[media] media: vb2: add length check for mmap"
> > patch verifies that the mmap() size requested by userspace
> > doesn't exceed the buffer size.
> > 
> > As the mmap() size is rounded up to the next page boundary
> > the check will fail for buffer sizes that are not multiple
> > of the page size.
> > 
> > This patch fixes the check by aligning the buffer size to page
> > size during the check. Alongside fixes the vmalloc allocator
> > to round up the size.
> > 
> > Signed-off-by: Lad, Prabhakar 
> > Cc: Laurent Pinchart 
> > Cc: Marek Szyprowski 
> > Cc: Seung-Woo Kim 
> > Cc: Hans Verkuil 
> > Cc: Mauro Carvalho Chehab 
> > ---
> > 
> >  drivers/media/v4l2-core/videobuf2-core.c|2 +-
> >  drivers/media/v4l2-core/videobuf2-vmalloc.c |2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c
> > b/drivers/media/v4l2-core/videobuf2-core.c index 58c1744..223fcd4 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -1886,7 +1886,7 @@ int vb2_mmap(struct vb2_queue *q, struct
> > vm_area_struct *vma)> 
> > vb = q->bufs[buffer];
> > 
> > -   if (vb->v4l2_planes[plane].length < (vma->vm_end - vma->vm_start)) {
> > +   if (PAGE_ALIGN(vb->v4l2_planes[plane].length) < (vma->vm_end -
> > vma->vm_start)) {> 
> > dprintk(1, "Invalid length\n");
> > return -EINVAL;
> > 
> > }
> 
> That is tricky, as it assumes that vb->v4l2_planes[plane].length was round
> up to PAGE_SIZE at each memops driver, but the vb2 core doesn't enforce it.
> 
> IMO, it would be cleaner to round vb->v4l2_planes[plane].length up
> at VB2 core, before calling the memops alloc functions at the drivers.

I don't think we should round vb->v4l2_planes[plane].length up. That variable 
stores the buffer length required by the driver, and will be used to perform 
size checks when importing a dmabuf buffer. We don't want to prevent a buffer 
large enough for the driver but not page size aligned to be imported.

What we could do is round in the core the size passed to the alloc function, 
without storing the rounded value in vb->v4l2_planes[plane].length.

And, reading down, I realize that this is exactly what you meant :-) The 
proposed patch looks good to me.

> Also, VB2 is already complex enough to put it there without proper
> comments (and there's a minor codingstyle issue there: line is bigger
> than 80 cols).

A comment is definitely a good idea.

> > diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c
> > b/drivers/media/v4l2-core/videobuf2-vmalloc.c index 313d977..bf3b95c
> > 100644
> > --- a/drivers/media/v4l2-core/videobuf2-vmalloc.c
> > +++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c
> > @@ -44,7 +44,7 @@ static void *vb2_vmalloc_alloc(void *alloc_ctx, unsigned
> > long size, gfp_t gfp_fl> 
> > return NULL;
> > 
> > buf->size = size;
> > 
> > -   buf->vaddr = vmalloc_user(buf->size);
> > +   buf->vaddr = vmalloc_user(PAGE_ALIGN(buf->size));
> 
> See? You needed to put an alignment here as well, not because vmalloc
> needs it, but because this is needed by VB2 core.
> 
> Also, on the other drivers, buf->size is stored page aligned, while
> here, you're doing different, without any documented reason for doing
> that, instead of doing the same as on the other memops drivers.
> 
> That mistake reflects, for example, when the driver prints the failure:
> 
> if (!buf->vaddr) {
> pr_debug("vmalloc of size %ld failed\n", buf->size);
> 
> as it will show a different size than what you actually required.
> As those memory starving errors can also produce a dump at the mm
> core, the size there won't match the size on the above printed message.
> 
> Also, it is a very bad idea to delegate the core's requirement of
> do page alignment from the core to the memops drivers, as other
> patches may change the logic there, or a new memops could be added,
> and the same problem will hit again (and unnoticed, as the check
> routine do page alignments).

Agreed. The memory allocator shouldn't need to guess the core requirements.

> > buf->handler.refcount = &buf->refcount;
> > buf->handler.put = vb2_vmalloc_put;
> > buf->handler.arg = buf;
> 
> IMO, a cleaner version would be the following (untested) code.
> 
> -
> 
> [media] videobuf2: fix the length check for mmap
> 
> Memory maps typically require that the buffer size to be page
> aligned. Currently, two memops drivers do such alignment
> internally, but videobuf-vmalloc doesn't.
> 
> Also, the buffer overflow check doesn't take it into account.
> 
> So, instead of doing it at each memops driver, enforce it at
> VB2 core.
> 
> Reported-by: Prabhakar lad 
> 

Re: mdadm raid1 regression

[NeilBrown]

On Thu, 18 Apr 2013 14:38:53 +0400 Vasiliy Tolstov 
wrote:

> Hello. I'm using linux 3.8.6 and mdadm 3.2.6 (from git).
> I have many raid1 arrays that have data offset 2048 (metadata 1.2,
> created with various mdadm versions but mostly 3.2.1 on linux 2.6.32).
> If i create raid1 with never mdadm on 3.8.6 i have data offset 8192?? Why?

More room for various useful things.
In particular, if you one day want to convert this raid1 to a raid5, then
having a bit of extra space at the front will mean you can avoid a 'backup
file' and all the problems they cause (code for this isn't quite ready, but
is getting there).

> 
> My problem:
> Sometimes i'm doing mdadm --zero-superblock on both parts of array and
> re-create it. On older systems i have no errors. On new (linux 3.8.6
> and mdadm 3.2.6) i get corrupted ext3 fs and partition table. Why this
> happening?

Why are you doing that?

> P.S. If i use mdadm 3.2.2 i get data offset 4096 that not breaks data,
> but inconsistent with older versions.

I suggest you use mdadm 3.2.2 then.

> P.P.S. I'm try to specify --data-offset when create array but as i see
> - its ignored and data offset still have 8192).

I'll try to make sure that works correctly for the next release.
Thanks for the report.

NeilBrown

> 
> 
> Thanks!
> --
> Vasiliy Tolstov,
> e-mail: v.tols...@selfip.ru
> jabber: v...@selfip.ru
> --
> 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/



signature.asc
Description: PGP signature

Re: [PATCH] x86: Fix AMD K6 indirect call check v2

[H. Peter Anvin]

On 04/21/2013 10:44 AM, Borislav Petkov wrote:
> 
> But I have hard time understanding what that test with the 10^6 loop
> iterations is supposed to achieve. And what makes sure that the RDTSCs
> don't get reordered? Or maybe K6 wasn't reordering that aggressively...
> 
> Erratum says "unpredictable system behavior" but it seems it wasn't that
> unpredictable after all - otherwise the fix would've been "HLT" right
> then and there. :)
> 

Looks like it is just trying to sense the bug... but then it doesn't
actually do anything about it.  At least it should taint the kernel.

-hpa


--
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/3] Tools: hv: fix warnings in hv_vss_daemon

[KY Srinivasan]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Friday, April 19, 2013 7:24 PM
> To: Olaf Hering
> Cc: KY Srinivasan; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/3] Tools: hv: fix warnings in hv_vss_daemon
> 
> On Tue, Mar 26, 2013 at 04:28:27PM +0100, Olaf Hering wrote:
> > This change fixes a few compile errors:
> >
> > hv_vss_daemon.c:64:15: warning: unknown escape sequence '\/'
> > hv_vss_daemon.c:64:15: warning: unknown escape sequence '\/'
> > hv_vss_daemon.c: In function 'vss_operate':
> > hv_vss_daemon.c:66: warning: 'return' with no value, in function returning
> non-void
> > hv_vss_daemon.c: In function 'main':
> > hv_vss_daemon.c:130: warning: ignoring return value of 'daemon', declared
> with attribute warn_unused_result
> > hv_vss_daemon.c: In function 'vss_operate':
> > hv_vss_daemon.c:47: warning: 'fs_op' may be used uninitialized in this 
> > function
> >
> > Signed-off-by: Olaf Hering 
> 
> For some reason, all of your hv tools patches ended up in my spam
> filter.  KY, can you resend me any that I didn't apply, and you have
> tested?

Greg,

I forwarded some patches from Olaf (I think Olaf is on vacation) that have not 
been applied. I had acked all these patches when Olaf sent them out initially.

Regards,

K. Y
> 
> thanks,
> 
> greg k-h
> 


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

Re: irq 16: nobody cared

[Borislav Petkov]

On Sun, Apr 21, 2013 at 03:00:15PM -0700, Paul E. McKenney wrote:
> Cool!!!  Note that there is no need for expediting TINY_RCU because
> its grace periods are already maximally expedited.  There is only one
> CPU, so if you are following the rules, when you call synchronize_rcu(),
> by definition there is a zero-length grace period.  ;-)
>
> So all you need is rcutree.c.

Ok, even better :-).

> Looking forward to the section-mismatch-free version!

Yeah, here it is. Please sanity-check the commit message whether I'm
making sense.

I've just pulled -rc8 and tip/master + this patch and a couple of other
fixes and will run it the coming week to make sure there are no other
issues.

Thanks!

--
>From 3c155e9a22036839c09d98a4acbc7e17a5a3783c Mon Sep 17 00:00:00 2001
From: Borislav Petkov 
Date: Sun, 21 Apr 2013 23:56:15 +0200
Subject: [PATCH] RCU: Expedite grace periods during suspend/resume

Paul says CONFIG_RCU_FAST_NO_HZ can increase grace-period durations by a
factor of four. This, in turn, can change timings during suspend and can
delay interrupts handling, leading to "IRQ XX: nobody cared" splats and
the machine disabling those interrupt lines for no sensible reason.

Thus, we want to temporarily switch to expedited grace periods when
suspending the box and return to normal settings when resuming. This
patch does exactly that.

Cc: "Paul E. McKenney" 
Signed-off-by: Borislav Petkov 
---
 kernel/rcutree.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index 986d1d3a34f5..9e9aeb38b7a2 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -53,6 +53,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "rcutree.h"
 #include 
@@ -3097,6 +3098,22 @@ static int __cpuinit rcu_cpu_notify(struct 
notifier_block *self,
return NOTIFY_OK;
 }
 
+static int rcu_pm_notify(struct notifier_block *self,
+unsigned long action, void *hcpu)
+{
+   switch (action) {
+   case PM_HIBERNATION_PREPARE:
+   rcu_expedited = 1;
+   break;
+   case PM_POST_RESTORE:
+   rcu_expedited = 0;
+   break;
+   default:
+   break;
+   }
+   return NOTIFY_OK;
+}
+
 /*
  * Spawn the kthread that handles this RCU flavor's grace periods.
  */
@@ -3323,6 +3340,7 @@ void __init rcu_init(void)
 * or the scheduler are operational.
 */
cpu_notifier(rcu_cpu_notify, 0);
+   pm_notifier(rcu_pm_notify, 0);
for_each_online_cpu(cpu)
rcu_cpu_notify(NULL, CPU_UP_PREPARE, (void *)(long)cpu);
 }
-- 
1.8.2.135.g7b592fa


-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/