Re: [RFC v2 0/2] vfs / btrfs: add support for ustat()

[Luis R. Rodriguez]

On Thu, Jul 17, 2014 at 01:03:01AM -0700, Christoph Hellwig wrote:
> On Wed, Jul 16, 2014 at 02:37:56PM -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@xxxxxxxx>
> > 
> > This makes the implementation simpler by stuffing the struct on
> > the driver and just letting the driver iinsert it and remove it
> > onto the sb list. This avoids the kzalloc() completely.
> 
> Again, NAK.  Make btrfs report the proper anon dev_t in stat and
> everything will just work.

Let's consider this userspace case:

        struct stat buf;                                                        
        struct ustat ubuf;                                                      
                                                                                
        /* Find a valid device number */                                        
        if (stat("/", &buf)) {
                fprintf(stderr, "Stat failed: %s\n", strerror(errno));          
                return 1;                                                       
        }                                                                       
                                                                                
        /* Call ustat on it */                                                  
        if (ustat(buf.st_dev, &ubuf)) {                                         
                fprintf(stderr, "Ustat failed: %s\n", strerror(errno));         
                return 1;                                                       
        } 

In the btrfs case it has an inode op for getattr, that is used and we set
the dev to anonymous dev_t. Later ustat will use user_get_super() which
will only be able to work with a userblock if the super block's only
dev_t is assigned to it. Since we have many anonymous to dev_t mapping
to super block though we can't complete the search for btfs and ustat()
fails with -EINVAL. The series expands the number of dev_t's that a super
block can have and allows this search to complete.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/