Re: Subject: [PATCH] rtc: Explicitly set llseek to no_llseek

[John Kacur]

On Tue, 3 Nov 2009, Andrew Morton wrote:

> On Wed, 21 Oct 2009 23:13:26 +0200 (CEST)
> John Kacur <jkacur@xxxxxxxxxx> wrote:
> 
> > >From e1b7175258b33da3b0564ef04a0b1956f04f0cc7 Mon Sep 17 00:00:00 2001
> > From: John Kacur <jkacur@xxxxxxxxxx>
> > 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/