On Tue, 12 Jun 2007 10:16:22 +1000 Neil Brown <[EMAIL PROTECTED]> wrote:
> > please consider incorporating scripts/checkpatch.pl into your patch
> > preparation toolchain.
>
> Done... Any reason that it isn't executable (chmod +x)?
It is executable now (Linus did a chmod).
However I think it
On Thursday June 7, [EMAIL PROTECTED] wrote:
> On Fri, 8 Jun 2007 12:48:48 +1000 Neil Brown <[EMAIL PROTECTED]> wrote:
>
> > The following patch will remove the extra seqlock except when we
> > actually need it and remove the extra arithmetic - but I haven't
> > tested it or reviewed it properly.
On Thursday June 7, [EMAIL PROTECTED] wrote:
On Fri, 8 Jun 2007 12:48:48 +1000 Neil Brown [EMAIL PROTECTED] wrote:
The following patch will remove the extra seqlock except when we
actually need it and remove the extra arithmetic - but I haven't
tested it or reviewed it properly. I can do
On Tue, 12 Jun 2007 10:16:22 +1000 Neil Brown [EMAIL PROTECTED] wrote:
please consider incorporating scripts/checkpatch.pl into your patch
preparation toolchain.
Done... Any reason that it isn't executable (chmod +x)?
It is executable now (Linus did a chmod).
However I think it was wrong
On Fri, 8 Jun 2007 12:48:48 +1000 Neil Brown <[EMAIL PROTECTED]> wrote:
> The following patch will remove the extra seqlock except when we
> actually need it and remove the extra arithmetic - but I haven't
> tested it or reviewed it properly. I can do that if you think it is
> the right
On Fri, 8 Jun 2007 12:48:48 +1000 Neil Brown [EMAIL PROTECTED] wrote:
The following patch will remove the extra seqlock except when we
actually need it and remove the extra arithmetic - but I haven't
tested it or reviewed it properly. I can do that if you think it is
the right direction.
On Thursday June 7, [EMAIL PROTECTED] wrote:
>
> Is this really worth fixing?
Hard to say.
One could argue that a read should never return data that was never in
the file. One could also argue that you should always use locking...
But people often look for lock-less solutions.
>
> The code
On Thu, 7 Jun 2007 11:46:53 +1000
NeilBrown <[EMAIL PROTECTED]> wrote:
> do_generic_mapping_read currently samples the i_size at the start
> and doesn't do so again unless it needs to call ->readpage to load
> a page. After ->readpage it has to re-sample i_size as a truncate
> may have caused
On Thu, Jun 07 2007, NeilBrown wrote:
>
> do_generic_mapping_read currently samples the i_size at the start
> and doesn't do so again unless it needs to call ->readpage to load
> a page. After ->readpage it has to re-sample i_size as a truncate
> may have caused that page to be filled with
On Thu, 7 Jun 2007 11:46:53 +1000
NeilBrown [EMAIL PROTECTED] wrote:
do_generic_mapping_read currently samples the i_size at the start
and doesn't do so again unless it needs to call -readpage to load
a page. After -readpage it has to re-sample i_size as a truncate
may have caused that page
On Thursday June 7, [EMAIL PROTECTED] wrote:
Is this really worth fixing?
Hard to say.
One could argue that a read should never return data that was never in
the file. One could also argue that you should always use locking...
But people often look for lock-less solutions.
The code still
On Thu, Jun 07 2007, NeilBrown wrote:
do_generic_mapping_read currently samples the i_size at the start
and doesn't do so again unless it needs to call -readpage to load
a page. After -readpage it has to re-sample i_size as a truncate
may have caused that page to be filled with zeros, and
do_generic_mapping_read currently samples the i_size at the start
and doesn't do so again unless it needs to call ->readpage to load
a page. After ->readpage it has to re-sample i_size as a truncate
may have caused that page to be filled with zeros, and the read()
call should not see these.
do_generic_mapping_read currently samples the i_size at the start
and doesn't do so again unless it needs to call -readpage to load
a page. After -readpage it has to re-sample i_size as a truncate
may have caused that page to be filled with zeros, and the read()
call should not see these.
14 matches
Mail list logo