Re: [PATCH] tty: provide tty_name() even without CONFIG_TTY

From: Paul Moore
Date: Wed Apr 27 2016 - 12:20:11 EST


On Wed, Apr 27, 2016 at 5:56 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> The audit subsystem just started printing the name of the tty,
> but that causes a build failure when CONFIG_TTY is disabled:
>
> kernel/built-in.o: In function `audit_log_task_info':
> memremap.c:(.text+0x5e34c): undefined reference to `tty_name'
> kernel/built-in.o: In function `audit_set_loginuid':
> memremap.c:(.text+0x63b34): undefined reference to `tty_name'
>
> This adds tty_name() to the list of functions that are provided
> as trivial stubs in that configuration.
>
> Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
> Fixes: db0a6fb5d97a ("audit: add tty field to LOGIN event")
> ---
> include/linux/tty.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)

Thanks for reporting this and providing a patch; I'll be happy to
merge this into the audit#next branch with commit db0a6fb5d97a but I
have one question (see below).

> diff --git a/include/linux/tty.h b/include/linux/tty.h
> index 3b09f235db66..17b247c94440 100644
> --- a/include/linux/tty.h
> +++ b/include/linux/tty.h
> @@ -371,6 +371,7 @@ extern void proc_clear_tty(struct task_struct *p);
> extern struct tty_struct *get_current_tty(void);
> /* tty_io.c */
> extern int __init tty_init(void);
> +extern const char *tty_name(const struct tty_struct *tty);
> #else
> static inline void console_init(void)
> { }
> @@ -391,6 +392,8 @@ static inline struct tty_struct *get_current_tty(void)
> /* tty_io.c */
> static inline int __init tty_init(void)
> { return 0; }
> +static inline const char *tty_name(const struct tty_struct *tty)
> +{ return "(none)"; }
> #endif

As it currently stands tty_name() returns "NULL tty" when the passed
tty_struct is NULL while this patch returns "(none)" in the case of
CONFIG_TTY=n; it seems like some consistency might be good, yes? Or
do you think there is value in differentiating between the two cases?

>From an audit point of view, we would prefer if both were "(none)".

--
paul moore
www.paul-moore.com