headers
Venkateswararao Jujjuri (JV | 1 Jul 2011 01:18
Picon

[PATCH 1/3] [net/9p] Fix the size of receive buffer packing onto VirtIO ring.

Signed-off-by: Venkateswararao Jujjuri "<jvrao <at> linux.vnet.ibm.com>
---
 net/9p/trans_virtio.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
index 244e707..0ec5423 100644
--- a/net/9p/trans_virtio.c
+++ b/net/9p/trans_virtio.c
 <at>  <at>  -367,7 +367,7  <at>  <at>  req_retry_pinned:
 		in += inp;
 	} else {
 		in = pack_sg_list(chan->sg, out, VIRTQUEUE_NUM, rdata,
-				client->msize);
+				req->rc->capacity);
 	}

 	err = virtqueue_add_buf(chan->vq, chan->sg, out, in, req->tc);
--

-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 7 comments |
headers
Venkateswararao Jujjuri (JV | 1 Jul 2011 01:18
Picon

[PATCH 3/3] [net/9p] VirtIO can transfer VIRTQUEUE_NUM of pages.

Signed-off-by: Venkateswararao Jujjuri "<jvrao <at> linux.vnet.ibm.com>
---
 net/9p/trans_virtio.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
index 0ec5423..175b513 100644
--- a/net/9p/trans_virtio.c
+++ b/net/9p/trans_virtio.c
 <at>  <at>  -592,7 +592,7  <at>  <at>  static struct p9_trans_module p9_virtio_trans = {
 	.close = p9_virtio_close,
 	.request = p9_virtio_request,
 	.cancel = p9_virtio_cancel,
-	.maxsize = PAGE_SIZE*16,
+	.maxsize = PAGE_SIZE*VIRTQUEUE_NUM,
 	.pref = P9_TRANS_PREF_PAYLOAD_SEP,
 	.def = 0,
 	.owner = THIS_MODULE,
--

-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
Venkateswararao Jujjuri (JV | 1 Jul 2011 01:18
Picon

[PATCH 2/3] [net/9p] Fix the msize calculation.

msize represents the maximum PDU size that includes P9_IOHDRSZ.

Signed-off-by: Venkateswararao Jujjuri "<jvrao <at> linux.vnet.ibm.com>
---
 net/9p/client.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/9p/client.c b/net/9p/client.c
index 9e3b0e6..1b89351 100644
--- a/net/9p/client.c
+++ b/net/9p/client.c
 <at>  <at>  -821,8 +821,8  <at>  <at>  struct p9_client *p9_client_create(const char *dev_name, char *options)
 	if (err)
 		goto destroy_fidpool;

-	if ((clnt->msize+P9_IOHDRSZ) > clnt->trans_mod->maxsize)
-		clnt->msize = clnt->trans_mod->maxsize-P9_IOHDRSZ;
+	if (clnt->msize > clnt->trans_mod->maxsize)
+		clnt->msize = clnt->trans_mod->maxsize;

 	err = p9_client_version(clnt);
 	if (err)
--

-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dave Chinner | 1 Jul 2011 02:16

Re: fsync serialization on ext4 with blkio throttling (Was: Re: [PATCH 0/8][V2] blk-throttle: Throttle buffered WRITEs in balance_dirty_pages())

On Thu, Jun 30, 2011 at 04:44:32PM -0400, Vivek Goyal wrote:
> On Thu, Jun 30, 2011 at 04:04:59PM -0400, Vivek Goyal wrote:
> 
> [..]
> > Dave,
> > 
> > Just another example where serialization is taking place with ext4.
> > 
> > I created a group with 1MB/s write limit and ran tedso's fsync tester
> > program with little modification. I used write() system call instead
> > of pwrite() so that file size grows. This program basically writes
> > 1MB of data and then fsync's it and then measures the fsync time.
> > 
> > I ran two instances of prgram in two groups on two separate files. One
> > instances is throttled to 1MB/s and other is in root group unthrottled.
> > 
> > Unthrottled program gets serialized behind throttled one. Following
> > are fsync times.
> > 
> > Throttled instance	Unthrottled Instance
> > ------------------ 	--------------------
> > fsync time: 1.0051	fsync time: 1.0067
> > fsync time: 1.0049	fsync time: 1.0075
> > fsync time: 1.0048	fsync time: 1.0063
> > fsync time: 1.0073	fsync time: 1.0062
> > fsync time: 1.0070	fsync time: 1.0078
> > fsync time: 1.0032	fsync time: 1.0049
> > fsync time: 0.0154	fsync time: 1.0068
> > fsync time: 0.0137	fsync time: 1.0048
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aneesh Kumar K.V | 1 Jul 2011 13:14
Picon
Gravatar

Re: [PATCH 2/3] [net/9p] Fix the msize calculation.

On Thu, 30 Jun 2011 16:18:40 -0700, "Venkateswararao Jujjuri (JV)" <jvrao <at> linux.vnet.ibm.com> wrote:
> msize represents the maximum PDU size that includes P9_IOHDRSZ.
> 
> Signed-off-by: Venkateswararao Jujjuri "<jvrao <at> linux.vnet.ibm.com>
> ---
>  net/9p/client.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/net/9p/client.c b/net/9p/client.c
> index 9e3b0e6..1b89351 100644
> --- a/net/9p/client.c
> +++ b/net/9p/client.c
>  <at>  <at>  -821,8 +821,8  <at>  <at>  struct p9_client *p9_client_create(const char *dev_name, char *options)
>  	if (err)
>  		goto destroy_fidpool;
> 
> -	if ((clnt->msize+P9_IOHDRSZ) > clnt->trans_mod->maxsize)
> -		clnt->msize = clnt->trans_mod->maxsize-P9_IOHDRSZ;
> +	if (clnt->msize > clnt->trans_mod->maxsize)
> +		clnt->msize = clnt->trans_mod->maxsize;
> 
>  	err = p9_client_version(clnt);
>  	if (err)

Reviewed-by: Aneesh Kumar K.V <aneesh.kumar <at> linux.vnet.ibm.com>

-aneesh
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aneesh Kumar K.V | 1 Jul 2011 13:21
Picon
Gravatar

Re: [PATCH 1/3] [net/9p] Fix the size of receive buffer packing onto VirtIO ring.

On Thu, 30 Jun 2011 16:18:39 -0700, "Venkateswararao Jujjuri (JV)" <jvrao <at> linux.vnet.ibm.com> wrote:
> Signed-off-by: Venkateswararao Jujjuri "<jvrao <at> linux.vnet.ibm.com>
> ---
>  net/9p/trans_virtio.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
> index 244e707..0ec5423 100644
> --- a/net/9p/trans_virtio.c
> +++ b/net/9p/trans_virtio.c
>  <at>  <at>  -367,7 +367,7  <at>  <at>  req_retry_pinned:
>  		in += inp;
>  	} else {
>  		in = pack_sg_list(chan->sg, out, VIRTQUEUE_NUM, rdata,
> -				client->msize);
> +				req->rc->capacity);
>  	}
> 
>  	err = virtqueue_add_buf(chan->vq, chan->sg, out, in, req->tc);

So when will req->rc->capacity be different from client->msize ? Can we
get details for that documented in p9_tag_alloc ?

The above pack_sg_list will only be called for non-zero copy case ? In
that case won't client->size be same as rc->capacity ?

-aneesh
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 1 comment |
headers
Aneesh Kumar K.V | 1 Jul 2011 13:24
Picon
Gravatar

Re: [PATCH 3/3] [net/9p] VirtIO can transfer VIRTQUEUE_NUM of pages.

On Thu, 30 Jun 2011 16:18:41 -0700, "Venkateswararao Jujjuri (JV)" <jvrao <at> linux.vnet.ibm.com> wrote:
> Signed-off-by: Venkateswararao Jujjuri "<jvrao <at> linux.vnet.ibm.com>
> ---
>  net/9p/trans_virtio.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
> index 0ec5423..175b513 100644
> --- a/net/9p/trans_virtio.c
> +++ b/net/9p/trans_virtio.c
>  <at>  <at>  -592,7 +592,7  <at>  <at>  static struct p9_trans_module p9_virtio_trans = {
>  	.close = p9_virtio_close,
>  	.request = p9_virtio_request,
>  	.cancel = p9_virtio_cancel,
> -	.maxsize = PAGE_SIZE*16,
> +	.maxsize = PAGE_SIZE*VIRTQUEUE_NUM,
>  	.pref = P9_TRANS_PREF_PAYLOAD_SEP,
>  	.def = 0,
>  	.owner = THIS_MODULE,

Reviewed-by: Aneesh Kumar K.V <aneesh.kumar <at> linux.vnet.ibm.com>

I guess we also need to make sure Qemu server also set the msize to this
value so that we can operate with large msize ?

-aneesh
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tobias Klauser | 1 Jul 2011 13:44
Picon
Favicon
Gravatar

[PATCH] VFS: Fixup kerneldoc for generic_permission()

The flags parameter went away in
5c90c1601f00154f8695951469f25f33579272ed

Signed-off-by: Tobias Klauser <tklauser <at> distanz.ch>
---
 fs/namei.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/fs/namei.c b/fs/namei.c
index f181e4c..73fc34a 100644
--- a/fs/namei.c
+++ b/fs/namei.c
 <at>  <at>  -213,7 +213,6  <at>  <at>  other_perms:
  * generic_permission -  check for access rights on a Posix-like filesystem
  *  <at> inode:	inode to check access rights for
  *  <at> mask:	right to check for (%MAY_READ, %MAY_WRITE, %MAY_EXEC)
- *  <at> flags:	IPERM_FLAG_ flags.
  *
  * Used to check for read/write/execute permissions on a file.
  * We use "fsuid" for this, letting us set arbitrary permissions
--

-- 
1.7.5.4

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 3 comments |
headers
Allison Henderson | 1 Jul 2011 16:30
Picon

Re: [PATCH 0/2v v7] XFS TESTS: ENOSPC Punch Hole Test

On 06/28/2011 07:44 AM, Allison Henderson wrote:
> Hi All,
>
> This is another set I sent out a while ago, but I didnt see it show up on the lists,
> so I am resending this one too. The work in this patch is a continuation from a
> previous patch set that has been partially accepted, so I thought I
> should retain the v6.
>
> This patch set adds the ENOSPC test that was used for ext4 punch hole testing.
> This test will verify that a hole can be punched even when the disk is full.
> Reserved blocks should be used to complete the operation when there is not blocks
> to further fragment the file.
>
> Because punching a hole does not always require extra blocks, there needs to
> be serveal iterations of punching holes, and then filling the file system to 100%
> usage before it is forced to grow the tree in order to handle the fragmentation.
> The growing of the tree is what would cause ENOSPC if not for the use of reserved blocks.
>
> I could use some opinions on this patch set becuase I am not sure if other filesystems
> handle their punch holes in the same way.  Although xfs appears to pass the test,
> should this test be an ext4 only test? Thx!
>

Hi All,

I just wanted to poke this thread before too much time goes by.  This 
patch was initially part of an earlier set that's already been picked 
up, and it seemed like people were generally interested in it, so I 
resubmitted it as it's own patch.  Is there still an interest in this 
patch set?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mimi Zohar | 1 Jul 2011 16:34
Picon

Re: [PATCH v7 00/16] EVM

On Thu, 2011-06-30 at 18:31 -0400, Kyle Moffett wrote:

> The problem is that you are assuming that a large chunk of filesystem
> code is capable of properly and securely handling untrusted and
> malicious
> content.  Historically filesystem drivers are NOT capable of handling
> such things, as evidenced by the large number of bugs that tools such
> as
> fsfuzzer tend to trigger.  If you want to use IMA as-designed then you
> need to perform a relatively extensive audit of filesystem and fsck
> code.
> 
> Furthermore, even when the filesystem does not have any security
> issues
> itself, you are assuming that intentionally malicious data-aliasing
> between "trusted" and "untrusted" files can have no potential security
> implications.  You should look at the prevalence of simple stupid
> "/tmp"
> symlink attacks for more counter-examples there.
> 
> In addition, IMA relies on the underlying attribute and data caching
> properties of the VFS, which won't hold true for intentionally
> malicious
> corrupted filesystems.  It effectively assumes that writing data or
> metadata for one file will not invalidate the cached data or metadata
> for
> another which is blatantly false when filesystem extents overlap each
> other.
> 
> Overall, the IMA architecture assumes that if it loads and validates
(Continue reading)

Permalink | Reply | 1 comment |

Gmane