[PATCH 1/2] iommu: Include linux/types.h
The linux/iommu.h header uses types defined in linux/types.h but doesn't include it. Signed-off-by: Thierry Reding --- include/linux/iommu.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/iommu.h b/include/linux/iommu.h index a71df92..9cbcc6a 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -20,6 +20,7 @@ #define __LINUX_IOMMU_H #include +#include #define IOMMU_READ (1) #define IOMMU_WRITE(2) -- 1.7.11.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RESEND] Ext4: No need to add inode to orphan list during hole punch
While performing punch hole for an inode, i_disksize is not changed. So, there is no need to add the inode to orphan list. Signed-off-by: Ashish Sangwan Signed-off-by: Namjae Jeon --- fs/ext4/extents.c |4 1 file changed, 4 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 91341ec..3e902f9 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -4801,9 +4801,6 @@ int ext4_ext_punch_hole(struct file *file, loff_t offset, loff_t length) if (IS_ERR(handle)) return PTR_ERR(handle); - err = ext4_orphan_add(handle, inode); - if (err) - goto out; /* * Now we need to zero out the non-page-aligned data in the @@ -4889,7 +4886,6 @@ int ext4_ext_punch_hole(struct file *file, loff_t offset, loff_t length) up_write(_I(inode)->i_data_sem); out: - ext4_orphan_del(handle, inode); inode->i_mtime = inode->i_ctime = ext4_current_time(inode); ext4_mark_inode_dirty(handle, inode); ext4_journal_stop(handle); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 4/7] softirq: Use hotplug thread infrastructure
2012/7/16 Thomas Gleixner :
> - static const struct sched_param param = {
> - .sched_priority = MAX_RT_PRIO-1
> - };
> -
> - p = per_cpu(ksoftirqd, hotcpu);
> - per_cpu(ksoftirqd, hotcpu) = NULL;
> - sched_setscheduler_nocheck(p, SCHED_FIFO, );
> - kthread_stop(p);
> + int hotcpu = (unsigned long)hcpu;
> +
> takeover_tasklets(hotcpu);
> break;
Currently, "int hotcpu = (unsigned long)hcpu;" is somewhat strange.
"takeover_tasklets((unsigned long)hcpu)" is sufficient for me.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] vfs: don't let do_last pass negative dentry to audit_inode
I can reliably reproduce the following panic by simply setting an audit rule on a recent 3.5.0+ kernel: BUG: unable to handle kernel NULL pointer dereference at 0040 IP: [] audit_copy_inode+0x10/0x90 PGD 7acd9067 PUD 7b8fb067 PMD 0 Oops: [#86] SMP Modules linked in: nfs nfs_acl auth_rpcgss fscache lockd sunrpc tpm_bios btrfs zlib_deflate libcrc32c kvm_amd kvm joydev virtio_net pcspkr i2c_piix4 floppy virtio_balloon microcode virtio_blk cirrus drm_kms_helper ttm drm i2c_core [last unloaded: scsi_wait_scan] CPU 0 Pid: 1286, comm: abrt-dump-oops Tainted: G D 3.5.0+ #1 Bochs Bochs RIP: 0010:[] [] audit_copy_inode+0x10/0x90 RSP: 0018:88007aebfc38 EFLAGS: 00010282 RAX: RBX: 88003692d860 RCX: 38c4 RDX: RSI: 88006baf5d80 RDI: 88003692d860 RBP: 88007aebfc68 R08: R09: R10: R11: 0001 R12: R13: 880036d30f00 R14: 88006baf5d80 R15: 88003692d800 FS: 7f7562634740() GS:88007fc0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0040 CR3: 3643d000 CR4: 06f0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process abrt-dump-oops (pid: 1286, threadinfo 88007aebe000, task 880079614530) Stack: 88007aebfdf8 88007aebff28 88007aebfc98 81211358 88003692d860 88007aebfcc8 810d4968 88007aebfcc8 880038c4 Call Trace: [] ? ext4_lookup+0xe8/0x160 [] __audit_inode+0x118/0x2d0 [] do_last+0x999/0xe80 [] ? inode_permission+0x18/0x50 [] ? kmem_cache_alloc_trace+0x11a/0x130 [] path_openat+0xba/0x420 [] do_filp_open+0x41/0xa0 [] ? alloc_fd+0x4d/0x120 [] do_sys_open+0xed/0x1c0 [] ? __audit_syscall_entry+0xcc/0x300 [] sys_open+0x21/0x30 [] system_call_fastpath+0x16/0x1b RSP CR2: 0040 The problem is that do_last is passing a negative dentry to audit_inode. The comments on lookup_open note that it can pass back a negative dentry if O_CREAT is not set. This patch fixes the oops, but I'm not clear on whether there's a better approach. Cc: Miklos Szeredi Signed-off-by: Jeff Layton --- fs/namei.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/namei.c b/fs/namei.c index 2ccc35c..0b951d4 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -2608,9 +2608,10 @@ retry_lookup: } /* -* It already exists. +* create/update audit record if it already exists. */ - audit_inode(pathname, path->dentry); + if (path->dentry->d_inode) + audit_inode(pathname, path->dentry); /* * If atomic_open() acquired write access it is dropped now due to -- 1.7.11.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Ext4: No need to add inode to orphan list during hole punch
Signed-off-by: Ashish Sangwan Signed-off-by: Namjae Jeon --- fs/ext4/extents.c |4 1 file changed, 4 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 91341ec..3e902f9 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -4801,9 +4801,6 @@ int ext4_ext_punch_hole(struct file *file, loff_t offset, loff_t length) if (IS_ERR(handle)) return PTR_ERR(handle); - err = ext4_orphan_add(handle, inode); - if (err) - goto out; /* * Now we need to zero out the non-page-aligned data in the @@ -4889,7 +4886,6 @@ int ext4_ext_punch_hole(struct file *file, loff_t offset, loff_t length) up_write(_I(inode)->i_data_sem); out: - ext4_orphan_del(handle, inode); inode->i_mtime = inode->i_ctime = ext4_current_time(inode); ext4_mark_inode_dirty(handle, inode); ext4_journal_stop(handle); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Cocci] coccinelle hung on mini_lock.cocci
Hi Julia,
On Wed, Jul 25, 2012 at 04:15:19PM +0200, Julia Lawall wrote:
> Do you use a timeout when you run Coccinelle You could put the argument
> --timeout 120.
Good to know that! I'll definitely try it.
> The function has a goto from the very end to the very beginning, and there
> are a lot of ifs in between. It seems possible that there is too much
> information, and it gets too slow. I will look further.
Ah OK, yeah this coccinelle case is a bit complex.
Thanks,
Fengguang
> On Wed, 25 Jul 2012, Fengguang Wu wrote:
>
> > Hi all,
> >
> > This command seem to hang for ever on the current linus/master.
> > It happens only on mini_lock.cocci _and_ mm/shmem.c
> > I've updated coccinelle to its git release, however it didn't help..
> >
> > % spatch -debug -D report -I /c/kernel-tests/src/linux/include -sp_file
> > /c/kernel-tests/src/linux/scripts/coccinelle/locks/mini_lock.cocci
> > -no_includes -include_headers /c/kernel-tests/src/linux/mm/shmem.c
> > -no_show_diff
> > init_defs_builtins: /usr/share/coccinelle/standard.h
> > ---
> > processing semantic patch file:
> > /c/kernel-tests/src/linux/scripts/coccinelle/locks/mini_lock.cocci
> > with isos from: /usr/share/coccinelle/standard.iso
> > ---
> > /// Find missing unlocks. This semantic match considers the specific case
> > /// where the unlock is missing from an if branch, and there is a lock
> > /// before the if and an unlock after the if. False positives are due to
> > /// cases where the if branch represents a case where the function is
> > /// supposed to exit with the lock held, or where there is some preceding
> > /// function call that releases the lock.
> > ///
> > // Confidence: Moderate
> > // Copyright: (C) 2010-2012 Nicolas Palix. GPLv2.
> > // Copyright: (C) 2010-2012 Julia Lawall, INRIA/LIP6. GPLv2.
> > // Copyright: (C) 2010-2012 Gilles Muller, INRIA/LiP6. GPLv2.
> > // URL: http://coccinelle.lip6.fr/
> > // Comments:
> > // Options: -no_includes -include_headers
> >
> > virtual context
> > virtual org
> > virtual report
> >
> > @prelocked@
> > position p1,p;
> > expression E1;
> > @@
> >
> > (
> > mutex_lock@p1
> > |
> > mutex_trylock@p1
> > |
> > spin_lock@p1
> > |
> > spin_trylock@p1
> > |
> > read_lock@p1
> > |
> > read_trylock@p1
> > |
> > write_lock@p1
> > |
> > write_trylock@p1
> > |
> > read_lock_irq@p1
> > |
> > write_lock_irq@p1
> > |
> > read_lock_irqsave@p1
> > |
> > write_lock_irqsave@p1
> > |
> > spin_lock_irq@p1
> > |
> > spin_lock_irqsave@p1
> > ) (E1@p,...);
> >
> > @looped@
> > position r;
> > @@
> >
> > for(...;...;...) { <+... return@r ...; ...+> }
> >
> > @err exists@
> > expression E1;
> > position prelocked.p;
> > position up != prelocked.p1;
> > position r!=looped.r;
> > identifier lock,unlock;
> > @@
> >
> > *lock(E1@p,...);
> > <+... when != E1
> > if (...) {
> > ... when != E1
> > * return@r ...;
> > }
> > ...+>
> > *unlock@up(E1,...);
> >
> > @script:python depends on org@
> > p << prelocked.p1;
> > lock << err.lock;
> > unlock << err.unlock;
> > p2 << err.r;
> > @@
> >
> > cocci.print_main(lock,p)
> > cocci.print_secs(unlock,p2)
> >
> > @script:python depends on report@
> > p << prelocked.p1;
> > lock << err.lock;
> > unlock << err.unlock;
> > p2 << err.r;
> > @@
> >
> > msg = "preceding lock on line %s" % (p[0].line)
> > coccilib.report.print_report(p2[0],msg)
> >
> > ---
> > script rule -1 =
> > ---
> > dependencies for script satisfied:
> > binding in = []
> > HANDLING: /c/kernel-tests/src/linux/mm/shmem.c
> > ---
> > let's go
> > ---
> > Defined virtual rules: report
> > ---
> > CFG: orphelin nodes, maybe something weird happened
> > ---
> > prelocked =
> > ---
> > dependencies for rule prelocked satisfied:
> > binding in = []
> > binding relevant in = []
> > transformation info is empty
> > binding out = [prelocked.p1 -->
> > poss[(/c/kernel-tests/src/linux/mm/shmem.c,shmem_reserve_inode,(194,2),(194,11))];
> >prelocked.p -->
> > poss[(/c/kernel-tests/src/linux/mm/shmem.c,shmem_reserve_inode,(194,12),(194,30))]]
> > transformation info is empty
> > binding out = [prelocked.p1 -->
> > poss[(/c/kernel-tests/src/linux/mm/shmem.c,shmem_free_inode,(209,2),(209,11))];
> >prelocked.p -->
> > poss[(/c/kernel-tests/src/linux/mm/shmem.c,shmem_free_inode,(209,12),(209,30))]]
> > transformation info is empty
> > binding
virtio(-scsi) vs. chained sg_lists (was Re: [PATCH] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list)
Il 25/07/2012 15:26, Boaz Harrosh ha scritto: >>> In SCSI land most LLDs should support chaining just by virtu of using the >>> for_each_sg macro. That all it takes. Your code above does support it. >> >> Yes, it supports it but still has to undo them before passing to virtio. >> >> What my LLD does is add a request descriptor in front of the scatterlist >> that the LLD receives. I would like to do this with a 2-item >> scatterlist: one for the request descriptor, and one which is a chain to >> the original scatterlist. > > I hate that plan. Why yet override the scatter element yet again with a third > union of a "request descriptor" I'm not overriding (or did you mean overloading?) anything, and I think you're reading too much in my words. What I am saying is (for a WRITE command): 1) what I get is a scsi_cmnd which contains an N-element scatterlist. 2) virtio-scsi has to build the "packet" that is passed to the hardware (it does not matter that the hardware is virtual). This packet (per virtio-scsi spec) has an N+1-element scatterlist, where the first element is a request descriptor (struct virtio_scsi_cmd_req), and the others describe the written data. 3) virtio takes care of converting the "packet" from a scatterlist (which currently must be a flat one) to the hardware representation. Here a walk is inevitable, so we don't care about this walk. 4) What I'm doing now: copying (and flattening) the N-element scatterlist onto the last elements of an N+1 array that I pass to virtio. _ _ _ _ _ _ |_|_|_|_|_|_| scsi_cmnd scatterlist vvv COPY vvv _ _ _ _ _ _ _ |_|_|_|_|_|_|_| scatterlist passed to virtio | virtio_scsi_cmd_req Then I hand off the scatterlist to virtio. virtio walks it and converts it to hardware format. 5) What I want to do: create a 2-element scatterlist, the first being the request descriptor and the second chaining to scsi_cmnd's N-element scatterlist. _ _ _ _ _ _ |_|_|_|_|_|_| scsi_cmnd scatterlist _ _/ |_|C| scatterlist passed to virtio | virtio_scsi_cmd_req Then I hand off the scatterlist to virtio. virtio will still walk the scatterlist chain, and convert it to N+1 elements for the hardware to consume. Still, removing one walk largely reduces the length of my critical sections. I also save some pointer-chasing because the 2-element scatterlist are short-lived and can reside on the stack. Other details (you can probably skip these): There is also a response descriptor. In the case of writes this is the only element that the hardware will write to, so in the case of writes the "written by hardware" scatterlist has 1 element only and does not need chaining. Reads are entirely symmetric. The hardware will read the request descriptor from a 1-element scatterlist, and will write response+data into an N+1-element scatterlist (the response descriptor precedes the data that was read). It can be treated in exactly the same way. The N+1-element scatterlist could also become a 2-element scatterlist with chaining. >> Except that if I call sg_chain and my >> architecture does not define ARCH_HAS_SG_CHAIN, it will BUG out. So I >> need to keep all the scatterlist allocation and copying crap that I have >> now within #ifdef, and it will bitrot. > > except that with the correct design you don't call sg_chain you just do: > request_descriptor->sg_list = sg; By the above it should be clear, that request_descriptor is not a driver-private extension of the scsi_cmnd. It is something passed to the hardware. >>> Well that can be done as well, (If done carefully) It should be easy to add >>> chained fragments to both the end of a given chain just as at beginning. >>> It only means that the last element of the appended-to chain moves to >>> the next fragment and it's place is replaced by a link. >> >> But you cannot do that in constant time, can you? And that means you do >> not enjoy any benefit in terms of cache misses etc. > > I did not understand "constant time" it is O(0) if that what you meant. In the worst case it is a linked list, no? So in the worst case _finding_ the last element of the appended-to chain is O(n). Actually, appending to the end is not a problem for virtio-scsi. But for example the virtio-blk spec places the response descriptor _after_ the input data. I think this was a mistake, and I didn't repeat it for virtio-scsi, but I cited it because in the past Rusty complained that the long sglist implementation was "SCSI-centric". >> Also, this assumes that I can modify the appended-to chain. I'm not >> sure I can do this? > > Each case it's own. If the appended-to chain is const, yes you'll have > to reallocate it and copy. Is that your case? It will be virtio-blk's case, but we can ignore it. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
RE: [PATCH 1/1] Drivers: hv: Cleanup the guest ID computation
This is the patch I sent out yesterday for Linux to clean up the guest ID mess.
For FreeBSD, you can use the following constant:
HV_FREEBSD_VENDOR_ID0x8200
and use the function to generate the ID appropriately. Larry, I will forward
you the proposal for guest ID in a separate email.
Regards.
K. Y
> -Original Message-
> From: K. Y. Srinivasan [mailto:k...@microsoft.com]
> Sent: Tuesday, July 24, 2012 7:12 PM
> To: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; virtualizat...@lists.osdl.org; o...@aepfle.de;
> a...@canonical.com
> Cc: KY Srinivasan
> Subject: [PATCH 1/1] Drivers: hv: Cleanup the guest ID computation
>
> The current guest ID string in use in vmbus driver does not conform
> to the MSFT guidelines on guest ID. MSFT currently does not specify
> Linux specific guidelines. MSFT however has plans to publish Linux
> specific guidelines. This implementation conforms to the yet unpublished
> Linux specific guidelines for guest ID. This implementation also broadly
> conforms to the current guidelines as well.
>
>
> Signed-off-by: K. Y. Srinivasan
> ---
> drivers/hv/hv.c |9 +--
> drivers/hv/hyperv_vmbus.h | 48
> +---
> 2 files changed, 50 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
> index 86f8885..771e24f 100644
> --- a/drivers/hv/hv.c
> +++ b/drivers/hv/hv.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include "hyperv_vmbus.h"
>
> @@ -164,9 +165,11 @@ int hv_init(void)
>
> max_leaf = query_hypervisor_info();
>
> - /* Write our OS info */
> - wrmsrl(HV_X64_MSR_GUEST_OS_ID, HV_LINUX_GUEST_ID);
> - hv_context.guestid = HV_LINUX_GUEST_ID;
> + /*
> + * Write our OS ID.
> + */
> + hv_context.guestid = generate_guest_id(0, LINUX_VERSION_CODE, 0);
> + wrmsrl(HV_X64_MSR_GUEST_OS_ID, hv_context.guestid);
>
> /* See if the hypercall page is already set */
> rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
> diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
> index 0614ff3..108a441 100644
> --- a/drivers/hv/hyperv_vmbus.h
> +++ b/drivers/hv/hyperv_vmbus.h
> @@ -410,10 +410,50 @@ enum {
>
> #define HV_PRESENT_BIT 0x8000
>
> -#define HV_LINUX_GUEST_ID_LO 0x
> -#define HV_LINUX_GUEST_ID_HI 2976579765
> -#define HV_LINUX_GUEST_ID(((u64)HV_LINUX_GUEST_ID_HI << 32) |
> \
> -HV_LINUX_GUEST_ID_LO)
> +/*
> + * The guest OS needs to register the guest ID with the hypervisor.
> + * The guest ID is a 64 bit entity and the structure of this ID is
> + * specified in the Hyper-V specification:
> + *
> + * http://msdn.microsoft.com/en-us/library/windows/
> + * hardware/ff542653%28v=vs.85%29.aspx
> + *
> + * While the current guideline does not specify how Linux guest ID(s)
> + * need to be generated, our plan is to publish the guidelines for
> + * Linux and other guest operating systems that currently are hosted
> + * on Hyper-V. The implementation here conforms to this yet
> + * unpublished guidelines.
> + *
> + *
> + * Bit(s)
> + * 63 - Indicates if the OS is Open Source or not; 1 is Open Source
> + * 62:56 - Os Type; Linux is 0x100
> + * 55:48 - Distro specific identification
> + * 47:16 - Linux kernel version number
> + * 15:0 - Distro specific identification
> + *
> + *
> + */
> +
> +#define HV_LINUX_VENDOR_ID 0x8100
> +
> +/*
> + * Generate the guest ID based on the guideline described above.
> + */
> +
> +static inline __u64 generate_guest_id(__u8 d_info1, __u32 kernel_version,
> + __u16 d_info2)
> +{
> + __u64 guest_id = 0;
> +
> + guest_id = (((__u64)HV_LINUX_VENDOR_ID) << 48);
> + guest_id |= (((__u64)(d_info1)) << 48);
> + guest_id |= (((__u64)(kernel_version)) << 16);
> + guest_id |= ((__u64)(d_info2));
> +
> + return guest_id;
> +}
> +
>
> #define HV_CPU_POWER_MANAGEMENT (1 << 0)
> #define HV_RECOMMENDATIONS_MAX 4
> --
> 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: [Cocci] coccinelle hung on mini_lock.cocci
Do you use a timeout when you run Coccinelle You could put the argument
--timeout 120.
The function has a goto from the very end to the very beginning, and there
are a lot of ifs in between. It seems possible that there is too much
information, and it gets too slow. I will look further.
julia
On Wed, 25 Jul 2012, Fengguang Wu wrote:
> Hi all,
>
> This command seem to hang for ever on the current linus/master.
> It happens only on mini_lock.cocci _and_ mm/shmem.c
> I've updated coccinelle to its git release, however it didn't help..
>
> % spatch -debug -D report -I /c/kernel-tests/src/linux/include -sp_file
> /c/kernel-tests/src/linux/scripts/coccinelle/locks/mini_lock.cocci
> -no_includes -include_headers /c/kernel-tests/src/linux/mm/shmem.c
> -no_show_diff
> init_defs_builtins: /usr/share/coccinelle/standard.h
> ---
> processing semantic patch file:
> /c/kernel-tests/src/linux/scripts/coccinelle/locks/mini_lock.cocci
> with isos from: /usr/share/coccinelle/standard.iso
> ---
> /// Find missing unlocks. This semantic match considers the specific case
> /// where the unlock is missing from an if branch, and there is a lock
> /// before the if and an unlock after the if. False positives are due to
> /// cases where the if branch represents a case where the function is
> /// supposed to exit with the lock held, or where there is some preceding
> /// function call that releases the lock.
> ///
> // Confidence: Moderate
> // Copyright: (C) 2010-2012 Nicolas Palix. GPLv2.
> // Copyright: (C) 2010-2012 Julia Lawall, INRIA/LIP6. GPLv2.
> // Copyright: (C) 2010-2012 Gilles Muller, INRIA/LiP6. GPLv2.
> // URL: http://coccinelle.lip6.fr/
> // Comments:
> // Options: -no_includes -include_headers
>
> virtual context
> virtual org
> virtual report
>
> @prelocked@
> position p1,p;
> expression E1;
> @@
>
> (
> mutex_lock@p1
> |
> mutex_trylock@p1
> |
> spin_lock@p1
> |
> spin_trylock@p1
> |
> read_lock@p1
> |
> read_trylock@p1
> |
> write_lock@p1
> |
> write_trylock@p1
> |
> read_lock_irq@p1
> |
> write_lock_irq@p1
> |
> read_lock_irqsave@p1
> |
> write_lock_irqsave@p1
> |
> spin_lock_irq@p1
> |
> spin_lock_irqsave@p1
> ) (E1@p,...);
>
> @looped@
> position r;
> @@
>
> for(...;...;...) { <+... return@r ...; ...+> }
>
> @err exists@
> expression E1;
> position prelocked.p;
> position up != prelocked.p1;
> position r!=looped.r;
> identifier lock,unlock;
> @@
>
> *lock(E1@p,...);
> <+... when != E1
> if (...) {
> ... when != E1
> * return@r ...;
> }
> ...+>
> *unlock@up(E1,...);
>
> @script:python depends on org@
> p << prelocked.p1;
> lock << err.lock;
> unlock << err.unlock;
> p2 << err.r;
> @@
>
> cocci.print_main(lock,p)
> cocci.print_secs(unlock,p2)
>
> @script:python depends on report@
> p << prelocked.p1;
> lock << err.lock;
> unlock << err.unlock;
> p2 << err.r;
> @@
>
> msg = "preceding lock on line %s" % (p[0].line)
> coccilib.report.print_report(p2[0],msg)
>
> ---
> script rule -1 =
> ---
> dependencies for script satisfied:
> binding in = []
> HANDLING: /c/kernel-tests/src/linux/mm/shmem.c
> ---
> let's go
> ---
> Defined virtual rules: report
> ---
> CFG: orphelin nodes, maybe something weird happened
> ---
> prelocked =
> ---
> dependencies for rule prelocked satisfied:
> binding in = []
> binding relevant in = []
> transformation info is empty
> binding out = [prelocked.p1 -->
> poss[(/c/kernel-tests/src/linux/mm/shmem.c,shmem_reserve_inode,(194,2),(194,11))];
>prelocked.p -->
> poss[(/c/kernel-tests/src/linux/mm/shmem.c,shmem_reserve_inode,(194,12),(194,30))]]
> transformation info is empty
> binding out = [prelocked.p1 -->
> poss[(/c/kernel-tests/src/linux/mm/shmem.c,shmem_free_inode,(209,2),(209,11))];
>prelocked.p -->
> poss[(/c/kernel-tests/src/linux/mm/shmem.c,shmem_free_inode,(209,12),(209,30))]]
> transformation info is empty
> binding out = [prelocked.p1 -->
> poss[(/c/kernel-tests/src/linux/mm/shmem.c,shmem_add_to_page_cache,(300,1),(300,14))];
>prelocked.p -->
> poss[(/c/kernel-tests/src/linux/mm/shmem.c,shmem_add_to_page_cache,(300,15),(300,34))]]
> transformation info is empty
> binding out = [prelocked.p1 -->
> poss[(/c/kernel-tests/src/linux/mm/shmem.c,shmem_delete_from_page_cache,(327,1),(327,14))];
>prelocked.p -->
>
Re: [PATCH 4/4] fbcon: optimize parameters parsing loop.
From 67cecd09d850542e00a1d9a29567232d1224cf23 Mon Sep 17 00:00:00 2001
From: Paul Cercueil
Date: Thu, 12 Jan 2012 19:40:24 +0100
Subject: [PATCH 4/4] fbcon: optimize parameters parsing loop.
Signed-off-by: Paul Cercueil
---
drivers/video/console/fbcon.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/video/console/fbcon.c
b/drivers/video/console/fbcon.c
index 9b83b75..1ecaf68 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -441,8 +441,10 @@ static int __init fb_console_setup(char *this_opt)
return 1;
while ((options = strsep(_opt, ",")) != NULL) {
- if (!strncmp(options, "font:", 5))
+ if (!strncmp(options, "font:", 5)) {
strlcpy(fontname, options + 5, sizeof(fontname));
+ continue;
+ }
if (!strncmp(options, "scrollback:", 11)) {
char *k;
@@ -468,6 +470,7 @@ static int __init fb_console_setup(char *this_opt)
/* (k && *k): Check for garbage after the suffix */
if (ret || (k && *k))
pr_warn("fbcon: scrollback: incorrect
value.\n");
+ continue;
}
if (!strncmp(options, "map:", 4)) {
@@ -484,6 +487,7 @@ static int __init fb_console_setup(char *this_opt)
} else {
pr_warn("fbcon: map: incorrect value.\n");
}
+ continue;
}
if (!strncmp(options, "vc:", 3)) {
@@ -513,6 +517,7 @@ static int __init fb_console_setup(char *this_opt)
fbcon_is_default = 0;
else
pr_warn("fbcon: vc: incorrect value.\n");
+ continue;
}
if (!strncmp(options, "rotate:", 7)) {
@@ -525,6 +530,7 @@ static int __init fb_console_setup(char *this_opt)
} else {
pr_warn("fbcon: rotate: incorrect value.\n");
}
+ continue;
}
}
return 1;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] cpu: intel, amd: mask cleared cpuid features
With the necessary infrastructure, yes. Trap and emulate is montrivial work. Vladimir Davydov wrote: >On 07/25/2012 04:57 AM, H. Peter Anvin wrote: >> On 07/24/2012 04:09 AM, Vladimir Davydov wrote: >>> We have not encountered this situation in our environments and I >hope we >>> won't :-) >>> >>> But look, these CPUID functions cover majority of CPU features, >don't >>> they? So, most of "normal" apps inside VM will survive migration. >>> Perhaps, some low-level utils won't. I guess that's why there are no >>> MSRs for other levels provided by vendors. >>> >> You will once Ivy Bridge becomes common. > >Ivy Bridge has CPUID faulting, which allows masking all CPUID >levels/functions. > >> -hpa >> -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] fbcon: optimize parameters parsing loop.
Oh, I'm really sorry, I truely am. It looks like that 4th patch is an old version, not the one that should have been sent. Next message will be the correct patch. My apologies about that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 6/6] arm/dts: am33xx rtc node
Hi Sergei,
On Wed, Jul 25, 2012 at 16:50:56, Sergei Shtylyov wrote:
> > + rtc@44e3e000 {
>
> Address postfix in the node name without "reg" property?
As per [1], "The unit-address is included if the node describes
a device with an address".
Here even though reg property is not present, as via hwmod
(see below) it is getting address, isn't it better to have it
>
> > + compatible = "ti,da830-rtc";
> > + ti,hwmods = "rtc";
Regards
Afzal
[1] http://devicetree.org/Device_Tree_Usage
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 08/17] Tools: hv: Gather subnet information
> -Original Message-
> From: Ben Hutchings [mailto:b...@decadent.org.uk]
> Sent: Tuesday, July 24, 2012 9:14 PM
> To: KY Srinivasan
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; virtualizat...@lists.osdl.org; o...@aepfle.de;
> a...@canonical.com; net...@vger.kernel.org
> Subject: Re: [PATCH 08/17] Tools: hv: Gather subnet information
>
> On Tue, 2012-07-24 at 09:01 -0700, K. Y. Srinivasan wrote:
> > Now gather sub-net information for the specified interface.
> >
> > Signed-off-by: K. Y. Srinivasan
> > Reviewed-by: Haiyang Zhang
> > ---
> > tools/hv/hv_kvp_daemon.c | 31 +--
> > 1 files changed, 29 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
> > index 79eb130..2c24ebf 100644
> > --- a/tools/hv/hv_kvp_daemon.c
> > +++ b/tools/hv/hv_kvp_daemon.c
> > @@ -534,6 +534,7 @@ kvp_get_ip_address(int family, char *if_name, int op,
> > struct ifaddrs *ifap;
> > struct ifaddrs *curp;
> > int offset = 0;
> > + int sn_offset = 0;
> > const char *str;
> > int error = 0;
> > char *buffer;
> > @@ -594,12 +595,38 @@ kvp_get_ip_address(int family, char *if_name, int op,
> > * Gather info other than the IP address.
> > * IP address info will be gathered later.
> > */
> > - if (curp->ifa_addr->sa_family == AF_INET)
> > + if (curp->ifa_addr->sa_family == AF_INET) {
> > ip_buffer->addr_family |= ADDR_FAMILY_IPV4;
> > - else
> > + /*
> > +* Get subnet info.
> > +*/
> > + error = kvp_process_ip_address(
> > + curp->ifa_netmask,
> > + AF_INET,
> > + (char *)
> > + ip_buffer->sub_net,
> > + length,
> > + _offset);
> [...]
>
> This is barely readable; why don't you indent the arguments by just one
> extra tab?
Will do.
Regards,
K. Y
RE: [PATCH 03/17] Drivers: hv: kvp: Cleanup error handling in KVP
> -Original Message-
> From: Ben Hutchings [mailto:b...@decadent.org.uk]
> Sent: Tuesday, July 24, 2012 9:11 PM
> To: KY Srinivasan
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; virtualizat...@lists.osdl.org; o...@aepfle.de;
> a...@canonical.com; net...@vger.kernel.org
> Subject: Re: [PATCH 03/17] Drivers: hv: kvp: Cleanup error handling in KVP
>
> On Tue, 2012-07-24 at 09:01 -0700, K. Y. Srinivasan wrote:
> > In preparation to implementing IP injection, cleanup the way we propagate
> > and handle errors both in the driver as well as in the user level daemon.
> >
> > Signed-off-by: K. Y. Srinivasan
> > Reviewed-by: Haiyang Zhang
> > ---
> > drivers/hv/hv_kvp.c | 112 +-
>
> > include/linux/hyperv.h | 17 +---
> > tools/hv/hv_kvp_daemon.c | 70 +++-
> > 3 files changed, 138 insertions(+), 61 deletions(-)
> >
> > diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
> > index 0012eed..9b7fc4a 100644
> > --- a/drivers/hv/hv_kvp.c
> > +++ b/drivers/hv/hv_kvp.c
> [...]
> > @@ -109,27 +154,52 @@ kvp_cn_callback(struct cn_msg *msg, struct
> netlink_skb_parms *nsp)
> > {
> > struct hv_kvp_msg *message;
> > struct hv_kvp_msg_enumerate *data;
> > + int error = 0;
> >
> > message = (struct hv_kvp_msg *)msg->data;
> > - switch (message->kvp_hdr.operation) {
> > +
> > + /*
> > +* If we are negotiating the version information
> > +* with the daemon; handle that first.
> > +*/
> > +
> > + if (in_hand_shake) {
> > + if (kvp_handle_handshake(message))
> > + in_hand_shake = false;
> > + return;
> > + }
> > +
> > + /*
> > +* Based on the version of the daemon, we propagate errors from the
> > +* daemon differently.
> > +*/
> > +
> > + data = >body.kvp_enum_data;
> > +
> > + switch (dm_reg_value) {
> > case KVP_OP_REGISTER:
> > - pr_info("KVP: user-mode registering done.\n");
> > - kvp_register();
> > - kvp_transaction.active = false;
> > - hv_kvp_onchannelcallback(kvp_transaction.kvp_context);
> > + /*
> > +* Null string is used to pass back error condition.
> > +*/
> > + if (!strlen(data->data.key))
>
> Do we know that the key is null-terminated here? Shouldn't we just
> check whether data->data.key[0] == 0?
Yes, currently we do return null string to indicate error.
>
> > + error = HV_S_CONT;
> > break;
> >
> > - default:
> > - data = >body.kvp_enum_data;
> > + case KVP_OP_REGISTER1:
> > /*
> > -* Complete the transaction by forwarding the key value
> > -* to the host. But first, cancel the timeout.
> > +* We use the message header information from
> > +* the user level daemon to transmit errors.
> > */
> > - if (cancel_delayed_work_sync(_work))
> > - kvp_respond_to_host(data->data.key,
> > -data->data.value,
> > - !strlen(data->data.key));
> > + error = *((int *)(>kvp_hdr.operation));
> [...]
>
> What's with the casting (repeated in many other places)? Wouldn't it be
> better to redefine struct hv_kvp_msg to start with something like:
>
> union {
> struct hv_kvp_hdr request;
> int error;
> } kvp_hdr;
Agreed; will do.
>
> Ben.
>
> --
> Ben Hutchings
> If more than one person is responsible for a bug, no one is at fault.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH v2 1/6] rtc: omap: kicker mechanism support
Hi Sergei, On Wed, Jul 25, 2012 at 16:45:29, Sergei Shtylyov wrote: > > +/* OMAP_RTC_KICKER values */ > > +#defineKICK0_VALUE (0x83e70b13) > > +#defineKICK1_VALUE (0x95a4f1e0) > > Parens not needed around simple literals. Thanks for catching it > > > static void __iomem *rtc_base; > > > > #define rtc_read(addr)__raw_readb(rtc_base + (addr)) > > #define rtc_write(val, addr) __raw_writeb(val, rtc_base + (addr)) > > > > +#define rtc_writel(val, addr) writel(val, rtc_base + (addr)) > > + > > Why not __raw_writel() like the above functions? This driver would be used in AM335X, it being ARMv7, writel would be safe (existing __raw_readb/__raw_writeb too needs to be replaced) Regards Afzal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 05/13] driver core: firmware loader: introduce firmware_buf
On Wed, Jul 25, 2012 at 01:00:05AM +0800, Ming Lei wrote:
> This patch introduces struct firmware_buf to describe the buffer
> which holds the firmware data, which will make the following
> cache_firmware/uncache_firmware implemented easily.
>
> Signed-off-by: Ming Lei
> ---
> drivers/base/firmware_class.c | 176
> +++--
> 1 file changed, 101 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index 0b343b8..986d9df 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -89,7 +89,7 @@ static inline long firmware_loading_timeout(void)
> * guarding for corner cases a global lock should be OK */
> static DEFINE_MUTEX(fw_lock);
>
> -struct firmware_priv {
> +struct firmware_buf {
> struct completion completion;
> struct firmware *fw;
> unsigned long status;
> @@ -98,10 +98,14 @@ struct firmware_priv {
> struct page **pages;
> int nr_pages;
> int page_array_size;
> + char fw_id[];
> +};
> +
> +struct firmware_priv {
> struct timer_list timeout;
> - struct device dev;
> bool nowait;
> - char fw_id[];
> + struct device dev;
> + struct firmware_buf *buf;
> };
>
> static struct firmware_priv *to_firmware_priv(struct device *dev)
> @@ -111,8 +115,10 @@ static struct firmware_priv *to_firmware_priv(struct
> device *dev)
>
> static void fw_load_abort(struct firmware_priv *fw_priv)
> {
> - set_bit(FW_STATUS_ABORT, _priv->status);
> - complete(_priv->completion);
> + struct firmware_buf *buf = fw_priv->buf;
> +
> + set_bit(FW_STATUS_ABORT, >status);
> + complete(>completion);
> }
>
> static ssize_t firmware_timeout_show(struct class *class,
> @@ -152,16 +158,23 @@ static struct class_attribute firmware_class_attrs[] = {
> __ATTR_NULL
> };
>
> -static void fw_dev_release(struct device *dev)
> +static void fw_free_buf(struct firmware_buf *buf)
> {
> - struct firmware_priv *fw_priv = to_firmware_priv(dev);
> int i;
>
> - /* free untransfered pages buffer */
> - for (i = 0; i < fw_priv->nr_pages; i++)
> - __free_page(fw_priv->pages[i]);
> - kfree(fw_priv->pages);
> + if (!buf)
> + return;
This is subtle: the caller of fw_free_buf might forget to assign NULL to
the buf ptr.
Why not pass struct firmware_priv *fw_priv to the function instead and ...
> +
> + for (i = 0; i < buf->nr_pages; i++)
> + __free_page(buf->pages[i]);
> + kfree(buf->pages);
assign NULL to the ptr as a last step, when all is done:
fw_priv->buf = NULL;
This way you're making sure ->buf is NULL after all pages are freed and
your check above is always correct.
> +}
> +
> +static void fw_dev_release(struct device *dev)
> +{
> + struct firmware_priv *fw_priv = to_firmware_priv(dev);
>
> + kfree(fw_priv->buf);
> kfree(fw_priv);
>
> module_put(THIS_MODULE);
> @@ -171,7 +184,7 @@ static int firmware_uevent(struct device *dev, struct
> kobj_uevent_env *env)
> {
> struct firmware_priv *fw_priv = to_firmware_priv(dev);
>
> - if (add_uevent_var(env, "FIRMWARE=%s", fw_priv->fw_id))
> + if (add_uevent_var(env, "FIRMWARE=%s", fw_priv->buf->fw_id))
> return -ENOMEM;
> if (add_uevent_var(env, "TIMEOUT=%i", loading_timeout))
> return -ENOMEM;
> @@ -192,7 +205,7 @@ static ssize_t firmware_loading_show(struct device *dev,
>struct device_attribute *attr, char *buf)
> {
> struct firmware_priv *fw_priv = to_firmware_priv(dev);
> - int loading = test_bit(FW_STATUS_LOADING, _priv->status);
> + int loading = test_bit(FW_STATUS_LOADING, _priv->buf->status);
>
> return sprintf(buf, "%d\n", loading);
> }
> @@ -231,32 +244,33 @@ static ssize_t firmware_loading_store(struct device
> *dev,
> const char *buf, size_t count)
> {
> struct firmware_priv *fw_priv = to_firmware_priv(dev);
> + struct firmware_buf *fw_buf = fw_priv->buf;
> int loading = simple_strtol(buf, NULL, 10);
> int i;
>
> mutex_lock(_lock);
>
> - if (!fw_priv->fw)
> + if (!fw_buf)
> goto out;
>
> switch (loading) {
> case 1:
> /* discarding any previous partial load */
> - if (!test_bit(FW_STATUS_DONE, _priv->status)) {
> - for (i = 0; i < fw_priv->nr_pages; i++)
> - __free_page(fw_priv->pages[i]);
> - kfree(fw_priv->pages);
> - fw_priv->pages = NULL;
> - fw_priv->page_array_size = 0;
> - fw_priv->nr_pages = 0;
> - set_bit(FW_STATUS_LOADING, _priv->status);
> + if (!test_bit(FW_STATUS_DONE, _buf->status)) {
> + for (i = 0; i < fw_buf->nr_pages; i++)
Re: [PATCH v2 1/2] lis3: add generic DT matching code
On 25.07.2012 14:45, Daniel Mack wrote:
> This patch adds logic to parse lis3 properties from a device tree node
> and store them in a freshly allocated lis3lv02d_platform_data.
>
> Note that the actual match tables are left out here. This part should
> happen in the drivers that bind to the individual busses (SPI/I2C/PCI).
>
> Also adds some DT bindinds documentation.
>
> Signed-off-by: Daniel Mack
> ---
>
> v2 of this patch adds some documentation as well, and while writing it,
> I found two minor copy'n paste issues that I also fixed.
>
> Documentation/devicetree/bindings/misc/lis302.txt | 74 +++
> drivers/misc/lis3lv02d/lis3lv02d.c| 137
> +
> drivers/misc/lis3lv02d/lis3lv02d.h|4 +
> 3 files changed, 215 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/lis302.txt
>
> diff --git a/Documentation/devicetree/bindings/misc/lis302.txt
> b/Documentation/devicetree/bindings/misc/lis302.txt
> new file mode 100644
> index 000..66230fd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/lis302.txt
> @@ -0,0 +1,74 @@
> +LIS302 accelerometer devicetree bindings
> +
> +This device is matched via its bus drivers, and has a number of properties
> +that apply in on the generic device (independent from the bus).
> +
> +
> +Required properties for the SPI bindings:
> + - compatible: should be set to "st,lis3lv02d_spi"
> + - reg: the chipselect index
> + - spi-max-frequency:maximal bus speed, should be set to 100
> unless
> + constrained by external circuitry
> + - interrupts: the interrupt generated by the device
> +
> +
> +Optional properties for all bus drivers:
> +
> + - st,click-single-{x,y,z}: if present, tells the device to issue an
> + interrupt on single click events on the
> + x/y/z axis.
> + - st,click-double-{x,y,z}: if present, tells the device to issue an
> + interrupt on double click events on the
> + x/y/z axis.
> + - st,click-thresh-{x,y,z}: set the x/y/z axis threshold
> + - st,click-click-time-limit:click time limit, from 0 to 127.5msec
> + with step of 0.5 msec
> + - st,click-latency: click latency, from 0 to 255 msec with
> + step of 1 msec.
> + - st,click-window: click window, from 0 to 255 msec with
> + step of 1 msec.
> + - st,irq{1,2}-disable: disable IRQ 1/2
> + - st,irq{1,2}-ff-wu-1: raise IRQ 1/2 on FF_WU_1 condition
> + - st,irq{1,2}-ff-wu-2: raise IRQ 1/2 on FF_WU_2 condition
> + - st,irq{1,2}-data-ready: raise IRQ 1/2 on data ready contition
> + - st,irq{1,2}-click:raise IRQ 1/2 on click condition
> + - st,irq-open-drain:consider IRQ lines open-drain
> + - st,irq-active-low:make IRQ lines active low
> + - st,wu-duration-1: duration register for Free-Fall/Wake-Up
> + interrupt 1
> + - st,wu-duration-2: duration register for Free-Fall/Wake-Up
> + interrupt 2
> + - st,wakeup-{x,y,z}-{lo,hi}:set wakeup condition on x/y/z axis for
> + upper/lower limit
> + - st,highpass-cutoff-hz=: 1, 2, 4 or 8 for 1Hz, 2Hz, 4Hz or 8Hz of
> + highpass cut-off frequency
> + - st,hipass{1,2}-disable: disable highpass 1/2.
> + - st,default-rate=: set the default rate
> + - st,axis-{x,y,z}=: set the axis to map to the three coordinates
> +
> +
> +Example for a SPI device node:
> +
> + lis302@0 {
> + compatible = "st,lis302dl-spi";
> + reg = <0>;
> + spi-max-frequency = <100>;
> + interrupt-parent = <>;
> + interrupts = <104 0>;
> +
> + st,click-single-x;
> + st,click-single-y;
> + st,click-single-z;
> + st,click-thresh-x = <10>;
> + st,click-thresh-y = <10>;
> + st,click-thresh-z = <10>;
> + st,irq1-click;
> + st,irq2-click;
> + st,wakeup-x-lo;
> + st,wakeup-x-hi;
> + st,wakeup-y-lo;
> + st,wakeup-y-hi;
> + st,wakeup-z-lo;
> + st,wakeup-z-hi;
> + };
> +
> diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c
> b/drivers/misc/lis3lv02d/lis3lv02d.c
> index a981e2a..22f7d65 100644
> --- a/drivers/misc/lis3lv02d/lis3lv02d.c
> +++ b/drivers/misc/lis3lv02d/lis3lv02d.c
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
> #include "lis3lv02d.h"
>
> #define DRIVER_NAME "lis3lv02d"
> @@ -912,6 +913,138 @@ static void lis3lv02d_8b_configure(struct lis3lv02d
> *lis3,
> }
> }
>
> +#ifdef CONFIG_OF
>
Re: Attaching a process to cgroups
On Wed, 2012-07-25 at 17:36 +0400, Alexey Vlasov wrote:
> Hi.
>
> Now I've got almost 5k used groups and it got even worse. Now I've got
> almost 5k used groups and it got even worse.
>
> If only write was working slower, now everything connected with cgroups
> is hardly working.
>
> Could it be connected with synchronize_rcu()?
I'd profile it with perf, and expect to find a large pile of cycles.
> Hanging on read():
>
> # strace -ttT cat /proc/cgroups
>
> 17:30:43.825005 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 13),
> ...}) = 0 <0.05>
> 17:30:43.825048 open("/proc/cgroups", O_RDONLY) = 3 <0.14>
> 17:30:43.825085 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> <0.04>
> 17:30:43.825125 fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0 <0.05>
> 17:30:43.825161 read(3, "#subsys_name\thierarchy\tnum_cgrou"..., 32768) = 112
> <7.447084>
Ew.. zillion cgroups is definitely a bad idea.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] staging: gdm72xx: fix reference counting in gdm_wimax_event_init
Hi Devendra,
Thanks for cleaning up the driver. If I understand the code
correctly, the original author wanted to initialize wm_event once and
reuse it for multiple devices, and thus reference counted it with
ref_cnt.
For instance, each time gdm_usb_probe() is called, it may call
register_wimax_device() / gdm_wimax_event_init(). wm_event is
initialized the first time when wm_event.ref_cnt == 0 (alternatively,
the code could check !wm_event.sock). Subsequent calls to
gdm_wimax_event_init() will simply increase the ref count. Similarly,
gdm_usb_disconnect() calls unregister_wimax_device() /
gdm_wimax_event_exit(), which decreases the ref count and disposes
wm_event when ref_cnt becomes zero.
The code change in commit 8df858ea76b76dde9a39d4edd9aaded983582cfe
only prevents ref_cnt from increasing beyond one. So the code no
longer work when there are multiple devices (i.e. wm_event could be
disposed even when there is an active device).
Thanks,
Ben
On Tue, Jul 24, 2012 at 9:50 PM, devendra.aaru wrote:
> On Tue, Jul 24, 2012 at 8:34 PM, Ben Chan wrote:
>> This patch fixes the commit "staging/gdm72xx: cleanup little at
>> gdm_wimax_event_rcv" (8df858ea76b76dde9a39d4edd9aaded983582cfe),
>> which mishandles the reference counting of wm_event.
>>
>> Signed-off-by: Ben Chan
>> ---
>> Fixed the commit message as suggested by Dan Carpenter.
>>
>> drivers/staging/gdm72xx/gdm_wimax.c | 16 ++--
>> 1 files changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/staging/gdm72xx/gdm_wimax.c
>> b/drivers/staging/gdm72xx/gdm_wimax.c
>> index 0716efc..6cb8107 100644
>> --- a/drivers/staging/gdm72xx/gdm_wimax.c
>> +++ b/drivers/staging/gdm72xx/gdm_wimax.c
>> @@ -258,12 +258,16 @@ static int gdm_wimax_event_init(void)
>> if (!wm_event.ref_cnt) {
>> wm_event.sock = netlink_init(NETLINK_WIMAX,
>> gdm_wimax_event_rcv);
>> - if (wm_event.sock)
>> - wm_event.ref_cnt++;
>> - INIT_LIST_HEAD(_event.evtq);
>> - INIT_LIST_HEAD(_event.freeq);
>> - INIT_WORK(_event.ws, __gdm_wimax_event_send);
>> - spin_lock_init(_event.evt_lock);
>> + if (wm_event.sock) {
>> + INIT_LIST_HEAD(_event.evtq);
>> + INIT_LIST_HEAD(_event.freeq);
>> + INIT_WORK(_event.ws, __gdm_wimax_event_send);
>> + spin_lock_init(_event.evt_lock);
>> + }
>> + }
>> +
>> + if (wm_event.sock) {
>> + wm_event.ref_cnt++;
>> return 0;
>> }
>>
>> --
>> 1.7.7.3
>>
>
> Hi Ben,
>
> I have some basic understanding about this flow of the function,
>
> Here is my understanding of the thing i have done when i was doing
> some cleanups to this driver.
>
> The ref_cnt will be 0 at first time. if so the sock creation happens
> only once, and register_wimax_device only calls this function.
> so i think doing the ref_cnt++ inside the if (!wm_event.ref_cnt) is valid.
>
> Please suggest me if i am wrong.
>
> Thanks,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
FYI: Example [Re: [PATCH] scripts/kernel-doc: added support for html5]
On Wed, 2012-07-25 at 15:38 +0200, Dan Luedtke wrote:
> New output option html5 writes validating HTML5 and adds
> CSS classes ready to be selected by third-party stylesheets.
An example, generated with the patched version of kernel-doc:
https://www.nonattached.net/lanyfs/doc-linux.php
Uses CSS like this:
article.doc,
article.enum,
article.typedef,
article.struct,
article.function {
margin-bottom: 50px;
}
/* markup */
span.keyword {
font-weight: bold;
color: #000;
}
span.type {
font-weight: normal;
color: #284689;
}
span.identifier {
font-weight: bold;
color: #c43;
}
--
Dan Luedtke
http://www.danrl.de
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] xc5000: Add MODULE_FIRMWARE statements
On 07/25/2012 04:24 PM, Devin Heitmueller wrote:
On Wed, Jul 25, 2012 at 9:15 AM, Tim Gardner wrote:
This will make modinfo more useful with regard
to discovering necessary firmware files.
Cc: Mauro Carvalho Chehab
Cc: Michael Krufky
Cc: Eddi De Pieri
Cc: linux-me...@vger.kernel.org
Signed-off-by: Tim Gardner
---
drivers/media/common/tuners/xc5000.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/media/common/tuners/xc5000.c
b/drivers/media/common/tuners/xc5000.c
index dcca42c..4d33f86 100644
--- a/drivers/media/common/tuners/xc5000.c
+++ b/drivers/media/common/tuners/xc5000.c
@@ -210,13 +210,15 @@ struct xc5000_fw_cfg {
u16 size;
};
+#define XC5000A_FIRMWARE "dvb-fe-xc5000-1.6.114.fw"
static const struct xc5000_fw_cfg xc5000a_1_6_114 = {
- .name = "dvb-fe-xc5000-1.6.114.fw",
+ .name = XC5000A_FIRMWARE,
.size = 12401,
};
+#define XC5000C_FIRMWARE "dvb-fe-xc5000c-41.024.5.fw"
static const struct xc5000_fw_cfg xc5000c_41_024_5 = {
- .name = "dvb-fe-xc5000c-41.024.5.fw",
+ .name = XC5000C_FIRMWARE,
.size = 16497,
};
@@ -1253,3 +1255,5 @@ EXPORT_SYMBOL(xc5000_attach);
MODULE_AUTHOR("Steven Toth");
MODULE_DESCRIPTION("Xceive xc5000 silicon tuner driver");
MODULE_LICENSE("GPL");
+MODULE_FIRMWARE(XC5000A_FIRMWARE);
+MODULE_FIRMWARE(XC5000C_FIRMWARE);
--
Hi Tim,
I'm just eyeballing the patch and I'm not familiar with this new
functionality, but where are the new macros you're specifying actually
defined? You're swapping out the filename for XC5000A_FIRMWARE, but
where is the actual reference to "dvb-fe-xc5000-1.6.114.fw"?
Also, Mauro, can I merge this into my tree first rather than you
pulling it direct? I've got a whole patch series for xc5000 that I'm
slated to issue a PULL for this weekend, and I *really* don't want to
rebase the series for a four line change (which will definitely cause
a conflict).
Devin
Also this issue has been spoken earlier and nacked. It was 2009 when Ben
Hutchings sends large patch serie adding MODULE_FIRMWARE for every
Linux-Media driver. I am not sure if arguments are changed after that to
allow it now.
http://www.mail-archive.com/linux-media@vger.kernel.org/msg11373.html
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] scripts/kernel-doc: added support for html5
New output option html5 writes validating HTML5 and adds
CSS classes ready to be selected by third-party stylesheets.
Signed-off-by: Dan Luedtke
---
scripts/kernel-doc | 255 ++--
1 file changed, 249 insertions(+), 6 deletions(-)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 9b0c0b8..f85b278 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -6,6 +6,7 @@ use strict;
## Copyright (C) 2000, 1 Tim Waugh ##
## Copyright (C) 2001 Simon Huggins ##
## Copyright (C) 2005-2012 Randy Dunlap ##
+## Copyright (C) 2012 Dan Luedtke ##
## ##
## #define enhancements by Armin Kuster ##
## Copyright (c) 2000 MontaVista Software, Inc. ##
@@ -35,6 +36,8 @@ use strict;
# Small fixes (like spaces vs. \s in regex)
# -- Tim Jansen
+# 25/07/2012 - Added support for HTML5
+# -- Dan Luedtke
#
# This will read a 'c' file and scan for embedded comments in the
@@ -44,12 +47,16 @@ use strict;
# Note: This only supports 'c'.
# usage:
-# kernel-doc [ -docbook | -html | -text | -man | -list ] [ -no-doc-sections ]
-# [ -function funcname [ -function funcname ...] ] c file(s)s >
outputfile
+# kernel-doc [ -docbook | -html | -html5 | -text | -man | -list ]
+#[ -no-doc-sections ]
+#[ -function funcname [ -function funcname ...] ]
+#c file(s)s > outputfile
# or
-# [ -nofunction funcname [ -function funcname ...] ] c file(s)s >
outputfile
+#[ -nofunction funcname [ -function funcname ...] ]
+#c file(s)s > outputfile
#
-# Set output format using one of -docbook -html -text or -man. Default is
man.
+# Set output format using one of -docbook -html -html5 -text or -man.
+# Default is man.
# The -list format is for internal use by docproc.
#
# -no-doc-sections
@@ -182,6 +189,14 @@ my $local_lt = "lt:";
my $local_gt = "gt:";
my $blankline_html = $local_lt . "p" . $local_gt; # was ""
+# modern html
+my %highlights_html5 = ( $type_constant, "\$1",
+ $type_func, "\$1",
+ $type_struct_xml, "\$1",
+ $type_env, "\$1",
+ $type_param, "\$1" );
+my $blankline_html5 = $local_lt . "br /" . $local_gt;
+
# XML, docbook format
my %highlights_xml = ( "([^=])\\\"([^\\\"<]+)\\\"", "\$1\$2",
$type_constant, "\$1",
@@ -309,6 +324,10 @@ while ($ARGV[0] =~ m/^-(.*)/) {
$output_mode = "html";
%highlights = %highlights_html;
$blankline = $blankline_html;
+} elsif ($cmd eq "-html5") {
+ $output_mode = "html5";
+ %highlights = %highlights_html5;
+ $blankline = $blankline_html5;
} elsif ($cmd eq "-man") {
$output_mode = "man";
%highlights = %highlights_man;
@@ -351,10 +370,11 @@ while ($ARGV[0] =~ m/^-(.*)/) {
# continue execution near EOF;
sub usage {
-print "Usage: $0 [ -v ] [ -docbook | -html | -text | -man | -list ]\n";
+print "Usage: $0 [ -docbook | -html | -html5 | -text | -man | -list ]\n";
print " [ -no-doc-sections ]\n";
print " [ -function funcname [ -function funcname ...] ]\n";
print " [ -nofunction funcname [ -nofunction funcname ...] ]\n";
+print " [ -v ]\n";
print " c source file(s) > outputfile\n";
print " -v : verbose output, more warnings & other info listed\n";
exit 1;
@@ -448,7 +468,8 @@ sub output_highlight {
# confess "output_highlight got called with no args?\n";
# }
-if ($output_mode eq "html" || $output_mode eq "xml") {
+if ($output_mode eq "html" || $output_mode eq "html5" ||
+ $output_mode eq "xml") {
$contents = local_unescape($contents);
# convert data read & converted thru xml_escape() into format:
$contents =~ s/\\/\&/g;
@@ -458,6 +479,11 @@ sub output_highlight {
die $@ if $@;
# print STDERR "contents af:$contents\n";
+# strip whitespaces when generating html5
+if ($output_mode eq "html5") {
+ $contents =~ s/^\s+//;
+ $contents =~ s/\s+$//;
+}
foreach $line (split "\n", $contents) {
if ($line eq ""){
print $lineprefix, local_unescape($blankline);
@@ -633,6 +659,223 @@ sub output_blockhead_html(%) {
print "\n";
}
+#output sections in html5
+sub output_section_html5(%) {
+my %args = %{$_[0]};
+my $section;
+
+foreach $section (@{$args{'sectionlist'}}) {
+ print "\n";
+ print "$section\n";
+ print "\n";
+ output_highlight($args{'sections'}{$section});
+ print "\n";
+ print "\n";
+}
+}
+
+# output enum in html5
+sub output_enum_html5(%) {
+my %args = %{$_[0]};
+my ($parameter);
+my $count;
+
Re: [PATCH] xc5000: Add MODULE_FIRMWARE statements
On 07/25/2012 07:24 AM, Devin Heitmueller wrote:
> On Wed, Jul 25, 2012 at 9:15 AM, Tim Gardner
> wrote:
>> This will make modinfo more useful with regard
>> to discovering necessary firmware files.
>>
>> Cc: Mauro Carvalho Chehab
>> Cc: Michael Krufky
>> Cc: Eddi De Pieri
>> Cc: linux-me...@vger.kernel.org
>> Signed-off-by: Tim Gardner
>> ---
>> drivers/media/common/tuners/xc5000.c |8 ++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/common/tuners/xc5000.c
>> b/drivers/media/common/tuners/xc5000.c
>> index dcca42c..4d33f86 100644
>> --- a/drivers/media/common/tuners/xc5000.c
>> +++ b/drivers/media/common/tuners/xc5000.c
>> @@ -210,13 +210,15 @@ struct xc5000_fw_cfg {
>> u16 size;
>> };
>>
>> +#define XC5000A_FIRMWARE "dvb-fe-xc5000-1.6.114.fw"
>> static const struct xc5000_fw_cfg xc5000a_1_6_114 = {
>> - .name = "dvb-fe-xc5000-1.6.114.fw",
>> + .name = XC5000A_FIRMWARE,
>> .size = 12401,
>> };
>>
>> +#define XC5000C_FIRMWARE "dvb-fe-xc5000c-41.024.5.fw"
>> static const struct xc5000_fw_cfg xc5000c_41_024_5 = {
>> - .name = "dvb-fe-xc5000c-41.024.5.fw",
>> + .name = XC5000C_FIRMWARE,
>> .size = 16497,
>> };
>>
>> @@ -1253,3 +1255,5 @@ EXPORT_SYMBOL(xc5000_attach);
>> MODULE_AUTHOR("Steven Toth");
>> MODULE_DESCRIPTION("Xceive xc5000 silicon tuner driver");
>> MODULE_LICENSE("GPL");
>> +MODULE_FIRMWARE(XC5000A_FIRMWARE);
>> +MODULE_FIRMWARE(XC5000C_FIRMWARE);
>> --
>
> Hi Tim,
>
> I'm just eyeballing the patch and I'm not familiar with this new
> functionality, but where are the new macros you're specifying actually
> defined? You're swapping out the filename for XC5000A_FIRMWARE, but
> where is the actual reference to "dvb-fe-xc5000-1.6.114.fw"?
>
Devin - Please have a closer look. XC5000A_FIRMWARE and XC5000C_FIRMWARE
are defined in the patch.
MODULE_FIRMWARE() is defined in linux/module.h. It creates a firmware
section such that modinfo can print the names of the firmware files that
may possibly be in use by this module.
rtg
--
Tim Gardner tim.gard...@canonical.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] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list
Il 25/07/2012 15:26, Boaz Harrosh ha scritto: > On 07/25/2012 03:49 PM, Paolo Bonzini wrote: > >> >> Except here the destination array has to be given to virtio, which >> doesn't (yet) understand chaining. I'm using for_each_sg rather than a >> simple memcpy exactly because I want to flatten the input scatterlist >> onto consecutive scatterlist entries, which is what virtio expects (and >> what I'll change when I get to it). >> >> for_each_sg guarantees that I get non-chain scatterlists only, so it is >> okay to value-assign them to sg[]. > > So if the virtio does not understand chaining at all then surly it will > not understand the 2-bit end marker and will get a wrong page pointer > with the 1st bit set. It doesn't understand chaining, but it does use sg_phys(x) so it will not get a wrong page pointer for the end marker. > Fine then your code is now a crash because the terminating bit was just > copied over, which it was not before. I did test the patch with value-assignment. > Lets separate the two topics from now on. Send me one mail concerning > the proper above patch, And a different mail for how to support chaining. Ok, and I'll change the topic. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: x86/mm: Limit 2/4M size calculation to x86_32
On 07/25/2012 04:24 PM, Stefan Bader wrote: >>> ... >>> ifdef CONFIG_X86_32 >>> /* >>> * Don't use a large page for the first 2/4MB of memory >>> * because there are often fixed size MTRRs in there >>> * and overlapping MTRRs into large pages can cause >>> * slowdowns. >>> */ >>> >> >> That's equally true for X86_64. >> >> Best would be to merge the MTRRs into PAT, but that might not work for SMM. >> >> > Ok, true. Not sure why this was restricted to 32bit when reconsidering. Except > if in 64bit it was assumed (or asserted) that the regions are aligned to 2M... > But maybe this can be answered by someone knowing the details. I would not > mind > either way (have the first range with 4K pages in all cases or fixing the > additional PTE allocation). Just as it is now it is inconsistent. Sometimes CONFIG_X86_32 is used as an alias for "machines so old they don't support x86_64". As a 32-bit kernel can be run on a machine that does support x86_64, it should be replaced by a runtime test for X86_FEATURE_LM, until a more accurate test can be found. -- 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/
[PATCH] ia64: rename platform_* to ia64_platform_*
On Wed, Jul 25, 2012 at 01:18:39AM -0700, Joe Perches wrote:
> On Wed, 2012-07-25 at 16:06 +0800, Fengguang Wu wrote:
> > The macro name is too generic and conflicts with
> > snd_soc_dai_link.platform_name, which triggers lots of ALSA build errors.
>
> Is platform_name particularly special?
>
> Perhaps it's be better to rename all the other
> platform_ uses to ia64_platform_
That's good point in general, oh well I just wanted to make the minimal change..
> []
>
> > diff --git a/arch/ia64/include/asm/machvec.h
> > b/arch/ia64/include/asm/machvec.h
> []
> > @@ -120,7 +120,7 @@ extern void machvec_tlb_migrate_finish (struct
> > mm_struct *);
> > # ifdef MACHVEC_PLATFORM_HEADER
> > # include MACHVEC_PLATFORM_HEADER
> > # else
> > -# define platform_nameia64_mv.name
> > +# define ia64_platform_name ia64_mv.name
> > # define platform_setup ia64_mv.setup
> > # define platform_cpu_initia64_mv.cpu_init
> > # define platform_irq_initia64_mv.irq_init
>
> Maybe something like:
>
> $ git ls-files arch/ia64 | \
> xargs sed -r -i 's/\bplatform_([a-z_]+)\b/ia64_platform_\1/g'
Thanks! To avoid some undesired changes, I ended up with the below script :)
Thanks,
Fengguang
---
>From a099f447c2718ee9416dbdb24dd18789ebabfc5c Mon Sep 17 00:00:00 2001
From: Fengguang Wu
Date: Wed, 25 Jul 2012 20:24:28 +0800
Subject: [PATCH] ia64: rename platform_* to ia64_platform_*
The macro names are a bit too generic. In particular, platform_name
conflicts with snd_soc_dai_link.platform_name, which triggers lots of
ALSA build errors.
Generated by script, manual fixed indents and compile tested.
sed -r -i
's/\b(platform_name|platform_pci_fixup|platform_setup|platform_cpu_init|platform_irq_init|platform_send_ipi|platform_timer_interrupt|platform_global_tlb_purge|platform_tlb_migrate_finish|platform_dma_init|platform_dma_get_required_mask|platform_dma_get_ops|platform_irq_to_vector|platform_local_vector_to_irq|platform_pci_get_legacy_mem|platform_pci_legacy_read|platform_pci_legacy_write|platform_inb|platform_inw|platform_inl|platform_outb|platform_outw|platform_outl|platform_mmiowb|platform_readb|platform_readw|platform_readl|platform_readq|platform_readb_relaxed|platform_readw_relaxed|platform_readl_relaxed|platform_readq_relaxed|platform_migrate|platform_setup_msi_irq|platform_teardown_msi_irq|platform_pci_fixup_bus|platform_kernel_launch_event)\b/ia64_\1/g'
$(grep -r --files-with-matches '\
Signed-off-by: Fengguang Wu
---
arch/ia64/include/asm/dma-mapping.h | 10 +-
arch/ia64/include/asm/hw_irq.h|6 +-
arch/ia64/include/asm/io.h| 42 ++--
arch/ia64/include/asm/machvec.h | 282 -
arch/ia64/include/asm/machvec_dig.h |4 +-
arch/ia64/include/asm/machvec_dig_vtd.h |6 +-
arch/ia64/include/asm/machvec_hpsim.h | 10 +-
arch/ia64/include/asm/machvec_hpzx1.h |6 +-
arch/ia64/include/asm/machvec_hpzx1_swiotlb.h | 12 +-
arch/ia64/include/asm/machvec_sn2.h | 128 +--
arch/ia64/include/asm/machvec_uv.h|6 +-
arch/ia64/include/asm/machvec_xen.h | 10 +-
arch/ia64/include/asm/pci.h |6 +-
arch/ia64/include/asm/processor.h |2 +-
arch/ia64/include/asm/switch_to.h |2 +-
arch/ia64/include/asm/tlb.h |2 +-
arch/ia64/kernel/iosapic.c|6 +-
arch/ia64/kernel/irq_ia64.c |7 +-
arch/ia64/kernel/machine_kexec.c |2 +-
arch/ia64/kernel/mca.c| 12 +-
arch/ia64/kernel/msi_ia64.c |8 +-
arch/ia64/kernel/sal.c|2 +-
arch/ia64/kernel/setup.c |4 +-
arch/ia64/kernel/smp.c| 10 +-
arch/ia64/kernel/smpboot.c|2 +-
arch/ia64/kernel/time.c |2 +-
arch/ia64/mm/discontig.c |2 +-
arch/ia64/mm/init.c |2 +-
arch/ia64/mm/tlb.c|2 +-
arch/ia64/pci/fixup.c |4 +-
arch/ia64/pci/pci.c |4 +-
arch/ia64/sn/kernel/setup.c |2 +-
32 files changed, 304 insertions(+), 301 deletions(-)
diff --git a/arch/ia64/include/asm/dma-mapping.h
b/arch/ia64/include/asm/dma-mapping.h
index 4f5e814..4543953 100644
--- a/arch/ia64/include/asm/dma-mapping.h
+++ b/arch/ia64/include/asm/dma-mapping.h
@@ -29,7 +29,7 @@ static inline void *dma_alloc_attrs(struct device *dev,
size_t size,
dma_addr_t *daddr, gfp_t gfp,
struct dma_attrs *attrs)
{
- struct dma_map_ops *ops = platform_dma_get_ops(dev);
+ const struct dma_map_ops *ops = ia64_platform_dma_get_ops(dev);
void *caddr;
Re: [08/36] AArch64: Kernel booting and initialisation
On 07/25/2012 04:47 AM, Catalin Marinas wrote: > On Tue, Jul 24, 2012 at 08:42:28PM +0100, Christopher Covington wrote: >> On 01/-10/-28163 02:59 PM, Catalin Marinas wrote: >>> +- Architected timers >>> + CNTFRQ must be programmed with the timer frequency. >>> + If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) >>> + set where available. >> >> After Marc Zyngier's virtual timer patches come in, will the latter >> requirement only be strictly necessary for kernels wanting to do >> virtualization? > > A kernel is usually entered at EL1 (rather than EL2) if it is a guest. > In this case, the EL1PCTEN bit should have been enabled from the higher > level to give access to the physical counter. Ah right, those patches still use the physical counter for the clocksource and cyclecounter interfaces. Thanks, Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Attaching a process to cgroups
Hi.
Now I've got almost 5k used groups and it got even worse. Now I've got
almost 5k used groups and it got even worse.
If only write was working slower, now everything connected with cgroups
is hardly working.
Could it be connected with synchronize_rcu()?
Hanging on read():
# strace -ttT cat /proc/cgroups
17:30:43.825005 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 13), ...})
= 0 <0.05>
17:30:43.825048 open("/proc/cgroups", O_RDONLY) = 3 <0.14>
17:30:43.825085 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 <0.04>
17:30:43.825125 fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0 <0.05>
17:30:43.825161 read(3, "#subsys_name\thierarchy\tnum_cgrou"..., 32768) = 112
<7.447084>
17:30:51.272302 write(1, "#subsys_name\thierarchy\tnum_cgrou"...,
112#subsys_name hierarchy num_cgroups enabled
cpuacct 1 16844 1
memory 2 16844 1
devices 3 16844 1
blkio 4 16844 1
) = 112 <0.18>
17:30:51.272363 read(3, "", 32768) = 0 <0.07>
17:30:51.272405 brk(0x62d000) = 0x62d000 <0.11>
17:30:51.272444 close(3)= 0 <0.11>
17:30:51.272488 close(1)= 0 <0.07>
17:30:51.272518 close(2)= 0 <0.05>
On Wed, Jun 20, 2012 at 02:28:18PM +0200, Mike Galbraith wrote:
> On Tue, 2012-06-19 at 22:58 +0400, Alexey Vlasov wrote:
> > Is it possible to somehow fasten a process of pid attaching to cgroup?
> > The problem is the pid attaches to a task-file with some strange delay:
> >
> > 22:28:00.788224
> > open("/sys/fs/cgroup/memory/virtwww/w_test-l24-apache1_4bdf3d13/apache/tasks",
> > O_WRONLY|O_CREAT|O_APPEND, 0666) = 3 <0.35>
> > 22:28:00.788289 fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> > <0.04>
> > 22:28:00.788326 mmap(NULL, 4096, PROT_READ|PROT_WRITE,
> > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5e78074000 <0.05>
> > 22:28:00.788355 fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> > <0.04>
> > 22:28:00.788389 lseek(3, 0, SEEK_SET) = 0 <0.04>
> > 22:28:00.788426 write(3, "16317\n", 6) = 6 <0.128094>
> > 22:28:00.916578 close(3)= 0 <0.06>
>
>
> kernel/cgroup.c::cgroup_attach_task()
> {
> ...
> synchronize_rcu();
> ...
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] misc/pch_phub: Enable UART clock setting by module parameter
Hi Tomoya, On Tuesday 24 July 2012, Tomoya MORINAGA wrote: > Let me know this patch status. > If you have still any concern, let me know. Sorry for the late reply. > BTW, now I remember, Did you take part in LinuxConJapan last month ? > I also took part in this event as volunteer staff. > Additionally, I took charge of your session as time keeper. > > Thanks in advance. > -- > ROHM Co., Ltd. > tomoya > > On Thu, Jul 12, 2012 at 9:54 AM, Tomoya MORINAGA > wrote: > > On Wed, Jul 11, 2012 at 7:45 PM, Arnd Bergmann wrote: > >> This looks like a rather nonscalable solution if you get to systems > >> with lots of clocks. > > > > This "clock" is internal clock, not external clock. > > This PacketHub provides clock to the UART module > > Both the PacketHub and the UART is in 1 chip LSI which is EG20T. > > So, selectable clock 1.8432MHz or 48MHz or 64MHz or 192MHz are enough. Right, I got this part. > >> Given that you are doing it for the uart clock, shouldn't that be > >> set from the uart driver using an ioctl like other serial ports do? > > PacketHub is not serial driver but special driver. So, ioctl doesn't > > suit PacketHub. > > > >> What would be the use case for an end user to override the module > >> parameter? Is it about platform specific settings or policy? > > I show use case. > > Currently, UART works with 1.8432MHz. > > Using this clock, as you know, maximum speed is 115k. > > A user wants to use 4M speed, the user need to modify pch_phun.c by hand. > > If this patch is applied, a user can specify uart_clock via a modules > > parameter and use 4M speed. > > > > My reference driver for this patch is drivers/tty/serial/pch_uart.c > > This driver can set uart_clock via a module parameter(user_uartclk). It's clear that modifying the source code is not a good solution, so I agree something should be done about it. What I think should work better here would be to use the clk API, so that the phub driver registers a 'struct clk' using (I assume) clk_register_divider_table(). The UART driver would then call clk_get() to find that clk for the uart device and call clk_set_rate when it needs to change that clock in order to set a different baud rate. Does this make sense? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list
On 07/25/2012 03:49 PM, Paolo Bonzini wrote: > > Except here the destination array has to be given to virtio, which > doesn't (yet) understand chaining. I'm using for_each_sg rather than a > simple memcpy exactly because I want to flatten the input scatterlist > onto consecutive scatterlist entries, which is what virtio expects (and > what I'll change when I get to it). > > for_each_sg guarantees that I get non-chain scatterlists only, so it is > okay to value-assign them to sg[]. > So if the virtio does not understand chaining at all then surly it will not understand the 2-bit end marker and will get a wrong page pointer with the 1st bit set. As I said!! Since the last code did sg_set_buff() and worked then you must change it with sg_set_page(). If there are *any* chaining-or-no-chaining markers errors these should be fixed as a separate patch! Please lets concentrate at the problem at hand. > > It was _not_ properly terminated, and didn't matter because virtio > doesn't care about termination. Changing all the virtio devices to > properly terminate chains (and to use for_each_sg) is a prerequisite for > properly supporting long sglists). > Fine then your code is now a crash because the terminating bit was just copied over, which it was not before. Now Back to the how to support chaining: Lets separate the two topics from now on. Send me one mail concerning the proper above patch, And a different mail for how to support chaining. >> In SCSI land most LLDs should support chaining just by virtu of using the >> for_each_sg macro. That all it takes. Your code above does support it. > > Yes, it supports it but still has to undo them before passing to virtio. > > What my LLD does is add a request descriptor in front of the scatterlist > that the LLD receives. I would like to do this with a 2-item > scatterlist: one for the request descriptor, and one which is a chain to > the original scatterlist. I hate that plan. Why yet override the scatter element yet again with a third union of a "request descriptor" The reason it was overloaded as a link-pointer in the first place was because of historical compatibility reasons and not because of a good design. You should have a proper "request descriptor" structure defined, pointing to (or followed by), an sglist-chain. And all of the above is mute. > Except that if I call sg_chain and my > architecture does not define ARCH_HAS_SG_CHAIN, it will BUG out. So I > need to keep all the scatterlist allocation and copying crap that I have > now within #ifdef, and it will bitrot. > except that with the correct design you don't call sg_chain you just do: request_descriptor->sg_list = sg; >>> I would need to add support for the long sglists to virtio; this is not >>> a problem, but in the past Rusty complained that long sg-lists are not >>> well suited to virtio (which would like to add elements not just at the >>> beginning of a given sglist, but also at the end). >> >> Well that can be done as well, (If done carefully) It should be easy to add >> chained fragments to both the end of a given chain just as at beginning. >> It only means that the last element of the appended-to chain moves to >> the next fragment and it's place is replaced by a link. > > But you cannot do that in constant time, can you? And that means you do > not enjoy any benefit in terms of cache misses etc. > I did not understand "constant time" it is O(0) if that what you meant. (And surly today's code of copy the full list "cache misses") > Also, this assumes that I can modify the appended-to chain. I'm not > sure I can do this? > Each case it's own. If the appended-to chain is const, yes you'll have to reallocate it and copy. Is that your case? Cheers Boaz >>> It seems to me that virtio would prefer to work with a struct >>> scatterlist ** rather than a long sglist. >> >> That's just going backwards, and lazy. As you said if you want to enjoy >> the better performance cake you better break some eggs ;-) > > :) > > Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: coccinelle hung on mini_lock.cocci
Thanks for the report! I will look into it.
julia
On Wed, 25 Jul 2012, Fengguang Wu wrote:
> Hi all,
>
> This command seem to hang for ever on the current linus/master.
> It happens only on mini_lock.cocci _and_ mm/shmem.c
> I've updated coccinelle to its git release, however it didn't help..
>
> % spatch -debug -D report -I /c/kernel-tests/src/linux/include -sp_file
> /c/kernel-tests/src/linux/scripts/coccinelle/locks/mini_lock.cocci
> -no_includes -include_headers /c/kernel-tests/src/linux/mm/shmem.c
> -no_show_diff
> init_defs_builtins: /usr/share/coccinelle/standard.h
> ---
> processing semantic patch file:
> /c/kernel-tests/src/linux/scripts/coccinelle/locks/mini_lock.cocci
> with isos from: /usr/share/coccinelle/standard.iso
> ---
> /// Find missing unlocks. This semantic match considers the specific case
> /// where the unlock is missing from an if branch, and there is a lock
> /// before the if and an unlock after the if. False positives are due to
> /// cases where the if branch represents a case where the function is
> /// supposed to exit with the lock held, or where there is some preceding
> /// function call that releases the lock.
> ///
> // Confidence: Moderate
> // Copyright: (C) 2010-2012 Nicolas Palix. GPLv2.
> // Copyright: (C) 2010-2012 Julia Lawall, INRIA/LIP6. GPLv2.
> // Copyright: (C) 2010-2012 Gilles Muller, INRIA/LiP6. GPLv2.
> // URL: http://coccinelle.lip6.fr/
> // Comments:
> // Options: -no_includes -include_headers
>
> virtual context
> virtual org
> virtual report
>
> @prelocked@
> position p1,p;
> expression E1;
> @@
>
> (
> mutex_lock@p1
> |
> mutex_trylock@p1
> |
> spin_lock@p1
> |
> spin_trylock@p1
> |
> read_lock@p1
> |
> read_trylock@p1
> |
> write_lock@p1
> |
> write_trylock@p1
> |
> read_lock_irq@p1
> |
> write_lock_irq@p1
> |
> read_lock_irqsave@p1
> |
> write_lock_irqsave@p1
> |
> spin_lock_irq@p1
> |
> spin_lock_irqsave@p1
> ) (E1@p,...);
>
> @looped@
> position r;
> @@
>
> for(...;...;...) { <+... return@r ...; ...+> }
>
> @err exists@
> expression E1;
> position prelocked.p;
> position up != prelocked.p1;
> position r!=looped.r;
> identifier lock,unlock;
> @@
>
> *lock(E1@p,...);
> <+... when != E1
> if (...) {
> ... when != E1
> * return@r ...;
> }
> ...+>
> *unlock@up(E1,...);
>
> @script:python depends on org@
> p << prelocked.p1;
> lock << err.lock;
> unlock << err.unlock;
> p2 << err.r;
> @@
>
> cocci.print_main(lock,p)
> cocci.print_secs(unlock,p2)
>
> @script:python depends on report@
> p << prelocked.p1;
> lock << err.lock;
> unlock << err.unlock;
> p2 << err.r;
> @@
>
> msg = "preceding lock on line %s" % (p[0].line)
> coccilib.report.print_report(p2[0],msg)
>
> ---
> script rule -1 =
> ---
> dependencies for script satisfied:
> binding in = []
> HANDLING: /c/kernel-tests/src/linux/mm/shmem.c
> ---
> let's go
> ---
> Defined virtual rules: report
> ---
> CFG: orphelin nodes, maybe something weird happened
> ---
> prelocked =
> ---
> dependencies for rule prelocked satisfied:
> binding in = []
> binding relevant in = []
> transformation info is empty
> binding out = [prelocked.p1 -->
> poss[(/c/kernel-tests/src/linux/mm/shmem.c,shmem_reserve_inode,(194,2),(194,11))];
>prelocked.p -->
> poss[(/c/kernel-tests/src/linux/mm/shmem.c,shmem_reserve_inode,(194,12),(194,30))]]
> transformation info is empty
> binding out = [prelocked.p1 -->
> poss[(/c/kernel-tests/src/linux/mm/shmem.c,shmem_free_inode,(209,2),(209,11))];
>prelocked.p -->
> poss[(/c/kernel-tests/src/linux/mm/shmem.c,shmem_free_inode,(209,12),(209,30))]]
> transformation info is empty
> binding out = [prelocked.p1 -->
> poss[(/c/kernel-tests/src/linux/mm/shmem.c,shmem_add_to_page_cache,(300,1),(300,14))];
>prelocked.p -->
> poss[(/c/kernel-tests/src/linux/mm/shmem.c,shmem_add_to_page_cache,(300,15),(300,34))]]
> transformation info is empty
> binding out = [prelocked.p1 -->
> poss[(/c/kernel-tests/src/linux/mm/shmem.c,shmem_delete_from_page_cache,(327,1),(327,14))];
>prelocked.p -->
> poss[(/c/kernel-tests/src/linux/mm/shmem.c,shmem_delete_from_page_cache,(327,15),(327,34))]]
> transformation info is empty
> binding out = [prelocked.p1 -->
> poss[(/c/kernel-tests/src/linux/mm/shmem.c,shmem_free_swap,(397,1),(397,14))];
>
Re: x86/mm: Limit 2/4M size calculation to x86_32
On 25.07.2012 14:32, Avi Kivity wrote: > On 07/25/2012 02:14 PM, Stefan Bader wrote: >> On 25.07.2012 12:44, Avi Kivity wrote: >>> On 07/24/2012 06:52 PM, Cong Wang wrote: >>> > From 6b679d1af20656929c0e829f29eed60b0a86a74f Mon Sep 17 00:00:00 2001 > From: Stefan Bader > Date: Fri, 13 Jul 2012 15:16:33 +0200 > Subject: [PATCH] x86/mm: Limit 2/4M size calculation to x86_32 > > commit 722bc6b (x86/mm: Fix the size calculation of mapping tables) > did modify the extra space calculation for mapping tables in order > to make up for the first 2/4M memory range using 4K pages. > However this setup is only used when compiling for 32bit. On 64bit > there is only the trailing area of 4K pages (which is already added). > > The code was already adapted once for things went wrong on a 8TB > machine (bd2753b x86/mm: Only add extra pages count for the first memory > range during pre-allocation early page table space), but it looks a bit > like it currently would overdo things for 64bit. > I only noticed while bisecting for the reason I could not make a crash > kernel boot (which ended up on this patch). > > Signed-off-by: Stefan Bader > Cc: WANG Cong > Cc: Yinghai Lu > Cc: Tejun Heo Acked-by: Cong Wang Sorry for that I was not aware of x86_64 is different with x86 in the first 2/4M. >>> >>> Why would there be a difference? >>> >>> Shouldn't the IO space at 0xa-0x10 be mapped with uncacheable >>> attributes (or WC for VGA)? If it's done later, it can be done later >>> for both. >>> >> arch/x86/mm/init.c >> >> unsigned long __init_refok init_memory_mapping(... >> ... >> ifdef CONFIG_X86_32 >> /* >> * Don't use a large page for the first 2/4MB of memory >> * because there are often fixed size MTRRs in there >> * and overlapping MTRRs into large pages can cause >> * slowdowns. >> */ >> > > That's equally true for X86_64. > > Best would be to merge the MTRRs into PAT, but that might not work for SMM. > > Ok, true. Not sure why this was restricted to 32bit when reconsidering. Except if in 64bit it was assumed (or asserted) that the regions are aligned to 2M... But maybe this can be answered by someone knowing the details. I would not mind either way (have the first range with 4K pages in all cases or fixing the additional PTE allocation). Just as it is now it is inconsistent. signature.asc Description: OpenPGP digital signature
Re: [PATCH] xc5000: Add MODULE_FIRMWARE statements
On Wed, Jul 25, 2012 at 9:15 AM, Tim Gardner wrote:
> This will make modinfo more useful with regard
> to discovering necessary firmware files.
>
> Cc: Mauro Carvalho Chehab
> Cc: Michael Krufky
> Cc: Eddi De Pieri
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Tim Gardner
> ---
> drivers/media/common/tuners/xc5000.c |8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/common/tuners/xc5000.c
> b/drivers/media/common/tuners/xc5000.c
> index dcca42c..4d33f86 100644
> --- a/drivers/media/common/tuners/xc5000.c
> +++ b/drivers/media/common/tuners/xc5000.c
> @@ -210,13 +210,15 @@ struct xc5000_fw_cfg {
> u16 size;
> };
>
> +#define XC5000A_FIRMWARE "dvb-fe-xc5000-1.6.114.fw"
> static const struct xc5000_fw_cfg xc5000a_1_6_114 = {
> - .name = "dvb-fe-xc5000-1.6.114.fw",
> + .name = XC5000A_FIRMWARE,
> .size = 12401,
> };
>
> +#define XC5000C_FIRMWARE "dvb-fe-xc5000c-41.024.5.fw"
> static const struct xc5000_fw_cfg xc5000c_41_024_5 = {
> - .name = "dvb-fe-xc5000c-41.024.5.fw",
> + .name = XC5000C_FIRMWARE,
> .size = 16497,
> };
>
> @@ -1253,3 +1255,5 @@ EXPORT_SYMBOL(xc5000_attach);
> MODULE_AUTHOR("Steven Toth");
> MODULE_DESCRIPTION("Xceive xc5000 silicon tuner driver");
> MODULE_LICENSE("GPL");
> +MODULE_FIRMWARE(XC5000A_FIRMWARE);
> +MODULE_FIRMWARE(XC5000C_FIRMWARE);
> --
Hi Tim,
I'm just eyeballing the patch and I'm not familiar with this new
functionality, but where are the new macros you're specifying actually
defined? You're swapping out the filename for XC5000A_FIRMWARE, but
where is the actual reference to "dvb-fe-xc5000-1.6.114.fw"?
Also, Mauro, can I merge this into my tree first rather than you
pulling it direct? I've got a whole patch series for xc5000 that I'm
slated to issue a PULL for this weekend, and I *really* don't want to
rebase the series for a four line change (which will definitely cause
a conflict).
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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] xc5000: Add MODULE_FIRMWARE statements
This will make modinfo more useful with regard
to discovering necessary firmware files.
Cc: Mauro Carvalho Chehab
Cc: Michael Krufky
Cc: Eddi De Pieri
Cc: linux-me...@vger.kernel.org
Signed-off-by: Tim Gardner
---
drivers/media/common/tuners/xc5000.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/media/common/tuners/xc5000.c
b/drivers/media/common/tuners/xc5000.c
index dcca42c..4d33f86 100644
--- a/drivers/media/common/tuners/xc5000.c
+++ b/drivers/media/common/tuners/xc5000.c
@@ -210,13 +210,15 @@ struct xc5000_fw_cfg {
u16 size;
};
+#define XC5000A_FIRMWARE "dvb-fe-xc5000-1.6.114.fw"
static const struct xc5000_fw_cfg xc5000a_1_6_114 = {
- .name = "dvb-fe-xc5000-1.6.114.fw",
+ .name = XC5000A_FIRMWARE,
.size = 12401,
};
+#define XC5000C_FIRMWARE "dvb-fe-xc5000c-41.024.5.fw"
static const struct xc5000_fw_cfg xc5000c_41_024_5 = {
- .name = "dvb-fe-xc5000c-41.024.5.fw",
+ .name = XC5000C_FIRMWARE,
.size = 16497,
};
@@ -1253,3 +1255,5 @@ EXPORT_SYMBOL(xc5000_attach);
MODULE_AUTHOR("Steven Toth");
MODULE_DESCRIPTION("Xceive xc5000 silicon tuner driver");
MODULE_LICENSE("GPL");
+MODULE_FIRMWARE(XC5000A_FIRMWARE);
+MODULE_FIRMWARE(XC5000C_FIRMWARE);
--
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: [PATCH 1/1] Drivers: hv: Cleanup the guest ID computation
> -Original Message- > From: Olaf Hering [mailto:o...@aepfle.de] > Sent: Wednesday, July 25, 2012 4:17 AM > To: KY Srinivasan > Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org; a...@canonical.com > Subject: Re: [PATCH 1/1] Drivers: hv: Cleanup the guest ID computation > > On Tue, Jul 24, K. Y. Srinivasan wrote: > > > > +/* > > + * The guest OS needs to register the guest ID with the hypervisor. > > + * The guest ID is a 64 bit entity and the structure of this ID is > > + * specified in the Hyper-V specification: > > + * > > + * http://msdn.microsoft.com/en-us/library/windows/ > > + * hardware/ff542653%28v=vs.85%29.aspx > > + * > > + * While the current guideline does not specify how Linux guest ID(s) > > + * need to be generated, our plan is to publish the guidelines for > > + * Linux and other guest operating systems that currently are hosted > > + * on Hyper-V. The implementation here conforms to this yet > > + * unpublished guidelines. > > + * > > + * > > + * Bit(s) > > + * 63 - Indicates if the OS is Open Source or not; 1 is Open Source > > + * 62:56 - Os Type; Linux is 0x100 > > + * 55:48 - Distro specific identification > > + * 47:16 - Linux kernel version number > > + * 15:0 - Distro specific identification > > + * > > + * > > + */ > > + > > +#define HV_LINUX_VENDOR_ID 0x8100 > > I suggest to drop bit 63, why would the hypervisor care about that > weird detail? Hypervisor does not care, but on the host side we plan to use this to track the kind of guest operating systems currently hosted. Regards, K. Y
Re: [PATCH 48/52] tools/power: turbostat: fix large c1% issue
On Tue, Jul 24, 2012 at 11:41:44PM -0400, Len Brown wrote:
> From: Len Brown
>
> Under some conditions, c1% was displayed as very large number,
> much higher than 100%.
>
> c1% is not measured, it is derived as "that, which is left over"
> from other counters. However, the other counters are not collected
> atomically, and so it is possible for c1% to be calaculagted as
calculated.
> a small negative number -- displayed as very large positive.
>
> There was a check for mperf vs tsc for this already,
> but it needed to also include the other counters
> that are used to calculate c1.
>
> Signed-off-by: Len Brown
> ---
> tools/power/x86/turbostat/turbostat.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/tools/power/x86/turbostat/turbostat.c
> b/tools/power/x86/turbostat/turbostat.c
> index b815a12..861d771 100644
> --- a/tools/power/x86/turbostat/turbostat.c
> +++ b/tools/power/x86/turbostat/turbostat.c
> @@ -444,6 +444,9 @@ delta_core(struct core_data *new, struct core_data *old)
> old->c7 = new->c7 - old->c7;
> }
>
> +/*
> + * old = new - old
> + */
> void
> delta_thread(struct thread_data *new, struct thread_data *old,
> struct core_data *core_delta)
> @@ -482,19 +485,20 @@ delta_thread(struct thread_data *new, struct
> thread_data *old,
>
>
> /*
> - * As mperf and tsc collection are not atomic,
> - * it is possible for mperf's non-halted cycles
> + * As counter collection is not atomic,
> + * it is possible for mperf's non-halted cycles + idle states
>* to exceed TSC's all cycles: show c1 = 0% in that case.
>*/
> - if (old->mperf > old->tsc)
> + if ((old->mperf + core_delta->c3 + core_delta->c6 + core_delta->c7) >
> old->tsc)
> old->c1 = 0;
> else {
> /* normal case, derive c1 */
> old->c1 = old->tsc - old->mperf - core_delta->c3
> - core_delta->c6 - core_delta->c7;
> }
> +
> if (old->mperf == 0) {
> - if (verbose) fprintf(stderr, "cpu%d MPERF 0!\n", old->cpu_id);
> + if (verbose > 1) fprintf(stderr, "cpu%d MPERF 0!\n",
> old->cpu_id);
> old->mperf = 1; /* divide by 0 protection */
> }
>
> --
> 1.7.12.rc0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v8 2/2] mmc: card: Adding support for sanitize in eMMC 4.5
Looks good to me.
Reviewed-by: Maya Erez
On Wed, July 25, 2012 4:31 am, Yaniv Gardi wrote:
> This feature delete the unmap memory region of the eMMC card,
> by writing to a specific register in the EXT_CSD
> unmap region is the memory region that were previously deleted
> (by erase, trim or discard operation)
>
> Signed-off-by: Yaniv Gardi
>
> ---
> drivers/mmc/card/block.c | 72
> +-
> drivers/mmc/card/queue.c | 10 ++-
> include/linux/mmc/host.h |1 +
> 3 files changed, 62 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index f1c84de..c45ec9f 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -860,10 +860,10 @@ static int mmc_blk_issue_secdiscard_rq(struct
> mmc_queue *mq,
> {
> struct mmc_blk_data *md = mq->data;
> struct mmc_card *card = md->queue.card;
> - unsigned int from, nr, arg, trim_arg, erase_arg;
> + unsigned int from, nr, arg;
> int err = 0, type = MMC_BLK_SECDISCARD;
>
> - if (!(mmc_can_secure_erase_trim(card) || mmc_can_sanitize(card))) {
> + if (!(mmc_can_secure_erase_trim(card))) {
> err = -EOPNOTSUPP;
> goto out;
> }
> @@ -871,23 +871,10 @@ static int mmc_blk_issue_secdiscard_rq(struct
> mmc_queue *mq,
> from = blk_rq_pos(req);
> nr = blk_rq_sectors(req);
>
> - /* The sanitize operation is supported at v4.5 only */
> - if (mmc_can_sanitize(card)) {
> - erase_arg = MMC_ERASE_ARG;
> - trim_arg = MMC_TRIM_ARG;
> - } else {
> - erase_arg = MMC_SECURE_ERASE_ARG;
> - trim_arg = MMC_SECURE_TRIM1_ARG;
> - }
> -
> - if (mmc_erase_group_aligned(card, from, nr))
> - arg = erase_arg;
> - else if (mmc_can_trim(card))
> - arg = trim_arg;
> - else {
> - err = -EINVAL;
> - goto out;
> - }
> + if (mmc_can_trim(card) && !mmc_erase_group_aligned(card, from, nr))
> + arg = MMC_SECURE_TRIM1_ARG;
> + else
> + arg = MMC_SECURE_ERASE_ARG;
> retry:
> if (card->quirks & MMC_QUIRK_INAND_CMD38) {
> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> @@ -937,6 +924,46 @@ out:
> return err ? 0 : 1;
> }
>
> +static int mmc_blk_issue_sanitize_rq(struct mmc_queue *mq,
> + struct request *req)
> +{
> + struct mmc_blk_data *md = mq->data;
> + struct mmc_card *card = md->queue.card;
> + int err = 0;
> +
> + BUG_ON(!card);
> + BUG_ON(!card->host);
> +
> + if (!(mmc_can_sanitize(card) &&
> + (card->host->caps2 & MMC_CAP2_SANITIZE))) {
> + pr_warning("%s: %s - SANITIZE is not supported\n",
> +mmc_hostname(card->host), __func__);
> + err = -EOPNOTSUPP;
> + goto out;
> + }
> +
> + pr_debug("%s: %s - SANITIZE IN PROGRESS...\n",
> + mmc_hostname(card->host), __func__);
> +
> + err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> + EXT_CSD_SANITIZE_START, 1, 0);
> +
> + if (err)
> + pr_err("%s: %s - mmc_switch() with "
> +"EXT_CSD_SANITIZE_START failed. err=%d\n",
> +mmc_hostname(card->host), __func__, err);
> +
> + pr_debug("%s: %s - SANITIZE COMPLETED\n", mmc_hostname(card->host),
> + __func__);
> +
> +out:
> + spin_lock_irq(>lock);
> + __blk_end_request(req, err, blk_rq_bytes(req));
> + spin_unlock_irq(>lock);
> +
> + return err ? 0 : 1;
> +}
> +
> static int mmc_blk_issue_flush(struct mmc_queue *mq, struct request *req)
> {
> struct mmc_blk_data *md = mq->data;
> @@ -1407,7 +1434,12 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq,
> struct request *req)
> goto out;
> }
>
> - if (req && req->cmd_flags & REQ_DISCARD) {
> + if (req && req->cmd_flags & REQ_SANITIZE) {
> + /* complete ongoing async transfer before issuing sanitize */
> + if (card->host && card->host->areq)
> + mmc_blk_issue_rw_rq(mq, NULL);
> + ret = mmc_blk_issue_sanitize_rq(mq, req);
> + } else if (req && req->cmd_flags & REQ_DISCARD) {
> /* complete ongoing async transfer before issuing discard */
> if (card->host->areq)
> mmc_blk_issue_rw_rq(mq, NULL);
> diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
> index e360a97..4f3250e 100644
> --- a/drivers/mmc/card/queue.c
> +++ b/drivers/mmc/card/queue.c
> @@ -145,10 +145,15 @@ static void mmc_queue_setup_discard(struct
> request_queue *q,
> /* granularity must not be greater than max. discard */
> if (card->pref_erase > max_discard)
> q->limits.discard_granularity = 0;
> - if
Re: [PATCH RESEND v8 1/2] block: ioctl support for sanitize in eMMC 4.5
Looks good to me.
Reviewed-by: Maya Erez
On Wed, July 25, 2012 4:31 am, Yaniv Gardi wrote:
> Adding a new ioctl to support sanitize operation in eMMC
> cards version 4.5.
> The sanitize ioctl support helps performing this operation
> via user application.
>
> Signed-off-by: Yaniv Gardi
>
> ---
> block/blk-core.c | 15 ++--
> block/blk-lib.c | 51
> +
> block/blk-merge.c |4 +++
> block/elevator.c |2 +-
> block/ioctl.c |9
> include/linux/blk_types.h |5 +++-
> include/linux/blkdev.h|3 ++
> include/linux/fs.h|1 +
> kernel/trace/blktrace.c |2 +
> 9 files changed, 87 insertions(+), 5 deletions(-)
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index c3b17c3..55cb0da 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -1654,7 +1654,7 @@ generic_make_request_checks(struct bio *bio)
> goto end_io;
> }
>
> - if (unlikely(!(bio->bi_rw & REQ_DISCARD) &&
> + if (unlikely(!(bio->bi_rw & (REQ_DISCARD | REQ_SANITIZE)) &&
>nr_sectors > queue_max_hw_sectors(q))) {
> printk(KERN_ERR "bio too big device %s (%u > %u)\n",
> bdevname(bio->bi_bdev, b),
> @@ -1702,6 +1702,14 @@ generic_make_request_checks(struct bio *bio)
> goto end_io;
> }
>
> + if ((bio->bi_rw & REQ_SANITIZE) &&
> + (!blk_queue_sanitize(q))) {
> + pr_info("%s - got a SANITIZE request but the queue "
> +"doesn't support sanitize requests", __func__);
> + err = -EOPNOTSUPP;
> + goto end_io;
> + }
> +
> if (blk_throtl_bio(q, bio))
> return false; /* throttled, will be resubmitted later */
>
> @@ -1807,7 +1815,8 @@ void submit_bio(int rw, struct bio *bio)
>* If it's a regular read/write or a barrier with data attached,
>* go through the normal accounting stuff before submission.
>*/
> - if (bio_has_data(bio) && !(rw & REQ_DISCARD)) {
> + if (bio_has_data(bio) &&
> + (!(rw & (REQ_DISCARD | REQ_SANITIZE {
> if (rw & WRITE) {
> count_vm_events(PGPGOUT, count);
> } else {
> @@ -1853,7 +1862,7 @@ EXPORT_SYMBOL(submit_bio);
> */
> int blk_rq_check_limits(struct request_queue *q, struct request *rq)
> {
> - if (rq->cmd_flags & REQ_DISCARD)
> + if (rq->cmd_flags & (REQ_DISCARD | REQ_SANITIZE))
> return 0;
>
> if (blk_rq_sectors(rq) > queue_max_sectors(q) ||
> diff --git a/block/blk-lib.c b/block/blk-lib.c
> index 2b461b4..280d63e 100644
> --- a/block/blk-lib.c
> +++ b/block/blk-lib.c
> @@ -115,6 +115,57 @@ int blkdev_issue_discard(struct block_device *bdev,
> sector_t sector,
> EXPORT_SYMBOL(blkdev_issue_discard);
>
> /**
> + * blkdev_issue_sanitize - queue a sanitize request
> + * @bdev:blockdev to issue sanitize for
> + * @gfp_mask:memory allocation flags (for bio_alloc)
> + *
> + * Description:
> + *Issue a sanitize request for the specified block device
> + */
> +int blkdev_issue_sanitize(struct block_device *bdev, gfp_t gfp_mask)
> +{
> + DECLARE_COMPLETION_ONSTACK(wait);
> + struct request_queue *q = bdev_get_queue(bdev);
> + int type = REQ_WRITE | REQ_SANITIZE;
> + struct bio_batch bb;
> + struct bio *bio;
> + int ret = 0;
> +
> + if (!q)
> + return -ENXIO;
> +
> + if (!blk_queue_sanitize(q)) {
> + pr_err("%s - card doesn't support sanitize", __func__);
> + return -EOPNOTSUPP;
> + }
> +
> + bio = bio_alloc(gfp_mask, 1);
> + if (!bio)
> + return -ENOMEM;
> +
> + atomic_set(, 1);
> + bb.flags = 1 << BIO_UPTODATE;
> + bb.wait =
> +
> + bio->bi_end_io = bio_batch_end_io;
> + bio->bi_bdev = bdev;
> + bio->bi_private =
> +
> + atomic_inc();
> + submit_bio(type, bio);
> +
> + /* Wait for bios in-flight */
> + if (!atomic_dec_and_test())
> + wait_for_completion();
> +
> + if (!test_bit(BIO_UPTODATE, ))
> + ret = -EIO;
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(blkdev_issue_sanitize);
> +
> +/**
> * blkdev_issue_zeroout - generate number of zero filed write bios
> * @bdev:blockdev to issue
> * @sector: start sector
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index 160035f..ef93b23 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -477,6 +477,10 @@ bool blk_rq_merge_ok(struct request *rq, struct bio
> *bio)
> if (!rq_mergeable(rq))
> return false;
>
> + /* don't merge file system requests and sanitize requests */
> + if ((bio->bi_rw & REQ_SANITIZE) != (rq->bio->bi_rw & REQ_SANITIZE))
> + return false;
> +
> /* don't merge file system requests and discard requests */
> if ((bio->bi_rw & REQ_DISCARD) !=
Re: [GIT PULL v2] Blackfin changes for 3.6-rc1
On Wed, Jul 25, 2012 at 3:21 AM, Theodore Ts'o wrote: > On Tue, Jul 24, 2012 at 01:54:40PM +0800, Bob Liu wrote: >> >> This is the new pull request about blackfin changes for 3.6-rc1. >> I've rebased my tree to 3.5. > > To save Linus having to send you a chastising e-mail (and because I'll > probably be more gentle about it than he would be :-), in general it's > good not to rebase your the tree before submitting to Linus. If you > tested with your set of commits pon top of 3.5-rc3, then submit those > patches that way. Rebasing at least partially invalidates your > testing, and causes other problems if someone else has based their > tree off of yours. > > If the goal is to avoid merge conflicts, it's better to just resolve > the conflict, and push the proposed merge resolution, and send Linus > both the commit pre-merge, and post-merge, and let him decide if wants > to use your merge resolution, or to fix things up in a slightly > different way. > Got it, thanks a lot for your kindly explanation. -- Regards, --Bob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains)
On Tuesday 24 July 2012, Rafael J. Wysocki wrote: > On Tuesday, July 24, 2012, Arnd Bergmann wrote: > > On Tuesday 24 July 2012, Rafael J. Wysocki wrote: > > > On Tuesday, July 24, 2012, Arnd Bergmann wrote: > > > > On Saturday 21 July 2012, Rafael J. Wysocki wrote: > > > > > > > > > > Sorry for taking so long to reply. I am really not that familiar with > > > > the > > > > power domain requirements, but I do have two comments on your approach: > > > > > > > > * I think when we want to add a generic concept to the device tree such > > > > as power domains, we should always make it specified in a generic way. > > > > > > Do we really want that? I'm a bit skeptical, because apparently nobody > > > cares, as the (zero) response to this patchset evidently indicates and > > > since nobody cares, it's probably better not to add such "generic" things > > > just yet. > > > > Well, the trouble with bindings is that they are much harder to change > > later, at least in incompatible ways. > > Hmm, so I think you wanted to say that it might be burdensome to retain the > code handling the old binding once we had started to use a new generic one. > > I can agree with that, but that's quite similar to user space interfaces. > Once we've exposed a user space interface of some kind and someone starts > to use it, we'll have to maintain it going forward for the user in question. > However, there is a way to deprecate old user space interfaces and it has > happened. > > In this particular case the burden would be on Renesas, but I don't think it > would affect anybody else. [adding devicetree-disc...@lists.ozlabs.org] In case of user space interfaces, we also try very hard to avoid cases where we know that we will have to change things later. I don't think it's that hard to define a generic binding here, we just need to make sure it's extensible. One thing I would like to avoid is having to add to every single device binding two separate optional properties defined like diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt index 2b584ca..353152e 100644 --- a/Documentation/devicetree/bindings/mmc/mmci.txt +++ b/Documentation/devicetree/bindings/mmc/mmci.txt @@ -13,3 +13,9 @@ Required properties: Optional properties: - mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable - mmc-cap-sd-highspeed : indicates whether SD is high speed capable +- pm-domain : a phandle pointing to the power domain + controlling this device + See ../pm-domain/generic.txt +- renesas,pm-domain : a string with the name of the power domain + controlling this device. + See ../pm-domain/renesas.txt Even if you say that the burden is only on Renesas to maintain all those changes to every binding they use, there is also a burden on people trying to understand the binding and deciding which one to use. > > > > You have used the "renesas,pmdomain" attribute, which is specific to > > > > one vendor and requires platform specific code to read it. > > > > Is there any reason not to put the code into the generic > > > > drivers/base/power/domain.c file (or near it) and make a binding that > > > > works for everyone? > > > > > > Yes, there is. A couple of them in fact. > > > > > > First off, power domains will always need platform-specific code to > > > support > > > them, no matter what. The problem is that they tend to require special > > > handling, even within the same SoC, let alone different SoCs, and that > > > handling > > > has to be implemented in an SoC-specific way, because it has to know > > > various > > > things about the platform (like what to write to what register(s) at what > > > time > > > and so on). Of course, that platform-specific code needs to know which > > > domain the given description corresponds to and there doesn't seem to be > > > any > > > useful way to specify that through DTs. > > > > We have the same problem for a lot of other subsystems: clock, regulator, > > irq, gpio, pinctrl, dma, ... > > > > In each of these cases, we want a driver to be able to associate some > > property with a driver (or platform code) from another subsystem. > > We try to handle those using generic subsystem code that interprets > > regular property names. > > For power domains those properties would be SoC-specific. That is, there may > be a different set of properties for each SoC in principle and it's going to > get quite messy relatively quickly. I don't see how power domains are any different from the other cases I listed. The differences should be contained in whatever provides the domains. For a device that is part of a power domain, you only need to know how to find that domain, not what that information means. > > > Second, the generic code needed to support such a binding would have to be > > > quite complex
[PATCH v2 09/15] NFSd: make nfsd4_manager allocated per network namespace context.
Signed-off-by: Stanislav Kinsbursky
---
fs/nfsd/netns.h |2 ++
fs/nfsd/nfs4state.c | 32 +++-
2 files changed, 21 insertions(+), 13 deletions(-)
diff --git a/fs/nfsd/netns.h b/fs/nfsd/netns.h
index 3936563..e99767d 100644
--- a/fs/nfsd/netns.h
+++ b/fs/nfsd/netns.h
@@ -34,6 +34,8 @@ struct nfsd_net {
struct cache_detail *idtoname_cache;
struct cache_detail *nametoid_cache;
+
+ struct lock_manager nfsd4_manager;
};
extern int nfsd_net_id;
diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index ab0a02a..fad2408 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -45,6 +45,8 @@
#include "vfs.h"
#include "current_stateid.h"
+#include "netns.h"
+
#define NFSDDBG_FACILITYNFSDDBG_PROC
/* Globals */
@@ -3115,22 +3117,21 @@ out:
return status;
}
-static struct lock_manager nfsd4_manager = {
-};
-
static bool grace_ended;
static void
-nfsd4_end_grace(void)
+nfsd4_end_grace(struct net *net)
{
+ struct nfsd_net *nn = net_generic(net, nfsd_net_id);
+
/* do nothing if grace period already ended */
if (grace_ended)
return;
dprintk("NFSD: end of grace period\n");
grace_ended = true;
- nfsd4_record_grace_done(_net, boot_time);
- locks_end_grace(_manager);
+ nfsd4_record_grace_done(net, boot_time);
+ locks_end_grace(>nfsd4_manager);
/*
* Now that every NFSv4 client has had the chance to recover and
* to see the (possibly new, possibly shorter) lease time, we
@@ -3153,7 +3154,7 @@ nfs4_laundromat(void)
nfs4_lock_state();
dprintk("NFSD: laundromat service - starting\n");
- nfsd4_end_grace();
+ nfsd4_end_grace(_net);
INIT_LIST_HEAD();
spin_lock(_lock);
list_for_each_safe(pos, next, _lru) {
@@ -4687,6 +4688,8 @@ set_max_delegations(void)
int
nfs4_state_start(void)
{
+ struct net *net = _net;
+ struct nfsd_net *nn = net_generic(net, nfsd_net_id);
int ret;
/*
@@ -4696,10 +4699,10 @@ nfs4_state_start(void)
* to that instead and then do most of the rest of this on a per-net
* basis.
*/
- get_net(_net);
- nfsd4_client_tracking_init(_net);
+ get_net(net);
+ nfsd4_client_tracking_init(net);
boot_time = get_seconds();
- locks_start_grace(_manager);
+ locks_start_grace(>nfsd4_manager);
grace_ended = false;
printk(KERN_INFO "NFSD: starting %ld-second grace period\n",
nfsd4_grace);
@@ -4722,8 +4725,8 @@ nfs4_state_start(void)
out_free_laundry:
destroy_workqueue(laundry_wq);
out_recovery:
- nfsd4_client_tracking_exit(_net);
- put_net(_net);
+ nfsd4_client_tracking_exit(net);
+ put_net(net);
return ret;
}
@@ -4764,9 +4767,12 @@ __nfs4_state_shutdown(void)
void
nfs4_state_shutdown(void)
{
+ struct net *net = _net;
+ struct nfsd_net *nn = net_generic(net, nfsd_net_id);
+
cancel_delayed_work_sync(_work);
destroy_workqueue(laundry_wq);
- locks_end_grace(_manager);
+ locks_end_grace(>nfsd4_manager);
nfs4_lock_state();
__nfs4_state_shutdown();
nfs4_unlock_state();
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 00/13] firmware loader: introduce cache/uncache firmware
On Wed, Jul 25, 2012 at 8:50 PM, Ming Lei wrote: > - no harm to thaw all user space tasks before thawing all kernel threads > (there isn't any dependency about the thawing order) Sorry, I mean there isn't any constraint about the order, but the 'dependency' may be just what the patch is introducing. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 15/15] NFSd: make boot_time variable per network namespace
NFSd's boot_time represents grace period start point in time.
Signed-off-by: Stanislav Kinsbursky
---
fs/nfsd/netns.h |1 +
fs/nfsd/nfs4state.c | 39 +++
fs/nfsd/state.h |1 +
3 files changed, 25 insertions(+), 16 deletions(-)
diff --git a/fs/nfsd/netns.h b/fs/nfsd/netns.h
index b6deebd..65c2431 100644
--- a/fs/nfsd/netns.h
+++ b/fs/nfsd/netns.h
@@ -37,6 +37,7 @@ struct nfsd_net {
struct lock_manager nfsd4_manager;
bool grace_ended;
+ time_t boot_time;
};
extern int nfsd_net_id;
diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 2c53447..d683f32 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -52,7 +52,6 @@
/* Globals */
time_t nfsd4_lease = 90; /* default lease time */
time_t nfsd4_grace = 90;
-static time_t boot_time;
#define all_ones {{~0,~0},~0}
static const stateid_t one_stateid = {
@@ -1055,12 +1054,12 @@ renew_client(struct nfs4_client *clp)
/* SETCLIENTID and SETCLIENTID_CONFIRM Helper functions */
static int
-STALE_CLIENTID(clientid_t *clid)
+STALE_CLIENTID(clientid_t *clid, struct nfsd_net *nn)
{
- if (clid->cl_boot == boot_time)
+ if (clid->cl_boot == nn->boot_time)
return 0;
dprintk("NFSD stale clientid (%08x/%08x) boot_time %08lx\n",
- clid->cl_boot, clid->cl_id, boot_time);
+ clid->cl_boot, clid->cl_id, nn->boot_time);
return 1;
}
@@ -1241,8 +1240,9 @@ same_creds(struct svc_cred *cr1, struct svc_cred *cr2)
static void gen_clid(struct nfs4_client *clp)
{
static u32 current_clientid = 1;
+ struct nfsd_net *nn = net_generic(_net, nfsd_net_id);
- clp->cl_clientid.cl_boot = boot_time;
+ clp->cl_clientid.cl_boot = nn->boot_time;
clp->cl_clientid.cl_id = current_clientid++;
}
@@ -2225,8 +2225,9 @@ nfsd4_setclientid_confirm(struct svc_rqst *rqstp,
nfs4_verifier confirm = setclientid_confirm->sc_confirm;
clientid_t * clid = _confirm->sc_clientid;
__be32 status;
+ struct nfsd_net *nn = net_generic(_net, nfsd_net_id);
- if (STALE_CLIENTID(clid))
+ if (STALE_CLIENTID(clid, nn))
return nfserr_stale_clientid;
nfs4_lock_state();
@@ -2585,8 +2586,9 @@ nfsd4_process_open1(struct nfsd4_compound_state *cstate,
unsigned int strhashval;
struct nfs4_openowner *oo = NULL;
__be32 status;
+ struct nfsd_net *nn = net_generic(_net, nfsd_net_id);
- if (STALE_CLIENTID(>op_clientid))
+ if (STALE_CLIENTID(>op_clientid, nn))
return nfserr_stale_clientid;
/*
* In case we need it later, after we've already created the
@@ -3094,12 +3096,13 @@ nfsd4_renew(struct svc_rqst *rqstp, struct
nfsd4_compound_state *cstate,
{
struct nfs4_client *clp;
__be32 status;
+ struct nfsd_net *nn = net_generic(_net, nfsd_net_id);
nfs4_lock_state();
dprintk("process_renew(%08x/%08x): starting\n",
clid->cl_boot, clid->cl_id);
status = nfserr_stale_clientid;
- if (STALE_CLIENTID(clid))
+ if (STALE_CLIENTID(clid, nn))
goto out;
clp = find_confirmed_client(clid);
status = nfserr_expired;
@@ -3129,7 +3132,7 @@ nfsd4_end_grace(struct net *net)
dprintk("NFSD: end of grace period\n");
nn->grace_ended = true;
- nfsd4_record_grace_done(net, boot_time);
+ nfsd4_record_grace_done(net, nn->boot_time);
locks_end_grace(>nfsd4_manager);
/*
* Now that every NFSv4 client has had the chance to recover and
@@ -3235,9 +3238,9 @@ static inline __be32 nfs4_check_fh(struct svc_fh *fhp,
struct nfs4_ol_stateid *s
}
static int
-STALE_STATEID(stateid_t *stateid)
+STALE_STATEID(stateid_t *stateid, struct nfsd_net *nn)
{
- if (stateid->si_opaque.so_clid.cl_boot == boot_time)
+ if (stateid->si_opaque.so_clid.cl_boot == nn->boot_time)
return 0;
dprintk("NFSD: stale stateid " STATEID_FMT "!\n",
STATEID_VAL(stateid));
@@ -3372,10 +3375,11 @@ static __be32 nfsd4_validate_stateid(struct nfs4_client
*cl, stateid_t *stateid)
static __be32 nfsd4_lookup_stateid(stateid_t *stateid, unsigned char typemask,
struct nfs4_stid **s)
{
struct nfs4_client *cl;
+ struct nfsd_net *nn = net_generic(_net, nfsd_net_id);
if (ZERO_STATEID(stateid) || ONE_STATEID(stateid))
return nfserr_bad_stateid;
- if (STALE_STATEID(stateid))
+ if (STALE_STATEID(stateid, nn))
return nfserr_stale_stateid;
cl = find_confirmed_client(>si_opaque.so_clid);
if (!cl)
@@ -4047,6 +4051,7 @@ nfsd4_lock(struct svc_rqst *rqstp, struct
nfsd4_compound_state *cstate,
bool new_state = false;
int lkflg;
int err;
+ struct nfsd_net *nn = net_generic(_net, nfsd_net_id);
dprintk("NFSD: nfsd4_lock:
[PATCH v2 14/15] NFSd: make grace end flag per network namespace
Signed-off-by: Stanislav Kinsbursky
---
fs/nfsd/netns.h |1 +
fs/nfsd/nfs4state.c |8 +++-
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/fs/nfsd/netns.h b/fs/nfsd/netns.h
index e99767d..b6deebd 100644
--- a/fs/nfsd/netns.h
+++ b/fs/nfsd/netns.h
@@ -36,6 +36,7 @@ struct nfsd_net {
struct cache_detail *nametoid_cache;
struct lock_manager nfsd4_manager;
+ bool grace_ended;
};
extern int nfsd_net_id;
diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index b926e00..2c53447 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -3118,19 +3118,17 @@ out:
return status;
}
-static bool grace_ended;
-
static void
nfsd4_end_grace(struct net *net)
{
struct nfsd_net *nn = net_generic(net, nfsd_net_id);
/* do nothing if grace period already ended */
- if (grace_ended)
+ if (nn->grace_ended)
return;
dprintk("NFSD: end of grace period\n");
- grace_ended = true;
+ nn->grace_ended = true;
nfsd4_record_grace_done(net, boot_time);
locks_end_grace(>nfsd4_manager);
/*
@@ -4704,7 +4702,7 @@ nfs4_state_start(void)
nfsd4_client_tracking_init(net);
boot_time = get_seconds();
locks_start_grace(net, >nfsd4_manager);
- grace_ended = false;
+ nn->grace_ended = false;
printk(KERN_INFO "NFSD: starting %ld-second grace period\n",
nfsd4_grace);
ret = set_callback_cred();
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 12/15] LockD: pass actual network namespace to grace period management functions
Passed network namespace replaced hard-coded init_net
Signed-off-by: Stanislav Kinsbursky
---
fs/lockd/grace.c|6 ++
fs/lockd/svc.c | 16 +---
fs/lockd/svc4proc.c | 13 +++--
fs/lockd/svclock.c | 16
fs/lockd/svcproc.c | 15 +--
fs/nfsd/nfs4proc.c | 18 ++
fs/nfsd/nfs4state.c | 29 +++--
fs/nfsd/state.h |3 ++-
include/linux/fs.h |5 +++--
include/linux/lockd/lockd.h |4 ++--
10 files changed, 67 insertions(+), 58 deletions(-)
diff --git a/fs/lockd/grace.c b/fs/lockd/grace.c
index 8dbaff7..6d1ee72 100644
--- a/fs/lockd/grace.c
+++ b/fs/lockd/grace.c
@@ -21,9 +21,8 @@ static DEFINE_SPINLOCK(grace_lock);
*
* This function is called to start a grace period.
*/
-void locks_start_grace(struct lock_manager *lm)
+void locks_start_grace(struct net *net, struct lock_manager *lm)
{
- struct net *net = _net;
struct lockd_net *ln = net_generic(net, lockd_net_id);
spin_lock(_lock);
@@ -57,9 +56,8 @@ EXPORT_SYMBOL_GPL(locks_end_grace);
* to answer ordinary lock requests, and when they should accept only
* lock reclaims.
*/
-int locks_in_grace(void)
+int locks_in_grace(struct net *net)
{
- struct net *net = _net;
struct lockd_net *ln = net_generic(net, lockd_net_id);
return !list_empty(>grace_list);
diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
index 834dfe2..68271c2 100644
--- a/fs/lockd/svc.c
+++ b/fs/lockd/svc.c
@@ -97,12 +97,12 @@ static void grace_ender(struct work_struct *grace)
locks_end_grace(>lockd_manager);
}
-static void set_grace_period(void)
+static void set_grace_period(struct net *net)
{
unsigned long grace_period = get_lockd_grace_period();
- struct lockd_net *ln = net_generic(_net, lockd_net_id);
+ struct lockd_net *ln = net_generic(net, lockd_net_id);
- locks_start_grace(>lockd_manager);
+ locks_start_grace(net, >lockd_manager);
cancel_delayed_work_sync(>grace_period_end);
schedule_delayed_work(>grace_period_end, grace_period);
}
@@ -110,12 +110,13 @@ static void set_grace_period(void)
static void restart_grace(void)
{
if (nlmsvc_ops) {
- struct lockd_net *ln = net_generic(_net, lockd_net_id);
+ struct net *net = _net;
+ struct lockd_net *ln = net_generic(net, lockd_net_id);
cancel_delayed_work_sync(>grace_period_end);
locks_end_grace(>lockd_manager);
nlmsvc_invalidate_all();
- set_grace_period();
+ set_grace_period(net);
}
}
@@ -127,7 +128,8 @@ lockd(void *vrqstp)
{
int err = 0, preverr = 0;
struct svc_rqst *rqstp = vrqstp;
- struct lockd_net *ln = net_generic(_net, lockd_net_id);
+ struct net *net = _net;
+ struct lockd_net *ln = net_generic(net, lockd_net_id);
/* try_to_freeze() is called from svc_recv() */
set_freezable();
@@ -141,7 +143,7 @@ lockd(void *vrqstp)
nlm_timeout = LOCKD_DFLT_TIMEO;
nlmsvc_timeout = nlm_timeout * HZ;
- set_grace_period();
+ set_grace_period(net);
/*
* The main request loop. We don't terminate until the last
diff --git a/fs/lockd/svc4proc.c b/fs/lockd/svc4proc.c
index 9a41fdc..4a43d25 100644
--- a/fs/lockd/svc4proc.c
+++ b/fs/lockd/svc4proc.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#define NLMDBG_FACILITYNLMDBG_CLIENT
@@ -151,7 +152,7 @@ nlm4svc_proc_cancel(struct svc_rqst *rqstp, struct nlm_args
*argp,
resp->cookie = argp->cookie;
/* Don't accept requests during grace period */
- if (locks_in_grace()) {
+ if (locks_in_grace(SVC_NET(rqstp))) {
resp->status = nlm_lck_denied_grace_period;
return rpc_success;
}
@@ -161,7 +162,7 @@ nlm4svc_proc_cancel(struct svc_rqst *rqstp, struct nlm_args
*argp,
return resp->status == nlm_drop_reply ? rpc_drop_reply
:rpc_success;
/* Try to cancel request. */
- resp->status = nlmsvc_cancel_blocked(file, >lock);
+ resp->status = nlmsvc_cancel_blocked(SVC_NET(rqstp), file, >lock);
dprintk("lockd: CANCELstatus %d\n", ntohl(resp->status));
nlmsvc_release_host(host);
@@ -184,7 +185,7 @@ nlm4svc_proc_unlock(struct svc_rqst *rqstp, struct nlm_args
*argp,
resp->cookie = argp->cookie;
/* Don't accept new lock requests during grace period */
- if (locks_in_grace()) {
+ if (locks_in_grace(SVC_NET(rqstp))) {
resp->status = nlm_lck_denied_grace_period;
return rpc_success;
}
@@ -194,7 +195,7 @@ nlm4svc_proc_unlock(struct svc_rqst *rqstp, struct nlm_args
*argp,
return resp->status == nlm_drop_reply ?
[PATCH v2 13/15] Lockd: move grace period management from lockd() to per-net functions
Signed-off-by: Stanislav Kinsbursky
---
fs/lockd/svc.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
index 68271c2..31a63f8 100644
--- a/fs/lockd/svc.c
+++ b/fs/lockd/svc.c
@@ -128,8 +128,6 @@ lockd(void *vrqstp)
{
int err = 0, preverr = 0;
struct svc_rqst *rqstp = vrqstp;
- struct net *net = _net;
- struct lockd_net *ln = net_generic(net, lockd_net_id);
/* try_to_freeze() is called from svc_recv() */
set_freezable();
@@ -143,8 +141,6 @@ lockd(void *vrqstp)
nlm_timeout = LOCKD_DFLT_TIMEO;
nlmsvc_timeout = nlm_timeout * HZ;
- set_grace_period(net);
-
/*
* The main request loop. We don't terminate until the last
* NFS mount or NFS daemon has gone away.
@@ -190,8 +186,6 @@ lockd(void *vrqstp)
svc_process(rqstp);
}
flush_signals(current);
- cancel_delayed_work_sync(>grace_period_end);
- locks_end_grace(>lockd_manager);
if (nlmsvc_ops)
nlmsvc_invalidate_all();
nlm_shutdown_hosts();
@@ -272,6 +266,7 @@ static int lockd_up_net(struct svc_serv *serv, struct net
*net)
error = make_socks(serv, net);
if (error < 0)
goto err_socks;
+ set_grace_period(net);
dprintk("lockd_up_net: per-net data created; net=%p\n", net);
return 0;
@@ -289,6 +284,8 @@ static void lockd_down_net(struct svc_serv *serv, struct
net *net)
if (ln->nlmsvc_users) {
if (--ln->nlmsvc_users == 0) {
nlm_shutdown_hosts_net(net);
+ cancel_delayed_work_sync(>grace_period_end);
+ locks_end_grace(>lockd_manager);
svc_shutdown_net(serv, net);
dprintk("lockd_down_net: per-net data destroyed;
net=%p\n", net);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 11/15] LockD: manage grace list per network namespace
Signed-off-by: Stanislav Kinsbursky
---
fs/lockd/grace.c | 14 +++---
fs/lockd/netns.h |1 +
fs/lockd/svc.c |1 +
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/fs/lockd/grace.c b/fs/lockd/grace.c
index 183cc1f..8dbaff7 100644
--- a/fs/lockd/grace.c
+++ b/fs/lockd/grace.c
@@ -4,8 +4,10 @@
#include
#include
+#include
+
+#include "netns.h"
-static LIST_HEAD(grace_list);
static DEFINE_SPINLOCK(grace_lock);
/**
@@ -21,8 +23,11 @@ static DEFINE_SPINLOCK(grace_lock);
*/
void locks_start_grace(struct lock_manager *lm)
{
+ struct net *net = _net;
+ struct lockd_net *ln = net_generic(net, lockd_net_id);
+
spin_lock(_lock);
- list_add(>list, _list);
+ list_add(>list, >grace_list);
spin_unlock(_lock);
}
EXPORT_SYMBOL_GPL(locks_start_grace);
@@ -54,6 +59,9 @@ EXPORT_SYMBOL_GPL(locks_end_grace);
*/
int locks_in_grace(void)
{
- return !list_empty(_list);
+ struct net *net = _net;
+ struct lockd_net *ln = net_generic(net, lockd_net_id);
+
+ return !list_empty(>grace_list);
}
EXPORT_SYMBOL_GPL(locks_in_grace);
diff --git a/fs/lockd/netns.h b/fs/lockd/netns.h
index e78650c..4eee248 100644
--- a/fs/lockd/netns.h
+++ b/fs/lockd/netns.h
@@ -11,6 +11,7 @@ struct lockd_net {
struct delayed_work grace_period_end;
struct lock_manager lockd_manager;
+ struct list_head grace_list;
};
extern int lockd_net_id;
diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
index a9c436b..834dfe2 100644
--- a/fs/lockd/svc.c
+++ b/fs/lockd/svc.c
@@ -596,6 +596,7 @@ static int lockd_init_net(struct net *net)
struct lockd_net *ln = net_generic(net, lockd_net_id);
INIT_DELAYED_WORK(>grace_period_end, grace_ender);
+ INIT_LIST_HEAD(>grace_list);
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 10/15] SUNRPC: service request network namespace helper introduced
This is a cleanup patch - makes code looks simplier.
It replaces widely used rqstp->rq_xprt->xpt_net by introduced SVC_NET(rqstp).
Signed-off-by: Stanislav Kinsbursky
---
fs/lockd/host.c|2 +-
fs/nfs/callback_xdr.c |4 ++--
fs/nfsd/export.c |4 ++--
fs/nfsd/nfs4idmap.c|4 ++--
include/linux/sunrpc/svc.h |2 ++
5 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/fs/lockd/host.c b/fs/lockd/host.c
index 0084ab8..f9b22e5 100644
--- a/fs/lockd/host.c
+++ b/fs/lockd/host.c
@@ -331,7 +331,7 @@ struct nlm_host *nlmsvc_lookup_host(const struct svc_rqst
*rqstp,
struct nsm_handle *nsm = NULL;
struct sockaddr *src_sap = svc_daddr(rqstp);
size_t src_len = rqstp->rq_daddrlen;
- struct net *net = rqstp->rq_xprt->xpt_net;
+ struct net *net = SVC_NET(rqstp);
struct nlm_lookup_host_info ni = {
.server = 1,
.sap= svc_addr(rqstp),
diff --git a/fs/nfs/callback_xdr.c b/fs/nfs/callback_xdr.c
index e64b01d..742ff4f 100644
--- a/fs/nfs/callback_xdr.c
+++ b/fs/nfs/callback_xdr.c
@@ -863,7 +863,7 @@ static __be32 nfs4_callback_compound(struct svc_rqst
*rqstp, void *argp, void *r
.drc_status = 0,
.clp = NULL,
.slotid = NFS4_NO_SLOT,
- .net = rqstp->rq_xprt->xpt_net,
+ .net = SVC_NET(rqstp),
};
unsigned int nops = 0;
@@ -879,7 +879,7 @@ static __be32 nfs4_callback_compound(struct svc_rqst
*rqstp, void *argp, void *r
return rpc_garbage_args;
if (hdr_arg.minorversion == 0) {
- cps.clp = nfs4_find_client_ident(rqstp->rq_xprt->xpt_net,
hdr_arg.cb_ident);
+ cps.clp = nfs4_find_client_ident(SVC_NET(rqstp),
hdr_arg.cb_ident);
if (!cps.clp || !check_gss_callback_principal(cps.clp, rqstp))
return rpc_drop_reply;
}
diff --git a/fs/nfsd/export.c b/fs/nfsd/export.c
index ba23349..d77acd0 100644
--- a/fs/nfsd/export.c
+++ b/fs/nfsd/export.c
@@ -929,7 +929,7 @@ struct svc_export *
rqst_exp_get_by_name(struct svc_rqst *rqstp, struct path *path)
{
struct svc_export *gssexp, *exp = ERR_PTR(-ENOENT);
- struct nfsd_net *nn = net_generic(rqstp->rq_xprt->xpt_net, nfsd_net_id);
+ struct nfsd_net *nn = net_generic(SVC_NET(rqstp), nfsd_net_id);
struct cache_detail *cd = nn->svc_export_cache;
if (rqstp->rq_client == NULL)
@@ -960,7 +960,7 @@ struct svc_export *
rqst_exp_find(struct svc_rqst *rqstp, int fsid_type, u32 *fsidv)
{
struct svc_export *gssexp, *exp = ERR_PTR(-ENOENT);
- struct nfsd_net *nn = net_generic(rqstp->rq_xprt->xpt_net, nfsd_net_id);
+ struct nfsd_net *nn = net_generic(SVC_NET(rqstp), nfsd_net_id);
struct cache_detail *cd = nn->svc_export_cache;
if (rqstp->rq_client == NULL)
diff --git a/fs/nfsd/nfs4idmap.c b/fs/nfsd/nfs4idmap.c
index dae36f1..fdc91a6 100644
--- a/fs/nfsd/nfs4idmap.c
+++ b/fs/nfsd/nfs4idmap.c
@@ -546,7 +546,7 @@ idmap_name_to_id(struct svc_rqst *rqstp, int type, const
char *name, u32 namelen
.type = type,
};
int ret;
- struct nfsd_net *nn = net_generic(rqstp->rq_xprt->xpt_net, nfsd_net_id);
+ struct nfsd_net *nn = net_generic(SVC_NET(rqstp), nfsd_net_id);
if (namelen + 1 > sizeof(key.name))
return nfserr_badowner;
@@ -571,7 +571,7 @@ idmap_id_to_name(struct svc_rqst *rqstp, int type, uid_t
id, char *name)
.type = type,
};
int ret;
- struct nfsd_net *nn = net_generic(rqstp->rq_xprt->xpt_net, nfsd_net_id);
+ struct nfsd_net *nn = net_generic(SVC_NET(rqstp), nfsd_net_id);
strlcpy(key.authname, rqst_authname(rqstp), sizeof(key.authname));
ret = idmap_lookup(rqstp, idtoname_lookup, , nn->idtoname_cache,
);
diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc/svc.h
index 40e0a27..d83db80 100644
--- a/include/linux/sunrpc/svc.h
+++ b/include/linux/sunrpc/svc.h
@@ -278,6 +278,8 @@ struct svc_rqst {
struct task_struct *rq_task; /* service thread */
};
+#define SVC_NET(svc_rqst) (svc_rqst->rq_xprt->xpt_net)
+
/*
* Rigorous type checking on sockaddr type conversions
*/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 08/15] LockD: make lockd manager allocated per network namespace
Signed-off-by: Stanislav Kinsbursky
---
fs/lockd/netns.h |2 ++
fs/lockd/svc.c | 18 ++
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/fs/lockd/netns.h b/fs/lockd/netns.h
index 94653ae..e78650c 100644
--- a/fs/lockd/netns.h
+++ b/fs/lockd/netns.h
@@ -1,6 +1,7 @@
#ifndef __LOCKD_NETNS_H__
#define __LOCKD_NETNS_H__
+#include
#include
struct lockd_net {
@@ -9,6 +10,7 @@ struct lockd_net {
unsigned long nrhosts;
struct delayed_work grace_period_end;
+ struct lock_manager lockd_manager;
};
extern int lockd_net_id;
diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
index 70c4177..a9c436b 100644
--- a/fs/lockd/svc.c
+++ b/fs/lockd/svc.c
@@ -87,12 +87,14 @@ static unsigned long get_lockd_grace_period(void)
return nlm_timeout * 5 * HZ;
}
-static struct lock_manager lockd_manager = {
-};
-
-static void grace_ender(struct work_struct *not_used)
+static void grace_ender(struct work_struct *grace)
{
- locks_end_grace(_manager);
+ struct delayed_work *dwork = container_of(grace, struct delayed_work,
+ work);
+ struct lockd_net *ln = container_of(dwork, struct lockd_net,
+ grace_period_end);
+
+ locks_end_grace(>lockd_manager);
}
static void set_grace_period(void)
@@ -100,7 +102,7 @@ static void set_grace_period(void)
unsigned long grace_period = get_lockd_grace_period();
struct lockd_net *ln = net_generic(_net, lockd_net_id);
- locks_start_grace(_manager);
+ locks_start_grace(>lockd_manager);
cancel_delayed_work_sync(>grace_period_end);
schedule_delayed_work(>grace_period_end, grace_period);
}
@@ -111,7 +113,7 @@ static void restart_grace(void)
struct lockd_net *ln = net_generic(_net, lockd_net_id);
cancel_delayed_work_sync(>grace_period_end);
- locks_end_grace(_manager);
+ locks_end_grace(>lockd_manager);
nlmsvc_invalidate_all();
set_grace_period();
}
@@ -187,7 +189,7 @@ lockd(void *vrqstp)
}
flush_signals(current);
cancel_delayed_work_sync(>grace_period_end);
- locks_end_grace(_manager);
+ locks_end_grace(>lockd_manager);
if (nlmsvc_ops)
nlmsvc_invalidate_all();
nlm_shutdown_hosts();
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/15] LockD: manage grace period per network namespace
Signed-off-by: Stanislav Kinsbursky
---
fs/lockd/netns.h |2 ++
fs/lockd/svc.c | 17 +++--
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/fs/lockd/netns.h b/fs/lockd/netns.h
index 44c8f0b..94653ae 100644
--- a/fs/lockd/netns.h
+++ b/fs/lockd/netns.h
@@ -7,6 +7,8 @@ struct lockd_net {
unsigned int nlmsvc_users;
unsigned long next_gc;
unsigned long nrhosts;
+
+ struct delayed_work grace_period_end;
};
extern int lockd_net_id;
diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
index 80938fd..70c4177 100644
--- a/fs/lockd/svc.c
+++ b/fs/lockd/svc.c
@@ -95,21 +95,22 @@ static void grace_ender(struct work_struct *not_used)
locks_end_grace(_manager);
}
-static DECLARE_DELAYED_WORK(grace_period_end, grace_ender);
-
static void set_grace_period(void)
{
unsigned long grace_period = get_lockd_grace_period();
+ struct lockd_net *ln = net_generic(_net, lockd_net_id);
locks_start_grace(_manager);
- cancel_delayed_work_sync(_period_end);
- schedule_delayed_work(_period_end, grace_period);
+ cancel_delayed_work_sync(>grace_period_end);
+ schedule_delayed_work(>grace_period_end, grace_period);
}
static void restart_grace(void)
{
if (nlmsvc_ops) {
- cancel_delayed_work_sync(_period_end);
+ struct lockd_net *ln = net_generic(_net, lockd_net_id);
+
+ cancel_delayed_work_sync(>grace_period_end);
locks_end_grace(_manager);
nlmsvc_invalidate_all();
set_grace_period();
@@ -124,6 +125,7 @@ lockd(void *vrqstp)
{
int err = 0, preverr = 0;
struct svc_rqst *rqstp = vrqstp;
+ struct lockd_net *ln = net_generic(_net, lockd_net_id);
/* try_to_freeze() is called from svc_recv() */
set_freezable();
@@ -184,7 +186,7 @@ lockd(void *vrqstp)
svc_process(rqstp);
}
flush_signals(current);
- cancel_delayed_work_sync(_period_end);
+ cancel_delayed_work_sync(>grace_period_end);
locks_end_grace(_manager);
if (nlmsvc_ops)
nlmsvc_invalidate_all();
@@ -589,6 +591,9 @@ module_param(nlm_max_connections, uint, 0644);
static int lockd_init_net(struct net *net)
{
+ struct lockd_net *ln = net_generic(net, lockd_net_id);
+
+ INIT_DELAYED_WORK(>grace_period_end, grace_ender);
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 06/15] Lockd: add more debug to host shutdown functions
Signed-off-by: Stanislav Kinsbursky
---
fs/lockd/host.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/lockd/host.c b/fs/lockd/host.c
index 8cbf53d..0084ab8 100644
--- a/fs/lockd/host.c
+++ b/fs/lockd/host.c
@@ -608,11 +608,10 @@ nlm_shutdown_hosts_net(struct net *net)
struct hlist_node *pos;
struct nlm_host *host;
- dprintk("lockd: shutting down host module\n");
mutex_lock(_host_mutex);
/* First, make all hosts eligible for gc */
- dprintk("lockd: nuking all hosts...\n");
+ dprintk("lockd: nuking all hosts in net %p...\n", net);
for_each_host(host, pos, chain, nlm_server_hosts) {
if (net && host->net != net)
continue;
@@ -637,6 +636,7 @@ nlm_shutdown_hosts_net(struct net *net)
void
nlm_shutdown_hosts(void)
{
+ dprintk("lockd: shutting down host module\n");
nlm_shutdown_hosts_net(NULL);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 05/15] Lockd: host complaining function introduced
Just a small cleanup.
Signed-off-by: Stanislav Kinsbursky
---
fs/lockd/host.c | 57 +--
1 files changed, 30 insertions(+), 27 deletions(-)
diff --git a/fs/lockd/host.c b/fs/lockd/host.c
index 6c56090..8cbf53d 100644
--- a/fs/lockd/host.c
+++ b/fs/lockd/host.c
@@ -572,6 +572,35 @@ void nlm_host_rebooted(const struct nlm_reboot *info)
nsm_release(nsm);
}
+static void nlm_complain_hosts(struct net *net)
+{
+ struct hlist_head *chain;
+ struct hlist_node *pos;
+ struct nlm_host *host;
+
+ if (net) {
+ struct lockd_net *ln = net_generic(net, lockd_net_id);
+
+ if (ln->nrhosts == 0)
+ return;
+ printk(KERN_WARNING "lockd: couldn't shutdown host module for
net %p!\n", net);
+ dprintk("lockd: %lu hosts left in net %p:\n", ln->nrhosts, net);
+ } else {
+ if (nrhosts == 0)
+ return;
+ printk(KERN_WARNING "lockd: couldn't shutdown host module!\n");
+ dprintk("lockd: %lu hosts left:\n", nrhosts);
+ }
+
+ for_each_host(host, pos, chain, nlm_server_hosts) {
+ if (net && host->net != net)
+ continue;
+ dprintk(" %s (cnt %d use %d exp %ld net %p)\n",
+ host->h_name, atomic_read(>h_count),
+ host->h_inuse, host->h_expires, host->net);
+ }
+}
+
void
nlm_shutdown_hosts_net(struct net *net)
{
@@ -598,18 +627,7 @@ nlm_shutdown_hosts_net(struct net *net)
nlm_gc_hosts(net);
mutex_unlock(_host_mutex);
- /* complain if any hosts are left */
- if (net) {
- struct lockd_net *ln = net_generic(net, lockd_net_id);
-
- printk(KERN_WARNING "lockd: couldn't shutdown host module for
net %p!\n", net);
- dprintk("lockd: %lu hosts left in net %p:\n", ln->nrhosts, net);
- for_each_host(host, pos, chain, nlm_server_hosts) {
- dprintk(" %s (cnt %d use %d exp %ld net %p)\n",
- host->h_name, atomic_read(>h_count),
- host->h_inuse, host->h_expires, host->net);
- }
- }
+ nlm_complain_hosts(net);
}
/*
@@ -619,22 +637,7 @@ nlm_shutdown_hosts_net(struct net *net)
void
nlm_shutdown_hosts(void)
{
- struct hlist_head *chain;
- struct hlist_node *pos;
- struct nlm_host *host;
-
nlm_shutdown_hosts_net(NULL);
-
- /* complain if any hosts are left */
- if (nrhosts != 0) {
- printk(KERN_WARNING "lockd: couldn't shutdown host module!\n");
- dprintk("lockd: %lu hosts left:\n", nrhosts);
- for_each_host(host, pos, chain, nlm_server_hosts) {
- dprintk(" %s (cnt %d use %d exp %ld net %p)\n",
- host->h_name, atomic_read(>h_count),
- host->h_inuse, host->h_expires, host->net);
- }
- }
}
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/15] LockD: manage used host count per networks namespace
This patch introduces moves nrhosts in per-net data.
It also adds kernel warning to nlm_shutdown_hosts_net() about remaining hosts
in specified network namespace context.
Signed-off-by: Stanislav Kinsbursky
---
fs/lockd/host.c | 18 ++
fs/lockd/netns.h |1 +
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/fs/lockd/host.c b/fs/lockd/host.c
index 3636734..6c56090 100644
--- a/fs/lockd/host.c
+++ b/fs/lockd/host.c
@@ -173,6 +173,7 @@ out:
static void nlm_destroy_host_locked(struct nlm_host *host)
{
struct rpc_clnt *clnt;
+ struct lockd_net *ln = net_generic(host->net, lockd_net_id);
dprintk("lockd: destroy host %s\n", host->h_name);
@@ -189,6 +190,7 @@ static void nlm_destroy_host_locked(struct nlm_host *host)
rpc_shutdown_client(clnt);
kfree(host);
+ ln->nrhosts--;
nrhosts--;
}
@@ -229,6 +231,7 @@ struct nlm_host *nlmclnt_lookup_host(const struct sockaddr
*sap,
struct hlist_node *pos;
struct nlm_host *host;
struct nsm_handle *nsm = NULL;
+ struct lockd_net *ln = net_generic(net, lockd_net_id);
dprintk("lockd: %s(host='%s', vers=%u, proto=%s)\n", __func__,
(hostname ? hostname : ""), version,
@@ -263,6 +266,7 @@ struct nlm_host *nlmclnt_lookup_host(const struct sockaddr
*sap,
goto out;
hlist_add_head(>h_hash, chain);
+ ln->nrhosts++;
nrhosts++;
dprintk("lockd: %s created host %s (%s)\n", __func__,
@@ -384,6 +388,7 @@ struct nlm_host *nlmsvc_lookup_host(const struct svc_rqst
*rqstp,
memcpy(nlm_srcaddr(host), src_sap, src_len);
host->h_srcaddrlen = src_len;
hlist_add_head(>h_hash, chain);
+ ln->nrhosts++;
nrhosts++;
dprintk("lockd: %s created host %s (%s)\n",
@@ -592,6 +597,19 @@ nlm_shutdown_hosts_net(struct net *net)
/* Then, perform a garbage collection pass */
nlm_gc_hosts(net);
mutex_unlock(_host_mutex);
+
+ /* complain if any hosts are left */
+ if (net) {
+ struct lockd_net *ln = net_generic(net, lockd_net_id);
+
+ printk(KERN_WARNING "lockd: couldn't shutdown host module for
net %p!\n", net);
+ dprintk("lockd: %lu hosts left in net %p:\n", ln->nrhosts, net);
+ for_each_host(host, pos, chain, nlm_server_hosts) {
+ dprintk(" %s (cnt %d use %d exp %ld net %p)\n",
+ host->h_name, atomic_read(>h_count),
+ host->h_inuse, host->h_expires, host->net);
+ }
+ }
}
/*
diff --git a/fs/lockd/netns.h b/fs/lockd/netns.h
index 97c6c77..44c8f0b 100644
--- a/fs/lockd/netns.h
+++ b/fs/lockd/netns.h
@@ -6,6 +6,7 @@
struct lockd_net {
unsigned int nlmsvc_users;
unsigned long next_gc;
+ unsigned long nrhosts;
};
extern int lockd_net_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/
[PATCH v2 03/15] LockD: manage garbage collection timeout per networks namespace
This patch moves next_gc to per-net data.
Note: passed network can be NULL (when Lockd kthread is exiting of Lockd
module is removing).
Signed-off-by: Stanislav Kinsbursky
---
fs/lockd/host.c | 12 +---
fs/lockd/netns.h |1 +
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/fs/lockd/host.c b/fs/lockd/host.c
index 991274a..3636734 100644
--- a/fs/lockd/host.c
+++ b/fs/lockd/host.c
@@ -21,6 +21,8 @@
#include
+#include "netns.h"
+
#define NLMDBG_FACILITYNLMDBG_HOSTCACHE
#define NLM_HOST_NRHASH32
#define NLM_HOST_REBIND(60 * HZ)
@@ -41,7 +43,6 @@ static struct hlist_head
nlm_client_hosts[NLM_HOST_NRHASH];
hlist_for_each_entry_safe((host), (pos), (next), \
(chain), h_hash)
-static unsigned long next_gc;
static unsigned long nrhosts;
static DEFINE_MUTEX(nlm_host_mutex);
@@ -337,6 +338,7 @@ struct nlm_host *nlmsvc_lookup_host(const struct svc_rqst
*rqstp,
.hostname_len = hostname_len,
.net= net,
};
+ struct lockd_net *ln = net_generic(net, lockd_net_id);
dprintk("lockd: %s(host='%*s', vers=%u, proto=%s)\n", __func__,
(int)hostname_len, hostname, rqstp->rq_vers,
@@ -344,7 +346,7 @@ struct nlm_host *nlmsvc_lookup_host(const struct svc_rqst
*rqstp,
mutex_lock(_host_mutex);
- if (time_after_eq(jiffies, next_gc))
+ if (time_after_eq(jiffies, ln->next_gc))
nlm_gc_hosts(net);
chain = _server_hosts[nlm_hash_address(ni.sap)];
@@ -653,5 +655,9 @@ nlm_gc_hosts(struct net *net)
nlm_destroy_host_locked(host);
}
- next_gc = jiffies + NLM_HOST_COLLECT;
+ if (net) {
+ struct lockd_net *ln = net_generic(net, lockd_net_id);
+
+ ln->next_gc = jiffies + NLM_HOST_COLLECT;
+ }
}
diff --git a/fs/lockd/netns.h b/fs/lockd/netns.h
index ce227e0..97c6c77 100644
--- a/fs/lockd/netns.h
+++ b/fs/lockd/netns.h
@@ -5,6 +5,7 @@
struct lockd_net {
unsigned int nlmsvc_users;
+ unsigned long next_gc;
};
extern int lockd_net_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/
[PATCH v2 02/15] LockD: make garbage collector network namespace aware.
---
fs/lockd/host.c | 22 +-
1 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/fs/lockd/host.c b/fs/lockd/host.c
index 2c5f41b..991274a 100644
--- a/fs/lockd/host.c
+++ b/fs/lockd/host.c
@@ -45,7 +45,7 @@ static unsigned long next_gc;
static unsigned long nrhosts;
static DEFINE_MUTEX(nlm_host_mutex);
-static voidnlm_gc_hosts(void);
+static voidnlm_gc_hosts(struct net *net);
struct nlm_lookup_host_info {
const int server; /* search for server|client */
@@ -345,7 +345,7 @@ struct nlm_host *nlmsvc_lookup_host(const struct svc_rqst
*rqstp,
mutex_lock(_host_mutex);
if (time_after_eq(jiffies, next_gc))
- nlm_gc_hosts();
+ nlm_gc_hosts(net);
chain = _server_hosts[nlm_hash_address(ni.sap)];
hlist_for_each_entry(host, pos, chain, h_hash) {
@@ -588,7 +588,7 @@ nlm_shutdown_hosts_net(struct net *net)
}
/* Then, perform a garbage collection pass */
- nlm_gc_hosts();
+ nlm_gc_hosts(net);
mutex_unlock(_host_mutex);
}
@@ -623,27 +623,31 @@ nlm_shutdown_hosts(void)
* mark & sweep for resources held by remote clients.
*/
static void
-nlm_gc_hosts(void)
+nlm_gc_hosts(struct net *net)
{
struct hlist_head *chain;
struct hlist_node *pos, *next;
struct nlm_host *host;
- struct net *net = _net;
- dprintk("lockd: host garbage collection\n");
- for_each_host(host, pos, chain, nlm_server_hosts)
+ dprintk("lockd: host garbage collection for net %p\n", net);
+ for_each_host(host, pos, chain, nlm_server_hosts) {
+ if (net && host->net != net)
+ continue;
host->h_inuse = 0;
+ }
/* Mark all hosts that hold locks, blocks or shares */
nlmsvc_mark_resources(net);
for_each_host_safe(host, pos, next, chain, nlm_server_hosts) {
+ if (net && host->net != net)
+ continue;
if (atomic_read(>h_count) || host->h_inuse
|| time_before(jiffies, host->h_expires)) {
dprintk("nlm_gc_hosts skipping %s "
- "(cnt %d use %d exp %ld)\n",
+ "(cnt %d use %d exp %ld net %p)\n",
host->h_name, atomic_read(>h_count),
- host->h_inuse, host->h_expires);
+ host->h_inuse, host->h_expires, host->net);
continue;
}
nlm_destroy_host_locked(host);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/15] LockD: mark host per network namespace on garbage collect
This is required for per-network NLM shutdown and cleanup.
This patch passes init_net for a while.
Signed-off-by: Stanislav Kinsbursky
---
fs/lockd/host.c |3 ++-
fs/lockd/svcsubs.c | 19 +--
include/linux/lockd/lockd.h |2 +-
3 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/fs/lockd/host.c b/fs/lockd/host.c
index eb75ca7..2c5f41b 100644
--- a/fs/lockd/host.c
+++ b/fs/lockd/host.c
@@ -628,13 +628,14 @@ nlm_gc_hosts(void)
struct hlist_head *chain;
struct hlist_node *pos, *next;
struct nlm_host *host;
+ struct net *net = _net;
dprintk("lockd: host garbage collection\n");
for_each_host(host, pos, chain, nlm_server_hosts)
host->h_inuse = 0;
/* Mark all hosts that hold locks, blocks or shares */
- nlmsvc_mark_resources();
+ nlmsvc_mark_resources(net);
for_each_host_safe(host, pos, next, chain, nlm_server_hosts) {
if (atomic_read(>h_count) || host->h_inuse
diff --git a/fs/lockd/svcsubs.c b/fs/lockd/svcsubs.c
index 2240d38..0deb5f6 100644
--- a/fs/lockd/svcsubs.c
+++ b/fs/lockd/svcsubs.c
@@ -309,7 +309,8 @@ nlm_release_file(struct nlm_file *file)
* Helpers function for resource traversal
*
* nlmsvc_mark_host:
- * used by the garbage collector; simply sets h_inuse.
+ * used by the garbage collector; simply sets h_inuse only for those
+ * hosts, which passed network check.
* Always returns 0.
*
* nlmsvc_same_host:
@@ -320,12 +321,15 @@ nlm_release_file(struct nlm_file *file)
* returns 1 iff the host is a client.
* Used by nlmsvc_invalidate_all
*/
+
static int
-nlmsvc_mark_host(void *data, struct nlm_host *dummy)
+nlmsvc_mark_host(void *data, struct nlm_host *hint)
{
struct nlm_host *host = data;
- host->h_inuse = 1;
+ if ((hint->net == NULL) ||
+ (host->net == hint->net))
+ host->h_inuse = 1;
return 0;
}
@@ -358,10 +362,13 @@ nlmsvc_is_client(void *data, struct nlm_host *dummy)
* Mark all hosts that still hold resources
*/
void
-nlmsvc_mark_resources(void)
+nlmsvc_mark_resources(struct net *net)
{
- dprintk("lockd: nlmsvc_mark_resources\n");
- nlm_traverse_files(NULL, nlmsvc_mark_host, NULL);
+ struct nlm_host hint;
+
+ dprintk("lockd: nlmsvc_mark_resources for net %p\n", net);
+ hint.net = net;
+ nlm_traverse_files(, nlmsvc_mark_host, NULL);
}
/*
diff --git a/include/linux/lockd/lockd.h b/include/linux/lockd/lockd.h
index f04ce6a..50e31a2 100644
--- a/include/linux/lockd/lockd.h
+++ b/include/linux/lockd/lockd.h
@@ -279,7 +279,7 @@ void nlmsvc_release_call(struct nlm_rqst
*);
__be32 nlm_lookup_file(struct svc_rqst *, struct nlm_file **,
struct nfs_fh *);
void nlm_release_file(struct nlm_file *);
-void nlmsvc_mark_resources(void);
+void nlmsvc_mark_resources(struct net *);
void nlmsvc_free_host_resources(struct nlm_host *);
void nlmsvc_invalidate_all(void);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/15] Lockd: grace period containerization
Bruce, I feel this patch set is ready for inclusion. v2: 1) Rebase on Bruce's "for-3.6" branch. This patch set makes grace period and hosts reclaiming network namespace aware. Main ideas: 1) moving of unsigned long next_gc; unsigned long nrhosts; struct delayed_work grace_period_end; struct lock_manager lockd_manager; struct list_head grace_list; to per-net Lockd data. 2) moving of struct lock_manager nfsd4_manager; to per-net NFSd data. 3) shutdown + gc of NLM hosts done now network namespace aware. 4) restart_grace() now works only for init_net. The following series implements... --- Stanislav Kinsbursky (15): LockD: mark host per network namespace on garbage collect LockD: make garbage collector network namespace aware. LockD: manage garbage collection timeout per networks namespace LockD: manage used host count per networks namespace Lockd: host complaining function introduced Lockd: add more debug to host shutdown functions LockD: manage grace period per network namespace LockD: make lockd manager allocated per network namespace NFSd: make nfsd4_manager allocated per network namespace context. SUNRPC: service request network namespace helper introduced LockD: manage grace list per network namespace LockD: pass actual network namespace to grace period management functions Lockd: move grace period management from lockd() to per-net functions NFSd: make grace end flag per network namespace NFSd: make boot_time variable per network namespace fs/lockd/grace.c| 16 +-- fs/lockd/host.c | 92 ++ fs/lockd/netns.h|7 +++ fs/lockd/svc.c | 43 ++ fs/lockd/svc4proc.c | 13 +++-- fs/lockd/svclock.c | 16 +++ fs/lockd/svcproc.c | 15 -- fs/lockd/svcsubs.c | 19 +--- fs/nfs/callback_xdr.c |4 +- fs/nfsd/export.c|4 +- fs/nfsd/netns.h |4 ++ fs/nfsd/nfs4idmap.c |4 +- fs/nfsd/nfs4proc.c | 18 --- fs/nfsd/nfs4state.c | 104 --- fs/nfsd/state.h |4 +- include/linux/fs.h |5 +- include/linux/lockd/lockd.h |6 +- include/linux/sunrpc/svc.h |2 + 18 files changed, 231 insertions(+), 145 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/
[GIT PULL] spi updates for 3.6
The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678: Linux 3.5-rc5 (2012-06-30 16:08:57 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git tags/spi-3.6 for you to fetch changes up to 8ceffa7c4a4c378d8e371fe2f444656e75390b34: spi/orion: remove uneeded spi_info (2012-07-23 14:14:54 +0100) spi: Updates for 3.6 Since Grant is even more specacularly busy than usual for the time being I've been collecting SPI patches for him for this release - probably things will revert back to Grant before the next release. There's nothing too exciting here, mostly it's simple driver specific stuff: - Add spi: to the modaliases of SPI devices to provide namespacing. - A driver for AD-FMCOMMS1-EBZ. - DT binding for Orion. - Fixes and cleanups for i.MX, PL0022, OMAP and bitbang drivers. There may be a few more fixes I've missed, people keep sending me new things. Alexandre Pereira da Silva (1): spi/pl022: cleanup pl022 header documentation Andrew Lunn (1): spi/orion: add device tree binding Arnd Bergmann (1): spi/omap2: mark omap2_mcspi_master_setup as __devinit Florian Fainelli (1): spi/bcm63xx: fix clock configuration selection Grant Likely (1): spi: Add "spi:" prefix to modalias attribute of spi devices Hui Wang (2): spi/imx: remove redundant config.speed_hz setting spi/imx: use gpio_is_valid to determine if a gpio is valid Lars-Peter Clausen (1): spi: Add AD-FMCOMMS1-EBZ I2C-SPI bridge driver Laxman Dewangan (1): spi: tegra: use dmaengine based dma driver Linus Walleij (2): spi/pl022: delete DB5500 support spi/pl022: enable runtime PM Mark Brown (1): Merge branch 'pl022' of git://git.kernel.org/.../linusw/linux-stericsson into spi-next Michael Walle (1): spi/orion: remove uneeded spi_info Shubhrajyoti D (1): spi: omap2-mcspi: Fix the below warning Uwe Kleine-König (1): spi/gpio: start with CS non-active Virupax Sadashivpetimath (1): spi/pl022: disable port when unused .../devicetree/bindings/spi/spi-orion.txt | 19 ++ drivers/spi/Kconfig|9 +- drivers/spi/Makefile |1 + drivers/spi/spi-bcm63xx.c |2 +- drivers/spi/spi-gpio.c |3 +- drivers/spi/spi-imx.c | 14 +- drivers/spi/spi-omap2-mcspi.c |8 +- drivers/spi/spi-orion.c| 22 +- drivers/spi/spi-pl022.c| 23 +- drivers/spi/spi-tegra.c| 89 ++- drivers/spi/spi-xcomm.c| 276 drivers/spi/spi.c |2 +- include/linux/amba/pl022.h |9 +- 13 files changed, 430 insertions(+), 47 deletions(-) create mode 100644 Documentation/devicetree/bindings/spi/spi-orion.txt create mode 100644 drivers/spi/spi-xcomm.c signature.asc Description: Digital signature
Re: [RFC PATCH 00/13] firmware loader: introduce cache/uncache firmware
On Wed, Jul 25, 2012 at 8:43 PM, Oliver Neukum wrote: > This is likely unwise. You'd better introduce a special flag for kernel > threads > that should be thawed only after user space will have been thawed. IMO, it is not necessary to introduce one extra flag for the purpose since - usermodehelper flag should be set/get as enabled after user space tasks have been waken up - no harm to thaw all user space tasks before thawing all kernel threads (there isn't any dependency about the thawing order) Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list
Il 25/07/2012 14:47, Boaz Harrosh ha scritto: > > NACK-by: Boaz Harrosh > > > Apart from the HighMem pages problem, where in previous sg_set_buf() > code was the marker copied? It was not because it is not needed because > the allocation of sg took care of that. For example in 64bit the is no > bugs, right? > > If there was a destination sg_list termination bug, it should be fixed > as a separate patch from this "HighMem pages problem". But I bet if > you inspect the code carefully there isn't such a bug. Hmm, we're talking past each other. Let's sort it out in the v1 thread. Sen, please hold up the patch for a moment. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list
Il 25/07/2012 14:34, Boaz Harrosh ha scritto: >>> for_each_sg(table->sgl, sg_elem, table->nents, i) >>> - sg_set_buf([idx++], sg_virt(sg_elem), >>> sg_elem->length); >>> + sg_set_page([idx++], sg_page(sg_elem), >>> sg_elem->length, >>> + sg_elem->offset); > > This can simply be > >sg[idx++] = *sg_elem; > >>> >>> No! Please use sg_set_page()! Look at sg_set_page(), which calls >>> sg_assign_page(). >>> It has all these jump over chained arrays. When you'll start using long >>> sg_lists (which you should) then jumping from chain to chain must go through >>> sg_page(sg_elem) && sg_assign_page(), As in the original patch. >> >> actually it seems to me that using sg_set_page is wrong, because it will >> not copy the end marker from table->sgl to sg[]. If something chained >> the sg[] scatterlist onto something else, sg_next's test for sg_is_last >> would go beyond the table->nents-th item and access invalid memory. > > > Yes, you did not understand this structure. And Yes I am right, when > using chained lists you *must* use sg_set_page(). > > You see the chaining belongs to the allocation not the value of the > sg-elements. One must not copy the chaining marker to the destination > array which might have it's own. Except here the destination array has to be given to virtio, which doesn't (yet) understand chaining. I'm using for_each_sg rather than a simple memcpy exactly because I want to flatten the input scatterlist onto consecutive scatterlist entries, which is what virtio expects (and what I'll change when I get to it). for_each_sg guarantees that I get non-chain scatterlists only, so it is okay to value-assign them to sg[]. (Replying to your other message, > No this code is correct, though you will need to make sure to properly > terminate the destination sg_list. > > But since old code was using sg_set_buf(), than it means it was properly > terminated before, and there for this code is good as is please don't > touch it. It was _not_ properly terminated, and didn't matter because virtio doesn't care about termination. Changing all the virtio devices to properly terminate chains (and to use for_each_sg) is a prerequisite for properly supporting long sglists). > In SCSI land most LLDs should support chaining just by virtu of using the > for_each_sg macro. That all it takes. Your code above does support it. Yes, it supports it but still has to undo them before passing to virtio. What my LLD does is add a request descriptor in front of the scatterlist that the LLD receives. I would like to do this with a 2-item scatterlist: one for the request descriptor, and one which is a chain to the original scatterlist. Except that if I call sg_chain and my architecture does not define ARCH_HAS_SG_CHAIN, it will BUG out. So I need to keep all the scatterlist allocation and copying crap that I have now within #ifdef, and it will bitrot. >> I would need to add support for the long sglists to virtio; this is not >> a problem, but in the past Rusty complained that long sg-lists are not >> well suited to virtio (which would like to add elements not just at the >> beginning of a given sglist, but also at the end). > > Well that can be done as well, (If done carefully) It should be easy to add > chained fragments to both the end of a given chain just as at beginning. > It only means that the last element of the appended-to chain moves to > the next fragment and it's place is replaced by a link. But you cannot do that in constant time, can you? And that means you do not enjoy any benefit in terms of cache misses etc. Also, this assumes that I can modify the appended-to chain. I'm not sure I can do this? >> It seems to me that virtio would prefer to work with a struct >> scatterlist ** rather than a long sglist. > > That's just going backwards, and lazy. As you said if you want to enjoy > the better performance cake you better break some eggs ;-) :) Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list
On 07/25/2012 03:34 PM, Paolo Bonzini wrote: > Il 25/07/2012 14:13, Wang Sen ha scritto: >> When using the commands below to write some data to a virtio-scsi LUN of the >> QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will >> crash. >> >> # sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.) >> # sudo mount /dev/sdb /mnt >> # dd if=/dev/zero of=/mnt/file bs=1M count=1024 >> >> In current implementation, sg_set_buf is called to add buffers to sg list >> which >> is put into the virtqueue eventually. But if there are some HighMem pages in >> table->sgl you can not get virtual address by sg_virt. So, sg_virt(sg_elem) >> may >> return NULL value. This will cause QEMU exit when virtqueue_map_sg is called >> in QEMU because an invalid GPA is passed by virtqueue. >> >> I take Paolo's solution mentioned in last thread to avoid failure on >> handling >> flag bits. > > Please include an URL or (better) summarize the reason why sg_set_page > is not correct in the commit message. For example, replace this > paragraph with the following: > > "To fix this, we can simply copy the original scatterlist entries into > virtio-scsi's; we need to copy the entries entirely, including the flag > bits, so using sg_set_page is not correct". > > Please send v3 with this change and I'll add my Acked-by. > NACK-by: Boaz Harrosh Apart from the HighMem pages problem, where in previous sg_set_buf() code was the marker copied? It was not because it is not needed because the allocation of sg took care of that. For example in 64bit the is no bugs, right? If there was a destination sg_list termination bug, it should be fixed as a separate patch from this "HighMem pages problem". But I bet if you inspect the code carefully there isn't such a bug. Cheers Boaz > Paolo > >> >> I have tested the patch on my workstation. QEMU would not crash any more. >> >> Signed-off-by: Wang Sen >> --- >> drivers/scsi/virtio_scsi.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c >> index 1b38431..6661610 100644 >> --- a/drivers/scsi/virtio_scsi.c >> +++ b/drivers/scsi/virtio_scsi.c >> @@ -198,7 +198,7 @@ static void virtscsi_map_sgl(struct scatterlist *sg, >> unsigned int *p_idx, >> int i; >> >> for_each_sg(table->sgl, sg_elem, table->nents, i) >> -sg_set_buf([idx++], sg_virt(sg_elem), sg_elem->length); >> +sg[idx++] = *sg_elem; >> >> *p_idx = idx; >> } >> > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] lis3: add generic DT matching code
This patch adds logic to parse lis3 properties from a device tree node
and store them in a freshly allocated lis3lv02d_platform_data.
Note that the actual match tables are left out here. This part should
happen in the drivers that bind to the individual busses (SPI/I2C/PCI).
Also adds some DT bindinds documentation.
Signed-off-by: Daniel Mack
---
v2 of this patch adds some documentation as well, and while writing it,
I found two minor copy'n paste issues that I also fixed.
Documentation/devicetree/bindings/misc/lis302.txt | 74 +++
drivers/misc/lis3lv02d/lis3lv02d.c| 137 +
drivers/misc/lis3lv02d/lis3lv02d.h|4 +
3 files changed, 215 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/lis302.txt
diff --git a/Documentation/devicetree/bindings/misc/lis302.txt
b/Documentation/devicetree/bindings/misc/lis302.txt
new file mode 100644
index 000..66230fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/lis302.txt
@@ -0,0 +1,74 @@
+LIS302 accelerometer devicetree bindings
+
+This device is matched via its bus drivers, and has a number of properties
+that apply in on the generic device (independent from the bus).
+
+
+Required properties for the SPI bindings:
+ - compatible: should be set to "st,lis3lv02d_spi"
+ - reg:the chipselect index
+ - spi-max-frequency: maximal bus speed, should be set to 100 unless
+ constrained by external circuitry
+ - interrupts: the interrupt generated by the device
+
+
+Optional properties for all bus drivers:
+
+ - st,click-single-{x,y,z}:if present, tells the device to issue an
+ interrupt on single click events on the
+ x/y/z axis.
+ - st,click-double-{x,y,z}:if present, tells the device to issue an
+ interrupt on double click events on the
+ x/y/z axis.
+ - st,click-thresh-{x,y,z}:set the x/y/z axis threshold
+ - st,click-click-time-limit: click time limit, from 0 to 127.5msec
+ with step of 0.5 msec
+ - st,click-latency: click latency, from 0 to 255 msec with
+ step of 1 msec.
+ - st,click-window:click window, from 0 to 255 msec with
+ step of 1 msec.
+ - st,irq{1,2}-disable:disable IRQ 1/2
+ - st,irq{1,2}-ff-wu-1:raise IRQ 1/2 on FF_WU_1 condition
+ - st,irq{1,2}-ff-wu-2:raise IRQ 1/2 on FF_WU_2 condition
+ - st,irq{1,2}-data-ready: raise IRQ 1/2 on data ready contition
+ - st,irq{1,2}-click: raise IRQ 1/2 on click condition
+ - st,irq-open-drain: consider IRQ lines open-drain
+ - st,irq-active-low: make IRQ lines active low
+ - st,wu-duration-1: duration register for Free-Fall/Wake-Up
+ interrupt 1
+ - st,wu-duration-2: duration register for Free-Fall/Wake-Up
+ interrupt 2
+ - st,wakeup-{x,y,z}-{lo,hi}: set wakeup condition on x/y/z axis for
+ upper/lower limit
+ - st,highpass-cutoff-hz=: 1, 2, 4 or 8 for 1Hz, 2Hz, 4Hz or 8Hz of
+ highpass cut-off frequency
+ - st,hipass{1,2}-disable: disable highpass 1/2.
+ - st,default-rate=: set the default rate
+ - st,axis-{x,y,z}=: set the axis to map to the three coordinates
+
+
+Example for a SPI device node:
+
+ lis302@0 {
+ compatible = "st,lis302dl-spi";
+ reg = <0>;
+ spi-max-frequency = <100>;
+ interrupt-parent = <>;
+ interrupts = <104 0>;
+
+ st,click-single-x;
+ st,click-single-y;
+ st,click-single-z;
+ st,click-thresh-x = <10>;
+ st,click-thresh-y = <10>;
+ st,click-thresh-z = <10>;
+ st,irq1-click;
+ st,irq2-click;
+ st,wakeup-x-lo;
+ st,wakeup-x-hi;
+ st,wakeup-y-lo;
+ st,wakeup-y-hi;
+ st,wakeup-z-lo;
+ st,wakeup-z-hi;
+ };
+
diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c
b/drivers/misc/lis3lv02d/lis3lv02d.c
index a981e2a..22f7d65 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include "lis3lv02d.h"
#define DRIVER_NAME "lis3lv02d"
@@ -912,6 +913,138 @@ static void lis3lv02d_8b_configure(struct lis3lv02d *lis3,
}
}
+#ifdef CONFIG_OF
+static int lis3lv02d_init_dt(struct lis3lv02d *lis3)
+{
+ struct lis3lv02d_platform_data *pdata;
+ struct device_node *np = lis3->of_node;
+ u32 tmp;
+
+ if (!lis3->of_node)
+ return 0;
+
+
Re: [RFC PATCH 00/13] firmware loader: introduce cache/uncache firmware
On Wednesday 25 July 2012 20:35:28 Ming Lei wrote: > CC usb guys and list > > On Wed, Jul 25, 2012 at 1:53 AM, Linus Torvalds > wrote: > > > > I really think the isight thing is a totally different thing entirely. > > > > And quite frankly, that's just a BUG in the USB implementation. If the > > USB ID changes, it shouldn't be considered a "resume" thing at all, > > but a probe thing, and that should not be done in early resume - it > > should be done *after* the resume is done. > > IMO, usbcore may have found the ID changes during resume(reset_resume), > and make the device disconnect. The disconnect event will be handled > in hubd kthread, which is woken up before usermodehelper_enable()(see > thaw_processes), so request_firmware will return failure during probe() > inside hubd kthread. > > The cache firmware patch set may not help the situation, because the > original isight usb device for downloading firmware has been disconnected > before system suspend, so firmware loader can't cache the firmware for > the device. > > The below patch should fix the problem above. This is likely unwise. You'd better introduce a special flag for kernel threads that should be thawed only after user space will have been thawed. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list
On 07/25/2012 02:44 PM, Sen Wang wrote: > 2012/7/25 Paolo Bonzini : >> Il 25/07/2012 10:29, Wang Sen ha scritto: >>> When using the commands below to write some data to a virtio-scsi LUN of the >>> QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will >>> crash. >>> >>> # sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.) >>> # sudo mount /dev/sdb /mnt >>> # dd if=/dev/zero of=/mnt/file bs=1M count=1024 >>> >>> In current implementation, sg_set_buf is called to add buffers to sg list >>> which >>> is put into the virtqueue eventually. But there are some HighMem pages in >>> table->sgl can not get virtual address by sg_virt. So, sg_virt(sg_elem) may >>> return NULL value. This will cause QEMU exit when virtqueue_map_sg is called >>> in QEMU because an invalid GPA is passed by virtqueue. >> >> Heh, I was compiling (almost) the same patch as we speak. :) > > Uh, what a coincidence! :) > >> >> I've never seen QEMU crash; the VM would more likely just fail to boot >> with a panic. But it's the same bug anyway. > > I never met this before. How this situation happens? > >> >>> My solution is using sg_set_page instead of sg_set_buf. >>> >>> I have tested the patch on my workstation. QEMU would not crash any more. >>> >>> Signed-off-by: Wang Sen >>> --- >>> drivers/scsi/virtio_scsi.c |3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c >>> index 1b38431..fc5c88a 100644 >>> --- a/drivers/scsi/virtio_scsi.c >>> +++ b/drivers/scsi/virtio_scsi.c >>> @@ -198,7 +198,8 @@ static void virtscsi_map_sgl(struct scatterlist *sg, >>> unsigned int *p_idx, >>> int i; >>> >>> for_each_sg(table->sgl, sg_elem, table->nents, i) >>> - sg_set_buf([idx++], sg_virt(sg_elem), sg_elem->length); >>> + sg_set_page([idx++], sg_page(sg_elem), sg_elem->length, >>> + sg_elem->offset); >> >> This can simply be >> >>sg[idx++] = *sg_elem; >> > > Yes, I saw your another E-mail. I think you're right. Simply calling > sg_set_page can not handle > the flag bits correctly. So, I'll repost the patch soon. Thank you! > No this code is correct, though you will need to make sure to properly terminate the destination sg_list. But since old code was using sg_set_buf(), than it means it was properly terminated before, and there for this code is good as is please don't touch it. Thanks Boaz >> Can you repost it with this change, and also add sta...@vger.kernel.org >> to the Cc? Thanks very much! >> >> Paolo >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pwm_backlight: Add device tree support for Low Threshold Brightness
Low Threshold Brightness should be configured to have a linear relation
in brightness scale. This patch adds device tree support for low
threshold brightness as optional one for pwm_backlight.
Signed-off-by: Philip, Avinash
---
:100644 100644 1e4fc72... 5c54380... M
Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
:100644 100644 995f016... 4965408... M drivers/video/backlight/pwm_bl.c
.../bindings/video/backlight/pwm-backlight.txt | 21
drivers/video/backlight/pwm_bl.c |5
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git
a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
index 1e4fc72..5c54380 100644
--- a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
+++ b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
@@ -14,6 +14,8 @@ Required properties:
Optional properties:
- pwm-names: a list of names for the PWM devices specified in the
"pwms" property (see PWM binding[0])
+ - low_threshold_brightness: brightness threshold low level. (get linear
+scales in brightness in low end of brightness levels)
[0]: Documentation/devicetree/bindings/pwm/pwm.txt
@@ -26,3 +28,22 @@ Example:
brightness-levels = <0 4 8 16 32 64 128 255>;
default-brightness-level = <6>;
};
+
+Example for brightness_threshold_level:
+
+ backlight {
+ compatible = "pwm-backlight";
+ pwms = < 0 5>;
+
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+ low_threshold_brightness = <50>;
+ };
+};
+Note:
+Low threshold support is required to have linear brightness scale from
+0 to max. For some panels, backlight absent on low end of brightness
+scale. So support for Low Threshold been required. So that the scale of
+brightness changed from Low Threshold to Max in scales defined in
+brightness-levels. In this example 20% maximum brightness scale should
+be required to turn on panel backlight.
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 995f016..4965408 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -143,6 +143,11 @@ static int pwm_backlight_parse_dt(struct device *dev,
data->dft_brightness = value;
data->max_brightness--;
+
+ ret = of_property_read_u32(node, "low_threshold_brightness",
+ );
+ if (!ret)
+ data->lth_brightness = value;
}
/*
--
1.7.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: [RFC PATCH 00/13] firmware loader: introduce cache/uncache firmware
CC usb guys and list
On Wed, Jul 25, 2012 at 1:53 AM, Linus Torvalds
wrote:
>
> I really think the isight thing is a totally different thing entirely.
>
> And quite frankly, that's just a BUG in the USB implementation. If the
> USB ID changes, it shouldn't be considered a "resume" thing at all,
> but a probe thing, and that should not be done in early resume - it
> should be done *after* the resume is done.
IMO, usbcore may have found the ID changes during resume(reset_resume),
and make the device disconnect. The disconnect event will be handled
in hubd kthread, which is woken up before usermodehelper_enable()(see
thaw_processes), so request_firmware will return failure during probe()
inside hubd kthread.
The cache firmware patch set may not help the situation, because the
original isight usb device for downloading firmware has been disconnected
before system suspend, so firmware loader can't cache the firmware for
the device.
The below patch should fix the problem above.
diff --git a/kernel/power/process.c b/kernel/power/process.c
index 19db29f..eb8355f 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -185,16 +185,18 @@ void thaw_processes(void)
printk("Restarting tasks ... ");
- thaw_workqueues();
-
read_lock(_lock);
do_each_thread(g, p) {
- __thaw_task(p);
+ if (!(p->flags & (PF_KTHREAD | PF_WQ_WORKER)))
+ __thaw_task(p);
} while_each_thread(g, p);
read_unlock(_lock);
usermodehelper_enable();
+ /* let kthread see usermodehelper enabled flag */
+ thaw_kernel_threads();
+
schedule();
printk("done.\n");
}
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list
On 07/25/2012 12:41 PM, Paolo Bonzini wrote: > Il 25/07/2012 11:22, Boaz Harrosh ha scritto: >> for_each_sg(table->sgl, sg_elem, table->nents, i) >> -sg_set_buf([idx++], sg_virt(sg_elem), >> sg_elem->length); >> +sg_set_page([idx++], sg_page(sg_elem), >> sg_elem->length, >> +sg_elem->offset); This can simply be sg[idx++] = *sg_elem; Can you repost it with this change, and also add sta...@vger.kernel.org to the Cc? Thanks very much! >> >> No! Please use sg_set_page()! Look at sg_set_page(), which calls >> sg_assign_page(). >> It has all these jump over chained arrays. When you'll start using long >> sg_lists (which you should) then jumping from chain to chain must go through >> sg_page(sg_elem) && sg_assign_page(), As in the original patch. > > Hi Boaz, > > actually it seems to me that using sg_set_page is wrong, because it will > not copy the end marker from table->sgl to sg[]. If something chained > the sg[] scatterlist onto something else, sg_next's test for sg_is_last > would go beyond the table->nents-th item and access invalid memory. > Yes, you did not understand this structure. And Yes I am right, when using chained lists you *must* use sg_set_page(). You see the chaining belongs to the allocation not the value of the sg-elements. One must not copy the chaining marker to the destination array which might have it's own. And one must not crap all over the destination chaining markers, set at allocation time. The sizes and mostly the pointers of source and destination are not the same. > Using chained sglists is on my to-do list, I expect that it would make a > nice performance improvement. However, I was a bit confused as to > what's the plan there; there is hardly any user, and many arches still > do not define ARCH_HAS_SG_CHAIN. Do you have any pointer to discussions > or LWN articles? > Only the source code I'm afraid. In SCSI land most LLDs should support chaining just by virtu of using the for_each_sg macro. That all it takes. Your code above does support it. (In Wang version). Though more code need probably be added at sg allocation to actually allocate and prepare a chain. > I would need to add support for the long sglists to virtio; this is not > a problem, but in the past Rusty complained that long sg-lists are not > well suited to virtio (which would like to add elements not just at the > beginning of a given sglist, but also at the end). Well that can be done as well, (If done carefully) It should be easy to add chained fragments to both the end of a given chain just as at beginning. It only means that the last element of the appended-to chain moves to the next fragment and it's place is replaced by a link. If you have ready made two long segments A and C which you would like not to reallocate and copy, you insert a two-elements segment in the middle, say call it B. The first element of B is the last element of A which is now used as the pointer to B, and the 2nd element of B is a pointer to C. > It seems to me that > virtio would prefer to work with a struct scatterlist ** rather than a > long sglist. > That's just going backwards, and lazy. As you said if you want to enjoy the better performance cake you better break some eggs ;-) > Paolo Cheers Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list
Il 25/07/2012 14:13, Wang Sen ha scritto: > When using the commands below to write some data to a virtio-scsi LUN of the > QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash. > > # sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.) > # sudo mount /dev/sdb /mnt > # dd if=/dev/zero of=/mnt/file bs=1M count=1024 > > In current implementation, sg_set_buf is called to add buffers to sg list > which > is put into the virtqueue eventually. But if there are some HighMem pages in > table->sgl you can not get virtual address by sg_virt. So, sg_virt(sg_elem) > may > return NULL value. This will cause QEMU exit when virtqueue_map_sg is called > in QEMU because an invalid GPA is passed by virtqueue. > > I take Paolo's solution mentioned in last thread to avoid failure on handling > flag bits. Please include an URL or (better) summarize the reason why sg_set_page is not correct in the commit message. For example, replace this paragraph with the following: "To fix this, we can simply copy the original scatterlist entries into virtio-scsi's; we need to copy the entries entirely, including the flag bits, so using sg_set_page is not correct". Please send v3 with this change and I'll add my Acked-by. Paolo > > I have tested the patch on my workstation. QEMU would not crash any more. > > Signed-off-by: Wang Sen > --- > drivers/scsi/virtio_scsi.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c > index 1b38431..6661610 100644 > --- a/drivers/scsi/virtio_scsi.c > +++ b/drivers/scsi/virtio_scsi.c > @@ -198,7 +198,7 @@ static void virtscsi_map_sgl(struct scatterlist *sg, > unsigned int *p_idx, > int i; > > for_each_sg(table->sgl, sg_elem, table->nents, i) > - sg_set_buf([idx++], sg_virt(sg_elem), sg_elem->length); > + sg[idx++] = *sg_elem; > > *p_idx = idx; > } > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: x86/mm: Limit 2/4M size calculation to x86_32
On 07/25/2012 02:14 PM, Stefan Bader wrote: > On 25.07.2012 12:44, Avi Kivity wrote: >> On 07/24/2012 06:52 PM, Cong Wang wrote: >> From 6b679d1af20656929c0e829f29eed60b0a86a74f Mon Sep 17 00:00:00 2001 From: Stefan Bader Date: Fri, 13 Jul 2012 15:16:33 +0200 Subject: [PATCH] x86/mm: Limit 2/4M size calculation to x86_32 commit 722bc6b (x86/mm: Fix the size calculation of mapping tables) did modify the extra space calculation for mapping tables in order to make up for the first 2/4M memory range using 4K pages. However this setup is only used when compiling for 32bit. On 64bit there is only the trailing area of 4K pages (which is already added). The code was already adapted once for things went wrong on a 8TB machine (bd2753b x86/mm: Only add extra pages count for the first memory range during pre-allocation early page table space), but it looks a bit like it currently would overdo things for 64bit. I only noticed while bisecting for the reason I could not make a crash kernel boot (which ended up on this patch). Signed-off-by: Stefan Bader Cc: WANG Cong Cc: Yinghai Lu Cc: Tejun Heo >>> >>> Acked-by: Cong Wang >>> >>> Sorry for that I was not aware of x86_64 is different with x86 in the >>> first 2/4M. >> >> Why would there be a difference? >> >> Shouldn't the IO space at 0xa-0x10 be mapped with uncacheable >> attributes (or WC for VGA)? If it's done later, it can be done later >> for both. >> > arch/x86/mm/init.c > > unsigned long __init_refok init_memory_mapping(... > ... > ifdef CONFIG_X86_32 > /* > * Don't use a large page for the first 2/4MB of memory > * because there are often fixed size MTRRs in there > * and overlapping MTRRs into large pages can cause > * slowdowns. > */ > That's equally true for X86_64. Best would be to merge the MTRRs into PAT, but that might not work for SMM. -- 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/
[PATCH v2] power_supply: Added helper function to get the ps object from supplied_to list
This patch adds a helper function in the power supply core to get the
power supply object from supplied_to list based on power supply attribute.
Signed-off-by: Ramakrishna Pallala
---
drivers/power/power_supply_core.c | 19 +++
include/linux/power_supply.h |3 +++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/power/power_supply_core.c
b/drivers/power/power_supply_core.c
index ff990d2..5845a76 100644
--- a/drivers/power/power_supply_core.c
+++ b/drivers/power/power_supply_core.c
@@ -158,6 +158,25 @@ struct power_supply *power_supply_get_by_name(char *name)
}
EXPORT_SYMBOL_GPL(power_supply_get_by_name);
+struct power_supply *power_supply_get_by_suppliedto(struct power_supply *psy,
+ enum power_supply_property psp, int intval)
+{
+ union power_supply_propval ret = {0,};
+ struct power_supply *pst;
+ int i;
+
+ for (i = 0; i < psy->num_supplicants; i++) {
+ pst = power_supply_get_by_name(psy->supplied_to[i]);
+ if (!pst || pst->get_property(pst, psp, ))
+ continue;
+ if (ret.intval == intval)
+ return pst;
+ }
+
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(power_supply_get_by_suppliedto);
+
int power_supply_powers(struct power_supply *psy, struct device *dev)
{
return sysfs_create_link(>dev->kobj, >kobj, "powers");
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 0bafbb1..3cfee0c 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -219,6 +219,9 @@ struct power_supply_info {
};
extern struct power_supply *power_supply_get_by_name(char *name);
+extern struct power_supply *power_supply_get_by_suppliedto(
+ struct power_supply *psy,
+ enum power_supply_property psp, int intval);
extern void power_supply_changed(struct power_supply *psy);
extern int power_supply_am_i_supplied(struct power_supply *psy);
extern int power_supply_set_battery_charged(struct power_supply *psy);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list
On Wed, 2012-07-25 at 20:13 +0800, Wang Sen wrote: > When using the commands below to write some data to a virtio-scsi LUN of the > QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash. > > # sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.) > # sudo mount /dev/sdb /mnt > # dd if=/dev/zero of=/mnt/file bs=1M count=1024 > > In current implementation, sg_set_buf is called to add buffers to sg list > which > is put into the virtqueue eventually. But if there are some HighMem pages in > table->sgl you can not get virtual address by sg_virt. So, sg_virt(sg_elem) > may > return NULL value. This will cause QEMU exit when virtqueue_map_sg is called > in QEMU because an invalid GPA is passed by virtqueue. > > I take Paolo's solution mentioned in last thread to avoid failure on handling > flag bits. > > I have tested the patch on my workstation. QEMU would not crash any more. > > Signed-off-by: Wang Sen [...] This is not the correct way to submit a change for stable. See Documentation/stable_kernel_rules.txt. Ben. -- Ben Hutchings If more than one person is responsible for a bug, no one is at fault. signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 2/2] proc: do not allow negative offsets on /proc//environ
On 07/24, Djalal Harouni wrote:
>
> static int mem_open(struct inode *inode, struct file *file)
> {
> - return __mem_open(inode, file, PTRACE_MODE_ATTACH);
> + int ret = __mem_open(inode, file, PTRACE_MODE_ATTACH);
> +
> + /* OK to pass negative loff_t, we can catch out-of-range */
> + file->f_mode |= FMODE_UNSIGNED_OFFSET;
> +
> + return ret;
> }
It could be even simpler, I meant
file->f_mode |= FMODE_UNSIGNED_OFFSET;
return __mem_open(inode, file, PTRACE_MODE_ATTACH);
Never mind, this is very minor and the patch is already in -mm.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list
When using the commands below to write some data to a virtio-scsi LUN of the QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash. # sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.) # sudo mount /dev/sdb /mnt # dd if=/dev/zero of=/mnt/file bs=1M count=1024 In current implementation, sg_set_buf is called to add buffers to sg list which is put into the virtqueue eventually. But if there are some HighMem pages in table->sgl you can not get virtual address by sg_virt. So, sg_virt(sg_elem) may return NULL value. This will cause QEMU exit when virtqueue_map_sg is called in QEMU because an invalid GPA is passed by virtqueue. I take Paolo's solution mentioned in last thread to avoid failure on handling flag bits. I have tested the patch on my workstation. QEMU would not crash any more. Signed-off-by: Wang Sen --- drivers/scsi/virtio_scsi.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c index 1b38431..6661610 100644 --- a/drivers/scsi/virtio_scsi.c +++ b/drivers/scsi/virtio_scsi.c @@ -198,7 +198,7 @@ static void virtscsi_map_sgl(struct scatterlist *sg, unsigned int *p_idx, int i; for_each_sg(table->sgl, sg_elem, table->nents, i) - sg_set_buf([idx++], sg_virt(sg_elem), sg_elem->length); + sg[idx++] = *sg_elem; *p_idx = idx; } -- 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: [PATCH 03/11] perf kvm: guest userspace samples should not be lumped with host uspace
On Fri, Jul 20, 2012 at 05:25:48PM -0600, David Ahern wrote: > e.g., perf kvm --host --guest report -i perf.data --stdio -D > shows: > > 1 599127912065356 0x143b8 [0x48]: PERF_RECORD_SAMPLE(IP, 5): 5671/5676: > 0x7fdf95a061c0 period: 1 addr: 0 > ... chain: nr:2 > . 0: ff80 > . 1: fe00 > ... thread: qemu-kvm:5671 > .. dso: > > (IP, 5) means sample in guest userspace. Those samples should not be lumped > into the VMM's host thread. i.e, the report output: > > 56.86% qemu-kvm [unknown] [u] 0x7fdf95a061c0 > > With this patch the output emphasizes it is a guest userspace hit: > > 56.86% [guest/5671] [unknown] [u] 0x7fdf95a061c0 > > Looking at 3 VMs (2 64-bit, 1 32-bit) with each running a CPU bound > process (openssl speed), perf report currently shows: > > 93.84% 117726 qemu-kvm [unknown] [u] 0x7fd7dcaea8e5 > > which is wrong. With this patch you get: > > 31.50% 39258 [guest/18772] [unknown] [u] 0x7fd7dcaea8e5 > 31.50% 39236 [guest/11230] [unknown] [u] 0x00a57340 > 30.84% 39232 [guest/18395] [unknown] [u] 0x7f66f641e107 Tested-by: Jiri Olsa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 02/11] perf kvm: set name for VM process in guest machine
On Fri, Jul 20, 2012 at 05:25:47PM -0600, David Ahern wrote:
> COMM events are not generated in the context of a guest machine, so the
> thread name is never set for the VMM process. For example, the qemu-kvm
> name applies to the process in the host machine, not the guest machine.
> So, samples for guest machines are currently displayed as:
>
> 99.67% :5671 [unknown] [g] 0x81366b41
>
> where 5671 is the pid of the VMM. With this patch the samples in the guest
> machine are shown as:
>
> 18.43% [guest/5671] [unknown] [g] 0x810d68b7
Tested-by: Jiri Olsa
>
> Signed-off-by: David Ahern
> Cc: Arnaldo Carvalho de Melo
> Cc: Ingo Molnar
> Cc: Jiri Olsa
> Cc: Namhyung Kim
> Cc: Frederic Weisbecker
> Cc: Peter Zijlstra
> ---
> tools/perf/util/map.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
> index a1f4e36..8668569 100644
> --- a/tools/perf/util/map.c
> +++ b/tools/perf/util/map.c
> @@ -7,6 +7,7 @@
> #include
> #include
> #include "map.h"
> +#include "thread.h"
>
> const char *map_type__name[MAP__NR_TYPES] = {
> [MAP__FUNCTION] = "Functions",
> @@ -585,7 +586,21 @@ int machine__init(struct machine *self, const char
> *root_dir, pid_t pid)
> self->kmaps.machine = self;
> self->pid = pid;
> self->root_dir = strdup(root_dir);
> - return self->root_dir == NULL ? -ENOMEM : 0;
> + if (self->root_dir == NULL)
> + return -ENOMEM;
> +
> + if (pid != HOST_KERNEL_ID) {
> + struct thread *thread = machine__findnew_thread(self, pid);
> + char comm[64];
> +
> + if (thread == NULL)
> + return -ENOMEM;
> +
> + snprintf(comm, sizeof(comm), "[guest/%d]", pid);
> + thread__set_comm(thread, comm);
> + }
> +
> + return 0;
> }
>
> static void dsos__delete(struct list_head *self)
> --
> 1.7.10.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 04/11] perf kvm: fix bug resolving guest kernel syms - v2
On Fri, Jul 20, 2012 at 05:25:49PM -0600, David Ahern wrote: > Guest kernel symbols are not resolved despite passing the information > needed to resolve them. e.g., > > perf kvm --guest --guestmount=/tmp/guest-mount record -a -- sleep 1 > perf kvm --guest --guestmount=/tmp/guest-mount report --stdio > > 36.55% [guest/11399] [unknown] [g] 0x81600bc8 > 33.19% [guest/10474] [unknown] [g] 0xc0116e00 > 30.26% [guest/11094] [unknown] [g] 0x8100a288 > 43.69% [guest/10474] [unknown] [g] 0xc0103d90 > 37.38% [guest/11399] [unknown] [g] 0x81600bc8 > 12.24% [guest/11094] [unknown] [g] 0x810aa91d > 6.69% [guest/11094] [unknown] [u] 0x7fa784d721c3 > > which is just pathetic. > > After a maddening 2 days sifting through perf minutia I found it -- > id_hdr_size is not initialized for guest machines. This shows up on the > report side as random garbage for the cpu and timestamp, e.g., > > 29816 7310572949125804849 0x1ac0 [0x50]: PERF_RECORD_MMAP ... > > That messes up the sample sorting such that synthesized guest maps are > processed last. > > With this patch you get a much more helpful report: > > 12.11% [guest/11399] [guest.kernel.kallsyms.11399] [g] > irqtime_account_process_tick > 10.58% [guest/11399] [guest.kernel.kallsyms.11399] [g] run_timer_softirq >6.95% [guest/11094] [guest.kernel.kallsyms.11094] [g] printk_needs_cpu >6.50% [guest/11094] [guest.kernel.kallsyms.11094] [g] do_timer >6.45% [guest/11399] [guest.kernel.kallsyms.11399] [g] idle_balance >4.90% [guest/11094] [guest.kernel.kallsyms.11094] [g] native_read_tsc > ... > > v2: > - changed rbtree walk to use rb_first per Namhyung's suggestion > > Signed-off-by: David Ahern > Cc: Arnaldo Carvalho de Melo > Cc: Ingo Molnar > Cc: Jiri Olsa Tested-by: Jiri Olsa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] w1: omap-hdq: convert to module_platform_driver
trivial patch, no functional changes.
Signed-off-by: Felipe Balbi
---
drivers/w1/masters/omap_hdq.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/masters/omap_hdq.c
index 404a4de..1ebddcf 100644
--- a/drivers/w1/masters/omap_hdq.c
+++ b/drivers/w1/masters/omap_hdq.c
@@ -654,19 +654,7 @@ static int __devexit omap_hdq_remove(struct
platform_device *pdev)
return 0;
}
-static int __init
-omap_hdq_init(void)
-{
- return platform_driver_register(_hdq_driver);
-}
-module_init(omap_hdq_init);
-
-static void __exit
-omap_hdq_exit(void)
-{
- platform_driver_unregister(_hdq_driver);
-}
-module_exit(omap_hdq_exit);
+module_platform_driver(omap_hdq_driver);
module_param(w1_id, int, S_IRUSR);
MODULE_PARM_DESC(w1_id, "1-wire id for the slave detection");
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] w1: omap-hdq: remove unnecessary return
trivial patch, no functional changes. Signed-off-by: Felipe Balbi --- drivers/w1/masters/omap_hdq.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/masters/omap_hdq.c index b6eb0ba..778a65d 100644 --- a/drivers/w1/masters/omap_hdq.c +++ b/drivers/w1/masters/omap_hdq.c @@ -540,8 +540,6 @@ static void omap_w1_write_byte(void *_hdq, u8 byte) hdq_data->init_trans = 0; mutex_unlock(_data->hdq_mutex); } - - return; } static int __devinit omap_hdq_probe(struct platform_device *pdev) -- 1.7.11 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sd: do not set changed flag on all unit attention conditions
On 07/17/2012 11:11 AM, James Bottomley wrote: > On Tue, 2012-07-17 at 10:54 +0200, Paolo Bonzini wrote: >> Il 17/07/2012 10:40, James Bottomley ha scritto: > > It's not specific to virtio-scsi, in fact I expect that virtio-scsi will > be almost always used with non-removable disks. > > However, QEMU's SCSI target is not used just for virtio-scsi (for > example it can be used for USB storage), and it lets you mark a disk as > removable---why? because there exists real hardware that presents itself > as an SBC removable disk. The only thing that is specific to > virtualization, is support for online resizing (which generates a unit > attention condition CAPACITY DATA HAS CHANGED). >>> So what's the problem? If you're doing pass through of a physical disk, >>> we pick up removable from its inquiry string ... a physical removable >>> device doesn't get resized. If you have a virtual disk you want to >>> resize, you don't set the removable flag in the inquiry data. >> >> In practice people will do what you said, and it's not a problem. >> >> However, there's nothing that prevents you from running qemu with a >> removable SCSI disk, and then resizing it. I would like this to work, >> because SBC allows it and there's no reason why it shouldn't. > > There's no such thing in the market today as a removable disk that's > resizeable. Removable disks are for things like backup cartridges and > ageing jazz drives. Worse: most removeable devices today are USB card > readers whose standards compliance varies from iffy to non existent. > Resizeable disks are currently the province of storage arrays. > Ho-hum. I beg to disagree. drivers/scsi/aacraid/aachba.c:2266 /* Do not cache partition table for arrays */ scsicmd->device->removable = 1; To the extend of my knowledge aacraid does this _precisely_ to allow for resizing; in effect every open() will trigger a device revalidation. So I guess by just setting the 'removable' flag you should be okay. You might need to remount it, but that's another story. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] w1: omap-hdq: drop ARCH dependency
Let the driver compile everywhere while also removing unnecessary headers. Signed-off-by: Felipe Balbi --- drivers/w1/masters/Kconfig| 1 - drivers/w1/masters/omap_hdq.c | 3 --- 2 files changed, 4 deletions(-) diff --git a/drivers/w1/masters/Kconfig b/drivers/w1/masters/Kconfig index 5ceb1cd..7e98403 100644 --- a/drivers/w1/masters/Kconfig +++ b/drivers/w1/masters/Kconfig @@ -60,7 +60,6 @@ config W1_MASTER_GPIO config HDQ_MASTER_OMAP tristate "OMAP HDQ driver" - depends on ARCH_OMAP2PLUS help Say Y here if you want support for the 1-wire or HDQ Interface on an OMAP processor. diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/masters/omap_hdq.c index 778a65d..771875d 100644 --- a/drivers/w1/masters/omap_hdq.c +++ b/drivers/w1/masters/omap_hdq.c @@ -18,9 +18,6 @@ #include #include -#include -#include - #include "../w1.h" #include "../w1_int.h" -- 1.7.11 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] w1: omap-hdq: convert to devm_* functions
this lets us remove a bit of boilerplate code.
Signed-off-by: Felipe Balbi
---
drivers/w1/masters/omap_hdq.c | 32 +---
1 file changed, 9 insertions(+), 23 deletions(-)
diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/masters/omap_hdq.c
index 1ebddcf..b6eb0ba 100644
--- a/drivers/w1/masters/omap_hdq.c
+++ b/drivers/w1/masters/omap_hdq.c
@@ -546,33 +546,31 @@ static void omap_w1_write_byte(void *_hdq, u8 byte)
static int __devinit omap_hdq_probe(struct platform_device *pdev)
{
+ struct device *dev = >dev;
struct hdq_data *hdq_data;
struct resource *res;
int ret, irq;
u8 rev;
- hdq_data = kmalloc(sizeof(*hdq_data), GFP_KERNEL);
+ hdq_data = devm_kzalloc(dev, sizeof(*hdq_data), GFP_KERNEL);
if (!hdq_data) {
dev_dbg(>dev, "unable to allocate memory\n");
- ret = -ENOMEM;
- goto err_kmalloc;
+ return -ENOMEM;
}
- hdq_data->dev = >dev;
+ hdq_data->dev = dev;
platform_set_drvdata(pdev, hdq_data);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_dbg(>dev, "unable to get resource\n");
- ret = -ENXIO;
- goto err_resource;
+ return -ENXIO;
}
- hdq_data->hdq_base = ioremap(res->start, resource_size(res));
+ hdq_data->hdq_base = devm_request_and_ioremap(dev, res);
if (!hdq_data->hdq_base) {
dev_dbg(>dev, "ioremap failed\n");
- ret = -EINVAL;
- goto err_ioremap;
+ return -ENOMEM;
}
hdq_data->hdq_usecount = 0;
@@ -593,7 +591,8 @@ static int __devinit omap_hdq_probe(struct platform_device
*pdev)
goto err_irq;
}
- ret = request_irq(irq, hdq_isr, IRQF_DISABLED, "omap_hdq", hdq_data);
+ ret = devm_request_irq(dev, irq, hdq_isr, IRQF_DISABLED,
+ "omap_hdq", hdq_data);
if (ret < 0) {
dev_dbg(>dev, "could not request irq\n");
goto err_irq;
@@ -618,16 +617,7 @@ err_irq:
err_w1:
pm_runtime_disable(>dev);
- iounmap(hdq_data->hdq_base);
-
-err_ioremap:
-err_resource:
- platform_set_drvdata(pdev, NULL);
- kfree(hdq_data);
-
-err_kmalloc:
return ret;
-
}
static int __devexit omap_hdq_remove(struct platform_device *pdev)
@@ -646,10 +636,6 @@ static int __devexit omap_hdq_remove(struct
platform_device *pdev)
/* remove module dependency */
pm_runtime_disable(>dev);
- free_irq(INT_24XX_HDQ_IRQ, hdq_data);
- platform_set_drvdata(pdev, NULL);
- iounmap(hdq_data->hdq_base);
- kfree(hdq_data);
return 0;
}
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] w1: omap-hdq: don't hardcode resource size
we have the helpful resource_size() macro to
calculate the size of the memory resource for
us, let's use it.
Signed-off-by: Felipe Balbi
---
drivers/w1/masters/omap_hdq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/masters/omap_hdq.c
index 46e1f6f..404a4de 100644
--- a/drivers/w1/masters/omap_hdq.c
+++ b/drivers/w1/masters/omap_hdq.c
@@ -568,7 +568,7 @@ static int __devinit omap_hdq_probe(struct platform_device
*pdev)
goto err_resource;
}
- hdq_data->hdq_base = ioremap(res->start, SZ_4K);
+ hdq_data->hdq_base = ioremap(res->start, resource_size(res));
if (!hdq_data->hdq_base) {
dev_dbg(>dev, "ioremap failed\n");
ret = -EINVAL;
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] w1: omap-hdq: add section annotation to remove
trivial patch, no functional changes.
Signed-off-by: Felipe Balbi
---
drivers/w1/masters/omap_hdq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/masters/omap_hdq.c
index 291897c..46e1f6f 100644
--- a/drivers/w1/masters/omap_hdq.c
+++ b/drivers/w1/masters/omap_hdq.c
@@ -73,11 +73,11 @@ struct hdq_data {
};
static int __devinit omap_hdq_probe(struct platform_device *pdev);
-static int omap_hdq_remove(struct platform_device *pdev);
+static int __devexit omap_hdq_remove(struct platform_device *pdev);
static struct platform_driver omap_hdq_driver = {
.probe =omap_hdq_probe,
- .remove = omap_hdq_remove,
+ .remove = __devexit_p(omap_hdq_remove),
.driver = {
.name = "omap_hdq",
},
@@ -630,7 +630,7 @@ err_kmalloc:
}
-static int omap_hdq_remove(struct platform_device *pdev)
+static int __devexit omap_hdq_remove(struct platform_device *pdev)
{
struct hdq_data *hdq_data = platform_get_drvdata(pdev);
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 10/12] block: Add bio_clone_kmalloc()
On 07/24/2012 11:11 PM, Kent Overstreet wrote:
ACK-by: Boaz Harrosh
> Signed-off-by: Kent Overstreet
Thanks looks nice
> ---
> drivers/block/osdblk.c |3 +--
> fs/bio.c | 13 +
> fs/exofs/ore.c |5 ++---
> include/linux/bio.h|1 +
> 4 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/block/osdblk.c b/drivers/block/osdblk.c
> index 87311eb..1bbc681 100644
> --- a/drivers/block/osdblk.c
> +++ b/drivers/block/osdblk.c
> @@ -266,11 +266,10 @@ static struct bio *bio_chain_clone(struct bio
> *old_chain, gfp_t gfpmask)
> struct bio *tmp, *new_chain = NULL, *tail = NULL;
>
> while (old_chain) {
> - tmp = bio_kmalloc(gfpmask, old_chain->bi_max_vecs);
> + tmp = bio_clone_kmalloc(old_chain, gfpmask);
> if (!tmp)
> goto err_out;
>
> - __bio_clone(tmp, old_chain);
> tmp->bi_bdev = NULL;
> gfpmask &= ~__GFP_WAIT;
> tmp->bi_next = NULL;
> diff --git a/fs/bio.c b/fs/bio.c
> index fa6dee4..9d0ceb2 100644
> --- a/fs/bio.c
> +++ b/fs/bio.c
> @@ -499,6 +499,19 @@ struct bio *bio_clone(struct bio *bio, gfp_t gfp_mask)
> }
> EXPORT_SYMBOL(bio_clone);
>
> +struct bio *bio_clone_kmalloc(struct bio *bio, gfp_t gfp_mask)
> +{
> + struct bio *b = bio_kmalloc(gfp_mask, bio->bi_max_vecs);
> +
> + if (!b)
> + return NULL;
> +
> + __bio_clone(b, bio);
> +
> + return b;
> +}
> +EXPORT_SYMBOL(bio_clone_kmalloc);
> +
> /**
> * bio_get_nr_vecs - return approx number of vecs
> * @bdev: I/O target
> diff --git a/fs/exofs/ore.c b/fs/exofs/ore.c
> index 24a49d4..a8d92fc 100644
> --- a/fs/exofs/ore.c
> +++ b/fs/exofs/ore.c
> @@ -814,8 +814,8 @@ static int _write_mirror(struct ore_io_state *ios, int
> cur_comp)
> struct bio *bio;
>
> if (per_dev != master_dev) {
> - bio = bio_kmalloc(GFP_KERNEL,
> - master_dev->bio->bi_max_vecs);
> + bio = bio_clone_kmalloc(master_dev->bio,
> + GFP_KERNEL);
> if (unlikely(!bio)) {
> ORE_DBGMSG(
> "Failed to allocate BIO
> size=%u\n",
> @@ -824,7 +824,6 @@ static int _write_mirror(struct ore_io_state *ios, int
> cur_comp)
> goto out;
> }
>
> - __bio_clone(bio, master_dev->bio);
> bio->bi_bdev = NULL;
> bio->bi_next = NULL;
> per_dev->offset = master_dev->offset;
> diff --git a/include/linux/bio.h b/include/linux/bio.h
> index 9720544..e180f1d 100644
> --- a/include/linux/bio.h
> +++ b/include/linux/bio.h
> @@ -221,6 +221,7 @@ extern int bio_phys_segments(struct request_queue *,
> struct bio *);
>
> extern void __bio_clone(struct bio *, struct bio *);
> extern struct bio *bio_clone(struct bio *, gfp_t);
> +struct bio *bio_clone_kmalloc(struct bio *, gfp_t);
>
> extern void bio_init(struct bio *);
> extern void bio_reset(struct bio *);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 09/12] block: Rework bio_pair_split()
On 07/24/2012 11:11 PM, Kent Overstreet wrote:
> This changes bio_pair_split() to use the new bio_split() underneath,
> which gets rid of the single page bio limitation. The various callers
> are fixed up for the slightly different struct bio_pair, and to remove
> the unnecessary checks.
>
> Signed-off-by: Kent Overstreet
> +
> +extern struct bio *bio_split(struct bio *bio, int sectors,
> + gfp_t gfp, struct bio_set *bs);
nit:
Just for taking pride in my work, I'd move this extern declaration
to the previous patch that actually introduces it.
Cheers
Boaz
> extern struct bio_pair *bio_pair_split(struct bio *bi, int first_sectors);
> extern void bio_pair_release(struct bio_pair *dbio);
>
> @@ -512,7 +514,6 @@ extern int bio_integrity_prep(struct bio *);
> extern void bio_integrity_endio(struct bio *, int);
> extern void bio_integrity_advance(struct bio *, unsigned int);
> extern void bio_integrity_trim(struct bio *, unsigned int, unsigned int);
> -extern void bio_integrity_split(struct bio *, struct bio_pair *, int);
> extern int bio_integrity_clone(struct bio *, struct bio *, gfp_t, struct
> bio_set *);
> extern int bioset_integrity_create(struct bio_set *, int);
> extern void bioset_integrity_free(struct bio_set *);
> @@ -556,12 +557,6 @@ static inline int bio_integrity_clone(struct bio *bio,
> struct bio *bio_src,
> return 0;
> }
>
> -static inline void bio_integrity_split(struct bio *bio, struct bio_pair *bp,
> -int sectors)
> -{
> - return;
> -}
> -
> static inline void bio_integrity_advance(struct bio *bio,
>unsigned int bytes_done)
> {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] lis3-spi: add DT matching table passthru code
If probed from a device tree, this driver now passes the node
information to the generic part, so the runtime information can be
derived.
Successfully tested on a PXA3xx board.
Signed-off-by: Daniel Mack
---
drivers/misc/lis3lv02d/lis3lv02d_spi.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/misc/lis3lv02d/lis3lv02d_spi.c
b/drivers/misc/lis3lv02d/lis3lv02d_spi.c
index 80880e9..8616054 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d_spi.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d_spi.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include "lis3lv02d.h"
@@ -58,6 +59,12 @@ static int lis3_spi_init(struct lis3lv02d *lis3)
static union axis_conversion lis3lv02d_axis_normal =
{ .as_array = { 1, 2, 3 } };
+static struct of_device_id lis302dl_spi_dt_ids[] = {
+ { .compatible = "st,lis302dl-spi" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, lis302dl_spi_dt_ids);
+
static int __devinit lis302dl_spi_probe(struct spi_device *spi)
{
int ret;
@@ -75,6 +82,12 @@ static int __devinit lis302dl_spi_probe(struct spi_device
*spi)
lis3_dev.irq= spi->irq;
lis3_dev.ac = lis3lv02d_axis_normal;
lis3_dev.pdata = spi->dev.platform_data;
+
+#ifdef CONFIG_OF
+ if (of_match_device(lis302dl_spi_dt_ids, >dev))
+ lis3_dev.of_node = spi->dev.of_node;
+#endif
+
spi_set_drvdata(spi, _dev);
return lis3lv02d_init_device(_dev);
@@ -121,6 +134,7 @@ static struct spi_driver lis302dl_spi_driver = {
.name = DRV_NAME,
.owner = THIS_MODULE,
.pm = _spi_pm,
+ .of_match_table = of_match_ptr(lis302dl_spi_dt_ids),
},
.probe = lis302dl_spi_probe,
.remove = __devexit_p(lis302dl_spi_remove),
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] lis3: add generic DT matching code
This patch adds logic to parse lis3 properties from a device tree node
and store them in a freshly allocated lis3lv02d_platform_data.
Note that the actual match tables are left out here. This part should
happen in the drivers that bind to the individual busses (SPI/I2C/PCI).
Signed-off-by: Daniel Mack
---
drivers/misc/lis3lv02d/lis3lv02d.c | 145
drivers/misc/lis3lv02d/lis3lv02d.h |4 +
2 files changed, 149 insertions(+)
diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c
b/drivers/misc/lis3lv02d/lis3lv02d.c
index a981e2a..cfa4689 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include "lis3lv02d.h"
#define DRIVER_NAME "lis3lv02d"
@@ -912,6 +913,146 @@ static void lis3lv02d_8b_configure(struct lis3lv02d *lis3,
}
}
+#ifdef CONFIG_OF
+static int lis3lv02d_init_dt(struct lis3lv02d *lis3)
+{
+ struct lis3lv02d_platform_data *pdata;
+ struct device_node *np = lis3->of_node;
+ u32 tmp;
+
+ if (!lis3->of_node)
+ return 0;
+
+ pdata = kzalloc(sizeof(*lis3->pdata), GFP_KERNEL);
+ if (!lis3->pdata)
+ return -ENOMEM;
+
+ if (of_get_property(np, "st,click-single-x", NULL))
+ pdata->click_flags |= LIS3_CLICK_SINGLE_X;
+ if (of_get_property(np, "st,click-double-x", NULL))
+ pdata->click_flags |= LIS3_CLICK_DOUBLE_X;
+
+ if (of_get_property(np, "st,click-single-y", NULL))
+ pdata->click_flags |= LIS3_CLICK_SINGLE_Y;
+ if (of_get_property(np, "st,click-double-y", NULL))
+ pdata->click_flags |= LIS3_CLICK_DOUBLE_Y;
+
+ if (of_get_property(np, "st,click-single-z", NULL))
+ pdata->click_flags |= LIS3_CLICK_SINGLE_Z;
+ if (of_get_property(np, "st,click-double-z", NULL))
+ pdata->click_flags |= LIS3_CLICK_DOUBLE_Z;
+
+ if (!of_property_read_u32(np, "st,click-threshold-x", ))
+ pdata->click_thresh_x = tmp;
+ if (!of_property_read_u32(np, "st,click-threshold-y", ))
+ pdata->click_thresh_y = tmp;
+ if (!of_property_read_u32(np, "st,click-threshold-z", ))
+ pdata->click_thresh_z = tmp;
+
+ if (!of_property_read_u32(np, "st,click-time-limit", ))
+ pdata->click_time_limit = tmp;
+ if (!of_property_read_u32(np, "st,click-latency", ))
+ pdata->click_latency = tmp;
+ if (!of_property_read_u32(np, "st,click-time-limit", ))
+ pdata->click_time_limit = tmp;
+
+ if (of_get_property(np, "st,irq1-disable", NULL))
+ pdata->irq_cfg |= LIS3_IRQ1_DISABLE;
+ if (of_get_property(np, "st,irq1-ff-wu-1", NULL))
+ pdata->irq_cfg |= LIS3_IRQ1_FF_WU_1;
+ if (of_get_property(np, "st,irq1-ff-wu-2", NULL))
+ pdata->irq_cfg |= LIS3_IRQ1_FF_WU_2;
+ if (of_get_property(np, "st,irq1-ff-wu-2", NULL))
+ pdata->irq_cfg |= LIS3_IRQ1_FF_WU_2;
+ if (of_get_property(np, "st,irq1-data-ready", NULL))
+ pdata->irq_cfg |= LIS3_IRQ1_DATA_READY;
+ if (of_get_property(np, "st,irq1-click", NULL))
+ pdata->irq_cfg |= LIS3_IRQ1_CLICK;
+ if (of_get_property(np, "st,irq1-mask", NULL))
+ pdata->irq_cfg |= LIS3_IRQ1_MASK;
+
+ if (of_get_property(np, "st,irq2-disable", NULL))
+ pdata->irq_cfg |= LIS3_IRQ2_DISABLE;
+ if (of_get_property(np, "st,irq2-ff-wu-1", NULL))
+ pdata->irq_cfg |= LIS3_IRQ2_FF_WU_1;
+ if (of_get_property(np, "st,irq2-ff-wu-2", NULL))
+ pdata->irq_cfg |= LIS3_IRQ2_FF_WU_2;
+ if (of_get_property(np, "st,irq2-ff-wu-2", NULL))
+ pdata->irq_cfg |= LIS3_IRQ2_FF_WU_2;
+ if (of_get_property(np, "st,irq2-data-ready", NULL))
+ pdata->irq_cfg |= LIS3_IRQ2_DATA_READY;
+ if (of_get_property(np, "st,irq2-click", NULL))
+ pdata->irq_cfg |= LIS3_IRQ2_CLICK;
+ if (of_get_property(np, "st,irq2-mask", NULL))
+ pdata->irq_cfg |= LIS3_IRQ2_MASK;
+
+ if (of_get_property(np, "st,irq-open-drain", NULL))
+ pdata->irq_cfg |= LIS3_IRQ_OPEN_DRAIN;
+ if (of_get_property(np, "st,irq-active-low", NULL))
+ pdata->irq_cfg |= LIS3_IRQ_ACTIVE_LOW;
+
+ if (!of_property_read_u32(np, "st,duration-1", ))
+ pdata->duration1 = tmp;
+ if (!of_property_read_u32(np, "st,duration-2", ))
+ pdata->duration2 = tmp;
+
+ if (of_get_property(np, "st,wakeup-x-lo", NULL))
+ pdata->wakeup_flags |= LIS3_WAKEUP_X_LO;
+ if (of_get_property(np, "st,wakeup-x-hi", NULL))
+ pdata->wakeup_flags |= LIS3_WAKEUP_X_HI;
+ if (of_get_property(np, "st,wakeup-y-lo", NULL))
+ pdata->wakeup_flags |= LIS3_WAKEUP_Y_LO;
+ if (of_get_property(np,
[PATCH 1/1] x86, MSI: Support multiple MSIs in presense of IRQ remapping
The MSI specification has several constraints in comparison with MSI-X,
most notable of them is the inability to configure MSIs independently.
As a result, it is impossible to dispatch interrupts from different
queues to different CPUs. This is largely devalues the support of
multiple MSIs in SMP systems.
Also, a necessity to allocate a contiguous block of vector numbers for
devices capable of multiple MSIs might cause a considerable pressure on
x86 interrupt vector allocator and could lead to fragmentation of the
interrupt vectors space.
This patch overcomes both drawbacks in presense of IRQ remapping and
lets devices take advantage of multiple queues and per-IRQ affinity
assignments.
Signed-off-by: Alexander Gordeev
---
arch/x86/kernel/apic/io_apic.c | 166 +--
include/linux/irq.h|6 ++
kernel/irq/chip.c | 30 +--
kernel/irq/irqdesc.c | 31
4 files changed, 216 insertions(+), 17 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index a951ef7..f083049 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -305,6 +305,11 @@ static int alloc_irq_from(unsigned int from, int node)
return irq_alloc_desc_from(from, node);
}
+static int alloc_irqs_from(unsigned int from, unsigned int count, int node)
+{
+ return irq_alloc_descs_from(from, count, node);
+}
+
static void free_irq_at(unsigned int at, struct irq_cfg *cfg)
{
free_irq_cfg(at, cfg);
@@ -3030,6 +3035,55 @@ int create_irq(void)
return irq;
}
+unsigned int create_irqs(unsigned int from, unsigned int count, int node)
+{
+ struct irq_cfg **cfg;
+ unsigned long flags;
+ int irq, i;
+
+ if (from < nr_irqs_gsi)
+ from = nr_irqs_gsi;
+
+ cfg = kzalloc_node(count * sizeof(cfg[0]), GFP_KERNEL, node);
+ if (!cfg)
+ return 0;
+
+ irq = alloc_irqs_from(from, count, node);
+ if (irq < 0)
+ goto out_cfgs;
+
+ for (i = 0; i < count; i++) {
+ cfg[i] = alloc_irq_cfg(irq + i, node);
+ if (!cfg[i])
+ goto out_irqs;
+ }
+
+ raw_spin_lock_irqsave(_lock, flags);
+ for (i = 0; i < count; i++)
+ if (__assign_irq_vector(irq + i, cfg[i], apic->target_cpus()))
+ goto out_vecs;
+ raw_spin_unlock_irqrestore(_lock, flags);
+
+ for (i = 0; i < count; i++) {
+ irq_set_chip_data(irq + i, cfg[i]);
+ irq_clear_status_flags(irq + i, IRQ_NOREQUEST);
+ }
+
+ kfree(cfg);
+ return irq;
+
+out_vecs:
+ for (; i; i--)
+ __clear_irq_vector(irq + i - 1, cfg[i - 1]);
+ raw_spin_unlock_irqrestore(_lock, flags);
+out_irqs:
+ for (i = 0; i < count; i++)
+ free_irq_at(irq + i, cfg[i]);
+out_cfgs:
+ kfree(cfg);
+ return 0;
+}
+
void destroy_irq(unsigned int irq)
{
struct irq_cfg *cfg = irq_get_chip_data(irq);
@@ -3045,6 +3099,27 @@ void destroy_irq(unsigned int irq)
free_irq_at(irq, cfg);
}
+static inline void destroy_irqs(unsigned int irq, unsigned int count)
+{
+ unsigned int i;
+ for (i = 0; i < count; i++)
+ destroy_irq(irq + i);
+}
+
+static inline int
+can_create_pow_of_two_irqs(unsigned int from, unsigned int count)
+{
+ if ((count > 1) && (count % 2))
+ return -EINVAL;
+
+ for (; count; count = count / 2) {
+ if (!irq_can_alloc_irqs(from, count))
+ return count;
+ }
+
+ return -ENOSPC;
+}
+
/*
* MSI message composition
*/
@@ -3136,18 +3211,25 @@ static struct irq_chip msi_chip = {
.irq_retrigger = ioapic_retrigger_irq,
};
-static int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc, int
irq)
+static int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
+unsigned int irq_base, unsigned int irq_offset)
{
struct irq_chip *chip = _chip;
struct msi_msg msg;
+ unsigned int irq = irq_base + irq_offset;
int ret;
ret = msi_compose_msg(dev, irq, , -1);
if (ret < 0)
return ret;
- irq_set_msi_desc(irq, msidesc);
- write_msi_msg(irq, );
+ irq_set_msi_desc_off(irq_base, irq_offset, msidesc);
+
+ /* MSI-X message is written per-IRQ, the offset is always 0.
+* MSI message denotes a contiguous group of IRQs, written for 0th IRQ.
+*/
+ if (!irq_offset)
+ write_msi_msg(irq, );
if (irq_remapped(irq_get_chip_data(irq))) {
irq_set_status_flags(irq, IRQ_MOVE_PCNTXT);
@@ -3161,16 +3243,12 @@ static int setup_msi_irq(struct pci_dev *dev, struct
msi_desc *msidesc, int irq)
return 0;
}
-int native_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+int
Re: [PATCH v4 08/12] block: Introduce new bio_split()
On 07/24/2012 11:11 PM, Kent Overstreet wrote:
> The new bio_split() can split arbitrary bios - it's not restricted to
> single page bios, like the old bio_split() (previously renamed to
> bio_pair_split()). It also has different semantics - it doesn't allocate
> a struct bio_pair, leaving it up to the caller to handle completions.
>
> Signed-off-by: Kent Overstreet
> ---
> fs/bio.c | 99
> ++
> 1 files changed, 99 insertions(+), 0 deletions(-)
>
> diff --git a/fs/bio.c b/fs/bio.c
> index 5d02aa5..a15e121 100644
> --- a/fs/bio.c
> +++ b/fs/bio.c
> @@ -1539,6 +1539,105 @@ struct bio_pair *bio_pair_split(struct bio *bi, int
> first_sectors)
> EXPORT_SYMBOL(bio_pair_split);
>
> /**
> + * bio_split - split a bio
> + * @bio: bio to split
> + * @sectors: number of sectors to split from the front of @bio
> + * @gfp: gfp mask
> + * @bs: bio set to allocate from
> + *
> + * Allocates and returns a new bio which represents @sectors from the start
> of
> + * @bio, and updates @bio to represent the remaining sectors.
> + *
> + * If bio_sectors(@bio) was less than or equal to @sectors, returns @bio
> + * unchanged.
> + *
> + * The newly allocated bio will point to @bio's bi_io_vec, if the split was
> on a
> + * bvec boundry; it is the caller's responsibility to ensure that @bio is not
> + * freed before the split.
> + *
> + * If bio_split() is running under generic_make_request(), it's not safe to
> + * allocate more than one bio from the same bio set. Therefore, if it is
> running
> + * under generic_make_request() it masks out __GFP_WAIT when doing the
> + * allocation. The caller must check for failure if there's any possibility
> of
> + * it being called from under generic_make_request(); it is then the caller's
> + * responsibility to retry from a safe context (by e.g. punting to
> workqueue).
> + */
> +struct bio *bio_split(struct bio *bio, int sectors,
> + gfp_t gfp, struct bio_set *bs)
> +{
> + unsigned idx, vcnt = 0, nbytes = sectors << 9;
> + struct bio_vec *bv;
> + struct bio *ret = NULL;
> +
> + BUG_ON(sectors <= 0);
> +
> + /*
> + * If we're being called from underneath generic_make_request() and we
> + * already allocated any bios from this bio set, we risk deadlock if we
> + * use the mempool. So instead, we possibly fail and let the caller punt
> + * to workqueue or somesuch and retry in a safe context.
> + */
> + if (current->bio_list)
> + gfp &= ~__GFP_WAIT;
NACK!
If as you said above in the comment:
if there's any possibility of it being called from under
generic_make_request();
it is then the caller's responsibility to ...
So all the comment needs to say is:
... caller's responsibility to not set __GFP_WAIT at gfp.
And drop this here. It is up to the caller to decide. If the caller wants he
can do
"if (current->bio_list)" by his own.
This is a general purpose utility you might not know it's context.
for example with osdblk above will break.
Thanks
Boaz
> +
> + if (sectors >= bio_sectors(bio))
> + return bio;
> +
> + trace_block_split(bdev_get_queue(bio->bi_bdev), bio,
> + bio->bi_sector + sectors);
> +
> + bio_for_each_segment(bv, bio, idx) {
> + vcnt = idx - bio->bi_idx;
> +
> + if (!nbytes) {
> + ret = bio_alloc_bioset(gfp, 0, bs);
> + if (!ret)
> + return NULL;
> +
> + ret->bi_io_vec = bio_iovec(bio);
> + ret->bi_flags |= 1 << BIO_CLONED;
> + break;
> + } else if (nbytes < bv->bv_len) {
> + ret = bio_alloc_bioset(gfp, ++vcnt, bs);
> + if (!ret)
> + return NULL;
> +
> + memcpy(ret->bi_io_vec, bio_iovec(bio),
> +sizeof(struct bio_vec) * vcnt);
> +
> + ret->bi_io_vec[vcnt - 1].bv_len = nbytes;
> + bv->bv_offset += nbytes;
> + bv->bv_len -= nbytes;
> + break;
> + }
> +
> + nbytes -= bv->bv_len;
> + }
> +
> + ret->bi_bdev= bio->bi_bdev;
> + ret->bi_sector = bio->bi_sector;
> + ret->bi_size= sectors << 9;
> + ret->bi_rw = bio->bi_rw;
> + ret->bi_vcnt= vcnt;
> + ret->bi_max_vecs = vcnt;
> + ret->bi_end_io = bio->bi_end_io;
> + ret->bi_private = bio->bi_private;
> +
> + bio->bi_sector += sectors;
> + bio->bi_size-= sectors << 9;
> + bio->bi_idx = idx;
> +
> + if (bio_integrity(bio)) {
> + bio_integrity_clone(ret, bio, gfp, bs);
> + bio_integrity_trim(ret, 0, bio_sectors(ret));
> + bio_integrity_trim(bio, bio_sectors(ret), bio_sectors(bio));
> + }
Re: [REGRESSION] [KMS] [INTEL] Wrong resolution in console and XWindow
On Wed, Jul 25, 2012 at 12:57 PM, Maciej Rutecki
wrote:
> On środa, 25 lipca 2012 o 11:29:28 Daniel Vetter wrote:
>> On Wed, Jul 25, 2012 at 10:54:25AM +0200, Maciej Rutecki wrote:
>> > On środa, 25 lipca 2012 o 10:29:26 Daniel Vetter wrote:
>> > > On Wed, Jul 25, 2012 at 10:20:47AM +0200, Maciej Rutecki wrote:
>> > > > Last known good: 3.4.4
>> > > > First bad: 3.5.0
>> > > >
>> > > > When booting 3.5.0 resolution (in console, and after in KDE) is set
>> > > > to 1024x768 (60Hz). In 3.4.4 was correct: 1440x900 (60Hz).
>> > >
>> > > Can you please attach the output of xrandr --verbose for both kernels?
>> > > Also, please boot with drm.debug=0xe added to your kernel cmdline and
>> > > grab the dmesg (again for both kernels).
>> >
>> > Thanks for the ansfer.
>> >
>> > Here xrandr and dmesg outputs for 3.4.4 and 3.5.0
>> >
>> > http://mrutecki.pl/download/kernel/3.5/swinka/debug/
>>
>> Can you please test this quick hack:
>>
>>
>> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
>> b/drivers/gpu/drm/i915/intel_i2c.c index 1991a44..abe1611 100644
>> --- a/drivers/gpu/drm/i915/intel_i2c.c
>> +++ b/drivers/gpu/drm/i915/intel_i2c.c
>> @@ -405,7 +405,7 @@ clear_err:
>>* timing out seems to happen when there _is_ a ddc chip present, but
>>* it's slow responding and only answers on the 2nd retry.
>>*/
>> - ret = -ENXIO;
>> + ret = 0;
>> if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0,
>>10)) {
>> DRM_DEBUG_KMS("GMBUS [%s] timed out after NAK\n",
>>
>>
>> Thanks, Daniel
>
> Still the same.
Hm, can you attach the dmesg again (with drm.debug=0xe)? If I haven't
botched up something, we should now retry at least the ddc transfer
...
-Daniel
>
> PS. Unfortunately, this afternoon I have small a surgical operation and
> further tests will be possible only after 2-3 days.
>
> Regards
> --
> Maciej Rutecki
> http://www.mrutecki.pl
--
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 PATCH 6/6] CPU hotplug: Invoke CPU offline notifiers in reverse order
During CPU hotplug, we want to create the following effect:
* During CPU online, the CPU incrementally grows the number of services
it offers.
* During CPU offline, the services are incrementally retired, in the
reverse order of their growth during CPU online.
To achieve the above, invoke the registered CPU hotplug notifiers in the
reverse order during CPU offline, with respect to the order in which they
were invoked during CPU online.
This approach helps in making the hotplug path a lot more logically
coherent: Services are started in a well-known order, perhaps with dependencies
between them, while bringing up a CPU. While offlining the CPU, we honor
many of the dependencies automatically by just backtracking the way we came;
that is, by invoking the notifiers in the reverse order. Thus, this model of
reverse notifier invocation helps us in avoiding the need for excessively
messing with the notifier priorities while trying to get the ordering right.
Notes:
1. The workqueue code becomes simpler, since it now needs just a single CPU
hotplug callback.
2. The scheduler's sched_cpu_[in]active() callbacks can also be merged into
a single callback.
3. On similar lines, the cpusets' cpuset_cpu_[in]active() callbacks can also
be merged.
Signed-off-by: Srivatsa S. Bhat
---
include/linux/cpu.h | 37 -
kernel/cpu.c| 34 ++
kernel/sched/core.c | 48 ++--
kernel/workqueue.c | 30 +++---
4 files changed, 75 insertions(+), 74 deletions(-)
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 88de47d..b27a046 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -55,26 +55,37 @@ extern ssize_t arch_print_cpu_modalias(struct device *dev,
*/
enum {
/*
-* SCHED_ACTIVE marks a cpu which is coming up active during CPU_ONLINE
-* and CPU_DOWN_FAILED and must be the first notifier. It then passes
-* control to the cpuset_cpu_active() notifier which adjusts cpusets
-* according to cpu_active mask. During CPU_DOWN_PREPARE, SCHED_INACTIVE
-* marks the cpu as inactive and passes control to the
-* cpuset_cpu_inactive() notifier in a similar way.
+* sched_cpu_notify() marks a cpu which is coming up active during
+* CPU_ONLINE and CPU_DOWN_FAILED and must be the first notifier. It
+* then passes control to the cpuset_cpu_active() notifier which adjusts
+* cpusets according to cpu_active mask. During CPU_DOWN_PREPARE,
+* sched_cpu_notify() marks the cpu as inactive and passes control to
+* the cpuset_cpu_inactive() notifier in a similar way.
*
* This ordering guarantees consistent cpu_active mask and
* migration behavior to all cpu notifiers.
*/
- CPU_PRI_SCHED_ACTIVE= INT_MAX,
- CPU_PRI_SCHED_INACTIVE = INT_MIN,
+ CPU_PRI_SCHED = INT_MAX,
- /* migration should happen before other stuff but after perf */
+ /*
+* Migration should happen before other stuff but after perf,
+* in the CPU online path.
+*/
CPU_PRI_PERF= 20,
CPU_PRI_MIGRATION_UP= 10,
- CPU_PRI_MIGRATION_DOWN = 9,
- /* bring up workqueues before normal notifiers and down after */
- CPU_PRI_WORKQUEUE_UP= 5,
- CPU_PRI_WORKQUEUE_DOWN = -5,
+
+ /*
+* Bring up workqueues before normal notifiers in the CPU online
+* path. Do the opposite in the CPU offline path.
+*/
+ CPU_PRI_WORKQUEUE = 5,
+
+ /*
+* In the CPU offline path, the notifiers are invoked in the reverse
+* order. So use a numerically low value for the priority, to ensure
+* that we get invoked early.
+*/
+ CPU_PRI_MIGRATION_DOWN = -10,
};
#define CPU_ONLINE 0x0002 /* CPU (unsigned)v is up */
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 8ab33ae..30444c2 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -155,16 +155,32 @@ static int __cpu_notify(unsigned long val, void *v, int
nr_to_call,
return notifier_to_errno(ret);
}
+static int __cpu_notify_reverse(unsigned long val, void *v, int nr_to_call,
+ int *nr_calls)
+{
+ int ret;
+
+ ret = __raw_notifier_call_chain_reverse(_chain, val, v,
+ nr_to_call, nr_calls);
+
+ return notifier_to_errno(ret);
+}
+
static int cpu_notify(unsigned long val, void *v)
{
return __cpu_notify(val, v, -1, NULL);
}
+static int cpu_notify_reverse(unsigned long val, void *v)
+{
+ return __cpu_notify_reverse(val, v, -1, NULL);
+}
+
#ifdef CONFIG_HOTPLUG_CPU
-static void cpu_notify_nofail(unsigned long val, void *v)
+static void cpu_notify_reverse_nofail(unsigned long val, void *v)
{
- BUG_ON(cpu_notify(val, v));
+
[RFC PATCH 5/6] sched, perf: Prepare migration and perf CPU hotplug callbacks for reverse invocation
While dealing with reverse invocation of callbacks during CPU offline, we
get an opportunity to revisit some of the reasons behind the existing callback
invocation orders and how they would fit into the new reverse invocation model
(which poses its own constraints and challenges).
It is documented that the perf and migration CPU hotplug callbacks must be
run pretty early (ie., before the normal callbacks that have priority 0 and
lower)... and also that the perf callbacks must be run before the migration
one. Again, at first glance, it looks like the "Notifier A must be followed
by B, always, in both cpu online and cpu offline paths" rule. However, looking
a bit closely at the code, it appears that this requirement is true mainly for
the CPU online path, and not for the CPU offline path.
In the CPU offline path, some of the perf callbacks deal with low-level
registers, whereas the migration callback deals with the scheduler runqueues
and stuff, which look quite unrelated. Also, there are quite a few priority 0
callbacks that deal with low-level arch-specific-cpu-disable stuff in the
CPU down path.
All in all, it appears that the requirement can be restated as follows:
CPU online path:
Run the perf callbacks early, followed by the migration callback and later
run the priority 0 and other callbacks as usual.
CPU offline path:
Run the migration callback early, followed by the priority 0 callbacks and
later run the perf callbacks.
Keeping this in mind, adjust the perf and migration callbacks in preparation
for moving over to the reverse invocation model. That is, split up the
migration callback into CPU online and CPU offline components and assign
suitable priorities to them. This split would help us move over to the
reverse invocation model easily, since we would now have the necessary control
over both the paths (online and offline) to handle the ordering requirements
correctly.
Signed-off-by: Srivatsa S. Bhat
---
include/linux/cpu.h |3 ++-
kernel/sched/core.c | 55 ---
2 files changed, 45 insertions(+), 13 deletions(-)
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 255b889..88de47d 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -70,7 +70,8 @@ enum {
/* migration should happen before other stuff but after perf */
CPU_PRI_PERF= 20,
- CPU_PRI_MIGRATION = 10,
+ CPU_PRI_MIGRATION_UP= 10,
+ CPU_PRI_MIGRATION_DOWN = 9,
/* bring up workqueues before normal notifiers and down after */
CPU_PRI_WORKQUEUE_UP= 5,
CPU_PRI_WORKQUEUE_DOWN = -5,
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 9ccebdd..6a511f2 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5444,12 +5444,10 @@ static void set_rq_offline(struct rq *rq)
}
}
-/*
- * migration_call - callback that gets triggered when a CPU is added.
- * Here we can start up the necessary migration thread for the new CPU.
- */
+/* cpu_up_migration_call - callback that gets triggered when a CPU is added. */
static int __cpuinit
-migration_call(struct notifier_block *nfb, unsigned long action, void *hcpu)
+cpu_up_migration_call(struct notifier_block *nfb, unsigned long action,
+ void *hcpu)
{
int cpu = (long)hcpu;
unsigned long flags;
@@ -5471,6 +5469,36 @@ migration_call(struct notifier_block *nfb, unsigned long
action, void *hcpu)
}
raw_spin_unlock_irqrestore(>lock, flags);
break;
+ }
+
+ update_max_interval();
+
+ return NOTIFY_OK;
+}
+
+/*
+ * Register at high priority so that task migration (migrate_tasks)
+ * happens before everything else. This has to be lower priority than
+ * the notifier in the perf_event subsystem, though.
+ */
+static struct notifier_block __cpuinitdata cpu_up_migration_notifier = {
+ .notifier_call = cpu_up_migration_call,
+ .priority = CPU_PRI_MIGRATION_UP,
+};
+
+/*
+ * cpu_down_migration_call - callback that gets triggered when a CPU is
+ * removed.
+ */
+static int __cpuinit
+cpu_down_migration_call(struct notifier_block *nfb, unsigned long action,
+ void *hcpu)
+{
+ int cpu = (long)hcpu;
+ unsigned long flags;
+ struct rq *rq = cpu_rq(cpu);
+
+ switch (action & ~CPU_TASKS_FROZEN) {
#ifdef CONFIG_HOTPLUG_CPU
case CPU_DYING:
@@ -5497,13 +5525,13 @@ migration_call(struct notifier_block *nfb, unsigned
long action, void *hcpu)
}
/*
- * Register at high priority so that task migration (migrate_all_tasks)
+ * Register at high priority so that task migration (migrate_tasks)
* happens before everything else. This has to be lower priority than
* the notifier in the perf_event subsystem, though.
*/
-static struct notifier_block __cpuinitdata migration_notifier = {
-
[RFC PATCH 4/6] sched, cpuset: Prepare scheduler and cpuset CPU hotplug callbacks for reverse invocation
Some of the CPU hotplug callbacks of the scheduler and cpuset infrastructure are
intertwined in an interesting way. The scheduler's sched_cpu_[in]active()
callbacks and cpuset's cpuset_cpu_[in]active() callbacks have the following
documented dependency:
The sched_cpu_active() callback must be the first callback to run, and
should be immediately followed by cpuset_cpu_active() to update the
cpusets and the sched domains. This ordering (sched followed by cpuset)
needs to be honored in both the CPU online *and* the CPU offline paths.
Hence its not straightforward to convert these callbacks to the reverse
invocation model, because, a plain conversion would result in the problem
explained below.
In general, if 2 notifiers A and B expect to be -always- called in the order
A followed by B, ie., during both CPU online and CPU offline, then we can't
ensure that easily because, when we do reverse invocation, we get the
following call path:
Event| Invocation order
-|-
CPU online: | A (high priority), B (low priority)
CPU offline: | B (low priority), A (high priority)
So this breaks the requirement for A and B. We see this ordering requirement
in the case of the scheduler and cpusets.
So, to solve this, club the 2 callbacks together as a unit, so that they
are always invoked as a unit, which means, forward or reverse, the requirement
is satisfied. In this case, since the 2 callbacks are quite related, it
doesn't break semantics/readability if we club them together, which is a good
thing!
There is a one more aspect that we need to take care of while clubbing the two
callbacks. During boot, the scheduler is initialized in two phases:
sched_init(), which happens before SMP initialization (and hence *before* the
non-boot CPUs are booted up), and sched_init_smp(), which happens after SMP
initialization (and hence *after* the non-boot CPUs are booted).
In the original code, the cpuset callbacks are registered during
sched_init_smp(), which means that while starting the non-boot CPUs, only the
scheduler callbacks are invoked, not the cpuset ones. So in order to keep
this intact even after clubbing the 2 callbacks, we need to be able to find out
if we are running post-SMP init or if we are running pre-SMP early boot code,
to decide whether to pass on control to the cpuset callback or not. So introduce
a flag 'sched_smp_init_complete' that gets set after the scheduler is
initialized for SMP. This would help us in making that decision.
Signed-off-by: Srivatsa S. Bhat
---
include/linux/cpu.h | 16 -
kernel/sched/core.c | 89 ++-
2 files changed, 59 insertions(+), 46 deletions(-)
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index ce7a074..255b889 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -55,20 +55,18 @@ extern ssize_t arch_print_cpu_modalias(struct device *dev,
*/
enum {
/*
-* SCHED_ACTIVE marks a cpu which is coming up active during
-* CPU_ONLINE and CPU_DOWN_FAILED and must be the first
-* notifier. CPUSET_ACTIVE adjusts cpuset according to
-* cpu_active mask right after SCHED_ACTIVE. During
-* CPU_DOWN_PREPARE, SCHED_INACTIVE and CPUSET_INACTIVE are
-* ordered in the similar way.
+* SCHED_ACTIVE marks a cpu which is coming up active during CPU_ONLINE
+* and CPU_DOWN_FAILED and must be the first notifier. It then passes
+* control to the cpuset_cpu_active() notifier which adjusts cpusets
+* according to cpu_active mask. During CPU_DOWN_PREPARE, SCHED_INACTIVE
+* marks the cpu as inactive and passes control to the
+* cpuset_cpu_inactive() notifier in a similar way.
*
* This ordering guarantees consistent cpu_active mask and
* migration behavior to all cpu notifiers.
*/
CPU_PRI_SCHED_ACTIVE= INT_MAX,
- CPU_PRI_CPUSET_ACTIVE = INT_MAX - 1,
- CPU_PRI_SCHED_INACTIVE = INT_MIN + 1,
- CPU_PRI_CPUSET_INACTIVE = INT_MIN,
+ CPU_PRI_SCHED_INACTIVE = INT_MIN,
/* migration should happen before other stuff but after perf */
CPU_PRI_PERF= 20,
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index d5594a4..9ccebdd 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -280,6 +280,7 @@ const_debug unsigned int sysctl_sched_time_avg =
MSEC_PER_SEC;
unsigned int sysctl_sched_rt_period = 100;
__read_mostly int scheduler_running;
+static bool __read_mostly sched_smp_init_complete;
/*
* part of the period that we allow rt tasks to run in us.
@@ -5505,29 +5506,75 @@ static struct notifier_block __cpuinitdata
migration_notifier = {
.priority = CPU_PRI_MIGRATION,
};
+/*
+ * Update cpusets according to cpu_active mask. If cpusets are
+ * disabled, cpuset_update_active_cpus() becomes a simple wrapper
+ * around partition_sched_domains().
+ */
+static int
[RFC PATCH 3/6] notifiers: Add support for reverse invocation of notifier chains
In certain scenarios, it is useful to be able to invoke notifiers in the
reverse order. One such example is CPU hotplug, where we would like to
invoke the notifiers in one order during CPU online and in the reverse
order during CPU offline. So add support for reverse invocation of
notifier chains.
Signed-off-by: Srivatsa S. Bhat
---
include/linux/notifier.h |4 ++
kernel/notifier.c| 82 ++
2 files changed, 86 insertions(+), 0 deletions(-)
diff --git a/include/linux/notifier.h b/include/linux/notifier.h
index 67f9a3a..4626d17 100644
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -145,8 +145,12 @@ extern int __blocking_notifier_call_chain(struct
blocking_notifier_head *nh,
unsigned long val, void *v, int nr_to_call, int *nr_calls);
extern int raw_notifier_call_chain(struct raw_notifier_head *nh,
unsigned long val, void *v);
+extern int raw_notifier_call_chain_reverse(struct raw_notifier_head *nh,
+ unsigned long val, void *v);
extern int __raw_notifier_call_chain(struct raw_notifier_head *nh,
unsigned long val, void *v, int nr_to_call, int *nr_calls);
+extern int __raw_notifier_call_chain_reverse(struct raw_notifier_head *nh,
+ unsigned long val, void *v, int nr_to_call, int *nr_calls);
extern int srcu_notifier_call_chain(struct srcu_notifier_head *nh,
unsigned long val, void *v);
extern int __srcu_notifier_call_chain(struct srcu_notifier_head *nh,
diff --git a/kernel/notifier.c b/kernel/notifier.c
index ad6feab..536f32c 100644
--- a/kernel/notifier.c
+++ b/kernel/notifier.c
@@ -105,6 +105,50 @@ static int __kprobes notifier_call_chain(struct list_head
*nl,
return ret;
}
+/**
+ * notifier_call_chain_reverse - Informs the registered notifiers about an
+ * event, by invoking the notifiers in the reverse order.
+ *
+ * @nl:Pointer to head of the blocking notifier chain
+ * @val: Value passed unmodified to notifier function
+ * @v: Pointer passed unmodified to notifier function
+ * @nr_to_call:Number of notifier functions to be called. Don't care
+ * value of this parameter is -1.
+ * @nr_calls: Records the number of notifications sent. Don't care
+ * value of this field is NULL.
+ * @returns: notifier_call_chain_reverse returns the value returned
+ * by the last notifier function called.
+ */
+static int __kprobes notifier_call_chain_reverse(struct list_head *nl,
+ unsigned long val, void *v,
+ int nr_to_call, int *nr_calls)
+{
+ int ret = NOTIFY_DONE;
+ struct notifier_block *nb;
+
+ list_for_each_entry_reverse_rcu(nb, nl, list) {
+ if (!nr_to_call)
+ break;
+
+#ifdef CONFIG_DEBUG_NOTIFIERS
+ if (unlikely(!func_ptr_is_kernel_text(nb->notifier_call))) {
+ WARN(1, "Invalid notifier called!");
+ continue;
+ }
+#endif
+ ret = nb->notifier_call(nb, val, v);
+
+ if (nr_calls)
+ (*nr_calls)++;
+
+ if ((ret & NOTIFY_STOP_MASK) == NOTIFY_STOP_MASK)
+ break;
+ nr_to_call--;
+ }
+
+ return ret;
+}
+
/*
* Atomic notifier chain routines. Registration and unregistration
* use a spinlock, and call_chain is synchronized by RCU (no locks).
@@ -402,6 +446,44 @@ int raw_notifier_call_chain(struct raw_notifier_head *nh,
}
EXPORT_SYMBOL_GPL(raw_notifier_call_chain);
+
+/**
+ * __raw_notifier_call_chain_reverse - Call functions in a raw notifier
+ * chain in the reverse order
+ *
+ * @nh: Pointer to head of the raw notifier chain
+ * @val: Value passed unmodified to notifier function
+ * @v: Pointer passed unmodified to notifier function
+ * @nr_to_call: See comment for notifier_call_chain_reverse.
+ * @nr_calls: See comment for notifier_call_chain_reverse
+ *
+ * Calls each function in a notifier chain in turn, in the reverse order.
+ * The functions run in an undefined context.
+ * All locking must be provided by the caller.
+ *
+ * If the return value of the notifier can be and'ed
+ * with %NOTIFY_STOP_MASK then __raw_notifier_call_chain_reverse()
+ * will return immediately, with the return value of
+ * the notifier function which halted execution.
+ * Otherwise the return value is the return value
+ * of the last notifier function called.
+ */
+int __raw_notifier_call_chain_reverse(struct raw_notifier_head *nh,
+ unsigned long val, void *v,
+ int nr_to_call, int *nr_calls)
+{
+ return notifier_call_chain_reverse(>list, val, v,
+
[RFC PATCH 2/6] notifiers: Convert notifier chain to circular doubly linked-list
In order to support invoking the notifiers in the reverse order, we need to
be able to traverse the callback chain in both directions. So convert the
notifier list into a circular doubly linked list.
Signed-off-by: Srivatsa S. Bhat
---
arch/mips/powertv/powertv_setup.c|2
arch/um/drivers/mconsole_kern.c |2
arch/um/kernel/um_arch.c |2
drivers/acpi/sleep.c |2
drivers/char/ipmi/ipmi_msghandler.c |2
drivers/char/ipmi/ipmi_watchdog.c|4 -
drivers/firmware/dcdbas.c|2
drivers/md/md.c |2
drivers/net/ethernet/intel/igb/igb_main.c|2
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c|2
drivers/net/ethernet/myricom/myri10ge/myri10ge.c |2
drivers/staging/vt6655/device_main.c |2
include/linux/notifier.h | 23 +++--
kernel/debug/debug_core.c|2
kernel/notifier.c| 99 +++---
kernel/trace/trace.c |2
mm/page-writeback.c |2
mm/vmstat.c |4 -
18 files changed, 81 insertions(+), 77 deletions(-)
diff --git a/arch/mips/powertv/powertv_setup.c
b/arch/mips/powertv/powertv_setup.c
index 3933c37..bade798 100644
--- a/arch/mips/powertv/powertv_setup.c
+++ b/arch/mips/powertv/powertv_setup.c
@@ -87,7 +87,7 @@ static void register_panic_notifier()
{
static struct notifier_block panic_notifier = {
.notifier_call = panic_handler,
- .next = NULL,
+ .list = LIST_HEAD_INIT(panic_notifier.list),
.priority = INT_MAX
};
atomic_notifier_chain_register(_notifier_list, _notifier);
diff --git a/arch/um/drivers/mconsole_kern.c b/arch/um/drivers/mconsole_kern.c
index 88e466b..dea89210 100644
--- a/arch/um/drivers/mconsole_kern.c
+++ b/arch/um/drivers/mconsole_kern.c
@@ -898,7 +898,7 @@ static int notify_panic(struct notifier_block *self,
unsigned long unused1,
static struct notifier_block panic_exit_notifier = {
.notifier_call = notify_panic,
- .next = NULL,
+ .list = LIST_HEAD_INIT(panic_exit_notifier.list),
.priority = 1
};
diff --git a/arch/um/kernel/um_arch.c b/arch/um/kernel/um_arch.c
index 4db8770..fdd2b78 100644
--- a/arch/um/kernel/um_arch.c
+++ b/arch/um/kernel/um_arch.c
@@ -243,7 +243,7 @@ static int panic_exit(struct notifier_block *self, unsigned
long unused1,
static struct notifier_block panic_exit_notifier = {
.notifier_call = panic_exit,
- .next = NULL,
+ .list = LIST_HEAD_INIT(panic_exit_notifier.list),
.priority = 0
};
diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index 8856102..2fa6147 100644
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -85,7 +85,7 @@ static int tts_notify_reboot(struct notifier_block *this,
static struct notifier_block tts_notifier = {
.notifier_call = tts_notify_reboot,
- .next = NULL,
+ .list = LIST_HEAD_INIT(tts_notifier.list),
.priority = 0,
};
diff --git a/drivers/char/ipmi/ipmi_msghandler.c
b/drivers/char/ipmi/ipmi_msghandler.c
index 2c29942..5a49739 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -4473,7 +4473,7 @@ static int panic_event(struct notifier_block *this,
static struct notifier_block panic_block = {
.notifier_call = panic_event,
- .next = NULL,
+ .list = LIST_HEAD_INIT(panic_block.list),
.priority = 200 /* priority: INT_MAX >= x >= 0 */
};
diff --git a/drivers/char/ipmi/ipmi_watchdog.c
b/drivers/char/ipmi/ipmi_watchdog.c
index 7ed356e..e340cc2 100644
--- a/drivers/char/ipmi/ipmi_watchdog.c
+++ b/drivers/char/ipmi/ipmi_watchdog.c
@@ -1183,7 +1183,7 @@ static int wdog_reboot_handler(struct notifier_block
*this,
static struct notifier_block wdog_reboot_notifier = {
.notifier_call = wdog_reboot_handler,
- .next = NULL,
+ .list = LIST_HEAD_INIT(wdog_reboot_notifier.list),
.priority = 0
};
@@ -1212,7 +1212,7 @@ static int wdog_panic_handler(struct notifier_block *this,
static struct notifier_block wdog_panic_notifier = {
.notifier_call = wdog_panic_handler,
- .next = NULL,
+ .list = LIST_HEAD_INIT(wdog_panic_notifier.list),
.priority = 150 /* priority: INT_MAX >= x >= 0 */
};
diff --git a/drivers/firmware/dcdbas.c b/drivers/firmware/dcdbas.c
index ea5ac2d..fcd2334 100644
--- a/drivers/firmware/dcdbas.c
+++ b/drivers/firmware/dcdbas.c
@@ -505,7
[PATCH] dma: mxs_dma: Add the missing entries for mx6
From: Fabio Estevam
Add the missing entries for mx6.
Signed-off-by: Fabio Estevam
---
Build tested only, as I currently do not have mx6 board handy.
drivers/dma/mxs-dma.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
index 7f41b25..6e8509b 100644
--- a/drivers/dma/mxs-dma.c
+++ b/drivers/dma/mxs-dma.c
@@ -128,6 +128,7 @@ enum mxs_dma_devtype {
enum mxs_dma_id {
IMX23_DMA,
IMX28_DMA,
+ IMX6Q_DMA,
};
struct mxs_dma_engine {
@@ -158,7 +159,10 @@ static struct mxs_dma_type mxs_dma_types[] = {
}, {
.id = IMX28_DMA,
.type = MXS_DMA_APBX,
- }
+ }, {
+ .id = IMX6Q_DMA,
+ .type = MXS_DMA_APBH,
+ },
};
static struct platform_device_id mxs_dma_ids[] = {
@@ -175,6 +179,8 @@ static struct platform_device_id mxs_dma_ids[] = {
.name = "imx28-dma-apbx",
.driver_data = (kernel_ulong_t) _dma_types[3],
}, {
+ .name = "imx6q-dma-apbh",
+ .driver_data = (kernel_ulong_t) _dma_types[4],
/* end of list */
}
};
@@ -184,6 +190,7 @@ static const struct of_device_id mxs_dma_dt_ids[] = {
{ .compatible = "fsl,imx23-dma-apbx", .data = _dma_ids[1], },
{ .compatible = "fsl,imx28-dma-apbh", .data = _dma_ids[2], },
{ .compatible = "fsl,imx28-dma-apbx", .data = _dma_ids[3], },
+ { .compatible = "fsl,imx6q-dma-apbh", .data = _dma_ids[4], },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mxs_dma_dt_ids);
--
1.7.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/
[RFC PATCH 0/6] CPU hotplug: Reverse invocation of notifiers during CPU hotplug
Hi, This patchset implements the approach of invoking the CPU hotplug callbacks (notifiers) in one order during CPU online and in the reverse order during CPU offline. The rationale behind this is that services for a CPU are started in a particular order (perhaps, with implicit dependencies between them) while bringing up the CPU, and hence, it makes sense to tear down the services in the opposite order, thereby honoring most of the dependencies automatically (and also correctly). This is explained in more detail in Patch 6. Patch 1 adds rcu primitives for traversing a linked list in reverse order. Patch 2 converts the notifiers to a circular doubly linked list (in preparation for the reverse invocation support). Patch 3 adds helpers to invoke notifiers in the reverse order. Patches 4 and 5 do the necessary prep work for moving over to the reverse invocation model, by adjusting some of the callbacks/priorities as necessary. Patch 6 does the final transition and invokes the notifiers in the reverse order during CPU offline. This patchset applies on top of: 1. Tejun's workqueue CPU hotplug patchset[1] merged with 2. Thomas Gleixner's park/unpark patchset with Paul McKenney's fixes which are available at [2]. References: [1]. git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git review-wq-hotplug [2]. git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/smp/hotplug -- Srivatsa S. Bhat (6): list, rcu: Introduce rcu version of reverse list traversal notifiers: Convert notifier chain to circular doubly linked-list notifiers: Add support for reverse invocation of notifier chains sched, cpuset: Prepare scheduler and cpuset CPU hotplug callbacks for reverse invocation sched, perf: Prepare migration and perf CPU hotplug callbacks for reverse invocation CPU hotplug: Invoke CPU offline notifiers in reverse order arch/mips/powertv/powertv_setup.c|2 arch/um/drivers/mconsole_kern.c |2 arch/um/kernel/um_arch.c |2 drivers/acpi/sleep.c |2 drivers/char/ipmi/ipmi_msghandler.c |2 drivers/char/ipmi/ipmi_watchdog.c|4 drivers/firmware/dcdbas.c|2 drivers/md/md.c |2 drivers/net/ethernet/intel/igb/igb_main.c|2 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c|2 drivers/net/ethernet/myricom/myri10ge/myri10ge.c |2 drivers/staging/vt6655/device_main.c |2 include/linux/cpu.h | 40 +++-- include/linux/notifier.h | 27 ++- include/linux/rculist.h | 46 ++ kernel/cpu.c | 34 +++- kernel/debug/debug_core.c|2 kernel/notifier.c| 179 -- kernel/sched/core.c | 140 ++--- kernel/trace/trace.c |2 kernel/workqueue.c | 30 +--- mm/page-writeback.c |2 mm/vmstat.c |4 23 files changed, 357 insertions(+), 175 deletions(-) Thanks, Srivatsa S. Bhat IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 1/6] list, rcu: Introduce rcu version of reverse list traversal
Provide a helper to traverse an RCU-protected doubly linked list in the reverse
order. Also add a corresponding helper to delete entries from the linked list,
which takes care to see that we don't poison either of the pointers (->prev
and ->next), since it is legal to run an rcu list-traversal operation (in
either forward/reverse direction) concurrently.
Signed-off-by: Srivatsa S. Bhat
---
include/linux/rculist.h | 46 ++
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/include/linux/rculist.h b/include/linux/rculist.h
index e0f0fab..6f22a13 100644
--- a/include/linux/rculist.h
+++ b/include/linux/rculist.h
@@ -118,6 +118,36 @@ static inline void list_del_rcu(struct list_head *entry)
}
/**
+ * list_del_bidir_rcu - deletes entry from list without re-initialization.
+ * Useful when one wants to perform bidirectional traversal of the list.
+ *
+ * @entry: the element to delete from the list.
+ *
+ * Note: list_empty() on entry does not return true after this,
+ * the entry is in an undefined state. It is useful for RCU based
+ * lockfree traversal.
+ *
+ * In particular, since we should be able to traverse this list in both
+ * directions, it means that we can not poison either of the pointers
+ * (->prev and ->next) because they may still be used for walking the list.
+ *
+ * The caller must take whatever precautions are necessary (such as holding
+ * appropriate locks) to avoid racing with another list-mutation primitive,
+ * such as list_del_bidir_rcu() or list_add_rcu(), running on this same list.
+ * However, it is perfectly legal to run concurrently with the _rcu
+ * list-traversal primitives, such as list_for_each_entry_rcu() or
+ * list_for_each_entry_reverse_rcu().
+ *
+ * Note that the caller is not permitted to immediately free the newly deleted
+ * entry. Instead, either synchronize_rcu() or call_rcu() must be used to
+ * defer freeing until an RCU grace period has elapsed.
+ */
+static inline void list_del_bidir_rcu(struct list_head *entry)
+{
+ __list_del_entry(entry);
+}
+
+/**
* hlist_del_init_rcu - deletes entry from hash list with re-initialization
* @n: the element to delete from the hash list.
*
@@ -286,6 +316,22 @@ static inline void list_splice_init_rcu(struct list_head
*list,
>member != (head); \
pos = list_entry_rcu(pos->member.next, typeof(*pos), member))
+/**
+ * list_for_each_entry_reverse_rcu - iterate backwards over rcu list of given
+ * type
+ *
+ * @pos: the type * to use as a loop cursor.
+ * @head: the head for your list.
+ * @member:the name of the list_struct within the struct.
+ *
+ * This list-traversal primitive may safely run concurrently with
+ * the _rcu list-mutation primitives such as list_add_rcu()
+ * as long as the traversal is guarded by rcu_read_lock().
+ */
+#define list_for_each_entry_reverse_rcu(pos, head, member) \
+ for (pos = list_entry_rcu((head)->prev, typeof(*pos), member); \
+ >member != (head); \
+ pos = list_entry_rcu(pos->member.prev, typeof(*pos), member))
/**
* list_for_each_continue_rcu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
