| Message ID | 20190621113357.8264-2-broonie@kernel.org (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | ceaea851b9ea75f9ea2bbefb53ff0d4b27cd5a6e |
| Headers | show |
| Series | [1/2] ASoC: core: Adapt for debugfs API change | expand |
On Fri, Jun 21, 2019 at 12:33:57PM +0100, Mark Brown wrote: > Back in ff9fb72bc07705c (debugfs: return error values, not NULL) the > debugfs APIs were changed to return error pointers rather than NULL > pointers on error, breaking the error checking in ASoC. Update the > code to use IS_ERR() and log the codes that are returned as part of > the error messages. > > Fixes: ff9fb72bc07705c (debugfs: return error values, not NULL) > Signed-off-by: Mark Brown <broonie@kernel.org> > Cc: stable@vger.kernel.org > --- > sound/soc/soc-dapm.c | 18 ++++++++++-------- > 1 file changed, 10 insertions(+), 8 deletions(-) > > diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c > index 6b44b4a78b8e..f013b24c050a 100644 > --- a/sound/soc/soc-dapm.c > +++ b/sound/soc/soc-dapm.c > @@ -2156,23 +2156,25 @@ void snd_soc_dapm_debugfs_init(struct snd_soc_dapm_context *dapm, > { > struct dentry *d; > > - if (!parent) > + if (!parent || IS_ERR(parent)) > return; How can parent be NULL? > > dapm->debugfs_dapm = debugfs_create_dir("dapm", parent); > > - if (!dapm->debugfs_dapm) { > + if (IS_ERR(dapm->debugfs_dapm)) { > dev_warn(dapm->dev, > - "ASoC: Failed to create DAPM debugfs directory\n"); > + "ASoC: Failed to create DAPM debugfs directory %ld\n", > + PTR_ERR(dapm->debugfs_dapm)); Same comment as before, no need to print anything. > return; > } > > d = debugfs_create_file("bias_level", 0444, > dapm->debugfs_dapm, dapm, > &dapm_bias_fops); > - if (!d) > + if (IS_ERR(d)) > dev_warn(dapm->dev, > - "ASoC: Failed to create bias level debugfs file\n"); > + "ASoC: Failed to create bias level debugfs file: %ld\n", > + PTR_ERR(d)); Again, no need to warn, no one will see it :) I am trying to make it so that debugfs doesn't return anything for when a file is created. Now if that will ever be possible or not, I don't know, but I am pretty close in one of the branches in my driver-core tree... thanks, greg k-h
On Fri, Jun 21, 2019 at 03:22:22PM +0200, Greg KH wrote: > On Fri, Jun 21, 2019 at 12:33:57PM +0100, Mark Brown wrote: > > struct dentry *d; > > > > - if (!parent) > > + if (!parent || IS_ERR(parent)) > > return; > How can parent be NULL? It was more effort than it was worth to check to see if it could actually be NULL through default initialization or something and fix it than just not delete the check so I just left it there. I'll probably go back and clean it up more thorougly at some point. > I am trying to make it so that debugfs doesn't return anything for when > a file is created. Now if that will ever be possible or not, I don't > know, but I am pretty close in one of the branches in my driver-core > tree... You mentioned this in a mail last week, I then replied pointing out that this is not helpful as it reduces the robustness and quality of our debugging tools and you then did not respond. This is a view I still hold and in any case debugfs as it stands (and was in the kernel versions since this was broken) is still capable of reporting errors so we should fix that.
On Fri, Jun 21, 2019 at 03:30:53PM +0100, Mark Brown wrote: > On Fri, Jun 21, 2019 at 03:22:22PM +0200, Greg KH wrote: > > On Fri, Jun 21, 2019 at 12:33:57PM +0100, Mark Brown wrote: > > > > struct dentry *d; > > > > > > - if (!parent) > > > + if (!parent || IS_ERR(parent)) > > > return; > > > How can parent be NULL? > > It was more effort than it was worth to check to see if it could > actually be NULL through default initialization or something and fix it > than just not delete the check so I just left it there. I'll probably > go back and clean it up more thorougly at some point. > > > I am trying to make it so that debugfs doesn't return anything for when > > a file is created. Now if that will ever be possible or not, I don't > > know, but I am pretty close in one of the branches in my driver-core > > tree... > > You mentioned this in a mail last week, I then replied pointing out that > this is not helpful as it reduces the robustness and quality of our > debugging tools and you then did not respond. Sorry, had lots of other stuff to work on, it's in my queue to respond to still... > This is a view I still hold and in any case debugfs as it stands (and > was in the kernel versions since this was broken) is still capable of > reporting errors so we should fix that. Sort story is, I am trying to change it so that it can not report errors :) And even then, no kernel code should be doing anything different if debugfs calls fail or not, that is why I am I making these changes. No "real" code should ever be affected, and right now, it is, if something goes wrong with debugfs. So removing those checks is the goal here. Your driver code should not care if debugfs is working at all or not. thanks, greg k-h
On Fri, Jun 21, 2019 at 04:53:09PM +0200, Greg KH wrote: > On Fri, Jun 21, 2019 at 03:30:53PM +0100, Mark Brown wrote: > > On Fri, Jun 21, 2019 at 03:22:22PM +0200, Greg KH wrote: > > This is a view I still hold and in any case debugfs as it stands (and > > was in the kernel versions since this was broken) is still capable of > > reporting errors so we should fix that. > Sort story is, I am trying to change it so that it can not report errors :) Yes, I know. This is what I think is a bad idea. > And even then, no kernel code should be doing anything different if > debugfs calls fail or not, that is why I am I making these changes. No > "real" code should ever be affected, and right now, it is, if something > goes wrong with debugfs. > So removing those checks is the goal here. Your driver code should not > care if debugfs is working at all or not. None of which addresses the issue which is that we should be telling users who are trying to use debugfs to debug things that something went wrong rather than silently failing and potentially confusing them with corrupted data display. This isn't something you can address through API restrictions without hurting users unless you are prepared to add user visible error reporting to the debugfs core. The conditional code here beyond printing errors only affects the creation of further debugfs files, it's just there to avoid spewing secondary errors at people when something goes wrong so the underlying problem is clearer and is entirely compatible with the idea of not affecting real code.
diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 6b44b4a78b8e..f013b24c050a 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -2156,23 +2156,25 @@ void snd_soc_dapm_debugfs_init(struct snd_soc_dapm_context *dapm, { struct dentry *d; - if (!parent) + if (!parent || IS_ERR(parent)) return; dapm->debugfs_dapm = debugfs_create_dir("dapm", parent); - if (!dapm->debugfs_dapm) { + if (IS_ERR(dapm->debugfs_dapm)) { dev_warn(dapm->dev, - "ASoC: Failed to create DAPM debugfs directory\n"); + "ASoC: Failed to create DAPM debugfs directory %ld\n", + PTR_ERR(dapm->debugfs_dapm)); return; } d = debugfs_create_file("bias_level", 0444, dapm->debugfs_dapm, dapm, &dapm_bias_fops); - if (!d) + if (IS_ERR(d)) dev_warn(dapm->dev, - "ASoC: Failed to create bias level debugfs file\n"); + "ASoC: Failed to create bias level debugfs file: %ld\n", + PTR_ERR(d)); } static void dapm_debugfs_add_widget(struct snd_soc_dapm_widget *w) @@ -2186,10 +2188,10 @@ static void dapm_debugfs_add_widget(struct snd_soc_dapm_widget *w) d = debugfs_create_file(w->name, 0444, dapm->debugfs_dapm, w, &dapm_widget_power_fops); - if (!d) + if (IS_ERR(d)) dev_warn(w->dapm->dev, - "ASoC: Failed to create %s debugfs file\n", - w->name); + "ASoC: Failed to create %s debugfs file: %ld\n", + w->name, PTR_ERR(d)); } static void dapm_debugfs_cleanup(struct snd_soc_dapm_context *dapm)
Back in ff9fb72bc07705c (debugfs: return error values, not NULL) the debugfs APIs were changed to return error pointers rather than NULL pointers on error, breaking the error checking in ASoC. Update the code to use IS_ERR() and log the codes that are returned as part of the error messages. Fixes: ff9fb72bc07705c (debugfs: return error values, not NULL) Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org --- sound/soc/soc-dapm.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-)