From: Arnd Bergmann <[email protected]>
Seeking on /dev/random and /dev/urandom is pointless.
Using generic_file_llseek means we no longer need to
take the BKL if anyone tries to seek on these.
Signed-off-by: Arnd Bergmann <[email protected]>
Cc: Matt Mackall <[email protected]>
Cc: Andrew Morton <[email protected]>
Signed-off-by: Frederic Weisbecker <[email protected]>
---
drivers/char/random.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 2fd3d39..513c685 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1169,6 +1169,7 @@ const struct file_operations random_fops = {
.poll = random_poll,
.unlocked_ioctl = random_ioctl,
.fasync = random_fasync,
+ .open = nonseekable_open,
};
const struct file_operations urandom_fops = {
@@ -1176,6 +1177,7 @@ const struct file_operations urandom_fops = {
.write = random_write,
.unlocked_ioctl = random_ioctl,
.fasync = random_fasync,
+ .open = nonseekable_open,
};
/***************************************************************
--
1.6.2.3
On Sat, 2010-04-10 at 16:17 +0200, Frederic Weisbecker wrote:
> From: Arnd Bergmann <[email protected]>
>
> Seeking on /dev/random and /dev/urandom is pointless.
It is indeed pointless, though that doesn't mean no one does it.
Forbidding a no-op seems a rather unfriendly way to fix this.
> Using generic_file_llseek means we no longer need to
> take the BKL if anyone tries to seek on these.
Comment doesn't match the patch?
> Signed-off-by: Arnd Bergmann <[email protected]>
> Cc: Matt Mackall <[email protected]>
> Cc: Andrew Morton <[email protected]>
> Signed-off-by: Frederic Weisbecker <[email protected]>
> ---
> drivers/char/random.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index 2fd3d39..513c685 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -1169,6 +1169,7 @@ const struct file_operations random_fops = {
> .poll = random_poll,
> .unlocked_ioctl = random_ioctl,
> .fasync = random_fasync,
> + .open = nonseekable_open,
> };
>
> const struct file_operations urandom_fops = {
> @@ -1176,6 +1177,7 @@ const struct file_operations urandom_fops = {
> .write = random_write,
> .unlocked_ioctl = random_ioctl,
> .fasync = random_fasync,
> + .open = nonseekable_open,
> };
>
> /***************************************************************
--
http://selenic.com : development and support for Mercurial and Linux
On Sat, Apr 10, 2010 at 11:25:50AM -0500, Matt Mackall wrote:
> On Sat, 2010-04-10 at 16:17 +0200, Frederic Weisbecker wrote:
> > From: Arnd Bergmann <[email protected]>
> >
> > Seeking on /dev/random and /dev/urandom is pointless.
>
> It is indeed pointless, though that doesn't mean no one does it.
> Forbidding a no-op seems a rather unfriendly way to fix this.
I worried about that too. If you think that could break some user
space apps, we can make it a generic_file_llseek.
> > Using generic_file_llseek means we no longer need to
> > take the BKL if anyone tries to seek on these.
>
> Comment doesn't match the patch?
Oops. I guess the patch has been updated, but not the changelog.
Some background: we are trying to remove the uses of default_llseek
that use the bkl. We started with turning llseek stubs to
generic_file_llseek (or non seekable open in some cases), but we are
hesitating now and think about actually turn all the stubs that
might need the bkl into default_llseek, and fallback to
generic_file_llseek for all other stubs.
Depending on what we do I'll resend you an updated version
of this patch with generic_file_llseek, or I will let the stub
as is.
Thanks.
On Sat, 2010-04-10 at 18:35 +0200, Frederic Weisbecker wrote:
> On Sat, Apr 10, 2010 at 11:25:50AM -0500, Matt Mackall wrote:
> > On Sat, 2010-04-10 at 16:17 +0200, Frederic Weisbecker wrote:
> > > From: Arnd Bergmann <[email protected]>
> > >
> > > Seeking on /dev/random and /dev/urandom is pointless.
> >
> > It is indeed pointless, though that doesn't mean no one does it.
> > Forbidding a no-op seems a rather unfriendly way to fix this.
>
>
> I worried about that too. If you think that could break some user
> space apps, we can make it a generic_file_llseek.
>
>
> > > Using generic_file_llseek means we no longer need to
> > > take the BKL if anyone tries to seek on these.
> >
> > Comment doesn't match the patch?
>
>
> Oops. I guess the patch has been updated, but not the changelog.
>
> Some background: we are trying to remove the uses of default_llseek
> that use the bkl. We started with turning llseek stubs to
> generic_file_llseek (or non seekable open in some cases), but we are
> hesitating now and think about actually turn all the stubs that
> might need the bkl into default_llseek, and fallback to
> generic_file_llseek for all other stubs.
>
> Depending on what we do I'll resend you an updated version
> of this patch with generic_file_llseek, or I will let the stub
> as is.
Sounds good.
--
http://selenic.com : development and support for Mercurial and Linux
On Saturday 10 April 2010 18:35:30 Frederic Weisbecker wrote:
>
> > > Using generic_file_llseek means we no longer need to
> > > take the BKL if anyone tries to seek on these.
> >
> > Comment doesn't match the patch?
Yes, my fault. The version in my series already had this problem.
> Oops. I guess the patch has been updated, but not the changelog.
>
> Some background: we are trying to remove the uses of default_llseek
> that use the bkl. We started with turning llseek stubs to
> generic_file_llseek (or non seekable open in some cases), but we are
> hesitating now and think about actually turn all the stubs that
> might need the bkl into default_llseek, and fallback to
> generic_file_llseek for all other stubs.
>
> Depending on what we do I'll resend you an updated version
> of this patch with generic_file_llseek, or I will let the stub
> as is.
The noop_llseek from Jan's series seems most appropriate here.
Arnd