All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Borislav Petkov <bp@alien8.de>
Cc: balbi@ti.com, Greg KH <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	JBottomley@parallels.com, linux-scsi@vger.kernel.org,
	davem@davemloft.net, netdev@vger.kernel.org,
	Doug Thompson <dougthompson@xmission.com>,
	linux-edac@vger.kernel.org, rjw@sisk.pl,
	linux-pm@vger.kernel.org
Subject: Re: SYSFS "errors"
Date: Tue, 19 Feb 2013 09:16:10 -0300	[thread overview]
Message-ID: <20130219091610.2b746a30@redhat.com> (raw)
In-Reply-To: <20130219114345.GA26623@pd.tnic>

Em Tue, 19 Feb 2013 12:43:46 +0100
Borislav Petkov <bp@alien8.de> escreveu:

> On Tue, Feb 19, 2013 at 08:11:49AM -0300, Mauro Carvalho Chehab wrote:
> > > > I remember I saw some discussions about it in the past at bluesmoke ML,
> > > > saying that -ENODEV is the expected behavior when this is not supported.
> > > > 
> > > > Changing from -ENODEV to "N/A" will break anything that would be relying
> > > > on the previous behavior. So, I think that such change will for sure break
> > > > userspace.
> > > > 
> > > > If we're willing to change it, not creating the "sdram_scrub_rate" sysfs 
> > > > node is less likely to affect userspace.
> 
> This will break scripts which assume this file's presence implicitly.

If are there any script like that, then yes.

> [ … ]
> 
> > @@ -1017,6 +1010,14 @@ int edac_create_sysfs_mci_device(struct mem_ctl_info *mci)
> >  		return err;
> >  	}
> >  
> > +	if (mci->set_sdram_scrub_rate && mci->get_sdram_scrub_rate) {
> 
> This will break cpc925_edac.c because it defines a
> ->get_sdram_scrub_rate but not a ->set_sdram_scrub_rate.

True. Patch below fixes it.

> I think a maybe better fix would be to figure out the sysfs file
> permissions based on the presence of the two functions and *then* add
> the attribute.
> 
> This way, the only visible change to userspace is the corrected sysfs
> file permissions.

I'm not sure if is there a way to pass fs permissions to something similar
to device_create_file().

On both cases, an error will happen at open:
	- if file doesn't exist (this approach), it will return -ENOENT;
	- if file is opened with wrong permissions, open will return -EPERM.

However, if the file is not created, readdir() won't show the file.
So, if userspace first seeks for the sdram_scrub_rate, it won't fail.
That makes the logic below a little safer, IMO.


[PATCH EDAC] edac: only create sdram_scrub_rate where supported

Currently, sdram_scrub_rate sysfs node is created even if the device
doesn't support get/set the scub rate. Change the logic to only
create this device node when the operation is supported.

If only read or only write is supported, it will keep returning -ENODEV
just like before.

Reported-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 9c58da6..29b66a2 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -7,7 +7,7 @@
  *
  * Written Doug Thompson <norsk5@xmission.com> www.softwarebitmaker.com
  *
- * (c) 2012 - Mauro Carvalho Chehab <mchehab@redhat.com>
+ * (c) 2012-2013 - Mauro Carvalho Chehab <mchehab@redhat.com>
  *	The entire API were re-written, and ported to use struct device
  *
  */
@@ -882,7 +882,6 @@ static struct attribute *mci_attrs[] = {
 	&dev_attr_ce_noinfo_count.attr,
 	&dev_attr_ue_count.attr,
 	&dev_attr_ce_count.attr,
-	&dev_attr_sdram_scrub_rate.attr,
 	&dev_attr_max_location.attr,
 	NULL
 };
@@ -1017,6 +1016,14 @@ int edac_create_sysfs_mci_device(struct mem_ctl_info *mci)
 		return err;
 	}
 
+	if (mci->set_sdram_scrub_rate || mci->get_sdram_scrub_rate) {
+		err = device_create_file(&mci->dev,
+					 &dev_attr_sdram_scrub_rate);
+		if (err) {
+			edac_dbg(1, "failure: create sdram_scrub_rate\n");
+			goto fail2;
+		}
+	}
 	/*
 	 * Create the dimm/rank devices
 	 */
@@ -1061,6 +1068,7 @@ fail:
 			continue;
 		device_unregister(&dimm->dev);
 	}
+fail2:
 	device_unregister(&mci->dev);
 	bus_unregister(&mci->bus);
 	kfree(mci->bus.name);

  reply	other threads:[~2013-02-19 12:16 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-18 15:33 SYSFS "errors" Felipe Balbi
2013-02-18 15:50 ` Greg KH
2013-02-18 15:52   ` Felipe Balbi
2013-02-18 17:13     ` Greg KH
2013-02-18 17:27       ` Felipe Balbi
2013-02-18 17:45         ` Borislav Petkov
2013-02-18 18:47           ` Felipe Balbi
2013-02-18 19:40             ` Borislav Petkov
2013-02-18 20:04               ` Felipe Balbi
2013-02-18 17:49         ` Greg KH
2013-02-18 18:46           ` Felipe Balbi
2013-02-18 18:46             ` Felipe Balbi
2013-02-18 19:46             ` Mauro Carvalho Chehab
2013-02-18 19:46               ` Mauro Carvalho Chehab
2013-02-18 20:05               ` Felipe Balbi
2013-02-18 20:05                 ` Felipe Balbi
2013-02-18 21:47                 ` Mauro Carvalho Chehab
2013-02-18 21:47                   ` Mauro Carvalho Chehab
2013-02-18 21:54                   ` Greg KH
2013-02-18 22:13                     ` Borislav Petkov
2013-02-18 22:26                       ` Greg KH
2013-02-18 22:44                         ` Borislav Petkov
2013-02-19 10:03                           ` Mauro Carvalho Chehab
2013-02-19 10:11                             ` Felipe Balbi
2013-02-19 10:11                               ` Felipe Balbi
2013-02-19 11:11                               ` Mauro Carvalho Chehab
2013-02-19 11:11                                 ` Mauro Carvalho Chehab
2013-02-19 11:43                                 ` Borislav Petkov
2013-02-19 12:16                                   ` Mauro Carvalho Chehab [this message]
2013-02-19 12:35                                     ` Borislav Petkov
2013-02-19 12:46                                       ` Mauro Carvalho Chehab
2013-02-19 13:06                                         ` Borislav Petkov
2013-02-19 13:15                                           ` Felipe Balbi
2013-02-19 13:15                                             ` Felipe Balbi
2013-02-19 13:28                                             ` Borislav Petkov
2013-02-19 13:38                                               ` Felipe Balbi
2013-02-19 13:38                                                 ` Felipe Balbi
2013-02-19 13:50                                                 ` Mauro Carvalho Chehab
2013-02-19 13:50                                                   ` Mauro Carvalho Chehab
2013-02-19 13:55                                                   ` Borislav Petkov
2013-02-19 13:50                                                 ` Borislav Petkov
2013-02-19 13:58                                                   ` Hannes Reinecke
2013-02-19 14:10                                                     ` Borislav Petkov
2013-02-19 14:14                                                     ` Mauro Carvalho Chehab
2013-02-19 14:19                                                       ` Felipe Balbi
2013-02-19 14:19                                                         ` Felipe Balbi
2013-02-19 14:35                                                   ` Mauro Carvalho Chehab
2013-02-19 14:50                                                     ` Borislav Petkov
2013-02-19 14:53                                                     ` Felipe Balbi
2013-02-19 14:53                                                       ` Felipe Balbi
2013-02-19 13:42                                           ` Mauro Carvalho Chehab
2013-02-18 21:48             ` Alan Stern
2013-02-18 21:48               ` Alan Stern
2013-02-18 21:57               ` Felipe Balbi
2013-02-18 21:57                 ` Felipe Balbi
2013-02-19  7:41           ` Alexander Stein
2013-02-19 10:12             ` Felipe Balbi

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=20130219091610.2b746a30@redhat.com \
    --to=mchehab@redhat.com \
    --cc=JBottomley@parallels.com \
    --cc=balbi@ti.com \
    --cc=bp@alien8.de \
    --cc=davem@davemloft.net \
    --cc=dougthompson@xmission.com \
    --cc=fweisbec@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --cc=rostedt@goodmis.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 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.