From: Carlos Llamas <cmllamas@google.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Arve Hjønnevåg" <arve@android.com>,
"Todd Kjos" <tkjos@android.com>,
"Martijn Coenen" <maco@android.com>,
"Christian Brauner" <brauner@kernel.org>,
"Joel Fernandes" <joel@joelfernandes.org>,
"Hridya Valsaraju" <hridya@google.com>,
"Suren Baghdasaryan" <surenb@google.com>,
kernel-team@android.com, linux-kernel@vger.kernel.org,
"kernel test robot" <lkp@intel.com>
Subject: Re: [PATCH] binder: fix redefinition of seq_file attributes
Date: Thu, 7 Jul 2022 21:21:52 +0000 [thread overview]
Message-ID: <YsdOcFxGTGkYvtd4@google.com> (raw)
In-Reply-To: <YsMRtGg8xQ2Qicr2@kroah.com>
On Mon, Jul 04, 2022 at 06:13:40PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Jul 01, 2022 at 06:20:41PM +0000, Carlos Llamas wrote:
> > + binder_for_each_debugfs_entry(db_entry) {
> > + dentry = binderfs_create_file(binder_logs_root_dir,
> > + db_entry->name,
> > + db_entry->fops,
> > + db_entry->data);
> > + if (IS_ERR(dentry)) {
> > + ret = PTR_ERR(dentry);
> > + goto out;
> > + }
>
> I know this is a copy of what is there already, but there is never a
> need to check the result of a debugfs_create_* call. Just call it and
> move on, never "abort" based on the result of a debugfs call, that's not
> a good idea.
This is true, none of these debugfs files seem critical for mounting a
binderfs instance. I'm thinking init_binder_logs() should just return
void. I'm only a bit hesitant to completely ignore the return code as
users specifically ask for these files to be created via mount option
"stats". So probably a pr_warn is what is actually needed here.
>
> So can you change this here, or want to send a follow-on patch that
> removes these checks?
Sure, I'll send a follow-on patch. I'm currently AFK so setting ETA for
next week until I can actually test this change.
>
> > }
> >
> > proc_log_dir = binderfs_create_dir(binder_logs_root_dir, "proc");
>
> Also there's never a need to save a directory, you can always look it up
> when you want to remove it.
It seems this is a convenient way to share this path with binder which
otherwise doesn't know where binderfs was mounted. From having a quick
look it doesn't seem that we need to share all the details in struct
binderfs_info though. Maybe there is a better way to handle all this.
Christian, since this is binderfs area WDYT?
--
Carlos Llamas
next prev parent reply other threads:[~2022-07-07 21:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-01 18:20 [PATCH] binder: fix redefinition of seq_file attributes Carlos Llamas
2022-07-04 16:13 ` Greg Kroah-Hartman
2022-07-07 21:21 ` Carlos Llamas [this message]
2022-07-08 6:00 ` Greg Kroah-Hartman
2022-07-08 14:30 ` Carlos Llamas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YsdOcFxGTGkYvtd4@google.com \
--to=cmllamas@google.com \
--cc=arve@android.com \
--cc=brauner@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=hridya@google.com \
--cc=joel@joelfernandes.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=maco@android.com \
--cc=surenb@google.com \
--cc=tkjos@android.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.