lkml.org 
[lkml]   [2009]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Subject: [PATCH] rtc: Explicitly set llseek to no_llseek


On Tue, 3 Nov 2009, Andrew Morton wrote:

> On Wed, 21 Oct 2009 23:13:26 +0200 (CEST)
> John Kacur <jkacur@redhat.com> wrote:
>
> > >From e1b7175258b33da3b0564ef04a0b1956f04f0cc7 Mon Sep 17 00:00:00 2001
> > From: John Kacur <jkacur@redhat.com>
> > Date: Wed, 21 Oct 2009 23:10:30 +0200
> > Subject: [PATCH] rtc: Explicitly set llseek to no_llseek
> >
> > Now that we've removed the BKL here, lets explicitly set llseek to no_llseek
> > since the default llseek is not used here.
> >
>
> I don't understand.
>
> >
> > diff --git a/drivers/char/efirtc.c b/drivers/char/efirtc.c
> > index 26a47dc..53c524e 100644
> > --- a/drivers/char/efirtc.c
> > +++ b/drivers/char/efirtc.c
> > @@ -285,6 +285,7 @@ static const struct file_operations efi_rtc_fops = {
> > .unlocked_ioctl = efi_rtc_ioctl,
> > .open = efi_rtc_open,
> > .release = efi_rtc_close,
> > + .llseek = no_llseek,
> > };
> >
> > static struct miscdevice efi_rtc_dev= {
>
> What has this change to do with the BKL?

The default_llseek function still contains the BKL.
When we are auditing code to see if we can remove the BKL, this is one of
the hidden considerations we need to take into account.
i.e., is there syncronization between code that has the BKL and llseek.

At the same time we remove the BKL it would be a good idea to do indicate
when no llseek function is required, so we don't have to revisit this code
again, when we are trying to determine if we can remove the BKL from
the default_llseek.


\
 
 \ /
  Last update: 2009-11-04 01:47    [W:0.104 / U:23.480 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site