RE: Work queue questions

[Daniel Taylor]

 

> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org 
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of anish singh
> Sent: Friday, September 21, 2012 9:25 PM
> To: Deepawali Verma
> Cc: Tejun Heo; linux-kernel@vger.kernel.org
> Subject: Re: Work queue questions
> 
> On Sat, Sep 22, 2012 at 1:05 AM, Deepawali Verma 
>  wrote:
> > Hi Tajun,
> >
> > These three tasks are writing the three chunks of data in 
> parallel. I
> > am not getting improvement here otherwise what is difference between
> > writing these chunks one by one in single thread instead of 
> trying to
> > write the data by scheduling the work on three different workqueues
> > means 3 worker threads?
> You should have carefully read "If none of them blocks, there
> isn't much point in throwing more threads at them.  What are those
> thread doing?" what Tejun said.
> 
> I think what he means is that concurrency is the concept of 
> keeping the
> system busy.
> If you see the below logs:
> kworker/u:1-21[000]   110.964895: task_event: 
> MYTASKJOB2381 XStarted
> kworker/u:1-21[000]   110.964909: task_event: 
> MYTASKJOB2381 Xstopped
> Here your first worker thread blocked.
> 
> So the system will try to get other workqueue started which is:
> kworker/u:1-21[000]   110.965137: task_event: 
> MYTASKJOB2382 XStarted
> kworker/u:1-21[000]   110.965154: task_event: 
> MYTASKJOB2382 Xstopped
> Here again your second worker thread blocked.
> 
> So on so forth.
> Anyway how can you write chunks of data in parallel when 
> already some worker
> thread is writing i.e. the system is busy.
> Analogy: Suppose you are ambidextrous and you are eating.Can 
> you eat with
> both of your hands at a time?So worker thread are like your 
> hands and keeping
> you fed all the time is the concept of concurrency.
> 
> I am not an expert on this but from Tejun's reply I could 
> make out this.
> Please correct me If I have wrongly understood the concept 
> based on this mail

I don't know how many cores are in the CPU Deepawali's using, but if I have 
four,
for example, I could do something simplistic like copy pages A-G with one, pages
H-O with another, and pages Q-Z with a third.  There are memory and cache 
bottlenecks
(like the mouth, in your example), but all three copies could be running 
concurrently.

Copying, of course, is a silly, trivial example, and I hope there's a better 
reason
than that for the concurrency, but, if, for example, your needed to byte-swap, 
XOR,
or checksum, as core functionality of an embedded system, and the processing 
units were
available to do these things in parallel, then interleaving those operations 
with memory
accesses could provide higher throughput.

I think what he's asking is why there's no apparent concurrency, presuming that 
NONE
of his threads has a real reason to block.  With examining his code, I cannot 
tell,
but it looks like, from the messages, that the kernel did not attempt 
concurrency.
Perhaps he needs to pass additional state to the scheduler?


> chain.
> >
> > Regards,
> > Deepa
> >
> > On Fri, Sep 21, 2012 at 8:27 PM, Tejun Heo  wrote:
> >> On Fri, Sep 21, 2012 at 08:26:01PM +0100, Deepawali Verma wrote:
> >>>  kworker/u:1-21[000]   110.964895: task_event: 
> MYTASKJOB2381 XStarted
> >>>  kworker/u:1-21[000]   110.964909: task_event: 
> MYTASKJOB2381 Xstopped
> >>>  kworker/u:1-21[000]   110.965137: task_event: 
> MYTASKJOB2382 XStarted
> >>>  kworker/u:1-21[000]   110.965154: task_event: 
> MYTASKJOB2382 Xstopped
> >>>  kworker/u:5-3724  [000]   110.965311: task_event: 
> MYTASKJOB2383 XStarted
> >>>  kworker/u:5-3724  [000]   110.965325: task_event: 
> MYTASKJOB2383 Xstopped
> >>>
> >>> I have this one big task to whom I divided into small sub 
> tasks. These
> >>> are numbered 2381, 2382 and 2383, what was I expecting 
> that task 2381,
> >>> 2382, 2383 run in parallel. I have put start and stop 
> markers here so
> >>> that I can see how this concurrency managed work queue is 
> distributing
> >>> the load.
> >>>
> >>> I found that task no 2381 is started first and exited 
> before starting
> >>> task 2382 and so on. What I expected that it should start 
> the three
> >>> sub tasks in parallel, not one by one.
> >>>
> >>> Where is concurrency here?
> >>
> >> If none of them blocks, there isn't much point in throwing more
> >> threads at them.  What are those thread doing?
> >>
> >> Thanks.
> >>
> >> --
> >> tejun
> > --
> > To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  

Re: [PATCH v2] charger-manager: Add support sysfs entry for charger

[Kyungmin Park]

On 9/22/12, Anton Vorontsov  wrote:
> On Fri, Sep 21, 2012 at 06:49:37PM +0900, Chanwoo Choi wrote:
>> This patch add support sysfs entry for each charger(regulator).
>> Charger-manager use one or more chargers for charging battery but
>> some charger isn't necessary on specific scenario. So, if some charger
>> isn't needed, can disable specific charger through 'externally_control'
>> entry while system is on state and confirm the information(name, state)
>> of charger.
> [...]
>> the list of added sysfs entry
>> - /sys/class/power_supply/battery/chargers/charger.[index]/name
>> : show name of charger(regulator)
>> - /sys/class/power_supply/battery/chargers/charger.[index]/state
>> : show either enabled or disabled state of charger
>> -
>> /sys/class/power_supply/battery/chargers/charger.[index]/externally_control
>>
>> If 'externally_control' of specific charger is 1, Charger-manager cannot
>> enable
>> regulator for charging when charger cable is attached and charger must be
>> maintained with disabled state. If 'externally_control' is zero,
>> Charger-manager
>> usually can control to enable/disable regulator.
>>
>> Signed-off-by: Chanwoo Choi 
>> Signed-off-by: Myungjoo Ham 
>> Signed-off-by: Kyungmin Park 
>> ---
>
> Thanks for your work, folks!
>
> There are some serious issues wrt. the coding standards, though.
>
> (I must confess that because of the issues I didn't look much into the
> logic itself, I hope it works.)
>
>>  drivers/power/charger-manager.c   |  174
>> -
>>  include/linux/power/charger-manager.h |   19 
>>  2 files changed, 192 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/power/charger-manager.c
>> b/drivers/power/charger-manager.c
>> index e92ec55..a1ab825 100644
>> --- a/drivers/power/charger-manager.c
>> +++ b/drivers/power/charger-manager.c
>> @@ -22,6 +22,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  static const char * const default_event_names[] = {
>>  [CM_EVENT_UNKNOWN] = "Unknown",
>> @@ -332,6 +333,9 @@ static int try_charger_enable(struct charger_manager
>> *cm, bool enable)
>>  cm->charging_end_time = 0;
>>
>>  for (i = 0 ; i < desc->num_charger_regulators ; i++) {
>> +if (desc->charger_regulators[i].externally_control)
>> +continue;
>> +
>>  err = 
>> regulator_enable(desc->charger_regulators[i].consumer);
>>  if (err < 0) {
>>  dev_warn(cm->dev,
>> @@ -348,6 +352,9 @@ static int try_charger_enable(struct charger_manager
>> *cm, bool enable)
>>  cm->charging_end_time = ktime_to_ms(ktime_get());
>>
>>  for (i = 0 ; i < desc->num_charger_regulators ; i++) {
>> +if (desc->charger_regulators[i].externally_control)
>> +continue;
>> +
>>  err = 
>> regulator_disable(desc->charger_regulators[i].consumer);
>>  if (err < 0) {
>>  dev_warn(cm->dev,
>> @@ -1217,12 +1224,101 @@ static int charger_extcon_init(struct
>> charger_manager *cm,
>>  return ret;
>>  }
>>
>> +/* help function of sysfs node to control charger(regulator) */
>> +static ssize_t charger_name_show(struct device *dev,
>> +struct device_attribute *attr, char *buf)
>> +{
>> +struct charger_regulator *charger
>> += container_of(attr, struct charger_regulator, attr_name);
>
> Here must be an empty line.
>
>> +return sprintf(buf, "%s\n", charger->regulator_name);
>> +}
>> +
>> +static ssize_t charger_state_show(struct device *dev,
>> +struct device_attribute *attr, char *buf)
>> +{
>> +struct charger_regulator *charger
>> += container_of(attr, struct charger_regulator, attr_state);
>> +int state = 1;
>
> = 1 is not needed. Instead, you could rewrite it as
>
> int state = 0;
>
> if (!charger->externally_control)
>   state = regulator_is_enabled(charger->consumer);
>
>> +if (charger->externally_control)
>> +state = 0;
>> +else
>> +state = regulator_is_enabled(charger->consumer);
>> +
>> +return sprintf(buf, "%s\n", state ? "enabled" : "disabled");
>> +}
>> +
>> +static ssize_t charger_externally_control_show(struct device *dev,
>> +struct device_attribute *attr, char *buf)
>> +{
>> +struct charger_regulator *charger = container_of(attr,
>> +struct charger_regulator, attr_externally_control);
>
> Empty line is required.
>
>> +return sprintf(buf, "%d\n", charger->externally_control);
>> +}
>> +
>> +static ssize_t charger_externally_control_store(struct device *dev,
>> +struct device_attribute *attr, const char *buf,
>> +size_t count)
>> +{
>> +struct charger_regulator *charger
>> += container_of(attr, struct 

Re: [PATCH 01/14] davinci: vpfe: add dm3xx IPIPEIF hardware support module

[Prabhakar Lad]

Hi Laurent,

Thanks for the review.

On Thu, Sep 20, 2012 at 3:31 AM, Laurent Pinchart
 wrote:
> Hi Prabhakar,
>
> Thanks for the patch.
>
> On Friday 14 September 2012 18:16:31 Prabhakar Lad wrote:
>> From: Manjunath Hadli 
>>
>> add support for dm3xx IPIPEIF hardware setup. This is the
>> lowest software layer for the dm3x vpfe driver which directly
>> accesses hardware. Add support for features like default
>> pixel correction, dark frame substraction and hardware setup.
>>
>> Signed-off-by: Manjunath Hadli 
>> Signed-off-by: Lad, Prabhakar 
>> ---
>>  drivers/media/platform/davinci/dm3xx_ipipeif.c |  318 +
>>  drivers/media/platform/davinci/dm3xx_ipipeif.h |  262 +++
>>  include/linux/dm3xx_ipipeif.h  |   62 +
>
>
>>  3 files changed, 642 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/media/platform/davinci/dm3xx_ipipeif.c
>>  create mode 100644 drivers/media/platform/davinci/dm3xx_ipipeif.h
>>  create mode 100644 include/linux/dm3xx_ipipeif.h
>>
>> diff --git a/drivers/media/platform/davinci/dm3xx_ipipeif.c
>> b/drivers/media/platform/davinci/dm3xx_ipipeif.c new file mode 100644
>> index 000..7961a74
>> --- /dev/null
>> +++ b/drivers/media/platform/davinci/dm3xx_ipipeif.c
>
> [snip]
>
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>
> Just a side note, I usually sort headers alphabetically, but feel free to use
> whatever convention you like.
>
Ok I'll sort to.

>> +#include "dm3xx_ipipeif.h"
>> +
>> +static void *__iomem ipipeif_base_addr;
>
> That's not good. You shouldn't have global constants like that. The value
> should instead be stored in your device structure, that you will need to pass
> around to all functions.
>
Ok.

>> +static inline u32 regr_if(u32 offset)
>> +{
>> + return readl(ipipeif_base_addr + offset);
>> +}
>> +
>> +static inline void regw_if(u32 val, u32 offset)
>> +{
>> + writel(val, ipipeif_base_addr + offset);
>> +}
>
> Maybe ipipeif_read() and ipipeif_write() ?
>
>> +void ipipeif_set_enable()
>> +{
>> + regw_if(1, IPIPEIF_ENABLE);
>> +}
>
> Please define constants in a header file for register values, masks and shifts
> instead of hardcoding the raw numbers.
>
Ok.

> [snip]
>
>> +static int __devinit dm3xx_ipipeif_probe(struct platform_device *pdev)
>> +{
>> + static resource_size_t  res_len;
>> + struct resource *res;
>> + int status;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!res)
>> + return -ENOENT;
>> +
>> + res_len = resource_size(res);
>> +
>> + res = request_mem_region(res->start, res_len, res->name);
>> + if (!res)
>> + return -EBUSY;
>> +
>> + ipipeif_base_addr = ioremap_nocache(res->start, res_len);
>> + if (!ipipeif_base_addr) {
>> + status = -EBUSY;
>> + goto fail;
>> + }
>> + return 0;
>> +
>> +fail:
>> + release_mem_region(res->start, res_len);
>> +
>> + return status;
>> +}
>> +
>> +static int dm3xx_ipipeif_remove(struct platform_device *pdev)
>> +{
>> + struct resource *res;
>> +
>> + iounmap(ipipeif_base_addr);
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (res)
>> + release_mem_region(res->start, resource_size(res));
>> + return 0;
>> +}
>> +
>> +static struct platform_driver dm3xx_ipipeif_driver = {
>> + .driver = {
>> + .name   = "dm3xx_ipipeif",
>> + .owner = THIS_MODULE,
>> + },
>> + .remove = __devexit_p(dm3xx_ipipeif_remove),
>> + .probe = dm3xx_ipipeif_probe,
>> +};
>> +
>> +static int dm3xx_ipipeif_init(void)
>> +{
>> + return platform_driver_register(_ipipeif_driver);
>> +}
>> +
>> +static void dm3xx_ipipeif_exit(void)
>> +{
>> + platform_driver_unregister(_ipipeif_driver);
>> +}
>> +
>> +module_init(dm3xx_ipipeif_init);
>> +module_exit(dm3xx_ipipeif_exit);
>
> I'm not sure to like this. You're registering a module for a device that
> essentially sits there without doing anything, except providing functions that
> can be called by other modules.
>
> I somehow feel that the way the code is split amongst the different layers
> isn't optimal. Could you briefly explain the rationale behind the current
> architecture ?
>
> (BTW, please use the module_platform_driver() macro instead of
> module_init/module_exit)
>
As discussed over the IRC, I am working on new design, hopefully
you will be happy this time :)

> [snip]
>
>> diff --git a/include/linux/dm3xx_ipipeif.h b/include/linux/dm3xx_ipipeif.h
>> new file mode 100644
>> index 000..1c1a830
>> --- /dev/null
>> +++ b/include/linux/dm3xx_ipipeif.h
>
> [snip]
>
>> +#include 
>> +#include 
>
> This header file defines part of the userspace API, but includes media/
> headers that are not exported to userspace.
>
> Header files should be split between 3 directories:
>
> - Definitions required by platform data used to go to media/ but the new
> 

Re: [ACPI/PCI] possible recursive locking detected

[Yinghai Lu]

On Fri, Sep 21, 2012 at 5:35 PM, Fengguang Wu  wrote:
> Hi Taku,
>
> The below oops is pretty reproducible, and shows up first in:
>
> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git 
> pci/taku-acpi-pci-host-bridge-v3
> head:   e3faec8ea9c8aa683c56fa20ff2c58a4c5857960
> commit: d3c663236318a43fed5d86a643e6ea2534e9220e [5/7] PCI/ACPI: Protect 
> acpi_pci_roots list with mutex
>
> [8.613239]  (acpi_pci_root_lock){+.+.+.}, at: [] 
> acpi_get_pci_rootbridge_handle+0x22/0x63
> [8.613239]  (acpi_pci_root_lock){+.+.+.}, at: [] 
> acpi_get_pci_rootbridge_handle+0x22/0x63
> [8.613239]  (acpi_pci_root_lock){+.+.+.}, at: [] 
> acpi_pci_register_driver+0x21/0x79
> [8.613239]   lock(acpi_pci_root_lock);
> [8.613239]   lock(acpi_pci_root_lock);
> [8.613239]  #0:  (acpi_pci_root_lock){+.+.+.}, at: [] 
> acpi_pci_register_driver+0x21/0x79
> [8.613239]  [] ? 
> acpi_get_pci_rootbridge_handle+0x22/0x63
> [8.613239]  [] ? 
> acpi_get_pci_rootbridge_handle+0x22/0x63
> [8.613239]  [] ? 
> acpi_get_pci_rootbridge_handle+0x22/0x63
> [8.613239]  [] acpi_get_pci_rootbridge_handle+0x22/0x63
>
> [8.610859]
> [8.611385] =
> [8.612505] [ INFO: possible recursive locking detected ]
> [8.613239] 3.6.0-rc1-00022-gd3c6632 #7512 Not tainted
> [8.613239] -
> [8.613239] swapper/0/1 is trying to acquire lock:
> [8.613239]  (acpi_pci_root_lock){+.+.+.}, at: [] 
> acpi_get_pci_rootbridge_handle+0x22/0x63
> [8.613239]
> [8.613239] but task is already holding lock:
> [8.613239]  (acpi_pci_root_lock){+.+.+.}, at: [] 
> acpi_pci_register_driver+0x21/0x79
> [8.613239]
> [8.613239] other info that might help us debug this:
> [8.613239]  Possible unsafe locking scenario:
> [8.613239]
> [8.613239]CPU0
> [8.613239]
> [8.613239]   lock(acpi_pci_root_lock);
> [8.613239]   lock(acpi_pci_root_lock);
> [8.613239]
> [8.613239]  *** DEADLOCK ***
> [8.613239]
> [8.613239]  May be due to missing lock nesting notation
> [8.613239]
> [8.613239] 1 lock held by swapper/0/1:
> [8.613239]  #0:  (acpi_pci_root_lock){+.+.+.}, at: [] 
> acpi_pci_register_driver+0x21/0x79
> [8.613239]
> [8.613239] stack backtrace:
> [8.613239] Pid: 1, comm: swapper/0 Not tainted 3.6.0-rc1-00022-gd3c6632 
> #7512
> [8.613239] Call Trace:
> [8.613239]  [] __lock_acquire+0xbef/0xd04
> [8.613239]  [] ? kvm_clock_read+0x2e/0x36
> [8.613239]  [] lock_acquire+0xd5/0x119
> [8.613239]  [] ? 
> acpi_get_pci_rootbridge_handle+0x22/0x63
> [8.613239]  [] ? 
> acpi_get_pci_rootbridge_handle+0x22/0x63
> [8.613239]  [] __mutex_lock_common+0x58/0x387
> [8.613239]  [] ? 
> acpi_get_pci_rootbridge_handle+0x22/0x63
> [8.613239]  [] ? kvm_clock_read+0x2e/0x36
> [8.613239]  [] ? irq_trace+0x14/0x21
> [8.613239]  [] mutex_lock_nested+0x40/0x45
> [8.613239]  [] acpi_get_pci_rootbridge_handle+0x22/0x63
> [8.613239]  [] acpi_pci_get_bridge_handle+0x2c/0x2e
> [8.613239]  [] acpi_pci_check_ejectable+0x18/0x49
> [8.613239]  [] ? _raw_spin_unlock_irqrestore+0x45/0x61
> [8.613239]  [] register_slot+0x2f/0x460
> [8.613239]  [] ? up+0x39/0x3e
> [8.613239]  [] acpi_ns_walk_namespace+0xbe/0x179
> [8.613239]  [] ? acpi_os_wait_semaphore+0x45/0x5a
> [8.613239]  [] ? kzalloc.constprop.14+0x10/0x10
> [8.613239]  [] ? kzalloc.constprop.14+0x10/0x10
> [8.613239]  [] acpi_walk_namespace+0x98/0xcb
> [8.613239]  [] init_bridge_misc+0x4c/0xd5
> [8.613239]  [] add_bridge+0xe9/0x138
> [8.613239]  [] acpi_pci_register_driver+0x52/0x79
> [8.613239]  [] ? shpcd_init+0xf0/0xf0
> [8.613239]  [] acpiphp_glue_init+0x48/0x51
> [8.613239]  [] acpiphp_init+0x2b/0x50
> [8.613239]  [] do_one_initcall+0x7f/0x13a
> [8.613239]  [] kernel_init+0x13c/0x1c0
> [8.613239]  [] ? do_early_param+0x8c/0x8c
> [8.613239]  [] kernel_thread_helper+0x4/0x10
> [8.613239]  [] ? retint_restore_args+0x13/0x13
> [8.613239]  [] ? start_kernel+0x3d1/0x3d1
> [8.613239]  [] ? gs_change+0x13/0x13

Please check attached patch that should fix the problem.

-Yinghai


pci_root_bus_to_handle.patch
Description: Binary data

Re: Work queue questions

[anish singh]

On Sat, Sep 22, 2012 at 1:05 AM, Deepawali Verma  wrote:
> Hi Tajun,
>
> These three tasks are writing the three chunks of data in parallel. I
> am not getting improvement here otherwise what is difference between
> writing these chunks one by one in single thread instead of trying to
> write the data by scheduling the work on three different workqueues
> means 3 worker threads?
You should have carefully read "If none of them blocks, there
isn't much point in throwing more threads at them.  What are those
thread doing?" what Tejun said.

I think what he means is that concurrency is the concept of keeping the
system busy.
If you see the below logs:
kworker/u:1-21[000]   110.964895: task_event: MYTASKJOB2381 XStarted
kworker/u:1-21[000]   110.964909: task_event: MYTASKJOB2381 Xstopped
Here your first worker thread blocked.

So the system will try to get other workqueue started which is:
kworker/u:1-21[000]   110.965137: task_event: MYTASKJOB2382 XStarted
kworker/u:1-21[000]   110.965154: task_event: MYTASKJOB2382 Xstopped
Here again your second worker thread blocked.

So on so forth.
Anyway how can you write chunks of data in parallel when already some worker
thread is writing i.e. the system is busy.
Analogy: Suppose you are ambidextrous and you are eating.Can you eat with
both of your hands at a time?So worker thread are like your hands and keeping
you fed all the time is the concept of concurrency.

I am not an expert on this but from Tejun's reply I could make out this.
Please correct me If I have wrongly understood the concept based on this mail
chain.
>
> Regards,
> Deepa
>
> On Fri, Sep 21, 2012 at 8:27 PM, Tejun Heo  wrote:
>> On Fri, Sep 21, 2012 at 08:26:01PM +0100, Deepawali Verma wrote:
>>>  kworker/u:1-21[000]   110.964895: task_event: MYTASKJOB2381 
>>> XStarted
>>>  kworker/u:1-21[000]   110.964909: task_event: MYTASKJOB2381 
>>> Xstopped
>>>  kworker/u:1-21[000]   110.965137: task_event: MYTASKJOB2382 
>>> XStarted
>>>  kworker/u:1-21[000]   110.965154: task_event: MYTASKJOB2382 
>>> Xstopped
>>>  kworker/u:5-3724  [000]   110.965311: task_event: MYTASKJOB2383 
>>> XStarted
>>>  kworker/u:5-3724  [000]   110.965325: task_event: MYTASKJOB2383 
>>> Xstopped
>>>
>>> I have this one big task to whom I divided into small sub tasks. These
>>> are numbered 2381, 2382 and 2383, what was I expecting that task 2381,
>>> 2382, 2383 run in parallel. I have put start and stop markers here so
>>> that I can see how this concurrency managed work queue is distributing
>>> the load.
>>>
>>> I found that task no 2381 is started first and exited before starting
>>> task 2382 and so on. What I expected that it should start the three
>>> sub tasks in parallel, not one by one.
>>>
>>> Where is concurrency here?
>>
>> If none of them blocks, there isn't much point in throwing more
>> threads at them.  What are those thread doing?
>>
>> Thanks.
>>
>> --
>> tejun
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/5] unicore32: pwm: Use managed resource allocations

[guanxuetao]

> This commit uses the managed resource allocation functions to simplify
> the cleanup paths on error and removal.
>
> Signed-off-by: Thierry Reding 

Tested-by: Qin Rui 
Acked-by: Guan Xuetao 

Thanks & Regards,
Guan Xuetao

> ---
>  arch/unicore32/kernel/pwm.c | 47
> +
>  1 file changed, 9 insertions(+), 38 deletions(-)
>
> diff --git a/arch/unicore32/kernel/pwm.c b/arch/unicore32/kernel/pwm.c
> index 7e23470..724e860 100644
> --- a/arch/unicore32/kernel/pwm.c
> +++ b/arch/unicore32/kernel/pwm.c
> @@ -160,19 +160,17 @@ static int __devinit pwm_probe(struct
> platform_device *pdev)
>  {
>   struct pwm_device *pwm;
>   struct resource *r;
> - int ret = 0;
>
> - pwm = kzalloc(sizeof(struct pwm_device), GFP_KERNEL);
> + pwm = devm_kzalloc(>dev, sizeof(struct pwm_device), GFP_KERNEL);
>   if (pwm == NULL) {
>   dev_err(>dev, "failed to allocate memory\n");
>   return -ENOMEM;
>   }
>
> - pwm->clk = clk_get(NULL, "OST_CLK");
> - if (IS_ERR(pwm->clk)) {
> - ret = PTR_ERR(pwm->clk);
> - goto err_free;
> - }
> + pwm->clk = devm_clk_get(>dev, "OST_CLK");
> + if (IS_ERR(pwm->clk))
> + return PTR_ERR(pwm->clk);
> +
>   pwm->clk_enabled = 0;
>
>   pwm->use_count = 0;
> @@ -182,41 +180,21 @@ static int __devinit pwm_probe(struct
> platform_device *pdev)
>   r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>   if (r == NULL) {
>   dev_err(>dev, "no memory resource defined\n");
> - ret = -ENODEV;
> - goto err_free_clk;
> - }
> -
> - r = request_mem_region(r->start, resource_size(r), pdev->name);
> - if (r == NULL) {
> - dev_err(>dev, "failed to request memory resource\n");
> - ret = -EBUSY;
> - goto err_free_clk;
> + return -ENODEV;
>   }
>
> - pwm->base = ioremap_nocache(r->start, resource_size(r));
> - if (pwm->base == NULL) {
> - dev_err(>dev, "failed to remap memory resource\n");
> - ret = -EADDRNOTAVAIL;
> - goto err_release_mem;
> - }
> + pwm->base = devm_request_and_ioremap(>dev, r);
> + if (pwm->base == NULL)
> + return -EADDRNOTAVAIL;
>
>   __add_pwm(pwm);
>   platform_set_drvdata(pdev, pwm);
>   return 0;
> -
> -err_release_mem:
> - release_mem_region(r->start, resource_size(r));
> -err_free_clk:
> - clk_put(pwm->clk);
> -err_free:
> - kfree(pwm);
> - return ret;
>  }
>
>  static int __devexit pwm_remove(struct platform_device *pdev)
>  {
>   struct pwm_device *pwm;
> - struct resource *r;
>
>   pwm = platform_get_drvdata(pdev);
>   if (pwm == NULL)
> @@ -226,13 +204,6 @@ static int __devexit pwm_remove(struct
> platform_device *pdev)
>   list_del(>node);
>   mutex_unlock(_lock);
>
> - iounmap(pwm->base);
> -
> - r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - release_mem_region(r->start, resource_size(r));
> -
> - clk_put(pwm->clk);
> - kfree(pwm);
>   return 0;
>  }
>
> --
> 1.7.12
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/5] pwm: Move PUV3 PWM driver to PWM framework

[guanxuetao]

> This commit moves the driver to drivers/pwm and converts it to the new
> PWM framework.
>
> Signed-off-by: Thierry Reding 

Tested-by: Qin Rui 
Acked-by: Guan Xuetao 

Thanks & Regards,
Guan Xuetao


> ---
>  arch/unicore32/Kconfig |  12 +--
>  arch/unicore32/kernel/Makefile |   1 -
>  arch/unicore32/kernel/pwm.c| 219
> -
>  drivers/pwm/Kconfig|  10 +-
>  drivers/pwm/Makefile   |   1 +
>  drivers/pwm/pwm-puv3.c | 161 ++
>  6 files changed, 173 insertions(+), 231 deletions(-)
>  delete mode 100644 arch/unicore32/kernel/pwm.c
>  create mode 100644 drivers/pwm/pwm-puv3.c
>
> diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig
> index b0a4743..91e2037 100644
> --- a/arch/unicore32/Kconfig
> +++ b/arch/unicore32/Kconfig
> @@ -20,9 +20,6 @@ config UNICORE32
> designs licensed by PKUnity Ltd.
> Please see web page at .
>
> -config HAVE_PWM
> - bool
> -
>  config GENERIC_GPIO
>   def_bool y
>
> @@ -105,7 +102,8 @@ config PUV3_DB0913
>
>  config PUV3_NB0916
>   bool "NetBook board (0916)"
> - select HAVE_PWM
> + select PWM
> + select PWM_PUV3
>
>  config PUV3_SMW0919
>   bool "Security Mini-Workstation board (0919)"
> @@ -219,12 +217,6 @@ config PUV3_GPIO
>   select GPIO_SYSFS if EXPERIMENTAL
>   default y
>
> -config PUV3_PWM
> - tristate
> - default BACKLIGHT_PWM
> - help
> -   Enable support for NB0916 PWM controllers
> -
>  if PUV3_NB0916
>
>  menu "PKUnity NetBook-0916 Features"
> diff --git a/arch/unicore32/kernel/Makefile
> b/arch/unicore32/kernel/Makefile
> index 3240101..fa497e0 100644
> --- a/arch/unicore32/kernel/Makefile
> +++ b/arch/unicore32/kernel/Makefile
> @@ -16,7 +16,6 @@ obj-$(CONFIG_UNICORE_FPU_F64)   += fpu-ucf64.o
>  obj-$(CONFIG_ARCH_PUV3)  += clock.o irq.o time.o
>
>  obj-$(CONFIG_PUV3_GPIO)  += gpio.o
> -obj-$(CONFIG_PUV3_PWM)   += pwm.o
>  obj-$(CONFIG_PUV3_PM)+= pm.o sleep.o
>  obj-$(CONFIG_HIBERNATION)+= hibernate.o hibernate_asm.o
>
> diff --git a/arch/unicore32/kernel/pwm.c b/arch/unicore32/kernel/pwm.c
> deleted file mode 100644
> index 724e860..000
> --- a/arch/unicore32/kernel/pwm.c
> +++ /dev/null
> @@ -1,219 +0,0 @@
> -/*
> - * linux/arch/unicore32/kernel/pwm.c
> - *
> - * Code specific to PKUnity SoC and UniCore ISA
> - *
> - *   Maintained by GUAN Xue-tao 
> - *   Copyright (C) 2001-2010 Guan Xuetao
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#include 
> -#include 
> -
> -struct pwm_device {
> - struct list_headnode;
> - struct platform_device *pdev;
> -
> - void __iomem*base;
> -
> - const char  *label;
> - struct clk  *clk;
> - int clk_enabled;
> -
> - unsigned intuse_count;
> - unsigned intpwm_id;
> -};
> -
> -/*
> - * period_ns = 10^9 * (PRESCALE + 1) * (PV + 1) / PWM_CLK_RATE
> - * duty_ns   = 10^9 * (PRESCALE + 1) * DC / PWM_CLK_RATE
> - */
> -int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
> -{
> - unsigned long long c;
> - unsigned long period_cycles, prescale, pv, dc;
> -
> - if (pwm == NULL || period_ns == 0 || duty_ns > period_ns)
> - return -EINVAL;
> -
> - c = clk_get_rate(pwm->clk);
> - c = c * period_ns;
> - do_div(c, 10);
> - period_cycles = c;
> -
> - if (period_cycles < 1)
> - period_cycles = 1;
> - prescale = (period_cycles - 1) / 1024;
> - pv = period_cycles / (prescale + 1) - 1;
> -
> - if (prescale > 63)
> - return -EINVAL;
> -
> - if (duty_ns == period_ns)
> - dc = OST_PWMDCCR_FDCYCLE;
> - else
> - dc = (pv + 1) * duty_ns / period_ns;
> -
> - /* NOTE: the clock to PWM has to be enabled first
> -  * before writing to the registers
> -  */
> - clk_enable(pwm->clk);
> -
> - writel(prescale, pwm->base + OST_PWM_PWCR);
> - writel(pv - dc, pwm->base + OST_PWM_DCCR);
> - writel(pv, pwm->base + OST_PWM_PCR);
> -
> - clk_disable(pwm->clk);
> -
> - return 0;
> -}
> -EXPORT_SYMBOL(pwm_config);
> -
> -int pwm_enable(struct pwm_device *pwm)
> -{
> - int rc = 0;
> -
> - if (!pwm->clk_enabled) {
> - rc = clk_enable(pwm->clk);
> - if (!rc)
> - pwm->clk_enabled = 1;
> - }
> - return rc;
> -}
> -EXPORT_SYMBOL(pwm_enable);
> -
> -void pwm_disable(struct pwm_device *pwm)
> -{
> - if (pwm->clk_enabled) {
> - clk_disable(pwm->clk);
> - pwm->clk_enabled = 0;
> - }
> -}
> -EXPORT_SYMBOL(pwm_disable);

Re: [PATCH v2 3/5] unicore32: pwm: Remove unnecessary indirection

[guanxuetao]

> Calling the actual probing function through a proxy isn't required and
> makes the code needlessly complex.
>
> Signed-off-by: Thierry Reding 

Tested-by: Qin Rui 
Acked-by: Guan Xuetao 

Thanks & Regards,
Guan Xuetao


> ---
>  arch/unicore32/kernel/pwm.c | 23 ++-
>  1 file changed, 6 insertions(+), 17 deletions(-)
>
> diff --git a/arch/unicore32/kernel/pwm.c b/arch/unicore32/kernel/pwm.c
> index 012c54a..7e23470 100644
> --- a/arch/unicore32/kernel/pwm.c
> +++ b/arch/unicore32/kernel/pwm.c
> @@ -156,8 +156,7 @@ static inline void __add_pwm(struct pwm_device *pwm)
>   mutex_unlock(_lock);
>  }
>
> -static struct pwm_device *pwm_probe(struct platform_device *pdev,
> - unsigned int pwm_id, struct pwm_device *parent_pwm)
> +static int __devinit pwm_probe(struct platform_device *pdev)
>  {
>   struct pwm_device *pwm;
>   struct resource *r;
> @@ -166,7 +165,7 @@ static struct pwm_device *pwm_probe(struct
> platform_device *pdev,
>   pwm = kzalloc(sizeof(struct pwm_device), GFP_KERNEL);
>   if (pwm == NULL) {
>   dev_err(>dev, "failed to allocate memory\n");
> - return ERR_PTR(-ENOMEM);
> + return -ENOMEM;
>   }
>
>   pwm->clk = clk_get(NULL, "OST_CLK");
> @@ -177,7 +176,7 @@ static struct pwm_device *pwm_probe(struct
> platform_device *pdev,
>   pwm->clk_enabled = 0;
>
>   pwm->use_count = 0;
> - pwm->pwm_id = pwm_id;
> + pwm->pwm_id = pdev->id;
>   pwm->pdev = pdev;
>
>   r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -203,7 +202,7 @@ static struct pwm_device *pwm_probe(struct
> platform_device *pdev,
>
>   __add_pwm(pwm);
>   platform_set_drvdata(pdev, pwm);
> - return pwm;
> + return 0;
>
>  err_release_mem:
>   release_mem_region(r->start, resource_size(r));
> @@ -211,17 +210,7 @@ err_free_clk:
>   clk_put(pwm->clk);
>  err_free:
>   kfree(pwm);
> - return ERR_PTR(ret);
> -}
> -
> -static int __devinit puv3_pwm_probe(struct platform_device *pdev)
> -{
> - struct pwm_device *pwm = pwm_probe(pdev, pdev->id, NULL);
> -
> - if (IS_ERR(pwm))
> - return PTR_ERR(pwm);
> -
> - return 0;
> + return ret;
>  }
>
>  static int __devexit pwm_remove(struct platform_device *pdev)
> @@ -251,7 +240,7 @@ static struct platform_driver puv3_pwm_driver = {
>   .driver = {
>   .name   = "PKUnity-v3-PWM",
>   },
> - .probe  = puv3_pwm_probe,
> + .probe  = pwm_probe,
>   .remove = __devexit_p(pwm_remove),
>  };
>  module_platform_driver(puv3_pwm_driver);
> --
> 1.7.12
>

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

Re: [PATCH v2 2/5] unicore32: pwm: Use module_platform_driver()

[guanxuetao]

> Some of the boilerplate code can be eliminated by using this macro. The
> driver was previously registered with an arch_initcall(), so technically
> this is no longer the same, but when the driver is moved to the PWM
> framework, deferred probing will take care of any driver probe ordering
> issues.
>
> Signed-off-by: Thierry Reding 

Tested-by: Qin Rui 
Acked-by: Guan Xuetao 

Thanks & Regards,
Guan Xuetao

> ---
>  arch/unicore32/kernel/pwm.c | 21 +
>  1 file changed, 1 insertion(+), 20 deletions(-)
>
> diff --git a/arch/unicore32/kernel/pwm.c b/arch/unicore32/kernel/pwm.c
> index 885bbcd..012c54a 100644
> --- a/arch/unicore32/kernel/pwm.c
> +++ b/arch/unicore32/kernel/pwm.c
> @@ -254,25 +254,6 @@ static struct platform_driver puv3_pwm_driver = {
>   .probe  = puv3_pwm_probe,
>   .remove = __devexit_p(pwm_remove),
>  };
> -
> -static int __init pwm_init(void)
> -{
> - int ret = 0;
> -
> - ret = platform_driver_register(_pwm_driver);
> - if (ret) {
> - printk(KERN_ERR "failed to register puv3_pwm_driver\n");
> - return ret;
> - }
> -
> - return ret;
> -}
> -arch_initcall(pwm_init);
> -
> -static void __exit pwm_exit(void)
> -{
> - platform_driver_unregister(_pwm_driver);
> -}
> -module_exit(pwm_exit);
> +module_platform_driver(puv3_pwm_driver);
>
>  MODULE_LICENSE("GPL v2");
> --
> 1.7.12
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] net/phy/bcm87xx: Add MODULE_LICENSE("GPL") to GPL driver

[Peter Huewe]

Currently the driver has no MODULE_LICENSE attribute in its source which
results in a kernel taint if I load this:

root@(none):~# modprobe bcm87xx
bcm87xx: module license 'unspecified' taints kernel.

Since the first lines of the source code clearly state:
 * This file is subject to the terms and conditions of the GNU General
 * Public License.  See the file "COPYING" in the main directory of this
 * archive for more details.
I think it's safe to add the MODULE_LICENSE("GPL") macro and thus remove
the kernel taint.

Cc: sta...@vger.kernel.org
Signed-off-by: Peter Huewe 
---
 drivers/net/phy/bcm87xx.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/net/phy/bcm87xx.c b/drivers/net/phy/bcm87xx.c
index 2346b38..7997895 100644
--- a/drivers/net/phy/bcm87xx.c
+++ b/drivers/net/phy/bcm87xx.c
@@ -229,3 +229,5 @@ static void __exit bcm87xx_exit(void)
ARRAY_SIZE(bcm87xx_driver));
 }
 module_exit(bcm87xx_exit);
+
+MODULE_LICENSE("GPL");
-- 
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/

[PATCH 3/7][RFC] netfilter: qtaguid: initialize a local var to keep compiler happy.

[John Stultz]

From: JP Abgrall 

There was a case that might have seemed like new_tag_stat was not
initialized and actually used.
Added comment explaining why it was impossible, and a BUG()
in case the logic gets changed.

Cc: net...@vger.kernel.org
Cc: JP Abgrall 
Cc: Ashish Sharma 
Cc: Peter P Waskiewicz Jr 
Signed-off-by: JP Abgrall 
Signed-off-by: John Stultz 
---
 net/netfilter/xt_qtaguid.c |   13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/net/netfilter/xt_qtaguid.c b/net/netfilter/xt_qtaguid.c
index 7c4ac46..214a990 100644
--- a/net/netfilter/xt_qtaguid.c
+++ b/net/netfilter/xt_qtaguid.c
@@ -1255,7 +1255,7 @@ static void if_tag_stat_update(const char *ifname, uid_t 
uid,
struct data_counters *uid_tag_counters;
struct sock_tag *sock_tag_entry;
struct iface_stat *iface_entry;
-   struct tag_stat *new_tag_stat;
+   struct tag_stat *new_tag_stat = NULL;
MT_DEBUG("qtaguid: if_tag_stat_update(ifname=%s "
"uid=%u sk=%p dir=%d proto=%d bytes=%d)\n",
 ifname, uid, sk, direction, proto, bytes);
@@ -1320,8 +1320,19 @@ static void if_tag_stat_update(const char *ifname, uid_t 
uid,
}
 
if (acct_tag) {
+   /* Create the child {acct_tag, uid_tag} and hook up parent. */
new_tag_stat = create_if_tag_stat(iface_entry, tag);
new_tag_stat->parent_counters = uid_tag_counters;
+   } else {
+   /*
+* For new_tag_stat to be still NULL here would require:
+*  {0, uid_tag} exists
+*  and {acct_tag, uid_tag} doesn't exist
+*  AND acct_tag == 0.
+* Impossible. This reassures us that new_tag_stat
+* below will always be assigned.
+*/
+   BUG_ON(!new_tag_stat);
}
tag_stat_update(new_tag_stat, direction, proto, bytes);
spin_unlock_bh(_entry->tag_stat_list_lock);
-- 
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/

[PATCH 4/7][RFC] netfilter: xt_qtaguid: fix ipv6 protocol lookup

[John Stultz]

From: JP Abgrall 

When updating the stats for a given uid it would incorrectly assume
IPV4 and pick up the wrong protocol when IPV6.

Cc: net...@vger.kernel.org
Cc: JP Abgrall 
Cc: Ashish Sharma 
Cc: Peter P Waskiewicz Jr 
Signed-off-by: JP Abgrall 
[Small compile fix for ipv6_find_hdr() -jstultz]
Signed-off-by: John Stultz 
---
 net/netfilter/xt_qtaguid.c |   39 ---
 1 file changed, 32 insertions(+), 7 deletions(-)

diff --git a/net/netfilter/xt_qtaguid.c b/net/netfilter/xt_qtaguid.c
index 214a990..47dfb9e 100644
--- a/net/netfilter/xt_qtaguid.c
+++ b/net/netfilter/xt_qtaguid.c
@@ -26,6 +26,10 @@
 #include 
 #include 
 
+#if defined(CONFIG_IP6_NF_IPTABLES) || defined(CONFIG_IP6_NF_IPTABLES_MODULE)
+#include 
+#endif
+
 #include 
 #include "xt_qtaguid_internal.h"
 #include "xt_qtaguid_print.h"
@@ -1536,6 +1540,27 @@ static struct sock *qtaguid_find_sk(const struct sk_buff 
*skb,
return sk;
 }
 
+static int ipx_proto(const struct sk_buff *skb,
+struct xt_action_param *par)
+{
+   int thoff, tproto;
+
+   switch (par->family) {
+   case NFPROTO_IPV6:
+   tproto = ipv6_find_hdr(skb, , -1, NULL, NULL);
+   if (tproto < 0)
+   MT_DEBUG("%s(): transport header not found in ipv6"
+" skb=%p\n", __func__, skb);
+   break;
+   case NFPROTO_IPV4:
+   tproto = ip_hdr(skb)->protocol;
+   break;
+   default:
+   tproto = IPPROTO_RAW;
+   }
+   return tproto;
+}
+
 static void account_for_uid(const struct sk_buff *skb,
const struct sock *alternate_sk, uid_t uid,
struct xt_action_param *par)
@@ -1562,15 +1587,15 @@ static void account_for_uid(const struct sk_buff *skb,
} else if (unlikely(!el_dev->name)) {
pr_info("qtaguid[%d]: no dev->name?!!\n", par->hooknum);
} else {
-   MT_DEBUG("qtaguid[%d]: dev name=%s type=%d\n",
-par->hooknum,
-el_dev->name,
-el_dev->type);
+   int proto = ipx_proto(skb, par);
+   MT_DEBUG("qtaguid[%d]: dev name=%s type=%d fam=%d proto=%d\n",
+par->hooknum, el_dev->name, el_dev->type,
+par->family, proto);
 
if_tag_stat_update(el_dev->name, uid,
skb->sk ? skb->sk : alternate_sk,
par->in ? IFS_RX : IFS_TX,
-   ip_hdr(skb)->protocol, skb->len);
+   proto, skb->len);
}
 }
 
@@ -1615,8 +1640,8 @@ static bool qtaguid_mt(const struct sk_buff *skb, struct 
xt_action_param *par)
} else {
atomic64_inc(_events.match_found_sk);
}
-   MT_DEBUG("qtaguid[%d]: sk=%p got_sock=%d proto=%d\n",
-   par->hooknum, sk, got_sock, ip_hdr(skb)->protocol);
+   MT_DEBUG("qtaguid[%d]: sk=%p got_sock=%d fam=%d proto=%d\n",
+par->hooknum, sk, got_sock, par->family, ipx_proto(skb, par));
if (sk != NULL) {
MT_DEBUG("qtaguid[%d]: sk=%p->sk_socket=%p->file=%p\n",
par->hooknum, sk, sk->sk_socket,
-- 
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/

[PATCH 5/7][RFC] netfilter: xt_qtaguid: start tracking iface rx/tx at low level

[John Stultz]

From: JP Abgrall 

qtaguid tracks the device stats by monitoring when it goes up and down,
then it gets the dev_stats().
But devs don't correctly report stats (either they don't count headers
symmetrically between rx/tx, or they count internal control messages).

Now qtaguid counts the rx/tx bytes/packets during raw:prerouting and
mangle:postrouting (nat is not available in ipv6).

The results are in
  /proc/net/xt_qtaguid/iface_stat_fmt
which outputs a format line (bash expansion):
  ifname  total_skb_{rx,tx}_{bytes,packets}

Added event counters for pre/post handling.
Added extra ctrl_*() pid/uid debugging.

Cc: net...@vger.kernel.org
Cc: JP Abgrall 
Cc: Ashish Sharma 
Cc: Peter P Waskiewicz Jr 
Signed-off-by: JP Abgrall 
Signed-off-by: John Stultz 
---
 net/netfilter/xt_qtaguid.c  |  277 +++
 net/netfilter/xt_qtaguid_internal.h |5 +-
 net/netfilter/xt_qtaguid_print.c|   18 ++-
 3 files changed, 233 insertions(+), 67 deletions(-)

diff --git a/net/netfilter/xt_qtaguid.c b/net/netfilter/xt_qtaguid.c
index 47dfb9e..f490ef5 100644
--- a/net/netfilter/xt_qtaguid.c
+++ b/net/netfilter/xt_qtaguid.c
@@ -104,8 +104,15 @@ module_param_named(debug_mask, qtaguid_debug_mask, uint, 
S_IRUGO | S_IWUSR);
 /*---*/
 static const char *iface_stat_procdirname = "iface_stat";
 static struct proc_dir_entry *iface_stat_procdir;
+/*
+ * The iface_stat_all* will go away once userspace gets use to the new fields
+ * that have a format line.
+ */
 static const char *iface_stat_all_procfilename = "iface_stat_all";
 static struct proc_dir_entry *iface_stat_all_procfile;
+static const char *iface_stat_fmt_procfilename = "iface_stat_fmt";
+static struct proc_dir_entry *iface_stat_fmt_procfile;
+
 
 /*
  * Ordering of locks:
@@ -118,9 +125,9 @@ static struct proc_dir_entry *iface_stat_all_procfile;
  * Notice how sock_tag_list_lock is held sometimes when uid_tag_data_tree_lock
  * is acquired.
  *
- * Call tree with all lock holders as of 2011-09-25:
+ * Call tree with all lock holders as of 2012-04-27:
  *
- * iface_stat_all_proc_read()
+ * iface_stat_fmt_proc_read()
  *   iface_stat_list_lock
  * (struct iface_stat)
  *
@@ -771,13 +778,14 @@ done:
return iface_entry;
 }
 
-static int iface_stat_all_proc_read(char *page, char **num_items_returned,
+static int iface_stat_fmt_proc_read(char *page, char **num_items_returned,
off_t items_to_skip, int char_count,
int *eof, void *data)
 {
char *outp = page;
int item_index = 0;
int len;
+   int fmt = (int)data; /* The data is just 1 (old) or 2 (uses fmt) */
struct iface_stat *iface_entry;
struct rtnl_link_stats64 dev_stats, *stats;
struct rtnl_link_stats64 no_dev_stats = {0};
@@ -787,14 +795,32 @@ static int iface_stat_all_proc_read(char *page, char 
**num_items_returned,
return 0;
}
 
-   CT_DEBUG("qtaguid:proc iface_stat_all "
+   CT_DEBUG("qtaguid:proc iface_stat_fmt "
+"pid=%u tgid=%u uid=%u "
 "page=%p *num_items_returned=%p off=%ld "
-"char_count=%d *eof=%d\n", page, *num_items_returned,
+"char_count=%d *eof=%d\n",
+current->pid, current->tgid, current_fsuid(),
+page, *num_items_returned,
 items_to_skip, char_count, *eof);
 
if (*eof)
return 0;
 
+   if (fmt == 2 && item_index++ >= items_to_skip) {
+   len = snprintf(outp, char_count,
+  "ifname "
+  "total_skb_rx_bytes total_skb_rx_packets "
+  "total_skb_tx_bytes total_skb_tx_packets\n"
+   );
+   if (len >= char_count) {
+   *outp = '\0';
+   return outp - page;
+   }
+   outp += len;
+   char_count -= len;
+   (*num_items_returned)++;
+   }
+
/*
 * This lock will prevent iface_stat_update() from changing active,
 * and in turn prevent an interface from unregistering itself.
@@ -810,18 +836,37 @@ static int iface_stat_all_proc_read(char *page, char 
**num_items_returned,
} else {
stats = _dev_stats;
}
-   len = snprintf(outp, char_count,
-  "%s %d "
-  "%llu %llu %llu %llu "
-  "%llu %llu %llu %llu\n",
-  iface_entry->ifname,
-  iface_entry->active,
-  iface_entry->totals[IFS_RX].bytes,
-  iface_entry->totals[IFS_RX].packets,
-  iface_entry->totals[IFS_TX].bytes,
-  

[PATCH 7/7][RFC] netfilter: xt_IDLETIMER: Rename INTERFACE to LABEL in netlink notification.

[John Stultz]

From: Ashish Sharma 

Rename INTERFACE to LABEL in netlink notification.

Cc: net...@vger.kernel.org
Cc: JP Abgrall 
Cc: Ashish Sharma 
Cc: Peter P Waskiewicz Jr 
Signed-off-by: Ashish Sharma 
Signed-off-by: John Stultz 
---
 net/netfilter/xt_IDLETIMER.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/net/netfilter/xt_IDLETIMER.c b/net/netfilter/xt_IDLETIMER.c
index df91e26..f4ba863 100644
--- a/net/netfilter/xt_IDLETIMER.c
+++ b/net/netfilter/xt_IDLETIMER.c
@@ -68,15 +68,15 @@ static DEFINE_MUTEX(list_mutex);
 
 static struct kobject *idletimer_tg_kobj;
 
-static void notify_netlink_uevent(const char *iface, struct idletimer_tg 
*timer)
+static void notify_netlink_uevent(const char *label, struct idletimer_tg 
*timer)
 {
-   char iface_msg[NLMSG_MAX_SIZE];
+   char label_msg[NLMSG_MAX_SIZE];
char state_msg[NLMSG_MAX_SIZE];
-   char *envp[] = { iface_msg, state_msg, NULL };
+   char *envp[] = { label_msg, state_msg, NULL };
int res;
 
-   res = snprintf(iface_msg, NLMSG_MAX_SIZE, "INTERFACE=%s",
-  iface);
+   res = snprintf(label_msg, NLMSG_MAX_SIZE, "LABEL=%s",
+  label);
if (NLMSG_MAX_SIZE <= res) {
pr_err("message too long (%d)", res);
return;
@@ -87,7 +87,7 @@ static void notify_netlink_uevent(const char *iface, struct 
idletimer_tg *timer)
pr_err("message too long (%d)", res);
return;
}
-   pr_debug("putting nlmsg: <%s> <%s>\n", iface_msg, state_msg);
+   pr_debug("putting nlmsg: <%s> <%s>\n", label_msg, state_msg);
kobject_uevent_env(idletimer_tg_kobj, KOBJ_CHANGE, envp);
return;
 
-- 
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/

[PATCH 0/7][RFC] Android netfilter patches

[John Stultz]

During Kernel Summit, I mentioned that one area of the Android patch
set that hasn't had seemed to have had much discussion were the
netfilter changes.

PJ Waskiewicz asked more about them, and I sent them along to him
to briefly review, and he suggested sending them out for wider review.

So here are some of the Android netfilter changes.

I'm not very familiar with the netfilter code, so I'm not proposing
these be merged, but I'm interested in hearing if folks have any
thoughts about the patches and what changes they thing might be
necessary in order for similar functionality to be included.

You can also access these patches via gitweb here:
http://git.linaro.org/gitweb?p=people/jstultz/android-dev.git;a=shortlog;h=refs/heads/dev/netfilter


Cc: net...@vger.kernel.org
Cc: JP Abgrall 
Cc: Ashish Sharma 
Cc: Peter P Waskiewicz Jr 

Ashish Sharma (1):
  netfilter: xt_IDLETIMER: Rename INTERFACE to LABEL in netlink
notification.

JP Abgrall (6):
  nf: xt_socket: export the fancy sock finder code
  netfilter: add xt_qtaguid matching module
  netfilter: qtaguid: initialize a local var to keep compiler happy.
  netfilter: xt_qtaguid: fix ipv6 protocol lookup
  netfilter: xt_qtaguid: start tracking iface rx/tx at low level
  netfilter: xt_IDLETIMER: Add new netlink msg type

 include/linux/netfilter/xt_IDLETIMER.h |8 +
 include/linux/netfilter/xt_qtaguid.h   |   13 +
 include/linux/netfilter/xt_socket.h|6 +
 net/netfilter/Kconfig  |   18 +
 net/netfilter/Makefile |1 +
 net/netfilter/xt_IDLETIMER.c   |   78 +-
 net/netfilter/xt_qtaguid.c | 2966 
 net/netfilter/xt_qtaguid_internal.h|  333 
 net/netfilter/xt_qtaguid_print.c   |  564 ++
 net/netfilter/xt_qtaguid_print.h   |  120 ++
 net/netfilter/xt_socket.c  |   69 +-
 11 files changed, 4146 insertions(+), 30 deletions(-)
 create mode 100644 include/linux/netfilter/xt_qtaguid.h
 create mode 100644 net/netfilter/xt_qtaguid.c
 create mode 100644 net/netfilter/xt_qtaguid_internal.h
 create mode 100644 net/netfilter/xt_qtaguid_print.c
 create mode 100644 net/netfilter/xt_qtaguid_print.h

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

[PATCH 6/7][RFC] netfilter: xt_IDLETIMER: Add new netlink msg type

[John Stultz]

From: JP Abgrall 

Send notifications when the label becomes active after an idle period.
Send netlink message notifications in addition to sysfs notifications.
Using a uevent with
  subsystem=xt_idletimer
  INTERFACE=...
  STATE={active,inactive}

This is backport from common android-3.0
commit: beb914e987cbbd368988d2b94a6661cb907c4d5a
with uevent support instead of a new netlink message type.

Cc: net...@vger.kernel.org
Cc: JP Abgrall 
Cc: Ashish Sharma 
Cc: Peter P Waskiewicz Jr 
Signed-off-by: Ashish Sharma 
Signed-off-by: JP Abgrall 
Signed-off-by: John Stultz 
---
 include/linux/netfilter/xt_IDLETIMER.h |8 
 net/netfilter/xt_IDLETIMER.c   |   78 +---
 2 files changed, 79 insertions(+), 7 deletions(-)

diff --git a/include/linux/netfilter/xt_IDLETIMER.h 
b/include/linux/netfilter/xt_IDLETIMER.h
index 208ae93..faaa28b 100644
--- a/include/linux/netfilter/xt_IDLETIMER.h
+++ b/include/linux/netfilter/xt_IDLETIMER.h
@@ -4,6 +4,7 @@
  * Header file for Xtables timer target module.
  *
  * Copyright (C) 2004, 2010 Nokia Corporation
+ *
  * Written by Timo Teras 
  *
  * Converted to x_tables and forward-ported to 2.6.34
@@ -32,12 +33,19 @@
 #include 
 
 #define MAX_IDLETIMER_LABEL_SIZE 28
+#define NLMSG_MAX_SIZE 64
+
+#define NL_EVENT_TYPE_INACTIVE 0
+#define NL_EVENT_TYPE_ACTIVE 1
 
 struct idletimer_tg_info {
__u32 timeout;
 
char label[MAX_IDLETIMER_LABEL_SIZE];
 
+   /* Use netlink messages for notification in addition to sysfs */
+   __u8 send_nl_msg;
+
/* for kernel module internal use only */
struct idletimer_tg *timer __attribute__((aligned(8)));
 };
diff --git a/net/netfilter/xt_IDLETIMER.c b/net/netfilter/xt_IDLETIMER.c
index f407ebc1..df91e26 100644
--- a/net/netfilter/xt_IDLETIMER.c
+++ b/net/netfilter/xt_IDLETIMER.c
@@ -5,6 +5,7 @@
  * After timer expires a kevent will be sent.
  *
  * Copyright (C) 2004, 2010 Nokia Corporation
+ *
  * Written by Timo Teras 
  *
  * Converted to x_tables and reworked for upstream inclusion
@@ -38,8 +39,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 
 struct idletimer_tg_attr {
struct attribute attr;
@@ -56,6 +59,8 @@ struct idletimer_tg {
struct idletimer_tg_attr attr;
 
unsigned int refcnt;
+   bool send_nl_msg;
+   bool active;
 };
 
 static LIST_HEAD(idletimer_tg_list);
@@ -63,6 +68,32 @@ static DEFINE_MUTEX(list_mutex);
 
 static struct kobject *idletimer_tg_kobj;
 
+static void notify_netlink_uevent(const char *iface, struct idletimer_tg 
*timer)
+{
+   char iface_msg[NLMSG_MAX_SIZE];
+   char state_msg[NLMSG_MAX_SIZE];
+   char *envp[] = { iface_msg, state_msg, NULL };
+   int res;
+
+   res = snprintf(iface_msg, NLMSG_MAX_SIZE, "INTERFACE=%s",
+  iface);
+   if (NLMSG_MAX_SIZE <= res) {
+   pr_err("message too long (%d)", res);
+   return;
+   }
+   res = snprintf(state_msg, NLMSG_MAX_SIZE, "STATE=%s",
+  timer->active ? "active" : "inactive");
+   if (NLMSG_MAX_SIZE <= res) {
+   pr_err("message too long (%d)", res);
+   return;
+   }
+   pr_debug("putting nlmsg: <%s> <%s>\n", iface_msg, state_msg);
+   kobject_uevent_env(idletimer_tg_kobj, KOBJ_CHANGE, envp);
+   return;
+
+
+}
+
 static
 struct idletimer_tg *__idletimer_tg_find_by_label(const char *label)
 {
@@ -83,6 +114,7 @@ static ssize_t idletimer_tg_show(struct kobject *kobj, 
struct attribute *attr,
 {
struct idletimer_tg *timer;
unsigned long expires = 0;
+   unsigned long now = jiffies;
 
mutex_lock(_mutex);
 
@@ -92,11 +124,15 @@ static ssize_t idletimer_tg_show(struct kobject *kobj, 
struct attribute *attr,
 
mutex_unlock(_mutex);
 
-   if (time_after(expires, jiffies))
+   if (time_after(expires, now))
return sprintf(buf, "%u\n",
-  jiffies_to_msecs(expires - jiffies) / 1000);
+  jiffies_to_msecs(expires - now) / 1000);
 
-   return sprintf(buf, "0\n");
+   if (timer->send_nl_msg)
+   return sprintf(buf, "0 %d\n",
+   jiffies_to_msecs(now - expires) / 1000);
+   else
+   return sprintf(buf, "0\n");
 }
 
 static void idletimer_tg_work(struct work_struct *work)
@@ -105,6 +141,9 @@ static void idletimer_tg_work(struct work_struct *work)
  work);
 
sysfs_notify(idletimer_tg_kobj, NULL, timer->attr.attr.name);
+
+   if (timer->send_nl_msg)
+   notify_netlink_uevent(timer->attr.attr.name, timer);
 }
 
 static void idletimer_tg_expired(unsigned long data)
@@ -113,6 +152,7 @@ static void idletimer_tg_expired(unsigned long data)
 
pr_debug("timer %s expired\n", timer->attr.attr.name);
 
+   timer->active = false;
schedule_work(>work);
 }
 
@@ -145,6 

[PATCH 1/7][RFC] nf: xt_socket: export the fancy sock finder code

[John Stultz]

From: JP Abgrall 

The socket matching function has some nifty logic to get the struct sock
from the skb or from the connection tracker.
We export this so other xt_* can use it, similarly to ho how
xt_socket uses nf_tproxy_get_sock.

Cc: net...@vger.kernel.org
Cc: JP Abgrall 
Cc: Ashish Sharma 
Cc: Peter P Waskiewicz Jr 
Signed-off-by: JP Abgrall 
Signed-off-by: John Stultz 
---
 include/linux/netfilter/xt_socket.h |6 +++
 net/netfilter/xt_socket.c   |   69 +++
 2 files changed, 52 insertions(+), 23 deletions(-)

diff --git a/include/linux/netfilter/xt_socket.h 
b/include/linux/netfilter/xt_socket.h
index 26d7217..6359456 100644
--- a/include/linux/netfilter/xt_socket.h
+++ b/include/linux/netfilter/xt_socket.h
@@ -11,4 +11,10 @@ struct xt_socket_mtinfo1 {
__u8 flags;
 };
 
+void xt_socket_put_sk(struct sock *sk);
+struct sock *xt_socket_get4_sk(const struct sk_buff *skb,
+  struct xt_action_param *par);
+struct sock *xt_socket_get6_sk(const struct sk_buff *skb,
+  struct xt_action_param *par);
+
 #endif /* _XT_SOCKET_H */
diff --git a/net/netfilter/xt_socket.c b/net/netfilter/xt_socket.c
index 9ea482d..ee8c5f5 100644
--- a/net/netfilter/xt_socket.c
+++ b/net/netfilter/xt_socket.c
@@ -35,7 +35,7 @@
 #include 
 #endif
 
-static void
+void
 xt_socket_put_sk(struct sock *sk)
 {
if (sk->sk_state == TCP_TIME_WAIT)
@@ -43,6 +43,7 @@ xt_socket_put_sk(struct sock *sk)
else
sock_put(sk);
 }
+EXPORT_SYMBOL(xt_socket_put_sk);
 
 static int
 extract_icmp4_fields(const struct sk_buff *skb,
@@ -101,9 +102,8 @@ extract_icmp4_fields(const struct sk_buff *skb,
return 0;
 }
 
-static bool
-socket_match(const struct sk_buff *skb, struct xt_action_param *par,
-const struct xt_socket_mtinfo1 *info)
+struct sock*
+xt_socket_get4_sk(const struct sk_buff *skb, struct xt_action_param *par)
 {
const struct iphdr *iph = ip_hdr(skb);
struct udphdr _hdr, *hp = NULL;
@@ -120,7 +120,7 @@ socket_match(const struct sk_buff *skb, struct 
xt_action_param *par,
hp = skb_header_pointer(skb, ip_hdrlen(skb),
sizeof(_hdr), &_hdr);
if (hp == NULL)
-   return false;
+   return NULL;
 
protocol = iph->protocol;
saddr = iph->saddr;
@@ -131,9 +131,9 @@ socket_match(const struct sk_buff *skb, struct 
xt_action_param *par,
} else if (iph->protocol == IPPROTO_ICMP) {
if (extract_icmp4_fields(skb, , , ,
, ))
-   return false;
+   return NULL;
} else {
-   return false;
+   return NULL;
}
 
 #ifdef XT_SOCKET_HAVE_CONNTRACK
@@ -157,6 +157,23 @@ socket_match(const struct sk_buff *skb, struct 
xt_action_param *par,
 
sk = nf_tproxy_get_sock_v4(dev_net(skb->dev), protocol,
   saddr, daddr, sport, dport, par->in, 
NFT_LOOKUP_ANY);
+
+   pr_debug("proto %hhu %pI4:%hu -> %pI4:%hu (orig %pI4:%hu) sock %p\n",
+protocol, , ntohs(sport),
+, ntohs(dport),
+>daddr, hp ? ntohs(hp->dest) : 0, sk);
+
+   return sk;
+}
+EXPORT_SYMBOL(xt_socket_get4_sk);
+
+static bool
+socket_match(const struct sk_buff *skb, struct xt_action_param *par,
+const struct xt_socket_mtinfo1 *info)
+{
+   struct sock *sk;
+
+   sk = xt_socket_get4_sk(skb, par);
if (sk != NULL) {
bool wildcard;
bool transparent = true;
@@ -179,11 +196,6 @@ socket_match(const struct sk_buff *skb, struct 
xt_action_param *par,
sk = NULL;
}
 
-   pr_debug("proto %hhu %pI4:%hu -> %pI4:%hu (orig %pI4:%hu) sock %p\n",
-protocol, , ntohs(sport),
-, ntohs(dport),
->daddr, hp ? ntohs(hp->dest) : 0, sk);
-
return (sk != NULL);
 }
 
@@ -255,8 +267,8 @@ extract_icmp6_fields(const struct sk_buff *skb,
return 0;
 }
 
-static bool
-socket_mt6_v1(const struct sk_buff *skb, struct xt_action_param *par)
+struct sock*
+xt_socket_get6_sk(const struct sk_buff *skb, struct xt_action_param *par)
 {
struct ipv6hdr *iph = ipv6_hdr(skb);
struct udphdr _hdr, *hp = NULL;
@@ -276,7 +288,7 @@ socket_mt6_v1(const struct sk_buff *skb, struct 
xt_action_param *par)
hp = skb_header_pointer(skb, thoff,
sizeof(_hdr), &_hdr);
if (hp == NULL)
-   return false;
+   return NULL;
 
saddr = >saddr;
sport = hp->source;
@@ -286,13 +298,30 @@ socket_mt6_v1(const struct sk_buff *skb, struct 
xt_action_param *par)
} else if (tproto == IPPROTO_ICMPV6) {
if 

OOPS/panic in iio_dummy (v3.6-rc6-176-gabef3bd)

[Peter Hüwe]

Hi,

loading iio_dummy results in kernel panic as the call to 
iio_buffer_register in iio_dummy_probe is performed with indio_dev->buffer == 
NULL and thus the access to indio_dev->buffer->attrs results in this 
oops/panic.

Thanks,
Peter

Steps to reproduce:

#modprobe iio_dummy
iio_dummy: module is from the staging directory, the quality is unknown, you 
have been warned.

Modules linked in: iio_dummy(C+) industrialio
Pid: 615, comm: modprobe Tainted: G C   3.6.0-rc6-00180-g68d0383-dirty
RIP: 0033:[]
RSP: 9f4ffd30  EFLAGS: 00010206
RAX: 0004 RBX: a08be6a0 RCX: 
RDX: 6036a320 RSI: 0008 RDI: 
RBP: 9f4ffda0 R08: 9f4ff900 R09: 60406da8
R10: 004a R11: 0246 R12: 602a58bc
R13: 0005 R14: 6005f170 R15: 9f6b0400
Call Trace: 
603675d8:  [<6001d53d>] segv+0x1bd/0x340
603675f8:  [<6008b8ab>] handle_irq_event_percpu+0xab/0x1b0
60367620:  [<6008b9b0>] handle_irq_event+0x0/0x40
60367630:  [<6002e09c>] os_waiting_for_events+0x0/0xc5
60367658:  [<6008fccf>] rcu_irq_exit+0x5f/0xb0
603676a8:  [<6001d713>] segv_handler+0x53/0xb0
603676c8:  [<60019b5c>] sigio_handler+0xac/0xc0
603676f8:  [<6002ff5a>] sig_handler_common+0xa4/0xb9
60367708:  [<6005f170>] __mutex_init+0x0/0x20
60367718:  [<602a58bc>] printk+0x0/0xa8
60367780:  [] iio_buffer_register+0x46/0x610 [industrialio]
60367818:  [<60016c34>] _einittext+0x2572/0x38f6
60367828:  [<60016728>] _einittext+0x2066/0x38f6
60367908:  [<60016c34>] _einittext+0x2572/0x38f6
603679a8:  [<60019b70>] to_irq_stack+0x0/0xe0
60367a28:  [<60019b70>] to_irq_stack+0x0/0xe0
60367a38:  [<600300b5>] sig_handler+0x4a/0x5d
60367a58:  [<6002fb81>] hard_handler+0x89/0xd8
60367a90:  [<602a58bc>] printk+0x0/0xa8
60367aa0:  [<6005f170>] __mutex_init+0x0/0x20
60367b08:  [<602a58bc>] printk+0x0/0xa8
60367b18:  [<6005f170>] __mutex_init+0x0/0x20
60367b68:  [] iio_buffer_register+0x46/0x610 [industrialio]

Kernel panic - not syncing: Kernel mode fault at addr 0x68, ip 0xa089d846
Call Trace: 
603674b0:  [] iio_buffer_register+0x46/0x610 [industrialio]
603674c8:  [<602a5751>] panic+0x146/0x2b1
60367500:  [] iio_buffer_register+0x46/0x610 [industrialio]
60367508:  [<602a560b>] panic+0x0/0x2b1
60367520:  [<6007a4d4>] __module_text_address+0x14/0x70
60367538:  [<6007ec20>] is_module_text_address+0x10/0x20
60367548:  [<600582c7>] __kernel_text_address+0x87/0xc0
60367568:  [<6001bc1f>] show_trace+0x7f/0xf0
60367598:  [] iio_buffer_register+0x46/0x610 [industrialio]
603675c0:  [] iio_buffer_register+0x46/0x610 [industrialio]
603675d8:  [<6001d55b>] segv+0x1db/0x340
603675f8:  [<6008b8ab>] handle_irq_event_percpu+0xab/0x1b0
60367620:  [<6008b9b0>] handle_irq_event+0x0/0x40
60367630:  [<6002e09c>] os_waiting_for_events+0x0/0xc5
60367658:  [<6008fccf>] rcu_irq_exit+0x5f/0xb0
603676a8:  [<6001d713>] segv_handler+0x53/0xb0
603676c8:  [<60019b5c>] sigio_handler+0xac/0xc0
603676f8:  [<6002ff5a>] sig_handler_common+0xa4/0xb9
60367708:  [<6005f170>] __mutex_init+0x0/0x20
60367718:  [<602a58bc>] printk+0x0/0xa8
60367780:  [] iio_buffer_register+0x46/0x610 [industrialio]
60367818:  [<60016c34>] _einittext+0x2572/0x38f6
60367828:  [<60016728>] _einittext+0x2066/0x38f6
60367908:  [<60016c34>] _einittext+0x2572/0x38f6
603679a8:  [<60019b70>] to_irq_stack+0x0/0xe0
60367a28:  [<60019b70>] to_irq_stack+0x0/0xe0
60367a38:  [<600300b5>] sig_handler+0x4a/0x5d
60367a58:  [<6002fb81>] hard_handler+0x89/0xd8
60367a90:  [<602a58bc>] printk+0x0/0xa8
60367aa0:  [<6005f170>] __mutex_init+0x0/0x20
60367b08:  [<602a58bc>] printk+0x0/0xa8
60367b18:  [<6005f170>] __mutex_init+0x0/0x20
60367b68:  [] iio_buffer_register+0x46/0x610 [industrialio]


Modules linked in: iio_dummy(C+) industrialio
Pid: 615, comm: modprobe Tainted: G C   3.6.0-rc6-00180-g68d0383-dirty
RIP: 0033:[<402eff9a>]
RSP: 007fbfbf6798  EFLAGS: 0246
RAX: ffda RBX:  RCX: 
RDX: 0060e110 RSI: 000148c9 RDI: 40024000
RBP: 00611b70 R08: 0060e100 R09: 
R10:  R11: 0246 R12: 0060e110
R13:  R14: 0060e010 R15: 00611b88
Call Trace: 
60367448:  [<6001db1e>] panic_exit+0x3e/0x60
60367478:  [<600616ad>] notifier_call_chain+0x4d/0x70
603674a0:  [] iio_buffer_register+0x46/0x610 [industrialio]
603674b8:  [<60061708>] atomic_notifier_call_chain+0x18/0x20
603674c8:  [<602a5784>] panic+0x179/0x2b1
60367500:  [] iio_buffer_register+0x46/0x610 [industrialio]
60367508:  [<602a560b>] panic+0x0/0x2b1
60367520:  [<6007a4d4>] __module_text_address+0x14/0x70
60367538:  [<6007ec20>] is_module_text_address+0x10/0x20
60367548:  [<600582c7>] __kernel_text_address+0x87/0xc0
60367568:  [<6001bc1f>] show_trace+0x7f/0xf0
60367598:  [] iio_buffer_register+0x46/0x610 [industrialio]
603675c0:  [] iio_buffer_register+0x46/0x610 [industrialio]

Re: mmotm 2012-09-20-17-25 uploaded (fs/bimfmt_elf on uml)

[Stephen Rothwell]

Hi Randy,

On Fri, 21 Sep 2012 08:23:09 -0700 Randy Dunlap  wrote:
>
> on uml for x86_64 defconfig:
> 
> fs/binfmt_elf.c: In function 'fill_files_note':
> fs/binfmt_elf.c:1419:2: error: implicit declaration of function 'vmalloc'
> fs/binfmt_elf.c:1419:7: warning: assignment makes pointer from integer 
> without a cast
> fs/binfmt_elf.c:1437:5: error: implicit declaration of function 'vfree'

reported in linux-next (offending patch reverted for other
problems).

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


pgp6P1ItUkFYr.pgp
Description: PGP signature

[PATCH 11/11] userns: Convert the ufs filesystem to use kuid/kgid where appropriate

[Eric W. Biederman]

From: "Eric W. Biederman" 

Cc: Evgeniy Dushistov 
Acked-by: Serge Hallyn 
Signed-off-by: Eric W. Biederman 
---
 fs/ufs/inode.c |   16 
 init/Kconfig   |1 -
 2 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/fs/ufs/inode.c b/fs/ufs/inode.c
index dd7c89d..eb6d0b7 100644
--- a/fs/ufs/inode.c
+++ b/fs/ufs/inode.c
@@ -597,8 +597,8 @@ static int ufs1_read_inode(struct inode *inode, struct 
ufs_inode *ufs_inode)
/*
 * Linux now has 32-bit uid and gid, so we can support EFT.
 */
-   inode->i_uid = ufs_get_inode_uid(sb, ufs_inode);
-   inode->i_gid = ufs_get_inode_gid(sb, ufs_inode);
+   i_uid_write(inode, ufs_get_inode_uid(sb, ufs_inode));
+   i_gid_write(inode, ufs_get_inode_gid(sb, ufs_inode));
 
inode->i_size = fs64_to_cpu(sb, ufs_inode->ui_size);
inode->i_atime.tv_sec = fs32_to_cpu(sb, ufs_inode->ui_atime.tv_sec);
@@ -645,8 +645,8 @@ static int ufs2_read_inode(struct inode *inode, struct 
ufs2_inode *ufs2_inode)
 /*
  * Linux now has 32-bit uid and gid, so we can support EFT.
  */
-   inode->i_uid = fs32_to_cpu(sb, ufs2_inode->ui_uid);
-   inode->i_gid = fs32_to_cpu(sb, ufs2_inode->ui_gid);
+   i_uid_write(inode, fs32_to_cpu(sb, ufs2_inode->ui_uid));
+   i_gid_write(inode, fs32_to_cpu(sb, ufs2_inode->ui_gid));
 
inode->i_size = fs64_to_cpu(sb, ufs2_inode->ui_size);
inode->i_atime.tv_sec = fs64_to_cpu(sb, ufs2_inode->ui_atime);
@@ -745,8 +745,8 @@ static void ufs1_update_inode(struct inode *inode, struct 
ufs_inode *ufs_inode)
ufs_inode->ui_mode = cpu_to_fs16(sb, inode->i_mode);
ufs_inode->ui_nlink = cpu_to_fs16(sb, inode->i_nlink);
 
-   ufs_set_inode_uid(sb, ufs_inode, inode->i_uid);
-   ufs_set_inode_gid(sb, ufs_inode, inode->i_gid);
+   ufs_set_inode_uid(sb, ufs_inode, i_uid_read(inode));
+   ufs_set_inode_gid(sb, ufs_inode, i_gid_read(inode));

ufs_inode->ui_size = cpu_to_fs64(sb, inode->i_size);
ufs_inode->ui_atime.tv_sec = cpu_to_fs32(sb, inode->i_atime.tv_sec);
@@ -789,8 +789,8 @@ static void ufs2_update_inode(struct inode *inode, struct 
ufs2_inode *ufs_inode)
ufs_inode->ui_mode = cpu_to_fs16(sb, inode->i_mode);
ufs_inode->ui_nlink = cpu_to_fs16(sb, inode->i_nlink);
 
-   ufs_inode->ui_uid = cpu_to_fs32(sb, inode->i_uid);
-   ufs_inode->ui_gid = cpu_to_fs32(sb, inode->i_gid);
+   ufs_inode->ui_uid = cpu_to_fs32(sb, i_uid_read(inode));
+   ufs_inode->ui_gid = cpu_to_fs32(sb, i_gid_read(inode));
 
ufs_inode->ui_size = cpu_to_fs64(sb, inode->i_size);
ufs_inode->ui_atime = cpu_to_fs64(sb, inode->i_atime.tv_sec);
diff --git a/init/Kconfig b/init/Kconfig
index 6f9819a..577916d 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -939,7 +939,6 @@ config UIDGID_CONVERTED
depends on NFSD = n
depends on NFS_FS = n
depends on OCFS2_FS = n
-   depends on UFS_FS = n
depends on XFS_FS = n
 
 config UIDGID_STRICT_TYPE_CHECKS
-- 
1.7.5.4

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

[PATCH 06/11] userns: Convert jfs to use kuid/kgid where appropriate

[Eric W. Biederman]

From: "Eric W. Biederman" 

Cc: Dave Kleikamp 
Signed-off-by: Eric W. Biederman 
---
 fs/jfs/file.c   |4 ++--
 fs/jfs/jfs_imap.c   |   22 --
 fs/jfs/jfs_incore.h |8 
 fs/jfs/super.c  |   22 +++---
 init/Kconfig|1 -
 5 files changed, 33 insertions(+), 24 deletions(-)

diff --git a/fs/jfs/file.c b/fs/jfs/file.c
index 844f946..9d3afd1 100644
--- a/fs/jfs/file.c
+++ b/fs/jfs/file.c
@@ -108,8 +108,8 @@ int jfs_setattr(struct dentry *dentry, struct iattr *iattr)
 
if (is_quota_modification(inode, iattr))
dquot_initialize(inode);
-   if ((iattr->ia_valid & ATTR_UID && iattr->ia_uid != inode->i_uid) ||
-   (iattr->ia_valid & ATTR_GID && iattr->ia_gid != inode->i_gid)) {
+   if ((iattr->ia_valid & ATTR_UID && !uid_eq(iattr->ia_uid, 
inode->i_uid)) ||
+   (iattr->ia_valid & ATTR_GID && !gid_eq(iattr->ia_gid, 
inode->i_gid))) {
rc = dquot_transfer(inode, iattr);
if (rc)
return rc;
diff --git a/fs/jfs/jfs_imap.c b/fs/jfs/jfs_imap.c
index 1b6f15f..6ba4006 100644
--- a/fs/jfs/jfs_imap.c
+++ b/fs/jfs/jfs_imap.c
@@ -3078,15 +3078,15 @@ static int copy_from_dinode(struct dinode * dip, struct 
inode *ip)
}
set_nlink(ip, le32_to_cpu(dip->di_nlink));
 
-   jfs_ip->saved_uid = le32_to_cpu(dip->di_uid);
-   if (sbi->uid == -1)
+   jfs_ip->saved_uid = make_kuid(_user_ns, le32_to_cpu(dip->di_uid));
+   if (!uid_valid(sbi->uid))
ip->i_uid = jfs_ip->saved_uid;
else {
ip->i_uid = sbi->uid;
}
 
-   jfs_ip->saved_gid = le32_to_cpu(dip->di_gid);
-   if (sbi->gid == -1)
+   jfs_ip->saved_gid = make_kgid(_user_ns, le32_to_cpu(dip->di_gid));
+   if (!gid_valid(sbi->gid))
ip->i_gid = jfs_ip->saved_gid;
else {
ip->i_gid = sbi->gid;
@@ -3150,14 +3150,16 @@ static void copy_to_dinode(struct dinode * dip, struct 
inode *ip)
dip->di_size = cpu_to_le64(ip->i_size);
dip->di_nblocks = cpu_to_le64(PBLK2LBLK(ip->i_sb, ip->i_blocks));
dip->di_nlink = cpu_to_le32(ip->i_nlink);
-   if (sbi->uid == -1)
-   dip->di_uid = cpu_to_le32(ip->i_uid);
+   if (!uid_valid(sbi->uid))
+   dip->di_uid = cpu_to_le32(i_uid_read(ip));
else
-   dip->di_uid = cpu_to_le32(jfs_ip->saved_uid);
-   if (sbi->gid == -1)
-   dip->di_gid = cpu_to_le32(ip->i_gid);
+   dip->di_uid =cpu_to_le32(from_kuid(_user_ns,
+  jfs_ip->saved_uid));
+   if (!gid_valid(sbi->gid))
+   dip->di_gid = cpu_to_le32(i_gid_read(ip));
else
-   dip->di_gid = cpu_to_le32(jfs_ip->saved_gid);
+   dip->di_gid = cpu_to_le32(from_kgid(_user_ns,
+   jfs_ip->saved_gid));
jfs_get_inode_flags(jfs_ip);
/*
 * mode2 is only needed for storing the higher order bits.
diff --git a/fs/jfs/jfs_incore.h b/fs/jfs/jfs_incore.h
index 584a4a1..680605d 100644
--- a/fs/jfs/jfs_incore.h
+++ b/fs/jfs/jfs_incore.h
@@ -38,8 +38,8 @@
 struct jfs_inode_info {
int fileset;/* fileset number (always 16)*/
uintmode2;  /* jfs-specific mode*/
-   uintsaved_uid;  /* saved for uid mount option */
-   uintsaved_gid;  /* saved for gid mount option */
+   kuid_t  saved_uid;  /* saved for uid mount option */
+   kgid_t  saved_gid;  /* saved for gid mount option */
pxd_t   ixpxd;  /* inode extent descriptor  */
dxd_t   acl;/* dxd describing acl   */
dxd_t   ea; /* dxd describing ea*/
@@ -192,8 +192,8 @@ struct jfs_sb_info {
uintstate;  /* mount/recovery state */
unsigned long   flag;   /* mount time flags */
uintp_state;/* state prior to going no integrity */
-   uintuid;/* uid to override on-disk uid */
-   uintgid;/* gid to override on-disk gid */
+   kuid_t  uid;/* uid to override on-disk uid */
+   kgid_t  gid;/* gid to override on-disk gid */
uintumask;  /* umask to override on-disk umask */
 };
 
diff --git a/fs/jfs/super.c b/fs/jfs/super.c
index c55c745..706692f 100644
--- a/fs/jfs/super.c
+++ b/fs/jfs/super.c
@@ -321,13 +321,19 @@ static int parse_options(char *options, struct 
super_block *sb, s64 *newLVSize,
case Opt_uid:
{
char *uid = args[0].from;
-   sbi->uid = simple_strtoul(uid, , 0);
+   uid_t val = simple_strtoul(uid, , 0);
+   sbi->uid = make_kuid(current_user_ns(), val);
+ 

[PATCH 04/11] userns: Convert hpfs to use kuid and kgid where appropriate

[Eric W. Biederman]

From: "Eric W. Biederman" 

Cc: Mikulas Patocka 
Acked-by: Serge Hallyn 
Signed-off-by: Eric W. Biederman 
---
 fs/hpfs/hpfs_fn.h |4 ++--
 fs/hpfs/inode.c   |   19 +++
 fs/hpfs/namei.c   |8 
 fs/hpfs/super.c   |   18 +++---
 init/Kconfig  |1 -
 5 files changed, 28 insertions(+), 22 deletions(-)

diff --git a/fs/hpfs/hpfs_fn.h b/fs/hpfs/hpfs_fn.h
index ac1ead1..7102aae 100644
--- a/fs/hpfs/hpfs_fn.h
+++ b/fs/hpfs/hpfs_fn.h
@@ -63,8 +63,8 @@ struct hpfs_sb_info {
unsigned sb_dmap;   /* sector number of dnode bit map */
unsigned sb_n_free; /* free blocks for statfs, or -1 */
unsigned sb_n_free_dnodes;  /* free dnodes for statfs, or -1 */
-   uid_t sb_uid;   /* uid from mount options */
-   gid_t sb_gid;   /* gid from mount options */
+   kuid_t sb_uid;  /* uid from mount options */
+   kgid_t sb_gid;  /* gid from mount options */
umode_t sb_mode;/* mode from mount options */
unsigned sb_eas : 2;/* eas: 0-ignore, 1-ro, 2-rw */
unsigned sb_err : 2;/* on errs: 0-cont, 1-ro, 2-panic */
diff --git a/fs/hpfs/inode.c b/fs/hpfs/inode.c
index ed671e0..804a9a8 100644
--- a/fs/hpfs/inode.c
+++ b/fs/hpfs/inode.c
@@ -7,6 +7,7 @@
  */
 
 #include 
+#include 
 #include "hpfs_fn.h"
 
 void hpfs_init_inode(struct inode *i)
@@ -60,14 +61,14 @@ void hpfs_read_inode(struct inode *i)
if (hpfs_sb(i->i_sb)->sb_eas) {
if ((ea = hpfs_get_ea(i->i_sb, fnode, "UID", _size))) {
if (ea_size == 2) {
-   i->i_uid = le16_to_cpu(*(__le16*)ea);
+   i_uid_write(i, le16_to_cpu(*(__le16*)ea));
hpfs_inode->i_ea_uid = 1;
}
kfree(ea);
}
if ((ea = hpfs_get_ea(i->i_sb, fnode, "GID", _size))) {
if (ea_size == 2) {
-   i->i_gid = le16_to_cpu(*(__le16*)ea);
+   i_gid_write(i, le16_to_cpu(*(__le16*)ea));
hpfs_inode->i_ea_gid = 1;
}
kfree(ea);
@@ -149,13 +150,13 @@ static void hpfs_write_inode_ea(struct inode *i, struct 
fnode *fnode)
hpfs_error(i->i_sb, "fnode %08x has some unknown HPFS386 
stuctures", i->i_ino);
} else*/ if (hpfs_sb(i->i_sb)->sb_eas >= 2) {
__le32 ea;
-   if ((i->i_uid != hpfs_sb(i->i_sb)->sb_uid) || 
hpfs_inode->i_ea_uid) {
-   ea = cpu_to_le32(i->i_uid);
+   if (!uid_eq(i->i_uid, hpfs_sb(i->i_sb)->sb_uid) || 
hpfs_inode->i_ea_uid) {
+   ea = cpu_to_le32(i_uid_read(i));
hpfs_set_ea(i, fnode, "UID", (char*), 2);
hpfs_inode->i_ea_uid = 1;
}
-   if ((i->i_gid != hpfs_sb(i->i_sb)->sb_gid) || 
hpfs_inode->i_ea_gid) {
-   ea = cpu_to_le32(i->i_gid);
+   if (!gid_eq(i->i_gid, hpfs_sb(i->i_sb)->sb_gid) || 
hpfs_inode->i_ea_gid) {
+   ea = cpu_to_le32(i_gid_read(i));
hpfs_set_ea(i, fnode, "GID", (char *), 2);
hpfs_inode->i_ea_gid = 1;
}
@@ -261,9 +262,11 @@ int hpfs_setattr(struct dentry *dentry, struct iattr *attr)
hpfs_lock(inode->i_sb);
if (inode->i_ino == hpfs_sb(inode->i_sb)->sb_root)
goto out_unlock;
-   if ((attr->ia_valid & ATTR_UID) && attr->ia_uid >= 0x1)
+   if ((attr->ia_valid & ATTR_UID) &&
+   from_kuid(_user_ns, attr->ia_uid) >= 0x1)
goto out_unlock;
-   if ((attr->ia_valid & ATTR_GID) && attr->ia_gid >= 0x1)
+   if ((attr->ia_valid & ATTR_GID) &&
+   from_kgid(_user_ns, attr->ia_gid) >= 0x1)
goto out_unlock;
if ((attr->ia_valid & ATTR_SIZE) && attr->ia_size > inode->i_size)
goto out_unlock;
diff --git a/fs/hpfs/namei.c b/fs/hpfs/namei.c
index bc90824..345713d 100644
--- a/fs/hpfs/namei.c
+++ b/fs/hpfs/namei.c
@@ -91,8 +91,8 @@ static int hpfs_mkdir(struct inode *dir, struct dentry 
*dentry, umode_t mode)
inc_nlink(dir);
insert_inode_hash(result);
 
-   if (result->i_uid != current_fsuid() ||
-   result->i_gid != current_fsgid() ||
+   if (!uid_eq(result->i_uid, current_fsuid()) ||
+   !gid_eq(result->i_gid, current_fsgid()) ||
result->i_mode != (mode | S_IFDIR)) {
result->i_uid = current_fsuid();
result->i_gid = current_fsgid();
@@ -179,8 +179,8 @@ static int hpfs_create(struct inode *dir, struct dentry 
*dentry, umode_t mode, b
 
insert_inode_hash(result);
 
-   if (result->i_uid != current_fsuid() 

[PATCH 10/11] userns: Convert the udf filesystem to use kuid/kgid where appropriate

[Eric W. Biederman]

From: "Eric W. Biederman" 

Cc: Jan Kara 
Acked-by: Serge Hallyn 
Signed-off-by: Eric W. Biederman 
---
 fs/udf/inode.c |   20 
 init/Kconfig   |1 -
 2 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index fafaad7..2e6fb4d 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1250,6 +1250,8 @@ static void udf_fill_inode(struct inode *inode, struct 
buffer_head *bh)
struct udf_sb_info *sbi = UDF_SB(inode->i_sb);
struct udf_inode_info *iinfo = UDF_I(inode);
unsigned int link_count;
+   uid_t i_uid;
+   gid_t i_gid;
 
fe = (struct fileEntry *)bh->b_data;
efe = (struct extendedFileEntry *)bh->b_data;
@@ -1309,17 +1311,19 @@ static void udf_fill_inode(struct inode *inode, struct 
buffer_head *bh)
}
 
read_lock(>s_cred_lock);
-   inode->i_uid = le32_to_cpu(fe->uid);
-   if (inode->i_uid == -1 ||
+   i_uid = le32_to_cpu(fe->uid);
+   if (i_uid == -1 ||
UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_UID_IGNORE) ||
UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_UID_SET))
-   inode->i_uid = UDF_SB(inode->i_sb)->s_uid;
+   i_uid = UDF_SB(inode->i_sb)->s_uid;
+   i_uid_write(inode, i_uid);
 
-   inode->i_gid = le32_to_cpu(fe->gid);
-   if (inode->i_gid == -1 ||
+   i_gid = le32_to_cpu(fe->gid);
+   if (i_gid == -1 ||
UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_GID_IGNORE) ||
UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_GID_SET))
-   inode->i_gid = UDF_SB(inode->i_sb)->s_gid;
+   i_gid = UDF_SB(inode->i_sb)->s_gid;
+   i_gid_write(inode, i_gid);
 
if (fe->icbTag.fileType != ICBTAG_FILE_TYPE_DIRECTORY &&
sbi->s_fmode != UDF_INVALID_MODE)
@@ -1539,12 +1543,12 @@ static int udf_update_inode(struct inode *inode, int 
do_sync)
if (UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_UID_FORGET))
fe->uid = cpu_to_le32(-1);
else
-   fe->uid = cpu_to_le32(inode->i_uid);
+   fe->uid = cpu_to_le32(i_uid_read(inode));
 
if (UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_GID_FORGET))
fe->gid = cpu_to_le32(-1);
else
-   fe->gid = cpu_to_le32(inode->i_gid);
+   fe->gid = cpu_to_le32(i_gid_read(inode));
 
udfperms = ((inode->i_mode & S_IRWXO)) |
   ((inode->i_mode & S_IRWXG) << 2) |
diff --git a/init/Kconfig b/init/Kconfig
index 21adc1c..6f9819a 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -939,7 +939,6 @@ config UIDGID_CONVERTED
depends on NFSD = n
depends on NFS_FS = n
depends on OCFS2_FS = n
-   depends on UDF_FS = n
depends on UFS_FS = n
depends on XFS_FS = n
 
-- 
1.7.5.4

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

[PATCH 2/2] extcon: unregister compat link on cleanup

[Peter Huewe]

Since extcon registers this compat link at device registration
(extcon_dev_register), we should probably remove them at deregistration/cleanup.

Cc: sta...@vger.kernel.org
Signed-off-by: Peter Huewe 
---
 drivers/extcon/extcon_class.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/extcon/extcon_class.c b/drivers/extcon/extcon_class.c
index 6e914d0..7610b4e 100644
--- a/drivers/extcon/extcon_class.c
+++ b/drivers/extcon/extcon_class.c
@@ -575,6 +575,11 @@ static void extcon_cleanup(struct extcon_dev *edev, bool 
skip)
kfree(edev->cables);
}
 
+#if defined(CONFIG_ANDROID)
+   if (switch_class)
+   ret = class_compat_remove_link(switch_class, edev->dev,
+  NULL);
+#endif /* CONFIG_ANDROID */
device_unregister(edev->dev);
put_device(edev->dev);
}
-- 
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/

[PATCH 1/2] extcon: Unregister compat class at module unload to fix oops

[Peter Huewe]

If you compile extcon with CONFIG_ANDROID and then load and unload the
module you get a simple oops as the driver does not unregister its
compat class and thus cannot register it again.

Full trace:

root@(none):~# modprobe extcon_class
root@(none):~# rmmod extcon_class
root@(none):~# modprobe extcon_class
[ cut here ]
WARNING: at fs/sysfs/dir.c:536 sysfs_add_one+0xde/0x100()
sysfs: cannot create duplicate filename '/class/switch'
Modules linked in: extcon_class(+) [last unloaded: extcon_class]
Call Trace:
9f451a00:  [<602a58bc>] printk+0x0/0xa8
9f451a18:  [<60039b43>] warn_slowpath_common+0x93/0xd0
9f451a28:  [<6012c6de>] sysfs_add_one+0xde/0x100
9f451a50:  [<601d3d90>] strcat+0x0/0x40
9f451a68:  [<60039cdc>] warn_slowpath_fmt+0x9c/0xa0
9f451a90:  [<6002fe32>] unblock_signals+0x0/0x84
9f451ab0:  [<60039c40>] warn_slowpath_fmt+0x0/0xa0
9f451ac0:  [<6002fe32>] unblock_signals+0x0/0x84
9f451ae8:  [<6012bd97>] sysfs_pathname.isra.10+0x57/0x70
9f451b00:  [<601d3d90>] strcat+0x0/0x40
9f451b18:  [<6012bd97>] sysfs_pathname.isra.10+0x57/0x70
9f451b48:  [<6012c6de>] sysfs_add_one+0xde/0x100
9f451b78:  [<6012c96f>] create_dir+0x8f/0x100
9f451bc0:  [] extcon_class_init+0x0/0x12 [extcon_class]
9f451bd8:  [<6012cda6>] sysfs_create_dir+0xa6/0x1c0
9f451be8:  [<601d89f1>] kvasprintf+0x81/0xa0
9f451bf8:  [<601cf0f0>] kobject_get+0x0/0x50
9f451c18:  [<601cf396>] kobject_add_internal+0x96/0x280
9f451c60:  [] extcon_class_init+0x0/0x12 [extcon_class]
9f451c78:  [<601cfb93>] kobject_add+0xd3/0x140
9f451cc0:  [<601cfac0>] kobject_add+0x0/0x140
9f451cd0:  [<6002fe32>] unblock_signals+0x0/0x84
9f451cf8:  [<6002fffc>] set_signals+0x29/0x3f
9f451d28:  [<600c1de1>] kmem_cache_alloc+0xe1/0x100
9f451d78:  [<601cffa0>] kobject_create_and_add+0x50/0xa0
9f451da8:  [<601fbe76>] class_compat_register+0x56/0x80
9f451dc8:  [] create_extcon_class+0x88/0xd0 [extcon_class]
9f451de8:  [] extcon_class_init+0x10/0x12 [extcon_class]
9f451df8:  [<600189a8>] do_one_initcall+0x48/0x1f0
9f451e20:  [<60061920>] blocking_notifier_call_chain+0x0/0x20
9f451e30:  [<60061920>] blocking_notifier_call_chain+0x0/0x20
9f451e58:  [<6007e3c3>] sys_init_module+0xa3/0x280
9f451e88:  [<6001e2ad>] handle_syscall+0x8d/0x90
9f451ea8:  [<60033370>] userspace+0x405/0x531
9f451ee8:  [<6001e380>] copy_chunk_to_user+0x0/0x40
9f451ef8:  [<6001e5cd>] do_op_one_page+0x14d/0x220
9f451fd8:  [<6001a355>] fork_handler+0x95/0xa0

---[ end trace dd512cc03fe1c367 ]---
[ cut here ]
WARNING: at lib/kobject.c:196 kobject_add_internal+0x26e/0x280()
kobject_add_internal failed for switch with -EEXIST, don't try to
register things with the same name in the same directory.
Modules linked in: extcon_class(+) [last unloaded: extcon_class]
Call Trace:
9f451ad0:  [<602a58bc>] printk+0x0/0xa8
9f451ae8:  [<60039b43>] warn_slowpath_common+0x93/0xd0
9f451af8:  [<601cf56e>] kobject_add_internal+0x26e/0x280
9f451b18:  [<601cf140>] kobject_put+0x0/0x70
9f451b20:  [] extcon_class_init+0x0/0x12 [extcon_class]
9f451b38:  [<60039cdc>] warn_slowpath_fmt+0x9c/0xa0
9f451b88:  [<60039c40>] warn_slowpath_fmt+0x0/0xa0
9f451bc0:  [] extcon_class_init+0x0/0x12 [extcon_class]
9f451bd8:  [<6012cda6>] sysfs_create_dir+0xa6/0x1c0
9f451be8:  [<601d89f1>] kvasprintf+0x81/0xa0
9f451bf8:  [<601cf0f0>] kobject_get+0x0/0x50
9f451c18:  [<601cf56e>] kobject_add_internal+0x26e/0x280
9f451c60:  [] extcon_class_init+0x0/0x12 [extcon_class]
9f451c78:  [<601cfb93>] kobject_add+0xd3/0x140
9f451cc0:  [<601cfac0>] kobject_add+0x0/0x140
9f451cd0:  [<6002fe32>] unblock_signals+0x0/0x84
9f451cf8:  [<6002fffc>] set_signals+0x29/0x3f
9f451d28:  [<600c1de1>] kmem_cache_alloc+0xe1/0x100
9f451d78:  [<601cffa0>] kobject_create_and_add+0x50/0xa0
9f451da8:  [<601fbe76>] class_compat_register+0x56/0x80
9f451dc8:  [] create_extcon_class+0x88/0xd0 [extcon_class]
9f451de8:  [] extcon_class_init+0x10/0x12 [extcon_class]
9f451df8:  [<600189a8>] do_one_initcall+0x48/0x1f0
9f451e20:  [<60061920>] blocking_notifier_call_chain+0x0/0x20
9f451e30:  [<60061920>] blocking_notifier_call_chain+0x0/0x20
9f451e58:  [<6007e3c3>] sys_init_module+0xa3/0x280
9f451e88:  [<6001e2ad>] handle_syscall+0x8d/0x90
9f451ea8:  [<60033370>] userspace+0x405/0x531
9f451ee8:  [<6001e380>] copy_chunk_to_user+0x0/0x40
9f451ef8:  [<6001e5cd>] do_op_one_page+0x14d/0x220
9f451fd8:  [<6001a355>] fork_handler+0x95/0xa0

---[ end trace dd512cc03fe1c368 ]---
kobject_create_and_add: kobject_add error: -17
[ cut here ]
WARNING: at drivers/extcon/extcon_class.c:545
create_extcon_class+0xbc/0xd0 [extcon_class]()
cannot allocate
Modules linked in: extcon_class(+) [last unloaded: extcon_class]
Call Trace:
9f451c80:  [<602a58bc>] printk+0x0/0xa8
9f451c98:  [<60039b43>] warn_slowpath_common+0x93/0xd0
9f451ca0:  [<6002fe32>] unblock_signals+0x0/0x84
9f451ca8:  [] create_extcon_class+0xbc/0xd0 [extcon_class]
9f451cd0:  [] extcon_class_init+0x0/0x12 [extcon_class]
9f451ce8:  [<60039cdc>] warn_slowpath_fmt+0x9c/0xa0
9f451d20:  

[PATCH 09/11] userns: Convert ubifs to use kuid/kgid

[Eric W. Biederman]

From: "Eric W. Biederman" 

Cc: Artem Bityutskiy 
Cc: Adrian Hunter 
Acked-by: Serge Hallyn 
Signed-off-by: Eric W. Biederman 
---
 fs/ubifs/budget.c  |4 ++--
 fs/ubifs/debug.c   |4 ++--
 fs/ubifs/journal.c |4 ++--
 fs/ubifs/sb.c  |4 ++--
 fs/ubifs/super.c   |4 ++--
 fs/ubifs/ubifs.h   |4 ++--
 init/Kconfig   |1 -
 7 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/fs/ubifs/budget.c b/fs/ubifs/budget.c
index bc4f94b..969489e 100644
--- a/fs/ubifs/budget.c
+++ b/fs/ubifs/budget.c
@@ -272,8 +272,8 @@ long long ubifs_calc_available(const struct ubifs_info *c, 
int min_idx_lebs)
  */
 static int can_use_rp(struct ubifs_info *c)
 {
-   if (current_fsuid() == c->rp_uid || capable(CAP_SYS_RESOURCE) ||
-   (c->rp_gid != 0 && in_group_p(c->rp_gid)))
+   if (uid_eq(current_fsuid(), c->rp_uid) || capable(CAP_SYS_RESOURCE) ||
+   (!gid_eq(c->rp_gid, GLOBAL_ROOT_GID) && in_group_p(c->rp_gid)))
return 1;
return 0;
 }
diff --git a/fs/ubifs/debug.c b/fs/ubifs/debug.c
index bb31672..340d1af 100644
--- a/fs/ubifs/debug.c
+++ b/fs/ubifs/debug.c
@@ -243,8 +243,8 @@ void ubifs_dump_inode(struct ubifs_info *c, const struct 
inode *inode)
printk(KERN_ERR "\tsize   %llu\n",
   (unsigned long long)i_size_read(inode));
printk(KERN_ERR "\tnlink  %u\n", inode->i_nlink);
-   printk(KERN_ERR "\tuid%u\n", (unsigned int)inode->i_uid);
-   printk(KERN_ERR "\tgid%u\n", (unsigned int)inode->i_gid);
+   printk(KERN_ERR "\tuid%u\n", (unsigned 
int)i_uid_read(inode));
+   printk(KERN_ERR "\tgid%u\n", (unsigned 
int)i_gid_read(inode));
printk(KERN_ERR "\tatime  %u.%u\n",
   (unsigned int)inode->i_atime.tv_sec,
   (unsigned int)inode->i_atime.tv_nsec);
diff --git a/fs/ubifs/journal.c b/fs/ubifs/journal.c
index 12c0f15..afaad07 100644
--- a/fs/ubifs/journal.c
+++ b/fs/ubifs/journal.c
@@ -469,8 +469,8 @@ static void pack_inode(struct ubifs_info *c, struct 
ubifs_ino_node *ino,
ino->ctime_nsec = cpu_to_le32(inode->i_ctime.tv_nsec);
ino->mtime_sec  = cpu_to_le64(inode->i_mtime.tv_sec);
ino->mtime_nsec = cpu_to_le32(inode->i_mtime.tv_nsec);
-   ino->uid   = cpu_to_le32(inode->i_uid);
-   ino->gid   = cpu_to_le32(inode->i_gid);
+   ino->uid   = cpu_to_le32(i_uid_read(inode));
+   ino->gid   = cpu_to_le32(i_gid_read(inode));
ino->mode  = cpu_to_le32(inode->i_mode);
ino->flags = cpu_to_le32(ui->flags);
ino->size  = cpu_to_le64(ui->ui_size);
diff --git a/fs/ubifs/sb.c b/fs/ubifs/sb.c
index 15e2fc5..52c21f4 100644
--- a/fs/ubifs/sb.c
+++ b/fs/ubifs/sb.c
@@ -611,8 +611,8 @@ int ubifs_read_superblock(struct ubifs_info *c)
c->fanout= le32_to_cpu(sup->fanout);
c->lsave_cnt = le32_to_cpu(sup->lsave_cnt);
c->rp_size   = le64_to_cpu(sup->rp_size);
-   c->rp_uid= le32_to_cpu(sup->rp_uid);
-   c->rp_gid= le32_to_cpu(sup->rp_gid);
+   c->rp_uid= make_kuid(_user_ns, le32_to_cpu(sup->rp_uid));
+   c->rp_gid= make_kgid(_user_ns, le32_to_cpu(sup->rp_gid));
sup_flags= le32_to_cpu(sup->flags);
if (!c->mount_opts.override_compr)
c->default_compr = le16_to_cpu(sup->default_compr);
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index 1c766c3..f39bad9 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -130,8 +130,8 @@ struct inode *ubifs_iget(struct super_block *sb, unsigned 
long inum)
 
inode->i_flags |= (S_NOCMTIME | S_NOATIME);
set_nlink(inode, le32_to_cpu(ino->nlink));
-   inode->i_uid   = le32_to_cpu(ino->uid);
-   inode->i_gid   = le32_to_cpu(ino->gid);
+   i_uid_write(inode, le32_to_cpu(ino->uid));
+   i_gid_write(inode, le32_to_cpu(ino->gid));
inode->i_atime.tv_sec  = (int64_t)le64_to_cpu(ino->atime_sec);
inode->i_atime.tv_nsec = le32_to_cpu(ino->atime_nsec);
inode->i_mtime.tv_sec  = (int64_t)le64_to_cpu(ino->mtime_sec);
diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h
index 1e5a086..64f2367 100644
--- a/fs/ubifs/ubifs.h
+++ b/fs/ubifs/ubifs.h
@@ -1426,8 +1426,8 @@ struct ubifs_info {
 
long long rp_size;
long long report_rp_size;
-   uid_t rp_uid;
-   gid_t rp_gid;
+   kuid_t rp_uid;
+   kgid_t rp_gid;
 
/* The below fields are used only during mounting and re-mounting */
unsigned int empty:1;
diff --git a/init/Kconfig b/init/Kconfig
index d88f945..21adc1c 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -939,7 +939,6 @@ config UIDGID_CONVERTED
depends on NFSD = n
depends on NFS_FS = n
depends on OCFS2_FS = n
-   depends on UBIFS_FS = n
depends on UDF_FS = n
depends on UFS_FS = n
depends on XFS_FS = n
-- 
1.7.5.4

--
To unsubscribe from this list: send the line "unsubscribe 

[PATCH 08/11] userns: Convert squashfs to use kuid/kgid where appropriate

[Eric W. Biederman]

From: "Eric W. Biederman" 

Cc: Phillip Lougher 
Acked-by: Serge Hallyn 
Signed-off-by: Eric W. Biederman 
---
 fs/squashfs/inode.c |8 ++--
 init/Kconfig|1 -
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/fs/squashfs/inode.c b/fs/squashfs/inode.c
index 81afbcc..a1ce5ce 100644
--- a/fs/squashfs/inode.c
+++ b/fs/squashfs/inode.c
@@ -56,16 +56,20 @@
 static int squashfs_new_inode(struct super_block *sb, struct inode *inode,
struct squashfs_base_inode *sqsh_ino)
 {
+   uid_t i_uid;
+   gid_t i_gid;
int err;
 
-   err = squashfs_get_id(sb, le16_to_cpu(sqsh_ino->uid), >i_uid);
+   err = squashfs_get_id(sb, le16_to_cpu(sqsh_ino->uid), _uid);
if (err)
return err;
 
-   err = squashfs_get_id(sb, le16_to_cpu(sqsh_ino->guid), >i_gid);
+   err = squashfs_get_id(sb, le16_to_cpu(sqsh_ino->guid), _gid);
if (err)
return err;
 
+   i_uid_write(inode, i_uid);
+   i_gid_write(inode, i_gid);
inode->i_ino = le32_to_cpu(sqsh_ino->inode_number);
inode->i_mtime.tv_sec = le32_to_cpu(sqsh_ino->mtime);
inode->i_atime.tv_sec = inode->i_mtime.tv_sec;
diff --git a/init/Kconfig b/init/Kconfig
index 8b11f29..d88f945 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -939,7 +939,6 @@ config UIDGID_CONVERTED
depends on NFSD = n
depends on NFS_FS = n
depends on OCFS2_FS = n
-   depends on SQUASHFS = n
depends on UBIFS_FS = n
depends on UDF_FS = n
depends on UFS_FS = n
-- 
1.7.5.4

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

[PATCH 07/11] userns: Convert reiserfs to use kuid and kgid where appropriate

[Eric W. Biederman]

From: "Eric W. Biederman" 

Cc: reiserfs-de...@vger.kernel.org
Signed-off-by: Eric W. Biederman 
---
 fs/reiserfs/inode.c |   26 +-
 fs/reiserfs/xattr_acl.c |   20 +---
 init/Kconfig|1 -
 3 files changed, 30 insertions(+), 17 deletions(-)

diff --git a/fs/reiserfs/inode.c b/fs/reiserfs/inode.c
index a6d4268..7119f48 100644
--- a/fs/reiserfs/inode.c
+++ b/fs/reiserfs/inode.c
@@ -1155,8 +1155,8 @@ static void init_inode(struct inode *inode, struct 
treepath *path)
set_inode_sd_version(inode, STAT_DATA_V1);
inode->i_mode = sd_v1_mode(sd);
set_nlink(inode, sd_v1_nlink(sd));
-   inode->i_uid = sd_v1_uid(sd);
-   inode->i_gid = sd_v1_gid(sd);
+   i_uid_write(inode, sd_v1_uid(sd));
+   i_gid_write(inode, sd_v1_gid(sd));
inode->i_size = sd_v1_size(sd);
inode->i_atime.tv_sec = sd_v1_atime(sd);
inode->i_mtime.tv_sec = sd_v1_mtime(sd);
@@ -1200,9 +1200,9 @@ static void init_inode(struct inode *inode, struct 
treepath *path)
 
inode->i_mode = sd_v2_mode(sd);
set_nlink(inode, sd_v2_nlink(sd));
-   inode->i_uid = sd_v2_uid(sd);
+   i_uid_write(inode, sd_v2_uid(sd));
inode->i_size = sd_v2_size(sd);
-   inode->i_gid = sd_v2_gid(sd);
+   i_gid_write(inode, sd_v2_gid(sd));
inode->i_mtime.tv_sec = sd_v2_mtime(sd);
inode->i_atime.tv_sec = sd_v2_atime(sd);
inode->i_ctime.tv_sec = sd_v2_ctime(sd);
@@ -1258,9 +1258,9 @@ static void inode2sd(void *sd, struct inode *inode, 
loff_t size)
 
set_sd_v2_mode(sd_v2, inode->i_mode);
set_sd_v2_nlink(sd_v2, inode->i_nlink);
-   set_sd_v2_uid(sd_v2, inode->i_uid);
+   set_sd_v2_uid(sd_v2, i_uid_read(inode));
set_sd_v2_size(sd_v2, size);
-   set_sd_v2_gid(sd_v2, inode->i_gid);
+   set_sd_v2_gid(sd_v2, i_gid_read(inode));
set_sd_v2_mtime(sd_v2, inode->i_mtime.tv_sec);
set_sd_v2_atime(sd_v2, inode->i_atime.tv_sec);
set_sd_v2_ctime(sd_v2, inode->i_ctime.tv_sec);
@@ -1280,8 +1280,8 @@ static void inode2sd_v1(void *sd, struct inode *inode, 
loff_t size)
struct stat_data_v1 *sd_v1 = (struct stat_data_v1 *)sd;
 
set_sd_v1_mode(sd_v1, inode->i_mode);
-   set_sd_v1_uid(sd_v1, inode->i_uid);
-   set_sd_v1_gid(sd_v1, inode->i_gid);
+   set_sd_v1_uid(sd_v1, i_uid_read(inode));
+   set_sd_v1_gid(sd_v1, i_gid_read(inode));
set_sd_v1_nlink(sd_v1, inode->i_nlink);
set_sd_v1_size(sd_v1, size);
set_sd_v1_atime(sd_v1, inode->i_atime.tv_sec);
@@ -1869,7 +1869,7 @@ int reiserfs_new_inode(struct reiserfs_transaction_handle 
*th,
goto out_bad_inode;
}
if (old_format_only(sb)) {
-   if (inode->i_uid & ~0x || inode->i_gid & ~0x) {
+   if (i_uid_read(inode) & ~0x || i_gid_read(inode) & ~0x) 
{
pathrelse(_to_key);
/* i_uid or i_gid is too big to be stored in stat data 
v3.5 */
err = -EINVAL;
@@ -3140,16 +3140,16 @@ int reiserfs_setattr(struct dentry *dentry, struct 
iattr *attr)
}
}
 
-   if attr->ia_valid & ATTR_UID) && (attr->ia_uid & ~0x)) ||
-((attr->ia_valid & ATTR_GID) && (attr->ia_gid & ~0x))) &&
+   if attr->ia_valid & ATTR_UID) && (from_kuid(_user_ns, 
attr->ia_uid) & ~0x)) ||
+((attr->ia_valid & ATTR_GID) && (from_kgid(_user_ns, 
attr->ia_gid) & ~0x))) &&
(get_inode_sd_version(inode) == STAT_DATA_V1)) {
/* stat data of format v3.5 has 16 bit uid and gid */
error = -EINVAL;
goto out;
}
 
-   if ((ia_valid & ATTR_UID && attr->ia_uid != inode->i_uid) ||
-   (ia_valid & ATTR_GID && attr->ia_gid != inode->i_gid)) {
+   if ((ia_valid & ATTR_UID && !uid_eq(attr->ia_uid, inode->i_uid)) ||
+   (ia_valid & ATTR_GID && !gid_eq(attr->ia_gid, inode->i_gid))) {
struct reiserfs_transaction_handle th;
int jbegin_count =
2 *
diff --git a/fs/reiserfs/xattr_acl.c b/fs/reiserfs/xattr_acl.c
index 87d6911..d7c01ef 100644
--- a/fs/reiserfs/xattr_acl.c
+++ b/fs/reiserfs/xattr_acl.c
@@ -121,15 +121,23 @@ static struct posix_acl *posix_acl_from_disk(const void 
*value, size_t size)
case ACL_OTHER:
value = (char *)value +
sizeof(reiserfs_acl_entry_short);
-   acl->a_entries[n].e_id = ACL_UNDEFINED_ID;
break;
 
case ACL_USER:
+   value = (char *)value + sizeof(reiserfs_acl_entry);
+   if ((char *)value > end)
+   goto 

[PATCH 05/11] userns: Convert jffs2 to use kuid and kgid where appropriate

[Eric W. Biederman]

From: "Eric W. Biederman" 

- General routine uid/gid conversion work
- When storing posix acls treat ACL_USER and ACL_GROUP separately
  so I can call from_kuid or from_kgid as appropriate.
- When reading posix acls treat ACL_USER and ACL_GROUP separately
  so I can call make_kuid or make_kgid as appropriate.

Cc: David Woodhouse 
Signed-off-by: Eric W. Biederman 
---
 fs/jffs2/acl.c  |   26 --
 fs/jffs2/file.c |8 
 fs/jffs2/fs.c   |   24 +---
 fs/jffs2/os-linux.h |4 ++--
 init/Kconfig|1 -
 5 files changed, 39 insertions(+), 24 deletions(-)

diff --git a/fs/jffs2/acl.c b/fs/jffs2/acl.c
index 42e4edc..223283c 100644
--- a/fs/jffs2/acl.c
+++ b/fs/jffs2/acl.c
@@ -94,15 +94,23 @@ static struct posix_acl *jffs2_acl_from_medium(void *value, 
size_t size)
case ACL_MASK:
case ACL_OTHER:
value += sizeof(struct jffs2_acl_entry_short);
-   acl->a_entries[i].e_id = ACL_UNDEFINED_ID;
break;
 
case ACL_USER:
+   value += sizeof(struct jffs2_acl_entry);
+   if (value > end)
+   goto fail;
+   acl->a_entries[i].e_uid =
+   make_kuid(_user_ns,
+ je32_to_cpu(entry->e_id));
+   break;
case ACL_GROUP:
value += sizeof(struct jffs2_acl_entry);
if (value > end)
goto fail;
-   acl->a_entries[i].e_id = 
je32_to_cpu(entry->e_id);
+   acl->a_entries[i].e_gid =
+   make_kgid(_user_ns,
+ je32_to_cpu(entry->e_id));
break;
 
default:
@@ -131,13 +139,19 @@ static void *jffs2_acl_to_medium(const struct posix_acl 
*acl, size_t *size)
header->a_version = cpu_to_je32(JFFS2_ACL_VERSION);
e = header + 1;
for (i=0; i < acl->a_count; i++) {
+   const struct posix_acl_entry *acl_e = >a_entries[i];
entry = e;
-   entry->e_tag = cpu_to_je16(acl->a_entries[i].e_tag);
-   entry->e_perm = cpu_to_je16(acl->a_entries[i].e_perm);
-   switch(acl->a_entries[i].e_tag) {
+   entry->e_tag = cpu_to_je16(acl_e->e_tag);
+   entry->e_perm = cpu_to_je16(acl_e->e_perm);
+   switch(acl_e->e_tag) {
case ACL_USER:
+   entry->e_id = cpu_to_je32(
+   from_kuid(_user_ns, acl_e->e_uid));
+   e += sizeof(struct jffs2_acl_entry);
+   break;
case ACL_GROUP:
-   entry->e_id = 
cpu_to_je32(acl->a_entries[i].e_id);
+   entry->e_id = cpu_to_je32(
+   from_kgid(_user_ns, acl_e->e_gid));
e += sizeof(struct jffs2_acl_entry);
break;
 
diff --git a/fs/jffs2/file.c b/fs/jffs2/file.c
index db3889b..60ef3fb 100644
--- a/fs/jffs2/file.c
+++ b/fs/jffs2/file.c
@@ -175,8 +175,8 @@ static int jffs2_write_begin(struct file *filp, struct 
address_space *mapping,
ri.ino = cpu_to_je32(f->inocache->ino);
ri.version = cpu_to_je32(++f->highest_version);
ri.mode = cpu_to_jemode(inode->i_mode);
-   ri.uid = cpu_to_je16(inode->i_uid);
-   ri.gid = cpu_to_je16(inode->i_gid);
+   ri.uid = cpu_to_je16(i_uid_read(inode));
+   ri.gid = cpu_to_je16(i_gid_read(inode));
ri.isize = cpu_to_je32(max((uint32_t)inode->i_size, pageofs));
ri.atime = ri.ctime = ri.mtime = cpu_to_je32(get_seconds());
ri.offset = cpu_to_je32(inode->i_size);
@@ -283,8 +283,8 @@ static int jffs2_write_end(struct file *filp, struct 
address_space *mapping,
/* Set the fields that the generic jffs2_write_inode_range() code can't 
find */
ri->ino = cpu_to_je32(inode->i_ino);
ri->mode = cpu_to_jemode(inode->i_mode);
-   ri->uid = cpu_to_je16(inode->i_uid);
-   ri->gid = cpu_to_je16(inode->i_gid);
+   ri->uid = cpu_to_je16(i_uid_read(inode));
+   ri->gid = cpu_to_je16(i_gid_read(inode));
ri->isize = cpu_to_je32((uint32_t)inode->i_size);
ri->atime = ri->ctime = ri->mtime = cpu_to_je32(get_seconds());
 
diff --git a/fs/jffs2/fs.c b/fs/jffs2/fs.c
index 3d3092e..fe3c052 100644
--- a/fs/jffs2/fs.c
+++ b/fs/jffs2/fs.c
@@ 

[PATCH 03/11] userns: Convert btrfs to use kuid/kgid where appropriate

[Eric W. Biederman]

From: "Eric W. Biederman" 

Cc: Chris Mason 
Acked-by: Serge Hallyn 
Signed-off-by: Eric W. Biederman 
---
 fs/btrfs/delayed-inode.c |8 
 fs/btrfs/inode.c |8 
 fs/btrfs/ioctl.c |6 +++---
 init/Kconfig |1 -
 4 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
index 335605c..f908c51 100644
--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -1715,8 +1715,8 @@ static void fill_stack_inode_item(struct 
btrfs_trans_handle *trans,
  struct btrfs_inode_item *inode_item,
  struct inode *inode)
 {
-   btrfs_set_stack_inode_uid(inode_item, inode->i_uid);
-   btrfs_set_stack_inode_gid(inode_item, inode->i_gid);
+   btrfs_set_stack_inode_uid(inode_item, i_uid_read(inode));
+   btrfs_set_stack_inode_gid(inode_item, i_gid_read(inode));
btrfs_set_stack_inode_size(inode_item, BTRFS_I(inode)->disk_i_size);
btrfs_set_stack_inode_mode(inode_item, inode->i_mode);
btrfs_set_stack_inode_nlink(inode_item, inode->i_nlink);
@@ -1764,8 +1764,8 @@ int btrfs_fill_inode(struct inode *inode, u32 *rdev)
 
inode_item = _node->inode_item;
 
-   inode->i_uid = btrfs_stack_inode_uid(inode_item);
-   inode->i_gid = btrfs_stack_inode_gid(inode_item);
+   i_uid_write(inode, btrfs_stack_inode_uid(inode_item));
+   i_gid_write(inode, btrfs_stack_inode_gid(inode_item));
btrfs_i_size_write(inode, btrfs_stack_inode_size(inode_item));
inode->i_mode = btrfs_stack_inode_mode(inode_item);
set_nlink(inode, btrfs_stack_inode_nlink(inode_item));
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 83baec2..5368714 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2570,8 +2570,8 @@ static void btrfs_read_locked_inode(struct inode *inode)
struct btrfs_inode_item);
inode->i_mode = btrfs_inode_mode(leaf, inode_item);
set_nlink(inode, btrfs_inode_nlink(leaf, inode_item));
-   inode->i_uid = btrfs_inode_uid(leaf, inode_item);
-   inode->i_gid = btrfs_inode_gid(leaf, inode_item);
+   i_uid_write(inode, btrfs_inode_uid(leaf, inode_item));
+   i_gid_write(inode, btrfs_inode_gid(leaf, inode_item));
btrfs_i_size_write(inode, btrfs_inode_size(leaf, inode_item));
 
tspec = btrfs_inode_atime(inode_item);
@@ -2649,8 +2649,8 @@ static void fill_inode_item(struct btrfs_trans_handle 
*trans,
struct btrfs_inode_item *item,
struct inode *inode)
 {
-   btrfs_set_inode_uid(leaf, item, inode->i_uid);
-   btrfs_set_inode_gid(leaf, item, inode->i_gid);
+   btrfs_set_inode_uid(leaf, item, i_uid_read(inode));
+   btrfs_set_inode_gid(leaf, item, i_gid_read(inode));
btrfs_set_inode_size(leaf, item, BTRFS_I(inode)->disk_i_size);
btrfs_set_inode_mode(leaf, item, inode->i_mode);
btrfs_set_inode_nlink(leaf, item, inode->i_nlink);
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index bc2f6ff..1292682 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -575,13 +575,13 @@ fail:
 */
 static inline int btrfs_check_sticky(struct inode *dir, struct inode *inode)
 {
-   uid_t fsuid = current_fsuid();
+   kuid_t fsuid = current_fsuid();
 
if (!(dir->i_mode & S_ISVTX))
return 0;
-   if (inode->i_uid == fsuid)
+   if (uid_eq(inode->i_uid, fsuid))
return 0;
-   if (dir->i_uid == fsuid)
+   if (uid_eq(dir->i_uid, fsuid))
return 0;
return !capable(CAP_FOWNER);
 }
diff --git a/init/Kconfig b/init/Kconfig
index fd91d2b..44f580f 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -930,7 +930,6 @@ config UIDGID_CONVERTED
depends on 9P_FS = n
depends on AFS_FS = n
depends on AUTOFS4_FS = n
-   depends on BTRFS_FS = n
depends on CEPH_FS = n
depends on CIFS = n
depends on CODA_FS = n
-- 
1.7.5.4

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

[PATCH 02/11] userns: Convert bfs to use kuid/kgid where appropriate

[Eric W. Biederman]

From: "Eric W. Biederman" 

Cc: "Tigran A. Aivazian" 
Acked-by: Serge Hallyn 
Signed-off-by: Eric W. Biederman 
---
 fs/bfs/inode.c |8 
 init/Kconfig   |1 -
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/fs/bfs/inode.c b/fs/bfs/inode.c
index 9870417..b242beb 100644
--- a/fs/bfs/inode.c
+++ b/fs/bfs/inode.c
@@ -76,8 +76,8 @@ struct inode *bfs_iget(struct super_block *sb, unsigned long 
ino)
BFS_I(inode)->i_sblock =  le32_to_cpu(di->i_sblock);
BFS_I(inode)->i_eblock =  le32_to_cpu(di->i_eblock);
BFS_I(inode)->i_dsk_ino = le16_to_cpu(di->i_ino);
-   inode->i_uid =  le32_to_cpu(di->i_uid);
-   inode->i_gid =  le32_to_cpu(di->i_gid);
+   i_uid_write(inode, le32_to_cpu(di->i_uid));
+   i_gid_write(inode,  le32_to_cpu(di->i_gid));
set_nlink(inode, le32_to_cpu(di->i_nlink));
inode->i_size = BFS_FILESIZE(di);
inode->i_blocks = BFS_FILEBLOCKS(di);
@@ -139,8 +139,8 @@ static int bfs_write_inode(struct inode *inode, struct 
writeback_control *wbc)
 
di->i_ino = cpu_to_le16(ino);
di->i_mode = cpu_to_le32(inode->i_mode);
-   di->i_uid = cpu_to_le32(inode->i_uid);
-   di->i_gid = cpu_to_le32(inode->i_gid);
+   di->i_uid = cpu_to_le32(i_uid_read(inode));
+   di->i_gid = cpu_to_le32(i_gid_read(inode));
di->i_nlink = cpu_to_le32(inode->i_nlink);
di->i_atime = cpu_to_le32(inode->i_atime.tv_sec);
di->i_mtime = cpu_to_le32(inode->i_mtime.tv_sec);
diff --git a/init/Kconfig b/init/Kconfig
index a358f4a..fd91d2b 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -930,7 +930,6 @@ config UIDGID_CONVERTED
depends on 9P_FS = n
depends on AFS_FS = n
depends on AUTOFS4_FS = n
-   depends on BFS_FS = n
depends on BTRFS_FS = n
depends on CEPH_FS = n
depends on CIFS = n
-- 
1.7.5.4

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

[PATCH 01/11] userns: Convert affs to use kuid/kgid wherwe appropriate

[Eric W. Biederman]

From: "Eric W. Biederman" 

Acked-by: Serge Hallyn 
Signed-off-by: Eric W. Biederman 
---
 fs/affs/affs.h  |4 ++--
 fs/affs/inode.c |   20 ++--
 fs/affs/super.c |   18 +++---
 init/Kconfig|1 -
 4 files changed, 23 insertions(+), 20 deletions(-)

diff --git a/fs/affs/affs.h b/fs/affs/affs.h
index 6e21641..3952121 100644
--- a/fs/affs/affs.h
+++ b/fs/affs/affs.h
@@ -88,8 +88,8 @@ struct affs_sb_info {
u32 s_root_block;   /* FFS root block number. */
int s_hashsize; /* Size of hash table. */
unsigned long s_flags;  /* See below. */
-   uid_t s_uid;/* uid to override */
-   gid_t s_gid;/* gid to override */
+   kuid_t s_uid;   /* uid to override */
+   kgid_t s_gid;   /* gid to override */
umode_t s_mode; /* mode to override */
struct buffer_head *s_root_bh;  /* Cached root block. */
struct mutex s_bmlock;  /* Protects bitmap access. */
diff --git a/fs/affs/inode.c b/fs/affs/inode.c
index 8bc4a59..15c4842 100644
--- a/fs/affs/inode.c
+++ b/fs/affs/inode.c
@@ -80,17 +80,17 @@ struct inode *affs_iget(struct super_block *sb, unsigned 
long ino)
if (id == 0 || sbi->s_flags & SF_SETUID)
inode->i_uid = sbi->s_uid;
else if (id == 0x && sbi->s_flags & SF_MUFS)
-   inode->i_uid = 0;
+   i_uid_write(inode, 0);
else
-   inode->i_uid = id;
+   i_uid_write(inode, id);
 
id = be16_to_cpu(tail->gid);
if (id == 0 || sbi->s_flags & SF_SETGID)
inode->i_gid = sbi->s_gid;
else if (id == 0x && sbi->s_flags & SF_MUFS)
-   inode->i_gid = 0;
+   i_gid_write(inode, 0);
else
-   inode->i_gid = id;
+   i_gid_write(inode, id);
 
switch (be32_to_cpu(tail->stype)) {
case ST_ROOT:
@@ -193,13 +193,13 @@ affs_write_inode(struct inode *inode, struct 
writeback_control *wbc)
tail->size = cpu_to_be32(inode->i_size);
secs_to_datestamp(inode->i_mtime.tv_sec,>change);
if (!(inode->i_ino == AFFS_SB(sb)->s_root_block)) {
-   uid = inode->i_uid;
-   gid = inode->i_gid;
+   uid = i_uid_read(inode);
+   gid = i_gid_read(inode);
if (AFFS_SB(sb)->s_flags & SF_MUFS) {
-   if (inode->i_uid == 0 || inode->i_uid == 0x)
-   uid = inode->i_uid ^ ~0;
-   if (inode->i_gid == 0 || inode->i_gid == 0x)
-   gid = inode->i_gid ^ ~0;
+   if (uid == 0 || uid == 0x)
+   uid = uid ^ ~0;
+   if (gid == 0 || gid == 0x)
+   gid = gid ^ ~0;
}
if (!(AFFS_SB(sb)->s_flags & SF_SETUID))
tail->uid = cpu_to_be16(uid);
diff --git a/fs/affs/super.c b/fs/affs/super.c
index c70f1e5..966c8c0 100644
--- a/fs/affs/super.c
+++ b/fs/affs/super.c
@@ -188,7 +188,7 @@ static const match_table_t tokens = {
 };
 
 static int
-parse_options(char *options, uid_t *uid, gid_t *gid, int *mode, int *reserved, 
s32 *root,
+parse_options(char *options, kuid_t *uid, kgid_t *gid, int *mode, int 
*reserved, s32 *root,
int *blocksize, char **prefix, char *volume, unsigned long 
*mount_opts)
 {
char *p;
@@ -253,13 +253,17 @@ parse_options(char *options, uid_t *uid, gid_t *gid, int 
*mode, int *reserved, s
case Opt_setgid:
if (match_int([0], ))
return 0;
-   *gid = option;
+   *gid = make_kgid(current_user_ns(), option);
+   if (!gid_valid(*gid))
+   return 0;
*mount_opts |= SF_SETGID;
break;
case Opt_setuid:
if (match_int([0], ))
return 0;
-   *uid = option;
+   *uid = make_kuid(current_user_ns(), option);
+   if (!uid_valid(*uid))
+   return 0;
*mount_opts |= SF_SETUID;
break;
case Opt_verbose:
@@ -301,8 +305,8 @@ static int affs_fill_super(struct super_block *sb, void 
*data, int silent)
int  num_bm;
int  i, j;
s32  key;
-   uid_tuid;
-   gid_tgid;
+   kuid_t   uid;
+   

[REVIEW][PATCH 00/11] userns: Simple filesystems conversions

[Eric W. Biederman]

This continus my conversion of filesystems to support running
when kernel user namespace supprot is enabled.  This time I have
targed the filesystems that I had to look twice at to verify
the changes were correct.

The strategy is to convert the structures in the kernel where we store
uid_t and gid_t to to kuid_t and kgid_t.  To assume all file systems are
encoded in the initial user namespace for purposes of conversions.
Mount options containing uids and gids along with other user space
interfaces are of assumed to be encoded in the current user namespace.

These patches are against:
git.kernel.org:/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-next

Eric W. Biederman (11):
  userns: Convert affs to use kuid/kgid wherwe appropriate
  userns: Convert bfs to use kuid/kgid where appropriate
  userns: Convert btrfs to use kuid/kgid where appropriate
  userns: Convert hpfs to use kuid and kgid where appropriate
  userns: Convert jffs2 to use kuid and kgid where appropriate
  userns: Convert jfs to use kuid/kgid where appropriate
  userns: Convert reiserfs to use kuid and kgid where appropriate
  userns: Convert squashfs to use kuid/kgid where appropriate
  userns: Convert ubifs to use kuid/kgid
  userns: Convert the udf filesystem to use kuid/kgid where appropriate
  userns: Convert the ufs filesystem to use kuid/kgid where appropriate

 fs/affs/affs.h   |4 ++--
 fs/affs/inode.c  |   20 ++--
 fs/affs/super.c  |   18 +++---
 fs/bfs/inode.c   |8 
 fs/btrfs/delayed-inode.c |8 
 fs/btrfs/inode.c |8 
 fs/btrfs/ioctl.c |6 +++---
 fs/hpfs/hpfs_fn.h|4 ++--
 fs/hpfs/inode.c  |   19 +++
 fs/hpfs/namei.c  |8 
 fs/hpfs/super.c  |   18 +++---
 fs/jffs2/acl.c   |   26 --
 fs/jffs2/file.c  |8 
 fs/jffs2/fs.c|   24 +---
 fs/jffs2/os-linux.h  |4 ++--
 fs/jfs/file.c|4 ++--
 fs/jfs/jfs_imap.c|   22 --
 fs/jfs/jfs_incore.h  |8 
 fs/jfs/super.c   |   22 +++---
 fs/reiserfs/inode.c  |   26 +-
 fs/reiserfs/xattr_acl.c  |   20 +---
 fs/squashfs/inode.c  |8 ++--
 fs/ubifs/budget.c|4 ++--
 fs/ubifs/debug.c |4 ++--
 fs/ubifs/journal.c   |4 ++--
 fs/ubifs/sb.c|4 ++--
 fs/ubifs/super.c |4 ++--
 fs/ubifs/ubifs.h |4 ++--
 fs/udf/inode.c   |   12 ++--
 fs/udf/super.c   |   20 
 fs/udf/udf_sb.h  |4 ++--
 fs/ufs/inode.c   |   16 
 init/Kconfig |   11 ---
 33 files changed, 214 insertions(+), 166 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ext4: remove static from struct match_token used in token2str

[Herton Ronaldo Krzesinski]

There is no reason to use static there, and it will cause issues when
reading /proc/fs/ext4//options concurrently.

Signed-off-by: Herton Ronaldo Krzesinski 
Cc: sta...@vger.kernel.org # 3.4+
---
 fs/ext4/super.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

The problem is easy to reproduce, for example running:
$ cat /proc/fs/ext4//options > options.txt
$ while diff /proc/fs/ext4//options options.txt; do true; done
- And concurrently on another terminal:
$ while diff /proc/fs/ext4//options options.txt; do true; done

One of the diff loops will get incomplete options contents because of
the issue, and exit.

I also believe the same problem is the cause of the following bug:
https://bugs.launchpad.net/bugs/1053019, that happened while running
test 234 from xfstests.

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 41598ee..975405c 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1748,7 +1748,7 @@ static inline void ext4_show_quota_options(struct 
seq_file *seq,
 
 static const char *token2str(int token)
 {
-   static const struct match_token *t;
+   const struct match_token *t;
 
for (t = tokens; t->token != Opt_err; t++)
if (t->token == token && !strchr(t->pattern, '='))
-- 
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: Helping with backports: linux-next, linux, linux-stable - a few enhancements

[Stephen Rothwell]

Hi Luis,

On Fri, 21 Sep 2012 09:24:44 -0700 "Luis R. Rodriguez" 
 wrote:
>
> > I don't see how pulling linux-stable into linux-next really helps anyone
> > out, linux-stable is so far behind what is in linux-next it's not funny.
> 
> By pulling linux-stable into linux-next you get to be able to run
> things like this from within linux-next:
> 
> git format-patch --grep="sta...@vger.kernel.org" -o
> $PENDING_STABLE_DIR v3.5.4.. $MY_FILES
> 
> That is, from v3.5.4 up to that day's linux-next tag.
> 
> Without linux-stable linux-next does not get the v3.5.4 tags to allow
> me / users of compat-drivers to do this. We do this to accelerate the
> incorporation of stable pending-stable patches into a release based on
> a stable extraversion release.

You need to have linux-stable as a remote in your tree then.
linux-stable and linux-next are independent tree and will never share any
commits that are not in Linus' tree as well.  I do not need more commits
and tags in my tree than I already have.

> Right, absolutely! Using a remote arrangements fixes this completely
> for me. I alone can live happy doing what I do but since I have users
> depending on using compat-drivers to make their own set of releases
> and test things it means I have to get folks using compat-drivers to
> also set up the same git remotes arrangements. That's fine but I'm
> looking to simplify it if I can for users.

If they fetch from your tree, and your tree has Linus' tree and
linux-next and linux-stable in it (and you have local tracking branches
for those trees, or they explicitly use --tags when they fetch) then they
will get all that from you.

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


pgpn4sR3OVmwf.pgp
Description: PGP signature

Re: [PATCH 00/10] Convert MSM to common clock framework

[Mike Turquette]

Quoting Stephen Boyd (2012-09-20 19:26:48)
> This patchset moves the existing MSM clock code and affected drivers to the
> common clock framework. A prerequisite of moving to the common clock
> framework is to use clk_prepare() and clk_enable() so the first
> few patches migrate drivers to that call (clk_prepare() is a no-op on MSM
> right now). It also removes some custom clock APIs that MSM provides
> and finally moves the proc_comm clock code to the common struct clock.
> 
> This patch series will be used as the foundation of the MSM 8660/8960
> clock code that I plan to send out soon.
> 
> These patches have one dependency on the devm_clk_register() function
> which I already posted to the list[1]. They're based on linux-next-20120917.
> 

Hi Stephen,

Thanks for sending this!  It is too much churn to take in for the 3.7
merge window.  As such I'll put reviewing this on my TODO list, but it
might wait until after the merge window settles down.


Regards,
Mike

> Stephen Boyd (10):
>   usb: otg: msm: Convert to clk_prepare/unprepare
>   msm_sdcc: Convert to clk_prepare/unprepare
>   msm: iommu: Convert to clk_prepare/unprepare
>   msm: iommu: Use clk_set_rate() instead of clk_set_min_rate()
>   ARM: msm: Remove custom clk_set_flags() API
>   ARM: msm: Remove custom clk_set_{max,min}_rate() API
>   ARM: msm: Remove clock-7x30.h include file
>   ARM: msm: Prepare clk_get() users in mach-msm for clock-pcom driver
>   ARM: msm: Make proc_comm clock control into a platform driver
>   ARM: msm: Migrate to common clock framework
> 
>  arch/arm/Kconfig   |   1 +
>  arch/arm/mach-msm/Makefile |  10 +-
>  arch/arm/mach-msm/board-halibut.c  |   2 +-
>  arch/arm/mach-msm/board-msm7x30.c  |   2 +-
>  arch/arm/mach-msm/board-qsd8x50.c  |   2 +-
>  arch/arm/mach-msm/board-trout-panel.c  |  19 ++--
>  arch/arm/mach-msm/board-trout.c|   3 +-
>  arch/arm/mach-msm/clock-7x30.h | 155 --
>  arch/arm/mach-msm/clock-debug.c| 130 --
>  arch/arm/mach-msm/clock-pcom.c | 149 ++---
>  arch/arm/mach-msm/clock-pcom.h |  31 +++---
>  arch/arm/mach-msm/clock.c  | 166 
> +
>  arch/arm/mach-msm/clock.h  |  51 +++---
>  arch/arm/mach-msm/devices-msm7x00.c|  12 ++-
>  arch/arm/mach-msm/devices-msm7x30.c|  13 ++-
>  arch/arm/mach-msm/devices-qsd8x50.c|  11 ++-
>  arch/arm/mach-msm/devices.h|  15 +--
>  arch/arm/mach-msm/dma.c|   5 +-
>  arch/arm/mach-msm/include/mach/board.h |   5 -
>  arch/arm/mach-msm/include/mach/clk.h   |   9 --
>  drivers/iommu/msm_iommu_dev.c  |  20 ++--
>  drivers/mmc/host/msm_sdcc.c|  14 ++-
>  drivers/usb/otg/msm_otg.c  |  38 
>  23 files changed, 222 insertions(+), 641 deletions(-)
>  delete mode 100644 arch/arm/mach-msm/clock-7x30.h
>  delete mode 100644 arch/arm/mach-msm/clock-debug.c
> 
> [1] https://lkml.org/lkml/2012/9/19/28
> 
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm: add support for zsmalloc and zcache

[Mel Gorman]

On Fri, Sep 21, 2012 at 01:35:15PM -0700, Dan Magenheimer wrote:
> > From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com]
> > Subject: Re: [RFC] mm: add support for zsmalloc and zcache
> > 
> > On 09/21/2012 01:02 PM, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Sep 21, 2012 at 05:12:52PM +0100, Mel Gorman wrote:
> > >> On Tue, Sep 04, 2012 at 04:34:46PM -0500, Seth Jennings wrote:
> > >>> zcache is the remaining piece of code required to support in-kernel
> > >>> memory compression.  The other two features, cleancache and frontswap,
> > >>> have been promoted to mainline in 3.0 and 3.5 respectively.  This
> > >>> patchset promotes zcache from the staging tree to mainline.
> > 
> > >>
> > >> Very broadly speaking my initial reaction before I reviewed anything was
> > >> that *some* sort of usable backend for cleancache or frontswap should 
> > >> exist
> > >> at this point. My understanding is that Xen is the primary user of both
> > >> those frontends and ramster, while interesting, is not something that a
> > >> typical user will benefit from.
> > >
> > > Right, the majority of users do not use virtualization. Thought embedded
> > > wise .. well, there are a lot of Android users - thought I am not 100%
> > > sure they are using it right now (I recall seeing changelogs for the 
> > > clones
> > > of Android mentioning zcache).
> > >>
> > >> That said, I worry that this has bounced around a lot and as Dan (the
> > >> original author) has a rewrite. I'm wary of spending too much time on 
> > >> this
> > >> at all. Is Dan's new code going to replace this or what? It'd be nice to
> > >> find a definitive answer on that.
> > >
> > > The idea is to take parts of zcache2 as seperate patches and stick it
> > > in the code you just reviewed (those that make sense as part of 
> > > unstaging).
> > 
> > I agree with this.  Only the changes from zcache2 (Dan's
> > rewrite) that are necessary for promotion should be
> > considered right now.  Afaict, none of the concerns raised
> > in these comments are addressed by the changes in zcache2.
> 
> While I may agree with the proposed end result, this proposal
> is a _very_ long way away from a solution.  To me, it sounds like
> a "split the baby in half" proposal (cf. wisdom of Solomon)
> which may sound reasonable to some but, in the end, everyone loses.
> 

I tend to agree but this really is an unhappy situation that should be
resolved in the coming weeks instead of months if it's going to move
forward.

> I have proposed a reasonable compromise offlist to Seth, but
> it appears that it has been silently rejected; I guess it is
> now time to take the proposal public.  I apologize in advance
> for my characteristic bluntness...
> 

Meh, I'm ok with blunt.

> So let's consider two proposals and the pros and cons of them,
> before we waste any further mm developer time.  (Fortunately,
> most of Mel's insightful comments apply to both versions, though
> he did identify some of the design issues that led to zcache2!)
> 
> The two proposals:
> A) Recreate all the work done for zcache2 as a proper sequence of
>independent patches and apply them to zcache1. (Seth/Konrad)
> B) Add zsmalloc back in to zcache2 as an alternative allocator
>for frontswap pages. (Dan)

Throwing it out there but 

C) Merge both, but freeze zcache1 except for critical fixes. Only allow
   future work on zcache2. Document limitations of zcache1 and
   workarounds until zcache2 is fully production ready.

> 
> Pros for (A):
> 1. It better preserves the history of the handful of (non-zsmalloc)
>commits in the original zcache code.

Marginal benefit.

> 2. Seth[1] can incrementally learn the new designs by reading
>normal kernel patches.

Which would be nice but that is not exactly compelling.

> 3. For kernel purists, it is the _right_ way dammit (and Dan
>should be shot for redesigning code non-incrementally, even
>if it was in staging, etc.)

Yes, but there are historical examples of ditching something completely
too. USB has been ditched a few times. Andrea shot a large chunk of the
VM out the window in 2.6.10. jbd vs jbd2 is still there.

> 4. Seth believes that zcache will be promoted out of staging sooner
>because, except for a few nits, it is ready today.
> 

I wouldn't call them minor but it's probably better understood by more
people. It's why I'd be sortof ok with promoting zcache1 as long as
the limitations were clearly understood and there was a migration path
to zcache2.

> Cons for (A):
> 1. Nobody has signed up to do the work, including testing.  It
>took the author (and sole expert on all the components
>except zsmalloc) between two and three months essentially
>fulltime to move zcache1->zcache2.  So forward progress on
>zcache will likely be essentially frozen until at least the
>end of 2012, possibly a lot longer.

This to me is a big issue. It's one reason why I think it would be ok for
zcache1 + zcache2 to exist in parallel but 

Re: pull request: bluetooth-next 2012-09-18

[Luis R. Rodriguez]

On Tue, Sep 18, 2012 at 6:31 PM, Gustavo Padovan  wrote:

> Johan Hedberg (2):
>   Bluetooth: mgmt: Implement support for passkey notification

Too late now... but why did we allow this a stable fix? I get its a
feature that is important and likely overlooked / someone had a brain
fart, but from what I gather this is not on v3.5.4 and yet may make it
to v3.5.5. At least for backporting this was a bitch:

/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3290:52:
error: dereferencing pointer to incomplete type
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3294:6:
error: ‘struct hci_conn’ has no member named ‘passkey_notify’
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3294:25:
error: dereferencing pointer to incomplete type
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3295:6:
error: ‘struct hci_conn’ has no member named ‘passkey_entered’
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3298:3:
error: implicit declaration of function ‘mgmt_user_passkey_notify’
[-Werror=implicit-function-declaration]
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3299:27:
error: ‘struct hci_conn’ has no member named ‘passkey_notify’
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3300:11:
error: ‘struct hci_conn’ has no member named ‘passkey_entered’
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:
In function ‘hci_keypress_notify_evt’:
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3310:52:
error: dereferencing pointer to incomplete type
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3314:12:
error: dereferencing pointer to incomplete type
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3315:7:
error: ‘HCI_KEYPRESS_STARTED’ undeclared (first use in this function)
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3315:7:
note: each undeclared identifier is reported only once for each
function it appears in
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3316:7:
error: ‘struct hci_conn’ has no member named ‘passkey_entered’
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3319:7:
error: ‘HCI_KEYPRESS_ENTERED’ undeclared (first use in this function)
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3320:7:
error: ‘struct hci_conn’ has no member named ‘passkey_entered’
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3323:7:
error: ‘HCI_KEYPRESS_ERASED’ undeclared (first use in this function)
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3324:7:
error: ‘struct hci_conn’ has no member named ‘passkey_entered’
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3327:7:
error: ‘HCI_KEYPRESS_CLEARED’ undeclared (first use in this function)
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3328:7:
error: ‘struct hci_conn’ has no member named ‘passkey_entered’
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3331:7:
error: ‘HCI_KEYPRESS_COMPLETED’ undeclared (first use in this
function)
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3337:27:
error: ‘struct hci_conn’ has no member named ‘passkey_notify’
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3338:11:
error: ‘struct hci_conn’ has no member named ‘passkey_entered’
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:
In function ‘hci_event_packet’:
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3701:7:
error: ‘HCI_EV_USER_PASSKEY_NOTIFY’ undeclared (first use in this
function)
/home/mcgrof/staging/v3.5.4/compat-wireless-3.5.3-2-snpc/net/bluetooth/hci_event.c:3705:7:
error: ‘HCI_EV_KEYPRESS_NOTIFY’ undeclared (first use in this
function)

I'd much prefer to see things like these identified as 'important' but
not 'fuck, this fixes that crash'. The fact that kernel maintainers
may be anal about these sorts of patches is *good* for many reasons
and figuring out a way to categorize, identify and allow users to reap
benefits of backporting suck fixes / cherry picking a full solution is
what something that should not interfere and hopefully be transparent
to Linux upstream development.

Here's one way I dealt with these type of patches:

https://backports.wiki.kernel.org/index.php/Documentation/compat-drivers/additional-patches

If you look at the patch 'Bluetooth: mgmt: Implement support for
passkey' its  a clear "feature" implementation, not a fucking fix.

  

Re: Linux 3.6-rc6

[Shaun Ruffell]

On Sun, Sep 16, 2012 at 03:59:09PM -0700, Linus Torvalds wrote:
> 
> Please do test things out, I'd really like to be able to do the final
> 3.6 soonish..

Linus,

Just a heads up in case you are about to tag v3.6.

v3.6-rc6 still has a regression with edac_mc_alloc()/edac_mc_free()
introduced in commit de3910eb79ac8c0f29a11224661c0ebaaf813039.
edac_mc_free() assumes that struct mem_ctl_info is registered in
sysfs but there are error paths where this is not always the case.

I posted patches [1,2,3] that resolve the issue for me. Shaohui Xie
also hit the issue and posted a slightly different patch [4]. The
patches are currently waiting for Mauro, who I understand is
catching up since returning from San Diego, to check them out.

[1] http://marc.info/?l=linux-kernel=134764595921752=2
[2] http://marc.info/?l=linux-kernel=134764594721747=2
[3] http://marc.info/?l=linux-kernel=134764597921761=2
[4] http://marc.info/?l=linux-kernel=134753579818528=2

Without the patches I'll always hit on boot:

[  36.703479] BUG: unable to handle kernel NULL pointer dereference at   (null)
[  36.703479] IP: [] __wake_up_common+0x1a/0x6a
[  36.703479] *pde = 7f0c6067
[  36.703479] Oops:  [#1] SMP
[  36.703479] Modules linked in: parport_pc parport floppy e7xxx_edac(+) 
ide_cd_mod edac_core intel_rng cdrom microcode(+) dm_snapshot dm_zero dm_mirror 
dm_region_hash d
[  36.703479] Pid: 933, comm: modprobe Tainted: GW
3.6.0-rc2-00111-gc1999ee #12 Dell Computer Corporation PowerEdge 2600   
  /0F0364
[  36.703479] EIP: 0060:[] EFLAGS: 00010093 CPU: 3
[  36.703479] EIP is at __wake_up_common+0x1a/0x6a
[  36.703479] EAX: f47b0984 EBX: fff4 ECX:  EDX: 0003
[  36.703479] ESI: f47b0984 EDI: 0282 EBP: f3dc7d38 ESP: f3dc7d1c
[  36.703479]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[  36.703479] CR0: 8005003b CR2:  CR3: 347d4000 CR4: 07d0
[  36.703479] DR0:  DR1:  DR2:  DR3: 
[  36.703479] DR6: 0ff0 DR7: 0400
[  36.703479] Process modprobe (pid: 933, ti=f3dc6000 task=f3db9520 
task.ti=f3dc6000)
[  36.703479] Stack:
[  36.703479]    0003 c046701a f47b0980 f47b0984 0282 
f3dc7d54
[  36.703479]  c046703f   f47b08b0 f47b08b0  f3dc7d74 
c06961ce
[  36.703479]  f3dc7d74 f3dc7d80 c05e2837 c094c4cc f47b08b0 f47b08b0 f3dc7d88 
c068d56d
[  36.703479] Call Trace:
[  36.703479]  [] ? complete_all+0x1a/0x50
[  36.703479]  [] complete_all+0x3f/0x50
[  36.703479]  [] device_pm_remove+0x23/0xa2
[  36.703479]  [] ? kobject_put+0x5b/0x5d
[  36.703479]  [] device_del+0x34/0x142
[  36.703479]  [] edac_unregister_sysfs+0x3b/0x5c [edac_core]
[  36.703479]  [] edac_mc_free+0x29/0x2f [edac_core]
[  36.703479]  [] e7xxx_probe1+0x268/0x311 [e7xxx_edac]
[  36.703479]  [] ? __pci_enable_device_flags+0x8f/0xd3
[  36.703479]  [] e7xxx_init_one+0x56/0x61 [e7xxx_edac]
[  36.703479]  [] local_pci_probe+0x13/0x15
...

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

Re: [PATCH] pda_power: remove ac_draw_failed goto and label

[Paul Parsons]

Hello Anton,

On 22/09/12 00:51, Anton Vorontsov wrote:

On Fri, Sep 21, 2012 at 01:56:43AM +0100, Paul Parsons wrote:

A previous patch added the ac_draw_failed goto and label to
pda_power_probe(). The goto would be invoked after a failed call to
regulator_get().

However the way ac_draw is used - always after a check for NULL -
suggests that a failed call to regulator_get() was not fatal.

This patch removes the ac_draw_failed goto and label, partly reverting
the previous patch.

This patch also removes the assignment of an error code to ret after a
failed call to regulator_get(), since the error code is now never used.

Signed-off-by: Paul Parsons 
Cc: Philipp Zabel 
---
  drivers/power/pda_power.c |3 ---
  1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/power/pda_power.c b/drivers/power/pda_power.c
index d3be834d..7df7c5f 100644
--- a/drivers/power/pda_power.c
+++ b/drivers/power/pda_power.c
@@ -284,9 +284,7 @@ static int pda_power_probe(struct platform_device *pdev)
ac_draw = regulator_get(dev, "ac_draw");
if (IS_ERR(ac_draw)) {
dev_dbg(dev, "couldn't get ac_draw regulator\n");
-   ret = PTR_ERR(ac_draw);
ac_draw = NULL;
-   goto ac_draw_failed;


For some reason you have a bit different code, so your patch is not based
on the battery tree. (In my tree ret and ac_draw assignments are swapped.)
Maybe that's because I had to manually redo your first patch...

Anyway, I repeated your patch by hand again and thus applied it.


Yes, in my first patch I had swapped the ret and ac_draw assignments
when I moved the regulator_get() call to before the update_charger()
call. This was because the original order of the assignments:

ac_draw = NULL;
ret = PTR_ERR(ac_draw);

is obviously incorrect; the ac_draw assignment overwrites the error
code that should be returned by PTR_ERR().

Anyway, thank you for sorting this out!

Regards,
Paul


Thank you!


}

update_status();
@@ -416,7 +414,6 @@ ac_supply_failed:
regulator_put(ac_draw);
ac_draw = NULL;
}
-ac_draw_failed:
if (pdata->exit)
pdata->exit(dev);
  init_failed:
--
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/

Re: [PATCH 00/11] x86: Supervisor Mode Access Prevention

[Eric W. Biederman]

"H. Peter Anvin"  writes:

> On 09/21/2012 03:07 PM, Eric W. Biederman wrote:
>> 
>> Have you tested kexec in this environment?
>> 
>> This is the kind of cpu feature that when we enable it, frequently we
>> have to do something on the kexec path.
>> 
>> At a quick skim it looks like the kexec path is using kernel page table
>> entries and clearing all bits from cr4 except X86_CR4_PAE so I don't
>> actually expect this change will require anything on the kexec path.
>> 
>
> I have not, no, but as you quite correctly point out that shouldn't
> affect things.
>
> We should also change the kernel to start clean with CR4 -- the purpose
> of CR4 is to indicate which CPU features the OS is opting into.
>
> I think we do on x86-64 but not on x86-32 at the moment.
>
> This is an unrelated problem, though, and can be addressed later.

Agreed.  I just was just curious where things stood.

Eric

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

[PATCH v4] trace,x86: add x86 irq vector tracepoints

[Seiji Aguchi]

Change log 
 v3 -> v4
 - Add a latency measurement of each tracepoint
 - Rebased to 3.6-rc6

 v2 -> v3
 - Remove an invalidate_tlb_vector event because it was replaced by a call 
function vector
   in a following commit.
   
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=52aec3308db85f4e9f5c8b9f5dc4fbd0138c6fa4

 v1 -> v2
 - Modify variable name from irq to vector.
 - Merge arch-specific tracepoints below to an arch_irq_vector_entry/exit.
   - error_apic_vector
   - thermal_apic_vector
   - threshold_apic_vector
   - spurious_apic_vector
   - x86_platform_ipi_vector

As Vaibhav explained in the thread below, tracepoints for irq vectors
are useful.

http://www.spinics.net/lists/mm-commits/msg85707.html


The current interrupt traces from irq_handler_entry and irq_handler_exit
provide when an interrupt is handled.  They provide good data about when
the system has switched to kernel space and how it affects the currently
running processes.

There are some IRQ vectors which trigger the system into kernel space,
which are not handled in generic IRQ handlers.  Tracing such events gives
us the information about IRQ interaction with other system events.

The trace also tells where the system is spending its time.  We want to
know which cores are handling interrupts and how they are affecting other
processes in the system.  Also, the trace provides information about when
the cores are idle and which interrupts are changing that state.


On the other hand, my usecase is tracing just local timer event and 
getting a value of instruction pointer.

  I suggested to add an argument local timer event to get instruction pointer 
before.
  But there is another way to get it with external module like systemtap.
  So, I don't need to add any argument to irq vector tracepoints now.

Vaibhav's patch shared a trace point ,irq_vector_entry/irq_vector_exit, in all 
events.
But there is an above use case to trace specific irq_vector rather than tracing 
all events.
In this case, we are concerned about overhead due to unwanted events.

This patch modifies Vaibhav's one as follows.
 - Separate generic, and across-architecture tracepoints to enable 
independently.
   - nmi_vector
   - local_timer_vector
   - reschedule_vector
   - call_function_vector
   - call_function_single_vector 
   - irq_work_entry_vector

 - Rename architecture-specific tracepoints from irq_vector_entry/exit to 
   arch_irq_vector_entry/exit.
   - error_apic_vector
   - thermal_apic_vector
   - threshold_apic_vector
   - spurious_apic_vector
   - x86_platform_ipi_vector

   Those x86 specific ones are not really frequently raised vectors, so
   enabling them all won't affect performance and readability of the
   traces too much.

 Latencies of each event are measured by enabling a latency tracer of ftrace 
because some of tracepoints are 
 in performace critical pathes. 
 In my machine, all tracepoints are an usec order in case where they are 
enabled.

 CPU: Xeon X3430  @ 2.40GHz
 kernel: 3.6-rc6
 arch: x86_64

(1) local timer

(1-1) local_timer_entry

 - 3.6-rc6 original
<...>-27882dNh. 894834337us : exit_idle <-smp_apic_timer_interrupt
<...>-27882dNh. 894834337us : hrtimer_interrupt 
<-smp_apic_timer_interrupt

 - 3.6-rc6 + this patch + trace off
<...>-19810d.h. 210538us : exit_idle <-smp_apic_timer_interrupt
<...>-19810d.h. 210538us : hrtimer_interrupt 
<-smp_apic_timer_interrupt

 - 3.6-rc6 + this patch + trace on
cat-31580d.h. 169673us : exit_idle <-smp_apic_timer_interrupt
*cat-31580d.h. 169674us : local_timer_entry: vector=239*
cat-31580d.h. 169674us : hrtimer_interrupt 
<-smp_apic_timer_interrupt

(1-2) local_timer_exit

 - 3.6-rc6 original
<...>-27882dNh. 894834361us : lapic_next_event 
<-clockevents_program_event
<...>-27882dNh. 894834361us : irq_exit <-smp_apic_timer_interrupt

 - 3.6-rc6 + this patch + trace off
<...>-19810d.h. 210550us : lapic_next_event 
<-clockevents_program_event
<...>-19810d.h. 210550us : irq_exit <-smp_apic_timer_interrupt

 - 3.6-rc6 + this patch + trace on
cat-31580d.h. 169695us : lapic_next_event 
<-clockevents_program_event
*cat-31580d.h. 169695us : local_timer_exit: vector=239*
cat-31580d.h. 169695us : irq_exit <-smp_apic_timer_interrupt

(2) reschedule
(2-1) reschedule_entry

 - 3.6-rc6 original
-0   2d... 897118426us : smp_reschedule_interrupt 
<-reschedule_interrupt
-0   2d... 897118426us : scheduler_ipi 
<-smp_reschedule_interrupt

 - 3.6-rc6 + this patch + trace off
-0   0d... 212565us : smp_reschedule_interrupt 
<-reschedule_interrupt
-0   0d... 212565us : scheduler_ipi <-smp_reschedule_interrupt

 - 3.6-rc6 + this patch + trace on
-0   0d... 181656us : smp_reschedule_interrupt 
<-reschedule_interrupt
*-0   0d... 181656us : reschedule_entry: vector=253*

Re: [RFC] mm: add support for zsmalloc and zcache

[Mel Gorman]

On Fri, Sep 21, 2012 at 12:14:39PM -0700, Dan Magenheimer wrote:
> Hi Mel --
> 
> Wow!  An incredibly wonderfully detailed response!  Thank you very
> much for taking the time to read through all of zcache!
> 

My pleasure.

> Your comments run the gamut from nit and code style, to design,
> architecture and broad naming.  Until the choice-of-codebase issue
> is resolved, I'll avoid the nits and codestyle comments and respond
> to the higher level strategic and design questions. 

That's fair enough. FWIW, I would never consider the nits to be
blockers. If all the complaints I had were nits then there would be no
real issue to merging it to the core.

> Since a couple
> of your questions are repeated and the specific code which provoked
> your question is not isolated, I hope it is OK if I answer those
> first out-of-context from your original comments in the code.
> (This should also make this easier to read and to extract optimal
> meaning, for you and for posterity.)

Sure. I recognise that I was repeating myself at parts.

> > That said, I worry that this has bounced around a lot and as Dan (the
> > original author) has a rewrite. I'm wary of spending too much time on this
> > at all. Is Dan's new code going to replace this or what? It'd be nice to
> > find a definitive answer on that.
> 
> Replacing this code was my intent, but that was blocked.  IMHO zcache2
> is _much_ better than the "demo version" of zcache (aka zcache1).
> Hopefully a middle ground can be reached.  I've proposed one privately
> offlist.
> 

Ok. Unfortunately I cannot help resolve that issue but I'll mention it
again later.

> Seth, please feel free to augment or correct anything below, or
> respond to anything I haven't commented on.
> 
> > Anyway, here goes
> 
> Repeated comments answered first out-of-context:
> 
> 1) The interrupt context for zcache (and any tmem backend) is imposed
>by the frontend callers.  Cleancache_put [see naming comment below]
>is always called with interrupts disabled. 

Ok, I sortof see. It's always called within the irq-safe mapping tree_lock
and that infects the lower layers in a sense. It still feels like a layering
violation and minimally I would expect this is propagated down by making
locks like the hb->lock IRQ-safe and document the locking accordingly.

> Cleancache_flush is
>sometimes called with interrupts disabled and sometimes not.
>Cleancache_get is never called in an atomic context.  (I think)
>frontswap_get/put/flush are never called in an atomic context but
>sometimes with the swap_lock held. Because it is dangerous (true?)
>for code to sometimes/not be called in atomic context, much of the
>code in zcache and tmem is forced into atomic context. 

FWIW, if it can be called from a context with IRQs disabled then it must
be consistent throughout or it's unsafe. At the very least lockdep will
throw a fit if it is inconsistent.

> BUT Andrea
>observed that there are situations where asynchronicity would be
>preferable and, it turns out that cleancache_get and frontswap_get
>are never called in atomic context.  Zcache2/ramster takes advantage of
>that, and a future KVM backend may want to do so as well.  However,
>the interrupt/atomicity model and assumptions certainly does deserve
>better documentation.
> 

Minimally, move the locking to use the irq-safe with spin_lock_irqsave
rather than the current arrangement of calling local_irq_save() in
places. That alone would make it a bit easier to follow.

> 2) The naming of the core tmem functions (put, get, flush) has been
>discussed endlessly, everyone has a different opinion, and the
>current state is a mess: cleancache, frontswap, and the various
>backends are horribly inconsistent.   IMHO, the use of "put"
>and "get" for reference counting is a historical accident, and
>the tmem ABI names were chosen well before I understood the historical
>precedence and the potential for confusion by kernel developers.
>So I don't have a good answer... I'd prefer the ABI-documented
>names, but if they are unacceptable, at least we need to agree
>on a consistent set of names and fix all references in all
>the various tmem parts (and possibly Xen and the kernel<->Xen
>ABI as well).
> 

Ok, I see. Well, it's unfortunate but I'm not going to throw the toys out
of the pram over it either. Changing the names at this stage might just
confuse the people who are already familiar with the code. I'm the newbie
here so the confusion about terminology is my problem.

> The rest of my comments/replies are in context.
> 
> > > +/*
> > > + * A tmem host implementation must use this function to register
> > > + * callbacks for a page-accessible memory (PAM) implementation
> > > + */
> > > +static struct tmem_pamops tmem_pamops;
> > > +
> > > +void tmem_register_pamops(struct tmem_pamops *m)
> > > +{
> > > + tmem_pamops = *m;
> > > +}
> > > +
> > 
> > This implies that this 

[tip:x86/fpu] x86, kvm: fix kvm's usage of kernel_fpu_begin/end()

[tip-bot for Suresh Siddha]

Commit-ID:  b1a74bf8212367be2b1d6685c11a84e056eaaaf1
Gitweb: http://git.kernel.org/tip/b1a74bf8212367be2b1d6685c11a84e056eaaaf1
Author: Suresh Siddha 
AuthorDate: Thu, 20 Sep 2012 11:01:49 -0700
Committer:  H. Peter Anvin 
CommitDate: Fri, 21 Sep 2012 16:59:04 -0700

x86, kvm: fix kvm's usage of kernel_fpu_begin/end()

Preemption is disabled between kernel_fpu_begin/end() and as such
it is not a good idea to use these routines in kvm_load/put_guest_fpu()
which can be very far apart.

kvm_load/put_guest_fpu() routines are already called with
preemption disabled and KVM already uses the preempt notifier to save
the guest fpu state using kvm_put_guest_fpu().

So introduce __kernel_fpu_begin/end() routines which don't touch
preemption and use them instead of kernel_fpu_begin/end()
for KVM's use model of saving/restoring guest FPU state.

Also with this change (and with eagerFPU model), fix the host cr0.TS vm-exit
state in the case of VMX. For eagerFPU case, host cr0.TS is always clear.
So no need to worry about it. For the traditional lazyFPU restore case,
change the cr0.TS bit for the host state during vm-exit to be always clear
and cr0.TS bit is set in the __vmx_load_host_state() when the FPU
(guest FPU or the host task's FPU) state is not active. This ensures
that the host/guest FPU state is properly saved, restored
during context-switch and with interrupts (using irq_fpu_usable()) not
stomping on the active FPU state.

Signed-off-by: Suresh Siddha 
Link: 
http://lkml.kernel.org/r/1348164109.26695.338.ca...@sbsiddha-desk.sc.intel.com
Cc: Avi Kivity 
Signed-off-by: H. Peter Anvin 
---
 arch/x86/include/asm/i387.h |   28 ++--
 arch/x86/kernel/i387.c  |   13 +
 arch/x86/kvm/vmx.c  |   10 +++---
 arch/x86/kvm/x86.c  |4 ++--
 4 files changed, 40 insertions(+), 15 deletions(-)

diff --git a/arch/x86/include/asm/i387.h b/arch/x86/include/asm/i387.h
index 6c3bd37..ed8089d 100644
--- a/arch/x86/include/asm/i387.h
+++ b/arch/x86/include/asm/i387.h
@@ -24,8 +24,32 @@ extern int dump_fpu(struct pt_regs *, struct 
user_i387_struct *);
 extern void math_state_restore(void);
 
 extern bool irq_fpu_usable(void);
-extern void kernel_fpu_begin(void);
-extern void kernel_fpu_end(void);
+
+/*
+ * Careful: __kernel_fpu_begin/end() must be called with preempt disabled
+ * and they don't touch the preempt state on their own.
+ * If you enable preemption after __kernel_fpu_begin(), preempt notifier
+ * should call the __kernel_fpu_end() to prevent the kernel/user FPU
+ * state from getting corrupted. KVM for example uses this model.
+ *
+ * All other cases use kernel_fpu_begin/end() which disable preemption
+ * during kernel FPU usage.
+ */
+extern void __kernel_fpu_begin(void);
+extern void __kernel_fpu_end(void);
+
+static inline void kernel_fpu_begin(void)
+{
+   WARN_ON_ONCE(!irq_fpu_usable());
+   preempt_disable();
+   __kernel_fpu_begin();
+}
+
+static inline void kernel_fpu_end(void)
+{
+   __kernel_fpu_end();
+   preempt_enable();
+}
 
 /*
  * Some instructions like VIA's padlock instructions generate a spurious
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index 6782e39..675a050 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -73,32 +73,29 @@ bool irq_fpu_usable(void)
 }
 EXPORT_SYMBOL(irq_fpu_usable);
 
-void kernel_fpu_begin(void)
+void __kernel_fpu_begin(void)
 {
struct task_struct *me = current;
 
-   WARN_ON_ONCE(!irq_fpu_usable());
-   preempt_disable();
if (__thread_has_fpu(me)) {
__save_init_fpu(me);
__thread_clear_has_fpu(me);
-   /* We do 'stts()' in kernel_fpu_end() */
+   /* We do 'stts()' in __kernel_fpu_end() */
} else if (!use_eager_fpu()) {
this_cpu_write(fpu_owner_task, NULL);
clts();
}
 }
-EXPORT_SYMBOL(kernel_fpu_begin);
+EXPORT_SYMBOL(__kernel_fpu_begin);
 
-void kernel_fpu_end(void)
+void __kernel_fpu_end(void)
 {
if (use_eager_fpu())
math_state_restore();
else
stts();
-   preempt_enable();
 }
-EXPORT_SYMBOL(kernel_fpu_end);
+EXPORT_SYMBOL(__kernel_fpu_end);
 
 void unlazy_fpu(struct task_struct *tsk)
 {
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c00f03d..70dfcec 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1493,8 +1493,12 @@ static void __vmx_load_host_state(struct vcpu_vmx *vmx)
 #ifdef CONFIG_X86_64
wrmsrl(MSR_KERNEL_GS_BASE, vmx->msr_host_kernel_gs_base);
 #endif
-   if (user_has_fpu())
-   clts();
+   /*
+* If the FPU is not active (through the host task or
+* the guest vcpu), then restore the cr0.TS bit.
+*/
+   if (!user_has_fpu() && !vmx->vcpu.guest_fpu_loaded)
+   stts();
load_gdt(&__get_cpu_var(host_gdt));
 }
 
@@ -3730,7 +3734,7 @@ static void vmx_set_constant_host_state(void)
 

Re: rcu self-detected stall messages on OMAP3, 4 boards

[Paul E. McKenney]

On Fri, Sep 21, 2012 at 10:41:14PM +, Paul Walmsley wrote:
> On Fri, 21 Sep 2012, Paul E. McKenney wrote:
> 
> > On Fri, Sep 21, 2012 at 05:47:31PM +, Paul Walmsley wrote:
> >
> > > I built an OMAP kernel from Linus' commit 
> > > 4651afbbae968772efd6dc4ba461cba9b49bb9d8 ("Merge branch 'for-3.6-fixes' 
> > > of 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq").  The config used 
> > > was 'omap2plus_defconfig', and enabled CONFIG_CPU_IDLE by hand.  Booted 
> > > it 
> > > on a Pandaboard (OMAP4430ES2) into a very minimal Debian rootfs.
> > 
> > Did you have the patch at https://lkml.org/lkml/2012/8/30/290 applied?
> 
> No, it's just as described above.
> 
> > If not, could you please try it?  (This patch cleared up a similar
> > problem for Becky, also on OMAP.)
> 
> Did not seem to help, either with or without CONFIG_CPU_IDLE.

I was hoping!  ;-)

And my init=/bin/sh kernel ran idle for more than an hour without
any RCU CPU stall warnings...

I am wondering if your system somehow figured out how to start a grace
period that had no RCU callbacks waiting for it.  If that happened,
then a CONFIG_NO_HZ=y system could in theory get into a state where all
CPUs are in dyntick-idle mode, so that none of them is doing anything
to force the grace period to complete.

That should be easy to diagnose, anyway.  Please see below, which
includes the earlier diagnostic patch.

Thanx, Paul



diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index 307caf1..696f189 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -879,6 +879,7 @@ static void print_other_cpu_stall(struct rcu_state *rsp)
unsigned long flags;
int ndetected = 0;
struct rcu_node *rnp = rcu_get_root(rsp);
+   long totqlen = 0;
 
/* Only let one CPU complain about others per time interval. */
 
@@ -923,8 +924,11 @@ static void print_other_cpu_stall(struct rcu_state *rsp)
raw_spin_unlock_irqrestore(>lock, flags);
 
print_cpu_stall_info_end();
-   printk(KERN_CONT "(detected by %d, t=%ld jiffies)\n",
-  smp_processor_id(), (long)(jiffies - rsp->gp_start));
+   for_each_possible_cpu(cpu)
+   totqlen += per_cpu_ptr(rsp->rda, cpu)->qlen;
+   pr_cont("(detected by %d, t=%ld jiffies, g=%lu, c=%lu, q=%lu)\n",
+  smp_processor_id(), (long)(jiffies - rsp->gp_start),
+  rsp->gpnum, rsp->completed, totqlen);
if (ndetected == 0)
printk(KERN_ERR "INFO: Stall ended before state dump start\n");
else if (!trigger_all_cpu_backtrace())
@@ -939,8 +943,10 @@ static void print_other_cpu_stall(struct rcu_state *rsp)
 
 static void print_cpu_stall(struct rcu_state *rsp)
 {
+   int cpu;
unsigned long flags;
struct rcu_node *rnp = rcu_get_root(rsp);
+   long totqlen = 0;
 
/*
 * OK, time to rat on ourselves...
@@ -951,7 +957,10 @@ static void print_cpu_stall(struct rcu_state *rsp)
print_cpu_stall_info_begin();
print_cpu_stall_info(rsp, smp_processor_id());
print_cpu_stall_info_end();
-   printk(KERN_CONT " (t=%lu jiffies)\n", jiffies - rsp->gp_start);
+   for_each_possible_cpu(cpu)
+   totqlen += per_cpu_ptr(rsp->rda, cpu)->qlen;
+   pr_cont(" (t=%lu jiffies g=%lu c=%lu q=%lu)\n",
+   jiffies - rsp->gp_start, rsp->gpnum, rsp->completed, totqlen);
if (!trigger_all_cpu_backtrace())
dump_stack();
 

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

[PATCH v2] serial: set correct baud_base for EXSYS EX-41092 Dual 16950

[Flavio Leitner]

Apparently the same card model has two IDs, so this patch
complements the commit 39aced68d664291db3324d0fcf0985ab5626aac2
adding the missing one.

Signed-off-by: Flavio Leitner 
---
 drivers/tty/serial/8250/8250_pci.c | 9 +++--
 include/linux/pci_ids.h| 1 -
 2 files changed, 7 insertions(+), 3 deletions(-)

Changelog:
V2
moved IDs from pci_ids.h to 8250_pci.c
requested by greg k-h

diff --git a/drivers/tty/serial/8250/8250_pci.c 
b/drivers/tty/serial/8250/8250_pci.c
index 28e7c7c..6b8fcb4 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1164,6 +1164,8 @@ pci_xr17c154_setup(struct serial_private *priv,
 #define PCI_SUBDEVICE_ID_OCTPRO422 0x0208
 #define PCI_SUBDEVICE_ID_POCTAL232 0x0308
 #define PCI_SUBDEVICE_ID_POCTAL422 0x0408
+#define PCI_SUBDEVICE_ID_SIIG_DUAL_00  0x2500
+#define PCI_SUBDEVICE_ID_SIIG_DUAL_30  0x2530
 #define PCI_VENDOR_ID_ADVANTECH0x13fe
 #define PCI_DEVICE_ID_INTEL_CE4100_UART 0x2e66
 #define PCI_DEVICE_ID_ADVANTECH_PCI36200x3620
@@ -3232,8 +3234,11 @@ static struct pci_device_id serial_pci_tbl[] = {
 * For now just used the hex ID 0x950a.
 */
{   PCI_VENDOR_ID_OXSEMI, 0x950a,
-   PCI_SUBVENDOR_ID_SIIG, PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL, 0, 0,
-   pbn_b0_2_115200 },
+   PCI_SUBVENDOR_ID_SIIG, PCI_SUBDEVICE_ID_SIIG_DUAL_00,
+   0, 0, pbn_b0_2_115200 },
+   {   PCI_VENDOR_ID_OXSEMI, 0x950a,
+   PCI_SUBVENDOR_ID_SIIG, PCI_SUBDEVICE_ID_SIIG_DUAL_30,
+   0, 0, pbn_b0_2_115200 },
{   PCI_VENDOR_ID_OXSEMI, 0x950a,
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
pbn_b0_2_113 },
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 6b4565c..8d3c427 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1847,7 +1847,6 @@
 #define PCI_DEVICE_ID_SIIG_8S_20x_650  0x2081
 #define PCI_DEVICE_ID_SIIG_8S_20x_850  0x2082
 #define PCI_SUBDEVICE_ID_SIIG_QUARTET_SERIAL   0x2050
-#define PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL  0x2530
 
 #define PCI_VENDOR_ID_RADISYS  0x1331
 
-- 
1.7.11.4

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

Re: [PATCH] pda_power: remove ac_draw_failed goto and label

[Anton Vorontsov]

On Fri, Sep 21, 2012 at 01:56:43AM +0100, Paul Parsons wrote:
> A previous patch added the ac_draw_failed goto and label to
> pda_power_probe(). The goto would be invoked after a failed call to
> regulator_get().
> 
> However the way ac_draw is used - always after a check for NULL -
> suggests that a failed call to regulator_get() was not fatal.
> 
> This patch removes the ac_draw_failed goto and label, partly reverting
> the previous patch.
> 
> This patch also removes the assignment of an error code to ret after a
> failed call to regulator_get(), since the error code is now never used.
> 
> Signed-off-by: Paul Parsons 
> Cc: Philipp Zabel 
> ---
>  drivers/power/pda_power.c |3 ---
>  1 files changed, 0 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/power/pda_power.c b/drivers/power/pda_power.c
> index d3be834d..7df7c5f 100644
> --- a/drivers/power/pda_power.c
> +++ b/drivers/power/pda_power.c
> @@ -284,9 +284,7 @@ static int pda_power_probe(struct platform_device *pdev)
>   ac_draw = regulator_get(dev, "ac_draw");
>   if (IS_ERR(ac_draw)) {
>   dev_dbg(dev, "couldn't get ac_draw regulator\n");
> - ret = PTR_ERR(ac_draw);
>   ac_draw = NULL;
> - goto ac_draw_failed;

For some reason you have a bit different code, so your patch is not based
on the battery tree. (In my tree ret and ac_draw assignments are swapped.)
Maybe that's because I had to manually redo your first patch...

Anyway, I repeated your patch by hand again and thus applied it.

Thank you!

>   }
> 
>   update_status();
> @@ -416,7 +414,6 @@ ac_supply_failed:
>   regulator_put(ac_draw);
>   ac_draw = NULL;
>   }
> -ac_draw_failed:
>   if (pdata->exit)
>   pdata->exit(dev);
>  init_failed:
> -- 
> 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/

Re: [RFC v3 1/2] PCI-Express Non-Transparent Bridge Support

[Jon Mason]

On Fri, Sep 21, 2012 at 02:14:47PM -0400, David Miller wrote:
> From: Jon Mason 
> Date: Fri, 21 Sep 2012 11:09:48 -0700
> 
> > A PCI-Express non-transparent bridge (NTB) is a point-to-point PCIe bus
> > connecting 2 systems, providing electrical isolation between the two 
> > subsystems.
> > A non-transparent bridge is functionally similar to a transparent bridge 
> > except
> > that both sides of the bridge have their own independent address domains.  
> > The
> > host on one side of the bridge will not have the visibility of the complete
> > memory or I/O space on the other side of the bridge.  To communicate across 
> > the
> > non-transparent bridge, each NTB endpoint has one (or more) apertures 
> > exposed to
> > the local system.  Writes to these apertures are mirrored to memory on the
> > remote system.  Communications can also occur through the use of doorbell
> > registers that initiate interrupts to the alternate domain, and scratch-pad
> > registers accessible from both sides.
> > 
> > The NTB device driver is needed to configure these memory windows, 
> > doorbell, and
> > scratch-pad registers as well as use them in such a way as they can be 
> > turned
> > into a viable communication channel to the remote system.  ntb_hw.[ch]
> > determines the usage model (NTB to NTB or NTB to Root Port) and abstracts 
> > away
> > the underlying hardware to provide access and a common interface to the 
> > doorbell
> > registers, scratch pads, and memory windows.  These hardware interfaces are
> > exported so that other, non-mainlined kernel drivers can access these.
> > ntb_transport.[ch] also uses the exported interfaces in ntb_hw.[ch] to 
> > setup a
> > communication channel(s) and provide a reliable way of transferring data 
> > from
> > one side to the other, which it then exports so that "client" drivers can 
> > access
> > them.  These client drivers are used to provide a standard kernel interface
> > (i.e., Ethernet device) to NTB, such that Linux can transfer data from one
> > system to the other in a standard way.
> > 
> > Signed-off-by: Jon Mason 
> 
> I really don't see anything that requires the TX networking processing
> to occur in a tasklet.  I see no sleeping, strange locking, or
> anything like that.
> 
> And if that's the case, it's just pure overhead.

Good point.  Removed (and I see a nice little perf bump).

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

Re: [PATCH v2] charger-manager: Add support sysfs entry for charger

[Anton Vorontsov]

On Fri, Sep 21, 2012 at 06:49:37PM +0900, Chanwoo Choi wrote:
> This patch add support sysfs entry for each charger(regulator).
> Charger-manager use one or more chargers for charging battery but
> some charger isn't necessary on specific scenario. So, if some charger
> isn't needed, can disable specific charger through 'externally_control'
> entry while system is on state and confirm the information(name, state)
> of charger.
[...]
> the list of added sysfs entry
> - /sys/class/power_supply/battery/chargers/charger.[index]/name
> : show name of charger(regulator)
> - /sys/class/power_supply/battery/chargers/charger.[index]/state
> : show either enabled or disabled state of charger
> - /sys/class/power_supply/battery/chargers/charger.[index]/externally_control
> 
> If 'externally_control' of specific charger is 1, Charger-manager cannot 
> enable
> regulator for charging when charger cable is attached and charger must be
> maintained with disabled state. If 'externally_control' is zero, 
> Charger-manager
> usually can control to enable/disable regulator.
> 
> Signed-off-by: Chanwoo Choi 
> Signed-off-by: Myungjoo Ham 
> Signed-off-by: Kyungmin Park 
> ---

Thanks for your work, folks!

There are some serious issues wrt. the coding standards, though.

(I must confess that because of the issues I didn't look much into the
logic itself, I hope it works.)

>  drivers/power/charger-manager.c   |  174 
> -
>  include/linux/power/charger-manager.h |   19 
>  2 files changed, 192 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
> index e92ec55..a1ab825 100644
> --- a/drivers/power/charger-manager.c
> +++ b/drivers/power/charger-manager.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  static const char * const default_event_names[] = {
>   [CM_EVENT_UNKNOWN] = "Unknown",
> @@ -332,6 +333,9 @@ static int try_charger_enable(struct charger_manager *cm, 
> bool enable)
>   cm->charging_end_time = 0;
>  
>   for (i = 0 ; i < desc->num_charger_regulators ; i++) {
> + if (desc->charger_regulators[i].externally_control)
> + continue;
> +
>   err = 
> regulator_enable(desc->charger_regulators[i].consumer);
>   if (err < 0) {
>   dev_warn(cm->dev,
> @@ -348,6 +352,9 @@ static int try_charger_enable(struct charger_manager *cm, 
> bool enable)
>   cm->charging_end_time = ktime_to_ms(ktime_get());
>  
>   for (i = 0 ; i < desc->num_charger_regulators ; i++) {
> + if (desc->charger_regulators[i].externally_control)
> + continue;
> +
>   err = 
> regulator_disable(desc->charger_regulators[i].consumer);
>   if (err < 0) {
>   dev_warn(cm->dev,
> @@ -1217,12 +1224,101 @@ static int charger_extcon_init(struct 
> charger_manager *cm,
>   return ret;
>  }
>  
> +/* help function of sysfs node to control charger(regulator) */
> +static ssize_t charger_name_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct charger_regulator *charger
> + = container_of(attr, struct charger_regulator, attr_name);

Here must be an empty line.

> + return sprintf(buf, "%s\n", charger->regulator_name);
> +}
> +
> +static ssize_t charger_state_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct charger_regulator *charger
> + = container_of(attr, struct charger_regulator, attr_state);
> + int state = 1;

= 1 is not needed. Instead, you could rewrite it as

int state = 0;

if (!charger->externally_control)
state = regulator_is_enabled(charger->consumer);

> + if (charger->externally_control)
> + state = 0;
> + else
> + state = regulator_is_enabled(charger->consumer);
> +
> + return sprintf(buf, "%s\n", state ? "enabled" : "disabled");
> +}
> +
> +static ssize_t charger_externally_control_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct charger_regulator *charger = container_of(attr,
> + struct charger_regulator, attr_externally_control);

Empty line is required.

> + return sprintf(buf, "%d\n", charger->externally_control);
> +}
> +
> +static ssize_t charger_externally_control_store(struct device *dev,
> + struct device_attribute *attr, const char *buf,
> + size_t count)
> +{
> + struct charger_regulator *charger
> + = container_of(attr, struct charger_regulator,
> + attr_externally_control);
> + struct charger_manager *cm = 

Re: [PATCH 5/4] mm: remove unevictable_pgs_mlockfreed

[Johannes Weiner]

On Fri, Sep 21, 2012 at 03:56:11PM -0700, Hugh Dickins wrote:
> Simply remove UNEVICTABLE_MLOCKFREED and unevictable_pgs_mlockfreed
> line from /proc/vmstat: Johannes and Mel point out that it was very
> unlikely to have been used by any tool, and of course we can restore
> it easily enough if that turns out to be wrong.
> 
> Signed-off-by: Hugh Dickins 
> Cc: Mel Gorman 
> Cc: Rik van Riel 
> Cc: Johannes Weiner 
> Cc: Michel Lespinasse 
> Cc: Ying Han 

Acked-by: Johannes Weiner 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: gpmc_cs_request() causes early boot hang

[Tony Lindgren]

* Mark Jackson  [120921 12:29]:
> I'm developing a beaglebone cape board which requires the use of a
> GPMC chip select.
> 
> I've chosen GPMC_CS0, and in board-am335xevm.c, I have added the following:-
> 
> static void gpmc_test()
> {
> unsigned long base = 0x12345678;
> gpmc_cs_request(0, SZ_16M, );
> printk(KERN_INFO "gpmc base @ 0x%08lx\n", base);
> }
> 
> ... and added a call to gpmc_test() at the end of am335x_evm_init().
> 
> If I try to run this code, the kernel fails to boot, and simply hangs at:-
> 
> Uncompressing Linux... done, booting the kernel.
> 
> If I comment out the call to gpmc_cs_request(), the system boots as
> expected (but without my required cs).
> 
> I've looked at the use of this call in other board files, and can't
> see that their code does anything special so I'm stuck on why this
> simple code fails to work.
> 
> Can anyone shed light on what I'm doing wrong ?
> 
> Do I have to initialise the gpmc beforehand in some way ?

Can you enable DEBUG_LL + EARLYPRINTK and have earlyprintk in your
cmdline? You may then get some error messages providing more info.

GPMC is working on many boards with various devices like smsc911x,
onenand, tusb etc.

Regards,

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

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Francois Romieu]

Thanasis  :
> on 09/21/2012 11:29 PM Francois Romieu wrote the following:
[...]
> What message? What do you mean "the usual netdev watchdog message"?

No, this one (see your 3.5.4 kernel log):

[   23.712058] WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x121/0x1a3(
)
[   23.712062] Hardware name: AOA110
[   23.712067] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out

[...]
> > Could you perform a test with your vendor's 3.2-something kernel and its
> > r8169 driver ?
> > 
> The vendor's kernel was a 2.6 series.

You did experience a failure with a 3.5.4 kernel. Can you try a 3.2.x if
your vendor provides one ?

Thanks.

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

[PATCH 5/4] mm: remove unevictable_pgs_mlockfreed

[Hugh Dickins]

Simply remove UNEVICTABLE_MLOCKFREED and unevictable_pgs_mlockfreed
line from /proc/vmstat: Johannes and Mel point out that it was very
unlikely to have been used by any tool, and of course we can restore
it easily enough if that turns out to be wrong.

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

--- 3.6-rc6.orig/include/linux/vm_event_item.h  2012-09-18 20:04:42.0 
-0700
+++ 3.6-rc6/include/linux/vm_event_item.h   2012-09-21 15:13:26.608016171 
-0700
@@ -52,7 +52,6 @@ enum vm_event_item { PGPGIN, PGPGOUT, PS
UNEVICTABLE_PGMUNLOCKED,
UNEVICTABLE_PGCLEARED,  /* on COW, page truncate */
UNEVICTABLE_PGSTRANDED, /* unable to isolate on unlock */
-   UNEVICTABLE_MLOCKFREED, /* no longer useful: always zero */
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
THP_FAULT_ALLOC,
THP_FAULT_FALLBACK,
--- 3.6-rc6.orig/mm/vmstat.c2012-09-18 20:04:42.0 -0700
+++ 3.6-rc6/mm/vmstat.c 2012-09-21 15:13:43.724017386 -0700
@@ -781,7 +781,6 @@ const char * const vmstat_text[] = {
"unevictable_pgs_munlocked",
"unevictable_pgs_cleared",
"unevictable_pgs_stranded",
-   "unevictable_pgs_mlockfreed",   /* no longer useful: always zero */
 
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
"thp_fault_alloc",
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: zcache: fix spelling of comment

[Greg KH]

On Fri, Sep 21, 2012 at 11:45:51AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 05, 2012 at 12:05:55PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Sat, Sep 01, 2012 at 10:29:46PM +0200, Marcus Karlsson wrote:
> > > Fix spelling in tmem.c:
> > > Transcedent -> Transcendent
> > > 
> > > Signed-off-by: Marcus Karlsson 
> > 
> > Acked-by: Konrad Rzeszutek Wilk 
> 
> Greg, can you pick this up for 3.7 pls? Or should I prep a git branch
> to send to you (I've a patch for the TODO file as well).

No need for a git branch, just send me the patches in email, as that's
the format I need them in.

Please resend this one, as I don't want to dig it out of this thread by
hand :(

thanks,

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

Re: [RFC] Second attempt at kernel secure boot support

[Eric W. Biederman]

Matthew Garrett  writes:

> This is pretty much identical to the first patchset, but with the capability
> renamed (CAP_COMPROMISE_KERNEL) and the kexec patch dropped. If anyone wants
> to deploy these then they should disable kexec until support for signed
> kexec payloads has been merged.

A couple of thoughts.

1) I don't see anything disabling kdb or kgdb.  If ever there
   was a way to poke into the kernel and change things...

2) You almost certainly want to disable module removal.  It is all to
   easy to have races where that are not properly handled in the module
   removal path.  I know I saw a bundle of those in debugfs the other
   day.

3) And half seriously you probably want to disable mounting of
   filesystems.  I believe I have heard it said the kernel has not been
   vetted against a hostile root user mounting deliberately corrupted
   filesystem images.

As it is designed I don't believe your patchset can successfully achieve
the goal of keeping a determined root user from injecting code into the
kernel without disabling so many kernel features the kernel is
uninteresting for most people to run.

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

Re: [PATCH] [V3]power: battery: Generic battery driver using IIO

[Anton Vorontsov]

On Fri, Sep 21, 2012 at 09:40:14PM +0530, anish kumar wrote:
> From: anish kumar 
> 
> In last version:
> Addressed concerns raised by lars:
> a. made the adc_bat per device.
> b. get the IIO channel using hardcoded channel names.
> c. Minor issues related to gpio_is_valid and some code
>refactoring.

In the commit message itself it usually good idea to write a short
description for the patch: the rationale behind the driver. Just a few
sentences will work.

And changelog usually goes below the "---" separator, as we don't want it
in the commit log ("git am" command ignores anything below "---").

> In V1:
> Addressed concerns raised by Anton:
> a. changed the struct name to gab(generic adc battery).
> b. Added some functions to neaten the code.
> c. Some minor coding guidelines changes.
> d. Used the latest function introduce by lars:
>iio_read_channel_processed to streamline the code.
> 
> In V2:
> Addressed concerns by lars:
> a. No need of allocating memory for channels.Make it array.
> b. Code restructring, coding style and following kernel guidelines changes
>suggested by him.
> 
> In V3:
> Addressed conerns by Anton:
> a. Added the copyright.
> b. Coding guidelines changes suggested by him.
> c. Added Makefile and Kconfig
> 
> Signed-off-by: anish kumar 
> ---

OK, I belive it is good enough, and as it depends on IIO changes,
I believe now it's IIO maintainer's worry to pick it up. :-)

Acked-by: Anton Vorontsov 

Thanks a lot for your work!

>  drivers/power/Kconfig |7 +
>  drivers/power/Makefile|1 +
>  drivers/power/generic-adc-battery.c   |  422 
> +
>  include/linux/power/generic-adc-battery.h |   29 ++
>  4 files changed, 459 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/power/generic-adc-battery.c
>  create mode 100644 include/linux/power/generic-adc-battery.h
> 
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index fcc1bb0..30a173a 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -29,6 +29,13 @@ config APM_POWER
> Say Y here to enable support APM status emulation using
> battery class devices.
>  
> +config GENERIC_ADC_BATTERY
> + tristate "Generic battery support using IIO"
> + depends on IIO
> + help
> +   Say Y here to enable support for the generic battery driver
> +   which uses IIO framework to read adc.
> +
>  config MAX8925_POWER
>   tristate "MAX8925 battery charger support"
>   depends on MFD_MAX8925
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index ee58afb..e0b4d42 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -5,6 +5,7 @@ power_supply-$(CONFIG_SYSFS)  += power_supply_sysfs.o
>  power_supply-$(CONFIG_LEDS_TRIGGERS) += power_supply_leds.o
>  
>  obj-$(CONFIG_POWER_SUPPLY)   += power_supply.o
> +obj-$(CONFIG_GENERIC_ADC_BATTERY)+= generic-adc-battery.o
>  
>  obj-$(CONFIG_PDA_POWER)  += pda_power.o
>  obj-$(CONFIG_APM_POWER)  += apm_power.o
> diff --git a/drivers/power/generic-adc-battery.c 
> b/drivers/power/generic-adc-battery.c
> new file mode 100644
> index 000..a34d52a
> --- /dev/null
> +++ b/drivers/power/generic-adc-battery.c
> @@ -0,0 +1,422 @@
> +/*
> + * Generic battery driver code using IIO
> + * Copyright (C) 2012, Anish Kumar 
> + * based on jz4740-battery.c
> + * based on s3c_adc_battery.c
> + *
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License.  See the file COPYING in the main directory of this archive for
> + * more details.
> + *
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define JITTER_DEFAULT 10 /* hope 10ms is enough */
> +
> +enum gab_chan_type {
> + GAB_VOLTAGE = 0,
> + GAB_CURRENT,
> + GAB_POWER,
> + GAB_MAX_CHAN_TYPE
> +};
> +
> +/*
> + * gab_chan_name suggests the standard channel names for commonly used
> + * channel types.
> + */
> +static const char *const gab_chan_name[] = {
> + [GAB_VOLTAGE]   = "voltage",
> + [GAB_CURRENT]   = "current",
> + [GAB_POWER] = "power",
> +};
> +
> +struct gab {
> + struct power_supply psy;
> + struct iio_channel  *channel[GAB_MAX_CHAN_TYPE];
> + struct gab_platform_data*pdata;
> + struct delayed_work bat_work;
> + int level;
> + int status;
> + bool cable_plugged;
> +};
> +
> +struct gab *to_generic_bat(struct power_supply *psy)
> +{
> + return container_of(psy, struct gab, psy);
> +}
> +
> +static void gab_ext_power_changed(struct power_supply *psy)
> +{
> + struct gab *adc_bat = to_generic_bat(psy);
> +
> + schedule_delayed_work(_bat->bat_work, msecs_to_jiffies(0));
> +}
> +
> +static const enum power_supply_property gab_props[] = {
> + 

Re: [PATCH v3 17/17] ARM: mm: clean up membank size limit checks

[Cyril Chemparathy]

On 9/21/2012 2:42 PM, Nicolas Pitre wrote:

On Tue, 11 Sep 2012, Cyril Chemparathy wrote:


This patch cleans up the highmem sanity check code by simplifying the range
checks with a pre-calculated size_limit.  This patch should otherwise have no
functional impact on behavior.

This patch also removes a redundant (bank->start < vmalloc_limit) check, since
this is already covered by the !highmem condition.

Signed-off-by: Cyril Chemparathy 
Signed-off-by: Vitaly Andrianov 


Acked-by: Nicolas Pitre 



Thanks, Nico.

Could you please take another peek at patch 05/17 (support 64-bit 
virt_to_phys patching)?  You had reviewed it in an earlier posting, but 
I've had to tweak the code to optimize the compiler generated inline 
expansion code.


Patch 14/17 (accomodate >32-bit addresses for page table base) could use 
some attention as well.  The same goes with 12/17 (define 
ARCH_LOW_ADDRESS_LIMIT for bootmem), if you could.


--
Thanks
- Cyril
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 Patch 0/4] fs/inode.c: optimization for inode lock usage

[Dave Chinner]

On Fri, Sep 21, 2012 at 05:31:02PM +0800, Guo Chao wrote:
> This patchset optimizes several places which take the per inode spin lock.
> They have not been fully tested yet, thus they are marked as RFC. 

Inodes are RCU freed. The i_lock spinlock on the i_state field forms
part of the memory barrier that allows the RCU read side to
correctly detect a freed inode during a RCU protected cache lookup
(hash list traversal for the VFS, or a radix tree traversal for XFS).
The i_lock usage around the hahs list operations ensures the hash
list operations are atomic with state changes so that such changes
are correctly detected during RCU-protected traversals...

IOWs, removing the i_lock from around the i_state transitions and
inode hash insert/remove/traversal operations will cause races in
the RCU lookups and result in incorrectly using freed inodes instead
of failing the lookup and creating a new one.

So I don't think this is a good idea at all...

Cheers,

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

Re: rcu self-detected stall messages on OMAP3, 4 boards

[Paul Walmsley]

On Fri, 21 Sep 2012, Paul E. McKenney wrote:

> On Fri, Sep 21, 2012 at 05:47:31PM +, Paul Walmsley wrote:
>
> > I built an OMAP kernel from Linus' commit 
> > 4651afbbae968772efd6dc4ba461cba9b49bb9d8 ("Merge branch 'for-3.6-fixes' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq").  The config used 
> > was 'omap2plus_defconfig', and enabled CONFIG_CPU_IDLE by hand.  Booted it 
> > on a Pandaboard (OMAP4430ES2) into a very minimal Debian rootfs.
> 
> Did you have the patch at https://lkml.org/lkml/2012/8/30/290 applied?

No, it's just as described above.

> If not, could you please try it?  (This patch cleared up a similar
> problem for Becky, also on OMAP.)

Did not seem to help, either with or without CONFIG_CPU_IDLE.


- 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: [PATCH] Documentation: RCU: update the stall warning message "timer=-1" to match reality

[Paul Walmsley]

On Fri, 21 Sep 2012, Paul E. McKenney wrote:

> Good catch!  Even worse, it gives "timer=18446744073709551615" on
> 64-bit systems, which is no easier on the eyes.  I therefore changed
> the code to print a nicer message in this case, patch below.

Looks better, thanks.

- 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: [PATCH v3 01/17] ARM: add mechanism for late code patching

[Cyril Chemparathy]

On 9/21/2012 2:09 PM, Nicolas Pitre wrote:

On Tue, 11 Sep 2012, Cyril Chemparathy wrote:


The original phys_to_virt/virt_to_phys patching implementation relied on early
patching prior to MMU initialization.  On PAE systems running out of >4G
address space, this would have entailed an additional round of patching after
switching over to the high address space.

The approach implemented here conceptually extends the original PHYS_OFFSET
patching implementation with the introduction of "early" patch stubs.  Early
patch code is required to be functional out of the box, even before the patch
is applied.  This is implemented by inserting functional (but inefficient)
load code into the .runtime.patch.code init section.  Having functional code
out of the box then allows us to defer the init time patch application until
later in the init sequence.

In addition to fitting better with our need for physical address-space
switch-over, this implementation should be somewhat more extensible by virtue
of its more readable (and hackable) C implementation.  This should prove
useful for other similar init time specialization needs, especially in light
of our multi-platform kernel initiative.

This code has been boot tested in both ARM and Thumb-2 modes on an ARMv7
(Cortex-A8) device.

Note: the obtuse use of stringified symbols in patch_stub() and
early_patch_stub() is intentional.  Theoretically this should have been
accomplished with formal operands passed into the asm block, but this requires
the use of the 'c' modifier for instantiating the long (e.g. .long %c0).
However, the 'c' modifier has been found to ICE certain versions of GCC, and
therefore we resort to stringified symbols here.

Signed-off-by: Cyril Chemparathy 
Reviewed-by: Nicolas Pitre 


I know I provided review before, but here's another nit I'd like fixed:



Fixed for v4.  Thanks.


--- /dev/null
+++ b/arch/arm/include/asm/runtime-patch.h
@@ -0,0 +1,208 @@
+/*
+ * arch/arm/include/asm/runtime-patch.h
+ * Note: this file should not be included by non-asm/.h files
+ *
+ * Copyright 2012 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#ifndef __ASM_ARM_RUNTIME_PATCH_H
+#define __ASM_ARM_RUNTIME_PATCH_H
+
+#include 
+
+#ifndef __ASSEMBLY__
+
+#ifdef CONFIG_ARM_RUNTIME_PATCH


[...]


+#else
+
+static inline int runtime_patch(const void *table, unsigned size)
+{
+   return 0;
+}


This is wrong.  If runtime_patch() is ever called when
CONFIG_ARM_RUNTIME_PATCH is not set, then i'd better return an error and
not pretend it performed the requested action.  Returning -ENOSYS would
be appropriate.

This is especially important in the following context:


--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -321,6 +322,12 @@ int module_finalize(const Elf32_Ehdr *hdr, const Elf_Shdr 
*sechdrs,
if (s)
fixup_pv_table((void *)s->sh_addr, s->sh_size);
  #endif
+   s = find_mod_section(hdr, sechdrs, ".runtime.patch.table");
+   if (s) {
+   err = runtime_patch((void *)s->sh_addr, s->sh_size);
+   if (err)
+   return err;
+   }


Despite the vermagic check, If ever a .runtime.patch.table section is
found in a module to be loaded in a kernel with no support for it then
it is best to return an error than see the kernel crashing later on when
the fallback stubs have been discarded.


Nicolas



--
Thanks
- Cyril
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/17] ARM: add self test for runtime patch mechanism

[Cyril Chemparathy]

On 9/21/2012 1:40 PM, Nicolas Pitre wrote:

On Tue, 11 Sep 2012, Cyril Chemparathy wrote:


This patch adds basic sanity tests to ensure that the instruction patching
results in valid instruction encodings.  This is done by verifying the output
of the patch process against a vector of assembler generated instructions at
init time.

Signed-off-by: Cyril Chemparathy 
---
  arch/arm/Kconfig|   12 +++
  arch/arm/kernel/runtime-patch.c |   75 +++
  2 files changed, 87 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 36de4ea..bfcd29d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -207,6 +207,18 @@ config ARM_PATCH_PHYS_VIRT
  this feature (eg, building a kernel for a single machine) and
  you need to shrink the kernel to the minimal size.

+config ARM_RUNTIME_PATCH_TEST
+   bool "Self test runtime patching mechanism" if ARM_RUNTIME_PATCH
+   default y


Here you probably want this instead:

bool "Self test runtime patching mechanism"
default y
depends on ARM_RUNTIME_PATCH

Otherwise ARM_RUNTIME_PATCH_TEST will be forced to y whenever
ARM_RUNTIME_PATCH is unset.  That doesn't currently affect the build
since the containing .c file is only compiled when ARM_RUNTIME_PATCH is
set but that is still not strictly right.



Indeed.  Excellent.  Thanks.


[...]

@@ -189,5 +261,8 @@ void __init runtime_patch_kernel(void)
const void *start = &__runtime_patch_table_begin;
const void *end   = &__runtime_patch_table_end;

+#ifdef CONFIG_ARM_RUNTIME_PATCH_TEST
+   runtime_patch_test();
+#endif
BUG_ON(runtime_patch(start, end - start));


I think you shoulld have runtime_patch_test() return a possible error
code and use BUG_ON() with it as well.



Sure.  Will do in v4.


With those minor changes you can add...

Reviewed-by: Nicolas Pitre 



Thanks.

--
- Cyril
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 15/19] mfd: Don't convert just one IRQ using irqdomain if a range is provided

[Samuel Ortiz]

Hi Lee,

On Mon, Sep 17, 2012 at 03:11:07PM +0100, Lee Jones wrote:
> On Mon, Sep 17, 2012 at 03:45:50PM +0200, Samuel Ortiz wrote:
> > Hi Lee, Arnd,
> > 
> > On Fri, Sep 07, 2012 at 01:57:27PM +, Arnd Bergmann wrote:
> > > On Friday 07 September 2012, Lee Jones wrote:
> > > > On Fri, Sep 07, 2012 at 01:37:26PM +, Arnd Bergmann wrote:
> > > > > On Friday 07 September 2012, Lee Jones wrote:
> > > > > > On Fri, Sep 07, 2012 at 12:35:41PM +, Arnd Bergmann wrote:
> > > > >
> > > > > The examples I had seen before were all just ranges of two interrupts,
> > > > > and in those cases it was clear that splitting them would be best.
> > > > > 
> > > > > In the exampled of the ab8500-gpio driver, it looks like the resource 
> > > > > is
> > > > > not actually being used, and the gpio driver implements its own 
> > > > > irq_chip,
> > > > > so maybe we can get away with not solving this problem for now.
> > > > 
> > > > Understood. I'd still feel more comfortable if we didn't trash the
> > > > range. I think it would be best to show the warning, and leave the
> > > > range for its target driver to take care - hence the patch.
> > > > 
> > > > ... but it's your call.
> > > 
> > > I'm fine with whatever Samuel sees fit here.  My personal opinion is
> > > that leaving the range alone for the child driver to do the conversion
> > > would be too inconsistent and only lead to confusion with driver authors.
> > Although I agree modifying the range is not very nice from the MFD core, I
> > also think that the actual mapping should always be handled by MFD and not
> > depend on wether the range is a singleton or not. Moreover the semantics of
> > leaving the range untouched meaning that we haven't done the mappings is
> > obscure.
> > So I'm not taking this patch, sorry Lee.
> 
> No problem.
> 
> Would it be better if we _did_ support ranges, and map all of the
> IRQs in the range instead?
I think that would be a reasonable solution, unless Arnd or Mark see a serious
problem with that.

Cheers,
Samuel.

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

Re: rcu self-detected stall messages on OMAP3, 4 boards

[Paul E. McKenney]

On Fri, Sep 21, 2012 at 12:57:17PM -0700, Paul E. McKenney wrote:
> On Fri, Sep 21, 2012 at 07:11:14PM +, Paul Walmsley wrote:
> > On Fri, 21 Sep 2012, Paul E. McKenney wrote:

[ . . . ]

> > > I may take your advice of remote access to a Panda board, though that
> > > is likely to take a bit of time due to timezones.  Regardless of the
> > > underlying issue here, I clearly need to make the stall-warning messages
> > > do a better job of printing out needed information.
> > 
> > If you've got a patch in mind for that, I'll boot it here.
> 
> Hammering it out, will send it along when it is a bit less destructive.  ;-)

And I eventually decided to keep things simple, please see below.
This applies on top of https://lkml.org/lkml/2012/8/30/290.

Thanx, Paul



rcu: Add grace-period information to RCU CPU stall warnings

This commit causes the last grace period started and completed to be
printed on RCU CPU stall warning messages in order to aid diagnosis.

Signed-off-by: Paul E. McKenney 
Signed-off-by: Paul E. McKenney 

diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index cdaa7aa..fdb6854 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -925,8 +925,9 @@ static void print_other_cpu_stall(struct rcu_state *rsp)
raw_spin_unlock_irqrestore(>lock, flags);
 
print_cpu_stall_info_end();
-   printk(KERN_CONT "(detected by %d, t=%ld jiffies)\n",
-  smp_processor_id(), (long)(jiffies - rsp->gp_start));
+   pr_cont("(detected by %d, t=%ld jiffies, g=%lu, c=%lu)\n",
+  smp_processor_id(), (long)(jiffies - rsp->gp_start),
+  rsp->gpnum, rsp->completed);
if (ndetected == 0)
printk(KERN_ERR "INFO: Stall ended before state dump start\n");
else if (!trigger_all_cpu_backtrace())
@@ -953,7 +954,8 @@ static void print_cpu_stall(struct rcu_state *rsp)
print_cpu_stall_info_begin();
print_cpu_stall_info(rsp, smp_processor_id());
print_cpu_stall_info_end();
-   printk(KERN_CONT " (t=%lu jiffies)\n", jiffies - rsp->gp_start);
+   pr_cont(" (t=%lu jiffies g=%lu c=%lu)\n",
+   jiffies - rsp->gp_start, rsp->gpnum, rsp->completed);
if (!trigger_all_cpu_backtrace())
dump_stack();
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/11] x86: Supervisor Mode Access Prevention

[H. Peter Anvin]

On 09/21/2012 03:07 PM, Eric W. Biederman wrote:
> 
> Have you tested kexec in this environment?
> 
> This is the kind of cpu feature that when we enable it, frequently we
> have to do something on the kexec path.
> 
> At a quick skim it looks like the kexec path is using kernel page table
> entries and clearing all bits from cr4 except X86_CR4_PAE so I don't
> actually expect this change will require anything on the kexec path.
> 

I have not, no, but as you quite correctly point out that shouldn't
affect things.

We should also change the kernel to start clean with CR4 -- the purpose
of CR4 is to indicate which CPU features the OS is opting into.

I think we do on x86-64 but not on x86-32 at the moment.

This is an unrelated problem, though, and can be addressed later.

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

Re: [PATCH 00/11] x86: Supervisor Mode Access Prevention

[H. Peter Anvin]

On 09/21/2012 03:08 PM, Dave Jones wrote:
> 
> Perhaps add a printk somewhere to show that it's actually been enabled maybe ?
> 
> Also, would it be feasible to add something like we have for test_nx ?
> If this feature regresses in some way in the future, I suspect we'd like
> to know about it sooner rather than later.
> 

Good idea... should add this both for SMEP and SMAP.

-hpa



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

Re: [PATCH 00/11] x86: Supervisor Mode Access Prevention

[Dave Jones]

On Fri, Sep 21, 2012 at 12:43:04PM -0700, H. Peter Anvin wrote:
 > Supervisor Mode Access Prevention (SMAP) is a new security feature
 > disclosed by Intel in revision 014 of the Intel® Architecture
 > Instruction Set Extensions Programming Reference:
 > 
 > http://software.intel.com/sites/default/files/319433-014.pdf
 > 
 > When SMAP is active, the kernel cannot normally access pages that are
 > user space (U=1).  Since the kernel does have the need to access user
 > space pages under specific circumstances, an override is provided: the
 > kernel can access user space pages if EFLAGS.AC=1.  For system data
 > structures, e.g. descriptor tables, that are accessed by the processor
 > directly, SMAP is active even in CPL 3 regardless of EFLAGS.AC.
 > 
 > SMAP also includes two new instructions, STAC and CLAC, to flip the AC
 > flag more quickly.

Perhaps add a printk somewhere to show that it's actually been enabled maybe ?

Also, would it be feasible to add something like we have for test_nx ?
If this feature regresses in some way in the future, I suspect we'd like
to know about it sooner rather than later.

Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: RCU: update the stall warning message "timer=-1" to match reality

[Paul E. McKenney]

On Fri, Sep 21, 2012 at 04:13:29PM +, Paul Walmsley wrote:
> 
> The CONFIG_RCU_FAST_NO_HZ stall warning messages can never emit
> "timer=-1".  This is because the printf() format specifier to generate
> that number is '%lu'.  So, update the documentation to use the
> unsigned long equivalent instead, "timer=4294967295".  This is what
> actually shows up in traces.
> 
> Signed-off-by: Paul Walmsley 
> Cc: Paul E. McKenney 
> Cc: Dipankar Sarma 

Good catch!  Even worse, it gives "timer=18446744073709551615" on
64-bit systems, which is no easier on the eyes.  I therefore changed
the code to print a nicer message in this case, patch below.

The meaning of the "timer=4294967295" was that the corresponding CPU
was either non-idle or idle with no RCU callbacks, FWIW.

Thanx, Paul

-

rcu: Fix CONFIG_RCU_FAST_NO_HZ stall warning message

The print_cpu_stall_fast_no_hz() function attempts to print -1 when
the ->idle_gp_timer is not pending, but unsigned arithmetic causes it
to instead print ULONG_MAX, which is 4294967295 on 32-bit systems and
18446744073709551615 on 64-bit systems.  Neither of these are the most
reader-friendly values, so this commit instead causes "timer not pending"
to be printed when ->idle_gp_timer is not pending.

Reported-by: Paul Walmsley 
Signed-off-by: Paul E. McKenney 
Signed-off-by: Paul E. McKenney 

diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt
index 523364e..1927151 100644
--- a/Documentation/RCU/stallwarn.txt
+++ b/Documentation/RCU/stallwarn.txt
@@ -99,7 +99,7 @@ In kernels with CONFIG_RCU_FAST_NO_HZ, even more information 
is
 printed:
 
INFO: rcu_preempt detected stall on CPU
-   0: (64628 ticks this GP) idle=dd5/3fff/0 drain=0 . timer=-1
+   0: (64628 ticks this GP) idle=dd5/3fff/0 drain=0 . timer 
not pending
   (t=65000 jiffies)
 
 The "(64628 ticks this GP)" indicates that this CPU has taken more
@@ -116,13 +116,13 @@ number between the two "/"s is the value of the nesting, 
which will
 be a small positive number if in the idle loop and a very large positive
 number (as shown above) otherwise.
 
-For CONFIG_RCU_FAST_NO_HZ kernels, the "drain=0" indicates that the
-CPU is not in the process of trying to force itself into dyntick-idle
-state, the "." indicates that the CPU has not given up forcing RCU
-into dyntick-idle mode (it would be "H" otherwise), and the "timer=-1"
-indicates that the CPU has not recented forced RCU into dyntick-idle
-mode (it would otherwise indicate the number of microseconds remaining
-in this forced state).
+For CONFIG_RCU_FAST_NO_HZ kernels, the "drain=0" indicates that the CPU is
+not in the process of trying to force itself into dyntick-idle state, the
+"." indicates that the CPU has not given up forcing RCU into dyntick-idle
+mode (it would be "H" otherwise), and the "timer not pending" indicates
+that the CPU has not recently forced RCU into dyntick-idle mode (it
+would otherwise indicate the number of microseconds remaining in this
+forced state).
 
 
 Multiple Warnings From One Stall
diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 3b1a11e..be822f0 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -2245,11 +2245,15 @@ static void print_cpu_stall_fast_no_hz(char *cp, int 
cpu)
 {
struct rcu_dynticks *rdtp = _cpu(rcu_dynticks, cpu);
struct timer_list *tltp = >idle_gp_timer;
+   char c;
 
-   sprintf(cp, "drain=%d %c timer=%lu",
-   rdtp->dyntick_drain,
-   rdtp->dyntick_holdoff == jiffies ? 'H' : '.',
-   timer_pending(tltp) ? tltp->expires - jiffies : -1);
+   c = rdtp->dyntick_holdoff == jiffies ? 'H' : '.';
+   if (timer_pending(tltp))
+   sprintf(cp, "drain=%d %c timer=%lu",
+   rdtp->dyntick_drain, c, tltp->expires - jiffies);
+   else
+   sprintf(cp, "drain=%d %c timer not pending",
+   rdtp->dyntick_drain, c);
 }
 
 #else /* #ifdef CONFIG_RCU_FAST_NO_HZ */

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/11] x86: Supervisor Mode Access Prevention

[Eric W. Biederman]

"H. Peter Anvin"  writes:

> Supervisor Mode Access Prevention (SMAP) is a new security feature
> disclosed by Intel in revision 014 of the Intel® Architecture
> Instruction Set Extensions Programming Reference:
>
> http://software.intel.com/sites/default/files/319433-014.pdf
>
> When SMAP is active, the kernel cannot normally access pages that are
> user space (U=1).  Since the kernel does have the need to access user
> space pages under specific circumstances, an override is provided: the
> kernel can access user space pages if EFLAGS.AC=1.  For system data
> structures, e.g. descriptor tables, that are accessed by the processor
> directly, SMAP is active even in CPL 3 regardless of EFLAGS.AC.
>
> SMAP also includes two new instructions, STAC and CLAC, to flip the AC
> flag more quickly.

Have you tested kexec in this environment?

This is the kind of cpu feature that when we enable it, frequently we
have to do something on the kexec path.

At a quick skim it looks like the kexec path is using kernel page table
entries and clearing all bits from cr4 except X86_CR4_PAE so I don't
actually expect this change will require anything on the kexec path.

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

Re: rcu self-detected stall messages on OMAP3, 4 boards

[Paul E. McKenney]

On Fri, Sep 21, 2012 at 01:31:49PM -0700, Tony Lindgren wrote:
> * Paul E. McKenney  [120921 12:58]:
> > 
> > Just to make sure I understand the combinations:
> > 
> > o   All stalls have happened when running a minimal userspace.
> > o   CONFIG_NO_HZ=n suppresses the stalls.
> > o   CONFIG_RCU_FAST_NO_HZ (which depends on CONFIG_NO_HZ=y) has
> > no observable effect on the stalls.
> 
> The reason why you may need minimal userspace is to cut down
> the number of timers waking up the system with NO_HZ.
> Booting with init=/bin/sh might also do the trick for that.

Good point!  This does make for a very quiet system, but does not
reproduce the problem under kvm, even after waiting for four minutes.
I will leave it for more time, but it looks like I really might need to
ask Linaro for remote access to a Panda.

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: [PATCH] net/can: rename peak_usb dump_mem function

[Marc Kleine-Budde]

On 09/21/2012 11:42 PM, Randy Dunlap wrote:
> On 09/02/2012 10:13 AM, Randy Dunlap wrote:
> 
>> From: Randy Dunlap 
>>
>> Rename generic-sounding function dump_mem() to pcan_dump_mem()
>> so that it does not conflict with the dump_mem() function in
>> arch/sh/include/asm/kdebug.h.
>>
>> drivers/net/can/usb/peak_usb/pcan_usb_core.c: error: conflicting types for 
>> 'dump_mem':  => 56:6
>> drivers/net/can/usb/peak_usb/pcan_usb_core.h: error: conflicting types for 
>> 'dump_mem':  => 134:6
>>
>> Not tested.
>>
>> Signed-off-by: Randy Dunlap 
>> Reported-by: Geert Uytterhoeven 
>> Cc: Stephane Grosjean 
>> Cc: Wolfgang Grandegger 
>> Cc: Marc Kleine-Budde 
> 
> 
> ping.

The patch is already part of can-next and will be included in the next
pull request to David.

regards, Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] backlight: platform-lcd: Add support for device tree based probe

[Andrew Morton]

On Fri, 21 Sep 2012 10:27:07 +0900
Jingoo Han  wrote:

> This patch adds the of_match_table to platform-lcd driver to be
> probed when platform-lcd device node is found in the device tree.
> 
> Cc: Richard Purdie 
> Signed-off-by: Jingoo Han 
> ---
>  drivers/video/backlight/platform_lcd.c |9 +
>  1 files changed, 9 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/video/backlight/platform_lcd.c 
> b/drivers/video/backlight/platform_lcd.c
> index b667234..574d5ee 100644
> --- a/drivers/video/backlight/platform_lcd.c
> +++ b/drivers/video/backlight/platform_lcd.c
> @@ -145,6 +145,14 @@ static SIMPLE_DEV_PM_OPS(platform_lcd_pm_ops, 
> platform_lcd_suspend,
>   platform_lcd_resume);
>  #endif
>  
> +#ifdef CONFIG_OF
> +static const struct of_device_id platform_lcd_of_match[] = {
> + { .compatible = "platform-lcd" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, platform_lcd_of_match);
> +#endif
> +
>  static struct platform_driver platform_lcd_driver = {
>   .driver = {
>   .name   = "platform-lcd",
> @@ -152,6 +160,7 @@ static struct platform_driver platform_lcd_driver = {
>  #ifdef CONFIG_PM
>   .pm = _lcd_pm_ops,
>  #endif
> + .of_match_table = of_match_ptr(platform_lcd_of_match),
>   },
>   .probe  = platform_lcd_probe,
>   .remove = __devexit_p(platform_lcd_remove),

This .c file includes no open-firmware headers.

It does happen to get a copy of of.h via fb.h->i2c.h->of.h, but that
was just luck.

I did this:

--- 
a/drivers/video/backlight/platform_lcd.c~backlight-platform-lcd-add-support-for-device-tree-based-probe-fix
+++ a/drivers/video/backlight/platform_lcd.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
_

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

[Benjamin Herrenschmidt]

On Thu, 2012-09-20 at 18:53 -0400, David Miller wrote:
> From: Benjamin Herrenschmidt 
> Date: Fri, 21 Sep 2012 08:22:44 +1000
> 
> > Hrm, that's ancient gunk, I'll have to dig. We potentially can support
> > ISA devices DMA'ing from an ISA bridge... but via the iommu, which means
> > isa_virt_to_bus is a non-starter.
> > 
> > But then, do we really care ? IE. Is there single device that actually
> > requires ISA_DMA_API and that is expected to work on any currently
> > supported powerpc hw ? :-)
> > 
> > We don't even support PReP anymore, so that leaves us with what ?
> 
> ISA_DMA_API implies a fixed window of addresses which are <= 32-bits
> on the bus, which is a hardware requirement of these devices.
>
> isa_virt_to_bus() goes to that physical address, and the expection is
> that you use GFP_DMA and thus the physical addresses fit inside of
> an unsigned int.

Right, but on ppc, GFP_DMA is a nop (no separate ZONE_DMA, or rather all
of memory is ZONE_DMA). It's always been like that afaik.

We could support ISA device limited addressability using the iommu but
that would involve a map/unmap type API (which I remember we did support
in the old days by passing NULL to pci_map_*, but we dropped that along
the way).

> isa_virt_to_bus() basically amounts to a virt-->phys plus a cast.
> 
> > Anybody has an objection to turning ISA_DMA_API off ?
> 
> Then you can remove all of the DMA api stuff in powerpc's asm/dma.h
> but some of it looks like it might be in use.

I will dig a bit. I think there might be some users of the ISA DMA
engine for legacy floppies and parport on some early pSeries and CHRP
machines (including Pegasos).

Cheers,
Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] net/can: rename peak_usb dump_mem function

[Randy Dunlap]

On 09/02/2012 10:13 AM, Randy Dunlap wrote:

> From: Randy Dunlap 
> 
> Rename generic-sounding function dump_mem() to pcan_dump_mem()
> so that it does not conflict with the dump_mem() function in
> arch/sh/include/asm/kdebug.h.
> 
> drivers/net/can/usb/peak_usb/pcan_usb_core.c: error: conflicting types for 
> 'dump_mem':  => 56:6
> drivers/net/can/usb/peak_usb/pcan_usb_core.h: error: conflicting types for 
> 'dump_mem':  => 134:6
> 
> Not tested.
> 
> Signed-off-by: Randy Dunlap 
> Reported-by: Geert Uytterhoeven 
> Cc: Stephane Grosjean 
> Cc: Wolfgang Grandegger 
> Cc: Marc Kleine-Budde 


ping.

> ---
>  drivers/net/can/usb/peak_usb/pcan_usb_core.c |2 +-
>  drivers/net/can/usb/peak_usb/pcan_usb_core.h |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> --- lnx-36-rc4.orig/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> +++ lnx-36-rc4/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> @@ -53,7 +53,7 @@ static struct peak_usb_adapter *peak_usb
>   * dump memory
>   */
>  #define DUMP_WIDTH   16
> -void dump_mem(char *prompt, void *p, int l)
> +void pcan_dump_mem(char *prompt, void *p, int l)
>  {
>   pr_info("%s dumping %s (%d bytes):\n",
>   PCAN_USB_DRIVER_NAME, prompt ? prompt : "memory", l);
> --- lnx-36-rc4.orig/drivers/net/can/usb/peak_usb/pcan_usb_core.h
> +++ lnx-36-rc4/drivers/net/can/usb/peak_usb/pcan_usb_core.h
> @@ -131,7 +131,7 @@ struct peak_usb_device {
>   struct peak_usb_device *next_siblings;
>  };
>  
> -void dump_mem(char *prompt, void *p, int l);
> +void pcan_dump_mem(char *prompt, void *p, int l);
>  
>  /* common timestamp management */
>  void peak_usb_init_time_ref(struct peak_time_ref *time_ref,
> 



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

Drop support to compressed modules?

[Lucas De Marchi]

Hey,

I'd like to ask people the following question: why are you using
compressed modules? Is it only for the disk space or is there any
performance related reason?

While fixing a bug in kmod related to using compressed modules (that
already existed in module-init-tools) we stopped to think about these
questions. Dave made a couple of benchmarks and performance wise it's
better to use uncompressed modules than modules with gz or xz
compression. However the benchmark was done in only 1 computer. I do
expect people with slow storage to have different numbers though. Does
anyone have these numbers?


About the bug, I think it's fixed in
http://www.spinics.net/lists/linux-modules/msg00846.html. Need to test
a bit more before rolling out a new release.


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

Re: [PATCH RESEND] PM / Runtime: let rpm_resume() succeed if RPM_ACTIVE, even when disabled

[Kevin Hilman]

Alan Stern  writes:

> On Fri, 21 Sep 2012, Rafael J. Wysocki wrote:
>
>> > Kevin makes a good case that pm_runtime_resume() and related functions 
>> > should succeed even when runtime PM is disabled, if the device is 
>> > already in the desired state.
>> > 
>> > The same may be true for pm_runtime_suspend().  What do you think?
>> 
>> I've discussed that with Kevin.  The problem is that the runtime PM
>> status may be changed at will when runtime PM is disabled by using
>> __pm_runtime_set_status(), so the status generally cannod be trusted
>> if power.disable_depth > 0.
>
> Hmmm.  That same argument applies even when is_suspended is true.  
> Runtime PM might have been disabled beforehand by the driver, so you 
> still don't know whether to believe the status.
>
>> During system suspend, however, runtime PM is disabled by the core and
>> if neither the driver nor the subsystem has disabled it in the meantime,
>> the status should be actually valid.
>
> I suppose you could check that .disable_depth == 1.  That would mean 
> only the core had disabled runtime PM.
>
>> > The way the patch is written contradicts the documentation:
>> > 
>> >   * A request to execute ->runtime_resume() will cancel any pending or
>> > scheduled requests to execute the other callbacks for the same device,
>> > except for scheduled autosuspends.
>> 
>> I'm not sure where the contradiction is.  The patch simply changes the
>> behavior for disabled runtime PM, which is to return a nonzero value 
>> immediately
>> anyway.
>
> It changes an error return to a non-error return.
>
> However, if we limit the effects to times when the system is 
> suspending then there shouldn't be any pending or scheduled requests 
> anyway.  So okay, this isn't an issue.
>
>> > > > @@ -510,7 +510,8 @@ static int rpm_resume(struct device *dev, int 
>> > > > rpmflags)
>> > > >if (dev->power.runtime_error)
>> > > >retval = -EINVAL;
>> > > >else if (dev->power.disable_depth > 0)
>> > > > -  retval = -EACCES;
>> > > > +  retval = dev->power.is_suspended && 
>> > > > +  dev->power.runtime_status == RPM_ACTIVE ? 1 : 
>> > > > -EACCES;
>> > > >if (retval)
>> > > >goto out;
>> > 
>> > Also, the is_suspended test seems irrelevant in general -- it makes 
>> > sense in terms of the scenario Kevin described but that's not the 
>> > stated purpose of the patch.
>> 
>> Well, it is, although the changelog doesn't state it sufficiently clearly. 
>> :-)
>
> Good point.  The changelog needs to be improved.
>
>> > Both of these problems can be addressed by writing the code as follows:
>> > 
>> >if (dev->power.runtime_error)
>> >retval = -EINVAL;
>> >else if (dev->power.disable_depth > 0) {
>> > 
>> >/* Special case: allow this if the device is already active */
>> >if (dev->power.runtime_status != RPM_ACTIVE)
>> >retval = -EACCES;
>> >}
>> >if (retval)
>> >goto out;
>> 
>> We could do that too, but I'm a bit concerned about the situations where
>> runtime PM is disabled by the driver itself or by the subsystem, because
>> in those cases whoever disables runtime PM would have to make sure that the
>> status still reflects the actual hardware state, but that's what the runtime
>> PM framework is for (among other things).
>
> All right, let's use Kevin's original scheme but add a test for 
> disable_depth == 1.  I suggest changing the ?: operator to a regular 
> "if" statement, because the new condition will be even longer than the 
> old one (which I found a little hard to read in the first place).
>
> And of course, a comment should be added to explain the reason for the
> exception.
>
> Kevin, how does this sound?
>

Sounds good to me.

I'll respin and try to make the changelog more clear.

Thanks,

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: [RFC] cgroup TODOs

[Tejun Heo]

On Thu, Sep 13, 2012 at 01:58:27PM -0700, Tejun Heo wrote:
> 7. Misc issues
> 
>   * Sort & unique when listing tasks.  Even the documentation says it
> doesn't happen but we have a good hunk of code doing it in
> cgroup.c.  I'm gonna rip it out at some point.  Again, if you
> don't like it, scream.
> 
>   * At the PLC, pjt told me that assinging threads of a cgroup to
> different cgroups is useful for some use cases but if we're to
> have a unified hierarchy, I don't think we can continue to do
> that.  Paul, can you please elaborate the use case?
> 
>   * Vivek brought up the issue of distributing resources to tasks and
> groups in the same cgroup.  I don't know.  Need to think more
> about it.

* Update docs.

* Clean up cftype->read/write*() mess.

* Use sane fs event mechanism.

* Drop userland helper based empty notification.  Argh...

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

Re: [PATCH] rds: Error on offset mismatch if not loopback

[Venkat Venkatsubra]

On 9/21/2012 4:32 PM, John Jolly wrote:

Attempting an rds connection from the IP address of an IPoIB interface
to itself causes a kernel panic due to a BUG_ON() being triggered.
Making the test less strict allows rds-ping to work without crashing
the machine.

A local unprivileged user could use this flaw to crash the system.

Signed-off-by: John Jolly
---
  net/rds/ib_send.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/rds/ib_send.c b/net/rds/ib_send.c
index e590949..7920c85 100644
--- a/net/rds/ib_send.c
+++ b/net/rds/ib_send.c
@@ -544,7 +544,7 @@ int rds_ib_xmit(struct rds_connection *conn, struct 
rds_message *rm,
 int flow_controlled = 0;
 int nr_sig = 0;

-   BUG_ON(off % RDS_FRAG_SIZE);
+   BUG_ON(!conn->c_loopback&&  off % RDS_FRAG_SIZE);
 BUG_ON(hdr_off != 0&&  hdr_off != sizeof(struct rds_header));

 /* Do not send cong updates to IB loopback */

Hi John,

How do you trigger this BUG_ON ?
With rds-ping I could not hit this condition of non-zero "off % 
RDS_FRAG_SIZE".
rds-ping uses zero byte messages to ping or pong back. How does the 
"off" become non-zero ?


Thanks.

Venkat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 8/9] mm: compaction: Cache if a pageblock was scanned and no pages were isolated

[Andrew Morton]

On Fri, 21 Sep 2012 11:46:22 +0100
Mel Gorman  wrote:

> When compaction was implemented it was known that scanning could potentially
> be excessive. The ideal was that a counter be maintained for each pageblock
> but maintaining this information would incur a severe penalty due to a
> shared writable cache line. It has reached the point where the scanning
> costs are an serious problem, particularly on long-lived systems where a
> large process starts and allocates a large number of THPs at the same time.
> 
> Instead of using a shared counter, this patch adds another bit to the
> pageblock flags called PG_migrate_skip. If a pageblock is scanned by
> either migrate or free scanner and 0 pages were isolated, the pageblock
> is marked to be skipped in the future. When scanning, this bit is checked
> before any scanning takes place and the block skipped if set.
> 
> The main difficulty with a patch like this is "when to ignore the cached
> information?" If it's ignored too often, the scanning rates will still
> be excessive. If the information is too stale then allocations will fail
> that might have otherwise succeeded. In this patch
> 
> o CMA always ignores the information
> o If the migrate and free scanner meet then the cached information will
>   be discarded if it's at least 5 seconds since the last time the cache
>   was discarded
> o If there are a large number of allocation failures, discard the cache.
> 
> The time-based heuristic is very clumsy but there are few choices for a
> better event. Depending solely on multiple allocation failures still allows
> excessive scanning when THP allocations are failing in quick succession
> due to memory pressure. Waiting until memory pressure is relieved would
> cause compaction to continually fail instead of using reclaim/compaction
> to try allocate the page. The time-based mechanism is clumsy but a better
> option is not obvious.

ick.

Wall time has sooo little relationship to what's happening in there. 
If we *have* to use polling, cannot we clock the poll with some metric
which is at least vaguely related to the amount of activity?  Number
(or proportion) of pages scanned, for example?  Or reset everything on
the Nth trip around the zone?  Or even a combination of one of these
*and* of wall time, so the system will at least work harder when MM is
under load.

Also, what has to be done to avoid the polling altogether?  eg/ie, zap
a pageblock's PB_migrate_skip synchronously, when something was done to
that pageblock which justifies repolling it?

>
> ...
>
> +static void reset_isolation_suitable(struct zone *zone)
> +{
> + unsigned long start_pfn = zone->zone_start_pfn;
> + unsigned long end_pfn = zone->zone_start_pfn + zone->spanned_pages;
> + unsigned long pfn;
> +
> + /*
> +  * Do not reset more than once every five seconds. If allocations are
> +  * failing sufficiently quickly to allow this to happen then continually
> +  * scanning for compaction is not going to help. The choice of five
> +  * seconds is arbitrary but will mitigate excessive scanning.
> +  */
> + if (time_before(jiffies, zone->compact_blockskip_expire))
> + return;
> + zone->compact_blockskip_expire = jiffies + (HZ * 5);
> +
> + /* Walk the zone and mark every pageblock as suitable for isolation */
> + for (pfn = start_pfn; pfn < end_pfn; pfn += pageblock_nr_pages) {
> + struct page *page;
> + if (!pfn_valid(pfn))
> + continue;
> +
> + page = pfn_to_page(pfn);
> + if (zone != page_zone(page))
> + continue;
> +
> + clear_pageblock_skip(page);
> + }

What's the worst-case loop count here?

> +}
> +
>
> ...
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/9] mm: compaction: Acquire the zone->lock as late as possible

[Andrew Morton]

On Fri, 21 Sep 2012 11:46:20 +0100
Mel Gorman  wrote:

> Compactions free scanner acquires the zone->lock when checking for PageBuddy
> pages and isolating them. It does this even if there are no PageBuddy pages
> in the range.
> 
> This patch defers acquiring the zone lock for as long as possible. In the
> event there are no free pages in the pageblock then the lock will not be
> acquired at all which reduces contention on zone->lock.
>
> ...
>
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -93,6 +93,28 @@ static inline bool compact_trylock_irqsave(spinlock_t 
> *lock,
>   return compact_checklock_irqsave(lock, flags, false, cc);
>  }
>  
> +/* Returns true if the page is within a block suitable for migration to */
> +static bool suitable_migration_target(struct page *page)
> +{
> +

stray newline

> + int migratetype = get_pageblock_migratetype(page);
> +
> + /* Don't interfere with memory hot-remove or the min_free_kbytes blocks 
> */
> + if (migratetype == MIGRATE_ISOLATE || migratetype == MIGRATE_RESERVE)
> + return false;
> +
> + /* If the page is a large free page, then allow migration */
> + if (PageBuddy(page) && page_order(page) >= pageblock_order)
> + return true;
> +
> + /* If the block is MIGRATE_MOVABLE or MIGRATE_CMA, allow migration */
> + if (migrate_async_suitable(migratetype))
> + return true;
> +
> + /* Otherwise skip the block */
> + return false;
> +}
> +
>
> ...
>
> @@ -168,23 +193,38 @@ static unsigned long isolate_freepages_block(unsigned 
> long blockpfn,
>   int isolated, i;
>   struct page *page = cursor;
>  
> - if (!pfn_valid_within(blockpfn)) {
> - if (strict)
> - return 0;
> - continue;
> - }
> + if (!pfn_valid_within(blockpfn))
> + goto strict_check;
>   nr_scanned++;
>  
> - if (!PageBuddy(page)) {
> - if (strict)
> - return 0;
> - continue;
> - }
> + if (!PageBuddy(page))
> + goto strict_check;
> +
> + /*
> +  * The zone lock must be held to isolate freepages. This
> +  * unfortunately this is a very coarse lock and can be

this this

> +  * heavily contended if there are parallel allocations
> +  * or parallel compactions. For async compaction do not
> +  * spin on the lock and we acquire the lock as late as
> +  * possible.
> +  */
> + locked = compact_checklock_irqsave(>zone->lock, ,
> + locked, cc);
> + if (!locked)
> + break;
> +
> + /* Recheck this is a suitable migration target under lock */
> + if (!strict && !suitable_migration_target(page))
> + break;
> +
> + /* Recheck this is a buddy page under lock */
> + if (!PageBuddy(page))
> + goto strict_check;
>  
>   /* Found a free page, break it into order-0 pages */
>   isolated = split_free_page(page);
>   if (!isolated && strict)
> - return 0;
> + goto strict_check;
>   total_isolated += isolated;
>   for (i = 0; i < isolated; i++) {
>   list_add(>lru, freelist);
> @@ -196,9 +236,23 @@ static unsigned long isolate_freepages_block(unsigned 
> long blockpfn,
>   blockpfn += isolated - 1;
>   cursor += isolated - 1;
>   }
> +
> + continue;
> +
> +strict_check:
> + /* Abort isolation if the caller requested strict isolation */
> + if (strict) {
> + total_isolated = 0;
> + goto out;
> + }
>   }
>  
>   trace_mm_compaction_isolate_freepages(nr_scanned, total_isolated);
> +
> +out:
> + if (locked)
> + spin_unlock_irqrestore(>zone->lock, flags);
> +
>   return total_isolated;
>  }

A a few things about this function.

Would it be cleaner if we did

if (!strict) {
if (!suitable_migration_target(page))
break;
} else {
if (!PageBuddy(page))
goto strict_check;
}

and then remove the test of `strict' from strict_check (which then
should be renamed)?

Which perhaps means that the whole `strict_check' block can go away:

if (!strict) {
if (!suitable_migration_target(page))
break;
} else {
if (!PageBuddy(page)) {
total_isolated = 0;
goto out;
}

Have a think about it?  The 

Re: [PATCH v2 0/3] input: Dynamic Minor Numbers

[David Herrmann]

Hi Dmitry

On Fri, Sep 21, 2012 at 10:51 PM, Dmitry Torokhov
 wrote:
> On Friday, September 21, 2012 09:18:00 PM David Herrmann wrote:
>> Hi Dmitry
>>
>> On Fri, Sep 21, 2012 at 11:22 AM, David Herrmann
>>
>>  wrote:
>> > Hi Dmitry
>> >
>> > On Fri, Sep 21, 2012 at 10:07 AM, Dmitry Torokhov
>> >
>> >  wrote:
>> >> Thank you very much for working on this, unfortunately your patch extends
>> >> the existing infrastructure handling of character devices in input core,
>> >> which is quite rigid and sub-optimal.
>> >>
>> >> For a while now I wanted to stop input core from pre-creating character
>> >> devices and multiplexing file operations and instead push more chardev
>> >> handling tasks into individual input handlers and make they more
>> >> independent from input core. So while I won't be taking your patch as is
>> >> it was a great motivator to finally do something about current
>> >> limitation and I would appreciate if you could take a look at the patch
>> >> below and see if you have any issues with it.
>> >
>> > I didn't know why we did that, anyway. But I tried to keep that logic,
>> > even though it is really weird. So I am quite glad that you fixed it.
>>
>> Sorry, compiling a kernel takes 44m here so I haven't had time earlier
>> this day. But I just recompiled with your patch and it works like a
>> charm. I have attached output of "ls -la /dev/input" with 900 uinput
>> devices. Performance does suck but that is definitely another issue.
>
> Could you elaborate a bit on this?

It takes like 2s to create 100 devices. Ok, that's about 500 syscalls.
But still, 2s seemed pretty much to me. But that's probably related to
uinput. 1000 devices take like 10s here.
Also the xserver crashes when connecting more than 40 or 50 devices.
It does print "too many devices; ignoring" but there seems to be some
error-path bug.
I haven't noticed any runtime kernel bugs or runtime
performance-drops, though. So as I said, there are some issues, that
need to be solved, but they are not related to input-core. (Also,
creating 1000 uinput devices doesn't seem like a use-case that we
should try to optimize).

Regards
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] rds: Error on offset mismatch if not loopback

[John Jolly]

Attempting an rds connection from the IP address of an IPoIB interface
to itself causes a kernel panic due to a BUG_ON() being triggered.
Making the test less strict allows rds-ping to work without crashing
the machine.

A local unprivileged user could use this flaw to crash the system.

Signed-off-by: John Jolly 
---
 net/rds/ib_send.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/rds/ib_send.c b/net/rds/ib_send.c
index e590949..7920c85 100644
--- a/net/rds/ib_send.c
+++ b/net/rds/ib_send.c
@@ -544,7 +544,7 @@ int rds_ib_xmit(struct rds_connection *conn, struct 
rds_message *rm,
int flow_controlled = 0;
int nr_sig = 0;
 
-   BUG_ON(off % RDS_FRAG_SIZE);
+   BUG_ON(!conn->c_loopback && off % RDS_FRAG_SIZE);
BUG_ON(hdr_off != 0 && hdr_off != sizeof(struct rds_header));
 
/* Do not send cong updates to IB loopback */
-- 
1.7.7

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

Re: [PATCH 4/9] mm: compaction: Abort compaction loop if lock is contended or run too long

[Andrew Morton]

On Fri, 21 Sep 2012 11:46:18 +0100
Mel Gorman  wrote:

> Changelog since V2
> o Fix BUG_ON triggered due to pages left on cc.migratepages
> o Make compact_zone_order() require non-NULL arg `contended'
> 
> Changelog since V1
> o only abort the compaction if lock is contended or run too long
> o Rearranged the code by Andrea Arcangeli.
> 
> isolate_migratepages_range() might isolate no pages if for example when
> zone->lru_lock is contended and running asynchronous compaction. In this
> case, we should abort compaction, otherwise, compact_zone will run a
> useless loop and make zone->lru_lock is even contended.

hm, this appears to be identical to

mm-compaction-abort-compaction-loop-if-lock-is-contended-or-run-too-long.patch
mm-compaction-abort-compaction-loop-if-lock-is-contended-or-run-too-long-fix.patch
mm-compaction-abort-compaction-loop-if-lock-is-contended-or-run-too-long-fix-2.patch

so I simply omitted patches 2, 3 and 4.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] rds: Error on offset mismatch if not loopback

[John Jolly]

On Fri, Sep 21, 2012 at 01:20:45PM -0400, David Miller wrote:
> From: John Jolly 
> Date: Thu, 20 Sep 2012 01:11:34 -0600
> 
> > Attempting an rds connection from the IP address of an IPoIB interface
> > to itself causes a kernel panic due to a BUG_ON() being triggered. Making
> > the test less strict allows rds-ping to work without crashing the machine.
> > 
> > A local unprivileged user could use this flaw to crash the sytem.
> 
> Please read Documentation/SubmittingPatches to learn how to properly
> submit a change, in particular your patch submission was missing a
> proper signoff.

Thanks for catching that. Resubmitting with proper signoff.

> 
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: rcu self-detected stall messages on OMAP3, 4 boards

[Paul E. McKenney]

On Fri, Sep 21, 2012 at 05:47:31PM +, Paul Walmsley wrote:
> Hi Paul
> 
> On Thu, 20 Sep 2012, Paul Walmsley wrote:
> 
> > On Thu, 20 Sep 2012, Paul E. McKenney wrote:
> >
> > > Paul Walmsley, please let me know if the config below doesn't clear things
> > > up for you or if there is some reason why this config is infeasible.
> > 
> > Will certainly test it here once things settle down.
> 
> I built an OMAP kernel from Linus' commit 
> 4651afbbae968772efd6dc4ba461cba9b49bb9d8 ("Merge branch 'for-3.6-fixes' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq").  The config used 
> was 'omap2plus_defconfig', and enabled CONFIG_CPU_IDLE by hand.  Booted it 
> on a Pandaboard (OMAP4430ES2) into a very minimal Debian rootfs.

Did you have the patch at https://lkml.org/lkml/2012/8/30/290 applied?
If not, could you please try it?  (This patch cleared up a similar
problem for Becky, also on OMAP.)

Thanx, Paul

> Long story short, the rcu_sched stall messages continue to appear.  
> Transcript below.
> 
> The above config should be easy to reproduce from mainline.  Paul, not 
> sure if you're still working with Linaro, but you should be able to get 
> access to a Pandaboard through them to try it yourself, should you wish.
> 
> 
> - Paul
> 
> ## Booting kernel from Legacy Image at 8200 ...   
> 
>Image Name:   Linux-3.6.0-rc6-00025-g4651afb   
> 
>Image Type:   ARM Linux Kernel Image (uncompressed)
> 
>Data Size:4061576 Bytes = 3.9 MiB  
> 
>Load Address: 80008000 
> 
>Entry Point:  80008000 
> 
>Verifying Checksum ... OK  
> 
>Loading Kernel Image ... OK
> 
> OK
> 
>   
> 
> Starting kernel ...   
> 
>   
> 
> Uncompressing Linux... done, booting the kernel.  
> 
> [0.00] Booting Linux on physical CPU 0
> 
> [0.00] Linux version 3.6.0-rc6-00025-g4651afb (paul@dusk) (gcc 
> version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #342 SMP Fri Sep 21 11:28:00 
> MDT 2012  
>
> [0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), 
> cr=10c53c7d
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache   
> [0.00] Machine: OMAP4 Panda board 
> 
> [0.00] debug: ignoring loglevel setting.  
> 
> [0.00] Reserving 16777216 bytes SDRAM for VRAM
> 
> [0.00] Memory policy: ECC disabled, Data cache writealloc
> [0.00] On node 0 totalpages: 126720   
> 
> [0.00] free_area_init_node: node 0, pgdat c07c6140, node_mem_map 
> c0d23000
> [0.00]   Normal zone: 1024 pages used for memmap
> [0.00]   Normal zone: 0 pages reserved
> [0.00]   Normal zone: 125696 pages, LIFO batch:31
> [0.00] OMAP4430 ES2.0
> [0.00] PERCPU: Embedded 9 pages/cpu @c112b000 s14016 r8192 d14656 
> u36864
> [0.00] pcpu-alloc: s14016 r8192 d14656 u36864 alloc=9*4096
> [0.00] pcpu-alloc: [0] 0 [0] 1 
> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
> pages: 125696
> [0.00] Kernel command line: console=ttyO2,230400n8 vram=16M 
> root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait earlyprintk debug 
> ignore_loglevel
> [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
> [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
> [0.00] Memory: 495MB = 495MB total
> [0.00] Memory: 488828k/488828k available, 35460k reserved, 0K highmem
> [0.00] Virtual kernel memory layout:
> [0.00] vector  : 0x - 0x1000   (   4 kB)
> [

Re: linux-next: Tree for Sept 21 (misc/lis3lv02d DT code)

[Daniel Mack]

On 21.09.2012 19:48, Randy Dunlap wrote:
> On 09/21/2012 12:01 AM, Stephen Rothwell wrote:
> 
>> Hi all,
>>
>> Changes since 201209020:
>>
> 
> 
> 
> on i386:
> 
> ERROR: "lis3lv02d_init_dt" [drivers/misc/lis3lv02d/lis3lv02d_i2c.ko] 
> undefined!
> 
> Full randconfig file is attached.
> 

Hmm, I cannot reproduce that on my machine with your config, but the
attached patch should fix it.

Andrew, you already have a patch queued up for this driver - could you
fold that one maybe after Randy signals success?


Thanks,
Daniel

>From 7b3210ec41a40f2b667f57eb4478eb5a149199c8 Mon Sep 17 00:00:00 2001
From: Daniel Mack 
Date: Fri, 21 Sep 2012 23:14:29 +0200
Subject: [PATCH] misc: lis3: fix undefined reference to lis3lv02d_init_dt

Export the symbol to fix linker errors.

Signed-off-by: Daniel Mack 
Reported-by: Randy Dunlap 
---
 drivers/misc/lis3lv02d/lis3lv02d.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c b/drivers/misc/lis3lv02d/lis3lv02d.c
index 026021e..f9c24ab 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d.c
@@ -1089,6 +1089,7 @@ int lis3lv02d_init_dt(struct lis3lv02d *lis3)
 	return 0;
 }
 #endif
+EXPORT_SYMBOL_GPL(lis3lv02d_init_dt);
 
 /*
  * Initialise the accelerometer and the various subsystems.
-- 
1.7.11.4

Re: [PATCH 01/40] PCI: fix default vga ref_count

[Yinghai Lu]

On Fri, Sep 21, 2012 at 1:52 PM, Bjorn Helgaas  wrote:
> On Wed, Sep 19, 2012 at 12:54 PM, Yinghai Lu  wrote:
>> --- a/drivers/gpu/vga/vgaarb.c
>> +++ b/drivers/gpu/vga/vgaarb.c
>> @@ -141,6 +141,12 @@ EXPORT_SYMBOL_GPL(vga_default_device);
>>
>>  void vga_set_default_device(struct pci_dev *pdev)
>>  {
>> +   if (vga_default)
>> +   pci_dev_put(vga_default);
>> +
>> +   if (pdev)
>> +   pdev = pci_dev_get(pdev);
>> +
>> vga_default = pdev;
>
> I think this is equivalent to:
>
> pci_dev_put(vga_default);
> vga_default = pci_dev_get(pdev);

ah, i missed that, pci_dev_put and pci_dev_get check that inside.

>
> I haven't seen an answer to Matthew's question about whether we want
> to check for "vga_default == pdev".

yes, that could avoid the extra put/get pair.

Please check updated version.

-Yinghai


fix_vgarab_add_x.patch
Description: Binary data

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Thanasis]

on 09/21/2012 11:29 PM Francois Romieu wrote the following:
> Thanasis  :
>> So far, ping has failed *only* at this iteration of the make loop:
> 
> Ok.
> 
> Without the usual netdev watchdog message I presume ?

What message? What do you mean "the usual netdev watchdog message"?
I used a usb stick to transfer the log to another machine, if that's
what you mean.

> 
> [...]
>> Now, after 74 iterations, it looks as if the loop is stuck at the following:
>>
>> HEAD is now at 1ce4b16 r8169: spinlock redux.
>> make -C /lib/modules/2.6.38-r8/build
>> M=/mnt/usb-disk/atom/usr/src/test-r8169/r8169 modules
>> make[1]: Entering directory `/usr/src/linux-2.6.38-r8'
>>   CC [M]  /mnt/usb-disk/atom/usr/src/test-r8169/r8169/r8169.o
>>   Building modules, stage 2.
>>   MODPOST 1 modules
>>   CC  /mnt/usb-disk/atom/usr/src/test-r8169/r8169/r8169.mod.o
>>   LD [M]  /mnt/usb-disk/atom/usr/src/test-r8169/r8169/r8169.ko
>> make[1]: Leaving directory `/usr/src/linux-2.6.38-r8'
>>
>>
>> Should I wait for it to end?
> 
> No. I surely f*cked up something.
> 
>> Do you want me to post the whole log so far?
> 
> Please. It should gzip well. The complete dmesg with timestamps would be
> welcome too.

Attached dmesg.gz
> 
> Could you perform a test with your vendor's 3.2-something kernel and its
> r8169 driver ?
> 
The vendor's kernel was a 2.6 series.


dmesg.gz
Description: GNU Zip compressed data

Re: Linux 3.6-rc4

[Dave Jones]

On Mon, Sep 10, 2012 at 04:36:20PM +0200, Peter Zijlstra wrote:
 > On Fri, 2012-09-07 at 11:39 -0700, Linus Torvalds wrote:
 > > Al? Please look into this. I'm not entirely sure what's going on, but
 > > lockdep complains about this:
 > > 
 > >  Possible interrupt unsafe locking scenario:
 > > 
 > >CPU0CPU1
 > >
 > >   lock(&(>alloc_lock)->rlock);
 > >local_irq_disable();
 > >lock(&(_timer->it_lock)->rlock);
 > >lock(tasklist_lock);
 > >   
 > > lock(&(_timer->it_lock)->rlock);
 > > 
 > >  *** DEADLOCK ***
 > > 
 > > and it looks real. IOW, if I read that right, we have the task_lock ->
 > > it_lock dependency through exit_itimers(), and then we have the
 > > tasklist_lock -> task_lock dependency everywhere else. So now it_lock
 > > -> tasklist_lock becomes a deadlock. 
 > 
 > Agreed, I've got the following series from Oleg queued to solve this:
 > 
 >  http://marc.info/?l=linux-kernel=134600821828491=2

What's happening with this series ? I'm still seeing these traces in rc6.

Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/11] x86: Supervisor Mode Access Prevention

[H. Peter Anvin]

On 09/21/2012 02:09 PM, Linus Torvalds wrote:
> On Fri, Sep 21, 2012 at 2:03 PM, H. Peter Anvin  wrote:
>>
>> A while ago I also did a mockup patch which switched %cr3 to
>> swapper_pg_dir while entering the kernel (basically where the CLAC
>> instructions go, plus the SYSCALL path; a restore was obviously needed,
>> too.)  The performance was atrocious, but I didn't remember running into
>> any problems.
> 
> Well, they are bound to be corner-cases and unusual. I was thinking of
> problems like the one recently fixed in commit ed6fe9d614fc ("Fix
> order of arguments to compat_put_time[spec|val]"), which really
> requires compat handling of fairly unusual cases.
> 
> That's the kind of situation where I'd expect bugs might still lurk.
> And it would only get triggered by some rather unusual setups.
> 

Yes; in *most* cases these are exploitable security bugs on non-SMAP
hardware (which is obviously the whole point!), but there are a few
conditions where there may be issues that aren't exploitable problems.

-hpa



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

Re: [PATCH 00/11] x86: Supervisor Mode Access Prevention

[Linus Torvalds]

On Fri, Sep 21, 2012 at 2:03 PM, H. Peter Anvin  wrote:
>
> A while ago I also did a mockup patch which switched %cr3 to
> swapper_pg_dir while entering the kernel (basically where the CLAC
> instructions go, plus the SYSCALL path; a restore was obviously needed,
> too.)  The performance was atrocious, but I didn't remember running into
> any problems.

Well, they are bound to be corner-cases and unusual. I was thinking of
problems like the one recently fixed in commit ed6fe9d614fc ("Fix
order of arguments to compat_put_time[spec|val]"), which really
requires compat handling of fairly unusual cases.

That's the kind of situation where I'd expect bugs might still lurk.
And it would only get triggered by some rather unusual setups.

 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: [PATCH] kgdb: Fix warning with !CONFIG_DEBUG_RODATA

[Andi Kleen]

On Fri, Sep 21, 2012 at 04:01:55PM -0500, Jason Wessel wrote:
> On 09/21/2012 03:59 PM, Andi Kleen wrote:
> > From: Andi Kleen 
> > 
> > Fixes
> > 
> > arch/x86/kernel/kgdb.c: In function ‘kgdb_arch_set_breakpoint’:
> > arch/x86/kernel/kgdb.c:749:7: warning: unused variable ‘opc’ 
> > [-Wunused-variable]
> > 
> > when CONFIG_DEBUG_RODATA is not defined.
> > 
> 
> This is already pending along with other fixes in kgdb-next / linux next for 
> the 3.7 merge window.

Ok.  This was broken in 3.5 too. Next time please fast track warning fixes.

It's about the only warning in my standard builds.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/11] x86: Supervisor Mode Access Prevention

[H. Peter Anvin]

On 09/21/2012 01:08 PM, Ingo Molnar wrote:
> 
> * Linus Torvalds  wrote:
> 
>> On Fri, Sep 21, 2012 at 12:43 PM, H. Peter Anvin  
>> wrote:
>>
>>> Supervisor Mode Access Prevention (SMAP) is a new security 
>>> feature disclosed by Intel in revision 014 of the Intel® 
>>> Architecture Instruction Set Extensions Programming 
>>> Reference:
>>
>> Looks good.
>>
>> Did this find any bugs, btw? We've had a few cases where we 
>> forgot to use the proper user access function, and code just 
>> happened to work because it all boils down to the same thing 
>> and never got any page faults in practice anyway..
> 
> The 4g:4g patch sweeped out most of the historic ones - so what 
> we have are perhaps newer bugs (but those should be pretty rare, 
> most new features are cross-arch).
> 

A while ago I also did a mockup patch which switched %cr3 to
swapper_pg_dir while entering the kernel (basically where the CLAC
instructions go, plus the SYSCALL path; a restore was obviously needed,
too.)  The performance was atrocious, but I didn't remember running into
any problems.

-hpa

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

Re: [PATCH] kgdb: Fix warning with !CONFIG_DEBUG_RODATA

[Jason Wessel]

On 09/21/2012 03:59 PM, Andi Kleen wrote:
> From: Andi Kleen 
> 
> Fixes
> 
> arch/x86/kernel/kgdb.c: In function ‘kgdb_arch_set_breakpoint’:
> arch/x86/kernel/kgdb.c:749:7: warning: unused variable ‘opc’ 
> [-Wunused-variable]
> 
> when CONFIG_DEBUG_RODATA is not defined.
> 

This is already pending along with other fixes in kgdb-next / linux next for 
the 3.7 merge window.

Jason.

--
commit 9a15c35d16cf76482be076125f631f1193e29413
Author: Jason Wessel 
Date:   Wed Aug 8 21:12:19 2012 -0500

kgdb,x86: fix warning about unused variable

When compiling without CONFIG_DEBUG_RODATA the following
compiler warning is generated:

arch/x86/kernel/kgdb.c: In function 'kgdb_arch_set_breakpoint':
arch/x86/kernel/kgdb.c:749: warning: unused variable 'opc'

The variable instantiation needs to be inside the #ifdef to
make the warning go away.

Reported-by: Thiago Rafael Becker 
Signed-off-by: Jason Wessel 

diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c
index 3f61904..836f832 100644
--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -746,7 +746,9 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long ip
 int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
 {
int err;
+#ifdef CONFIG_DEBUG_RODATA
char opc[BREAK_INSTR_SIZE];
+#endif /* CONFIG_DEBUG_RODATA */
 
bpt->type = BP_BREAKPOINT;
err = probe_kernel_read(bpt->saved_instr, (char *)bpt->bpt_addr,

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

[PATCH] kgdb: Fix warning with !CONFIG_DEBUG_RODATA

[Andi Kleen]

From: Andi Kleen 

Fixes

arch/x86/kernel/kgdb.c: In function ‘kgdb_arch_set_breakpoint’:
arch/x86/kernel/kgdb.c:749:7: warning: unused variable ‘opc’ [-Wunused-variable]

when CONFIG_DEBUG_RODATA is not defined.

Signed-off-by: Andi Kleen 
---
 arch/x86/kernel/kgdb.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c
index 3f61904..0e4badd 100644
--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -746,7 +746,9 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long 
ip)
 int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
 {
int err;
+#ifdef CONFIG_DEBUG_RODATA
char opc[BREAK_INSTR_SIZE];
+#endif
 
bpt->type = BP_BREAKPOINT;
err = probe_kernel_read(bpt->saved_instr, (char *)bpt->bpt_addr,
-- 
1.7.7.6

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

Re: [PATCH v2] Persistent grant maps for xen blk drivers

[Konrad Rzeszutek Wilk]

On Fri, Sep 21, 2012 at 02:56:22PM -0400, Konrad Rzeszutek Wilk wrote:
> > *: With a PVHVM guest I get
> > 
> > [  261.927218] privcmd_fault: vma=88002a31dce8 
> > 7f4edc095000-7f4edc195000, pgoff=c8, uv=7f4edc15d000
> > 
> > thought if I applied your patch on top of v3.6-rc6 I didn't see the 
> > privcmd_fault but
> > I did see the guest crash.
> 
> And that is due to c571898ffc24a1768e1b2dabeac0fc7dd4c14601 which I've 
> reverted in my
> #linux-next branch

Nevermind. Andres' patch by itself (so without yours) works just fine. There is
something your patch and his aren't agreeing on.

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

Re: [PATCH] Xen backend support for paged out grant targets V4.

[Konrad Rzeszutek Wilk]

> > So with this patch when I launch an PVHVM guest on Xen 4.1 I get this
> > in the initial domain and the guest is crashed:
> > 
> > [  261.927218] privcmd_fault: vma=88002a31dce8 
> > 7f4edc095000-7f4edc195000, pgoff=c8, uv=7f4edc15d000
> 
> With this patch? Or with the mmapbatch v2? This is a page fault in a 
> foreign-mapped VMA. Not touched by this grant backend patch we are talking 
> about.
> 
> Does the hypervisor dump anything to its console?
> 
> At which point during xc_hvm_build do you see this? (or elsewhere in the 
> toolstack?)

My apologies. It was Oliver's persistent grant patch that does not like your 
patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] ACPI: Override arbitrary ACPI tables via initrd for debugging

[Yinghai Lu]

On Fri, Sep 21, 2012 at 6:28 AM, Thomas Renninger  wrote:
> Details can be found in:
> Documentation/acpi/initrd_table_override.txt
>
> Signed-off-by: Thomas Renninger 
> CC: eric.p...@tremplin-utc.net
> CC: voj...@tlen.pl
> CC: Lin Ming 
> CC: l...@kernel.org
> CC: robert.mo...@intel.com
> CC: h...@zytor.com
> CC: ying...@kernel.org
> ---
>  Documentation/acpi/initrd_table_override.txt |  122 +++
>  arch/x86/kernel/setup.c  |4 +
>  drivers/acpi/Kconfig |9 +
>  drivers/acpi/osl.c   |  203 
> --
>  include/linux/acpi.h |4 +
>  5 files changed, 331 insertions(+), 11 deletions(-)
>  create mode 100644 Documentation/acpi/initrd_table_override.txt
>
> diff --git a/Documentation/acpi/initrd_table_override.txt 
> b/Documentation/acpi/initrd_table_override.txt
> new file mode 100644
> index 000..b550831
> --- /dev/null
> +++ b/Documentation/acpi/initrd_table_override.txt
> @@ -0,0 +1,122 @@
> +Overriding ACPI tables via initrd
> +=
> +
> +1) Introduction (What is this about)
> +2) What is this for
> +3) How does it work
> +4) References (Where to retrieve userspace tools)
> +
> +1) What is this about
> +-
> +
> +If ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible to
> +override nearly any ACPI table provided by the BIOS with an instrumented,
> +modified one.
> +
> +For a full list of ACPI tables that can be overridden, take a look at
> +the char *table_sigs[MAX_ACPI_SIGNATURE]; definition in drivers/acpi/osl.c
> +All ACPI tables iasl (Intel's ACPI compiler and disassembler) knows should
> +be overridable, except:
> +   - ACPI_SIG_RSDP (has a signature of 6 bytes)
> +   - ACPI_SIG_FACS (does not have an ordinary ACPI table header)
> +Both could get implemented as well.
> +
> +
> +2) What is this for
> +---
> +
> +Please keep in mind that this is a debug option.
> +ACPI tables should not get overridden for productive use.
> +If BIOS ACPI tables are overridden the kernel will get tainted with the
> +TAINT_OVERRIDDEN_ACPI_TABLE flag.
> +Complain to your platform/BIOS vendor if you find a bug which is that sever
> +that a workaround is not accepted in the Linus kernel.
> +
> +Still, it can and should be enabled in any kernel, because:
> +  - There is no functional change with not instrumented initrds
> +  - It provides a powerful feature to easily debug and test ACPI BIOS table
> +compatibility with the Linux kernel.
> +
> +Until now it was only possible to override the DSDT by compiling it into
> +the kernel. This is a nightmare when trying to work on ACPI related bugs
> +and a lot bugs got stuck because of that.
> +Even for people with enough kernel knowledge, building a kernel to try out
> +things is very time consuming. Also people may have to browse and modify the
> +ACPI interpreter code to find a possible BIOS bug. With this feature, people
> +can correct the ACPI tables and try out quickly whether this is the root 
> cause
> +that needs to get addressed in the kernel.
> +
> +This could even ease up testing for BIOS providers who could flush their BIOS
> +to test, but overriding table via initrd is much easier and quicker.
> +For example one could prepare different initrds overriding NUMA tables with
> +different affinity settings. Set up a script, let the machine reboot and
> +run tests over night and one can get a picture how these settings influence
> +the Linux kernel and which values are best.
> +
> +People can instrument the dynamic ACPI (ASL) code (for example with debug
> +statements showing up in syslog when the ACPI code is processed, etc.),
> +to better understand BIOS to OS interfaces, to hunt down ACPI BIOS code 
> related
> +bugs quickly or to easier develop ACPI based drivers.
> +
> +Intstrumenting ACPI code in SSDTs is now much easier. Before, one had to copy
> +all SSDTs into the DSDT to compile it into the kernel for testing
> +(because only DSDT could get overridden). That's what the acpi_no_auto_ssdt
> +boot param is for: the BIOS provided SSDTs are ignored and all have to get
> +copied into the DSDT, complicated and time consuming.
> +
> +Much more use cases, depending on which ACPI parts you are working on...
> +
> +
> +3) How does it work
> +---
> +
> +# Extract the machine's ACPI tables:
> +cd /tmp
> +acpidump >acpidump
> +acpixtract -a acpidump
> +# Disassemble, modify and recompile them:
> +iasl -d *.dat
> +# For example add this statement into a _PRT (PCI Routing Table) function
> +# of the DSDT:
> +Store("HELLO WORLD", debug)
> +iasl -sa dsdt.dsl
> +# Add the raw ACPI tables to an uncompressed cpio archive.
> +# They must be put into a /kernel/firmware/acpi directory inside the
> +# cpio archive.
> +# The uncompressed cpio archive must be the first.
> +# Other, typically compressed cpio archives, must be
> +# concatenated on top of the 

sched: per-entity load-tracking

[Paul Turner]

Hi all,

I've refreshed the load-tracking branch at:
http://git.kernel.org/?p=linux/kernel/git/pjt/sched.git;a=summary
With the latest rebased version.  Similar I've got a quilt export
below to make it easier for people to patch in.

If you prefer raw patches there's a quilt series at:
  http://rs5.risingnet.net/~pjt/patches/load_tracking/

And a tar-ball at:
  http://rs5.risingnet.net/~pjt/patches/load_tracking/series.tar.gz

There are no functional differences from the version posted at:
  https://lkml.org/lkml/2012/8/23/267
So I won't bother posting the series again here.  If you have find
errors, please post them there and I'll do another round.

Similarly, if you previously pulled from my git tree above; the only
difference is that it's been re-written to current tip head, and that
the generator for the fixed-point math constants have been added to
the changelogs.

Thanks!

- 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: [PATCH v3 06/16] memcg: infrastructure to match an allocation to the right cache

[Tejun Heo]

Missed some stuff.

On Tue, Sep 18, 2012 at 06:12:00PM +0400, Glauber Costa wrote:
> +static struct kmem_cache *memcg_create_kmem_cache(struct mem_cgroup *memcg,
> +   struct kmem_cache *cachep)
> +{
...
> + memcg->slabs[idx] = new_cachep;
...
> +struct kmem_cache *__memcg_kmem_get_cache(struct kmem_cache *cachep,
> +   gfp_t gfp)
> +{
...
> + return memcg->slabs[idx];

I think you need memory barriers for the above pair.

Thanks.

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