linux.kernel - 26 new messages in 20 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* ARM: mm: Fix ECC mem policy printk - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3906a0ef98cfbada?hl=en
* KVM: Fix modprobe failure for kvm_intel/kvm_amd - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c37bef49a3050c22?hl=en
* ACPI / hotplug / PCI: Always rescan the slot for new devices - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/96d6e59fcf7a1850?hl=en
* dynamic-debug-howto.txt: update since new wildcard support - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/031a689623f6c727?hl=en
* sysfs: rename sysfs_assoc_lock and explain what it's about - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/3b751edf3c1d7dc0?hl=en
* RFC: paravirtualizing perf_clock - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/fd0f2bbda1fcc725?hl=en
* dynamic_debug: add wildcard support to filter files/functions/modules - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/be534b63c3020283?hl=en
* usb: gadget: add quirks field to struct usb_gadget - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a48ad07b4a8ba244?hl=en
* pstore: avoid incorrectly mark entry as duplicate - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/a37104d0d6d6fb84?hl=en
* kvm: Destroy & free KVM devices on release - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/e956ec826b7e4952?hl=en
* input: i8042 - add PNP modaliases - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/9053a1ab1e3b075c?hl=en
* efivarfs: 'efivarfs_file_write' function reorganization - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/fa13321d53a6cc06?hl=en
* perf: arch_perf_out_copy_user default - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/90d21da4f8643472?hl=en
* efivars,efi-pstore: Hold off deletion of sysfs entry until, the scan is
completed - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c14c3d114598752b?hl=en
* Subject: [PATCHSET driver-core-next] sysfs: separate out kernfs, part #1 - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/f2335fc427cd9a37?hl=en
* ARC: Add perf support for ARC700 cores - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2103bd9f47796e07?hl=en
* x86: Run checksumming in parallel accross multiple alu's - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/9cc32f57f77a2fb9?hl=en
* ARM: OMAP4+: Correct Wakeup-gen code to use physical irq number - 3 messages,
1 author
http://groups.google.com/group/linux.kernel/t/e83ace8a4952c67c?hl=en
* sysfs: return correct error code on unimplemented mmap() - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/876e9ae50cdc1a82?hl=en
* DRIVERS: IRQCHIP: Add support for crossbar IP - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ccd5d1a48b3156b0?hl=en

==============================================================================
TOPIC: ARM: mm: Fix ECC mem policy printk
http://groups.google.com/group/linux.kernel/t/3906a0ef98cfbada?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Oct 30 2013 7:30 am
From: Michal Simek


On 10/30/2013 02:07 PM, Russell King - ARM Linux wrote:
> On Wed, Oct 30, 2013 at 01:46:18PM +0100, Michal Simek wrote:
>> Russell, Will: We discussed this at KS that will be good
>> to rephrase it or have different logic around this.
>> I am not sure if we can also test that this bit is
>> implemented by particular SoC or not.
>>
>> Maybe logic should be that if SoC uses this bit
>> that message is shown in origin format to declare
>> that ECC is enabled or disabled.
>> When SoC doesn't implement it then do not show this message.
>
> This is not quite what I meant - by making the change you have, you also
> omit to print the data cache policy.
>
>> @@ -556,8 +556,9 @@ static void __init build_mem_type_table(void)
>> mem_types[MT_CACHECLEAN].prot_sect |= PMD_SECT_WB;
>> break;
>> }
>> - printk("Memory policy: ECC %sabled, Data cache %s\n",
>> - ecc_mask ? "en" : "dis", cp->policy);
>> + if (ecc_mask)
>> + pr_info("Memory policy: ECC enabled, Data cache %s\n",
>> + cp->policy);
>
> pr_info("Memory policy: %sData cache %s\n",
> ecc_mask ? "ECC enabled, " : "", cp->policy);
>
> is more what I was suggesting.

If this is what you would like to see it there, I am fine with that too.

Thanks,
Michal


--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform






== 2 of 2 ==
Date: Wed, Oct 30 2013 7:40 am
From: Michal Simek


On 10/30/2013 03:23 PM, Michal Simek wrote:
> On 10/30/2013 02:07 PM, Russell King - ARM Linux wrote:
>> On Wed, Oct 30, 2013 at 01:46:18PM +0100, Michal Simek wrote:
>>> Russell, Will: We discussed this at KS that will be good
>>> to rephrase it or have different logic around this.
>>> I am not sure if we can also test that this bit is
>>> implemented by particular SoC or not.
>>>
>>> Maybe logic should be that if SoC uses this bit
>>> that message is shown in origin format to declare
>>> that ECC is enabled or disabled.
>>> When SoC doesn't implement it then do not show this message.
>>
>> This is not quite what I meant - by making the change you have, you also
>> omit to print the data cache policy.
>>
>>> @@ -556,8 +556,9 @@ static void __init build_mem_type_table(void)
>>> mem_types[MT_CACHECLEAN].prot_sect |= PMD_SECT_WB;
>>> break;
>>> }
>>> - printk("Memory policy: ECC %sabled, Data cache %s\n",
>>> - ecc_mask ? "en" : "dis", cp->policy);
>>> + if (ecc_mask)
>>> + pr_info("Memory policy: ECC enabled, Data cache %s\n",
>>> + cp->policy);
>>
>> pr_info("Memory policy: %sData cache %s\n",
>> ecc_mask ? "ECC enabled, " : "", cp->policy);
>>
>> is more what I was suggesting.
>
> If this is what you would like to see it there, I am fine with that too.

btw: passing ecc=on through command line will caused that "ECC enabled" message
will be there even on systems which don't implement this bit.
It is just side effect for both these solutions.
Isn't there any easy way to test if this bit is implemented or not just by setting
it up and clear it?

Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform







==============================================================================
TOPIC: KVM: Fix modprobe failure for kvm_intel/kvm_amd
http://groups.google.com/group/linux.kernel/t/c37bef49a3050c22?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Oct 30 2013 7:30 am
From: Greg KH


On Wed, Oct 30, 2013 at 07:31:05PM +0530, Raghavendra K T wrote:
> On 10/30/2013 01:03 AM, Linus Torvalds wrote:
> > On Tue, Oct 29, 2013 at 12:27 PM, Raghavendra K T
> > <raghavendra.kt@linux.vnet.ibm.com> wrote:
> >>
> >> Could one solution be cascading actual error
> >> that is lost in fs/debugfs/inode.c:__create_file(), so that we could
> >> take correct action in case of failure of debugfs_create_dir()?
> >>
> >> (ugly side is we increase total number of params for __create_file to
> >> 6). or I hope there could be some better solution.
> >
> > The solution to this would be to simply return an error-pointer. See
> > <linux/err.h>. That's what we do for most complex subsystems that
> > return a pointer to a struct: rather than returning "NULL" as an
> > error, return the actual error number encoded in the pointer itself.
>
> Thank you Linus. Yes, this would have been ideal.
>
> >
> > But that would require every user of debugfs_create_dir() to be
> > updated to check errors using IS_ERR() instead of checking against
> > NULL, and there's quite a few of them.
> >
> > So I think just making the error be EEXIST is a simpler solution right now.
> >
>
> Agree.
> I had below patch, and just before sending as formal mail I saw
> Paolo's pull request which already took care of it.
> ---8<---
>
>

> >From ac5d9f038c273f27bea7a54aab6af79b57f56317 Mon Sep 17 00:00:00 2001
> From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> Date: Wed, 30 Oct 2013 18:59:46 +0530
> Subject: [PATCH] Return EEXIST on debugfs_create_dir failure in kvm
>
> As quoted by Linus, EFAULT means "user passed in an invalid
> virtual address pointer", which is why the error string is Bad address.
> But when a debugfs directory creation fails, the above error is not valid.
>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> I understand that Tim's patch that renames directory to something like
> kvm-pv would solve kvm-amd/kvm-intel modules insertion problem.
> This patch is to address error code change complained by Linus.
>
> arch/x86/kernel/kvm.c | 2 +-
> virt/kvm/kvm_main.c | 3 ++-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index a0e2a8a..e475fdb 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -622,7 +622,7 @@ static int __init kvm_spinlock_debugfs(void)
>
> d_kvm = kvm_init_debugfs();
> if (d_kvm == NULL)
> - return -ENOMEM;
> + return -EEXIST;

Why even error out at all here? You should never care about debugfs
file creation return values, so why pass any error back up the stack?

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





==============================================================================
TOPIC: ACPI / hotplug / PCI: Always rescan the slot for new devices
http://groups.google.com/group/linux.kernel/t/96d6e59fcf7a1850?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Oct 30 2013 7:30 am
From: Alex Williamson


On Wed, 2013-10-30 at 15:13 +0100, Rafael J. Wysocki wrote:
> On Wednesday, October 30, 2013 07:57:46 AM Alex Williamson wrote:
> > On Wed, 2013-10-30 at 14:40 +0200, Mika Westerberg wrote:
> > > Commit 2dc4128 (ACPI / hotplug / PCI: Avoid doing too much for spurious
> > > notifies) changed the enable_slot() to check return value of pci_scan_slot()
> > > and if it is zero return early from the function. It means that there were
> > > no new devices in this particular slot.
> > >
> > > However, if a device appeared deeper in the hierarchy the code now ignores
> > > it causing things like Thunderbolt chaining fail to recognize new devices.
> > >
> > > The problem with Alex Williamson's machine was solved with commit
> > > a47d8c8 (ACPI / hotplug / PCI: Avoid parent bus rescans on spurious device
> > > checks) and hence we should be able to restore the original functionality
> > > that we always rescan on bus check notification.
> > >
> > > On a device check notification we still check what acpiphp_rescan_slot()
> > > returns and on zero bail out early.
> > >
> > > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > ---
> > > Alex,
> > >
> > > Are you able to check if your machine still works and doesn't slow down
> > > during boot after this patch is applied?
> >
> > Looks ok to me, no new console output or boot delay. Thanks,
>
> Great, thanks!
>
> May I add your Tested-by to it, then?

Sure

Tested-by: Alex Williamson <alex.williamson@redhat.com>

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





==============================================================================
TOPIC: dynamic-debug-howto.txt: update since new wildcard support
http://groups.google.com/group/linux.kernel/t/031a689623f6c727?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Oct 30 2013 7:30 am
From: "Du, Changbin"


From: "Du, Changbin" <changbin.du@gmail.com>

Add the usage of using new feature wildcard support.

Signed-off-by: Du, Changbin <changbin.du@gmail.com>
---
Documentation/dynamic-debug-howto.txt | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/Documentation/dynamic-debug-howto.txt b/Documentation/dynamic-debug-howto.txt
index 1bbdcfc..46325eb 100644
--- a/Documentation/dynamic-debug-howto.txt
+++ b/Documentation/dynamic-debug-howto.txt
@@ -108,6 +108,12 @@ If your query set is big, you can batch them too:

~# cat query-batch-file > <debugfs>/dynamic_debug/control

+A another way is to use wildcard. The match rule support '*' (matches
+zero or more characters) and '?' (matches exactly one character).For
+example, you can match all usb drivers:
+
+ ~# echo "file drivers/usb/* +p" > <debugfs>/dynamic_debug/control
+
At the syntactical level, a command comprises a sequence of match
specifications, followed by a flags change specification.

@@ -315,6 +321,9 @@ nullarbor:~ # echo -n 'func svc_process -p' >
nullarbor:~ # echo -n 'format "nfsd: READ" +p' >
<debugfs>/dynamic_debug/control

+// enable messages in files of which the pathes include string "usb"
+nullarbor:~ # echo -n '*usb* +p' > <debugfs>/dynamic_debug/control
+
// enable all messages
nullarbor:~ # echo -n '+p' > <debugfs>/dynamic_debug/control

--
1.8.1.2

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





==============================================================================
TOPIC: sysfs: rename sysfs_assoc_lock and explain what it's about
http://groups.google.com/group/linux.kernel/t/3b751edf3c1d7dc0?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Oct 30 2013 7:30 am
From: Tejun Heo


Hey, again.

How about something like the following?

Thanks.
----- >8 -----
sysfs_assoc_lock is an odd piece of locking. In general, whoever owns
a kobject is responsible for synchronizing sysfs operations and sysfs
proper assumes that, for example, removal won't race with any other
operation; however, this doesn't work for symlinking because an entity
performing symlink doesn't usually own the target kobject and thus has
no control over its removal.

sysfs_assoc_lock synchronizes symlink operations against kobj->sd
disassociation so that symlink code doesn't end up dereferencing
already freed sysfs_dirent by racing with removal of the target
kobject.

This is quite obscure and the generic name of the lock and lack of
comments make it difficult to understand its role. Let's rename it to
sysfs_symlink_target_lock and add comments explaining what's going on.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
---
fs/sysfs/dir.c | 18 +++++++++++++++---
fs/sysfs/symlink.c | 20 ++++++++++++++------
fs/sysfs/sysfs.h | 2 +-
3 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index de47ed3..08c6696 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -26,7 +26,7 @@
#include "sysfs.h"

DEFINE_MUTEX(sysfs_mutex);
-DEFINE_SPINLOCK(sysfs_assoc_lock);
+DEFINE_SPINLOCK(sysfs_symlink_target_lock);

#define to_sysfs_dirent(X) rb_entry((X), struct sysfs_dirent, s_rb)

@@ -902,9 +902,21 @@ void sysfs_remove_dir(struct kobject *kobj)
{
struct sysfs_dirent *sd = kobj->sd;

- spin_lock(&sysfs_assoc_lock);
+ /*
+ * In general, kboject owner is responsible for ensuring removal
+ * doesn't race with other operations and sysfs doesn't provide any
+ * protection; however, when @kobj is used as a symlink target, the
+ * symlinking entity usually doesn't own @kobj and thus has no
+ * control over removal. @kobj->sd may be removed anytime and
+ * symlink code may end up dereferencing an already freed sd.
+ *
+ * sysfs_symlink_target_lock synchronizes @kobj->sd disassociation
+ * against symlink operations so that symlink code can safely
+ * dereference @kobj->sd.
+ */
+ spin_lock(&sysfs_symlink_target_lock);
kobj->sd = NULL;
- spin_unlock(&sysfs_assoc_lock);
+ spin_unlock(&sysfs_symlink_target_lock);

if (sd) {
WARN_ON_ONCE(sysfs_type(sd) != SYSFS_DIR);
diff --git a/fs/sysfs/symlink.c b/fs/sysfs/symlink.c
index 22ea2f5..1a23681 100644
--- a/fs/sysfs/symlink.c
+++ b/fs/sysfs/symlink.c
@@ -32,13 +32,15 @@ static int sysfs_do_create_link_sd(struct sysfs_dirent *parent_sd,

BUG_ON(!name || !parent_sd);

- /* target->sd can go away beneath us but is protected with
- * sysfs_assoc_lock. Fetch target_sd from it.
+ /*
+ * We don't own @target and it may be removed at any time.
+ * Synchronize using sysfs_symlink_target_lock. See
+ * sysfs_remove_dir() for details.
*/
- spin_lock(&sysfs_assoc_lock);
+ spin_lock(&sysfs_symlink_target_lock);
if (target->sd)
target_sd = sysfs_get(target->sd);
- spin_unlock(&sysfs_assoc_lock);
+ spin_unlock(&sysfs_symlink_target_lock);

error = -ENOENT;
if (!target_sd)
@@ -140,10 +142,16 @@ void sysfs_delete_link(struct kobject *kobj, struct kobject *targ,
const char *name)
{
const void *ns = NULL;
- spin_lock(&sysfs_assoc_lock);
+
+ /*
+ * We don't own @target and it may be removed at any time.
+ * Synchronize using sysfs_symlink_target_lock. See
+ * sysfs_remove_dir() for details.
+ */
+ spin_lock(&sysfs_symlink_target_lock);
if (targ->sd)
ns = targ->sd->s_ns;
- spin_unlock(&sysfs_assoc_lock);
+ spin_unlock(&sysfs_symlink_target_lock);
sysfs_hash_and_remove(kobj->sd, name, ns);
}

diff --git a/fs/sysfs/sysfs.h b/fs/sysfs/sysfs.h
index 05d063f..e3aea92 100644
--- a/fs/sysfs/sysfs.h
+++ b/fs/sysfs/sysfs.h
@@ -159,7 +159,7 @@ extern struct kmem_cache *sysfs_dir_cachep;
* dir.c
*/
extern struct mutex sysfs_mutex;
-extern spinlock_t sysfs_assoc_lock;
+extern spinlock_t sysfs_symlink_target_lock;
extern const struct dentry_operations sysfs_dentry_ops;

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





==============================================================================
TOPIC: RFC: paravirtualizing perf_clock
http://groups.google.com/group/linux.kernel/t/fd0f2bbda1fcc725?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Oct 30 2013 7:30 am
From: Gleb Natapov


On Mon, Oct 28, 2013 at 08:58:08PM -0600, David Ahern wrote:
> On 10/28/13 7:15 AM, Peter Zijlstra wrote:
> >>Any suggestions on how to do this and without impacting performance. I
> >>noticed the MSR path seems to take about twice as long as the current
> >>implementation (which I believe results in rdtsc in the VM for x86 with
> >>stable TSC).
> >
> >So assuming all the TSCs are in fact stable; you could implement this by
> >syncing up the guest TSC to the host TSC on guest boot. I don't think
> >anything _should_ rely on the absolute TSC value.
> >
> >Of course you then also need to make sure the host and guest tsc
> >multipliers (cyc2ns) are identical, you can play games with
> >cyc2ns_offset if you're brave.
> >
>
> This and the method Gleb mentioned both are going to be complex and
> fragile -- based assumptions on how the perf_clock timestamps are
> generated. For example, 489223e assumes you have the tracepoint
> enabled at VM start with some means of capturing the data (e.g., a
> perf-session active).
We can think of other ways to provide tsc offset to perf.

> In both cases the end result requires piecing
> together and re-generating the VM's timestamp on the events. For
> perf this means either modifying the tool to take parameters and an
> algorithm on how to modify the timestamp or a homegrown tool to
> regenerate the file with updated timestamps.
>
> To back out a bit, my end goal is to be able to create and merge
> perf-events from any context on a KVM-based host -- guest userspace,
> guest kernel space, host userspace and host kernel space (userspace
> events with a perf-clock timestamp is another topic ;-)). Having the
> events generated with the proper timestamp is the simpler approach
> than trying to collect various tidbits of data, massage timestamps
> (and hoping the clock source hasn't changed) and then merge events.
>
So can you explain a little bit more about how this will work? You run
perf on a host and get both host and guest events? How do you pass
events from guest to host in this case?

> And then for the cherry on top a design that works across
> architectures (e.g., x86 now, but arm later).
>
MSR is x86 thing.

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




== 2 of 2 ==
Date: Wed, Oct 30 2013 7:40 am
From: David Ahern


On 10/30/13 8:20 AM, Gleb Natapov wrote:
> So can you explain a little bit more about how this will work? You run
> perf on a host and get both host and guest events? How do you pass
> events from guest to host in this case?

The intent is to allow data capture to occur in both contexts (host and
guest) completely independently (e.g., record events in the guest to a
file and in the host to a separate file). The files are then made
available to a single post processing command (e.g., copy off box to an
analysis server or copy guest file to host or vice versa).

From there perf needs some tweaks to read 2 different data files and
sort. From an address to symbol perspective, perf already has the notion
of independent machines -- work that was done for perf-kvm. There has
already been a lot of discussion on writing perf events to mmap-specific
files which are then merged at analysis time (versus today where all
mmap's are scanned and dumped to the same file). This use case is not
much of an extension beyond those two concepts.

Right now, as a proof of concept, I am dumping events in the guest to a
file (perf-script) and in the host to a file, merging the two files
together and then time sorting. For example running, 'ls' in the guest
causes disk I/O which causes a VMEXIT, .... you can see this action end
to end.

>
>> And then for the cherry on top a design that works across
>> architectures (e.g., x86 now, but arm later).
>>
> MSR is x86 thing.

Sure the implementation of pv_perf_clock for x86 is an MSR read (open to
suggestions on other options). ARM would have some other means of a fast
access to host, no?

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





==============================================================================
TOPIC: dynamic_debug: add wildcard support to filter files/functions/modules
http://groups.google.com/group/linux.kernel/t/be534b63c3020283?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Oct 30 2013 7:30 am
From: "Du, Changbin"


From: "Du, Changbin" <changbin.du@gmail.com>

This patch add wildcard '*'(matches zero or more characters) and '?'
(matches one character) support when qurying debug flags.

Now we can open debug messages using keywords. eg:
1. open debug logs in all usb drivers
echo "file drivers/usb/* +p" > <debugfs>/dynamic_debug/control
2. open debug logs for usb xhci code
echo "file *xhci* +p" > <debugfs>/dynamic_debug/control

Signed-off-by: Du, Changbin <changbin.du@gmail.com>
---
lib/dynamic_debug.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 49 insertions(+), 5 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index c37aeac..b953780 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -8,6 +8,7 @@
* By Greg Banks <gnb@melbourne.sgi.com>
* Copyright (c) 2008 Silicon Graphics Inc. All Rights Reserved.
* Copyright (C) 2011 Bart Van Assche. All Rights Reserved.
+ * Copyright (C) 2013 Du, Changbin <changbin.du@gmail.com>
*/

#define pr_fmt(fmt) KBUILD_MODNAME ":%s: " fmt, __func__
@@ -127,6 +128,46 @@ static void vpr_info_dq(const struct ddebug_query *query, const char *msg)
query->first_lineno, query->last_lineno);
}

+/* check if the string matches given pattern which includes wildcards */
+static bool match_pattern(const char *pattern, const char *string)
+{
+ const char *s = string;
+ const char *p = pattern;
+ bool star = false;
+
+ while (*s) {
+ switch (*p) {
+ case '?':
+ s++;
+ p++;
+ break;
+ case '*':
+ star = true;
+ string = s;
+ if (!*++p)
+ return true;
+ pattern = p;
+ break;
+ default:
+ if (*s == *p) {
+ s++;
+ p++;
+ } else {
+ if (!star)
+ return false;
+ string++;
+ s = string;
+ p = pattern;
+ }
+ break;
+ }
+ }
+
+ if (*p == '*')
+ ++p;
+ return !*p;
+}
+
/*
* Search the tables for _ddebug's which match the given `query' and
* apply the `flags' and `mask' to them. Returns number of matching
@@ -147,7 +188,8 @@ static int ddebug_change(const struct ddebug_query *query,
list_for_each_entry(dt, &ddebug_tables, link) {

/* match against the module name */
- if (query->module && strcmp(query->module, dt->mod_name))
+ if (query->module &&
+ !match_pattern(query->module, dt->mod_name))
continue;

for (i = 0; i < dt->num_ddebugs; i++) {
@@ -155,14 +197,16 @@ static int ddebug_change(const struct ddebug_query *query,

/* match against the source filename */
if (query->filename &&
- strcmp(query->filename, dp->filename) &&
- strcmp(query->filename, kbasename(dp->filename)) &&
- strcmp(query->filename, trim_prefix(dp->filename)))
+ !match_pattern(query->filename, dp->filename) &&
+ !match_pattern(query->filename,
+ kbasename(dp->filename)) &&
+ !match_pattern(query->filename,
+ trim_prefix(dp->filename)))
continue;

/* match against the function */
if (query->function &&
- strcmp(query->function, dp->function))
+ !match_pattern(query->function, dp->function))
continue;

/* match against the format */
--
1.8.1.2

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





==============================================================================
TOPIC: usb: gadget: add quirks field to struct usb_gadget
http://groups.google.com/group/linux.kernel/t/a48ad07b4a8ba244?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Oct 30 2013 7:40 am
From: Alan Stern


On Tue, 29 Oct 2013, David Cohen wrote:

> Due to USB controllers may have different restrictions, usb gadget layer
> needs to provide a generic way to inform gadget functions to complain
> with non-standard requirements.
>
> This patch adds 'quirks' field to struct usb_gadget and the first quirk
> called USB_GADGET_QUIRK_EP_OUT_ALIGNED_SIZE necessary to inform when
> controller's epout requires buffer size to be aligned to MaxPacketSize.
>
> Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
> ---
> include/linux/usb/gadget.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> index 942ef5e..7014ad9 100644
> --- a/include/linux/usb/gadget.h
> +++ b/include/linux/usb/gadget.h
> @@ -540,6 +540,11 @@ struct usb_gadget {
> struct device dev;
> unsigned out_epnum;
> unsigned in_epnum;
> +
> + u32 quirks;
> +/* epout requires buffer size to be aligned to MaxPacketSize */
> +#define USB_GADGET_QUIRK_EP_OUT_ALIGNED_SIZE (1 << 0)

If you decide to go through with this, it might be better to define a
series of single-bit flags instead of a single "quirks" field. For
example:

unsigned quirk_ep_out_aligned_size:1;

Yes, other people (including me!) have done it your way in the past,
but now this seems to make more sense.

Alan Stern

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





==============================================================================
TOPIC: pstore: avoid incorrectly mark entry as duplicate
http://groups.google.com/group/linux.kernel/t/a37104d0d6d6fb84?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Oct 30 2013 7:40 am
From: Seiji Aguchi




> -----Original Message-----
> From: Madper Xie [mailto:cxie@redhat.com]
> Sent: Wednesday, October 30, 2013 5:45 AM
> To: tony.luck@intel.com; keescook@chromium.org; ccross@android.com; anton@enomsg.org; Seiji Aguchi
> Cc: linux-efi@vger.kernel.org; linux-kernel@vger.kernel.org; bbboson@gmail.com; Madper Xie
> Subject: [PATCH 1/2] pstore: avoid incorrectly mark entry as duplicate
>
> From: Madper Xie <bbboson@gmail.com>
>
> pstore try to find duplicate entries by check both ID, type and psi.
> They are not really enough for efi backend. dumped vars always have
> the same type, psi and ID. like follows:
> dump-type0-9-1-1382511508-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
> dump-type0-9-1-1382515661-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
>
> The "duplicate" entries won't appear in pstorefs. And a complain will be
> print -- pstore: failed to load 76 record(s) from 'efi'
> So I add two more checks: timespec and count.
>
> Signed-off-by: Madper Xie <cxie@redhat.com>

Looks good to me.
Acked-by: Seiji Aguchi <seiji.aguchi@hds.com>

But, this patch has to be tested by other backend drivers like erst and ramoops.
In my understanding, erst has supported to log multiple events.
So, I'm interested why the same error hasn't happened in the other drivers.

Seiji

> ---
> fs/pstore/inode.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
> index 1282384..0ae994c 100644
> --- a/fs/pstore/inode.c
> +++ b/fs/pstore/inode.c
> @@ -47,6 +47,7 @@ static LIST_HEAD(allpstore);
> struct pstore_private {
> struct list_head list;
> struct pstore_info *psi;
> + struct timespec time;
> enum pstore_type_id type;
> u64 id;
> int count;
> @@ -290,7 +291,9 @@ int pstore_mkfile(enum pstore_type_id type, char *psname, u64 id, int count,
> list_for_each_entry(pos, &allpstore, list) {
> if (pos->type == type &&
> pos->id == id &&
> - pos->psi == psi) {
> + pos->psi == psi &&
> + pos->count == count &&
> + !timespec_compare(&pos->time, &time)) {
> rc = -EEXIST;
> break;
> }
> @@ -312,6 +315,7 @@ int pstore_mkfile(enum pstore_type_id type, char *psname, u64 id, int count,
> private->id = id;
> private->count = count;
> private->psi = psi;
> + memcpy(&private->time, &time, sizeof(struct timespec));
>
> switch (type) {
> case PSTORE_TYPE_DMESG:
> --
> 1.8.4.2

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




== 2 of 3 ==
Date: Wed, Oct 30 2013 7:40 am
From: Seiji Aguchi




> -----Original Message-----
> From: Madper Xie [mailto:cxie@redhat.com]
> Sent: Wednesday, October 30, 2013 5:45 AM
> To: tony.luck@intel.com; keescook@chromium.org; ccross@android.com; anton@enomsg.org; Seiji Aguchi
> Cc: linux-efi@vger.kernel.org; linux-kernel@vger.kernel.org; bbboson@gmail.com; Madper Xie
> Subject: [PATCH 2/2] pstore: Differentiating names by adding count and timestamp
>
> From: Madper Xie <bbboson@gmail.com>
>
> pstore denominates dumped file as type-psname-id. it makes many file have
> the same name if there are many entries in backend have the same id.
> So adding count and timestamp to file name for differentiating.
>
> Signed-off-by: Madper Xie <cxie@redhat.com>

It should be tested by other drivers as well..
But, looks good to me.
Acked-by: Seiji Aguchi <seiji.aguchi@hds.com>

> ---
> fs/pstore/inode.c | 29 ++++++++++++++++++-----------
> 1 file changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
> index 0ae994c..36b502f 100644
> --- a/fs/pstore/inode.c
> +++ b/fs/pstore/inode.c
> @@ -285,7 +285,7 @@ int pstore_mkfile(enum pstore_type_id type, char *psname, u64 id, int count,
> int rc = 0;
> char name[PSTORE_NAMELEN];
> struct pstore_private *private, *pos;
> - unsigned long flags;
> + unsigned long flags, timestamp;
>
> spin_lock_irqsave(&allpstore_lock, flags);
> list_for_each_entry(pos, &allpstore, list) {
> @@ -316,35 +316,42 @@ int pstore_mkfile(enum pstore_type_id type, char *psname, u64 id, int count,
> private->count = count;
> private->psi = psi;
> memcpy(&private->time, &time, sizeof(struct timespec));
> + timestamp = time.tv_sec;
>
> switch (type) {
> case PSTORE_TYPE_DMESG:
> - sprintf(name, "dmesg-%s-%lld%s", psname, id,
> - compressed ? ".enc.z" : "");
> + sprintf(name, "dmesg-%s-%lld-%d-%ld%s", psname, id, count,
> + timestamp, compressed ? ".enc.z" : "");
> break;
> case PSTORE_TYPE_CONSOLE:
> - sprintf(name, "console-%s", psname);
> + sprintf(name, "console-%s-%d-%ld", psname, count, timestamp);
> break;
> case PSTORE_TYPE_FTRACE:
> - sprintf(name, "ftrace-%s", psname);
> + sprintf(name, "ftrace-%s-%d-%ld", psname, count, timestamp);
> break;
> case PSTORE_TYPE_MCE:
> - sprintf(name, "mce-%s-%lld", psname, id);
> + sprintf(name, "mce-%s-%lld-%d-%ld", psname, id, count,
> + timestamp);
> break;
> case PSTORE_TYPE_PPC_RTAS:
> - sprintf(name, "rtas-%s-%lld", psname, id);
> + sprintf(name, "rtas-%s-%lld-%d-%ld", psname, id, count,
> + timestamp);
> break;
> case PSTORE_TYPE_PPC_OF:
> - sprintf(name, "powerpc-ofw-%s-%lld", psname, id);
> + sprintf(name, "powerpc-ofw-%s-%lld-%d-%ld", psname, id, count,
> + timestamp);
> break;
> case PSTORE_TYPE_PPC_COMMON:
> - sprintf(name, "powerpc-common-%s-%lld", psname, id);
> + sprintf(name, "powerpc-common-%s-%lld-%d-%ld", psname, id,
> + count, timestamp);
> break;
> case PSTORE_TYPE_UNKNOWN:
> - sprintf(name, "unknown-%s-%lld", psname, id);
> + sprintf(name, "unknown-%s-%lld-%d-%ld", psname, id, count,
> + timestamp);
> break;
> default:
> - sprintf(name, "type%d-%s-%lld", type, psname, id);
> + sprintf(name, "type%d-%s-%lld-%d-%ld", type, psname, id, count,
> + timestamp);
> break;
> }
>
> --
> 1.8.4.2

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




== 3 of 3 ==
Date: Wed, Oct 30 2013 8:00 am
From: Madper Xie



seiji.aguchi@hds.com writes:

>> -----Original Message-----
>> From: Madper Xie [mailto:cxie@redhat.com]
>> Sent: Wednesday, October 30, 2013 5:45 AM
>> To: tony.luck@intel.com; keescook@chromium.org; ccross@android.com; anton@enomsg.org; Seiji Aguchi
>> Cc: linux-efi@vger.kernel.org; linux-kernel@vger.kernel.org; bbboson@gmail.com; Madper Xie
>> Subject: [PATCH 1/2] pstore: avoid incorrectly mark entry as duplicate
>>
>> From: Madper Xie <bbboson@gmail.com>
>>
>> pstore try to find duplicate entries by check both ID, type and psi.
>> They are not really enough for efi backend. dumped vars always have
>> the same type, psi and ID. like follows:
>> dump-type0-9-1-1382511508-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
>> dump-type0-9-1-1382515661-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
>>
>> The "duplicate" entries won't appear in pstorefs. And a complain will be
>> print -- pstore: failed to load 76 record(s) from 'efi'
>> So I add two more checks: timespec and count.
>>
>> Signed-off-by: Madper Xie <cxie@redhat.com>
>
> Looks good to me.
> Acked-by: Seiji Aguchi <seiji.aguchi@hds.com>
>
> But, this patch has to be tested by other backend drivers like erst and ramoops.
> In my understanding, erst has supported to log multiple events.
> So, I'm interested why the same error hasn't happened in the other drivers.
>
> Seiji
Thanks for your review. I'll try to test other backends. :-)
>
>> ---
>> fs/pstore/inode.c | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
>> index 1282384..0ae994c 100644
>> --- a/fs/pstore/inode.c
>> +++ b/fs/pstore/inode.c
>> @@ -47,6 +47,7 @@ static LIST_HEAD(allpstore);
>> struct pstore_private {
>> struct list_head list;
>> struct pstore_info *psi;
>> + struct timespec time;
>> enum pstore_type_id type;
>> u64 id;
>> int count;
>> @@ -290,7 +291,9 @@ int pstore_mkfile(enum pstore_type_id type, char *psname, u64 id, int count,
>> list_for_each_entry(pos, &allpstore, list) {
>> if (pos->type == type &&
>> pos->id == id &&
>> - pos->psi == psi) {
>> + pos->psi == psi &&
>> + pos->count == count &&
>> + !timespec_compare(&pos->time, &time)) {
>> rc = -EEXIST;
>> break;
>> }
>> @@ -312,6 +315,7 @@ int pstore_mkfile(enum pstore_type_id type, char *psname, u64 id, int count,
>> private->id = id;
>> private->count = count;
>> private->psi = psi;
>> + memcpy(&private->time, &time, sizeof(struct timespec));
>>
>> switch (type) {
>> case PSTORE_TYPE_DMESG:
>> --
>> 1.8.4.2


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





==============================================================================
TOPIC: kvm: Destroy & free KVM devices on release
http://groups.google.com/group/linux.kernel/t/e956ec826b7e4952?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Oct 30 2013 7:40 am
From: Alex Williamson


On Wed, 2013-10-30 at 12:40 +0200, Gleb Natapov wrote:
> On Tue, Oct 29, 2013 at 10:13:22AM -0600, Alex Williamson wrote:
> > The KVM device interface allocates a struct kvm_device and calls
> > kvm_device_ops.create on it from KVM VM ioctl KVM_CREATE_DEVICE.
> > This returns a file descriptor to the user for them to set/get/check
> > further attributes. On closing the file descriptor, one would assume
> > that kvm_device_ops.destroy is called and all traces of the device
> > would go away. One would be wrong, it actually does nothing more
> > than release the struct kvm reference, waiting until the VM is
> > destroyed before doing more. This leaves devices that only want a
> > single instance of themselves per VM in a tough spot.
> >
> This is by design. Otherwise locking will be needed on each device access
> and for interrupt controllers this is unnecessary serialization and
> overhead. Device API is not designed for devices that can go away while
> machine is running anyway, so after creation device is only destroyed
> during VM destruction.

Hmm, ok. In that case I can drop this patch and I think the rest just
boils down to userspace use of the device. I had been close()'ing the
kvm device fd when all QEMU vfio devices are detached, but I can just as
easily leave it open in case a new device is added later. I'll send out
a new series after doing some more review and testing. Do you have any
comments on the rest of the series? Thanks,

Alex

> > To fix this, do full cleanup on release of the device file descriptor.
> > It's also non-symmetric that one of the existing devices frees the
> > struct kvm_device from it's .destroy function, while the other
> > doesn't. KVM-core allocates the structure and should therefore be
> > responsible for freeing it. Finally, add a missing kfree for the
> > device creation error path.
> >
> > Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> > ---
> > arch/powerpc/kvm/book3s_xics.c | 1 -
> > virt/kvm/kvm_main.c | 5 +++++
> > 2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/kvm/book3s_xics.c b/arch/powerpc/kvm/book3s_xics.c
> > index a3a5cb8..9a82426 100644
> > --- a/arch/powerpc/kvm/book3s_xics.c
> > +++ b/arch/powerpc/kvm/book3s_xics.c
> > @@ -1220,7 +1220,6 @@ static void kvmppc_xics_free(struct kvm_device *dev)
> > for (i = 0; i <= xics->max_icsid; i++)
> > kfree(xics->ics[i]);
> > kfree(xics);
> > - kfree(dev);
> > }
> >
> > static int kvmppc_xics_create(struct kvm_device *dev, u32 type)
> > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > index a9dd682..fec8320 100644
> > --- a/virt/kvm/kvm_main.c
> > +++ b/virt/kvm/kvm_main.c
> > @@ -572,6 +572,7 @@ static void kvm_destroy_devices(struct kvm *kvm)
> >
> > list_del(node);
> > dev->ops->destroy(dev);
> > + kfree(dev);
> > }
> > }
> >
> > @@ -2231,6 +2232,9 @@ static int kvm_device_release(struct inode *inode, struct file *filp)
> > struct kvm_device *dev = filp->private_data;
> > struct kvm *kvm = dev->kvm;
> >
> > + list_del(&dev->vm_node);
> > + dev->ops->destroy(dev);
> > + kfree(dev);
> > kvm_put_kvm(kvm);
> > return 0;
> > }
> > @@ -2294,6 +2298,7 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
> > ret = anon_inode_getfd(ops->name, &kvm_device_fops, dev, O_RDWR | O_CLOEXEC);
> > if (ret < 0) {
> > ops->destroy(dev);
> > + kfree(dev);
> > return ret;
> > }
> >
>
> --
> Gleb.



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





==============================================================================
TOPIC: input: i8042 - add PNP modaliases
http://groups.google.com/group/linux.kernel/t/9053a1ab1e3b075c?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Oct 30 2013 7:40 am
From: Tom Gundersen


On Fri, Oct 4, 2013 at 2:26 PM, Tom Gundersen <teg@jklm.no> wrote:
> On Wed, Sep 4, 2013 at 11:27 AM, Tom Gundersen <teg@jklm.no> wrote:
>> This allows the module to be autoloaded in the common case.
>>
>> In order to work on non-PnP systems the module should be compiled in or loaded
>> unconditionally at boot (c.f. modules-load.d(5)), as before.
>>
>> Cc: Matthew Garrett <mjg59@srcf.ucam.org>
>> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>> Signed-off-by: Tom Gundersen <teg@jklm.no>
>> --
>
>
> Hi Dmitry,
>
> Any comments on this? Any chance of having this (and the two patches
> dropping EXPERT=y requirements) included for 3.13 (or even 3.12 if it
> is not too late for this kind of stuff)? Let me know if I should
> resend the three patches.

Ping? Any chance of seeing this in 3.13?

Cheers,

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





==============================================================================
TOPIC: efivarfs: 'efivarfs_file_write' function reorganization
http://groups.google.com/group/linux.kernel/t/fa13321d53a6cc06?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Oct 30 2013 7:40 am
From: Matt Fleming


On Wed, 30 Oct, at 10:44:16AM, Geyslan Gregório Bem wrote:
> Do you want that I undo that? I aggre that the variable use only
> reduces the line code.

Yes please.

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





==============================================================================
TOPIC: perf: arch_perf_out_copy_user default
http://groups.google.com/group/linux.kernel/t/90d21da4f8643472?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Oct 30 2013 7:40 am
From: Peter Zijlstra


Hi Frederic,

I just spotted:

#ifndef arch_perf_out_copy_user
#define arch_perf_out_copy_user __copy_from_user_inatomic