From: Jan Glauber <jan.glauber@caviumnetworks.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org
Subject: Re: [PATCH] i2c: Prevent endless uevent loop with dev_dbg
Date: Wed, 23 Mar 2016 18:29:05 +0100 [thread overview]
Message-ID: <20160323172905.GB1712@hardcore> (raw)
In-Reply-To: <20160323165033.GB1385@katana>
On Wed, Mar 23, 2016 at 05:50:33PM +0100, Wolfram Sang wrote:
> On Wed, Mar 23, 2016 at 04:50:47PM +0100, Jan Glauber wrote:
> > After enabling CONFIG_I2C_DEBUG_CORE my system was broken
> > (no network, console login not possible). System log was
> > flooded with the this message:
> >
> > ...
> > [ 608.052077] rtc-ds1307 0-0068: uevent
> > [ 608.052500] rtc-ds1307 0-0068: uevent
> > [ 608.052925] rtc-ds1307 0-0068: uevent
> > ...
> >
> > The culprit is the dev_dbg printk in the i2c uevent handler.
> > If this is activated (for instance by CONFIG_I2C_DEBUG_CORE)
> > it results in an endless loop with systemd-journald.
> >
> > This happens if user-space scans the system log and reads the uevent
> > file to get information about a newly created device, which seems fair
> > use to me. Unfortunately reading the "uevent" file uses the same
> > function that runs for creating the uevent for a new device,
> > generating the next syslog entry.
> >
> > Ideally user-space would implement a recursion detection and
> > after reading the same device file for the 1000th time call it a
> > day, but nevertheless I think we should avoid this problem by
> > removing the debug print completly or using another print variant.
>
> Thanks for pointing out this problem. I think this debug can go. I also
> think the function can be cleaned up some more. Can you test this patch?
Works for me!
Thanks, Jan
> Thanks,
>
> Wolfram
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index 0f2f8484e8ec1f..e584d88ee337f6 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -525,22 +525,16 @@ static int i2c_device_match(struct device *dev, struct device_driver *drv)
> return 0;
> }
>
> -
> -/* uevent helps with hotplug: modprobe -q $(MODALIAS) */
> static int i2c_device_uevent(struct device *dev, struct kobj_uevent_env *env)
> {
> - struct i2c_client *client = to_i2c_client(dev);
> + struct i2c_client *client = to_i2c_client(dev);
> int rc;
>
> rc = acpi_device_uevent_modalias(dev, env);
> if (rc != -ENODEV)
> return rc;
>
> - if (add_uevent_var(env, "MODALIAS=%s%s",
> - I2C_MODULE_PREFIX, client->name))
> - return -ENOMEM;
> - dev_dbg(dev, "uevent\n");
> - return 0;
> + return add_uevent_var(env, "MODALIAS=%s%s", I2C_MODULE_PREFIX, client->name);
> }
>
> /* i2c bus recovery routines */
>
WARNING: multiple messages have this Message-ID (diff)
From: Jan Glauber <jan.glauber@caviumnetworks.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: <linux-kernel@vger.kernel.org>, <linux-i2c@vger.kernel.org>
Subject: Re: [PATCH] i2c: Prevent endless uevent loop with dev_dbg
Date: Wed, 23 Mar 2016 18:29:05 +0100 [thread overview]
Message-ID: <20160323172905.GB1712@hardcore> (raw)
In-Reply-To: <20160323165033.GB1385@katana>
On Wed, Mar 23, 2016 at 05:50:33PM +0100, Wolfram Sang wrote:
> On Wed, Mar 23, 2016 at 04:50:47PM +0100, Jan Glauber wrote:
> > After enabling CONFIG_I2C_DEBUG_CORE my system was broken
> > (no network, console login not possible). System log was
> > flooded with the this message:
> >
> > ...
> > [ 608.052077] rtc-ds1307 0-0068: uevent
> > [ 608.052500] rtc-ds1307 0-0068: uevent
> > [ 608.052925] rtc-ds1307 0-0068: uevent
> > ...
> >
> > The culprit is the dev_dbg printk in the i2c uevent handler.
> > If this is activated (for instance by CONFIG_I2C_DEBUG_CORE)
> > it results in an endless loop with systemd-journald.
> >
> > This happens if user-space scans the system log and reads the uevent
> > file to get information about a newly created device, which seems fair
> > use to me. Unfortunately reading the "uevent" file uses the same
> > function that runs for creating the uevent for a new device,
> > generating the next syslog entry.
> >
> > Ideally user-space would implement a recursion detection and
> > after reading the same device file for the 1000th time call it a
> > day, but nevertheless I think we should avoid this problem by
> > removing the debug print completly or using another print variant.
>
> Thanks for pointing out this problem. I think this debug can go. I also
> think the function can be cleaned up some more. Can you test this patch?
Works for me!
Thanks, Jan
> Thanks,
>
> Wolfram
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index 0f2f8484e8ec1f..e584d88ee337f6 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -525,22 +525,16 @@ static int i2c_device_match(struct device *dev, struct device_driver *drv)
> return 0;
> }
>
> -
> -/* uevent helps with hotplug: modprobe -q $(MODALIAS) */
> static int i2c_device_uevent(struct device *dev, struct kobj_uevent_env *env)
> {
> - struct i2c_client *client = to_i2c_client(dev);
> + struct i2c_client *client = to_i2c_client(dev);
> int rc;
>
> rc = acpi_device_uevent_modalias(dev, env);
> if (rc != -ENODEV)
> return rc;
>
> - if (add_uevent_var(env, "MODALIAS=%s%s",
> - I2C_MODULE_PREFIX, client->name))
> - return -ENOMEM;
> - dev_dbg(dev, "uevent\n");
> - return 0;
> + return add_uevent_var(env, "MODALIAS=%s%s", I2C_MODULE_PREFIX, client->name);
> }
>
> /* i2c bus recovery routines */
>
next prev parent reply other threads:[~2016-03-23 17:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-23 15:50 [PATCH] i2c: Prevent endless uevent loop with dev_dbg Jan Glauber
2016-03-23 16:35 ` Alexander Sverdlin
2016-03-23 16:50 ` Wolfram Sang
2016-03-23 17:29 ` Jan Glauber [this message]
2016-03-23 17:29 ` Jan Glauber
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=20160323172905.GB1712@hardcore \
--to=jan.glauber@caviumnetworks.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wsa@the-dreams.de \
/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.