linux-kernel - Re: [PATCH RESEND] pty: show associative slave of ptmx in fdinfo

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170717144154.GA26498@kroah.com>
Date:   Mon, 17 Jul 2017 16:41:54 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Masatake YAMATO <yamato@...hat.com>
Cc:     linux-kernel@...r.kernel.org, jslaby@...e.com
Subject: Re: [PATCH RESEND] pty: show associative slave of ptmx in fdinfo

On Thu, Jul 13, 2017 at 04:34:37AM +0900, Masatake YAMATO wrote:
> This patch adds "tty-index" field to /proc/PID/fdinfo/N if N
> specifies /dev/ptmx. The field shows the index of associative
> slave pts.
> 
> Though a minor number is given for each pts instance, ptmx is not.
> It means there is no way in user-space to know the association between
> file descriptors for pts/n and ptmx. (n = 0, 1, ...)
> 
> This is different from pipe. About pipe such association can be solved
> by inode of pipefs.
> 
> Providing the way to know the association between pts/n and ptmx helps
> users understand the status of running system. lsof can utilize this field.
> 
> Signed-off-by: Masatake YAMATO <yamato@...hat.com>
> ---
>  drivers/tty/pty.c          | 12 +++++++++++-
>  drivers/tty/tty_io.c       | 15 +++++++++++++++
>  include/linux/tty_driver.h |  5 +++++
>  3 files changed, 31 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
> index 6579957..9357c6a 100644
> --- a/drivers/tty/pty.c
> +++ b/drivers/tty/pty.c
> @@ -669,6 +669,13 @@ static void pty_unix98_remove(struct tty_driver *driver, struct tty_struct *tty)
>  	}
>  }
>  
> +#ifdef CONFIG_PROC_FS

There is no real need for all of the #ifdef everywhere here, if PROC_FS
is not enabled, the functions will just not be called, right?

Can you fix this up and resend a new version?

thanks,

greg k-h