Kristian Nielsen writes:
> Benjamin LaHaise writes:
>
>> Linus just pushed out 3.13-rc5 that has changes to aio_migratepage() that
>> should make it much more robust, as well as other fixes. Can you please
>> give it a spin as well and let me know if it works?
Kristian Nielsen kniel...@knielsen-hq.org writes:
Benjamin LaHaise b...@kvack.org writes:
Linus just pushed out 3.13-rc5 that has changes to aio_migratepage() that
should make it much more robust, as well as other fixes. Can you please
give it a spin as well and let me know if it works
Benjamin LaHaise writes:
> Linus just pushed out 3.13-rc5 that has changes to aio_migratepage() that
> should make it much more robust, as well as other fixes. Can you please
> give it a spin as well and let me know if it works? Thanks a bunch!
Ok, will do.
- Kristian.
--
To unsubscribe
Gu Zheng writes:
> This issue seems like a problem that has been fixed yet:
> http://article.gmane.org/gmane.linux.kernel.aio.general/3741/match=potential+use+after+free+aio%5fmigratepage
> commit 5e9ae2e5da0beb93f8557fc92a8f4fbc05ea448f
> aio: fix use-after-free in aio_migratepage
> So I think
Gu Zheng guz.f...@cn.fujitsu.com writes:
This issue seems like a problem that has been fixed yet:
http://article.gmane.org/gmane.linux.kernel.aio.general/3741/match=potential+use+after+free+aio%5fmigratepage
commit 5e9ae2e5da0beb93f8557fc92a8f4fbc05ea448f
aio: fix use-after-free in
Benjamin LaHaise b...@kvack.org writes:
Linus just pushed out 3.13-rc5 that has changes to aio_migratepage() that
should make it much more robust, as well as other fixes. Can you please
give it a spin as well and let me know if it works? Thanks a bunch!
Ok, will do.
- Kristian.
--
To
What is the status of this?
If I understand correctly, the crash I saw is different from what Dave
saw.
There was one patched scheduled for inclusion that fixes Dave's crash. But
what about mine? I have been running 3.13-rc2 for a couple of weeks now with
your other patch, without seeing it
What is the status of this?
If I understand correctly, the crash I saw is different from what Dave
saw.
There was one patched scheduled for inclusion that fixes Dave's crash. But
what about mine? I have been running 3.13-rc2 for a couple of weeks now with
your other patch, without seeing it
Gu Zheng writes:
> Hi Kristian, Dave,
>
> Could you please help to check whether the following patch can fix this issue?
> Signed-off-by: Gu Zheng
> ---
> fs/aio.c | 28 ++--
> 1 files changed, 10 insertions(+), 18 deletions(-)
>
Ok. I've applied the patch to
Gu Zheng guz.f...@cn.fujitsu.com writes:
Hi Kristian, Dave,
Could you please help to check whether the following patch can fix this issue?
Signed-off-by: Gu Zheng guz.f...@cn.fujitsu.com
---
fs/aio.c | 28 ++--
1 files changed, 10 insertions(+), 18 deletions(-)
Benjamin LaHaise writes:
> For Dave: what line is this bug on? Is it the dereference of ctx when
> doing spin_lock_irqsave(>completion_lock, flags); or is the
> ctx->ring_pages[idx] = new; ? From the 64 bit splat, I'm thinking the
> former, which is quite strange given that the clearing of
Benjamin LaHaise b...@kvack.org writes:
For Dave: what line is this bug on? Is it the dereference of ctx when
doing spin_lock_irqsave(ctx-completion_lock, flags); or is the
ctx-ring_pages[idx] = new; ? From the 64 bit splat, I'm thinking the
former, which is quite strange given that the
Jan Kara writes:
> On Mon 03-09-12 10:45:15, Kristian Nielsen wrote:
>> It appears that ext3 and ext4 fdatasync() does not fully sync data to
>> disk. Specifically, when new data is written at the end (so that the file
>> length is increased), not all of the new data i
Jan Kara j...@suse.cz writes:
On Mon 03-09-12 10:45:15, Kristian Nielsen wrote:
It appears that ext3 and ext4 fdatasync() does not fully sync data to
disk. Specifically, when new data is written at the end (so that the file
length is increased), not all of the new data is synced by fdatasync
It appears that ext3 and ext4 fdatasync() does not fully sync data to
disk. Specifically, when new data is written at the end (so that the file
length is increased), not all of the new data is synced by fdatasync().
It looks as if the problem is when the new data fits in the last allocated
page
It appears that ext3 and ext4 fdatasync() does not fully sync data to
disk. Specifically, when new data is written at the end (so that the file
length is increased), not all of the new data is synced by fdatasync().
It looks as if the problem is when the new data fits in the last allocated
page
16 matches
Mail list logo
