Re: [PATCH] debugfs: keep the old valid mode value when no explicity specify it

[Zhang, Yanmin]

On 2014/8/28 23:10, Greg KH wrote:

> On Thu, Aug 28, 2014 at 06:09:09PM +0800, Chen LinX wrote:
> > From: "Chen, LinX" <linx.z.chen@xxxxxxxxx>
> >
> > When mount debugfs with no mode specifed after it's mounted, the mount
> > point mode will change to default mode(0700) even the mount operation was fail,
> > this will cause some issues like can't get binder info in android.
> I don't understand, what did you do to get into this state?

Greg,

Thanks for your kind quick comments. The patch description can be improved.

We hit the issue when debugging a UIWDT issue. Android framework has a good
method to detect userspace hang and reports UIWDT issues. Android uses
client/server model. Clients communicates with servers by binder. binder has
debugfs interfaces. Some files show what threads are communicating with what
other threads. If one thread is blocked for a long time, we can find the
blocking chain from the binder info.

Since the error dumping process has no root access, booting process changes
debugfs mount dir mode to 0755. When UIWDT happens, the error dumping
process can read the info.

Unfortunately, some other scripts at booting try to mount debugfs for many times.
No matter if the double mounting fails or succeeds, debugfs_parse_options changes
the root inode's mode back to the default 0700. It means the effect of previous
mode changing to 0755 is lost. At UIWDT, the dumping process can't save binder
info to disk log files.

> And why does binder care about debugfs?
>
> > Here we can keep the old valid mode if no explicity specify the mode
> > value and also change the mode value even the mount fails if the mode
> > value is specified.
> I can't parse this sentence :(

Lin's patch checks if debugfs_mount_opts->mode is initiated.
If it is already, the patch would bypass the reinitiation, so the old mode
value is kept.

Yanmin

--
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/