headers
Andrew Morton | 1 Sep 2011 01:13

Re: bade page state while calling munmap() for kmalloc'ed UIO memory

On Wed, 31 Aug 2011 11:58:25 +0200
"Hans J. Koch" <hjk <at> hansjkoch.de> wrote:

> On Mon, Aug 29, 2011 at 05:05:47PM +0200, Jan Altenberg wrote:
> 
> [Since we got no reply on linux-mm, I added lkml and Andrew to Cc: (mm doesn't
> seem to have a maintainer...)]
> 
> > Hi,
> > 
> > I'm currently analysing a problem similar to some mmap() issue reported
> > in the past: https://lkml.org/lkml/2010/7/11/140
> 
> The arch there was microblaze, and you are working on arm. That means
> the problem appears on at least to archs.
> 
> > 
> > So, what I'm trying to do is mapping some physically continuous memory
> > (allocated by kmalloc) to userspace, using a trivial UIO driver (the
> > idea is that a device can directly DMA to that buffer):
> > 
> > [...]
> > #define MEM_SIZE (4 * PAGE_SIZE)
> > 
> > addr = kmalloc(MEM_SIZE, GFP_KERNEL)
> > [...]
> > info.mem[0].addr = (unsigned long) addr;
> > info.mem[0].internal_addr = addr;
> > info.mem[0].size = MEM_SIZE;
> > info.mem[0].memtype = UIO_MEM_LOGICAL;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Foley | 1 Sep 2011 01:11
Picon

Re: Hyper-V TODO file

On Wed, 31 Aug 2011, K. Y. Srinivasan wrote:
> Greg, as I have been pestering you for some time now, we are very interested in
> exiting staging and we are willing to dedicate the necessary development 
> resources to address whatever issues that may still be pending. So, your help
> in identifying what needs to be done will be greatly appreciated. To that end,
> I think it will be useful to update the TODO file to reflect the current state of
> the drivers. Let us know how we should proceed here. 

An issue I've come across in the hyper-v drivers is the forced modular 
build. You might want to see if the "depends on m" is still needed.

Thanks,

Peter Foley
Permalink | Reply | 4 comments |
headers
Axel Lin | 1 Sep 2011 02:11
Picon
Gravatar

[PATCH RESEND] video: mxsfb: add missing include of linux/module.h

Include linux/module.h to fix below build error:

                 from drivers/video/mxsfb.c:42:
arch/arm/mach-mxs/include/mach/memory.h:22:1: warning: this is the location of the previous definition
drivers/video/mxsfb.c:574: error: 'THIS_MODULE' undeclared here (not in a function)
drivers/video/mxsfb.c:893: warning: data definition has no type or storage class
drivers/video/mxsfb.c:893: warning: type defaults to 'int' in declaration of 'MODULE_DEVICE_TABLE'
drivers/video/mxsfb.c:893: warning: parameter names (without types) in function declaration
drivers/video/mxsfb.c:917: error: expected declaration specifiers or '...' before string constant
drivers/video/mxsfb.c:917: warning: data definition has no type or storage class
drivers/video/mxsfb.c:917: warning: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION'
drivers/video/mxsfb.c:917: warning: function declaration isn't a prototype
drivers/video/mxsfb.c:918: error: expected declaration specifiers or '...' before string constant
drivers/video/mxsfb.c:918: warning: data definition has no type or storage class
drivers/video/mxsfb.c:918: warning: type defaults to 'int' in declaration of 'MODULE_AUTHOR'
drivers/video/mxsfb.c:918: warning: function declaration isn't a prototype
drivers/video/mxsfb.c:919: error: expected declaration specifiers or '...' before string constant
drivers/video/mxsfb.c:919: warning: data definition has no type or storage class
drivers/video/mxsfb.c:919: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE'
drivers/video/mxsfb.c:919: warning: function declaration isn't a prototype
make[2]: *** [drivers/video/mxsfb.o] Error 1
make[1]: *** [drivers/video] Error 2
make: *** [drivers] Error 2

Signed-off-by: Axel Lin <axel.lin <at> gmail.com>
---
 drivers/video/mxsfb.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wang Sheng-Hui | 1 Sep 2011 02:22
Picon

[PATCH] cleanup: small fix on comment for block_invalidatepage

The patch is aganist 3.1-rc3.

Signed-off-by: Wang Sheng-Hui <shhuiw <at> gmail.com>
---
 fs/buffer.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/buffer.c b/fs/buffer.c
index 1a80b04..936d603 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
 <at>  <at>  -1470,13 +1470,13  <at>  <at>  static void discard_buffer(struct buffer_head * bh)
 }

 /**
- * block_invalidatepage - invalidate part of all of a buffer-backed page
+ * block_invalidatepage - invalidate part or all of a buffer-backed page
  *
  *  <at> page: the page which is affected
  *  <at> offset: the index of the truncation point
  *
  * block_invalidatepage() is called when all or part of the page has become
- * invalidatedby a truncate operation.
+ * invalidated by a truncate operation.
  *
  * block_invalidatepage() does not have to release all buffers, but it must
  * ensure that no dirty buffer is left outside  <at> offset and that no I/O
--

-- 
1.7.1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Perches | 1 Sep 2011 02:25

Re: [PATCH 18/24] sctp: Remove unnecessary OOM logging messages

On Mon, 2011-08-29 at 18:15 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet <at> gmail.com>
> Date: Mon, 29 Aug 2011 23:51:21 +0200
> > Le lundi 29 août 2011 à 23:43 +0200, Eric Dumazet a écrit :
> >> Furthermore, a failed vmalloc() is not guaranteed to emit an OOM
> >> message, is it ?
> > It currently displays a message without context :
> > vmap allocation for size XXXXXX failed: use vmalloc=<size> to increase
> > size.
> > So we dont know which part of the kernel asked this allocation.
> > Please dont remove existing error messages after failed vmalloc() calls.
> Indeed.
> Joe, these vmalloc() and also the __GFP_NOWARN cases will need to be
> attended to and this series resubmitted as such.

No worries.

Andrew Morton picked up a patch I posted that
changes vmalloc to be similar to kmalloc when
the pointer returned is NULL (OOM).  It now
uses dump_stack for those cases.

https://patchwork.kernel.org/patch/1114682/

I'll keep all the current vmalloc failure messages
for now and resubmit in a day or two this series
with acks.  Not batman or netfilter though as they
were picked up by their maintainers.

A month or two after the vmalloc patch hits
(Continue reading)

Permalink | Reply | 0 comments |
headers
Darrick J. Wong | 1 Sep 2011 02:30
Picon
Favicon

[PATCH v1 00/16] ext4: Add metadata checksumming

Hi all,

This patchset adds crc32c checksums to most of the ext4 metadata objects.  A
full design document is on the ext4 wiki[1] but I will summarize that document here.

As much as we wish our storage hardware was totally reliable, it is still
quite possible for data to be corrupted on disk, corrupted during transfer over
a wire, or written to the wrong places.  To protect against this sort of
non-hostile corruption, it is desirable to store checksums of metadata objects
on the filesystem to prevent broken metadata from shredding the filesystem.

The crc32c polynomial was chosen for its improved error detection capabilities
over crc32 and crc16, and because of its hardware acceleration on current and
upcoming Intel and Sparc chips.

Each type of metadata object has been retrofitted to store a checksum as follows:

- The superblock stores a crc32c of itself.
- Each inode stores crc32c(fs_uuid + inode_num + inode + slack_space_after_inode)
- Block and inode bitmaps each get their own crc32c(fs_uuid + group_num +
  bitmap), stored in the block group descriptor.
- Each extent tree block stores a crc32c(fs_uuid + inode_num + extent_entries)
  in unused space at the end of the block.
- Each directory leaf block has an unused-looking directory entry big enough to
  store a crc32c(fs_uuid + inode_num + block) at the end of the block.
- Each directory htree block is shortened to contain a crc32c(fs_uuid +
  inode_num + block) at the end of the block.
- Extended attribute blocks store crc32c(fs_uuid + block_no + ea_block) in the
  header.
- Journal commit blocks can be converted to use crc32c to checksum all blocks
(Continue reading)

Permalink | Reply | 37 comments |
headers
Darrick J. Wong | 1 Sep 2011 02:30
Picon
Favicon

[PATCH 02/16] ext4: ext4_rename should dirty dir_bh with the correct directory

When ext4_rename performs a directory rename (move), dir_bh is a buffer that is
modified to update the '..' link in the directory being moved (old_inode).
However, ext4_handle_dirty_metadata is called with the old parent directory
inode (old_dir) and dir_bh, which is incorrect because dir_bh does not belong
to the parent inode.  Fix this error.

Signed-off-by: Darrick J. Wong <djwong <at> us.ibm.com>
---
 fs/ext4/namei.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index 815c31a..f778a54 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
 <at>  <at>  -2529,7 +2529,7  <at>  <at>  static int ext4_rename(struct inode *old_dir, struct dentry *old_dentry,
 		PARENT_INO(dir_bh->b_data, new_dir->i_sb->s_blocksize) =
 						cpu_to_le32(new_dir->i_ino);
 		BUFFER_TRACE(dir_bh, "call ext4_handle_dirty_metadata");
-		retval = ext4_handle_dirty_metadata(handle, old_dir, dir_bh);
+		retval = ext4_handle_dirty_metadata(handle, old_inode, dir_bh);
 		if (retval) {
 			ext4_std_error(old_dir->i_sb, retval);
 			goto end_rename;
Permalink | Reply | 0 comments |
headers
Darrick J. Wong | 1 Sep 2011 02:30
Picon
Favicon

[PATCH 01/16] ext4: ext4_dx_add_entry should dirty directory metadata with the directory inode

ext4_dx_add_entry manipulates bh2 and frames[0].bh, which are two buffer_heads
that point to directory blocks assigned to the directory inode.  However, the
function calls ext4_handle_dirty_metadata with the inode of the file that's
being added to the directory, not the directory inode itself.  Therefore,
correct the code to dirty the directory buffers with the directory inode, not
the file inode.

Signed-off-by: Darrick J. Wong <djwong <at> us.ibm.com>
---
 fs/ext4/namei.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index f8068c7..815c31a 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
 <at>  <at>  -1585,7 +1585,7  <at>  <at>  static int ext4_dx_add_entry(handle_t *handle, struct dentry *dentry,
 			dxtrace(dx_show_index("node", frames[1].entries));
 			dxtrace(dx_show_index("node",
 			       ((struct dx_node *) bh2->b_data)->entries));
-			err = ext4_handle_dirty_metadata(handle, inode, bh2);
+			err = ext4_handle_dirty_metadata(handle, dir, bh2);
 			if (err)
 				goto journal_error;
 			brelse (bh2);
 <at>  <at>  -1611,7 +1611,7  <at>  <at>  static int ext4_dx_add_entry(handle_t *handle, struct dentry *dentry,
 			if (err)
 				goto journal_error;
 		}
-		err = ext4_handle_dirty_metadata(handle, inode, frames[0].bh);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Darrick J. Wong | 1 Sep 2011 02:30
Picon
Favicon

[PATCH 04/16] ext4: Create a new BH_Verified flag to avoid unnecessary metadata validation

Create a new BH_Verified flag to indicate that we've verified all the data in a
buffer_head for correctness.  This allows us to bypass expensive verification
steps when they are not necessary without missing them when they are.

Signed-off-by: Darrick J. Wong <djwong <at> us.ibm.com>
---
 fs/ext4/ext4.h    |    2 ++
 fs/ext4/extents.c |   35 ++++++++++++++++++++++++++---------
 2 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index e717dfd..ecb86c2 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
 <at>  <at>  -2242,10 +2242,12  <at>  <at>  extern int ext4_multi_mount_protect(struct super_block *, ext4_fsblk_t);
 enum ext4_state_bits {
 	BH_Uninit	/* blocks are allocated but uninitialized on disk */
 	  = BH_JBDPrivateStart,
+	BH_Verified,	/* metadata block has been verified ok */
 };

 BUFFER_FNS(Uninit, uninit)
 TAS_BUFFER_FNS(Uninit, uninit)
+BUFFER_FNS(Verified, verified)

 /*
  * Add new method to test wether block and inode bitmaps are properly
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 57cf568..4ac4303 100644
--- a/fs/ext4/extents.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Darrick J. Wong | 1 Sep 2011 02:30
Picon
Favicon

[PATCH 03/16] ext4: ext4_mkdir should dirty dir_block with the parent inode

ext4_mkdir calls ext4_handle_dirty_metadata with dir_block and the inode "dir".
Unfortunately, dir_block belongs to the newly created directory (which is
"inode"), not the parent directory (which is "dir").  Fix the incorrect
association.

Signed-off-by: Darrick J. Wong <djwong <at> us.ibm.com>
---
 fs/ext4/namei.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index f778a54..a067835 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
 <at>  <at>  -1862,7 +1862,7  <at>  <at>  retry:
 	ext4_set_de_type(dir->i_sb, de, S_IFDIR);
 	inode->i_nlink = 2;
 	BUFFER_TRACE(dir_block, "call ext4_handle_dirty_metadata");
-	err = ext4_handle_dirty_metadata(handle, dir, dir_block);
+	err = ext4_handle_dirty_metadata(handle, inode, dir_block);
 	if (err)
 		goto out_clear_inode;
 	err = ext4_mark_inode_dirty(handle, inode);
Permalink | Reply | 0 comments |

Gmane