* [PATCH 32/32] random: convert to ->poll_mask
From: Christoph Hellwig @ 2018-05-11 11:08 UTC (permalink / raw)
To: viro; +Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180511110803.10910-1-hch@lst.de>
The big change is that random_read_wait and random_write_wait are merged
into a single waitqueue that uses keyed wakeups. Because wait_event_*
doesn't know about that this will lead to occassional spurious wakeups
in _random_read and add_hwgenerator_randomness, but wait_event_* is
designed to handle these and were are not in a a hot path there.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/char/random.c | 29 ++++++++++++++++-------------
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index cd888d4ee605..a8fb0020ba5c 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -402,8 +402,7 @@ static struct poolinfo {
/*
* Static global variables
*/
-static DECLARE_WAIT_QUEUE_HEAD(random_read_wait);
-static DECLARE_WAIT_QUEUE_HEAD(random_write_wait);
+static DECLARE_WAIT_QUEUE_HEAD(random_wait);
static struct fasync_struct *fasync;
static DEFINE_SPINLOCK(random_ready_list_lock);
@@ -722,8 +721,8 @@ static void credit_entropy_bits(struct entropy_store *r, int nbits)
/* should we wake readers? */
if (entropy_bits >= random_read_wakeup_bits &&
- wq_has_sleeper(&random_read_wait)) {
- wake_up_interruptible(&random_read_wait);
+ wq_has_sleeper(&random_wait)) {
+ wake_up_interruptible_poll(&random_wait, POLLIN);
kill_fasync(&fasync, SIGIO, POLL_IN);
}
/* If the input pool is getting full, send some
@@ -1397,7 +1396,7 @@ static size_t account(struct entropy_store *r, size_t nbytes, int min,
trace_debit_entropy(r->name, 8 * ibytes);
if (ibytes &&
(r->entropy_count >> ENTROPY_SHIFT) < random_write_wakeup_bits) {
- wake_up_interruptible(&random_write_wait);
+ wake_up_interruptible_poll(&random_wait, POLLOUT);
kill_fasync(&fasync, SIGIO, POLL_OUT);
}
@@ -1839,7 +1838,7 @@ _random_read(int nonblock, char __user *buf, size_t nbytes)
if (nonblock)
return -EAGAIN;
- wait_event_interruptible(random_read_wait,
+ wait_event_interruptible(random_wait,
ENTROPY_BITS(&input_pool) >=
random_read_wakeup_bits);
if (signal_pending(current))
@@ -1876,14 +1875,17 @@ urandom_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
return ret;
}
+static struct wait_queue_head *
+random_get_poll_head(struct file *file, __poll_t events)
+{
+ return &random_wait;
+}
+
static __poll_t
-random_poll(struct file *file, poll_table * wait)
+random_poll_mask(struct file *file, __poll_t events)
{
- __poll_t mask;
+ __poll_t mask = 0;
- poll_wait(file, &random_read_wait, wait);
- poll_wait(file, &random_write_wait, wait);
- mask = 0;
if (ENTROPY_BITS(&input_pool) >= random_read_wakeup_bits)
mask |= EPOLLIN | EPOLLRDNORM;
if (ENTROPY_BITS(&input_pool) < random_write_wakeup_bits)
@@ -1990,7 +1992,8 @@ static int random_fasync(int fd, struct file *filp, int on)
const struct file_operations random_fops = {
.read = random_read,
.write = random_write,
- .poll = random_poll,
+ .get_poll_head = random_get_poll_head,
+ .poll_mask = random_poll_mask,
.unlocked_ioctl = random_ioctl,
.fasync = random_fasync,
.llseek = noop_llseek,
@@ -2323,7 +2326,7 @@ void add_hwgenerator_randomness(const char *buffer, size_t count,
* We'll be woken up again once below random_write_wakeup_thresh,
* or when the calling thread is about to terminate.
*/
- wait_event_interruptible(random_write_wait, kthread_should_stop() ||
+ wait_event_interruptible(random_wait, kthread_should_stop() ||
ENTROPY_BITS(&input_pool) <= random_write_wakeup_bits);
mix_pool_bytes(poolp, buffer, count);
credit_entropy_bits(poolp, entropy);
--
2.17.0
--
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 related
* Re: [PATCH 14/32] net/tcp: convert to ->poll_mask
From: Eric Dumazet @ 2018-05-11 13:13 UTC (permalink / raw)
To: Christoph Hellwig, viro
Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180511110803.10910-15-hch@lst.de>
On 05/11/2018 04:07 AM, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> include/net/tcp.h | 4 ++--
> net/ipv4/af_inet.c | 3 ++-
> net/ipv4/tcp.c | 31 ++++++++++++++-----------------
> net/ipv6/af_inet6.c | 3 ++-
> 4 files changed, 20 insertions(+), 21 deletions(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 9c9b3768b350..d4d72ea9128d 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -388,8 +388,8 @@ bool tcp_peer_is_proven(struct request_sock *req, struct dst_entry *dst);
> void tcp_close(struct sock *sk, long timeout);
> void tcp_init_sock(struct sock *sk);
> void tcp_init_transfer(struct sock *sk, int bpf_op);
> -__poll_t tcp_poll(struct file *file, struct socket *sock,
> - struct poll_table_struct *wait);
> +struct wait_queue_head *tcp_get_poll_head(struct socket *sock, __poll_t events);
> +__poll_t tcp_poll_mask(struct socket *sock, __poll_t events);
> int tcp_getsockopt(struct sock *sk, int level, int optname,
> char __user *optval, int __user *optlen);
> int tcp_setsockopt(struct sock *sk, int level, int optname,
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index eaed0367e669..220b51347526 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -986,7 +986,8 @@ const struct proto_ops inet_stream_ops = {
> .socketpair = sock_no_socketpair,
> .accept = inet_accept,
> .getname = inet_getname,
> - .poll = tcp_poll,
> + .get_poll_head = tcp_get_poll_head,
> + .poll_mask = tcp_poll_mask,
> .ioctl = inet_ioctl,
> .listen = inet_listen,
> .shutdown = inet_shutdown,
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 9ce1c726185e..6ec0e7a13581 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -493,33 +493,30 @@ static inline bool tcp_stream_is_readable(const struct tcp_sock *tp,
> sk->sk_prot->stream_memory_read(sk) : false);
> }
>
> +struct wait_queue_head *tcp_get_poll_head(struct socket *sock, __poll_t events)
> +{
> + sock_poll_busy_loop(sock, events);
> + sock_rps_record_flow(sock->sk);
Why are you adding sock_rps_record_flow() ?
> + return sk_sleep(sock->sk);
> +}
> +EXPORT_SYMBOL(tcp_get_poll_head);
> +
> /*
> - * Wait for a TCP event.
> - *
> - * Note that we don't need to lock the socket, as the upper poll layers
> - * take care of normal races (between the test and the event) and we don't
> - * go look at any of the socket buffers directly.
> + * Socket is not locked. We are protected from async events by poll logic and
> + * correct handling of state changes made by other threads is impossible in
> + * any case.
> */
> -__poll_t tcp_poll(struct file *file, struct socket *sock, poll_table *wait)
> +__poll_t tcp_poll_mask(struct socket *sock, __poll_t events)
> {
> - __poll_t mask;
> struct sock *sk = sock->sk;
> const struct tcp_sock *tp = tcp_sk(sk);
> + __poll_t mask = 0;
> int state;
>
> - sock_poll_wait(file, sk_sleep(sk), wait);
> -
> state = inet_sk_state_load(sk);
> if (state == TCP_LISTEN)
> return inet_csk_listen_poll(sk);
>
> - /* Socket is not locked. We are protected from async events
> - * by poll logic and correct handling of state changes
> - * made by other threads is impossible in any case.
> - */
> -
> - mask = 0;
> -
> /*
> * EPOLLHUP is certainly not done right. But poll() doesn't
> * have a notion of HUP in just one direction, and for a
> @@ -600,7 +597,7 @@ __poll_t tcp_poll(struct file *file, struct socket *sock, poll_table *wait)
>
> return mask;
> }
> -EXPORT_SYMBOL(tcp_poll);
> +EXPORT_SYMBOL(tcp_poll_mask);
>
> int tcp_ioctl(struct sock *sk, int cmd, unsigned long arg)
> {
> diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
> index 8da0b513f188..a43d967eeca5 100644
> --- a/net/ipv6/af_inet6.c
> +++ b/net/ipv6/af_inet6.c
> @@ -571,7 +571,8 @@ const struct proto_ops inet6_stream_ops = {
> .socketpair = sock_no_socketpair, /* a do nothing */
> .accept = inet_accept, /* ok */
> .getname = inet6_getname,
> - .poll = tcp_poll, /* ok */
> + .get_poll_head = tcp_get_poll_head,
> + .poll_mask = tcp_poll_mask, /* ok */
> .ioctl = inet6_ioctl, /* must change */
> .listen = inet_listen, /* ok */
> .shutdown = inet_shutdown, /* ok */
>
--
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 v5 1/7] proc: add proc_fs_info struct to store proc information
From: Jann Horn @ 2018-05-11 13:49 UTC (permalink / raw)
To: Alexey Gladkov
Cc: Kees Cook, Andy Lutomirski, Andrew Morton, linux-fsdevel,
kernel list, Kernel Hardening, linux-security-module, Linux API,
Greg Kroah-Hartman, Alexander Viro, Akinobu Mita, Oleg Nesterov,
Jeff Layton, Ingo Molnar, Alexey Dobriyan, Eric W. Biederman,
Linus Torvalds, aniel Micay, Jon
In-Reply-To: <20180511093445.GA1008@comp-core-i7-2640m-0182e6>
On Fri, May 11, 2018 at 11:34 AM, Alexey Gladkov
<gladkov.alexey@gmail.com> wrote:
> From: Djalal Harouni <tixxdz@gmail.com>
>
> This is a preparation patch that adds proc_fs_info to be able to store
> different procfs options and informations. Right now some mount options
> are stored inside the pid namespace which makes it hard to change or
> modernize procfs without affecting pid namespaces. Plus we do want to
> treat proc as more of a real mount point and filesystem. procfs is part
> of Linux API where it offers some features using filesystem syscalls and
> in order to support some features where we are able to have multiple
> instances of procfs, each one with its mount options inside the same pid
> namespace, we have to separate these procfs instances.
>
> This is the same feature that was also added to other Linux interfaces
> like devpts in order to support containers, sandboxes, and to have
> multiple instances of devpts filesystem [1].
>
> [1] http://lxr.free-electrons.com/source/Documentation/filesystems/devpts.txt?v=3.14
>
> Cc: Kees Cook <keescook@chromium.org>
> Suggested-by: Andy Lutomirski <luto@kernel.org>
> Signed-off-by: Djalal Harouni <tixxdz@gmail.com>
> Signed-off-by: Alexey Gladkov <gladkov.alexey@gmail.com>
> ---
[...]
> static struct dentry *proc_mount(struct file_system_type *fs_type,
> int flags, const char *dev_name, void *data)
> {
> + int error;
> + struct super_block *sb;
> struct pid_namespace *ns;
> + struct proc_fs_info *fs_info;
> +
> + /*
> + * Don't allow mounting unless the caller has CAP_SYS_ADMIN over
> + * the namespace.
> + */
> + if (!(flags & MS_KERNMOUNT) && !ns_capable(current_user_ns(), CAP_SYS_ADMIN))
> + return ERR_PTR(-EPERM);
Is this correct?
The old code invoked a check with the same comment through mount_ns();
however, this patch changes the semantics of the check.
The old code checked that the caller has privileges over the user
namespace that contains the PID namespace; in other words, it checked
that the caller has privileges over the PID namespace. The current
code just checks that the caller is privileged over its own user
namespace.
As far as I can tell, this means that by doing something like this:
unshare(CLONE_NEWNS|CLONE_NEWUSER);
mount("none", "/", NULL, MS_REC|MS_PRIVATE, NULL);
mount("proc", "/proc", "proc", 0, "newinstance,pids=all");
any process could create a new unrestricted procfs mount for its PID
namespace, even if it is only supposed to have access to a more
restricted procfs mount.
> + fs_info = kzalloc(sizeof(*fs_info), GFP_NOFS);
> + if (!fs_info)
> + return ERR_PTR(-ENOMEM);
>
> if (flags & SB_KERNMOUNT) {
> ns = data;
> @@ -98,20 +128,47 @@ static struct dentry *proc_mount(struct file_system_type *fs_type,
> ns = task_active_pid_ns(current);
> }
>
> - return mount_ns(fs_type, flags, data, ns, ns->user_ns, proc_fill_super);
> + fs_info->pid_ns = ns;
> +
> + sb = sget_userns(fs_type, proc_test_super, proc_set_super, flags,
> + ns->user_ns, fs_info);
> + if (IS_ERR(sb)) {
> + error = PTR_ERR(sb);
> + goto error_fs_info;
> + }
> +
> + if (sb->s_root) {
> + kfree(fs_info);
> + } else {
> + error = proc_fill_super(sb, data, flags & MS_SILENT ? 1 : 0);
> + if (error) {
> + deactivate_locked_super(sb);
> + goto error;
> + }
> +
> + sb->s_flags |= MS_ACTIVE;
> + }
> +
> + return dget(sb->s_root);
> +
> +error_fs_info:
> + kfree(fs_info);
> +error:
> + return ERR_PTR(error);
> }
^ permalink raw reply
* Re: [PATCH v5 7/7] proc: add option to mount only a pids subset
From: Jann Horn @ 2018-05-11 13:58 UTC (permalink / raw)
To: Alexey Gladkov
Cc: Kees Cook, Andy Lutomirski, Andrew Morton, linux-fsdevel,
kernel list, Kernel Hardening, linux-security-module, Linux API,
Greg Kroah-Hartman, Alexander Viro, Akinobu Mita, Oleg Nesterov,
Jeff Layton, Ingo Molnar, Alexey Dobriyan, Eric W. Biederman,
Linus Torvalds, aniel Micay, Jon
In-Reply-To: <20180511093707.GA1403@comp-core-i7-2640m-0182e6>
On Fri, May 11, 2018 at 11:37 AM, Alexey Gladkov
<gladkov.alexey@gmail.com> wrote:
> This allows to hide all files and directories in the procfs that are not
> related to tasks.
/proc/$pid/net and /proc/$pid/task/$tid/net aren't in scope for this
protection, even though they contain information about the whole
network namespace of the task, right?
^ permalink raw reply
* Re: [RFC v2 4/4] btrfs: verify symlinks with append/immutable flags
From: David Sterba @ 2018-05-11 14:04 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: viro, darrick.wong, tytso, adilger.kernel, clm, jbacik, dsterba,
sandeen, dhowells, fliu, jack, jeffm, nborisov, jake.norris,
mtk.manpages, linux-api, linux-fsdevel, linux-xfs, linux-ext4,
linux-btrfs, linux-kernel
In-Reply-To: <20180510231359.16899-5-mcgrof@kernel.org>
On Thu, May 10, 2018 at 04:13:59PM -0700, Luis R. Rodriguez wrote:
> The Linux VFS does not allow a way to set append/immuttable
^^^^^^^^^^
Typo, in all 3 patches.
> attributes to symlinks, this is just not possible. If this is
> detected inform the user as the filesystem must be corrupted.
>
> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
> ---
> fs/btrfs/inode.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> index c4bdb597b323..d9c786be408c 100644
> --- a/fs/btrfs/inode.c
> +++ b/fs/btrfs/inode.c
> @@ -3933,6 +3933,15 @@ static int btrfs_read_locked_inode(struct inode *inode)
> inode->i_op = &btrfs_dir_inode_operations;
> break;
> case S_IFLNK:
> + /* VFS does not allow setting these so must be corruption */
> + if (IS_APPEND(inode) || IS_IMMUTABLE(inode)) {
> + ret = -EUCLEAN;
> + btrfs_crit(fs_info,
> + "corrupt symlink with append/immutable ino=%llu root=%llu\n",
no "\n" and please un-indent the string so it fits 80 columns.
> + btrfs_ino(BTRFS_I(inode)),
> + root->root_key.objectid);
> + goto make_bad;
I found some error handling issues, before the switch, there's
btrfs_free_path and there's one more at the make_bad label.
To fix that, please set path = NULL after the first btrfs_free_path, it
can handle a NULL when it's called again.
Next thing I'm not sure about are the ACLs that get initialized in some
cases. There's cache_no_acl() that only resets the inode::i_acl and
inode::i_default_acl, so I think this should be called too. Thanks.
^ permalink raw reply
* Re: [PATCH 1/2 V2] fs: hoist BTRFS_IOC_[SG]ET_FSLABEL to vfs
From: David Sterba @ 2018-05-11 14:10 UTC (permalink / raw)
To: Al Viro
Cc: Eric Sandeen, Eric Sandeen, fsdevel, linux-btrfs@vger.kernel.org,
Linux API
In-Reply-To: <20180510191608.GR30522@ZenIV.linux.org.uk>
On Thu, May 10, 2018 at 08:16:09PM +0100, Al Viro wrote:
> On Thu, May 10, 2018 at 01:13:57PM -0500, Eric Sandeen wrote:
> > Move the btrfs label ioctls up to the vfs for general use.
> >
> > This retains 256 chars as the maximum size through the interface, which
> > is the btrfs limit and AFAIK exceeds any other filesystem's maximum
> > label size.
> >
> > Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> > Reviewed-by: Andreas Dilger <adilger@dilger.ca>
> > Reviewed-by: David Sterba <dsterba@suse.com>
>
> No objections (and it obviously ought to go through btrfs tree).
I can take it through my tree, but Eric mentioned that there's a patch
for xfs that depends on it. In this case it would make sense to take
both patches at once via the xfs tree. There are no pending conflicting
changes in btrfs.
^ permalink raw reply
* Re: [PATCH 1/2 V2] hoist BTRFS_IOC_[SG]ET_FSLABEL to vfs
From: Chris Mason @ 2018-05-11 14:32 UTC (permalink / raw)
To: David Sterba
Cc: Al Viro, Eric Sandeen, Eric Sandeen, fsdevel, linux-btrfs,
Linux API
In-Reply-To: <20180511141017.GZ6649@twin.jikos.cz>
On 11 May 2018, at 10:10, David Sterba wrote:
> On Thu, May 10, 2018 at 08:16:09PM +0100, Al Viro wrote:
>> On Thu, May 10, 2018 at 01:13:57PM -0500, Eric Sandeen wrote:
>>> Move the btrfs label ioctls up to the vfs for general use.
>>>
>>> This retains 256 chars as the maximum size through the interface,
>>> which
>>> is the btrfs limit and AFAIK exceeds any other filesystem's maximum
>>> label size.
>>>
>>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>>> Reviewed-by: Andreas Dilger <adilger@dilger.ca>
>>> Reviewed-by: David Sterba <dsterba@suse.com>
>>
>> No objections (and it obviously ought to go through btrfs tree).
>
> I can take it through my tree, but Eric mentioned that there's a patch
> for xfs that depends on it. In this case it would make sense to take
> both patches at once via the xfs tree. There are no pending
> conflicting
> changes in btrfs.
Probably easiest to just have a separate pull dedicated just for this
series. That way it doesn't really matter which tree it goes through.
-chris
^ permalink raw reply
* Re: [PATCH 1/2 V2] hoist BTRFS_IOC_[SG]ET_FSLABEL to vfs
From: Eric Sandeen @ 2018-05-11 14:36 UTC (permalink / raw)
To: Chris Mason, David Sterba
Cc: Al Viro, Eric Sandeen, fsdevel, linux-btrfs, Linux API
In-Reply-To: <9F0DCA90-AD82-4179-B50A-F112CF966CCB@fb.com>
On 5/11/18 9:32 AM, Chris Mason wrote:
> On 11 May 2018, at 10:10, David Sterba wrote:
>
>> On Thu, May 10, 2018 at 08:16:09PM +0100, Al Viro wrote:
>>> On Thu, May 10, 2018 at 01:13:57PM -0500, Eric Sandeen wrote:
>>>> Move the btrfs label ioctls up to the vfs for general use.
>>>>
>>>> This retains 256 chars as the maximum size through the interface, which
>>>> is the btrfs limit and AFAIK exceeds any other filesystem's maximum
>>>> label size.
>>>>
>>>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>>>> Reviewed-by: Andreas Dilger <adilger@dilger.ca>
>>>> Reviewed-by: David Sterba <dsterba@suse.com>
>>>
>>> No objections (and it obviously ought to go through btrfs tree).
>>
>> I can take it through my tree, but Eric mentioned that there's a patch
>> for xfs that depends on it. In this case it would make sense to take
>> both patches at once via the xfs tree. There are no pending conflicting
>> changes in btrfs.
>
> Probably easiest to just have a separate pull dedicated just for this series. That way it doesn't really matter which tree it goes through.
Actually, I just realized that the changes to include/uapi/linux/fs.h are completely
independent of any btrfs changes, right - there's nothing wrong w/ redefining
the common ioctl under a different name in btrfs. So the fs.h patch could go first,
through the xfs tree since it'll be using it.
Once the common ioctl definition goes in, then btrfs can change to define its ioctls to
the common ioctls, or act on them directly as my patch did, etc. Would that be
a better plan? IOWs there's no urgent need to coordinate a btrfs change.
-Eric
^ permalink raw reply
* Re: [PATCH 1/2 V2] hoist BTRFS_IOC_[SG]ET_FSLABEL to vfs
From: David Sterba @ 2018-05-11 14:41 UTC (permalink / raw)
To: Eric Sandeen
Cc: Chris Mason, David Sterba, Al Viro, Eric Sandeen, fsdevel,
linux-btrfs, Linux API
In-Reply-To: <94b5a947-d7f5-19e7-fb2b-161a5c20e85e@sandeen.net>
On Fri, May 11, 2018 at 09:36:09AM -0500, Eric Sandeen wrote:
> On 5/11/18 9:32 AM, Chris Mason wrote:
> > On 11 May 2018, at 10:10, David Sterba wrote:
> >
> >> On Thu, May 10, 2018 at 08:16:09PM +0100, Al Viro wrote:
> >>> On Thu, May 10, 2018 at 01:13:57PM -0500, Eric Sandeen wrote:
> >>>> Move the btrfs label ioctls up to the vfs for general use.
> >>>>
> >>>> This retains 256 chars as the maximum size through the interface, which
> >>>> is the btrfs limit and AFAIK exceeds any other filesystem's maximum
> >>>> label size.
> >>>>
> >>>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> >>>> Reviewed-by: Andreas Dilger <adilger@dilger.ca>
> >>>> Reviewed-by: David Sterba <dsterba@suse.com>
> >>>
> >>> No objections (and it obviously ought to go through btrfs tree).
> >>
> >> I can take it through my tree, but Eric mentioned that there's a patch
> >> for xfs that depends on it. In this case it would make sense to take
> >> both patches at once via the xfs tree. There are no pending conflicting
> >> changes in btrfs.
> >
> > Probably easiest to just have a separate pull dedicated just for this series. That way it doesn't really matter which tree it goes through.
>
> Actually, I just realized that the changes to include/uapi/linux/fs.h are completely
> independent of any btrfs changes, right - there's nothing wrong w/ redefining
> the common ioctl under a different name in btrfs. So the fs.h patch could go first,
> through the xfs tree since it'll be using it.
>
> Once the common ioctl definition goes in, then btrfs can change to define its ioctls to
> the common ioctls, or act on them directly as my patch did, etc. Would that be
> a better plan? IOWs there's no urgent need to coordinate a btrfs change.
Agreed, I like that plan.
^ permalink raw reply
* Re: [PATCH v5 5/7] proc: instantiate only pids that we can ptrace on 'limit_pids=1' mount option
From: Randy Dunlap @ 2018-05-11 16:09 UTC (permalink / raw)
To: Alexey Gladkov, Kees Cook, Andy Lutomirski, Andrew Morton,
linux-fsdevel, linux-kernel, kernel-hardening,
linux-security-module, linux-api
Cc: Greg Kroah-Hartman, Alexander Viro, Akinobu Mita, Oleg Nesterov,
Jeff Layton, Ingo Molnar, Alexey Dobriyan, Eric W. Biederman,
Linus Torvalds, aniel Micay, Jonathan Corbet, bfields,
Stephen Rothwell, solar, Dmitry V. Levin, Djalal Harouni
In-Reply-To: <20180511093613.GA1330@comp-core-i7-2640m-0182e6>
On 05/11/2018 02:36 AM, Alexey Gladkov wrote:
> From: Djalal Harouni <tixxdz@gmail.com>
>
> If "limit_pids=1" mount option is set then do not instantiate pids that
> we can not ptrace. "limit_pids=1" means that procfs should only contain
> pids that the caller can ptrace.
Where can I find documentation on these mount options (pidonly, limit_pids)?
Thanks.
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Andy Lutomirski <luto@kernel.org>
> Signed-off-by: Djalal Harouni <tixxdz@gmail.com>
> ---
> fs/proc/base.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
--
~Randy
^ permalink raw reply
* Re: [PATCH v5 0/7] proc: modernize proc to support multiple private instances
From: Linus Torvalds @ 2018-05-11 16:39 UTC (permalink / raw)
To: gladkov.alexey, Al Viro
Cc: Kees Cook, Andrew Lutomirski, Andrew Morton, linux-fsdevel,
Linux Kernel Mailing List, Kernel Hardening, LSM List, Linux API,
Greg Kroah-Hartman, Akinobu Mita, Oleg Nesterov, Jeff Layton,
Ingo Molnar, Alexey Dobriyan, Eric W. Biederman, Daniel Micay,
Jonathan Corbet, J. Bruce Fields
In-Reply-To: <20180511093221.GA902@comp-core-i7-2640m-0182e6>
On Fri, May 11, 2018 at 2:42 AM Alexey Gladkov <gladkov.alexey@gmail.com>
wrote:
> This is RFC v5 to modernize procfs and make it able to support multiple
> private instances per the same pid namespace.
So I have no big objections, but I would *really* like this to go through
Al's vfs tree.
Al? Have you looked at this series?
Linus
^ permalink raw reply
* Re: [PATCH v5 5/7] proc: instantiate only pids that we can ptrace on 'limit_pids=1' mount option
From: Linus Torvalds @ 2018-05-11 16:45 UTC (permalink / raw)
To: gladkov.alexey
Cc: Kees Cook, Andrew Lutomirski, Andrew Morton, linux-fsdevel,
Linux Kernel Mailing List, Kernel Hardening, LSM List, Linux API,
Greg Kroah-Hartman, Al Viro, Akinobu Mita, Oleg Nesterov,
Jeff Layton, Ingo Molnar, Alexey Dobriyan, Eric W. Biederman,
Daniel Micay, Jonathan Corbet, J.
In-Reply-To: <20180511093613.GA1330@comp-core-i7-2640m-0182e6>
On Fri, May 11, 2018 at 2:46 AM Alexey Gladkov <gladkov.alexey@gmail.com>
wrote:
> + /* Limit procfs to only ptracable tasks */
> + if (limit_pids == PROC_LIMIT_PIDS_PTRACE) {
> + cond_resched();
> + if (!has_pid_permissions(fs_info, task,
HIDEPID_NO_ACCESS))
> + goto out_put_task;
> + }
Where did that "cond_resched()" come from? That doesn't seem to make a lot
of sense.
Linus
^ permalink raw reply
* Re: [PATCH v5 0/7] proc: modernize proc to support multiple private instances
From: Al Viro @ 2018-05-11 19:28 UTC (permalink / raw)
To: Linus Torvalds
Cc: gladkov.alexey, Kees Cook, Andrew Lutomirski, Andrew Morton,
linux-fsdevel, Linux Kernel Mailing List, Kernel Hardening,
LSM List, Linux API, Greg Kroah-Hartman, Akinobu Mita,
Oleg Nesterov, Jeff Layton, Ingo Molnar, Alexey Dobriyan,
Eric W. Biederman, Daniel Micay, Jonathan Corbet,
"J. Bruce Fields" <bf>
In-Reply-To: <CA+55aFwZK+BMsm19sK-Wmfta6PcdvW6z-ghuKsb4PAwk19nRVg@mail.gmail.com>
On Fri, May 11, 2018 at 09:39:23AM -0700, Linus Torvalds wrote:
> On Fri, May 11, 2018 at 2:42 AM Alexey Gladkov <gladkov.alexey@gmail.com>
> wrote:
>
> > This is RFC v5 to modernize procfs and make it able to support multiple
> > private instances per the same pid namespace.
>
> So I have no big objections, but I would *really* like this to go through
> Al's vfs tree.
>
> Al? Have you looked at this series?
Looking through it...
^ permalink raw reply
* Re: [RFC v2 3/4] ext4: add verifier check for symlink with append/immutable flags
From: Jan Kara @ 2018-05-11 21:12 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: viro, darrick.wong, tytso, adilger.kernel, clm, jbacik, dsterba,
sandeen, dhowells, fliu, jack, jeffm, nborisov, jake.norris,
mtk.manpages, linux-api, linux-fsdevel, linux-xfs, linux-ext4,
linux-btrfs, linux-kernel
In-Reply-To: <20180510231359.16899-4-mcgrof@kernel.org>
On Thu 10-05-18 16:13:58, Luis R. Rodriguez wrote:
> The Linux VFS does not allow a way to set append/immuttable
> attributes to symlinks, this is just not possible. If this is
> detected inform the user as the filesystem must be corrupted.
>
> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
Looks good to me. You can add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
> ---
> fs/ext4/inode.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 37a2f7a2b66a..6acf0dd6b6e6 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -4947,6 +4947,13 @@ struct inode *ext4_iget(struct super_block *sb, unsigned long ino)
> inode->i_op = &ext4_dir_inode_operations;
> inode->i_fop = &ext4_dir_operations;
> } else if (S_ISLNK(inode->i_mode)) {
> + /* VFS does not allow setting these so must be corruption */
> + if (IS_APPEND(inode) || IS_IMMUTABLE(inode)) {
> + EXT4_ERROR_INODE(inode,
> + "immutable or append flags not allowed on symlinks");
> + ret = -EFSCORRUPTED;
> + goto bad_inode;
> + }
> if (ext4_encrypted_inode(inode)) {
> inode->i_op = &ext4_encrypted_symlink_inode_operations;
> ext4_set_aops(inode);
> --
> 2.17.0
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH 1/2 V2] hoist BTRFS_IOC_[SG]ET_FSLABEL to vfs
From: Darrick J. Wong @ 2018-05-12 0:20 UTC (permalink / raw)
To: dsterba, Eric Sandeen, Chris Mason, Al Viro, Eric Sandeen,
fsdevel, linux-btrfs, Linux API
In-Reply-To: <20180511144145.GA6649@twin.jikos.cz>
On Fri, May 11, 2018 at 04:41:45PM +0200, David Sterba wrote:
> On Fri, May 11, 2018 at 09:36:09AM -0500, Eric Sandeen wrote:
> > On 5/11/18 9:32 AM, Chris Mason wrote:
> > > On 11 May 2018, at 10:10, David Sterba wrote:
> > >
> > >> On Thu, May 10, 2018 at 08:16:09PM +0100, Al Viro wrote:
> > >>> On Thu, May 10, 2018 at 01:13:57PM -0500, Eric Sandeen wrote:
> > >>>> Move the btrfs label ioctls up to the vfs for general use.
> > >>>>
> > >>>> This retains 256 chars as the maximum size through the interface, which
> > >>>> is the btrfs limit and AFAIK exceeds any other filesystem's maximum
> > >>>> label size.
> > >>>>
> > >>>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> > >>>> Reviewed-by: Andreas Dilger <adilger@dilger.ca>
> > >>>> Reviewed-by: David Sterba <dsterba@suse.com>
> > >>>
> > >>> No objections (and it obviously ought to go through btrfs tree).
> > >>
> > >> I can take it through my tree, but Eric mentioned that there's a patch
> > >> for xfs that depends on it. In this case it would make sense to take
> > >> both patches at once via the xfs tree. There are no pending conflicting
> > >> changes in btrfs.
> > >
> > > Probably easiest to just have a separate pull dedicated just for this series. That way it doesn't really matter which tree it goes through.
> >
> > Actually, I just realized that the changes to include/uapi/linux/fs.h are completely
> > independent of any btrfs changes, right - there's nothing wrong w/ redefining
> > the common ioctl under a different name in btrfs. So the fs.h patch could go first,
> > through the xfs tree since it'll be using it.
> >
> > Once the common ioctl definition goes in, then btrfs can change to define its ioctls to
> > the common ioctls, or act on them directly as my patch did, etc. Would that be
> > a better plan? IOWs there's no urgent need to coordinate a btrfs change.
>
> Agreed, I like that plan.
Ok, I'll await a new series with all the patches that Eric wants to
squeeze through the xfs tree. I don't mind carrying the btrfs changes
too, so long as they're one-liners and the btrfs maintainers ack/rvb it.
--D
^ permalink raw reply
* Re: [PATCH 14/32] net/tcp: convert to ->poll_mask
From: Christoph Hellwig @ 2018-05-12 10:09 UTC (permalink / raw)
To: Eric Dumazet
Cc: Christoph Hellwig, viro, Avi Kivity, linux-aio, linux-fsdevel,
netdev, linux-api, linux-kernel
In-Reply-To: <96284b0e-0d4e-a944-4fd5-933d12cf53cb@gmail.com>
On Fri, May 11, 2018 at 06:13:11AM -0700, Eric Dumazet wrote:
> > +struct wait_queue_head *tcp_get_poll_head(struct socket *sock, __poll_t events)
> > +{
> > + sock_poll_busy_loop(sock, events);
> > + sock_rps_record_flow(sock->sk);
>
> Why are you adding sock_rps_record_flow() ?
Because I mismerged the removal of it from tcp_poll in
'net: revert "Update RFS target at poll for tcp/udp"'
Thanks for the headsup, this will be removed for the next version.
--
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: [RFC v2 3/4] ext4: add verifier check for symlink with append/immutable flags
From: Theodore Y. Ts'o @ 2018-05-13 20:51 UTC (permalink / raw)
To: Jan Kara
Cc: Luis R. Rodriguez, viro, darrick.wong, adilger.kernel, clm,
jbacik, dsterba, sandeen, dhowells, fliu, jeffm, nborisov,
jake.norris, mtk.manpages, linux-api, linux-fsdevel, linux-xfs,
linux-ext4, linux-btrfs, linux-kernel
In-Reply-To: <20180511211218.rs365ftuw53c4qj2@quack2.suse.cz>
On Fri, May 11, 2018 at 11:12:18PM +0200, Jan Kara wrote:
> On Thu 10-05-18 16:13:58, Luis R. Rodriguez wrote:
> > The Linux VFS does not allow a way to set append/immuttable
> > attributes to symlinks, this is just not possible. If this is
> > detected inform the user as the filesystem must be corrupted.
> >
> > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
>
> Looks good to me. You can add:
>
> Reviewed-by: Jan Kara <jack@suse.cz>
Applied into the ext4 tree after verifying that e2fsck already handles
this case:
% e2fsck -fy /tmp/foo.img
e2fsck 1.44.1 (24-Mar-2018)
Pass 1: Checking inodes, blocks, and sizes
Special (device/socket/fifo/symlink) file (inode 13) has immutable
or append-only flag set. Clear? yes
(The btrfs and xfs maintainers might want to make a similar check
before accepting their respective patches.)
- Ted
^ permalink raw reply
* Re: [PATCH v5 5/7] proc: instantiate only pids that we can ptrace on 'limit_pids=1' mount option
From: Alexey Gladkov @ 2018-05-14 8:29 UTC (permalink / raw)
To: Linus Torvalds
Cc: Kees Cook, Andrew Lutomirski, Andrew Morton, linux-fsdevel,
Linux Kernel Mailing List, Kernel Hardening, LSM List, Linux API,
Greg Kroah-Hartman, Al Viro, Akinobu Mita, Oleg Nesterov,
Jeff Layton, Ingo Molnar, Alexey Dobriyan, Eric W. Biederman,
Daniel Micay, Jonathan Corbet, J.
In-Reply-To: <CA+55aFxYwH6dw=bsQJHEgkM_iZfVNerqn+RAXrrY2iufJag6Qw@mail.gmail.com>
On Fri, May 11, 2018 at 09:45:33AM -0700, Linus Torvalds wrote:
> On Fri, May 11, 2018 at 2:46 AM Alexey Gladkov <gladkov.alexey@gmail.com>
> wrote:
>
> > + /* Limit procfs to only ptracable tasks */
> > + if (limit_pids == PROC_LIMIT_PIDS_PTRACE) {
> > + cond_resched();
> > + if (!has_pid_permissions(fs_info, task,
> HIDEPID_NO_ACCESS))
> > + goto out_put_task;
> > + }
>
> Where did that "cond_resched()" come from? That doesn't seem to make a lot
> of sense.
This call came along with has_pid_permissions from proc_pid_readdir [1]. It
seems to me that proc_pid_readdir and proc_pid_lookup should act in a
similar way in this case.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3ba4bceef23206349d4130ddf140819b365de7c8
--
Rgrds, legion
^ permalink raw reply
* Re: [PATCH v5 5/7] proc: instantiate only pids that we can ptrace on 'limit_pids=1' mount option
From: Alexey Gladkov @ 2018-05-14 8:34 UTC (permalink / raw)
To: Randy Dunlap
Cc: Kees Cook, Andy Lutomirski, Andrew Morton, linux-fsdevel,
linux-kernel, kernel-hardening, linux-security-module, linux-api,
Greg Kroah-Hartman, Alexander Viro, Akinobu Mita, Oleg Nesterov,
Jeff Layton, Ingo Molnar, Alexey Dobriyan, Eric W. Biederman,
Linus Torvalds, aniel Micay, Jonathan Corbet, bfields,
Stephen Rothwell
In-Reply-To: <7c638a92-8c40-fa15-8c63-777232588137@infradead.org>
On Fri, May 11, 2018 at 09:09:04AM -0700, Randy Dunlap wrote:
> On 05/11/2018 02:36 AM, Alexey Gladkov wrote:
> > From: Djalal Harouni <tixxdz@gmail.com>
> >
> > If "limit_pids=1" mount option is set then do not instantiate pids that
> > we can not ptrace. "limit_pids=1" means that procfs should only contain
> > pids that the caller can ptrace.
>
> Where can I find documentation on these mount options (pidonly, limit_pids)?
The documentation is not ready yet. It will be added in the next version
of the patchset.
--
Rgrds, legion
^ permalink raw reply
* Re: [PATCH v5 7/7] proc: add option to mount only a pids subset
From: Alexey Gladkov @ 2018-05-14 9:01 UTC (permalink / raw)
To: Jann Horn
Cc: Kees Cook, Andy Lutomirski, Andrew Morton, linux-fsdevel,
kernel list, Kernel Hardening, linux-security-module, Linux API,
Greg Kroah-Hartman, Alexander Viro, Akinobu Mita, Oleg Nesterov,
Jeff Layton, Ingo Molnar, Alexey Dobriyan, Eric W. Biederman,
Linus Torvalds, aniel Micay, Jon
In-Reply-To: <CAG48ez0bXvp1iF=HqyhEP1p5B6PRR07_j0qRoypJqs8x3Z+=mw@mail.gmail.com>
On Fri, May 11, 2018 at 03:58:39PM +0200, Jann Horn wrote:
> On Fri, May 11, 2018 at 11:37 AM, Alexey Gladkov
> <gladkov.alexey@gmail.com> wrote:
> > This allows to hide all files and directories in the procfs that are not
> > related to tasks.
>
> /proc/$pid/net and /proc/$pid/task/$tid/net aren't in scope for this
> protection, even though they contain information about the whole
> network namespace of the task, right?
Yes. The pidonly makes visible only pids subset. You can still access the
process namespaces via /proc/$pid/ns.
We can think of additional constraints since the parameters are not
stored in the pid namespace anymore.
--
Rgrds, legion
^ permalink raw reply
* Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
From: Florian Weimer @ 2018-05-14 12:01 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-arch, Linux-MM, Linux API, X86 ML, linuxram, Dave Hansen,
linux-x86_64, linuxppc-dev
In-Reply-To: <CALCETrUGjN8mhOaLqGcau-pPKm9TQW8k05hZrh52prRNdC5yQQ@mail.gmail.com>
On 05/09/2018 04:41 PM, Andy Lutomirski wrote:
> Hmm. I can get on board with the idea that fork() / clone() /
> pthread_create() are all just special cases of the idea that the thread
> that*calls* them should have the right pkey values, and the latter is
> already busted given our inability to asynchronously propagate the new mode
> in pkey_alloc(). So let's so PKEY_ALLOC_SETSIGNAL as a starting point.
Ram, any suggestions for implementing this on POWER?
> One thing we could do, though: the current initual state on process
> creation is all access blocked on all keys. We could change it so that
> half the keys are fully blocked and half are read-only. Then we could add
> a PKEY_ALLOC_STRICT or similar that allocates a key with the correct
> initial state*and* does the setsignal thing. If there are no keys left
> with the correct initial state, then it fails.
The initial PKRU value can currently be configured by the system
administrator. I fear this approach has too many moving parts to be viable.
Thanks,
Florian
^ permalink raw reply
* Re: [PATCH v5 7/7] proc: add option to mount only a pids subset
From: Eric W. Biederman @ 2018-05-14 13:13 UTC (permalink / raw)
To: Alexey Gladkov
Cc: Jann Horn, Kees Cook, Andy Lutomirski, Andrew Morton,
linux-fsdevel, kernel list, Kernel Hardening,
linux-security-module, Linux API, Greg Kroah-Hartman,
Alexander Viro, Akinobu Mita, Oleg Nesterov, Jeff Layton,
Ingo Molnar, Alexey Dobriyan, Linus Torvalds, aniel Micay,
Jonathan Corbet
In-Reply-To: <20180514090117.GC28179@comp-core-i7-2640m-0182e6>
Alexey Gladkov <gladkov.alexey@gmail.com> writes:
> On Fri, May 11, 2018 at 03:58:39PM +0200, Jann Horn wrote:
>> On Fri, May 11, 2018 at 11:37 AM, Alexey Gladkov
>> <gladkov.alexey@gmail.com> wrote:
>> > This allows to hide all files and directories in the procfs that are not
>> > related to tasks.
>>
>> /proc/$pid/net and /proc/$pid/task/$tid/net aren't in scope for this
>> protection, even though they contain information about the whole
>> network namespace of the task, right?
>
> Yes. The pidonly makes visible only pids subset. You can still access the
> process namespaces via /proc/$pid/ns.
>
> We can think of additional constraints since the parameters are not
> stored in the pid namespace anymore.
pidonly is fine.
You have to be very careful with this. The existing hidepid option
needs to live in the pid namespace. The issue is if someone is allowed
to mount proc and play with these options as in remount you this may
cause issues.
Eric
^ permalink raw reply
* Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
From: Andy Lutomirski @ 2018-05-14 15:32 UTC (permalink / raw)
To: Florian Weimer
Cc: linux-arch, Linux-MM, Linux API, X86 ML, linuxram, Dave Hansen,
linux-x86_64, Andy Lutomirski, linuxppc-dev
In-Reply-To: <008010c1-20a1-c307-25ac-8a69d672d031@redhat.com>
> On May 14, 2018, at 5:01 AM, Florian Weimer <fweimer@redhat.com> wrote:
>
>> One thing we could do, though: the current initual state on process
>> creation is all access blocked on all keys. We could change it so that
>> half the keys are fully blocked and half are read-only. Then we could add
>> a PKEY_ALLOC_STRICT or similar that allocates a key with the correct
>> initial state*and* does the setsignal thing. If there are no keys left
>> with the correct initial state, then it fails.
>
> The initial PKRU value can currently be configured by the system administrator. I fear this approach has too many moving parts to be viable.
>
>
Honestly, I think we should drop that option. I don’t see how we can expect an administrator to do this usefully.
^ permalink raw reply
* Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
From: Florian Weimer @ 2018-05-14 15:34 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-arch, Linux-MM, Linux API, X86 ML, linuxram, Dave Hansen,
linux-x86_64, Andy Lutomirski, linuxppc-dev
In-Reply-To: <E77C6E12-EF2A-435A-AAD4-1554459606F1@amacapital.net>
On 05/14/2018 05:32 PM, Andy Lutomirski wrote:
>
>
>
>> On May 14, 2018, at 5:01 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>
>>> One thing we could do, though: the current initual state on process
>>> creation is all access blocked on all keys. We could change it so that
>>> half the keys are fully blocked and half are read-only. Then we could add
>>> a PKEY_ALLOC_STRICT or similar that allocates a key with the correct
>>> initial state*and* does the setsignal thing. If there are no keys left
>>> with the correct initial state, then it fails.
>>
>> The initial PKRU value can currently be configured by the system administrator. I fear this approach has too many moving parts to be viable.
>>
>>
>
> Honestly, I think we should drop that option. I don’t see how we can expect an administrator to do this usefully.
I don't disagree—it makes things way less predictable in practice.
Thanks,
Florian
^ permalink raw reply
* [patch v20 0/4] JTAG driver introduction
From: Oleksandr Shamray @ 2018-05-14 16:19 UTC (permalink / raw)
To: gregkh, arnd
Cc: linux-kernel, linux-arm-kernel, devicetree, openbmc, joel, jiri,
tklauser, linux-serial, vadimp, system-sw-low-level, robh+dt,
openocd-devel-owner, linux-api, davem, mchehab, Oleksandr Shamray
When a need raise up to use JTAG interface for system's devices
programming or CPU debugging, usually the user layer
application implements jtag protocol by bit-bang or using a
proprietary connection to vendor hardware.
This method can be slow and not generic.
We propose to implement general JTAG interface and infrastructure
to communicate with user layer application. In such way, we can
have the standard JTAG interface core part and separation from
specific HW implementation.
This allow new capability to debug the CPU or program system's
device via BMC without additional devices nor cost.
This patch purpose is to add JTAG master core infrastructure by
defining new JTAG class and provide generic JTAG interface
to allow hardware specific drivers to connect this interface.
This will enable all JTAG drivers to use the common interface
part and will have separate for hardware implementation.
The JTAG (Joint Test Action Group) core driver provides minimal generic
JTAG interface, which can be used by hardware specific JTAG master
controllers. By providing common interface for the JTAG controllers,
user space device programing is hardware independent.
Modern SoC which in use for embedded system' equipped with
internal JTAG master interface.
This interface is used for programming and debugging system's
hardware components, like CPLD, FPGA, CPU, voltage and
industrial controllers.
Firmware for such devices can be upgraded through JTAG interface during
Runtime. The JTAG standard support for multiple devices programming,
is in case their lines are daisy-chained together.
For example, systems which equipped with host CPU, BMC SoC or/and
number of programmable devices are capable to connect a pin and
select system components dynamically for programming and debugging,
This is using by the BMC which is equipped with internal SoC master
controller.
For example:
BMC JTAG master --> pin selected to CPLDs chain for programming (filed
upgrade, production)
BMC JTAG master --> pin selected to voltage monitors for programming
(field upgrade, production)
BMC JTAG master --> pin selected to host CPU (on-site debugging
and developers debugging)
For example, we can have application in user space which using calls
to JTAG driver executes CPLD programming directly from SVF file
The JTAG standard (IEEE 1149.1) defines the next connector pins:
- TDI (Test Data In);
- TDO (Test Data Out);
- TCK (Test Clock);
- TMS (Test Mode Select);
- TRST (Test Reset) (Optional);
The SoC equipped with JTAG master controller, performs
device programming on command or vector level. For example
a file in a standard SVF (Serial Vector Format) that contains
boundary scan vectors, can be used by sending each vector
to the JTAG interface and the JTAG controller will execute
the programming.
Initial version provides the system calls set for:
- SIR (Scan Instruction Register, IEEE 1149.1 Instruction Register scan);
- SDR (Scan Data Register, IEEE 1149.1 Data Register scan);
- RUNTEST (Forces the IEEE 1149.1 bus to a run state for a specified
number of clocks.
SoC which are not equipped with JTAG master interface, can be built
on top of JTAG core driver infrastructure, by applying bit-banging of
TDI, TDO, TCK and TMS pins within the hardware specific driver.
Oleksandr Shamray (4):
drivers: jtag: Add JTAG core driver
drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master
driver
Documentation: jtag: Add bindings for Aspeed SoC 24xx and 25xx
families JTAG master driver
Documentation: jtag: Add ABI documentation
Documentation/ABI/testing/jtag-dev | 27 +
.../devicetree/bindings/jtag/aspeed-jtag.txt | 22 +
Documentation/ioctl/ioctl-number.txt | 2 +
Documentation/jtag/overview | 28 +
Documentation/jtag/transactions | 109 +++
MAINTAINERS | 10 +
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/jtag/Kconfig | 32 +
drivers/jtag/Makefile | 2 +
drivers/jtag/jtag-aspeed.c | 786 ++++++++++++++++++++
drivers/jtag/jtag.c | 274 +++++++
include/linux/jtag.h | 41 +
include/uapi/linux/jtag.h | 105 +++
14 files changed, 1441 insertions(+), 0 deletions(-)
create mode 100644 Documentation/ABI/testing/jtag-dev
create mode 100644 Documentation/devicetree/bindings/jtag/aspeed-jtag.txt
create mode 100644 Documentation/jtag/overview
create mode 100644 Documentation/jtag/transactions
create mode 100644 drivers/jtag/Kconfig
create mode 100644 drivers/jtag/Makefile
create mode 100644 drivers/jtag/jtag-aspeed.c
create mode 100644 drivers/jtag/jtag.c
create mode 100644 include/linux/jtag.h
create mode 100644 include/uapi/linux/jtag.h
^ 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