From: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
To: drepper-85h5CteqBpZAfugRpC6u6w@public.gmane.org
Cc: kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org,
wilsons-bbsPK2OMKKo@public.gmane.org,
linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Yoshinori Sato
<ysato-Rn4VEauK+AKRv+LV9MX5uooqe+aC9MnS@public.gmane.org>,
Geert Uytterhoeven
<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>,
Chris Zankel <chris-YvXeqwSYzG2sTnJN9+BGXg@public.gmane.org>
Subject: Re: [PATCH] Add cloexec information to fdinfo
Date: Mon, 20 Jun 2011 14:31:31 -0700 [thread overview]
Message-ID: <20110620143131.9c6e040c.akpm@linux-foundation.org> (raw)
In-Reply-To: <201106100355.p5A3t8Aa024924-/1RLGD9tqMZ22nUyOigohnmVWlWGoA+o+lehtg8QC5Y@public.gmane.org>
On Thu, 9 Jun 2011 23:55:08 -0400
drepper-85h5CteqBpZAfugRpC6u6w@public.gmane.org wrote:
> There is one piece of information about a file descriptor which is
> currently not visible from the outside: the close-on-exec flag. The
> /proc/PID/fdinfo/* files have the mode information but this is
> missing. Is the following patch acceptable?
>
> What I don't know is whether the RCU locking is needed given that
> real locks are taken. Someone with more knowledge could just
> remove those two lines.
The locking looks OK to me.
Hopefully /prod/pid/fdinfo is documented somewhere.
linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org appears to be the email address we use to rub
the documentation lamp.
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index 14def99..bda3651 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -1924,12 +1924,23 @@ static int proc_fd_info(struct inode *inode, struct path *path, char *info)
> *path = file->f_path;
> path_get(&file->f_path);
> }
> - if (info)
> + if (info) {
> + int cloexec;
> + struct fdtable *fdt;
> +
> + rcu_read_lock();
> + fdt = files_fdtable(files);
> + cloexec = FD_ISSET(fd, fdt->close_on_exec);
Does FD_ISSET return 0 or 1? Or 0 or non-zero?
For x86 it's the former.
<checks the architectures>
arch/h8300/include/asm/posix_types.h: busted
#define __FD_ISSET(d, set) ((set)->fds_bits[__FDELT(d)] & __FDMASK(d))
arch/m68k/include/asm/posix_types.h: busted
#define __FD_ISSET(d, set) ((set)->fds_bits[__FDELT(d)] & __FDMASK(d))
arch/xtensa/include/asm/posix_types.h: busted
#define __FD_ISSET(d, set) ((set)->fds_bits[__FDELT(d)] & __FDMASK(d))
From: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Harmonise these return values with other architectures. In some cases
this affects all compilers and in other cases non-gcc compilers only.
Cc: Yoshinori Sato <ysato-Rn4VEauK+AKRv+LV9MX5uooqe+aC9MnS@public.gmane.org>
Cc: Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
Cc: Chris Zankel <chris-YvXeqwSYzG2sTnJN9+BGXg@public.gmane.org>
Cc: Ulrich Drepper <drepper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
---
arch/h8300/include/asm/posix_types.h | 2 +-
arch/m68k/include/asm/posix_types.h | 2 +-
arch/xtensa/include/asm/posix_types.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff -puN arch/h8300/include/asm/posix_types.h~h8300-m68k-xtensa-__fd_isset-should-return-0-1 arch/h8300/include/asm/posix_types.h
--- a/arch/h8300/include/asm/posix_types.h~h8300-m68k-xtensa-__fd_isset-should-return-0-1
+++ a/arch/h8300/include/asm/posix_types.h
@@ -50,7 +50,7 @@ typedef struct {
#define __FD_CLR(d, set) ((set)->fds_bits[__FDELT(d)] &= ~__FDMASK(d))
#undef __FD_ISSET
-#define __FD_ISSET(d, set) ((set)->fds_bits[__FDELT(d)] & __FDMASK(d))
+#define __FD_ISSET(d, set) (!!((set)->fds_bits[__FDELT(d)] & __FDMASK(d)))
#undef __FD_ZERO
#define __FD_ZERO(fdsetp) (memset (fdsetp, 0, sizeof(*(fd_set *)fdsetp)))
diff -puN arch/m68k/include/asm/posix_types.h~h8300-m68k-xtensa-__fd_isset-should-return-0-1 arch/m68k/include/asm/posix_types.h
--- a/arch/m68k/include/asm/posix_types.h~h8300-m68k-xtensa-__fd_isset-should-return-0-1
+++ a/arch/m68k/include/asm/posix_types.h
@@ -51,7 +51,7 @@ typedef struct {
#define __FD_CLR(d, set) ((set)->fds_bits[__FDELT(d)] &= ~__FDMASK(d))
#undef __FD_ISSET
-#define __FD_ISSET(d, set) ((set)->fds_bits[__FDELT(d)] & __FDMASK(d))
+#define __FD_ISSET(d, set) (!!((set)->fds_bits[__FDELT(d)] & __FDMASK(d)))
#undef __FD_ZERO
#define __FD_ZERO(fdsetp) (memset (fdsetp, 0, sizeof(*(fd_set *)fdsetp)))
diff -puN arch/xtensa/include/asm/posix_types.h~h8300-m68k-xtensa-__fd_isset-should-return-0-1 arch/xtensa/include/asm/posix_types.h
--- a/arch/xtensa/include/asm/posix_types.h~h8300-m68k-xtensa-__fd_isset-should-return-0-1
+++ a/arch/xtensa/include/asm/posix_types.h
@@ -58,7 +58,7 @@ typedef struct {
#define __FD_SET(d, set) ((set)->fds_bits[__FDELT(d)] |= __FDMASK(d))
#define __FD_CLR(d, set) ((set)->fds_bits[__FDELT(d)] &= ~__FDMASK(d))
-#define __FD_ISSET(d, set) ((set)->fds_bits[__FDELT(d)] & __FDMASK(d))
+#define __FD_ISSET(d, set) (!!((set)->fds_bits[__FDELT(d)] & __FDMASK(d)))
#define __FD_ZERO(set) \
((void) memset ((void *) (set), 0, sizeof (__kernel_fd_set)))
_
> + rcu_read_unlock();
> +
> snprintf(info, PROC_FDINFO_MAX,
> "pos:\t%lli\n"
> - "flags:\t0%o\n",
> + "flags:\t0%o\n"
> + "cloexec: %d\n",
Should use a tab here for consistency.
--- a/fs/proc/base.c~proc-pid-fdinfo-add-cloexec-information-fix
+++ a/fs/proc/base.c
@@ -1936,7 +1936,7 @@ static int proc_fd_info(struct inode *in
snprintf(info, PROC_FDINFO_MAX,
"pos:\t%lli\n"
"flags:\t0%o\n"
- "cloexec: %d\n",
+ "cloexec:\t%d\n",
(long long) file->f_pos,
file->f_flags,
cloexec);
_
> (long long) file->f_pos,
> - file->f_flags);
> + file->f_flags,
> + cloexec);
> + }
> spin_unlock(&files->file_lock);
> put_files_struct(files);
> return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: drepper@akkadia.org
Cc: kosaki.motohiro@jp.fujitsu.com, linux-kernel@vger.kernel.org,
rientjes@google.com, torvalds@linux-foundation.org,
viro@zeniv.linux.org.uk, wilsons@start.ca,
linux-man@vger.kernel.org,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Chris Zankel <chris@zankel.net>
Subject: Re: [PATCH] Add cloexec information to fdinfo
Date: Mon, 20 Jun 2011 14:31:31 -0700 [thread overview]
Message-ID: <20110620143131.9c6e040c.akpm@linux-foundation.org> (raw)
In-Reply-To: <201106100355.p5A3t8Aa024924@drepperk.user.openhosting.com>
On Thu, 9 Jun 2011 23:55:08 -0400
drepper@akkadia.org wrote:
> There is one piece of information about a file descriptor which is
> currently not visible from the outside: the close-on-exec flag. The
> /proc/PID/fdinfo/* files have the mode information but this is
> missing. Is the following patch acceptable?
>
> What I don't know is whether the RCU locking is needed given that
> real locks are taken. Someone with more knowledge could just
> remove those two lines.
The locking looks OK to me.
Hopefully /prod/pid/fdinfo is documented somewhere.
linux-man@vger.kernel.org appears to be the email address we use to rub
the documentation lamp.
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index 14def99..bda3651 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -1924,12 +1924,23 @@ static int proc_fd_info(struct inode *inode, struct path *path, char *info)
> *path = file->f_path;
> path_get(&file->f_path);
> }
> - if (info)
> + if (info) {
> + int cloexec;
> + struct fdtable *fdt;
> +
> + rcu_read_lock();
> + fdt = files_fdtable(files);
> + cloexec = FD_ISSET(fd, fdt->close_on_exec);
Does FD_ISSET return 0 or 1? Or 0 or non-zero?
For x86 it's the former.
<checks the architectures>
arch/h8300/include/asm/posix_types.h: busted
#define __FD_ISSET(d, set) ((set)->fds_bits[__FDELT(d)] & __FDMASK(d))
arch/m68k/include/asm/posix_types.h: busted
#define __FD_ISSET(d, set) ((set)->fds_bits[__FDELT(d)] & __FDMASK(d))
arch/xtensa/include/asm/posix_types.h: busted
#define __FD_ISSET(d, set) ((set)->fds_bits[__FDELT(d)] & __FDMASK(d))
From: Andrew Morton <akpm@linux-foundation.org>
Harmonise these return values with other architectures. In some cases
this affects all compilers and in other cases non-gcc compilers only.
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Chris Zankel <chris@zankel.net>
Cc: Ulrich Drepper <drepper@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/h8300/include/asm/posix_types.h | 2 +-
arch/m68k/include/asm/posix_types.h | 2 +-
arch/xtensa/include/asm/posix_types.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff -puN arch/h8300/include/asm/posix_types.h~h8300-m68k-xtensa-__fd_isset-should-return-0-1 arch/h8300/include/asm/posix_types.h
--- a/arch/h8300/include/asm/posix_types.h~h8300-m68k-xtensa-__fd_isset-should-return-0-1
+++ a/arch/h8300/include/asm/posix_types.h
@@ -50,7 +50,7 @@ typedef struct {
#define __FD_CLR(d, set) ((set)->fds_bits[__FDELT(d)] &= ~__FDMASK(d))
#undef __FD_ISSET
-#define __FD_ISSET(d, set) ((set)->fds_bits[__FDELT(d)] & __FDMASK(d))
+#define __FD_ISSET(d, set) (!!((set)->fds_bits[__FDELT(d)] & __FDMASK(d)))
#undef __FD_ZERO
#define __FD_ZERO(fdsetp) (memset (fdsetp, 0, sizeof(*(fd_set *)fdsetp)))
diff -puN arch/m68k/include/asm/posix_types.h~h8300-m68k-xtensa-__fd_isset-should-return-0-1 arch/m68k/include/asm/posix_types.h
--- a/arch/m68k/include/asm/posix_types.h~h8300-m68k-xtensa-__fd_isset-should-return-0-1
+++ a/arch/m68k/include/asm/posix_types.h
@@ -51,7 +51,7 @@ typedef struct {
#define __FD_CLR(d, set) ((set)->fds_bits[__FDELT(d)] &= ~__FDMASK(d))
#undef __FD_ISSET
-#define __FD_ISSET(d, set) ((set)->fds_bits[__FDELT(d)] & __FDMASK(d))
+#define __FD_ISSET(d, set) (!!((set)->fds_bits[__FDELT(d)] & __FDMASK(d)))
#undef __FD_ZERO
#define __FD_ZERO(fdsetp) (memset (fdsetp, 0, sizeof(*(fd_set *)fdsetp)))
diff -puN arch/xtensa/include/asm/posix_types.h~h8300-m68k-xtensa-__fd_isset-should-return-0-1 arch/xtensa/include/asm/posix_types.h
--- a/arch/xtensa/include/asm/posix_types.h~h8300-m68k-xtensa-__fd_isset-should-return-0-1
+++ a/arch/xtensa/include/asm/posix_types.h
@@ -58,7 +58,7 @@ typedef struct {
#define __FD_SET(d, set) ((set)->fds_bits[__FDELT(d)] |= __FDMASK(d))
#define __FD_CLR(d, set) ((set)->fds_bits[__FDELT(d)] &= ~__FDMASK(d))
-#define __FD_ISSET(d, set) ((set)->fds_bits[__FDELT(d)] & __FDMASK(d))
+#define __FD_ISSET(d, set) (!!((set)->fds_bits[__FDELT(d)] & __FDMASK(d)))
#define __FD_ZERO(set) \
((void) memset ((void *) (set), 0, sizeof (__kernel_fd_set)))
_
> + rcu_read_unlock();
> +
> snprintf(info, PROC_FDINFO_MAX,
> "pos:\t%lli\n"
> - "flags:\t0%o\n",
> + "flags:\t0%o\n"
> + "cloexec: %d\n",
Should use a tab here for consistency.
--- a/fs/proc/base.c~proc-pid-fdinfo-add-cloexec-information-fix
+++ a/fs/proc/base.c
@@ -1936,7 +1936,7 @@ static int proc_fd_info(struct inode *in
snprintf(info, PROC_FDINFO_MAX,
"pos:\t%lli\n"
"flags:\t0%o\n"
- "cloexec: %d\n",
+ "cloexec:\t%d\n",
(long long) file->f_pos,
file->f_flags,
cloexec);
_
> (long long) file->f_pos,
> - file->f_flags);
> + file->f_flags,
> + cloexec);
> + }
> spin_unlock(&files->file_lock);
> put_files_struct(files);
> return 0;
next prev parent reply other threads:[~2011-06-20 21:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-10 3:55 [PATCH] Add cloexec information to fdinfo drepper
2011-06-13 2:54 ` KOSAKI Motohiro
[not found] ` <201106100355.p5A3t8Aa024924-/1RLGD9tqMZ22nUyOigohnmVWlWGoA+o+lehtg8QC5Y@public.gmane.org>
2011-06-20 21:31 ` Andrew Morton [this message]
2011-06-20 21:31 ` Andrew Morton
2011-06-28 7:07 ` Ulrich Drepper
2011-06-28 17:23 ` Linus Torvalds
2011-06-29 8:15 ` Ulrich Drepper
2011-06-29 10:51 ` Pádraig Brady
2011-06-29 16:22 ` Linus Torvalds
2011-06-29 18:05 ` Linus Torvalds
2011-06-30 2:59 ` Ulrich Drepper
2011-06-30 13:39 ` Ulrich Drepper
2011-06-30 16:07 ` Linus Torvalds
2011-08-05 11:49 ` Ulrich Drepper
2011-08-06 18:58 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110620143131.9c6e040c.akpm@linux-foundation.org \
--to=akpm-de/tnxtf+jlsfhdxvbkv3wd2fqjk+8+b@public.gmane.org \
--cc=chris-YvXeqwSYzG2sTnJN9+BGXg@public.gmane.org \
--cc=drepper-85h5CteqBpZAfugRpC6u6w@public.gmane.org \
--cc=geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org \
--cc=kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
--cc=wilsons-bbsPK2OMKKo@public.gmane.org \
--cc=ysato-Rn4VEauK+AKRv+LV9MX5uooqe+aC9MnS@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.