From: Andrew Morton <akpm@linux-foundation.org>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>,
Suparna Bhattacharya <suparna@in.ibm.com>,
Zach Brown <zach.brown@oracle.com>,
Benjamin LaHaise <bcrl@kvack.org>
Subject: Re: [patch 10/13] signal/timer/event fds v8 - eventfd core ...
Date: Fri, 30 Mar 2007 18:26:03 -0700 [thread overview]
Message-ID: <20070330182603.5d6817d3.akpm@linux-foundation.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0703301804110.3721@alien.or.mcafeemobile.com>
On Fri, 30 Mar 2007 18:11:55 -0700 (PDT) Davide Libenzi <davidel@xmailserver.org> wrote:
>
> > > + */
> >
> > So it is the caller's responsibility to ensure that *file refers to an
> > eventfd file?
>
> In which function? I lost you ...
>
eventfd_signal() assumes that the passed in file* refers to an eventfd
file. So if a caller passes in a file* for /etc/passwd, the kernel will go
splat.
I guess that's caveat emptor, and any violations of that will show up
quickly in testing. My main concern would be that there might be some way
for a naughty user to force the kernel to pass a non-eventfd file* into
this function. That depends upon as-yet-unwritten code - is there a risk
of this happening, and how do we prevent it?
>
> > > +int eventfd_signal(struct file *file, int n)
> > > +{
> > > + struct eventfd_ctx *ctx = file->private_data;
> > > + unsigned long flags;
> > > +
> > > + if (n < 0)
> > > + return -EINVAL;
> > > + spin_lock_irqsave(&ctx->lock, flags);
> > > + if (ULLONG_MAX - ctx->count < n)
> > > + n = (int) (ULLONG_MAX - ctx->count);
> > > + ctx->count += n;
> > > + if (waitqueue_active(&ctx->wqh))
> > > + wake_up_locked(&ctx->wqh);
> > > + spin_unlock_irqrestore(&ctx->lock, flags);
> > > +
> > > + return n;
> > > +}
>
>
>
> > > + DECLARE_WAITQUEUE(wait, current);
> > > +
> > > + if (count < sizeof(ucnt))
> > > + return -EINVAL;
> > > + if (get_user(ucnt, (const __u64 __user *) buf))
> > > + return -EFAULT;
> >
> > Some architectures do not implement 64-bit get_user()
>
> copy_from_user it is, then ...
>
spose so. I think architectures _should_ implement 64-bit get_user() and
put_user() nowadays. So you could leave the code as-is and inform the arch
maintainers, if you're feeling keen.
If all this code has its own Kconfig options then the architectures won't
break until their maintainers come along to enable the new features, so
they'll implement 64-bit get_user() at that time and things will all unfold
in a nicely non-chaotic fashion.
next prev parent reply other threads:[~2007-03-31 1:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-20 18:37 [patch 10/13] signal/timer/event fds v8 - eventfd core Davide Libenzi
2007-03-30 19:40 ` Andrew Morton
2007-03-31 1:11 ` Davide Libenzi
2007-03-31 1:14 ` Davide Libenzi
2007-03-31 1:26 ` Andrew Morton [this message]
2007-03-31 19:50 ` Davide Libenzi
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=20070330182603.5d6817d3.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=bcrl@kvack.org \
--cc=davidel@xmailserver.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=suparna@in.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=zach.brown@oracle.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