Re: [PATCH 1/4] acpi,memory-hotplug : add memory offline code to acpi_memory_device_remove()

[Wen Congyang]

At 10/20/2012 02:19 AM, KOSAKI Motohiro Wrote:
>> Hmm, IIRC, if the memory is recognized from kerenl before driver 
>> initialization,
>> the memory device is not managed by the driver acpi_memhotplug.
> 
> Yup.
> 
> 
>> I think we should also deal with REMOVAL_NORMAL here now. Otherwise it will 
>> cause
>> some critical problem: we unbind the device from the driver but we still use
>> it. If we eject it, we have no chance to offline and remove it. It is very 
>> dangerous.
> 
> ??
> If resource was not allocated a driver, a driver doesn't need to
> deallocate it when
> error path. I haven't caught your point.
> 

REMOVAL_NORMAL can be in 2 cases:
1. error path. If init call fails, we don't call it. We call this function
   only when something fails after init.

2. unbind the device from the driver.
   If we don't offline and remove memory when unbinding the device from the 
driver,
   the device may be out of control. When we eject this driver, we don't 
offline and
   remove it, but we will eject and poweroff the device. It is very dangerous 
because
   the kernel uses the memory but we poweroff it.

   acpi_bus_hot_remove_device()
   acpi_bus_trim() // this function successes because the device has no 
driver
   _PS3 // poweroff
   _EJ0 // eject

Thanks
Wen Congyang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clocksource: clean up parse_pmtmr()

[Dan Carpenter]

I changed the strict_strtoul() to kstrtouint().  That has the check
for UINT_MAX built in to it so the ifdefs can be removed.  Also
I changed a printk() to pr_info().

Signed-off-by: Dan Carpenter 

diff --git a/drivers/clocksource/acpi_pm.c b/drivers/clocksource/acpi_pm.c
index 6b5cf02..5d1b926 100644
--- a/drivers/clocksource/acpi_pm.c
+++ b/drivers/clocksource/acpi_pm.c
@@ -233,16 +233,15 @@ fs_initcall(init_acpi_pm_clocksource);
  */
 static int __init parse_pmtmr(char *arg)
 {
-   unsigned long base;
+   unsigned int base;
+   int ret;
 
-   if (strict_strtoul(arg, 16, ))
-   return -EINVAL;
-#ifdef CONFIG_X86_64
-   if (base > UINT_MAX)
-   return -ERANGE;
-#endif
-   printk(KERN_INFO "PMTMR IOPort override: 0x%04x -> 0x%04lx\n",
-  pmtmr_ioport, base);
+   ret = kstrtouint(arg, 16, );
+   if (ret)
+   return ret;
+
+   pr_info("PMTMR IOPort override: 0x%04x -> 0x%04x\n", pmtmr_ioport,
+   base);
pmtmr_ioport = base;
 
return 1;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] use clamp_t in UNAME26 fix

[Kees Cook]

Argh, whoops. Greg, can you please include
31fd84b95eb211d5db460a1dda85e004800a7b52 in stable?

Thanks,

-Kees

On Fri, Oct 19, 2012 at 8:22 PM, Andrew Morton
 wrote:
> On Fri, 19 Oct 2012 18:45:53 -0700 Kees Cook  wrote:
>
>>
>> The min/max call needed to have explicit types on some architectures
>> (e.g. mn10300). Use clamp_t instead to avoid the warning.
>>
>> kernel/sys.c: In function 'override_release':
>> kernel/sys.c:1287:10: warning: comparison of distinct pointer types lacks a 
>> cast [enabled by default]
>>
>> Reported-by: Fengguang Wu 
>> Signed-off-by: Kees Cook 
>
> Needs a cc:stable in the changelog before committing, please.



-- 
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: [RESEND PATCH v2 1/2] update mem= option's spec according to its implementation

[KOSAKI Motohiro]

On Fri, Oct 19, 2012 at 8:52 PM, Wen Congyang  wrote:
> At 10/20/2012 02:11 AM, KOSAKI Motohiro Wrote:
>> On Fri, Oct 19, 2012 at 6:16 AM,   wrote:
>>> From: Wen Congyang 
>>>
>>> Current mem= implementation seems buggy because specification and
>>> implementation doesn't match. Current mem= has been working
>>> for many years and it's not buggy, it works as expected. So
>>> we should update the specification.
>>>
>>> Signed-off-by: Wen Congyang 
>>> Sort-of-tentatively-acked-by: Rob Landley 
>>> ---
>>>  Documentation/kernel-parameters.txt |7 ---
>>>  1 files changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/Documentation/kernel-parameters.txt 
>>> b/Documentation/kernel-parameters.txt
>>> index 9776f06..85b911a 100644
>>> --- a/Documentation/kernel-parameters.txt
>>> +++ b/Documentation/kernel-parameters.txt
>>> @@ -1481,9 +1481,10 @@ bytes respectively. Such letter suffixes can also be 
>>> entirely omitted.
>>> mem=nn[KMG] [KNL,BOOT] Force usage of a specific amount of 
>>> memory
>>> Amount of memory to be used when the kernel is not 
>>> able
>>> to see the whole system memory or for test.
>>> -   [X86-32] Use together with memmap= to avoid physical
>>> -   address space collisions. Without memmap= PCI 
>>> devices
>>> -   could be placed at addresses belonging to unused 
>>> RAM.
>>> +   [X86-32] Work as limiting max address. Use together
>>> +   with memmap= to avoid physical address space 
>>> collisions.
>>> +   Without memmap= PCI devices could be placed at 
>>> addresses
>>> +   belonging to unused RAM.
>>
>> If my remember is correct, x86-64 also specify maximum address.
>> but my remember is not clear.
>
> Do you mean max_addr option? It is only for ia64 box.

No.
Your patch say x86-32 and x86-64 have different mem parameter
semantics. and I doubt it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: sign the modules at install time

[Rusty Russell]

Stephen Rothwell  writes:
> Hi Rusty,
>
> On Fri, 19 Oct 2012 11:53:15 +1030 Rusty Russell  
> wrote:
>>
>> Linus Torvalds  writes:
>> > On Wed, Oct 17, 2012 at 10:34 PM, Rusty Russell  
>> > wrote:
>> >>
>> >> Hacking the keyid and signer-name to be extracted every time by
>> >> sign-file takes my modules_install time from 18.6 seconds to 19.1.  We'd
>> >> get that back easily by making sign-file a perl script anyway; it calls
>> >> out to perl 3 times already.
>> >
>> > Ok, that tiny slowdown seems worth the cleanup, especially if we'd get
>> > it back from somebody re-writing it in perl.
>> >
>> > Want to sign off on the two patches, or put them in your git tree?
>> 
>> Smerged them together: no point moving the x509keyid script now.
>> I dropped the optional dst arg, since we don't use it.
>
> So, this still generates the keys during the normal build, right?  That
> would be a problem for build servers that have limited randomness
> available to them, I think.

Yes.  You can either continue to disable module signatures, or copy some
pre-made keys in the toplevel: signing_key.priv and signing_key.x509.

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 1/4] module: add syscall to load module from fd

[Rusty Russell]

"H. Peter Anvin"  writes:
> On 10/18/2012 07:23 PM, Rusty Russell wrote:
>> "H. Peter Anvin"  writes:
>>> Given that, I have to say I now seriously question the value of
>>> finit_module().  The kernel can trivially discover if the pointed-to
>>> memory area is a MAP_SHARED mmap() of a file descriptor and if so which
>>> file descriptor... why can't we handle this behind the scenes?
>>
>> It is a bit more indirect, but also in practice it's a bit trickier than
>> that.  We need to ensure the memory doesn't change underneath us and
>> stays attached to that fd.  I can easily see that code slipping and
>> ending in an exploit.
>>
>> But that may be my irrational fear of the mm :)
>
> You have to do the same thing with a file/file descriptor, I would think.

After the fget(fd), it can't change where it's attached to though.
Ensuring that the fd behind the shared region is trusted and doesn't
change between the check and the read has more atomicity issues.

> However, I keep wondering about the use case for this, as opposed to 
> signatures.

The IMA people are signing every file in xattrs; this makes it trivial
for them to extend the same mechanism to kernel modules (though they'll
probably want to add xattrs to our cpio support, but bsdcpio et al
already have cpio-with-xattrs so I doubt it'll be hard).

And Kees simply has a known-secure partition, IIUC, which makes their
verification step pretty trivial.

The opportunity to add a flags arg is just the icing on the cake, but I
think the combination is compelling.

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/

[Update][PATCH] ACPI / PM: Fix device PM kernedoc comments and #ifdefs

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

The kerneldoc comments for acpi_pm_device_sleep_state(),
acpi_pm_device_run_wake(), and acpi_pm_device_sleep_wake() are
outdated or otherwise inaccurate and/or don't follow the common
kerneldoc patterns, so fix them.

Additionally, notice that acpi_pm_device_run_wake() should be under
CONFIG_PM_RUNTIME rather than under CONFIG_PM_SLEEP, so fix that too.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/sleep.c|   53 +---
 include/acpi/acpi_bus.h |8 +--
 2 files changed, 30 insertions(+), 31 deletions(-)

Index: linux-pm/drivers/acpi/sleep.c
===
--- linux-pm.orig/drivers/acpi/sleep.c
+++ linux-pm/drivers/acpi/sleep.c
@@ -699,28 +699,21 @@ int acpi_suspend(u32 acpi_state)
 
 #ifdef CONFIG_PM
 /**
- * acpi_pm_device_sleep_state - return preferred power state of ACPI device
- * in the system sleep state given by %acpi_target_sleep_state
- * @dev: device to examine; its driver model wakeup flags control
- * whether it should be able to wake up the system
- * @d_min_p: used to store the upper limit of allowed states range
- * @d_max_in: specify the lowest allowed states
- * Return value: preferred power state of the device on success, -ENODEV
- * (ie. if there's no 'struct acpi_device' for @dev) or -EINVAL on failure
+ * acpi_pm_device_sleep_state - Get preferred power state of ACPI device.
+ * @dev: Device whose preferred target power state to return.
+ * @d_min_p: Location to store the upper limit of the allowed states range.
+ * @d_max_in: Deepest low-power state to take into consideration.
+ * Return value: Preferred power state of the device on success, -ENODEV
+ * (if there's no 'struct acpi_device' for @dev) or -EINVAL on failure
  *
- * Find the lowest power (highest number) ACPI device power state that
- * device @dev can be in while the system is in the sleep state represented
- * by %acpi_target_sleep_state.  If @wake is nonzero, the device should be
- * able to wake up the system from this sleep state.  If @d_min_p is set,
- * the highest power (lowest number) device power state of @dev allowed
- * in this system sleep state is stored at the location pointed to by it.
+ * Find the lowest power (highest number) ACPI device power state that the
+ * device can be in while the system is in the sleep state represented
+ * by %acpi_target_sleep_state.  If @d_min_p is set, the highest power (lowest
+ * number) device power state that @dev can be in for the given system sleep
+ * state is stored at the location pointed to by it.
  *
- * The caller must ensure that @dev is valid before using this function.
- * The caller is also responsible for figuring out if the device is
- * supposed to be able to wake up the system and passing this information
- * via @wake.
+ * The caller must ensure that @dev is valid before using this function.
  */
-
 int acpi_pm_device_sleep_state(struct device *dev, int *d_min_p, int d_max_in)
 {
acpi_handle handle = DEVICE_ACPI_HANDLE(dev);
@@ -812,14 +805,15 @@ int acpi_pm_device_sleep_state(struct de
 EXPORT_SYMBOL(acpi_pm_device_sleep_state);
 #endif /* CONFIG_PM */
 
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_PM_RUNTIME
 /**
- * acpi_pm_device_run_wake - Enable/disable wake-up for given device.
- * @phys_dev: Device to enable/disable the platform to wake-up the system for.
- * @enable: Whether enable or disable the wake-up functionality.
+ * acpi_pm_device_run_wake - Enable/disable remote wakeup for given device.
+ * @phys_dev: Device to enable/disable the platform to wake up.
+ * @enable: Whether enable or disable the wakeup functionality.
  *
- * Find the ACPI device object corresponding to @pci_dev and try to
- * enable/disable the GPE associated with it.
+ * Find the ACPI device object corresponding to @phys_dev and try to
+ * enable/disable the GPE associated with it, so that it can generate
+ * wakeup signals for the device in response to external (remote) events.
  */
 int acpi_pm_device_run_wake(struct device *phys_dev, bool enable)
 {
@@ -847,12 +841,13 @@ int acpi_pm_device_run_wake(struct devic
return 0;
 }
 EXPORT_SYMBOL(acpi_pm_device_run_wake);
+#endif /* CONFIG_PM_RUNTIME */
 
+#ifdef CONFIG_PM_SLEEP
 /**
- * acpi_pm_device_sleep_wake - enable or disable the system wake-up
- *  capability of given device
- * @dev: device to handle
- * @enable: 'true' - enable, 'false' - disable the wake-up capability
+ * acpi_pm_device_sleep_wake - Enable or disable device to wake up the system.
+ * @dev: Device to enable/desible to wake up the system from sleep states.
+ * @enable: Whether enable or disable @dev to wake up the system.
  */
 int acpi_pm_device_sleep_wake(struct device *dev, bool enable)
 {
Index: linux-pm/include/acpi/acpi_bus.h

Re: Finding the interrupt vector of a given IRQ

[anish kumar]

On Sat, 2012-10-20 at 13:08 +0900, anish kumar wrote:
> On Fri, 2012-10-19 at 10:34 +0530, Arun KS wrote:
> > Hi Anish,
> > 
> > On Mon, May 28, 2012 at 9:16 AM, anish singh
> >  wrote:
> > On Mon, May 28, 2012 at 2:57 AM, richard -rw- weinberger
> >  wrote:
> > > On Sun, May 27, 2012 at 2:02 AM, Mark Farnell
> >  wrote:
> > >> In the kernel, how can I find out the interrupt vector
> > number of a
> > >> given IRQ (for example, IRQ7)?
> > >>
> > >> Within the kernel module, I would like to manually set the
> > IRQ using
> > >> the assembly code:
> > >>
> > >> asm("int $");
> > >>
> > >> and let the IRQ handler installed by a different module
> > catch that interrupt.
> > >>
> > >> Is this possible?
> > >
> > > No really because not all IRQ have an interrupt line to the
> > CPU.
> > > Linux can multiplex and emulate them. Think of GPIO drivers
> > with
> > > interrupt support.
> > 
> > Can you please describe this in detail?It would really help a
> > lot of
> > people like me.Does multiplex mean that all numbers starting
> > from
> > 0,1,2,3,.. TOTAL-interrupt will have interrupt lines
> > associated with it
> > eventhough all interrupt numbers are not linear?
> > 
> > GPIOs are grouped as banks. Let’s say 32 gpios are in a bank.
> > There will be only single interrupt line to interrupt controller for a
> > bank.
> > 
> > 
> > Consider that you have configured gpio1 and gpio16 as interrupts.
> > Even if interrupt happens on gpio 1 or gpio 16, the same interrupt
> > line will be triggered to 
> >   
> > Interrupt controller.
> > 
> > 
> > Now the gpio driver has to figure out reading the Interrupt status 
> > 
> > Register of GPIO to find which interrupt (gpio1 or gpio16) has really
> > fired.
> And this is done by this way:
> Suppose we have a chip(mfd-multi-funcion-driver) driver which is
> connected to processor using a gpio - this gpio line acts as interrupt
> line from the processor
> 
>   ++
> + Processor+  + Chip   +>USB  interrupt handler
> +  +gpio->+ MFD+>dock interrupt handler
>   ++>UART interrupt handler
> ++>Factory cable interrupt handler
> 
> So the code will be as follows:
> 
> handler_function()
> { 
>   /* find out which interrupt is triggered */
>   /* it can be usb,dock,uart or factory cable */
>   ret_irq = read_mfd_register();
>   /*
> * ok we found out the interrupt line, get a corresponding
>   * software linux irq number by calling
> * irq_domain_add_linear 
> * irq_create_mapping 
> * you would have made this calls in the probe probably
>   */ 
>   handle_nested_irq(ret_irq); 
> }
> 
> handle_nested_irq inturn will call all the irq_handlers in the system
> for your UART,usb and dock driver.
> 
> mfd_driver()
> { 
>   request_irq(gpio_to_irq(gpio), handler_function);
> }
> 
> Hope I have not missed anything.
> > 
> > So in this case a single interrupt line is multiplex for 32 gpio
> > interrupts.
> > 
> > 
> > HTH.
> > 
> > Thanks,
> > Arun
> >  
> > > Anyway, why to you think you need to trigger the raw IRQ
> > manually?
> > > This sounds really odd...
> > >
> > >
> > > --
> > > Thanks,
> > > //richard
> > >
> > > ___
> > > Kernelnewbies mailing list
> > > kernelnewb...@kernelnewbies.org
> > >
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> > 
> > ___
> > Kernelnewbies mailing list
> > kernelnewb...@kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> > 
> > 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [PATCH] extcon: driver model release call not needed

[Chanwoo Choi]

On 10/20/2012 12:33 PM, anish kumar wrote:
[]
> How about below?

I agree, but there were some minor issues,

[]
>  
>  static const char *muex_name = "mutually_exclusive";
> @@ -813,7 +779,32 @@ EXPORT_SYMBOL_GPL(extcon_dev_register);
>   */
>  void extcon_dev_unregister(struct extcon_dev *edev)
>  {
> -   extcon_cleanup(edev, false);
> +   mutex_lock(_dev_list_lock);
> +   list_del(>entry);
> +   mutex_unlock(_dev_list_lock);
> +
> +   if (!skip && get_device(edev->dev)) {

'skip' variable isn't anymore used and fix indentation as below code

[...]

-
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index e717bbc..ec7cc84 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -566,47 +566,9 @@ static int create_extcon_class(void)
return 0;
 }

-static void extcon_cleanup(struct extcon_dev *edev, bool skip)
-{
-   mutex_lock(_dev_list_lock);
-   list_del(>entry);
-   mutex_unlock(_dev_list_lock);
-
-   if (!skip && get_device(edev->dev)) {
-   int index;
-
-   if (edev->mutually_exclusive && edev->max_supported) {
-   for (index = 0; edev->mutually_exclusive[index];
-index++)
-   kfree(edev->d_attrs_muex[index].attr.name);
-   kfree(edev->d_attrs_muex);
-   kfree(edev->attrs_muex);
-   }
-
-   for (index = 0; index < edev->max_supported; index++)
-   kfree(edev->cables[index].attr_g.name);
-
-   if (edev->max_supported) {
-   kfree(edev->extcon_dev_type.groups);
-   kfree(edev->cables);
-   }
-
-#if defined(CONFIG_ANDROID)
-   if (switch_class)
-   class_compat_remove_link(switch_class, edev->dev, NULL);
-#endif
-   device_unregister(edev->dev);
-   put_device(edev->dev);
-   }
-
-   kfree(edev->dev);
-}
-
 static void extcon_dev_release(struct device *dev)
 {
-   struct extcon_dev *edev = (struct extcon_dev *) dev_get_drvdata(dev);
-
-   extcon_cleanup(edev, true);
+   kfree(edev->dev);
 }

 static const char *muex_name = "mutually_exclusive";
@@ -832,7 +794,37 @@ EXPORT_SYMBOL_GPL(extcon_dev_register);
  */
 void extcon_dev_unregister(struct extcon_dev *edev)
 {
-   extcon_cleanup(edev, false);
+   int index;
+
+   mutex_lock(_dev_list_lock);
+   list_del(>entry);
+   mutex_unlock(_dev_list_lock);
+
+   if (!get_device(edev->dev))
+   return;
+
+   if (edev->mutually_exclusive && edev->max_supported) {
+   for (index = 0; edev->mutually_exclusive[index];
+index++)
+   kfree(edev->d_attrs_muex[index].attr.name);
+   kfree(edev->d_attrs_muex);
+   kfree(edev->attrs_muex);
+   }
+
+   for (index = 0; index < edev->max_supported; index++)
+   kfree(edev->cables[index].attr_g.name);
+
+   if (edev->max_supported) {
+   kfree(edev->extcon_dev_type.groups);
+   kfree(edev->cables);
+   }
+
+#if defined(CONFIG_ANDROID)
+   if (switch_class)
+   class_compat_remove_link(switch_class, edev->dev, NULL);
+#endif
+   device_unregister(edev->dev);
+   put_device(edev->dev);
 }
 EXPORT_SYMBOL_GPL(extcon_dev_unregister);

Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 0/3] Add modules to support realtek PCIE card reader

[Dan Carpenter]

On Sat, Oct 06, 2012 at 03:23:56PM +0800, wwang wrote:
> We are still maintaining the SCSI driver for Realtek card reader,
> and will release the latest source code in the Github in the future.
> But maybe we won't push it to the staging tree any more.

Maybe we should just remove the staging code if it won't be fixed.
That's sort of the point of staging.

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio-timberdale: fix a potential wrapping issue

[Dan Carpenter]

On Fri, Oct 12, 2012 at 11:01:08PM +0200, Linus Walleij wrote:
> On Thu, Oct 11, 2012 at 8:56 AM, Dan Carpenter  
> wrote:
> 
> > ->last_ier is an unsigned long but the high bits can't be used int the
> > original code because the shift wraps.
> >
> > Signed-off-by: Dan Carpenter 
> 
> Applied, thanks!
> Should we send this to stable? (I assume so ...)

This was a static checker fix.  I guess the answer would depend on
if there are over 30 IRQs.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MM: Support more pagesizes for MAP_HUGETLB/SHM_HUGETLB v6

[Hillf Danton]

On Sat, Oct 20, 2012 at 12:48 AM, Andi Kleen  wrote:
> From: Andi Kleen 
>
> There was some desire in large applications using MAP_HUGETLB/SHM_HUGETLB
> to use 1GB huge pages on some mappings, and stay with 2MB on others. This
> is useful together with NUMA policy: use 2MB interleaving on some mappings,
> but 1GB on local mappings.
>
> This patch extends the IPC/SHM syscall interfaces slightly to allow specifying
> the page size.
>
> It borrows some upper bits in the existing flag arguments and allows encoding
> the log of the desired page size in addition to the *_HUGETLB flag.
> When 0 is specified the default size is used, this makes the change fully
> compatible.
>
> Extending the internal hugetlb code to handle this is straight forward. 
> Instead
> of a single mount it just keeps an array of them and selects the right
> mount based on the specified page size. When no page size is specified
> it uses the mount of the default page size.
>
> The change is not visible in /proc/mounts because internal mounts
> don't appear there. It also has very little overhead: the additional
> mounts just consume a super block, but not more memory when not used.
>
> I also exported the new flags to the user headers
> (they were previously under __KERNEL__). Right now only symbols
> for x86 and some other architecture for 1GB and 2MB are defined.
> The interface should already work for all other architectures
> though.  Only architectures that define multiple hugetlb sizes
> actually need it (that is currently x86, tile, powerpc). However
> tile and powerpc have user configurable hugetlb sizes, so it's
> not easy to add defines. A program on those architectures would
> need to query sysfs and use the appropiate log2.
>
> v2: Port to new tree. Fix unmount.
> v3: Ported to latest tree.
> v4: Ported to latest tree. Minor changes for review feedback. Updated
> description.
> v5: Remove unnecessary prototypes to fix merge error (Hillf Danton)
> v6: Rebased. Fix some unlikely error paths (Hillf Danton)
> Acked-by: Rik van Riel 
> Acked-by: KAMEZAWA Hiroyuki 
> Cc: Hillf Danton 
> Signed-off-by: Andi Kleen 
> ---

Thanks:)

Acked-by: Hillf Danton 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [PATCH] extcon: driver model release call not needed

[anish kumar]

On Sat, 2012-10-20 at 11:37 +0900, Chanwoo Choi wrote:
> On 10/20/2012 11:30 AM, anish kumar wrote:
> > On Sat, 2012-10-20 at 10:57 +0900, Chanwoo Choi wrote:
> >> On 10/19/2012 02:12 AM, anish kumar wrote:
> >>> From: anish kumar 
> >>>
> >>> We don't need a release call in this file as we are doing
> >>> everything needed in unregister call and we don't have any
> >>> more pointer to free up.
> >>>
> >>> Signed-off-by: anish kumar 
> >>> ---
> >>>  drivers/extcon/extcon-class.c |4 +---
> >>>  1 files changed, 1 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
> >>> index 946a318..cf30eb1 100644
> >>> --- a/drivers/extcon/extcon-class.c
> >>> +++ b/drivers/extcon/extcon-class.c
> >>> @@ -585,9 +585,7 @@ static void extcon_cleanup(struct extcon_dev *edev, 
> >>> bool skip)
> >>>  
> >>>  static void extcon_dev_release(struct device *dev)
> >>>  {
> >>> - struct extcon_dev *edev = (struct extcon_dev *) dev_get_drvdata(dev);
> >>> -
> >>> - extcon_cleanup(edev, true);
> >>> + /* We don't have any thing to free here */
> >>>  }
> >>>  
> >>>  static const char *muex_name = "mutually_exclusive";
> >>
> >> I can't agree this patch. The extcon_dev_release() function is used
> >> for dev->release. If some case without calling extcon_dev_unregister(),
> >> I think dev->release function is needed to free memory of edev->dev.
> > Is it not being released by extcon_dev_unregister?
> > I think it is released by that and we will do two times free and
> > list_del(>entry) as it is called by extcon_dev_release also.
> 
> I think that this patch should modify it as below patch to remove
> two call of kfree().  How about you?
> 
> diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
> index e717bbc..efca0b4 100644
> --- a/drivers/extcon/extcon-class.c
> +++ b/drivers/extcon/extcon-class.c
> @@ -597,9 +597,8 @@ static void extcon_cleanup(struct extcon_dev *edev, bool 
> skip)
>  #endif
> device_unregister(edev->dev);
> put_device(edev->dev);
> -   }
> -
> -   kfree(edev->dev);
> +   } else {
> +   kfree(edev->dev)
How about below?

diff --git a/drivers/extcon/extcon-class.c
b/drivers/extcon/extcon-class.c
index 946a318..62e4ecb 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -551,43 +551,9 @@ static int create_extcon_class(void)
return 0;
 }
 
-static void extcon_cleanup(struct extcon_dev *edev, bool skip)
-{
-   mutex_lock(_dev_list_lock);
-   list_del(>entry);
-   mutex_unlock(_dev_list_lock);
-
-   if (!skip && get_device(edev->dev)) {
-   int index;
-
-   if (edev->mutually_exclusive && edev->max_supported) {
-   for (index = 0; edev->mutually_exclusive[index];
-index++)
-
kfree(edev->d_attrs_muex[index].attr.name);
-   kfree(edev->d_attrs_muex);
-   kfree(edev->attrs_muex);
-   }
-
-   for (index = 0; index < edev->max_supported; index++)
-   kfree(edev->cables[index].attr_g.name);
-
-   if (edev->max_supported) {
-   kfree(edev->extcon_dev_type.groups);
-   kfree(edev->cables);
-   }
-
-   device_unregister(edev->dev);
-   put_device(edev->dev);
-   }
-
-   kfree(edev->dev);
-}
-
 static void extcon_dev_release(struct device *dev)
 {
-   struct extcon_dev *edev = (struct extcon_dev *)
dev_get_drvdata(dev);
-
-   extcon_cleanup(edev, true);
+   kfree(edev->dev);
 }
 
 static const char *muex_name = "mutually_exclusive";
@@ -813,7 +779,32 @@ EXPORT_SYMBOL_GPL(extcon_dev_register);
  */
 void extcon_dev_unregister(struct extcon_dev *edev)
 {
-   extcon_cleanup(edev, false);
+   mutex_lock(_dev_list_lock);
+   list_del(>entry);
+   mutex_unlock(_dev_list_lock);
+
+   if (!skip && get_device(edev->dev)) {
+   int index;
+
+   if (edev->mutually_exclusive && edev->max_supported) {
+   for (index = 0; edev->mutually_exclusive[index];
+index++)
+
kfree(edev->d_attrs_muex[index].attr.name);
+   kfree(edev->d_attrs_muex);
+   kfree(edev->attrs_muex);
+   }
+
+   for (index = 0; index < edev->max_supported; index++)
+   kfree(edev->cables[index].attr_g.name);
+
+   if (edev->max_supported) {
+   kfree(edev->extcon_dev_type.groups);
+   kfree(edev->cables);
+   }
+
+   device_unregister(edev->dev);
+   put_device(edev->dev);
+   }
 }
 EXPORT_SYMBOL_GPL(extcon_dev_unregister);
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 

Re: [PATCH] use clamp_t in UNAME26 fix

[Andrew Morton]

On Fri, 19 Oct 2012 18:45:53 -0700 Kees Cook  wrote:

> 
> The min/max call needed to have explicit types on some architectures
> (e.g. mn10300). Use clamp_t instead to avoid the warning.
> 
> kernel/sys.c: In function 'override_release':
> kernel/sys.c:1287:10: warning: comparison of distinct pointer types lacks a 
> cast [enabled by default]
> 
> Reported-by: Fengguang Wu 
> Signed-off-by: Kees Cook 

Needs a cc:stable in the changelog before committing, please.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [PATCH] extcon: driver model release call not needed

[Chanwoo Choi]

On 10/20/2012 11:30 AM, anish kumar wrote:
> On Sat, 2012-10-20 at 10:57 +0900, Chanwoo Choi wrote:
>> On 10/19/2012 02:12 AM, anish kumar wrote:
>>> From: anish kumar 
>>>
>>> We don't need a release call in this file as we are doing
>>> everything needed in unregister call and we don't have any
>>> more pointer to free up.
>>>
>>> Signed-off-by: anish kumar 
>>> ---
>>>  drivers/extcon/extcon-class.c |4 +---
>>>  1 files changed, 1 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
>>> index 946a318..cf30eb1 100644
>>> --- a/drivers/extcon/extcon-class.c
>>> +++ b/drivers/extcon/extcon-class.c
>>> @@ -585,9 +585,7 @@ static void extcon_cleanup(struct extcon_dev *edev, 
>>> bool skip)
>>>  
>>>  static void extcon_dev_release(struct device *dev)
>>>  {
>>> -   struct extcon_dev *edev = (struct extcon_dev *) dev_get_drvdata(dev);
>>> -
>>> -   extcon_cleanup(edev, true);
>>> +   /* We don't have any thing to free here */
>>>  }
>>>  
>>>  static const char *muex_name = "mutually_exclusive";
>>
>> I can't agree this patch. The extcon_dev_release() function is used
>> for dev->release. If some case without calling extcon_dev_unregister(),
>> I think dev->release function is needed to free memory of edev->dev.
> Is it not being released by extcon_dev_unregister?
> I think it is released by that and we will do two times free and
> list_del(>entry) as it is called by extcon_dev_release also.

I think that this patch should modify it as below patch to remove
two call of kfree().  How about you?

diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index e717bbc..efca0b4 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -597,9 +597,8 @@ static void extcon_cleanup(struct extcon_dev *edev, bool 
skip)
 #endif
device_unregister(edev->dev);
put_device(edev->dev);
-   }
-
-   kfree(edev->dev);
+   } else {
+   kfree(edev->dev);

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

Re: linux-next: build failure after merge of the final tree (tip/s390 trees related)

[Stephen Rothwell]

Hi Ingo,

On Sat, 20 Oct 2012 00:43:45 +0200 Ingo Molnar  wrote:
>
> * Stephen Rothwell  wrote:
> 
> > It looks as though you have not gone back far enough - you 
> > removed a couple of merges of sched/numa, but there are more. 
> > I have two of the problems resolved with merge patches that 
> > supply pmd_pgprot() for s390 and mips, but there is another 
> > problem with mips (see Ralf's other email).
> 
> Yeah. All of this should be resolved now in principle. Next time 
> you'll integrate linux-next is on Monday, right?

Excellent, thanks.  Yes, the next linux-next will be Monday (my time).

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


pgpQ6y8YqJolr.pgp
Description: PGP signature

RE: [PATCH net-next 04/21] wireless: Convert is__ether_addr uses to eth_addr_

[Bing Zhao]

Hi Joe,

> Subject: [PATCH net-next 04/21] wireless: Convert is__ether_addr uses to 
> eth_addr_
> 
> Convert the old ether_addr tests to eth_addr_.
> Adds api consistency.
> 
> Signed-off-by: Joe Perches 

Acked-by: Bing Zhao  [mwifiex]

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

Re: linux-next: build failure after merge of the final tree (tip/s390 trees related)

[Stephen Rothwell]

Hi Ingo,

On Sat, 20 Oct 2012 00:39:38 +0200 Ingo Molnar  wrote:
>
> From 7fc4d49214dba401f4b92ed62da60a5b257a653a Mon Sep 17 00:00:00 2001
> From: Ingo Molnar 
> Date: Sat, 20 Oct 2012 00:33:01 +0200
> Subject: [PATCH] MIPS/thp: Fix update_mmu_cache() cache call
> 
> As per recent upstream commit:
> 
>   b113da65785d mm: Add and use update_mmu_cache_pmd() in transparent huge 
> page code.
> 
> The call in do_huge_pmd_prot_none() needs to call update_mmu_cache_pmd()
> as well.
> 
> This resolves a MIPS build error triggered on linux-next.
> 
> Reported-by: Ralf Baechle 
> Reported-by: Stephen Rothwell 

Just a small nit - I didn't actually report this one, just Ralf did.

Thanks for the fixes.

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


pgponCKAQ4jdA.pgp
Description: PGP signature

Re: [PATCH] [PATCH] extcon: driver model release call not needed

[anish kumar]

On Sat, 2012-10-20 at 10:57 +0900, Chanwoo Choi wrote:
> On 10/19/2012 02:12 AM, anish kumar wrote:
> > From: anish kumar 
> > 
> > We don't need a release call in this file as we are doing
> > everything needed in unregister call and we don't have any
> > more pointer to free up.
> > 
> > Signed-off-by: anish kumar 
> > ---
> >  drivers/extcon/extcon-class.c |4 +---
> >  1 files changed, 1 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
> > index 946a318..cf30eb1 100644
> > --- a/drivers/extcon/extcon-class.c
> > +++ b/drivers/extcon/extcon-class.c
> > @@ -585,9 +585,7 @@ static void extcon_cleanup(struct extcon_dev *edev, 
> > bool skip)
> >  
> >  static void extcon_dev_release(struct device *dev)
> >  {
> > -   struct extcon_dev *edev = (struct extcon_dev *) dev_get_drvdata(dev);
> > -
> > -   extcon_cleanup(edev, true);
> > +   /* We don't have any thing to free here */
> >  }
> >  
> >  static const char *muex_name = "mutually_exclusive";
> 
> I can't agree this patch. The extcon_dev_release() function is used
> for dev->release. If some case without calling extcon_dev_unregister(),
> I think dev->release function is needed to free memory of edev->dev.
Is it not being released by extcon_dev_unregister?
I think it is released by that and we will do two times free and
list_del(>entry) as it is called by extcon_dev_release also.
> 
> The edev->dev->release store the function pointer of extcon_dev_release()
> in extcon_dev_register().
> edev->dev->parent = dev;
> edev->dev->class = extcon_class;
> edev->dev->release = extcon_dev_release;
> 
> 
> Thanks,
> Chanwoo Choi


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [PATCH] extcon: driver model release call not needed

[Chanwoo Choi]

On 10/19/2012 02:12 AM, anish kumar wrote:
> From: anish kumar 
> 
> We don't need a release call in this file as we are doing
> everything needed in unregister call and we don't have any
> more pointer to free up.
> 
> Signed-off-by: anish kumar 
> ---
>  drivers/extcon/extcon-class.c |4 +---
>  1 files changed, 1 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
> index 946a318..cf30eb1 100644
> --- a/drivers/extcon/extcon-class.c
> +++ b/drivers/extcon/extcon-class.c
> @@ -585,9 +585,7 @@ static void extcon_cleanup(struct extcon_dev *edev, bool 
> skip)
>  
>  static void extcon_dev_release(struct device *dev)
>  {
> - struct extcon_dev *edev = (struct extcon_dev *) dev_get_drvdata(dev);
> -
> - extcon_cleanup(edev, true);
> + /* We don't have any thing to free here */
>  }
>  
>  static const char *muex_name = "mutually_exclusive";

I can't agree this patch. The extcon_dev_release() function is used
for dev->release. If some case without calling extcon_dev_unregister(),
I think dev->release function is needed to free memory of edev->dev.

The edev->dev->release store the function pointer of extcon_dev_release()
in extcon_dev_register().
edev->dev->parent = dev;
edev->dev->class = extcon_class;
edev->dev->release = extcon_dev_release;


Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/10] memory-hotplug : check whether memory is offline or not when removing memory

[Wen Congyang]

At 10/20/2012 02:33 AM, KOSAKI Motohiro Wrote:
>> I think it again, and found that this check is necessary. Because we only
>> lock memory hotplug when offlining pages. Here is the steps to offline and
>> remove memory:
>>
>> 1. lock memory hotplug
>> 2. offline a memory section
>> 3. unlock memory hotplug
>> 4. repeat 1-3 to offline all memory sections
>> 5. lock memory hotplug
>> 6. remove memory
>> 7. unlock memory hotplug
>>
>> All memory sections must be offlined before removing memory. But we don't
>> hold
>> the lock in the whole operation. So we should check whether all memory
>> sections
>> are offlined before step6.
> 
> You should describe the race scenario in the patch description. OK?
> 

OK

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

Re: [RESEND PATCH v2 1/2] update mem= option's spec according to its implementation

[Wen Congyang]

At 10/20/2012 02:11 AM, KOSAKI Motohiro Wrote:
> On Fri, Oct 19, 2012 at 6:16 AM,   wrote:
>> From: Wen Congyang 
>>
>> Current mem= implementation seems buggy because specification and
>> implementation doesn't match. Current mem= has been working
>> for many years and it's not buggy, it works as expected. So
>> we should update the specification.
>>
>> Signed-off-by: Wen Congyang 
>> Sort-of-tentatively-acked-by: Rob Landley 
>> ---
>>  Documentation/kernel-parameters.txt |7 ---
>>  1 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/kernel-parameters.txt 
>> b/Documentation/kernel-parameters.txt
>> index 9776f06..85b911a 100644
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -1481,9 +1481,10 @@ bytes respectively. Such letter suffixes can also be 
>> entirely omitted.
>> mem=nn[KMG] [KNL,BOOT] Force usage of a specific amount of memory
>> Amount of memory to be used when the kernel is not 
>> able
>> to see the whole system memory or for test.
>> -   [X86-32] Use together with memmap= to avoid physical
>> -   address space collisions. Without memmap= PCI devices
>> -   could be placed at addresses belonging to unused RAM.
>> +   [X86-32] Work as limiting max address. Use together
>> +   with memmap= to avoid physical address space 
>> collisions.
>> +   Without memmap= PCI devices could be placed at 
>> addresses
>> +   belonging to unused RAM.
> 
> If my remember is correct, x86-64 also specify maximum address.
> but my remember is not clear.
> 

Do you mean max_addr option? It is only for ia64 box.

Thanks
Wen Congyang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] use clamp_t in UNAME26 fix

[Kees Cook]

The min/max call needed to have explicit types on some architectures
(e.g. mn10300). Use clamp_t instead to avoid the warning.

kernel/sys.c: In function 'override_release':
kernel/sys.c:1287:10: warning: comparison of distinct pointer types lacks a 
cast [enabled by default]

Reported-by: Fengguang Wu 
Signed-off-by: Kees Cook 
---
 kernel/sys.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sys.c b/kernel/sys.c
index 01865c6..e6e0ece 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1284,7 +1284,7 @@ static int override_release(char __user *release, size_t 
len)
rest++;
}
v = ((LINUX_VERSION_CODE >> 8) & 0xff) + 40;
-   copy = min(sizeof(buf), max_t(size_t, 1, len));
+   copy = clamp_t(size_t, len, 1, sizeof(buf));
copy = scnprintf(buf, copy, "2.6.%u%s", v, rest);
ret = copy_to_user(release, buf, copy + 1);
}
-- 
1.7.9.5


-- 
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: [PATCH] extcon : callback function to read cable property

[Chanwoo Choi]

On 10/19/2012 12:13 PM, Tc, Jenny wrote:
> 
> 
>> Subject: Re: [PATCH] extcon : callback function to read cable
>> property
>>
>> I think the reason why we have extcon is in first place is to
>> only notify the clients of cable connection and disconnection
>> and it is up to the client to decide what else to do with the
>> cable such as finding which state it is in and other details.
>> So I feel this should not be handled in the extcon.
>>
>> However it is up to the maintainer to decide.
>
> Once the consumer gets the notification, it needs to take some action.
> One of the action is to read the cable properties. This can be
> done by proprietary calls which is known both to the consumer and the
>> provider.
> My intention is to avoid this proprietary calls. Since both the
> provider and consumer are communicating with the extcon subsystem
> , I feel having a callback function of this kind would help to
> avoid the use of proprietary calls. Also I agree that extcon
> notifier chains are used to notify the cable state
> (attach/detach). But if a cable has more than two states (like the
> charger cable) how do we support it without
 having a callback function like this?
> Let the maintainer take the final decision.
 Well this use case will keep on growing if we start factor in this
 kind of changes and that is why I am opposed to adding any other state.
 Maintainer?
>
>

>>
>> Hello,
>>
>>
>> I don't think it's appropriate to declare the charger specific properties in
>> extcon.h. The status of a charger should be and can be represented by an
>> instance of regulator, power-supply-class, or charger-manager.
>>
> Agreed. We can move this to power supply subsystem.
> 
>> Thus, we may (I'm still not sure) need to let extcon to relay the instance
>> (struct device? or char *devname?) with some callback similar with
>> get_cable_device().  However, allowing (and encouraging) to pass void
>> pointer of cable_props to extcon users from extcon device appears not
>> adequete. If the both parties can use their own "private"
>> data structure, why they cannot simply pass their own data witht the
>> "private" data channel?
>>
>>
>> Recap:
>> - The later part of patch: NACK
>> - The first part of patch (callback): need to reconsider the data type.
>> We may get device pointer or device name that is correspondant to the
>> cable, which in turn, guides us to the corresponding data structure (charger-
>> manager, regulator, or something) However, I'm still not sure which should
>> be appropriate for this.
>>
> 
> The requirement for this feature came from the implementation of the
> power supply charging framework 
> (http://www.spinics.net/lists/kernel/msg1420500.html 
> refer charger_cable_event_worker function). The charging framework is not a 
> driver. It can
> be compiled with the power supply class driver to support charging. Also the
> private data structure may not provide a generic method for this 
> implementation
> since the extcon provider drivers will be different in different platforms. 
> So it's not
> necessary that the framework knows the private data structure of the provider.
> Basically the requirement is to have a generic method to retrieve the cable 
> properties without
> knowing the extcon provider driver internal implementation. Can you suggest a 
> generic approach
> for this problem?
> 
The rold of extcon inform only attached/detached state of extcon consumer driver
from extcon provider driver. After extcon consumer driver detect the state of 
cable
through extcon, extcon consumer driver or framework should get the additional 
information of cable
from other device driver except of extcon.

Also, extcon manage various cables (e.g., USB, TA, MHL, JIG-USB-ON, 
JIG-USB-OFF, Dock)
What are common properties among many cables expect attached or detached state?

> Also the cable states we support in extcon (attach/detach) is not sufficient
> to support the cable states of a charger cable which can have more than 2 
> states. The charger cable 
> states can be (1)attach/(2)detach, (3)suspend - host suspend (different from 
> detach since it's possible to charge
> in this state but with a different charge current than the attached 
> state),(4)resume - resume after the suspend,
> (5)update - update the cable properties after USB enumeration (USB cable 
> supports 100(USB2.0)/150(USB3.0)
> in an un configured state. But after enumeration it can support up to 
> 500mA(USB 2.0)/900(USB 3.0))
> 
> Since extcon is basically intended to support the cable states, how do we 
> support cables with
> more than two states?

You explained about charger cable for charging framework. I think that extcon 
consumer driver
can detect the chagne of system state from idle to suspend, then extcon 
consumer driver change
charge current according to system state(idle or suspend).  Also, I think that 
the main 

[PATCH 6/6] xen/pvh: /dev/xen/privcmd changes.

[Konrad Rzeszutek Wilk]

From: Mukesh Rathor 

PVH only supports the batch interface. To map a foreign page to a process,
the PFN must be allocated and PVH path uses ballooning for that purpose.

The returned PFN is then mapped to the foreign page.
xen_unmap_domain_mfn_range() is introduced to unmap these pages via the
privcmd close call.

Signed-off-by: Mukesh Rathor 
[v1: Fix up privcmd_close]
Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/privcmd.c |   69 +++-
 1 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index b612267..b9d0898 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -33,11 +33,14 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "privcmd.h"
 
 MODULE_LICENSE("GPL");
 
+#define PRIV_VMA_LOCKED ((void *)1)
+
 #ifndef HAVE_ARCH_PRIVCMD_MMAP
 static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
 #endif
@@ -199,6 +202,10 @@ static long privcmd_ioctl_mmap(void __user *udata)
if (!xen_initial_domain())
return -EPERM;
 
+   /* We only support privcmd_ioctl_mmap_batch for auto translated. */
+   if (xen_feature(XENFEAT_auto_translated_physmap))
+   return -ENOSYS;
+
if (copy_from_user(, udata, sizeof(mmapcmd)))
return -EFAULT;
 
@@ -246,6 +253,7 @@ struct mmap_batch_state {
domid_t domain;
unsigned long va;
struct vm_area_struct *vma;
+   int index;
/* A tristate:
 *  0 for no errors
 *  1 if at least one error has happened (and no
@@ -260,15 +268,24 @@ struct mmap_batch_state {
xen_pfn_t __user *user_mfn;
 };
 
+/* auto translated dom0 note: if domU being created is PV, then mfn is
+ * mfn(addr on bus). If it's auto xlated, then mfn is pfn (input to HAP).
+ */
 static int mmap_batch_fn(void *data, void *state)
 {
xen_pfn_t *mfnp = data;
struct mmap_batch_state *st = state;
+   struct vm_area_struct *vma = st->vma;
+   struct page **pages = vma->vm_private_data;
+   struct page *cur_page = NULL;
int ret;
 
+   if (xen_feature(XENFEAT_auto_translated_physmap))
+   cur_page = pages[st->index++];
+
ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
 st->vma->vm_page_prot, st->domain,
-NULL);
+_page);
 
/* Store error code for second pass. */
*(st->err++) = ret;
@@ -304,6 +321,32 @@ static int mmap_return_errors_v1(void *data, void *state)
return __put_user(*mfnp, st->user_mfn++);
 }
 
+/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
+ * the vma with the page info to use later.
+ * Returns: 0 if success, otherwise -errno
+ */
+static int alloc_empty_pages(struct vm_area_struct *vma, int numpgs)
+{
+   int rc;
+   struct page **pages;
+
+   pages = kcalloc(numpgs, sizeof(pages[0]), GFP_KERNEL);
+   if (pages == NULL)
+   return -ENOMEM;
+
+   rc = alloc_xenballooned_pages(numpgs, pages, 0);
+   if (rc != 0) {
+   pr_warn("%s Could not alloc %d pfns rc:%d\n", __func__,
+   numpgs, rc);
+   kfree(pages);
+   return -ENOMEM;
+   }
+   BUG_ON(vma->vm_private_data != PRIV_VMA_LOCKED);
+   vma->vm_private_data = pages;
+
+   return 0;
+}
+
 static struct vm_operations_struct privcmd_vm_ops;
 
 static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
@@ -371,10 +414,18 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, 
int version)
up_write(>mmap_sem);
goto out;
}
+   if (xen_feature(XENFEAT_auto_translated_physmap)) {
+   ret = alloc_empty_pages(vma, m.num);
+   if (ret < 0) {
+   up_write(>mmap_sem);
+   goto out;
+   }
+   }
 
state.domain= m.dom;
state.vma   = vma;
state.va= m.addr;
+   state.index = 0;
state.global_error  = 0;
state.err   = err_array;
 
@@ -439,6 +490,19 @@ static long privcmd_ioctl(struct file *file,
return ret;
 }
 
+static void privcmd_close(struct vm_area_struct *vma)
+{
+   struct page **pages = vma->vm_private_data;
+   int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+
+   if (!xen_feature(XENFEAT_auto_translated_physmap || !numpgs || !pages))
+   return;
+
+   xen_unmap_domain_mfn_range(vma, numpgs, pages);
+   free_xenballooned_pages(numpgs, pages);
+   kfree(pages);
+}
+
 static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
@@ -449,6 +513,7 @@ static int 

[PATCH 4/6] xen/pvh: bootup and setup related changes.

[Konrad Rzeszutek Wilk]

From: Mukesh Rathor 

In enlighten.c for PVH we can trap cpuid via vmexit, so don't
need to use emulated prefix call. We also check for vector callback
early on, as it is a required feature. PVH also runs at default kernel
IOPL.

In setup.c, in xen_add_extra_mem() we can skip updating P2M as it's managed
by Xen. PVH maps the entire IO space, but only RAM pages need to be repopulated.

Finally, pure PV settings are moved to a separate function that is only called
for pure PV, ie, pv with pvmmu.

Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/enlighten.c |   77 ++---
 arch/x86/xen/setup.c |   64 +++---
 2 files changed, 110 insertions(+), 31 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e3497f2..53db37f 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -107,6 +108,9 @@ RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
+#define xen_pvh_domain() (xen_pv_domain() && \
+ xen_feature(XENFEAT_auto_translated_physmap) && \
+ xen_have_vector_callback)
 /*
  * Point at some empty memory to start with. We map the real shared_info
  * page as soon as fixmap is up and running.
@@ -219,8 +223,9 @@ static void __init xen_banner(void)
struct xen_extraversion extra;
HYPERVISOR_xen_version(XENVER_extraversion, );
 
-   printk(KERN_INFO "Booting paravirtualized kernel on %s\n",
-  pv_info.name);
+   pr_info("Booting paravirtualized kernel %son %s\n",
+   xen_feature(XENFEAT_auto_translated_physmap) ?
+   "with PVH extensions " : "", pv_info.name);
printk(KERN_INFO "Xen version: %d.%d%s%s\n",
   version >> 16, version & 0x, extra.extraversion,
   xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " 
(preserve-AD)" : "");
@@ -273,12 +278,15 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
break;
}
 
-   asm(XEN_EMULATE_PREFIX "cpuid"
-   : "=a" (*ax),
- "=b" (*bx),
- "=c" (*cx),
- "=d" (*dx)
-   : "0" (*ax), "2" (*cx));
+   if (xen_pvh_domain())
+   native_cpuid(ax, bx, cx, dx);
+   else
+   asm(XEN_EMULATE_PREFIX "cpuid"
+   : "=a" (*ax),
+   "=b" (*bx),
+   "=c" (*cx),
+   "=d" (*dx)
+   : "0" (*ax), "2" (*cx));
 
*bx &= maskebx;
*cx &= maskecx;
@@ -1055,6 +1063,10 @@ void xen_setup_shared_info(void)
HYPERVISOR_shared_info =
(struct shared_info *)__va(xen_start_info->shared_info);
 
+   /* PVH TBD/FIXME: vcpu info placement in phase 2 */
+   if (xen_pvh_domain())
+   return;
+
 #ifndef CONFIG_SMP
/* In UP this is as good a place as any to set up shared info */
xen_setup_vcpu_info_placement();
@@ -1292,6 +1304,11 @@ static const struct machine_ops xen_machine_ops 
__initconst = {
  */
 static void __init xen_setup_stackprotector(void)
 {
+   /* PVH TBD/FIXME: investigate setup_stack_canary_segment */
+   if (xen_feature(XENFEAT_auto_translated_physmap)) {
+   switch_to_new_gdt(0);
+   return;
+   }
pv_cpu_ops.write_gdt_entry = xen_write_gdt_entry_boot;
pv_cpu_ops.load_gdt = xen_load_gdt_boot;
 
@@ -1302,6 +1319,19 @@ static void __init xen_setup_stackprotector(void)
pv_cpu_ops.load_gdt = xen_load_gdt;
 }
 
+static void __init xen_pvh_early_guest_init(void)
+{
+   if (xen_feature(XENFEAT_hvm_callback_vector))
+   xen_have_vector_callback = 1;
+
+#ifdef CONFIG_X86_32
+   if (xen_feature(XENFEAT_auto_translated_physmap)) {
+   xen_raw_printk("ERROR: 32bit PVH guests are not supported\n");
+   BUG();
+   }
+#endif
+}
+
 /* First C function to be called on Xen boot */
 asmlinkage void __init xen_start_kernel(void)
 {
@@ -1313,13 +1343,18 @@ asmlinkage void __init xen_start_kernel(void)
 
xen_domain_type = XEN_PV_DOMAIN;
 
+   xen_setup_features();
+   xen_pvh_early_guest_init();
xen_setup_machphys_mapping();
 
/* Install Xen paravirt ops */
pv_info = xen_info;
pv_init_ops = xen_init_ops;
-   pv_cpu_ops = xen_cpu_ops;
pv_apic_ops = xen_apic_ops;
+   if (xen_pvh_domain())
+   pv_cpu_ops.cpuid = xen_cpuid;
+   else
+   pv_cpu_ops = xen_cpu_ops;
 
x86_init.resources.memory_setup = xen_memory_setup;
x86_init.oem.arch_setup = xen_arch_setup;
@@ -1351,8 +1386,6 @@ asmlinkage void __init 

[PATCH 3/6] xen/pvh: Implements mmu changes for PVH.

[Konrad Rzeszutek Wilk]

From: Mukesh Rathor 

First the set/clear mmio pte function makes a hypercall to update the
P2M in Xen with 1:1 mapping. Since PVH uses mostly native mmu ops, we
leave the generic (native_*) for the rest.

Two local functions are introduced to add to xen physmap for xen remap
interface. Xen unmap interface is introduced so the privcmd pte entries
can be cleared in Xen p2m table.

Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/mmu.c|  162 +++--
 arch/x86/xen/mmu.h|2 +
 drivers/xen/privcmd.c |5 +-
 include/xen/xen-ops.h |5 +-
 4 files changed, 165 insertions(+), 9 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 6226c99..5747a41 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -74,6 +74,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "multicalls.h"
 #include "mmu.h"
@@ -332,6 +333,20 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
__xen_set_pte(ptep, pteval);
 }
 
+void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
+ int nr_mfns, int add_mapping)
+{
+   struct physdev_map_iomem iomem;
+
+   iomem.first_gfn = pfn;
+   iomem.first_mfn = mfn;
+   iomem.nr_mfns = nr_mfns;
+   iomem.add_mapping = add_mapping;
+
+   if (HYPERVISOR_physdev_op(PHYSDEVOP_map_iomem, ))
+   BUG();
+}
+
 static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
pte_t *ptep, pte_t pteval)
 {
@@ -1221,6 +1236,8 @@ static void __init xen_pagetable_init(void)
 #endif
paging_init();
xen_setup_shared_info();
+   if (xen_feature(XENFEAT_auto_translated_physmap))
+   return;
 #ifdef CONFIG_X86_64
if (!xen_feature(XENFEAT_auto_translated_physmap)) {
unsigned long new_mfn_list;
@@ -1528,6 +1545,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t 
pte)
 static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
 {
struct mmuext_op op;
+
+   if (xen_feature(XENFEAT_writable_page_tables))
+   return;
+
op.cmd = cmd;
op.arg1.mfn = pfn_to_mfn(pfn);
if (HYPERVISOR_mmuext_op(, 1, NULL, DOMID_SELF))
@@ -1725,6 +1746,10 @@ static void set_page_prot(void *addr, pgprot_t prot)
unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
pte_t pte = pfn_pte(pfn, prot);
 
+   /* recall for PVH, page tables are native. */
+   if (xen_feature(XENFEAT_auto_translated_physmap))
+   return;
+
if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
BUG();
 }
@@ -1802,6 +1827,9 @@ static void convert_pfn_mfn(void *v)
pte_t *pte = v;
int i;
 
+   if (xen_feature(XENFEAT_auto_translated_physmap))
+   return;
+
/* All levels are converted the same way, so just treat them
   as ptes. */
for (i = 0; i < PTRS_PER_PTE; i++)
@@ -1821,6 +1849,7 @@ static void __init check_pt_base(unsigned long *pt_base, 
unsigned long *pt_end,
(*pt_end)--;
}
 }
+
 /*
  * Set up the initial kernel pagetable.
  *
@@ -1831,6 +1860,7 @@ static void __init check_pt_base(unsigned long *pt_base, 
unsigned long *pt_end,
  * but that's enough to get __va working.  We need to fill in the rest
  * of the physical mapping once some sort of allocator has been set
  * up.
+ * NOTE: for PVH, the page tables are native.
  */
 void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
 {
@@ -1908,10 +1938,13 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, 
unsigned long max_pfn)
 * structure to attach it to, so make sure we just set kernel
 * pgd.
 */
-   xen_mc_batch();
-   __xen_write_cr3(true, __pa(init_level4_pgt));
-   xen_mc_issue(PARAVIRT_LAZY_CPU);
-
+   if (xen_feature(XENFEAT_writable_page_tables)) {
+   native_write_cr3(__pa(init_level4_pgt));
+   } else {
+   xen_mc_batch();
+   __xen_write_cr3(true, __pa(init_level4_pgt));
+   xen_mc_issue(PARAVIRT_LAZY_CPU);
+   }
/* We can't that easily rip out L3 and L2, as the Xen pagetables are
 * set out this way: [L4], [L1], [L2], [L3], [L1], [L1] ...  for
 * the initial domain. For guests using the toolstack, they are in:
@@ -2178,8 +2211,13 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = 
{
 
 void __init xen_init_mmu_ops(void)
 {
-   x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
x86_init.paging.pagetable_init = xen_pagetable_init;
+
+   if (xen_feature(XENFEAT_auto_translated_physmap)) {
+   pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
+   return;
+   }
+   x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
pv_mmu_ops = xen_mmu_ops;
 
memset(dummy_mapping, 0xff, PAGE_SIZE);
@@ 

[PATCH 2/6] xen/pvh: Extend vcpu_guest_context, p2m, event, and xenbus to support PVH.

[Konrad Rzeszutek Wilk]

From: Mukesh Rathor 

make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, as PVH
only needs to send down gdtaddr and gdtsz.

For interrupts, PVH uses native_irq_ops.
vcpu hotplug is currently not available for PVH.

For events we follow what PVHVM does - to use callback vector.
Lastly, also use HVM path to setup XenBus.

Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/include/asm/xen/interface.h |   11 +-
 arch/x86/xen/irq.c   |5 ++-
 arch/x86/xen/p2m.c   |2 +-
 arch/x86/xen/smp.c   |   75 ++
 drivers/xen/cpu_hotplug.c|4 +-
 drivers/xen/events.c |9 -
 drivers/xen/xenbus/xenbus_client.c   |3 +-
 7 files changed, 77 insertions(+), 32 deletions(-)

diff --git a/arch/x86/include/asm/xen/interface.h 
b/arch/x86/include/asm/xen/interface.h
index 6d2f75a..4c08f23 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -144,7 +144,16 @@ struct vcpu_guest_context {
 struct cpu_user_regs user_regs; /* User-level CPU registers */
 struct trap_info trap_ctxt[256];/* Virtual IDT  */
 unsigned long ldt_base, ldt_ents;   /* LDT (linear address, # ents) */
-unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
+union {
+   struct {
+   /* PV: GDT (machine frames, # ents).*/
+   unsigned long gdt_frames[16], gdt_ents;
+   } pv;
+   struct {
+   /* PVH: GDTR addr and size */
+   unsigned long gdtaddr, gdtsz;
+   } pvh;
+} u;
 unsigned long kernel_ss, kernel_sp; /* Virtual TSS (only SS1/SP1)   */
 /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
 unsigned long ctrlreg[8];   /* CR0-CR7 (control registers)  */
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 01a4dc0..fcbe56a 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -129,6 +130,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = {
 
 void __init xen_init_irq_ops(void)
 {
-   pv_irq_ops = xen_irq_ops;
+   /* For PVH we use default pv_irq_ops settings */
+   if (!xen_feature(XENFEAT_hvm_callback_vector))
+   pv_irq_ops = xen_irq_ops;
x86_init.irqs.intr_init = xen_init_IRQ;
 }
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 95fb2aa..ea553c8 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -798,7 +798,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long 
mfn)
 {
unsigned topidx, mididx, idx;
 
-   if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
+   if (xen_feature(XENFEAT_auto_translated_physmap)) {
BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
return true;
}
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 353c50f..df400349 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
touch_softlockup_watchdog();
preempt_disable();
 
-   xen_enable_sysenter();
-   xen_enable_syscall();
-
+   /* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
+   if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
+   xen_enable_sysenter();
+   xen_enable_syscall();
+   }
cpu = smp_processor_id();
smp_store_cpu_info(cpu);
cpu_data(cpu).x86_max_cores = 1;
@@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
BUG_ON(smp_processor_id() != 0);
native_smp_prepare_boot_cpu();
 
-   /* We've switched to the "real" per-cpu gdt, so make sure the
-  old memory can be recycled */
-   make_lowmem_page_readwrite(xen_initial_gdt);
-
+   if (!xen_feature(XENFEAT_writable_page_tables)) {
+   /* We've switched to the "real" per-cpu gdt, so make sure the
+* old memory can be recycled */
+   make_lowmem_page_readwrite(xen_initial_gdt);
+   }
xen_filter_cpu_maps();
xen_setup_vcpu_info_placement();
 }
@@ -300,8 +303,6 @@ cpu_initialize_context(unsigned int cpu, struct task_struct 
*idle)
gdt = get_cpu_gdt_table(cpu);
 
ctxt->flags = VGCF_IN_KERNEL;
-   ctxt->user_regs.ds = __USER_DS;
-   ctxt->user_regs.es = __USER_DS;
ctxt->user_regs.ss = __KERNEL_DS;
 #ifdef CONFIG_X86_32
ctxt->user_regs.fs = __KERNEL_PERCPU;
@@ -310,35 +311,57 @@ cpu_initialize_context(unsigned int cpu, struct 
task_struct *idle)
ctxt->gs_base_kernel = per_cpu_offset(cpu);
 #endif
ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
-   ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
 
memset(>fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
 
-   

[PATCH 1/6] xen/pvh: Support ParaVirtualized Hardware extensions.

[Konrad Rzeszutek Wilk]

From: Mukesh Rathor 

PVH allows PV linux guest to utilize hardware extended capabilities, such
as running MMU updates in a HVM container.

This patch allows it to be configured and enabled. Also, basic header file
changes to add new subcalls to physmap hypercall.

Lastly, mfn_to_local_pfn must return mfn for paging mode translate
(since we let the hypervisor - or CPU - do them for us).

Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/include/asm/xen/page.h |3 +++
 arch/x86/xen/Kconfig|   10 ++
 arch/x86/xen/xen-head.S |   11 ++-
 include/xen/interface/memory.h  |   24 +++-
 include/xen/interface/physdev.h |   10 ++
 5 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 472b9b7..6af440d 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -159,6 +159,9 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine)
 static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
 {
unsigned long pfn = mfn_to_pfn(mfn);
+
+   if (xen_feature(XENFEAT_auto_translated_physmap))
+   return mfn;
if (get_phys_to_machine(pfn) != mfn)
return -1; /* force !pfn_valid() */
return pfn;
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index fdce49c..822c5a0 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -50,3 +50,13 @@ config XEN_DEBUG_FS
  Enable statistics output and various tuning options in debugfs.
  Enabling this option may incur a significant performance overhead.
 
+config XEN_X86_PVH
+   bool "Support for running as a PVH guest (EXPERIMENTAL)"
+   depends on X86_64 && XEN && EXPERIMENTAL
+   default n
+   help
+  This option enables support for running as a PVH guest (PV guest
+  using hardware extensions) under a suitably capable hypervisor.
+  This option is EXPERIMENTAL because the hypervisor interfaces
+  which it uses are not yet considered stable therefore backwards and
+  forwards compatibility is not yet guaranteed.  If unsure, say N.
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 7faed58..1a6bca1 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -13,6 +13,15 @@
 #include 
 #include 
 
+#ifdef CONFIG_XEN_X86_PVH
+#define FEATURES_PVH "|writable_descriptor_tables" \
+"|auto_translated_physmap" \
+"|supervisor_mode_kernel" \
+"|hvm_callback_vector"
+#else
+#define FEATURES_PVH /* Not supported */
+#endif
+
__INIT
 ENTRY(startup_xen)
cld
@@ -95,7 +104,7 @@ NEXT_HYPERCALL(arch_6)
 #endif
ELFNOTE(Xen, XEN_ELFNOTE_ENTRY,  _ASM_PTR startup_xen)
ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _ASM_PTR hypercall_page)
-   ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,   .asciz 
"!writable_page_tables|pae_pgdir_above_4gb")
+   ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,   .asciz 
"!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH)
ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE,   .asciz "yes")
ELFNOTE(Xen, XEN_ELFNOTE_LOADER, .asciz "generic")
ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID,
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index b66d04c..8beebdb 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -169,7 +169,13 @@ struct xen_add_to_physmap {
 /* Source mapping space. */
 #define XENMAPSPACE_shared_info 0 /* shared info page */
 #define XENMAPSPACE_grant_table 1 /* grant table page */
-unsigned int space;
+#define XENMAPSPACE_gmfn2 /* GMFN */
+#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
+uint16_t space;
+domid_t foreign_domid; /* IFF XENMAPSPACE_gmfn_foreign */
+
+#define XENMAPIDX_grant_table_status 0x8000
 
 /* Index into source mapping space. */
 xen_ulong_t idx;
@@ -237,4 +243,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map);
  * during a driver critical region.
  */
 extern spinlock_t xen_reservation_lock;
+
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap  15
+struct xen_remove_from_physmap {
+/* Which domain to change the mapping for. */
+domid_t domid;
+
+/* GPFN of the current mapping of the page. */
+xen_pfn_t gpfn;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index 1844d31..83050d3 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -274,6 +274,16 @@ struct physdev_dbgp_op {
 

[PATCH 5/6] xen/pvh: balloon and grant changes.

[Konrad Rzeszutek Wilk]

From: Mukesh Rathor 

For balloon changes we skip setting of local P2M as it's updated
in Xen. For grant, the shared grant frame is the pfn and not mfn,
hence its mapped via the same code path as HVM.

Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/balloon.c |   15 +--
 drivers/xen/gntdev.c  |3 ++-
 drivers/xen/grant-table.c |   26 ++
 3 files changed, 33 insertions(+), 11 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 31ab82f..c825b63 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -361,7 +361,9 @@ static enum bp_state increase_reservation(unsigned long 
nr_pages)
set_phys_to_machine(pfn, frame_list[i]);
 
/* Link back into the page tables if not highmem. */
-   if (xen_pv_domain() && !PageHighMem(page)) {
+   if (xen_pv_domain() && !PageHighMem(page) &&
+   !xen_feature(XENFEAT_auto_translated_physmap)) {
+
int ret;
ret = HYPERVISOR_update_va_mapping(
(unsigned long)__va(pfn << PAGE_SHIFT),
@@ -418,12 +420,13 @@ static enum bp_state decrease_reservation(unsigned long 
nr_pages, gfp_t gfp)
scrub_page(page);
 
if (xen_pv_domain() && !PageHighMem(page)) {
-   ret = HYPERVISOR_update_va_mapping(
-   (unsigned long)__va(pfn << PAGE_SHIFT),
-   __pte_ma(0), 0);
-   BUG_ON(ret);
+   if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+   ret = HYPERVISOR_update_va_mapping(
+   (unsigned long)__va(pfn << PAGE_SHIFT),
+   __pte_ma(0), 0);
+   BUG_ON(ret);
+   }
}
-
}
 
/* Ensure that ballooned highmem pages don't have kmaps. */
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 610bfc6..d39d54e 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -803,7 +803,8 @@ static int __init gntdev_init(void)
if (!xen_domain())
return -ENODEV;
 
-   use_ptemod = xen_pv_domain();
+   use_ptemod = xen_pv_domain() &&
+!xen_feature(XENFEAT_auto_translated_physmap);
 
err = misc_register(_miscdev);
if (err != 0) {
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index b2b0a37..9c0019d 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1029,14 +1029,19 @@ static void gnttab_unmap_frames_v2(void)
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
struct gnttab_setup_table setup;
-   unsigned long *frames;
+   unsigned long *frames, start_gpfn;
unsigned int nr_gframes = end_idx + 1;
int rc;
 
-   if (xen_hvm_domain()) {
+   if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) {
struct xen_add_to_physmap xatp;
unsigned int i = end_idx;
rc = 0;
+
+   if (xen_hvm_domain())
+   start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
+   else
+   start_gpfn = virt_to_pfn(gnttab_shared.addr);
/*
 * Loop backwards, so that the first hypercall has the largest
 * index, ensuring that the table will grow only once.
@@ -1045,7 +1050,7 @@ static int gnttab_map(unsigned int start_idx, unsigned 
int end_idx)
xatp.domid = DOMID_SELF;
xatp.idx = i;
xatp.space = XENMAPSPACE_grant_table;
-   xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
+   xatp.gpfn = start_gpfn + i;
rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, );
if (rc != 0) {
printk(KERN_WARNING
@@ -1108,7 +1113,7 @@ static void gnttab_request_version(void)
int rc;
struct gnttab_set_version gsv;
 
-   if (xen_hvm_domain())
+   if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap))
gsv.version = 1;
else
gsv.version = 2;
@@ -1136,12 +1141,25 @@ static void gnttab_request_version(void)
 int gnttab_resume(void)
 {
unsigned int max_nr_gframes;
+   char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
 
gnttab_request_version();
max_nr_gframes = gnttab_max_grant_frames();
if (max_nr_gframes < nr_grant_frames)
return -ENOSYS;
 
+   /* PVH note: xen will free existing kmalloc'd mfn in
+* XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
+* kmalloc(). */
+   

Re: [RFC] ACPI S3 and Xen (suprisingly small\!).

[Ben Guthro]

ack.
I'm happy to test a 2nd round, if you CC me on any fixed patches (just
in case I'm not monitoring lkml / xen-devel on that particular day)

On Fri, Oct 19, 2012 at 2:49 PM, Konrad Rzeszutek Wilk
 wrote:
> On Wed, Oct 17, 2012 at 02:00:29PM -0400, Ben Guthro wrote:
>> I'm not sure it matters, but I'm testing against a changeset about a week 
>> old:
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=1c4a5b37b55c56e49135e65728137f54288d1fe6
>
> I was able to reproduce it with Xen 4.2 so found the culprit.
>
> .. And then another issue :-(
>
>>
>> Plus patches specific to XenClient Enterprise.
>>
>>
>> On Wed, Oct 17, 2012 at 1:43 PM, Konrad Rzeszutek Wilk
>>  wrote:
>> > On Wed, Oct 17, 2012 at 01:46:09PM -0400, Ben Guthro wrote:
>> >> On Wed, Oct 17, 2012 at 9:49 AM, Konrad Rzeszutek Wilk
>> >>  wrote:
>> >> [...]
>> >>
>> >> > The end result is this is a nice set of patches where there is only
>> >> > _one_ change in the x86 code (and it is just more of dealing with
>> >> > error case) - and the rest are all done in Xen side.
>> >>
>> >> I'm sorry to report that this series doesn't seem to work in my setup
>> >> against xen-unstable.
>> >>
>> >> To verify that it was, in fact this patch series, and not another Xen
>> >> regression - I swapped out the kernel with this patch series, with an
>> >> identical one, replacing only this series with your acpi-s3.v9 branch
>> >> - and everything worked fine.
>> >
>> > Thanks for testing it!
>> >
>> > I had tested it with Xen 4.1.3, which could be doing something different.
>> > Will see what is up.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: question on NUMA page migration

[Ingo Molnar]

* Rik van Riel  wrote:

> On 10/19/2012 01:53 PM, Peter Zijlstra wrote:
> >On Fri, 2012-10-19 at 13:13 -0400, Rik van Riel wrote:
> 
> >>Another alternative might be to do the put_page inside
> >>do_prot_none_numa().  That would be analogous to do_wp_page
> >>disposing of the old page for the caller.
> >
> >It'd have to be inside migrate_misplaced_page(), can't do before
> >isolate_lru_page() or the page might disappear. Doing it after is
> >(obviously) too late.
> 
> Keeping an extra refcount on the page might _still_
> result in it disappearing from the process by some
> other means, in-between you grabbing the refcount
> and invoking migration of the page.
> 
> >>I am not real happy about NUMA migration introducing its own
> >>migration mode...
> >
> >You didn't seem to mind too much earlier, but I can remove it if you
> >want.
> 
> Could have been reviewing fatigue :)

:-)

> And yes, it would have been nice to not have a special
> migration mode for sched/numa.
> 
> Speaking of, when do you guys plan to submit a (cleaned up)
> version of the sched/numa patch series for review on lkml?

Which commit(s) worry you specifically?

Thanks,

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

[tip:numa/core] sched: Fix !CONFIG_SCHED_NUMA account_numa_enqueue () variant

[tip-bot for Ingo Molnar]

Commit-ID:  9744d7978477bddc141284876b6544f3d8f7dbd8
Gitweb: http://git.kernel.org/tip/9744d7978477bddc141284876b6544f3d8f7dbd8
Author: Ingo Molnar 
AuthorDate: Sat, 20 Oct 2012 02:22:53 +0200
Committer:  Ingo Molnar 
CommitDate: Sat, 20 Oct 2012 03:12:17 +0200

sched: Fix !CONFIG_SCHED_NUMA account_numa_enqueue() variant

This build warning:

  kernel/sched/fair.c:1015:1: warning: no return statement in function 
returning non-void

Triggers because the dummy account_numa_enqueue() should return the
rq's task list.

It's not possible to trigger this bug runtime, nevertheless fix the
warning.

Signed-off-by: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Link: http://lkml.kernel.org/n/tip-qauskijfwddwtkf5pivzh...@git.kernel.org
---
 kernel/sched/fair.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index e93032d..a66a1b6 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -967,6 +967,7 @@ void task_tick_numa(struct rq *rq, struct task_struct *curr)
 #else
 static struct list_head *account_numa_enqueue(struct rq *rq, struct 
task_struct *p)
 {
+   return NULL;
 }
 
 static void account_numa_dequeue(struct rq *rq, struct task_struct *p)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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:numa/core] sched: Fix !CONFIG_SCHED_NUMA account_numa_enqueue () variant

[tip-bot for Ingo Molnar]

Commit-ID:  aacc9ac4dc832613f12e4022f4a51f5d0d5136a7
Gitweb: http://git.kernel.org/tip/aacc9ac4dc832613f12e4022f4a51f5d0d5136a7
Author: Ingo Molnar 
AuthorDate: Sat, 20 Oct 2012 02:22:53 +0200
Committer:  Ingo Molnar 
CommitDate: Sat, 20 Oct 2012 02:22:53 +0200

sched: Fix !CONFIG_SCHED_NUMA account_numa_enqueue() variant

This build warning:

  kernel/sched/fair.c:1015:1: warning: no return statement in function 
returning non-void

Triggers because the dummy account_numa_enqueue() should return the
rq's task list.

It's not possible to trigger this bug runtime, nevertheless fix the
warning.

Signed-off-by: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Link: http://lkml.kernel.org/n/tip-qauskijfwddwtkf5pivzh...@git.kernel.org
---
 kernel/sched/fair.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index e93032d..05d568f 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -967,6 +967,7 @@ void task_tick_numa(struct rq *rq, struct task_struct *curr)
 #else
 static struct list_head *account_numa_enqueue(struct rq *rq, struct 
task_struct *p)
 {
+   return >cfs_tasks;
 }
 
 static void account_numa_dequeue(struct rq *rq, struct task_struct *p)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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:numa/core] MIPS/thp: Add pmd_pgprot() implementation

[tip-bot for Ralf Baechle]

Commit-ID:  8cd7680d8b7241941fd51d83302677d58b447223
Gitweb: http://git.kernel.org/tip/8cd7680d8b7241941fd51d83302677d58b447223
Author: Ralf Baechle 
AuthorDate: Thu, 18 Oct 2012 16:51:01 +0200
Committer:  Ingo Molnar 
CommitDate: Fri, 19 Oct 2012 23:46:11 +0200

MIPS/thp: Add pmd_pgprot() implementation

Resolve the semantic conflict between the new THP code
on MIPS and the new NUMA code, in linux-next, by adding
the pmd_pgprot() method needed by the NUMA code.

Reported-by: Stephen Rothwell 
Signed-off-by: Ralf Baechle 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20121018145101.ga17...@linux-mips.org
Signed-off-by: Ingo Molnar 
---
 arch/mips/include/asm/pgtable.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/mips/include/asm/pgtable.h b/arch/mips/include/asm/pgtable.h
index c02158b..bbe4cda 100644
--- a/arch/mips/include/asm/pgtable.h
+++ b/arch/mips/include/asm/pgtable.h
@@ -89,6 +89,8 @@ static inline int is_zero_pfn(unsigned long pfn)
 
 extern void paging_init(void);
 
+#define pmd_pgprot(x)  __pgprot(pmd_val(x) & ~_PAGE_CHG_MASK)
+
 /*
  * Conversion functions: convert a page and protection to a page entry,
  * and a page entry and page directory to the page they refer to.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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:numa/core] s390/thp: implement pmd_pgprot() for s390

[tip-bot for Gerald Schaefer]

Commit-ID:  ca6cfbe6d25cdf9ed81cbf26c2146eda17a70472
Gitweb: http://git.kernel.org/tip/ca6cfbe6d25cdf9ed81cbf26c2146eda17a70472
Author: Gerald Schaefer 
AuthorDate: Thu, 18 Oct 2012 18:26:42 +0200
Committer:  Ingo Molnar 
CommitDate: Fri, 19 Oct 2012 23:38:48 +0200

s390/thp: implement pmd_pgprot() for s390

Git commit "mm/thp: Preserve pgprot across huge page split"
introduced a pmd_pgprot() function, which is missing
on s390, resulting in a compile error in linux-next where
THP is enabled on s390 as well.

This patch adds an implementation of pmd_pgprot() for s390.

Reported-by: Stephen Rothwell 
Signed-off-by: Gerald Schaefer 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Peter Zijlstra 
Cc: Ralf Baechle 
Link: http://lkml.kernel.org/r/20121018182642.2a541275@thinkpad
Signed-off-by: Ingo Molnar 
---
 arch/s390/include/asm/pgtable.h |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
index dd647c9..098fc5a 100644
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -1240,6 +1240,19 @@ static inline void set_pmd_at(struct mm_struct *mm, 
unsigned long addr,
*pmdp = entry;
 }
 
+static inline pgprot_t pmd_pgprot(pmd_t pmd)
+{
+   pgprot_t prot = PAGE_RW;
+
+   if (pmd_val(pmd) & _SEGMENT_ENTRY_RO) {
+   if (pmd_val(pmd) & _SEGMENT_ENTRY_INV)
+   prot = PAGE_NONE;
+   else
+   prot = PAGE_RO;
+   }
+   return prot;
+}
+
 static inline unsigned long massage_pgprot_pmd(pgprot_t pgprot)
 {
unsigned long pgprot_pmd = 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:perf/urgent] tools lib traceevent: Fix missed freeing of subargs in free_arg() in filter

[tip-bot for Steven Rostedt]

Commit-ID:  743df75ff10630f1f2a461f0f4b51f601f53ec44
Gitweb: http://git.kernel.org/tip/743df75ff10630f1f2a461f0f4b51f601f53ec44
Author: Steven Rostedt 
AuthorDate: Mon, 1 Oct 2012 20:23:28 -0400
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 16 Oct 2012 13:07:05 -0300

tools lib traceevent: Fix missed freeing of subargs in free_arg() in filter

Some of args were missed in free_args(), as well as subargs.

That is args like FILTER_ARG_NUM have left and right pointers to other
args that also need to be freed.

Signed-off-by: Steven Rostedt 
Cc: Ingo Molnar 
Cc: Namhyung Kim 
Link: http://lkml.kernel.org/r/1349137408.22822.135.ca...@gandalf.local.home
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/lib/traceevent/parse-filter.c |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/tools/lib/traceevent/parse-filter.c 
b/tools/lib/traceevent/parse-filter.c
index ad17855..5ea4326 100644
--- a/tools/lib/traceevent/parse-filter.c
+++ b/tools/lib/traceevent/parse-filter.c
@@ -209,7 +209,16 @@ static void free_arg(struct filter_arg *arg)
switch (arg->type) {
case FILTER_ARG_NONE:
case FILTER_ARG_BOOLEAN:
+   break;
+
case FILTER_ARG_NUM:
+   free_arg(arg->num.left);
+   free_arg(arg->num.right);
+   break;
+
+   case FILTER_ARG_EXP:
+   free_arg(arg->exp.left);
+   free_arg(arg->exp.right);
break;
 
case FILTER_ARG_STR:
@@ -218,6 +227,12 @@ static void free_arg(struct filter_arg *arg)
free(arg->str.buffer);
break;
 
+   case FILTER_ARG_VALUE:
+   if (arg->value.type == FILTER_STRING ||
+   arg->value.type == FILTER_CHAR)
+   free(arg->value.str);
+   break;
+
case FILTER_ARG_OP:
free_arg(arg->op.left);
free_arg(arg->op.right);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/urgent] lib tools traceevent: Add back pevent assignment in __pevent_parse_format()

[tip-bot for Steven Rostedt]

Commit-ID:  101782ea2c6984cf169631c59df76b8497899caf
Gitweb: http://git.kernel.org/tip/101782ea2c6984cf169631c59df76b8497899caf
Author: Steven Rostedt 
AuthorDate: Mon, 1 Oct 2012 20:13:51 -0400
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 16 Oct 2012 13:06:36 -0300

lib tools traceevent: Add back pevent assignment in __pevent_parse_format()

Even though with the change of commit commit 2b29175 "tools lib
traceevent: Carve out events format parsing routine", allowed
__pevent_parse_format() to parse an event without the need of a pevent
handler, the event still needs to assign the pevent handed to it.

There's no problem with assigning it if the pevent is NULL, as the
event->pevent would be NULL without the assignment. But function parsing
handlers may be assigned to the pevent handler to help in parsing the
event. If there's no pevent then there would not be any function
handlers, but if the pevent isn't assigned first before parsing the
event, it wont honor the function handlers that were assigned.

Worse yet, the current code crashes if an event has a function that it
tries to parse. For example:

 # perf record -e scsi:scsi_dispatch_cmd_timeout
 Segmentation fault (core dumped)

This happens because the scsi_dispatch_cmd_timeout event format has the 
following:

  scsi_trace_parse_cdb(p, __get_dynamic_array(cmnd), REC->cmd_len)

which hasn't been defined by the pevent code.

Signed-off-by: Steven Rostedt 
Reviewed-by: Namhyung Kim 
Cc: Ingo Molnar 
Cc: Namhyung Kim 
Link: http://lkml.kernel.org/r/1349136831.22822.133.ca...@gandalf.local.home
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/lib/traceevent/event-parse.c |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/tools/lib/traceevent/event-parse.c 
b/tools/lib/traceevent/event-parse.c
index 47264b4..f2989c5 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -2602,6 +2602,9 @@ find_func_handler(struct pevent *pevent, char *func_name)
 {
struct pevent_function_handler *func;
 
+   if (!pevent)
+   return NULL;
+
for (func = pevent->func_handlers; func; func = func->next) {
if (strcmp(func->name, func_name) == 0)
break;
@@ -4938,6 +4941,9 @@ enum pevent_errno __pevent_parse_format(struct 
event_format **eventp,
goto event_alloc_failed;
}
 
+   /* Add pevent to event so that it can be referenced */
+   event->pevent = pevent;
+
ret = event_read_format(event);
if (ret < 0) {
ret = PEVENT_ERRNO__READ_FORMAT_FAILED;
@@ -5041,9 +5047,6 @@ enum pevent_errno pevent_parse_event(struct pevent 
*pevent, const char *buf,
if (event == NULL)
return ret;
 
-   /* Add pevent to event so that it can be referenced */
-   event->pevent = pevent;
-
if (add_event(pevent, event)) {
ret = PEVENT_ERRNO__MEM_ALLOC_FAILED;
goto event_add_failed;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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:perf/urgent] perf hists browser: Fix off-by-two bug on the first column

[tip-bot for Namhyung Kim]

Commit-ID:  63a1a3d820c619a4dab1781cc16c110a284efded
Gitweb: http://git.kernel.org/tip/63a1a3d820c619a4dab1781cc16c110a284efded
Author: Namhyung Kim 
AuthorDate: Mon, 15 Oct 2012 18:14:35 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 16 Oct 2012 13:06:05 -0300

perf hists browser: Fix off-by-two bug on the first column

The commit 5395a04841fc ("perf hists: Separate overhead and baseline
columns") makes the "Overhead" column no more the first one.  So it
resulted in the mis-aligned column in the normal (non-diff) output.

Signed-off-by: Namhyung Kim 
Reported-by: Markus Trippelsdorf 
Acked-by: Jiri Olsa 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/None
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/ui/browsers/hists.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 0568536..fe4430a 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -610,6 +610,7 @@ static int hist_browser__show_entry(struct hist_browser 
*browser,
char folded_sign = ' ';
bool current_entry = ui_browser__is_current_entry(>b, row);
off_t row_offset = entry->row_offset;
+   bool first = true;
 
if (current_entry) {
browser->he_selection = entry;
@@ -633,10 +634,11 @@ static int hist_browser__show_entry(struct hist_browser 
*browser,
if (!perf_hpp__format[i].cond)
continue;
 
-   if (i) {
+   if (!first) {
slsmg_printf("  ");
width -= 2;
}
+   first = false;
 
if (perf_hpp__format[i].color) {
hpp.ptr = 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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:perf/urgent] perf tools: Remove warnings on JIT samples for srcline sort key

[tip-bot for Namhyung Kim]

Commit-ID:  88481b6b33d6cb5edb57e5794abae4daeabd08c5
Gitweb: http://git.kernel.org/tip/88481b6b33d6cb5edb57e5794abae4daeabd08c5
Author: Namhyung Kim 
AuthorDate: Mon, 15 Oct 2012 12:39:43 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 16 Oct 2012 13:05:38 -0300

perf tools: Remove warnings on JIT samples for srcline sort key

When using the srcline sort key with perf report, I see many lines of
warning related to JIT samples like below:

  addr2line: '/tmp/perf-1397.map': No such file

Since it's not a ELF binary and doesn't provide such information, just
use the raw ip address.

Signed-off-by: Namhyung Kim 
Cc: David Ahern 
Cc: Ingo Molnar 
Cc: Irina Tirdea 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1350272383-7016-2-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/sort.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index dd68f11..cfd1c0f 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -263,6 +263,9 @@ static int hist_entry__srcline_snprintf(struct hist_entry 
*self, char *bf,
if (!self->ms.map)
goto out_ip;
 
+   if (!strncmp(self->ms.map->dso->long_name, "/tmp/perf-", 10))
+   goto out_ip;
+
snprintf(cmd, sizeof(cmd), "addr2line -e %s %016" PRIx64,
 self->ms.map->dso->long_name, self->ip);
fp = popen(cmd, "r");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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:perf/urgent] perf tools: Fix segfault when using srcline sort key

[tip-bot for Namhyung Kim]

Commit-ID:  ffe10c6f95412da01695e659e967747333d5e812
Gitweb: http://git.kernel.org/tip/ffe10c6f95412da01695e659e967747333d5e812
Author: Namhyung Kim 
AuthorDate: Mon, 15 Oct 2012 12:39:42 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 16 Oct 2012 13:05:07 -0300

perf tools: Fix segfault when using srcline sort key

The srcline sort key is for grouping samples based on their source file
and line number.  It use addr2line tool to get the information but it
requires dso name.  It caused a segfault when a sample does not have the
name by dereferencing a NULL pointer.  Fix it by using raw ip addresses
for those samples.

Signed-off-by: Namhyung Kim 
Cc: Ingo Molnar 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1350272383-7016-1-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/sort.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index b5b1b92..dd68f11 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -260,6 +260,9 @@ static int hist_entry__srcline_snprintf(struct hist_entry 
*self, char *bf,
if (path != NULL)
goto out_path;
 
+   if (!self->ms.map)
+   goto out_ip;
+
snprintf(cmd, sizeof(cmd), "addr2line -e %s %016" PRIx64,
 self->ms.map->dso->long_name, self->ip);
fp = popen(cmd, "r");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] perf fixes

[Ingo Molnar]

Linus,

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

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

   HEAD: 45bff41a9a6f22af28e4ba22f83c87f619e573a8 perf python: Properly link 
with libtraceevent

Assorted small fixes.

 Thanks,

Ingo

-->
Arnaldo Carvalho de Melo (4):
  perf python: Initialize 'page_size' variable
  perf python: Link with libtraceevent
  perf hists browser: Add back callchain folding symbol
  perf python: Properly link with libtraceevent

David Ahern (1):
  perf tool: Precise mode requires exclude_guest

David Miller (1):
  perf tools: Fix build on sparc.

Namhyung Kim (3):
  perf tools: Fix segfault when using srcline sort key
  perf tools: Remove warnings on JIT samples for srcline sort key
  perf hists browser: Fix off-by-two bug on the first column

Peter Zijlstra (1):
  perf: Require exclude_guest to use PEBS - kernel side enforcement

Steven Rostedt (2):
  lib tools traceevent: Add back pevent assignment in 
__pevent_parse_format()
  tools lib traceevent: Fix missed freeing of subargs in free_arg() in 
filter


 arch/x86/kernel/cpu/perf_event.c|  6 ++
 tools/lib/traceevent/event-parse.c  |  9 ++---
 tools/lib/traceevent/parse-filter.c | 15 +++
 tools/perf/Makefile | 24 +---
 tools/perf/perf.h   |  2 +-
 tools/perf/ui/browsers/hists.c  |  6 --
 tools/perf/util/parse-events.c  |  3 +++
 tools/perf/util/setup.py|  2 ++
 tools/perf/util/sort.c  |  6 ++
 9 files changed, 56 insertions(+), 17 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 915b876..3373f84 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -338,6 +338,9 @@ int x86_setup_perfctr(struct perf_event *event)
/* BTS is currently only allowed for user-mode. */
if (!attr->exclude_kernel)
return -EOPNOTSUPP;
+
+   if (!attr->exclude_guest)
+   return -EOPNOTSUPP;
}
 
hwc->config |= config;
@@ -380,6 +383,9 @@ int x86_pmu_hw_config(struct perf_event *event)
if (event->attr.precise_ip) {
int precise = 0;
 
+   if (!event->attr.exclude_guest)
+   return -EOPNOTSUPP;
+
/* Support for constant skid */
if (x86_pmu.pebs_active && !x86_pmu.pebs_broken) {
precise++;
diff --git a/tools/lib/traceevent/event-parse.c 
b/tools/lib/traceevent/event-parse.c
index 47264b4..f2989c5 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -2602,6 +2602,9 @@ find_func_handler(struct pevent *pevent, char *func_name)
 {
struct pevent_function_handler *func;
 
+   if (!pevent)
+   return NULL;
+
for (func = pevent->func_handlers; func; func = func->next) {
if (strcmp(func->name, func_name) == 0)
break;
@@ -4938,6 +4941,9 @@ enum pevent_errno __pevent_parse_format(struct 
event_format **eventp,
goto event_alloc_failed;
}
 
+   /* Add pevent to event so that it can be referenced */
+   event->pevent = pevent;
+
ret = event_read_format(event);
if (ret < 0) {
ret = PEVENT_ERRNO__READ_FORMAT_FAILED;
@@ -5041,9 +5047,6 @@ enum pevent_errno pevent_parse_event(struct pevent 
*pevent, const char *buf,
if (event == NULL)
return ret;
 
-   /* Add pevent to event so that it can be referenced */
-   event->pevent = pevent;
-
if (add_event(pevent, event)) {
ret = PEVENT_ERRNO__MEM_ALLOC_FAILED;
goto event_add_failed;
diff --git a/tools/lib/traceevent/parse-filter.c 
b/tools/lib/traceevent/parse-filter.c
index ad17855..5ea4326 100644
--- a/tools/lib/traceevent/parse-filter.c
+++ b/tools/lib/traceevent/parse-filter.c
@@ -209,7 +209,16 @@ static void free_arg(struct filter_arg *arg)
switch (arg->type) {
case FILTER_ARG_NONE:
case FILTER_ARG_BOOLEAN:
+   break;
+
case FILTER_ARG_NUM:
+   free_arg(arg->num.left);
+   free_arg(arg->num.right);
+   break;
+
+   case FILTER_ARG_EXP:
+   free_arg(arg->exp.left);
+   free_arg(arg->exp.right);
break;
 
case FILTER_ARG_STR:
@@ -218,6 +227,12 @@ static void free_arg(struct filter_arg *arg)
free(arg->str.buffer);
break;
 
+   case FILTER_ARG_VALUE:
+   if (arg->value.type == FILTER_STRING ||
+   arg->value.type == FILTER_CHAR)
+   free(arg->value.str);
+   break;
+
case FILTER_ARG_OP:

[tip:perf/urgent] perf: Require exclude_guest to use PEBS - kernel side enforcement

[tip-bot for Peter Zijlstra]

Commit-ID:  20b279ddb38ca42f8863cec07b4d45ec24589f13
Gitweb: http://git.kernel.org/tip/20b279ddb38ca42f8863cec07b4d45ec24589f13
Author: Peter Zijlstra 
AuthorDate: Thu, 13 Sep 2012 14:59:14 -0600
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 16 Oct 2012 12:43:58 -0300

perf: Require exclude_guest to use PEBS - kernel side enforcement

Intel PEBS in VT-x context uses the DS address as a guest linear
address, even though its programmed by the host as a host linear
address. This either results in guest memory corruption and or the
hardware faulting and 'crashing' the virtual machine.  Therefore we have
to disable PEBS on VT-x enter and re-enable on VT-x exit, enforcing a
strict exclude_guest.

This patch enforces exclude_guest kernel side.

Signed-off-by: Peter Zijlstra 
Cc: Avi Kivity 
Cc: David Ahern 
Cc: Gleb Natapov 
Cc: Ingo Molnar 
Cc: Robert Richter 
Link: 
http://lkml.kernel.org/r/1347569955-54626-3-git-send-email-dsah...@gmail.com
Signed-off-by: David Ahern 
Signed-off-by: Arnaldo Carvalho de Melo 
---
 arch/x86/kernel/cpu/perf_event.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 915b876..3373f84 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -338,6 +338,9 @@ int x86_setup_perfctr(struct perf_event *event)
/* BTS is currently only allowed for user-mode. */
if (!attr->exclude_kernel)
return -EOPNOTSUPP;
+
+   if (!attr->exclude_guest)
+   return -EOPNOTSUPP;
}
 
hwc->config |= config;
@@ -380,6 +383,9 @@ int x86_pmu_hw_config(struct perf_event *event)
if (event->attr.precise_ip) {
int precise = 0;
 
+   if (!event->attr.exclude_guest)
+   return -EOPNOTSUPP;
+
/* Support for constant skid */
if (x86_pmu.pebs_active && !x86_pmu.pebs_broken) {
precise++;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] acpi,memory-hotplug : implement framework for hot removing memory

[Wen Congyang]

At 10/20/2012 12:32 AM, Rafael J. Wysocki Wrote:
> On Friday 19 of October 2012 18:03:57 we...@cn.fujitsu.com wrote:
>> From: Wen Congyang 
>>
>> The patch-set implements a framework for hot removing memory.
>>
>> The memory device can be removed by 2 ways:
>> 1. send eject request by SCI
>> 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
>>
>> In the 1st case, acpi_memory_disable_device() will be called.
>> In the 2nd case, acpi_memory_device_remove() will be called.
>> acpi_memory_device_remove() will also be called when we unbind the
>> memory device from the driver acpi_memhotplug or a driver initialization
>> fails.
>>
>> acpi_memory_disable_device() has already implemented a code which
>> offlines memory and releases acpi_memory_info struct . But
>> acpi_memory_device_remove() has not implemented it yet.
>>
>> So the patch prepares the framework for hot removing memory and
>> adds the framework into acpi_memory_device_remove().
>>
>> The last version of this patchset is here:
>> https://lkml.org/lkml/2012/10/3/126
>>
>> Changelos from v1 to v2:
>>   Patch1: use acpi_bus_trim() instead of acpi_bus_remove()
>>   Patch2: new patch, introduce a lock to protect the list
>>   Patch3: remove memory too when type is ACPI_BUS_REMOVAL_NORMAL
>>   Note: I don't send [Patch2-4 v1] in this series because they
>>   are no logical changes in these 3 patches.
>>
>> Wen Congyang (2):
>>   acpi,memory-hotplug: call acpi_bus_trim() to remove memory device
>>   acpi,memory-hotplug: introduce a mutex lock to protect the list in
>> acpi_memory_device
>>
>> Yasuaki Ishimatsu (1):
>>   acpi,memory-hotplug : add memory offline code to
>> acpi_memory_device_remove()
>>
>>  drivers/acpi/acpi_memhotplug.c |   51 
>> 
>>  1 files changed, 41 insertions(+), 10 deletions(-)
>>
>> --
> 
> Can you please tell me what kernel is the series supposed to apply to?
> Is it the current Linus' tree, or linux-next, or something else?

Current Linux's tree.

Thanks
Wen Congyang

> 
> Thanks,
> Rafael
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: x2apic boot failure on recent sandy bridge system

[Yinghai Lu]

On Fri, Oct 19, 2012 at 5:02 PM, Suresh Siddha
 wrote:
> On Fri, 2012-10-19 at 16:36 -0700, H. Peter Anvin wrote:
>> On 10/19/2012 04:32 PM, Yinghai Lu wrote:
>> > On Fri, Oct 19, 2012 at 4:03 PM, Suresh Siddha
>> >  wrote:
>> >> On Fri, 2012-10-19 at 13:42 -0700, rrl...@gmail.com wrote:
>> >>> Any update? The messages just seem to have stopped months ago. A
>> >>> fallback would be nice, I have been booting the kernel with noa2xpic
>> >>> for since kernel 3.2, and currently I am working with 3.6.2.
>> >>>
>> >>> If needed I can try to attempt modifying the patch to include
>> >>> fallback, but I am probably not the best person to do it.
>> >>>
>> >>
>> >> Are you referring to this commit that made into the mainline tree
>> >> already?
>> >>
>> >> commit fb209bd891645bb87b9618b724f0b4928e0df3de
>> >> Author: Yinghai Lu 
>> >> Date:   Wed Dec 21 17:45:17 2011 -0800
>> >>
>> >>  x86, x2apic: Fallback to xapic when BIOS doesn't setup 
>> >> interrupt-remapping
>> >
>> > I think his system has DMAR table and cpu support x2apic, So kernel
>> > will switch to x2apic,
>> >
>> > but somehow BIOS SMI handler has problem with x2apic. should be thinkpad 
>> > W520?
>> >
>>
>> Right, StinkPad W520 needs a quirk.
>
> yes. Yinghai, if you remember you had a T420 that didn't show the
> problem. And someone in the bugzilla with T420 had the problem. And
> their dmidecode is
> https://launchpadlibrarian.net/109393850/dmidecode.txt
>
> What is the difference with your system? Bios I think is the same.

1.37 was working too, i updated it to 1.39 and it is still working.

>
> Can you see what we should check for in the dmi tables to black list
> these systems? Can you post your T420's dmidecode to see the difference.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=43054

post dmesg and dmidecode to that bug report.

Thanks

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 09/11] perf python: Link with libtraceevent

[Ingo Molnar]

* Namhyung Kim  wrote:

> 2012-10-18 (???), 11:38 -0300, Arnaldo Carvalho de Melo:
> > Em Thu, Oct 18, 2012 at 11:00:33AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Thu, Oct 18, 2012 at 10:38:18AM +0900, Namhyung Kim escreveu:
> > > > On Wed, 17 Oct 2012 14:19:45 -0300, Arnaldo Carvalho de Melo wrote:
> > > > I got a build error after adding 'extern unsigned int page_size' to
> > > > util/python.c - please see my previous reply.
> > > > 
> > > >   namhyung@sejong:perf$ make
> > > >   SUBDIR ../lib/traceevent/
> > > >   LINK perf
> > > >   GEN python/perf.so
> > > >   gcc: error: python_ext_build/tmp//../../libtraceevent.a: No such file 
> > > > or directory
> > > >   error: command 'gcc' failed with exit status 1
> > > >   cp: cannot stat `python_ext_build/lib/perf.so': No such file or 
> > > > directory
> > > >   make: *** [python/perf.so] Error 1
> > > >   TRACE_EVENT_DIR = ../lib/traceevent/
> >
> > > >   ifneq ($(OUTPUT),)
> > > > TE_PATH=$(OUTPUT)
> > > >   else
> > > > TE_PATH=$(TRACE_EVENT_DIR)
> > > >   endif
> > > >   
> > > >   LIBTRACEEVENT = $(TE_PATH)libtraceevent.a
> > > 
> > > I see, so we need to somehow propagate this TE_PATH variable to the 
> > > setup.py file...
> > 
> > Can you try with the attached patch? I tested it here and works with:
> > 
> >  make -C tools/perf
> > 
> > and with O=
> 
> It works well for me too:
> 
> Tested-by: Namhyung Kim 

Even with that I'm getting:

util/python.c: In function ???initperf???:
util/python.c:1018:2: error: ???page_size??? undeclared 
(first use in this function)
util/python.c:1018:2: note: each undeclared identifier is 
reported only once for each function it appears in
error: command 'gcc' failed with exit status 1

Thanks,

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

[PATCH] MODSIGN: Move the magic string to the end of a module and eliminate the search

[David Howells]

Emit the magic string that indicates a module has a signature after the
signature data instead of before it.  This allows module_sig_check() to be
made simpler and faster by the elimination of the search for the magic string.
Instead we just need to do a single memcmp().

This works because at the end of the signature data there is the fixed-length
signature information block.  This block then falls immediately prior to the
magic number.

>From the contents of the information block, it is trivial to calculate the size
of the signature data and thus the size of the actual module data.

Signed-off-by: David Howells 
---

 kernel/module-internal.h |3 +--
 kernel/module.c  |   26 +-
 kernel/module_signing.c  |   24 +++-
 scripts/sign-file|6 +++---
 4 files changed, 28 insertions(+), 31 deletions(-)


diff --git a/kernel/module-internal.h b/kernel/module-internal.h
index 6114a13..24f9247 100644
--- a/kernel/module-internal.h
+++ b/kernel/module-internal.h
@@ -11,5 +11,4 @@
 
 extern struct key *modsign_keyring;
 
-extern int mod_verify_sig(const void *mod, unsigned long modlen,
- const void *sig, unsigned long siglen);
+extern int mod_verify_sig(const void *mod, unsigned long *_modlen);
diff --git a/kernel/module.c b/kernel/module.c
index 0e2da86..6085f5e 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2421,25 +2421,17 @@ static inline void kmemleak_load_module(const struct 
module *mod,
 
 #ifdef CONFIG_MODULE_SIG
 static int module_sig_check(struct load_info *info,
-   const void *mod, unsigned long *len)
+   const void *mod, unsigned long *_len)
 {
int err = -ENOKEY;
-   const unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
-   const void *p = mod, *end = mod + *len;
-
-   /* Poor man's memmem. */
-   while ((p = memchr(p, MODULE_SIG_STRING[0], end - p))) {
-   if (p + markerlen > end)
-   break;
-
-   if (memcmp(p, MODULE_SIG_STRING, markerlen) == 0) {
-   const void *sig = p + markerlen;
-   /* Truncate module up to signature. */
-   *len = p - mod;
-   err = mod_verify_sig(mod, *len, sig, end - sig);
-   break;
-   }
-   p++;
+   unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
+   unsigned long len = *_len;
+
+   if (len > markerlen &&
+   memcmp(mod + len - markerlen, MODULE_SIG_STRING, markerlen) == 0) {
+   /* We truncate the module to discard the signature */
+   *_len -= markerlen;
+   err = mod_verify_sig(mod, _len);
}
 
if (!err) {
diff --git a/kernel/module_signing.c b/kernel/module_signing.c
index 6b09f69..d492a23 100644
--- a/kernel/module_signing.c
+++ b/kernel/module_signing.c
@@ -183,27 +183,33 @@ static struct key *request_asymmetric_key(const char 
*signer, size_t signer_len,
 /*
  * Verify the signature on a module.
  */
-int mod_verify_sig(const void *mod, unsigned long modlen,
-  const void *sig, unsigned long siglen)
+int mod_verify_sig(const void *mod, unsigned long *_modlen)
 {
struct public_key_signature *pks;
struct module_signature ms;
struct key *key;
-   size_t sig_len;
+   const void *sig;
+   size_t modlen = *_modlen, sig_len;
int ret;
 
-   pr_devel("==>%s(,%lu,,%lu,)\n", __func__, modlen, siglen);
+   pr_devel("==>%s(,%lu)\n", __func__, modlen);
 
-   if (siglen <= sizeof(ms))
+   if (modlen <= sizeof(ms))
return -EBADMSG;
 
-   memcpy(, sig + (siglen - sizeof(ms)), sizeof(ms));
-   siglen -= sizeof(ms);
+   memcpy(, mod + (modlen - sizeof(ms)), sizeof(ms));
+   modlen -= sizeof(ms);
 
sig_len = be32_to_cpu(ms.sig_len);
-   if (sig_len >= siglen ||
-   siglen - sig_len != (size_t)ms.signer_len + ms.key_id_len)
+   if (sig_len >= modlen)
return -EBADMSG;
+   modlen -= sig_len;
+   if ((size_t)ms.signer_len + ms.key_id_len >= modlen)
+   return -EBADMSG;
+   modlen -= (size_t)ms.signer_len + ms.key_id_len;
+
+   *_modlen = modlen;
+   sig = mod + modlen;
 
/* For the moment, only support RSA and X.509 identifiers */
if (ms.algo != PKEY_ALGO_RSA ||
diff --git a/scripts/sign-file b/scripts/sign-file
index d37d130..87ca59d 100755
--- a/scripts/sign-file
+++ b/scripts/sign-file
@@ -403,11 +403,11 @@ my $info = pack("CxxxN",
 
 if ($verbose) {
 print "Size of unsigned module: ", length($unsigned_module), "\n";
-print "Size of magic number   : ", length($magic_number), "\n";
 print "Size of signer's name  : ", length($signers_name), "\n";
 print "Size of key identifier : ", length($key_identifier), "\n";
 print "Size of signature  : ", 

Re: [PATCH V2 01/10] Secure boot: Add new capability

[joeyli]

Hi Matt, 

Sorry for bother you!

I didn't see this Matthew's patchset merged in EFI git tree. Do you have
plan to merge it? Or those patches need wait different subsystem leaders
merge.


Thanks a lot!
Joey Lee

於 四，2012-09-20 於 10:40 -0400，Matthew Garrett 提到：
> Secure boot adds certain policy requirements, including that root must not
> be able to do anything that could cause the kernel to execute arbitrary code.
> The simplest way to handle this would seem to be to add a new capability
> and gate various functionality on that. We'll then strip it from the initial
> capability set if required.
> 
> Signed-off-by: Matthew Garrett 
> ---
>  include/linux/capability.h | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/capability.h b/include/linux/capability.h
> index d10b7ed..4345bc8 100644
> --- a/include/linux/capability.h
> +++ b/include/linux/capability.h
> @@ -364,7 +364,11 @@ struct cpu_vfs_cap_data {
>  
>  #define CAP_BLOCK_SUSPEND36
>  
> -#define CAP_LAST_CAP CAP_BLOCK_SUSPEND
> +/* Allow things that trivially permit root to modify the running kernel */
> +
> +#define CAP_COMPROMISE_KERNEL  37
> +
> +#define CAP_LAST_CAP CAP_COMPROMISE_KERNEL
>  
>  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>  


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

[GIT PULL] ARM: soc fixes for -rc2

[Olof Johansson]

Hi Linus,

The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:

  Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git 
tags/fixes-for-linus

for you to fetch changes up to 70f3900ee5c78d498dbbf880ec409f4b8f4da21e:

  Merge tag 'kirkwood_fixes_for_v3.7' of 
git://git.infradead.org/users/jcooper/linux into fixes (2012-10-19 16:17:51 
-0700)



ARM: soc: Fixes for 3.7-rc2

A set of fixes and some minor cleanups for -rc2:

- A series from Arnd that fixes warnings in drivers and other code
  included by ARM defconfigs. Most have been acked by corresponding
  maintainers (and seem quite hard to argue not picking up anyway in the
  few exception cases).
- A few misc patches from the list for integrator/vt8500/i.MX
- A batch of fixes to OMAP platforms, fixing:
  - boot problems on beaglebone,
  - regression fixes for local timers
  - clockdomain locking fixes
  - a few boot/sparse warnings
- For Tegra:
  - Clock rate calculation overflow fix
  - Revert a change that removed timer clocks and a fix for symbol name clashes
- For Renesas:
  - IO accessor / annotation cleanups to remove warnings
- For Kirkwood/Dove/mvebu:
  - Fixes for device trees for Dove (some minor cleanups, some fixes)
  - Fixes for the mvebu gpio driver
  - Fix build problem for Feroceon due to missing ifdefs
  - Fix lsxl DTS files


Arnd Bergmann (7):
  SCSI: ARM: ncr5380/oak uses no interrupts
  SCSI: ARM: make fas216_dumpinfo function conditional
  mm/slob: use min_t() to compare ARCH_SLAB_MINALIGN
  USB: EHCI: mark ehci_orion_conf_mbus_windows __devinit
  pcmcia: sharpsl: don't discard sharpsl_pcmcia_ops
  spi/s3c64xx: use correct dma_transfer_direction type
  ARM: s3c: mark s3c2440_clk_add as __init_refok

Axel Lin (1):
  gpio: mvebu: Add missing breaks in mvebu_gpio_irq_set_type

Benoit Cousson (1):
  ARM: OMAP2+: clock data: Add dev-id for the omap-gpmc dummy fck

Jason Gunthorpe (1):
  ARM: Kirkwood: fix disabling CACHE_FEROCEON_L2

Jon Hunter (1):
  ARM: OMAP2+: Allow kernel to boot even if GPMC fails to reserve memory

Kuninori Morimoto (2):
  ARM: shmobile: armadillo800eva: __io abuse cleanup
  ARM: shmobile: r8a7779: use __iomem pointers for MMIO

Linus Walleij (1):
  ARM: dts: compile Integrator device trees

Mark Zhang (1):
  ARM: tegra30: clk: Fix output_rate overflow

Michael Walle (2):
  ARM: kirkwood: fix LEDs names for lsxl boards
  ARM: kirkwood: fix buttons on lsxl boards

Olof Johansson (7):
  Merge branch 'fixes' of git://git.kernel.org/.../horms/renesas into fixes
  Merge tag 'tegra-for-3.7-fixes-for-rc2' of 
git://git.kernel.org/.../swarren/linux-tegra into fixes
  Merge tag 'omap-for-v3.7-rc1/fixes-take5-signed' of 
git://git.kernel.org/.../tmlind/linux-omap into fixes
  Merge tag 'mvebu_dove_late_fixes_for_v3.7' of 
git://git.infradead.org/users/jcooper/linux into fixes
  Merge tag 'mvebu_gpio_fixes_for_v3.7' of 
git://git.infradead.org/users/jcooper/linux into fixes
  Merge branch 'testing/driver-warnings' of 
git://git.kernel.org/.../arm/arm-soc into fixes
  Merge tag 'kirkwood_fixes_for_v3.7' of 
git://git.infradead.org/users/jcooper/linux into fixes

Paul Walmsley (1):
  ARM: OMAP: resolve sparse warning concerning debug_card_init()

Sebastian Hesselbarth (6):
  ARM: dove: Add pcie clock support
  ARM: dove: Fix tauros2 device tree init
  ARM: dove: Fix clock names of sata and gbe
  ARM: dove: Restructure SoC device tree descriptor
  ARM: dove: Remove watchdog from DT
  ARM: dove: Add crypto engine to DT

Sebastien Guiriec (1):
  ARM: OMAP4: devices: fixup OMAP4 DMIC platform device error message

Shawn Guo (1):
  ARM: dts: imx6q-arm2: move NANDF_CS pins out of 'hog'

Sivaram Nair (2):
  ARM: tegra: rename tegra system timer
  ARM: tegra: add tegra_timer clock

Tero Kristo (1):
  ARM: OMAP: clockdomain: Fix locking on _clkdm_clk_hwmod_enable / disable

Tony Lindgren (1):
  ARM: OMAP4: Fix twd_local_timer_register regression

Tony Prisk (1):
  dtb: fix interrupt assignment for ehci/uhci on wm8505

 arch/arm/boot/dts/Makefile |  2 ++
 arch/arm/boot/dts/dove.dtsi| 49 +-
 arch/arm/boot/dts/imx6q-arm2.dts   | 10 +-
 arch/arm/boot/dts/kirkwood-lsxl.dtsi   | 18 +-
 arch/arm/boot/dts/wm8505.dtsi  |  4 +--
 arch/arm/mach-dove/common.c|  8 ++---
 arch/arm/mach-dove/pcie.c  |  5 +++
 arch/arm/mach-kirkwood/board-dt.c  |  2 --
 arch/arm/mach-kirkwood/common.c|  4 +--
 arch/arm/mach-omap2/clock44xx_data.c   |  2 +-
 arch/arm/mach-omap2/clockdomain.c  

Re: x2apic boot failure on recent sandy bridge system

[Suresh Siddha]

On Fri, 2012-10-19 at 16:36 -0700, H. Peter Anvin wrote:
> On 10/19/2012 04:32 PM, Yinghai Lu wrote:
> > On Fri, Oct 19, 2012 at 4:03 PM, Suresh Siddha
> >  wrote:
> >> On Fri, 2012-10-19 at 13:42 -0700, rrl...@gmail.com wrote:
> >>> Any update? The messages just seem to have stopped months ago. A
> >>> fallback would be nice, I have been booting the kernel with noa2xpic
> >>> for since kernel 3.2, and currently I am working with 3.6.2.
> >>>
> >>> If needed I can try to attempt modifying the patch to include
> >>> fallback, but I am probably not the best person to do it.
> >>>
> >>
> >> Are you referring to this commit that made into the mainline tree
> >> already?
> >>
> >> commit fb209bd891645bb87b9618b724f0b4928e0df3de
> >> Author: Yinghai Lu 
> >> Date:   Wed Dec 21 17:45:17 2011 -0800
> >>
> >>  x86, x2apic: Fallback to xapic when BIOS doesn't setup 
> >> interrupt-remapping
> >
> > I think his system has DMAR table and cpu support x2apic, So kernel
> > will switch to x2apic,
> >
> > but somehow BIOS SMI handler has problem with x2apic. should be thinkpad 
> > W520?
> >
> 
> Right, StinkPad W520 needs a quirk.

yes. Yinghai, if you remember you had a T420 that didn't show the
problem. And someone in the bugzilla with T420 had the problem. And
their dmidecode is
https://launchpadlibrarian.net/109393850/dmidecode.txt

What is the difference with your system? Bios I think is the same.

Can you see what we should check for in the dmi tables to black list
these systems? Can you post your T420's dmidecode to see the difference.

Bugs I have on this are:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/776999
https://bugzilla.kernel.org/show_bug.cgi?id=43054

thanks,
suresh

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: sched_clock: update epoch_cyc on resume

[Kevin Hilman]

Barry Song <21cn...@gmail.com> writes:

> 2012/7/18 Colin Cross :
>> Many clocks that are used to provide sched_clock will reset during
>> suspend.  If read_sched_clock returns 0 after suspend, sched_clock will
>> appear to jump forward.  This patch resets cd.epoch_cyc to the current
>> value of read_sched_clock during resume, which causes sched_clock() just
>> after suspend to return the same value as sched_clock() just before
>> suspend.
>>
>> In addition, during the window where epoch_ns has been updated before
>> suspend, but epoch_cyc has not been updated after suspend, it is unknown
>> whether the clock has reset or not, and sched_clock() could return a
>> bogus value.  Add a suspended flag, and return the pre-suspend epoch_ns
>> value during this period.
>
> Acked-by: Barry Song <21cn...@gmail.com>
>
> this patch should also fix the issue that:
> 1. launch some rt threads, rt threads sleep before suspend
> 2. repeat to suspend/resume
> 3. after resuming, waking up rt threads
>
> repeat 1-3 again and again, sometimes all rt threads will hang after
> resuming due to wrong sched_clock will make sched_rt think rt_time is
> much more than rt_runtime (default 950ms in 1s). then rt threads will
> lost cpu timeslot to run since the 95% threshold is there.

Re-visiting this in light of a related problem.

I've run into a similar issue where IRQ threads are prevented from
running during resume becase the RT throttling kicks because RT
runtime is accumulated during suspend.  Using the 'needs_suspend'
version fixes this problem too.

However, because of the RT throttling issue, it seems like *all*
platforms should be using the 'needs_suspend' version always.  But, as
already pointed out, that makes the timed printk output during
suspend/resume rather unhelpful.

Having to choose between useful printk times during suspend/resume and
functioning IRQ threads during suspend/resume isn't a choice I want to
make.   I'd rather have both.  Any ideas?

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: x2apic boot failure on recent sandy bridge system

[H. Peter Anvin]

On 10/19/2012 04:32 PM, Yinghai Lu wrote:

On Fri, Oct 19, 2012 at 4:03 PM, Suresh Siddha
 wrote:

On Fri, 2012-10-19 at 13:42 -0700, rrl...@gmail.com wrote:

Any update? The messages just seem to have stopped months ago. A
fallback would be nice, I have been booting the kernel with noa2xpic
for since kernel 3.2, and currently I am working with 3.6.2.

If needed I can try to attempt modifying the patch to include
fallback, but I am probably not the best person to do it.



Are you referring to this commit that made into the mainline tree
already?

commit fb209bd891645bb87b9618b724f0b4928e0df3de
Author: Yinghai Lu 
Date:   Wed Dec 21 17:45:17 2011 -0800

 x86, x2apic: Fallback to xapic when BIOS doesn't setup interrupt-remapping


I think his system has DMAR table and cpu support x2apic, So kernel
will switch to x2apic,

but somehow BIOS SMI handler has problem with x2apic. should be thinkpad W520?



Right, StinkPad W520 needs a quirk.


--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: x2apic boot failure on recent sandy bridge system

[Yinghai Lu]

On Fri, Oct 19, 2012 at 4:03 PM, Suresh Siddha
 wrote:
> On Fri, 2012-10-19 at 13:42 -0700, rrl...@gmail.com wrote:
>> Any update? The messages just seem to have stopped months ago. A
>> fallback would be nice, I have been booting the kernel with noa2xpic
>> for since kernel 3.2, and currently I am working with 3.6.2.
>>
>> If needed I can try to attempt modifying the patch to include
>> fallback, but I am probably not the best person to do it.
>>
>
> Are you referring to this commit that made into the mainline tree
> already?
>
> commit fb209bd891645bb87b9618b724f0b4928e0df3de
> Author: Yinghai Lu 
> Date:   Wed Dec 21 17:45:17 2011 -0800
>
> x86, x2apic: Fallback to xapic when BIOS doesn't setup interrupt-remapping

I think his system has DMAR table and cpu support x2apic, So kernel
will switch to x2apic,

but somehow BIOS SMI handler has problem with x2apic. should be thinkpad W520?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Optimizing scheduling policies for Ubuntu (desktop), for low-jitter.

[Uwaysi Bin Kareem]

Not many are discussing this.

So odd since an overloaded computer, looks like a computer with jitter. So  
removing jitter = higher performance.


I changed X to nice -20 though instead. It is hard to predict jitter, and  
maybe some measure of fairness is good.
Still daemons wouldn`t mind running sequentially as simple round robin,  
or? I would like to see a lowpriority round-robin, and not just the  
realtime one. Maybe a modification on "idle" pri. I just want to know  
daemons can be made transparent to jitter. Or atleast some measure of  
fairness to sequentialness that keeps the lowest jitter.


Anyone following ? :)

Peace Be With You.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 12/37] block: fix request_queue->flags initialization

[Ben Hutchings]

On Thu, Oct 18, 2012 at 08:16:35PM -0700, Greg Kroah-Hartman wrote:
> 3.0-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Tejun Heo 
> 
> commit 60ea8226cbd5c8301f9a39edc574ddabcb8150e0 upstream.
> 
> A queue newly allocated with blk_alloc_queue_node() has only
> QUEUE_FLAG_BYPASS set.  For request-based drivers,
> blk_init_allocated_queue() is called and q->queue_flags is overwritten
> with QUEUE_FLAG_DEFAULT which doesn't include BYPASS even though the
> initial bypass is still in effect.
> 
> In blk_init_allocated_queue(), or QUEUE_FLAG_DEFAULT to q->queue_flags
> instead of overwriting.
[...]

This is not needed, as there is no QUEUE_FLAG_BYPASS in 3.0.y.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 02/37] lockd: use rpc clients cl_nodename for id encoding

[Ben Hutchings]

On Thu, Oct 18, 2012 at 08:16:25PM -0700, Greg Kroah-Hartman wrote:
> 3.0-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Stanislav Kinsbursky 
> 
> commit 303a7ce92064c285a04c870f2dc0192fdb2968cb upstream.
> 
> Taking hostname from uts namespace if not safe, because this cuold be
> performind during umount operation on child reaper death. And in this case
> current->nsproxy is NULL already.
 
In this case (3.0.y) you haven't included the following change
(commit cb7323fffa85 'lockd: create and use per-net NSM RPC clients on
MON/UNMON requests') that makes lockd actually use cl_nodename.  I
think this patch alone won't fix the bug, as nsm_args::nodename can
end up pointing to freed memory.

(I also wonder whether clients should really be per-net or per UTS
namespace, and whether those should be orthogonal namespaces at all.)

Ben.

[]
> --- a/fs/lockd/mon.c
> +++ b/fs/lockd/mon.c
> @@ -40,6 +40,7 @@ struct nsm_args {
>   u32 proc;
>  
>   char*mon_name;
> + char*nodename;
>  };
>  
>  struct nsm_res {
> @@ -93,6 +94,7 @@ static int nsm_mon_unmon(struct nsm_hand
>   .vers   = 3,
>   .proc   = NLMPROC_NSM_NOTIFY,
>   .mon_name   = nsm->sm_mon_name,
> + .nodename   = utsname()->nodename,
>   };
>   struct rpc_message msg = {
>   .rpc_argp   = ,
> @@ -429,7 +431,7 @@ static void encode_my_id(struct xdr_stre
>  {
>   __be32 *p;
>  
> - encode_nsm_string(xdr, utsname()->nodename);
> + encode_nsm_string(xdr, argp->nodename);
>   p = xdr_reserve_space(xdr, 4 + 4 + 4);
>   *p++ = cpu_to_be32(argp->prog);
>   *p++ = cpu_to_be32(argp->vers);

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ACPI / PM: Fix device PM kernedoc comments and #ifdefs

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

The kerneldoc comments for acpi_pm_device_sleep_state(),
acpi_pm_device_run_wake(), and acpi_pm_device_sleep_wake() are
outdated and/or don't follow the common kerneldoc patters, so
fix them.

Additionally, notice that acpi_pm_device_run_wake() should be under
CONFIG_PM_RUNTIME rather than under CONFIG_PM_SLEEP, so fix that too.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/sleep.c|   51 +---
 include/acpi/acpi_bus.h |8 +--
 2 files changed, 29 insertions(+), 30 deletions(-)

Index: linux-pm/drivers/acpi/sleep.c
===
--- linux-pm.orig/drivers/acpi/sleep.c
+++ linux-pm/drivers/acpi/sleep.c
@@ -699,28 +699,21 @@ int acpi_suspend(u32 acpi_state)
 
 #ifdef CONFIG_PM
 /**
- * acpi_pm_device_sleep_state - return preferred power state of ACPI device
- * in the system sleep state given by %acpi_target_sleep_state
- * @dev: device to examine; its driver model wakeup flags control
- * whether it should be able to wake up the system
- * @d_min_p: used to store the upper limit of allowed states range
- * @d_max_in: specify the lowest allowed states
- * Return value: preferred power state of the device on success, -ENODEV
- * (ie. if there's no 'struct acpi_device' for @dev) or -EINVAL on failure
+ * acpi_pm_device_sleep_state - Get preferred power state of ACPI device.
+ * @dev: Device whose preferred target power state to return.
+ * @d_min_p: Location to store the upper limit of the allowed states range.
+ * @d_max_in: Deepest low-power state to take into consideration.
+ * Return value: Preferred power state of the device on success, -ENODEV
+ * (if there's no 'struct acpi_device' for @dev) or -EINVAL on failure
  *
- * Find the lowest power (highest number) ACPI device power state that
- * device @dev can be in while the system is in the sleep state represented
- * by %acpi_target_sleep_state.  If @wake is nonzero, the device should be
- * able to wake up the system from this sleep state.  If @d_min_p is set,
- * the highest power (lowest number) device power state of @dev allowed
- * in this system sleep state is stored at the location pointed to by it.
+ * Find the lowest power (highest number) ACPI device power state that the
+ * device can be in while the system is in the sleep state represented
+ * by %acpi_target_sleep_state.  If @d_min_p is set, the highest power (lowest
+ * number) device power state that @dev can be in for the given system sleep
+ * state is stored at the location pointed to by it.
  *
- * The caller must ensure that @dev is valid before using this function.
- * The caller is also responsible for figuring out if the device is
- * supposed to be able to wake up the system and passing this information
- * via @wake.
+ * The caller must ensure that @dev is valid before using this function.
  */
-
 int acpi_pm_device_sleep_state(struct device *dev, int *d_min_p, int d_max_in)
 {
acpi_handle handle = DEVICE_ACPI_HANDLE(dev);
@@ -812,14 +805,15 @@ int acpi_pm_device_sleep_state(struct de
 EXPORT_SYMBOL(acpi_pm_device_sleep_state);
 #endif /* CONFIG_PM */
 
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_PM_RUNTIME
 /**
- * acpi_pm_device_run_wake - Enable/disable wake-up for given device.
- * @phys_dev: Device to enable/disable the platform to wake-up the system for.
- * @enable: Whether enable or disable the wake-up functionality.
+ * acpi_pm_device_run_wake - Enable/disable remote wakeup for given device.
+ * @phys_dev: Device to enable/disable the platform to wake up.
+ * @enable: Whether enable or disable the wakeup functionality.
  *
  * Find the ACPI device object corresponding to @pci_dev and try to
- * enable/disable the GPE associated with it.
+ * enable/disable the GPE associated with it, so that it can generate
+ * wakeup signals for the device in response to external (remote) events.
  */
 int acpi_pm_device_run_wake(struct device *phys_dev, bool enable)
 {
@@ -847,12 +841,13 @@ int acpi_pm_device_run_wake(struct devic
return 0;
 }
 EXPORT_SYMBOL(acpi_pm_device_run_wake);
+#endif /* CONFIG_PM_RUNTIME */
 
+#ifdef CONFIG_PM_SLEEP
 /**
- * acpi_pm_device_sleep_wake - enable or disable the system wake-up
- *  capability of given device
- * @dev: device to handle
- * @enable: 'true' - enable, 'false' - disable the wake-up capability
+ * acpi_pm_device_sleep_wake - Enable or disable device to wake up the system.
+ * @dev: Device to enable/desible to wake up the system from sleep states.
+ * @enable: Whether enable or disable @dev to wake up the system.
  */
 int acpi_pm_device_sleep_wake(struct device *dev, bool enable)
 {
Index: linux-pm/include/acpi/acpi_bus.h
===
--- linux-pm.orig/include/acpi/acpi_bus.h
+++ 

[PATCH 1/3] kconfig: remove CONFIG_ from string constants

[Yann E. MORIN]

Having the CONFIG_ prefix in string constants gets in the way of
using a run-time-defined CONFIG_ prefix.

Fix that by using temp growable strings (gstr) in which we printf
the text.

Signed-off-by: "Yann E. MORIN" 
---
 scripts/kconfig/mconf.c |   10 --
 scripts/kconfig/nconf.c |   11 +--
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index 48f6744..5f29618 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -348,15 +348,19 @@ static void search_conf(void)
 {
struct symbol **sym_arr;
struct gstr res;
+   struct gstr title;
char *dialog_input;
int dres, vscroll = 0, hscroll = 0;
bool again;
 
+   title = str_new();
+   str_printf( , _("Enter %s (sub)string to search for "
+ "(with or without \"%s\")"), CONFIG_, CONFIG_);
+
 again:
dialog_clear();
dres = dialog_inputbox(_("Search Configuration Parameter"),
- _("Enter " CONFIG_ " (sub)string to search for "
-   "(with or without \"" CONFIG_ "\")"),
+ str_get(),
  10, 75, "");
switch (dres) {
case 0:
@@ -365,6 +369,7 @@ again:
show_helptext(_("Search Configuration"), search_help);
goto again;
default:
+   str_free();
return;
}
 
@@ -398,6 +403,7 @@ again:
str_free();
} while (again);
free(sym_arr);
+   str_free();
 }
 
 static void build_conf(struct menu *menu)
diff --git a/scripts/kconfig/nconf.c b/scripts/kconfig/nconf.c
index 87d4b15..261f926 100644
--- a/scripts/kconfig/nconf.c
+++ b/scripts/kconfig/nconf.c
@@ -696,13 +696,18 @@ static void search_conf(void)
 {
struct symbol **sym_arr;
struct gstr res;
+   struct gstr title;
char *dialog_input;
int dres;
+
+   title = str_new();
+   str_printf( , _("Enter %s (sub)string to search for "
+ "(with or without \"%s\")"), CONFIG_, CONFIG_);
+
 again:
dres = dialog_inputbox(main_window,
_("Search Configuration Parameter"),
-   _("Enter " CONFIG_ " (sub)string to search for "
-   "(with or without \"" CONFIG_ "\")"),
+   str_get(),
"", _input_result, _input_result_len);
switch (dres) {
case 0:
@@ -712,6 +717,7 @@ again:
_("Search Configuration"), search_help);
goto again;
default:
+   str_free();
return;
}
 
@@ -726,6 +732,7 @@ again:
show_scroll_win(main_window,
_("Search Results"), str_get());
str_free();
+   str_free();
 }
 
 
-- 
1.7.2.5

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

[PATCH 2/3] kconfig: add a function to get the CONFIG_ prefix

[Yann E. MORIN]

Currently, we get the CONFIG_ prefix via the CONFIG_ macro, which means
the CONFIG_ prefix is hard-coded at compile time. This goes against
having a run-time defined CONFIG_ prefix.

Add a function that returns the CONFIG_ prefix to use (but keep the
current hard-coded behavior, to be changed in a later patch).

To avoid touching all the code that uses the CONFIG_ macro, we just
undef it, and define it to be a call to the function.

Signed-off-by: "Yann E. MORIN" 
---
 scripts/kconfig/lkc.h |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h
index c18f2bd..7aa9db0 100644
--- a/scripts/kconfig/lkc.h
+++ b/scripts/kconfig/lkc.h
@@ -39,6 +39,12 @@ extern "C" {
 #ifndef CONFIG_
 #define CONFIG_ "CONFIG_"
 #endif
+static inline const char *CONFIG_prefix(void)
+{
+   return CONFIG_;
+}
+#undef CONFIG_
+#define CONFIG_ CONFIG_prefix()
 
 #define TF_COMMAND 0x0001
 #define TF_PARAM   0x0002
-- 
1.7.2.5

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

[PATCH 0/3 v3] kconfig: get the CONFIG_ prefix from the environment

[Yann E. MORIN]

Hello All!

This little patch series allows one to override the CONFIG_ prefix at 
runtime, without the need to rebuild the frontends.

This will be useful to have, to share the same kconfig frontends between
different projects that may use different prefix. For example:
  - busybox and uClibc use the standard 'CONFIG_'
  - crosstool-NG uses 'CT_'
  - PTXdist uses 'PTXCONF_'
  - buildroot does not use a prefix at all
  - and so on...

[PATCH 1/3] kconfig: remove CONFIG_ from string constants
[PATCH 2/3] kconfig: add a function to get the CONFIG_ prefix
[PATCH 3/3] kconfig: get CONFIG_ prefix from environment

This is part of my efforts to get a generic package that encapsulates the
kconfig frontends and parser into a standalone package, to make it easy
for third-party projects to easily sync (and ultimately share) their
kconfig infrastructure:
kconfig-frontends
http://ymorin.is-a-geek.org/projects/kconfig-frontends

Changes in v3:
  - simplify the CONFIG_prefix() function (Michal)
  - rebase on-top master to date
Changes in v2:
  - call getenv() only once
  - don't touch code when not strictly neeeded (don't fold not-so-long lines)
  - rebase on-top 3.7-rc1

Regards,
Yann E. MORIN.

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

Re: [PATCH 1/2] MODSIGN: perlify sign-file and merge in x509keyid [ver #2]

[Linus Torvalds]

On Fri, Oct 19, 2012 at 3:58 PM, Linus Torvalds
 wrote:
>
> Also, I wonder how standard this /usr/bin/perl is:
>
>> +#!/usr/bin/perl -w

Well, we have other uses of that path in the kernel already, and your
v3 patch uses 'perl' in the Makefile to run it, so it will pick up the
path that way.

So I think it all looks fine now. Will apply, thanks,

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

[PATCH 3/3] kconfig: get CONFIG_ prefix from the environment

[Yann E. MORIN]

Currently, the CONFIG_ prefix is hard-coded in the kconfig frontends
executables. This means that two projects that use kconfig with
different prefixes can not share the same kconfig frontends.

Instead of hard-coding the prefix in the frontends, get it from the
environment, and revert back to hard-coded value if not found.

Signed-off-by: "Yann E. MORIN" 
---
 scripts/kconfig/gconf.c |2 +-
 scripts/kconfig/lkc.h   |2 +-
 scripts/kconfig/nconf.c |1 +
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/scripts/kconfig/gconf.c b/scripts/kconfig/gconf.c
index adc2306..f2bee70 100644
--- a/scripts/kconfig/gconf.c
+++ b/scripts/kconfig/gconf.c
@@ -10,6 +10,7 @@
 #  include 
 #endif
 
+#include 
 #include "lkc.h"
 #include "images.c"
 
@@ -22,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 
 //#define DEBUG
 
diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h
index 7aa9db0..7577a7f 100644
--- a/scripts/kconfig/lkc.h
+++ b/scripts/kconfig/lkc.h
@@ -41,7 +41,7 @@ extern "C" {
 #endif
 static inline const char *CONFIG_prefix(void)
 {
-   return CONFIG_;
+   return getenv( "CONFIG_" ) ?: CONFIG_;
 }
 #undef CONFIG_
 #define CONFIG_ CONFIG_prefix()
diff --git a/scripts/kconfig/nconf.c b/scripts/kconfig/nconf.c
index 261f926..ce93e87 100644
--- a/scripts/kconfig/nconf.c
+++ b/scripts/kconfig/nconf.c
@@ -7,6 +7,7 @@
  */
 #define _GNU_SOURCE
 #include 
+#include 
 
 #include "lkc.h"
 #include "nconf.h"
-- 
1.7.2.5

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

Re: x2apic boot failure on recent sandy bridge system

[Suresh Siddha]

On Fri, 2012-10-19 at 13:42 -0700, rrl...@gmail.com wrote:
> Any update? The messages just seem to have stopped months ago. A
> fallback would be nice, I have been booting the kernel with noa2xpic
> for since kernel 3.2, and currently I am working with 3.6.2.
> 
> If needed I can try to attempt modifying the patch to include
> fallback, but I am probably not the best person to do it.
> 

Are you referring to this commit that made into the mainline tree
already?

commit fb209bd891645bb87b9618b724f0b4928e0df3de
Author: Yinghai Lu 
Date:   Wed Dec 21 17:45:17 2011 -0800

x86, x2apic: Fallback to xapic when BIOS doesn't setup interrupt-remapping

On some of the recent Intel SNB platforms, by default bios is pre-enabling
x2apic mode in the cpu with out setting up interrupt-remapping.
This case was resulting in the kernel to panic as the cpu is already in
x2apic mode but the OS was not able to enable interrupt-remapping (which
is a pre-req for using x2apic capability).

On these platforms all the apic-ids are < 255 and the kernel can fallback to
xapic mode if the bios has not enabled interrupt-remapping (which is
mostly the case if the bios has not exported interrupt-remapping tables to 
the
OS).

Reported-by: Berck E. Nash 
Signed-off-by: Yinghai Lu 
Link: 
http://lkml.kernel.org/r/20111222014632.600418...@sbsiddha-desk.sc.intel.com
Signed-off-by: Suresh Siddha 
Signed-off-by: H. Peter Anvin 


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

Re: [PATCH 1/2] Input: matrix-keypad - remove const from pointer to array of gpios

[Dmitry Torokhov]

On Fri, Oct 19, 2012 at 12:36:12PM +0530, AnilKumar Ch wrote:
> Remove const from pointer to array of gpios in matrix_keypad_platform_data
> struct. This is required if we update row_gpios and col_gpios based on
> device tree data.

Then don't. Set them up via non-const aliases instead.

Thanks.

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

Re: [PATCH 1/2] MODSIGN: perlify sign-file and merge in x509keyid [ver #2]

[Linus Torvalds]

This version still seems to have some debug turds in it:

On Fri, Oct 19, 2012 at 3:51 PM, David Howells  wrote:
>
> +   printk("Check for sig\n");
> +
...
> +   printk("Found sig\n");
...
> +#define DEBUG

Also, I wonder how standard this /usr/bin/perl is:

> +#!/usr/bin/perl -w

and maybe we should use Unix best practices and make it do

#!/usr/bin/env perl

instead?

But I dunno, maybe /usr/bin/perl has become sufficiently standardized..

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

[PATCH 2/2] MODSIGN: Cleanup .gitignore [ver #3]

[David Howells]

The module build process no longer creates intermediate files for module
signing, so remove them from .gitignore.

Signed-off-by: David Howells 
---

 .gitignore |6 --
 1 file changed, 6 deletions(-)


diff --git a/.gitignore b/.gitignore
index 0f2f40f..92bd0e4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -14,10 +14,6 @@
 *.o.*
 *.a
 *.s
-*.ko.unsigned
-*.ko.stripped
-*.ko.stripped.dig
-*.ko.stripped.sig
 *.ko
 *.so
 *.so.dbg
@@ -95,6 +91,4 @@ GTAGS
 extra_certificates
 signing_key.priv
 signing_key.x509
-signing_key.x509.keyid
-signing_key.x509.signer
 x509.genkey

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

[PATCH 1/2] MODSIGN: perlify sign-file and merge in x509keyid [ver #3]

[David Howells]

Turn sign-file into perl and merge in x509keyid.  The latter doesn't need to be
a separate script as it doesn't actually need to work out the SHA1 sum of the
X.509 certificate itself, since it can get that from the X.509 certificate.

Signed-off-by: David Howells 
---

 Makefile  |2 
 scripts/sign-file |  477 -
 scripts/x509keyid |  268 --
 3 files changed, 400 insertions(+), 347 deletions(-)
 mode change 100644 => 100755 scripts/sign-file
 delete mode 100755 scripts/x509keyid


diff --git a/Makefile b/Makefile
index 4fd82f7..14b9874 100644
--- a/Makefile
+++ b/Makefile
@@ -723,7 +723,7 @@ ifeq ($(CONFIG_MODULE_SIG),y)
 MODSECKEY = ./signing_key.priv
 MODPUBKEY = ./signing_key.x509
 export MODPUBKEY
-mod_sign_cmd = sh $(srctree)/scripts/sign-file $(MODSECKEY) $(MODPUBKEY) 
$(srctree)/scripts/x509keyid
+mod_sign_cmd = perl $(srctree)/scripts/sign-file $(MODSECKEY) $(MODPUBKEY)
 else
 mod_sign_cmd = true
 endif
diff --git a/scripts/sign-file b/scripts/sign-file
old mode 100644
new mode 100755
index d014abd..c8a2e7c
--- a/scripts/sign-file
+++ b/scripts/sign-file
@@ -1,108 +1,429 @@
-#!/bin/bash
+#!/usr/bin/perl -w
 #
 # Sign a module file using the given key.
 #
-# Format: sign-file
+# Format:
 #
+#  ./scripts/sign-file [-v][]
+#
+#
+use strict;
+use FileHandle;
+use IPC::Open2;
+
+my $verbose = 0;
+if ($#ARGV >= 0 && $ARGV[0] eq "-v") {
+$verbose = 1;
+shift;
+}
+
+die "Format: ./scripts/sign-file [-v][]\n"
+if ($#ARGV != 2 && $#ARGV != 3);
+
+my $private_key = $ARGV[0];
+my $x509 = $ARGV[1];
+my $module = $ARGV[2];
+my $dest = ($#ARGV == 3) ? $ARGV[3] : $ARGV[2] . "~";
+
+die "Can't read private key\n" unless (-r $private_key);
+die "Can't read X.509 certificate\n" unless (-r $x509);
+die "Can't read module\n" unless (-r $module);
+
+#
+# Read the kernel configuration
+#
+my %config = (
+CONFIG_MODULE_SIG_SHA512 => 1
+);
+
+if (-r ".config") {
+open(FD, "<.config") || die ".config";
+while () {
+   if ($_ =~ /^(CONFIG_.*)=[ym]/) {
+   $config{$1} = 1;
+   }
+}
+close(FD);
+}
 
-scripts=`dirname $0`
+#
+# Function to read the contents of a file into a variable.
+#
+sub read_file($)
+{
+my ($file) = @_;
+my $contents;
+my $len;
+
+open(FD, "<$file") || die $file;
+binmode FD;
+my @st = stat(FD);
+die $file if (!@st);
+$len = read(FD, $contents, $st[7]) || die $file;
+close(FD) || die $file;
+die "$file: Wanted length ", $st[7], ", got ", $len, "\n"
+   if ($len != $st[7]);
+return $contents;
+}
+
+###
+#
+# First of all, we have to parse the X.509 certificate to find certain details
+# about it.
+#
+# We read the DER-encoded X509 certificate and parse it to extract the Subject
+# name and Subject Key Identifier.  Theis provides the data we need to build
+# the certificate identifier.
+#
+# The signer's name part of the identifier is fabricated from the commonName,
+# the organizationName or the emailAddress components of the X.509 subject
+# name.
+#
+# The subject key ID is used to select which of that signer's certificates
+# we're intending to use to sign the module.
+#
+###
+my $x509_certificate = read_file($x509);
 
-CONFIG_MODULE_SIG_SHA512=y
-if [ -r .config ]
-then
-. ./.config
-fi
+my $UNIV = 0 << 6;
+my $APPL = 1 << 6;
+my $CONT = 2 << 6;
+my $PRIV = 3 << 6;
 
-key="$1"
-x509="$2"
-keyid_script="$3"
-mod="$4"
+my $CONS = 0x20;
 
-if [ ! -r "$key" ]
-then
-echo "Can't read private key" >&2
-exit 2
-fi
+my $BOOLEAN= 0x01;
+my $INTEGER= 0x02;
+my $BIT_STRING = 0x03;
+my $OCTET_STRING = 0x04;
+my $NULL   = 0x05;
+my $OBJ_ID = 0x06;
+my $UTF8String = 0x0c;
+my $SEQUENCE   = 0x10;
+my $SET= 0x11;
+my $UTCTime= 0x17;
+my $GeneralizedTime = 0x18;
 
-if [ ! -r "$x509" ]
-then
-echo "Can't read X.509 certificate" >&2
-exit 2
-fi
+my %OIDs = (
+pack("CCC", 85, 4, 3)  => "commonName",
+pack("CCC", 85, 4, 6)  => "countryName",
+pack("CCC", 85, 4, 10) => "organizationName",
+pack("CCC", 85, 4, 11) => "organizationUnitName",
+pack("C", 42, 134, 72, 134, 247, 13, 1, 1, 1) => "rsaEncryption",
+pack("C", 42, 134, 72, 134, 247, 13, 1, 1, 5) => 
"sha1WithRSAEncryption",
+pack("C", 42, 134, 72, 134, 247, 13, 1, 9, 1) => "emailAddress",
+pack("CCC", 85, 29, 35)=> "authorityKeyIdentifier",
+pack("CCC", 85, 29, 14)=> "subjectKeyIdentifier",
+pack("CCC", 85, 29, 19)=> "basicConstraints"
+);
+
+###
+#
+# Extract an ASN.1 element from a string and return information about it.
+#

Re: [PATCH 1/2] brw_mutex: big read-write mutex

[Mikulas Patocka]

On Fri, 19 Oct 2012, Peter Zijlstra wrote:

> > Yes, I tried this approach - it involves doing LOCK instruction on read 
> > lock, remembering the cpu and doing another LOCK instruction on read 
> > unlock (which will hopefully be on the same CPU, so no cacheline bouncing 
> > happens in the common case). It was slower than the approach without any 
> > LOCK instructions (43.3 seconds seconds for the implementation with 
> > per-cpu LOCKed access, 42.7 seconds for this implementation without atomic 
> > instruction; the benchmark involved doing 512-byte direct-io reads and 
> > writes on a ramdisk with 8 processes on 8-core machine).
> 
> So why is that a problem? Surely that's already tons better then what
> you've currently got.

Percpu rw-semaphores do not improve performance at all. I put them there 
to avoid performance regression, not to improve performance.

All Linux kernels have a race condition - when you change block size of a 
block device and you read or write the device at the same time, a crash 
may happen. This bug is there since ever. Recently, this bug started to 
cause major trouble - multiple high profile business sites report crashes 
because of this race condition.

You can fix this race by using a read lock around I/O paths and write lock 
around block size changing, but normal rw semaphore cause cache line 
bouncing when taken for read by multiple processors and I/O performance 
degradation because of it is measurable.

So I put this percpu-rw-semaphore there to fix the crashes and minimize 
performance impact - on x86 it doesn't take any interlocked instructions 
in the read path.

I don't quite understand why are people opposing to this and what do they 
want to do instead? If you pull percpu-rw-semaphores out of the kernel, 
you introduce a performance regression (raw device i/o will be slower on 
3.7 than on 3.6, because on 3.6 it doesn't take any lock at all and on 3.7 
it takes a read lock).

So you have options:
1) don't lock i/o just like on 3.6 and previous versions - you get a fast 
kernel that randomly crashes
2) lock i/o with normal rw semaphore - you get a kernel that doesn't 
crash, but that is slower than previous versions
3) lock i/o with percpu rw semaphore - you get kernel that is almost as 
fast as previous kernels and that doesn't crash

For the users, the option 3) is the best. The users don't care whether it 
looks ugly or not, they care about correctness and performance, that's 
all.

Obviously, you can improve rw semaphores by adding lockdep annotations, or 
by other things (turning rcu_read_lock/sychronize_rcu into 
preempt_disable/synchronize_sched, by using barrier()-synchronize_sched() 
instead of smp_mb()...), but I don't see a reason why do you want to hurt 
users' experience by pulling it out and reverting to state 1) or 2) and 
then, two kernel cycles later, come up with percpu-rw-semaphores again.

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

Re: [PATCH 1/2] MODSIGN: perlify sign-file and merge in x509keyid [ver #2]

[David Howells]

David Howells  wrote:

> + printk("Check for sig\n");
> +
> ...
> + printk("Found sig\n");
> ...
> +#define DEBUG

And I also forgot to remove the debugging.  Sigh.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kconfig/menuconfig: use TAILQ instead of CIRCLEQ

[Yann E. MORIN]

Tetsuo, Michal, All,

On Friday 19 October 2012 Tetsuo Handa wrote:
> Yann E. MORIN wrote:
> > Some systems (eg. Cygwin, FreeBSD) are missing the CIRCLEQ macros.
[--SNIP--]
> > So, switch to using TAILQ instead, which are more portable.
[--SNIP--]
> Excuse me, but your patch does not solve my problem because kconfig started
> using macros which does not exist in "@(#)queue.h 8.3 (Berkeley) 12/13/93".

Whoa. That's old... :-/

Currently, kconfig uses (CIRCLEQ or TAILQ)

> Kconfig still fails after applying your patch:
[--SNIP--]
> So, would you add something which looks like "sed -e 's/CIRCLEQ/TAILQ/g'" upon
> https://lkml.org/lkml/2012/10/16/274 ?

Sorry, I did not see you had posted a patch.

Basically, I don't care what solution we choose. Using TAILQ looks like
being not the solution. So, here are the known options:
1-  Michal pointed to tools/firewire/list.h, but those are different from
the CIRCLEQ/TAILQ, and switching is not easy (at least for me after a
quick glance);

1b- note also that drivers/scsi/aic7xxx/queue.h has all of both the CIRCLEQ
and TAILQ macros we're interested in, too, and it looks like it can be
used out of the kernel (eg. for userland);

2-  carry the parts of CIRCLEQ (or TAILQ) that we need, and use them if
the system's sys/queue.h does not provide them, as Tetsuo proposed;

3-  carry the parts of CIRCLEQ (or TAILQ) that we need, and do not rely
on the system's sys/queue.h to provide them at all.


Michal, what do you think would be the best route to go, to:
1- get a fix in 3.7 ?
2- if the fix for 3.7 is just a workaround, a proper fix for 3.8 ?

Regards,
Yann E. MORIN.

-- 
.-..--..
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN |  ___   |
| +33 223 225 172 `.---:  X  AGAINST  |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL|   v   conspiracy.  |
'--^---^--^'
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3.7-rc1 (nouveau_bios_score oops).

[Linus Torvalds]

On Fri, Oct 19, 2012 at 3:41 PM, Martin Peres  wrote:
>
> You must have missed the oops that was attached to the mail:
> http://www.spinics.net/lists/kernel/msg1420355.html

I did indeed. So never mind about that dmesg request, Paweł ;-p

> Paweł, could you try the attached patch please ?

Thanks for being on it,

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

[PATCH 2/2] MODSIGN: Cleanup .gitignore [ver #2]

[David Howells]

The module build process no longer creates intermediate files for module
signing, so remove them from .gitignore.

Signed-off-by: David Howells 
---

 .gitignore |6 --
 1 file changed, 6 deletions(-)


diff --git a/.gitignore b/.gitignore
index 0f2f40f..92bd0e4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -14,10 +14,6 @@
 *.o.*
 *.a
 *.s
-*.ko.unsigned
-*.ko.stripped
-*.ko.stripped.dig
-*.ko.stripped.sig
 *.ko
 *.so
 *.so.dbg
@@ -95,6 +91,4 @@ GTAGS
 extra_certificates
 signing_key.priv
 signing_key.x509
-signing_key.x509.keyid
-signing_key.x509.signer
 x509.genkey

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

[PATCH 1/2] MODSIGN: perlify sign-file and merge in x509keyid [ver #2]

[David Howells]

Turn sign-file into perl and merge in x509keyid.  The latter doesn't need to be
a separate script as it doesn't actually need to work out the SHA1 sum of the
X.509 certificate itself, since it can get that from the X.509 certificate.

Signed-off-by: David Howells 
---

 Makefile|2 
 kernel/module.c |3 
 kernel/module_signing.c |2 
 scripts/sign-file   |  477 +++
 scripts/x509keyid   |  268 --
 5 files changed, 404 insertions(+), 348 deletions(-)
 mode change 100644 => 100755 scripts/sign-file
 delete mode 100755 scripts/x509keyid


diff --git a/Makefile b/Makefile
index 4fd82f7..14b9874 100644
--- a/Makefile
+++ b/Makefile
@@ -723,7 +723,7 @@ ifeq ($(CONFIG_MODULE_SIG),y)
 MODSECKEY = ./signing_key.priv
 MODPUBKEY = ./signing_key.x509
 export MODPUBKEY
-mod_sign_cmd = sh $(srctree)/scripts/sign-file $(MODSECKEY) $(MODPUBKEY) 
$(srctree)/scripts/x509keyid
+mod_sign_cmd = perl $(srctree)/scripts/sign-file $(MODSECKEY) $(MODPUBKEY)
 else
 mod_sign_cmd = true
 endif
diff --git a/kernel/module.c b/kernel/module.c
index 0e2da86..ae0972b 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2427,6 +2427,8 @@ static int module_sig_check(struct load_info *info,
const unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
const void *p = mod, *end = mod + *len;
 
+   printk("Check for sig\n");
+
/* Poor man's memmem. */
while ((p = memchr(p, MODULE_SIG_STRING[0], end - p))) {
if (p + markerlen > end)
@@ -2435,6 +2437,7 @@ static int module_sig_check(struct load_info *info,
if (memcmp(p, MODULE_SIG_STRING, markerlen) == 0) {
const void *sig = p + markerlen;
/* Truncate module up to signature. */
+   printk("Found sig\n");
*len = p - mod;
err = mod_verify_sig(mod, *len, sig, end - sig);
break;
diff --git a/kernel/module_signing.c b/kernel/module_signing.c
index 6b09f69..c823a02 100644
--- a/kernel/module_signing.c
+++ b/kernel/module_signing.c
@@ -8,7 +8,7 @@
  * as published by the Free Software Foundation; either version
  * 2 of the Licence, or (at your option) any later version.
  */
-
+#define DEBUG
 #include 
 #include 
 #include 
diff --git a/scripts/sign-file b/scripts/sign-file
old mode 100644
new mode 100755
index d014abd..c8a2e7c
--- a/scripts/sign-file
+++ b/scripts/sign-file
@@ -1,108 +1,429 @@
-#!/bin/bash
+#!/usr/bin/perl -w
 #
 # Sign a module file using the given key.
 #
-# Format: sign-file
+# Format:
 #
+#  ./scripts/sign-file [-v][]
+#
+#
+use strict;
+use FileHandle;
+use IPC::Open2;
+
+my $verbose = 0;
+if ($#ARGV >= 0 && $ARGV[0] eq "-v") {
+$verbose = 1;
+shift;
+}
+
+die "Format: ./scripts/sign-file [-v][]\n"
+if ($#ARGV != 2 && $#ARGV != 3);
+
+my $private_key = $ARGV[0];
+my $x509 = $ARGV[1];
+my $module = $ARGV[2];
+my $dest = ($#ARGV == 3) ? $ARGV[3] : $ARGV[2] . "~";
+
+die "Can't read private key\n" unless (-r $private_key);
+die "Can't read X.509 certificate\n" unless (-r $x509);
+die "Can't read module\n" unless (-r $module);
+
+#
+# Read the kernel configuration
+#
+my %config = (
+CONFIG_MODULE_SIG_SHA512 => 1
+);
+
+if (-r ".config") {
+open(FD, "<.config") || die ".config";
+while () {
+   if ($_ =~ /^(CONFIG_.*)=[ym]/) {
+   $config{$1} = 1;
+   }
+}
+close(FD);
+}
 
-scripts=`dirname $0`
+#
+# Function to read the contents of a file into a variable.
+#
+sub read_file($)
+{
+my ($file) = @_;
+my $contents;
+my $len;
+
+open(FD, "<$file") || die $file;
+binmode FD;
+my @st = stat(FD);
+die $file if (!@st);
+$len = read(FD, $contents, $st[7]) || die $file;
+close(FD) || die $file;
+die "$file: Wanted length ", $st[7], ", got ", $len, "\n"
+   if ($len != $st[7]);
+return $contents;
+}
+
+###
+#
+# First of all, we have to parse the X.509 certificate to find certain details
+# about it.
+#
+# We read the DER-encoded X509 certificate and parse it to extract the Subject
+# name and Subject Key Identifier.  Theis provides the data we need to build
+# the certificate identifier.
+#
+# The signer's name part of the identifier is fabricated from the commonName,
+# the organizationName or the emailAddress components of the X.509 subject
+# name.
+#
+# The subject key ID is used to select which of that signer's certificates
+# we're intending to use to sign the module.
+#
+###
+my $x509_certificate = read_file($x509);
 
-CONFIG_MODULE_SIG_SHA512=y
-if [ -r .config ]
-then
-. ./.config
-fi
+my $UNIV = 0 << 6;
+my $APPL = 1 << 6;
+my $CONT = 2 << 6;
+my $PRIV = 3 << 6;
 
-key="$1"
-x509="$2"

Re: [PATCH 1/2] MODSIGN: perlify sign-file and merge in x509keyid

[David Howells]

David Howells  wrote:

> -mod_sign_cmd = sh $(srctree)/scripts/sign-file $(MODSECKEY) $(MODPUBKEY) 
> $(srctree)/scripts/x509keyid
> +mod_sign_cmd = sh $(srctree)/scripts/sign-file $(MODSECKEY) $(MODPUBKEY)

Hmmm...  That's not quite right.  That needs to be 'perl' not 'sh'.

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

[PATCH 2/2] MODSIGN: Cleanup .gitignore

[David Howells]

The module build process no longer creates intermediate files for module
signing, so remove them from .gitignore.

Signed-off-by: David Howells 
---

 .gitignore |6 --
 1 file changed, 6 deletions(-)


diff --git a/.gitignore b/.gitignore
index 0f2f40f..92bd0e4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -14,10 +14,6 @@
 *.o.*
 *.a
 *.s
-*.ko.unsigned
-*.ko.stripped
-*.ko.stripped.dig
-*.ko.stripped.sig
 *.ko
 *.so
 *.so.dbg
@@ -95,6 +91,4 @@ GTAGS
 extra_certificates
 signing_key.priv
 signing_key.x509
-signing_key.x509.keyid
-signing_key.x509.signer
 x509.genkey

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

[PATCH 1/2] MODSIGN: perlify sign-file and merge in x509keyid

[David Howells]

Turn sign-file into perl and merge in x509keyid.  The latter doesn't need to be
a separate script as it doesn't actually need to work out the SHA1 sum of the
X.509 certificate itself, since it can get that from the X.509 certificate.

Signed-off-by: David Howells 
---

 Makefile|2 
 kernel/module.c |3 
 kernel/module_signing.c |2 
 scripts/sign-file   |  477 +++
 scripts/x509keyid   |  268 --
 5 files changed, 404 insertions(+), 348 deletions(-)
 mode change 100644 => 100755 scripts/sign-file
 delete mode 100755 scripts/x509keyid


diff --git a/Makefile b/Makefile
index 4fd82f7..89a2e2c 100644
--- a/Makefile
+++ b/Makefile
@@ -723,7 +723,7 @@ ifeq ($(CONFIG_MODULE_SIG),y)
 MODSECKEY = ./signing_key.priv
 MODPUBKEY = ./signing_key.x509
 export MODPUBKEY
-mod_sign_cmd = sh $(srctree)/scripts/sign-file $(MODSECKEY) $(MODPUBKEY) 
$(srctree)/scripts/x509keyid
+mod_sign_cmd = sh $(srctree)/scripts/sign-file $(MODSECKEY) $(MODPUBKEY)
 else
 mod_sign_cmd = true
 endif
diff --git a/kernel/module.c b/kernel/module.c
index 0e2da86..ae0972b 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2427,6 +2427,8 @@ static int module_sig_check(struct load_info *info,
const unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
const void *p = mod, *end = mod + *len;
 
+   printk("Check for sig\n");
+
/* Poor man's memmem. */
while ((p = memchr(p, MODULE_SIG_STRING[0], end - p))) {
if (p + markerlen > end)
@@ -2435,6 +2437,7 @@ static int module_sig_check(struct load_info *info,
if (memcmp(p, MODULE_SIG_STRING, markerlen) == 0) {
const void *sig = p + markerlen;
/* Truncate module up to signature. */
+   printk("Found sig\n");
*len = p - mod;
err = mod_verify_sig(mod, *len, sig, end - sig);
break;
diff --git a/kernel/module_signing.c b/kernel/module_signing.c
index 6b09f69..c823a02 100644
--- a/kernel/module_signing.c
+++ b/kernel/module_signing.c
@@ -8,7 +8,7 @@
  * as published by the Free Software Foundation; either version
  * 2 of the Licence, or (at your option) any later version.
  */
-
+#define DEBUG
 #include 
 #include 
 #include 
diff --git a/scripts/sign-file b/scripts/sign-file
old mode 100644
new mode 100755
index d014abd..c8a2e7c
--- a/scripts/sign-file
+++ b/scripts/sign-file
@@ -1,108 +1,429 @@
-#!/bin/bash
+#!/usr/bin/perl -w
 #
 # Sign a module file using the given key.
 #
-# Format: sign-file
+# Format:
 #
+#  ./scripts/sign-file [-v][]
+#
+#
+use strict;
+use FileHandle;
+use IPC::Open2;
+
+my $verbose = 0;
+if ($#ARGV >= 0 && $ARGV[0] eq "-v") {
+$verbose = 1;
+shift;
+}
+
+die "Format: ./scripts/sign-file [-v][]\n"
+if ($#ARGV != 2 && $#ARGV != 3);
+
+my $private_key = $ARGV[0];
+my $x509 = $ARGV[1];
+my $module = $ARGV[2];
+my $dest = ($#ARGV == 3) ? $ARGV[3] : $ARGV[2] . "~";
+
+die "Can't read private key\n" unless (-r $private_key);
+die "Can't read X.509 certificate\n" unless (-r $x509);
+die "Can't read module\n" unless (-r $module);
+
+#
+# Read the kernel configuration
+#
+my %config = (
+CONFIG_MODULE_SIG_SHA512 => 1
+);
+
+if (-r ".config") {
+open(FD, "<.config") || die ".config";
+while () {
+   if ($_ =~ /^(CONFIG_.*)=[ym]/) {
+   $config{$1} = 1;
+   }
+}
+close(FD);
+}
 
-scripts=`dirname $0`
+#
+# Function to read the contents of a file into a variable.
+#
+sub read_file($)
+{
+my ($file) = @_;
+my $contents;
+my $len;
+
+open(FD, "<$file") || die $file;
+binmode FD;
+my @st = stat(FD);
+die $file if (!@st);
+$len = read(FD, $contents, $st[7]) || die $file;
+close(FD) || die $file;
+die "$file: Wanted length ", $st[7], ", got ", $len, "\n"
+   if ($len != $st[7]);
+return $contents;
+}
+
+###
+#
+# First of all, we have to parse the X.509 certificate to find certain details
+# about it.
+#
+# We read the DER-encoded X509 certificate and parse it to extract the Subject
+# name and Subject Key Identifier.  Theis provides the data we need to build
+# the certificate identifier.
+#
+# The signer's name part of the identifier is fabricated from the commonName,
+# the organizationName or the emailAddress components of the X.509 subject
+# name.
+#
+# The subject key ID is used to select which of that signer's certificates
+# we're intending to use to sign the module.
+#
+###
+my $x509_certificate = read_file($x509);
 
-CONFIG_MODULE_SIG_SHA512=y
-if [ -r .config ]
-then
-. ./.config
-fi
+my $UNIV = 0 << 6;
+my $APPL = 1 << 6;
+my $CONT = 2 << 6;
+my $PRIV = 3 << 6;
 
-key="$1"
-x509="$2"
-keyid_script="$3"

Re: [RFC PATCH] gpiolib: Refactor gpio_export

[Grant Likely]

On Fri, Oct 19, 2012 at 11:14 PM, Ryan Mallon  wrote:
> On 19/10/12 21:07, Linus Walleij wrote:
>
>> On Wed, Oct 17, 2012 at 1:41 AM, Ryan Mallon  wrote:
>>
>>> The gpio_export function uses nested if statements and the status
>>> variable to handle the failure cases. This makes the function logic
>>> difficult to follow. Refactor the code to abort immediately on failure
>>> using goto. This makes the code slightly longer, but significantly
>>> reduces the nesting and number of split lines and makes the code easier
>>> to read.
>>>
>>> Signed-off-by: Ryan Mallon
>>
>> Very good initiative!
>>
>>> +++ b/drivers/gpio/gpiolib.c
>>> @@ -702,68 +702,74 @@ int gpio_export(unsigned gpio, bool 
>>> direction_may_change)
>>>  {
>>> unsigned long   flags;
>>> struct gpio_desc*desc;
>>> -   int status = -EINVAL;
>>> +   int status;
>>> const char  *ioname = NULL;
>>> +   struct device   *dev;
>>>
>>> /* can't export until sysfs is available ... */
>>> if (!gpio_class.p) {
>>> pr_debug("%s: called too early!\n", __func__);
>>> -   return -ENOENT;
>>> +   status = -ENOENT;
>>> +   goto fail;
>>
>> Why bother with all the goto:s here since there are no resources
>> to clean up? Just pr_debug() and return -ENOENT; is good enough.
>>
>> I don't quite see the point.
>
> I did it this way just so that there would be a single exit point.
> I don't mind either way, so I'll update the ones without any
> clean up to simply return.

Single exit points are overrated. The code is shorter and easier to
read to return immediately if there isn't any unwinding to do.

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

Re: linux-next: build failure after merge of the final tree (tip/s390 trees related)

[Ingo Molnar]

* Stephen Rothwell  wrote:

> Hi Ingo,
> 
> On Thu, 18 Oct 2012 20:29:53 +0200 Ingo Molnar  wrote:
> >
> > * Stephen Rothwell  wrote:
> > > 
> > > After merging the final tree, today's linux-next build (s390 allyesconfig)
> > > failed like this:
> > > 
> > > mm/huge_memory.c:1424:2: error: implicit declaration of function 
> > > 'pmd_pgprot' [-Werror=implicit-function-declaration]
> > > mm/huge_memory.c:1424:7: error: incompatible types when assigning to type 
> > > 'pgprot_t' from type 'int'
> > > 
> > > (see http://kisskb.ellerman.id.au/kisskb/buildresult/7383823/)
> > > 
> > > Caused by commit 35d3d3427314 ("s390/thp: select
> > > HAVE_ARCH_TRANSPARENT_HUGEPAGE") from the s390 tree interacting with
> > > commit 93c9d633bd9e ("mm/thp: Preserve pgprot across huge page split")
> > > from the tip tree.
> > > 
> > > N.B. Mips also selects HAVE_ARCH_TRANSPARENT_HUGEPAGE as of commit
> > > e21a828a1bba ("MIPS: Transparent Huge Pages support") from the mips tree
> > > and so will be broken in some configs now as well.
> > > 
> > > Anyone have suggested merge fix patches I can apply?
> > 
> > Resolved it for now by excluding those changes, will put them 
> > back in once they are fixed.
> 
> It looks as though you have not gone back far enough - you 
> removed a couple of merges of sched/numa, but there are more. 
> I have two of the problems resolved with merge patches that 
> supply pmd_pgprot() for s390 and mips, but there is another 
> problem with mips (see Ralf's other email).

Yeah. All of this should be resolved now in principle. Next time 
you'll integrate linux-next is on Monday, right?

Thanks,

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

Re: linux-next: build failure after merge of the final tree (tip/s390 trees related)

[Ingo Molnar]

Actually, there's two sites - find the updated patch below.

Thanks,

Ingo

--->
>From 7fc4d49214dba401f4b92ed62da60a5b257a653a Mon Sep 17 00:00:00 2001
From: Ingo Molnar 
Date: Sat, 20 Oct 2012 00:33:01 +0200
Subject: [PATCH] MIPS/thp: Fix update_mmu_cache() cache call

As per recent upstream commit:

  b113da65785d mm: Add and use update_mmu_cache_pmd() in transparent huge page 
code.

The call in do_huge_pmd_prot_none() needs to call update_mmu_cache_pmd()
as well.

This resolves a MIPS build error triggered on linux-next.

Reported-by: Ralf Baechle 
Reported-by: Stephen Rothwell 
Acked-by: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20121018145101.ga17...@linux-mips.org
Signed-off-by: Ingo Molnar 
---
 mm/huge_memory.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 8100c01..1068e78 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -770,7 +770,7 @@ fixup:
/* change back to regular protection */
entry = pmd_modify(entry, vma->vm_page_prot);
set_pmd_at(mm, haddr, pmd, entry);
-   update_mmu_cache(vma, address, entry);
+   update_mmu_cache_pmd(vma, address, entry);
 
 unlock:
spin_unlock(>page_table_lock);
@@ -846,7 +846,7 @@ migrate:
page_add_new_anon_rmap(new_page, vma, haddr);
 
set_pmd_at(mm, haddr, pmd, entry);
-   update_mmu_cache(vma, address, entry);
+   update_mmu_cache_pmd(vma, address, entry);
page_remove_rmap(page);
spin_unlock(>page_table_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: [PATCH 1/3] ARM: dts: Update board files for pwm support

[Tony Prisk]

On Fri, 2012-10-19 at 23:38 +1300, Tony Prisk wrote:
> This patch adds pwm support to arch-vt8500 board files, and adds
> the use-case of pwm-backlight.
> 
> Signed-off-by: Tony Prisk 
> ---
>  arch/arm/boot/dts/vt8500-bv07.dts |8 
>  arch/arm/boot/dts/vt8500.dtsi |   29 +
>  arch/arm/boot/dts/wm8505-ref.dts  |8 
>  arch/arm/boot/dts/wm8505.dtsi |   29 +
>  arch/arm/boot/dts/wm8650-mid.dts  |8 
>  arch/arm/boot/dts/wm8650.dtsi |   17 +
>  6 files changed, 95 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/vt8500-bv07.dts 
> b/arch/arm/boot/dts/vt8500-bv07.dts
> index 567cf4e..3cba367 100644
> --- a/arch/arm/boot/dts/vt8500-bv07.dts
> +++ b/arch/arm/boot/dts/vt8500-bv07.dts
> @@ -33,4 +33,12 @@
>   };
>   };
>   };
> +
> + backlight {
> + compatible = "pwm-backlight";
> + pwms = < 0 5>;
> +
> + brightness-levels = <0 4 8 16 32 64 128 255>;
> + default-brightness-level = <5>;
> + };
>  };
> diff --git a/arch/arm/boot/dts/vt8500.dtsi b/arch/arm/boot/dts/vt8500.dtsi
> index d8645e9..e196b2e 100644
> --- a/arch/arm/boot/dts/vt8500.dtsi
> +++ b/arch/arm/boot/dts/vt8500.dtsi
> @@ -40,14 +40,43 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>  
> + ref25: ref25M {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <2500>;
> + };
> +
>   ref24: ref24M {
>   #clock-cells = <0>;
>   compatible = "fixed-clock";
>   clock-frequency = <2400>;
>   };
> +
> + pllb: pllb {
> + #clock-cells = <0>;
> + compatible = "via,vt8500-pll-clock";
> + clocks = <>;
> + reg = <0x204>;
> + };
> +
> + clkpwm: pwm {
> + #clock-cells = <0>;
> + compatible = "via,vt8500-device-clock";
> + clocks = <>;
> + divisor-reg = <0x348>;
> + enable-reg = <0x250>;
> + enable-bit = <14>;
> + };
>   };
>   };
>  
> + pwm: pwm@d822 {
> + #pwm-cells = <2>;
> + compatible = "via,vt8500-pwm";
> + reg = <0xd822 0x100>;
> + clocks = <>;
> + };
> +
>   timer@d8130100 {
>   compatible = "via,vt8500-timer";
>   reg = <0xd8130100 0x28>;
> diff --git a/arch/arm/boot/dts/wm8505-ref.dts 
> b/arch/arm/boot/dts/wm8505-ref.dts
> index fd4e248..f51c0ed 100644
> --- a/arch/arm/boot/dts/wm8505-ref.dts
> +++ b/arch/arm/boot/dts/wm8505-ref.dts
> @@ -33,4 +33,12 @@
>   };
>   };
>   };
> +
> + backlight {
> + compatible = "pwm-backlight";
> + pwms = < 0 5>;
> +
> + brightness-levels = <0 4 8 16 32 64 128 255>;
> + default-brightness-level = <5>;
> + };
>  };
> diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
> index b459691..83c8ec5 100644
> --- a/arch/arm/boot/dts/wm8505.dtsi
> +++ b/arch/arm/boot/dts/wm8505.dtsi
> @@ -54,14 +54,43 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>  
> + ref25: ref25M {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <2500>;
> + };
> +
>   ref24: ref24M {
>   #clock-cells = <0>;
>   compatible = "fixed-clock";
>   clock-frequency = <2400>;
>   };
> +
> + pllb: pllb {
> + #clock-cells = <0>;
> + compatible = "via,vt8500-pll-clock";
> + clocks = <>;
> + reg = <0x204>;
> + };
> +
> +

Re: linux-next: build failure after merge of the final tree (tip/s390 trees related)

[Ingo Molnar]

* Peter Zijlstra  wrote:

> On Thu, 2012-10-18 at 17:02 +0200, Ralf Baechle wrote:
> >   CC  mm/huge_memory.o
> > mm/huge_memory.c: In function ???do_huge_pmd_prot_none???:
> > mm/huge_memory.c:789:3: error: incompatible type for argument 3 of 
> > ???update_mmu_cache???
> 
> That appears to have become update_mmu_cache_pmd(), which 
> makes sense given that there's now architectures that care 
> about it.

Ok, I fixed it as per below. Does everyone agree?

Thanks,

Ingo

>
>From 6e683978132907ff339e8a01a4d901c75709e62c Mon Sep 17 00:00:00 2001
From: Ingo Molnar 
Date: Sat, 20 Oct 2012 00:33:01 +0200
Subject: [PATCH] MIPS/thp: Fix update_mmu_cache() cache call

As per recent upstream commit:

  b113da65785d mm: Add and use update_mmu_cache_pmd() in transparent huge page 
code.

The call in do_huge_pmd_prot_none() needs to call update_mmu_cache_pmd()
as well.

This resolves a MIPS build error triggered on linux-next.

Reported-by: Ralf Baechle 
Reported-by: Stephen Rothwell 
Acked-by: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20121018145101.ga17...@linux-mips.org
Signed-off-by: Ingo Molnar 
---
 mm/huge_memory.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 8100c01..57c5018 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -770,7 +770,7 @@ fixup:
/* change back to regular protection */
entry = pmd_modify(entry, vma->vm_page_prot);
set_pmd_at(mm, haddr, pmd, entry);
-   update_mmu_cache(vma, address, entry);
+   update_mmu_cache_pmd(vma, address, entry);
 
 unlock:
spin_unlock(>page_table_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: [PATCH V3 0/3] PNP: Allow PNP resources to be disabled (interface)

[Rafael J. Wysocki]

On Friday 19 of October 2012 21:02:20 Witold Szczeponik wrote:
> On 18/09/12 23:42, Rafael J. Wysocki wrote:
> 
> > Hi,
> > 
> > On Sunday, September 16, 2012, Witold Szczeponik wrote:
> >> Hi Rafael, 
> >>
> >> what about the patches 1 and 3 which do not make any changes to the ABI?
> >> The first patch simplifies the code, while the third patch fixes a problem 
> >> in
> >> the PNP resource allocation.  Any chances to have them included in 3.7?
> > 
> > They would be fine as far as I'm concerned, but I'm not maintaining that 
> > part
> > of the kernel (at least at the moment).
> > 
> > I'm not sure who's the maintainer of it, to be honest.
> 
> Well, according to https://lkml.org/lkml/2012/10/19/375, that would be you
> (together with Bjorn and Len).  :-)  Hence I am resending the request for
> inclusion to you as well.  PNP code went, if I am not mistaken, traditionally
> through Len's tree.  

OK, so can you please resend them?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Documentation/sparse.txt: document context annotations for lock checking

[Christopher Li]

On Thu, Oct 18, 2012 at 7:27 AM, Ed Cashin  wrote:
> The context feature of sparse is used with the Linux kernel
> sources to check for imbalanced uses of locks.  Document the
> annotations defined in include/linux/compiler.h that tell sparse
> what to expect when a lock is held on function entry, exit, or
> both.
>
> Signed-off-by: Ed Cashin 

Signed-off-by: Christopher Li 

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

[Ryan Mallon]

On 19/10/12 21:07, Linus Walleij wrote:

> On Wed, Oct 17, 2012 at 1:41 AM, Ryan Mallon  wrote:
> 
>> The gpio_export function uses nested if statements and the status
>> variable to handle the failure cases. This makes the function logic
>> difficult to follow. Refactor the code to abort immediately on failure
>> using goto. This makes the code slightly longer, but significantly
>> reduces the nesting and number of split lines and makes the code easier
>> to read.
>>
>> Signed-off-by: Ryan Mallon
> 
> Very good initiative!
> 
>> +++ b/drivers/gpio/gpiolib.c
>> @@ -702,68 +702,74 @@ int gpio_export(unsigned gpio, bool 
>> direction_may_change)
>>  {
>> unsigned long   flags;
>> struct gpio_desc*desc;
>> -   int status = -EINVAL;
>> +   int status;
>> const char  *ioname = NULL;
>> +   struct device   *dev;
>>
>> /* can't export until sysfs is available ... */
>> if (!gpio_class.p) {
>> pr_debug("%s: called too early!\n", __func__);
>> -   return -ENOENT;
>> +   status = -ENOENT;
>> +   goto fail;
> 
> Why bother with all the goto:s here since there are no resources
> to clean up? Just pr_debug() and return -ENOENT; is good enough.
> 
> I don't quite see the point.

I did it this way just so that there would be a single exit point.
I don't mind either way, so I'll update the ones without any
clean up to simply return.

> Arguably this should be pr_err() or something BTW, just debug()
> may hide serious bugs.


Not sure about that. User-space can check the return code if it
wants to find out why the call failed. We shouldn't 
unconditionally spam the log with error messages on sysfs 
access since it makes an easy DoS vector on the syslog. The
pr_debug messages I think are really for people who are 
developing on gpiolib.

~Ryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 09/76] lockd: use rpc clients cl_nodename for id encoding

[Ben Hutchings]

On Fri, Oct 19, 2012 at 11:10:30PM +0100, Ben Hutchings wrote:
> On Thu, Oct 18, 2012 at 07:46:33PM -0700, Greg Kroah-Hartman wrote:
> > 3.6-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Stanislav Kinsbursky 
> > 
> > commit 303a7ce92064c285a04c870f2dc0192fdb2968cb upstream.
> > 
> > Taking hostname from uts namespace if not safe, because this cuold be
> > performind during umount operation on child reaper death. And in this case
> > current->nsproxy is NULL already.
[...]
> >  struct nsm_res {
> > @@ -141,6 +142,7 @@ static int nsm_mon_unmon(struct nsm_hand
> > .vers   = 3,
> > .proc   = NLMPROC_NSM_NOTIFY,
> > .mon_name   = nsm->sm_mon_name,
> > +   .nodename   = utsname()->nodename,
> 
> Can we be sure that this string pointer will remain valid at the point
> where current->nsproxy has become NULL?  Or should nsm_args::nodename
> actually be a copy of the string?
[...]

Never mind, the following patch seems to deal with that.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 09/76] lockd: use rpc clients cl_nodename for id encoding

[Ben Hutchings]

On Thu, Oct 18, 2012 at 07:46:33PM -0700, Greg Kroah-Hartman wrote:
> 3.6-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Stanislav Kinsbursky 
> 
> commit 303a7ce92064c285a04c870f2dc0192fdb2968cb upstream.
> 
> Taking hostname from uts namespace if not safe, because this cuold be
> performind during umount operation on child reaper death. And in this case
> current->nsproxy is NULL already.
> 
> Signed-off-by: Stanislav Kinsbursky 
> Signed-off-by: Trond Myklebust 
> Signed-off-by: Greg Kroah-Hartman 
> 
> ---
>  fs/lockd/mon.c |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> --- a/fs/lockd/mon.c
> +++ b/fs/lockd/mon.c
> @@ -42,6 +42,7 @@ struct nsm_args {
>   u32 proc;
>  
>   char*mon_name;
> + char*nodename;
>  };
>  
>  struct nsm_res {
> @@ -141,6 +142,7 @@ static int nsm_mon_unmon(struct nsm_hand
>   .vers   = 3,
>   .proc   = NLMPROC_NSM_NOTIFY,
>   .mon_name   = nsm->sm_mon_name,
> + .nodename   = utsname()->nodename,

Can we be sure that this string pointer will remain valid at the point
where current->nsproxy has become NULL?  Or should nsm_args::nodename
actually be a copy of the string?

Ben.

>   };
>   struct rpc_message msg = {
>   .rpc_argp   = ,
> @@ -477,7 +479,7 @@ static void encode_my_id(struct xdr_stre
>  {
>   __be32 *p;
>  
> - encode_nsm_string(xdr, utsname()->nodename);
> + encode_nsm_string(xdr, argp->nodename);
>   p = xdr_reserve_space(xdr, 4 + 4 + 4);
>   *p++ = cpu_to_be32(argp->prog);
>   *p++ = cpu_to_be32(argp->vers);

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] staging: et131x: Remove USE_FBR0 define and #ifdefs

[Mark Einon]

USE_FBR0 has always been defined, even in the original driver code.
Remove the define and #ifdef code to leave the code in the same state.

Signed-off-by: Mark Einon 
---
 drivers/staging/et131x/et131x.c |   58 +--
 1 file changed, 7 insertions(+), 51 deletions(-)

diff --git a/drivers/staging/et131x/et131x.c b/drivers/staging/et131x/et131x.c
index 32f909a..c33cafd 100644
--- a/drivers/staging/et131x/et131x.c
+++ b/drivers/staging/et131x/et131x.c
@@ -176,20 +176,13 @@ MODULE_DESCRIPTION("10/100/1000 Base-T Ethernet Driver 
for the ET1310 by Agere S
 #define PARM_DMA_CACHE_DEF  0
 
 /* RX defines */
-#define USE_FBR0 1
 #define FBR_CHUNKS 32
 #define MAX_DESC_PER_RING_RX 1024
 
 /* number of RFDs - default and min */
-#ifdef USE_FBR0
 #define RFD_LOW_WATER_MARK 40
 #define NIC_DEFAULT_NUM_RFD1024
 #define NUM_FBRS   2
-#else
-#define RFD_LOW_WATER_MARK 20
-#define NIC_DEFAULT_NUM_RFD256
-#define NUM_FBRS   1
-#endif
 
 #define NIC_MIN_NUM_RFD64
 #define NUM_PACKETS_HANDLED256
@@ -871,7 +864,7 @@ static void et131x_rx_dma_enable(struct et131x_adapter 
*adapter)
csr |= 0x1000;
else if (adapter->rx_ring.fbr[0]->buffsize == 16384)
csr |= 0x1800;
-#ifdef USE_FBR0
+
csr |= 0x0400;  /* FBR0 enable */
if (adapter->rx_ring.fbr[1]->buffsize == 256)
csr |= 0x0100;
@@ -879,7 +872,6 @@ static void et131x_rx_dma_enable(struct et131x_adapter 
*adapter)
csr |= 0x0200;
else if (adapter->rx_ring.fbr[1]->buffsize == 1024)
csr |= 0x0300;
-#endif
writel(csr, >regs->rxdma.csr);
 
csr = readl(>regs->rxdma.csr);
@@ -1909,7 +1901,6 @@ static void et131x_config_rx_dma_regs(struct 
et131x_adapter *adapter)
   ((rx_local->fbr[0]->num_entries * LO_MARK_PERCENT_FOR_RX) / 100) - 1,
   _dma->fbr1_min_des);
 
-#ifdef USE_FBR0
/* Now's the best time to initialize FBR0 contents */
fbr_entry = (struct fbr_desc *) rx_local->fbr[1]->ring_virtaddr;
for (entry = 0; entry < rx_local->fbr[1]->num_entries; entry++) {
@@ -1933,7 +1924,6 @@ static void et131x_config_rx_dma_regs(struct 
et131x_adapter *adapter)
writel(
   ((rx_local->fbr[1]->num_entries * LO_MARK_PERCENT_FOR_RX) / 100) - 1,
   _dma->fbr0_min_des);
-#endif
 
/* Program the number of packets we will receive before generating an
 * interrupt.
@@ -2305,9 +2295,7 @@ static int et131x_rx_dma_memory_alloc(struct 
et131x_adapter *adapter)
rx_ring = >rx_ring;
 
/* Alloc memory for the lookup table */
-#ifdef USE_FBR0
rx_ring->fbr[1] = kmalloc(sizeof(struct fbr_lookup), GFP_KERNEL);
-#endif
rx_ring->fbr[0] = kmalloc(sizeof(struct fbr_lookup), GFP_KERNEL);
 
/* The first thing we will do is configure the sizes of the buffer
@@ -2329,35 +2317,25 @@ static int et131x_rx_dma_memory_alloc(struct 
et131x_adapter *adapter)
 */
 
if (adapter->registry_jumbo_packet < 2048) {
-#ifdef USE_FBR0
rx_ring->fbr[1]->buffsize = 256;
rx_ring->fbr[1]->num_entries = 512;
-#endif
rx_ring->fbr[0]->buffsize = 2048;
rx_ring->fbr[0]->num_entries = 512;
} else if (adapter->registry_jumbo_packet < 4096) {
-#ifdef USE_FBR0
rx_ring->fbr[1]->buffsize = 512;
rx_ring->fbr[1]->num_entries = 1024;
-#endif
rx_ring->fbr[0]->buffsize = 4096;
rx_ring->fbr[0]->num_entries = 512;
} else {
-#ifdef USE_FBR0
rx_ring->fbr[1]->buffsize = 1024;
rx_ring->fbr[1]->num_entries = 768;
-#endif
rx_ring->fbr[0]->buffsize = 16384;
rx_ring->fbr[0]->num_entries = 128;
}
 
-#ifdef USE_FBR0
adapter->rx_ring.psr_num_entries =
adapter->rx_ring.fbr[1]->num_entries +
adapter->rx_ring.fbr[0]->num_entries;
-#else
-   adapter->rx_ring.psr_num_entries = adapter->rx_ring.fbr[0]->num_entries;
-#endif
 
/* Allocate an area of memory for Free Buffer Ring 1 */
bufsize = (sizeof(struct fbr_desc) * rx_ring->fbr[0]->num_entries) +
@@ -2381,7 +2359,6 @@ static int et131x_rx_dma_memory_alloc(struct 
et131x_adapter *adapter)
(void *)((u8 *) rx_ring->fbr[0]->ring_virtaddr +
rx_ring->fbr[0]->offset);
 
-#ifdef USE_FBR0
/* Allocate an area of memory for Free Buffer Ring 0 */
bufsize = (sizeof(struct fbr_desc) * rx_ring->fbr[1]->num_entries) +
0xfff;
@@ -2403,7 +2380,7 @@ static int et131x_rx_dma_memory_alloc(struct 
et131x_adapter *adapter)
rx_ring->fbr[1]->ring_virtaddr =
(void *)((u8 *) rx_ring->fbr[1]->ring_virtaddr +
   

[PATCH 2/3] staging: et131x: Use upper_32_bits() instead of '>> 32'

[Mark Einon]

>From a previous comment by Alan Cox:
'>> 32 of a 32bit value is undefined in C. The compiler is free
to do what it likes with this...'

Change all uses of '>> 32' to use upper_32_bits() and use
the corresponding lower_32_bits() to match.

Also remove an incorrect comment about dma alloc always returning 32bit
addresses.

Signed-off-by: Mark Einon 
---
 drivers/staging/et131x/et131x.c |   55 ++-
 1 file changed, 25 insertions(+), 30 deletions(-)

diff --git a/drivers/staging/et131x/et131x.c b/drivers/staging/et131x/et131x.c
index 3fd8142..32f909a 100644
--- a/drivers/staging/et131x/et131x.c
+++ b/drivers/staging/et131x/et131x.c
@@ -1859,25 +1859,17 @@ static void et131x_config_rx_dma_regs(struct 
et131x_adapter *adapter)
/* Halt RXDMA to perform the reconfigure.  */
et131x_rx_dma_disable(adapter);
 
-   /* Load the completion writeback physical address
-*
-* NOTE : dma_alloc_coherent(), used above to alloc DMA regions,
-* ALWAYS returns SAC (32-bit) addresses. If DAC (64-bit) addresses
-* are ever returned, make sure the high part is retrieved here
-* before storing the adjusted address.
-*/
-   writel((u32) ((u64)rx_local->rx_status_bus >> 32),
-  _dma->dma_wb_base_hi);
-   writel((u32) rx_local->rx_status_bus, _dma->dma_wb_base_lo);
+   /* Load the completion writeback physical address */
+   writel(upper_32_bits(rx_local->rx_status_bus), _dma->dma_wb_base_hi);
+   writel(lower_32_bits(rx_local->rx_status_bus), _dma->dma_wb_base_lo);
 
memset(rx_local->rx_status_block, 0, sizeof(struct rx_status_block));
 
/* Set the address and parameters of the packet status ring into the
 * 1310's registers
 */
-   writel((u32) ((u64)rx_local->ps_ring_physaddr >> 32),
-  _dma->psr_base_hi);
-   writel((u32) rx_local->ps_ring_physaddr, _dma->psr_base_lo);
+   writel(upper_32_bits(rx_local->ps_ring_physaddr), _dma->psr_base_hi);
+   writel(lower_32_bits(rx_local->ps_ring_physaddr), _dma->psr_base_lo);
writel(rx_local->psr_num_entries - 1, _dma->psr_num_des);
writel(0, _dma->psr_full_offset);
 
@@ -1902,9 +1894,10 @@ static void et131x_config_rx_dma_regs(struct 
et131x_adapter *adapter)
/* Set the address and parameters of Free buffer ring 1 (and 0 if
 * required) into the 1310's registers
 */
-   writel((u32) (rx_local->fbr[0]->ring_physaddr >> 32),
+   writel(upper_32_bits(rx_local->fbr[0]->ring_physaddr),
   _dma->fbr1_base_hi);
-   writel((u32) rx_local->fbr[0]->ring_physaddr, _dma->fbr1_base_lo);
+   writel(lower_32_bits(rx_local->fbr[0]->ring_physaddr),
+  _dma->fbr1_base_lo);
writel(rx_local->fbr[0]->num_entries - 1, _dma->fbr1_num_des);
writel(ET_DMA10_WRAP, _dma->fbr1_full_offset);
 
@@ -1926,9 +1919,10 @@ static void et131x_config_rx_dma_regs(struct 
et131x_adapter *adapter)
fbr_entry++;
}
 
-   writel((u32) (rx_local->fbr[1]->ring_physaddr >> 32),
+   writel(upper_32_bits(rx_local->fbr[1]->ring_physaddr),
   _dma->fbr0_base_hi);
-   writel((u32) rx_local->fbr[1]->ring_physaddr, _dma->fbr0_base_lo);
+   writel(lower_32_bits(rx_local->fbr[1]->ring_physaddr),
+  _dma->fbr0_base_lo);
writel(rx_local->fbr[1]->num_entries - 1, _dma->fbr0_num_des);
writel(ET_DMA10_WRAP, _dma->fbr0_full_offset);
 
@@ -1970,18 +1964,19 @@ static void et131x_config_tx_dma_regs(struct 
et131x_adapter *adapter)
struct txdma_regs __iomem *txdma = >regs->txdma;
 
/* Load the hardware with the start of the transmit descriptor ring. */
-   writel((u32) ((u64)adapter->tx_ring.tx_desc_ring_pa >> 32),
+   writel(upper_32_bits(adapter->tx_ring.tx_desc_ring_pa),
   >pr_base_hi);
-   writel((u32) adapter->tx_ring.tx_desc_ring_pa,
+   writel(lower_32_bits(adapter->tx_ring.tx_desc_ring_pa),
   >pr_base_lo);
 
/* Initialise the transmit DMA engine */
writel(NUM_DESC_PER_RING_TX - 1, >pr_num_des);
 
/* Load the completion writeback physical address */
-   writel((u32)((u64)adapter->tx_ring.tx_status_pa >> 32),
-   >dma_wb_base_hi);
-   writel((u32)adapter->tx_ring.tx_status_pa, >dma_wb_base_lo);
+   writel(upper_32_bits(adapter->tx_ring.tx_status_pa),
+  >dma_wb_base_hi);
+   writel(lower_32_bits(adapter->tx_ring.tx_status_pa),
+  >dma_wb_base_lo);
 
*adapter->tx_ring.tx_status = 0;
 
@@ -2460,16 +2455,16 @@ static int et131x_rx_dma_memory_alloc(struct 
et131x_adapter *adapter)
 * so the device can access it
 */
rx_ring->fbr[0]->bus_high[index] =
-   (u32) (fbr1_tmp_physaddr >> 32);
+ 

[PATCH 1/3] staging: et131x: Remove fbr_lookup.real_physaddr

[Mark Einon]

fbr_lookup.real_physaddr is only being used as a pseudonym for
fbr_lookup.ring_physaddr, so remove it and rename all instances to
ring_physaddr.

Signed-off-by: Mark Einon 
---
 drivers/staging/et131x/et131x.c |   31 ++-
 1 file changed, 6 insertions(+), 25 deletions(-)

diff --git a/drivers/staging/et131x/et131x.c b/drivers/staging/et131x/et131x.c
index 23d166b..3fd8142 100644
--- a/drivers/staging/et131x/et131x.c
+++ b/drivers/staging/et131x/et131x.c
@@ -299,7 +299,6 @@ struct fbr_lookup {
dma_addr_t   ring_physaddr;
void*mem_virtaddrs[MAX_DESC_PER_RING_RX / FBR_CHUNKS];
dma_addr_t   mem_physaddrs[MAX_DESC_PER_RING_RX / FBR_CHUNKS];
-   u64  real_physaddr;
u64  offset;
u32  local_full;
u32  num_entries;
@@ -1903,9 +1902,9 @@ static void et131x_config_rx_dma_regs(struct 
et131x_adapter *adapter)
/* Set the address and parameters of Free buffer ring 1 (and 0 if
 * required) into the 1310's registers
 */
-   writel((u32) (rx_local->fbr[0]->real_physaddr >> 32),
+   writel((u32) (rx_local->fbr[0]->ring_physaddr >> 32),
   _dma->fbr1_base_hi);
-   writel((u32) rx_local->fbr[0]->real_physaddr, _dma->fbr1_base_lo);
+   writel((u32) rx_local->fbr[0]->ring_physaddr, _dma->fbr1_base_lo);
writel(rx_local->fbr[0]->num_entries - 1, _dma->fbr1_num_des);
writel(ET_DMA10_WRAP, _dma->fbr1_full_offset);
 
@@ -1927,9 +1926,9 @@ static void et131x_config_rx_dma_regs(struct 
et131x_adapter *adapter)
fbr_entry++;
}
 
-   writel((u32) (rx_local->fbr[1]->real_physaddr >> 32),
+   writel((u32) (rx_local->fbr[1]->ring_physaddr >> 32),
   _dma->fbr0_base_hi);
-   writel((u32) rx_local->fbr[1]->real_physaddr, _dma->fbr0_base_lo);
+   writel((u32) rx_local->fbr[1]->ring_physaddr, _dma->fbr0_base_lo);
writel(rx_local->fbr[1]->num_entries - 1, _dma->fbr0_num_des);
writel(ET_DMA10_WRAP, _dma->fbr0_full_offset);
 
@@ -2378,18 +2377,9 @@ static int et131x_rx_dma_memory_alloc(struct 
et131x_adapter *adapter)
return -ENOMEM;
}
 
-   /* Save physical address
-*
-* NOTE: dma_alloc_coherent(), used above to alloc DMA regions,
-* ALWAYS returns SAC (32-bit) addresses. If DAC (64-bit) addresses
-* are ever returned, make sure the high part is retrieved here
-* before storing the adjusted address.
-*/
-   rx_ring->fbr[0]->real_physaddr = rx_ring->fbr[0]->ring_physaddr;
-
/* Align Free Buffer Ring 1 on a 4K boundary */
et131x_align_allocated_memory(adapter,
- _ring->fbr[0]->real_physaddr,
+ _ring->fbr[0]->ring_physaddr,
  _ring->fbr[0]->offset, 0x0FFF);
 
rx_ring->fbr[0]->ring_virtaddr =
@@ -2410,18 +2400,9 @@ static int et131x_rx_dma_memory_alloc(struct 
et131x_adapter *adapter)
return -ENOMEM;
}
 
-   /* Save physical address
-*
-* NOTE: dma_alloc_coherent(), used above to alloc DMA regions,
-* ALWAYS returns SAC (32-bit) addresses. If DAC (64-bit) addresses
-* are ever returned, make sure the high part is retrieved here before
-* storing the adjusted address.
-*/
-   rx_ring->fbr[1]->real_physaddr = rx_ring->fbr[1]->ring_physaddr;
-
/* Align Free Buffer Ring 0 on a 4K boundary */
et131x_align_allocated_memory(adapter,
- _ring->fbr[1]->real_physaddr,
+ _ring->fbr[1]->ring_physaddr,
  _ring->fbr[1]->offset, 0x0FFF);
 
rx_ring->fbr[1]->ring_virtaddr =
-- 
1.7.9.5

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

Re: x2apic boot failure on recent sandy bridge system

[rrl125]

Any update? The messages just seem to have stopped months ago. A fallback would 
be nice, I have been booting the kernel with noa2xpic for since kernel 3.2, and 
currently I am working with 3.6.2.

If needed I can try to attempt modifying the patch to include fallback, but I 
am probably not the best person to do it.

On Sunday, December 18, 2011 3:49:27 AM UTC-5, Ingo Molnar wrote:
> * Berck E. Nash  wrote:
> 
> 
> 
> > On 12/12/2011 10:13 PM, Yinghai Lu wrote:
> 
> > > please check -v7.
> 
> > 
> 
> > Works just fine for me.
> 
> 
> 
> That's interesting.
> 
> 
> 
> Now if this could be made completely automatic (no extra 
> 
> parameter passing), then we have a usable fallback mode - which 
> 
> is preferred to crashing the box.
> 
> 
> 
> Thanks,
> 
> 
> 
>   Ingo
> 
> --
> 
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> 
> the body of a message to majord...@vger.kernel.org
> 
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> Please read the FAQ at  http://www.tux.org/lkml/

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

Re: [PATCH 1/2] cpufreq: return early from __cpufreq_driver_getavg()

[Rafael J. Wysocki]

On Saturday 20 of October 2012 01:42:05 Viresh Kumar wrote:
> There is no need to do cpufreq_get_cpu() and cpufreq_put_cpu() for drivers 
> that
> don't support getavg() routine.
> 
> Signed-off-by: Viresh Kumar 

The patch doesn't seem to follow the changelog or the other way around.

Thanks,
Rafael


> ---
>  drivers/cpufreq/cpufreq.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 85df538..f552d5f 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1511,12 +1511,14 @@ int __cpufreq_driver_getavg(struct cpufreq_policy 
> *policy, unsigned int cpu)
>  {
>   int ret = 0;
>  
> + if (!(cpu_online(cpu) && cpufreq_driver->getavg))
> + return 0;
> +
>   policy = cpufreq_cpu_get(policy->cpu);
>   if (!policy)
>   return -EINVAL;
>  
> - if (cpu_online(cpu) && cpufreq_driver->getavg)
> - ret = cpufreq_driver->getavg(policy, cpu);
> + ret = cpufreq_driver->getavg(policy, cpu);
>  
>   cpufreq_cpu_put(policy);
>   return ret;
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: sign the modules at install time

[Linus Torvalds]

On Fri, Oct 19, 2012 at 12:58 PM, Linus Torvalds
 wrote:
>
> Tssk. I fixed it up, and now it works-for-me(tm), but some perl person
> probably really should try to make that sign-file and x509keyid merge.
> My fix made the thing even slower, doing two extra "wc -c" invocations
> since it can't do "${#..}" expansion due to the locale problem.

Hmm. I haven't seen this breakage personally yet, but looking more at
Rusty's last changes I'm pretty sure my fixes are potentially not
sufficient.

In particular, this line from Rusty's sign-file script simplification
makes me worry:

  KEYID="`perl $keyid_script $x509 keyid`"

and the problem is that the 'keyid' is a binary blob.

And I'm pretty damn sure that assigning random binary data to shell
variables is going to break eventually. In particular, I tested NUL
characters, and bash is not happy about doing things like

   a="`echo -en '\000'`"

and 'a' ends up empty, not containing a one-byte string containing a
NUL character. Not to mention that even if the shell were to handle
this correctly, if you do

  echo -n "$a"

then even *if* the shell remembered that 'a' contains one NUL
character, when it then executes the 'echo' binary, that will
certainly not be able to handle it. With a built-in 'echo' it _could_
work, with an external one it fundamentally could not. NUL is special,
and terminates strings at execve(). You cannot have NUL bytes in
arguments.

Of course, I don't know the rules for x509 key id blobs. Maybe they
aren't allowed to contain NUL anyway?

Possible solutions:

 - Linus is a worry-wart, and key id's never contain NUL.

 - somebody with the appropriate perl-fu does the perl conversion, and
keeps it all in perl.

 - somebody with (slightly less) perl-fu makes the x509 keyid_script
return a quoted string, so that we can save that *quoted* version for
the shell interatction (perhaps in a similar format that we now use
for the "prologue" variable, ie just a list of hex bytes)

otherwise we need to go back to putting the binary blob in a file
(which shell won't corrupt).

Rusty, David?

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

Re: linux-next: build failure after merge of the final tree (tip/s390 trees related)

[Peter Zijlstra]

On Thu, 2012-10-18 at 17:02 +0200, Ralf Baechle wrote:
>   CC  mm/huge_memory.o
> mm/huge_memory.c: In function ‘do_huge_pmd_prot_none’:
> mm/huge_memory.c:789:3: error: incompatible type for argument 3 of 
> ‘update_mmu_cache’

That appears to have become update_mmu_cache_pmd(), which makes sense
given that there's now architectures that care about it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] acpi/cpuidle: reinitialize power_usage values when adding/removing C-states

[Julius Werner]

When cpuidle drivers do not supply explicit power_usage values,
cpuidle/driver.c inserts dummy values instead. When a running processor
dynamically gains new C-states (e.g. after ACPI events), the power_usage
values of those states will stay uninitialized, and cpuidle governors
will never choose to enter them.

This patch ensures that the ACPI cpuidle driver sets those dummy power
values itself whenever it (re-)initializes its idle states.
Tested and verified on an Acer AC700 Chromebook, which supports the C3
state only when it switches from AC to battery power.

Signed-off-by: Julius Werner 
---
 drivers/acpi/processor_idle.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index e8086c7..078e22f 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -1090,6 +1090,9 @@ static int acpi_processor_setup_cpuidle_states(struct 
acpi_processor *pr)
state->exit_latency = cx->latency;
state->target_residency = cx->latency * latency_factor;
 
+   /* reinitialize this in case new states are added after boot */
+   state->power_usage = -1 - count;
+
state->flags = 0;
switch (cx->type) {
case ACPI_STATE_C1:
-- 
1.7.8.6

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

[GIT PULL v3] ARM architecture fixes for 3.7

[Arnd Bergmann]

Hi Russell,

you never replied to the second version of the pull request, and it hasn't
shown up in linux-next or your git tree so far. I assume you've been busy
otherwise and missed it, so here is a friendly reminder.

The contents are still identical to what we had before after I fixed up
the changeset comment for the Xen patch.

Arnd

---
The following changes since commit 0e51793e162ca432fc5f04178cf82b80a92c2659:

  Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm 
(2012-10-07 21:20:57 +0900)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git 
tags/fixes-for-rmk

for you to fetch changes up to 8e7fc18b5eacc37b6e6fcf486ec4eafbfef91738:

  ARM: warnings in arch/arm/include/asm/uaccess.h (2012-10-09 20:29:07 +0200)


These bug fixes all address problems found with automated build testing.
Some of them have been around for a long time, other bugs are
regressions since the merge window.


Arnd Bergmann (9):
  ARM: kprobes: make more tests conditional
  ARM: export set_irq_flags
  ARM: Fix another build warning in arch/arm/mm/alignment.c
  ARM: export default read_current_timer
  ARM: Xen: fix initial build problems
  ARM: pass -marm to gcc by default for both C and assembler
  ARM: be really quiet when building with 'make -s'
  ARM: binfmt_flat: unused variable 'persistent'
  ARM: warnings in arch/arm/include/asm/uaccess.h

 arch/arm/Kconfig   |1 +
 arch/arm/Makefile  |   13 +++--
 arch/arm/boot/Makefile |   10 +-
 arch/arm/include/asm/flat.h|2 +-
 arch/arm/include/asm/uaccess.h |4 ++--
 arch/arm/kernel/irq.c  |2 ++
 arch/arm/kernel/kprobes-test-arm.c |4 
 arch/arm/lib/delay.c   |1 +
 arch/arm/mm/alignment.c|4 +++-
 arch/arm/tools/Makefile|2 +-
 drivers/xen/Kconfig|2 ++
 drivers/xen/sys-hypervisor.c   |1 +
 12 files changed, 30 insertions(+), 16 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the final tree (tip/s390 trees related)

[Ingo Molnar]

* Ralf Baechle  wrote:

> On Thu, Oct 18, 2012 at 05:22:01PM +1100, Stephen Rothwell wrote:
> 
> > After merging the final tree, today's linux-next build (s390 allyesconfig)
> > failed like this:
> > 
> > mm/huge_memory.c:1424:2: error: implicit declaration of function 
> > 'pmd_pgprot' [-Werror=implicit-function-declaration]
> > mm/huge_memory.c:1424:7: error: incompatible types when assigning to type 
> > 'pgprot_t' from type 'int'
> > 
> > (see http://kisskb.ellerman.id.au/kisskb/buildresult/7383823/)
> > 
> > Caused by commit 35d3d3427314 ("s390/thp: select
> > HAVE_ARCH_TRANSPARENT_HUGEPAGE") from the s390 tree interacting with
> > commit 93c9d633bd9e ("mm/thp: Preserve pgprot across huge page split")
> > from the tip tree.
> > 
> > N.B. Mips also selects HAVE_ARCH_TRANSPARENT_HUGEPAGE as of commit
> > e21a828a1bba ("MIPS: Transparent Huge Pages support") from the mips tree
> > and so will be broken in some configs now as well.
> > 
> > Anyone have suggested merge fix patches I can apply?
> 
> See below.  There's further MIPS breakage in -next; more on than in a
> separate email.
> 
>   Ralf
> 
> Signed-off-by: Ralf Baechle 

Thanks Ralf! I've applied it, with a changelog and a 
Reported-by: Stephen Rothwell line - see the commit below.

Note that I moved the definition slightly up, so that regardless 
of the order merging the commits don't create a conflict in 
linux-next. If that fine with you I'll push it out that way.

(Looking at the other MIPS problem as well.)

Thanks,

Ingo


>
>From 8cd7680d8b7241941fd51d83302677d58b447223 Mon Sep 17 00:00:00 2001
From: Ralf Baechle 
Date: Thu, 18 Oct 2012 16:51:01 +0200
Subject: [PATCH] MIPS/thp: Add pmd_pgprot() implementation

Resolve the semantic conflict between the new THP code
on MIPS and the new NUMA code, in linux-next, by adding
the pmd_pgprot() method needed by the NUMA code.

Reported-by: Stephen Rothwell 
Signed-off-by: Ralf Baechle 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20121018145101.ga17...@linux-mips.org
Signed-off-by: Ingo Molnar 
---
 arch/mips/include/asm/pgtable.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/mips/include/asm/pgtable.h b/arch/mips/include/asm/pgtable.h
index c02158b..bbe4cda 100644
--- a/arch/mips/include/asm/pgtable.h
+++ b/arch/mips/include/asm/pgtable.h
@@ -89,6 +89,8 @@ static inline int is_zero_pfn(unsigned long pfn)
 
 extern void paging_init(void);
 
+#define pmd_pgprot(x)  __pgprot(pmd_val(x) & ~_PAGE_CHG_MASK)
+
 /*
  * Conversion functions: convert a page and protection to a page entry,
  * and a page entry and page directory to the page they refer to.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] device_cgroup: rename deny_all to behavior

[Jiri Slaby]

> Signed-off-by: Jiri Slaby 

R U sure?^^^
As I don't remember myself ever seeing this patch...
Maybe I should start smoking some crap to refresh my memory?

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

Re: [PATCH 1/2] brw_mutex: big read-write mutex

[Paul E. McKenney]

On Thu, Oct 18, 2012 at 07:57:47PM +0200, Oleg Nesterov wrote:
> On 10/18, Paul E. McKenney wrote:
> >
> > On Thu, Oct 18, 2012 at 06:24:09PM +0200, Oleg Nesterov wrote:
> > >
> > > I thought that you meant that without mb() brw_start_write() can
> > > race with brw_end_read() and hang forever.
> > >
> > > But probably you meant that we need the barriers to ensure that,
> > > say, if the reader does
> > >
> > >   brw_start_read();
> > >   CONDITION = 1;
> > >   brw_end_read();
> > >
> > > then the writer must see CONDITION != 0 after brw_start_write() ?
> > > (or vice-versa)
> >
> > Yes, this is exactly my concern.
> 
> Oh, thanks at lot Paul (as always).

Glad it helped.  ;-)

> > > In this case we need the barrier, yes. Obviously brw_start_write()
> > > can return right after this_cpu_dec() and before wake_up_all().
> > >
> > > 2/2 doesn't need this guarantee but I agree, this doesn't look
> > > sane in gerenal...
> >
> > Or name it something not containing "lock".  And clearly document
> > the behavior and how it is to be used.  ;-)
> 
> this would be insane, I guess ;)

Well, I suppose you could call it a "phase" : brw_start_phase_1() and
so on.

> So. Ignoring the possible optimization you mentioned before,
> brw_end_read() should do:
> 
>   smp_mb();
>   this_cpu_dec();
> 
>   wake_up_all();
> 
> And yes, we need the full mb(). wmb() is enough to ensure that the
> writer will see the memory modifications done by the reader. But we
> also need to ensure that any LOAD inside start_read/end_read can not
> be moved outside of the critical section.
> 
> But we should also ensure that "read" will see all modifications
> which were done under start_write/end_write. This means that
> brw_end_write() needs another synchronize_sched() before
> atomic_dec_and_test(), or brw_start_read() needs mb() in the
> fast-path.
> 
> Correct?

Good point, I missed the need for synchronize_sched() to avoid
readers sleeping through the next write cycle due to racing with
an exiting writer.  But yes, this sounds correct.

> Ooooh. And I just noticed include/linux/percpu-rwsem.h which does
> something similar. Certainly it was not in my tree when I started
> this patch... percpu_down_write() doesn't allow multiple writers,
> but the main problem it uses msleep(1). It should not, I think.
> 
> But. It seems that percpu_up_write() is equally wrong? Doesn't
> it need synchronize_rcu() before "p->locked = false" ?
> 
> (add Mikulas)

Mikulas said something about doing an updated patch, so I figured I
would look at his next version.

Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 32/62] kdb,vt_console: Fix missed data due to pager overruns

[Ben Hutchings]

On Thu, Oct 18, 2012 at 07:45:00PM -0700, Greg Kroah-Hartman wrote:
> 3.4-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Jason Wessel 
> 
> commit 17b572e82032bc246324ce136696656b66d4e3f1 upstream.
[...]
> This also means that the vt screen needs to set the kdb COLUMNS
> variable.
[...]
> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -3475,6 +3475,19 @@ int con_debug_enter(struct vc_data *vc)
>   kdb_set(2, setargs);
>   }
>   }
> + if (vc->vc_cols < 999) {
> + int colcount;
> + char cols[4];
> + const char *setargs[3] = {
> + "set",
> + "COLUMNS",
> + cols,
> + };
> + if (kdbgetintenv(setargs[0], )) {
> + snprintf(cols, 4, "%i", vc->vc_cols);
> + kdb_set(2, setargs);
> + }
> + }

Presumably the idea here was to avoid overriding the 'COLUMNS'
variable if it is already set, but it's actually testing whether the
variable 'set' is set.  (Besides which, there should be a kdbsetenv()
instead of this gross hack of faking up a user command.  And whyever
did kdb have to make argc off-by-one from the usual C convention?)

[...]
> + if (KDB_STATE(PAGER)) {
> + /*
> +  * Check printed string to decide how to bump the
> +  * kdb_nextline to control when the more prompt should
> +  * show up.
> +  */
> + int got = 0;
> + len = retlen;
> + while (len--) {
> + if (kdb_buffer[len] == '\n') {
> + kdb_nextline++;
> + got = 0;
> + } else if (kdb_buffer[len] == '\r') {
> + got = 0;
> + } else {
> + got++;
> + }
> + }
> + kdb_nextline += got / (colcount + 1);

What if more than one logical line is wrapped?
Why divide by colcount + 1?  Shouldn't it be (got - 1) / colcount?
 
Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the final tree (tip/s390 trees related)

[Ingo Molnar]

* Gerald Schaefer  wrote:

> On Thu, 18 Oct 2012 17:22:01 +1100
> Stephen Rothwell  wrote:
> 
> > Hi all,
> > 
> > After merging the final tree, today's linux-next build (s390 allyesconfig)
> > failed like this:
> > 
> > mm/huge_memory.c:1424:2: error: implicit declaration of function 
> > 'pmd_pgprot' [-Werror=implicit-function-declaration]
> > mm/huge_memory.c:1424:7: error: incompatible types when assigning to type 
> > 'pgprot_t' from type 'int'
> > 
> > (see http://kisskb.ellerman.id.au/kisskb/buildresult/7383823/)
> > 
> > Caused by commit 35d3d3427314 ("s390/thp: select
> > HAVE_ARCH_TRANSPARENT_HUGEPAGE") from the s390 tree interacting with
> > commit 93c9d633bd9e ("mm/thp: Preserve pgprot across huge page split")
> > from the tip tree.
> > 
> > N.B. Mips also selects HAVE_ARCH_TRANSPARENT_HUGEPAGE as of commit
> > e21a828a1bba ("MIPS: Transparent Huge Pages support") from the mips tree
> > and so will be broken in some configs now as well.
> > 
> > Anyone have suggested merge fix patches I can apply?
> 
> Subject: [PATCH] s390/thp: implement pmd_pgprot() for s390

Thanks Gerald! I'll merge this as well so that the semantic 
conflict disappears from linux-next.

Thanks,

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