* Re: [PATCH] drm/i915: fix definition of the DRM_IOCTL_I915_GET_SPRITE_COLORKEY ioctl
From: Jani Nikula @ 2015-03-27 6:39 UTC (permalink / raw)
To: Tommi Rantala, Daniel Vetter
Cc: David Airlie, linux-api, intel-gfx, dri-devel, Barnes, Jesse
In-Reply-To: <1427399236-14012-1-git-send-email-tt.rantala@gmail.com>
On Thu, 26 Mar 2015, Tommi Rantala <tt.rantala@gmail.com> wrote:
> Fix definition of the DRM_IOCTL_I915_GET_SPRITE_COLORKEY ioctl, so that it
> is different from the DRM_IOCTL_I915_SET_SPRITE_COLORKEY ioctl.
>
> Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Whoa. Broken since its introduction in
commit 8ea30864229e54b01ac0e9fe88c4b733a940ec4e
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Tue Jan 3 08:05:39 2012 -0800
drm/i915: add color key support v4
Cc: stable@vger.kernel.org
BR,
Jani.
> ---
> include/uapi/drm/i915_drm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 6eed16b..0e9c835 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -270,7 +270,7 @@ typedef struct _drm_i915_sarea {
> #define DRM_IOCTL_I915_OVERLAY_PUT_IMAGE DRM_IOW(DRM_COMMAND_BASE + DRM_I915_OVERLAY_PUT_IMAGE, struct drm_intel_overlay_put_image)
> #define DRM_IOCTL_I915_OVERLAY_ATTRS DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_OVERLAY_ATTRS, struct drm_intel_overlay_attrs)
> #define DRM_IOCTL_I915_SET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_SET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
> -#define DRM_IOCTL_I915_GET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_SET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
> +#define DRM_IOCTL_I915_GET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
> #define DRM_IOCTL_I915_GEM_WAIT DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_WAIT, struct drm_i915_gem_wait)
> #define DRM_IOCTL_I915_GEM_CONTEXT_CREATE DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_GEM_CONTEXT_CREATE, struct drm_i915_gem_context_create)
> #define DRM_IOCTL_I915_GEM_CONTEXT_DESTROY DRM_IOW (DRM_COMMAND_BASE + DRM_I915_GEM_CONTEXT_DESTROY, struct drm_i915_gem_context_destroy)
> --
> 2.1.0
>
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH net-next] tc: bpf: generalize pedit action
From: Jiri Pirko @ 2015-03-27 6:38 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Daniel Borkmann, Jamal Hadi Salim,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1427424837-7757-1-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
Fri, Mar 27, 2015 at 03:53:57AM CET, ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org wrote:
>existing TC action 'pedit' can munge any bits of the packet.
>Generalize it for use in bpf programs attached as cls_bpf and act_bpf via
>bpf_skb_store_bytes() helper function.
>
>Signed-off-by: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
This looks fine to me. Great stuff.
Reviewed-by: Jiri Pirko <jiri-rHqAuBHg3fBzbRFIqnYvSA@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
From: Andrew Morton @ 2015-03-27 6:08 UTC (permalink / raw)
To: Volker.Lendecke-3ekOc4rQMZmzQB+pC5nmwQ
Cc: Milosz Tanski, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Christoph Hellwig, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-aio-Bw31MaZKKs3YtjvyW6yDsg, Mel Gorman, Tejun Heo,
Jeff Moyer, Theodore Ts'o, Al Viro,
linux-api-u79uwXL29TY76Z2rM5mHXA, Michael Kerrisk,
linux-arch-u79uwXL29TY76Z2rM5mHXA, Dave Chinner
In-Reply-To: <E1YbN1J-0084qO-3s-dqLtpHMqGvUyWpdLl23E4A@public.gmane.org>
On Fri, 27 Mar 2015 06:41:25 +0100 Volker Lendecke <Volker.Lendecke-3ekOc4rQMZmzQB+pC5nmwQ@public.gmane.org> wrote:
> On Thu, Mar 26, 2015 at 08:28:24PM -0700, Andrew Morton wrote:
> > A thing which bugs me about pread2() is that it is specifically
> > tailored to applications which are able to use a partial read result.
> > ie, by sending it over the network.
>
> Can you explain what you mean by this? Samba gets a pread
> request from a client for some bytes. The client will be
> confused when we send less than requested although the file
> is long enough to satisfy all.
Well it was my assumption that samba would be able to do something
useful with a partial read - pread() is allowed to return less than requested.
If it isn't the case that samba can use the partial read result then
what does it do? It has to save the partial data, then do the
additional IO? That's pretty clunky compared to
if (it's all in cache)
read it all now
else
ask a worker thread to read it all
> > And of course fincore could be used by Samba etc to avoid blocking on
> > reads. It wouldn't perform quite as well as pread2(), but I bet it's
> > good enough.
> >
> > Bottom line: with pread2() there's still a need for fincore(), but with
> > fincore() there probably isn't a need for pread2().
>
> fincore would be a second syscall per pread, and it is not
> atomic. I've had discussions with MIPS based vendors who
> are worried about every single syscall. This is the #1
> hottest code path in Samba.
Bear in mind that these operations involve physical IO and large
memcpy's. Yes, a fincore() approach will consume more CPU but the
additional overhead will be relatively small.
Tradeoffs are involved, and it may turn out that choosing a more
flexible and powerful interface which is somewhat more CPU intensive is
a better decision. It's hard to say until this is quantified (ie:
measured).
> > And I'm doubtful about claims that it absolutely has to be non-blocking
> > 100% of the time. I bet that 99.99% is good enough. A fincore()
> > option to run mark_page_accessed() against present pages would help
> > with the race-with-reclaim situation.
>
> If you can make sure that after an fincore the pages remain
> in memory for x milliseconds the atomicity concern might go
> away.
It won't be guaranteed that the fincore()+pread() will be
non-blocking. But blocking will be very rare. I don't know whether
the additional expense of activating the pages within fincore() is
justified - needs runtime testing.
^ permalink raw reply
* Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
From: Volker Lendecke @ 2015-03-27 5:41 UTC (permalink / raw)
To: Andrew Morton
Cc: Milosz Tanski, linux-kernel, Christoph Hellwig, linux-fsdevel,
linux-aio, Mel Gorman, Tejun Heo, Jeff Moyer, Theodore Ts'o,
Al Viro, linux-api, Michael Kerrisk, linux-arch, Dave Chinner
In-Reply-To: <20150326202824.65d03787.akpm@linux-foundation.org>
On Thu, Mar 26, 2015 at 08:28:24PM -0700, Andrew Morton wrote:
> A thing which bugs me about pread2() is that it is specifically
> tailored to applications which are able to use a partial read result.
> ie, by sending it over the network.
Can you explain what you mean by this? Samba gets a pread
request from a client for some bytes. The client will be
confused when we send less than requested although the file
is long enough to satisfy all.
> And of course fincore could be used by Samba etc to avoid blocking on
> reads. It wouldn't perform quite as well as pread2(), but I bet it's
> good enough.
>
> Bottom line: with pread2() there's still a need for fincore(), but with
> fincore() there probably isn't a need for pread2().
fincore would be a second syscall per pread, and it is not
atomic. I've had discussions with MIPS based vendors who
are worried about every single syscall. This is the #1
hottest code path in Samba.
> And I'm doubtful about claims that it absolutely has to be non-blocking
> 100% of the time. I bet that 99.99% is good enough. A fincore()
> option to run mark_page_accessed() against present pages would help
> with the race-with-reclaim situation.
If you can make sure that after an fincore the pages remain
in memory for x milliseconds the atomicity concern might go
away.
Volker
--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt@sernet.de
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
From: Andrew Morton @ 2015-03-27 3:28 UTC (permalink / raw)
To: Milosz Tanski
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Christoph Hellwig,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-aio-Bw31MaZKKs3YtjvyW6yDsg, Mel Gorman, Volker Lendecke,
Tejun Heo, Jeff Moyer, Theodore Ts'o, Al Viro,
linux-api-u79uwXL29TY76Z2rM5mHXA, Michael Kerrisk,
linux-arch-u79uwXL29TY76Z2rM5mHXA, Dave Chinner
In-Reply-To: <cover.1426528417.git.milosz-B5zB6C1i6pkAvxtiuMwx3w@public.gmane.org>
On Mon, 16 Mar 2015 14:27:10 -0400 Milosz Tanski <milosz-B5zB6C1i6pkAvxtiuMwx3w@public.gmane.org> wrote:
> This patchset introduces two new syscalls preadv2 and pwritev2. They are the
> same syscalls as preadv and pwrite but with a flag argument. Additionally,
> preadv2 implements an extra RWF_NONBLOCK flag.
I still don't understand why pwritev() exists. We discussed this last
time but it seems nothing has changed. I'm not seeing here an adequate
description of why it exists nor a justification for its addition.
Also, why are we adding new syscalls instead of using O_NONBLOCK? I
think this might have been discussed before, but the changelogs haven't
been updated to reflect it - please do so.
> The RWF_NONBLOCK flag in preadv2 introduces an ability to perform a
> non-blocking read from regular files in buffered IO mode. This works by only
> for those filesystems that have data in the page cache.
>
> We discussed these changes at this year's LSF/MM summit in Boston. More details
> on the Samba use case, the numbers, and presentation is available at this link:
> https://lists.samba.org/archive/samba-technical/2015-March/106290.html
https://drive.google.com/file/d/0B3maCn0jCvYncndGbXJKbGlhejQ/view?usp=sharing
talks about "sync" but I can't find a description of what this actually
is. It appears to perform better than anything else?
> Background:
>
> Using a threadpool to emulate non-blocking operations on regular buffered
> files is a common pattern today (samba, libuv, etc...) Applications split the
> work between network bound threads (epoll) and IO threadpool. Not every
> application can use sendfile syscall (TLS / post-processing).
>
> This common pattern leads to increased request latency. Latency can be due to
> additional synchronization between the threads or fast (cached data) request
> stuck behind slow request (large / uncached data).
>
> The preadv2 syscall with RWF_NONBLOCK lets userspace applications bypass
> enqueuing operation in the threadpool if it's already available in the
> pagecache.
A thing which bugs me about pread2() is that it is specifically
tailored to applications which are able to use a partial read result.
ie, by sending it over the network.
But it is not very useful for the class of applications which require
that the entire read be completed before they can proceed with using
the data. Such applications will have to run pread2(), see the short
result, save away the partial data, perform some IO then fetch the
remaining data then proceed. By this time, the original partially read
data may have fallen out of CPU cache (or we're on a different CPU) and
the data will need to be fetched into cache a second time.
Such applications would be better served if they were able to query for
pagecache presence _before_ doing the big copy_to_user(), so they can
ensure that all the data is in pagecache before copying it in. ie:
fincore(), perhaps supported by a synchronous POSIX_FADV_WILLNEED.
And of course fincore could be used by Samba etc to avoid blocking on
reads. It wouldn't perform quite as well as pread2(), but I bet it's
good enough.
Bottom line: with pread2() there's still a need for fincore(), but with
fincore() there probably isn't a need for pread2().
And (again) we've discussed this before, but the patchset gets resent
as if nothing had happened.
And I'm doubtful about claims that it absolutely has to be non-blocking
100% of the time. I bet that 99.99% is good enough. A fincore()
option to run mark_page_accessed() against present pages would help
with the race-with-reclaim situation.
^ permalink raw reply
* Re: [PATCH v5] Add virtio-input driver.
From: Rusty Russell @ 2015-03-27 2:56 UTC (permalink / raw)
To: Michael S. Tsirkin, Gerd Hoffmann
Cc: virtio-dev-sDuHXQ4OtrM4h7I2RyI4rWD2FQJk+8+b,
virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
David Herrmann, Dmitry Torokhov, open list, open list:ABI/API,
Denys Vlasenko
In-Reply-To: <20150326130644-mutt-send-email-mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
"Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> On Thu, Mar 26, 2015 at 11:49:25AM +0100, Gerd Hoffmann wrote:
>> virtio-input is basically evdev-events-over-virtio, so this driver isn't
>> much more than reading configuration from config space and forwarding
>> incoming events to the linux input layer.
>>
>> Signed-off-by: Gerd Hoffmann <kraxel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>
> Still a bit worried about using input.h as host/guest
> interface (can't we use some formal standard, e.g. USB HID?),
> but I'll let Rusty decide that.
I like the simplicity, and this API is pretty well proven.
Since this is under drivers/virtio rather than drivers/input, I've
applied it to my tree.
I have a dream where Denys Vlasenko adds this and the virtio gl device
to lguest, and we have X running under lguest :)
Applied!
Rusty.
^ permalink raw reply
* [PATCH net-next] tc: bpf: generalize pedit action
From: Alexei Starovoitov @ 2015-03-27 2:53 UTC (permalink / raw)
To: David S. Miller
Cc: Daniel Borkmann, Jiri Pirko, Jamal Hadi Salim,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
existing TC action 'pedit' can munge any bits of the packet.
Generalize it for use in bpf programs attached as cls_bpf and act_bpf via
bpf_skb_store_bytes() helper function.
Signed-off-by: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
---
pedit is limited to 32-bit masked rewrites. Here let it be flexible.
ptr = skb_header_pointer(skb, offset, len, buf);
memcpy(ptr, from, len);
if (ptr == buf)
skb_store_bits(skb, offset, ptr, len);
^^ logic is the same as in pedit.
shifts, mask, invert style of rewrite is easily done by the program.
Just like arbitrary parsing of the packet and applying rewrites on demand.
include/linux/bpf.h | 1 +
include/uapi/linux/bpf.h | 1 +
kernel/bpf/verifier.c | 2 ++
net/core/filter.c | 71 ++++++++++++++++++++++++++++++++++++++++++++--
4 files changed, 73 insertions(+), 2 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 280a315de8d6..d5cda067115a 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -59,6 +59,7 @@ enum bpf_arg_type {
ARG_PTR_TO_STACK, /* any pointer to eBPF program stack */
ARG_CONST_STACK_SIZE, /* number of bytes accessed from stack */
+ ARG_PTR_TO_CTX, /* pointer to context */
ARG_ANYTHING, /* any (initialized) argument is ok */
};
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 27dc4ec58840..74aab6e0d964 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -168,6 +168,7 @@ enum bpf_func_id {
BPF_FUNC_map_delete_elem, /* int map_delete_elem(&map, &key) */
BPF_FUNC_get_prandom_u32, /* u32 prandom_u32(void) */
BPF_FUNC_get_smp_processor_id, /* u32 raw_smp_processor_id(void) */
+ BPF_FUNC_skb_store_bytes, /* int skb_store_bytes(skb, offset, from, len) */
__BPF_FUNC_MAX_ID,
};
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 0e714f799ec0..630a7bac1e51 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -773,6 +773,8 @@ static int check_func_arg(struct verifier_env *env, u32 regno,
expected_type = CONST_IMM;
} else if (arg_type == ARG_CONST_MAP_PTR) {
expected_type = CONST_PTR_TO_MAP;
+ } else if (arg_type == ARG_PTR_TO_CTX) {
+ expected_type = PTR_TO_CTX;
} else {
verbose("unsupported arg_type %d\n", arg_type);
return -EFAULT;
diff --git a/net/core/filter.c b/net/core/filter.c
index 32f43c59908c..444a07e4f68d 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -1175,6 +1175,56 @@ int sk_attach_bpf(u32 ufd, struct sock *sk)
return 0;
}
+static u64 bpf_skb_store_bytes(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
+{
+ struct sk_buff *skb = (struct sk_buff *) (long) r1;
+ unsigned int offset = (unsigned int) r2;
+ void *from = (void *) (long) r3;
+ unsigned int len = (unsigned int) r4;
+ char buf[16];
+ void *ptr;
+
+ /* bpf verifier guarantees that:
+ * 'from' pointer points to bpf program stack
+ * 'len' bytes of it were initialized
+ * 'len' > 0
+ * 'skb' is a valid pointer to 'struct sk_buff'
+ *
+ * so check for invalid 'offset' and too large 'len'
+ */
+ if (offset > 0xffff || len > sizeof(buf))
+ return -EFAULT;
+
+ if (skb_cloned(skb) && !skb_clone_writable(skb, offset + len))
+ return -EFAULT;
+
+ ptr = skb_header_pointer(skb, offset, len, buf);
+ if (unlikely(!ptr))
+ return -EFAULT;
+
+ skb_postpull_rcsum(skb, ptr, len);
+
+ memcpy(ptr, from, len);
+
+ if (ptr == buf)
+ /* skb_store_bits cannot return -EFAULT here */
+ skb_store_bits(skb, offset, ptr, len);
+
+ if (skb->ip_summed == CHECKSUM_COMPLETE)
+ skb->csum = csum_add(skb->csum, csum_partial(ptr, len, 0));
+ return 0;
+}
+
+const struct bpf_func_proto bpf_skb_store_bytes_proto = {
+ .func = bpf_skb_store_bytes,
+ .gpl_only = false,
+ .ret_type = RET_INTEGER,
+ .arg1_type = ARG_PTR_TO_CTX,
+ .arg2_type = ARG_ANYTHING,
+ .arg3_type = ARG_PTR_TO_STACK,
+ .arg4_type = ARG_CONST_STACK_SIZE,
+};
+
static const struct bpf_func_proto *
sk_filter_func_proto(enum bpf_func_id func_id)
{
@@ -1194,6 +1244,17 @@ sk_filter_func_proto(enum bpf_func_id func_id)
}
}
+static const struct bpf_func_proto *
+tc_cls_act_func_proto(enum bpf_func_id func_id)
+{
+ switch (func_id) {
+ case BPF_FUNC_skb_store_bytes:
+ return &bpf_skb_store_bytes_proto;
+ default:
+ return sk_filter_func_proto(func_id);
+ }
+}
+
static bool sk_filter_is_valid_access(int off, int size,
enum bpf_access_type type)
{
@@ -1270,18 +1331,24 @@ static const struct bpf_verifier_ops sk_filter_ops = {
.convert_ctx_access = sk_filter_convert_ctx_access,
};
+static const struct bpf_verifier_ops tc_cls_act_ops = {
+ .get_func_proto = tc_cls_act_func_proto,
+ .is_valid_access = sk_filter_is_valid_access,
+ .convert_ctx_access = sk_filter_convert_ctx_access,
+};
+
static struct bpf_prog_type_list sk_filter_type __read_mostly = {
.ops = &sk_filter_ops,
.type = BPF_PROG_TYPE_SOCKET_FILTER,
};
static struct bpf_prog_type_list sched_cls_type __read_mostly = {
- .ops = &sk_filter_ops,
+ .ops = &tc_cls_act_ops,
.type = BPF_PROG_TYPE_SCHED_CLS,
};
static struct bpf_prog_type_list sched_act_type __read_mostly = {
- .ops = &sk_filter_ops,
+ .ops = &tc_cls_act_ops,
.type = BPF_PROG_TYPE_SCHED_ACT,
};
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
From: Milosz Tanski @ 2015-03-27 2:29 UTC (permalink / raw)
To: Christoph Hellwig
Cc: LKML, linux-fsdevel@vger.kernel.org, linux-aio@kvack.org,
Mel Gorman, Volker Lendecke, Tejun Heo, Jeff Moyer,
Theodore Ts'o, Al Viro, Linux API, Michael Kerrisk,
linux-arch, Dave Chinner, Andrew Morton
In-Reply-To: <CANP1eJGpgXUv626KQb6kduJgMaOzU5hH9GLGBM-QSVUBagoG8w@mail.gmail.com>
On Thu, Mar 26, 2015 at 3:12 PM, Milosz Tanski <milosz@adfin.com> wrote:
> On Thu, Mar 26, 2015 at 7:55 AM, Christoph Hellwig <hch@infradead.org> wrote:
>>
>> On Mon, Mar 16, 2015 at 02:27:10PM -0400, Milosz Tanski wrote:
>> > This patchset introduces two new syscalls preadv2 and pwritev2. They are the
>> > same syscalls as preadv and pwrite but with a flag argument. Additionally,
>> > preadv2 implements an extra RWF_NONBLOCK flag.
>>
>> There was some arugment that we just don't wait and don't have the
>> classic unix "blocking" semantics. Maybe it's time to bite the bullet
>> and rename it to RWF_DONTWAIT? (I personally dont really care).
>
>
> Sure. It is in line with the MSG_DONTWAIT flag for sendmsg() which
> this whole idea is based on anyways.
Okay, It's RWF_DONTWAIT now. I also split it into two RWF_DONTWAIT for
the userspace API and IOCB_DONTWAIT that goes into kiocb->ki_flags.
>
>>
>>
>> Second this probably needs to be on top of Al's for-next tree:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/viro/vfs.git/log/?h=for-next
>>
>> Note that this has a flags field in struct kiocb, so we could just use
>> that for the flags.
>
>
> Okay I started rebasing the patches on-top of that. I did see that
> there is a new flags field "ki_flags". I see that there's already a
> IOCB_EVENTFD flag.
>
> Did you see you Andres' question about making the flags a enum? I
> usually wouldn't do that, because C++ is stronger when it comes enums,
> you can't combine them then assignment them to an enum without a cast.
> But in the kernel this doesn't matter.
>
>>
>>
>> Otherwise this version look fine to me, let's get it merged!
>>
>> Al, are yo ready to pick this up? I'd hate to miss another merge
>> window.
>
>
> Just got back from vacation today, I'll try to get this out before the
> end of the week. I also have to make some adjustments to xfs-tests (to
> push preadv2 into xfs_io).
You'll see the patches and the pull request against viro/for-next
branch tomorrow. The rebase was a bit of work since you guys changed a
fair amount of stuff.
>
>
> --
> Milosz Tanski
> CTO
> 16 East 34th Street, 15th floor
> New York, NY 10016
>
> p: 646-253-9055
> e: milosz@adfin.com
P.S: Sorry for the double email / HTML spam. I'm not a my primary
computer and apparently gmail randomly forgets that a thread is plain
text only. Thanks gmail.
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: milosz@adfin.com
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
From: Milosz Tanski @ 2015-03-27 2:26 UTC (permalink / raw)
To: Christoph Hellwig
Cc: LKML, linux-fsdevel@vger.kernel.org, linux-aio@kvack.org,
Mel Gorman, Volker Lendecke, Tejun Heo, Jeff Moyer,
Theodore Ts'o, Al Viro, Linux API, Michael Kerrisk,
linux-arch, Dave Chinner, Andrew Morton
In-Reply-To: <CANP1eJGpgXUv626KQb6kduJgMaOzU5hH9GLGBM-QSVUBagoG8w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2355 bytes --]
On Thu, Mar 26, 2015 at 3:12 PM, Milosz Tanski <milosz@adfin.com> wrote:
> On Thu, Mar 26, 2015 at 7:55 AM, Christoph Hellwig <hch@infradead.org>
> wrote:
> >
> > On Mon, Mar 16, 2015 at 02:27:10PM -0400, Milosz Tanski wrote:
> > > This patchset introduces two new syscalls preadv2 and pwritev2. They
> are the
> > > same syscalls as preadv and pwrite but with a flag argument.
> Additionally,
> > > preadv2 implements an extra RWF_NONBLOCK flag.
> >
> > There was some arugment that we just don't wait and don't have the
> > classic unix "blocking" semantics. Maybe it's time to bite the bullet
> > and rename it to RWF_DONTWAIT? (I personally dont really care).
>
>
> Sure. It is in line with the MSG_DONTWAIT flag for sendmsg() which
> this whole idea is based on anyways.
>
Okay, It's RWF_DONTWAIT now. I also split it into two RWF_DONTWAIT for the
userspace API and IOCB_DONTWAIT that goes into kiocb->ki_flags.
>
> >
> >
> > Second this probably needs to be on top of Al's for-next tree:
> >
> >
> https://git.kernel.org/cgit/linux/kernel/git/viro/vfs.git/log/?h=for-next
> >
> > Note that this has a flags field in struct kiocb, so we could just use
> > that for the flags.
>
>
> Okay I started rebasing the patches on-top of that. I did see that
> there is a new flags field "ki_flags". I see that there's already a
> IOCB_EVENTFD flag.
>
> Did you see you Andres' question about making the flags a enum? I
> usually wouldn't do that, because C++ is stronger when it comes enums,
> you can't combine them then assignment them to an enum without a cast.
> But in the kernel this doesn't matter.
>
> >
> >
> > Otherwise this version look fine to me, let's get it merged!
> >
> > Al, are yo ready to pick this up? I'd hate to miss another merge
> > window.
>
>
> Just got back from vacation today, I'll try to get this out before the
> end of the week. I also have to make some adjustments to xfs-tests (to
> push preadv2 into xfs_io).
>
You'll see the patches and the pull request against viro/for-next
branch tomorrow. The rebase was a bit of work since you guys changed a fair
amount of stuff.
>
>
> --
> Milosz Tanski
> CTO
> 16 East 34th Street, 15th floor
> New York, NY 10016
>
> p: 646-253-9055
> e: milosz@adfin.com
>
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: milosz@adfin.com
[-- Attachment #2: Type: text/html, Size: 3992 bytes --]
^ permalink raw reply
* Re: [patch 2/2] mm, selftests: test return value of munmap for MAP_HUGETLB memory
From: Michael Ellerman @ 2015-03-26 23:52 UTC (permalink / raw)
To: David Rientjes
Cc: Andrew Morton, Jonathan Corbet, Davide Libenzi, Luiz Capitulino,
Shuah Khan, Hugh Dickins, Andrea Arcangeli, Joern Engel,
Jianguo Wu, Eric B Munson, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.DEB.2.10.1503261623280.20009-X6Q0R45D7oAcqpCFd4KODRPsWskHk0ljAL8bYrjMMd8@public.gmane.org>
On Thu, 2015-03-26 at 16:23 -0700, David Rientjes wrote:
> When MAP_HUGETLB memory is unmapped, the length must be hugepage aligned,
> otherwise it fails with -EINVAL.
>
> All tests currently behave correctly, but it's better to explcitly test
> the return value for completeness and document the requirement,
> especially if users copy map_hugetlb.c as a sample implementation.
>
> Signed-off-by: David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> ---
> tools/testing/selftests/powerpc/mm/hugetlb_vs_thp_test.c | 8 ++++++--
>
> diff --git a/tools/testing/selftests/powerpc/mm/hugetlb_vs_thp_test.c b/tools/testing/selftests/powerpc/mm/hugetlb_vs_thp_test.c
> --- a/tools/testing/selftests/powerpc/mm/hugetlb_vs_thp_test.c
> +++ b/tools/testing/selftests/powerpc/mm/hugetlb_vs_thp_test.c
> @@ -21,9 +21,13 @@ static int test_body(void)
> * Typically the mmap will fail because no huge pages are
> * allocated on the system. But if there are huge pages
> * allocated the mmap will succeed. That's fine too, we just
> - * munmap here before continuing.
> + * munmap here before continuing. munmap() length of
> + * MAP_HUGETLB memory must be hugepage aligned.
> */
> - munmap(addr, SIZE);
> + if (munmap(addr, SIZE)) {
> + perror("munmap");
> + return 1;
> + }
> }
>
> p = mmap(addr, SIZE, PROT_READ | PROT_WRITE,
Acked-by: Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
cheers
^ permalink raw reply
* [patch 2/2] mm, selftests: test return value of munmap for MAP_HUGETLB memory
From: David Rientjes @ 2015-03-26 23:23 UTC (permalink / raw)
To: Andrew Morton
Cc: Jonathan Corbet, Davide Libenzi, Luiz Capitulino, Shuah Khan,
Hugh Dickins, Andrea Arcangeli, Joern Engel, Jianguo Wu,
Eric B Munson, linux-mm, linux-kernel, linux-api, linux-doc
In-Reply-To: <alpine.DEB.2.10.1503261621570.20009@chino.kir.corp.google.com>
When MAP_HUGETLB memory is unmapped, the length must be hugepage aligned,
otherwise it fails with -EINVAL.
All tests currently behave correctly, but it's better to explcitly test
the return value for completeness and document the requirement,
especially if users copy map_hugetlb.c as a sample implementation.
Signed-off-by: David Rientjes <rientjes@google.com>
---
tools/testing/selftests/powerpc/mm/hugetlb_vs_thp_test.c | 8 ++++++--
tools/testing/selftests/vm/hugetlbfstest.c | 4 +++-
tools/testing/selftests/vm/map_hugetlb.c | 6 +++++-
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/powerpc/mm/hugetlb_vs_thp_test.c b/tools/testing/selftests/powerpc/mm/hugetlb_vs_thp_test.c
--- a/tools/testing/selftests/powerpc/mm/hugetlb_vs_thp_test.c
+++ b/tools/testing/selftests/powerpc/mm/hugetlb_vs_thp_test.c
@@ -21,9 +21,13 @@ static int test_body(void)
* Typically the mmap will fail because no huge pages are
* allocated on the system. But if there are huge pages
* allocated the mmap will succeed. That's fine too, we just
- * munmap here before continuing.
+ * munmap here before continuing. munmap() length of
+ * MAP_HUGETLB memory must be hugepage aligned.
*/
- munmap(addr, SIZE);
+ if (munmap(addr, SIZE)) {
+ perror("munmap");
+ return 1;
+ }
}
p = mmap(addr, SIZE, PROT_READ | PROT_WRITE,
diff --git a/tools/testing/selftests/vm/hugetlbfstest.c b/tools/testing/selftests/vm/hugetlbfstest.c
--- a/tools/testing/selftests/vm/hugetlbfstest.c
+++ b/tools/testing/selftests/vm/hugetlbfstest.c
@@ -34,6 +34,7 @@ static void do_mmap(int fd, int extra_flags, int unmap)
int *p;
int flags = MAP_PRIVATE | MAP_POPULATE | extra_flags;
u64 before, after;
+ int ret;
before = read_rss();
p = mmap(NULL, length, PROT_READ | PROT_WRITE, flags, fd, 0);
@@ -44,7 +45,8 @@ static void do_mmap(int fd, int extra_flags, int unmap)
!"rss didn't grow as expected");
if (!unmap)
return;
- munmap(p, length);
+ ret = munmap(p, length);
+ assert(!ret || !"munmap returned an unexpected error");
after = read_rss();
assert(llabs(after - before) < 0x40000 ||
!"rss didn't shrink as expected");
diff --git a/tools/testing/selftests/vm/map_hugetlb.c b/tools/testing/selftests/vm/map_hugetlb.c
--- a/tools/testing/selftests/vm/map_hugetlb.c
+++ b/tools/testing/selftests/vm/map_hugetlb.c
@@ -73,7 +73,11 @@ int main(void)
write_bytes(addr);
ret = read_bytes(addr);
- munmap(addr, LENGTH);
+ /* munmap() length of MAP_HUGETLB memory must be hugepage aligned */
+ if (munmap(addr, LENGTH)) {
+ perror("munmap");
+ exit(1);
+ }
return ret;
}
^ permalink raw reply
* [patch 1/2] mm, doc: cleanup and clarify munmap behavior for hugetlb memory
From: David Rientjes @ 2015-03-26 23:23 UTC (permalink / raw)
To: Andrew Morton, Jonathan Corbet
Cc: Davide Libenzi, Luiz Capitulino, Shuah Khan, Hugh Dickins,
Andrea Arcangeli, Joern Engel, Jianguo Wu, Eric B Munson,
linux-mm, linux-kernel, linux-api, linux-doc
munmap(2) of hugetlb memory requires a length that is hugepage aligned,
otherwise it may fail. Add this to the documentation.
This also cleans up the documentation and separates it into logical
units: one part refers to MAP_HUGETLB and another part refers to
requirements for shared memory segments.
Signed-off-by: David Rientjes <rientjes@google.com>
---
Documentation/vm/hugetlbpage.txt | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt
--- a/Documentation/vm/hugetlbpage.txt
+++ b/Documentation/vm/hugetlbpage.txt
@@ -289,15 +289,20 @@ file systems, write system calls are not.
Regular chown, chgrp, and chmod commands (with right permissions) could be
used to change the file attributes on hugetlbfs.
-Also, it is important to note that no such mount command is required if the
+Also, it is important to note that no such mount command is required if
applications are going to use only shmat/shmget system calls or mmap with
-MAP_HUGETLB. Users who wish to use hugetlb page via shared memory segment
-should be a member of a supplementary group and system admin needs to
-configure that gid into /proc/sys/vm/hugetlb_shm_group. It is possible for
-same or different applications to use any combination of mmaps and shm*
-calls, though the mount of filesystem will be required for using mmap calls
-without MAP_HUGETLB. For an example of how to use mmap with MAP_HUGETLB see
-map_hugetlb.c.
+MAP_HUGETLB. For an example of how to use mmap with MAP_HUGETLB see map_hugetlb
+below.
+
+Users who wish to use hugetlb memory via shared memory segment should be a
+member of a supplementary group and system admin needs to configure that gid
+into /proc/sys/vm/hugetlb_shm_group. It is possible for same or different
+applications to use any combination of mmaps and shm* calls, though the mount of
+filesystem will be required for using mmap calls without MAP_HUGETLB.
+
+When using munmap(2) to unmap hugetlb memory, the length specified must be
+hugepage aligned, otherwise it will fail with errno set to EINVAL.
+
Examples
========
^ permalink raw reply
* Re: [virtio-dev] Re: [PATCH] Add virtio gpu driver.
From: Alex Elsayed @ 2015-03-26 22:49 UTC (permalink / raw)
To: linux-api-u79uwXL29TY76Z2rM5mHXA
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <20150326174401-mutt-send-email-mst@redhat.com>
Michael S. Tsirkin wrote:
> On Thu, Mar 26, 2015 at 04:07:16PM +0100, Gerd Hoffmann wrote:
>> Hi,
>>
>> > I don't know. This seems exactly like the kind of thing
>> > we had in mind when we added the virtio pci capability.
>> > For example, we have text in spec that requires drivers
>> > to skip unknown capabilities.
>> >
>> > And yes, if bios pokes at a specific bar then we do
>> > need to list this info in the virtio spec so this makes
>> > it an issue that is virtio related.
>>
>> Hmm, virtio-vga is a two-in-one device basically. When virtio is
>> enabled it behaves like virtio-gpu-pci, otherwise it behaves very
>> simliar to stdvga. So you need to know nothing about virtio to handle
>> the vga side, and I want keep it that way.
>>
>> When no vga compatibility is needed there always is the option to just
>> use virtio-gpu-pci instead.
>>
>> > Yes, it's not about what we put there now. It's about being able
>> > to move things about in the future without breaking guests.
>>
>> We don't have that today for stdvga, and I still fail to see what this
>> buys us.
>>
>>
>> Completely different thing crossing my mind: I think we can make
>> virtio-vga fully compatible with stdvga. stdvga has two bars, memory
>> (#0) and mmio (#2). We can make the mmio bar larger and place all the
>> virtio regions there.
>>
>
> Full compatibility with some standard sounds like a better motivation,
> yes.
I think you misunderstand; stdvga is a specific qemu device that only
provides the VGA interface.
This proposed GPU provides both the VGA interface (the BAR in question)
_and_ a virtio interface.
>>
>> I think in any case I'll go split off the vga compatibility bits to a
>> different patch (and possible a separate patch series).
>>
>> cheers,
>> Gerd
>
> Will you still need me to change core to claim specific memory only?
>
>
^ permalink raw reply
* Re: [PATCH v2 01/11] stm class: Introduce an abstraction for System Trace Module devices
From: Greg Kroah-Hartman @ 2015-03-26 22:35 UTC (permalink / raw)
To: Alexander Shishkin
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A,
pebolle-IWqWACnzNjzz+pZb47iToQ,
peter.lachner-ral2JQCrhuEAvxtiuMwx3w,
norbert.schulz-ral2JQCrhuEAvxtiuMwx3w,
keven.boell-ral2JQCrhuEAvxtiuMwx3w,
yann.fouassier-ral2JQCrhuEAvxtiuMwx3w,
laurent.fert-ral2JQCrhuEAvxtiuMwx3w,
linux-api-u79uwXL29TY76Z2rM5mHXA, Pratik Patel
In-Reply-To: <1427056381-27614-2-git-send-email-alexander.shishkin-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On Sun, Mar 22, 2015 at 10:32:51PM +0200, Alexander Shishkin wrote:
> +static struct attribute *stm_attrs[] = {
> + &dev_attr_masters.attr,
> + &dev_attr_channels.attr,
> + NULL,
> +};
> +
> +static const struct attribute_group stm_group = {
> + .attrs = stm_attrs,
> +};
> +
> +static const struct attribute_group *stm_groups[] = {
> + &stm_group,
> + NULL,
> +};
> +
ATTRIBUTE_GROUP(stm)?
> +static struct class stm_class = {
> + .name = "stm",
> + .dev_groups = stm_groups,
> +};
> +
> +static int stm_dev_match(struct device *dev, const void *data)
> +{
> + const char *name = data;
> +
> + return sysfs_streq(name, dev_name(dev));
> +}
> +
> +/**
> + * stm_find_device() - find stm device by name
> + * @buf: character buffer containing the name
> + * @len: length of the name in @buf
> + *
> + * This is called from attributes' store methods, so it will
> + * also trim the trailing newline if necessary.
Why is this needed and the device isn't the one that was just passed to
you in the attribute store method?
> +static int stm_char_open(struct inode *inode, struct file *file)
> +{
> + struct stm_file *stmf;
> + struct device *dev;
> + unsigned int major = imajor(inode);
> + int err = -ENODEV;
> +
> + dev = class_find_device(&stm_class, NULL, &major, major_match);
> + if (!dev)
> + return -ENODEV;
Where are you documenting your character devices, the major/minor usage,
and the ioctls? Is that in some other patch?
> +static long
> +stm_char_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
> +{
> + struct stm_file *stmf = file->private_data;
> + struct stm_data *stm_data = stmf->stm->data;
> + int err = -ENOTTY;
> +
> + switch (cmd) {
> + case STP_POLICY_ID_SET:
> + err = stm_char_policy_set_ioctl(stmf, (void __user *)arg);
Cast to the proper structure/type instead of void * please.
> + if (err)
> + return err;
> +
> + return stm_char_policy_get_ioctl(stmf, (void __user *)arg);
Same here.
> +
> + case STP_POLICY_ID_GET:
> + return stm_char_policy_get_ioctl(stmf, (void __user *)arg);
Same here.
> + default:
> + if (stm_data->ioctl)
> + err = stm_data->ioctl(stm_data, cmd, arg);
oh that's fun, two levels of ioctls, ugh, that makes auditing the code
hard...
> --- /dev/null
> +++ b/drivers/hwtracing/stm/stm.h
> @@ -0,0 +1,79 @@
> +/*
> + * System Trace Module (STM) infrastructure
> + * Copyright (c) 2014, Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * STM class implements generic infrastructure for System Trace Module devices
> + * as defined in MIPI STPv2 specification.
> + */
> +
> +#ifndef _CLASS_STM_H_
> +#define _CLASS_STM_H_
"_CLASS_" ?
> +
> +struct stp_policy;
> +struct stp_policy_node;
> +
> +struct stp_policy_node *
> +stp_policy_node_lookup(struct stp_policy *policy, char *s);
> +void stp_policy_unbind(struct stp_policy *policy);
> +
> +void stp_policy_node_get_ranges(struct stp_policy_node *policy_node,
> + unsigned int *mstart, unsigned int *mend,
> + unsigned int *cstart, unsigned int *cend);
> +int stp_configfs_init(void);
> +void stp_configfs_exit(void);
> +
> +struct stp_master {
> + unsigned int nr_free;
> + unsigned long chan_map[0];
> +};
> +
> +struct stm_device {
> + struct device *dev;
> + struct module *owner;
> + struct stp_policy *policy;
> + struct mutex policy_mutex;
> + int major;
> + unsigned int sw_nmasters;
> + struct stm_data *data;
> + spinlock_t link_lock;
> + struct list_head link_list;
> + /* master allocation */
> + spinlock_t mc_lock;
> + struct stp_master *masters[0];
> +};
This is a "device" so please embed struct device into the device, don't
have it as a pointer.
And modules can not "own" data, they "own" code, so why does the device
have a module pointer?
Every device gets a new major number? Is that really needed?
> +struct stm_output {
> + unsigned int master;
> + unsigned int channel;
> + unsigned int nr_chans;
> +};
> +
> +struct stm_file {
> + struct stm_device *stm;
> + struct stp_policy_node *policy_node;
> + struct stm_output output;
> +};
> +
> +struct device *stm_find_device(const char *name, size_t len);
> +
> +struct stm_source_device {
> + struct device *dev;
Same device question here, this needs to be embedded, not a pointer, to
properly control the lifecycle of this structure.
> +/**
> + * struct stp_policy_id - identification for the STP policy
> + * @size: size of the structure including real id[] length
> + * @master: assigned master
> + * @channel: first assigned channel
> + * @width: number of requested channels
> + * @id: identification string
> + *
> + * User must calculate the total size of the structure and put it into
> + * @size field, fill out the @id and desired @width. In return, kernel
> + * fills out @master, @channel and @width.
> + */
> +struct stp_policy_id {
> + __u32 size;
> + __u16 master;
> + __u16 channel;
> + __u16 width;
> + /* padding */
> + __u16 __reserved_0;
> + __u32 __reserved_1;
> + char id[0];
> +};
> +
> +#define STP_POLICY_ID_SET _IOWR('%', 0, struct stp_policy_id)
> +#define STP_POLICY_ID_GET _IOR('%', 1, struct stp_policy_id)
Where did you get those ioctl numbers from?
And why need an ioctl at all?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 01/11] stm class: Introduce an abstraction for System Trace Module devices
From: Greg Kroah-Hartman @ 2015-03-26 22:23 UTC (permalink / raw)
To: Alexander Shishkin
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A,
pebolle-IWqWACnzNjzz+pZb47iToQ,
peter.lachner-ral2JQCrhuEAvxtiuMwx3w,
norbert.schulz-ral2JQCrhuEAvxtiuMwx3w,
keven.boell-ral2JQCrhuEAvxtiuMwx3w,
yann.fouassier-ral2JQCrhuEAvxtiuMwx3w,
laurent.fert-ral2JQCrhuEAvxtiuMwx3w,
linux-api-u79uwXL29TY76Z2rM5mHXA, Pratik Patel
In-Reply-To: <1427056381-27614-2-git-send-email-alexander.shishkin-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On Sun, Mar 22, 2015 at 10:32:51PM +0200, Alexander Shishkin wrote:
> A System Trace Module (STM) is a device exporting data in System Trace
> Protocol (STP) format as defined by MIPI STP standards. Examples of such
> devices are Intel Trace Hub and Coresight STM.
>
> This abstraction provides a unified interface for software trace sources
> to send their data over an STM device to a debug host. In order to do
> that, such a trace source needs to be assigned a pair of master/channel
> identifiers that all the data from this source will be tagged with. The
> STP decoder on the debug host side will use these master/channel tags to
> distinguish different trace streams from one another inside one STP
> stream.
>
> This abstraction provides a configfs-based policy management mechanism
> for dynamic allocation of these master/channel pairs based on trace
> source-supplied string identifier. It has the flexibility of being
> defined at runtime and at the same time (provided that the policy
> definition is aligned with the decoding end) consistency.
>
> For userspace trace sources, this abstraction provides write()-based and
> mmap()-based (if the underlying stm device allows this) output mechanism.
>
> For kernel-side trace sources, we provide "stm_source" device class that
> can be connected to an stm device at run time.
>
> Cc: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Pratik Patel <pratikp-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Cc: Mathieu Poirier <mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Alexander Shishkin <alexander.shishkin-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> ---
> Documentation/ABI/testing/configfs-stp-policy | 44 ++
> Documentation/ABI/testing/sysfs-class-stm | 14 +
> Documentation/ABI/testing/sysfs-class-stm_source | 11 +
> Documentation/trace/stm.txt | 77 ++
> drivers/Kconfig | 2 +
> drivers/Makefile | 1 +
> drivers/hwtracing/stm/Kconfig | 8 +
> drivers/hwtracing/stm/Makefile | 3 +
> drivers/hwtracing/stm/core.c | 897 +++++++++++++++++++++++
> drivers/hwtracing/stm/policy.c | 467 ++++++++++++
> drivers/hwtracing/stm/stm.h | 79 ++
> include/linux/stm.h | 102 +++
> include/uapi/linux/stm.h | 47 ++
> 13 files changed, 1752 insertions(+)
> create mode 100644 Documentation/ABI/testing/configfs-stp-policy
> create mode 100644 Documentation/ABI/testing/sysfs-class-stm
> create mode 100644 Documentation/ABI/testing/sysfs-class-stm_source
> create mode 100644 Documentation/trace/stm.txt
> create mode 100644 drivers/hwtracing/stm/Kconfig
> create mode 100644 drivers/hwtracing/stm/Makefile
> create mode 100644 drivers/hwtracing/stm/core.c
> create mode 100644 drivers/hwtracing/stm/policy.c
> create mode 100644 drivers/hwtracing/stm/stm.h
> create mode 100644 include/linux/stm.h
> create mode 100644 include/uapi/linux/stm.h
>
> diff --git a/Documentation/ABI/testing/configfs-stp-policy b/Documentation/ABI/testing/configfs-stp-policy
> new file mode 100644
> index 0000000000..1c7ab3dbcd
> --- /dev/null
> +++ b/Documentation/ABI/testing/configfs-stp-policy
> @@ -0,0 +1,44 @@
> +What: /config/stp-policy
> +Date: Jan 2015
> +KernelVersion: 3.20
There is no 3.20 kernel version, and January 2015 is in the past :(
^ permalink raw reply
* Re: [PATCH v2] coresight: moving to new "hwtracing" directory
From: Greg KH @ 2015-03-26 22:22 UTC (permalink / raw)
To: Mathieu Poirier
Cc: linux, catalin.marinas, will.deacon, alexander.shishkin,
linux-kernel, peter.lachner, norbert.schulz, keven.boell,
yann.fouassier, laurent.fert, linux-api, linux-arm-kernel,
kaixu.xia, zhang.chunyan
In-Reply-To: <1426870883-12169-1-git-send-email-mathieu.poirier@linaro.org>
On Fri, Mar 20, 2015 at 11:01:23AM -0600, Mathieu Poirier wrote:
> Keeping drivers related to HW tracing on ARM, i.e coresight,
> under "drivers/coresight" doesn't make sense when other
> architectures start rolling out technologies of the same
> nature.
>
> As such creating a new "drivers/hwtracing" directory where all
> drivers of the same kind can reside, reducing namespace
> pollution under "drivers/".
>
> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> ---
> Change for v2:
> - generated patch with -M option
> ---
> MAINTAINERS | 2 +-
> arch/arm/Kconfig.debug | 2 +-
> arch/arm64/Kconfig.debug | 2 +-
> drivers/Makefile | 2 +-
> drivers/{ => hwtracing}/coresight/Kconfig | 0
> drivers/{ => hwtracing}/coresight/Makefile | 0
> drivers/{ => hwtracing}/coresight/coresight-etb10.c | 0
> drivers/{ => hwtracing}/coresight/coresight-etm-cp14.c | 0
> drivers/{ => hwtracing}/coresight/coresight-etm.h | 0
> drivers/{ => hwtracing}/coresight/coresight-etm3x.c | 0
> drivers/{ => hwtracing}/coresight/coresight-funnel.c | 0
> drivers/{ => hwtracing}/coresight/coresight-priv.h | 0
> drivers/{ => hwtracing}/coresight/coresight-replicator.c | 0
> drivers/{ => hwtracing}/coresight/coresight-tmc.c | 0
> drivers/{ => hwtracing}/coresight/coresight-tpiu.c | 0
> drivers/{ => hwtracing}/coresight/coresight.c | 0
> drivers/{ => hwtracing}/coresight/of_coresight.c | 0
> 17 files changed, 4 insertions(+), 4 deletions(-)
> rename drivers/{ => hwtracing}/coresight/Kconfig (100%)
> rename drivers/{ => hwtracing}/coresight/Makefile (100%)
> rename drivers/{ => hwtracing}/coresight/coresight-etb10.c (100%)
> rename drivers/{ => hwtracing}/coresight/coresight-etm-cp14.c (100%)
> rename drivers/{ => hwtracing}/coresight/coresight-etm.h (100%)
> rename drivers/{ => hwtracing}/coresight/coresight-etm3x.c (100%)
> rename drivers/{ => hwtracing}/coresight/coresight-funnel.c (100%)
> rename drivers/{ => hwtracing}/coresight/coresight-priv.h (100%)
> rename drivers/{ => hwtracing}/coresight/coresight-replicator.c (100%)
> rename drivers/{ => hwtracing}/coresight/coresight-tmc.c (100%)
> rename drivers/{ => hwtracing}/coresight/coresight-tpiu.c (100%)
> rename drivers/{ => hwtracing}/coresight/coresight.c (100%)
> rename drivers/{ => hwtracing}/coresight/of_coresight.c (100%)
I'm fine with this, but it doesn't apply to my tree, so I can't add it
:(
Fix it up and resend?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v5] add support for Freescale's MMA8653FC 10 bit accelerometer
From: Greg KH @ 2015-03-26 22:19 UTC (permalink / raw)
To: Martin Kepplinger
Cc: benjamin.tissoires-Re5JQEeQqe8AvxtiuMwx3w,
mark.rutland-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
Pawel.Moll-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
alexander.stein-93q1YBGzJSMe9JSWTWOYM3xStJ4P+DSV,
hadess-0MeiytkfxGOsTnJN9+BGXg,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-api-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Martin Kepplinger,
Christoph Muellner
In-Reply-To: <1426937164-10997-1-git-send-email-martink-1KBjaw7Xf1+zQB+pC5nmwQ@public.gmane.org>
On Sat, Mar 21, 2015 at 12:26:04PM +0100, Martin Kepplinger wrote:
> From: Martin Kepplinger <martin.kepplinger-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
>
> The MMA8653FC is a low-power, three-axis, capacitive micromachined
> accelerometer with 10 bits of resolution with flexible user-programmable
> options.
>
> Embedded interrupt functions enable overall power savings, by relieving the
> host processor from continuously polling data, for example using the poll()
> system call.
>
> The device can be configured to generate wake-up interrupt signals from any
> combination of the configurable embedded functions, enabling the MMA8653FC
> to monitor events while remaining in a low-power mode during periods of
> inactivity.
>
> This driver provides devicetree properties to program the device's behaviour
> and a simple, tested and documented sysfs interface. The data sheet and more
> information is available on Freescale's website.
>
> Signed-off-by: Martin Kepplinger <martin.kepplinger-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
> Signed-off-by: Christoph Muellner <christoph.muellner-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
> ---
>
> Still, I was missing the drivers/staging Makefile addition. This applies and
> builds automatically.
You sent 4 different copies of a "v5" patch, which kind of defeats the
whole purpose of a "v" number...
All of them now deleted from my todo queue, get it together and send a
correct one, properly numbered.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v3 10/15] serial: stm32-usart: Add STM32 USART Driver
From: Maxime Coquelin @ 2015-03-26 22:05 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Peter Hurley, Uwe Kleine-König, Andreas Färber,
Geert Uytterhoeven, Rob Herring, Philipp Zabel, Linus Walleij,
Arnd Bergmann, Stefan Agner, Peter Meerwald, Paul Bolle,
Jonathan Corbet, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Daniel Lezcano, Thomas Gleixner, Greg Kroah-Hartman,
Jiri Slaby, Andrew Morton, David S. Miller
In-Reply-To: <20150326154618.GO8656@n2100.arm.linux.org.uk>
2015-03-26 16:46 GMT+01:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Tue, Mar 24, 2015 at 02:23:38PM -0400, Peter Hurley wrote:
>> Hi Maxime,
>>
>> On 03/12/2015 05:55 PM, Maxime Coquelin wrote:
>> > +static unsigned int stm32_get_mctrl(struct uart_port *port)
>> > +{
>> > + /*
>> > + * This routine is used for geting signals of: DTR, DCD, DSR, RI,
>> > + * and CTS/RTS
>
> It's also worth noting that this comment is wrong. This is used to get
> the state of DCD, DSR, RI and CTS. DTR and RTS are *not* included
> because the core tracks their state.
OK, thanks for pointing this.
I will fix the comment in the v4.
>
> ...
>
>> > + stm32port->clk = devm_clk_get(&pdev->dev, NULL);
>> > +
>> > + if (WARN_ON(IS_ERR(stm32port->clk)))
>>
>> Do you really need a stack trace here? Could this be dev_err() instead?
>>
>> > + return -EINVAL;
>
> Also, propagate the error code.
Ok.
>
>> > +
>> > + /* ensure that clk rate is correct by enabling the clk */
>> > + clk_prepare_enable(stm32port->clk);
>
> And remember to check the return value of clk_prepare_enable().
I will.
Thanks for the review,
Maxime
>
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.
^ permalink raw reply
* Re: [PATCH v3 10/15] serial: stm32-usart: Add STM32 USART Driver
From: Maxime Coquelin @ 2015-03-26 22:03 UTC (permalink / raw)
To: Peter Hurley
Cc: Uwe Kleine-König, Andreas Färber, Geert Uytterhoeven,
Rob Herring, Philipp Zabel, Linus Walleij, Arnd Bergmann,
Stefan Agner, Peter Meerwald, Paul Bolle, Jonathan Corbet,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King,
Daniel Lezcano, Thomas Gleixner, Greg Kroah-Hartman, Jiri Slaby,
Andrew Morton, David S. Miller
In-Reply-To: <5511ABAA.2010303@hurleysoftware.com>
HI Peter
2015-03-24 19:23 GMT+01:00 Peter Hurley <peter@hurleysoftware.com>:
> Hi Maxime,
>
> On 03/12/2015 05:55 PM, Maxime Coquelin wrote:
>> From: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>
>> This drivers adds support to the STM32 USART controller, which is a
>> standard serial driver.
>
> Comments below.
Thanks for the review, please find my answsers below
>
>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>> ---
>> drivers/tty/serial/Kconfig | 17 +
>> drivers/tty/serial/Makefile | 1 +
>> drivers/tty/serial/stm32-usart.c | 695 +++++++++++++++++++++++++++++++++++++++
>> include/uapi/linux/serial_core.h | 3 +
>> 4 files changed, 716 insertions(+)
>> create mode 100644 drivers/tty/serial/stm32-usart.c
>>
...
>> +static unsigned int stm32_tx_empty(struct uart_port *port)
>> +{
>> + return readl_relaxed(port->membase + USART_SR) & USART_SR_TXE;
>> +}
>> +
>> +static void stm32_set_mctrl(struct uart_port *port, unsigned int mctrl)
>> +{
>> + /*
>> + * This routine is used for seting signals of: DTR, DCD, CTS/RTS
>> + * We use USART's hardware for CTS/RTS, so don't need any for that.
>
> If this means that you're enabling autoflow control, then you still need
> to respond to the state of TIOCM_RTS, so that both serial core and userspace
> can halt input flow.
>
> If the hardware doesn't support separate RTS enable/disable control,
> then you need to disable autoRTS when TIOCM_RTS is clear, and re-enable
> it when raised.
>
>
>> + * Some boards have DTR and DCD implemented using PIO pins,
>> + * code to do this should be hooked in here.
>> + */
>> +}
>> +
>> +static unsigned int stm32_get_mctrl(struct uart_port *port)
>> +{
>> + /*
>> + * This routine is used for geting signals of: DTR, DCD, DSR, RI,
>> + * and CTS/RTS
>> + */
>> + return TIOCM_CAR | TIOCM_DSR | TIOCM_CTS;
>> +}
>> +
...
>> +
>> +static void stm32_set_termios(struct uart_port *port, struct ktermios *termios,
>> + struct ktermios *old)
>> +{
>> + unsigned int baud;
>> + u32 usardiv, mantissa, fraction;
>> + tcflag_t cflag;
>> + u32 cr1, cr2, cr3;
>> + unsigned long flags;
>> +
>> + baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk / 16);
>> + cflag = termios->c_cflag;
>> +
>> + spin_lock_irqsave(&port->lock, flags);
>> +
>> + /* Stop serial port and reset value */
>> + writel_relaxed(0, port->membase + USART_CR1);
>> +
>> + cr1 = USART_CR1_TE | USART_CR1_RE | USART_CR1_UE | USART_CR1_RXNEIE;
>> +
>> + if (cflag & CSTOPB)
>> + cr2 = USART_CR2_STOP_2B;
>> +
>> + if (cflag & PARENB) {
>> + cr1 |= USART_CR1_PCE;
>> + if ((cflag & CSIZE) == CS8)
>> + cr1 |= USART_CR1_M;
>> + }
>> +
>> + if (cflag & PARODD)
>> + cr1 |= USART_CR1_PS;
>> +
>> + if (cflag & CRTSCTS)
>> + cr3 = USART_CR3_RTSE | USART_CR3_CTSE;
>
> If this means autoflow control, then you need to define
> throttle()/unthrottle() methods, otherwise the serial core won't
> be able to throttle the remote when input buffers are about
> to overflow.
>
> And you should only enable the autoCTS and let the serial
> core enable autoRTS through set_mctrl(TIOCM_RTS).
>
> Just let me know if you need more info about how to do this.
Ok, let's see if I have well understood.
USART_CR3_RTSE should be set/cleared in set_mctrl(), depending on
TIOCM_RTS value.
The throttle callback should disable the rx interrupt, and the
unthrottle enable it.
For CTS, it should be enabled in set_termios() if CRTSCTS, as done here.
Am I right?
>
>> +
>> + usardiv = (port->uartclk * 25) / (baud * 4);
>> + mantissa = (usardiv / 100) << USART_BRR_DIV_M_SHIFT;
>> + fraction = DIV_ROUND_CLOSEST((usardiv % 100) * 16, 100);
>> + if (fraction & ~USART_BRR_DIV_F_MASK) {
>> + fraction = 0;
>> + mantissa += (1 << USART_BRR_DIV_M_SHIFT);
>> + }
>> +
>> + writel_relaxed(mantissa | fraction, port->membase + USART_BRR);
>> +
>> + uart_update_timeout(port, cflag, baud);
>> +
>> + port->read_status_mask = USART_SR_ORE;
>> + if (termios->c_iflag & INPCK)
>> + port->read_status_mask |= USART_SR_PE | USART_SR_FE;
>> + if (termios->c_iflag & (IGNBRK | BRKINT | PARMRK))
>> + port->read_status_mask |= USART_SR_LBD;
>> +
>> + /* Characters to ignore */
>> + port->ignore_status_mask = 0;
>> + if (termios->c_iflag & IGNPAR)
>> + port->ignore_status_mask = USART_SR_PE | USART_SR_FE;
>> + if (termios->c_iflag & IGNBRK) {
>> + port->ignore_status_mask |= USART_SR_LBD;
>> + /*
>> + * If we're ignoring parity and break indicators,
>> + * ignore overruns too (for real raw support).
>> + */
>> + if (termios->c_iflag & IGNPAR)
>> + port->ignore_status_mask |= USART_SR_ORE;
>> + }
>> +
>> + /*
>> + * Ignore all characters if CREAD is not set.
>> + */
>> + if ((termios->c_cflag & CREAD) == 0)
>> + port->ignore_status_mask |= USART_SR_DUMMY_RX;
>> +
>> + writel_relaxed(cr3, port->membase + USART_CR3);
>> + writel_relaxed(cr2, port->membase + USART_CR2);
>> + writel_relaxed(cr1, port->membase + USART_CR1);
>> +
>> + spin_unlock_irqrestore(&port->lock, flags);
>> +}
>> +
...
>> +static void stm32_config_port(struct uart_port *port, int flags)
>> +{
>> + if ((flags & UART_CONFIG_TYPE))
>
> Single parens.
Sure.
>
>> + port->type = PORT_STM32;
>> +}
>> +
...
>> +
>> +static int stm32_init_port(struct stm32_port *stm32port,
>> + struct platform_device *pdev)
>> +{
>> + struct uart_port *port = &stm32port->port;
>> + struct resource *res;
>> +
>> + port->iotype = UPIO_MEM;
>> + port->flags = UPF_BOOT_AUTOCONF;
>> + port->ops = &stm32_uart_ops;
>> + port->dev = &pdev->dev;
>> + port->irq = platform_get_irq(pdev, 0);
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + port->membase = devm_ioremap_resource(&pdev->dev, res);
>> + if (IS_ERR(port->membase))
>> + return PTR_ERR(port->membase);
>> + port->mapbase = res->start;
>> +
>> + spin_lock_init(&port->lock);
>> +
>> + stm32port->clk = devm_clk_get(&pdev->dev, NULL);
>> +
>> + if (WARN_ON(IS_ERR(stm32port->clk)))
>
> Do you really need a stack trace here? Could this be dev_err() instead?
No I don't, dev_err() will be enough.
>
>> + return -EINVAL;
>> +
>> + /* ensure that clk rate is correct by enabling the clk */
>> + clk_prepare_enable(stm32port->clk);
>> + stm32port->port.uartclk = clk_get_rate(stm32port->clk);
>> + WARN_ON(stm32port->port.uartclk == 0);
>
> Or here?
Same here.
>
>> + clk_disable_unprepare(stm32port->clk);
>> +
>> + return 0;
>> +}
>> +
>> +static struct stm32_port *stm32_of_get_stm32_port(struct platform_device *pdev)
>> +{
>> + struct device_node *np = pdev->dev.of_node;
>> + int id;
>> +
>> + if (!np)
>> + return NULL;
>> +
>> + id = of_alias_get_id(np, STM32_SERIAL_NAME);
>> +
>> + if (id < 0)
>> + id = 0;
>> +
>> + if (WARN_ON(id >= STM32_MAX_PORTS))
>
> Or here?
I will return PTR_ERR(-EINVAL); instead.
>
>> + return NULL;
>> +
>> + stm32_ports[id].port.line = id;
>> + return &stm32_ports[id];
>> +}
>> +
...
>> diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
>> index b212281..e22dee5 100644
>> --- a/include/uapi/linux/serial_core.h
>> +++ b/include/uapi/linux/serial_core.h
>> @@ -258,4 +258,7 @@
>> /* Cris v10 / v32 SoC */
>> #define PORT_CRIS 112
>>
>> +/* STM32 USART */
>> +#define PORT_STM32 110
>
> Already taken.
>
> You'll want to make sure v4 applies cleanly to Greg's tty-next branch.
Sure, I made a mistake during the rebase conflict resolution.
Thanks,
Maxime
>
> Regards,
> Peter Hurley
>
>> +
>> #endif /* _UAPILINUX_SERIAL_CORE_H */
>>
>
^ permalink raw reply
* [PATCH] stm class: Adding master and channel parameter to ioctl function
From: Mathieu Poirier @ 2015-03-26 21:46 UTC (permalink / raw)
To: alexander.shishkin-VuQAYsv1563Yd54FQh9/CA
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
peter.lachner-ral2JQCrhuEAvxtiuMwx3w,
norbert.schulz-ral2JQCrhuEAvxtiuMwx3w,
keven.boell-ral2JQCrhuEAvxtiuMwx3w,
yann.fouassier-ral2JQCrhuEAvxtiuMwx3w,
laurent.fert-ral2JQCrhuEAvxtiuMwx3w,
linux-api-u79uwXL29TY76Z2rM5mHXA,
kaixu.xia-QSEj5FYQhm4dnm+yROfE0A,
zhang.chunyan-QSEj5FYQhm4dnm+yROfE0A,
mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A
Hey Alex,
Have a look at the following patch and see if you agree with my approach. If so
simply add the code to a third version.
Thanks,
Mathieu
>From 70b4709b668ef59b303dabeff73ed850a4980cfc Mon Sep 17 00:00:00 2001
From: Mathieu Poirier <mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Date: Thu, 26 Mar 2015 15:33:03 -0600
Subject: [PATCH] stm class: Adding master and channel parameter to ioctl
function
Just like the "write" function, architecture specific device need
to know about master and channels to do the correct operations on
a ioctl call.
Since this information is embedded in the stm_file structure that
is private to the stm class core, adding extra parameters to convey
the values is simple and clean.
Signed-off-by: Mathieu Poirier <mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
drivers/hwtracing/stm/core.c | 12 ++++++++++--
include/linux/stm.h | 5 +++--
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index 9e82634590dc..ca71b06bbfea 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -511,9 +511,17 @@ stm_char_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
return stm_char_policy_get_ioctl(stmf, (void __user *)arg);
default:
- if (stm_data->ioctl)
- err = stm_data->ioctl(stm_data, cmd, arg);
+ if (stm_data->ioctl) {
+ /* users shouldn't call device specific ioctl before
+ * getting a channel using the proper potocol
+ */
+ if (!stmf->output.nr_chans)
+ return -EINVAL;
+ err = stm_data->ioctl(stm_data, stmf->output.master,
+ stmf->output.channel, cmd, arg);
+
+ }
break;
}
diff --git a/include/linux/stm.h b/include/linux/stm.h
index 976c94d8f17f..84dd83c47fe7 100644
--- a/include/linux/stm.h
+++ b/include/linux/stm.h
@@ -62,8 +62,9 @@ struct stm_data {
unsigned int);
void (*unlink)(struct stm_data *, unsigned int,
unsigned int);
- long (*ioctl)(struct stm_data *, unsigned int,
- unsigned long);
+ long (*ioctl)(struct stm_data *,
+ unsigned int, unsigned int,
+ unsigned int, unsigned long);
};
int stm_register_device(struct device *parent, struct stm_data *stm_data,
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] mremap: add MREMAP_NOHOLE flag --resend
From: Daniel Micay @ 2015-03-26 20:45 UTC (permalink / raw)
To: Vlastimil Babka, David Rientjes
Cc: Aliaksey Kandratsenka, Andrew Morton, Shaohua Li, linux-mm,
linux-api, Rik van Riel, Hugh Dickins, Mel Gorman,
Johannes Weiner, Michal Hocko, Andy Lutomirski,
google-perftools@googlegroups.com
In-Reply-To: <5514410C.7090408@suse.cz>
[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]
> Are you sure it's due to page faults and not khugepaged + high value
> (such as the default 511) of max_ptes_none? As reported here?
>
> https://bugzilla.kernel.org/show_bug.cgi?id=93111
>
> Once you have faulted in a THP, and then purged part of it and split it,
> I don't think page faults in the purged part can lead to a new THP
> collapse, only khugepaged can do that AFAIK.
> And if you mmap smaller than 2M areas (i.e. your 256K chunks), that
> should prevent THP page faults on the first fault within the chunk as well.
Hm, that's probably it. The page faults would still be an issue when
reserving ranges on 64-bit for parallel chunk allocation and to make
sure the lowest address chunks are the oldest from the start, which is
likely down the road.
A nice property of 2M chunks is that mremap doesn't need to split huge
pages and neither does purging at the chunk level. I'd expect that to be
a *good thing* rather than something that needs to be avoided due to an
aggressive heuristic.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3 04/15] clocksource: Add ARM System timer driver
From: Maxime Coquelin @ 2015-03-26 20:19 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Uwe Kleine-König, Andreas Färber, Geert Uytterhoeven,
Rob Herring, Philipp Zabel, Linus Walleij, Arnd Bergmann,
Stefan Agner, Peter Meerwald, Paul Bolle, Jonathan Corbet,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King,
Thomas Gleixner, Greg Kroah-Hartman, Jiri Slaby, Andrew Morton,
David S. Miller, Mauro Carvalho Chehab
In-Reply-To: <5513D64A.7060702@linaro.org>
Hi Daniel,
Thanks for the review. Please find my answers below.
2015-03-26 10:50 GMT+01:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> On 03/12/2015 10:55 PM, Maxime Coquelin wrote:
>>
>> From: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>
>> This patch adds clocksource support for ARMv7-M's System timer,
>> also known as SysTick.
>>
>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>
>
> Hi Maxime,
>
> the driver looks good. Three comments below.
>
> -- Daniel
>
>
>> ---
>> drivers/clocksource/Kconfig | 7 ++++
>> drivers/clocksource/Makefile | 1 +
>> drivers/clocksource/armv7m_systick.c | 78
>> ++++++++++++++++++++++++++++++++++++
>> 3 files changed, 86 insertions(+)
>> create mode 100644 drivers/clocksource/armv7m_systick.c
>>
>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>> index 1c2506f..b82e58b 100644
>> --- a/drivers/clocksource/Kconfig
>> +++ b/drivers/clocksource/Kconfig
>> @@ -134,6 +134,13 @@ config CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
>> help
>> Use ARM global timer clock source as sched_clock
>>
>> +config ARMV7M_SYSTICK
>> + bool
>> + select CLKSRC_OF if OF
>> + select CLKSRC_MMIO
>> + help
>> + This options enables support for the ARMv7M system timer unit
>> +
>> config ATMEL_PIT
>> select CLKSRC_OF if OF
>> def_bool SOC_AT91SAM9 || SOC_SAMA5
>> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
>> index 752d5c7..1c9a643 100644
>> --- a/drivers/clocksource/Makefile
>> +++ b/drivers/clocksource/Makefile
>> @@ -44,6 +44,7 @@ obj-$(CONFIG_MTK_TIMER) += mtk_timer.o
>>
>> obj-$(CONFIG_ARM_ARCH_TIMER) += arm_arch_timer.o
>> obj-$(CONFIG_ARM_GLOBAL_TIMER) += arm_global_timer.o
>> +obj-$(CONFIG_ARMV7M_SYSTICK) += armv7m_systick.o
>> obj-$(CONFIG_CLKSRC_METAG_GENERIC) += metag_generic.o
>> obj-$(CONFIG_ARCH_HAS_TICK_BROADCAST) += dummy_timer.o
>> obj-$(CONFIG_ARCH_KEYSTONE) += timer-keystone.o
>> diff --git a/drivers/clocksource/armv7m_systick.c
>> b/drivers/clocksource/armv7m_systick.c
>> new file mode 100644
>> index 0000000..23d8249
>> --- /dev/null
>> +++ b/drivers/clocksource/armv7m_systick.c
>> @@ -0,0 +1,78 @@
>> +/*
>> + * Copyright (C) Maxime Coquelin 2015
>> + * Author: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>> + * License terms: GNU General Public License (GPL), version 2
>> + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/clocksource.h>
>> +#include <linux/clockchips.h>
>> +#include <linux/of.h>
>> +#include <linux/of_address.h>
>> +#include <linux/clk.h>
>> +#include <linux/bitops.h>
>> +
>> +#define SYST_CSR 0x00
>> +#define SYST_RVR 0x04
>> +#define SYST_CVR 0x08
>> +#define SYST_CALIB 0x0c
>> +
>> +#define SYST_CSR_ENABLE BIT(0)
>> +
>> +#define SYSTICK_LOAD_RELOAD_MASK 0x00FFFFFF
>> +
>> +static void __init system_timer_of_register(struct device_node *np)
>> +{
>> + struct clk *clk;
>> + void __iomem *base;
>> + u32 rate = 0;
>> + int ret;
>> +
>> + base = of_iomap(np, 0);
>> + if (!base) {
>> + pr_warn("system-timer: invalid base address\n");
>> + return;
>> + }
>> +
>> + clk = of_clk_get(np, 0);
>> + if (!IS_ERR(clk)) {
>> + ret = clk_prepare_enable(clk);
>> + if (ret) {
>> + clk_put(clk);
>> + goto out_unmap;
>> + }
>> +
>> + rate = clk_get_rate(clk);
>> + }
>> +
>> + /* If no clock found, try to get clock-frequency property */
>> + if (!rate) {
>> + ret = of_property_read_u32(np, "clock-frequency", &rate);
>> + if (ret)
>> + goto out_unmap;
>
>
> Shouldn't be 'goto out_clk_disable' ?
No, because I assumed !rate means we failed to get the clock.
Actually, clk_get_rate could return 0, so relying on rate value is not safe.
I propose to get clock-frequency property if IS_ERR(clk).
Is it fine for you?
>
>> + }
>> +
>> + writel_relaxed(SYSTICK_LOAD_RELOAD_MASK, base + SYST_RVR);
>> + writel_relaxed(SYST_CSR_ENABLE, base + SYST_CSR);
>> +
>> + ret = clocksource_mmio_init(base + SYST_CVR, "arm_system_timer",
>> rate,
>> + 200, 24, clocksource_mmio_readl_down);
>> + if (ret) {
>> + pr_err("failed to init clocksource (%d)\n", ret);
>> + goto out_clk_disable;
>> + }
>> +
>> + pr_info("ARM System timer initialized as clocksource\n");
>> +
>> + return;
>> +
>> +out_clk_disable:
>> + if (!IS_ERR(clk))
>
>
> Why do you need this check ?
To handle the case were no clock was found, but a clk-frequency value
was provided.
>
> It isn't missing a clk_put ?
Right, thanks for spotting this.
I wonder if it makes sense to implement the error path.
If we fail to initialize the clocksource, the system will be unusable.
Maybe I should just perform a BUG_ON() in the error cases, as most of
the other clocksource drivers do.
What is your view?
Regards,
Maxime
>
>> + clk_disable_unprepare(clk);
>> +out_unmap:
>> + iounmap(base);
>> + WARN(ret, "ARM System timer register failed (%d)\n", ret);
>> +}
>> +
>> +CLOCKSOURCE_OF_DECLARE(arm_systick, "arm,armv7m-systick",
>> + system_timer_of_register);
>>
>
>
> --
> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>
^ permalink raw reply
* [PATCH] drm/i915: fix definition of the DRM_IOCTL_I915_GET_SPRITE_COLORKEY ioctl
From: Tommi Rantala @ 2015-03-26 19:47 UTC (permalink / raw)
To: Daniel Vetter, Jani Nikula; +Cc: linux-api, intel-gfx, dri-devel
Fix definition of the DRM_IOCTL_I915_GET_SPRITE_COLORKEY ioctl, so that it
is different from the DRM_IOCTL_I915_SET_SPRITE_COLORKEY ioctl.
Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
---
include/uapi/drm/i915_drm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 6eed16b..0e9c835 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -270,7 +270,7 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_OVERLAY_PUT_IMAGE DRM_IOW(DRM_COMMAND_BASE + DRM_I915_OVERLAY_PUT_IMAGE, struct drm_intel_overlay_put_image)
#define DRM_IOCTL_I915_OVERLAY_ATTRS DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_OVERLAY_ATTRS, struct drm_intel_overlay_attrs)
#define DRM_IOCTL_I915_SET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_SET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
-#define DRM_IOCTL_I915_GET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_SET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
+#define DRM_IOCTL_I915_GET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
#define DRM_IOCTL_I915_GEM_WAIT DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_WAIT, struct drm_i915_gem_wait)
#define DRM_IOCTL_I915_GEM_CONTEXT_CREATE DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_GEM_CONTEXT_CREATE, struct drm_i915_gem_context_create)
#define DRM_IOCTL_I915_GEM_CONTEXT_DESTROY DRM_IOW (DRM_COMMAND_BASE + DRM_I915_GEM_CONTEXT_DESTROY, struct drm_i915_gem_context_destroy)
--
2.1.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
From: Milosz Tanski @ 2015-03-26 19:12 UTC (permalink / raw)
To: Christoph Hellwig
Cc: LKML, linux-fsdevel@vger.kernel.org, linux-aio@kvack.org,
Mel Gorman, Volker Lendecke, Tejun Heo, Jeff Moyer,
Theodore Ts'o, Al Viro, Linux API, Michael Kerrisk,
linux-arch, Dave Chinner, Andrew Morton
In-Reply-To: <20150326115514.GA12329@infradead.org>
On Thu, Mar 26, 2015 at 7:55 AM, Christoph Hellwig <hch@infradead.org> wrote:
>
> On Mon, Mar 16, 2015 at 02:27:10PM -0400, Milosz Tanski wrote:
> > This patchset introduces two new syscalls preadv2 and pwritev2. They are the
> > same syscalls as preadv and pwrite but with a flag argument. Additionally,
> > preadv2 implements an extra RWF_NONBLOCK flag.
>
> There was some arugment that we just don't wait and don't have the
> classic unix "blocking" semantics. Maybe it's time to bite the bullet
> and rename it to RWF_DONTWAIT? (I personally dont really care).
Sure. It is in line with the MSG_DONTWAIT flag for sendmsg() which
this whole idea is based on anyways.
>
>
> Second this probably needs to be on top of Al's for-next tree:
>
> https://git.kernel.org/cgit/linux/kernel/git/viro/vfs.git/log/?h=for-next
>
> Note that this has a flags field in struct kiocb, so we could just use
> that for the flags.
Okay I started rebasing the patches on-top of that. I did see that
there is a new flags field "ki_flags". I see that there's already a
IOCB_EVENTFD flag.
Did you see you Andres' question about making the flags a enum? I
usually wouldn't do that, because C++ is stronger when it comes enums,
you can't combine them then assignment them to an enum without a cast.
But in the kernel this doesn't matter.
>
>
> Otherwise this version look fine to me, let's get it merged!
>
> Al, are yo ready to pick this up? I'd hate to miss another merge
> window.
Just got back from vacation today, I'll try to get this out before the
end of the week. I also have to make some adjustments to xfs-tests (to
push preadv2 into xfs_io).
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: milosz@adfin.com
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* [GIT PULL] kselftest fixes for 4.0-rc6
From: Shuah Khan @ 2015-03-26 18:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
open list:KERNEL SELFTEST F..., Shuah Khan
Hi Linus,
Could you please pull the following kselftest fix for 4.0-rc6.
thanks,
-- Shuah
The following changes since commit 9a0b57451ae8142c74d65bddb6d7765818babbed:
selftests/exec: Check if the syscall exists and bail if not
(2015-03-11 10:15:19 -0600)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
tags/linux-kselftest-4.0-rc6
for you to fetch changes up to 67d8712dcc70aa16d8e14a52eb73870e3cbddfc2:
selftests: Fix build failures when invoked from kselftest target
(2015-03-19 09:54:55 -0600)
----------------------------------------------------------------
kselftest fixes for: 4.0-rc6
----------------------------------------------------------------
Shuah Khan (1):
selftests: Fix build failures when invoked from kselftest target
tools/testing/selftests/Makefile | 8 ++++++++
1 file changed, 8 insertions(+)
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org | (970) 217-8978
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox