Il 06/04/2013 15:20, Matthew Wilcox ha scritto:
On Sat, Apr 06, 2013 at 12:05:52PM +0200, Marco Stornelli wrote:
In every place where sb_start_pagefault was called now we must manage
the error code and return VM_FAULT_RETRY.
Erm ... in patch 1/4:
static inline void sb_start_pagefault
Il 06/04/2013 15:17, Matthew Wilcox ha scritto:
On Sat, Apr 06, 2013 at 12:04:52PM +0200, Marco Stornelli wrote:
In every place where sb_start_write was called now we must manage
the error code and return -EINTR.
If we must manage the error code, then these functions should be marked
In every place where sb_start_pagefault was called now we must manage
the error code and return VM_FAULT_RETRY.
Signed-off-by: Marco Stornelli
---
fs/btrfs/inode.c |4 +++-
fs/buffer.c|4 +++-
fs/ext4/inode.c|4 +++-
fs/f2fs/file.c |4 +++-
fs/gfs2/file.c
In every place where sb_start_write was called now we must manage
the error code and return -EINTR.
Signed-off-by: Marco Stornelli
---
fs/btrfs/file.c|9 +++--
fs/cifs/file.c |4 +++-
fs/ext4/mmp.c |3 ++-
fs/ext4/super.c|4 +++-
fs/fuse/file.c |4
Il 14/08/2012 15:53, Liu Bo ha scritto:
On 08/14/2012 08:59 PM, Marco Stornelli wrote:
Il 14/08/2012 07:01, liub.li...@gmail.com ha scritto:
From: Liu Bo
I found this while testing xfstests 068, the story is
t1t2
sys_sync
Il 14/08/2012 07:01, liub.li...@gmail.com ha scritto:
From: Liu Bo
I found this while testing xfstests 068, the story is
t1t2
sys_syncthaw_super
iterate_supers
down_read(sb->s_umount)
Il 09/06/2012 02:28, Andrew Morton ha scritto:
On Fri, 8 Jun 2012 16:46:47 -0700 Linus Torvalds
wrote:
Of course, if you just mean having a VFS wrapper that does
static void vfs_inode_kmem_cache_destroy(struct kmem_cache *cachep)
{
rcu_barrier();
kmem_cache_destro
2012/4/11 Josef Bacik :
> Btrfs stores generation numbers as 64bit numbers, which means we have to
> carry around a u64 in our incore inode in addition to setting i_generation.
> So convert to a u64 so btrfs can kill it's incore generation. Thanks,
>
> Signed-off-by: Josef Bacik
> ---
> include/
Il 18/09/2011 09:29, Jeff Liu ha scritto:
Hi Andreas and Andi,
Thanks for your comments.
On 09/18/2011 09:46 AM, Andi Kleen wrote:
with an additional improvement if the offset is larger or equal to the
file size, return -ENXIO in directly:
if (offset>= inode->i_size) {
Il 27/08/2011 10:30, Marco Stornelli ha scritto:
Il 26/08/2011 16:41, Zach Brown ha scritto:
Hole: a range of the file that contains no data or is made up
entirely of NULL (zero) data. Holes include preallocated ranges of
files that have not had actual data written to them.
No for me. A hole
Il 26/08/2011 16:41, Zach Brown ha scritto:
Hole: a range of the file that contains no data or is made up
entirely of NULL (zero) data. Holes include preallocated ranges of
files that have not had actual data written to them.
No for me. A hole is made up of zero data? It's a strange definitio
2011/8/26 Dave Chinner :
> On Thu, Aug 25, 2011 at 12:51:56AM -0600, Andreas Dilger wrote:
>> On 2011-08-25, at 12:40 AM, Dave Chinner wrote:
>> > On Thu, Aug 25, 2011 at 02:06:32AM -0400, Christoph Hellwig wrote:
>> >> On Tue, Jun 28, 2011 at 11:33:19AM -0400, Josef Bacik wrote:
>> >>> This is a t
Il 22/08/2011 23:22, Sunil Mushran ha scritto:
On 08/22/2011 10:56 AM, Marco Stornelli wrote:
Il 22/08/2011 17:57, Sunil Mushran ha scritto:
The following test was used to test the early implementations.
http://oss.oracle.com/~smushran/seek_data/
Thank you very much!! I found another point
Il 22/08/2011 17:57, Sunil Mushran ha scritto:
Any proposal that differentiates between holes is wrong. It should not
matter where the hole is.
Think of it from the usage-pov.
doff = 0;
while ((doff = lseek(SEEK_DATA, doff)) != -ENXIO) {
hoff = lseek(SEEK_HOLE, doff);
read_offset = doff;
read_l
2011/8/22 Sunil Mushran :
> On 08/20/2011 09:32 AM, Marco Stornelli wrote:
>>
>> Il 20/08/2011 17:36, Sunil Mushran ha scritto:
>>>
>>> On 08/20/2011 03:03 AM, Marco Stornelli wrote:
>>>>
>>>> Il 20/08/2011 11:41, Marco Stornelli ha scritt
Il 20/08/2011 17:36, Sunil Mushran ha scritto:
On 08/20/2011 03:03 AM, Marco Stornelli wrote:
Il 20/08/2011 11:41, Marco Stornelli ha scritto:
Hi,
Il 28/06/2011 17:33, Josef Bacik ha scritto:
This just gets us ready to support the SEEK_HOLE and SEEK_DATA flags.
Turns out
using fiemap in
Il 20/08/2011 11:41, Marco Stornelli ha scritto:
Hi,
Il 28/06/2011 17:33, Josef Bacik ha scritto:
This just gets us ready to support the SEEK_HOLE and SEEK_DATA flags.
Turns out
using fiemap in things like cp cause more problems than it solves, so
lets try
and give userspace an interface that
Hi,
Il 28/06/2011 17:33, Josef Bacik ha scritto:
This just gets us ready to support the SEEK_HOLE and SEEK_DATA flags. Turns out
using fiemap in things like cp cause more problems than it solves, so lets try
and give userspace an interface that doesn't suck. We need to match solaris
here, and
Sorry maybe I'm a bit late? :)
Il 28/06/2011 17:33, Josef Bacik ha scritto:
loff_t default_llseek(struct file *file, loff_t offset, int origin)
{
+ struct inode *inode = file->f_path.dentry->d_inode;
loff_t retval;
- mutex_lock(&file->f_dentry->d_inode->i_mutex);
+
Il 04/05/2011 19:58, Josef Bacik ha scritto:
+ if (offset>= i_size_read(inode)) {
+ mutex_unlock(&inode->i_mutex);
+ return -ENXIO;
+ }
+ offset = i_size_read(inode);
+ break;
I can add that gene
Il 05/05/2011 21:01, Josef Bacik ha scritto:
On 05/05/2011 02:54 PM, Marco Stornelli wrote:
Il 04/05/2011 19:58, Josef Bacik ha scritto:
+ if (offset>= i_size_read(inode)) {
+ mutex_unlock(&inode->i_mutex);
+ return -ENXIO;
+ }
+ offset = i_size_read(inode);
+ break;
Here maybe it&
Il 04/05/2011 19:58, Josef Bacik ha scritto:
+ if (offset>= i_size_read(inode)) {
+ mutex_unlock(&inode->i_mutex);
+ return -ENXIO;
+ }
+ offset = i_size_read(inode);
+ break;
Here maybe it's pos
2011/3/14 Christoph Hellwig :
> On Fri, Mar 04, 2011 at 08:39:03AM +1100, Dave Chinner wrote:
>> WTF? Why does append mode have any effect on whether we can punch
>> holes in a file or not? There's no justification for adding this in
>> the commit message. Why is it even in a patch that is for che
Il 04/03/2011 09:17, Marco Stornelli ha scritto:
> Hi Dave,
>
> Il 03/03/2011 22:39, Dave Chinner ha scritto:
>> WTF? Why does append mode have any effect on whether we can punch
>> holes in a file or not? There's no justification for adding this in
>> the com
Hi Dave,
Il 03/03/2011 22:39, Dave Chinner ha scritto:
> WTF? Why does append mode have any effect on whether we can punch
> holes in a file or not? There's no justification for adding this in
> the commit message. Why is it even in a patch that is for checking
> immutable inodes? What is the poi
From: Marco Stornelli
All fs must check for the immutable flag in their fallocate callback.
It's possible to have a race condition in this scenario: an application
open a file in read/write and it does something, meanwhile root set the
immutable flag on the file, the application at that
Il 27/02/2011 23:49, Ted Ts'o ha scritto:
> On Mon, Feb 21, 2011 at 05:50:21PM +0100, Marco Stornelli wrote:
>> 2011/2/21 Christoph Hellwig :
>>> On Mon, Feb 21, 2011 at 09:26:32AM +0100, Marco Stornelli wrote:
>>>> From: Marco Stornelli
>>>>
>>
2011/2/27 Ted Ts'o :
> On Mon, Feb 21, 2011 at 05:50:21PM +0100, Marco Stornelli wrote:
>> 2011/2/21 Christoph Hellwig :
>> > On Mon, Feb 21, 2011 at 09:26:32AM +0100, Marco Stornelli wrote:
>> >> From: Marco Stornelli
>> >>
>> >>
Il 21/02/2011 09:26, Marco Stornelli ha scritto:
> From: Marco Stornelli
>
> All fs must check for the immutable flag in their fallocate callback.
> It's possible to have a race condition in this scenario: an application
> open a file in read/write and it does something, me
2011/2/21 Christoph Hellwig :
> On Mon, Feb 21, 2011 at 09:26:32AM +0100, Marco Stornelli wrote:
>> From: Marco Stornelli
>>
>> All fs must check for the immutable flag in their fallocate callback.
>> It's possible to have a race condition in this scenario: an ap
From: Marco Stornelli
All fs must check for the immutable flag in their fallocate callback.
It's possible to have a race condition in this scenario: an application
open a file in read/write and it does something, meanwhile root set the
immutable flag on the file, the application at that
Il 29/12/2010 07:46, Andreas Dilger ha scritto:
> On 2010-12-28, at 09:06, Marco Stornelli wrote:
>> it seems that ext4/btrfs code for fallocate doesn't check for
>> immutable/append inode flag.
>
> fallocate() probably shouldn't be allowed for immutable files, bu
Hi,
it seems that ext4/btrfs code for fallocate doesn't check for
immutable/append inode flag. I think it's possible to do an fallocate
operation even if the immutable flag is turned on. You can think about
this case: an application opens a file for read/write, meanwhile a user
set the immutable f
33 matches
Mail list logo