On Fri, Oct 17, 2025 at 12:08:24PM +0100, Andrew Cooper wrote:
> On 17/10/2025 11:09 am, Thomas Gleixner wrote:
> > --- a/include/linux/uaccess.h
> > +++ b/include/linux/uaccess.h
> > +#define __scoped_masked_user_access(_mode, _uptr, _size, _elbl)            
> >                         \
> > +for (bool ____stop = false; !____stop; ____stop = true)                    
> >                         \
> > +   for (typeof((_uptr)) _tmpptr = __scoped_user_access_begin(_mode, _uptr, 
> > _size, _elbl);  \
> > +        !____stop; ____stop = true)                                        
> >                 \
> > +           for (CLASS(masked_user_##_mode##_access, scope) (_tmpptr); 
> > !____stop;           \
> > +                ____stop = true)                                   \
> > +                   /* Force modified pointer usage within the scope */     
> >                 \
> > +                   for (const typeof((_uptr)) _uptr = _tmpptr; !____stop; 
> > ____stop = true) \
> > +                           if (1)
> > +
> 
> Truly a thing of beauty.  At least the end user experience is nice.
> 
> One thing to be aware of is that:
> 
>     scoped_masked_user_rw_access(ptr, efault) {
>         unsafe_get_user(rval, &ptr->rval, efault);
>         unsafe_put_user(wval, &ptr->wval, efault);
>     } else {
>         // unreachable
>     }
> 
> will compile.  Instead, I think you want the final line of the macro to
> be "if (0) {} else" to prevent this.
> 
> 
> While we're on the subject, can we find some C standards people to lobby.
> 
> C2Y has a proposal to introduce "if (int foo =" syntax to generalise the
> for() loop special case.  Can we please see about fixing the restriction
> of only allowing a single type per loop?   This example could be a
> single loop if it weren't for that restriction.

So elsewhere, Linus suggested to use a struct to get around that. See
for example this lovely thing:

  
https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/commit/?h=locking/core&id=1bc5d8cefd0d9768dc03c83140dd54c552bea470


Reply via email to