lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 17 Oct 2007 12:16:54 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Greg KH <greg@...ah.com>
Cc:	David Miller <davem@...emloft.net>, jens.axboe@...cle.com,
	rjw@...k.pl, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, htejun@...il.com,
	linux-kernel@...r.kernel.org
Subject: Re: linux-2.6.23-git3: Many sysfs-related warnings in dmesg

On Tue, 2007-10-16 at 16:23 -0700, Greg KH wrote:
> On Tue, Oct 16, 2007 at 03:32:48PM -0700, David Miller wrote:
> > From: Greg KH <greg@...ah.com>
> > Date: Tue, 16 Oct 2007 14:37:30 -0700
> > 
> > > Kay, are we doing something wrong in userspace when renaming wireless
> > > devices such that we can overlap names?

Not udev, but SUSE 10.2's network renaming. It uses udev and calls
ifrename in the same code path. 10.3 uses the unified version from the
udev tree.

> > It does it for all network devices, I see this ugly message on every
> > single system I have from Fedora foo to RHEL foo to ubuntu foo to
> > debian foo.
> >
> > udev simply applies the MAC address to device name rules blindly, it
> > doesn't check if the device already has the desired name already

There is a check for the same name in udev for long.

> Ugh :(
> 
> > It's been like this forever, and since userland has been doing it for
> > so long, you can't warn on this there is too much established
> > practice.  Expecting people to install "fixed" udev is not an
> > acceptable answer, the warning is a regression and therefore you'll
> > have to remove the kernel warning for this case and live with this
> > issue essentially forever.

We should probably just add the check to kobject_rename() and print a
simple warning and then do nothing. Or just do the check in the network
ioctl, if we really don't want to see this.

> Nope, I guess we will have to take out the check (or put it under the
> kobject debugging flag), unless Kay has any other ideas...

We should really keep it, it already exposed a lot of serious bugs in
the kernel and users, we never spotted before.

Kay

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ