[PATCH] decode mtd/ubi ioctls

[Dmitry V. Levin]

On Fri, May 03, 2013 at 11:15:52PM -0400, Mike Frysinger wrote:
> On Thursday 02 May 2013 19:03:30 Dmitry V. Levin wrote:
> > On Wed, May 01, 2013 at 11:35:30PM -0400, Mike Frysinger wrote:
> > > +int ubi_ioctl(struct tcb *tcp, long code, long arg)
> > > +{
> > > +	struct ubi_mkvol_req mkvol;
> > > +	struct ubi_rsvol_req rsvol;
> > > +	struct ubi_rnvol_req rnvol;
> > > +	struct ubi_attach_req attach;
> > > +	struct ubi_map_req map;
> > > +	struct ubi_set_vol_prop_req prop;
> > > +	/* 4*(n-1) + 3 for quotes and NUL */
> > > +	char vol_name[(UBI_MAX_VOLUME_NAME + 1) * 4];
> > > +
> > > +	if (entering(tcp))
> > > +		return 0;
> > > +
> > > +	switch (code) {
> > > +	case UBI_IOCMKVOL:
> > > +		if (!verbose(tcp) || umove(tcp, arg, &mkvol) < 0)
> > > +			return 0;
> > 
> > In this and many other similar cases, it looks like failed ioctl syscall
> > shouldn't be decoded in detail.  Please have a look whether my guess is
> > correct in case of mtd.c; if it is correct, then the code could be changed
> > to
> > 
> > 	if (entering(tcp) || syserror(tcp) || !verbose(tcp))
> > 		return 0;
> 
> unfortunately, i don't think we want that.  if we get back something like 
> EINVAL because the struct was incorrect, there's no way for us to figure things 
> out easily.
> 
> maybe instead we want to do (syserror(tcp) && abbrev()) ?

In case of _IOW ioctls, decoding is desirable regardless of syscall exit
status.  In fact, these ioctls could be decoded on entering syscall.
Decoding output of failed _IOR ioctls looks rather pointless.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20130505/8af2e2fe/attachment.bin>