mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Greg K-H <greg@kroah.com>, linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH]sysfs: Don't emit a warning when sysfs_rename_link() fails.
Date: Thu, 18 Sep 2008 03:00:31 -0700	[thread overview]
Message-ID: <m17i99wz7k.fsf@frodo.ebiederm.org> (raw)
In-Reply-To: <20080918090705.6985cced@gondolin.boeblingen.de.ibm.com> (Cornelia Huck's message of "Thu, 18 Sep 2008 09:07:05 +0200")

Cornelia Huck <cornelia.huck@de.ibm.com> writes:

> On Wed, 17 Sep 2008 11:55:14 -0700,
> ebiederm@xmission.com (Eric W. Biederman) wrote:
>> Cornelia Huck <cornelia.huck@de.ibm.com> writes:


>> Or we are actually using a conflicting name.  In which case it is a
>> real and valid problem. 
>
> Which may be in userspace as well. In the past the networking folks
> were unhappy about the sysfs warning, claiming that failures should
> rather be handled in their layer.

Because the failures have always been handled in the networking
stack.

The only case that was ever warned about by sysfs were noop
renames.

So no we will not catch any userspace bugs with this code.

>> The netdev layer especially since the
>> networking layer already has validated that the rename is valid
>> before calling device_rename.
>
> Does it? Or do I just don't get it because of lack of coffee?

In the dev_change_name we either do dev_alloc_name
which generates a unique device name or __dev_get_by_name
which looks to see if we are already using that name.

The code in cfg80211_dev_rename is a trivial probe so I
don't think that is subtle.

>> > The following patch switches sysfs_rename_link() to non-warning symlink
>> > creation again. It is on top of the current driver core series.
>> 
>> We don't need this.  Using the non-warning symlink creation is unnecessary.
>> Using non-warning symlink creation hides real errors.
>
> For most cases, yes.

In these cases especially.

>> In practice any errors that show up will be errors in sysfs, because
>> the network subsystem validates everything before calling us.
>
> I was under the impression that no checks are done if the rename is
> triggered via ioctl. And it makes more sense to have the caller of the
> ioctl get an error than to spit a sysfs warning.

Currently there are exactly 2 callers of device_rename.
net/core/dev.c:dev_change_name 
net/wireless/core.c:cfg80211_dev_rename

Both of which verify that the rename is valid before
they call device_rename.  In fact that they have to because
the kobject layer does not have enough information to verify
that the rename is valid, and sysfs is not necessarily compiled in.

Eric

  reply	other threads:[~2008-09-18 11:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-17 11:08 Cornelia Huck
2008-09-17 18:55 ` Eric W. Biederman
2008-09-18  7:07   ` Cornelia Huck
2008-09-18 10:00     ` Eric W. Biederman [this message]
2008-09-18 10:50       ` Cornelia Huck
2008-09-18 11:37         ` Eric W. Biederman
2008-09-18 12:28           ` [PATCH] sysfs: Remove sysfs_do_create_link() Cornelia Huck
2008-10-07  4:19             ` Greg KH
2008-10-07  7:23               ` Cornelia Huck

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=m17i99wz7k.fsf@frodo.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome