Re: [RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA more precisely

[Hiroshi Doyu]

Hi Joerg,

On Tue, 18 Sep 2012 14:49:18 +0200
Joerg Roedel  wrote:

> On Wed, Aug 29, 2012 at 09:55:30AM +0300, Hiroshi Doyu wrote:
> > The following APIs are needed for us to support the legacy Tegra
> > memory manager for devices("NvMap") with *DMA mapping API*.
> 
> Maybe I am not understanding the need completly. Can you elaborate on
> why this is needed for legacy Tegra?

Actually not for legacy but it's necessary to replace homebrewed
in-kernel API(not upstreamed) with the standard ones. The homebrewed
in-kernel API has been used for the abvoe nvmap as its backend. The
homebrewed ones are being replaced with the standard ones, IOMMU-API,
DMA-API and dma-buf, mainly for transition purpose. I found that some
missing features in DMA-API for that. I posted since other SoCs may
have the similiar requirements, (1) To specify IOVA address at
allocation, and (2) To have IOVA allocation and mapping separately.

> > New API:
> > 
> >  ->iova_alloc(): To allocate IOVA area.
> >  ->iova_alloc_at(): To allocate IOVA area at specific address.
> >  ->iova_free():  To free IOVA area.
> > 
> >  ->map_page_at(): To map page at specific IOVA.
> 
> This sounds like a layering violation. The situation today is as
> follows:
> 
>   DMA-API   : Handle DMA-addresses including an address allocator
>   IOMMU-API : Full control over DMA address space, no address
>   allocator
> 
> So what you want to do add to the DMA-API is already part of the
> IOMMU-API.
>
> Here is my suggestion what you can do instead of extending the DMA-API.
> You can use the IOMMU-API to initialize the device address space with
> any mappings at the IOVAs you need the mappings. In the end you allocate
> another free range in the device address space and use that to satisfy
> DMA-API allocations. Any reason why that could not work?

I guess that it would work. Originally I thought that using DMA-API
and IOMMU-API together in driver might be kind of layering violation
since IOMMU-API itself is used in DMA-API. Only DMA-API used in driver
might be cleaner. Considering that DMA API traditionally handling
*anonymous* {bus,iova} address only, introducing the concept of
specific address in DMA API may not be so encouraged, though.

It would be nice to listen how other SoCs have solved similar needs.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build warning after merge of the final tree (slab tree related)

[Pekka Enberg]

On Tue, 11 Sep 2012, Christoph Lameter wrote:

> On Tue, 11 Sep 2012, Stephen Rothwell wrote:
> 
> > After merging the final tree, today's linux-next build (sparc64 defconfig)
> > produced this warning:
> >
> > mm/slab.c:808:13: warning: '__slab_error' defined but not used 
> > [-Wunused-function]
> >
> > Introduced by commit 945cf2b6199b ("mm/sl[aou]b: Extract a common function 
> > for kmem_cache_destroy").  All uses of slab_error() are now guarded by 
> > DEBUG.
> 
> 
> Subject: Slab: Only define slab_error for DEBUG
> 
> There is no use case left for slab builds without DEBUG.
> 
> Signed-off-by: Christoph Lameter 
> 
> Index: linux/mm/slab.c
> ===
> --- linux.orig/mm/slab.c  2012-09-11 14:44:56.304015235 -0500
> +++ linux/mm/slab.c   2012-09-11 14:48:46.988948440 -0500
> @@ -803,6 +803,7 @@ static void cache_estimate(unsigned long
>   *left_over = slab_size - nr_objs*buffer_size - mgmt_size;
>  }
> 
> +#if DEBUG
>  #define slab_error(cachep, msg) __slab_error(__func__, cachep, msg)
> 
>  static void __slab_error(const char *function, struct kmem_cache *cachep,
> @@ -812,6 +813,7 @@ static void __slab_error(const char *fun
>  function, cachep->name, msg);
>   dump_stack();
>  }
> +#endif
> 
>  /*
>   * By default on NUMA we use alien caches to stage the freeing of
> 

Applied, thanks.

P.S. Guys, please use penb...@kernel.org email address. I missed this 
patch because I don't read this mailbox.

Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/4] Some libtraceevent cleanups/simplifications

[Namhyung Kim]

On Mon, 17 Sep 2012 17:50:45 -0300, Arnaldo Carvalho de Melo wrote:
> Hi Steven,
>
>   Please take a look, while looking at how to do some stuff in 'perf
> test' just for parsing the /format file I ended up with this series, lemme 
> know
> if I can add your Acked-by and push via my perf/core branch.

With my add-on patch, the series looks good to me.  You can add my

  Reviewed-by: Namhyung Kim 

if you want. :)

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

Re: [PATCH] clk: Make the managed clk functions generically available

[Thierry Reding]

On Tue, Sep 18, 2012 at 09:40:14PM +0100, Russell King - ARM Linux wrote:
> On Tue, Sep 18, 2012 at 01:25:55PM +0200, Thierry Reding wrote:
> > On Tue, Sep 18, 2012 at 10:35:36AM +0100, Russell King - ARM Linux wrote:
> > > On Tue, Sep 18, 2012 at 10:00:37AM +0200, Thierry Reding wrote:
> > > > On Sat, Sep 15, 2012 at 10:31:52PM +0100, Russell King - ARM Linux 
> > > > wrote:
> > > > > On Wed, Sep 12, 2012 at 10:43:07PM +0200, Lars-Peter Clausen wrote:
> > > > > > I wouldn't mind having this merged sooner rather than later, there 
> > > > > > is at least
> > > > > > one driver in next which is currently broken due to the missing 
> > > > > > devm_clk_get.
> > > > > > Russell what's your plan for the patch? Maybe under the given 
> > > > > > circumstances it
> > > > > > makes sense to let it go through the m68k tree.
> > > > > 
> > > > > Ok, I've merged it but there was no indication in the patch that it 
> > > > > was
> > > > > supposed to be a fix... there's no cc: to stable.  Does it need to go 
> > > > > to
> > > > > stable?  When was this brokenness introduced?  What's the story for 
> > > > > the
> > > > > m68k bit?
> 
> I said abouve "I've merged it" - that means, I've put it in my
> tree...
> 
> > > > What tree is this supposed to go through? I've checked your ARM tree as
> > > > well as Mike's clock tree but neither seem to carry this patch. The
> > > > reason I ask is because I want to take a patch series that converts the
> > > > Unicore32 PWM code to the PWM framework into linux-next but it depends
> > > > on this patch as well.
> > > 
> > > It /is/ in my tree (you'll notice that it is in linux-next.)  You're
> > > probably looking at my Linaro tree instead, which doesn't carry
> > > anything which isn't about to be sent to Linus.
> > 
> > I must be blind then. next-20120918 doesn't have it. And looking at your
> > tree here[0] doesn't show the commit either.
> 
> Hmm, it's possible I didn't push the tree out... well, I have done so
> now, so it should be visible from tonight onwards and should be in
> -next sometime during the next couple of days (it seems to take a
> couple of days between me pushing stuff out one evening to stuff
> appearing in -next because of the timezones and timing of sfr's pulls.)

Okay, I see it both in your tree and in linux-next now. Thanks!

Thierry


pgpg15zqrzrfc.pgp
Description: PGP signature

[PATCH] tools lib traceevent: Handle alloc_arg failure

[Namhyung Kim]

From: Namhyung Kim 

Now alloc_arg returns NULL if memory allocation failed, it should be
handled on callsites properly.

Signed-off-by: Namhyung Kim 
---
 tools/lib/traceevent/event-parse.c | 98 ++
 1 file changed, 98 insertions(+)

diff --git a/tools/lib/traceevent/event-parse.c 
b/tools/lib/traceevent/event-parse.c
index e8e0fe0443a4..ee4fa1912542 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -1565,6 +1565,14 @@ process_cond(struct event_format *event, struct 
print_arg *top, char **tok)
left = alloc_arg();
right = alloc_arg();
 
+   if (!arg || !left || !right) {
+   do_warning("%s: not enough memory!", __func__);
+   /* arg will be freed at out_free */
+   free_arg(left);
+   free_arg(right);
+   goto out_free;
+   }
+
arg->type = PRINT_OP;
arg->op.left = left;
arg->op.right = right;
@@ -1607,6 +1615,12 @@ process_array(struct event_format *event, struct 
print_arg *top, char **tok)
char *token = NULL;
 
arg = alloc_arg();
+   if (!arg) {
+   do_warning("%s: not enough memory!", __func__);
+   /* '*tok' is set to top->op.op.  No need to free. */
+   *tok = NULL;
+   return EVENT_ERROR;
+   }
 
*tok = NULL;
type = process_arg(event, arg, &token);
@@ -1726,10 +1740,18 @@ process_op(struct event_format *event, struct print_arg 
*arg, char **tok)
 
/* make an empty left */
left = alloc_arg();
+   if (!left) {
+   do_warning("%s(%d): not enough memory!", __func__, 
__LINE__);
+   goto out_free;
+   }
left->type = PRINT_NULL;
arg->op.left = left;
 
right = alloc_arg();
+   if (!right) {
+   do_warning("%s(%d): not enough memory!", __func__, 
__LINE__);
+   goto out_free;
+   }
arg->op.right = right;
 
/* do not free the token, it belongs to an op */
@@ -1739,6 +1761,10 @@ process_op(struct event_format *event, struct print_arg 
*arg, char **tok)
} else if (strcmp(token, "?") == 0) {
 
left = alloc_arg();
+   if (!left) {
+   do_warning("%s(%d): not enough memory!", __func__, 
__LINE__);
+   goto out_free;
+   }
/* copy the top arg to the left */
*left = *arg;
 
@@ -1766,6 +1792,10 @@ process_op(struct event_format *event, struct print_arg 
*arg, char **tok)
   strcmp(token, "!=") == 0) {
 
left = alloc_arg();
+   if (!left) {
+   do_warning("%s(%d): not enough memory!", __func__, 
__LINE__);
+   goto out_free;
+   }
 
/* copy the top arg to the left */
*left = *arg;
@@ -1808,12 +1838,20 @@ process_op(struct event_format *event, struct print_arg 
*arg, char **tok)
}
 
right = alloc_arg();
+   if (!right) {
+   do_warning("%s(%d): not enough memory!", __func__, 
__LINE__);
+   goto out_free;
+   }
type = process_arg_token(event, right, tok, type);
arg->op.right = right;
 
} else if (strcmp(token, "[") == 0) {
 
left = alloc_arg();
+   if (!left) {
+   do_warning("%s(%d): not enough memory!", __func__, 
__LINE__);
+   goto out_free;
+   }
*left = *arg;
 
arg->type = PRINT_OP;
@@ -2201,6 +2239,8 @@ process_fields(struct event_format *event, struct 
print_flag_sym **list, char **
break;
 
arg = alloc_arg();
+   if (!arg)
+   goto out_free;
 
free_token(token);
type = process_arg(event, arg, &token);
@@ -2227,6 +2267,8 @@ process_fields(struct event_format *event, struct 
print_flag_sym **list, char **
 
free_arg(arg);
arg = alloc_arg();
+   if (!arg)
+   goto out_free;
 
free_token(token);
type = process_arg(event, arg, &token);
@@ -2271,6 +2313,10 @@ process_flags(struct event_format *event, struct 
print_arg *arg, char **tok)
arg->type = PRINT_FLAGS;
 
field = alloc_arg();
+   if (!field) {
+   do_warning("%s: not enough memory!", __func__);
+   goto out_free;
+   }
 
type = process_arg(event, field, &token);
 
@@ -2318,6 +2364,10 @@ process_symbols(struct event_format *event, struct 
print_arg *arg, char **tok)
arg->type = PRINT_SYMBOL;
 
field = a

Re: [PATCH] pwm_backlight: Add device tree support for Low Threshold Brightness

[Thierry Reding]

On Wed, Aug 01, 2012 at 06:51:21AM +, Philip, Avinash wrote:
> On Mon, Jul 30, 2012 at 12:28:05, Thierry Reding wrote:
> > On Wed, Jul 25, 2012 at 05:54:02PM +0530, Philip, Avinash wrote:
> > > Low Threshold Brightness should be configured to have a linear relation
> > > in brightness scale. This patch adds device tree support for low
> > > threshold brightness as optional one for pwm_backlight.
> > 
> > I think this should be more explicit as to why this is required, perhaps
> > something like this:
> > 
> > Some backlights perform poorly when driven by a PWM with a short
> > duty-cycle. For such devices, the low threshold can be used to
> > specify a lower bound for the duty-cycle and should be chosen to
> > exclude the problematic range.
> > 
> > This patch adds support for an optional low-threshold-brightness
> > property.
> 
> Ok I will correct it.
> 
> > 
> > Perhaps a similar explanation should be given somewhere else instead of
> > just the changelog. It took me some time to understand what exactly this
> > low threshold means and I think it'd make sense to write this kind of
> > information down somewhere. I'll see if I can make time to add a bit of
> > documentation somewhere below Documentation/backlight perhaps.
> > 
> > > Signed-off-by: Philip, Avinash 
> > > ---
> > > :100644 100644 1e4fc72... 5c54380... M
> > > Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
> > > :100644 100644 995f016... 4965408... Mdrivers/video/backlight/pwm_bl.c
> > >  .../bindings/video/backlight/pwm-backlight.txt |   21 
> > > 
> > >  drivers/video/backlight/pwm_bl.c   |5 
> > >  2 files changed, 26 insertions(+), 0 deletions(-)
> > > 
> > > diff --git 
> > > a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt 
> > > b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
> > > index 1e4fc72..5c54380 100644
> > > --- a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
> > > +++ b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
> > > @@ -14,6 +14,8 @@ Required properties:
> > >  Optional properties:
> > >- pwm-names: a list of names for the PWM devices specified in the
> > > "pwms" property (see PWM binding[0])
> > > +  - low_threshold_brightness: brightness threshold low level. (get linear
> > > +  scales in brightness in low end of brightness levels)
> > 
> > The convention is to use dashes, not underscores, in device tree
> > property names, so this should be "low-threshold-brightness". I'd also
> > omit the comment in parentheses because the DT binding document
> > shouldn't specify any particular use-case. However I think it'd make
> > sense to add some information about the number space of the low
> > threshold value.
> 
> Ok, I will correct it.
> 
> > 
> > Maybe we should also rethink how the low threshold is handled in cases
> > where the brightness levels are used. I'm not sure it makes sense to
> > specify the low threshold as a value relative to the range given by the
> > levels. Perhaps it is more meaningful to specify it as relative to the
> > period/duty-cycle.
> > 
> > >  
> > >  [0]: Documentation/devicetree/bindings/pwm/pwm.txt
> > >  
> > > @@ -26,3 +28,22 @@ Example:
> > >   brightness-levels = <0 4 8 16 32 64 128 255>;
> > >   default-brightness-level = <6>;
> > >   };
> > > +
> > > +Example for brightness_threshold_level:
> > > +
> > > + backlight {
> > > + compatible  = "pwm-backlight";
> > > + pwms = <&pwm 0 5>;
> > > +
> > > + brightness-levels = <0 4 8 16 32 64 128 255>;
> > > + default-brightness-level = <6>;
> > > + low_threshold_brightness = <50>;
> > > + };
> > > +};
> > 
> > I think you can just merge the low-threshold-brightness with the
> > previous example.
> 
> Ok I will check and correct it.
> 
> > 
> > > +Note:
> > > +Low threshold support is required to have linear brightness scale from
> > > +0 to max. For some panels, backlight absent on low end of brightness
> > > +scale. So support for Low Threshold been required. So that the scale of
> > > +brightness changed from Low Threshold to Max in scales defined in
> > > +brightness-levels. In this example 20% maximum brightness scale should
> > > +be required to turn on panel backlight.
> > 
> > I think this kind of documentation doesn't belong in the device tree
> > binding. I'll work something like that into the proper documentation.
> > 
> > > diff --git a/drivers/video/backlight/pwm_bl.c 
> > > b/drivers/video/backlight/pwm_bl.c
> > > index 995f016..4965408 100644
> > > --- a/drivers/video/backlight/pwm_bl.c
> > > +++ b/drivers/video/backlight/pwm_bl.c
> > > @@ -143,6 +143,11 @@ static int pwm_backlight_parse_dt(struct device *dev,
> > >  
> > >   data->dft_brightness = value;
> > >   data->max_brightness--;
> > > +
> > > + ret = of_property_read_u

[PATCH V2] poweroff: fix bug in orderly_poweroff

[hongfeng]

orderly_poweroff is trying to poweroff platform by two steps:
step 1: Call userspace application to poweroff
step 2: If userspace poweroff fail, then do a force power off if force param is 
set.

The bug here is, step 1 is always successful with param UMH_NO_WAIT,
should change to UMH_WAIT_EXEC which will monitor whether user application 
successful run.

Change-Id: I2f9ebbb90c0c2443780080ec9507c8d004e5da74
Signed-off-by: Feng Hong 
Acked-by: Kees Cook 
---
 kernel/sys.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/sys.c b/kernel/sys.c
index 241507f..a624d4c 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -2204,7 +2204,7 @@ static int __orderly_poweroff(void)
return -ENOMEM;
}
 
-   ret = call_usermodehelper_fns(argv[0], argv, envp, UMH_NO_WAIT,
+   ret = call_usermodehelper_fns(argv[0], argv, envp, UMH_WAIT_EXEC,
  NULL, argv_cleanup, NULL);
if (ret == -ENOMEM)
argv_free(argv);
-- 
1.7.0.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 V2] poweroff: fix bug in orderly_poweroff

[hongfeng]

orderly_poweroff is trying to poweroff platform by two steps:
step 1: Call userspace application to poweroff
step 2: If userspace poweroff fail, then do a force power off if force param is 
set.

The bug here is, step 1 is always successful with param UMH_NO_WAIT,
should change to UMH_WAIT_EXEC which will monitor whether user application 
successful run.

Change-Id: I2f9ebbb90c0c2443780080ec9507c8d004e5da74
Signed-off-by: Feng Hong 
---
 kernel/sys.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/sys.c b/kernel/sys.c
index 241507f..a624d4c 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -2204,7 +2204,7 @@ static int __orderly_poweroff(void)
return -ENOMEM;
}
 
-   ret = call_usermodehelper_fns(argv[0], argv, envp, UMH_NO_WAIT,
+   ret = call_usermodehelper_fns(argv[0], argv, envp, UMH_WAIT_EXEC,
  NULL, argv_cleanup, NULL);
if (ret == -ENOMEM)
argv_free(argv);
-- 
1.7.0.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] poweroff: fix bug in orderly_poweroff

[Feng Hong]

Hi, Eric,

I agree with your idea, I'll prepare another patch, thanks for remind this 
possible issue.

--
Best Regards,
Feng Hong
Application Processor Software Engnieer 
Marvell Technology (Shanghai) Ltd


-Original Message-
From: Eric W. Biederman [mailto:ebied...@xmission.com] 
Sent: 2012年9月19日 13:58
To: Feng Hong
Cc: a...@linux-foundation.org; gorcu...@openvz.org; keesc...@chromium.org; 
serge.hal...@canonical.com; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] poweroff: fix bug in orderly_poweroff

Feng Hong  writes:

> Hi, Eric
>
> 1. We are developing on an Android phone platform, we use thermal
> framework to monitor the temperature, when the temperature above like
> 110 degree, thermal framework will use orderly_shutdown to shutdown
> phone, however, on Android platform there is no " /sbin/poweroff " cmd
> ready . Then we want "fail ret" to trigger force shutdown (use
> kernel_power_off), but always we get "suc ret"

> 2. Here the caller just wait for "poweroff" userspace application, if
> it block the called, then it's the "poweroff" problem itself

> 3. As in the original orderly_shutdown design, we must get the right
> "ret", if this ret is always "0", then it obey orderly_poweroff design
> goal. Step 2: force shutdown is always useless code. 

That sounds like a clear case that we need to change it to
UMH_WAIT_EXEC.

Changing it to UMH_WAIT_PROC seems much more dangerous.

Eric
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: [PATCH v2 1/1] USB: EHCI: Tegra: Fix wrong register definition

[Greg KH]

On Wed, Sep 19, 2012 at 11:48:50AM +0800, Jim Lin wrote:
> Fix the issue that EHCI registers, hostpc[0] and usbmode_ex,
> are not correctly accessed on Tegra3 platform.
> 
> Signed-off-by: Jim Lin 
> ---
> Changes in v2:
> - Modify array size for reserved4[] only.
> - Note that defining hostpc[0] is for a variable-length object.

Didn't I already apply V1 of this patch?  Can you now send me a fixup
given that the first patch had a problem?

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/

linux-next: Tree for Sept 19

[Stephen Rothwell]

Hi all,

Changes since 201209018:

The bluetooth tree gained a build failure so I used the version from
next-20120918.

The workqueues tree gained a conflict against the pm tree.

The usb tree gained a conflict against the tty tree and a build failure
for which I applied a merge fix patch.

The staging tree gained a conflict against the usb tree.

The signal tree gained a conflict against the sh tree.

The akpm tree lost a few problematic patches.



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc,
sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 200 trees (counting Linus' and 26 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (925a6f0 Merge tag 'hwspinlock-3.6-fix' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock)
Merging fixes/master (9023a40 Merge tag 'mmc-fixes-for-3.5-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc)
Merging kbuild-current/rc-fixes (6c7080a firmware: fix directory creation rule 
matching with make 3.82)
Merging arm-current/fixes (6f7dad7 Merge branch 'clkdev' into fixes)
Merging m68k-current/for-linus (3be7184 m68k: Add missing RCU idle APIs on idle 
loop)
Merging powerpc-merge/merge (636802e powerpc: Don't use __put_user() in 
patch_instruction)
Merging sparc/master (5698bd7 Linux 3.6-rc6)
Merging net/master (59d86c7 e1000: Small packets may get corrupted during 
padding by HW)
Merging sound-current/for-linus (5d037f9 Merge tag 'asoc-3.6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (0ff9514 PCI: Don't print anything while decoding 
is disabled)
Merging wireless/master (e020a83 brcmfmac: Fix big endian host configuration 
data.)
Merging driver-core.current/driver-core-linus (5698bd7 Linux 3.6-rc6)
Merging tty.current/tty-linus (5698bd7 Linux 3.6-rc6)
Merging usb.current/usb-linus (5698bd7 Linux 3.6-rc6)
Merging staging.current/staging-linus (5698bd7 Linux 3.6-rc6)
Merging char-misc.current/char-misc-linus (fea7a08 Linux 3.6-rc3)
Merging input-current/for-linus (6f4d038 Input: wacom - add support for EMR on 
Cintiq 24HD touch)
Merging md-current/for-linus (58e94ae md/raid1: close some possible races on 
write errors during resync)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (9b2f4cb crypto: authenc - Fix crash with 
zero-length assoc data)
Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops)
Merging dwmw2/master (244dc4e Merge 
git://git.infradead.org/users/dwmw2/random-2.6)
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs 
formatting)
Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for 
of_parse_phandle_with_args)
Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using 
proper "spi:" modalias prefixes.)
Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, 
remove cast)
Merging arm/for-next (18824d9 Merge branches 'arch-timers', 'atags&#x

Davicom DM9000C driver

[黃偉格]

Hi,

I'm Allen Huang from Davicom. We are hereby opensourcing the linux
driver for our DM9000C. 

We would appreciate any comments that you have on our driver and
whether it is ready to go into the kernel. Please see DM9000C driver in the
attachment.

Best regards, 

Allen



dm9000_KT2.6.31.c
Description: Binary data


dm9000_KT2.6.31.h
Description: Binary data

Re: [PATCH] mfd: use IRQF_ONESHOT for twl6040

[Peter Ujfalusi]

On 09/19/2012 04:32 AM, Fengguang Wu wrote:
> Generated by: scripts/coccinelle/misc/irqf_oneshot.cocci
> 
> Make sure threaded IRQs without a primary handler are always request
> with IRQF_ONESHOT.
> 
> Signed-off-by: Fengguang Wu 

Acked-by: Peter Ujfalusi 

> ---
> 
> Please take the patch only if it's a positive warning. Thanks!
> 
>  drivers/mfd/twl6040-core.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- linux.orig/drivers/mfd/twl6040-core.c 2012-09-18 08:22:36.381180459 
> +0800
> +++ linux/drivers/mfd/twl6040-core.c  2012-09-19 09:27:15.947969313 +0800
> @@ -584,7 +584,7 @@ static int __devinit twl6040_probe(struc
>   goto irq_init_err;
>  
>   ret = request_threaded_irq(twl6040->irq_base + TWL6040_IRQ_READY,
> -NULL, twl6040_naudint_handler, 0,
> +NULL, twl6040_naudint_handler, IRQF_ONESHOT,
>  "twl6040_irq_ready", twl6040);
>   if (ret) {
>   dev_err(twl6040->dev, "READY IRQ request failed: %d\n",
> 

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

[PATCH 0/3] Introduce devm_clk_register()

[Stephen Boyd]

The first patch in this series fixes error checking in the wm831x clock
driver and is here to prevent context conflicts in the third patch.
I split it out in case it needed to merge sooner rather than later.

The goal of this series is to add devm_clk_register() so I can use it in
some MSM clock code I'm sending out in the near future. The second 
patch adds the API and the third patch moves over an existing user of
clk_unregister() to the devm API.

Stephen Boyd (3):
  clk: wm831x: Fix clk_register() error code checking
  clk: Add devm_clk_{register,unregister}()
  clk: wm831x: Use devm_clk_register() to simplify code

 drivers/clk/clk-wm831x.c |  34 -
 drivers/clk/clk.c| 111 +++
 include/linux/clk-provider.h |   2 +
 3 files changed, 101 insertions(+), 46 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

[PATCH 2/3] clk: Add devm_clk_{register,unregister}()

[Stephen Boyd]

Some clock drivers can be simplified if devres takes care of
unregistering any registered clocks along error paths. Introduce
devm_clk_register() so that clock drivers get unregistration for
free along with simplified error paths.

Signed-off-by: Stephen Boyd 
---
 drivers/clk/clk.c| 111 +++
 include/linux/clk-provider.h |   2 +
 2 files changed, 92 insertions(+), 21 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 56e4495e..6852809 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static DEFINE_SPINLOCK(enable_lock);
 static DEFINE_MUTEX(prepare_lock);
@@ -1361,28 +1362,9 @@ struct clk *__clk_register(struct device *dev, struct 
clk_hw *hw)
 }
 EXPORT_SYMBOL_GPL(__clk_register);
 
-/**
- * clk_register - allocate a new clock, register it and return an opaque cookie
- * @dev: device that is registering this clock
- * @hw: link to hardware-specific clock data
- *
- * clk_register is the primary interface for populating the clock tree with new
- * clock nodes.  It returns a pointer to the newly allocated struct clk which
- * cannot be dereferenced by driver code but may be used in conjuction with the
- * rest of the clock API.  In the event of an error clk_register will return an
- * error code; drivers must test for an error code after calling clk_register.
- */
-struct clk *clk_register(struct device *dev, struct clk_hw *hw)
+static int _clk_register(struct device *dev, struct clk_hw *hw, struct clk 
*clk)
 {
int i, ret;
-   struct clk *clk;
-
-   clk = kzalloc(sizeof(*clk), GFP_KERNEL);
-   if (!clk) {
-   pr_err("%s: could not allocate clk\n", __func__);
-   ret = -ENOMEM;
-   goto fail_out;
-   }
 
clk->name = kstrdup(hw->init->name, GFP_KERNEL);
if (!clk->name) {
@@ -1420,7 +1402,7 @@ struct clk *clk_register(struct device *dev, struct 
clk_hw *hw)
 
ret = __clk_init(dev, clk);
if (!ret)
-   return clk;
+   return 0;
 
 fail_parent_names_copy:
while (--i >= 0)
@@ -1429,6 +1411,36 @@ fail_parent_names_copy:
 fail_parent_names:
kfree(clk->name);
 fail_name:
+   return ret;
+}
+
+/**
+ * clk_register - allocate a new clock, register it and return an opaque cookie
+ * @dev: device that is registering this clock
+ * @hw: link to hardware-specific clock data
+ *
+ * clk_register is the primary interface for populating the clock tree with new
+ * clock nodes.  It returns a pointer to the newly allocated struct clk which
+ * cannot be dereferenced by driver code but may be used in conjuction with the
+ * rest of the clock API.  In the event of an error clk_register will return an
+ * error code; drivers must test for an error code after calling clk_register.
+ */
+struct clk *clk_register(struct device *dev, struct clk_hw *hw)
+{
+   int ret;
+   struct clk *clk;
+
+   clk = kzalloc(sizeof(*clk), GFP_KERNEL);
+   if (!clk) {
+   pr_err("%s: could not allocate clk\n", __func__);
+   ret = -ENOMEM;
+   goto fail_out;
+   }
+
+   ret = _clk_register(dev, hw, clk);
+   if (!ret)
+   return clk;
+
kfree(clk);
 fail_out:
return ERR_PTR(ret);
@@ -1444,6 +1456,63 @@ EXPORT_SYMBOL_GPL(clk_register);
 void clk_unregister(struct clk *clk) {}
 EXPORT_SYMBOL_GPL(clk_unregister);
 
+static void devm_clk_release(struct device *dev, void *res)
+{
+   clk_unregister(res);
+}
+
+/**
+ * devm_clk_register - resource managed clk_register()
+ * @dev: device that is registering this clock
+ * @hw: link to hardware-specific clock data
+ *
+ * Managed clk_register(). Clocks returned from this function are
+ * automatically clk_unregister()ed on driver detach. See clk_register() for
+ * more information.
+ */
+struct clk *devm_clk_register(struct device *dev, struct clk_hw *hw)
+{
+   struct clk *clk;
+   int ret;
+
+   clk = devres_alloc(devm_clk_release, sizeof(*clk), GFP_KERNEL);
+   if (!clk)
+   return ERR_PTR(-ENOMEM);
+
+   ret = _clk_register(dev, hw, clk);
+   if (!ret) {
+   devres_add(dev, clk);
+   } else {
+   devres_free(clk);
+   clk = ERR_PTR(ret);
+   }
+
+   return clk;
+}
+EXPORT_SYMBOL_GPL(devm_clk_register);
+
+static int devm_clk_match(struct device *dev, void *res, void *data)
+{
+   struct clk *c = res;
+   if (WARN_ON(!c))
+   return 0;
+   return c == data;
+}
+
+/**
+ * devm_clk_unregister - resource managed clk_unregister()
+ * @clk: clock to unregister
+ *
+ * Deallocate a clock allocated with devm_clk_register(). Normally
+ * this function will not need to be called and the resource management
+ * code will ensure that the resource is freed.
+ */
+void devm_clk_unregister(struct device *dev, struct clk *clk)
+{
+   WARN_ON(dev

[PATCH 3/3] clk: wm831x: Use devm_clk_register() to simplify code

[Stephen Boyd]

Move this driver to use devm_clk_register() to simplify some
error paths and reduce lines of code.

Cc: Mark Brown 
Signed-off-by: Stephen Boyd 
---
 drivers/clk/clk-wm831x.c | 30 +++---
 1 file changed, 7 insertions(+), 23 deletions(-)

diff --git a/drivers/clk/clk-wm831x.c b/drivers/clk/clk-wm831x.c
index eb1afaf..db4fbf2 100644
--- a/drivers/clk/clk-wm831x.c
+++ b/drivers/clk/clk-wm831x.c
@@ -370,43 +370,27 @@ static __devinit int wm831x_clk_probe(struct 
platform_device *pdev)
clkdata->xtal_ena = ret & WM831X_XTAL_ENA;
 
clkdata->xtal_hw.init = &wm831x_xtal_init;
-   clkdata->xtal = clk_register(&pdev->dev, &clkdata->xtal_hw);
+   clkdata->xtal = devm_clk_register(&pdev->dev, &clkdata->xtal_hw);
if (IS_ERR(clkdata->xtal))
return PTR_ERR(clkdata->xtal);
 
clkdata->fll_hw.init = &wm831x_fll_init;
-   clkdata->fll = clk_register(&pdev->dev, &clkdata->fll_hw);
-   if (IS_ERR(clkdata->fll)) {
-   ret = PTR_ERR(clkdata->fll);
-   goto err_xtal;
-   }
+   clkdata->fll = devm_clk_register(&pdev->dev, &clkdata->fll_hw);
+   if (IS_ERR(clkdata->fll))
+   return PTR_ERR(clkdata->fll);
 
clkdata->clkout_hw.init = &wm831x_clkout_init;
-   clkdata->clkout = clk_register(&pdev->dev, &clkdata->clkout_hw);
-   if (IS_ERR(clkdata->clkout)) {
-   ret = PTR_ERR(clkdata->clkout);
-   goto err_fll;
-   }
+   clkdata->clkout = devm_clk_register(&pdev->dev, &clkdata->clkout_hw);
+   if (IS_ERR(clkdata->clkout))
+   return PTR_ERR(clkdata->clkout);
 
dev_set_drvdata(&pdev->dev, clkdata);
 
return 0;
-
-err_fll:
-   clk_unregister(clkdata->fll);
-err_xtal:
-   clk_unregister(clkdata->xtal);
-   return ret;
 }
 
 static int __devexit wm831x_clk_remove(struct platform_device *pdev)
 {
-   struct wm831x_clk *clkdata = dev_get_drvdata(&pdev->dev);
-
-   clk_unregister(clkdata->clkout);
-   clk_unregister(clkdata->fll);
-   clk_unregister(clkdata->xtal);
-
return 0;
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

[PATCH 1/3] clk: wm831x: Fix clk_register() error code checking

[Stephen Boyd]

clk_register() returns an ERR_PTR upon failure, not NULL. Fix
these error paths.

Cc: Mark Brown 
Signed-off-by: Stephen Boyd 
---
 drivers/clk/clk-wm831x.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/clk-wm831x.c b/drivers/clk/clk-wm831x.c
index e7b7765..eb1afaf 100644
--- a/drivers/clk/clk-wm831x.c
+++ b/drivers/clk/clk-wm831x.c
@@ -371,20 +371,20 @@ static __devinit int wm831x_clk_probe(struct 
platform_device *pdev)
 
clkdata->xtal_hw.init = &wm831x_xtal_init;
clkdata->xtal = clk_register(&pdev->dev, &clkdata->xtal_hw);
-   if (!clkdata->xtal)
-   return -EINVAL;
+   if (IS_ERR(clkdata->xtal))
+   return PTR_ERR(clkdata->xtal);
 
clkdata->fll_hw.init = &wm831x_fll_init;
clkdata->fll = clk_register(&pdev->dev, &clkdata->fll_hw);
-   if (!clkdata->fll) {
-   ret = -EINVAL;
+   if (IS_ERR(clkdata->fll)) {
+   ret = PTR_ERR(clkdata->fll);
goto err_xtal;
}
 
clkdata->clkout_hw.init = &wm831x_clkout_init;
clkdata->clkout = clk_register(&pdev->dev, &clkdata->clkout_hw);
-   if (!clkdata->clkout) {
-   ret = -EINVAL;
+   if (IS_ERR(clkdata->clkout)) {
+   ret = PTR_ERR(clkdata->clkout);
goto err_fll;
}
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

Re: [PATCH] poweroff: fix bug in orderly_poweroff

[Eric W. Biederman]

Feng Hong  writes:

> Hi, Eric
>
> 1. We are developing on an Android phone platform, we use thermal
> framework to monitor the temperature, when the temperature above like
> 110 degree, thermal framework will use orderly_shutdown to shutdown
> phone, however, on Android platform there is no " /sbin/poweroff " cmd
> ready . Then we want "fail ret" to trigger force shutdown (use
> kernel_power_off), but always we get "suc ret"

> 2. Here the caller just wait for "poweroff" userspace application, if
> it block the called, then it's the "poweroff" problem itself

> 3. As in the original orderly_shutdown design, we must get the right
> "ret", if this ret is always "0", then it obey orderly_poweroff design
> goal. Step 2: force shutdown is always useless code. 

That sounds like a clear case that we need to change it to
UMH_WAIT_EXEC.

Changing it to UMH_WAIT_PROC seems much more dangerous.

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

Re: lve module taint?

[Michael Tokarev]

On 19.09.2012 06:02, Rusty Russell wrote:

> From: Matthew Garrett 
> Subject: module: taint kernel when lve module is loaded
> Date: Fri, 22 Jun 2012 13:49:31 -0400
> 
> Cloudlinux have a product called lve that includes a kernel module. This
> was previously GPLed but is now under a proprietary license, but the
> module continues to declare MODULE_LICENSE("GPL") and makes use of some
> EXPORT_SYMBOL_GPL symbols. Forcibly taint it in order to avoid this.

> + /* lve claims to be GPL but upstream won't provide source */
> + if (strcmp(mod->name, "lve") == 0)
> + add_taint_module(mod, TAINT_PROPRIETARY_MODULE);

This is setting a, in my opinion, rather bad precedent.  Next we'll
be adding various modules here due to various reasons.

I think this case should be pure political now, not technical.  Ie,
if some project declares itself as GPL, it is not kernel task to
verify that the sources are available or to enforce that.

Thanks,

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mmc: omap_hsmmc: Pass on the suspend failure to the PM core

[Chris Ball]

Hi,

On Mon, Sep 17 2012, S, Venkatraman wrote:
> On Thu, Sep 13, 2012 at 12:01 PM, Hebbar, Gururaja
>  wrote:
>> From: Vaibhav Bedia 
>>
>> In some cases mmc_suspend_host() is not able to claim the
>> host and proceed with the suspend process. The core returns
>> -EBUSY to the host controller driver. Unfortunately, the
>> host controller driver does not pass on this information
>> to the PM core and hence the system suspend process continues.
>>
>> ret = mmc_suspend_host(host->mmc);
>> if (ret) {
>> host->suspended = 0;
>> if (host->pdata->resume) {
>> ret = host->pdata->resume(dev, host->slot_id);
>>
>> The return status from mmc_suspend_host() is overwritten by return
>> status from host->pdata->resume. So the original return status is lost.
>>
>> In these cases the MMC core gets to an unexpected state
>> during resume and multiple issues related to MMC crop up.
>> 1. Host controller driver starts accessing the device registers
>> before the clocks are enabled which leads to a prefetch abort.
>> 2. A file copy thread which was launched before suspend gets
>> stuck due to the host not being reclaimed during resume.
>>
>> To avoid such problems pass on the -EBUSY status to the PM core
>> from the host controller driver. With this change, MMC core
>> suspend might still fail but it does not end up making the
>> system unusable. Suspend gets aborted and the user can try
>> suspending the system again.
>>
>> Signed-off-by: Vaibhav Bedia 
>> Signed-off-by: Hebbar, Gururaja 
>
> This version is good.
>
> Acked-by: Venkatraman S 

Thanks, pushed to mmc-next for 3.7, with a stable@ tag added (right?).

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ACPI: Add new sysfs interface to export device description

[Yasuaki Ishimatsu]

Hi Lance,

2012/09/08 1:28, Lance Ortiz wrote:
> Add support to export the device description obtained from the ACPI _STR
> method, if one exists for a device, to user-space via a sysfs interface.
> This new interface provides a standard and platform neutral way for users
> to obtain the description text stored in the ACPI _STR method.  If no
> _STR method exists for the device, no sysfs 'description' file will be
> created.  The 'description' file will be located in the /sys/devices/
> directory using the device's path.
> 
> /sys/device///.../firmware_node/description
> 
> Example:
> 
> /sys/devices/pci:00/:00.07.0/:0e:00.0/firmware_node/description
> 
> It can also be located using the ACPI device path, for example:
> 
> /sys/devices/LNXSYSTM:00/device:00/ACPI0004:00/PNP0A08:00/device:13/device:15/description
> /sys/devices/LNXSYSTM:00/device:00/ACPI0004:00/ACPI0004:01/ACPI0007:02/description
> 
> Execute the 'cat' command on the 'description' file to obtain the
> description string for that device.
> 
> This patch also includes documentation describing how the new sysfs
> interface works
> 
> Signed-off-by: Lance Ortiz 
> ---

Tested-by: Yasuaki Ishimatsu 

There is a comment as follows. 

>   .../ABI/testing/sysfs-devices-firmware_node|   17 ++
>   drivers/acpi/scan.c|   58 
> +++-
>   include/acpi/acpi_bus.h|1 +
>   3 files changed, 74 insertions(+), 2 deletions(-)
>   create mode 100644 Documentation/ABI/testing/sysfs-devices-firmware_node
> 
> diff --git a/Documentation/ABI/testing/sysfs-devices-firmware_node 
> b/Documentation/ABI/testing/sysfs-devices-firmware_node
> new file mode 100644
> index 000..46badc9
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-devices-firmware_node
> @@ -0,0 +1,17 @@
> +What:/sys/devices/.../firmware_node/
> +Date:September 2012
> +Contact: <>
> +Description:
> + The /sys/devices/.../firmware_node directory contains attributes
> + allowing the user space to check and modify some firmware
> + related properties of given device.
> +
> +What:/sys/devices/.../firmware_node/description
> +Date:September 2012
> +Contact: Lance Ortiz 
> +Description:
> + The /sys/devices/.../firmware/description attribute contains a 
> string
> + that describes the device as provided by the _STR method in the 
> ACPI
> + namespace.  This attribute is read-only.  If the device does 
> not have
> + an _STR method associated with it in the ACPI namespace, this
> + attribute is not present.
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index c8a1f3b..c9c91e1 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -10,6 +10,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   
>   #include 
>   
> @@ -192,8 +193,38 @@ end:
>   }
>   static DEVICE_ATTR(path, 0444, acpi_device_path_show, NULL);
>   
> +/* sysfs file that shows description text from the ACPI _STR method */
> +static ssize_t description_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf) {
> + struct acpi_device *acpi_dev = to_acpi_device(dev);
> + int result;
> +
> + if (acpi_dev->pnp.str_obj == NULL) {
> + result = sprintf(buf, "No Description\n");
> + goto end;
> + }
> +
> + /*
> +  * The _STR object contains a Unicode identifier for a device.
> +  * We need to convert to utf-8 so it can be displayed.
> +  */
> + result = utf16s_to_utf8s(
> + (wchar_t *)acpi_dev->pnp.str_obj->buffer.pointer,
> + acpi_dev->pnp.str_obj->buffer.length,
> + UTF16_LITTLE_ENDIAN, buf,
> + PAGE_SIZE);
> +
> + buf[result++] = '\n';
> +
> +end:
> + return result;
> +}
> +static DEVICE_ATTR(description, 0444, description_show, NULL);
> +
>   static int acpi_device_setup_files(struct acpi_device *dev)
>   {
> + struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
>   acpi_status status;
>   acpi_handle temp;
>   int result = 0;
> @@ -217,6 +248,21 @@ static int acpi_device_setup_files(struct acpi_device 
> *dev)
>   goto end;
>   }
>   
> + /*
> +  * If device has _STR, 'description' file is created
> +  */
> + status = acpi_get_handle(dev->handle, "_STR", &temp);
> + if (ACPI_SUCCESS(status)) {
> + status = acpi_evaluate_object(dev->handle, "_STR",
> + NULL, &buffer);
> + if (ACPI_FAILURE(status))
> + buffer.pointer = NULL;
> + dev->pnp.str_obj = buffer.pointer;
> + result = device_create_file(&dev->dev, &dev_attr_description);

A description sysfs is created even if "acpi_evaluate_objec

Re: [PATCH 1/2] module: add syscall to load module from fd

[Rusty Russell]

Mimi Zohar  writes:

> On Wed, 2012-09-12 at 17:04 +0930, Rusty Russell wrote:
>> "H. Peter Anvin"  writes:
>> 
>> > On 09/06/2012 11:13 AM, Kees Cook wrote:
>> >> Instead of (or in addition to) kernel module signing, being able to reason
>> >> about the origin of a kernel module would be valuable in situations
>> >> where an OS already trusts a specific file system, file, etc, due to
>> >> things like security labels or an existing root of trust to a partition
>> >> through things like dm-verity.
>> >>
>> >> This introduces a new syscall (currently only on x86), similar to
>> >> init_module, that has only two arguments. The first argument is used as
>> >> a file descriptor to the module and the second argument is a pointer to
>> >> the NULL terminated string of module arguments.
>> >>
>> >
>> > Please use the standard naming convention, which is an f- prefix (i.e. 
>> > finit_module()).
>> 
>> Good point; I just did a replace here.
>
> Have you pushed out the changes?  And if so, to where?

No, I kept them in my patch series but out of linux-next, since I
thought you disliked the placement of the security hooks?

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

lve module taint?

[Rusty Russell]

Hi all,

I still have this patch sitting in my queue for next merge
window; I missed the previous one.  Is it still current?

Thanks,
Rusty.

From:   Matthew Garrett 
Subject: module: taint kernel when lve module is loaded
Date: Fri, 22 Jun 2012 13:49:31 -0400

Cloudlinux have a product called lve that includes a kernel module. This
was previously GPLed but is now under a proprietary license, but the
module continues to declare MODULE_LICENSE("GPL") and makes use of some
EXPORT_SYMBOL_GPL symbols. Forcibly taint it in order to avoid this.

Signed-off-by: Matthew Garrett 
Cc: Alex Lyashkov 
Signed-off-by: Rusty Russell 
Cc: sta...@kernel.org
---
 kernel/module.c |4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/module.c b/kernel/module.c
index 4edbd9c..9ad9ee9 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2730,6 +2730,10 @@ static int check_module_license_and_versions(struct 
module *mod)
if (strcmp(mod->name, "driverloader") == 0)
add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
 
+   /* lve claims to be GPL but upstream won't provide source */
+   if (strcmp(mod->name, "lve") == 0)
+   add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
+
 #ifdef CONFIG_MODVERSIONS
if ((mod->num_syms && !mod->crcs)
|| (mod->num_gpl_syms && !mod->gpl_crcs)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 repost] virtio: don't crash when device is buggy

[Rusty Russell]

"Michael S. Tsirkin"  writes:

> On Mon, Sep 17, 2012 at 01:57:17PM +0930, Rusty Russell wrote:
>> "Michael S. Tsirkin"  writes:
>> 
>> > Because of a sanity check in virtio_dev_remove, a buggy device can crash
>> > kernel.  And in case of rproc it's userspace so it's not a good idea.
>> > We are unloading a driver so how bad can it be?
>> > Be less aggressive in handling this error: if it's a driver bug,
>> > warning once should be enough.
>> >
>> > Signed-off-by: Michael S. Tsirkin 
>> >
>> > --
>> >
>> > 3.6 material?
>> 
>> I have already applied, this, but it's not for stable, since it's a
>> "theoretical bugfix".  That check has been in there forever and noone
>> AFAIK has actually struck it.
>> 
>> Cheers,
>> Rusty.
>
> Yes but can't malicious userspace trigger this with remoteproc? If yes
> it's not a question of whether anyone has struck it since people don't
> normally run malicious userspace :)

I think that malicious userspace is already priveleged, isn't it?

Cheers,
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 v3] gpio: Add Avionic Design N-bit GPIO expander support

[Thierry Reding]

On Tue, Sep 18, 2012 at 11:29:46PM +0200, Linus Walleij wrote:
> On Tue, Sep 18, 2012 at 10:57 AM, Thierry Reding
>  wrote:
> 
> > This commit adds a driver for the Avionic Design N-bit GPIO expander.
> > The expander provides a variable number of GPIO pins with interrupt
> > support.
> 
> And you followed up on absolutely everything I commented so how
> could I resist this patch ... applied with Rob's ACK!

There's this one issue that was discussed in the GPIO binding update
that I posted earlier and I was going to send an updated patch and then
make this patch reference the documentation but I can just go and do
that in a follow-up patch as well.

Thierry


pgpFSLoLTSmK6.pgp
Description: PGP signature

Re: [PATCH v2 0/2] mfd: twl: Move PWM driver to PWM framework

[Thierry Reding]

On Wed, Sep 19, 2012 at 02:24:59AM +0200, Samuel Ortiz wrote:
> Hi Thierry,
> 
> On Mon, Sep 10, 2012 at 02:10:18PM +0200, Thierry Reding wrote:
> > Hi,
> > 
> > This mini series replaces the twl_has_*() macros by the equivalent
> > standard IS_ENABLED() macro and moves the PWM driver to the PWM
> > framework.
> > 
> > I'll take the second patch through the PWM tree but would like to have
> > some Acked-bys from people that know and have the hardware and can
> > verify that I haven't broken anything.
> We're already going to have conflicts for twl-core.c as Tony is pushing some
> code for it through his tree. So, would you be ok with me carrying the whole
> series through the MFD tree ?

Yes, that's okay with me.

Thierry


pgpafrTtAcWCU.pgp
Description: PGP signature

Re: [PATCH 0/6][RFC] Rework vsyscall to avoid truncation/rounding issue in timekeeping core

[Andy Lutomirski]

On Tue, Sep 18, 2012 at 9:50 PM, Richard Cochran
 wrote:
> On Tue, Sep 18, 2012 at 11:29:50AM -0700, John Stultz wrote:
>> I believe its mostly historical, but on some architectures that
>> history has become an established ABI, making it technical.
>
> Fine, but what do you mean by "ABI?" Are you talking about magic
> addresses for functions?
>
> Without knowing the dirty details, what I imagine is a jump/branch
> from the arch-specific code into the common implementation.

I suspect (based mostly on speculation) that this is possible for
everything except ia64.  ia64 looks like it uses a highly magical
syscall entry, where user code jumps to a special address for *all*
syscalls, and that code does some kind of partial kernel entry.  Very
careful asm code can run in that weird state, and that code implements
gettimeofday.  Now, if that code could return back to normal execution
and jump to a vdso, it could use common code, I guess.

This assumes that all architectures that want to use vclock_gettime,
etc are capable of sharing a page of read-only kernel memory with
userspace at a fixed address or can otherwise make the VVAR macro
work.  The only architectures I actually understand are x86-{32,64},
which can.  I don't think anyone cares about x86-32 enough to
implement it, though.

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

Re: [RFC/PATCH 2/2] block: Adding ROW scheduling algorithm

[Jan Engelhardt]

On Monday 2012-08-06 18:35, Jeff Moyer wrote:
>Tatyana Brokhman writes:
>
>> This patch adds the implementation of a new scheduling algorithm - ROW.
>> The policy of this algorithm is to prioritize READ requests over WRITE
>> as much as possible without starving the WRITE requests.
>
>Perhaps you could start off by describing the workload, and describing
>why the existing I/O schedulers do not perform well.

My setup is a 1 GB RAM Atom N450 netbook, combined with the use of
dm-crypt for the 5400 rpm disk, which limits the effective write
throughput to somewhere around 20–26 MB/s. Now try this:

  ddrescue /dev/zero ~/bluntfile (or)

  (remote)# >nullfile
  (remote)# truncate -s 10G nullfile
  (local)# rsync -HPavz remote:nullfile .

The transfer rates of ddrescue/rsync first show 50–60 MB/s. Wait
until writeout is forced - which is after ~700–800 MB in my case when
all buffers are full. The transfer rates then drop to the
aforementioned 20–26 MB/s.

In the so-loaded system, try to start an xterm (preferably by the use
of a shortcut, or starting one from another xterm). The wait time for
the shell prompt to appear is then the measure for interactivity,
with lower being better.

I have casually observed that ROW has 1/4th of the wait time in this
heavy disk write scenario (around 5 s) for the shell to start up than
with CFQ (20–21 s). "Casual" meaning I had a clock with 1.0 s
granularity beside me and ran this for like 3 times for each
scheduler, averaging it out.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 signal tree with the sh tree

[Stephen Rothwell]

Hi Al,

Today's linux-next merge of the signal tree got a conflict in
arch/sh/kernel/cpu/sh5/entry.S arch/sh/kernel/entry-common.S between
commit 5e071e2b4b82 ("sh: Fix up TIF_NOTIFY_RESUME sans TIF_SIGPENDING
handling") from the sh tree and commit 52b8a6e18bfd ("sh: missing tests
for NOTIFY_RESUME") from the signal tree.

These appear to be the same patches (apart from some trivial bits), so I
used the one from the sh tree and can carry the fix as necessary (no
action is required).

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


pgpSS7tRZRaGH.pgp
Description: PGP signature

Re: [PATCH 7/13] drivers/mmc/host/mmci.c: use clk_prepare_enable and clk_disable_unprepare

[Chris Ball]

Hi Julia,

On Sun, Aug 26 2012, Julia Lawall wrote:
> From: Julia Lawall 
>
> Clk_prepare_enable and clk_disable_unprepare combine clk_prepare and
> clk_enable, and clk_disable and clk_unprepare.  They make the code more
> concise, and ensure that clk_unprepare is called when clk_enable fails.
>
> A simplified version of the semantic patch that introduces calls to these
> functions is as follows: (http://coccinelle.lip6.fr/)
>
> // 
> @@
> expression e;
> @@
>
> - clk_prepare(e);
> - clk_enable(e);
> + clk_prepare_enable(e);
>
> @@
> expression e;
> @@
>
> - clk_disable(e);
> - clk_unprepare(e);
> + clk_disable_unprepare(e);
> // 
>
> Signed-off-by: Julia Lawall 
>
> ---
>  drivers/mmc/host/mmci.c |   13 +++--
>  1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index 50ff19a..edc3e9b 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -1309,14 +1309,10 @@ static int __devinit mmci_probe(struct amba_device 
> *dev,
>   goto host_free;
>   }
>  
> - ret = clk_prepare(host->clk);
> + ret = clk_prepare_enable(host->clk);
>   if (ret)
>   goto clk_free;
>  
> - ret = clk_enable(host->clk);
> - if (ret)
> - goto clk_unprep;
> -
>   host->plat = plat;
>   host->variant = variant;
>   host->mclk = clk_get_rate(host->clk);
> @@ -1515,9 +1511,7 @@ static int __devinit mmci_probe(struct amba_device *dev,
>   err_gpio_cd:
>   iounmap(host->base);
>   clk_disable:
> - clk_disable(host->clk);
> - clk_unprep:
> - clk_unprepare(host->clk);
> + clk_disable_unprepare(host->clk);
>   clk_free:
>   clk_put(host->clk);
>   host_free:
> @@ -1564,8 +1558,7 @@ static int __devexit mmci_remove(struct amba_device 
> *dev)
>   gpio_free(host->gpio_cd);
>  
>   iounmap(host->base);
> - clk_disable(host->clk);
> - clk_unprepare(host->clk);
> + clk_disable_unprepare(host->clk);
>   clk_put(host->clk);
>  
>   if (host->vcc)

Thanks, pushed to mmc-next for 3.7.

(I merged v1 instead of v2 because I don't see any whitespace problems
with it, and I liked the verbosity in the original commit message.)

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] poweroff: fix bug in orderly_poweroff

[Feng Hong]

Hi, Eric

1. We are developing on an Android phone platform, we use thermal framework to 
monitor the temperature, when the temperature above like 110 degree, thermal 
framework will use orderly_shutdown to shutdown phone, however, on Android 
platform there is no " /sbin/poweroff " cmd ready . Then we want "fail ret" to 
trigger force shutdown (use kernel_power_off), but always we get "suc ret"
2. Here the caller just wait for "poweroff" userspace application, if it block 
the called, then it's the "poweroff" problem itself
3. As in the original orderly_shutdown design, we must get the right "ret", if 
this ret is always "0", then it obey orderly_poweroff design goal. Step 2: 
force shutdown is always useless code. 
int orderly_poweroff(bool force)
{
int ret = __orderly_poweroff();

if (ret && force) {
printk(KERN_WARNING "Failed to start orderly shutdown: "
   "forcing the issue\n");

/*
 * I guess this should try to kick off some daemon to sync and
 * poweroff asap.  Or not even bother syncing if we're doing an
 * emergency shutdown?
 */
emergency_sync();
kernel_power_off();
}

return ret;
}1
--
Best Regards,
Feng Hong
Application Processor Software Engnieer 
Marvell Technology (Shanghai) Ltd


-Original Message-
From: Eric W. Biederman [mailto:ebied...@xmission.com] 
Sent: 2012年9月19日 12:47
To: Feng Hong
Cc: a...@linux-foundation.org; gorcu...@openvz.org; keesc...@chromium.org; 
serge.hal...@canonical.com; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] poweroff: fix bug in orderly_poweroff

hongfeng  writes:

> orderly_poweroff is trying to poweroff platform by two steps:
> step 1: Call userspace application to poweroff
> step 2: If userspace poweroff fail, then do a force power off if force param 
> is set.
>
> The bug here is, step 1 is always successful with param UMH_NO_WAIT,

This code has existed for 5 years.  Is this a recent regression?  Why
has no one complained before?

It looks to me that step 2 is:
step 2: If we can not launch the userspace poweroff fail.

> should change to UMH_WAIT_PROC which will monitor the return value
> ofuserspace application.

Is it safe to block indefinitely in the callers waiting for userspace?

If the caller is not running in a kernel thread then we can easily get
into a case where the userspace caller will block waiting for us when we
are waiting for the userspace caller.

I don't want to impeded progress but I don't see the evidence that this
change is good enough.


> Change-Id: I2f9ebbb90c0c2443780080ec9507c8d004e5da74
> Signed-off-by: Feng Hong 
> ---
>  kernel/sys.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/sys.c b/kernel/sys.c
> index 241507f..1b30b30 100644
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -2204,7 +2204,7 @@ static int __orderly_poweroff(void)
>   return -ENOMEM;
>   }
>  
> - ret = call_usermodehelper_fns(argv[0], argv, envp, UMH_NO_WAIT,
> + ret = call_usermodehelper_fns(argv[0], argv, envp, UMH_WAIT_PROC,
> NULL, argv_cleanup, NULL);
>   if (ret == -ENOMEM)
>   argv_free(argv);

RE: [PATCH] edac/85xx: fix error handle of mpc85xx_mc_err_probe

[Xie Shaohui-B21989]

> -Original Message-
> From: Shaun Ruffell [mailto:sruff...@digium.com]
> Sent: Wednesday, September 19, 2012 11:53 AM
> To: Xie Shaohui-B21989
> Cc: linux-e...@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> a...@linux-foundation.org; avoront...@mvista.com; linux-
> ker...@vger.kernel.org; grant.lik...@secretlab.ca
> Subject: Re: [PATCH] edac/85xx: fix error handle of mpc85xx_mc_err_probe
> 
> On Wed, Sep 19, 2012 at 03:43:35AM +, Xie Shaohui-B21989 wrote:
> > > On Mon, Sep 17, 2012 at 10:32:59AM +, Xie Shaohui-B21989 wrote:
> > > >
> > > > BTW: seems you are using a different kernel tree with mine.
> > >
> > > On the chance that I missing something important: Why do you say I
> > > was running a different kernel tree? I was against 3.6-rc2 when I
> > > original hit the problem.
> >
> > [S.H] I'm using 3.6-rc4, and some codes in your patch I did not find
> > them in 3.6-rc4.
> 
> Is it because there were three patches in the series?
> 
>   [1/3] https://lkml.org/lkml/2012/9/14/473
>   [2/3] https://lkml.org/lkml/2012/9/14/469
>   [3/3] https://lkml.org/lkml/2012/9/14/474
> 
> They are also the last three commits on my edac_debug_v2 branch here,
> which is on top of 3.6-rc6:
> 
> https://github.com/sruffell/linux/commits/edac_debug_v2/

[S.H] Yes.

Best Regards, 
Shaohui Xie

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6][RFC] Rework vsyscall to avoid truncation/rounding issue in timekeeping core

[Richard Cochran]

On Tue, Sep 18, 2012 at 11:29:50AM -0700, John Stultz wrote:
> I believe its mostly historical, but on some architectures that
> history has become an established ABI, making it technical.

Fine, but what do you mean by "ABI?" Are you talking about magic
addresses for functions?

Without knowing the dirty details, what I imagine is a jump/branch
from the arch-specific code into the common implementation.

Can that be done?

Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: IMA policy search speedup

[Al Viro]

On Wed, Sep 19, 2012 at 02:21:56PM +1000, James Morris wrote:
> On Tue, 18 Sep 2012, Kasatkin, Dmitry wrote:
> 
> > I looked to  and found that there is a possibility to to
> > add additional flag for sb->s_flags.
> > For example
> > 
> > #define MS_NOT_IMA  (1<<25) /* NOT_IMA */
> > #define IS_I_NOT_IMA(inode)   __IS_FLG(inode, MS_NOT_IMA)
> > 
> > 
> > Another way is to add additional dedicated integrity related member to
> > the sb structure.
> > struct super_block {
> > ...
> > #ifdef CONFIG_INTEGRITY
> >   int s_integrity;
> > #endif
> > };
> > 
> > Obviously there are only few super blocks in the system and few bytes
> > will not harm.
> 
> The flag seems better than adding a new struct member.  Why would you need 
> an int for this?

Per-superblock bit would be a bit better, but I really hate the way we have
them mixed up between superblock ->s_flags bits and mount(2) action weirdly
encoded into flags thing.  If we are going to touch that thing, how about
separate S_... bits, with MS_... crap left only for mount(2) decoding?  Mapped
to S_... when needed.

The really messy part is that right now we silently ignore all the unknown
bits in mount(2) flags argument ;-/  It's *not* a widely used syscall, but
still - changing that in a non-trivial way is potential userland breakage.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] poweroff: fix bug in orderly_poweroff

[Eric W. Biederman]

hongfeng  writes:

> orderly_poweroff is trying to poweroff platform by two steps:
> step 1: Call userspace application to poweroff
> step 2: If userspace poweroff fail, then do a force power off if force param 
> is set.
>
> The bug here is, step 1 is always successful with param UMH_NO_WAIT,

This code has existed for 5 years.  Is this a recent regression?  Why
has no one complained before?

It looks to me that step 2 is:
step 2: If we can not launch the userspace poweroff fail.

> should change to UMH_WAIT_PROC which will monitor the return value
> ofuserspace application.

Is it safe to block indefinitely in the callers waiting for userspace?

If the caller is not running in a kernel thread then we can easily get
into a case where the userspace caller will block waiting for us when we
are waiting for the userspace caller.

I don't want to impeded progress but I don't see the evidence that this
change is good enough.


> Change-Id: I2f9ebbb90c0c2443780080ec9507c8d004e5da74
> Signed-off-by: Feng Hong 
> ---
>  kernel/sys.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/sys.c b/kernel/sys.c
> index 241507f..1b30b30 100644
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -2204,7 +2204,7 @@ static int __orderly_poweroff(void)
>   return -ENOMEM;
>   }
>  
> - ret = call_usermodehelper_fns(argv[0], argv, envp, UMH_NO_WAIT,
> + ret = call_usermodehelper_fns(argv[0], argv, envp, UMH_WAIT_PROC,
> NULL, argv_cleanup, NULL);
>   if (ret == -ENOMEM)
>   argv_free(argv);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 staging tree with the usb tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/serqt_usb2/serqt_usb2.c between commit e8656b02ef35
("USB: serial: serqt_usb2: remove dbg() usage") from the usb tree and
commit 623c2bb2c59a ("staging: serqt_usb2: fix dbg print when kzalloc
failed to allocate qt_port") from the staging tree.

The former removes the line changed by the latter, so I just did that (no
action is required).
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp2AmfkKf5SY.pgp
Description: PGP signature

linux-next: build failure after merge of the usb tree

[Stephen Rothwell]

Hi Greg,

After merging the usb tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/usb/serial/vizzini.c: In function 'vizzini_set_termios':
drivers/usb/serial/vizzini.c:454:22: error: invalid type argument of '->' (have 
'struct ktermios')

Caused by commit c05fecb1d57e ("USB: serial: add vizzini driver")
interacting with commit adc8d746caa6 ("tty: move the termios object into
the tty") from the tty tree.

I added the following merge fix patch and can carry it as necessary:

From: Stephen Rothwell 
Date: Wed, 19 Sep 2012 14:27:39 +1000
Subject: [PATCH] USB: serial: fix vizzini driver for move of the termios
 object

Signed-off-by: Stephen Rothwell 
---
 drivers/usb/serial/vizzini.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/serial/vizzini.c b/drivers/usb/serial/vizzini.c
index 2ac48fe..253eaf8 100644
--- a/drivers/usb/serial/vizzini.c
+++ b/drivers/usb/serial/vizzini.c
@@ -451,7 +451,7 @@ static void vizzini_set_termios(struct tty_struct 
*tty_param,
unsigned int format_size, format_parity, format_stop, flow, 
gpio_mode;
struct tty_struct   *tty = port->port.tty;
 
-   cflag = tty->termios->c_cflag;
+   cflag = tty->termios.c_cflag;
 
portdata->clocal = ((cflag & CLOCAL) != 0);
 
-- 
1.7.10.280.gaa39

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/


pgpS0Ax5GuIWT.pgp
Description: PGP signature

Re: IMA policy search speedup

[James Morris]

On Tue, 18 Sep 2012, Kasatkin, Dmitry wrote:

> I looked to  and found that there is a possibility to to
> add additional flag for sb->s_flags.
> For example
> 
> #define MS_NOT_IMA  (1<<25) /* NOT_IMA */
> #define IS_I_NOT_IMA(inode)   __IS_FLG(inode, MS_NOT_IMA)
> 
> 
> Another way is to add additional dedicated integrity related member to
> the sb structure.
> struct super_block {
> ...
> #ifdef CONFIG_INTEGRITY
>   int s_integrity;
> #endif
> };
> 
> Obviously there are only few super blocks in the system and few bytes
> will not harm.

The flag seems better than adding a new struct member.  Why would you need 
an int for this?



- James
-- 
James Morris

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

Re: [PATCH 14/16] X.509: Add an ASN.1 decoder

[James Morris]

On Tue, 18 Sep 2012, Alan Cox wrote:

> On Tue, 18 Sep 2012 18:34:12 +0100
> David Howells  wrote:
> 
> > Alan Cox  wrote:
> > 
> > > Why do this in the kernel.That appears to be completely insane.
> > 
> > A number of reasons:
> > 
> >  (1) The UEFI signature/key database may contain ASN.1 X.509 certificates 
> > and
> >  we may need to use those very early in the boot process, during initrd.
> 
> Ok that makes some sense.

I'd like to see some serious effort at code review and testing before this 
code is merged.


- James
-- 
James Morris

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 usb tree with the tty tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the usb tree got a conflict in
drivers/usb/serial/io_edgeport.c between commit adc8d746caa6 ("tty: move
the termios object into the tty") from the tty tree and commit
984f68683298 ("USB: serial: io_edgeport.c: remove dbg() usage") from the
usb 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/usb/serial/io_edgeport.c
index f435575,75b7ccd..000
--- a/drivers/usb/serial/io_edgeport.c
+++ b/drivers/usb/serial/io_edgeport.c
@@@ -1516,13 -1497,9 +1497,9 @@@ static void edge_set_termios(struct tty
struct edgeport_port *edge_port = usb_get_serial_port_data(port);
unsigned int cflag;
  
 -  cflag = tty->termios->c_cflag;
 -  dev_dbg(&port->dev, "%s - clfag %08x iflag %08x\n", __func__, 
tty->termios->c_cflag, tty->termios->c_iflag);
 +  cflag = tty->termios.c_cflag;
-   dbg("%s - clfag %08x iflag %08x", __func__,
-   tty->termios.c_cflag, tty->termios.c_iflag);
-   dbg("%s - old clfag %08x old iflag %08x", __func__,
-   old_termios->c_cflag, old_termios->c_iflag);
- 
-   dbg("%s - port %d", __func__, port->number);
++  dev_dbg(&port->dev, "%s - clfag %08x iflag %08x\n", __func__, 
tty->termios.c_cflag, tty->termios.c_iflag);
+   dev_dbg(&port->dev, "%s - old clfag %08x old iflag %08x\n", __func__, 
old_termios->c_cflag, old_termios->c_iflag);
  
if (edge_port == NULL)
return;


pgpSEH0cNHs92.pgp
Description: PGP signature

Re: [PATCH v8 2/3] perf: move stat related code to util/stat.c

[David Ahern]

On 9/18/12 7:53 PM, Xiao Guangrong wrote:

Does not apply to Arnaldo's latest perf/core branch.


The patch has already been applied to this branch:
http://git.kernel.org/?p=linux/kernel/git/acme/linux.git;a=commit;h=0007eceaceb11520071d053acfe06ee3326b1d13


Did not expect that. ok. I'll try patch 3 tomorrow.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] edac/85xx: fix error handle of mpc85xx_mc_err_probe

[Shaun Ruffell]

On Wed, Sep 19, 2012 at 03:43:35AM +, Xie Shaohui-B21989 wrote:
> > On Mon, Sep 17, 2012 at 10:32:59AM +, Xie Shaohui-B21989 wrote:
> > >
> > > BTW: seems you are using a different kernel tree with mine.
> > 
> > On the chance that I missing something important: Why do you say
> > I was running a different kernel tree? I was against 3.6-rc2
> > when I original hit the problem.
>
> [S.H] I'm using 3.6-rc4, and some codes in your patch I did not
> find them in 3.6-rc4.

Is it because there were three patches in the series?

  [1/3] https://lkml.org/lkml/2012/9/14/473
  [2/3] https://lkml.org/lkml/2012/9/14/469
  [3/3] https://lkml.org/lkml/2012/9/14/474

They are also the last three commits on my edac_debug_v2 branch
here, which is on top of 3.6-rc6:

https://github.com/sruffell/linux/commits/edac_debug_v2/

Cheers,
Shaun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] linux/kernel.h: Fix warning seen with W=1 due to change in DIV_ROUND_CLOSEST

[Guenter Roeck]

After commit b6d86d3d (Fix DIV_ROUND_CLOSEST to support negative dividends),
the following warning is seen if the kernel is compiled with W=1 (-Wextra):

warning: comparison of unsigned expression >= 0 is always true

The warning is due to the test '((typeof(x))-1) >= 0', which is used to detect
if the variable type is unsigned. Research on the web suggests that the warning
disappears if '>' instead of '>=' is used for the comparison.

Tests after changing the macro along that line show that the warning is gone,
and that the result is still correct:

i=-4: DIV_ROUND_CLOSEST(i, 2)=-2
i=-3: DIV_ROUND_CLOSEST(i, 2)=-2
i=-2: DIV_ROUND_CLOSEST(i, 2)=-1
i=-1: DIV_ROUND_CLOSEST(i, 2)=-1
i=0: DIV_ROUND_CLOSEST(i, 2)=0
i=1: DIV_ROUND_CLOSEST(i, 2)=1
i=2: DIV_ROUND_CLOSEST(i, 2)=1
i=3: DIV_ROUND_CLOSEST(i, 2)=2
i=4: DIV_ROUND_CLOSEST(i, 2)=2

Code size is the same as before.

Signed-off-by: Guenter Roeck 
---
 include/linux/kernel.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 594b419..2451f1f 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -91,7 +91,7 @@
 {  \
typeof(x) __x = x;  \
typeof(divisor) __d = divisor;  \
-   (((typeof(x))-1) >= 0 || (__x) >= 0) ?  \
+   (((typeof(x))-1) > 0 || (__x) > 0) ?\
(((__x) + ((__d) / 2)) / (__d)) :   \
(((__x) - ((__d) / 2)) / (__d));\
 }  \
-- 
1.7.9.7

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

[PATCH 4/4] mm: remove free_page_mlock

[Hugh Dickins]

We should not be seeing non-0 unevictable_pgs_mlockfreed any longer.
So remove free_page_mlock() from the page freeing paths: __PG_MLOCKED
is already in PAGE_FLAGS_CHECK_AT_FREE, so free_pages_check() will now
be checking it, reporting "BUG: Bad page state" if it's ever found set.
Comment UNEVICTABLE_MLOCKFREED and unevictable_pgs_mlockfreed always 0.

Signed-off-by: Hugh Dickins 
Cc: Mel Gorman 
Cc: Rik van Riel 
Cc: Johannes Weiner 
Cc: Michel Lespinasse 
Cc: Ying Han 
---
 include/linux/vm_event_item.h |2 +-
 mm/page_alloc.c   |   17 -
 mm/vmstat.c   |2 +-
 3 files changed, 2 insertions(+), 19 deletions(-)

--- 3.6-rc6.orig/include/linux/vm_event_item.h  2012-09-18 15:38:08.0 
-0700
+++ 3.6-rc6/include/linux/vm_event_item.h   2012-09-18 20:04:42.516625261 
-0700
@@ -52,7 +52,7 @@ enum vm_event_item { PGPGIN, PGPGOUT, PS
UNEVICTABLE_PGMUNLOCKED,
UNEVICTABLE_PGCLEARED,  /* on COW, page truncate */
UNEVICTABLE_PGSTRANDED, /* unable to isolate on unlock */
-   UNEVICTABLE_MLOCKFREED,
+   UNEVICTABLE_MLOCKFREED, /* no longer useful: always zero */
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
THP_FAULT_ALLOC,
THP_FAULT_FALLBACK,
--- 3.6-rc6.orig/mm/page_alloc.c2012-09-18 15:38:08.0 -0700
+++ 3.6-rc6/mm/page_alloc.c 2012-09-18 20:04:42.520625316 -0700
@@ -597,17 +597,6 @@ out:
zone->free_area[order].nr_free++;
 }
 
-/*
- * free_page_mlock() -- clean up attempts to free and mlocked() page.
- * Page should not be on lru, so no need to fix that up.
- * free_pages_check() will verify...
- */
-static inline void free_page_mlock(struct page *page)
-{
-   __dec_zone_page_state(page, NR_MLOCK);
-   __count_vm_event(UNEVICTABLE_MLOCKFREED);
-}
-
 static inline int free_pages_check(struct page *page)
 {
if (unlikely(page_mapcount(page) |
@@ -721,14 +710,11 @@ static bool free_pages_prepare(struct pa
 static void __free_pages_ok(struct page *page, unsigned int order)
 {
unsigned long flags;
-   int wasMlocked = __TestClearPageMlocked(page);
 
if (!free_pages_prepare(page, order))
return;
 
local_irq_save(flags);
-   if (unlikely(wasMlocked))
-   free_page_mlock(page);
__count_vm_events(PGFREE, 1 << order);
free_one_page(page_zone(page), page, order,
get_pageblock_migratetype(page));
@@ -1296,7 +1282,6 @@ void free_hot_cold_page(struct page *pag
struct per_cpu_pages *pcp;
unsigned long flags;
int migratetype;
-   int wasMlocked = __TestClearPageMlocked(page);
 
if (!free_pages_prepare(page, 0))
return;
@@ -1304,8 +1289,6 @@ void free_hot_cold_page(struct page *pag
migratetype = get_pageblock_migratetype(page);
set_page_private(page, migratetype);
local_irq_save(flags);
-   if (unlikely(wasMlocked))
-   free_page_mlock(page);
__count_vm_event(PGFREE);
 
/*
--- 3.6-rc6.orig/mm/vmstat.c2012-09-18 15:38:08.0 -0700
+++ 3.6-rc6/mm/vmstat.c 2012-09-18 20:04:42.524625352 -0700
@@ -781,7 +781,7 @@ const char * const vmstat_text[] = {
"unevictable_pgs_munlocked",
"unevictable_pgs_cleared",
"unevictable_pgs_stranded",
-   "unevictable_pgs_mlockfreed",
+   "unevictable_pgs_mlockfreed",   /* no longer useful: always zero */
 
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
"thp_fault_alloc",
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 workqueues tree with the pm tree

[Stephen Rothwell]

Hi Tejun,

Today's linux-next merge of the workqueues tree got a conflict in
drivers/cpufreq/powernow-k8.c between commit e1f0b8e9b04a ("cpufreq:
Remove support for hardware P-state chips from powernow-k8") from the pm
tree and commit 5d7efe7bf90f ("cpufreq/powernow-k8: workqueue user
shouldn't migrate the kworker to another CPU") from the workqueues tree.

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

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

diff --cc drivers/cpufreq/powernow-k8.c
index 0b19faf,1a40935..000
--- a/drivers/cpufreq/powernow-k8.c
+++ b/drivers/cpufreq/powernow-k8.c
@@@ -978,11 -1104,52 +977,18 @@@ static int transition_frequency_fidvid(
return res;
  }
  
- /* Driver entry point to switch to the target frequency */
- static int powernowk8_target(struct cpufreq_policy *pol,
-   unsigned targfreq, unsigned relation)
 -/* Take a frequency, and issue the hardware pstate transition command */
 -static int transition_frequency_pstate(struct powernow_k8_data *data,
 -  unsigned int index)
 -{
 -  u32 pstate = 0;
 -  int res, i;
 -  struct cpufreq_freqs freqs;
 -
 -  pr_debug("cpu %d transition to index %u\n", smp_processor_id(), index);
 -
 -  /* get MSR index for hardware pstate transition */
 -  pstate = index & HW_PSTATE_MASK;
 -  if (pstate > data->max_hw_pstate)
 -  return -EINVAL;
 -
 -  freqs.old = find_khz_freq_from_pstate(data->powernow_table,
 -  data->currpstate);
 -  freqs.new = find_khz_freq_from_pstate(data->powernow_table, pstate);
 -
 -  for_each_cpu(i, data->available_cores) {
 -  freqs.cpu = i;
 -  cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
 -  }
 -
 -  res = transition_pstate(data, pstate);
 -  freqs.new = find_khz_freq_from_pstate(data->powernow_table, pstate);
 -
 -  for_each_cpu(i, data->available_cores) {
 -  freqs.cpu = i;
 -  cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
 -  }
 -  return res;
 -}
 -
+ struct powernowk8_target_arg {
+   struct cpufreq_policy   *pol;
+   unsignedtargfreq;
+   unsignedrelation;
+ };
+ 
+ static long powernowk8_target_fn(void *arg)
  {
-   cpumask_var_t oldmask;
+   struct powernowk8_target_arg *pta = arg;
+   struct cpufreq_policy *pol = pta->pol;
+   unsigned targfreq = pta->targfreq;
+   unsigned relation = pta->relation;
struct powernow_k8_data *data = per_cpu(powernow_data, pol->cpu);
u32 checkfid;
u32 checkvid;
@@@ -1017,17 -1171,20 +1010,17 @@@
pol->cpu, targfreq, pol->min, pol->max, relation);
  
if (query_current_values_with_pending_wait(data))
-   goto err_out;
+   return -EIO;
  
 -  if (cpu_family != CPU_HW_PSTATE) {
 -  pr_debug("targ: curr fid 0x%x, vid 0x%x\n",
 -  data->currfid, data->currvid);
 +  pr_debug("targ: curr fid 0x%x, vid 0x%x\n",
 +   data->currfid, data->currvid);
  
 -  if ((checkvid != data->currvid) ||
 -  (checkfid != data->currfid)) {
 -  printk(KERN_INFO PFX
 -  "error - out of sync, fix 0x%x 0x%x, "
 -  "vid 0x%x 0x%x\n",
 -  checkfid, data->currfid,
 -  checkvid, data->currvid);
 -  }
 +  if ((checkvid != data->currvid) ||
 +  (checkfid != data->currfid)) {
 +  pr_info(PFX
 + "error - out of sync, fix 0x%x 0x%x, vid 0x%x 0x%x\n",
 + checkfid, data->currfid,
 + checkvid, data->currvid);
}
  
if (cpufreq_frequency_table_target(pol, data->powernow_table,
@@@ -1038,23 -1195,42 +1031,35 @@@
  
powernow_k8_acpi_pst_values(data, newstate);
  
 -  if (cpu_family == CPU_HW_PSTATE)
 -  ret = transition_frequency_pstate(data,
 -  data->powernow_table[newstate].index);
 -  else
 -  ret = transition_frequency_fidvid(data, newstate);
 +  ret = transition_frequency_fidvid(data, newstate);
 +
if (ret) {
printk(KERN_ERR PFX "transition frequency failed\n");
-   ret = 1;
mutex_unlock(&fidvid_mutex);
-   goto err_out;
+   return 1;
}
mutex_unlock(&fidvid_mutex);
  
 -  if (cpu_family == CPU_HW_PSTATE)
 -  pol->cur = find_khz_freq_from_pstate(data->powernow_table,
 -  data->powernow_table[newstate].index);
 -  else
 -  pol->cur = find_khz_freq_from_fid(data->currfid);
 +  pol->cur = find_khz_freq_from_fid(data->currfid);
-   ret = 0;
  
- err_out:
-   set_cpus_al

[PATCH 3/4] mm: clear_page_mlock in page_remove_rmap

[Hugh Dickins]

We had thought that pages could no longer get freed while still marked
as mlocked; but Johannes Weiner posted this program to demonstrate that
truncating an mlocked private file mapping containing COWed pages is
still mishandled:

#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main(void)
{
char *map;
int fd;

system("grep mlockfreed /proc/vmstat");
fd = open("chigurh", O_CREAT|O_EXCL|O_RDWR);
unlink("chigurh");
ftruncate(fd, 4096);
map = mmap(NULL, 4096, PROT_WRITE, MAP_PRIVATE, fd, 0);
map[0] = 11;
mlock(map, sizeof(fd));
ftruncate(fd, 0);
close(fd);
munlock(map, sizeof(fd));
munmap(map, 4096);
system("grep mlockfreed /proc/vmstat");
return 0;
}

The anon COWed pages are not caught by truncation's clear_page_mlock()
of the pagecache pages; but unmap_mapping_range() unmaps them, so we
ought to look out for them there in page_remove_rmap().  Indeed, why
should truncation or invalidation be doing the clear_page_mlock() when
removing from pagecache?  mlock is a property of mapping in userspace,
not a propertly of pagecache: an mlocked unmapped page is nonsensical.

Reported-by: Johannes Weiner 
Signed-off-by: Hugh Dickins 
Cc: Mel Gorman 
Cc: Rik van Riel 
Cc: Michel Lespinasse 
Cc: Ying Han 
---
 mm/internal.h |7 +--
 mm/memory.c   |   10 +-
 mm/mlock.c|   16 +++-
 mm/rmap.c |4 
 mm/truncate.c |4 
 5 files changed, 13 insertions(+), 28 deletions(-)

--- 3.6-rc6.orig/mm/internal.h  2012-09-18 16:39:50.0 -0700
+++ 3.6-rc6/mm/internal.h   2012-09-18 17:51:02.871288773 -0700
@@ -200,12 +200,7 @@ extern void munlock_vma_page(struct page
  * If called for a page that is still mapped by mlocked vmas, all we do
  * is revert to lazy LRU behaviour -- semantics are not broken.
  */
-extern void __clear_page_mlock(struct page *page);
-static inline void clear_page_mlock(struct page *page)
-{
-   if (unlikely(TestClearPageMlocked(page)))
-   __clear_page_mlock(page);
-}
+extern void clear_page_mlock(struct page *page);
 
 /*
  * mlock_migrate_page - called only from migrate_page_copy() to
--- 3.6-rc6.orig/mm/memory.c2012-09-18 15:38:08.0 -0700
+++ 3.6-rc6/mm/memory.c 2012-09-18 17:51:02.871288773 -0700
@@ -1576,12 +1576,12 @@ split_fallthrough:
if (page->mapping && trylock_page(page)) {
lru_add_drain();  /* push cached pages to LRU */
/*
-* Because we lock page here and migration is
-* blocked by the pte's page reference, we need
-* only check for file-cache page truncation.
+* Because we lock page here, and migration is
+* blocked by the pte's page reference, and we
+* know the page is still mapped, we don't even
+* need to check for file-cache page truncation.
 */
-   if (page->mapping)
-   mlock_vma_page(page);
+   mlock_vma_page(page);
unlock_page(page);
}
}
--- 3.6-rc6.orig/mm/mlock.c 2012-09-18 15:38:08.0 -0700
+++ 3.6-rc6/mm/mlock.c  2012-09-18 17:51:02.871288773 -0700
@@ -51,13 +51,10 @@ EXPORT_SYMBOL(can_do_mlock);
 /*
  *  LRU accounting for clear_page_mlock()
  */
-void __clear_page_mlock(struct page *page)
+void clear_page_mlock(struct page *page)
 {
-   VM_BUG_ON(!PageLocked(page));
-
-   if (!page->mapping) {   /* truncated ? */
+   if (!TestClearPageMlocked(page))
return;
-   }
 
dec_zone_page_state(page, NR_MLOCK);
count_vm_event(UNEVICTABLE_PGCLEARED);
@@ -290,14 +287,7 @@ void munlock_vma_pages_range(struct vm_a
page = follow_page(vma, addr, FOLL_GET | FOLL_DUMP);
if (page && !IS_ERR(page)) {
lock_page(page);
-   /*
-* Like in __mlock_vma_pages_range(),
-* because we lock page here and migration is
-* blocked by the elevated reference, we need
-* only check for file-cache page truncation.
-*/
-   if (page->mapping)
-   munlock_vma_page(page);
+   munlock_vma_page(page);
unlock_page(page);
put_page(page);
}
--- 3.6-rc6.orig/mm/rmap.c  2012-09-18 16:39:50.0 -0700
+++ 3.6-rc6/mm/rmap.c   2012-09-18 17:51:02.871288773 -0700
@@ -1203,7 +1203,10 @@ void page_remove_rmap(struct page *page)
} else {
__dec_zone_page_state(page, NR_FILE_MAPPED);
mem_cgroup_dec_page_stat(page, MEMC

[PATCH 2/4] mm: remove vma arg from page_evictable

[Hugh Dickins]

page_evictable(page, vma) is an irritant: almost all its callers pass
NULL for vma.  Remove the vma arg and use mlocked_vma_newpage(vma, page)
explicitly in the couple of places it's needed.  But in those places we
don't even need page_evictable() itself!  They're dealing with a freshly
allocated anonymous page, which has no "mapping" and cannot be mlocked yet.

Signed-off-by: Hugh Dickins 
Cc: Mel Gorman 
Cc: Rik van Riel 
Cc: Johannes Weiner 
Cc: Michel Lespinasse 
Cc: Ying Han 
---
 Documentation/vm/unevictable-lru.txt |   10 ++---
 include/linux/swap.h |2 -
 mm/internal.h|5 +---
 mm/ksm.c |2 -
 mm/rmap.c|2 -
 mm/swap.c|2 -
 mm/vmscan.c  |   27 -
 7 files changed, 18 insertions(+), 32 deletions(-)

--- 3.6-rc6.orig/Documentation/vm/unevictable-lru.txt   2012-09-18 
15:38:08.0 -0700
+++ 3.6-rc6/Documentation/vm/unevictable-lru.txt2012-09-18 
16:39:50.878992976 -0700
@@ -197,12 +197,8 @@ the pages are also "rescued" from the un
 freeing them.
 
 page_evictable() also checks for mlocked pages by testing an additional page
-flag, PG_mlocked (as wrapped by PageMlocked()).  If the page is NOT mlocked,
-and a non-NULL VMA is supplied, page_evictable() will check whether the VMA is
-VM_LOCKED via is_mlocked_vma().  is_mlocked_vma() will SetPageMlocked() and
-update the appropriate statistics if the vma is VM_LOCKED.  This method allows
-efficient "culling" of pages in the fault path that are being faulted in to
-VM_LOCKED VMAs.
+flag, PG_mlocked (as wrapped by PageMlocked()), which is set when a page is
+faulted into a VM_LOCKED vma, or found in a vma being VM_LOCKED.
 
 
 VMSCAN'S HANDLING OF UNEVICTABLE PAGES
@@ -651,7 +647,7 @@ PAGE RECLAIM IN shrink_*_list()
 ---
 
 shrink_active_list() culls any obviously unevictable pages - i.e.
-!page_evictable(page, NULL) - diverting these to the unevictable list.
+!page_evictable(page) - diverting these to the unevictable list.
 However, shrink_active_list() only sees unevictable pages that made it onto the
 active/inactive lru lists.  Note that these pages do not have PageUnevictable
 set - otherwise they would be on the unevictable list and shrink_active_list
--- 3.6-rc6.orig/include/linux/swap.h   2012-09-18 15:38:08.0 -0700
+++ 3.6-rc6/include/linux/swap.h2012-09-18 16:39:50.878992976 -0700
@@ -281,7 +281,7 @@ static inline int zone_reclaim(struct zo
 }
 #endif
 
-extern int page_evictable(struct page *page, struct vm_area_struct *vma);
+extern int page_evictable(struct page *page);
 extern void check_move_unevictable_pages(struct page **, int nr_pages);
 
 extern unsigned long scan_unevictable_pages;
--- 3.6-rc6.orig/mm/internal.h  2012-09-18 15:38:08.0 -0700
+++ 3.6-rc6/mm/internal.h   2012-09-18 16:39:50.882992906 -0700
@@ -167,9 +167,8 @@ static inline void munlock_vma_pages_all
 }
 
 /*
- * Called only in fault path via page_evictable() for a new page
- * to determine if it's being mapped into a LOCKED vma.
- * If so, mark page as mlocked.
+ * Called only in fault path, to determine if a new page is being
+ * mapped into a LOCKED vma.  If it is, mark page as mlocked.
  */
 static inline int mlocked_vma_newpage(struct vm_area_struct *vma,
struct page *page)
--- 3.6-rc6.orig/mm/ksm.c   2012-09-18 15:38:08.0 -0700
+++ 3.6-rc6/mm/ksm.c2012-09-18 16:39:50.882992906 -0700
@@ -1582,7 +1582,7 @@ struct page *ksm_does_need_to_copy(struc
SetPageSwapBacked(new_page);
__set_page_locked(new_page);
 
-   if (page_evictable(new_page, vma))
+   if (!mlocked_vma_newpage(vma, new_page))
lru_cache_add_lru(new_page, LRU_ACTIVE_ANON);
else
add_page_to_unevictable_list(new_page);
--- 3.6-rc6.orig/mm/rmap.c  2012-09-18 15:38:08.0 -0700
+++ 3.6-rc6/mm/rmap.c   2012-09-18 16:39:50.882992906 -0700
@@ -1128,7 +1128,7 @@ void page_add_new_anon_rmap(struct page
else
__inc_zone_page_state(page, NR_ANON_TRANSPARENT_HUGEPAGES);
__page_set_anon_rmap(page, vma, address, 1);
-   if (page_evictable(page, vma))
+   if (!mlocked_vma_newpage(vma, page))
lru_cache_add_lru(page, LRU_ACTIVE_ANON);
else
add_page_to_unevictable_list(page);
--- 3.6-rc6.orig/mm/swap.c  2012-09-18 15:38:08.0 -0700
+++ 3.6-rc6/mm/swap.c   2012-09-18 16:39:50.882992906 -0700
@@ -742,7 +742,7 @@ void lru_add_page_tail(struct page *page
 
SetPageLRU(page_tail);
 
-   if (page_evictable(page_tail, NULL)) {
+   if (page_evictable(page_tail)) {
if (PageActive(page)) {
SetPageActive(page_tail);
active = 1;
--- 3.6-rc6.

[PATCH 1/4] mm: fix invalidate_complete_page2 lock ordering

[Hugh Dickins]

In fuzzing with trinity, lockdep protested "possible irq lock inversion
dependency detected" when isolate_lru_page() reenabled interrupts while
still holding the supposedly irq-safe tree_lock:

invalidate_inode_pages2
  invalidate_complete_page2
spin_lock_irq(&mapping->tree_lock)
clear_page_mlock
  isolate_lru_page
spin_unlock_irq(&zone->lru_lock)

isolate_lru_page() is correct to enable interrupts unconditionally:
invalidate_complete_page2() is incorrect to call clear_page_mlock()
while holding tree_lock, which is supposed to nest inside lru_lock.

Both truncate_complete_page() and invalidate_complete_page() call
clear_page_mlock() before taking tree_lock to remove page from
radix_tree.  I guess invalidate_complete_page2() preferred to test
PageDirty (again) under tree_lock before committing to the munlock;
but since the page has already been unmapped, its state is already
somewhat inconsistent, and no worse if clear_page_mlock() moved up.

Reported-by: Sasha Levin 
Deciphered-by: Andrew Morton 
Signed-off-by: Hugh Dickins 
Cc: Mel Gorman 
Cc: Rik van Riel 
Cc: Johannes Weiner 
Cc: Michel Lespinasse 
Cc: Ying Han 
Cc: sta...@vger.kernel.org
---
 mm/truncate.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- 3.6-rc6.orig/mm/truncate.c  2012-09-18 15:38:08.0 -0700
+++ 3.6-rc6/mm/truncate.c   2012-09-18 15:42:17.066731792 -0700
@@ -394,11 +394,12 @@ invalidate_complete_page2(struct address
if (page_has_private(page) && !try_to_release_page(page, GFP_KERNEL))
return 0;
 
+   clear_page_mlock(page);
+
spin_lock_irq(&mapping->tree_lock);
if (PageDirty(page))
goto failed;
 
-   clear_page_mlock(page);
BUG_ON(page_has_private(page));
__delete_from_page_cache(page);
spin_unlock_irq(&mapping->tree_lock);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: blk, mm: lockdep irq lock inversion in linux-next

[Hugh Dickins]

On Mon, 17 Sep 2012, Hugh Dickins wrote:
> On Mon, 17 Sep 2012, Andrew Morton wrote:
> > On Sat, 15 Sep 2012 15:50:07 +0200
> > Sasha Levin  wrote:
> > 
> > > Hi all,
> > > 
> > > While fuzzing with trinity within a KVM tools guest on a linux-next 
> > > kernel, I
> > > got the lockdep warning at the bottom of this mail.
> > > 
> > > I've tried figuring out where it was introduced, but haven't found any 
> > > sign that
> > > any of the code in that area changed recently, so I'm probably missing 
> > > something...
> > > 
> > > 
> > > [ 157.966399] =
> > > [ 157.968523] [ INFO: possible irq lock inversion dependency detected ]
> > > [ 157.970029] 3.6.0-rc5-next-20120914-sasha-1-g802bf6c-dirty #340 
> > > Tainted: G W
> > > [ 157.970029] -
> > > [ 157.970029] trinity-child38/6642 just changed the state of lock:
> > > [ 157.970029] (&(&mapping->tree_lock)->rlock){+.+...}, at: 
> > > []
> > > invalidate_inode_pages2_range+0x20c/0x3c0
> > > [ 157.970029] but this lock was taken by another, SOFTIRQ-safe lock in 
> > > the past:
> > > [ 157.970029] (&(&new->queue_lock)->rlock){..-...}
> > > 
> > > [snippage]
> > 
> > gack, what a mess.  Thanks for the report.  AFAICT, what has happened is:
> > 
> > invalidate_complete_page2()
> > ->spin_lock_irq(&mapping->tree_lock)
> > ->clear_page_mlock()
> >   __clear_page_mlock()
> >   ->isolate_lru_page()
> > ->spin_lock_irq(&zone->lru_lock)
> > ->spin_unlock_irq(&zone->lru_lock)
> > 
> > whoops.  isolate_lru_page() just enabled local interrupts while we're
> > holding ->tree_lock, which is supposed to be an irq-save lock.  And in
> > a rather obscure way, lockdep caught it.
> 
> Congratulations on deciphering the lockdep report, I soon gave up.
> 
> But it looks like a bigger problem than your patch addresses:
> both filemap.c and rmap.c document tree_lock as nesting within
> lru_lock; and although it's possible that time has changed that,
> I doubt it.
> 
> I think invalidate_complete_page2() is simply wrong to be calling
> clear_page_mlock() while holding mapping->tree_lock (other callsites
> avoid doing so).  Maybe it should do a preliminary PageDirty test,
> then clear_page_mlock(), then take mapping->tree_lock, then repeat
> PageDirty test, without worrying about the odd case when it might
> clear mlock but then decide to back off the page.
> 
> Oh, hold on, that reminds me: a few months ago I was putting together
> a tidy-up patch near there, and it seemed to me inappropriate to be
> clearing mlock down in truncate/invalidate, that belongs better to
> when unmapping the page, doesn't it?
> 
> I'll look that out and try to finish it off.

I've completed that now, will send you a patchset of 4 in a moment.

The tidy-ups went rather beyond what we'd want to put in 3.6 or Cc stable
for this, so 1/4 is a one-liner to move up the offending clear_page_mlock(),
(which I think should replace your "mm: isolate_lru_page(): don't enable
local interrupts"), then the rest go on to make more sense of it.
Against 3.6-rc6: just the last gives a trivial reject on mmotm.

[PATCH 1/4] mm: fix invalidate_complete_page2 lock ordering
[PATCH 2/4] mm: remove vma arg from page_evictable
[PATCH 3/4] mm: clear_page_mlock in page_remove_rmap
[PATCH 4/4] mm: remove free_page_mlock

 Documentation/vm/unevictable-lru.txt |   10 ++---
 include/linux/swap.h |2 -
 include/linux/vm_event_item.h|2 -
 mm/internal.h|   12 ++-
 mm/ksm.c |2 -
 mm/memory.c  |   10 -
 mm/mlock.c   |   16 ++
 mm/page_alloc.c  |   17 ---
 mm/rmap.c|6 -
 mm/swap.c|2 -
 mm/truncate.c|3 --
 mm/vmscan.c  |   27 -
 mm/vmstat.c  |2 -
 13 files changed, 33 insertions(+), 78 deletions(-)

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

[PATCH v2 1/1] USB: EHCI: Tegra: Fix wrong register definition

[Jim Lin]

Fix the issue that EHCI registers, hostpc[0] and usbmode_ex,
are not correctly accessed on Tegra3 platform.

Signed-off-by: Jim Lin 
---
Changes in v2:
- Modify array size for reserved4[] only.
- Note that defining hostpc[0] is for a variable-length object.
 
 include/linux/usb/ehci_def.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/linux/usb/ehci_def.h b/include/linux/usb/ehci_def.h
index de4b9ed..b3c9d1b 100644
--- a/include/linux/usb/ehci_def.h
+++ b/include/linux/usb/ehci_def.h
@@ -171,7 +171,7 @@ struct ehci_regs {
 #define USBMODE_CM_HC  (3<<0)  /* host controller mode */
 #define USBMODE_CM_IDLE(0<<0)  /* idle state */
 
-   u32 reserved4[7];
+   u32 reserved4[6];
 
 /* Moorestown has some non-standard registers, partially due to the fact that
  * its EHCI controller has both TT and LPM support. HOSTPCx are extensions to
-- 
1.7.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] edac/85xx: fix error handle of mpc85xx_mc_err_probe

[Xie Shaohui-B21989]

> -Original Message-
> From: Shaun Ruffell [mailto:sruff...@digium.com]
> Sent: Wednesday, September 19, 2012 11:05 AM
> To: Xie Shaohui-B21989
> Cc: linux-e...@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> a...@linux-foundation.org; avoront...@mvista.com; linux-
> ker...@vger.kernel.org; grant.lik...@secretlab.ca
> Subject: Re: [PATCH] edac/85xx: fix error handle of mpc85xx_mc_err_probe
> 
> On Mon, Sep 17, 2012 at 10:32:59AM +, Xie Shaohui-B21989 wrote:
> > > -Original Message-
> > > From: Shaun Ruffell [mailto:sruff...@digium.com]
> > > Sent: Saturday, September 15, 2012 2:22 AM
> > > To: Xie Shaohui-B21989
> > > Cc: linux-e...@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > a...@linux-foundation.org; avoront...@mvista.com; linux-
> > > ker...@vger.kernel.org; grant.lik...@secretlab.ca
> > > Subject: Re: [PATCH] edac/85xx: fix error handle of
> > > mpc85xx_mc_err_probe
> > >
> > > On Thu, Sep 13, 2012 at 06:55:29PM +0800, Shaohui Xie wrote:
> > > > Error handle in case of DDR ECC off is wrong, sysfs entries have
> > > > not been created, so edac_mc_free which frees a mci instance
> > > > should not be called.
> > > > Also, free mci's memory in this case.
> > >
> > > Jus FYI: I ran into the same error in edac_mc_free() which I
> > > resolved in a slightly different way in some patches I sent
> > > previously. [1]
> > >
> > > [1] https://lkml.org/lkml/2012/9/14/475
> >
> > [S.H] Thanks! I did not aware of this patch when one of my colleague
> > asked me to have a look at the issue, It could save me some time if I
> > saw this patch earlier. :(
> >
> > BTW: seems you are using a different kernel tree with mine.
> 
> On the chance that I missing something important: Why do you say I was
> running a different kernel tree? I was against 3.6-rc2 when I original
> hit the problem.
[S.H] I'm using 3.6-rc4, and some codes in your patch I did not find them in 
3.6-rc4.


Best Regards, 
Shaohui Xie

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] poweroff: fix bug in orderly_poweroff

[Kees Cook]

On Tue, Sep 18, 2012 at 8:27 PM, hongfeng  wrote:
> orderly_poweroff is trying to poweroff platform by two steps:
> step 1: Call userspace application to poweroff
> step 2: If userspace poweroff fail, then do a force power off if force param 
> is set.
>
> The bug here is, step 1 is always successful with param UMH_NO_WAIT,
> should change to UMH_WAIT_PROC which will monitor the return value 
> ofuserspace application.
>
> Signed-off-by: Feng Hong 

Seems right to me.

Acked-by: Kees Cook 

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 117/135] NFS: return error from decode_getfh in decode open

[Ben Hutchings]

On Tue, 2012-09-18 at 22:26 -0300, Herton Ronaldo Krzesinski wrote:
> On Mon, Sep 17, 2012 at 01:38:22AM +0100, Ben Hutchings wrote:
> > 3.2-stable review patch.  If anyone has any objections, please let me know.
> > 
> > I'm not sure whether my expansion of the fix is correct here.
> > 
> > --
> > 
> > From: Weston Andros Adamson 
> > 
> > commit 01913b49cf1dc6409a07dd2a4cc6af2e77f3c410 upstream.
> > 
> > If decode_getfh failed, nfs4_xdr_dec_open would return 0 since the last
> > decode_* call must have succeeded.
> > 
> > Signed-off-by: Weston Andros Adamson 
> > Signed-off-by: Trond Myklebust 
> > [bwh: Backported to 3.2: this function makes two more function calls
> >  (no longer present in mainline) with the same issue, so fix them up
> >  similarly.]
> > Signed-off-by: Ben Hutchings 
> > ---
> >  fs/nfs/nfs4xdr.c |3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > --- a/fs/nfs/nfs4xdr.c
> > +++ b/fs/nfs/nfs4xdr.c
> > @@ -6113,12 +6113,15 @@ static int nfs4_xdr_dec_open(struct rpc_
> > status = decode_open(xdr, res);
> > if (status)
> > goto out;
> > -   if (decode_getfh(xdr, &res->fh) != 0)
> > +   status = decode_getfh(xdr, &res->fh);
> > +   if (status)
> > goto out;
> > -   if (decode_getfattr(xdr, res->f_attr, res->server,
> > -   !RPC_IS_ASYNC(rqstp->rq_task)) != 0)
> > +   status = decode_getfattr(xdr, res->f_attr, res->server,
> > +!RPC_IS_ASYNC(rqstp->rq_task));
> 
> I'm also not sure about the expansion of the fix here, not knowing very
> much about nfs. It seems that the code in some cases want to discard the
> status from decode_getfattr, for example nfs4_xdr_dec_rename is one case
> which does the same. Is it ok to return the status of decode_getfattr on
> nfs4_xdr_dec_open here? Or should it remain like it was before?

It looks like we try to get the file and directory attributes, and those
are nice to have but the open operation is still successful even if we
can't get them.  So my extra 'fixes' here are wrong.  Trond, is this
right?

Ben.

> > +   if (status)
> > goto out;
> > -   if (decode_restorefh(xdr) != 0)
> > +   status = decode_restorefh(xdr);
> > +   if (status)
> > goto out;
> > decode_getfattr(xdr, res->dir_attr, res->server,
> > !RPC_IS_ASYNC(rqstp->rq_task));
> 

-- 
Ben Hutchings
The world is coming to an end.  Please log off.


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

Re: [PATCH] spi: pl022: Add clk_{un}prepare() support in runtime PM

[viresh kumar]

On Tue, Sep 18, 2012 at 5:20 PM, Linus Walleij  wrote:
> On Tue, Sep 18, 2012 at 6:09 AM, viresh kumar  wrote:
>
>> Yes, we don't need to call prepare() again atleast for SPEAr. You are 
>> correct.
>> I saw the driver after a long time :)
>
> I'm asking because it's actually OK to do this, I was more asking whether it
> was really needed by any platforms...

Yes, I got that. Patch from Vipul is correct and should be there for
any platforms
which do anything in prepare/unprepare. But Atleast for SPEAr we don't need it.
But i would still insist in keeping it for completeness. :)

> We clk_disable() at runtime_suspend() and clk_enable() at runtime resume,
> and the driver gives hints to the runtime PM layer to autosuspend the
> driver whenever it's unused. Check the pm_runtime_* calls.

Ahh.. How could i miss it.

>> The amba layer is taking care of interface clock only and not
>> functional clock. So
>> i believe that's not the magic code. :)
>
> This clock is the one for the external bus. In some designs these two
> clocks are one and the same, and these won't currently get into any clock
> disabled states, sadly. (We need to fix that some day.)

I went through the code and found following in amba/bus.c:


static int amba_pm_runtime_suspend(struct device *dev)
{
struct amba_device *pcdev = to_amba_device(dev);
int ret = pm_generic_runtime_suspend(dev);

if (ret == 0 && dev->driver)
clk_disable(pcdev->pclk);

return ret;
}

static int amba_pm_runtime_resume(struct device *dev)
{
struct amba_device *pcdev = to_amba_device(dev);
int ret;

if (dev->driver) {
ret = clk_enable(pcdev->pclk);
/* Failure is probably fatal to the system, but... */
if (ret)
return ret;
}

return pm_generic_runtime_resume(dev);
}

If i am not wrong, these routines also get called with runtiime suspend/resume
of pl022? If that is the case, the even the interface clock of pl022 is getting
disabled when not in used.

And so for Architectures like SPEAr (where functional and interface
clock are controlled
by a single bit), we don't need anything else for power saving, with
respect to clocks.
Isn't it so?

@Vipul/Vinit: Can you please confirm this behavior?

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

[PATCH] poweroff: fix bug in orderly_poweroff

[hongfeng]

orderly_poweroff is trying to poweroff platform by two steps:
step 1: Call userspace application to poweroff
step 2: If userspace poweroff fail, then do a force power off if force param is 
set.

The bug here is, step 1 is always successful with param UMH_NO_WAIT,
should change to UMH_WAIT_PROC which will monitor the return value ofuserspace 
application.

Change-Id: I2f9ebbb90c0c2443780080ec9507c8d004e5da74
Signed-off-by: Feng Hong 
---
 kernel/sys.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/sys.c b/kernel/sys.c
index 241507f..1b30b30 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -2204,7 +2204,7 @@ static int __orderly_poweroff(void)
return -ENOMEM;
}
 
-   ret = call_usermodehelper_fns(argv[0], argv, envp, UMH_NO_WAIT,
+   ret = call_usermodehelper_fns(argv[0], argv, envp, UMH_WAIT_PROC,
  NULL, argv_cleanup, NULL);
if (ret == -ENOMEM)
argv_free(argv);
-- 
1.7.0.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 1/4] perf tools: remove sscanf extension %as

[Masami Hiramatsu]

(2012/09/14 10:54), Namhyung Kim wrote:
> Hi Irina,
> 
> (Adding Masami to Cc)

Thanks Irina and Namhyung :)

> On Fri, 14 Sep 2012 01:07:40 +0300, Irina Tirdea wrote:
>> From: Irina Tirdea 
>>
>> perf uses sscanf extension %as to read and allocate a
>> string in the same step. This is a non-standard extension
>> only present in new versions of glibc.
>>
>> Replacing the use of sscanf and %as with strtok_r calls
>> in order to parse a given string into its components.
>> This is needed in Android since bionic does not support
>> %as extension for sscanf.
>>
>> Signed-off-by: Irina Tirdea 
>> ---
>>  tools/perf/util/probe-event.c   |   25 ++---
>>  tools/perf/util/trace-event-parse.c |   18 --
>>  2 files changed, 26 insertions(+), 17 deletions(-)
>>
>> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
>> index 4ce04c2..685ddcf 100644
>> --- a/tools/perf/util/probe-event.c
>> +++ b/tools/perf/util/probe-event.c
>> @@ -1100,6 +1100,7 @@ static int parse_probe_trace_command(const char *cmd,
>>  struct probe_trace_point *tp = &tev->point;
>>  char pr;
>>  char *p;
>> +char *argv0_str = NULL, *fmt, *fmt1_str, *fmt2_str, *fmt3_str;
>>  int ret, i, argc;
>>  char **argv;
>>  
>> @@ -1116,14 +1117,19 @@ static int parse_probe_trace_command(const char *cmd,
>>  }
>>  
>>  /* Scan event and group name. */
>> -ret = sscanf(argv[0], "%c:%a[^/ \t]/%a[^ \t]",
>> - &pr, (float *)(void *)&tev->group,
>> - (float *)(void *)&tev->event);
>> -if (ret != 3) {
>> +argv0_str = strdup(argv[0]);
> 
> It seems you need to check return value of strdup.

Agreed.

>> +fmt1_str = strtok_r(argv0_str, ":", &fmt);
>> +fmt2_str = strtok_r(NULL, "/", &fmt);
>> +fmt3_str = strtok_r(NULL, " \t", &fmt);
>> +if (fmt1_str == NULL || strlen(fmt1_str) != 1 || fmt2_str == NULL
>> +|| fmt3_str == NULL) {
>>  semantic_error("Failed to parse event name: %s\n", argv[0]);
>>  ret = -EINVAL;
>>  goto out;
>>  }
>> +pr = fmt1_str[0];
>> +tev->group = strdup(fmt2_str);
>> +tev->event = strdup(fmt3_str);
>>  pr_debug("Group:%s Event:%s probe:%c\n", tev->group, tev->event, pr);
>>  
>>  tp->retprobe = (pr == 'r');
>> @@ -1135,10 +1141,13 @@ static int parse_probe_trace_command(const char *cmd,
>>  p++;
>>  } else
>>  p = argv[1];
>> -ret = sscanf(p, "%a[^+]+%lu", (float *)(void *)&tp->symbol,
>> - &tp->offset);
>> -if (ret == 1)
>> +fmt1_str = strtok_r(p, "+", &fmt);
>> +tp->symbol = strdup(fmt1_str);
> 
> Probably here too - although the original code didn't but I think it's
> needed.

right, it should be fixed.

>> +fmt2_str = strtok_r(NULL, "", &fmt);
>> +if (fmt2_str == NULL)
>>  tp->offset = 0;
>> +else
>> +tp->offset = strtoul(fmt2_str, NULL, 10);
>>  
>>  tev->nargs = argc - 2;
>>  tev->args = zalloc(sizeof(struct probe_trace_arg) * tev->nargs);
>> @@ -1162,6 +1171,8 @@ static int parse_probe_trace_command(const char *cmd,
>>  }
>>  ret = 0;
>>  out:
>> +if (argv0_str)
>> +free(argv0_str);
> 
> The free() can handle a NULL pointer safely.

I don't care about it, since there are already lots of "if (ptr) free(ptr)"
style code ;)

> 
>>  argv_free(argv);
>>  return ret;
>>  }

Thank you!

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PM / Sleep: use resume event when call dpm_resume_early

[hongfeng]

When dpm_suspend_noirq fail, state is PMSG_SUSPEND,
should change to PMSG_RESUME when dpm_resume_early is called

Change-Id: If815218d4934b4648e330235ab1ae26e713284bd
Signed-off-by: Feng Hong 
Signed-off-by: Raul Xiong 
Signed-off-by: Neil Zhang 
---
 drivers/base/power/main.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 0113adc..2700f2e 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -996,7 +996,7 @@ int dpm_suspend_end(pm_message_t state)
 
error = dpm_suspend_noirq(state);
if (error) {
-   dpm_resume_early(state);
+   dpm_resume_early(resume_event(state));
return error;
}
 
-- 
1.7.0.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] edac/85xx: fix error handle of mpc85xx_mc_err_probe

[Shaun Ruffell]

On Mon, Sep 17, 2012 at 10:32:59AM +, Xie Shaohui-B21989 wrote:
> > -Original Message-
> > From: Shaun Ruffell [mailto:sruff...@digium.com]
> > Sent: Saturday, September 15, 2012 2:22 AM
> > To: Xie Shaohui-B21989
> > Cc: linux-e...@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > a...@linux-foundation.org; avoront...@mvista.com; linux-
> > ker...@vger.kernel.org; grant.lik...@secretlab.ca
> > Subject: Re: [PATCH] edac/85xx: fix error handle of mpc85xx_mc_err_probe
> > 
> > On Thu, Sep 13, 2012 at 06:55:29PM +0800, Shaohui Xie wrote:
> > > Error handle in case of DDR ECC off is wrong, sysfs entries
> > > have not been created, so edac_mc_free which frees a mci
> > > instance should not be called.
> > > Also, free mci's memory in this case.
> > 
> > Jus FYI: I ran into the same error in edac_mc_free() which I
> > resolved in a slightly different way in some patches I sent
> > previously. [1]
> > 
> > [1] https://lkml.org/lkml/2012/9/14/475
>
> [S.H] Thanks! I did not aware of this patch when one of my
> colleague asked me to have a look at the issue, It could save me
> some time if I saw this patch earlier. :(
> 
> BTW: seems you are using a different kernel tree with mine.

On the chance that I missing something important: Why do you say I
was running a different kernel tree? I was against 3.6-rc2 when I
original hit the problem.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/4] tools lib traceevent: Use calloc were applicable

[Namhyung Kim]

On Mon, 17 Sep 2012 17:50:47 -0300, Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo 
>
> Replacing the equivalent open coded malloc + memset bits.
>
> Cc: David Ahern 
> Cc: Frederic Weisbecker 
> Cc: Jiri Olsa 
> Cc: Mike Galbraith 
> Cc: Namhyung Kim 
> Cc: Paul Mackerras 
> Cc: Peter Zijlstra 
> Cc: Stephane Eranian 
> Cc: Steven Rostedt 
> Link: http://lkml.kernel.org/n/tip-598fjtjbzal4wxh7fp0yv...@git.kernel.org
> Signed-off-by: Arnaldo Carvalho de Melo 
> ---
>  tools/lib/traceevent/event-parse.c |   44 
> 
>  1 file changed, 14 insertions(+), 30 deletions(-)
>
> diff --git a/tools/lib/traceevent/event-parse.c 
> b/tools/lib/traceevent/event-parse.c
> index 278f989..5e38d2f 100644
> --- a/tools/lib/traceevent/event-parse.c
> +++ b/tools/lib/traceevent/event-parse.c
> @@ -117,14 +117,7 @@ void breakpoint(void)
>  
>  struct print_arg *alloc_arg(void)
>  {
> - struct print_arg *arg;
> -
> - arg = malloc_or_die(sizeof(*arg));
> - if (!arg)
> - return NULL;
> - memset(arg, 0, sizeof(*arg));
> -
> - return arg;
> + return calloc(1, sizeof(struct print_arg));
>  }

This requires every callsite of the function should handle allocation
failure.

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

[PULL REQUEST] 3 fixes for md in 3.6.

[NeilBrown]

The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217:

  Linux 3.6-rc5 (2012-09-08 16:43:45 -0700)

are available in the git repository at:

  git://neil.brown.name/md/ tags/md-3.6-fixes

for you to fetch changes up to 6dafab6b1383e912cd252fa809570b484eb6e0dc:

  md: make sure metadata is updated when spares are activated or removed. 
(2012-09-19 12:54:22 +1000)


3 fixes for md in 3.6.

One reverts a recent patch which turns out to not be such a good
idea.
Other two fix minor bugs with the new (since 3.3) 'replacement' code
and have been tagged for -stable.


NeilBrown (3):
  Revert "md/raid5: For odirect-write performance, do not set 
STRIPE_PREREAD_ACTIVE."
  md/raid5: fix calculate of 'degraded' when a replacement becomes active.
  md: make sure metadata is updated when spares are activated or removed.

 drivers/md/md.c| 6 +-
 drivers/md/raid5.c | 6 +-
 2 files changed, 10 insertions(+), 2 deletions(-)


signature.asc
Description: PGP signature

Re: [PATCH v6 0/4] Runtime Interpreted Power Sequences

[Mark Brown]

On Thu, Sep 13, 2012 at 09:24:53AM -0600, Stephen Warren wrote:
> On 09/13/2012 01:29 AM, Mark Brown wrote:

> > The driver knows the power sequence.  Having to type the same sequence
> > into the DT or platform data for each board using the device wouuld be
> > retarded so we need the drivers to be able to give the sequence to the
> > library if they're going to be able to reuse it (which is a lot of what
> > Tomi is talking about).

> I believe that's trivial to implement. The relevant function is:

Right, that's what I'm saying - the code is mostly there now.

> It's up to the driver whether pseq comes from platform data or is
> hard-coded into the driver (or not provided at all, for the DT case).
> So, the only change needed to convert a "hard-coded" driver to this API
> is to convert the current custom data structure (or code) that describes
> the sequence into a struct platform_power_seq_set.

The framework could still help by providing ways to avoid having to copy
the structure and fill in the blanks for GPIO numbers (and anything else
that is numbered rather than named) by hand.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/6] dyndbg: in dynamic_emit_prefix, change inter-field separator

[Joe Perches]

On Tue, 2012-09-18 at 17:36 -0600, Jim Cromie wrote:
> dynamic_emit_prefix() currently separates modname, funcname, lineno
> with ':'.  This is confounds use of cut -d: , since the field
> positions can change per callsite with dynamic-debug.  So change
> inter-field separator to '.' and keep the ':' prefix terminator.
> 
> This improves the situation, but doesnt solve it entirely; if
> dyndbg==p is used instead of dyndbg==p[fmlt]+, the callsite is enabled
> but no prefix is added, so theres one less ':' in the message.
> Changing the terminator to ',' would fix this, and might be warranted,
> especially since pr_fmt() typically adds a ':' as well.
> 
> Joe Perches wasnt a fan of this, but his complaint was essentially
> that cut -d: was a poor way to do this kind of thing.  I concede that
> point, but note that the kernel is not in the habit of needlessly
> confounding users work, at least when accommodating them is so trivial.

And I still think this is ugly as it requires different parsing
by scripts when using combinations of +pfmlt


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [alsa-devel] [PATCH v2] ASoC: codecs: Add DA9055 codec driver

[Mark Brown]

On Fri, Sep 14, 2012 at 04:57:37PM +0530, Ashish Chavan wrote:

This looks like a good improvement, a few issues remain though:

> + /* DAC Routing control */
> + SOC_ENUM("DAC Left Select", da9055_dac_l_select),
> + SOC_ENUM("DAC Right Select", da9055_dac_r_select),

DAPM.  This even says its a routing control...

> + /* To select if MIC Bias powers MIC 1 or MIC 2 */
> + SOC_ENUM("Mic Bias Select", da9055_mic_bias_select),

This would normally be something controlled by the board...  what
exactly is this doing?  How does the MICBIAS relate to the microphone
inputs?

> + case SND_SOC_BIAS_STANDBY:
> + if (codec->dapm.bias_level == SND_SOC_BIAS_OFF) {
> + /* Enable VMID reference & master bias */
> + snd_soc_update_bits(codec, DA9055_REFERENCES,
> + DA9055_VMID_EN | DA9055_BIAS_EN,
> + DA9055_VMID_EN | DA9055_BIAS_EN);
> + }
> + regcache_sync(da9055->regmap);

Doing the sync every time is very odd, why is it only done on
transitions from _OFF?  Given that there's no regulator support here
it's also a bit surprising that you need to do a sync outside of system
suspend...

> + da9055->mclk_rate   = 0;/* This will be set from set_sysclk() */
> + da9055->master  = 0;/* This will be set from set_fmt() */

You use kzalloc...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 -next, RESEND] av32: Make sure _TIF_BREAKPOINT is defined

[Al Viro]

On Tue, Sep 18, 2012 at 08:19:21PM +0200, Geert Uytterhoeven wrote:

> Still not fixed after almost 4 months...

Gyah...  I really need to trim that pile of internal branches; the fixed
commit had not been cherry-picked into for-next.  My apologies ;-/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V3 8/8] DA9058 REGULATOR driver

[Mark Brown]

On Mon, Sep 17, 2012 at 12:07:11PM +, Opensource [Anthony Olech] wrote:

> > > Can you suggest a future proofed way of using the new regulator API
> > > that would solve my problem?

> > As I said you should set the voltage as part of the set voltage operation.

> So I will have to write my own set_voltage_sel() callback instead of using
> the default regulator_set_voltage_sel_regmap() ??

Yes.

> Well, I did try hard to use your defaults, but I suppose there is nothing to
> stop me calling regulator_set_voltage_sel_regmap() explicitly as the first
> part of my set_voltage_sel() callback before setting the ramp_enable bit.
> Then my implemenation of the set_voltage_time_sel() callback needs to
> just simply return the ramp time.

The point with using the framework stuff is that you should factor out
common code, if what you have is not common code then don't do crazy
things in other ops to try to paper over that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] HID: leave dev_rdesc unmodified and use it for comparisons

[Kevin Daughtridge]

The dev_rdesc member of the hid_device structure is meant to store the original
report descriptor received from the device, but it is currently passed to any
report_fixup method before it is copied to the rdesc member. This patch moves
the kmemdup to before, not after, the report_fixup call, keeping dev_rdesc
unchanged.

usbhid's hid_post_reset checks the report descriptor currently returned by the
device against a descriptor that may have been modified by a driver's
report_fixup method. That leaves some devices nonfunctional after a resume, with
a "reset_resume error 1" reported. This patch checks the new descriptor against
the unmodified dev_rdesc instead.

BugLink:http://bugs.launchpad.net/bugs/1049623
Signed-off-by: Kevin Daughtridge
---
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -775,12 +775,14 @@ int hid_open_report(struct hid_device *d
return -ENODEV;
size = device->dev_rsize;
 
+	start = kmemdup(start, size, GFP_KERNEL);

+   if (start == NULL)
+   return -ENOMEM;
+
if (device->driver->report_fixup)
start = device->driver->report_fixup(device, start, &size);
 
-	device->rdesc = kmemdup(start, size, GFP_KERNEL);

-   if (device->rdesc == NULL)
-   return -ENOMEM;
+   device->rdesc = start;
device->rsize = size;
 
 	parser = vzalloc(sizeof(struct hid_parser));

--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -1436,7 +1436,7 @@ static int hid_post_reset(struct usb_int
kfree(rdesc);
return 1;
}
-   status = memcmp(rdesc, hid->rdesc, hid->rsize);
+   status = memcmp(rdesc, hid->dev_rdesc, hid->rsize);
kfree(rdesc);
if (status != 0) {
dbg_hid("report descriptor changed\n");

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

Re: [PATCH v3 04/15] dmaengine: Pass flags via device_prep_dma_cyclic() callback

[Shawn Guo]

On Fri, Sep 14, 2012 at 03:05:47PM +0300, Peter Ujfalusi wrote:
> Change the parameter list of device_prep_dma_cyclic() so the DMA drivers
> can receive the flags coming from clients.
> This feature can be used during audio operation to disable all audio
> related interrupts when the DMA_PREP_INTERRUPT is cleared from the flags.
> 
> Signed-off-by: Peter Ujfalusi 
> CC: Nicolas Ferre 
> CC: Barry Song 
> CC: Srinidhi Kasagar 
> CC: Russell King - ARM Linux 
> CC: Vista Silicon 
> CC: Zhangfei Gao 
> CC: Shawn Guo 
> CC: Laxman Dewangan 
> ---
...
>  drivers/dma/imx-dma.c | 2 +-
>  drivers/dma/imx-sdma.c| 2 +-
...
>  drivers/dma/mxs-dma.c | 2 +-

Acked-by: Shawn Guo 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usbhid: call report_fixup before comparing descriptors

[Kevin Daughtridge]

On 09/18/12 09:16 N.U., Henrik Rydberg wrote:

You can use dev_rdesc here instead.
Hi Henrik. Thanks for the tip. I tried comparing rdesc to hid->dev_rdesc 
without any report_fixup call, but the problem (device nonfunctional 
with "reset_resume error 1" message) still occurred. Upon looking at 
hid_open_report, I noticed that it calls report_fixup on dev_rdesc 
(pointer copied to "start") before it is kmemdup'd to rdesc. For most 
HID drivers, the report_fixup method directly modifies and returns the 
passed structure instead of returning a new pointer, so dev_rdesc is 
also modified. Assuming that dev_rdesc is supposed to be the unmodified 
data, I moved the report_fixup call in hid_open_report to after the 
kmemdup. This combination successfully solves the original problem. I'll 
submit a new patch version presently that addresses both points.


On 09/18/12 05:00 N.U., Sergei Shtylyov wrote:
Your patch is whitespace damaged, i.e. has all tabs replaced by spaces. 
Hi Sergei. Thanks for catching that. The munging problem was supposedly 
fixed in Thunderbird years ago! I guess I'll just mail the new version 
from the command line.


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

Re: [PATCH v2 1/3] tracing,x86: add a TSC trace_clock

[Steven Rostedt]

On Tue, 2012-09-18 at 14:37 -0700, David Sharp wrote:
> In order to promote interoperability between userspace tracers and ftrace,
> add a trace_clock that reports raw TSC values which will then be recorded
> in the ring buffer. Userspace tracers that also record TSCs are then on
> exactly the same time base as the kernel and events can be unambiguously
> interlaced.
> 
> Tested: Enabled a tracepoint and the "tsc" trace_clock and saw very large
> timestamp values.
> 
> v2:
> Move arch-specific bits out of generic code.
> 
> Google-Bug-Id: 6980623
> Signed-off-by: David Sharp 
> Cc: Steven Rostedt 
> Cc: Masami Hiramatsu 


> Cc: Ingo Molnar 
> Cc: Thomas Gleixner 
> Cc: "H. Peter Anvin" 

Again this needs an Acked-by from one of the above.

-- Steve


> ---
>  arch/x86/include/asm/trace_clock.h |   16 
>  arch/x86/kernel/Makefile   |1 +
>  arch/x86/kernel/trace_clock.c  |   20 
>  include/asm-generic/trace_clock.h  |   15 +++
>  include/linux/trace_clock.h|2 ++
>  kernel/trace/trace.c   |1 +
>  6 files changed, 55 insertions(+), 0 deletions(-)
>  create mode 100644 arch/x86/include/asm/trace_clock.h
>  create mode 100644 arch/x86/kernel/trace_clock.c
>  create mode 100644 include/asm-generic/trace_clock.h
> 
> diff --git a/arch/x86/include/asm/trace_clock.h 
> b/arch/x86/include/asm/trace_clock.h
> new file mode 100644
> index 000..0b1f391
> --- /dev/null
> +++ b/arch/x86/include/asm/trace_clock.h
> @@ -0,0 +1,16 @@
> +#ifndef _ASM_X86_TRACE_CLOCK_H
> +#define _ASM_X86_TRACE_CLOCK_H
> +
> +#include 
> +#include 
> +
> +#ifdef CONFIG_X86_TSC
> +
> +extern u64 notrace trace_clock_x86_tsc(void);
> +
> +# define ARCH_TRACE_CLOCKS \
> + { trace_clock_x86_tsc,  "tsc" },
> +
> +#endif
> +
> +#endif  /* _ASM_X86_TRACE_CLOCK_H */
> diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
> index 8215e56..0ee9344 100644
> --- a/arch/x86/kernel/Makefile
> +++ b/arch/x86/kernel/Makefile
> @@ -62,6 +62,7 @@ obj-$(CONFIG_X86_REBOOTFIXUPS)  += reboot_fixups_32.o
>  obj-$(CONFIG_DYNAMIC_FTRACE) += ftrace.o
>  obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o
>  obj-$(CONFIG_FTRACE_SYSCALLS)+= ftrace.o
> +obj-$(CONFIG_X86_TSC)+= trace_clock.o
>  obj-$(CONFIG_KEXEC)  += machine_kexec_$(BITS).o
>  obj-$(CONFIG_KEXEC)  += relocate_kernel_$(BITS).o crash.o
>  obj-$(CONFIG_CRASH_DUMP) += crash_dump_$(BITS).o
> diff --git a/arch/x86/kernel/trace_clock.c b/arch/x86/kernel/trace_clock.c
> new file mode 100644
> index 000..b8959f8
> --- /dev/null
> +++ b/arch/x86/kernel/trace_clock.c
> @@ -0,0 +1,20 @@
> +/*
> + * X86 trace clocks
> + */
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * trace_clock_x86_tsc(): A clock that is just the cycle counter.
> + *
> + * Unlike the other clocks, this is not in nanoseconds.
> + */
> +u64 notrace trace_clock_x86_tsc(void)
> +{
> + u64 ret;
> + rdtsc_barrier();
> + rdtscll(ret);
> +
> + return ret;
> +}
> diff --git a/include/asm-generic/trace_clock.h 
> b/include/asm-generic/trace_clock.h
> new file mode 100644
> index 000..648cdcd
> --- /dev/null
> +++ b/include/asm-generic/trace_clock.h
> @@ -0,0 +1,15 @@
> +/*
> + * Arch-specific trace clocks.
> + */
> +#ifndef _ASM_GENERIC_TRACE_CLOCK_H
> +#define _ASM_GENERIC_TRACE_CLOCK_H
> +
> +/*
> + * Additional trace clocks added to the trace_clocks
> + * array in kernel/trace/trace.c
> + */
> +#ifndef ARCH_TRACE_CLOCKS
> +# define ARCH_TRACE_CLOCKS
> +#endif
> +
> +#endif  /* _ASM_GENERIC_TRACE_CLOCK_H */
> diff --git a/include/linux/trace_clock.h b/include/linux/trace_clock.h
> index 4eb4902..d563f37 100644
> --- a/include/linux/trace_clock.h
> +++ b/include/linux/trace_clock.h
> @@ -12,6 +12,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  extern u64 notrace trace_clock_local(void);
>  extern u64 notrace trace_clock(void);
>  extern u64 notrace trace_clock_global(void);
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 5c38c81..92fb08e 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -480,6 +480,7 @@ static struct {
>   { trace_clock_local,"local" },
>   { trace_clock_global,   "global" },
>   { trace_clock_counter,  "counter" },
> + ARCH_TRACE_CLOCKS
>  };
>  
>  int trace_clock_id;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] drivers/mmc/host/mxs-mmc.c: fix error return code

[Shawn Guo]

On Mon, Sep 17, 2012 at 10:15:28AM +0200, Peter Senna Tschudin wrote:
> From: Peter Senna Tschudin 
> 
> Convert a nonnegative error return code to a negative one, as returned
> elsewhere in the function.
> 
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
> 
> // 
> (
> if@p1 (\(ret < 0\|ret != 0\))
>  { ... return ret; }
> |
> ret@p1 = 0
> )
> ... when != ret = e1
> when != &ret
> *if(...)
> {
>   ... when != ret = e2
>   when forall
>  return ret;
> }
> // 
> 
> Signed-off-by: Peter Senna Tschudin 

Acked-by: Shawn Guo 

> ---
>  drivers/mmc/host/mxs-mmc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c
> index 80d1e6d..afd8fdd 100644
> --- a/drivers/mmc/host/mxs-mmc.c
> +++ b/drivers/mmc/host/mxs-mmc.c
> @@ -674,6 +674,7 @@ static int mxs_mmc_probe(struct platform_device *pdev)
>   if (!ssp->dmach) {
>   dev_err(mmc_dev(host->mmc),
>   "%s: failed to request dma\n", __func__);
> + ret = -ENODEV;
>   goto out_clk_put;
>   }
>  
> -- 
> 1.7.11.4
> 

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

Re: [RFC][PATCH] Reset PCIe devices to address DMA problem on kdump with iommu

[Takao Indoh]

(2012/09/15 5:03), Konrad Rzeszutek Wilk wrote:

As to the boot parameter to enable this function, you suggested using
reset_devices. I found that on a certain platform resetting devices
caused PCIe error due to a hardware bug. Therefore I think we need
new parameter apart from reset_devices to disable this function on
such a machine.


Wouldn't a DMI quirk be better for this? That way the second kernel
internally would know not to do this.


That sounds good. I'll try it, thanks.

Thanks,
Takao Indoh

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v8 2/3] perf: move stat related code to util/stat.c

[Xiao Guangrong]

On 09/19/2012 03:18 AM, David Ahern wrote:
> On 9/17/12 2:31 AM, Dong Hao wrote:
>> From: Xiao Guangrong 
>>
>> Then, the code can be shared between kvm events and perf stat
>>
>> [ Dong Hao : rebase it on acme's git tree ]
>> Signed-off-by: Xiao Guangrong 
>> Signed-off-by: Dong Hao 
>> ---
>>   tools/perf/Makefile   |1 +
>>   tools/perf/builtin-stat.c |   56 
>> +--
>>   tools/perf/util/stat.c|   57 
>> +
>>   tools/perf/util/stat.h|   16 
>>   4 files changed, 76 insertions(+), 54 deletions(-)
>>   create mode 100644 tools/perf/util/stat.c
>>   create mode 100644 tools/perf/util/stat.h
> 
> Does not apply to Arnaldo's latest perf/core branch.

The patch has already been applied to this branch:
http://git.kernel.org/?p=linux/kernel/git/acme/linux.git;a=commit;h=0007eceaceb11520071d053acfe06ee3326b1d13

You or we can improve rel_stddev_stats after perf-stat's code is fixed. :)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 bluetooth tree

[Stephen Rothwell]

Hi Gustavo,

After merging the bluetooth tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/bluetooth/btusb.c:100:2: error: expected '}' before '{' token

Caused by commit 493969cf4728 ("Bluetooth: Add support for BCM20702A0
[04ca, 2003]").  That wasn't really well tested, now was it? :-(

I have used the bluetooth tree from next-20120918 for today.

BTW, why is that commit not signed off by its author?
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpaT2iANhb5K.pgp
Description: PGP signature

[PATCH] mfd: use IRQF_ONESHOT for max8925

[Fengguang Wu]

Generated by: scripts/coccinelle/misc/irqf_oneshot.cocci

Make sure threaded IRQs without a primary handler are always request
with IRQF_ONESHOT.

Signed-off-by: Fengguang Wu 
---

Please take the patch only if it's a positive warning. Thanks!

 drivers/mfd/max8925-core.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux.orig/drivers/mfd/max8925-core.c   2012-09-18 08:22:36.381180459 
+0800
+++ linux/drivers/mfd/max8925-core.c2012-09-19 09:37:52.471984440 +0800
@@ -547,7 +547,7 @@ static int max8925_irq_init(struct max89
goto tsc_irq;
}
 
-   ret = request_threaded_irq(irq, NULL, max8925_irq, flags,
+   ret = request_threaded_irq(irq, NULL, max8925_irq, flags | IRQF_ONESHOT,
   "max8925", chip);
if (ret) {
dev_err(chip->dev, "Failed to request core IRQ: %d\n", ret);
@@ -565,7 +565,7 @@ tsc_irq:
chip->tsc_irq = pdata->tsc_irq;
 
ret = request_threaded_irq(chip->tsc_irq, NULL, max8925_tsc_irq,
-  flags, "max8925-tsc", chip);
+  flags | IRQF_ONESHOT, "max8925-tsc", chip);
if (ret) {
dev_err(chip->dev, "Failed to request TSC IRQ: %d\n", ret);
chip->tsc_irq = 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging: ozwpan: compare pointer to NULL rather than 0

[Fengguang Wu]

Generated by: scripts/coccinelle/null/badzero.cocci

Signed-off-by: Fengguang Wu 
---

 drivers/staging/ozwpan/ozcdev.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

--- linux.orig/drivers/staging/ozwpan/ozcdev.c  2012-09-19 09:33:20.887977986 
+0800
+++ linux/drivers/staging/ozwpan/ozcdev.c   2012-09-19 09:33:32.383978265 
+0800
@@ -104,10 +104,10 @@ ssize_t oz_cdev_read(struct file *filp,
if (pd)
oz_pd_get(pd);
spin_unlock_bh(&g_cdev.lock);
-   if (pd == 0)
+   if (pd == NULL)
return -1;
ctx = oz_cdev_claim_ctx(pd);
-   if (ctx == 0)
+   if (ctx == NULL)
goto out2;
n = ctx->rd_in - ctx->rd_out;
if (n < 0)
@@ -157,11 +157,11 @@ ssize_t oz_cdev_write(struct file *filp,
if (pd)
oz_pd_get(pd);
spin_unlock_bh(&g_cdev.lock);
-   if (pd == 0)
+   if (pd == NULL)
return -1;
eb = &pd->elt_buff;
ei = oz_elt_info_alloc(eb);
-   if (ei == 0) {
+   if (ei == NULL) {
count = 0;
goto out;
}
@@ -410,7 +410,7 @@ int oz_cdev_start(struct oz_pd *pd, int
return 0;
}
ctx = kzalloc(sizeof(struct oz_serial_ctx), GFP_ATOMIC);
-   if (ctx == 0)
+   if (ctx == NULL)
return -ENOMEM;
atomic_set(&ctx->ref_count, 1);
ctx->tx_seq_num = 1;
@@ -424,7 +424,7 @@ int oz_cdev_start(struct oz_pd *pd, int
spin_unlock_bh(&pd->app_lock[OZ_APPID_SERIAL-1]);
}
spin_lock(&g_cdev.lock);
-   if ((g_cdev.active_pd == 0) &&
+   if ((g_cdev.active_pd == NULL) &&
(memcmp(pd->mac_addr, g_cdev.active_addr, ETH_ALEN) == 0)) {
oz_pd_get(pd);
g_cdev.active_pd = pd;
@@ -477,7 +477,7 @@ void oz_cdev_rx(struct oz_pd *pd, struct
int ix;
 
ctx = oz_cdev_claim_ctx(pd);
-   if (ctx == 0) {
+   if (ctx == NULL) {
oz_trace("Cannot claim serial context.\n");
return;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: qemu-kvm loops after kernel udpate

[Stephen Rothwell]

Hi Andrew,

On Tue, 18 Sep 2012 17:20:29 -0700 Andrew Morton  
wrote:
>
> On Wed, 19 Sep 2012 10:00:34 +1000 Stephen Rothwell  
> wrote:
> 
> > On Tue, 18 Sep 2012 12:46:46 -0700 Andrew Morton 
> >  wrote:
> > >
> > > hm, thanks.  This will probably take some time to resolve so I think
> > > I'll drop
> > > 
> > > mm-move-all-mmu-notifier-invocations-to-be-done-outside-the-pt-lock.patch
> > > mm-move-all-mmu-notifier-invocations-to-be-done-outside-the-pt-lock-fix.patch
> > > mm-move-all-mmu-notifier-invocations-to-be-done-outside-the-pt-lock-fix-fix.patch
> > > mm-wrap-calls-to-set_pte_at_notify-with-invalidate_range_start-and-invalidate_range_end.patch
> > 
> > Should I attempt to remove these from the akpm tree in linux-next today?
> 
> That would be best - there's no point in having people test (and debug)
> dead stuff.

OK, I removed them.

> > Or should I just wait for a new mmotm?
> 
> You could be brave and test http://ozlabs.org/~akpm/mmots/ for me :)

Brave? maybe.  Stupid? no :-)

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


pgpnooEkwgr1C.pgp
Description: PGP signature

[PATCH] mfd: use IRQF_ONESHOT for twl6040

[Fengguang Wu]

Generated by: scripts/coccinelle/misc/irqf_oneshot.cocci

Make sure threaded IRQs without a primary handler are always request
with IRQF_ONESHOT.

Signed-off-by: Fengguang Wu 
---

Please take the patch only if it's a positive warning. Thanks!

 drivers/mfd/twl6040-core.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux.orig/drivers/mfd/twl6040-core.c   2012-09-18 08:22:36.381180459 
+0800
+++ linux/drivers/mfd/twl6040-core.c2012-09-19 09:27:15.947969313 +0800
@@ -584,7 +584,7 @@ static int __devinit twl6040_probe(struc
goto irq_init_err;
 
ret = request_threaded_irq(twl6040->irq_base + TWL6040_IRQ_READY,
-  NULL, twl6040_naudint_handler, 0,
+  NULL, twl6040_naudint_handler, IRQF_ONESHOT,
   "twl6040_irq_ready", twl6040);
if (ret) {
dev_err(twl6040->dev, "READY IRQ request failed: %d\n",
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

pull request: bluetooth-next 2012-09-18

[Gustavo Padovan]

Hi,

My last pull request to 3.7. There is nothin really exciting here.
The biggest stuff is hci_connect() code re-write, the rest is just bugfixes,
clean up and small improvements. 

Please pull!

Gustavo

---
The following changes since commit 22c5649eef0fc37532e20c14d2656b28ca708a69:

  p54: fix powerpc gcc warnings (2012-08-13 15:28:35 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next master

for you to fetch changes up to 3c860f3d3cd75f0e1a33ba6eb9f96bdb2194ec41:

  Bluetooth: Add support for BCM20702A0 [04ca, 2003] (2012-09-18 21:22:39 -0300)


Andrei Emeltchenko (7):
  Bluetooth: trivial: Shorten variable scope
  Bluetooth: trivial: Use preferred method for NULL check
  Bluetooth: Remove unneeded zero init
  Bluetooth: trivial: Make hci_chan_del return void
  Bluetooth: trivial: Remove empty line
  Bluetooth: debug: Print refcnt for hci_dev
  Bluetooth: AMP: Add Read Data Block Size to amp_init

Gustavo Padovan (1):
  Bluetooth: Add USB_VENDOR_AND_INTERFACE_INFO() for Broadcom/Foxconn

Jaroslav Resler (1):
  Bluetooth: Add support for BCM20702A0 [04ca, 2003]

Johan Hedberg (2):
  Bluetooth: mgmt: Implement support for passkey notification
  Bluetooth: Update management interface revision

Mikel Astiz (3):
  Bluetooth: Add more HCI error codes
  Bluetooth: Fix minor coding style in hci_event.c
  Bluetooth: mgmt: Add device disconnect reason

Peter Senna Tschudin (5):
  drivers/bluetooth/bluecard_cs.c: removes unnecessary semicolon
  drivers/bluetooth/hci_ldisc.c: removes unnecessary semicolon
  drivers/bluetooth/hci_ll.c: removes unnecessary semicolon
  drivers/bluetooth/hci_vhci.c: removes unnecessary semicolon
  drivers/bluetooth/btuart_cs.c: removes unnecessary semicolon

Sachin Kamat (1):
  Bluetooth: Use module_platform_driver() in btwilink.c file

Syam Sidhardhan (2):
  Bluetooth: debug: Correct the PSM printing
  Bluetooth: Use kref for l2cap channel reference counting

Vinicius Costa Gomes (8):
  Bluetooth: Remove some functions from being exported
  Bluetooth: Rename LE and ACL connection functions
  Bluetooth: Refactor LE connection into its own function
  Bluetooth: Refactor ACL connection into its own function
  Bluetooth: Refactor SCO connection into its own function
  Bluetooth: Simplify a the connection type handling
  Bluetooth: Add type information to the hci_connect() debug statement
  Bluetooth: Fix establishing ESCO links

Wei Yongjun (1):
  Bluetooth: btmrvl: remove pointless conditional before kfree_skb()

 drivers/bluetooth/bluecard_cs.c  |   2 +-
 drivers/bluetooth/btmrvl_sdio.c  |   3 +-
 drivers/bluetooth/btuart_cs.c|   2 +-
 drivers/bluetooth/btusb.c|   3 +-
 drivers/bluetooth/btwilink.c |  16 +--
 drivers/bluetooth/hci_ldisc.c|   2 +-
 drivers/bluetooth/hci_ll.c   |   2 +-
 drivers/bluetooth/hci_vhci.c |   2 +-
 include/net/bluetooth/hci.h  |  21 +
 include/net/bluetooth/hci_core.h |  26 +--
 include/net/bluetooth/l2cap.h|   3 +-
 include/net/bluetooth/mgmt.h |  16 +++
 net/bluetooth/af_bluetooth.c |  10 ++---
 net/bluetooth/hci_conn.c | 100 
+
 net/bluetooth/hci_core.c |   6 ++-
 net/bluetooth/hci_event.c|  99 +---
 net/bluetooth/l2cap_core.c   |  17 +++
 net/bluetooth/mgmt.c |  28 +---
 18 files changed, 255 insertions(+), 103 deletions(-)


pgpSadFqvxDgI.pgp
Description: PGP signature

[PATCH] mfd: use IRQF_ONESHOT for 88pm860x

[Fengguang Wu]

Generated by: scripts/coccinelle/misc/irqf_oneshot.cocci

Make sure threaded IRQs without a primary handler are always request
with IRQF_ONESHOT.

Signed-off-by: Fengguang Wu 
---

Please take the patch only if it's a positive warning. Thanks!

 drivers/mfd/88pm860x-core.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux.orig/drivers/mfd/88pm860x-core.c  2012-09-18 08:22:36.377180459 
+0800
+++ linux/drivers/mfd/88pm860x-core.c   2012-09-19 09:27:14.335969275 +0800
@@ -498,7 +498,7 @@ static int __devinit device_irq_init(str
 #endif
}
 
-   ret = request_threaded_irq(chip->core_irq, NULL, pm860x_irq, flags,
+   ret = request_threaded_irq(chip->core_irq, NULL, pm860x_irq, flags | 
IRQF_ONESHOT,
   "88pm860x", chip);
if (ret) {
dev_err(chip->dev, "Failed to request IRQ: %d\n", ret);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86: Don't clobber top of pt_regs in nested NMI

[Salman Qazi]

The nested NMI modifies the place (instruction, flags and stack)
that the first NMI will iret to.  However, the copy of registers
modified is exactly the one that is the part of pt_regs in
the first NMI.  This can change the behaviour of the first NMI.

In particular, Google's arch_trigger_all_cpu_backtrace handler
also prints regions of memory surrounding addresses appearing in
registers.  This results in handled exceptions, after which nested NMIs
start coming in.  These nested NMIs change the value of registers
in pt_regs.  This can cause the original NMI handler to produce
incorrect output.

We solve this problem by introducing an extra copy of the iret
registers that are exclusively a part of pt_regs and are not modified
elsewhere.  The downside is that the do_nmi function can no longer
change the control flow, as any values it writes to these five
registers will be discarded.

Signed-off-by: Salman Qazi 
---
 arch/x86/kernel/entry_64.S |   20 +++-
 1 files changed, 19 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 69babd8..40ddb6d 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1724,6 +1724,18 @@ repeat_nmi:
 end_repeat_nmi:
 
/*
+* We went a running NMI handling routine to have a consistent
+* picture of register state.  This should hold true even if
+* there is a nested NMI.  Therefore, we let the nested NMI
+* play with the previous copy of these registers and leave this
+* new copy unmodified for do_nmi()
+*/
+   .rept 5
+   pushq_cfi 4*8(%rsp)
+   .endr
+   CFI_DEF_CFA_OFFSET SS+8-RIP
+
+   /*
 * Everything below this point can be preempted by a nested
 * NMI if the first NMI took an exception and reset our iret stack
 * so that we repeat another NMI.
@@ -1771,7 +1783,13 @@ nmi_swapgs:
 nmi_restore:
RESTORE_ALL 8
/* Clear the NMI executing stack variable */
-   movq $0, 10*8(%rsp)
+   movq $0, 15*8(%rsp)
+
+   /* Pop the extra copy of iret context that was saved above
+* just for do_nmi()
+*/
+   addq $5*8, %rsp
+
jmp irq_return
CFI_ENDPROC
 END(nmi)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 117/135] NFS: return error from decode_getfh in decode open

[Herton Ronaldo Krzesinski]

On Mon, Sep 17, 2012 at 01:38:22AM +0100, Ben Hutchings wrote:
> 3.2-stable review patch.  If anyone has any objections, please let me know.
> 
> I'm not sure whether my expansion of the fix is correct here.
> 
> --
> 
> From: Weston Andros Adamson 
> 
> commit 01913b49cf1dc6409a07dd2a4cc6af2e77f3c410 upstream.
> 
> If decode_getfh failed, nfs4_xdr_dec_open would return 0 since the last
> decode_* call must have succeeded.
> 
> Signed-off-by: Weston Andros Adamson 
> Signed-off-by: Trond Myklebust 
> [bwh: Backported to 3.2: this function makes two more function calls
>  (no longer present in mainline) with the same issue, so fix them up
>  similarly.]
> Signed-off-by: Ben Hutchings 
> ---
>  fs/nfs/nfs4xdr.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> --- a/fs/nfs/nfs4xdr.c
> +++ b/fs/nfs/nfs4xdr.c
> @@ -6113,12 +6113,15 @@ static int nfs4_xdr_dec_open(struct rpc_
>   status = decode_open(xdr, res);
>   if (status)
>   goto out;
> - if (decode_getfh(xdr, &res->fh) != 0)
> + status = decode_getfh(xdr, &res->fh);
> + if (status)
>   goto out;
> - if (decode_getfattr(xdr, res->f_attr, res->server,
> - !RPC_IS_ASYNC(rqstp->rq_task)) != 0)
> + status = decode_getfattr(xdr, res->f_attr, res->server,
> +  !RPC_IS_ASYNC(rqstp->rq_task));

I'm also not sure about the expansion of the fix here, not knowing very
much about nfs. It seems that the code in some cases want to discard the
status from decode_getfattr, for example nfs4_xdr_dec_rename is one case
which does the same. Is it ok to return the status of decode_getfattr on
nfs4_xdr_dec_open here? Or should it remain like it was before?

> + if (status)
>   goto out;
> - if (decode_restorefh(xdr) != 0)
> + status = decode_restorefh(xdr);
> + if (status)
>   goto out;
>   decode_getfattr(xdr, res->dir_attr, res->server,
>   !RPC_IS_ASYNC(rqstp->rq_task));

-- 
[]'s
Herton
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: 3.6rc6 slab corruption.

[Raghavendra K T]

On 09/19/2012 02:19 AM, Linus Torvalds wrote:

On Tue, Sep 18, 2012 at 1:37 PM, Konrad Rzeszutek Wilk
  wrote:


30 words. ~360 + 29 spaces + NULL = 390?


Just allocate the max then. That's tiny.

And it's actually just 330: max ten characters for an unsigned 32-bit number.



Okay, I think you meant 32*11 = 352 chars.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: 3.6rc6 slab corruption.

[Raghavendra K T]

On 09/19/2012 01:54 AM, David Rientjes wrote:

On Tue, 18 Sep 2012, Konrad Rzeszutek Wilk wrote:


diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 2340f69..309b235 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -524,6 +524,7 @@ EXPORT_SYMBOL_GPL(debugfs_create_blob);
  struct array_data {
void *array;
u32 elements;
+   struct mutex lock;


This should be a spinlock.



I remember we used debugfs because traceprintks used spinlock.
The code was being accessed from paravirt spinlock.

Sorry for joining late (Time Zone difference)
CCing Jeremy




  };

  static int u32_array_open(struct inode *inode, struct file *file)
@@ -580,6 +581,7 @@ static ssize_t u32_array_read(struct file *file, char 
__user *buf, size_t len,
struct array_data *data = inode->i_private;
size_t size;

+   mutex_lock(&data->lock);
if (*ppos == 0) {
if (file->private_data) {
kfree(file->private_data);
@@ -594,6 +596,7 @@ static ssize_t u32_array_read(struct file *file, char 
__user *buf, size_t len,
if (file->private_data)
size = strlen(file->private_data);

+   mutex_unlock(&data->lock);
return simple_read_from_buffer(buf, len, ppos,
file->private_data, size);
  }


Your critical section isn't entirely covered since you're still accessing
file->private_data in the call to simple_read_from_buffer().  What happens
if a concurrent reader does file->private_data = NULL immediately after
your unlock?




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 7/9] ARM: OMAP: iommu: optimize save and restore routines

[Omar Ramirez Luna]

Hi Tony,

On 18 September 2012 13:04, Tony Lindgren  wrote:
> * Omar Ramirez Luna  [120912 12:47]:
>> --- a/arch/arm/plat-omap/include/plat/iommu.h
>> +++ b/arch/arm/plat-omap/include/plat/iommu.h
>> @@ -27,6 +27,13 @@ struct iotlb_entry {
>>   };
>>  };
>>
>> +/* context registers */
>> +struct iommu_regs {
>> + u32 irqen;
>> + u32 cntl;
>> + u32 ttb;
>> +};
>> +
>>  struct omap_iommu {
>>   const char  *name;
>>   struct module   *owner;
>> @@ -50,7 +57,8 @@ struct omap_iommu {
>>   struct list_headmmap;
>>   struct mutexmmap_lock; /* protect mmap */
>>
>> - void *ctx; /* iommu context: registres saved area */
>> + struct iommu_regs context;
>> + int ctx_loss_cnt;
>>   u32 da_start;
>>   u32 da_end;
>>  };
>> --- a/arch/arm/plat-omap/include/plat/iommu2.h
>> +++ b/arch/arm/plat-omap/include/plat/iommu2.h
>> @@ -35,8 +35,6 @@
>>  #define MMU_READ_RAM 0x6c
>>  #define MMU_EMU_FAULT_AD 0x70
>>
>> -#define MMU_REG_SIZE 256
>> -
>>  /*
>>   * MMU Register bit definitions
>>   */
>
> These headers should be moved to include/linux/platform_data/iommu-omap.h
> or something like that. Care to take care of that too?
>
> I guess there's no reason to have both iommu.h and iommuh2.h?

Agree, can this be made as part of a separate cleanup series? I was
hoping these could make it for 3.7 so we could have a usable rpmsg for
omap4.

Regards,

Omar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/14] MFD/ASoC/Input: twl4030-audio submodule DT support

[Samuel Ortiz]

Hi Peter,

On Mon, Sep 10, 2012 at 01:46:18PM +0300, Peter Ujfalusi wrote:
> Hello,
> 
> Generated on top of:
> git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/omap
I applied the first 8 patches, but I'd like to get Mark's ACK for the rest of
the serie.
Unless you're expecting Mark to take the whole thing, in which case you can
add my:

Acked-by: Samuel Ortiz 

to the MFD patches.
Please let me know how you'd like to proceed.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] mfd: twl: Move PWM driver to PWM framework

[Samuel Ortiz]

Hi Thierry,

On Mon, Sep 10, 2012 at 02:10:18PM +0200, Thierry Reding wrote:
> Hi,
> 
> This mini series replaces the twl_has_*() macros by the equivalent
> standard IS_ENABLED() macro and moves the PWM driver to the PWM
> framework.
> 
> I'll take the second patch through the PWM tree but would like to have
> some Acked-bys from people that know and have the hardware and can
> verify that I haven't broken anything.
We're already going to have conflicts for twl-core.c as Tony is pushing some
code for it through his tree. So, would you be ok with me carrying the whole
series through the MFD tree ?

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: pull request: bluetooth 2012-09-18

[Gustavo Padovan]

Forgot to sign this..

* Gustavo Padovan  [2012-09-18 21:11:43 -0300]:

> Hi John,
> 
> Here goes probably my last update to 3.6. It includes the two patches you
> were ok last week(from Andrzej Kaczmarek), those are critical ones, and two
> other fixes one for a system crash and the other for a missing lockdep
> annotation.
> 
> Please pull or let me know of any problems!
> 
>   Gustavo
> 
> ---
> The following changes since commit e020a83d0942a5aceac35986500c9834efc8707d:
> 
>   brcmfmac: Fix big endian host configuration data. (2012-09-12 14:15:31 
> -0400)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth master
> 
> for you to fetch changes up to 78c04c0bf52360dc2f7185e99c8e9aa05d73ae5a:
> 
>   Bluetooth: Fix not removing power_off delayed work (2012-09-18 20:13:02 
> -0300)
> 
> 
> Andrei Emeltchenko (1):
>   Bluetooth: Fix freeing uninitialized delayed works
> 
> Andrzej Kaczmarek (2):
>   Bluetooth: mgmt: Fix enabling SSP while powered off
>   Bluetooth: mgmt: Fix enabling LE while powered off
> 
> Vinicius Costa Gomes (1):
>   Bluetooth: Fix not removing power_off delayed work
> 
>  net/bluetooth/hci_core.c   |  2 ++
>  net/bluetooth/l2cap_core.c |  2 +-
>  net/bluetooth/mgmt.c   | 16 
>  3 files changed, 19 insertions(+), 1 deletion(-)
> 

Gustavo


pgpkD2paHA7La.pgp
Description: PGP signature

Re: qemu-kvm loops after kernel udpate

[Andrew Morton]

On Wed, 19 Sep 2012 10:00:34 +1000 Stephen Rothwell  
wrote:

> Hi Andrew,
> 
> On Tue, 18 Sep 2012 12:46:46 -0700 Andrew Morton  
> wrote:
> >
> > hm, thanks.  This will probably take some time to resolve so I think
> > I'll drop
> > 
> > mm-move-all-mmu-notifier-invocations-to-be-done-outside-the-pt-lock.patch
> > mm-move-all-mmu-notifier-invocations-to-be-done-outside-the-pt-lock-fix.patch
> > mm-move-all-mmu-notifier-invocations-to-be-done-outside-the-pt-lock-fix-fix.patch
> > mm-wrap-calls-to-set_pte_at_notify-with-invalidate_range_start-and-invalidate_range_end.patch
> 
> Should I attempt to remove these from the akpm tree in linux-next today?

That would be best - there's no point in having people test (and debug)
dead stuff.

> Or should I just wait for a new mmotm?

You could be brave and test http://ozlabs.org/~akpm/mmots/ for me :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

pull request: bluetooth 2012-09-18

[Gustavo Padovan]

Hi John,

Here goes probably my last update to 3.6. It includes the two patches you
were ok last week(from Andrzej Kaczmarek), those are critical ones, and two
other fixes one for a system crash and the other for a missing lockdep
annotation.

Please pull or let me know of any problems!

Gustavo

---
The following changes since commit e020a83d0942a5aceac35986500c9834efc8707d:

  brcmfmac: Fix big endian host configuration data. (2012-09-12 14:15:31 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth master

for you to fetch changes up to 78c04c0bf52360dc2f7185e99c8e9aa05d73ae5a:

  Bluetooth: Fix not removing power_off delayed work (2012-09-18 20:13:02 -0300)


Andrei Emeltchenko (1):
  Bluetooth: Fix freeing uninitialized delayed works

Andrzej Kaczmarek (2):
  Bluetooth: mgmt: Fix enabling SSP while powered off
  Bluetooth: mgmt: Fix enabling LE while powered off

Vinicius Costa Gomes (1):
  Bluetooth: Fix not removing power_off delayed work

 net/bluetooth/hci_core.c   |  2 ++
 net/bluetooth/l2cap_core.c |  2 +-
 net/bluetooth/mgmt.c   | 16 
 3 files changed, 19 insertions(+), 1 deletion(-)

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

[tip:x86/fpu] x86, fpu: remove cpu_has_xmm check in the fx_finit()

[tip-bot for Suresh Siddha]

Commit-ID:  a8615af4bc3621cb01096541dafa6f68352ec2d9
Gitweb: http://git.kernel.org/tip/a8615af4bc3621cb01096541dafa6f68352ec2d9
Author: Suresh Siddha 
AuthorDate: Mon, 10 Sep 2012 10:40:08 -0700
Committer:  H. Peter Anvin 
CommitDate: Tue, 18 Sep 2012 15:52:24 -0700

x86, fpu: remove cpu_has_xmm check in the fx_finit()

CPUs with FXSAVE but no XMM/MXCSR (Pentium II from Intel,
Crusoe/TM-3xxx/5xxx from Transmeta, and presumably some of the K6
generation from AMD) ever looked at the mxcsr field during
fxrstor/fxsave. So remove the cpu_has_xmm check in the fx_finit()

Reported-by: Al Viro 
Acked-by: H. Peter Anvin 
Signed-off-by: Suresh Siddha 
Link: 
http://lkml.kernel.org/r/1347300665-6209-6-git-send-email-suresh.b.sid...@intel.com
Signed-off-by: H. Peter Anvin 
---
 arch/x86/include/asm/fpu-internal.h |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/fpu-internal.h 
b/arch/x86/include/asm/fpu-internal.h
index 0ca72f0..92f3c6e 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -109,8 +109,7 @@ static inline void fx_finit(struct i387_fxsave_struct *fx)
 {
memset(fx, 0, xstate_size);
fx->cwd = 0x37f;
-   if (cpu_has_xmm)
-   fx->mxcsr = MXCSR_DEFAULT;
+   fx->mxcsr = MXCSR_DEFAULT;
 }
 
 extern void __sanitize_i387_state(struct task_struct *);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/fpu] x86, fpu: make eagerfpu= boot param tri-state

[tip-bot for Suresh Siddha]

Commit-ID:  e00229819f306b1f86134095347e9187dc346bd1
Gitweb: http://git.kernel.org/tip/e00229819f306b1f86134095347e9187dc346bd1
Author: Suresh Siddha 
AuthorDate: Mon, 10 Sep 2012 10:32:32 -0700
Committer:  H. Peter Anvin 
CommitDate: Tue, 18 Sep 2012 15:52:24 -0700

x86, fpu: make eagerfpu= boot param tri-state

Add the "eagerfpu=auto" (that selects the default scheme in
enabling eagerfpu) which can override compiled-in boot parameters
like "eagerfpu=on/off" (that force enable/disable eagerfpu).

Signed-off-by: Suresh Siddha 
Link: 
http://lkml.kernel.org/r/1347300665-6209-5-git-send-email-suresh.b.sid...@intel.com
Signed-off-by: H. Peter Anvin 
---
 Documentation/kernel-parameters.txt |4 +++-
 arch/x86/kernel/xsave.c |   17 -
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index e8f7faa..46a6a82 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1834,8 +1834,10 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
enabling legacy floating-point and sse state.
 
eagerfpu=   [X86]
-   on  enable eager fpu restore (default for xsaveopt)
+   on  enable eager fpu restore
off disable eager fpu restore
+   autoselects the default scheme, which automatically
+   enables eagerfpu restore for xsaveopt.
 
nohlt   [BUGS=ARM,SH] Tells the kernel that the sleep(SH) or
wfi(ARM) instruction doesn't work correctly and not to
diff --git a/arch/x86/kernel/xsave.c b/arch/x86/kernel/xsave.c
index e99f754..4e89b3d 100644
--- a/arch/x86/kernel/xsave.c
+++ b/arch/x86/kernel/xsave.c
@@ -508,13 +508,15 @@ static void __init setup_init_fpu_buf(void)
xsave_state(init_xstate_buf, -1);
 }
 
-static int disable_eagerfpu;
+static enum { AUTO, ENABLE, DISABLE } eagerfpu = AUTO;
 static int __init eager_fpu_setup(char *s)
 {
if (!strcmp(s, "on"))
-   setup_force_cpu_cap(X86_FEATURE_EAGER_FPU);
+   eagerfpu = ENABLE;
else if (!strcmp(s, "off"))
-   disable_eagerfpu = 1;
+   eagerfpu = DISABLE;
+   else if (!strcmp(s, "auto"))
+   eagerfpu = AUTO;
return 1;
 }
 __setup("eagerfpu=", eager_fpu_setup);
@@ -557,8 +559,9 @@ static void __init xstate_enable_boot_cpu(void)
prepare_fx_sw_frame();
setup_init_fpu_buf();
 
-   if (cpu_has_xsaveopt && !disable_eagerfpu)
-   setup_force_cpu_cap(X86_FEATURE_EAGER_FPU);
+   /* Auto enable eagerfpu for xsaveopt */
+   if (cpu_has_xsaveopt && eagerfpu != DISABLE)
+   eagerfpu = ENABLE;
 
pr_info("enabled xstate_bv 0x%llx, cntxt size 0x%x\n",
pcntxt_mask, xstate_size);
@@ -598,6 +601,10 @@ void __cpuinit eager_fpu_init(void)
 
clear_used_math();
current_thread_info()->status = 0;
+
+   if (eagerfpu == ENABLE)
+   setup_force_cpu_cap(X86_FEATURE_EAGER_FPU);
+
if (!cpu_has_eager_fpu) {
stts();
return;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: PM: Summary of changes for v3.7

[Yasuaki Ishimatsu]

Hi Rafael,

I'd like to include following thread's patch into v3.7.

https://patchwork.kernel.org/patch/1282121/

The patch has been discussed and I have updated all comments.

Thanks,
Yasuaki Ishimatsu

2012/09/19 5:19, Rafael J. Wysocki wrote:

Hi all,

All of the changes I'd like to include into the first PM pull request during
the v3.7 merge window, except maybe for a couple of patches I know of, but
haven't decided what to do with them yet, is on the 'linux-next' branch of the
linux-pm.git tree now.

The summary of those changes is appended.  If anyone finds any of them
objectionable, please let me know ASAP.  Also please let me know if there are
any power management patches I've seen already that you'd like me to take for
v3.7 (if I haven't seen them yet, they clearly are not v3.7 material, unless
they are urgent fixes).

Thanks,
Rafael

---

  Documentation/ABI/testing/sysfs-devices-system-cpu |  11 +
  Documentation/cpu-freq/boost.txt   |  93 +
  Documentation/cpuidle/sysfs.txt|  10 +-
  .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt   |  55 +++
  Documentation/devicetree/bindings/power/opp.txt|  25 ++
  arch/arm/kernel/smp.c  |  54 +++
  arch/arm/mach-shmobile/Makefile|   2 +-
  arch/arm/mach-shmobile/board-ap4evb.c  |  21 +-
  arch/arm/mach-shmobile/board-armadillo800eva.c |   6 +-
  arch/arm/mach-shmobile/board-mackerel.c|  34 +-
  arch/arm/mach-shmobile/common.c|  24 --
  arch/arm/mach-shmobile/cpuidle.c   |  39 +-
  arch/arm/mach-shmobile/include/mach/common.h   |  14 +-
  arch/arm/mach-shmobile/include/mach/pm-rmobile.h   |  35 +-
  arch/arm/mach-shmobile/include/mach/r8a7740.h  |   6 +-
  arch/arm/mach-shmobile/include/mach/r8a7779.h  |  12 +-
  arch/arm/mach-shmobile/include/mach/sh7372.h   |  20 +-
  arch/arm/mach-shmobile/pm-r8a7740.c|  42 ++-
  arch/arm/mach-shmobile/pm-r8a7779.c|  71 ++--
  arch/arm/mach-shmobile/pm-rmobile.c|  33 +-
  arch/arm/mach-shmobile/pm-sh7372.c | 283 --
  arch/arm/mach-shmobile/setup-r8a7740.c |  27 +-
  arch/arm/mach-shmobile/setup-r8a7779.c |   5 +-
  arch/arm/mach-shmobile/setup-sh7372.c  |  69 ++--
  arch/x86/include/asm/msr-index.h   |   3 +
  drivers/acpi/processor_driver.c|   8 +-
  drivers/acpi/processor_idle.c  |  40 +-
  drivers/acpi/processor_perflib.c   |  30 ++
  drivers/base/platform.c|   2 +
  drivers/base/power/domain.c| 244 ++---
  drivers/base/power/main.c  |  35 +-
  drivers/base/power/opp.c   |  47 +++
  drivers/base/power/power.h |  36 +-
  drivers/base/power/wakeup.c|  46 ++-
  drivers/clocksource/sh_cmt.c   |  71 +++-
  drivers/clocksource/sh_mtu2.c  |  41 ++-
  drivers/clocksource/sh_tmu.c   | 112 +-
  drivers/cpufreq/Kconfig|  11 +
  drivers/cpufreq/Kconfig.x86|  18 +-
  drivers/cpufreq/Makefile   |   4 +-
  drivers/cpufreq/acpi-cpufreq.c | 272 +-
  drivers/cpufreq/cpufreq-cpu0.c | 269 ++
  drivers/cpufreq/cpufreq_conservative.c |   2 +
  drivers/cpufreq/cpufreq_ondemand.c |   1 +
  drivers/cpufreq/longhaul.h |  26 +-
  drivers/cpufreq/omap-cpufreq.c |  35 --
  drivers/cpufreq/powernow-k8.c  | 406 ++---
  drivers/cpufreq/powernow-k8.h  |  32 --
  drivers/cpuidle/governors/ladder.c |   6 +-
  drivers/xen/xen-acpi-processor.c   |   1 -
  include/acpi/processor.h   |   9 +-
  include/linux/clockchips.h |   8 +
  include/linux/device.h |   7 +
  include/linux/opp.h|   8 +
  include/linux/pm.h |   2 +
  include/linux/pm_domain.h  |  92 -
  kernel/power/Kconfig   |   4 +
  kernel/power/poweroff.c|   2 +-
  kernel/power/process.c |   2 +-
  kernel/power/qos.c |   1 +
  kernel/time/clockevents.c  |  24 ++
  kernel/time/timekeeping.c  |   2 +
  62 files changed, 2028 insertions(+), 922 deletions(-)

---

Amit Daniel Kachhap (1):
   PM / cpufreq: Initialise the cpu field during conservative governor start

Andi Kleen (1):
   sections: fix 

[tip:x86/fpu] x86, fpu: decouple non-lazy/ eager fpu restore from xsave

[tip-bot for Suresh Siddha]

Commit-ID:  5d2bd7009f306c82afddd1ca4d9763ad8473c216
Gitweb: http://git.kernel.org/tip/5d2bd7009f306c82afddd1ca4d9763ad8473c216
Author: Suresh Siddha 
AuthorDate: Thu, 6 Sep 2012 14:58:52 -0700
Committer:  H. Peter Anvin 
CommitDate: Tue, 18 Sep 2012 15:52:22 -0700

x86, fpu: decouple non-lazy/eager fpu restore from xsave

Decouple non-lazy/eager fpu restore policy from the existence of the xsave
feature. Introduce a synthetic CPUID flag to represent the eagerfpu
policy. "eagerfpu=on" boot paramter will enable the policy.

Requested-by: H. Peter Anvin 
Requested-by: Linus Torvalds 
Signed-off-by: Suresh Siddha 
Link: 
http://lkml.kernel.org/r/1347300665-6209-2-git-send-email-suresh.b.sid...@intel.com
Signed-off-by: H. Peter Anvin 
---
 Documentation/kernel-parameters.txt |4 ++
 arch/x86/include/asm/cpufeature.h   |2 +
 arch/x86/include/asm/fpu-internal.h |   54 --
 arch/x86/kernel/cpu/common.c|2 -
 arch/x86/kernel/i387.c  |   25 +++---
 arch/x86/kernel/process.c   |2 +-
 arch/x86/kernel/traps.c |2 +-
 arch/x86/kernel/xsave.c |   87 +++
 8 files changed, 112 insertions(+), 66 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index ad7e2e5..741d064 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1833,6 +1833,10 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
and restore using xsave. The kernel will fallback to
enabling legacy floating-point and sse state.
 
+   eagerfpu=   [X86]
+   on  enable eager fpu restore
+   off disable eager fpu restore
+
nohlt   [BUGS=ARM,SH] Tells the kernel that the sleep(SH) or
wfi(ARM) instruction doesn't work correctly and not to
use it. This is also useful when using JTAG debugger.
diff --git a/arch/x86/include/asm/cpufeature.h 
b/arch/x86/include/asm/cpufeature.h
index 6b7ee5f..5dd2b47 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -97,6 +97,7 @@
 #define X86_FEATURE_EXTD_APICID(3*32+26) /* has extended APICID (8 
bits) */
 #define X86_FEATURE_AMD_DCM (3*32+27) /* multi-node processor */
 #define X86_FEATURE_APERFMPERF (3*32+28) /* APERFMPERF */
+#define X86_FEATURE_EAGER_FPU  (3*32+29) /* "eagerfpu" Non lazy FPU restore */
 
 /* Intel-defined CPU features, CPUID level 0x0001 (ecx), word 4 */
 #define X86_FEATURE_XMM3   (4*32+ 0) /* "pni" SSE-3 */
@@ -305,6 +306,7 @@ extern const char * const x86_power_flags[32];
 #define cpu_has_perfctr_core   boot_cpu_has(X86_FEATURE_PERFCTR_CORE)
 #define cpu_has_cx8boot_cpu_has(X86_FEATURE_CX8)
 #define cpu_has_cx16   boot_cpu_has(X86_FEATURE_CX16)
+#define cpu_has_eager_fpu  boot_cpu_has(X86_FEATURE_EAGER_FPU)
 
 #if defined(CONFIG_X86_INVLPG) || defined(CONFIG_X86_64)
 # define cpu_has_invlpg1
diff --git a/arch/x86/include/asm/fpu-internal.h 
b/arch/x86/include/asm/fpu-internal.h
index 8ca0f9f..0ca72f0 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -38,6 +38,7 @@ int ia32_setup_frame(int sig, struct k_sigaction *ka,
 
 extern unsigned int mxcsr_feature_mask;
 extern void fpu_init(void);
+extern void eager_fpu_init(void);
 
 DECLARE_PER_CPU(struct task_struct *, fpu_owner_task);
 
@@ -84,6 +85,11 @@ static inline int is_x32_frame(void)
 
 #define X87_FSW_ES (1 << 7)/* Exception Summary */
 
+static __always_inline __pure bool use_eager_fpu(void)
+{
+   return static_cpu_has(X86_FEATURE_EAGER_FPU);
+}
+
 static __always_inline __pure bool use_xsaveopt(void)
 {
return static_cpu_has(X86_FEATURE_XSAVEOPT);
@@ -99,6 +105,14 @@ static __always_inline __pure bool use_fxsr(void)
 return static_cpu_has(X86_FEATURE_FXSR);
 }
 
+static inline void fx_finit(struct i387_fxsave_struct *fx)
+{
+   memset(fx, 0, xstate_size);
+   fx->cwd = 0x37f;
+   if (cpu_has_xmm)
+   fx->mxcsr = MXCSR_DEFAULT;
+}
+
 extern void __sanitize_i387_state(struct task_struct *);
 
 static inline void sanitize_i387_state(struct task_struct *tsk)
@@ -291,13 +305,13 @@ static inline void __thread_set_has_fpu(struct 
task_struct *tsk)
 static inline void __thread_fpu_end(struct task_struct *tsk)
 {
__thread_clear_has_fpu(tsk);
-   if (!use_xsave())
+   if (!use_eager_fpu())
stts();
 }
 
 static inline void __thread_fpu_begin(struct task_struct *tsk)
 {
-   if (!use_xsave())
+   if (!use_eager_fpu())
clts();
__thread_set_has_fpu(tsk);
 }
@@ -327,10 +341,14 @@ static inline void drop_fpu(struct task_struct *tsk)
 
 static inline void drop_init_fpu(struct task_struct *tsk)
 {
-   if (!use_xsave()

[tip:x86/fpu] x86, fpu: use non-lazy fpu restore for processors supporting xsave

[tip-bot for Suresh Siddha]

Commit-ID:  304bceda6a18ae0b0240b8aac9a6bdf8ce2d2469
Gitweb: http://git.kernel.org/tip/304bceda6a18ae0b0240b8aac9a6bdf8ce2d2469
Author: Suresh Siddha 
AuthorDate: Fri, 24 Aug 2012 14:13:02 -0700
Committer:  H. Peter Anvin 
CommitDate: Tue, 18 Sep 2012 15:52:11 -0700

x86, fpu: use non-lazy fpu restore for processors supporting xsave

Fundamental model of the current Linux kernel is to lazily init and
restore FPU instead of restoring the task state during context switch.
This changes that fundamental lazy model to the non-lazy model for
the processors supporting xsave feature.

Reasons driving this model change are:

i. Newer processors support optimized state save/restore using xsaveopt and
xrstor by tracking the INIT state and MODIFIED state during context-switch.
This is faster than modifying the cr0.TS bit which has serializing semantics.

ii. Newer glibc versions use SSE for some of the optimized copy/clear routines.
With certain workloads (like boot, kernel-compilation etc), application
completes its work with in the first 5 task switches, thus taking upto 5 #DNA
traps with the kernel not getting a chance to apply the above mentioned
pre-load heuristic.

iii. Some xstate features (like AMD's LWP feature) don't honor the cr0.TS bit
and thus will not work correctly in the presence of lazy restore. Non-lazy
state restore is needed for enabling such features.

Some data on a two socket SNB system:
 * Saved 20K DNA exceptions during boot on a two socket SNB system.
 * Saved 50K DNA exceptions during kernel-compilation workload.
 * Improved throughput of the AVX based checksumming function inside the
   kernel by ~15% as xsave/xrstor is faster than the serializing clts/stts
   pair.

Also now kernel_fpu_begin/end() relies on the patched
alternative instructions. So move check_fpu() which uses the
kernel_fpu_begin/end() after alternative_instructions().

Signed-off-by: Suresh Siddha 
Link: 
http://lkml.kernel.org/r/1345842782-24175-7-git-send-email-suresh.b.sid...@intel.com
Merge 32-bit boot fix from,
Link: 
http://lkml.kernel.org/r/1347300665-6209-4-git-send-email-suresh.b.sid...@intel.com
Cc: Jim Kukunas 
Cc: NeilBrown 
Cc: Avi Kivity 
Signed-off-by: H. Peter Anvin 
---
 arch/x86/include/asm/fpu-internal.h |   96 +++
 arch/x86/include/asm/i387.h |1 +
 arch/x86/include/asm/xsave.h|1 +
 arch/x86/kernel/cpu/bugs.c  |7 ++-
 arch/x86/kernel/i387.c  |   20 ++-
 arch/x86/kernel/process.c   |   12 +++--
 arch/x86/kernel/process_32.c|4 --
 arch/x86/kernel/process_64.c|4 --
 arch/x86/kernel/traps.c |5 ++-
 arch/x86/kernel/xsave.c |   57 +
 10 files changed, 146 insertions(+), 61 deletions(-)

diff --git a/arch/x86/include/asm/fpu-internal.h 
b/arch/x86/include/asm/fpu-internal.h
index 52202a6..8ca0f9f 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -291,15 +291,48 @@ static inline void __thread_set_has_fpu(struct 
task_struct *tsk)
 static inline void __thread_fpu_end(struct task_struct *tsk)
 {
__thread_clear_has_fpu(tsk);
-   stts();
+   if (!use_xsave())
+   stts();
 }
 
 static inline void __thread_fpu_begin(struct task_struct *tsk)
 {
-   clts();
+   if (!use_xsave())
+   clts();
__thread_set_has_fpu(tsk);
 }
 
+static inline void __drop_fpu(struct task_struct *tsk)
+{
+   if (__thread_has_fpu(tsk)) {
+   /* Ignore delayed exceptions from user space */
+   asm volatile("1: fwait\n"
+"2:\n"
+_ASM_EXTABLE(1b, 2b));
+   __thread_fpu_end(tsk);
+   }
+}
+
+static inline void drop_fpu(struct task_struct *tsk)
+{
+   /*
+* Forget coprocessor state..
+*/
+   preempt_disable();
+   tsk->fpu_counter = 0;
+   __drop_fpu(tsk);
+   clear_used_math();
+   preempt_enable();
+}
+
+static inline void drop_init_fpu(struct task_struct *tsk)
+{
+   if (!use_xsave())
+   drop_fpu(tsk);
+   else
+   xrstor_state(init_xstate_buf, -1);
+}
+
 /*
  * FPU state switching for scheduling.
  *
@@ -333,7 +366,12 @@ static inline fpu_switch_t switch_fpu_prepare(struct 
task_struct *old, struct ta
 {
fpu_switch_t fpu;
 
-   fpu.preload = tsk_used_math(new) && new->fpu_counter > 5;
+   /*
+* If the task has used the math, pre-load the FPU on xsave processors
+* or if the past 5 consecutive context-switches used math.
+*/
+   fpu.preload = tsk_used_math(new) && (use_xsave() ||
+new->fpu_counter > 5);
if (__thread_has_fpu(old)) {
if (!__save_init_fpu(old))
cpu = ~0;
@@ -345,14 +383,14 @@ static inline fpu_switch_t switch_fpu_prepare(struct 
task_struct *old, struct ta
   

[tip:x86/fpu] lguest, x86: handle guest TS bit for lazy/ non-lazy fpu host models

[tip-bot for Suresh Siddha]

Commit-ID:  9c6ff8bbb69a4e7b47ac40bfa44509296e89c5c0
Gitweb: http://git.kernel.org/tip/9c6ff8bbb69a4e7b47ac40bfa44509296e89c5c0
Author: Suresh Siddha 
AuthorDate: Fri, 24 Aug 2012 14:13:01 -0700
Committer:  H. Peter Anvin 
CommitDate: Tue, 18 Sep 2012 15:52:09 -0700

lguest, x86: handle guest TS bit for lazy/non-lazy fpu host models

Instead of using unlazy_fpu() check if user_has_fpu() and set/clear
the host TS bits so that the lguest works fine with both the
lazy/non-lazy FPU host models with minimal changes.

Signed-off-by: Suresh Siddha 
Link: 
http://lkml.kernel.org/r/1345842782-24175-6-git-send-email-suresh.b.sid...@intel.com
Cc: Rusty Russell 
Signed-off-by: H. Peter Anvin 
---
 drivers/lguest/x86/core.c |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/lguest/x86/core.c b/drivers/lguest/x86/core.c
index 39809035..4af12e1 100644
--- a/drivers/lguest/x86/core.c
+++ b/drivers/lguest/x86/core.c
@@ -203,8 +203,8 @@ void lguest_arch_run_guest(struct lg_cpu *cpu)
 * we set it now, so we can trap and pass that trap to the Guest if it
 * uses the FPU.
 */
-   if (cpu->ts)
-   unlazy_fpu(current);
+   if (cpu->ts && user_has_fpu())
+   stts();
 
/*
 * SYSENTER is an optimized way of doing system calls.  We can't allow
@@ -234,6 +234,10 @@ void lguest_arch_run_guest(struct lg_cpu *cpu)
 if (boot_cpu_has(X86_FEATURE_SEP))
wrmsr(MSR_IA32_SYSENTER_CS, __KERNEL_CS, 0);
 
+   /* Clear the host TS bit if it was set above. */
+   if (cpu->ts && user_has_fpu())
+   clts();
+
/*
 * If the Guest page faulted, then the cr2 register will tell us the
 * bad virtual address.  We have to grab this now, because once we
@@ -249,7 +253,7 @@ void lguest_arch_run_guest(struct lg_cpu *cpu)
 * a different CPU. So all the critical stuff should be done
 * before this.
 */
-   else if (cpu->regs->trapnum == 7)
+   else if (cpu->regs->trapnum == 7 && !user_has_fpu())
math_state_restore();
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/fpu] x86, fpu: always use kernel_fpu_begin/end() for in-kernel FPU usage

[tip-bot for Suresh Siddha]

Commit-ID:  841e3604d35aa70d399146abdc526d8c89a2c2f5
Gitweb: http://git.kernel.org/tip/841e3604d35aa70d399146abdc526d8c89a2c2f5
Author: Suresh Siddha 
AuthorDate: Fri, 24 Aug 2012 14:13:00 -0700
Committer:  H. Peter Anvin 
CommitDate: Tue, 18 Sep 2012 15:52:08 -0700

x86, fpu: always use kernel_fpu_begin/end() for in-kernel FPU usage

use kernel_fpu_begin/end() instead of unconditionally accessing cr0 and
saving/restoring just the few used xmm/ymm registers.

This has some advantages like:
* If the task's FPU state is already active, then kernel_fpu_begin()
  will just save the user-state and avoiding the read/write of cr0.
  In general, cr0 accesses are much slower.

* Manual save/restore of xmm/ymm registers will affect the 'modified' and
  the 'init' optimizations brought in the by xsaveopt/xrstor
  infrastructure.

* Foward compatibility with future vector register extensions will be a
  problem if the xmm/ymm registers are manually saved and restored
  (corrupting the extended state of those vector registers).

With this patch, there was no significant difference in the xor throughput
using AVX, measured during boot.

Signed-off-by: Suresh Siddha 
Link: 
http://lkml.kernel.org/r/1345842782-24175-5-git-send-email-suresh.b.sid...@intel.com
Cc: Jim Kukunas 
Cc: NeilBrown 
Signed-off-by: H. Peter Anvin 
---
 arch/x86/include/asm/xor_32.h  |   56 +---
 arch/x86/include/asm/xor_64.h  |   61 ++--
 arch/x86/include/asm/xor_avx.h |   54 ---
 3 files changed, 29 insertions(+), 142 deletions(-)

diff --git a/arch/x86/include/asm/xor_32.h b/arch/x86/include/asm/xor_32.h
index 4545708..aabd585 100644
--- a/arch/x86/include/asm/xor_32.h
+++ b/arch/x86/include/asm/xor_32.h
@@ -534,38 +534,6 @@ static struct xor_block_template xor_block_p5_mmx = {
  * Copyright (C) 1999 Zach Brown (with obvious credit due Ingo)
  */
 
-#define XMMS_SAVE  \
-do {   \
-   preempt_disable();  \
-   cr0 = read_cr0();   \
-   clts(); \
-   asm volatile(   \
-   "movups %%xmm0,(%0) ;\n\t"  \
-   "movups %%xmm1,0x10(%0) ;\n\t"  \
-   "movups %%xmm2,0x20(%0) ;\n\t"  \
-   "movups %%xmm3,0x30(%0) ;\n\t"  \
-   :   \
-   : "r" (xmm_save)\
-   : "memory");\
-} while (0)
-
-#define XMMS_RESTORE   \
-do {   \
-   asm volatile(   \
-   "sfence ;\n\t"  \
-   "movups (%0),%%xmm0 ;\n\t"  \
-   "movups 0x10(%0),%%xmm1 ;\n\t"  \
-   "movups 0x20(%0),%%xmm2 ;\n\t"  \
-   "movups 0x30(%0),%%xmm3 ;\n\t"  \
-   :   \
-   : "r" (xmm_save)\
-   : "memory");\
-   write_cr0(cr0); \
-   preempt_enable();   \
-} while (0)
-
-#define ALIGN16 __attribute__((aligned(16)))
-
 #define OFFS(x)"16*("#x")"
 #define PF_OFFS(x) "256+16*("#x")"
 #definePF0(x)  "   prefetchnta "PF_OFFS(x)"(%1)
;\n"
@@ -587,10 +555,8 @@ static void
 xor_sse_2(unsigned long bytes, unsigned long *p1, unsigned long *p2)
 {
unsigned long lines = bytes >> 8;
-   char xmm_save[16*4] ALIGN16;
-   int cr0;
 
-   XMMS_SAVE;
+   kernel_fpu_begin();
 
asm volatile(
 #undef BLOCK
@@ -633,7 +599,7 @@ xor_sse_2(unsigned long bytes, unsigned long *p1, unsigned 
long *p2)
:
: "memory");
 
-   XMMS_RESTORE;
+   kernel_fpu_end();
 }
 
 static void
@@ -641,10 +607,8 @@ xor_sse_3(unsigned long bytes, unsigned long *p1, unsigned 
long *p2,
  unsigned long *p3)
 {
unsigned long lines = bytes >> 8;
-   char xmm_save[16*4] ALIGN16;
-   int cr0;
 
-   XMMS_SAVE;
+   kernel_fpu_begin();
 
asm volatile(
 #undef BLOCK
@@ -694,7 +658,7 @@ xor_sse_3(unsigned long bytes, unsigned long *p1, unsigned 
long *p2,
:
: "memory" );
 
-   XMMS_RESTORE;
+   kernel_fpu_end();
 }
 
 static void
@@ -702,10 +666,8 @@ xor_sse_4(unsigned long bytes, unsigned long *p1, unsigned 
long *p2,
  unsigned long *p3, unsigned long *p4)
 {
unsigned long lines = bytes >> 8;
-   char xmm_save[16*4] ALIGN16;
-   int cr0;
 
-   XMMS_SAVE;
+   kernel_fpu_begin();
 
asm volatile(
 #undef BLOCK
@@ -762,7 +724,7 @@ xor_sse_4(unsigned long bytes, unsigned long *p1, unsigned 
long *p2,
:
: "memory" );
 
-   XMMS_RESTORE;
+   kernel_fpu_end();
 }
 
 static void
@@ -770,10 +732

[tip:x86/fpu] x86, kvm: use kernel_fpu_begin/end() in kvm_load/ put_guest_fpu()

[tip-bot for Suresh Siddha]

Commit-ID:  9c1c3fac53378c9782c18f80107965578d7b7167
Gitweb: http://git.kernel.org/tip/9c1c3fac53378c9782c18f80107965578d7b7167
Author: Suresh Siddha 
AuthorDate: Fri, 24 Aug 2012 14:12:59 -0700
Committer:  H. Peter Anvin 
CommitDate: Tue, 18 Sep 2012 15:52:07 -0700

x86, kvm: use kernel_fpu_begin/end() in kvm_load/put_guest_fpu()

kvm's guest fpu save/restore should be wrapped around
kernel_fpu_begin/end(). This will avoid for example taking a DNA
in kvm_load_guest_fpu() when it tries to load the fpu immediately
after doing unlazy_fpu() on the host side.

More importantly this will prevent the host process fpu from being
corrupted.

Signed-off-by: Suresh Siddha 
Link: 
http://lkml.kernel.org/r/1345842782-24175-4-git-send-email-suresh.b.sid...@intel.com
Cc: Avi Kivity 
Signed-off-by: H. Peter Anvin 
---
 arch/x86/kvm/x86.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 148ed66..cf637f5 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5972,7 +5972,7 @@ void kvm_load_guest_fpu(struct kvm_vcpu *vcpu)
 */
kvm_put_guest_xcr0(vcpu);
vcpu->guest_fpu_loaded = 1;
-   unlazy_fpu(current);
+   kernel_fpu_begin();
fpu_restore_checking(&vcpu->arch.guest_fpu);
trace_kvm_fpu(1);
 }
@@ -5986,6 +5986,7 @@ void kvm_put_guest_fpu(struct kvm_vcpu *vcpu)
 
vcpu->guest_fpu_loaded = 0;
fpu_save_init(&vcpu->arch.guest_fpu);
+   kernel_fpu_end();
++vcpu->stat.fpu_reload;
kvm_make_request(KVM_REQ_DEACTIVATE_FPU, vcpu);
trace_kvm_fpu(0);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/fpu] x86, fpu: remove unnecessary user_fpu_end() in save_xstate_sig()

[tip-bot for Suresh Siddha]

Commit-ID:  377ffbcc536a5adc077395163ab149c02610
Gitweb: http://git.kernel.org/tip/377ffbcc536a5adc077395163ab149c02610
Author: Suresh Siddha 
AuthorDate: Fri, 24 Aug 2012 14:12:58 -0700
Committer:  H. Peter Anvin 
CommitDate: Tue, 18 Sep 2012 15:52:06 -0700

x86, fpu: remove unnecessary user_fpu_end() in save_xstate_sig()

Few lines below we do drop_fpu() which is more safer. Remove the
unnecessary user_fpu_end() in save_xstate_sig(), which allows
the drop_fpu() to ignore any pending exceptions from the user-space
and drop the current fpu.

Signed-off-by: Suresh Siddha 
Link: 
http://lkml.kernel.org/r/1345842782-24175-3-git-send-email-suresh.b.sid...@intel.com
Signed-off-by: H. Peter Anvin 
---
 arch/x86/include/asm/fpu-internal.h |   17 +++--
 arch/x86/kernel/xsave.c |1 -
 2 files changed, 3 insertions(+), 15 deletions(-)

diff --git a/arch/x86/include/asm/fpu-internal.h 
b/arch/x86/include/asm/fpu-internal.h
index 78169d1..52202a6 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -412,22 +412,11 @@ static inline void __drop_fpu(struct task_struct *tsk)
 }
 
 /*
- * The actual user_fpu_begin/end() functions
- * need to be preemption-safe.
+ * Need to be preemption-safe.
  *
- * NOTE! user_fpu_end() must be used only after you
- * have saved the FP state, and user_fpu_begin() must
- * be used only immediately before restoring it.
- * These functions do not do any save/restore on
- * their own.
+ * NOTE! user_fpu_begin() must be used only immediately before restoring
+ * it. This function does not do any save/restore on their own.
  */
-static inline void user_fpu_end(void)
-{
-   preempt_disable();
-   __thread_fpu_end(current);
-   preempt_enable();
-}
-
 static inline void user_fpu_begin(void)
 {
preempt_disable();
diff --git a/arch/x86/kernel/xsave.c b/arch/x86/kernel/xsave.c
index 07ddc87..4ac5f2e 100644
--- a/arch/x86/kernel/xsave.c
+++ b/arch/x86/kernel/xsave.c
@@ -255,7 +255,6 @@ int save_xstate_sig(void __user *buf, void __user *buf_fx, 
int size)
/* Update the thread's fxstate to save the fsave header. */
if (ia32_fxstate)
fpu_fxsave(&tsk->thread.fpu);
-   user_fpu_end();
} else {
sanitize_i387_state(tsk);
if (__copy_to_user(buf_fx, xsave, xstate_size))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/fpu] x86, fpu: drop_fpu() before restoring new state from sigframe

[tip-bot for Suresh Siddha]

Commit-ID:  e962591749dfd4df9fea2c530ed7a3cfed50e5aa
Gitweb: http://git.kernel.org/tip/e962591749dfd4df9fea2c530ed7a3cfed50e5aa
Author: Suresh Siddha 
AuthorDate: Fri, 24 Aug 2012 14:12:57 -0700
Committer:  H. Peter Anvin 
CommitDate: Tue, 18 Sep 2012 15:52:05 -0700

x86, fpu: drop_fpu() before restoring new state from sigframe

No need to save the state with unlazy_fpu(), that is about to get overwritten
by the state from the signal frame. Instead use drop_fpu() and continue
to restore the new state.

Also fold the stop_fpu_preload() into drop_fpu().

Signed-off-by: Suresh Siddha 
Link: 
http://lkml.kernel.org/r/1345842782-24175-2-git-send-email-suresh.b.sid...@intel.com
Signed-off-by: H. Peter Anvin 
---
 arch/x86/include/asm/fpu-internal.h |7 +--
 arch/x86/kernel/xsave.c |8 +++-
 2 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/fpu-internal.h 
b/arch/x86/include/asm/fpu-internal.h
index 4fbb419..78169d1 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -448,17 +448,12 @@ static inline void save_init_fpu(struct task_struct *tsk)
preempt_enable();
 }
 
-static inline void stop_fpu_preload(struct task_struct *tsk)
-{
-   tsk->fpu_counter = 0;
-}
-
 static inline void drop_fpu(struct task_struct *tsk)
 {
/*
 * Forget coprocessor state..
 */
-   stop_fpu_preload(tsk);
+   tsk->fpu_counter = 0;
preempt_disable();
__drop_fpu(tsk);
preempt_enable();
diff --git a/arch/x86/kernel/xsave.c b/arch/x86/kernel/xsave.c
index 0923d27..07ddc87 100644
--- a/arch/x86/kernel/xsave.c
+++ b/arch/x86/kernel/xsave.c
@@ -382,16 +382,14 @@ int __restore_xstate_sig(void __user *buf, void __user 
*buf_fx, int size)
struct xsave_struct *xsave = &tsk->thread.fpu.state->xsave;
struct user_i387_ia32_struct env;
 
-   stop_fpu_preload(tsk);
-   unlazy_fpu(tsk);
+   drop_fpu(tsk);
 
if (__copy_from_user(xsave, buf_fx, state_size) ||
-   __copy_from_user(&env, buf, sizeof(env))) {
-   drop_fpu(tsk);
+   __copy_from_user(&env, buf, sizeof(env)))
return -1;
-   }
 
sanitize_restored_xstate(tsk, &env, xstate_bv, fx_only);
+   set_used_math();
} else {
/*
 * For 64-bit frames and 32-bit fsave frames, restore the user
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/fpu] x86, fpu: Unify signal handling code paths for x86 and x86_64 kernels

[tip-bot for Suresh Siddha]

Commit-ID:  72a671ced66db6d1c2bfff1c930a101ac8d08204
Gitweb: http://git.kernel.org/tip/72a671ced66db6d1c2bfff1c930a101ac8d08204
Author: Suresh Siddha 
AuthorDate: Tue, 24 Jul 2012 16:05:29 -0700
Committer:  H. Peter Anvin 
CommitDate: Tue, 18 Sep 2012 15:51:48 -0700

x86, fpu: Unify signal handling code paths for x86 and x86_64 kernels

Currently for x86 and x86_32 binaries, fpstate in the user sigframe is copied
to/from the fpstate in the task struct.

And in the case of signal delivery for x86_64 binaries, if the fpstate is live
in the CPU registers, then the live state is copied directly to the user
sigframe. Otherwise  fpstate in the task struct is copied to the user sigframe.
During restore, fpstate in the user sigframe is restored directly to the live
CPU registers.

Historically, different code paths led to different bugs. For example,
x86_64 code path was not preemption safe till recently. Also there is lot
of code duplication for support of new features like xsave etc.

Unify signal handling code paths for x86 and x86_64 kernels.

New strategy is as follows:

Signal delivery: Both for 32/64-bit frames, align the core math frame area to
64bytes as needed by xsave (this where the main fpu/extended state gets copied
to and excludes the legacy compatibility fsave header for the 32-bit [f]xsave
frames). If the state is live, copy the register state directly to the user
frame. If not live, copy the state in the thread struct to the user frame. And
for 32-bit [f]xsave frames, construct the fsave header separately before
the actual [f]xsave area.

Signal return: As the 32-bit frames with [f]xstate has an additional
'fsave' header, copy everything back from the user sigframe to the
fpstate in the task structure and reconstruct the fxstate from the 'fsave'
header (Also user passed pointers may not be correctly aligned for
any attempt to directly restore any partial state). At the next fpstate usage,
everything will be restored to the live CPU registers.
For all the 64-bit frames and the 32-bit fsave frame, restore the state from
the user sigframe directly to the live CPU registers. 64-bit signals always
restored the math frame directly, so we can expect the math frame pointer
to be correctly aligned. For 32-bit fsave frames, there are no alignment
requirements, so we can restore the state directly.

"lat_sig catch" microbenchmark numbers (for x86, x86_64, x86_32 binaries) are
with in the noise range with this change.

Signed-off-by: Suresh Siddha 
Link: 
http://lkml.kernel.org/r/1343171129-2747-4-git-send-email-suresh.b.sid...@intel.com
[ Merged in compilation fix ]
Link: 
http://lkml.kernel.org/r/1344544736.8326.17.ca...@sbsiddha-desk.sc.intel.com
Signed-off-by: H. Peter Anvin 
---
 arch/x86/ia32/ia32_signal.c |9 +-
 arch/x86/include/asm/fpu-internal.h |  111 ++
 arch/x86/include/asm/xsave.h|6 +-
 arch/x86/kernel/i387.c  |  246 +
 arch/x86/kernel/process.c   |   10 -
 arch/x86/kernel/ptrace.c|3 -
 arch/x86/kernel/signal.c|   15 +-
 arch/x86/kernel/xsave.c |  432 +--
 8 files changed, 348 insertions(+), 484 deletions(-)

diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c
index 452d4dd..8c77c64 100644
--- a/arch/x86/ia32/ia32_signal.c
+++ b/arch/x86/ia32/ia32_signal.c
@@ -251,7 +251,7 @@ static int ia32_restore_sigcontext(struct pt_regs *regs,
 
get_user_ex(tmp, &sc->fpstate);
buf = compat_ptr(tmp);
-   err |= restore_i387_xstate_ia32(buf);
+   err |= restore_xstate_sig(buf, 1);
 
get_user_ex(*pax, &sc->ax);
} get_user_catch(err);
@@ -382,9 +382,12 @@ static void __user *get_sigframe(struct k_sigaction *ka, 
struct pt_regs *regs,
sp = (unsigned long) ka->sa.sa_restorer;
 
if (used_math()) {
-   sp = sp - sig_xstate_ia32_size;
+   unsigned long fx_aligned, math_size;
+
+   sp = alloc_mathframe(sp, 1, &fx_aligned, &math_size);
*fpstate = (struct _fpstate_ia32 __user *) sp;
-   if (save_i387_xstate_ia32(*fpstate) < 0)
+   if (save_xstate_sig(*fpstate, (void __user *)fx_aligned,
+   math_size) < 0)
return (void __user *) -1L;
}
 
diff --git a/arch/x86/include/asm/fpu-internal.h 
b/arch/x86/include/asm/fpu-internal.h
index 016acb3..4fbb419 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -22,11 +22,30 @@
 #include 
 #include 
 
-extern unsigned int sig_xstate_size;
+#ifdef CONFIG_X86_64
+# include 
+# include 
+int ia32_setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
+   compat_sigset_t *set, struct pt_regs *regs);
+int ia32_setup_frame(int sig, struct k_sigaction *ka,
+compat_sigset_t *set, struct pt_reg