From: Mauro Carvalho Chehab Date: Fri, 12 May 2017 10:45:42 +0000 (-0300) Subject: fs: add a blank lines on some kernel-doc comments X-Git-Tag: microblaze-4.14-rc3~476^2~21^2~32 X-Git-Url: http://git.monstr.eu/?a=commitdiff_plain;h=0117d4272b1acd151812abf4a6702fc7873e16ea;p=linux-2.6-microblaze.git fs: add a blank lines on some kernel-doc comments Sphinx gets confused when it finds identation without a good reason for it and without a preceding blank line: ./fs/mpage.c:347: ERROR: Unexpected indentation. ./fs/namei.c:4303: ERROR: Unexpected indentation. ./fs/fs-writeback.c:2060: ERROR: Unexpected indentation. No functional changes. Signed-off-by: Mauro Carvalho Chehab --- diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index 63ee2940775c..8b426f83909f 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -2052,11 +2052,13 @@ static noinline void block_dump___mark_inode_dirty(struct inode *inode) } /** - * __mark_inode_dirty - internal function - * @inode: inode to mark - * @flags: what kind of dirty (i.e. I_DIRTY_SYNC) - * Mark an inode as dirty. Callers should use mark_inode_dirty or - * mark_inode_dirty_sync. + * __mark_inode_dirty - internal function + * + * @inode: inode to mark + * @flags: what kind of dirty (i.e. I_DIRTY_SYNC) + * + * Mark an inode as dirty. Callers should use mark_inode_dirty or + * mark_inode_dirty_sync. * * Put the inode on the super block's dirty list. * diff --git a/fs/mpage.c b/fs/mpage.c index baff8f820c29..4760a0c09a4e 100644 --- a/fs/mpage.c +++ b/fs/mpage.c @@ -344,6 +344,7 @@ confused: * * So an mpage read of the first 16 blocks of an ext2 file will cause I/O to be * submitted in the following order: + * * 12 0 1 2 3 4 5 6 7 8 9 10 11 13 14 15 16 * * because the indirect block has to be read to get the mappings of blocks diff --git a/fs/namei.c b/fs/namei.c index 7286f87ce863..b5af8228e2d9 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -4300,6 +4300,7 @@ SYSCALL_DEFINE2(link, const char __user *, oldname, const char __user *, newname * The worst of all namespace operations - renaming directory. "Perverted" * doesn't even start to describe it. Somebody in UCB had a heck of a trip... * Problems: + * * a) we can get into loop creation. * b) race potential - two innocent renames can create a loop together. * That's where 4.4 screws up. Current fix: serialization on