Re: [PATCH] dcache: remove trailing whitespace

[Niklas Cassel]

On Fri, Mar 16, 2018 at 03:55:38PM +, Al Viro wrote:
> On Fri, Mar 16, 2018 at 03:34:00PM +0100, Niklas Cassel wrote:
> > Remove trailing whitespace.
> > Remove empty line and trailing whitespace after function comments.
> > Remove an extra space in one of the comments.
> > Fix a typo in of the comments.
> > 
> > Signed-off-by: Niklas Cassel 
> > ---
> > I know that these type of patches are not really appreciated,
> > however, there is enough trailing whitespace in this file to
> > distract me from reading the real code.
> 
> No, they are not, and here's why:
> 
> Applying: dcache: remove trailing whitespace
> error: patch failed: fs/dcache.c:254
> error: fs/dcache.c: patch does not apply
> Patch failed at 0001 dcache: remove trailing whitespace
> 
> ... which, BTW, happens in *all* branches.  If you do that kind
> of stuff, at least do it against something in the public trees
> and _tell_ _what_ _it_ _is_ _against_.

Hello Al,

I always base my patches on linux-next, which is usually correct,
and if it isn't, the maintainer usually says something :)

The patch in question is based on the latest linux-next tag:
next-20180316

It appears that the following three commits are in linux-next,
but not on your for-next branch @ your vfs git tree:
61fc3c8ce7f1 dcache: remove trailing whitespace
929387149a47 dcache: fix indirectly reclaimable memory accounting
ff335768ddd0 dcache: fix indirectly reclaimable memory accounting for 
CONFIG_SLOB

They appear to come from Andrew Morton's tree.

Would you prefer me to rebase my patch against your
for-next branch instead?

> Not applied.  Please, do it sanely.  BTW, which editor is _that_
> annoying?  Anything that shoves trailing whitespace in my face
> would've been either configured (with considerable cursing at
> the people who'd set such defaults) or, should that prove
> impossible, given a boot...

I'm using emacs, but having added show-trailing-whitespace
is my personal preference, however, I quite sure that I'm
not the only one who has an editor configured like this.


Kind regards,
Niklas

Re: [PATCH] dcache: remove trailing whitespace

[Niklas Cassel]

On Fri, Mar 16, 2018 at 03:55:38PM +, Al Viro wrote:
> On Fri, Mar 16, 2018 at 03:34:00PM +0100, Niklas Cassel wrote:
> > Remove trailing whitespace.
> > Remove empty line and trailing whitespace after function comments.
> > Remove an extra space in one of the comments.
> > Fix a typo in of the comments.
> > 
> > Signed-off-by: Niklas Cassel 
> > ---
> > I know that these type of patches are not really appreciated,
> > however, there is enough trailing whitespace in this file to
> > distract me from reading the real code.
> 
> No, they are not, and here's why:
> 
> Applying: dcache: remove trailing whitespace
> error: patch failed: fs/dcache.c:254
> error: fs/dcache.c: patch does not apply
> Patch failed at 0001 dcache: remove trailing whitespace
> 
> ... which, BTW, happens in *all* branches.  If you do that kind
> of stuff, at least do it against something in the public trees
> and _tell_ _what_ _it_ _is_ _against_.

Hello Al,

I always base my patches on linux-next, which is usually correct,
and if it isn't, the maintainer usually says something :)

The patch in question is based on the latest linux-next tag:
next-20180316

It appears that the following three commits are in linux-next,
but not on your for-next branch @ your vfs git tree:
61fc3c8ce7f1 dcache: remove trailing whitespace
929387149a47 dcache: fix indirectly reclaimable memory accounting
ff335768ddd0 dcache: fix indirectly reclaimable memory accounting for 
CONFIG_SLOB

They appear to come from Andrew Morton's tree.

Would you prefer me to rebase my patch against your
for-next branch instead?

> Not applied.  Please, do it sanely.  BTW, which editor is _that_
> annoying?  Anything that shoves trailing whitespace in my face
> would've been either configured (with considerable cursing at
> the people who'd set such defaults) or, should that prove
> impossible, given a boot...

I'm using emacs, but having added show-trailing-whitespace
is my personal preference, however, I quite sure that I'm
not the only one who has an editor configured like this.


Kind regards,
Niklas

Re: [PATCH] dcache: remove trailing whitespace

[Al Viro]

On Fri, Mar 16, 2018 at 03:34:00PM +0100, Niklas Cassel wrote:
> Remove trailing whitespace.
> Remove empty line and trailing whitespace after function comments.
> Remove an extra space in one of the comments.
> Fix a typo in of the comments.
> 
> Signed-off-by: Niklas Cassel 
> ---
> I know that these type of patches are not really appreciated,
> however, there is enough trailing whitespace in this file to
> distract me from reading the real code.

No, they are not, and here's why:

Applying: dcache: remove trailing whitespace
error: patch failed: fs/dcache.c:254
error: fs/dcache.c: patch does not apply
Patch failed at 0001 dcache: remove trailing whitespace

... which, BTW, happens in *all* branches.  If you do that kind
of stuff, at least do it against something in the public trees
and _tell_ _what_ _it_ _is_ _against_.

Or send a sed script for doing that[1] - even Linus takes those
for search-and-replace stuff.

[1] sed -i -e 's/[[:space:]]*$//' fs/dcache.c
or, if you are not sending to Linus,
ed fs/dcache.c <<'EOF'
%s/[[:space:]]*$//
wq
EOF

Not applied.  Please, do it sanely.  BTW, which editor is _that_
annoying?  Anything that shoves trailing whitespace in my face
would've been either configured (with considerable cursing at
the people who'd set such defaults) or, should that prove
impossible, given a boot...

Re: [PATCH] dcache: remove trailing whitespace

[Al Viro]

On Fri, Mar 16, 2018 at 03:34:00PM +0100, Niklas Cassel wrote:
> Remove trailing whitespace.
> Remove empty line and trailing whitespace after function comments.
> Remove an extra space in one of the comments.
> Fix a typo in of the comments.
> 
> Signed-off-by: Niklas Cassel 
> ---
> I know that these type of patches are not really appreciated,
> however, there is enough trailing whitespace in this file to
> distract me from reading the real code.

No, they are not, and here's why:

Applying: dcache: remove trailing whitespace
error: patch failed: fs/dcache.c:254
error: fs/dcache.c: patch does not apply
Patch failed at 0001 dcache: remove trailing whitespace

... which, BTW, happens in *all* branches.  If you do that kind
of stuff, at least do it against something in the public trees
and _tell_ _what_ _it_ _is_ _against_.

Or send a sed script for doing that[1] - even Linus takes those
for search-and-replace stuff.

[1] sed -i -e 's/[[:space:]]*$//' fs/dcache.c
or, if you are not sending to Linus,
ed fs/dcache.c <<'EOF'
%s/[[:space:]]*$//
wq
EOF

Not applied.  Please, do it sanely.  BTW, which editor is _that_
annoying?  Anything that shoves trailing whitespace in my face
would've been either configured (with considerable cursing at
the people who'd set such defaults) or, should that prove
impossible, given a boot...

[PATCH] dcache: remove trailing whitespace

[Niklas Cassel]

Remove trailing whitespace.
Remove empty line and trailing whitespace after function comments.
Remove an extra space in one of the comments.
Fix a typo in of the comments.

Signed-off-by: Niklas Cassel 
---
I know that these type of patches are not really appreciated,
however, there is enough trailing whitespace in this file to
distract me from reading the real code.

 fs/dcache.c | 26 ++
 1 file changed, 10 insertions(+), 16 deletions(-)

diff --git a/fs/dcache.c b/fs/dcache.c
index c5e53fb9ad8b..b8a3e654d7c0 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -254,7 +254,7 @@ static void __d_free(struct rcu_head *head)
 {
struct dentry *dentry = container_of(head, struct dentry, d_u.d_rcu);
 
-   kmem_cache_free(dentry_cache, dentry); 
+   kmem_cache_free(dentry_cache, dentry);
 }
 
 static void __d_free_external_name(struct rcu_head *head)
@@ -710,7 +710,7 @@ static inline bool fast_dput(struct dentry *dentry)
unsigned int d_flags;
 
/*
-* If we have a d_op->d_delete() operation, we sould not
+* If we have a d_op->d_delete() operation, we should not
 * let the dentry count go to zero, so use "put_or_lock".
 */
if (unlikely(dentry->d_flags & DCACHE_OP_DELETE))
@@ -800,7 +800,7 @@ static inline bool fast_dput(struct dentry *dentry)
 }
 
 
-/* 
+/*
  * This is dput
  *
  * This is complicated by the fact that we do not want to put
@@ -819,7 +819,7 @@ static inline bool fast_dput(struct dentry *dentry)
 
 /*
  * dput - release a dentry
- * @dentry: dentry to release 
+ * @dentry: dentry to release
  *
  * Release a dentry. This will drop the usage count and if appropriate
  * call the dentry unlink method as well as removing it from the queues and
@@ -1427,7 +1427,7 @@ int d_set_mounted(struct dentry *dentry)
  * searching.
  *
  * It returns zero iff there are no unused children,
- * otherwise  it returns the number of children moved to
+ * otherwise it returns the number of children moved to
  * the end of the unused list. This may not be the total
  * number of unused children, because select_parent can
  * drop the lock and return early due to latency
@@ -1630,7 +1630,6 @@ EXPORT_SYMBOL(d_invalidate);
  * available. On a success the dentry is returned. The name passed in is
  * copied and the copy passed in may be reused after this call.
  */
- 
 struct dentry *__d_alloc(struct super_block *sb, const struct qstr *name)
 {
struct external_name *ext = NULL;
@@ -1657,14 +1656,14 @@ struct dentry *__d_alloc(struct super_block *sb, const 
struct qstr *name)
 
ext = kmalloc(size + name->len, GFP_KERNEL_ACCOUNT);
if (!ext) {
-   kmem_cache_free(dentry_cache, dentry); 
+   kmem_cache_free(dentry_cache, dentry);
return NULL;
}
atomic_set(>u.count, 1);
dname = ext->name;
} else  {
dname = dentry->d_iname;
-   }   
+   }
 
dentry->d_name.len = name->len;
dentry->d_name.hash = name->hash;
@@ -1889,7 +1888,6 @@ static void __d_instantiate(struct dentry *dentry, struct 
inode *inode)
  * (or otherwise set) by the caller to indicate that it is now
  * in use by the dcache.
  */
- 
 void d_instantiate(struct dentry *entry, struct inode * inode)
 {
BUG_ON(!hlist_unhashed(>d_u.d_alias));
@@ -2133,7 +2131,7 @@ struct dentry *d_add_ci(struct dentry *dentry, struct 
inode *inode,
if (!found) {
iput(inode);
return ERR_PTR(-ENOMEM);
-   } 
+   }
}
res = d_splice_alias(inode, found);
if (res) {
@@ -2342,7 +2340,7 @@ struct dentry *__d_lookup(const struct dentry *parent, 
const struct qstr *name)
 * See Documentation/filesystems/path-lookup.txt for more details.
 */
rcu_read_lock();
-   
+
hlist_bl_for_each_entry_rcu(dentry, node, b, d_hash) {
 
if (dentry->d_name.hash != hash)
@@ -2405,7 +2403,7 @@ EXPORT_SYMBOL(d_hash_and_lookup);
  * it from the hash queues and waiting for
  * it to be deleted later when it has no users
  */
- 
+
 /**
  * d_delete - delete a dentry
  * @dentry: The dentry to delete
@@ -2413,7 +2411,6 @@ EXPORT_SYMBOL(d_hash_and_lookup);
  * Turn the dentry into a negative dentry if possible, otherwise
  * remove it from the hash queues so it can be deleted later
  */
- 
 void d_delete(struct dentry * dentry)
 {
struct inode *inode = dentry->d_inode;
@@ -2451,7 +2448,6 @@ static void __d_rehash(struct dentry *entry)
  *
  * Adds a dentry to the hash according to its name.
  */
- 
 void d_rehash(struct dentry * entry)
 {
spin_lock(>d_lock);
@@ -2651,7 +2647,6 @@ static inline void __d_add(struct dentry *dentry, struct 
inode *inode)
  * This adds the entry to the hash queues and initializes @inode.
  * The entry 

[PATCH] dcache: remove trailing whitespace

[Niklas Cassel]

Remove trailing whitespace.
Remove empty line and trailing whitespace after function comments.
Remove an extra space in one of the comments.
Fix a typo in of the comments.

Signed-off-by: Niklas Cassel 
---
I know that these type of patches are not really appreciated,
however, there is enough trailing whitespace in this file to
distract me from reading the real code.

 fs/dcache.c | 26 ++
 1 file changed, 10 insertions(+), 16 deletions(-)

diff --git a/fs/dcache.c b/fs/dcache.c
index c5e53fb9ad8b..b8a3e654d7c0 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -254,7 +254,7 @@ static void __d_free(struct rcu_head *head)
 {
struct dentry *dentry = container_of(head, struct dentry, d_u.d_rcu);
 
-   kmem_cache_free(dentry_cache, dentry); 
+   kmem_cache_free(dentry_cache, dentry);
 }
 
 static void __d_free_external_name(struct rcu_head *head)
@@ -710,7 +710,7 @@ static inline bool fast_dput(struct dentry *dentry)
unsigned int d_flags;
 
/*
-* If we have a d_op->d_delete() operation, we sould not
+* If we have a d_op->d_delete() operation, we should not
 * let the dentry count go to zero, so use "put_or_lock".
 */
if (unlikely(dentry->d_flags & DCACHE_OP_DELETE))
@@ -800,7 +800,7 @@ static inline bool fast_dput(struct dentry *dentry)
 }
 
 
-/* 
+/*
  * This is dput
  *
  * This is complicated by the fact that we do not want to put
@@ -819,7 +819,7 @@ static inline bool fast_dput(struct dentry *dentry)
 
 /*
  * dput - release a dentry
- * @dentry: dentry to release 
+ * @dentry: dentry to release
  *
  * Release a dentry. This will drop the usage count and if appropriate
  * call the dentry unlink method as well as removing it from the queues and
@@ -1427,7 +1427,7 @@ int d_set_mounted(struct dentry *dentry)
  * searching.
  *
  * It returns zero iff there are no unused children,
- * otherwise  it returns the number of children moved to
+ * otherwise it returns the number of children moved to
  * the end of the unused list. This may not be the total
  * number of unused children, because select_parent can
  * drop the lock and return early due to latency
@@ -1630,7 +1630,6 @@ EXPORT_SYMBOL(d_invalidate);
  * available. On a success the dentry is returned. The name passed in is
  * copied and the copy passed in may be reused after this call.
  */
- 
 struct dentry *__d_alloc(struct super_block *sb, const struct qstr *name)
 {
struct external_name *ext = NULL;
@@ -1657,14 +1656,14 @@ struct dentry *__d_alloc(struct super_block *sb, const 
struct qstr *name)
 
ext = kmalloc(size + name->len, GFP_KERNEL_ACCOUNT);
if (!ext) {
-   kmem_cache_free(dentry_cache, dentry); 
+   kmem_cache_free(dentry_cache, dentry);
return NULL;
}
atomic_set(>u.count, 1);
dname = ext->name;
} else  {
dname = dentry->d_iname;
-   }   
+   }
 
dentry->d_name.len = name->len;
dentry->d_name.hash = name->hash;
@@ -1889,7 +1888,6 @@ static void __d_instantiate(struct dentry *dentry, struct 
inode *inode)
  * (or otherwise set) by the caller to indicate that it is now
  * in use by the dcache.
  */
- 
 void d_instantiate(struct dentry *entry, struct inode * inode)
 {
BUG_ON(!hlist_unhashed(>d_u.d_alias));
@@ -2133,7 +2131,7 @@ struct dentry *d_add_ci(struct dentry *dentry, struct 
inode *inode,
if (!found) {
iput(inode);
return ERR_PTR(-ENOMEM);
-   } 
+   }
}
res = d_splice_alias(inode, found);
if (res) {
@@ -2342,7 +2340,7 @@ struct dentry *__d_lookup(const struct dentry *parent, 
const struct qstr *name)
 * See Documentation/filesystems/path-lookup.txt for more details.
 */
rcu_read_lock();
-   
+
hlist_bl_for_each_entry_rcu(dentry, node, b, d_hash) {
 
if (dentry->d_name.hash != hash)
@@ -2405,7 +2403,7 @@ EXPORT_SYMBOL(d_hash_and_lookup);
  * it from the hash queues and waiting for
  * it to be deleted later when it has no users
  */
- 
+
 /**
  * d_delete - delete a dentry
  * @dentry: The dentry to delete
@@ -2413,7 +2411,6 @@ EXPORT_SYMBOL(d_hash_and_lookup);
  * Turn the dentry into a negative dentry if possible, otherwise
  * remove it from the hash queues so it can be deleted later
  */
- 
 void d_delete(struct dentry * dentry)
 {
struct inode *inode = dentry->d_inode;
@@ -2451,7 +2448,6 @@ static void __d_rehash(struct dentry *entry)
  *
  * Adds a dentry to the hash according to its name.
  */
- 
 void d_rehash(struct dentry * entry)
 {
spin_lock(>d_lock);
@@ -2651,7 +2647,6 @@ static inline void __d_add(struct dentry *dentry, struct 
inode *inode)
  * This adds the entry to the hash queues and initializes @inode.
  * The entry was actually filled in