Messages in this thread | | | Date | Tue, 11 Sep 2018 08:50:14 +0200 | From | Gerd Hoffmann <> | Subject | Re: [PATCH v7] Add udmabuf misc device |
| |
Hi,
> > +#define UDMABUF_CREATE _IOW('u', 0x42, struct udmabuf_create) > > Why do you start at 0x42 if you reserve the 0x40-0x4f range ?
No particular strong reason, just that using 42 was less boring than starting with 0x40.
> > +#define UDMABUF_CREATE_LIST _IOW('u', 0x43, struct udmabuf_create_list) > > Where's the documentation ? :-)
Isn't it simple enough?
But, well, yes, I guess I can add some kerneldoc comments.
> > +static int udmabuf_vm_fault(struct vm_fault *vmf) > > +{ > > + struct vm_area_struct *vma = vmf->vma; > > + struct udmabuf *ubuf = vma->vm_private_data; > > + > > + if (WARN_ON(vmf->pgoff >= ubuf->pagecount)) > > + return VM_FAULT_SIGBUS; > > Just curious, when do you expect this to happen ?
It should not. If it actually happens it would be a bug somewhere, thats why the WARN_ON.
> > + struct udmabuf *ubuf;
> > + ubuf = kzalloc(sizeof(struct udmabuf), GFP_KERNEL); > > sizeof(*ubuf)
Why? Should not make a difference ...
> > + memfd = fget(list[i].memfd); > > + if (!memfd) > > + goto err_put_pages; > > + if (!shmem_mapping(file_inode(memfd)->i_mapping)) > > + goto err_put_pages; > > + seals = memfd_fcntl(memfd, F_GET_SEALS, 0); > > + if (seals == -EINVAL || > > + (seals & SEALS_WANTED) != SEALS_WANTED || > > + (seals & SEALS_DENIED) != 0) > > + goto err_put_pages; > > All these conditions will return -EINVAL. I'm not familiar with the memfd API, > should some error conditions return a different error code to make them > distinguishable by userspace ?
Hmm, I guess EBADFD would be reasonable in case the file handle isn't a memfd. Other suggestions?
I'll prepare a fixup patch series addressing most of the other review comments.
cheers, Gerd
| |