linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Myron Stowe <mstowe@redhat.com>
To: Kay Sievers <kay@vrfy.org>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Myron Stowe <myron.stowe@redhat.com>,
	linux-hotplug@vger.kernel.org, linux-pci@vger.kernel.org,
	yuxiangl@marvell.com, yxlraid@gmail.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files
Date: Sun, 17 Mar 2013 08:36:57 -0600	[thread overview]
Message-ID: <1363531017.2423.50.camel@zim.stowe> (raw)
In-Reply-To: <CAPXgP13+BACQEid=xcFLDv+Tm3A1pCqDDfP4K+ZZrwGZBQ9A8g@mail.gmail.com>

On Sun, 2013-03-17 at 15:29 +0100, Kay Sievers wrote:
> On Sun, Mar 17, 2013 at 3:20 PM, Myron Stowe <mstowe@redhat.com> wrote:
> > On Sun, 2013-03-17 at 15:00 +0100, Kay Sievers wrote:
> >> On Sun, Mar 17, 2013 at 2:38 PM, Alex Williamson
> >> <alex.williamson@redhat.com> wrote:
> >> > I'm assuming that the device only breaks because udevadm is dumping the
> >> > full I/O port register space of the device and that if an actual driver
> >> > was interacting with it through this interface that it would work.  Who
> >> > knows how many devices will have read side-effects by udevadm blindly
> >> > dumping these files.  Thanks,
> >>
> >> Sysfs is a too public interface to export things there which make
> >> devices/driver choke on a simple read() of an attribute.
> >>
> >> This is nothing specific to udevadm, any tool can do that. Udevadm
> >> will never read any of the files during normal operation. The admin
> >> explicitly asked udevadm with a specific command to dump all the stuff
> >> the device offers.
> >>
> >> The kernel driver needs to be fixed to allow that, in the worst case,
> >> the attributes not exported at all. People should take more care what
> >> they export in /sys, it's not a hidden and private ioctl what's
> >> exported there, stuff is very visible and will be looked at.
> >>
> >> Telling userspace not to use specific stuff in /sys I would not expect
> >> to work as a strategy; there is too much weird stuff out there that
> >> will always try to do that ...
> >
> > Kay - could you comment on Foot Note 3 in
> > https://lkml.org/lkml/2013/3/16/168
> >
> > With respect to 'udev', you are working on the assumption that all files
> > in sysfs must be readable with no consequences which may be implied by
> > the Documentation's sysfs.txt file's mentioning ASCII.  If we are to
> > interpret that as strictly as you seem to want to then why is there
> > sysfs support for creating binary files?
> 
> They cannot be distinguished from outside, so there is nothing I know
> that could make a difference to userspace tools.

Agreed
> 
> Tools -- no matter how useful they are not not, it's that they do that
> for many years already -- need to be able to read() the stuff in
> there, without causing any damage to the system.

So then, why are certain sysfs files skipped in udevadm-info's parsing
(./src/udevadm-info.c::skip_attribute())?
> 
> Kay



  reply	other threads:[~2013-03-17 14:36 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-16 21:35 [PATCH] udevadm-info: Don't access sysfs entries backing device I/O port space Myron Stowe
2013-03-16 21:35 ` [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files Myron Stowe
2013-03-16 22:11   ` Greg KH
2013-03-16 22:55     ` Bjorn Helgaas
2013-03-16 23:50     ` Myron Stowe
2013-03-17  1:03       ` Greg KH
2013-03-17  4:11         ` Alex Williamson
2013-03-17  5:36           ` Greg KH
2013-03-17 13:38             ` Alex Williamson
2013-03-17 14:00               ` Kay Sievers
2013-03-17 14:20                 ` Myron Stowe
2013-03-17 14:29                   ` Kay Sievers
2013-03-17 14:36                     ` Myron Stowe [this message]
2013-03-17 14:43                       ` Kay Sievers
2013-03-18 16:24                 ` Alex Williamson
2013-03-18 16:41                   ` Greg KH
2013-03-18 16:51                     ` Alex Williamson
2013-03-18 17:20                       ` Bjørn Mork
2013-03-18 17:54                         ` Alex Williamson
2013-03-18 18:02                           ` Robert Brown
2013-03-18 18:25                           ` Bjørn Mork
2013-03-18 18:59                             ` Alex Williamson
2013-03-19 16:57                               ` Myron Stowe
2013-03-19 17:06                                 ` Myron Stowe
2013-03-17 14:33               ` Myron Stowe
2013-03-17 22:28                 ` Alex Williamson
2013-03-18 14:50                   ` Don Dutile
2013-03-18 16:34                     ` Alex Williamson
2013-03-17 14:12         ` Myron Stowe
2013-03-19  1:54         ` Robert Hancock
2013-03-19  2:03           ` Greg KH
2013-03-19  2:09             ` Robert Hancock
2013-03-19  2:35               ` Greg KH
2013-03-19  3:08                 ` Robert Hancock

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=1363531017.2423.50.camel@zim.stowe \
    --to=mstowe@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kay@vrfy.org \
    --cc=linux-hotplug@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=myron.stowe@redhat.com \
    --cc=yuxiangl@marvell.com \
    --cc=yxlraid@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).