Re: [Cluster-devel] [PATCH v2 1/2] fs: warn about impending deprecation of mandatory locks

2021-08-20 Thread Steven Rostedt
On Fri, 20 Aug 2021 17:52:19 +0200
David Hildenbrand  wrote:

> > +static bool warned_mand;
> >   static inline bool may_mandlock(void)
> >   {
> > +   if (!warned_mand) {
> > +   warned_mand = true;
> > +   
> > pr_warn("==\n");
> > +   pr_warn("WARNING: the mand mount option is being deprecated 
> > and\n");
> > +   pr_warn(" will be removed in v5.15!\n");
> > +   
> > pr_warn("==\n");
> > +   }  
> 
> Is there a reason not to use pr_warn_once() ?

You would need a single call though, otherwise each pr_warn_once()
would have its own state that it warned once.

const char warning[] =
"==\n"
"WARNING: the mand mount option is being deprecated and\n"
" will be removed in v5.15!\n"
"==\n";

pr_warn_once(warning);

-- Steve



Re: [Cluster-devel] [PATCH v2 1/2] fs: warn about impending deprecation of mandatory locks

2021-08-20 Thread Jeff Layton
On Fri, 2021-08-20 at 17:52 +0200, David Hildenbrand wrote:
> On 20.08.21 15:57, Jeff Layton wrote:
> > We've had CONFIG_MANDATORY_FILE_LOCKING since 2015 and a lot of distros
> > have disabled it. Warn the stragglers that still use "-o mand" that
> > we'll be dropping support for that mount option.
> > 
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Jeff Layton 
> > ---
> >   fs/namespace.c | 8 
> >   1 file changed, 8 insertions(+)
> > 
> > diff --git a/fs/namespace.c b/fs/namespace.c
> > index ab4174a3c802..ffab0bb1e649 100644
> > --- a/fs/namespace.c
> > +++ b/fs/namespace.c
> > @@ -1716,8 +1716,16 @@ static inline bool may_mount(void)
> >   }
> >   
> >   #ifdefCONFIG_MANDATORY_FILE_LOCKING
> > +static bool warned_mand;
> >   static inline bool may_mandlock(void)
> >   {
> > +   if (!warned_mand) {
> > +   warned_mand = true;
> > +   
> > pr_warn("==\n");
> > +   pr_warn("WARNING: the mand mount option is being deprecated 
> > and\n");
> > +   pr_warn(" will be removed in v5.15!\n");
> > +   
> > pr_warn("==\n");
> > +   }
> 
> Is there a reason not to use pr_warn_once() ?
> 
> 

No reason at all. I'll send out a v3 set in a bit with that change.

Thanks!
-- 
Jeff Layton 



Re: [Cluster-devel] [PATCH v2 1/2] fs: warn about impending deprecation of mandatory locks

2021-08-20 Thread David Laight
From: Jeff Layton
> Sent: 20 August 2021 14:57
> 
> We've had CONFIG_MANDATORY_FILE_LOCKING since 2015 and a lot of distros
> have disabled it. Warn the stragglers that still use "-o mand" that
> we'll be dropping support for that mount option.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jeff Layton 
> ---
>  fs/namespace.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/fs/namespace.c b/fs/namespace.c
> index ab4174a3c802..ffab0bb1e649 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -1716,8 +1716,16 @@ static inline bool may_mount(void)
>  }
> 
>  #ifdef   CONFIG_MANDATORY_FILE_LOCKING
> +static bool warned_mand;
>  static inline bool may_mandlock(void)
>  {
> + if (!warned_mand) {
> + warned_mand = true;
> + 
> pr_warn("==\n");
> + pr_warn("WARNING: the mand mount option is being deprecated 
> and\n");
> + pr_warn(" will be removed in v5.15!\n");
> + 
> pr_warn("==\n");
> + }
>   return capable(CAP_SYS_ADMIN);
>  }

If that is called more than once you don't want the 'inline'.
I doubt it matters is not inlined - hardly a hot path.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)




Re: [Cluster-devel] [PATCH v2 1/2] fs: warn about impending deprecation of mandatory locks

2021-08-20 Thread David Hildenbrand

On 20.08.21 15:57, Jeff Layton wrote:

We've had CONFIG_MANDATORY_FILE_LOCKING since 2015 and a lot of distros
have disabled it. Warn the stragglers that still use "-o mand" that
we'll be dropping support for that mount option.

Cc: sta...@vger.kernel.org
Signed-off-by: Jeff Layton 
---
  fs/namespace.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/fs/namespace.c b/fs/namespace.c
index ab4174a3c802..ffab0bb1e649 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1716,8 +1716,16 @@ static inline bool may_mount(void)
  }
  
  #ifdef	CONFIG_MANDATORY_FILE_LOCKING

+static bool warned_mand;
  static inline bool may_mandlock(void)
  {
+   if (!warned_mand) {
+   warned_mand = true;
+   
pr_warn("==\n");
+   pr_warn("WARNING: the mand mount option is being deprecated 
and\n");
+   pr_warn(" will be removed in v5.15!\n");
+   
pr_warn("==\n");
+   }


Is there a reason not to use pr_warn_once() ?


--
Thanks,

David / dhildenb



Re: [Cluster-devel] [PATCH v2 1/2] fs: warn about impending deprecation of mandatory locks

2021-08-20 Thread Jeff Layton
On Fri, 2021-08-20 at 15:49 +, David Laight wrote:
> From: Jeff Layton
> > Sent: 20 August 2021 14:57
> > 
> > We've had CONFIG_MANDATORY_FILE_LOCKING since 2015 and a lot of distros
> > have disabled it. Warn the stragglers that still use "-o mand" that
> > we'll be dropping support for that mount option.
> > 
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Jeff Layton 
> > ---
> >  fs/namespace.c | 8 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/fs/namespace.c b/fs/namespace.c
> > index ab4174a3c802..ffab0bb1e649 100644
> > --- a/fs/namespace.c
> > +++ b/fs/namespace.c
> > @@ -1716,8 +1716,16 @@ static inline bool may_mount(void)
> >  }
> > 
> >  #ifdef CONFIG_MANDATORY_FILE_LOCKING
> > +static bool warned_mand;
> >  static inline bool may_mandlock(void)
> >  {
> > +   if (!warned_mand) {
> > +   warned_mand = true;
> > +   
> > pr_warn("==\n");
> > +   pr_warn("WARNING: the mand mount option is being deprecated 
> > and\n");
> > +   pr_warn(" will be removed in v5.15!\n");
> > +   
> > pr_warn("==\n");
> > +   }
> > return capable(CAP_SYS_ADMIN);
> >  }
> 
> If that is called more than once you don't want the 'inline'.
> I doubt it matters is not inlined - hardly a hot path.
> 
>   David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 
> 1PT, UK
> Registration No: 1397386 (Wales)
> 

ACK. Of course. That really needs to not be inline. I'll fix that up in
my tree.

Thanks!
-- 
Jeff Layton