From: Lucas De Marchi <lucas.demarchi@profusion.mobi>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: [REVIEW][PATCH] Making poll generally useful for sysctls
Date: Mon, 26 Mar 2012 14:44:50 -0300 [thread overview]
Message-ID: <CAMOw1v4hZFk20QzvwWUL73Nax2m77HOkfp0KkuOPFjCgYprZgw@mail.gmail.com> (raw)
In-Reply-To: <m1ty1esa52.fsf@fess.ebiederm.org>
Hi Eric,
On Sat, Mar 24, 2012 at 4:58 AM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Lucas De Marchi <lucas.demarchi@profusion.mobi> writes:
>
>>> /* A sysctl table is an array of struct ctl_table: */
>>> struct ctl_table
>>> {
>>> const char *procname; /* Text ID for /proc/sys, or zero */
>>> void *data;
>>> + atomic_t event;
>>> int maxlen;
>>> umode_t mode;
>>> struct ctl_table *child; /* Deprecated */
>>> proc_handler *proc_handler; /* Callback for text formatting */
>>> - struct ctl_table_poll *poll;
>>> void *extra1;
>>> void *extra2;
>>> };
>>> @@ -1042,6 +1025,7 @@ struct ctl_table_header
>>> };
>>> struct rcu_head rcu;
>>> };
>>> + wait_queue_head_t wait;
>>
>> If you have a waitqueue per table instead of per entry you will get
>> spurious notifications when other entries change. The easiest way to
>> test this is to poll /proc/sys/kernel/hostname and change your
>> domainname.
>
> You will get spurious wakeups but not spurious notifications to
> userspace since event is still per entry.
Yeah, indeed.
> For my money that seemed a nice compromise of code simplicity, and
> generality. We could of course do something much closer to what
> sysfs does and allocate and refcount something similar to your
> ctl_table_poll when we have a ctl_table opened. But that just looked
> like a pain.
I don't think we want spurious wakeups in favor of a slightly simpler code.
>
> Of course we already have spurious notifications for hostname and
> domainname when multiple uts namespaces are involved, but that
> is a different problem.
>
>> I couldn't apply this patch to any tree (linus/master + my previous
>> patch, your master, 3.3 + my previous patch), so I couldn't test. On
>> top of your tree:
>
> How odd. It should have applied cleanly to my tree and it applies
> with just a two line offset top of Linus's latest with my tree merged
> in. Those two lines of offset coming from the two extra includes
> that came in through the merge.
>
> patch -p1 --dry-run < ~/tmp/sysctl-poll-test.patch
> patching file fs/proc/proc_sysctl.c
> Hunk #1 succeeded at 18 (offset 2 lines).
> Hunk #2 succeeded at 173 (offset 2 lines).
> Hunk #3 succeeded at 245 (offset 2 lines).
> Hunk #4 succeeded at 512 (offset 2 lines).
> Hunk #5 succeeded at 542 (offset 2 lines).
> Hunk #6 succeeded at 561 (offset 2 lines).
> patching file include/linux/sysctl.h
> patching file kernel/utsname_sysctl.c
>
>> [lucas@vader kernel]$ git am /tmp/a.patch
>> Applying: Making poll generally useful for sysctls
>> error: patch failed: fs/proc/proc_sysctl.c:16
>> error: fs/proc/proc_sysctl.c: patch does not apply
>> error: patch failed: include/linux/sysctl.h:992
>> error: include/linux/sysctl.h: patch does not apply
>> Patch failed at 0001 Making poll generally useful for sysctls
>
> Here is rebased version of the patch just in case that helps.
Now I can apply, but I can't boot: we hit a NULL dereference in
__wake_up_common(), called by proc_sys_poll_notify(). It seems that
you forgot to initialize the waitqueue with
__WAIT_QUEUE_HEAD_INITIALIZER().
Lucas De Marchi
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-03-26 17:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20120313005855.GA24639@redhat.com>
[not found] ` <CA+55aFwb2WRRamWPVY-ETDG_LO0QR9C8epk8tSAJVZhPFSNzhA@mail.gmail.com>
[not found] ` <20120318192755.GB6589@ZenIV.linux.org.uk>
[not found] ` <CAMOw1v4qa_AxJgc+qAsY6M=K--2JDvO-+CNj8OwKuE7piRViGw@mail.gmail.com>
[not found] ` <m1vclw1fx8.fsf@fess.ebiederm.org>
[not found] ` <CAMOw1v4gszzV7F3z1m+RWEe9UDgR2Jrp9wX_w9z_1UkXT=FL5Q@mail.gmail.com>
2012-03-24 0:25 ` [REVIEW][PATCH] Making poll generally useful for sysctls Eric W. Biederman
2012-03-24 6:20 ` Lucas De Marchi
2012-03-24 7:58 ` Eric W. Biederman
2012-03-26 17:44 ` Lucas De Marchi [this message]
2012-03-27 4:02 ` Lucas De Marchi
2012-03-28 2:00 ` Eric W. Biederman
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=CAMOw1v4hZFk20QzvwWUL73Nax2m77HOkfp0KkuOPFjCgYprZgw@mail.gmail.com \
--to=lucas.demarchi@profusion.mobi \
--cc=ebiederm@xmission.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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 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).