* Re: [PATCH 1/6] mm: khugepaged: fix radix tree node leak in shmem collapse error path
From: Johannes Weiner @ 2016-11-14 15:52 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Jan Kara, Andrew Morton, Linus Torvalds, linux-mm, linux-kernel,
kernel-team
In-Reply-To: <20161114142902.GA10455@node.shutemov.name>
On Mon, Nov 14, 2016 at 05:29:02PM +0300, Kirill A. Shutemov wrote:
> On Mon, Nov 14, 2016 at 09:07:44AM +0100, Jan Kara wrote:
> > On Fri 11-11-16 19:37:53, Kirill A. Shutemov wrote:
> > > On Fri, Nov 11, 2016 at 01:22:24PM +0100, Jan Kara wrote:
> > > > On Fri 11-11-16 13:59:21, Kirill A. Shutemov wrote:
> > > > > On Tue, Nov 08, 2016 at 11:12:45AM -0500, Johannes Weiner wrote:
> > > > > > On Tue, Nov 08, 2016 at 10:53:52AM +0100, Jan Kara wrote:
> > > > > > > On Mon 07-11-16 14:07:36, Johannes Weiner wrote:
> > > > > > > > The radix tree counts valid entries in each tree node. Entries stored
> > > > > > > > in the tree cannot be removed by simpling storing NULL in the slot or
> > > > > > > > the internal counters will be off and the node never gets freed again.
> > > > > > > >
> > > > > > > > When collapsing a shmem page fails, restore the holes that were filled
> > > > > > > > with radix_tree_insert() with a proper radix tree deletion.
> > > > > > > >
> > > > > > > > Fixes: f3f0e1d2150b ("khugepaged: add support of collapse for tmpfs/shmem pages")
> > > > > > > > Reported-by: Jan Kara <jack@suse.cz>
> > > > > > > > Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> > > > > > > > ---
> > > > > > > > mm/khugepaged.c | 3 ++-
> > > > > > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > > > > > > > index 728d7790dc2d..eac6f0580e26 100644
> > > > > > > > --- a/mm/khugepaged.c
> > > > > > > > +++ b/mm/khugepaged.c
> > > > > > > > @@ -1520,7 +1520,8 @@ static void collapse_shmem(struct mm_struct *mm,
> > > > > > > > if (!nr_none)
> > > > > > > > break;
> > > > > > > > /* Put holes back where they were */
> > > > > > > > - radix_tree_replace_slot(slot, NULL);
> > > > > > > > + radix_tree_delete(&mapping->page_tree,
> > > > > > > > + iter.index);
> > > > > > >
> > > > > > > Hum, but this is inside radix_tree_for_each_slot() iteration. And
> > > > > > > radix_tree_delete() may end up freeing nodes resulting in invalidating
> > > > > > > current slot pointer and the iteration code will do use-after-free.
> > > > > >
> > > > > > Good point, we need to do another tree lookup after the deletion.
> > > > > >
> > > > > > But there are other instances in the code, where we drop the lock
> > > > > > temporarily and somebody else could delete the node from under us.
> > > > > >
> > > > > > In the main collapse path, I *think* this is prevented by the fact
> > > > > > that when we drop the tree lock we still hold the page lock of the
> > > > > > regular page that's in the tree while we isolate and unmap it, thus
> > > > > > pin the node. Even so, it would seem a little hairy to rely on that.
> > > > > >
> > > > > > Kirill?
> > > > >
> > > > > [ sorry for delay ]
> > > > >
> > > > > Yes, we make sure that locked page still belong to the radix tree and fall
> > > > > off if it's not. Locked page cannot be removed from radix-tree, so we
> > > > > should be fine.
> > > >
> > > > Well, it cannot be removed from the radix tree but radix tree code is still
> > > > free to collapse / expand the tree nodes as it sees fit (currently the only
> > > > real case is when changing direct page pointer in the tree root to a node
> > > > pointer or vice versa but still...). So code should not really assume that
> > > > the node page is referenced from does not change once tree_lock is dropped.
> > > > It leads to subtle bugs...
> > >
> > > Hm. Okay.
> > >
> > > What is the right way re-validate that slot is still valid? Do I need full
> > > look up again? Can I pin node explicitly?
> >
> > Full lookup is the only way to re-validate the slot. There is no way to pin
> > a radix tree node.
>
> I guess this should be enough:
>
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index 728d7790dc2d..c5ef73588676 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -1400,7 +1400,9 @@ static void collapse_shmem(struct mm_struct *mm,
> PAGE_SIZE, 0);
>
> spin_lock_irq(&mapping->tree_lock);
> -
> + slot = radix_tree_lookup_slot(&mapping->page_tree, index);
> + VM_BUG_ON_PAGE(page != radix_tree_deref_slot_protected(slot,
> + &mapping->tree_lock), page);
> VM_BUG_ON_PAGE(page_mapped(page), page);
That looks good to me. The slot may get relocated, but the content
shouldn't change with the page locked.
Are you going to send a full patch with changelog and sign-off? If so,
please add:
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
^ permalink raw reply
* Re: [PATCH 1/6] mm: khugepaged: fix radix tree node leak in shmem collapse error path
From: Johannes Weiner @ 2016-11-14 15:52 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Jan Kara, Andrew Morton, Linus Torvalds, linux-mm, linux-kernel,
kernel-team
In-Reply-To: <20161114142902.GA10455@node.shutemov.name>
On Mon, Nov 14, 2016 at 05:29:02PM +0300, Kirill A. Shutemov wrote:
> On Mon, Nov 14, 2016 at 09:07:44AM +0100, Jan Kara wrote:
> > On Fri 11-11-16 19:37:53, Kirill A. Shutemov wrote:
> > > On Fri, Nov 11, 2016 at 01:22:24PM +0100, Jan Kara wrote:
> > > > On Fri 11-11-16 13:59:21, Kirill A. Shutemov wrote:
> > > > > On Tue, Nov 08, 2016 at 11:12:45AM -0500, Johannes Weiner wrote:
> > > > > > On Tue, Nov 08, 2016 at 10:53:52AM +0100, Jan Kara wrote:
> > > > > > > On Mon 07-11-16 14:07:36, Johannes Weiner wrote:
> > > > > > > > The radix tree counts valid entries in each tree node. Entries stored
> > > > > > > > in the tree cannot be removed by simpling storing NULL in the slot or
> > > > > > > > the internal counters will be off and the node never gets freed again.
> > > > > > > >
> > > > > > > > When collapsing a shmem page fails, restore the holes that were filled
> > > > > > > > with radix_tree_insert() with a proper radix tree deletion.
> > > > > > > >
> > > > > > > > Fixes: f3f0e1d2150b ("khugepaged: add support of collapse for tmpfs/shmem pages")
> > > > > > > > Reported-by: Jan Kara <jack@suse.cz>
> > > > > > > > Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> > > > > > > > ---
> > > > > > > > mm/khugepaged.c | 3 ++-
> > > > > > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > > > > > > > index 728d7790dc2d..eac6f0580e26 100644
> > > > > > > > --- a/mm/khugepaged.c
> > > > > > > > +++ b/mm/khugepaged.c
> > > > > > > > @@ -1520,7 +1520,8 @@ static void collapse_shmem(struct mm_struct *mm,
> > > > > > > > if (!nr_none)
> > > > > > > > break;
> > > > > > > > /* Put holes back where they were */
> > > > > > > > - radix_tree_replace_slot(slot, NULL);
> > > > > > > > + radix_tree_delete(&mapping->page_tree,
> > > > > > > > + iter.index);
> > > > > > >
> > > > > > > Hum, but this is inside radix_tree_for_each_slot() iteration. And
> > > > > > > radix_tree_delete() may end up freeing nodes resulting in invalidating
> > > > > > > current slot pointer and the iteration code will do use-after-free.
> > > > > >
> > > > > > Good point, we need to do another tree lookup after the deletion.
> > > > > >
> > > > > > But there are other instances in the code, where we drop the lock
> > > > > > temporarily and somebody else could delete the node from under us.
> > > > > >
> > > > > > In the main collapse path, I *think* this is prevented by the fact
> > > > > > that when we drop the tree lock we still hold the page lock of the
> > > > > > regular page that's in the tree while we isolate and unmap it, thus
> > > > > > pin the node. Even so, it would seem a little hairy to rely on that.
> > > > > >
> > > > > > Kirill?
> > > > >
> > > > > [ sorry for delay ]
> > > > >
> > > > > Yes, we make sure that locked page still belong to the radix tree and fall
> > > > > off if it's not. Locked page cannot be removed from radix-tree, so we
> > > > > should be fine.
> > > >
> > > > Well, it cannot be removed from the radix tree but radix tree code is still
> > > > free to collapse / expand the tree nodes as it sees fit (currently the only
> > > > real case is when changing direct page pointer in the tree root to a node
> > > > pointer or vice versa but still...). So code should not really assume that
> > > > the node page is referenced from does not change once tree_lock is dropped.
> > > > It leads to subtle bugs...
> > >
> > > Hm. Okay.
> > >
> > > What is the right way re-validate that slot is still valid? Do I need full
> > > look up again? Can I pin node explicitly?
> >
> > Full lookup is the only way to re-validate the slot. There is no way to pin
> > a radix tree node.
>
> I guess this should be enough:
>
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index 728d7790dc2d..c5ef73588676 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -1400,7 +1400,9 @@ static void collapse_shmem(struct mm_struct *mm,
> PAGE_SIZE, 0);
>
> spin_lock_irq(&mapping->tree_lock);
> -
> + slot = radix_tree_lookup_slot(&mapping->page_tree, index);
> + VM_BUG_ON_PAGE(page != radix_tree_deref_slot_protected(slot,
> + &mapping->tree_lock), page);
> VM_BUG_ON_PAGE(page_mapped(page), page);
That looks good to me. The slot may get relocated, but the content
shouldn't change with the page locked.
Are you going to send a full patch with changelog and sign-off? If so,
please add:
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH net] sctp: change sk state only when it has assocs in sctp_shutdown
From: Neil Horman @ 2016-11-14 15:52 UTC (permalink / raw)
To: Xin Long
Cc: network dev, linux-sctp, davem, Marcelo Ricardo Leitner,
Vlad Yasevich, andreyknvl
In-Reply-To: <d260f8b59f52d7ef00b83a554fc19d4aa91766a2.1479044677.git.lucien.xin@gmail.com>
On Sun, Nov 13, 2016 at 09:44:37PM +0800, Xin Long wrote:
> Now when users shutdown a sock with SEND_SHUTDOWN in sctp, even if
> this sock has no connection (assoc), sk state would be changed to
> SCTP_SS_CLOSING, which is not as we expect.
>
> Besides, after that if users try to listen on this sock, kernel
> could even panic when it dereference sctp_sk(sk)->bind_hash in
> sctp_inet_listen, as bind_hash is null when sock has no assoc.
>
> This patch is to move sk state change after checking sk assocs
> is not empty, and also merge these two if() conditions and reduce
> indent level.
>
> Fixes: d46e416c11c8 ("sctp: sctp should change socket state when shutdown is received")
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
> Tested-by: Andrey Konovalov <andreyknvl@google.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> net/sctp/socket.c | 15 +++++++--------
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index faa48ff..f23ad91 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -4285,19 +4285,18 @@ static void sctp_shutdown(struct sock *sk, int how)
> {
> struct net *net = sock_net(sk);
> struct sctp_endpoint *ep;
> - struct sctp_association *asoc;
>
> if (!sctp_style(sk, TCP))
> return;
>
> - if (how & SEND_SHUTDOWN) {
> + ep = sctp_sk(sk)->ep;
> + if (how & SEND_SHUTDOWN && !list_empty(&ep->asocs)) {
> + struct sctp_association *asoc;
> +
> sk->sk_state = SCTP_SS_CLOSING;
> - ep = sctp_sk(sk)->ep;
> - if (!list_empty(&ep->asocs)) {
> - asoc = list_entry(ep->asocs.next,
> - struct sctp_association, asocs);
> - sctp_primitive_SHUTDOWN(net, asoc, NULL);
> - }
> + asoc = list_entry(ep->asocs.next,
> + struct sctp_association, asocs);
> + sctp_primitive_SHUTDOWN(net, asoc, NULL);
> }
> }
>
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* RE: [PATCH] drm/amdgpu: remove amdgpu_irq_get_delayed
From: Deucher, Alexander @ 2016-11-14 15:52 UTC (permalink / raw)
To: 'Christian König',
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
In-Reply-To: <1479129985-3401-1-git-send-email-deathsimple-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
> -----Original Message-----
> From: amd-gfx [mailto:amd-gfx-bounces@lists.freedesktop.org] On Behalf
> Of Christian König
> Sent: Monday, November 14, 2016 8:26 AM
> To: amd-gfx@lists.freedesktop.org
> Subject: [PATCH] drm/amdgpu: remove amdgpu_irq_get_delayed
>
> From: Christian König <christian.koenig@amd.com>
>
> Not used any more.
>
> Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 9 ---------
> drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h | 3 ---
> 2 files changed, 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> index e55ef0c..3cf3a19 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> @@ -433,15 +433,6 @@ int amdgpu_irq_get(struct amdgpu_device *adev,
> struct amdgpu_irq_src *src,
> return 0;
> }
>
> -bool amdgpu_irq_get_delayed(struct amdgpu_device *adev,
> - struct amdgpu_irq_src *src,
> - unsigned type)
> -{
> - if ((type >= src->num_types) || !src->enabled_types)
> - return false;
> - return atomic_inc_return(&src->enabled_types[type]) == 1;
> -}
> -
> /**
> * amdgpu_irq_put - disable interrupt
> *
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h
> index f016464..1642f41 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h
> @@ -88,9 +88,6 @@ int amdgpu_irq_update(struct amdgpu_device *adev,
> struct amdgpu_irq_src *src,
> unsigned type);
> int amdgpu_irq_get(struct amdgpu_device *adev, struct amdgpu_irq_src
> *src,
> unsigned type);
> -bool amdgpu_irq_get_delayed(struct amdgpu_device *adev,
> - struct amdgpu_irq_src *src,
> - unsigned type);
> int amdgpu_irq_put(struct amdgpu_device *adev, struct amdgpu_irq_src
> *src,
> unsigned type);
> bool amdgpu_irq_enabled(struct amdgpu_device *adev, struct
> amdgpu_irq_src *src,
> --
> 2.5.0
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: What to do about Offline_Uncorrectable and Pending_Sector in RAID1
From: Bruce Merry @ 2016-11-14 15:52 UTC (permalink / raw)
To: Wols Lists; +Cc: linux-raid
In-Reply-To: <5828D5DA.1070406@youngman.org.uk>
On 13 November 2016 at 23:06, Wols Lists <antlists@youngman.org.uk> wrote:
> Sounds like that drive could need replacing. I'd get a new drive and do
> that as soon as possible - use the --replace option of mdadm - don't
> fail the old drive and add the new.
Would you mind explaining why I should use --replace instead of taking
out the suspect drive? I guess I lose redundancy for any writes that
occur while the rebuild is happening, but I'd plan to do this with the
filesystem unmounted so there wouldn't be any writes.
What I'd quite like to do is treat the "good" drive as the source for
all the data (unless it turns out to have bad sectors too...), even if
the other drive doesn't have a read error; which I'd achieve by
failing the "bad" drive. I want to do this because after doing one
scrub and starting on a second, I'm still seeing non-zero
mismatch_cnt. Does --replace do anything clever about using the old
drive only when it must, or does it just read from the whole array
like normal, which might mean taking the mismatched data from the bad
drive?
Thanks
Bruce
--
Dr Bruce Merry
bmerry <@> gmail <.> com
http://www.brucemerry.org.za/
http://blog.brucemerry.org.za/
^ permalink raw reply
* Re: [PATCH v3 1/2] Documentation: dt: reset: Add TI SCI reset binding
From: Rob Herring @ 2016-11-14 15:52 UTC (permalink / raw)
To: Andrew F. Davis
Cc: Nishanth Menon, Tero Kristo, Santosh Shilimkar, Philipp Zabel,
Mark Rutland, Suman Anna, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20161104174240.9688-2-afd@ti.com>
On Fri, Nov 04, 2016 at 12:42:39PM -0500, Andrew F. Davis wrote:
> Add TI SCI reset controller binding. This describes the DT binding
> details for a reset controller node providing reset management services
> to hardware blocks (reset consumers) using the Texas Instrument's System
> Control Interface (TI SCI) protocol to communicate to a system controller
> block present on the SoC.
>
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> [s-anna@ti.com: revise the binding format]
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> .../devicetree/bindings/reset/ti,sci-reset.txt | 65 ++++++++++++++++++++++
> MAINTAINERS | 2 +
> include/dt-bindings/reset/k2g.h | 22 ++++++++
> 3 files changed, 89 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> create mode 100644 include/dt-bindings/reset/k2g.h
>
> diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.txt b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> new file mode 100644
> index 0000000..cb00679
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> @@ -0,0 +1,65 @@
> +Texas Instruments System Control Interface (TI-SCI) Reset Controller
> +=====================================================================
> +
> +Some TI SoCs contain a system controller (like the Power Management Micro
> +Controller (PMMC) on Keystone K2G SoC) that are responsible for controlling
> +the state of the various hardware modules present on the SoC. Communication
> +between the host processor running an OS and the system controller happens
> +through a protocol called TI System Control Interface (TI-SCI protocol).
> +For TI SCI details, please refer to the document,
> +Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> +
> +TI-SCI Reset Controller Node
> +============================
> +This reset controller node uses the TI SCI protocol to perform the reset
> +management of various hardware modules present on the SoC.
Needs to say must be a child of the SCI node somewhere in here.
> +
> +Required properties:
> +--------------------
> + - compatible : Should be "ti,sci-reset"
> + - #reset-cells : Should be 2. Please see the reset consumer node below for
> + usage details.
> +
> +TI-SCI Reset Consumer Nodes
> +===========================
> +Each of the reset consumer nodes should have the following properties,
> +in addition to their own properties.
> +
> +Required properties:
> +--------------------
> + - resets : A phandle and reset specifier pair, one pair for each reset
> + signal that affects the device, or that the device manages.
> + The phandle should point to the TI-SCI reset controller node,
> + and the reset specifier should have 2 cell-values. The first
> + cell should contain the device ID, the values of which are
> + specified in the <dt-bindings/genpd/<soc>.h> include file.
> + The second cell should contain the reset mask value used by
> + system controller, the values of which are specified in the
> + include file <dt-bindings/reset/<soc>.h>, where <soc> is the
> + name of the SoC involved, for example 'k2g'.
> +
> +Please also refer to Documentation/devicetree/bindings/reset/reset.txt for
> +common reset controller usage by consumers.
> +
> +Example:
> +--------
> +The following example demonstrates both a TI-SCI reset controller node and a
> +consumer (a DSP device) on the K2G SoC.
> +
> +#include <dt-bindings/genpd/k2g.h>
> +#include <dt-bindings/reset/k2g.h>
> +
> +pmmc: pmmc {
> + compatible = "ti,k2g-sci";
> +
> + k2g_reset: k2g_reset {
...: reset-controller {
> + compatible = "ti,sci-reset";
> + #reset-cells = <2>;
> + };
> +};
> +
> +dsp0: dsp0 {
> + ...
> + resets = <&k2g_reset K2G_DEV_CGEM0 K2G_DEV_CGEM0_DSP0_RESET>;
> + ...
> +};
^ permalink raw reply
* Re: [v3 4/5] vfio: implement APIs to set/put kvm to/from vfio group
From: Alex Williamson @ 2016-11-14 15:52 UTC (permalink / raw)
To: Jike Song; +Cc: Paolo Bonzini, guangrong.xiao, kwankhede, cjia, kevin.tian, kvm
In-Reply-To: <58298FB6.7040207@intel.com>
On Mon, 14 Nov 2016 18:19:34 +0800
Jike Song <jike.song@intel.com> wrote:
> On 11/10/2016 01:53 AM, Alex Williamson wrote:
> > On Wed, 09 Nov 2016 20:49:32 +0800
> > Jike Song <jike.song@intel.com> wrote:
> >
> >> On 11/08/2016 04:45 AM, Paolo Bonzini wrote:
> >>> On 07/11/2016 19:28, Alex Williamson wrote:
> >>>>>> Can the reference become invalid?
> >>>>>
> >>>>> No, this is guaranteed by virt/kvm/vfio.c + the udata.lock mutex (which
> >>>>> probably should be renamed...).
> >>>>
> >>>> The caller gets a reference to kvm, but there's no guarantee that the
> >>>> association of that kvm reference to the group stays valid. Once we're
> >>>> outside of that mutex, we might as well consider that kvm:group
> >>>> association stale.
> >>>>
> >>>>>> The caller may still hold
> >>>>>> a kvm references, but couldn't the group be detached from one kvm
> >>>>>> instance and re-attached to another?
> >>>>>
> >>>>> Can this be handled by the vendor driver? Does it get a callback when
> >>>>> it's detached from a KVM instance?
> >>>>
> >>>> The only release callback through vfio is when the user closes the
> >>>> device, the code in this series is the full extent of vfio awareness of
> >>>> kvm. Thanks,
> >>>
> >>> Maybe there should be an mdev callback at the point of association and
> >>> deassociation between VFIO and KVM. Then the vendor driver can just use
> >>> the same mutex for association, deassociation and usage. I'm not even
> >>> sure that these patches are necessary once you have that callback.
> >>
> >> Hi Alex & Paolo,
> >>
> >> So I cooked another draft version of this, there is no kvm pointer saved
> >> in vfio_group in this version, and notifier will be called on attach/detach,
> >> please kindly have a look :-)
> >>
> >>
> >> --
> >> Thanks,
> >> Jike
> >>
> >>
> >> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> >> index ed2361e4..20b5da9 100644
> >> --- a/drivers/vfio/vfio.c
> >> +++ b/drivers/vfio/vfio.c
> >> @@ -34,6 +34,7 @@
> >> #include <linux/uaccess.h>
> >> #include <linux/vfio.h>
> >> #include <linux/wait.h>
> >> +#include <linux/kvm_host.h>
> >>
> >> #define DRIVER_VERSION "0.3"
> >> #define DRIVER_AUTHOR "Alex Williamson <alex.williamson@redhat.com>"
> >> @@ -86,6 +87,10 @@ struct vfio_group {
> >> struct mutex unbound_lock;
> >> atomic_t opened;
> >> bool noiommu;
> >> + struct {
> >> + struct mutex lock;
> >> + struct blocking_notifier_head notifier;
> >> + } udata;
> >> };
> >>
> >> struct vfio_device {
> >> @@ -333,6 +338,7 @@ static struct vfio_group *vfio_create_group(struct iommu_group *iommu_group)
> >> mutex_init(&group->device_lock);
> >> INIT_LIST_HEAD(&group->unbound_list);
> >> mutex_init(&group->unbound_lock);
> >> + mutex_init(&group->udata.lock);
> >> atomic_set(&group->container_users, 0);
> >> atomic_set(&group->opened, 0);
> >> group->iommu_group = iommu_group;
> >> @@ -414,10 +420,11 @@ static void vfio_group_release(struct kref *kref)
> >> iommu_group_put(iommu_group);
> >> }
> >>
> >> -static void vfio_group_put(struct vfio_group *group)
> >> +void vfio_group_put(struct vfio_group *group)
> >> {
> >> kref_put_mutex(&group->kref, vfio_group_release, &vfio.group_lock);
> >> }
> >> +EXPORT_SYMBOL_GPL(vfio_group_put);
> >>
> >> /* Assume group_lock or group reference is held */
> >> static void vfio_group_get(struct vfio_group *group)
> >> @@ -480,7 +487,7 @@ static struct vfio_group *vfio_group_get_from_minor(int minor)
> >> return group;
> >> }
> >>
> >> -static struct vfio_group *vfio_group_get_from_dev(struct device *dev)
> >> +struct vfio_group *vfio_group_get_from_dev(struct device *dev)
> >> {
> >> struct iommu_group *iommu_group;
> >> struct vfio_group *group;
> >> @@ -494,6 +501,7 @@ static struct vfio_group *vfio_group_get_from_dev(struct device *dev)
> >>
> >> return group;
> >> }
> >> +EXPORT_SYMBOL_GPL(vfio_group_get_from_dev);
> >>
> >> /**
> >> * Device objects - create, release, get, put, search
> >> @@ -1745,6 +1753,44 @@ long vfio_external_check_extension(struct vfio_group *group, unsigned long arg)
> >> }
> >> EXPORT_SYMBOL_GPL(vfio_external_check_extension);
> >>
> >> +int vfio_group_register_notifier(struct vfio_group *group, struct notifier_block *nb)
> >> +{
> >> + return blocking_notifier_chain_register(&group->udata.notifier, nb);
> >> +}
> >> +EXPORT_SYMBOL_GPL(vfio_group_register_notifier);
> >> +
> >> +int vfio_group_unregister_notifier(struct vfio_group *group, struct notifier_block *nb)
> >> +{
> >> + return blocking_notifier_chain_unregister(&group->udata.notifier, nb);
> >> +}
> >> +EXPORT_SYMBOL_GPL(vfio_group_unregister_notifier);
> >
> > Kirti is already adding vfio_register_notifier &
> > vfio_unregister_notifier, these are not exclusive to the iommu, I
> > clarified that in my question that IOVA range invalidation is just one
> > aspect of what that notifier might be used for. The mdev framework
> > also automatically registers and unregisters that notifier around
> > open/release. So, I don't think we want a new notifier, we just want
> > vfio.c to also consume that notifier.
> >
>
> Hi Alex,
>
> Sorry, I have one more question: does combining Kirti's iommu notifier
> and my group notifier mean there should only one blocking_notifier_head?
> If so, where should it be? vfio_container, vfio_group or vfio_iommu?
I suspect the most straightforward approach is to place a
blocking_notifier_head on the vfio_group in addition to the one that
Kirti has placed on the vfio_iommu. Both will include the same
notifier_block from the vendor driver and call the notifier chain
independently. Thanks,
Alex
^ permalink raw reply
* Re: [PATCH igt v3 01/11] igt/perf: add i915 perf stream tests for Haswell
From: Robert Bragg @ 2016-11-14 15:52 UTC (permalink / raw)
To: Matthew Auld; +Cc: Intel Graphics Development
In-Reply-To: <20161110230302.pulguzdnmzq3ao56@mwahaha>
[-- Attachment #1.1: Type: text/plain, Size: 2426 bytes --]
On Thu, Nov 10, 2016 at 11:03 PM, Matthew Auld <matthew.william.auld@gmail.
com> wrote:
> On 11/09, Robert Bragg wrote:
> > +
> > +igt_main
> > +{
> > + igt_skip_on_simulation();
> > +
> > + igt_fixture {
> > + struct stat sb;
> > + int ret;
> > +
> > + drm_fd = drm_open_driver_render(DRIVER_INTEL);
> > + devid = intel_get_drm_devid(drm_fd);
> > + device = drm_get_card();
> > +
> > + igt_require(IS_HASWELL(devid));
> > + igt_require(lookup_hsw_render_basic_id());
> > +
> > + ret = stat("/proc/sys/dev/i915/perf_stream_paranoid",
> &sb);
> > + igt_require(ret == 0);
> > + ret = stat("/proc/sys/dev/i915/oa_max_sample_rate",
> &sb);
> > + igt_require(ret == 0);
> The absence of the above files would indicate a failure in the kernel,
> so would it not be more apt to assert, rather than skip ?
>
The test could be running against an older kernel which won't have these
files and we should skip all the tests in that case.
E.g. Chris asked me to maintain compatibility within the gem_exec_parse
test for older versions of the command parser so I suppose i-g-t tries to
maintain backwards compatibility.
We could potentially require one and assert the other.
> > +
> > + gt_frequency_range_save();
> > +
> > + write_u64_file("/proc/sys/dev/i915/perf_stream_paranoid",
> 1);
> Don't we also want to ensure that the oa_max_sample_rate is also in a
> "good" starting state before we begin, especially since we ensure that
> we leave in its default state when cleaning up ?
>
Explicitly setting the max rate interferes with being able to assert what
the default is, but that's already a problem with the cleanup fixture
explicitly setting the rate.
What I'm doing now is initializing oa_max_sample_rate before tests, as
suggested here, and I've also added a test_sysctl_defaults() test that's
run very early, just after the i915-ref-count test.
>
> Anyway, I think it all looks pretty reasonable to me and it looks like
> we have a good amount of coverage, so you can have my r-b with Chris'
> comment addressed.
>
Thanks, I've moved the ref counting test in front of the first fixture as
suggested by chris (with just the requirements check that the i915-perf
interface exists in another fixture before).
[-- Attachment #1.2: Type: text/html, Size: 3647 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Joerg Roedel @ 2016-11-14 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <41e3eff1-9ce6-bcfb-5716-c65ef38add63@arm.com>
On Mon, Nov 14, 2016 at 12:00:47PM +0000, Robin Murphy wrote:
> If we've already made the decision to move away from bus ops, I don't
> see that it makes sense to deliberately introduce new dependencies on
> them. Besides, as it stands, this patch literally implements "tell the
> iommu-core which hardware-iommus exist in the system and a seperate
> iommu_ops ptr for each of them" straight off.
Not sure which code you are looking at, but as I see it we have only
per-device iommu-ops now (with this patch). That is different from
having core-visible hardware-iommu instances where devices could link
to.
Also the rest of iommu-core code still makes use of the per-bus ops. The
per-device ops are only used for the of_xlate fn-ptr.
Joerg
^ permalink raw reply
* Re: [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Joerg Roedel @ 2016-11-14 15:52 UTC (permalink / raw)
To: Robin Murphy
Cc: Lorenzo Pieralisi, iommu, Will Deacon, Hanjun Guo, Marc Zyngier,
Rafael J. Wysocki, Tomasz Nowicki, Jon Masters, Eric Auger,
Sinan Kaya, Nate Watterson, Prem Mallappa, Dennis Chen,
linux-acpi, linux-pci, linux-kernel, linux-arm-kernel
In-Reply-To: <41e3eff1-9ce6-bcfb-5716-c65ef38add63@arm.com>
On Mon, Nov 14, 2016 at 12:00:47PM +0000, Robin Murphy wrote:
> If we've already made the decision to move away from bus ops, I don't
> see that it makes sense to deliberately introduce new dependencies on
> them. Besides, as it stands, this patch literally implements "tell the
> iommu-core which hardware-iommus exist in the system and a seperate
> iommu_ops ptr for each of them" straight off.
Not sure which code you are looking at, but as I see it we have only
per-device iommu-ops now (with this patch). That is different from
having core-visible hardware-iommu instances where devices could link
to.
Also the rest of iommu-core code still makes use of the per-bus ops. The
per-device ops are only used for the of_xlate fn-ptr.
Joerg
^ permalink raw reply
* Re: [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Joerg Roedel @ 2016-11-14 15:52 UTC (permalink / raw)
To: Robin Murphy
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-acpi-u79uwXL29TY76Z2rM5mHXA, Marc Zyngier, Will Deacon,
Rafael J. Wysocki, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Sinan Kaya,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Dennis Chen,
Tomasz Nowicki, Prem Mallappa, Jon Masters
In-Reply-To: <41e3eff1-9ce6-bcfb-5716-c65ef38add63-5wv7dgnIgG8@public.gmane.org>
On Mon, Nov 14, 2016 at 12:00:47PM +0000, Robin Murphy wrote:
> If we've already made the decision to move away from bus ops, I don't
> see that it makes sense to deliberately introduce new dependencies on
> them. Besides, as it stands, this patch literally implements "tell the
> iommu-core which hardware-iommus exist in the system and a seperate
> iommu_ops ptr for each of them" straight off.
Not sure which code you are looking at, but as I see it we have only
per-device iommu-ops now (with this patch). That is different from
having core-visible hardware-iommu instances where devices could link
to.
Also the rest of iommu-core code still makes use of the per-bus ops. The
per-device ops are only used for the of_xlate fn-ptr.
Joerg
^ permalink raw reply
* Re: [PATCH v3 1/2] Documentation: dt: reset: Add TI SCI reset binding
From: Rob Herring @ 2016-11-14 15:52 UTC (permalink / raw)
To: Andrew F. Davis
Cc: Nishanth Menon, Tero Kristo, Santosh Shilimkar, Philipp Zabel,
Mark Rutland, Suman Anna,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161104174240.9688-2-afd-l0cyMroinI0@public.gmane.org>
On Fri, Nov 04, 2016 at 12:42:39PM -0500, Andrew F. Davis wrote:
> Add TI SCI reset controller binding. This describes the DT binding
> details for a reset controller node providing reset management services
> to hardware blocks (reset consumers) using the Texas Instrument's System
> Control Interface (TI SCI) protocol to communicate to a system controller
> block present on the SoC.
>
> Signed-off-by: Andrew F. Davis <afd-l0cyMroinI0@public.gmane.org>
> [s-anna-l0cyMroinI0@public.gmane.org: revise the binding format]
> Signed-off-by: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>
> Signed-off-by: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
> ---
> .../devicetree/bindings/reset/ti,sci-reset.txt | 65 ++++++++++++++++++++++
> MAINTAINERS | 2 +
> include/dt-bindings/reset/k2g.h | 22 ++++++++
> 3 files changed, 89 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> create mode 100644 include/dt-bindings/reset/k2g.h
>
> diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.txt b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> new file mode 100644
> index 0000000..cb00679
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> @@ -0,0 +1,65 @@
> +Texas Instruments System Control Interface (TI-SCI) Reset Controller
> +=====================================================================
> +
> +Some TI SoCs contain a system controller (like the Power Management Micro
> +Controller (PMMC) on Keystone K2G SoC) that are responsible for controlling
> +the state of the various hardware modules present on the SoC. Communication
> +between the host processor running an OS and the system controller happens
> +through a protocol called TI System Control Interface (TI-SCI protocol).
> +For TI SCI details, please refer to the document,
> +Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> +
> +TI-SCI Reset Controller Node
> +============================
> +This reset controller node uses the TI SCI protocol to perform the reset
> +management of various hardware modules present on the SoC.
Needs to say must be a child of the SCI node somewhere in here.
> +
> +Required properties:
> +--------------------
> + - compatible : Should be "ti,sci-reset"
> + - #reset-cells : Should be 2. Please see the reset consumer node below for
> + usage details.
> +
> +TI-SCI Reset Consumer Nodes
> +===========================
> +Each of the reset consumer nodes should have the following properties,
> +in addition to their own properties.
> +
> +Required properties:
> +--------------------
> + - resets : A phandle and reset specifier pair, one pair for each reset
> + signal that affects the device, or that the device manages.
> + The phandle should point to the TI-SCI reset controller node,
> + and the reset specifier should have 2 cell-values. The first
> + cell should contain the device ID, the values of which are
> + specified in the <dt-bindings/genpd/<soc>.h> include file.
> + The second cell should contain the reset mask value used by
> + system controller, the values of which are specified in the
> + include file <dt-bindings/reset/<soc>.h>, where <soc> is the
> + name of the SoC involved, for example 'k2g'.
> +
> +Please also refer to Documentation/devicetree/bindings/reset/reset.txt for
> +common reset controller usage by consumers.
> +
> +Example:
> +--------
> +The following example demonstrates both a TI-SCI reset controller node and a
> +consumer (a DSP device) on the K2G SoC.
> +
> +#include <dt-bindings/genpd/k2g.h>
> +#include <dt-bindings/reset/k2g.h>
> +
> +pmmc: pmmc {
> + compatible = "ti,k2g-sci";
> +
> + k2g_reset: k2g_reset {
...: reset-controller {
> + compatible = "ti,sci-reset";
> + #reset-cells = <2>;
> + };
> +};
> +
> +dsp0: dsp0 {
> + ...
> + resets = <&k2g_reset K2G_DEV_CGEM0 K2G_DEV_CGEM0_DSP0_RESET>;
> + ...
> +};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 1/2] Documentation: dt: reset: Add TI SCI reset binding
From: Rob Herring @ 2016-11-14 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104174240.9688-2-afd@ti.com>
On Fri, Nov 04, 2016 at 12:42:39PM -0500, Andrew F. Davis wrote:
> Add TI SCI reset controller binding. This describes the DT binding
> details for a reset controller node providing reset management services
> to hardware blocks (reset consumers) using the Texas Instrument's System
> Control Interface (TI SCI) protocol to communicate to a system controller
> block present on the SoC.
>
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> [s-anna at ti.com: revise the binding format]
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> .../devicetree/bindings/reset/ti,sci-reset.txt | 65 ++++++++++++++++++++++
> MAINTAINERS | 2 +
> include/dt-bindings/reset/k2g.h | 22 ++++++++
> 3 files changed, 89 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> create mode 100644 include/dt-bindings/reset/k2g.h
>
> diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.txt b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> new file mode 100644
> index 0000000..cb00679
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> @@ -0,0 +1,65 @@
> +Texas Instruments System Control Interface (TI-SCI) Reset Controller
> +=====================================================================
> +
> +Some TI SoCs contain a system controller (like the Power Management Micro
> +Controller (PMMC) on Keystone K2G SoC) that are responsible for controlling
> +the state of the various hardware modules present on the SoC. Communication
> +between the host processor running an OS and the system controller happens
> +through a protocol called TI System Control Interface (TI-SCI protocol).
> +For TI SCI details, please refer to the document,
> +Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> +
> +TI-SCI Reset Controller Node
> +============================
> +This reset controller node uses the TI SCI protocol to perform the reset
> +management of various hardware modules present on the SoC.
Needs to say must be a child of the SCI node somewhere in here.
> +
> +Required properties:
> +--------------------
> + - compatible : Should be "ti,sci-reset"
> + - #reset-cells : Should be 2. Please see the reset consumer node below for
> + usage details.
> +
> +TI-SCI Reset Consumer Nodes
> +===========================
> +Each of the reset consumer nodes should have the following properties,
> +in addition to their own properties.
> +
> +Required properties:
> +--------------------
> + - resets : A phandle and reset specifier pair, one pair for each reset
> + signal that affects the device, or that the device manages.
> + The phandle should point to the TI-SCI reset controller node,
> + and the reset specifier should have 2 cell-values. The first
> + cell should contain the device ID, the values of which are
> + specified in the <dt-bindings/genpd/<soc>.h> include file.
> + The second cell should contain the reset mask value used by
> + system controller, the values of which are specified in the
> + include file <dt-bindings/reset/<soc>.h>, where <soc> is the
> + name of the SoC involved, for example 'k2g'.
> +
> +Please also refer to Documentation/devicetree/bindings/reset/reset.txt for
> +common reset controller usage by consumers.
> +
> +Example:
> +--------
> +The following example demonstrates both a TI-SCI reset controller node and a
> +consumer (a DSP device) on the K2G SoC.
> +
> +#include <dt-bindings/genpd/k2g.h>
> +#include <dt-bindings/reset/k2g.h>
> +
> +pmmc: pmmc {
> + compatible = "ti,k2g-sci";
> +
> + k2g_reset: k2g_reset {
...: reset-controller {
> + compatible = "ti,sci-reset";
> + #reset-cells = <2>;
> + };
> +};
> +
> +dsp0: dsp0 {
> + ...
> + resets = <&k2g_reset K2G_DEV_CGEM0 K2G_DEV_CGEM0_DSP0_RESET>;
> + ...
> +};
^ permalink raw reply
* Re: [PATCH net] sctp: change sk state only when it has assocs in sctp_shutdown
From: Neil Horman @ 2016-11-14 15:52 UTC (permalink / raw)
To: Xin Long
Cc: network dev, linux-sctp, davem, Marcelo Ricardo Leitner,
Vlad Yasevich, andreyknvl
In-Reply-To: <d260f8b59f52d7ef00b83a554fc19d4aa91766a2.1479044677.git.lucien.xin@gmail.com>
On Sun, Nov 13, 2016 at 09:44:37PM +0800, Xin Long wrote:
> Now when users shutdown a sock with SEND_SHUTDOWN in sctp, even if
> this sock has no connection (assoc), sk state would be changed to
> SCTP_SS_CLOSING, which is not as we expect.
>
> Besides, after that if users try to listen on this sock, kernel
> could even panic when it dereference sctp_sk(sk)->bind_hash in
> sctp_inet_listen, as bind_hash is null when sock has no assoc.
>
> This patch is to move sk state change after checking sk assocs
> is not empty, and also merge these two if() conditions and reduce
> indent level.
>
> Fixes: d46e416c11c8 ("sctp: sctp should change socket state when shutdown is received")
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
> Tested-by: Andrey Konovalov <andreyknvl@google.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> net/sctp/socket.c | 15 +++++++--------
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index faa48ff..f23ad91 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -4285,19 +4285,18 @@ static void sctp_shutdown(struct sock *sk, int how)
> {
> struct net *net = sock_net(sk);
> struct sctp_endpoint *ep;
> - struct sctp_association *asoc;
>
> if (!sctp_style(sk, TCP))
> return;
>
> - if (how & SEND_SHUTDOWN) {
> + ep = sctp_sk(sk)->ep;
> + if (how & SEND_SHUTDOWN && !list_empty(&ep->asocs)) {
> + struct sctp_association *asoc;
> +
> sk->sk_state = SCTP_SS_CLOSING;
> - ep = sctp_sk(sk)->ep;
> - if (!list_empty(&ep->asocs)) {
> - asoc = list_entry(ep->asocs.next,
> - struct sctp_association, asocs);
> - sctp_primitive_SHUTDOWN(net, asoc, NULL);
> - }
> + asoc = list_entry(ep->asocs.next,
> + struct sctp_association, asocs);
> + sctp_primitive_SHUTDOWN(net, asoc, NULL);
> }
> }
>
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: Creating 'wic' image
From: Christopher Larson @ 2016-11-14 15:51 UTC (permalink / raw)
To: Mike Looijmans; +Cc: OE-core
In-Reply-To: <95b4383a-727c-a022-9a9a-5398c7dabf36@topic.nl>
[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]
On Mon, Nov 14, 2016 at 8:23 AM, Mike Looijmans <mike.looijmans@topic.nl>
wrote:
> In order to make life easier for people, I was looking into creating
> images with the "wic" tool.
>
> There's just one big piece of documentation lacking: What's the format it
> wants my rootfs and boot files?
> http://www.yoctoproject.org/docs/2.2/mega-manual/mega-manual.html
>
> Basically I want an SD card with a FAT boot partition and an ext4 rootfs,
> and "sdimage-bootpart" is pretty close to that.
>
> Without "wic", I build a tar of the rootfs and copy the boot files using a
> bit of shell scripting.
>
> Adding "wic" to IMAGE_FSTYPES just results in an error that I should set
> WKS_FILE but I have no clue as to what file that should point to.
>
> Running wic manually just results in more missing variables that I can't
> find what to specify in them...
>
WKS_FILE is how you tell it to use sdimage-bootpart.wks. IMAGE_BOOT_FILES
Is how to add extra files to the fat boot partiiton.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
[-- Attachment #2: Type: text/html, Size: 1780 bytes --]
^ permalink raw reply
* Re: [PATCH 2/6] perf config: Document examples to get config key-value pairs in man page
From: Arnaldo Carvalho de Melo @ 2016-11-14 15:51 UTC (permalink / raw)
To: Taeung Song
Cc: linux-kernel, Jiri Olsa, Namhyung Kim, Ingo Molnar,
Peter Zijlstra, Wang Nan, Nambong Ha, Wookje Kwon
In-Reply-To: <1478241862-31230-3-git-send-email-treeze.taeung@gmail.com>
Em Fri, Nov 04, 2016 at 03:44:18PM +0900, Taeung Song escreveu:
> Explain how to query particular config items in config file
> and how to get several config items from user or system config file
> using '--user' or '--system' options.
This one should be combined with the previous one, i.e. the patch that
introduces this feature, doing it myself.
- Arnaldo
> Cc: Namhyung Kim <namhyung@kernel.org>
> Cc: Jiri Olsa <jolsa@kernel.org>
> Cc: Wang Nan <wangnan0@huawei.com>
> Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
> ---
> tools/perf/Documentation/perf-config.txt | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/tools/perf/Documentation/perf-config.txt b/tools/perf/Documentation/perf-config.txt
> index cb081ac5..1714b0c 100644
> --- a/tools/perf/Documentation/perf-config.txt
> +++ b/tools/perf/Documentation/perf-config.txt
> @@ -8,6 +8,8 @@ perf-config - Get and set variables in a configuration file.
> SYNOPSIS
> --------
> [verse]
> +'perf config' [<file-option>] [section.name ...]
> +or
> 'perf config' [<file-option>] -l | --list
>
> DESCRIPTION
> @@ -118,6 +120,22 @@ Given a $HOME/.perfconfig like this:
> children = true
> group = true
>
> +To query the record mode of call graph, do
> +
> + % perf config call-graph.record-mode
> +
> +If you want to know multiple config key/value pairs, you can do like
> +
> + % perf config report.queue-size call-graph.order report.children
> +
> +To query the config value of sort order of call graph in user config file (i.e. `~/.perfconfig`), do
> +
> + % perf config --user call-graph.sort-order
> +
> +To query the config value of buildid directory in system config file (i.e. `$(sysconf)/perfconfig`), do
> +
> + % perf config --system buildid.dir
> +
> Variables
> ~~~~~~~~~
>
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH] ARM: dts: at91: replace gpio-key,wakeup with wakeup-source for sam9260ek
From: Sudeep Holla @ 2016-11-14 15:51 UTC (permalink / raw)
To: Nicolas Ferre
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Sudeep Holla,
devicetree-u79uwXL29TY76Z2rM5mHXA, Alexandre Belloni,
Jean-Christophe Plagniol-Villard
In-Reply-To: <55e95acc-d30f-432e-90d6-f96bad69ac3d-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
On 14/11/16 15:45, Nicolas Ferre wrote:
> Le 14/11/2016 à 16:44, Sudeep Holla a écrit :
>> Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
>> check for/support the legacy "gpio-key,wakeup" boolean property to
>> enable gpio buttons as wakeup source, "wakeup-source" is the new
>> standard binding.
>>
>> This patch replaces the legacy "gpio-key,wakeup" with the unified
>> "wakeup-source" property in order to avoid any further copy-paste
>> duplication.
>>
>> Cc: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
>
> Acked-by: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
>
>> Cc: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> Cc: Jean-Christophe Plagniol-Villard <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
>> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
>> ---
>> arch/arm/boot/dts/at91sam9260ek.dts | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> Hi,
>>
>> Inspite of getting rid of most of the legacy property almost a year ago,
>> addition of new platforms have brought this back and over time it's
>> now found again in few places. Just get rid of them *again*
>>
>> Regards,
>> Sudeep
>
> Sorry for this Sudeep and thanks for the patch.
>
No problem, in fact you reminded me to post them :)
--
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ARM: dts: at91: replace gpio-key,wakeup with wakeup-source for sam9260ek
From: Sudeep Holla @ 2016-11-14 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55e95acc-d30f-432e-90d6-f96bad69ac3d@atmel.com>
On 14/11/16 15:45, Nicolas Ferre wrote:
> Le 14/11/2016 ? 16:44, Sudeep Holla a ?crit :
>> Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
>> check for/support the legacy "gpio-key,wakeup" boolean property to
>> enable gpio buttons as wakeup source, "wakeup-source" is the new
>> standard binding.
>>
>> This patch replaces the legacy "gpio-key,wakeup" with the unified
>> "wakeup-source" property in order to avoid any further copy-paste
>> duplication.
>>
>> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>
>> Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>> arch/arm/boot/dts/at91sam9260ek.dts | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> Hi,
>>
>> Inspite of getting rid of most of the legacy property almost a year ago,
>> addition of new platforms have brought this back and over time it's
>> now found again in few places. Just get rid of them *again*
>>
>> Regards,
>> Sudeep
>
> Sorry for this Sudeep and thanks for the patch.
>
No problem, in fact you reminded me to post them :)
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 1/6] perf config: Add support for getting config key-value pairs
From: Arnaldo Carvalho de Melo @ 2016-11-14 15:50 UTC (permalink / raw)
To: Taeung Song
Cc: linux-kernel, Jiri Olsa, Namhyung Kim, Ingo Molnar,
Peter Zijlstra, Wang Nan, Nambong Ha, Wookje Kwon
In-Reply-To: <1478241862-31230-2-git-send-email-treeze.taeung@gmail.com>
Em Fri, Nov 04, 2016 at 03:44:17PM +0900, Taeung Song escreveu:
> Add a functionality getting specific config key-value pairs.
> For the syntax examples,
>
> perf config [<file-option>] [section.name ...]
>
> e.g. To query config items 'report.queue-size' and 'report.children', do
>
> # perf config report.queue-size report.children
So, I'm applying it, but while testing I noticed that it shows only the
options that were explicitely set:
[acme@jouet linux]$ perf config report.queue-size report.children
report.children=false
[acme@jouet linux]$
Perhaps we should, in a follow up patch, show this instead:
[acme@jouet linux]$ perf config report.queue-size report.children
report.children=false
# report.queue-size=18446744073709551615 # Default, not set in ~/.perfconfig
[acme@jouet linux]$
?
- Arnaldo
> Cc: Namhyung Kim <namhyung@kernel.org>
> Cc: Jiri Olsa <jolsa@kernel.org>
> Cc: Wang Nan <wangnan0@huawei.com>
> Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
> ---
> tools/perf/builtin-config.c | 40 +++++++++++++++++++++++++++++++++++++---
> 1 file changed, 37 insertions(+), 3 deletions(-)
>
> diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
> index e4207a2..df3fa1c 100644
> --- a/tools/perf/builtin-config.c
> +++ b/tools/perf/builtin-config.c
> @@ -17,7 +17,7 @@
> static bool use_system_config, use_user_config;
>
> static const char * const config_usage[] = {
> - "perf config [<file-option>] [options]",
> + "perf config [<file-option>] [options] [section.name ...]",
> NULL
> };
>
> @@ -33,6 +33,36 @@ static struct option config_options[] = {
> OPT_END()
> };
>
> +static int show_spec_config(struct perf_config_set *set, const char *var)
> +{
> + struct perf_config_section *section;
> + struct perf_config_item *item;
> +
> + if (set == NULL)
> + return -1;
> +
> + perf_config_items__for_each_entry(&set->sections, section) {
> + if (prefixcmp(var, section->name) != 0)
> + continue;
> +
> + perf_config_items__for_each_entry(§ion->items, item) {
> + const char *name = var + strlen(section->name) + 1;
> +
> + if (strcmp(name, item->name) == 0) {
> + char *value = item->value;
> +
> + if (value) {
> + printf("%s=%s\n", var, value);
> + return 0;
> + }
> + }
> +
> + }
> + }
> +
> + return 0;
> +}
> +
> static int show_config(struct perf_config_set *set)
> {
> struct perf_config_section *section;
> @@ -54,7 +84,7 @@ static int show_config(struct perf_config_set *set)
>
> int cmd_config(int argc, const char **argv, const char *prefix __maybe_unused)
> {
> - int ret = 0;
> + int i, ret = 0;
> struct perf_config_set *set;
> char *user_config = mkpath("%s/.perfconfig", getenv("HOME"));
>
> @@ -100,7 +130,11 @@ int cmd_config(int argc, const char **argv, const char *prefix __maybe_unused)
> }
> break;
> default:
> - usage_with_options(config_usage, config_options);
> + if (argc)
> + for (i = 0; argv[i]; i++)
> + ret = show_spec_config(set, argv[i]);
> + else
> + usage_with_options(config_usage, config_options);
> }
>
> perf_config_set__delete(set);
> --
> 2.7.4
^ permalink raw reply
* Re: [Qemu-devel] [Qemu-block] [PATCH for-2.8] block: Let write zeroes fallback work even with small max_transfer
From: Eric Blake @ 2016-11-14 15:50 UTC (permalink / raw)
To: Kevin Wolf, Fam Zheng
Cc: Stefan Hajnoczi, qemu-devel, qemu-block, qemu-stable, Max Reitz,
Ed Swierk, Stefan Hajnoczi, Denis V . Lunev
In-Reply-To: <20161110080346.GB4981@noname.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]
On 11/10/2016 02:03 AM, Kevin Wolf wrote:
>>>>> Test case:
>>>>>
>>>>> $ qemu-img create -f qcow2 -o cluster_size=1M file 10M
>>>>> $ losetup /dev/loop2 /path/to/file
>>>>> $ qemu-io -f qcow2 /dev/loop2
>>>>> qemu-io> w 7m 1k
>>>>> qemu-io> w -z 8003584 2093056
>>>>
>>>> Please include a qemu-iotests test case to protect against regressions.
>>>
>>> None of the existing qemu-iotests use losetup; I guess the closest thing
>>> to do is crib from a test that uses passwordless sudo?
>>>
>>> It will certainly be a separate commit, but I'll give it my best shot to
>>> post something soon.
>>
>> Alternatively, maybe add a blkdebug option to emulate a small max_transfer at
>> the protocol layer?
>
> This sounds like the better option indeed.
I'm working on this, but found that blkdebug doesn't yet support discard
or write zero. While I do plan on adding that support, it is a new
feature to blkdebug, and therefore probably belongs in 2.9. That said,
I'm still hoping to post an entire series with improved blkdebug and
qemu-iotest coverage of the two tangentially related patches (this one
for write zeroes, and another for discard support), where we can pick
the first half of the series (basically v2 of my pending patches) into
2.8 while feeling more confident that the second half (the blkdebug and
testsuite additions) wait for 2.9.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
^ permalink raw reply
* Re: [PATCH] ioctl.h: add missing kernel compatibility header for BUILD_ASSERT
From: David Sterba @ 2016-11-14 15:50 UTC (permalink / raw)
To: dsterba, Sergei Trofimovich, linux-btrfs
In-Reply-To: <20161114123449.GL12522@suse.cz>
On Mon, Nov 14, 2016 at 01:34:49PM +0100, David Sterba wrote:
> On Sat, Nov 12, 2016 at 10:14:49PM +0000, Sergei Trofimovich wrote:
> > > > Basically gcc tries to say us BUILD_ASSERT is not visible.
> > > >
> > > > BUILD_ASSERT lives in kerncompat.h which this change adds.
> > >
> > > I think including the kerncompat.h is too intrusive here, I've fixed by
> > > providing an empty macro if it's not defined. I'll release 4.8.2 soon.
> >
> > Apologies. I did not test your fix right afterwards. Seems now header is incomplete
> > due to missing NULL (gcc-6):
> >
> > btrfs-progs-v4.8.3 $ gcc -c ioctl.h -o /tmp/a.o
> > ioctl.h: In function 'btrfs_err_str':
> > ioctl.h:711:11: error: 'NULL' undeclared (first use in this function)
> > return NULL;
> > ^~~~
> > ioctl.h:711:11: note: each undeclared identifier is reported only once for each function it appears in
>
> The ioctl.h file can be included in both C and C++ code, I'd rahter
> avoid to ifdef the right definition of NULL, so s/NULL/0/ seems as a
> best fix to me.
Or #include <stddef.h>, now committed to devel.
^ permalink raw reply
* Re: [PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"
From: Ville Syrjälä @ 2016-11-14 15:49 UTC (permalink / raw)
To: Sharma, Shashank
Cc: Jose Abreu, Jia, Lin A, Akashdeep Sharma, Emil Velikov, dri-devel,
Daniel Vetter, Jim Bride
In-Reply-To: <69c7ad2d-be85-b7c5-4a89-3fa4f37f44e2@intel.com>
On Mon, Nov 14, 2016 at 08:14:34PM +0530, Sharma, Shashank wrote:
> Regards
> Shashank
> > the revert:
> >
> > HDMI2 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 700mm x 390mm
> > - 1920x1080 60.00*+
> > - 1920x1080i 60.00 50.00
> > + 1920x1080 60.00*+ 50.00 59.94 30.00 25.00 24.00 29.97 23.98
> > + 1920x1080i 60.00 50.00 59.94
> > 1600x1200 60.00
> > 1680x1050 59.88
> > 1280x1024 75.02 60.02
> > @@ -13,30 +13,29 @@
> > 1360x768 60.02
> > 1280x800 59.91
> > 1152x864 75.00
> > - 1280x720 60.00 50.00
> > + 1280x720 60.00 50.00 59.94
> > 1024x768 75.03 70.07 60.00
> > 832x624 74.55
> > 800x600 72.19 75.00 60.32
> > - 640x480 75.00 72.81 66.67 59.94
> > + 720x576 50.00
> > + 720x480 60.00 59.94
> > + 640x480 75.00 72.81 66.67 60.00 59.94
> > 720x400 70.08
> None of these aspect ratios are new modes / new aspect ratios from HDMI
> 2.0/CEA-861-F
> These are the existing modes, and should be independent of reverted
> patches.
They're affected because your patches changed them by adding the aspect
ratio flags to them.
> > This was with sna, which does this:
> > #define KNOWN_MODE_FLAGS ((1<<14)-1)
> > if (mode->status == MODE_OK && kmode->flags & ~KNOWN_MODE_FLAGS)
> > mode->status = MODE_BAD; /* unknown flags => unhandled */
> > so all the modes with an aspect ratio just vanished.
> >
> > -modesetting and -ati on the other hand just copy over the unknown
> > bits into the xrandr mode structure, which sounds dubious at best:
> > mode->Flags = kmode->flags; //& FLAG_BITS;
> > I've not checked what damage it can actually cause.
> >
> >
> > It looks like a few modes disappeared from the kernel's mode list
> > as well, presumably because some cea modes in the list originated from
> > DTDs and whanot so they don't have an aspect ratio and that causes
> > add_alternate_cea_modes() to ignore them. So not populating an aspect
> > ratio for cea modes originating from a source other than
> > edid_cea_modes[] looks like another bug to me as well.
> I am writing a patch series to cap the aspect ratio implementation under
> a drm_cap_hdmi2_aspect_ratios
> This is how its going to work (inspired from the 2D/stereo series from
> damien L)
>
> - Add a new capability hdmi2_ar
It should be just a generic "expose aspect ratio flags to userspace?"
> - by default parsing the new hdmi 2.0 aspect ratio will be disabled
> under check of this cap
> - during bootup time, while initializing the display, a userspace can
> get_cap on the hdmi2_aspect_ratio
> - If it wants HDMI 2.0 aspect ratio support, it will set the cap, and
> kernel will expose these aspect ratios
> > Another bug I think might be the ordering of the modes with aspect ratio
> > specified. IIRC the spec says that the preferred aspect ratio should be
> > listed first in the EDID, but I don't think we preserve that ordering
> > in the final mode list. I guess we could fix that by somehow noting
> > which aspect ratio is preferred and sort based on that, or we try to
> > preserve the order from the EDID until we're ready to sort, and then do
> > the sorting with a stable algorithm.
> AFAIK The mode order and priority is decided and arranged in userspace,
> based on various factors like
> - preferred mode.
> - previously applied mode in previous sessions (like for android tvs)
> - Bigger h/w vs better refresh rate ?
> - Xserver applies its own algorithms to decide which mode should be
> shown first.
Xorg does sort on its own. But since it doesn't know anything about
aspect ratios and whatnot I wouldn't rely on that for anything. I
also wouldn't expect eg. wayland compositors to do their own sorting.
And yeah, looks like weston at least doesn't do any sorting whatsoever.
>
> I dont think kernel needs to bother about it.
So I'm going to say that we in fact do need to bother.
--
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v6 1/2] block/vxhs.c: Add support for a new block device type called "vxhs"
From: Fam Zheng @ 2016-11-14 15:49 UTC (permalink / raw)
To: Ashish Mittal, Stefan Hajnoczi
Cc: qemu-devel, pbonzini, kwolf, armbru, berrange, jcody,
ashish.mittal, Rakesh.Ranjan, Buddhi.Madhav, Ketan.Nilangekar,
Abhijit.Dey, Venkatesha.Mg
In-Reply-To: <20161114150701.GD26198@stefanha-x1.localdomain>
On Mon, 11/14 15:07, Stefan Hajnoczi wrote:
> On Mon, Nov 07, 2016 at 04:59:44PM -0800, Ashish Mittal wrote:
> > diff --git a/block/vxhs.c b/block/vxhs.c
> > new file mode 100644
> > index 0000000..8913e8f
> > --- /dev/null
> > +++ b/block/vxhs.c
> > @@ -0,0 +1,689 @@
> > +/*
> > + * QEMU Block driver for Veritas HyperScale (VxHS)
> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> > + * See the COPYING file in the top-level directory.
> > + *
> > + */
> > +
> > +#include "qemu/osdep.h"
> > +#include "block/block_int.h"
> > +#include <qnio/qnio_api.h>
>
> Please move system headers (<>) above user headers (""). This way you
> can be sure the system header isn't affected by any macros defined by
> user headers.
Yes, but still after "qemu/osdep.h", which prepares necessary bits for any other
headers.
Fam
^ permalink raw reply
* [PATCH v12 06/22] vfio iommu type1: Update arguments of vfio_lock_acct
From: Kirti Wankhede @ 2016-11-14 15:42 UTC (permalink / raw)
To: alex.williamson, pbonzini, kraxel, cjia
Cc: qemu-devel, kvm, kevin.tian, jike.song, bjsdjshi, linux-kernel,
Kirti Wankhede
In-Reply-To: <1479138156-28905-1-git-send-email-kwankhede@nvidia.com>
Added task structure as input argument to vfio_lock_acct() function.
Signed-off-by: Kirti Wankhede <kwankhede@nvidia.com>
Signed-off-by: Neo Jia <cjia@nvidia.com>
Change-Id: I5d3673cc9d3786bb436b395d5f74537f1a36da80
---
drivers/vfio/vfio_iommu_type1.c | 30 ++++++++++++++++--------------
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 9f3d58d3dfaf..34d17e51dc97 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -150,17 +150,22 @@ static void vfio_lock_acct_bg(struct work_struct *work)
kfree(vwork);
}
-static void vfio_lock_acct(long npage)
+static void vfio_lock_acct(struct task_struct *task, long npage)
{
struct vwork *vwork;
struct mm_struct *mm;
- if (!current->mm || !npage)
+ if (!npage)
+ return;
+
+ mm = get_task_mm(task);
+ if (!mm)
return; /* process exited or nothing to do */
- if (down_write_trylock(¤t->mm->mmap_sem)) {
- current->mm->locked_vm += npage;
- up_write(¤t->mm->mmap_sem);
+ if (down_write_trylock(&mm->mmap_sem)) {
+ mm->locked_vm += npage;
+ up_write(&mm->mmap_sem);
+ mmput(mm);
return;
}
@@ -170,11 +175,8 @@ static void vfio_lock_acct(long npage)
* wouldn't need this silliness
*/
vwork = kmalloc(sizeof(struct vwork), GFP_KERNEL);
- if (!vwork)
- return;
- mm = get_task_mm(current);
- if (!mm) {
- kfree(vwork);
+ if (!vwork) {
+ mmput(mm);
return;
}
INIT_WORK(&vwork->work, vfio_lock_acct_bg);
@@ -285,7 +287,7 @@ static long vfio_pin_pages_remote(unsigned long vaddr, long npage,
if (unlikely(disable_hugepages)) {
if (!rsvd)
- vfio_lock_acct(1);
+ vfio_lock_acct(current, 1);
return 1;
}
@@ -313,7 +315,7 @@ static long vfio_pin_pages_remote(unsigned long vaddr, long npage,
}
if (!rsvd)
- vfio_lock_acct(i);
+ vfio_lock_acct(current, i);
return i;
}
@@ -328,7 +330,7 @@ static long vfio_unpin_pages_remote(unsigned long pfn, long npage,
unlocked += put_pfn(pfn++, prot);
if (do_accounting)
- vfio_lock_acct(-unlocked);
+ vfio_lock_acct(current, -unlocked);
return unlocked;
}
@@ -390,7 +392,7 @@ static void vfio_unmap_unpin(struct vfio_iommu *iommu, struct vfio_dma *dma)
cond_resched();
}
- vfio_lock_acct(-unlocked);
+ vfio_lock_acct(current, -unlocked);
}
static void vfio_remove_dma(struct vfio_iommu *iommu, struct vfio_dma *dma)
--
2.7.0
^ permalink raw reply related
* Re: [PATCH 1/2] regulator: pwm: DT: Add ramp delay for exponential voltage transition
From: Rob Herring @ 2016-11-14 15:48 UTC (permalink / raw)
To: Laxman Dewangan
Cc: broonie, mark.rutland, linux-kernel, devicetree, Douglas Anderson,
Aleksandr Frid
In-Reply-To: <1478281075-3498-1-git-send-email-ldewangan@nvidia.com>
On Fri, Nov 04, 2016 at 11:07:54PM +0530, Laxman Dewangan wrote:
> Some PWM regulator has the exponential transition in voltage change as
> opposite to fixed slew-rate linear transition on other regulators.
> For such PWM regulators, add the property for providing the delay
> from DT node.
>
> Add DT binding details of the new property
> "pwm-regulator-voltage-ramp-time-us" added for providing voltage
> transition delay.
>
> Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
> CC: Douglas Anderson <dianders@chromium.org>
> CC: Aleksandr Frid <afrid@nvidia.com>
>
> ---
> This patch is continuation of discussion on patch
> regulator: pwm: Fix regulator ramp delay for continuous mode
> https://patchwork.kernel.org/patch/9216857/
> where is it discussed to have separate property for PWM which has
> exponential voltage transition.
> ---
> Documentation/devicetree/bindings/regulator/pwm-regulator.txt | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
> index 3aeba9f..a163f42 100644
> --- a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
> @@ -54,6 +54,16 @@ Optional properties:
> --------------------
> - enable-gpios: GPIO to use to enable/disable the regulator
>
> +- pwm-regulator-voltage-ramp-time-us: Integer, voltage ramp time in
This is a really long name. Drop the 'pwm-regulator-' part as it is
redundant. The fact that it is PWM reg specific is captured as it is
documented that way.
Rob
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.