RE: [PATCHv4 1/4] modem_shm: Add Modem Access Framework

[Arun MURTHY]

> On Fri, Sep 28, 2012 at 01:35:01PM +0530, Arun Murthy wrote:
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +static struct class *modem_class;
> 
> What's wrong with a bus_type instead?

Can I know the advantage of using bus_type over class?

> 
> > +static int __modem_is_requested(struct device *dev, void *data) {
> > +   struct modem_desc *mdesc = (struct modem_desc *)data;
> > +
> > +   if (!mdesc->mclients) {
> > +   printk(KERN_ERR "modem_access: modem description is
> NULL\n");
> > +   return 0;
> > +   }
> > +   return atomic_read(>mclients->cnt);
> > +}
> > +
> > +int modem_is_requested(struct modem_desc *mdesc) {
> > +   return class_for_each_device(modem_class, NULL, (void *)mdesc,
> > +__modem_is_requested); }
> 
> Where is the documentation for your public api functions like this?

Sure will include this in the next patchset.

> 
> > +
> > +int modem_release(struct modem_desc *mdesc) {
> > +   if (!mdesc->release)
> > +   return -EFAULT;
> > +
> > +   if (modem_is_requested(mdesc)) {
> > +   atomic_dec(>mclients->cnt);
> > +   if (atomic_read(>use_cnt) == 1) {
> > +   mdesc->release(mdesc);
> > +   atomic_dec(>use_cnt);
> > +   }
> 
> Eeek, why aren't you using the built-in reference counting that the struct
> device provided to you, and instead are rolling your own?  This happens in
> many places, why?

My usage of counters over here is for each modem there are many clients.
Each of the clients will have a ref to modem_desc. Each of them use this for
requesting and releasing the modem. One counter for tracking the request
and release for each client which is done by variable 'cnt' in struct clients.
The counter use_cnt is used for tracking the modem request/release irrespective
of the clients and counter cli_cnt is used for restricting the modem_get to
the no of clients defined in no_clients.

So totally 3 counter one for restricting the usage of modem_get by clients,
second for restricting modem request/release at top level, and 3rd for
restricting modem release/request for per client per modem basis.

Can you let me know if the same can be achieved by using built-in ref
counting?

Thanks and Regards,
Arun R Murthy
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] usb: dwc3: core: add dt support for dwc3 core

[ABRAHAM, KISHON VIJAY]

Hi,

On Sun, Sep 30, 2012 at 10:17 PM, Sergei Shtylyov  wrote:
> Hello.
>
>
> On 28-09-2012 14:53, Kishon Vijay Abraham I wrote:
>
>> Added dwc3 support for dwc3 core and update the documentation with
>> device tree binding information.
>>
>> Signed-off-by: Kishon Vijay Abraham I
>
> [...]
>
>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 08a5738..0c17a7a 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>
> [...]
>
>> @@ -602,11 +601,22 @@ static int __devexit dwc3_remove(struct
>> platform_device *pdev)
>> return 0;
>>   }
>>
>> +#ifdef CONFIG_OF
>> +static const struct of_device_id of_dwc3_matach[] = {
>
>
> I guess you meant 'of_dwc3_match' here and below?

indeed.. will re-post the patch..

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

Re: [PATCH] Fix userspace compilation of ip_tables.h/ip6_tables.h in C++ mode

[David Miller]

From: Jason Gunthorpe 
Date: Sun, 30 Sep 2012 17:17:37 -0600

> The implicit cast from void * is not allowed for C++ compilers, and the
> arithmetic on void * generates warnings in C++ mode.
> 
> $ g++ -c t.cc
> ip_tables.h:221:24: warning: pointer of type 'void *' used in arithmetic
> ip_tables.h:221:24: error: invalid conversion from 'void*' to 
> 'xt_entry_target*'
> 
> Signed-off-by: Jason Gunthorpe 

Please post netfilter patches to netfilter-de...@vger.kernel.org

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

Re: [RFC v9 PATCH 00/21] memory-hotplug: hot-remove physical memory

[Yasuaki Ishimatsu]

Hi Chen,

2012/09/29 17:19, Ni zhan Chen wrote:

On 09/05/2012 05:25 PM, we...@cn.fujitsu.com wrote:

From: Wen Congyang 

This patch series aims to support physical memory hot-remove.

The patches can free/remove the following things:

   - acpi_memory_info  : [RFC PATCH 4/19]
   - /sys/firmware/memmap/X/{end, start, type} : [RFC PATCH 8/19]
   - iomem_resource: [RFC PATCH 9/19]
   - mem_section and related sysfs files   : [RFC PATCH 10-11, 13-16/19]
   - page table of removed memory  : [RFC PATCH 12/19]
   - node and related sysfs files  : [RFC PATCH 18-19/19]

If you find lack of function for physical memory hot-remove, please let me
know.

How to test this patchset?
1. apply this patchset and build the kernel. MEMORY_HOTPLUG, MEMORY_HOTREMOVE,
ACPI_HOTPLUG_MEMORY must be selected.
2. load the module acpi_memhotplug


Hi Yasuaki,

where is the acpi_memhotplug module?


If you build acpi_memhotplug as module, it is created under
/lib/modules//driver/acpi/ directory. It depends
on config ACPI_HOTPLUG_MEMORY. The confing is [*], it becomes built-in
function. So you don't need to care about it.  


Thanks,
Yasuaki Ishimatsu




3. hotplug the memory device(it depends on your hardware)
You will see the memory device under the directory /sys/bus/acpi/devices/.
Its name is PNP0C80:XX.
4. online/offline pages provided by this memory device
You can write online/offline to /sys/devices/system/memory/memoryX/state to
online/offline pages provided by this memory device
5. hotremove the memory device
You can hotremove the memory device by the hardware, or writing 1 to
/sys/bus/acpi/devices/PNP0C80:XX/eject.

Note: if the memory provided by the memory device is used by the kernel, it
can't be offlined. It is not a bug.

Known problems:
1. memory can't be offlined when CONFIG_MEMCG is selected.
For example: there is a memory device on node 1. The address range
is [1G, 1.5G). You will find 4 new directories memory8, memory9, memory10,
and memory11 under the directory /sys/devices/system/memory/.
If CONFIG_MEMCG is selected, we will allocate memory to store page cgroup
when we online pages. When we online memory8, the memory stored page cgroup
is not provided by this memory device. But when we online memory9, the 
memory
stored page cgroup may be provided by memory8. So we can't offline memory8
now. We should offline the memory in the reversed order.
When the memory device is hotremoved, we will auto offline memory provided
by this memory device. But we don't know which memory is onlined first, so
offlining memory may fail. In such case, you should offline the memory by
hand before hotremoving the memory device.
2. hotremoving memory device may cause kernel panicked
This bug will be fixed by Liu Jiang's patch:
https://lkml.org/lkml/2012/7/3/1

change log of v9:
  [RFC PATCH v9 8/21]
* add a lock to protect the list map_entries
* add an indicator to firmware_map_entry to remember whether the memory
  is allocated from bootmem
  [RFC PATCH v9 10/21]
* change the macro to inline function
  [RFC PATCH v9 19/21]
* don't offline the node if the cpu on the node is onlined
  [RFC PATCH v9 21/21]
* create new patch: auto offline page_cgroup when onlining memory block
  failed

change log of v8:
  [RFC PATCH v8 17/20]
* Fix problems when one node's range include the other nodes
  [RFC PATCH v8 18/20]
* fix building error when CONFIG_MEMORY_HOTPLUG_SPARSE or CONFIG_HUGETLBFS
  is not defined.
  [RFC PATCH v8 19/20]
* don't offline node when some memory sections are not removed
  [RFC PATCH v8 20/20]
* create new patch: clear hwpoisoned flag when onlining pages

change log of v7:
  [RFC PATCH v7 4/19]
* do not continue if acpi_memory_device_remove_memory() fails.
  [RFC PATCH v7 15/19]
* handle usemap in register_page_bootmem_info_section() too.

change log of v6:
  [RFC PATCH v6 12/19]
* fix building error on other archtitectures than x86

  [RFC PATCH v6 15-16/19]
* fix building error on other archtitectures than x86

change log of v5:
  * merge the patchset to clear page table and the patchset to hot remove
memory(from ishimatsu) to one big patchset.

  [RFC PATCH v5 1/19]
* rename remove_memory() to offline_memory()/offline_pages()

  [RFC PATCH v5 2/19]
* new patch: implement offline_memory(). This function offlines pages,
  update memory block's state, and notify the userspace that the memory
  block's state is changed.

  [RFC PATCH v5 4/19]
* offline and remove memory in acpi_memory_disable_device() too.

  [RFC PATCH v5 17/19]
* new patch: add a new function __remove_zone() to revert the things done
  in the function __add_zone().

  [RFC PATCH v5 18/19]
* flush work befor reseting node device.

change log of v4:
  * remove "memory-hotplug : unify argument of 

Re: CONFIG_EXPERT is a booby trap

[Tim Shepard]

Interestingly, of the 26 configs that use EXPERT in the default
clause, 15 of them are in drivers/hid (see below).

-Tim Shepard
 s...@alum.mit.edu

 - -  - -  - -  - -  - -  - -  - -  - -  - -  - -  - -  - -  - -  - - 

$ find . -type f -name Kconfig'*' -print | xargs fgrep default | grep EXPERT 
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/media/common/tuners/Kconfig:  default y if !EXPERT
./drivers/media/common/tuners/Kconfig:  default y if EXPERT
./drivers/media/dvb/frontends/Kconfig:  default y if EXPERT
./drivers/media/video/Kconfig:  default y if !EXPERT
./init/Kconfig: default !EXPERT
./lib/Kconfig.debug:default !EXPERT
./net/rfkill/Kconfig:   default y if !EXPERT
./usr/Kconfig:  default !EXPERT
./usr/Kconfig:  default !EXPERT
./usr/Kconfig:  default !EXPERT
./usr/Kconfig:  default !EXPERT
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi Ralf,

Today's linux-next merge of the mips tree got a conflict in
drivers/net/ethernet/octeon/octeon_mgmt.c between commit df555b665367
("netdev: octeon: fix return value check in octeon_mgmt_init_phy()") from
Linus' tree and commit eeae05aa2169 ("netdev: octeon_mgmt: Add support
for 1Gig ports") from the mips tree.

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

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

diff --cc drivers/net/ethernet/octeon/octeon_mgmt.c
index a688a2d,5be431c..000
--- a/drivers/net/ethernet/octeon/octeon_mgmt.c
+++ b/drivers/net/ethernet/octeon/octeon_mgmt.c
@@@ -722,10 -973,8 +973,8 @@@ static int octeon_mgmt_init_phy(struct 
   octeon_mgmt_adjust_link, 0,
   PHY_INTERFACE_MODE_MII);
  
 -  if (p->phydev == NULL)
 +  if (!p->phydev)
-   return -1;
- 
-   phy_start_aneg(p->phydev);
+   return -ENODEV;
  
return 0;
  }


pgph4DfS6X0ge.pgp
Description: PGP signature

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

[Stephen Rothwell]

Hi Chris,

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

fs/btrfs/disk-io.c:34:28: fatal error: asm/cpufeature.h: No such file or 
directory

Caused by commit 2fcfff234500 ("Btrfs: do not async metadata csumming in
certain situations").  Only x86 has asm/cupfeature.h

I have dropped the btrfs tree for today.  This is exactly why your tree
should have been in linux-next some time ago ... :-(
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp8vrchIqEpp.pgp
Description: PGP signature

linux-next: import of the device-mapper series failed

[Stephen Rothwell]

Hi Alasdair,

Trying to import the device-mapper series produce this error:

$ git am 
../quilt/device-mapper/dm-thin-support-discard-with-non-power-of-two-block-size.patch
Applying: Support discards when the pool's block size is not a power of 2.
error: patch failed: drivers/md/dm-thin.c:2762
error: drivers/md/dm-thin.c: patch does not apply

and indeed the code in question is very different from what the patch
expects.  Is there a missing patch?

I dropped that patch and the following
dm-thin-move-bio_prison-code-to-separate-module.patch that also did not
apply.

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


pgpWvJr0WcGdc.pgp
Description: PGP signature

Re: [PATCH V2 3/3] workqueue: Schedule work on non-idle cpu instead of current one

[Viresh Kumar]

On 1 October 2012 06:02, Tejun Heo  wrote:
> It isn't about the CPU being actually idle?

No. Being idle only from scheduler's perspective. :)

> Also, if it's only about timers, shouldn't it be enough to implement
> it for timer and delayed_work?

What if we need a timer, which must re-arm itself + schedule a work?
delayed_work will not be sufficient in that case, and we would need
to use normal work.

If i am not wrong, there can be other future users of this routine too.
@Vincent: Can you please comment on this?

> It would be great if you explain what you're trying to achieve how.  I
> can't tell what you're aiming for and why that would be beneficial
> from these submissions.

Following slides are implemented by Vincent and presented during LPC.
Please have a look at them, they explain the problem statement well:

http://www.linuxplumbersconf.org/2012/wp-content/uploads/2012/08/lpc2012-sched-timer-workqueue.pdf

Specifically slides: 12 & 19.

There aren't too many users with this behavior, but even a single user
will be sufficient not to let the cpu get idle at all. And that will result in
less power saving.

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

[tip:x86/acpi] ACPI: Document ACPI table overriding via initrd

[tip-bot for Thomas Renninger]

Commit-ID:  8347bbecf3518aa1518f6157e661812a35775130
Gitweb: http://git.kernel.org/tip/8347bbecf3518aa1518f6157e661812a35775130
Author: Thomas Renninger 
AuthorDate: Mon, 1 Oct 2012 00:23:57 +0200
Committer:  H. Peter Anvin 
CommitDate: Sun, 30 Sep 2012 18:03:41 -0700

ACPI: Document ACPI table overriding via initrd

Signed-off-by: Thomas Renninger 
Link: http://lkml.kernel.org/r/1349043837-22659-7-git-send-email-tr...@suse.de
Cc: Len Brown 
Cc: Robert Moore 
Cc: Yinghai Lu 
Cc: Eric Piel 
Signed-off-by: H. Peter Anvin 
---
 Documentation/acpi/initrd_table_override.txt |   94 ++
 1 files changed, 94 insertions(+), 0 deletions(-)

diff --git a/Documentation/acpi/initrd_table_override.txt 
b/Documentation/acpi/initrd_table_override.txt
new file mode 100644
index 000..35c3f54
--- /dev/null
+++ b/Documentation/acpi/initrd_table_override.txt
@@ -0,0 +1,94 @@
+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 the 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 so sever
+that a workaround is not accepted in the Linux 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.
+
+
+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 uncompressed one.
+mkdir -p kernel/firmware/acpi
+cp dsdt.aml kernel/firmware/acpi
+# A maximum of: #define ACPI_OVERRIDE_TABLES 10
+# tables are  currently allowed (see osl.c):
+iasl -sa facp.dsl
+iasl -sa ssdt1.dsl
+cp facp.aml kernel/firmware/acpi
+cp ssdt1.aml kernel/firmware/acpi
+# Create the uncompressed cpio archive and concatenate the original initrd
+# on top:
+find kernel | cpio -H newc --create > /boot/instrumented_initrd
+cat /boot/initrd >>/boot/instrumented_initrd
+# reboot with increased acpi debug level, e.g. boot params:
+acpi.debug_level=0x2 acpi.debug_layer=0x
+# and check your syslog:
+[1.268089] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
+[1.272091] [ACPI Debug]  String [0x0B] "HELLO WORLD"
+
+iasl is able to disassemble and recompile quite a lot different,
+also static ACPI tables.
+
+
+4) Where to retrieve userspace tools
+
+
+iasl and acpixtract are part of Intel's ACPICA project:
+http://acpica.org/
+and should be packaged by distributions (for example in the acpica package
+on SUSE).
+
+acpidump can be found in Len Browns pmtools:
+ftp://kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools/acpidump
+This tool is also part of the acpica package on SUSE.
+Alternatively, used ACPI tables can be retrieved via sysfs in latest kernels:
+/sys/firmware/acpi/tables
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/acpi] ACPI: Create acpi_table_taint() function to avoid code duplication

[tip-bot for Thomas Renninger]

Commit-ID:  325a8d36035f0623950e38e9cf7a47a48e72df11
Gitweb: http://git.kernel.org/tip/325a8d36035f0623950e38e9cf7a47a48e72df11
Author: Thomas Renninger 
AuthorDate: Mon, 1 Oct 2012 00:23:56 +0200
Committer:  H. Peter Anvin 
CommitDate: Sun, 30 Sep 2012 18:03:35 -0700

ACPI: Create acpi_table_taint() function to avoid code duplication

There are two ways of overriding ACPI tables now, both need to taint the
the kernel.

Signed-off-by: Thomas Renninger 
Link: http://lkml.kernel.org/r/1349043837-22659-6-git-send-email-tr...@suse.de
Cc: Len Brown 
Cc: Robert Moore 
Cc: Yinghai Lu 
Cc: Eric Piel 
Signed-off-by: H. Peter Anvin 
---
 drivers/acpi/osl.c |   20 +---
 1 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 007224b..a2845ff 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -656,6 +656,15 @@ void __init acpi_initrd_override(void *data, size_t size)
 }
 #endif /* CONFIG_ACPI_INITRD_TABLE_OVERRIDE */
 
+static void acpi_table_taint(struct acpi_table_header *table)
+{
+   pr_warn(PREFIX
+   "Override [%4.4s-%8.8s], this is unsafe: tainting kernel\n",
+   table->signature, table->oem_table_id);
+   add_taint(TAINT_OVERRIDDEN_ACPI_TABLE);
+}
+
+
 acpi_status
 acpi_os_table_override(struct acpi_table_header * existing_table,
   struct acpi_table_header ** new_table)
@@ -669,13 +678,8 @@ acpi_os_table_override(struct acpi_table_header * 
existing_table,
if (strncmp(existing_table->signature, "DSDT", 4) == 0)
*new_table = (struct acpi_table_header *)AmlCode;
 #endif
-   if (*new_table != NULL) {
-   printk(KERN_WARNING PREFIX "Override [%4.4s-%8.8s], "
-  "this is unsafe: tainting kernel\n",
-  existing_table->signature,
-  existing_table->oem_table_id);
-   add_taint(TAINT_OVERRIDDEN_ACPI_TABLE);
-   }
+   if (*new_table != NULL)
+   acpi_table_taint(existing_table);
return AE_OK;
 }
 
@@ -736,6 +740,8 @@ acpi_os_physical_table_override(struct acpi_table_header 
*existing_table,
break;
} while (table_offset + ACPI_HEADER_SIZE < all_tables_size);
 
+   if (*address != 0)
+   acpi_table_taint(existing_table);
return AE_OK;
 #endif
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/acpi] ACPI: Implement physical address table override

[tip-bot for Thomas Renninger]

Commit-ID:  b2a35003dfbcc7b7a5e5c6e524e7d49ba66e0bb5
Gitweb: http://git.kernel.org/tip/b2a35003dfbcc7b7a5e5c6e524e7d49ba66e0bb5
Author: Thomas Renninger 
AuthorDate: Mon, 1 Oct 2012 00:23:55 +0200
Committer:  H. Peter Anvin 
CommitDate: Sun, 30 Sep 2012 18:03:29 -0700

ACPI: Implement physical address table override

Previous patches stored ACPI tables provided via initrd in a memblock reserved
area.
If a table is loaded and the table type of an initrd provided one matches,
the one from initrd is prefered.
In case of a SSDT table, the OEM table id also has to match.

ACPI tables can be loaded at boot time (static table pointers in XSDT),
but also dynamically any time later via ASL commands load() or loadTable().
The override mechanism always works.

Signed-off-by: Thomas Renninger 
Link: http://lkml.kernel.org/r/1349043837-22659-5-git-send-email-tr...@suse.de
Cc: Len Brown 
Cc: Robert Moore 
Cc: Yinghai Lu 
Cc: Eric Piel 
Signed-off-by: H. Peter Anvin 
---
 drivers/acpi/osl.c |   60 ---
 1 files changed, 56 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index b20b079..007224b 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -681,12 +681,64 @@ acpi_os_table_override(struct acpi_table_header * 
existing_table,
 
 acpi_status
 acpi_os_physical_table_override(struct acpi_table_header *existing_table,
-   acpi_physical_address * new_address,
-   u32 *new_table_length)
+   acpi_physical_address *address,
+   u32 *table_length)
 {
-   return AE_SUPPORT;
-}
+#ifndef CONFIG_ACPI_INITRD_TABLE_OVERRIDE
+   *table_length = 0;
+   *address = 0;
+   return AE_OK;
+#else
+   int table_offset = 0;
+   struct acpi_table_header *table;
+
+   *table_length = 0;
+   *address = 0;
+
+   if (!acpi_tables_addr)
+   return AE_OK;
+
+   do {
+   if (table_offset + ACPI_HEADER_SIZE > all_tables_size) {
+   WARN_ON(1);
+   return AE_OK;
+   }
+
+   table = acpi_os_map_memory(acpi_tables_addr + table_offset,
+  ACPI_HEADER_SIZE);
+
+   if (table_offset + table->length > all_tables_size) {
+   acpi_os_unmap_memory(table, ACPI_HEADER_SIZE);
+   WARN_ON(1);
+   return AE_OK;
+   }
 
+   table_offset += table->length;
+
+   if (memcmp(existing_table->signature, table->signature, 4)) {
+   acpi_os_unmap_memory(table,
+ACPI_HEADER_SIZE);
+   continue;
+   }
+
+   /* Only override tables with matching oem id */
+   if (memcmp(table->oem_table_id, existing_table->oem_table_id,
+  ACPI_OEM_TABLE_ID_SIZE)) {
+   acpi_os_unmap_memory(table,
+ACPI_HEADER_SIZE);
+   continue;
+   }
+
+   table_offset -= table->length;
+   *table_length = table->length;
+   acpi_os_unmap_memory(table, ACPI_HEADER_SIZE);
+   *address = acpi_tables_addr + table_offset;
+   break;
+   } while (table_offset + ACPI_HEADER_SIZE < all_tables_size);
+
+   return AE_OK;
+#endif
+}
 
 static irqreturn_t acpi_irq(int irq, void *dev_id)
 {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/acpi] ACPI: Store valid ACPI tables passed via early initrd in reserved memblock areas

[tip-bot for Thomas Renninger]

Commit-ID:  53aac44c904abbad9f474f652f099de13b5c3563
Gitweb: http://git.kernel.org/tip/53aac44c904abbad9f474f652f099de13b5c3563
Author: Thomas Renninger 
AuthorDate: Mon, 1 Oct 2012 00:23:54 +0200
Committer:  H. Peter Anvin 
CommitDate: Sun, 30 Sep 2012 18:03:23 -0700

ACPI: Store valid ACPI tables passed via early initrd in reserved memblock areas

A later patch will compare them with ACPI tables that get loaded at boot or
runtime and if criteria match, a stored one is loaded.

Signed-off-by: Thomas Renninger 
Link: http://lkml.kernel.org/r/1349043837-22659-4-git-send-email-tr...@suse.de
Cc: Len Brown 
Cc: Robert Moore 
Cc: Yinghai Lu 
Cc: Eric Piel 
Signed-off-by: H. Peter Anvin 
---
 arch/x86/kernel/setup.c |2 +
 drivers/acpi/Kconfig|9 
 drivers/acpi/osl.c  |  122 +++
 include/linux/acpi.h|8 +++
 4 files changed, 141 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index f4b9b80..764e543 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -941,6 +941,8 @@ void __init setup_arch(char **cmdline_p)
 
reserve_initrd();
 
+   acpi_initrd_override((void *)initrd_start, initrd_end - initrd_start);
+
reserve_crashkernel();
 
vsmp_init();
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 8099895..8cf7195 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -261,6 +261,15 @@ config ACPI_CUSTOM_DSDT
bool
default ACPI_CUSTOM_DSDT_FILE != ""
 
+config ACPI_INITRD_TABLE_OVERRIDE
+   bool "ACPI tables can be passed via uncompressed cpio in initrd"
+   default n
+   help
+ This option provides functionality to override arbitrary ACPI tables
+ via initrd. No functional change if no ACPI tables are passed via
+ initrd, therefore it's safe to say Y.
+ See Documentation/acpi/initrd_table_override.txt for details
+
 config ACPI_BLACKLIST_YEAR
int "Disable ACPI for systems before Jan 1st this year" if X86_32
default 0
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 9eaf708..b20b079 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -534,6 +534,128 @@ acpi_os_predefined_override(const struct 
acpi_predefined_names *init_val,
return AE_OK;
 }
 
+#ifdef CONFIG_ACPI_INITRD_TABLE_OVERRIDE
+#include 
+#include 
+
+static u64 acpi_tables_addr;
+static int all_tables_size;
+
+/* Copied from acpica/tbutils.c:acpi_tb_checksum() */
+u8 __init acpi_table_checksum(u8 *buffer, u32 length)
+{
+   u8 sum = 0;
+   u8 *end = buffer + length;
+
+   while (buffer < end)
+   sum = (u8) (sum + *(buffer++));
+   return sum;
+}
+
+/* All but ACPI_SIG_RSDP and ACPI_SIG_FACS: */
+static const char * const table_sigs[] = {
+   ACPI_SIG_BERT, ACPI_SIG_CPEP, ACPI_SIG_ECDT, ACPI_SIG_EINJ,
+   ACPI_SIG_ERST, ACPI_SIG_HEST, ACPI_SIG_MADT, ACPI_SIG_MSCT,
+   ACPI_SIG_SBST, ACPI_SIG_SLIT, ACPI_SIG_SRAT, ACPI_SIG_ASF,
+   ACPI_SIG_BOOT, ACPI_SIG_DBGP, ACPI_SIG_DMAR, ACPI_SIG_HPET,
+   ACPI_SIG_IBFT, ACPI_SIG_IVRS, ACPI_SIG_MCFG, ACPI_SIG_MCHI,
+   ACPI_SIG_SLIC, ACPI_SIG_SPCR, ACPI_SIG_SPMI, ACPI_SIG_TCPA,
+   ACPI_SIG_UEFI, ACPI_SIG_WAET, ACPI_SIG_WDAT, ACPI_SIG_WDDT,
+   ACPI_SIG_WDRT, ACPI_SIG_DSDT, ACPI_SIG_FADT, ACPI_SIG_PSDT,
+   ACPI_SIG_RSDT, ACPI_SIG_XSDT, ACPI_SIG_SSDT, NULL };
+
+/* Non-fatal errors: Affected tables/files are ignored */
+#define INVALID_TABLE(x, path, name)   \
+   { pr_err("ACPI OVERRIDE: " x " [%s%s]\n", path, name); continue; }
+
+#define ACPI_HEADER_SIZE sizeof(struct acpi_table_header)
+
+/* Must not increase 10 or needs code modification below */
+#define ACPI_OVERRIDE_TABLES 10
+
+void __init acpi_initrd_override(void *data, size_t size)
+{
+   int sig, no, table_nr = 0, total_offset = 0;
+   long offset = 0;
+   struct acpi_table_header *table;
+   char cpio_path[32] = "kernel/firmware/acpi/";
+   struct cpio_data file;
+   struct cpio_data early_initrd_files[ACPI_OVERRIDE_TABLES];
+   char *p;
+
+   if (data == NULL || size == 0)
+   return;
+
+   for (no = 0; no < ACPI_OVERRIDE_TABLES; no++) {
+   file = find_cpio_data(cpio_path, data, size, );
+   if (!file.data)
+   break;
+
+   data += offset;
+   size -= offset;
+
+   if (file.size < sizeof(struct acpi_table_header))
+   INVALID_TABLE("Table smaller than ACPI header",
+ cpio_path, file.name);
+
+   table = file.data;
+
+   for (sig = 0; table_sigs[sig]; sig++)
+   if (!memcmp(table->signature, table_sigs[sig], 4))
+   break;
+
+   if (!table_sigs[sig])
+   INVALID_TABLE("Unknown signature",
+  

[tip:x86/acpi] lib: Add early cpio decoder

[tip-bot for H. Peter Anvin]

Commit-ID:  e6459606b04e6385ccd3c2060fc10f78a92c7700
Gitweb: http://git.kernel.org/tip/e6459606b04e6385ccd3c2060fc10f78a92c7700
Author: H. Peter Anvin 
AuthorDate: Mon, 1 Oct 2012 00:23:52 +0200
Committer:  H. Peter Anvin 
CommitDate: Sun, 30 Sep 2012 18:02:20 -0700

lib: Add early cpio decoder

Add a simple cpio decoder without library dependencies for the purpose
of extracting components from the initramfs blob for early kernel
uses.  Intended consumers so far are microcode and ACPI override.

Signed-off-by: H. Peter Anvin 
Link: http://lkml.kernel.org/r/1349043837-22659-2-git-send-email-tr...@suse.de
Cc: Len Brown 
Cc: Fenghua Yu 
Signed-off-by: Thomas Renninger 
Signed-off-by: H. Peter Anvin 
---
 include/linux/earlycpio.h |   17 +
 lib/Makefile  |2 +-
 lib/earlycpio.c   |  145 +
 3 files changed, 163 insertions(+), 1 deletions(-)

diff --git a/include/linux/earlycpio.h b/include/linux/earlycpio.h
new file mode 100644
index 000..111f46d
--- /dev/null
+++ b/include/linux/earlycpio.h
@@ -0,0 +1,17 @@
+#ifndef _LINUX_EARLYCPIO_H
+#define _LINUX_EARLYCPIO_H
+
+#include 
+
+#define MAX_CPIO_FILE_NAME 18
+
+struct cpio_data {
+   void *data;
+   size_t size;
+   char name[MAX_CPIO_FILE_NAME];
+};
+
+struct cpio_data find_cpio_data(const char *path, void *data, size_t len,
+   long *offset);
+
+#endif /* _LINUX_EARLYCPIO_H */
diff --git a/lib/Makefile b/lib/Makefile
index 42d283e..0924041 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -12,7 +12,7 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \
 idr.o int_sqrt.o extable.o prio_tree.o \
 sha1.o md5.o irq_regs.o reciprocal_div.o argv_split.o \
 proportions.o flex_proportions.o prio_heap.o ratelimit.o show_mem.o \
-is_single_threaded.o plist.o decompress.o
+is_single_threaded.o plist.o decompress.o earlycpio.o
 
 lib-$(CONFIG_MMU) += ioremap.o
 lib-$(CONFIG_SMP) += cpumask.o
diff --git a/lib/earlycpio.c b/lib/earlycpio.c
new file mode 100644
index 000..8078ef4
--- /dev/null
+++ b/lib/earlycpio.c
@@ -0,0 +1,145 @@
+/* --- *
+ *
+ *   Copyright 2012 Intel Corporation; author H. Peter Anvin
+ *
+ *   This file is part of the Linux kernel, and is made available
+ *   under the terms of the GNU General Public License version 2, as
+ *   published by the Free Software Foundation.
+ *
+ *   This program is distributed in the hope 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.
+ *
+ * --- */
+
+/*
+ * earlycpio.c
+ *
+ * Find a specific cpio member; must precede any compressed content.
+ * This is used to locate data items in the initramfs used by the
+ * kernel itself during early boot (before the main initramfs is
+ * decompressed.)  It is the responsibility of the initramfs creator
+ * to ensure that these items are uncompressed at the head of the
+ * blob.  Depending on the boot loader or package tool that may be a
+ * separate file or part of the same file.
+ */
+
+#include 
+#include 
+#include 
+
+enum cpio_fields {
+   C_MAGIC,
+   C_INO,
+   C_MODE,
+   C_UID,
+   C_GID,
+   C_NLINK,
+   C_MTIME,
+   C_FILESIZE,
+   C_MAJ,
+   C_MIN,
+   C_RMAJ,
+   C_RMIN,
+   C_NAMESIZE,
+   C_CHKSUM,
+   C_NFIELDS
+};
+
+/**
+ * cpio_data find_cpio_data - Search for files in an uncompressed cpio
+ * @path:   The directory to search for, including a slash at the end
+ * @data:   Pointer to the the cpio archive or a header inside
+ * @len:Remaining length of the cpio based on data pointer
+ * @offset: When a matching file is found, this is the offset to the
+ *  beginning of the cpio. It can be used to iterate through
+ *  the cpio to find all files inside of a directory path
+ *
+ * @return: struct cpio_data containing the address, length and
+ *  filename (with the directory path cut off) of the found file.
+ *  If you search for a filename and not for files in a directory,
+ *  pass the absolute path of the filename in the cpio and make sure
+ *  the match returned an empty filename string.
+ */
+
+struct cpio_data __cpuinit find_cpio_data(const char *path, void *data,
+ size_t len,  long *offset)
+{
+   const size_t cpio_header_len = 8*C_NFIELDS - 2;
+   struct cpio_data cd = { NULL, 0, "" };
+   const char *p, *dptr, *nptr;
+   unsigned int ch[C_NFIELDS], *chp, v;
+   unsigned char c, x;
+   size_t mypathsize = strlen(path);
+   int i, j;
+
+   p = data;
+
+   while (len > cpio_header_len) {
+   if (!*p) {
+ 

Re: CONFIG_EXPERT is a booby trap

[Randy Dunlap]

On 09/30/2012 07:21 PM, Tim Shepard wrote:

> A month or two ago when I attempted to upgrade from 3.4 to 3.5 on my
> MacBook Pro laptop, in preparation to try an interesting patch to TCP
> developed against 3.5 by a colleague, my keyboard stopped working.  I
> tried bisecting, but that lead to nowhere useful and much confusion.
> 
> 
> It turns out that while I was looking for some debug options under
> "General setup" and "Kernel hacking", I turned on "Configure standard
> kernel features (expert users)" which is also known as CONFIG_EXPERT.
> I read the documentation for that option, and I perused the options
> which appeared underneath when it was turned on, thought to myself "oh,
> hmm, I don't want to change any of these" and wandered off and
> eventually found what I was actually looking for elsewhere in the
> kernel configuration tree.
> 
> This weekend I finally figured out why the keyboard in my MacBook Pro
> stopped working between 3.4 and 3.5.
> 
> When I turned on CONFIG_EXPERT it turned off CONFIG_HID_APPLE.  There
> was no warning that selecting "Configure standard kernel features" will
> invisibly turn off needed things elsewhere in the configuration tree.
> 
> Something needs to be fixed, but it's not obvious that any simple change
> will work without causing other troubles.
> 
> I've read some of the lkml history history and learned that references
> to CONFIG_EXPERT (like the one on CONFIG_HID_APPLE) used to be
> references to CONFIG_EMBEDDED, so CONFIG_EXPERT used to mean something
> else.
> 
> Maybe "make menuconfig" should show you all the things that you've just
> changed and ask for confirmation when changing one configuration option
> causes actual configuration changes elsewhere in the tree.
> 
> And may I suggest that CONFIG_EXPERT should be factored into two
> CONFIGs, one of which makes configuration things visible, and another
> which changes the default values to something more appropriate for
> embedded systems (perhaps call it CONFIG_EMBEDDED_DEFAULTS).  That way
> you'd have to select CONFIG_EXPERT, and then select the
> CONFIG_EMBEDDED_DEFAULTS option that CONFIG_EXPERT made visible to
> actually change any configuration, and the documentation for
> CONFIG_EMBEDDED_DEFAULTS could explain that it changes defaults
> throughout the tree (and selecting CONFIG_EXPERT alone would not go off
> and muck things up with no warning).
> 
> The transition plan such a factoring needs some further thought to avoid
> breaking anyone's current configuration when they "make oldconfig".


I don't disagree with you that it can be a problem, but
the help text for CONFIG_EXPERT does say:

Only use this if you really know what you are doing.


Anyway, the hid drivers are certainly a big user of this mechanism.
Many of them are like HID_APPLE:

config HID_APPLE
tristate "Apple {i,Power,Mac}Books" if EXPERT
depends on (USB_HID || BT_HIDP)
default !EXPERT


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

Re: [RFC v9 PATCH 13/21] memory-hotplug: check page type in get_page_bootmem

[Yasuaki Ishimatsu]

Hi Chen,

2012/09/29 11:15, Ni zhan Chen wrote:

On 09/05/2012 05:25 PM, we...@cn.fujitsu.com wrote:

From: Yasuaki Ishimatsu 

The function get_page_bootmem() may be called more than one time to the same
page. There is no need to set page's type, private if the function is not
the first time called to the page.

Note: the patch is just optimization and does not fix any problem.


Hi Yasuaki,

this patch is reasonable to me. I have another question associated to 
get_page_bootmem(), the question is from another fujitsu guy's patch changelog 
[commit : 04753278769f3], the changelog said  that:

  1) When the memmap of removing section is allocated on other
  section by bootmem, it should/can be free.
  2) When the memmap of removing section is allocated on the
  same section, it shouldn't be freed. Because the section has to be
  logical memory offlined already and all pages must be isolated against
  page allocater. If it is freed, page allocator may use it which will
  be removed physically soon.

but I don't see his patch guarantee 2), it means that his patch doesn't 
guarantee the memmap of removing section which is allocated on other section by 
bootmem doesn't be freed. Hopefully get your explaination in details, thanks in 
advance. :-)


In my understanding, the patch does not guarantee it.
Please see [commit : 0c0a4a517a31e]. free_map_bootmem() in the commit
guarantees it.

Thanks,
Yasuaki Ishimatsu





CC: David Rientjes 
CC: Jiang Liu 
CC: Len Brown 
CC: Benjamin Herrenschmidt 
CC: Paul Mackerras 
CC: Christoph Lameter 
Cc: Minchan Kim 
CC: Andrew Morton 
CC: KOSAKI Motohiro 
CC: Wen Congyang 
Signed-off-by: Yasuaki Ishimatsu 
---
  mm/memory_hotplug.c |   15 +++
  1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index d736df3..26a5012 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -95,10 +95,17 @@ static void release_memory_resource(struct resource *res)
  static void get_page_bootmem(unsigned long info,  struct page *page,
   unsigned long type)
  {
-page->lru.next = (struct list_head *) type;
-SetPagePrivate(page);
-set_page_private(page, info);
-atomic_inc(>_count);
+unsigned long page_type;
+
+page_type = (unsigned long)page->lru.next;
+if (page_type < MEMORY_HOTPLUG_MIN_BOOTMEM_TYPE ||
+page_type > MEMORY_HOTPLUG_MAX_BOOTMEM_TYPE){
+page->lru.next = (struct list_head *)type;
+SetPagePrivate(page);
+set_page_private(page, info);
+atomic_inc(>_count);
+} else
+atomic_inc(>_count);
  }
  /* reference to __meminit __free_pages_bootmem is valid





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

CONFIG_EXPERT is a booby trap

[Tim Shepard]

A month or two ago when I attempted to upgrade from 3.4 to 3.5 on my
MacBook Pro laptop, in preparation to try an interesting patch to TCP
developed against 3.5 by a colleague, my keyboard stopped working.  I
tried bisecting, but that lead to nowhere useful and much confusion.


It turns out that while I was looking for some debug options under
"General setup" and "Kernel hacking", I turned on "Configure standard
kernel features (expert users)" which is also known as CONFIG_EXPERT.
I read the documentation for that option, and I perused the options
which appeared underneath when it was turned on, thought to myself "oh,
hmm, I don't want to change any of these" and wandered off and
eventually found what I was actually looking for elsewhere in the
kernel configuration tree.

This weekend I finally figured out why the keyboard in my MacBook Pro
stopped working between 3.4 and 3.5.

When I turned on CONFIG_EXPERT it turned off CONFIG_HID_APPLE.  There
was no warning that selecting "Configure standard kernel features" will
invisibly turn off needed things elsewhere in the configuration tree.

Something needs to be fixed, but it's not obvious that any simple change
will work without causing other troubles.

I've read some of the lkml history history and learned that references
to CONFIG_EXPERT (like the one on CONFIG_HID_APPLE) used to be
references to CONFIG_EMBEDDED, so CONFIG_EXPERT used to mean something
else.

Maybe "make menuconfig" should show you all the things that you've just
changed and ask for confirmation when changing one configuration option
causes actual configuration changes elsewhere in the tree.

And may I suggest that CONFIG_EXPERT should be factored into two
CONFIGs, one of which makes configuration things visible, and another
which changes the default values to something more appropriate for
embedded systems (perhaps call it CONFIG_EMBEDDED_DEFAULTS).  That way
you'd have to select CONFIG_EXPERT, and then select the
CONFIG_EMBEDDED_DEFAULTS option that CONFIG_EXPERT made visible to
actually change any configuration, and the documentation for
CONFIG_EMBEDDED_DEFAULTS could explain that it changes defaults
throughout the tree (and selecting CONFIG_EXPERT alone would not go off
and muck things up with no warning).

The transition plan such a factoring needs some further thought to avoid
breaking anyone's current configuration when they "make oldconfig".


-Tim Shepard
 s...@alum.mit.edu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Re: [PATCH -tip 0/3] Move kprobes files under the kprobes directory

[Masami Hiramatsu]

(2012/09/28 21:34), Steven Rostedt wrote:
> On Fri, 2012-09-28 at 17:15 +0900, Masami Hiramatsu wrote:
>> Hi,
>>
>> Here are a series of patches to split ftrace-based kprobe part
>> from arch/x86/kernel/kprobes.c and to move kprobes related
>> files under arch/x86/kernel/kprobes/, according to Ingo's
>> suggestion.
>> https://lkml.org/lkml/2012/9/20/122
>>
> 
> Hi Masami,
> 
> Thanks for sending this. As it is getting very close to the merge
> window, do you feel that his is good enough to push for 3.7, or do you
> think we should hold off till 3.8, and let it brew a while?

Thank you for asking, this is just a kind of cleanup, so I think stable
enough for 3.7. At least, it is better to push this into tip tree
for future works. :)

Thank you again,

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


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

[PATCH -next] bluetooth: fix printk format warnings

[Randy Dunlap]

From: Randy Dunlap 

Fix printk format warnings in net/bluetooth/:

net/bluetooth/hci_event.c:886:3: warning: format '%ld' expects type 'long int', 
but argument 2 has type 'size_t'
net/bluetooth/hci_event.c:886:3: warning: format '%ld' expects type 'long int', 
but argument 3 has type 'size_t'
net/bluetooth/a2mp.c:386:2: warning: format '%lu' expects type 'long unsigned 
int', but argument 4 has type 'unsigned int'

Signed-off-by: Randy Dunlap 
M:  Marcel Holtmann 
M:  Gustavo Padovan 
M:  Johan Hedberg 
L:  linux-blueto...@vger.kernel.org
---
 net/bluetooth/a2mp.c  |2 +-
 net/bluetooth/hci_event.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- linux-next-20120928.orig/net/bluetooth/a2mp.c
+++ linux-next-20120928/net/bluetooth/a2mp.c
@@ -383,7 +383,7 @@ static int a2mp_getampassoc_rsp(struct a
if (len < sizeof(*rsp))
return -EINVAL;
 
-   BT_DBG("id %d status 0x%2.2x assoc len %lu", rsp->id, rsp->status,
+   BT_DBG("id %d status 0x%2.2x assoc len %zu", rsp->id, rsp->status,
   len - sizeof(*rsp));
 
if (rsp->status)
--- linux-next-20120928.orig/net/bluetooth/hci_event.c
+++ linux-next-20120928/net/bluetooth/hci_event.c
@@ -883,7 +883,7 @@ static void hci_cc_read_local_amp_assoc(
rem_len = __le16_to_cpu(rp->rem_len);
 
if (rem_len > frag_len) {
-   BT_DBG("frag_len %ld rem_len %ld", frag_len, rem_len);
+   BT_DBG("frag_len %zu rem_len %zu", frag_len, rem_len);
 
memcpy(assoc->data + assoc->offset, rp->frag, frag_len);
assoc->offset += frag_len;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4] KSM: numa awareness sysfs knob

[Hugh Dickins]

Andrea's point about ksm_migrate_page() is an important one, and I've
answered that against his mail, but here's some other easier points.

On Mon, 24 Sep 2012, Petr Holasek wrote:

> Introduces new sysfs boolean knob /sys/kernel/mm/ksm/merge_across_nodes
> which control merging pages across different numa nodes.
> When it is set to zero only pages from the same node are merged,
> otherwise pages from all nodes can be merged together (default behavior).
> 
> Typical use-case could be a lot of KVM guests on NUMA machine
> and cpus from more distant nodes would have significant increase
> of access latency to the merged ksm page. Sysfs knob was choosen
> for higher variability when some users still prefers higher amount
> of saved physical memory regardless of access latency.
> 
> Every numa node has its own stable & unstable trees because of faster
> searching and inserting. Changing of merge_nodes value is possible only

merge_across_nodes

> when there are not any ksm shared pages in system.
> 
> I've tested this patch on numa machines with 2, 4 and 8 nodes and
> measured speed of memory access inside of KVM guests with memory pinned
> to one of nodes with this benchmark:
> 
> http://pholasek.fedorapeople.org/alloc_pg.c
> 
> Population standard deviations of access times in percentage of average
> were following:
> 
> merge_nodes=1

merge_across_nodes

> 2 nodes 1.4%
> 4 nodes 1.6%
> 8 nodes   1.7%
> 
> merge_nodes=0

merge_across_nodes

> 2 nodes   1%
> 4 nodes   0.32%
> 8 nodes   0.018%
> 
> RFC: https://lkml.org/lkml/2011/11/30/91
> v1: https://lkml.org/lkml/2012/1/23/46
> v2: https://lkml.org/lkml/2012/6/29/105
> v3: https://lkml.org/lkml/2012/9/14/550
> 
> Changelog:
> 
> v2: Andrew's objections were reflected:
>   - value of merge_nodes can't be changed while there are some ksm
>   pages in system
>   - merge_nodes sysfs entry appearance depends on CONFIG_NUMA
>   - more verbose documentation
>   - added some performance testing results
> 
> v3:   - more verbose documentation
>   - fixed race in merge_nodes store function
>   - introduced share_all debugging knob proposed by Andrew
>   - minor cleanups
> 
> v4:   - merge_nodes was renamed to merge_across_nodes
>   - share_all debug knob was dropped

Yes, you were right to drop the share_all knob for now.  I do like the
idea, but it was quite inappropriate to mix it in with this NUMAnode
patch.  And although I like the idea, I think it wants a bit more: I
already have a hacky "allksm" boot option patch to mm/mmap.c for my
own testing, which adds VM_MERGEABLE everywhere.  If I gave that up
(I'd like to!) in favour of yours, I think I would still be missing
all the mms that are created before there's a chance to switch the
share_all mode on.  Or maybe I misread your v3.  Anyway, that's a
different topic, happily taken off today's agenda.

>   - get_kpfn_nid helper
>   - fixed page migration behaviour
> 
> Signed-off-by: Petr Holasek 
> ---
>  Documentation/vm/ksm.txt |   7 +++
>  mm/ksm.c | 135 
> ---
>  2 files changed, 122 insertions(+), 20 deletions(-)
> 
> diff --git a/Documentation/vm/ksm.txt b/Documentation/vm/ksm.txt
> index b392e49..100d58d 100644
> --- a/Documentation/vm/ksm.txt
> +++ b/Documentation/vm/ksm.txt
> @@ -58,6 +58,13 @@ sleep_millisecs  - how many milliseconds ksmd should sleep 
> before next scan
> e.g. "echo 20 > /sys/kernel/mm/ksm/sleep_millisecs"
> Default: 20 (chosen for demonstration purposes)
>  
> +merge_nodes  - specifies if pages from different numa nodes can be 
> merged.

merge_across_nodes

> +   When set to 0, ksm merges only pages which physically
> +   reside in the memory area of same NUMA node. It brings
> +   lower latency to access to shared page. Value can be
> +   changed only when there is no ksm shared pages in system.
> +   Default: 1
> +
>  run  - set 0 to stop ksmd from running but keep merged pages,
> set 1 to run ksmd e.g. "echo 1 > /sys/kernel/mm/ksm/run",
> set 2 to stop ksmd and unmerge all pages currently merged,
> diff --git a/mm/ksm.c b/mm/ksm.c
> index 47c8853..7c82032 100644
> --- a/mm/ksm.c
> +++ b/mm/ksm.c
> @@ -36,6 +36,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include "internal.h"
> @@ -140,7 +141,10 @@ struct rmap_item {
>   unsigned long address;  /* + low bits used for flags below */
>   unsigned int oldchecksum;   /* when unstable */
>   union {
> - struct rb_node node;/* when node of unstable tree */
> + struct {
> + struct rb_node node;/* when node of unstable tree */
> + struct rb_root *root;
> + };

This worries me a little, enlarging struct 

Re: [PATCH] perf, tools: Add library dependencies for static perf link

[Andi Kleen]

> This is superfluous, because FLAGS_BFD has -ldl already by your change
> above. This is cascaded downwards.

I tried to remove it, but that makes it not link again for the static build.
Haven't looked into the causes.

-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 v3 04/13] kmem accounting basic infrastructure

[Tejun Heo]

Hello, James.

On Sun, Sep 30, 2012 at 12:25:52PM +0100, James Bottomley wrote:
> But you've got to ask yourself who cares about accurate accounting per
> container of dentry and inode objects? They're not objects that any
> administrator is used to limiting.  What we at parallels care about
> isn't accurately accounting them, it's that one container can't DoS
> another by exhausting system resources.  That's achieved equally well by
> first charge slab accounting, so we don't really have an interest in
> pushing object accounting code for which there's no use case.

Isn't it more because the use cases you have on mind don't share
dentries/inodes too much?  Wildly incorrect accounting definitely
degrades container isolation and can lead to unexpected behaviors.

> All we need kernel memory accounting and limiting for is DoS prevention.
> There aren't really any system administrators who care about Kernel
> Memory accounting (at least until the system goes oom) because there are
> no absolute knobs for it (all there is are a set of weird and wonderful
> heuristics, like dirty limit ratio and drop caches).  Kernel memory

I think that's because the mechanism currently doesn't exist.  If one
wants to control how memory is distributed across different cgroups,
it's logical to control kernel memory too.  The resource in question
is the actual memory after all.  I think at least google would be
interested in it, so, no, I don't agree that nobody wants it.  If that
is the case, we're working towards the wrong direction.

> usage has a whole set of regulatory infrastructure for trying to make it
> transparent to the user.
> 
> Don't get me wrong: if there were some easy way to get proper memory
> accounting for free, we'd be happy but, because it has no practical
> application for any of our customers, there's a limited price we're
> willing to pay to get it.

Even on purely technical ground, it could be that first-use is the
right trade off if other more accurate approaches are too difficult
and most workloads are happy with such approach.  I'm still a bit
weary to base userland interface decisions on that tho.

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/

[RFC v3] perf tools: Try to find cross-built objdump path

[Irina Tirdea]

From: Namhyung Kim 

As we have architecture information of saved perf.data file, we can
try to find cross-built objdump path.

The triplets include support for Android (arm, x86 and mips architectures).

Signed-off-by: Namhyung Kim 
Signed-off-by: Irina Tirdea 
---

v3:
 () update triplets to include Android toolchains for arm, x86 and mips
 () fixed a few small bugs
 () tested on Android
 
v2: don't modify env string

 tools/perf/Makefile   |2 +
 tools/perf/arch/common.c  |   51 
 tools/perf/builtin-annotate.c |3 ++
 tools/perf/util/annotate.c|  107 +
 tools/perf/util/annotate.h|   11 +
 5 files changed, 174 insertions(+)
 create mode 100644 tools/perf/arch/common.c

diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index e5e71e7..816fc04 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -412,6 +412,8 @@ LIB_OBJS += $(OUTPUT)ui/helpline.o
 LIB_OBJS += $(OUTPUT)ui/hist.o
 LIB_OBJS += $(OUTPUT)ui/stdio/hist.o
 
+LIB_OBJS += $(OUTPUT)arch/common.o
+
 BUILTIN_OBJS += $(OUTPUT)builtin-annotate.o
 BUILTIN_OBJS += $(OUTPUT)builtin-bench.o
 # Benchmark modules
diff --git a/tools/perf/arch/common.c b/tools/perf/arch/common.c
new file mode 100644
index 000..6904777
--- /dev/null
+++ b/tools/perf/arch/common.c
@@ -0,0 +1,51 @@
+#include 
+
+const char *const arm_triplets[] = {
+   "arm-eabi-",
+   "arm-linux-androideabi-",
+   "arm-unknown-linux-",
+   "arm-unknown-linux-gnu-",
+   "arm-unknown-linux-gnueabi-",
+   NULL
+};
+
+const char *const powerpc_triplets[] = {
+   "powerpc-unknown-linux-gnu-",
+   "powerpc64-unknown-linux-gnu-",
+   NULL
+};
+
+const char *const s390_triplets[] = {
+   "s390-ibm-linux-",
+   NULL
+};
+
+const char *const sh_triplets[] = {
+   "sh-unknown-linux-gnu-",
+   "sh64-unknown-linux-gnu-",
+   NULL
+};
+
+const char *const sparc_triplets[] = {
+   "sparc-unknown-linux-gnu-",
+   "sparc64-unknown-linux-gnu-",
+   NULL
+};
+
+const char *const x86_triplets[] = {
+   "x86_64-pc-linux-gnu-",
+   "x86_64-unknown-linux-gnu-",
+   "i686-pc-linux-gnu-",
+   "i586-pc-linux-gnu-",
+   "i486-pc-linux-gnu-",
+   "i386-pc-linux-gnu-",
+   "i686-linux-android-",
+   "i686-android-linux-",
+   NULL
+};
+
+const char *const mips_triplets[] = {
+   "mips-unknown-linux-gnu-",
+   "mipsel-linux-android-",
+   NULL
+};
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 9ea3854..20fe9bb 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -186,6 +186,9 @@ static int __cmd_annotate(struct perf_annotate *ann)
goto out_delete;
}
 
+   if (!objdump_path)
+   try_objdump_path(session);
+
ret = perf_session__process_events(session, >tool);
if (ret)
goto out_delete;
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index f0a9103..36f3af0 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -15,6 +15,7 @@
 #include "debug.h"
 #include "annotate.h"
 #include 
+#include 
 
 const char *disassembler_style;
 const char *objdump_path;
@@ -1140,3 +1141,109 @@ int symbol__tty_annotate(struct symbol *sym, struct map 
*map, int evidx,
 
return 0;
 }
+
+static bool lookup_path(char *name)
+{
+   bool found = false;
+   char *path, *tmp;
+   char buf[PATH_MAX];
+   char *env = getenv("PATH");
+
+   if (!env)
+   return false;
+
+   env = strdup(env);
+   if (!env)
+   return false;
+
+   path = strtok_r(env, ":", );
+   while (path) {
+   scnprintf(buf, sizeof(buf), "%s/%s", path, name);
+   if (access(buf, F_OK) == 0) {
+   found = true;
+   break;
+   }
+   path = strtok_r(NULL, ":", );
+   }
+   free(env);
+   return found;
+}
+
+static int lookup_triplets(const char **triplets, const char *name)
+{
+   int i;
+   char buf[PATH_MAX];
+
+   for (i = 0; triplets[i] != NULL; i++) {
+   scnprintf(buf, sizeof(buf), "%s%s", triplets[i], name);
+   if (lookup_path(buf))
+   return i;
+   }
+   return -1;
+}
+
+static char *try_binutils_path(struct perf_session *session, const char *name)
+{
+   int idx;
+   char *arch, *env;
+   struct utsname uts;
+   const char **path_list;
+   char buf[PATH_MAX];
+
+   if (uname() < 0)
+   return NULL;
+
+   /*
+* We don't need to try to find objdump path for native system.
+* Just use default "objdump".
+*/
+   if (!strcmp(uts.machine, session->header.env.arch))
+   return NULL;
+
+   env = getenv("CROSS_COMPILE");
+   if (env) {
+   scnprintf(buf, 

Linux 3.6

[Linus Torvalds]

When I did the -rc7 announcement a week ago, I said I might have to do
an -rc8, but a week passed, and things have been calm, and I honestly
cannot see a major reason to do another rc.

So here it is, 3.6 final. Sure, I'd have been happier with even fewer
changes, but that just never happens. And holding off the release
until people get too bored to send me the small stuff just makes the
next merge window more painful.

The changes that got merged this week were generally pretty tiny, but
more importantly, they tend to be small or very unlikely/special
things. Famous last words.

The shortlog below is obviously just the log since -rc7, the changes
in 3.6 since 3.5 are too many to list. There haven't been any huge new
architectures or filesystems, it's all "solid progress". That may not
sound all that exciting, but the devil is in the details, and there's
a lot of small fixes all over.

Anyway, this obviously means that the merge window for 3.7 is open,
and on that subject I do want to note that I'm going to travel much of
this merge window. Let's see how much that impacts my merging, but I
hope that it won't be *that* noticeable. But in case it results in any
problems, I'll just give a heads-up, and if worst comes to worst I'll
just extend the merge window to give myself more time for merging. I
aim to avoid it, but I'll note it here just in case it happens.

Steven Rothwell already noted during the -rc7 release that people
should have the stuff for 3.7 in linux-next, and I hope that is true.
Guys and gals, please behave, ok?

 Linus

---
Al Viro (6):
  do_add_mount()/umount -l races
  close the race in nlmsvc_free_block()
  um: take cleaning singlestep to start_thread()
  um: don't leak floating point state and segment registers on execve()
  um: let signal_delivered() do SIGTRAP on singlestepping into handler
  um: kill thread->forking

Alan Stern (1):
  USB: Fix race condition when removing host controllers

Alex Elder (2):
  rbd: drop dev reference on error in rbd_open()
  libceph: only kunmap kmapped pages

Alex Williamson (3):
  vfio: Trivial Documentation correction
  vfio: Fix virqfd release race
  iommu: static inline iommu group stub functions

Andrea Arcangeli (1):
  thp: avoid VM_BUG_ON page_count(page) false positives in
__collapse_huge_page_copy

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

Andrew Lunn (1):
  ARM: Orion5x: Fix too small coherent pool.

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

Ben Skeggs (3):
  drm/nouveau: silence a debug message triggered by newer userspace
  drm/nvc0/ltcg: mask off intr 0x10
  drm/nvc0/fifo: ignore bits in PFIFO_INTR that aren't set in PFIFO_INTR_EN

Chris Metcalf (1):
  tile: gxio iorpc numbering change for TRIO interface

Dan Carpenter (2):
  NVMe: handle allocation failure in nvme_map_user_pages()
  vmwgfx: corruption in vmw_event_fence_action_create()

Daniel Mack (1):
  ALSA: snd-usb: fix next_packet_size calls for pause case

Dave Airlie (1):
  drm/udl: limit modes to the sku pixel limits.

Dave Jiang (1):
  MAINTAINERS: update Intel C600 SAS driver maintainers

Def (1):
  batman-adv: Fix change mac address of soft iface.

Emmanuel Grumbach (1):
  iwlwifi: don't double free the interrupt in failure path

Eric Dumazet (4):
  ipv4: raw: fix icmp_filter()
  net: guard tcp_set_keepalive() to tcp sockets
  ipv6: raw: fix icmpv6_filter()
  ipv6: mip6: fix mip6_mh_filter()

Geert Uytterhoeven (1):
  um: Preinclude include/linux/kern_levels.h

Heiko Carstens (1):
  checksyscalls: fix "here document" handling

J. Bruce Fields (1):
  trivial select_parent documentation fix

Jan Engelhardt (1):
  netfilter: xt_limit: have r->cost != 0 case work

Jan Kara (1):
  lib/flex_proportions.c: fix corruption of denominator in
flexible proportions

Jiri Pirko (1):
  team: send port changed when added

Joachim Eastwood (1):
  USB: ohci-at91: fix null pointer in ohci_hcd_at91_overcurrent_irq

Joerg Roedel (1):
  iommu/amd: Fix wrong assumption in iommu-group specific code

Keith Busch (7):
  NVMe: Set request queue logical block size
  NVMe: Fix nvme module init when nvme_major is set
  NVMe: replace nvme_ns with nvme_dev for user admin
  NVMe: use namespace id for nvme_get_features
  NVMe: Set block queue max sectors
  NVMe: Do not set IO queue depth beyond device max
  NVMe: Fix uninitialized iod compiler warning

Konrad Rzeszutek Wilk (1):
  xen/boot: Disable NUMA for PV guests.

Linus Lüssing (1):
  batman-adv: Fix symmetry check / route flapping in multi interface setups

Linus Torvalds (2):
  mtdchar: fix offset overflow detection
  Linux 3.6

Luis R. Rodriguez (1):
  cfg80211: fix possible circular lock on reg_regdb_search()

Re: [PATCH v4] KSM: numa awareness sysfs knob

[Hugh Dickins]

Sorry for taking so long to look at Petr's nice work: it's more than
what I can think through in odd stolen moments; but yesterday at last
I managed to get down to remembering KSM and giving this some time.

On Fri, 28 Sep 2012, Andrea Arcangeli wrote:
> On Mon, Sep 24, 2012 at 02:56:06AM +0200, Petr Holasek wrote:
> > @@ -1758,7 +1800,12 @@ void ksm_migrate_page(struct page *newpage, struct 
> > page *oldpage)
> > stable_node = page_stable_node(newpage);
> > if (stable_node) {
> > VM_BUG_ON(stable_node->kpfn != page_to_pfn(oldpage));
> > -   stable_node->kpfn = page_to_pfn(newpage);
> > +
> > +   if (ksm_merge_across_nodes ||
> > +   page_to_nid(oldpage) == page_to_nid(newpage))
> > +   stable_node->kpfn = page_to_pfn(newpage);
> > +   else
> > +   remove_node_from_stable_tree(stable_node);
> > }
> >  }
> 
> This will result in memory corruption because the ksm page still
> points to the stable_node that has been freed (that is copied by the
> migrate code when the newpage->mapping = oldpage->mapping).

That is a very acute observation!  (And there was I searching for
where we copy over the PageKsm ;) which of course is in ->mapping.)

> 
> What should happen is that the ksm page of src_node is merged with
> the pre-existing ksm page in the dst_node of the migration. That's the
> complex case, the easy case is if there's no pre-existing page and
> that just requires an insert of the stable node in a different rbtree
> I think (without actual pagetable mangling).

I believe it's not as bad as "pagetable mangling" suggests.

> 
> It may be simpler to break cow across migrate and require the ksm
> scanner to re-merge it however.

I'm all for the simplest solution, but here in ksm_migrate_page()
is not a good place for COW breaking - we don't want to get into
an indefinite number of page allocations, and the risk of failure.

I was toying with the idea of leaving the new page in the old NUMAnode's
stable tree temporarily, until ksmd comes around again, and let that
clean it up.  Which would imply less reliance on get_kpfn_nid(),
and not skipping PageKsm in ksm_do_scan(), and...

But it's not all that simple, and I think we can do better.

> 
> Basically the above would remove the ability to rmap the ksm page
> (i.e. rmap crashes on a dangling pointer), but we need rmap to be
> functional at all times on all ksm pages.

Yes.

> 
> Hugh what's your views on this ksm_migrate_page NUMA aware that is
> giving trouble? What would you prefer? Merge two ksm pages together
> (something that has never happened before), break_cow (so we don't
> have to merge two ksm pages together in the first place and we
> fallback in the regular paths) etc...

It's only just fully dawned on me that ksm_migrate_page() is actually
a very convenient place: no pagetable mangling required, because we
know that neither old nor new page is at this instant mapped into
userspace at all - don't we?  Instead there are swap-like migration
entries plugging all ptes until we're ready to put in the new page.

So I think what we really want to do is change the ksm_migrate_page()
interface a little, and probably the precise position it's called from,
to allow it to update mm/migrate.c's newpage - in the collision case
when the new NUMAnode already has a stable copy of this page.  But when
it doesn't, just move KSMnode from old NUMAnode's stable tree to new.

How well the existing ksm.c primitives are suited to this, I've not
checked.  Probably not too well, but shouldn't be hard to add what's
needed.

What do you think?  Does that sound reasonable, Petr?

By the way, this is probably a good occasion to remind ourselves,
that page migration is still usually disabled on PageKsm pages:
ksm_migrate_page() is only being called for memory hotremove.  I had
been about to complain that calling remove_node_from_stable_tree()
from ksm_migrate_page() is also unsafe from a locking point of view;
until I remembered that MEM_GOING_OFFLINE has previously acquired
ksm_thread_mutex.

But page migration is much more important now than three years ago,
with compaction relying upon it, CMA and THP relying upon compaction,
and lumpy reclaim gone.

Whilst it should not be mixed up in the NUMA patch itself, I think we
need now to relax that restriction.  I found re-reading my 62b61f611e
"ksm: memory hotremove migration only" was helpful.  Petr, is that
something you could take on also?  I _think_ it's just a matter of
protecting the stable tree(s) with an additional mutex (which ought
not to be contended, since ksm_thread_mutex is normally held above
it, except in migration); then removing a number of PageKsm refusals
(and the offlining arg to unmap_and_move() etc).  But perhaps there's
more to it, I haven't gone over it properly.

> 
> All the rest looks very good, great work Petr!

Yes, I agree; but a few more comments I'll make against the v4 post.

Hugh
--
To 

Re: [PATCH V2 3/3] workqueue: Schedule work on non-idle cpu instead of current one

[Tejun Heo]

Hello,

On Sun, Sep 30, 2012 at 05:46:45PM +0530, Viresh Kumar wrote:
> For the scheduler CPU is idle, if all below are true:
> - current task is idle task
> - nr_running == 0
> - wake_list is empty
> 
> And during these conditions, there can be a timer running in background.
> And when we reach its interrupt handler, then also these conditions hold true
> and local cpu is idle.

It isn't about the CPU being actually idle?  Also, if it's only about
timers, shouldn't it be enough to implement it for timer and
delayed_work?

It would be great if you explain what you're trying to achieve how.  I
can't tell what you're aiming for and why that would be beneficial
from these submissions.

Thanks.

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

Re: [PATCH 8/10] bug.h: Make BUILD_BUG_ON generate compile-time error

[Josh Triplett]

On Sun, Sep 30, 2012 at 06:29:01PM -0500, Daniel Santos wrote:
> On 09/28/2012 09:55 PM, Josh Triplett wrote:
> > Assuming you don't call BUILD_BUG_ON_MSG more than once per line:
> >
> > /tmp$ cat test.c
> > #define BUILD_BUG_ON_MSG_INTERNAL2(cond, msg, line) \
> > do { \
> > extern void __build_bug_on_failed_ ## line (void) 
> > __attribute__((error(msg))); \
> > if (cond) \
> > __build_bug_on_failed_ ## line(); \
> > } while (0)
> >
> > #define BUILD_BUG_ON_MSG_INTERNAL(cond, msg, line) 
> > BUILD_BUG_ON_MSG_INTERNAL2(cond, msg, line)
> > #define BUILD_BUG_ON_MSG(cond, msg) BUILD_BUG_ON_MSG_INTERNAL(cond, msg, 
> > __LINE__)
> >
> > void f(void)
> > {
> > BUILD_BUG_ON_MSG(0, "test 1");
> > BUILD_BUG_ON_MSG(1, "test 2");
> > BUILD_BUG_ON_MSG(0, "test 3");
> > BUILD_BUG_ON_MSG(1, "test 4");
> > }
> > /tmp$ gcc -c test.c
> > test.c: In function ‘f’:
> > test.c:14:119: error: call to ‘__build_bug_on_failed_14’ declared with 
> > attribute error: test 2
> > test.c:16:119: error: call to ‘__build_bug_on_failed_16’ declared with 
> > attribute error: test 4
> Thanks! This is very nice!  I've done a little more research and
> discovered that there's also a __COUNTER__ macro that is available
> in gcc 4.3+.  Before I realized that it was only available in gcc
> 4.3, I wrote this little macro:
> 
> #define _CONCAT1(a, b) a##b
> #define CONCAT(a, b) _CONCAT1(a, b)
> 
> #ifdef __COUNTER__
> # define UNIQUIFY(prefix) CONCAT(prefix, __COUNTER__)
> #else
> # define UNIQUIFY(prefix) CONCAT(prefix, __LINE__)
> #endif
> 
> However, this could lead to code might compile on gcc 4.3+, but
> not compile prior, so this is bad, right?

Yes, as long as Linux continues to support prior GCC versions (currently
anything 3.2 or newer), I'd suggest sticking with __LINE__ so that it
consistently breaks if you use more than one BUILD_BUG_ON_MSG per line.

Good to know that __COUNTER__ exists, though.

Also, the name BUILD_BUG_ON_MSG seems wrong to me somehow; I keep
parsing it as though something about the message causes the build bug.

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

Re: [PATCH 3/10] compiler-gcc.h: Add gcc-recommended GCC_VERSION macro

[Josh Triplett]

On Sun, Sep 30, 2012 at 06:11:01PM -0500, Daniel Santos wrote:
> So in light of feedback I've been getting on this patch set, it leaves
> me with
> this question.
> > +#define GCC_VERSION (__GNUC__ * 1 \
> > +  + __GNUC_MINOR__ * 100 \
> > +  + __GNUC_PATCHLEVEL__)
> This macro presumes you are using gcc 3.0 or later, which introduced the
> __GNUC_PATCHLEVEL__ predefined macro.  Should you be using a version of gcc
> prior to 3.0 (where the macro is undefined), you would get an error that
> __GNUC_PATCHLEVEL__ is undefined prior to getting the error trying to
> include
> "linux/compiler-gcc2.h".  So it presumes the compiler is 3.0+, when another
> part of the code may allow it from a future change.  Should it be
> modified to
> do account for this or would that be overkill?

Overkill, since Linux requires GCC 3.2 or newer.  From compiler-gcc3.h:

#if __GNUC_MINOR__ < 2
# error Sorry, your compiler is too old - please upgrade it.
#endif

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

Re: [PATCH] gpio: mvebu: Add missing breaks in mvebu_gpio_irq_set_type

[Jason Cooper]

On Sun, Sep 30, 2012 at 11:49:49PM +0200, Linus Walleij wrote:
> On Sun, Sep 30, 2012 at 10:23 AM, Axel Lin  wrote:
> 
> > Signed-off-by: Axel Lin 
> 
> Acked-by: Linus Walleij 
> 
> Since this gpio-mvebu patch is in ARM SoC or somewhere I expect
> whoever put it there to safeguide the fix to its destination.

yep, I got it.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [ARM] Use AT() in the linker script to create correct program headers

[Jason Gunthorpe]

The standard linux asm-generic/vmlinux.lds.h already supports this,
and it seems other architectures do as well.

The goal is to create an ELF file that has correct program headers. We
want to see the VirtAddr be the runtime address of the kernel with the
MMU turned on, and PhysAddr be the physical load address for the section
with no MMU.

This allows ELF based boot loaders to properly load vmlinux:

$ readelf -l vmlinux
Entry point 0x8000
  Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD   0x008000 0xc0008000 0x8000 0x372244 0x3a4310 RWE 0x8000

Signed-off-by: Jason Gunthorpe 
---
 arch/arm/include/asm/memory.h |2 +-
 arch/arm/kernel/vmlinux.lds.S |   47 
 2 files changed, 29 insertions(+), 20 deletions(-)

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 5f6ddcc..4ce5b6d 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -283,7 +283,7 @@ static inline __deprecated void *bus_to_virt(unsigned long 
x)
 #define arch_is_coherent() 0
 #endif
 
-#endif
+#endif /* __ASSEMBLY__ */
 
 #include 
 
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 36ff15b..07942b6 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -3,6 +3,13 @@
  * Written by Martin Mares 
  */
 
+/* If we have a known, fixed physical load address then set LOAD_OFFSET
+   and generate an ELF that has the physical load address in the program
+   headers. */
+#ifndef CONFIG_ARM_PATCH_PHYS_VIRT
+#define LOAD_OFFSET (PAGE_OFFSET - PHYS_OFFSET)
+#endif
+
 #include 
 #include 
 #include 
@@ -39,7 +46,7 @@
 #endif
 
 OUTPUT_ARCH(arm)
-ENTRY(stext)
+ENTRY(phys_start)
 
 #ifndef __ARMEB__
 jiffies = jiffies_64;
@@ -86,11 +93,13 @@ SECTIONS
 #else
. = PAGE_OFFSET + TEXT_OFFSET;
 #endif
-   .head.text : {
+   .head.text : AT(ADDR(.head.text) - LOAD_OFFSET) {
_text = .;
+   phys_start = . - LOAD_OFFSET;
HEAD_TEXT
}
-   .text : {   /* Real text segment*/
+   /* Real text segment */
+   .text :  AT(ADDR(.text) - LOAD_OFFSET) {
_stext = .; /* Text and read-only data  */
__exception_text_start = .;
*(.exception.text)
@@ -119,12 +128,12 @@ SECTIONS
 * Stack unwinding tables
 */
. = ALIGN(8);
-   .ARM.unwind_idx : {
+   .ARM.unwind_idx : AT(ADDR(.ARM.unwind_idx) - LOAD_OFFSET) {
__start_unwind_idx = .;
*(.ARM.exidx*)
__stop_unwind_idx = .;
}
-   .ARM.unwind_tab : {
+   .ARM.unwind_tab : AT(ADDR(.ARM.unwind_tab) - LOAD_OFFSET) {
__start_unwind_tab = .;
*(.ARM.extab*)
__stop_unwind_tab = .;
@@ -139,35 +148,35 @@ SECTIONS
 #endif
 
INIT_TEXT_SECTION(8)
-   .exit.text : {
+   .exit.text : AT(ADDR(.exit.text) - LOAD_OFFSET) {
ARM_EXIT_KEEP(EXIT_TEXT)
}
-   .init.proc.info : {
+   .init.proc.info : AT(ADDR(.init.proc.info) - LOAD_OFFSET) {
ARM_CPU_DISCARD(PROC_INFO)
}
-   .init.arch.info : {
+   .init.arch.info : AT(ADDR(.init.arch.info) - LOAD_OFFSET) {
__arch_info_begin = .;
*(.arch.info.init)
__arch_info_end = .;
}
-   .init.tagtable : {
+   .init.tagtable : AT(ADDR(.init.tagtable) - LOAD_OFFSET) {
__tagtable_begin = .;
*(.taglist.init)
__tagtable_end = .;
}
 #ifdef CONFIG_SMP_ON_UP
-   .init.smpalt : {
+   .init.smpalt : AT(ADDR(.init.smpalt) - LOAD_OFFSET) {
__smpalt_begin = .;
*(.alt.smp.init)
__smpalt_end = .;
}
 #endif
-   .init.pv_table : {
+   .init.pv_table : AT(ADDR(.init.pv_table) - LOAD_OFFSET) {
__pv_table_begin = .;
*(.pv_table)
__pv_table_end = .;
}
-   .init.data : {
+   .init.data : AT(ADDR(.init.data) - LOAD_OFFSET) {
 #ifndef CONFIG_XIP_KERNEL
INIT_DATA
 #endif
@@ -178,7 +187,7 @@ SECTIONS
INIT_RAM_FS
}
 #ifndef CONFIG_XIP_KERNEL
-   .exit.data : {
+   .exit.data : AT(ADDR(.exit.data) - LOAD_OFFSET) {
ARM_EXIT_KEEP(EXIT_DATA)
}
 #endif
@@ -196,7 +205,7 @@ SECTIONS
__data_loc = .;
 #endif
 
-   .data : AT(__data_loc) {
+   .data : AT(__data_loc - LOAD_OFFSET) {
_data = .;  /* address in memory */
_sdata = .;
 
@@ -245,7 +254,7 @@ SECTIONS
 * free it after init has commenced and TCM contents have
 * been copied to its destination.
 */
-   .tcm_start : {
+   .tcm_start : AT(ADDR(.tcm_start) - LOAD_OFFSET) {
  

[PATCH] Fix userspace compilation of ip_tables.h/ip6_tables.h in C++ mode

[Jason Gunthorpe]

The implicit cast from void * is not allowed for C++ compilers, and the
arithmetic on void * generates warnings in C++ mode.

$ g++ -c t.cc
ip_tables.h:221:24: warning: pointer of type 'void *' used in arithmetic
ip_tables.h:221:24: error: invalid conversion from 'void*' to 'xt_entry_target*'

Signed-off-by: Jason Gunthorpe 
---
 include/linux/netfilter_ipv4/ip_tables.h  |2 +-
 include/linux/netfilter_ipv6/ip6_tables.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/netfilter_ipv4/ip_tables.h 
b/include/linux/netfilter_ipv4/ip_tables.h
index db79231..050ad8a 100644
--- a/include/linux/netfilter_ipv4/ip_tables.h
+++ b/include/linux/netfilter_ipv4/ip_tables.h
@@ -226,7 +226,7 @@ struct ipt_get_entries {
 static __inline__ struct xt_entry_target *
 ipt_get_target(struct ipt_entry *e)
 {
-   return (void *)e + e->target_offset;
+   return (struct xt_entry_target *)((__u8 *)e + e->target_offset);
 }
 
 /*
diff --git a/include/linux/netfilter_ipv6/ip6_tables.h 
b/include/linux/netfilter_ipv6/ip6_tables.h
index 08c2cbb..3349bf1 100644
--- a/include/linux/netfilter_ipv6/ip6_tables.h
+++ b/include/linux/netfilter_ipv6/ip6_tables.h
@@ -263,7 +263,7 @@ struct ip6t_get_entries {
 static __inline__ struct xt_entry_target *
 ip6t_get_target(struct ip6t_entry *e)
 {
-   return (void *)e + e->target_offset;
+   return (struct xt_entry_target *)((__u8 *)e + e->target_offset);
 }
 
 /*
-- 
1.7.4.1

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

Re: [PATCH 11/12] perf tools: Convert to BACKTRACE_SUPPORT

[Irina Tirdea]

> @@ -751,10 +753,8 @@ else
>  endif
>
>  ifdef NO_BACKTRACE

This should be changed to ifndef NO_BACKTRACE.

> -   BASIC_CFLAGS += -DNO_BACKTRACE
> -else
> -   ifneq ($(call try-cc,$(SOURCE_BACKTRACE),),y)
> -   BASIC_CFLAGS += -DNO_BACKTRACE
> +   ifeq ($(call try-cc,$(SOURCE_BACKTRACE),),y)
> +   BASIC_CFLAGS += -DBACKTRACE_SUPPORT
> endif
>  endif
>

Thanks,
Irina
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/4] perf annotate: configure objdump path at compile time

[Irina Tirdea]

On Thu, Sep 27, 2012 at 4:16 PM, Namhyung Kim  wrote:
> On Thu, 27 Sep 2012 14:25:10 +0300, Irina Tirdea wrote:
 The perf built to run on the host needs to use arm-eabi-objdump from
 the toolchain so that it can analyse data recorded on Android. This
 patch is targeting this scenario, not the previous one. In this case,
 the CROSS_COMPILE option would be different than arm-eabi- so using
 $(CROSS_COMPILE)objdump would be wrong. objdump should be overridden
 when running make since there is no connection between the toolchain
 used here and the path for objdump. I am always overriding objdump
 when calling make, so I did not catch this.

 I think that I should change DEFAULT_OBJDUMP_PATH=objdump in the
 Makefile to handle the first scenario. I'll also explain this in the
 commit message so that it is more clear and make the same change for
 the addr2line patch.

 What do you think?
>>>
>>> I think the right thing to do is finding a correct objdump at runtime in
>>> some way.  Why do you want to make it compile-time configurable?
>>>
>>
>> The correct objdump path can be detected at runtime by setting the
>> toolchain path. But since the name is arm-eabi-objdump and not
>> objdump, it does not know to use it instead.
>>
>> The only way (I can think of) to change objdump at runtime would be to
>> use the --objdump option for perf annotate (and provide a similar
>> option for addr2line). The problem with this approach is that the user
>> has to be aware that perf annotate uses the objdump tool and that he
>> has to use the cross-compiler version instead. Since the user will
>> have perf compiled for host as part of his Android tree, he will
>> expect it to work without these further changes from his part. The
>> path for objdump can be set in the Android Makefile at compile time so
>> that the user doesn't need to be aware of it.
>
> What I'm thinking is that perf can try to find cross-built binutils when
> it detects perf.data file is came from other machine/architecture.
> Fortunately perf_session_env was added recently and it has the arch
> information from the file so we can use it to find the path.
>
> Following patch is a proof-of-concept patch and only build tested.
> What do you think?  Could you play with it for some time? :)
>

Thanks, this looks like the right approach. :)
I'm going to test it for Android cross-compiling and submit an update if needed.

Thanks,
Irina
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] TPM: Let the tpm char device be openable multiple times

[Jason Gunthorpe]

How to use the TPM is really a user space policy choice, if the
environment wants to use middleware then fine, but it is possible to
make correct TPM apps without using middleware.

So, remove the kernel restriction that only one process may open the TPM.
- TPM low level functions (in kernel users) are already locked proprely
  and can run in parallel with the user space interface anyhow.
- Move the user space data buffer and related goop into a
  struct tpm_file, create one struct tpm_file per open file.

Signed-off-by: Jason Gunthorpe 
---
 drivers/char/tpm/tpm.c |   97 +---
 drivers/char/tpm/tpm.h |   23 ++-
 2 files changed, 55 insertions(+), 65 deletions(-)

This is rebase, retest, resend of a patch I sent two years ago. The
discussion on that earlier patch fizzled out. Resending incase there
is renewed interest :)

diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c
index 60e8442..a161be9 100644
--- a/drivers/char/tpm/tpm.c
+++ b/drivers/char/tpm/tpm.c
@@ -33,7 +33,6 @@
 
 enum tpm_const {
TPM_MINOR = 224,/* officially assigned */
-   TPM_BUFSIZE = 4096,
TPM_NUM_DEVICES = 256,
 };
 
@@ -333,19 +332,19 @@ static const u8 tpm_ordinal_duration[TPM_MAX_ORDINAL] = {
 
 static void user_reader_timeout(unsigned long ptr)
 {
-   struct tpm_chip *chip = (struct tpm_chip *) ptr;
+   struct tpm_file *fl = (struct tpm_file *) ptr;
 
-   schedule_work(>work);
+   schedule_work(>work);
 }
 
 static void timeout_work(struct work_struct *work)
 {
-   struct tpm_chip *chip = container_of(work, struct tpm_chip, work);
+   struct tpm_file *fl = container_of(work, struct tpm_file, work);
 
-   mutex_lock(>buffer_mutex);
-   atomic_set(>data_pending, 0);
-   memset(chip->data_buffer, 0, TPM_BUFSIZE);
-   mutex_unlock(>buffer_mutex);
+   mutex_lock(>buffer_mutex);
+   atomic_set(>data_pending, 0);
+   memset(fl->data_bufferx, 0, sizeof(fl->data_bufferx));
+   mutex_unlock(>buffer_mutex);
 }
 
 /*
@@ -384,9 +383,6 @@ static ssize_t tpm_transmit(struct tpm_chip *chip, const 
char *buf,
u32 count, ordinal;
unsigned long stop;
 
-   if (bufsiz > TPM_BUFSIZE)
-   bufsiz = TPM_BUFSIZE;
-
count = be32_to_cpu(*((__be32 *) (buf + 2)));
ordinal = be32_to_cpu(*((__be32 *) (buf + 6)));
if (count == 0)
@@ -1161,6 +1157,7 @@ int tpm_open(struct inode *inode, struct file *file)
 {
int minor = iminor(inode);
struct tpm_chip *chip = NULL, *pos;
+   struct tpm_file *fl;
 
rcu_read_lock();
list_for_each_entry_rcu(pos, _chip_list, list) {
@@ -1175,22 +1172,19 @@ int tpm_open(struct inode *inode, struct file *file)
if (!chip)
return -ENODEV;
 
-   if (test_and_set_bit(0, >is_open)) {
-   dev_dbg(chip->dev, "Another process owns this TPM\n");
-   put_device(chip->dev);
-   return -EBUSY;
-   }
-
-   chip->data_buffer = kzalloc(TPM_BUFSIZE, GFP_KERNEL);
-   if (chip->data_buffer == NULL) {
-   clear_bit(0, >is_open);
+   fl = kzalloc(sizeof(*fl), GFP_KERNEL);
+   if (fl == NULL) {
put_device(chip->dev);
return -ENOMEM;
}
 
-   atomic_set(>data_pending, 0);
+   fl->chip = chip;
+   mutex_init(>buffer_mutex);
+   setup_timer(>user_read_timer, user_reader_timeout,
+   (unsigned long)fl);
+   INIT_WORK(>work, timeout_work);
 
-   file->private_data = chip;
+   file->private_data = fl;
return 0;
 }
 EXPORT_SYMBOL_GPL(tpm_open);
@@ -1200,14 +1194,14 @@ EXPORT_SYMBOL_GPL(tpm_open);
  */
 int tpm_release(struct inode *inode, struct file *file)
 {
-   struct tpm_chip *chip = file->private_data;
+   struct tpm_file *fl = file->private_data;
+   struct tpm_chip *chip = fl->chip;
 
-   del_singleshot_timer_sync(>user_read_timer);
-   flush_work_sync(>work);
+   del_singleshot_timer_sync(>user_read_timer);
+   flush_work_sync(>work);
+   mutex_destroy(>buffer_mutex);
+   kfree(file->private_data);
file->private_data = NULL;
-   atomic_set(>data_pending, 0);
-   kfree(chip->data_buffer);
-   clear_bit(0, >is_open);
put_device(chip->dev);
return 0;
 }
@@ -1216,33 +1210,33 @@ EXPORT_SYMBOL_GPL(tpm_release);
 ssize_t tpm_write(struct file *file, const char __user *buf,
  size_t size, loff_t *off)
 {
-   struct tpm_chip *chip = file->private_data;
+   struct tpm_file *fl = file->private_data;
size_t in_size = size, out_size;
 
/* cannot perform a write until the read has cleared
   either via tpm_read or a user_read_timer timeout */
-   while (atomic_read(>data_pending) != 0)
+   while (atomic_read(>data_pending) != 0)
msleep(TPM_TIMEOUT);
 
-   mutex_lock(>buffer_mutex);
+   

[PATCH] TPM: Provide a tpm_tis OF driver

[Jason Gunthorpe]

This provides an open firwmare driver binding for tpm_tis. OF
is useful on arches where PNP is not used.

Allow the tpm_tis driver to be selected if PNP or OF are compiled in.

Signed-off-by: Jason Gunthorpe 
---
 drivers/char/tpm/Kconfig   |2 +-
 drivers/char/tpm/tpm_tis.c |   56 +--
 2 files changed, 54 insertions(+), 4 deletions(-)

This is a rebase, retest, resend of a patch I sent two years ago...

diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index a048199..a346714 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -26,7 +26,7 @@ if TCG_TPM
 
 config TCG_TIS
tristate "TPM Interface Specification 1.2 Interface"
-   depends on X86
+   depends on X86 || OF
---help---
  If you have a TPM security chip that is compliant with the
  TCG TIS 1.2 TPM specification say Yes and it will be accessible
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index c4be351..0a890ed 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -27,6 +27,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include "tpm.h"
 
 enum tis_access {
@@ -506,8 +509,10 @@ static bool interrupts = 1;
 module_param(interrupts, bool, 0444);
 MODULE_PARM_DESC(interrupts, "Enable interrupts");
 
+/* irq == 0 -> autoprobe, -1 ->forced no interrupt,
+   others -> irq line to use */
 static int tpm_tis_init(struct device *dev, resource_size_t start,
-   resource_size_t len, unsigned int irq)
+   resource_size_t len, int irq)
 {
u32 vendor, intfcaps, intmask;
int rc, i, irq_s, irq_e, probe;
@@ -605,9 +610,11 @@ static int tpm_tis_init(struct device *dev, 
resource_size_t start,
iowrite32(intmask,
  chip->vendor.iobase +
  TPM_INT_ENABLE(chip->vendor.locality));
-   if (interrupts)
+   if (!interrupts)
+   irq = -1;
+   if (irq != -1)
chip->vendor.irq = irq;
-   if (interrupts && !chip->vendor.irq) {
+   if (irq == 0) {
irq_s =
ioread8(chip->vendor.iobase +
TPM_INT_VECTOR(chip->vendor.locality));
@@ -821,12 +828,53 @@ static int tpm_tis_resume(struct device *dev)
 
 static SIMPLE_DEV_PM_OPS(tpm_tis_pm, tpm_pm_suspend, tpm_tis_resume);
 
+#ifdef CONFIG_OF
+static struct of_device_id tis_of_platform_match[] = {
+   {.compatible = "tcg,tpm_tis"},
+   {},
+};
+static int __devinit tis_of_init_one(struct platform_device *pdev)
+{
+   struct resource res;
+   int ret;
+   int irq;
+
+   if (!pdev->dev.of_node)
+   return -ENODEV;
+
+   ret = of_address_to_resource(pdev->dev.of_node, 0, );
+   if (ret)
+   return ret;
+
+   irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
+   if (irq == NO_IRQ)
+   irq = -1;
+   return tpm_tis_init(>dev, res.start, res.end - res.start + 1,
+   irq);
+}
+
+static int __devexit tis_of_remove_one(struct platform_device *odev)
+{
+   struct tpm_chip *chip = dev_get_drvdata(>dev);
+   tpm_dev_vendor_release(chip);
+   kfree(chip);
+   return 0;
+}
+#endif
+
 static struct platform_driver tis_drv = {
.driver = {
.name = "tpm_tis",
.owner  = THIS_MODULE,
.pm = _tis_pm,
+#ifdef CONFIG_OF
+   .of_match_table = tis_of_platform_match,
+#endif
},
+#ifdef CONFIG_OF
+   .probe = tis_of_init_one,
+   .remove = __devexit_p(tis_of_remove_one)
+#endif
 };
 
 static struct platform_device *pdev;
@@ -849,7 +897,9 @@ static int __init init_tis(void)
return PTR_ERR(pdev);
if((rc=tpm_tis_init(>dev, TIS_MEM_BASE, TIS_MEM_LEN, 0)) != 0) {
platform_device_unregister(pdev);
+#ifndef CONFIG_OF
platform_driver_unregister(_drv);
+#endif
}
return rc;
 }
-- 
1.7.4.1

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

[PATCH] TPM: Issue TPM_STARTUP at driver load if the TPM has not been started

[Jason Gunthorpe]

The TPM will respond to TPM_GET_CAP with TPM_ERR_INVALID_POSTINIT if
TPM_STARTUP has not been issued. This will result in the TPM driver
failing to load and no way to recover. Detect this and automatically
issue TPM_STARTUP.

This is for embedded applications where the kernel is the first thing
to touch the TPM.

Signed-off-by: Jason Gunthorpe 
---
 drivers/char/tpm/tpm.c |   41 -
 drivers/char/tpm/tpm.h |6 ++
 2 files changed, 42 insertions(+), 5 deletions(-)

diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c
index 817f0ee..60e8442 100644
--- a/drivers/char/tpm/tpm.c
+++ b/drivers/char/tpm/tpm.c
@@ -473,7 +473,7 @@ static ssize_t transmit_cmd(struct tpm_chip *chip, struct 
tpm_cmd_t *cmd,
return -EFAULT;
 
err = be32_to_cpu(cmd->header.out.return_code);
-   if (err != 0)
+   if (err != 0 && desc)
dev_err(chip->dev, "A TPM error (%d) occurred %s\n", err, desc);
 
return err;
@@ -489,6 +489,15 @@ static const struct tpm_input_header tpm_getcap_header = {
.ordinal = TPM_ORD_GET_CAP
 };
 
+
+#define TPM_ORD_STARTUP cpu_to_be32(153)
+#define TPM_ST_CLEAR cpu_to_be32(1)
+static const struct tpm_input_header tpm_startup_header = {
+   .tag = TPM_TAG_RQU_COMMAND,
+   .length = cpu_to_be32(12),
+   .ordinal = TPM_ORD_STARTUP
+};
+
 ssize_t tpm_getcap(struct device *dev, __be32 subcap_id, cap_t *cap,
   const char *desc)
 {
@@ -545,11 +554,33 @@ int tpm_get_timeouts(struct tpm_chip *chip)
tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT;
+   rc = transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE, 0);
+
+   if (rc == TPM_ERR_INVALID_POSTINIT) {
+   struct tpm_cmd_t start_cmd;
+   /* The TPM is not started, we are the first to talk to it.
+  Execute a startup command. */
+   start_cmd.header.in = tpm_startup_header;
+   start_cmd.params.startup_in.startup_type = TPM_ST_CLEAR;
+
+   dev_info(chip->dev, "Issuing TPM_STARTUP");
+   rc = transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE,
+   "attempting to start the TPM");
+   if (rc)
+   return -EINVAL;
 
-   rc = transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE,
-   "attempting to determine the timeouts");
-   if (rc)
+   tpm_cmd.header.in = tpm_getcap_header;
+   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
+   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
+   tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT;
+   rc = transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE, 0);
+   }
+   if (rc) {
+   dev_err(chip->dev,
+   "A TPM error (%d) occurred attempting to determine the 
timeouts\n",
+   rc);
goto duration;
+   }
 
if (be32_to_cpu(tpm_cmd.header.out.return_code) != 0 ||
be32_to_cpu(tpm_cmd.header.out.length)
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 917f727..2d583ef 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -41,6 +41,7 @@ enum tpm_addr {
 #define TPM_WARN_DOING_SELFTEST 0x802
 #define TPM_ERR_DEACTIVATED 0x6
 #define TPM_ERR_DISABLED0x7
+#define TPM_ERR_INVALID_POSTINIT 38
 
 #define TPM_HEADER_SIZE10
 extern ssize_t tpm_show_pubek(struct device *, struct device_attribute *attr,
@@ -269,6 +270,10 @@ struct tpm_pcrextend_in {
u8  hash[TPM_DIGEST_SIZE];
 }__attribute__((packed));
 
+struct tpm_startup_in {
+   __be16  startup_type;
+} __packed;
+
 typedef union {
struct  tpm_getcap_params_out getcap_out;
struct  tpm_readpubek_params_out readpubek_out;
@@ -277,6 +282,7 @@ typedef union {
struct  tpm_pcrread_in  pcrread_in;
struct  tpm_pcrread_out pcrread_out;
struct  tpm_pcrextend_in pcrextend_in;
+   struct tpm_startup_in startup_in;
 } tpm_cmd_params;
 
 struct tpm_cmd_t {
-- 
1.7.4.1

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

Re: [PATCH 8/10] bug.h: Make BUILD_BUG_ON generate compile-time error

[Daniel Santos]

On 09/28/2012 09:55 PM, Josh Triplett wrote:
> Assuming you don't call BUILD_BUG_ON_MSG more than once per line:
>
> /tmp$ cat test.c
> #define BUILD_BUG_ON_MSG_INTERNAL2(cond, msg, line) \
> do { \
> extern void __build_bug_on_failed_ ## line (void) 
> __attribute__((error(msg))); \
> if (cond) \
> __build_bug_on_failed_ ## line(); \
> } while (0)
>
> #define BUILD_BUG_ON_MSG_INTERNAL(cond, msg, line) 
> BUILD_BUG_ON_MSG_INTERNAL2(cond, msg, line)
> #define BUILD_BUG_ON_MSG(cond, msg) BUILD_BUG_ON_MSG_INTERNAL(cond, msg, 
> __LINE__)
>
> void f(void)
> {
> BUILD_BUG_ON_MSG(0, "test 1");
> BUILD_BUG_ON_MSG(1, "test 2");
> BUILD_BUG_ON_MSG(0, "test 3");
> BUILD_BUG_ON_MSG(1, "test 4");
> }
> /tmp$ gcc -c test.c
> test.c: In function ‘f’:
> test.c:14:119: error: call to ‘__build_bug_on_failed_14’ declared with 
> attribute error: test 2
> test.c:16:119: error: call to ‘__build_bug_on_failed_16’ declared with 
> attribute error: test 4
Thanks! This is very nice!  I've done a little more research and
discovered that there's also a __COUNTER__ macro that is available
in gcc 4.3+.  Before I realized that it was only available in gcc
4.3, I wrote this little macro:

#define _CONCAT1(a, b) a##b
#define CONCAT(a, b) _CONCAT1(a, b)

#ifdef __COUNTER__
# define UNIQUIFY(prefix) CONCAT(prefix, __COUNTER__)
#else
# define UNIQUIFY(prefix) CONCAT(prefix, __LINE__)
#endif

However, this could lead to code might compile on gcc 4.3+, but
not compile prior, so this is bad, right?

Daniel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PPC: Do not make the entire heap executable

[Jason Gunthorpe]

On PPC the ELF PLT sections look like this:

  [17] .sbss NOBITS  0002aff8 01aff8 14 00  WA  0   0  4
  [18] .plt  NOBITS  0002b00c 01aff8 84 00 WAX  0   0  4
  [19] .bss  NOBITS  0002b090 01aff8 a4 00  WA  0   0  4

Which results in an ELF load header:
  Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD   0x019c70 0x00029c70 0x00029c70 0x01388 0x014c4 RWE 0x1

This is all correct, the load region containing the PLT is marked as
executable. Note that the PLT starts at 0002b00c but the file mapping ends at
0002aff8, so the PLT falls in the 0 fill section described by the load header,
and after a page boundary.

Unfortunately the generic ELF loader ignores the X bit in the load headers
when it creates the 0 filled non-file backed mappings. It assumes all of these
mappings are RW BSS sections, which is not the case for PPC.

Teach the ELF loader to check the X bit in the relevant load header and
create 0 filled anonymous mappings that are executable if the load header
requests that.

Signed-off-by: Jason Gunthorpe 
---
 arch/powerpc/include/asm/page.h|   10 +
 arch/powerpc/include/asm/page_32.h |2 -
 arch/powerpc/include/asm/page_64.h |4 ---
 fs/binfmt_elf.c|   37 ---
 4 files changed, 30 insertions(+), 23 deletions(-)

Please consider this a proposal to solve this issue.. 

diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index f072e97..61e46fc 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -215,15 +215,7 @@ extern long long virt_phys_offset;
 #define __pa(x) ((unsigned long)(x) - PAGE_OFFSET + MEMORY_START)
 #endif
 
-/*
- * Unfortunately the PLT is in the BSS in the PPC32 ELF ABI,
- * and needs to be executable.  This means the whole heap ends
- * up being executable.
- */
-#define VM_DATA_DEFAULT_FLAGS32(VM_READ | VM_WRITE | VM_EXEC | \
-VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
-
-#define VM_DATA_DEFAULT_FLAGS64(VM_READ | VM_WRITE | \
+#define VM_DATA_DEFAULT_FLAGS  (VM_READ | VM_WRITE | \
 VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
 
 #ifdef __powerpc64__
diff --git a/arch/powerpc/include/asm/page_32.h 
b/arch/powerpc/include/asm/page_32.h
index 68d73b2..aaae5a6 100644
--- a/arch/powerpc/include/asm/page_32.h
+++ b/arch/powerpc/include/asm/page_32.h
@@ -7,8 +7,6 @@
 #endif
 #endif
 
-#define VM_DATA_DEFAULT_FLAGS  VM_DATA_DEFAULT_FLAGS32
-
 #ifdef CONFIG_NOT_COHERENT_CACHE
 #define ARCH_DMA_MINALIGN  L1_CACHE_BYTES
 #endif
diff --git a/arch/powerpc/include/asm/page_64.h 
b/arch/powerpc/include/asm/page_64.h
index fed85e6..615d88b 100644
--- a/arch/powerpc/include/asm/page_64.h
+++ b/arch/powerpc/include/asm/page_64.h
@@ -136,10 +136,6 @@ do {   \
 
 #endif /* !CONFIG_HUGETLB_PAGE */
 
-#define VM_DATA_DEFAULT_FLAGS \
-   (is_32bit_task() ? \
-VM_DATA_DEFAULT_FLAGS32 : VM_DATA_DEFAULT_FLAGS64)
-
 /*
  * This is the default if a program doesn't have a PT_GNU_STACK
  * program header entry. The PPC64 ELF ABI has a non executable stack
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 1b52956..e5a432b 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -76,13 +76,20 @@ static struct linux_binfmt elf_format = {
 
 #define BAD_ADDR(x) ((unsigned long)(x) >= TASK_SIZE)
 
-static int set_brk(unsigned long start, unsigned long end)
+static int set_brk(unsigned long start, unsigned long end, int prot)
 {
start = ELF_PAGEALIGN(start);
end = ELF_PAGEALIGN(end);
if (end > start) {
unsigned long addr;
-   addr = vm_brk(start, end - start);
+   /* Map the non-file portion of the last load header. If the
+  header is requesting these pages to be executeable then
+  we have to honour that, otherwise assume they are bss. */
+   if (prot & PROT_EXEC)
+   addr = vm_mmap(0, start, end - start, prot,
+   MAP_PRIVATE | MAP_FIXED, 0);
+   else
+   addr = vm_brk(start, end - start);
if (BAD_ADDR(addr))
return addr;
}
@@ -381,6 +388,7 @@ static unsigned long load_elf_interp(struct elfhdr 
*interp_elf_ex,
unsigned long load_addr = 0;
int load_addr_set = 0;
unsigned long last_bss = 0, elf_bss = 0;
+   int bss_prot = 0;
unsigned long error = ~0UL;
unsigned long total_size;
int retval, i, size;
@@ -489,8 +497,10 @@ static unsigned long load_elf_interp(struct elfhdr 
*interp_elf_ex,
 * elf_bss and last_bss is the bss section.
 */
k = load_addr + eppnt->p_memsz + eppnt->p_vaddr;
- 

Re: [PATCH v4 5/5] MFD: ti_tscadc: add suspend/resume functionality

[Samuel Ortiz]

Hi Jonathan,

On Sat, Sep 29, 2012 at 10:50:19AM +0100, Jonathan Cameron wrote:
> On 09/26/2012 11:09 AM, Patil, Rachna wrote:
> > Hi Shubhrajyoti,
> > 
> > On Wed, Sep 26, 2012 at 12:10:51, Datta, Shubhrajyoti wrote:
> >> On Wednesday 26 September 2012 10:50 AM, Patil, Rachna wrote:
> >>> This patch adds support for suspend/resume of
> >>> TSC/ADC MFDevice.
> >> this should be merged with the patch adding support else
> >> we may end up in a case where patch a does the runtime calls
> >> and the call back  handlers added later.
> > 
> > I am adding both the runtime calls and the handlers in this patch.
> > I think maintaining this as a separate patch in better in terms
> > of readability as well.
> I would prefer this merged into patch 4 as it's a simple addition to
> a driver that should arguably have been there in the first place.
I agree. And I would even go as far as saying that having all the MFD parts
from this patchset merged into patch #2 would make sense.
Rachna, could you please re-work this patchset in such way, and adress my
comments on patch #2 ? I could then take the MFD parts and then Jonathan and
Dmitry take their parts. There are build time dependencies, but neither the
input nor the ADC driver could be actually built as long as the MFD one is not
merged (provided that the subdevices driver comes with the right Kconfig
dependecy).

Cheers,
Samuel.

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

Re: [PATCH v4 2/5] MFD: ti_tscadc: Add support for TI's TSC/ADC MFDevice

[Samuel Ortiz]

Hi Rachna,

On Wed, Sep 26, 2012 at 10:50:11AM +0530, Patil, Rachna wrote:
> Add the mfd core driver which supports touchscreen
> and ADC.
> With this patch we are only adding infrastructure to
> support the MFD clients.
> 
> Signed-off-by: Patil, Rachna 
> ---
> Changes in v2:
>   Merged "[PATCH 5/5] MFD: ti_tscadc: Add check on number of i/p 
> channels",
>   patch submitted in previous version into this file.
> 
> Changes in v3:
>   No changes
> 
> Changes in v4:
>   No changes
> 
>  drivers/mfd/Kconfig  |9 ++
>  drivers/mfd/Makefile |1 +
>  drivers/mfd/ti_am335x_tscadc.c   |  193 
> ++
>  include/linux/mfd/ti_am335x_tscadc.h |  133 +++
>  4 files changed, 336 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/mfd/ti_am335x_tscadc.c
>  create mode 100644 include/linux/mfd/ti_am335x_tscadc.h
Looks good to me, I only have a few comments:

> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index b1a1462..e472184 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -94,6 +94,15 @@ config MFD_TI_SSP
> To compile this driver as a module, choose M here: the
> module will be called ti-ssp.
>  
> +config MFD_TI_AM335X_TSCADC
> + tristate "TI ADC / Touch Screen chip support"
> + depends on ARCH_OMAP2PLUS
- Why do you need to depend on that architecture ?
- You must select MFD_CORE.

> +static unsigned int tscadc_readl(struct ti_tscadc_dev *tsadc, unsigned int 
> reg)
> +{
> + return readl(tsadc->tscadc_base + reg);
> +}
> +
> +static void tscadc_writel(struct ti_tscadc_dev *tsadc, unsigned int reg,
> + unsigned int val)
> +{
> + writel(val, tsadc->tscadc_base + reg);
> +}
> +
Have you considered using the regmap MMIO API ? The benefits are not very
obvious in that case, but it's always better to use a common framework.


> +static   int __devinit ti_tscadc_probe(struct platform_device *pdev)
> +{
> + struct ti_tscadc_dev*tscadc;
> + struct resource *res;
> + struct clk  *clk;
> + struct mfd_tscadc_board *pdata = pdev->dev.platform_data;
> + int irq;
> + int err, ctrl;
> + int clk_value, clock_rate;
> +
> + if (!pdata) {
> + dev_err(>dev, "Could not find platform data\n");
> + return -EINVAL;
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + dev_err(>dev, "no memory resource defined.\n");
> + return -EINVAL;
> + }
> +
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0) {
> + dev_err(>dev, "no irq ID is specified.\n");
> + return -EINVAL;
> + }
> +
> + /* Allocate memory for device */
> + tscadc = kzalloc(sizeof(struct ti_tscadc_dev), GFP_KERNEL);
devm_kzalloc ?

Cheers,
Samuel.

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

Re: [PATCH 3/10] compiler-gcc.h: Add gcc-recommended GCC_VERSION macro

[Daniel Santos]

So in light of feedback I've been getting on this patch set, it leaves
me with
this question.
> +#define GCC_VERSION (__GNUC__ * 1 \
> ++ __GNUC_MINOR__ * 100 \
> ++ __GNUC_PATCHLEVEL__)
This macro presumes you are using gcc 3.0 or later, which introduced the
__GNUC_PATCHLEVEL__ predefined macro.  Should you be using a version of gcc
prior to 3.0 (where the macro is undefined), you would get an error that
__GNUC_PATCHLEVEL__ is undefined prior to getting the error trying to
include
"linux/compiler-gcc2.h".  So it presumes the compiler is 3.0+, when another
part of the code may allow it from a future change.  Should it be
modified to
do account for this or would that be overkill?


#ifdef __GNUC_PATCHLEVEL__
# define GCC_VERSION (__GNUC__ * 1 \
+ __GNUC_MINOR__ * 100 \
+ __GNUC_PATCHLEVEL__)
#else
# define GCC_VERSION (__GNUC__ * 1 \
+ __GNUC_MINOR__ * 100)
#endif

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Instead of IP addresses the kernel started to show zero's

[Borislav Petkov]

+ netdev

On Sun, Sep 30, 2012 at 11:25:59PM +0200, Giuliano Pochini wrote:
> On Tue, 25 Sep 2012 14:26:07 +0400
> Alexey Vlasov  wrote:
> 
> > Hi.
> > 
> > Here it writes LOG target from syslog:
> > 
> > Sep 25 03:23:49 l24 kernel: ip:SYN-OUTPUT-HTTP IN= OUT=eth0
> > SRC= DST= LEN=60 TOS=0x00 PREC=0x00
> > TTL=64 ID=22467 DF PROTO=TCP SPT=52829 DPT=80 WINDOW=14600 RES=0x00 SYN
> > URGP=0 UID=564373 GID=155
> > 
> > This is recent, here go zero's again:
> > # cat /proc/net/xt_recent/ssh-brute
> > ...
> > src= ttl: 122 last_seen: 4371027622 oldest_pkt: 1
> > 4371027622
> >
> > Can it be fixed without restarting the box?
> > Thanks!
> >
> > Kernel 3.4.6.
> 
> It look similar to a problem that occurred on some 3.x heavy loaded
> machines. After a while they begin to send packets with dst=0.0.0.0. We had
> to revert to 2.6 on our production machines.
> 
> tcpdump output looks like this:
> 
> 17:06:29.272225 IP 0.0.0.0.http > 0.0.0.0.1687: . ack 232 win 15400
> 17:06:29.272671 IP 0.0.0.0.http > 0.0.0.0.1687: P 0:511(511) ack 232 win 15400
> 17:06:29.272689 IP 0.0.0.0.http > 0.0.0.0.1687: F 511:511(0) ack 232 win 15400
> 17:06:29.273249 IP 0.0.0.0.http > 0.0.0.0.65307: . ack 62552748 win 1006 
> 
> 17:06:29.273662 IP 0.0.0.0.http > 0.0.0.0.65307: P 0:511(511) ack 1 win 1006 
> 
> 17:06:29.273678 IP 0.0.0.0.http > 0.0.0.0.65307: F 511:511(0) ack 1 win 1006 
> 
> 17:06:29.278683 IP 0.0.0.0.http > 0.0.0.0.12021: . ack 1 win 12240
> 17:06:29.288707 IP 0.0.0.0.http > 0.0.0.0.28308: . ack 1049058319 win 12420
> 17:06:29.289406 IP 0.0.0.0.http > 0.0.0.0.28308: . ack 57 win 12420
> 17:06:29.289834 IP 0.0.0.0.http > 0.0.0.0.28308: P 0:487(487) ack 57 win 12420
> 17:06:29.289851 IP 0.0.0.0.http > 0.0.0.0.28308: F 487:487(0) ack 57 win 12420
> 17:06:29.291767 IP 0.0.0.0.http > 0.0.0.0.11407: P 0:472(472) ack 171 win 
> 1275 
> 17:06:29.292657 IP 0.0.0.0.http > 0.0.0.0.50511: . ack 1 win 14400
> 17:06:29.293502 IP 0.0.0.0.http > 0.0.0.0.12381: . ack 558 win 14960
> 17:06:29.295080 IP 0.0.0.0.http > 0.0.0.0.10980: . ack 2 win 16692
> 
> When the network traffic slows down the machine recovers to normal operation.
> 
> I found another report about this issue:
> 
> https://bbs.archlinux.org/viewtopic.php?id=129304

Any chance you guys can try the latest Linus kernel - it is 3.6-rc7 +
100ish patches and it should be close to final release, so pretty stable
already - to check whether the issue still persists?

Thanks.

-- 
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] backlight: tps65217_bl: Add missing platform_set_drvdata in tps65217_bl_probe

[Samuel Ortiz]

Hi Axel,

On Sun, Sep 30, 2012 at 06:28:26PM +0800, Axel Lin wrote:
> Otherwise, we got NULL derefernce while calling backlight_device_unregister()
> in tps65217_bl_remove().
> 
> Also convert to use module_platform_driver.
> 
> Signed-off-by: Axel Lin 
> ---
>  drivers/video/backlight/tps65217_bl.c |   14 ++
>  1 file changed, 2 insertions(+), 12 deletions(-)
Applied, thanks.

Cheers,
Samuel.

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

Re: [PATCH v6 1/3] drivers/mfd: Add realtek pcie card reader driver

[Samuel Ortiz]

Hi Wei,

On Tue, Sep 11, 2012 at 12:54:22PM +0800, wei_w...@realsil.com.cn wrote:
> From: Wei WANG 
> 
> Realtek PCI-E card reader driver adapts requests from upper-level
> sdmmc/memstick layer to the real physical card reader.
> 
> Signed-off-by: Wei WANG 
> Reviewed-by: Arnd Bergmann 
> Tested-by: Borislav Petkov 
> ---
>  drivers/mfd/Kconfig |9 +
>  drivers/mfd/Makefile|4 +
>  drivers/mfd/rts5209.c   |  188 ++
>  drivers/mfd/rts5229.c   |  179 ++
>  drivers/mfd/rtsx_pcr.c  | 1345 
> +++
>  drivers/mfd/rtsx_pcr.h  |   31 +
>  include/linux/mfd/rtsx_common.h |   47 ++
>  include/linux/mfd/rtsx_pci.h|  773 ++
>  8 files changed, 2576 insertions(+)
>  create mode 100644 drivers/mfd/rts5209.c
>  create mode 100644 drivers/mfd/rts5229.c
>  create mode 100644 drivers/mfd/rtsx_pcr.c
>  create mode 100644 drivers/mfd/rtsx_pcr.h
>  create mode 100644 include/linux/mfd/rtsx_common.h
>  create mode 100644 include/linux/mfd/rtsx_pci.h
Although  pretty big, the patch looks mostly good to me.
I only have a few comments:

> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index d1facef..4c07a34 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -63,6 +63,15 @@ config MFD_SM501_GPIO
>lines on the SM501. The platform data is used to supply the
>base number for the first GPIO line to register.
>  
> +config MFD_RTSX_PCI
> + tristate "Support for Realtek PCI-E driver-based card reader"
> + depends on PCI
> + help
> +   This supports for Realtek PCI-Express driver-based card reader 
> including
> +   rts5209, rts5229, etc. Realtek driver-based card reader supports 
> access
driver-based ?

> diff --git a/drivers/mfd/rts5209.c b/drivers/mfd/rts5209.c
> new file mode 100644
> index 000..6680d6d
> --- /dev/null
> +++ b/drivers/mfd/rts5209.c
> @@ -0,0 +1,188 @@
> +/* Driver for Realtek PCI-Express card reader
> + *
> + * Copyright(c) 2009 Realtek Semiconductor Corp. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2, or (at your option) any
> + * later version.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, see .
> + *
> + * Author:
> + *   Wei WANG 
> + *   No. 450, Shenhu Road, Suzhou Industry Park, Suzhou, China
> + */
> +
> +#include 
> +#include 
> +
> +#include "rtsx_pcr.h"
> +
> +static u8 rts5209_get_ic_version(struct rtsx_pcr *pcr)
> +{
> + u8 val;
> +
> + val = rtsx_pci_readb(pcr, 0x1C);
> + return val & 0x0F;
For your IO accesses, it would e worth looking at the regmap MMIO routines. It
would also simplify your main probe routine.


> +static int rts5209_turn_on_led(struct rtsx_pcr *pcr)
> +{
> + return rtsx_pci_write_register(pcr, 0xFD58, 0x01, 0x00);
You have many hardcoded register adresses around this code. Defining them in
your header file wouldn't hurt.


> +static struct platform_device *rtsx_pci_create_subdev(struct rtsx_pcr *pcr,
> + const char *name, int slot_id)
> +{
> + struct platform_device *p_dev;
> + int err;
> +
> + p_dev = platform_device_alloc(name, pcr->id);
> + if (p_dev == NULL) {
> + dev_dbg(&(pcr->pci->dev), "alloc platform device fail!\n");
> + return NULL;
> + }
> +
> + p_dev->dev.parent = &(pcr->pci->dev);
> + platform_set_drvdata(p_dev, pcr);
> + pcr->slots[slot_id].p_dev = p_dev;
> +
> + err = platform_device_add(p_dev);
> + if (err) {
> + dev_dbg(&(pcr->pci->dev), "add platform device fail!\n");
> + pcr->slots[slot_id].p_dev = NULL;
> + platform_device_put(p_dev);
> + return NULL;
> + }
> +
> + return p_dev;
> +}
Please use the MFD device addition API for that.


> +static irqreturn_t rtsx_pci_isr(int irq, void *dev_id)
> +{
> + struct rtsx_pcr *pcr = dev_id;
> + u32 int_reg;
> +
> + if (!pcr)
> + return IRQ_NONE;
> +
> + spin_lock(>lock);
> +
> + int_reg = rtsx_pci_readl(pcr, RTSX_BIPR);
> + /* Clear interrupt flag */
> + rtsx_pci_writel(pcr, RTSX_BIPR, int_reg);
> + if ((int_reg & pcr->bier) == 0) {
> + spin_unlock(>lock);
> + return IRQ_NONE;
> + }
> + if (int_reg == 0x) {
> + spin_unlock(>lock);
> + return IRQ_HANDLED;
> + }
> +
> + int_reg &= (pcr->bier | 0x7F);
> +
> + if (int_reg & 

Re: [PATCH] gpio: mvebu: Add missing breaks in mvebu_gpio_irq_set_type

[Linus Walleij]

On Sun, Sep 30, 2012 at 10:23 AM, Axel Lin  wrote:

> Signed-off-by: Axel Lin 

Acked-by: Linus Walleij 

Since this gpio-mvebu patch is in ARM SoC or somewhere I expect
whoever put it there to safeguide the fix to its destination.

Else poke me after 3.7-rc1 and I'll take it as a GPIO fix...

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 10/12] gpio: pcf857x: select IRQ_DOMAIN

[Linus Walleij]

On Fri, Sep 28, 2012 at 11:36 PM, Arnd Bergmann  wrote:

> Patch 6e20a0a4 "gpio: pcf857x: enable gpio_to_irq() support"
> added IRQ domain support to the pcf857x driver, but some configurations
> (e.g. davinci_all_defconfig) don't already enable CONFIG_IRQ_DOMAIN.

Excellent patch Arnd thanks for this!
Applied to my GPIO tree (where the offending patch is queued).

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] scripts/kernel-doc: check that non-void fcts describe their return value

[Yacine Belkadi]

If a function has a return value, but its kernel-doc comment doesn't contain a
"Return" section, then emit the following warning:

   Warning(file.h:129): No description found for return value of 'fct'

Note: This check emits a lot of warnings at the moment, because many functions
don't have a 'Return' doc section. So until the number of warnings goes
sufficiently down, the check is only performed in verbose mode.

Signed-off-by: Yacine Belkadi 
---
 scripts/kernel-doc |   34 ++
 1 file changed, 34 insertions(+)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 8fd107a..7f82aa8 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -130,6 +130,8 @@ use strict;
 # should document the "Context:" of the function, e.g. whether the functions
 # can be called form interrupts. Unlike other sections you can end it with an
 # empty line.
+# A non-void function should have a "Return:" section describing the return
+# value.
 # Example-sections should contain the string EXAMPLE so that they are marked
 # appropriately in DocBook.
 #
@@ -298,6 +300,7 @@ my $section_default = "Description";# default 
section
 my $section_intro = "Introduction";
 my $section = $section_default;
 my $section_context = "Context";
+my $section_return = "Return";
 
 my $undescribed = "-- undescribed --";
 
@@ -1767,6 +1770,28 @@ sub check_sections($$) {
 }
 
 ##
+# Checks the section describing the return value of a function.
+sub check_return_section {
+my $file = shift;
+my $declaration_name = shift;
+my $return_type = shift;
+
+# Ignore an empty return type (It's a macro)
+# Ignore functions with a "void" return type. (But don't ignore "void 
*")
+if (($return_type eq "") || ($return_type =~ /void\s*\w*\s*$/)) {
+return;
+}
+
+if (!defined($sections{$section_return}) ||
+$sections{$section_return} eq "") {
+print STDERR "Warning(${file}:$.): " .
+"No description found for return value of " .
+"'$declaration_name'\n";
+++$warnings;
+}
+}
+
+##
 # takes a function prototype and the name of the current file being
 # processed and spits out all the details stored in the global
 # arrays/hashes.
@@ -1837,6 +1862,15 @@ sub dump_function($$) {
my $prms = join " ", @parameterlist;
check_sections($file, $declaration_name, "function", $sectcheck, $prms, 
"");
 
+# This check emits a lot of warnings at the moment, because many
+# functions don't have a 'Return' doc section. So until the number
+# of warnings goes sufficiently down, the check is only performed in
+# verbose mode.
+# TODO: always perform the check.
+if ($verbose) {
+check_return_section($file, $declaration_name, $return_type);
+}
+
 output_declaration($declaration_name,
   'function',
   {'function' => $declaration_name,
-- 
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 1/2] Kernel-doc: Convention: Use a "Return" section to describe return values

[Yacine Belkadi]

Non-void functions should describe their return values in their kernel-doc
comments. Currently, some don't, others do in various forms. For example:
   * Return the result.
   * Return: The result.
   * Returns the result.
   * Returns: the result.
   * Return Value: The result.
   * @return: the result.
   * This function returns the result.
   * It will return the result.

Defining a convention would improve consistency of kernel-doc comments. It
would also help scripts/kernel-doc identify the text describing the return
value of a function. Thus allowing additional checks on the comments, and
suitable highlighting in the generated docs (man pages, html, etc).

So, as a convention, use a section named "Return" to describe the return
value of a function.

Signed-off-by: Yacine Belkadi 
---
 Documentation/kernel-doc-nano-HOWTO.txt |   13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/Documentation/kernel-doc-nano-HOWTO.txt 
b/Documentation/kernel-doc-nano-HOWTO.txt
index 3d8a977..99b57ab 100644
--- a/Documentation/kernel-doc-nano-HOWTO.txt
+++ b/Documentation/kernel-doc-nano-HOWTO.txt
@@ -64,6 +64,8 @@ Example kernel-doc function comment:
  * comment lines.
  *
  * The longer description can have multiple paragraphs.
+ *
+ * Return: Describe the return value of foobar.
  */
 
 The short description following the subject can span multiple lines
@@ -78,6 +80,8 @@ If a function parameter is "..." (varargs), it should be 
listed in
 kernel-doc notation as:
  * @...: description
 
+The return value, if any, should be described in a dedicated section
+named "Return".
 
 Example kernel-doc data structure comment.
 
@@ -222,6 +226,9 @@ only a "*").
 "section header:" names must be unique per function (or struct,
 union, typedef, enum).
 
+Use the section header "Return" for sections describing the return value
+of a function.
+
 Avoid putting a spurious blank line after the function name, or else the
 description will be repeated!
 
@@ -237,21 +244,21 @@ patterns, which are highlighted appropriately.
 NOTE 1:  The multi-line descriptive text you provide does *not* recognize
 line breaks, so if you try to format some text nicely, as in:
 
-  Return codes
+  Return:
 0 - cool
 1 - invalid arg
 2 - out of memory
 
 this will all run together and produce:
 
-  Return codes 0 - cool 1 - invalid arg 2 - out of memory
+  Return: 0 - cool 1 - invalid arg 2 - out of memory
 
 NOTE 2:  If the descriptive text you provide has lines that begin with
 some phrase followed by a colon, each of those phrases will be taken as
 a new section heading, which means you should similarly try to avoid text
 like:
 
-  Return codes:
+  Return:
 0: cool
 1: invalid arg
 2: out of memory
-- 
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: Instead of IP addresses the kernel started to show zero's

[Giuliano Pochini]

On Tue, 25 Sep 2012 14:26:07 +0400
Alexey Vlasov  wrote:

> Hi.
> 
> Here it writes LOG target from syslog:
> 
> Sep 25 03:23:49 l24 kernel: ip:SYN-OUTPUT-HTTP IN= OUT=eth0
> SRC= DST= LEN=60 TOS=0x00 PREC=0x00
> TTL=64 ID=22467 DF PROTO=TCP SPT=52829 DPT=80 WINDOW=14600 RES=0x00 SYN
> URGP=0 UID=564373 GID=155
> 
> This is recent, here go zero's again:
> # cat /proc/net/xt_recent/ssh-brute
> ...
> src= ttl: 122 last_seen: 4371027622 oldest_pkt: 1
> 4371027622
>
> Can it be fixed without restarting the box?
> Thanks!
>
> Kernel 3.4.6.

It look similar to a problem that occurred on some 3.x heavy loaded
machines. After a while they begin to send packets with dst=0.0.0.0. We had
to revert to 2.6 on our production machines.

tcpdump output looks like this:

17:06:29.272225 IP 0.0.0.0.http > 0.0.0.0.1687: . ack 232 win 15400
17:06:29.272671 IP 0.0.0.0.http > 0.0.0.0.1687: P 0:511(511) ack 232 win 15400
17:06:29.272689 IP 0.0.0.0.http > 0.0.0.0.1687: F 511:511(0) ack 232 win 15400
17:06:29.273249 IP 0.0.0.0.http > 0.0.0.0.65307: . ack 62552748 win 1006 

17:06:29.273662 IP 0.0.0.0.http > 0.0.0.0.65307: P 0:511(511) ack 1 win 1006 

17:06:29.273678 IP 0.0.0.0.http > 0.0.0.0.65307: F 511:511(0) ack 1 win 1006 

17:06:29.278683 IP 0.0.0.0.http > 0.0.0.0.12021: . ack 1 win 12240
17:06:29.288707 IP 0.0.0.0.http > 0.0.0.0.28308: . ack 1049058319 win 12420
17:06:29.289406 IP 0.0.0.0.http > 0.0.0.0.28308: . ack 57 win 12420
17:06:29.289834 IP 0.0.0.0.http > 0.0.0.0.28308: P 0:487(487) ack 57 win 12420
17:06:29.289851 IP 0.0.0.0.http > 0.0.0.0.28308: F 487:487(0) ack 57 win 12420
17:06:29.291767 IP 0.0.0.0.http > 0.0.0.0.11407: P 0:472(472) ack 171 win 1275 

17:06:29.292657 IP 0.0.0.0.http > 0.0.0.0.50511: . ack 1 win 14400
17:06:29.293502 IP 0.0.0.0.http > 0.0.0.0.12381: . ack 558 win 14960
17:06:29.295080 IP 0.0.0.0.http > 0.0.0.0.10980: . ack 2 win 16692

When the network traffic slows down the machine recovers to normal operation.

I found another report about this issue:

https://bbs.archlinux.org/viewtopic.php?id=129304


-- 
Giuliano.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] qla2xxx: silence two GCC warnings

[Rolf Eike Beer]

Am Sonntag 30 September 2012, 13:07:54 schrieb Paul Bolle:
> Compiling qla_gs.o (part of the qla2xxx module) triggers two GCC
> warnings:
> drivers/scsi/qla2xxx/qla_gs.c: In function ‘qla2x00_fdmi_rhba’:
> drivers/scsi/qla2xxx/qla_gs.c:1339:7: warning: array subscript is above
> array bounds [-Warray-bounds] drivers/scsi/qla2xxx/qla_gs.c: In function
> ‘qla2x00_fdmi_register’: drivers/scsi/qla2xxx/qla_gs.c:1663:15: warning:
> array subscript is above array bounds [-Warray-bounds]
>
> It seems that the sequence of a strcpy followed by a strlen confuses GCC
> when it is keeping track of array bounds here. (It is not clear to me
> which array triggers this warning and by how much GCC thinks the
> subscript is above its bounds. Neither is it clear to me why comparable
> code in these two functions doesn't trigger this warning.)
>
> The easiest way to silence these warnings is to hardcode the length of
> these two strings in the code here. The length used here is the length
> of the string, including its NUL terminator, rounded up to the next
> multiple of four.

This adds some magic values, which is asking for trouble once someone changes
the manufacturer string or something. What about something like this:

const char *qlogic = "QLogic Corporation";
strcpy(eiter->a.manufacturer, qlogic);
alen += round_up(strlen(qlogic), 4);
...

Eike

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

Re: [PATCH 6/10] bug.h: Replace __linktime_error with __compiletime_error

[Daniel Santos]

On 09/30/2012 08:22 AM, Borislav Petkov wrote:
> On Fri, Sep 28, 2012 at 09:04:35PM -0400, Steven Rostedt wrote:
>> On Fri, 2012-09-28 at 17:23 -0700, Josh Triplett wrote:
>>> On Fri, Sep 28, 2012 at 06:20:07PM -0500, Daniel Santos wrote:
 Signed-off-by: Daniel Santos 
 ---
  include/linux/bug.h |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/include/linux/bug.h b/include/linux/bug.h
 index aaac4bb..298a916 100644
 --- a/include/linux/bug.h
 +++ b/include/linux/bug.h
 @@ -73,7 +73,7 @@ extern int __build_bug_on_failed;
  #define BUILD_BUG()   \
do {\
extern void __build_bug_failed(void)\
 -  __linktime_error("BUILD_BUG failed");   \
 +  __compiletime_error("BUILD_BUG failed");\
__build_bug_failed();   \
} while (0)
>>> This change should either occur as part of patch 5 or before patch 5,
>>> not after.
>> I noticed the same thing and was about to comment on it.
>>
>> Please do not break bisectablity. All your patches should compile and
>> run at every step.
> And while we're at it, every patch upstream should have a commit message
> explaining why this is done. No matter how trivial it is, because after
> a sufficient amount of time passes, everyone tends to forget why this
> has been done.
>
> Thanks.
>
Ah, well thank you all for the guidance!

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ath/ath9k/ar9003_eeprom.c: Remove semicolon after if

[Peter Senna Tschudin]

The semantic patch that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@r1@
position p;
@@
if (...);@p

@script:python@
p0 << r1.p;
@@
// Emacs org-mode output
cocci.print_main("", p0)
cocci.print_secs("", p0)
// 

Signed-off-by: Peter Senna Tschudin 
---
NOTE: This patch changes the semantics.

Changes from V1:
Commit message
Added a note about semantics change

 drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c 
b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
index 5bbe505..189aeb2 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -2989,7 +2989,7 @@ static u32 ath9k_hw_ar9300_get_eeprom(struct ath_hw *ah,
case EEP_PAPRD:
if (AR_SREV_9462(ah))
return false;
-   if (!ah->config.enable_paprd);
+   if (!ah->config.enable_paprd)
return false;
return !!(pBase->featureEnable & BIT(5));
case EEP_CHAIN_MASK_REDUCE:
-- 
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/

HID: picoLCD: optimize for inactive debugfs

[Bruno Prémont]

Matthieu CASTET adjusted picolcd_debug_out_report() to only operate when
there is an active listener on debugfs for events.

His change got lost while splitting hid_picolcd.c, restore it.

Signed-off-by: Bruno Prémont 
---


diff --git a/drivers/hid/hid-picolcd_debugfs.c 
b/drivers/hid/hid-picolcd_debugfs.c
index 6ef03be..4809aa1 100644
--- a/drivers/hid/hid-picolcd_debugfs.c
+++ b/drivers/hid/hid-picolcd_debugfs.c
@@ -402,7 +402,7 @@ void picolcd_debug_out_report(struct picolcd_data *data,
 #define BUFF_SZ 256
 
/* Avoid unnecessary overhead if debugfs is disabled */
-   if (!hdev->debug_events)
+   if (list_empty(>debug_list))
return;
 
buff = kmalloc(BUFF_SZ, GFP_ATOMIC);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/7] uprobes: register/unregister bugfixes

[Oleg Nesterov]

Forgot to mention,

This is on top of "[PATCH 0/3] uprobes: mprotect fixes" series,
which is still waiting for review...

On 09/30, Oleg Nesterov wrote:
>
> Hello.
>
> Misc bugfixes, mostly register/unregister related.
>
> Note: 4/7 and especially 6/7 are the really ugly (but hopefully
> temporary) hacks. We already discussed this, we should inspect
> the original insn in uprobe_register(). But this is not easy, and
> we need something simple to fix (some of) the bugs right now.
>
> Even 7/7 is ugly. Imho UPROBE_SKIP_SSTEP should die as well but
> this is another story.
>
> Oleg.
>
>  arch/x86/kernel/uprobes.c |   16 +--
>  include/linux/uprobes.h   |   10 
>  kernel/events/uprobes.c   |  107 +++-
>  3 files changed, 77 insertions(+), 56 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 2/7] uprobes: Don't return success if alloc_uprobe() fails

[Oleg Nesterov]

If alloc_uprobe() fails uprobe_register() should return ENOMEM, not 0.

Signed-off-by: Oleg Nesterov 
---
 kernel/events/uprobes.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index a741ba7..3ec114c 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -813,7 +813,9 @@ int uprobe_register(struct inode *inode, loff_t offset, 
struct uprobe_consumer *
mutex_lock(uprobes_hash(inode));
uprobe = alloc_uprobe(inode, offset);
 
-   if (uprobe && !consumer_add(uprobe, uc)) {
+   if (!uprobe) {
+   ret = -ENOMEM;
+   } else if (!consumer_add(uprobe, uc)) {
ret = __uprobe_register(uprobe);
if (ret) {
uprobe->consumers = NULL;
-- 
1.5.5.1

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

[PATCH 6/7] uprobes: Fix uprobe_copy_insn() race with itself

[Oleg Nesterov]

install_breakpoint() is called under mm->mmap_sem, this protects
set_swbp() but not uprobe_copy_insn(). Two or more different tasks
can call install_breakpoint()->uprobe_copy_insn() at the same time,
this leads to numerous problems if UPROBE_COPY_INSN is not set.

Just for example, the second copy_insn() can corrupt the already
analyzed/fixuped uprobe->arch.insn and race with handle_swbp().

This patch simply adds uprobe->copy_mutex to serialize this code.
We could probably reuse ->consumer_rwsem, but this would mean that
consumer->handler() can not use mm->mmap_sem, not good.

Note: this is another temporary ugly hack until we move this logic
into uprobe_register().

Signed-off-by: Oleg Nesterov 
---
 kernel/events/uprobes.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 5c0c1b0..8410388 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -89,6 +89,7 @@ struct uprobe {
struct rb_node  rb_node;/* node in the rb tree */
atomic_tref;
struct rw_semaphore consumer_rwsem;
+   struct mutexcopy_mutex; /* TODO: kill me and 
UPROBE_COPY_INSN */
struct list_headpending_list;
struct uprobe_consumer  *consumers;
struct inode*inode; /* Also hold a ref to inode */
@@ -444,6 +445,7 @@ static struct uprobe *alloc_uprobe(struct inode *inode, 
loff_t offset)
uprobe->inode = igrab(inode);
uprobe->offset = offset;
init_rwsem(>consumer_rwsem);
+   mutex_init(>copy_mutex);
 
/* add to uprobes_tree, sorted on inode:offset */
cur_uprobe = insert_uprobe(uprobe);
@@ -578,6 +580,10 @@ static int uprobe_copy_insn(struct uprobe *uprobe, struct 
file *file,
if (uprobe->flags & UPROBE_COPY_INSN)
return ret;
 
+   mutex_lock(>copy_mutex);
+   if (uprobe->flags & UPROBE_COPY_INSN)
+   goto out;
+
ret = copy_insn(uprobe, file);
if (ret)
goto out;
@@ -598,6 +604,8 @@ static int uprobe_copy_insn(struct uprobe *uprobe, struct 
file *file,
uprobe->flags |= UPROBE_COPY_INSN;
ret = 0;
  out:
+   mutex_unlock(>copy_mutex);
+
return ret;
 }
 
-- 
1.5.5.1

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

[PATCH 7/7] uprobes: Fix the racy uprobe->flags manipulation

[Oleg Nesterov]

Multiple threads can manipulate uprobe->flags, this is obviously
unsafe. For example mmap can set UPROBE_COPY_INSN while register
tries to set UPROBE_RUN_HANDLER, the latter can also race with
can_skip_sstep() which clears UPROBE_SKIP_SSTEP.

Change this code to use bitops.

Signed-off-by: Oleg Nesterov 
---
 kernel/events/uprobes.c |   28 ++--
 1 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 8410388..3d8c815 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -79,11 +79,11 @@ static struct mutex uprobes_mmap_mutex[UPROBES_HASH_SZ];
 static atomic_t uprobe_events = ATOMIC_INIT(0);
 
 /* Have a copy of original instruction */
-#define UPROBE_COPY_INSN   0x1
+#define UPROBE_COPY_INSN   0
 /* Dont run handlers when first register/ last unregister in progress*/
-#define UPROBE_RUN_HANDLER 0x2
+#define UPROBE_RUN_HANDLER 1
 /* Can skip singlestep */
-#define UPROBE_SKIP_SSTEP  0x4
+#define UPROBE_SKIP_SSTEP  2
 
 struct uprobe {
struct rb_node  rb_node;/* node in the rb tree */
@@ -94,7 +94,7 @@ struct uprobe {
struct uprobe_consumer  *consumers;
struct inode*inode; /* Also hold a ref to inode */
loff_t  offset;
-   int flags;
+   unsigned long   flags;
struct arch_uprobe  arch;
 };
 
@@ -423,7 +423,7 @@ static struct uprobe *insert_uprobe(struct uprobe *uprobe)
spin_unlock(_treelock);
 
/* For now assume that the instruction need not be single-stepped */
-   uprobe->flags |= UPROBE_SKIP_SSTEP;
+   __set_bit(UPROBE_SKIP_SSTEP, >flags);
 
return u;
 }
@@ -466,7 +466,7 @@ static void handler_chain(struct uprobe *uprobe, struct 
pt_regs *regs)
 {
struct uprobe_consumer *uc;
 
-   if (!(uprobe->flags & UPROBE_RUN_HANDLER))
+   if (!test_bit(UPROBE_RUN_HANDLER, >flags))
return;
 
down_read(>consumer_rwsem);
@@ -577,11 +577,11 @@ static int uprobe_copy_insn(struct uprobe *uprobe, struct 
file *file,
 {
int ret = 0;
 
-   if (uprobe->flags & UPROBE_COPY_INSN)
+   if (test_bit(UPROBE_COPY_INSN, >flags))
return ret;
 
mutex_lock(>copy_mutex);
-   if (uprobe->flags & UPROBE_COPY_INSN)
+   if (test_bit(UPROBE_COPY_INSN, >flags))
goto out;
 
ret = copy_insn(uprobe, file);
@@ -601,7 +601,7 @@ static int uprobe_copy_insn(struct uprobe *uprobe, struct 
file *file,
UPROBE_SWBP_INSN_SIZE > PAGE_SIZE);
 
smp_wmb(); /* pairs with rmb() in find_active_uprobe() */
-   uprobe->flags |= UPROBE_COPY_INSN;
+   set_bit(UPROBE_COPY_INSN, >flags);
ret = 0;
  out:
mutex_unlock(>copy_mutex);
@@ -852,7 +852,7 @@ int uprobe_register(struct inode *inode, loff_t offset, 
struct uprobe_consumer *
uprobe->consumers = NULL;
__uprobe_unregister(uprobe);
} else {
-   uprobe->flags |= UPROBE_RUN_HANDLER;
+   set_bit(UPROBE_RUN_HANDLER, >flags);
}
}
 
@@ -885,7 +885,7 @@ void uprobe_unregister(struct inode *inode, loff_t offset, 
struct uprobe_consume
if (consumer_del(uprobe, uc)) {
if (!uprobe->consumers) {
__uprobe_unregister(uprobe);
-   uprobe->flags &= ~UPROBE_RUN_HANDLER;
+   clear_bit(UPROBE_RUN_HANDLER, >flags);
}
}
 
@@ -1346,10 +1346,10 @@ bool uprobe_deny_signal(void)
  */
 static bool can_skip_sstep(struct uprobe *uprobe, struct pt_regs *regs)
 {
-   if (uprobe->flags & UPROBE_SKIP_SSTEP) {
+   if (test_bit(UPROBE_SKIP_SSTEP, >flags)) {
if (arch_uprobe_skip_sstep(>arch, regs))
return true;
-   uprobe->flags &= ~UPROBE_SKIP_SSTEP;
+   clear_bit(UPROBE_SKIP_SSTEP, >flags);
}
return false;
 }
@@ -1428,7 +1428,7 @@ static struct uprobe *find_active_uprobe(unsigned long 
bp_vaddr, int *is_swbp)
 * new and not-yet-analyzed uprobe at the same address, restart.
 */
smp_rmb(); /* pairs with wmb() in install_breakpoint() */
-   if (uprobe && unlikely(!(uprobe->flags & UPROBE_COPY_INSN))) {
+   if (uprobe && unlikely(!test_bit(UPROBE_COPY_INSN, >flags))) {
uprobe = NULL;
*is_swbp = 0;
}
-- 
1.5.5.1

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

[PATCH 5/7] uprobes: Introduce uprobe_copy_insn()

[Oleg Nesterov]

Preparation. Extract the copy_insn/arch_uprobe_analyze_insn code
from install_breakpoint() into the new helper, uprobe_copy_insn().

And move uprobe->flags defines from uprobes.h to uprobes.c, nobody
else can use them anyway.

Signed-off-by: Oleg Nesterov 
---
 include/linux/uprobes.h |   10 
 kernel/events/uprobes.c |   60 ---
 2 files changed, 41 insertions(+), 29 deletions(-)

diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index 18d839d..2459457 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -35,16 +35,6 @@ struct inode;
 # include 
 #endif
 
-/* flags that denote/change uprobes behaviour */
-
-/* Have a copy of original instruction */
-#define UPROBE_COPY_INSN   0x1
-
-/* Dont run handlers when first register/ last unregister in progress*/
-#define UPROBE_RUN_HANDLER 0x2
-/* Can skip singlestep */
-#define UPROBE_SKIP_SSTEP  0x4
-
 struct uprobe_consumer {
int (*handler)(struct uprobe_consumer *self, struct pt_regs *regs);
/*
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index a81080f..5c0c1b0 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -78,6 +78,13 @@ static struct mutex uprobes_mmap_mutex[UPROBES_HASH_SZ];
  */
 static atomic_t uprobe_events = ATOMIC_INIT(0);
 
+/* Have a copy of original instruction */
+#define UPROBE_COPY_INSN   0x1
+/* Dont run handlers when first register/ last unregister in progress*/
+#define UPROBE_RUN_HANDLER 0x2
+/* Can skip singlestep */
+#define UPROBE_SKIP_SSTEP  0x4
+
 struct uprobe {
struct rb_node  rb_node;/* node in the rb tree */
atomic_tref;
@@ -563,6 +570,37 @@ static int copy_insn(struct uprobe *uprobe, struct file 
*filp)
return __copy_insn(mapping, filp, uprobe->arch.insn, bytes, 
uprobe->offset);
 }
 
+static int uprobe_copy_insn(struct uprobe *uprobe, struct file *file,
+   struct mm_struct *mm, unsigned long vaddr)
+{
+   int ret = 0;
+
+   if (uprobe->flags & UPROBE_COPY_INSN)
+   return ret;
+
+   ret = copy_insn(uprobe, file);
+   if (ret)
+   goto out;
+
+   ret = -ENOTSUPP;
+   if (is_swbp_insn((uprobe_opcode_t *)uprobe->arch.insn))
+   goto out;
+
+   ret = arch_uprobe_analyze_insn(>arch, mm, vaddr);
+   if (ret)
+   goto out;
+
+   /* write_opcode() assumes we don't cross page boundary */
+   BUG_ON((uprobe->offset & ~PAGE_MASK) +
+   UPROBE_SWBP_INSN_SIZE > PAGE_SIZE);
+
+   smp_wmb(); /* pairs with rmb() in find_active_uprobe() */
+   uprobe->flags |= UPROBE_COPY_INSN;
+   ret = 0;
+ out:
+   return ret;
+}
+
 static int
 install_breakpoint(struct uprobe *uprobe, struct mm_struct *mm,
struct vm_area_struct *vma, unsigned long vaddr)
@@ -580,25 +618,9 @@ install_breakpoint(struct uprobe *uprobe, struct mm_struct 
*mm,
if (!uprobe->consumers)
return 0;
 
-   if (!(uprobe->flags & UPROBE_COPY_INSN)) {
-   ret = copy_insn(uprobe, vma->vm_file);
-   if (ret)
-   return ret;
-
-   if (is_swbp_insn((uprobe_opcode_t *)uprobe->arch.insn))
-   return -ENOTSUPP;
-
-   ret = arch_uprobe_analyze_insn(>arch, mm, vaddr);
-   if (ret)
-   return ret;
-
-   /* write_opcode() assumes we don't cross page boundary */
-   BUG_ON((uprobe->offset & ~PAGE_MASK) +
-   UPROBE_SWBP_INSN_SIZE > PAGE_SIZE);
-
-   smp_wmb(); /* pairs with rmb() in find_active_uprobe() */
-   uprobe->flags |= UPROBE_COPY_INSN;
-   }
+   ret = uprobe_copy_insn(uprobe, vma->vm_file, mm, vaddr);
+   if (ret)
+   return ret;
 
/*
 * set MMF_HAS_UPROBES in advance for uprobe_pre_sstep_notifier(),
-- 
1.5.5.1

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

[PATCH 4/7] uprobes: Fix handle_swbp() vs unregister() + register() race

[Oleg Nesterov]

Strictly speaking this race was added by me in 56bb4cf6. However
I think that this bug is just another indication that we should
move copy_insn/uprobe_analyze_insn code from install_breakpoint()
to uprobe_register(), there are a lot of other reasons for that.
Until then, add a hack to close the race.

A task can hit uprobe U1, but before it calls find_uprobe() this
uprobe can be unregistered *AND* another uprobe U2 can be added to
uprobes_tree at the same inode/offset. In this case handle_swbp()
will use the not-fully-initialized U2, in particular its arch.insn
for xol.

Add the additional !UPROBE_COPY_INSN check into find_active_uprobe,
if this flag is not set we simply restart as if the new uprobe was
not inserted yet. This is not very nice, we need barriers, but we
will remove this hack when we change uprobe_register().

Note: with or without this patch install_breakpoint() can race with
itself, yet another reson to kill UPROBE_COPY_INSN altogether. And
even the usage of uprobe->flags is not safe. See the next patches.

Signed-off-by: Oleg Nesterov 
---
 kernel/events/uprobes.c |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 6058231..a81080f 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -596,6 +596,7 @@ install_breakpoint(struct uprobe *uprobe, struct mm_struct 
*mm,
BUG_ON((uprobe->offset & ~PAGE_MASK) +
UPROBE_SWBP_INSN_SIZE > PAGE_SIZE);
 
+   smp_wmb(); /* pairs with rmb() in find_active_uprobe() */
uprobe->flags |= UPROBE_COPY_INSN;
}
 
@@ -1391,6 +1392,16 @@ static struct uprobe *find_active_uprobe(unsigned long 
bp_vaddr, int *is_swbp)
if (!uprobe && test_and_clear_bit(MMF_RECALC_UPROBES, >flags))
mmf_recalc_uprobes(mm);
up_read(>mmap_sem);
+   /*
+* TODO: move copy_insn/etc into _register and remove this hack.
+* After we hit the bp, _unregister + _register can install the
+* new and not-yet-analyzed uprobe at the same address, restart.
+*/
+   smp_rmb(); /* pairs with wmb() in install_breakpoint() */
+   if (uprobe && unlikely(!(uprobe->flags & UPROBE_COPY_INSN))) {
+   uprobe = NULL;
+   *is_swbp = 0;
+   }
 
return uprobe;
 }
-- 
1.5.5.1

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

[PATCH 1/7] uprobes/x86: Only rep+nop can be emulated correctly

[Oleg Nesterov]

__skip_sstep() correctly detects the "nontrivial" nop insns,
but since it doesn't update regs->ip we can not really skip
"0x0f 0x1f | 0x0f 0x19 | 0x87 0xc0", the probed application
is killed by SIGILL'ed handle_swbp().

Remove these additional checks. If we want to implement this
correctly we need to know the full insn length to update ->ip.

rep* + nop is fine even without updating ->ip.

Signed-off-by: Oleg Nesterov 
---
 arch/x86/kernel/uprobes.c |   16 ++--
 1 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index 9538f00..aafa555 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -651,31 +651,19 @@ void arch_uprobe_abort_xol(struct arch_uprobe *auprobe, 
struct pt_regs *regs)
 
 /*
  * Skip these instructions as per the currently known x86 ISA.
- * 0x66* { 0x90 | 0x0f 0x1f | 0x0f 0x19 | 0x87 0xc0 }
+ * rep=0x66*; nop=0x90
  */
 static bool __skip_sstep(struct arch_uprobe *auprobe, struct pt_regs *regs)
 {
int i;
 
for (i = 0; i < MAX_UINSN_BYTES; i++) {
-   if ((auprobe->insn[i] == 0x66))
+   if (auprobe->insn[i] == 0x66)
continue;
 
if (auprobe->insn[i] == 0x90)
return true;
 
-   if (i == (MAX_UINSN_BYTES - 1))
-   break;
-
-   if ((auprobe->insn[i] == 0x0f) && (auprobe->insn[i+1] == 0x1f))
-   return true;
-
-   if ((auprobe->insn[i] == 0x0f) && (auprobe->insn[i+1] == 0x19))
-   return true;
-
-   if ((auprobe->insn[i] == 0x87) && (auprobe->insn[i+1] == 0xc0))
-   return true;
-
break;
}
return false;
-- 
1.5.5.1

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

[PATCH 3/7] uprobes: Do not delete uprobe if uprobe_unregister() fails

[Oleg Nesterov]

delete_uprobe() must not be called if register_for_each_vma(false)
fails to remove all breakpoints, __uprobe_unregister() is correct.
The problem is that register_for_each_vma(false) always returns 0
and thus this logic does not work.

1. Change verify_opcode() to return 0 rather than -EINVAL when
   unregister detects the !is_swbp insn, we can treat this case
   as success and currently unregister paths ignore the error
   code anyway.

2. Change remove_breakpoint() to propagate the error code from
   write_opcode().

3. Change register_for_each_vma(is_register => false) to remove
   as much breakpoints as possible but return non-zero if
   remove_breakpoint() fails at least once.

Signed-off-by: Oleg Nesterov 
---
 kernel/events/uprobes.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 3ec114c..6058231 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -203,7 +203,7 @@ static int verify_opcode(struct page *page, unsigned long 
vaddr, uprobe_opcode_t
return 0;
} else {
if (!is_swbp)   /* unregister: was it changed by us? */
-   return -EINVAL;
+   return 0;
}
 
return 1;
@@ -616,15 +616,15 @@ install_breakpoint(struct uprobe *uprobe, struct 
mm_struct *mm,
return ret;
 }
 
-static void
+static int
 remove_breakpoint(struct uprobe *uprobe, struct mm_struct *mm, unsigned long 
vaddr)
 {
/* can happen if uprobe_register() fails */
if (!test_bit(MMF_HAS_UPROBES, >flags))
-   return;
+   return 0;
 
set_bit(MMF_RECALC_UPROBES, >flags);
-   set_orig_insn(>arch, mm, vaddr);
+   return set_orig_insn(>arch, mm, vaddr);
 }
 
 /*
@@ -740,7 +740,7 @@ static int register_for_each_vma(struct uprobe *uprobe, 
bool is_register)
struct mm_struct *mm = info->mm;
struct vm_area_struct *vma;
 
-   if (err)
+   if (err && is_register)
goto free;
 
down_write(>mmap_sem);
@@ -756,7 +756,7 @@ static int register_for_each_vma(struct uprobe *uprobe, 
bool is_register)
if (is_register)
err = install_breakpoint(uprobe, mm, vma, info->vaddr);
else
-   remove_breakpoint(uprobe, mm, info->vaddr);
+   err |= remove_breakpoint(uprobe, mm, info->vaddr);
 
  unlock:
up_write(>mmap_sem);
-- 
1.5.5.1

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

[PATCH 0/7] uprobes: register/unregister bugfixes

[Oleg Nesterov]

Hello.

Misc bugfixes, mostly register/unregister related.

Note: 4/7 and especially 6/7 are the really ugly (but hopefully
temporary) hacks. We already discussed this, we should inspect
the original insn in uprobe_register(). But this is not easy, and
we need something simple to fix (some of) the bugs right now.

Even 7/7 is ugly. Imho UPROBE_SKIP_SSTEP should die as well but
this is another story.

Oleg.

 arch/x86/kernel/uprobes.c |   16 +--
 include/linux/uprobes.h   |   10 
 kernel/events/uprobes.c   |  107 +++-
 3 files changed, 77 insertions(+), 56 deletions(-)

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

Re: The 10ms averager in fair.c

[Uwaysi Bin Kareem]

Just to illustrate, you have a filter that lasts 10ms, and a cpu process  
that lasts 100uS


Original spike

5 |
4 |
3 |
2 |
1 |
0 |
0ms___10ms
Filtered spike

5
4
3
2
1   .
0..  ..
0ms10ms

Not only is the filtered spike, much lower, but it lasts long beyond the  
100uS spike. (10ms). Why would that be used in something that should  
represent cpu-usage?


Peace Be With You.


On Sun, 30 Sep 2012 13:44:14 +0200, Uwaysi Bin Kareem  
 wrote:



Hiya. I just had an initial look at fair.c

There seems to be a 10ms averager in there?

You are aware that that means you work on delayed values?

Isn`t that counterintuitive to the principle of sharing?

That means short bursts of cpu-use will be filtered out, and given less  
cpu time.
Starting applications won`t have their cpu-usage before 5ms, which is  
quite a bit on modern machines. Well if you use a linearphase filter, I  
don`t know what kind of averager you use. The best would ofcourse be to  
use a minimalphase gaussian averager. Which might be overkill. Atleast a  
one-pole iir, buf = buf + (-buf + in) * cut)); One pole IIRs also have a  
better frequency response.


When you are working with low-latencies, wouldn`t it be better if such  
things are tuned for target latency. I think few care about latency  
after 0.2ms. So say the filter should be set to 0.4ms max.


Why would you want to filter cpu-usage also really?

Peace Be With You.

(please CC me.)

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

Re: [PATCH] sysfs: sysfs_pathname/sysfs_add_one: Use strlcat() instead of strcat()

[Geert Uytterhoeven]

Hi Greg,

On Sun, Sep 30, 2012 at 4:49 PM, Greg Kroah-Hartman
 wrote:
> On Sat, Sep 29, 2012 at 10:23:19PM +0200, Geert Uytterhoeven wrote:
>> The warning check for duplicate sysfs entries can cause a buffer overflow
>> when printing the warning, as strcat() doesn't check buffer sizes.
>> Use strlcat() instead.
>
> As the comment said, we knew about this, but I have never seen it, do
> you know of a way to trigger it?

I expected there would be a check somewhere else in the code, so we can
never overflow here. But I did manage to overflow the buffer by having a real
long name (4060 characters) in a conflicting mfd_cell.
There may be other ways.

I don't know how likely it is to trigger in a real world scenario. Is
there a limit
on the depth of sysfs? Or can it go unbounded, e.g. by cascading USB hubs?

>> Cc: sta...@vger.kernel.org
>
> Given that I don't know of any way to actually hit this problem, is it
> really needed for older kernel releases?

That's up to you to decide...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.6-rc7 32-bit PAE miscalculates dirty page limits

[H. Peter Anvin]

On 09/30/2012 02:38 AM, Pierre Beck wrote:

Hi,

there seems to be a bug in either ext4 or VM code triggered with 16 GB
memory when compiled with 32-bit and PAE. dirty_background_ratio
defaults to 10, dirty_ratio to 20. But in effect, dirty pages are
strongly limited (zero or negative?). I observed extreme I/O wait states
and slow disk access. A quick cure was to set dirty_bytes and
dirty_background_bytes to sane values, overriding the ratios. An
educated guess: the result of dirty_ratio calculation is stored as an
unsigned 32-bit integer and overflows?



Seriously, why are you running a 32-bit kernel on memory sizes this 
large?  Yes, in theory it should work up to 64 GB but claims are that 
the kernel doesn't even boot if you try...


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

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

Re: hot CPU with 3.6.0-rc7+ and intel graphic

[Samuel Ortiz]

Hi,

On Sun, Sep 30, 2012 at 05:06:43PM +0300, Anca Emanuel wrote:
> On Sun, Sep 30, 2012 at 4:37 PM, Feng Tang  wrote:
> > Where can we get a powertop-2.1? I searched google and found
> > git clone git://git.kernel.org/pub/scm/status/powertop/powertop.git
> > is null now.
> 
> https://01.org/powertop/
> https://01.org/powertop/sites/default/files/downloads/powertop-2.1.tar.gz
> 
> I'm not sure about this source.
> Samuel, can you confirm this is an official Intel site ?
Yes, 01.org is an official Intel website.

Cheers,
Samuel.

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

Re: [PATCH v2] psmouse: mitigate failing-mouse symptoms

[Alessandro Rubini]

> I think this would be less controversial if the run-time default were
> to disable the feature.

Yes, that's the common sensible path to new little-tested features.
As you say, it may become enabled by default over time.

Then, I think it would be good to have a specific sub-structure for
this stuff. It would allow this:

  +   psmouse->err_log_base = 0;
  +   psmouse->interval_base = 0;
  +   psmouse->hotio_log_base = 0;
  +   psmouse->err_log_counter = 0;
  +   psmouse->interval_pkts = 0;
  +   psmouse->hotio_log_counter = 0;

to be replaced with a memset. I also think it would make it clearer
what these are:

  +   unsigned long interval_base;
  +   unsigned long interval_pkts;
  +   unsigned long hotio_log_base;
  +   unsigned long hotio_log_counter;
  +   unsigned long err_log_base;
  +   unsigned long err_log_counter;

to the casual reader.

This is only a suggestion, though.

thanks
/alessandro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: ABI change for setitimer(2) [in feature-removal-schedule.txt]

[Linus Torvalds]

On Sat, Sep 29, 2012 at 11:30 PM, Michael Kerrisk
 wrote:
>
>> I think the whole "let's deprecate this six months into the future" is
>> unnecessary. Yes, it may well be worth doing for something with bigger
>> consequences, but I think that for something like this, it's just
>> overthinking the issue.
>
> When it comes to ABIs, I think there *is* value in a lead time on the
> change. This particular example is a good example of why.

No. This whole example is a good example of the fact that YOU SHOULD
NOT MAKE ABI CHANGES.

I don't understand why this seems to be so hard for people to understand.

There are exactly *zero* reasons to change the ABI for its own sake,
and this whole thread is a wonderful example of how F*CKING STUPID it
was to even consider it.

There are real and valid reasons to change the ABI, but for every
single one of them, there is some external issue:

 - security. We've had cases where we had an ABI that simply exposed
too much information.

 - implementation issues. Sometimes, we've done something really
really badly, and some subtle ABI issue may simply not work. This is
basically never about normal system calls used by normal applications,
though - it's about things like the whole iptables flaps etc.

 - actual real applications breaking. We've had cases where we simply
did things wrong, and portable applications broke. Then we can *try*
to fix it, and see if something else breaks from that.

And quite frankly, for all but the security case, even then we're
often better off at least having a compatibilty layer for the old
cases, even if it was bad and wrong (example: the very original linux
'select()' timeout behavior, where Linux did the documented thing, but
nobody else did. Or the various versions of 'stat()' we've had. Or the
inotify/dnotify/fsnotify things).

Occasionally some compat model may not be worth it (if the interface
is too specialized and there really is just one or two system apps
that use it), but that's very very rare to the point where it
shouldn't even be considered an issue.

Quite frankly, our most common ABI change is that we don't even
realize that something changed. And then people may or may not notice
it. And we've had cases where the same system call returned
*different* things for different subsystems, and we tried to make it
at least internally consistent.

But the "premeditated ABI change just for the reason of an ABI
change"? It's bullshit. And it's bullshit whether it shows up in
feature-removal or not.

(The whole feature-removal file is BS, for that matter, but that's a
different issue).

SO STOP DOING ABI CHANGES. WE DON'T DO THEM.

The absolute worst thing a kernel can do is "change the user-level
interfaces". It has to be done occasionally (see above), and sometimes
we do it by mistake, but anybody who does it on purpose "just because"
should not be involved in kernel development (or library development
for that matter).

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 v2] psmouse: mitigate failing-mouse symptoms

[Jonathan Nieder]

Hi Jim,

In January, 2011, Jim Hill wrote:

> Keep a failing PS/2 mouse usable until it's convenient to replace it.
> Filter incoming packets: drop invalid ones and attempt to correct for
> dropped bytes.
>
> New parameter 'filter' makes filtering and logging selectable, set to 0
> to shut off all effects.
[...]
> My mouse failed while in XP, but I didn't know it - it seemed it'd need
> cleaning soon. On booting into Linux, it was dangerous, wild slews and
> random clicks.  The difference was consistent, making it seem the
> problem wasn't the mouse.

I think this would be less controversial if the run-time default were
to disable the feature.  Then if lots of people are setting the
parameter and the idea proves itself, the default could change, and in
the meantime, people with broken setups would know about the breakage
and get a chance to look for other problems.

What do you think?

Thanks for your work,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RFC] pkt_sched: QFQ Plus: fair-queueing service at DRR cost

[Paolo Valente]

Hi,
this patch turns QFQ into QFQ+, a faster variant of QFQ that groups
classes into aggregates, and uses the original QFQ scheduling
algorithm to schedule aggregates instead of single classes. An
aggregate is made of at most M classes, all with the same weight and
maximum packet size.  M is equal to the minimum between tx_queue_len+1
and 8 (value chosen to get a good trade-off between execution time and
service guarantees). QFQ+ associates each aggregate with a budget
equal to the maximum packet size for the classes in the aggregate,
multiplied by the number of classes of the aggregate. Once selected an
aggregate for service, QFQ+ dequeues only the packets of its classes,
until the aggregate finishes its budget. Finally, within an aggregate,
classes are scheduled with DRR. In my tests, described below, the
execution time of QFQ+ with M=8 was from 16% to 31% lower than that of
QFQ, and close to that of DRR.

QFQ+ does not use packet lengths for computing aggregate timestamps,
but budgets. Hence it does not need to modify any timestamp if the
head packet of a class changes. As a consequence, differently from
QFQ, which uses head-packet lengths to compute class timestamps, QFQ+
does not need further modifications to correctly schedule also
non-leaf classes and classes with non-FIFO qdiscs. Finally, QFQ+ is
more robust than QFQ against corruption of the data structures
implementing the bucket lists. A detailed description of QFQ+ can be
found in [1].

As for service guarantees, thanks to the way how M is computed, the
service of QFQ+ is close to the one of QFQ. For example, as proved in
[1], under QFQ+ every packet of a given class is guaranteed the same
worst-case completion time as under QFQ, plus an additional delay
equal to the transmission time, at the rate reserved to the class, of
three maximum-size packet. See [1, Section 7.1] for a numerical
comparison among the packet delays guaranteed by QFQ+, QFQ and DRR.

I measured the execution time of QFQ+, DRR and QFQ using the testing
environment [2]. In particular, for each scheduler I measured the
average total execution time of a packet enqueue plus a packet
dequeue.  For practical reasons, in this testing environment each
enqueue is also charged for the cost of generating and
discarding an empty, fixed-size packet (using a free list). The
following table reports the results with an i7-2760QM, against four
different class sets. Time is measured in nanoseconds, while each set
or subset of classes is denoted as -w, where
 and  are, respectively, the number of classes
and the weight of every class in the set/subset (for example, 250-w1
stands for 250 classes with weight 1). For QFQ+, the table shows the
results for the two extremes for M: 1 and 8 (see [1, Section 7.2] for
results with other values of M and for more information).

 ---
| Set of  |  QFQ+ (M) |   DRR  QFQ  |
| classes |1  8   | |
|---| 
| 1k-w1   |   89 63   |56   81  |
|---|
| 500-w1, |   | |
| 250-w2, |  102 71   |87  103  |
| 250-w4  |   | |
|---|
| 32k-w1  |  267225   |   173  257  |
|---|
| 16k-w1, |   | |
| 8k-w2,  |  253187   |   252  257  |
| 8k-w4   |   | |
 ---

About DRR, it achieves its best performance when all the classes have
the same weight. This is fortunate, because in such scenarios it is
actually pointless to use a fair-queueing scheduler, as the latter
would provide the same quality of service as DRR. In contrast, when
classes have differentiated weights and the better service properties
of QFQ+ make a difference, QFQ+ has better performance than DRR. It
happens mainly because QFQ+ dequeues packets in an order that causes
about 8% less cache misses than DRR. As for the number of
instructions, QFQ+ executes instead about 7% more instructions than
DRR, whereas QFQ executes from 25% to 34% more instructions than DRR.

Paolo

[1] P. Valente, "Reducing the Execution Time of Fair-Queueing Schedulers"
http://algo.ing.unimo.it/people/paolo/agg-sched/agg-sched.pdf

[2] http://algo.ing.unimo.it/people/paolo/agg-sched/test-env.tgz

Signed-off-by: Paolo Valente 
---
 net/sched/sch_qfq.c |  826 ---
 1 file changed, 592 insertions(+), 234 deletions(-)

diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
index 211a212..af8f2a2 100644
--- a/net/sched/sch_qfq.c
+++ b/net/sched/sch_qfq.c
@@ -1,7 +1,8 @@
 /*
- * net/sched/sch_qfq.c Quick Fair Queueing Scheduler.
+ * net/sched/sch_qfq.c Quick Fair Queueing Plus Scheduler.
  *
  * Copyright (c) 

Re: ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

[Krzysztof Halasa]

Russell King - ARM Linux  writes:

>> Note I'm not only doing ARM, but also X86 and MIPS, with additional code
>> shared between them, and the "stable" part of it is what I'm paid for.
>> I can't simply work with arm-soc, none of my platforms will even boot
>> with pure arm-soc.
>
> I'm assuming that Linus' -rc kernels work for you, yes?

No, but it's OK :-)

I meant I need additional code for a) ARM and MIPS-based boards (off the
shelf by Ubiquity, Gateworks etc., support ported mostly from OpenWRT),
b) custom hardware used only by us.

I hope to eventually submit a) upstream, then arm-soc and Linus' trees
would work for me. I know it's a mess, but for now I have no options.

BTW the situation with hardware supported only by OpenWRT is a part of
the equation.
-- 
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] usb: dwc3: core: add dt support for dwc3 core

[Sergei Shtylyov]

Hello.

On 28-09-2012 14:53, Kishon Vijay Abraham I wrote:


Added dwc3 support for dwc3 core and update the documentation with
device tree binding information.

Signed-off-by: Kishon Vijay Abraham I

[...]


diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 08a5738..0c17a7a 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c

[...]

@@ -602,11 +601,22 @@ static int __devexit dwc3_remove(struct platform_device 
*pdev)
return 0;
  }

+#ifdef CONFIG_OF
+static const struct of_device_id of_dwc3_matach[] = {


I guess you meant 'of_dwc3_match' here and below?



+   {
+   .compatible = "synopsis,dwc3"
+   },
+   { },
+};
+MODULE_DEVICE_TABLE(of, of_dwc3_matach);
+#endif
+
  static struct platform_driver dwc3_driver = {
.probe  = dwc3_probe,
.remove = __devexit_p(dwc3_remove),
.driver = {
.name   = "dwc3",
+   .of_match_table = of_match_ptr(of_dwc3_matach),
},
  };
  


WBR, Sergei

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

Re: [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib

[Roland Stigge]

On 30/09/12 17:19, Stijn Devriendt wrote:
>> If I understand correctly, it's a violation (single-value should hold
>> for read and write).
>>
>> To solve it, I have the following in mind: /sys/.../gpiogroupXXX/
>> contains files "bit0" ... "bit31" which contain a gpio number each,
>> empty if "unconnected".
> 
> Unfortunately that means you can't atomically create a group.

I don't see a big advantage of having atomic create/request. Most
important is set/get, isn't it? I assume the following usage pattern:

* Create(request) - non atomic (maybe atomic but why not add GPIOs later?)
* Set - atomic
* Get - atomic
* ...

> It also creates a mess to keep ordering intact and to either
> keep the current pin state or override it at allocation-time.

Ordering should stay intact, and later add/delete operations could be
possible. I meant bit0 ... bit31 in the gpio block as such:

bit0  - "80"
bit1  - ""  (i.e. unconnected)
bit2  - "85"
bit3  - "2"
...
bit31 - ""

This scheme can support multiple gpio_chips, as discussed with Linus and
JC, which of course can't always guarantee real simultaneous I/O but
provide virtual I/O word access (32bit/64bit).

> Rules are rules, but why make the interface overly complex when
> the multi-value file is saner, cleaner and simpler?

Simply because they won't (and probably shouldn't) accept it mainline.

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

Re: [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib

[Stijn Devriendt]

On Sun, Sep 30, 2012 at 5:09 PM, Roland Stigge  wrote:
> Hi Stijn,
>
> On 30/09/12 16:52, Stijn Devriendt wrote:
>>> One question: How did you solve the one-value-per-file in the sysfs
>>> interface?
>>>
>> By exporting the group as a whole:
>> /sys/.../gpiogroup248/value
>> where value contains a decimal representing the group value.
>> Again, this respects the ordering of the pins:
>>
>> Actual pins: 0x2D (b 0010 1101)
>> Selected pins: 6 3 0 1
>> Readout: 6 (b 0 1 1 0)
>>
>> The export sysfs file does, however, accept multiple gpio IDs for groups.
>> Not sure if this is a 'violation' per se...
>
> If I understand correctly, it's a violation (single-value should hold
> for read and write).
>
> To solve it, I have the following in mind: /sys/.../gpiogroupXXX/
> contains files "bit0" ... "bit31" which contain a gpio number each,
> empty if "unconnected".

Unfortunately that means you can't atomically create a group.
It also creates a mess to keep ordering intact and to either
keep the current pin state or override it at allocation-time.

Rules are rules, but why make the interface overly complex when
the multi-value file is saner, cleaner and simpler?
I know I'm on the happy/corporate side of things and I can violate
whatever rule I can if it gets our product shipping, but I'd still
propose to have the multi-value approach, even in mainline.

Regards,
Stijn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: hot CPU with 3.6.0-rc7+ and intel graphic

[Toralf Förster]

On 09/30/2012 03:37 PM, Feng Tang wrote:
> Hi Toralf,
 Really weird, my commit only change the lpc_ich.c which affects the TCO_WDT
> driver. but from your .config file, neither CONFIG_LPC_ICH nor the
>  CONFIG_ITCO_WDT is enabled, which means the commit should not affect
> your kernel, could you double check the .config file?
> 
> Thanks,
> Feng

I accidently forgot (at least one time) to mount the external /boot
partition before installing teh test kernel image - therefore both
bisecting (and the revert of the "guilty" commit" to double check it)
were done using a wrong test case

:-[

Sry for the noise - and the waste of time - grr.


-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib

[Stijn Devriendt]

On Sun, Sep 30, 2012 at 12:34 PM, Roland Stigge  wrote:
> On 29/09/12 21:57, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> Problem here is that it's only an intermediate format since hardware
>>> often needs special preparation of the data.
>>>
>>> But will evaluate what makes most sense.
>> the key point here is to avoid to manipualte data each time we call
>> gpio_block_set
>>
>> hardware specific will have to be handle at driver level
>
> Understand, thanks! I'm just trying to prevent overly complex API because:
>
> * In our discussed scheme, the driver still needs to convert the data bits
The u32 mask scheme fits simple-gpio drivers (1 register for input/output,
1 for direction, e.g. mpc8xxx driver) pretty well. Consider that to get
true synchronous output behavior of multiple pins, this is probably the only
option anyway.
For the cavium octeon driver (which doesn't seem to be upstream yet; sports
a single register for readout, per-pin write register) you can only emulate
group behavior by looping over the mask, without synchronous behavior.

> * In practice, the block gpio API is especially useful for use on single
> gpio_chips (only there, a real simultaneous i/o is possible anyway)
> * Wouldn't introduce this kind of optimization in lack of measurable
> improvement
> * The actual i/o data bits still need handling, generating a bit CPU
> load anyway.

I believe it's not worth it to try and save some tens of CPU cycles, considering
that GPIO pins might be on some slower bus anyway. Even then, simple-gpio
drivers have 0 added overhead, because they can use the mask
straight away. That means all processing is done in gpiolib's code and
is limited
to a loop of 32 iterations at most...

For drivers where performance really is critical, you could probably precompute
the needed values:
sclmask = gpio_group_precompute(MY_I2C_SCL)
sdamask = gpio_group_precompute(MY_I2C_SDA)
gpio_group_set_direct(sclmask | sdamask)

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

Re: [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib

[Roland Stigge]

Hi Stijn,

On 30/09/12 16:52, Stijn Devriendt wrote:
>> One question: How did you solve the one-value-per-file in the sysfs
>> interface?
>>
> By exporting the group as a whole:
> /sys/.../gpiogroup248/value
> where value contains a decimal representing the group value.
> Again, this respects the ordering of the pins:
> 
> Actual pins: 0x2D (b 0010 1101)
> Selected pins: 6 3 0 1
> Readout: 6 (b 0 1 1 0)
> 
> The export sysfs file does, however, accept multiple gpio IDs for groups.
> Not sure if this is a 'violation' per se...

If I understand correctly, it's a violation (single-value should hold
for read and write).

To solve it, I have the following in mind: /sys/.../gpiogroupXXX/
contains files "bit0" ... "bit31" which contain a gpio number each,
empty if "unconnected".

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

Re: [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib

[Stijn Devriendt]

On Sun, Sep 30, 2012 at 12:50 PM, Roland Stigge  wrote:
> On 30/09/12 11:35, Stijn Devriendt wrote:
>> In our kernel tree we have similar code. If you like I can request
>> permission
>> to share. I can, however, already give you an update on the basic
>> structure, perhaps
>> it's useful now.
>>
>> For the first part, the drivers need to implement a the gpio interface
>> for groups.
>> gpio_set_multi, gpio_get_multi, gpio_direction_input_multi,
>> gpio_direction_output_multi. Each of them gets a 'u32 mask'.
>>
>> Secondly, gpiolib gets some new code to handle groups:
>> groups are requested via a list of gpio ids. Mind that order is respected:
>> request( [1, 5, 2, 4] ) followed by a set(0x5) will translate to
>> gpio_set_multi( 0x18 ). An opaque gpio_group struct is used to keep track.
>> This means the gpiolib interface also has a u32 mask, but translation is
>> done for the gpio-drivers.
>>
>> There is some code to request groups via device-tree (again respecting
>> order)
>> and there are also platform driver structures.
>>
>> gpiolib was also extended to export groups into sysfs, respecting policy
>> (input, output, user-selectable) and to make softlinks to groups in other
>> driver's subdir. (One driver we use this in is a power-sequencer with 2
>> gpios selecting a margining profile, this driver then has the gpio_group
>> exported in it's sysfs dir as .../profile, allowing H/W engineers to select
>> the profile without voltage glitches)
>>
>> There's also a separate driver, that does nothing more than exporting
>> both individual pins and groups to userspace based on platform description
>> or devicetree. This is probably less interesting for mainline, since we're
>> abusing device-tree to do away with some init script that can do the same.
>>
>> The rationale behind a 32bit mask is that typical processors can at most
>> set one processor-word worth of GPIOs at once and there are probably
>> few chips with over 32GPIOs on a single gpio_chip anyway.
>> Nevertheless, in the era of 64bit, it's definitely possible to go for
>> u64 instead.
>
> Hi Stijn,
>
> thank you for your notes!
>
> Besides what I discussed with JC and Linus, I find the unsigned int
> (i.e. u32 or u64, depending on the arch) quite appealing. It is a nice
> compromise between my general bit mapped data model (variable size *u8
> array) and the bool *values list. Even maps easily onto a single sysfs
> entry for values, by abstracting a gpio list to an actual data word.
>
> What do others think? JC? Linus? I'm considering this (unsigned int
> data) a valid option.
>
> One question: How did you solve the one-value-per-file in the sysfs
> interface?
>
By exporting the group as a whole:
/sys/.../gpiogroup248/value
where value contains a decimal representing the group value.
Again, this respects the ordering of the pins:

Actual pins: 0x2D (b 0010 1101)
Selected pins: 6 3 0 1
Readout: 6 (b 0 1 1 0)

The export sysfs file does, however, accept multiple gpio IDs for groups.
Not sure if this is a 'violation' per se... If the user stores a single value
he gets a single pin, multiple (space-separated) values give him a group.

Regards,
Stijn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sysfs: sysfs_pathname/sysfs_add_one: Use strlcat() instead of strcat()

[Greg Kroah-Hartman]

On Sat, Sep 29, 2012 at 10:23:19PM +0200, Geert Uytterhoeven wrote:
> The warning check for duplicate sysfs entries can cause a buffer overflow
> when printing the warning, as strcat() doesn't check buffer sizes.
> Use strlcat() instead.

As the comment said, we knew about this, but I have never seen it, do
you know of a way to trigger it?

> Since strlcat() doesn't return a pointer to the passed buffer, unlike
> strcat(), I had to convert the nested concatenation in sysfs_add_one() to
> an admittedly more obscure comma operator construct, to avoid emitting code
> for the concatenation if CONFIG_BUG is disabled.

That's a fun construct, nice work.

> Signed-off-by: Geert Uytterhoeven 
> Cc: sta...@vger.kernel.org

Given that I don't know of any way to actually hit this problem, is it
really needed for older kernel releases?

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: hot CPU with 3.6.0-rc7+ and intel graphic

[Toralf Förster]

On 09/30/2012 04:06 PM, Anca Emanuel wrote:
> On Sun, Sep 30, 2012 at 4:37 PM, Feng Tang  wrote:
>> Where can we get a powertop-2.1? I searched google and found
>> git clone git://git.kernel.org/pub/scm/status/powertop/powertop.git
>> is null now.
> 
> https://01.org/powertop/
> https://01.org/powertop/sites/default/files/downloads/powertop-2.1.tar.gz
> 
> I'm not sure about this source.
> Samuel, can you confirm this is an official Intel site ?
> 
I use this url = git://github.com/fenrus75/powertop.git


-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Re: 3.4.10 i915 [GM45] regression

[Greg KH]

On Sun, Sep 30, 2012 at 01:15:38PM +0200, Andreas Sturmlechner wrote:
> > Ok, now reverted, thanks.
> > 
> > greg k-h
> 
> The same patch also breaks 3.0 for me. A 3.0.42 image with the patch
> reverted was fine, I checked with several restarts.
> 
> Sort of confirms there is something in >=3.5 that makes this thing work.

Ok, Daniel, should I also revert this on 3.0.y?

thanks,

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

re: Linux 3.6-rc7

[Uwaysi Bin Kareem]

Compiled 3.6-rc7, with a hz timer of 3956 for a "natural" psychovisual
profile jitter level in OpenGL, and a shaved config for minimal jitter.

Also changed the 10ms filter in fair.c to 1. And I suggest the whole
filter to be removed. https://lkml.org/lkml/2012/9/30/78

There is very few clicks with ALSA + onboard soundcard at 0.3ms lantecy
now, without RT-threads.

Meaning os-jitter is near optimal for audio/video. I think few care once
it is below 0.2ms.

Ofcourse one always wants lower, but at that point, things feel like
hardware, and becomes unnoticable to the user.

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

Re: hot CPU with 3.6.0-rc7+ and intel graphic

[Anca Emanuel]

On Sun, Sep 30, 2012 at 4:37 PM, Feng Tang  wrote:
> Where can we get a powertop-2.1? I searched google and found
> git clone git://git.kernel.org/pub/scm/status/powertop/powertop.git
> is null now.

https://01.org/powertop/
https://01.org/powertop/sites/default/files/downloads/powertop-2.1.tar.gz

I'm not sure about this source.
Samuel, can you confirm this is an official Intel site ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: hot CPU with 3.6.0-rc7+ and intel graphic

[Feng Tang]

Hi Toralf,

On Sat, 29 Sep 2012 10:16:11 +0200
Toralf Förster  wrote:

> 
> Hello,
> 
> I'm observed hot CPUs at my ThinkPad T420 (i5-2540M CPU) w/ integrated
> intel graphic with current git
> Powertop-2.1 shows that the GPU is always at 100%.

Where can we get a powertop-2.1? I searched google and found 
git clone git://git.kernel.org/pub/scm/status/powertop/powertop.git
is null now.

> 
> .config is attached

Really weird, my commit only change the lpc_ich.c which affects the TCO_WDT
driver. but from your .config file, neither CONFIG_LPC_ICH nor the
 CONFIG_ITCO_WDT is enabled, which means the commit should not affect
your kernel, could you double check the .config file?

Thanks,
Feng
> 
> 
> I bisected this to
> 
> 
> commit a0e35322910555e20e9eced3f050a76c7b3a1f92
> Author: Feng Tang 
> Date:   Thu Aug 16 15:50:10 2012 +0800
> 
> mfd: lpc_ich: Fix a 3.5 kernel regression for iTCO_wdt driver
> 
> 
> 
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/10] bug.h: Replace __linktime_error with __compiletime_error

[Borislav Petkov]

On Fri, Sep 28, 2012 at 09:04:35PM -0400, Steven Rostedt wrote:
> On Fri, 2012-09-28 at 17:23 -0700, Josh Triplett wrote:
> > On Fri, Sep 28, 2012 at 06:20:07PM -0500, Daniel Santos wrote:
> > > Signed-off-by: Daniel Santos 
> > > ---
> > >  include/linux/bug.h |2 +-
> > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/include/linux/bug.h b/include/linux/bug.h
> > > index aaac4bb..298a916 100644
> > > --- a/include/linux/bug.h
> > > +++ b/include/linux/bug.h
> > > @@ -73,7 +73,7 @@ extern int __build_bug_on_failed;
> > >  #define BUILD_BUG()  \
> > >   do {\
> > >   extern void __build_bug_failed(void)\
> > > - __linktime_error("BUILD_BUG failed");   \
> > > + __compiletime_error("BUILD_BUG failed");\
> > >   __build_bug_failed();   \
> > >   } while (0)
> > 
> > This change should either occur as part of patch 5 or before patch 5,
> > not after.
> 
> I noticed the same thing and was about to comment on it.
> 
> Please do not break bisectablity. All your patches should compile and
> run at every step.

And while we're at it, every patch upstream should have a commit message
explaining why this is done. No matter how trivial it is, because after
a sufficient amount of time passes, everyone tends to forget why this
has been done.

Thanks.

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

Re: [PATCH 3/10] compiler-gcc.h: Add gcc-recommended GCC_VERSION macro

[Borislav Petkov]

On Fri, Sep 28, 2012 at 06:20:04PM -0500, Daniel Santos wrote:
> Throughout compiler*.h, many version checks are made.  These can be
> simplified by using the macro that gcc's documentation recommends.
> However, my primary reason for adding this is that I need bug-check
> macros that are enabled at certain gcc versions and it's cleaner to use
> this macro than the tradition method:
> 
> if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ => 2)
> 
> If you add patch level, it gets this ugly:
> 
> if __GNUC__ > 4 || (__GNUC__ == 4 && (__GNUC_MINOR__ > 2 || \
>__GNUC_MINOR__ == 2 __GNUC_PATCHLEVEL__ >= 1))
> 
> As opposed to:
> 
> if GCC_VERSION >= 40201
> 
> While having separate headers for gcc 3 & 4 eliminates some of this
> verbosity, they can still be cleaned up by this.

Yes,

very fine readability improvement.

Acked-by: Borislav Petkov 

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

re: Linux 3.5-rc7

[Uwaysi Bin Kareem]

Compiled 3.6-rc7, with a hz timer of 3956 for a "natural" psychovisual  
profile jitter level in OpenGL, and a shaved config for minimal jitter.


Also changed the 10ms filter in fair.c to 1. And I suggest the whole  
filter to be removed. https://lkml.org/lkml/2012/9/30/78


There is very few clicks with ALSA + onboard soundcard at 0.3ms lantecy  
now, without RT-threads.


Meaning os-jitter is near optimal for audio/video. I think few care once  
it is below 0.2ms.


Ofcourse one always wants lower, but at that point, things feel like  
hardware, and becomes unnoticable to the user.


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

Re: [ 080/262] usb: gadget: dummy_hcd: fixup error probe path

[Sebastian Andrzej Siewior]

On Sat, Sep 29, 2012 at 09:01:15PM +0200, Ben Hutchings wrote:
> > This is a problem since 448b6eb1 ("USB: Make sure to fetch the BOS desc
> > for roothubs.) if used in USB3 mode because dummy does not provide this
> > descriptor and explodes later.
> [...]
> 
> i.e. for 3.5 (as noted in the cc: stable line).  But I don't see why
> this isn't needed for earlier kernel versions.  The same broken error
> handling is present.

Hmmm. The error handling is broken since day 1 that is cdfcbd2c4a ("usb:
gadget: dummy_hcd: use the shared_hcd infrastructure") / v3.1-rc1.
Prior v3.5 it is unlikely that something fails here, I never noticed it.
However you are right: wrong is wrong and thefore it should be picked up to
v3.1.

> Ben.

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/3] workqueue: Schedule work on non-idle cpu instead of current one

[Viresh Kumar]

On 30 September 2012 14:24, Tejun Heo  wrote:
> On Thu, Sep 27, 2012 at 02:34:05PM +0530, Viresh Kumar wrote:
>> - A cpu has programmed a timer and is IDLE now.
>> - CPU gets into interrupt handler due to timer and queues a work. As the CPU 
>> is
>>   currently IDLE, we can queue this work to some other CPU.
>
> I'm still a bit confused, if the CPU is already running the IRQ
> handler, the CPU is not idle by definition.  What am I missing here?

Hi Tejun,

For the scheduler CPU is idle, if all below are true:
- current task is idle task
- nr_running == 0
- wake_list is empty

And during these conditions, there can be a timer running in background.
And when we reach its interrupt handler, then also these conditions hold true
and local cpu is idle.

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

Re: INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0, t=10002 jiffies)

[Fengguang Wu]

On Sun, Sep 30, 2012 at 01:32:46PM +0200, Avi Kivity wrote:
> On 09/30/2012 01:23 PM, Fengguang Wu wrote:
> > On Sun, Sep 30, 2012 at 01:10:55PM +0200, Avi Kivity wrote:
> >> On 09/28/2012 05:35 AM, Paul E. McKenney wrote:
> >> > On Thu, Sep 27, 2012 at 12:40:44PM +0800, Fengguang Wu wrote:
> >> >> On Wed, Sep 26, 2012 at 09:28:50PM -0700, Paul E. McKenney wrote:
> >> >> > On Thu, Sep 27, 2012 at 10:54:00AM +0800, Fengguang Wu wrote:
> >> >> > > On Wed, Sep 26, 2012 at 09:45:43AM -0700, Paul E. McKenney wrote:
> >> >> > > > On Wed, Sep 26, 2012 at 04:15:01PM +0800, Fengguang Wu wrote:
> >> > 
> >> > [ . . . ]
> >> > 
> >> >> > > > But could you also please send your .config file and a 
> >> >> > > > description of
> >> >> > > 
> >> >> > > .config attached.
> >> >> > > 
> >> >> > > > the workload you are running?
> >> >> > > 
> >> >> > > It's basically the below commands. The exact initrd is not relevant 
> >> >> > > in
> >> >> > > this case because it's a boot time warning before user space is
> >> >> > > started. The stalls roughly happen 1 time on every 10 boots.
> >> >> > 
> >> >> > Yow!!!
> >> >> > 
> >> >> > You have severe cross-CPU time-synchronization problems.  See for
> >> >> > example the first dmesg, with the relevant part extracted right here.
> >> >> > One CPU believes that it is about 37 seconds past boot, and the other
> >> >> > CPU beleives that it is about 137 seconds past boot.  Given that large
> >> >> > of a time difference, an RCU CPU stall warning is expected behavior.
> >> >> 
> >> >> Good spot! Yeah I noticed that huge timestamp gap, however didn't take
> >> >> it seriously enough..
> >> >> 
> >> >> > Get your two CPUs in agreement about what time it is, and I bet that
> >> >> > the CPU stall warnings will go away.
> >> >> 
> >> >> Possibly KVM related? Because the warnings show up in many test boxes
> >> >> running KVM and so is not likely some hardware specific issue.
> >> > 
> >> > I vaguely recall seeing something recently.  But let's ask the KVM and
> >> > timekeeping guys.
> >> 
> >> >From the logs it looks like hpet (why not kvmclock?) is used for the
> >> clock, it should not generate such drifts since it is a global clock.
> >> Can you verify current_clocksource on a boot that actually failed (in
> >> case the clocksource is switched during runtime)?
> > 
> > I've checked out the dmesg that's cited by Paul, attached. Yes it
> > contains lines
> > 
> > [4.970051] Switching to clocksource hpet
> > 
> > and then
> > 
> > [7.250353] Switching to clocksource tsc
> > 
> > And there is no kvm-clock lines. Oh well for this particular kernel:
> > 
> 
> Ah, tsc will certainly break on kvm if the hardware doesn't provide a
> constant tsc source.  I'm surprised the guest kernel didn't detect it
> and switch back to hpet though.

Thanks, it's good to know the root cause. All the dmesgs show the same hpet+tsc
switching pattern (and never switch back):

$ grep Switching dmesg-kvm_bisect2-inn-*21
dmesg-kvm_bisect2-inn-41931-2012-09-27-10-37-51-3.6.0-rc7-bisect2-00078-g593d100-21:[
4.111415] Switching to clocksource hpet
dmesg-kvm_bisect2-inn-41931-2012-09-27-10-37-51-3.6.0-rc7-bisect2-00078-g593d100-21:[
6.550098] Switching to clocksource tsc
dmesg-kvm_bisect2-inn-41931-2012-09-27-10-41-48-3.6.0-rc7-bisect2-00078-g593d100-21:[
3.927716] Switching to clocksource hpet
dmesg-kvm_bisect2-inn-41931-2012-09-27-10-41-48-3.6.0-rc7-bisect2-00078-g593d100-21:[
6.030117] Switching to clocksource tsc
dmesg-kvm_bisect2-inn-42322-2012-09-27-10-35-17-3.6.0-rc7-bisect2-00078-g593d100-21:[
3.587408] Switching to clocksource hpet
dmesg-kvm_bisect2-inn-42322-2012-09-27-10-35-17-3.6.0-rc7-bisect2-00078-g593d100-21:[
5.812400] Switching to clocksource tsc
dmesg-kvm_bisect2-inn-42322-2012-09-27-10-43-56-3.6.0-rc7-bisect2-00078-g593d100-21:[
4.294842] Switching to clocksource hpet
dmesg-kvm_bisect2-inn-42322-2012-09-27-10-43-56-3.6.0-rc7-bisect2-00078-g593d100-21:[
6.491696] Switching to clocksource tsc
dmesg-kvm_bisect2-inn-42322-2012-09-27-10-47-03-3.6.0-rc7-bisect2-00078-g593d100-21:[
4.745749] Switching to clocksource hpet
dmesg-kvm_bisect2-inn-42322-2012-09-27-10-47-03-3.6.0-rc7-bisect2-00078-g593d100-21:[
7.193121] Switching to clocksource tsc
dmesg-kvm_bisect2-inn-42527-2012-09-27-10-38-38-3.6.0-rc7-bisect2-00078-g593d100-21:[
4.970051] Switching to clocksource hpet
dmesg-kvm_bisect2-inn-42527-2012-09-27-10-38-38-3.6.0-rc7-bisect2-00078-g593d100-21:[
7.250353] Switching to clocksource tsc

And these are the stall times:

$ grep -hC1 stalls dmesg-kvm_bisect2-inn-*21
[   36.122624] bus: 'platform': really_probe: probing driver i8042 with device 
i8042
[   36.106893] INFO: rcu_preempt self-detected stall on CPU[  210.200388] INFO: 
rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0, t=17413 jiffies)
[  210.200417] Pid: 0, comm: swapper/0 Not tainted 
3.6.0-rc7-bisect2-00078-g593d100 #21
--
[   35.403888] bus: 'platform': really_probe: 

re: The 10ms averager in fair.c

[Uwaysi Bin Kareem]

I also did a quick hack changing some of those values, giving  
non-interrputed audiostream with audioapp alone, at 0.7ms. (on a core2duo  
@ 2.5ghz)

That is actually better than BFS.

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

[PATCH 1/2] kstrto*: add documentation

[Eldad Zack]

As J. Bruce Fields  pointed out, kstrto* is
currently lacking kerneldoc comments.
This patch adds kerneldoc comments to common variants of kstrto*:
kstrto(u)l, kstrto(u)ll and kstrto(u)int.

Cc: J. Bruce Fields 
Signed-off-by: Eldad Zack 
---
v2: includes typo fix from Joe Perches ,
 added details as suggested by J. Bruce Fields ,
 added the kstrto* functions to string conversions section in SGML.

 Documentation/DocBook/kernel-api.tmpl |3 ++
 include/linux/kernel.h|   33 +
 lib/kstrtox.c |   64 +
 3 files changed, 100 insertions(+), 0 deletions(-)

diff --git a/Documentation/DocBook/kernel-api.tmpl 
b/Documentation/DocBook/kernel-api.tmpl
index 00687ee..f75ab4c 100644
--- a/Documentation/DocBook/kernel-api.tmpl
+++ b/Documentation/DocBook/kernel-api.tmpl
@@ -58,6 +58,9 @@
 
  String Conversions
 !Elib/vsprintf.c
+!Finclude/linux/kernel.h kstrtol
+!Finclude/linux/kernel.h kstrtoul
+!Elib/kstrtox.c
  
  String Manipulation
 

[PATCH 2/2] simple_strto*: annotate function as obsolete

[Eldad Zack]

This patch update the documentation to simple_strto* to reflect
that it has been obsoleted and advise the usage of kstrto*.

Cc: J. Bruce Fields 
Signed-off-by: Eldad Zack 
---
 lib/vsprintf.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 0e33754..86e27d7 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -38,6 +38,8 @@
  * @cp: The start of the string
  * @endp: A pointer to the end of the parsed string will be placed here
  * @base: The number base to use
+ *
+ * This function is obsolete. Please use kstrtoull instead.
  */
 unsigned long long simple_strtoull(const char *cp, char **endp, unsigned int 
base)
 {
@@ -61,6 +63,8 @@ EXPORT_SYMBOL(simple_strtoull);
  * @cp: The start of the string
  * @endp: A pointer to the end of the parsed string will be placed here
  * @base: The number base to use
+ *
+ * This function is obsolete. Please use kstrtoul instead.
  */
 unsigned long simple_strtoul(const char *cp, char **endp, unsigned int base)
 {
@@ -73,6 +77,8 @@ EXPORT_SYMBOL(simple_strtoul);
  * @cp: The start of the string
  * @endp: A pointer to the end of the parsed string will be placed here
  * @base: The number base to use
+ *
+ * This function is obsolete. Please use kstrtol instead.
  */
 long simple_strtol(const char *cp, char **endp, unsigned int base)
 {
@@ -88,6 +94,8 @@ EXPORT_SYMBOL(simple_strtol);
  * @cp: The start of the string
  * @endp: A pointer to the end of the parsed string will be placed here
  * @base: The number base to use
+ *
+ * This function is obsolete. Please use kstrtoll instead.
  */
 long long simple_strtoll(const char *cp, char **endp, unsigned int base)
 {
-- 
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/

The 10ms averager in fair.c

[Uwaysi Bin Kareem]

Hiya. I just had an initial look at fair.c

There seems to be a 10ms averager in there?

You are aware that that means you work on delayed values?

Isn`t that counterintuitive to the principle of sharing?

That means short bursts of cpu-use will be filtered out, and given less  
cpu time.
Starting applications won`t have their cpu-usage before 5ms, which is  
quite a bit on modern machines. Well if you use a linearphase filter, I  
don`t know what kind of averager you use. The best would ofcourse be to  
use a minimalphase gaussian averager. Which might be overkill. Atleast a  
one-pole iir, buf = buf + (-buf + in) * cut)); One pole IIRs also have a  
better frequency response.


When you are working with low-latencies, wouldn`t it be better if such  
things are tuned for target latency. I think few care about latency after  
0.2ms. So say the filter should be set to 0.4ms max.


Why would you want to filter cpu-usage also really?

Peace Be With You.

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

Re: INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0, t=10002 jiffies)

[Avi Kivity]

On 09/30/2012 01:23 PM, Fengguang Wu wrote:
> On Sun, Sep 30, 2012 at 01:10:55PM +0200, Avi Kivity wrote:
>> On 09/28/2012 05:35 AM, Paul E. McKenney wrote:
>> > On Thu, Sep 27, 2012 at 12:40:44PM +0800, Fengguang Wu wrote:
>> >> On Wed, Sep 26, 2012 at 09:28:50PM -0700, Paul E. McKenney wrote:
>> >> > On Thu, Sep 27, 2012 at 10:54:00AM +0800, Fengguang Wu wrote:
>> >> > > On Wed, Sep 26, 2012 at 09:45:43AM -0700, Paul E. McKenney wrote:
>> >> > > > On Wed, Sep 26, 2012 at 04:15:01PM +0800, Fengguang Wu wrote:
>> > 
>> > [ . . . ]
>> > 
>> >> > > > But could you also please send your .config file and a description 
>> >> > > > of
>> >> > > 
>> >> > > .config attached.
>> >> > > 
>> >> > > > the workload you are running?
>> >> > > 
>> >> > > It's basically the below commands. The exact initrd is not relevant in
>> >> > > this case because it's a boot time warning before user space is
>> >> > > started. The stalls roughly happen 1 time on every 10 boots.
>> >> > 
>> >> > Yow!!!
>> >> > 
>> >> > You have severe cross-CPU time-synchronization problems.  See for
>> >> > example the first dmesg, with the relevant part extracted right here.
>> >> > One CPU believes that it is about 37 seconds past boot, and the other
>> >> > CPU beleives that it is about 137 seconds past boot.  Given that large
>> >> > of a time difference, an RCU CPU stall warning is expected behavior.
>> >> 
>> >> Good spot! Yeah I noticed that huge timestamp gap, however didn't take
>> >> it seriously enough..
>> >> 
>> >> > Get your two CPUs in agreement about what time it is, and I bet that
>> >> > the CPU stall warnings will go away.
>> >> 
>> >> Possibly KVM related? Because the warnings show up in many test boxes
>> >> running KVM and so is not likely some hardware specific issue.
>> > 
>> > I vaguely recall seeing something recently.  But let's ask the KVM and
>> > timekeeping guys.
>> 
>> >From the logs it looks like hpet (why not kvmclock?) is used for the
>> clock, it should not generate such drifts since it is a global clock.
>> Can you verify current_clocksource on a boot that actually failed (in
>> case the clocksource is switched during runtime)?
> 
> I've checked out the dmesg that's cited by Paul, attached. Yes it
> contains lines
> 
> [4.970051] Switching to clocksource hpet
> 
> and then
> 
> [7.250353] Switching to clocksource tsc
> 
> And there is no kvm-clock lines. Oh well for this particular kernel:
> 

Ah, tsc will certainly break on kvm if the hardware doesn't provide a
constant tsc source.  I'm surprised the guest kernel didn't detect it
and switch back to hpet though.


-- 
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0, t=10002 jiffies)

[Avi Kivity]

On 09/30/2012 01:18 PM, Fengguang Wu wrote:
> On Sun, Sep 30, 2012 at 01:10:55PM +0200, Avi Kivity wrote:
>> On 09/28/2012 05:35 AM, Paul E. McKenney wrote:
>> > On Thu, Sep 27, 2012 at 12:40:44PM +0800, Fengguang Wu wrote:
>> >> On Wed, Sep 26, 2012 at 09:28:50PM -0700, Paul E. McKenney wrote:
>> >> > On Thu, Sep 27, 2012 at 10:54:00AM +0800, Fengguang Wu wrote:
>> >> > > On Wed, Sep 26, 2012 at 09:45:43AM -0700, Paul E. McKenney wrote:
>> >> > > > On Wed, Sep 26, 2012 at 04:15:01PM +0800, Fengguang Wu wrote:
>> > 
>> > [ . . . ]
>> > 
>> >> > > > But could you also please send your .config file and a description 
>> >> > > > of
>> >> > > 
>> >> > > .config attached.
>> >> > > 
>> >> > > > the workload you are running?
>> >> > > 
>> >> > > It's basically the below commands. The exact initrd is not relevant in
>> >> > > this case because it's a boot time warning before user space is
>> >> > > started. The stalls roughly happen 1 time on every 10 boots.
>> >> > 
>> >> > Yow!!!
>> >> > 
>> >> > You have severe cross-CPU time-synchronization problems.  See for
>> >> > example the first dmesg, with the relevant part extracted right here.
>> >> > One CPU believes that it is about 37 seconds past boot, and the other
>> >> > CPU beleives that it is about 137 seconds past boot.  Given that large
>> >> > of a time difference, an RCU CPU stall warning is expected behavior.
>> >> 
>> >> Good spot! Yeah I noticed that huge timestamp gap, however didn't take
>> >> it seriously enough..
>> >> 
>> >> > Get your two CPUs in agreement about what time it is, and I bet that
>> >> > the CPU stall warnings will go away.
>> >> 
>> >> Possibly KVM related? Because the warnings show up in many test boxes
>> >> running KVM and so is not likely some hardware specific issue.
>> > 
>> > I vaguely recall seeing something recently.  But let's ask the KVM and
>> > timekeeping guys.
>> 
>> >From the logs it looks like hpet (why not kvmclock?) is used for the
> 
> Hi Avi! Thanks for looking into this. It seems you have the full logs
> attached in my previous email?
> 
> FYI, I've enabled CONFIG_KVM_CLOCK/CONFIG_KVM_GUEST for all bootable
> kernels and here is the related boot message:
> 
> [0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00
> [0.00] kvm-clock: cpu 0, msr 0:1b7ec81, boot clock
> 
>> clock, it should not generate such drifts since it is a global clock.
>> Can you verify current_clocksource on a boot that actually failed (in
>> case the clocksource is switched during runtime)?
> 
> I see a line
> 
> [2.011710] Switching to clocksource kvm-clock
> 
> w/o any indication of errors.

So, with kvmclock it works and with hpet it fails?  Strange, hpet is
simple while kvmclock is more complicated, I'd have expected the
opposite behaviour.



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

Re: [PATCH v3 04/13] kmem accounting basic infrastructure

[James Bottomley]

On Sun, 2012-09-30 at 19:37 +0900, Tejun Heo wrote:
> Hello, James.
> 
> On Sun, Sep 30, 2012 at 09:56:28AM +0100, James Bottomley wrote:
> > The beancounter approach originally used by OpenVZ does exactly this.
> > There are two specific problems, though, firstly you can't count
> > references in generic code, so now you have to extend the cgroup
> > tentacles into every object, an invasiveness which people didn't really
> > like.
> 
> Yeah, it will need some hooks.  For dentry and inode, I think it would
> be pretty well isolated tho.  Wasn't it?

But you've got to ask yourself who cares about accurate accounting per
container of dentry and inode objects? They're not objects that any
administrator is used to limiting.  What we at parallels care about
isn't accurately accounting them, it's that one container can't DoS
another by exhausting system resources.  That's achieved equally well by
first charge slab accounting, so we don't really have an interest in
pushing object accounting code for which there's no use case.

> > Secondly split accounting causes oddities too, like your total
> > kernel memory usage can appear to go down even though you do nothing
> > just because someone else added a share.  Worse, if someone drops the
> > reference, your usage can go up, even though you did nothing, and push
> > you over your limit, at which point action gets taken against the
> > container.  This leads to nasty system unpredictability (The whole point
> > of cgroup isolation is supposed to be preventing resource usage in one
> > cgroup from affecting that in another).
> 
> In a sense, the fluctuating amount is the actual resource burden the
> cgroup is putting on the system, so maybe it just needs to be handled
> better or maybe we should charge fixed amount per refcnt?  I don't
> know.

Yes, we considered single charge per reference accounting as well
(although I don't believe anyone went as far as producing an
implementation).  The problem here is now that the sum of the container
resources no-longer bears any relation to the host consumption.  This
makes it very difficult for virtualisation orchestration systems to make
accurate decisions when doing dynamic resource scheduling (DRS).

Conversely, as ugly as you think it, first use accounting is actually
pretty good at identifying problem containers (at least with regard to
memory usage) for DRS because containers which are stretching the memory
tend to accumulate the greatest number of first charges over the system
lifetime.

> > We discussed this pretty heavily at the Containers Mini Summit in Santa
> > Rosa.  The emergent consensus was that no-one really likes first use
> > accounting, but it does solve all the problems and it has the fewest
> > unexpected side effects.
> 
> But that's like fitting the problem to the mechanism.  Maybe that is
> the best which can be done, but the side effect there is way-off
> accounting under pretty common workload, which sounds pretty nasty to
> me.

All we need kernel memory accounting and limiting for is DoS prevention.
There aren't really any system administrators who care about Kernel
Memory accounting (at least until the system goes oom) because there are
no absolute knobs for it (all there is are a set of weird and wonderful
heuristics, like dirty limit ratio and drop caches).  Kernel memory
usage has a whole set of regulatory infrastructure for trying to make it
transparent to the user.

Don't get me wrong: if there were some easy way to get proper memory
accounting for free, we'd be happy but, because it has no practical
application for any of our customers, there's a limited price we're
willing to pay to get it.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0, t=10002 jiffies)

[Fengguang Wu]

On Sun, Sep 30, 2012 at 01:10:55PM +0200, Avi Kivity wrote:
> On 09/28/2012 05:35 AM, Paul E. McKenney wrote:
> > On Thu, Sep 27, 2012 at 12:40:44PM +0800, Fengguang Wu wrote:
> >> On Wed, Sep 26, 2012 at 09:28:50PM -0700, Paul E. McKenney wrote:
> >> > On Thu, Sep 27, 2012 at 10:54:00AM +0800, Fengguang Wu wrote:
> >> > > On Wed, Sep 26, 2012 at 09:45:43AM -0700, Paul E. McKenney wrote:
> >> > > > On Wed, Sep 26, 2012 at 04:15:01PM +0800, Fengguang Wu wrote:
> > 
> > [ . . . ]
> > 
> >> > > > But could you also please send your .config file and a description of
> >> > > 
> >> > > .config attached.
> >> > > 
> >> > > > the workload you are running?
> >> > > 
> >> > > It's basically the below commands. The exact initrd is not relevant in
> >> > > this case because it's a boot time warning before user space is
> >> > > started. The stalls roughly happen 1 time on every 10 boots.
> >> > 
> >> > Yow!!!
> >> > 
> >> > You have severe cross-CPU time-synchronization problems.  See for
> >> > example the first dmesg, with the relevant part extracted right here.
> >> > One CPU believes that it is about 37 seconds past boot, and the other
> >> > CPU beleives that it is about 137 seconds past boot.  Given that large
> >> > of a time difference, an RCU CPU stall warning is expected behavior.
> >> 
> >> Good spot! Yeah I noticed that huge timestamp gap, however didn't take
> >> it seriously enough..
> >> 
> >> > Get your two CPUs in agreement about what time it is, and I bet that
> >> > the CPU stall warnings will go away.
> >> 
> >> Possibly KVM related? Because the warnings show up in many test boxes
> >> running KVM and so is not likely some hardware specific issue.
> > 
> > I vaguely recall seeing something recently.  But let's ask the KVM and
> > timekeeping guys.
> 
> >From the logs it looks like hpet (why not kvmclock?) is used for the

Hi Avi! Thanks for looking into this. It seems you have the full logs
attached in my previous email?

FYI, I've enabled CONFIG_KVM_CLOCK/CONFIG_KVM_GUEST for all bootable
kernels and here is the related boot message:

[0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00
[0.00] kvm-clock: cpu 0, msr 0:1b7ec81, boot clock

> clock, it should not generate such drifts since it is a global clock.
> Can you verify current_clocksource on a boot that actually failed (in
> case the clocksource is switched during runtime)?

I see a line

[2.011710] Switching to clocksource kvm-clock

w/o any indication of errors.

Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Re: 3.4.10 i915 [GM45] regression

[Andreas Sturmlechner]

> Ok, now reverted, thanks.
> 
> greg k-h

The same patch also breaks 3.0 for me. A 3.0.42 image with the patch reverted 
was fine, I checked with several restarts.

Sort of confirms there is something in >=3.5 that makes this thing work.

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

Re: [PATCH RFC 1/2] kvm: Handle undercommitted guest case in PLE handler

[Avi Kivity]

On 09/30/2012 01:07 PM, Gleb Natapov wrote:
> On Sun, Sep 30, 2012 at 10:18:17AM +0200, Avi Kivity wrote:
>> On 09/28/2012 08:16 AM, Raghavendra K T wrote:
>> > 
>> >>
>> >> +struct pv_sched_info {
>> >> +   unsigned long   sched_bitmap;
>> > 
>> > Thinking, whether we need something similar to cpumask here?
>> > Only thing is we are representing guest (v)cpumask.
>> > 
>> 
>> DECLARE_BITMAP(sched_bitmap, KVM_MAX_VCPUS)
>> 
> vcpu_id can be greater than KVM_MAX_VCPUS.

Use the index into the vcpu table as the bitmap index then.  In fact
it's better because then the lookup to get the vcpu pointer is trivial.


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