<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/fs/ecryptfs, branch v4.0-rc2</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>VFS: (Scripted) Convert S_ISLNK/DIR/REG(dentry-&gt;d_inode) to d_is_*(dentry)</title>
<updated>2015-02-22T16:38:41+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2015-01-29T12:02:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e36cb0b89ce20b4f8786a57e8a6bc8476f577650'/>
<id>e36cb0b89ce20b4f8786a57e8a6bc8476f577650</id>
<content type='text'>
Convert the following where appropriate:

 (1) S_ISLNK(dentry-&gt;d_inode) to d_is_symlink(dentry).

 (2) S_ISREG(dentry-&gt;d_inode) to d_is_reg(dentry).

 (3) S_ISDIR(dentry-&gt;d_inode) to d_is_dir(dentry).  This is actually more
     complicated than it appears as some calls should be converted to
     d_can_lookup() instead.  The difference is whether the directory in
     question is a real dir with a -&gt;lookup op or whether it's a fake dir with
     a -&gt;d_automount op.

In some circumstances, we can subsume checks for dentry-&gt;d_inode not being
NULL into this, provided we the code isn't in a filesystem that expects
d_inode to be NULL if the dirent really *is* negative (ie. if we're going to
use d_inode() rather than d_backing_inode() to get the inode pointer).

Note that the dentry type field may be set to something other than
DCACHE_MISS_TYPE when d_inode is NULL in the case of unionmount, where the VFS
manages the fall-through from a negative dentry to a lower layer.  In such a
case, the dentry type of the negative union dentry is set to the same as the
type of the lower dentry.

However, if you know d_inode is not NULL at the call site, then you can use
the d_is_xxx() functions even in a filesystem.

There is one further complication: a 0,0 chardev dentry may be labelled
DCACHE_WHITEOUT_TYPE rather than DCACHE_SPECIAL_TYPE.  Strictly, this was
intended for special directory entry types that don't have attached inodes.

The following perl+coccinelle script was used:

use strict;

my @callers;
open($fd, 'git grep -l \'S_IS[A-Z].*-&gt;d_inode\' |') ||
    die "Can't grep for S_ISDIR and co. callers";
@callers = &lt;$fd&gt;;
close($fd);
unless (@callers) {
    print "No matches\n";
    exit(0);
}

my @cocci = (
    '@@',
    'expression E;',
    '@@',
    '',
    '- S_ISLNK(E-&gt;d_inode-&gt;i_mode)',
    '+ d_is_symlink(E)',
    '',
    '@@',
    'expression E;',
    '@@',
    '',
    '- S_ISDIR(E-&gt;d_inode-&gt;i_mode)',
    '+ d_is_dir(E)',
    '',
    '@@',
    'expression E;',
    '@@',
    '',
    '- S_ISREG(E-&gt;d_inode-&gt;i_mode)',
    '+ d_is_reg(E)' );

my $coccifile = "tmp.sp.cocci";
open($fd, "&gt;$coccifile") || die $coccifile;
print($fd "$_\n") || die $coccifile foreach (@cocci);
close($fd);

foreach my $file (@callers) {
    chomp $file;
    print "Processing ", $file, "\n";
    system("spatch", "--sp-file", $coccifile, $file, "--in-place", "--no-show-diff") == 0 ||
	die "spatch failed";
}

[AV: overlayfs parts skipped]

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Convert the following where appropriate:

 (1) S_ISLNK(dentry-&gt;d_inode) to d_is_symlink(dentry).

 (2) S_ISREG(dentry-&gt;d_inode) to d_is_reg(dentry).

 (3) S_ISDIR(dentry-&gt;d_inode) to d_is_dir(dentry).  This is actually more
     complicated than it appears as some calls should be converted to
     d_can_lookup() instead.  The difference is whether the directory in
     question is a real dir with a -&gt;lookup op or whether it's a fake dir with
     a -&gt;d_automount op.

In some circumstances, we can subsume checks for dentry-&gt;d_inode not being
NULL into this, provided we the code isn't in a filesystem that expects
d_inode to be NULL if the dirent really *is* negative (ie. if we're going to
use d_inode() rather than d_backing_inode() to get the inode pointer).

Note that the dentry type field may be set to something other than
DCACHE_MISS_TYPE when d_inode is NULL in the case of unionmount, where the VFS
manages the fall-through from a negative dentry to a lower layer.  In such a
case, the dentry type of the negative union dentry is set to the same as the
type of the lower dentry.

However, if you know d_inode is not NULL at the call site, then you can use
the d_is_xxx() functions even in a filesystem.

There is one further complication: a 0,0 chardev dentry may be labelled
DCACHE_WHITEOUT_TYPE rather than DCACHE_SPECIAL_TYPE.  Strictly, this was
intended for special directory entry types that don't have attached inodes.

The following perl+coccinelle script was used:

use strict;

my @callers;
open($fd, 'git grep -l \'S_IS[A-Z].*-&gt;d_inode\' |') ||
    die "Can't grep for S_ISDIR and co. callers";
@callers = &lt;$fd&gt;;
close($fd);
unless (@callers) {
    print "No matches\n";
    exit(0);
}

my @cocci = (
    '@@',
    'expression E;',
    '@@',
    '',
    '- S_ISLNK(E-&gt;d_inode-&gt;i_mode)',
    '+ d_is_symlink(E)',
    '',
    '@@',
    'expression E;',
    '@@',
    '',
    '- S_ISDIR(E-&gt;d_inode-&gt;i_mode)',
    '+ d_is_dir(E)',
    '',
    '@@',
    'expression E;',
    '@@',
    '',
    '- S_ISREG(E-&gt;d_inode-&gt;i_mode)',
    '+ d_is_reg(E)' );

my $coccifile = "tmp.sp.cocci";
open($fd, "&gt;$coccifile") || die $coccifile;
print($fd "$_\n") || die $coccifile foreach (@cocci);
close($fd);

foreach my $file (@callers) {
    chomp $file;
    print "Processing ", $file, "\n";
    system("spatch", "--sp-file", $coccifile, $file, "--in-place", "--no-show-diff") == 0 ||
	die "spatch failed";
}

[AV: overlayfs parts skipped]

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: remove mapping-&gt;backing_dev_info</title>
<updated>2015-01-20T21:03:05+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2015-01-14T09:42:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b83ae6d421435c6204150300f1c25bfbd39cd62b'/>
<id>b83ae6d421435c6204150300f1c25bfbd39cd62b</id>
<content type='text'>
Now that we never use the backing_dev_info pointer in struct address_space
we can simply remove it and save 4 to 8 bytes in every inode.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Acked-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
Reviewed-by: Tejun Heo &lt;tj@kernel.org&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Now that we never use the backing_dev_info pointer in struct address_space
we can simply remove it and save 4 to 8 bytes in every inode.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Acked-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
Reviewed-by: Tejun Heo &lt;tj@kernel.org&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: introduce f_op-&gt;mmap_capabilities for nommu mmap support</title>
<updated>2015-01-20T21:02:58+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2015-01-14T09:42:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b4caecd48005fbed3949dde6c1cb233142fd69e9'/>
<id>b4caecd48005fbed3949dde6c1cb233142fd69e9</id>
<content type='text'>
Since "BDI: Provide backing device capability information [try #3]" the
backing_dev_info structure also provides flags for the kind of mmap
operation available in a nommu environment, which is entirely unrelated
to it's original purpose.

Introduce a new nommu-only file operation to provide this information to
the nommu mmap code instead.  Splitting this from the backing_dev_info
structure allows to remove lots of backing_dev_info instance that aren't
otherwise needed, and entirely gets rid of the concept of providing a
backing_dev_info for a character device.  It also removes the need for
the mtd_inodefs filesystem.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Tejun Heo &lt;tj@kernel.org&gt;
Acked-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since "BDI: Provide backing device capability information [try #3]" the
backing_dev_info structure also provides flags for the kind of mmap
operation available in a nommu environment, which is entirely unrelated
to it's original purpose.

Introduce a new nommu-only file operation to provide this information to
the nommu mmap code instead.  Splitting this from the backing_dev_info
structure allows to remove lots of backing_dev_info instance that aren't
otherwise needed, and entirely gets rid of the concept of providing a
backing_dev_info for a character device.  It also removes the need for
the mtd_inodefs filesystem.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Tejun Heo &lt;tj@kernel.org&gt;
Acked-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'ecryptfs-3.19-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs</title>
<updated>2014-12-20T02:15:12+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-12-20T02:15:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=298647e31af52e795867a399fa049cebd88067ff'/>
<id>298647e31af52e795867a399fa049cebd88067ff</id>
<content type='text'>
Pull eCryptfs fixes from Tyler Hicks:
 "Fixes for filename decryption and encrypted view plus a cleanup

   - The filename decryption routines were, at times, writing a zero
     byte one character past the end of the filename buffer

   - The encrypted view feature attempted, and failed, to roll its own
     form of enforcing a read-only mount instead of letting the VFS
     enforce it"

* tag 'ecryptfs-3.19-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs:
  eCryptfs: Remove buggy and unnecessary write in file name decode routine
  eCryptfs: Remove unnecessary casts when parsing packet lengths
  eCryptfs: Force RO mount when encrypted view is enabled
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull eCryptfs fixes from Tyler Hicks:
 "Fixes for filename decryption and encrypted view plus a cleanup

   - The filename decryption routines were, at times, writing a zero
     byte one character past the end of the filename buffer

   - The encrypted view feature attempted, and failed, to roll its own
     form of enforcing a read-only mount instead of letting the VFS
     enforce it"

* tag 'ecryptfs-3.19-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs:
  eCryptfs: Remove buggy and unnecessary write in file name decode routine
  eCryptfs: Remove unnecessary casts when parsing packet lengths
  eCryptfs: Force RO mount when encrypted view is enabled
</pre>
</div>
</content>
</entry>
<entry>
<title>eCryptfs: Remove buggy and unnecessary write in file name decode routine</title>
<updated>2014-11-26T21:55:02+00:00</updated>
<author>
<name>Michael Halcrow</name>
<email>mhalcrow@google.com</email>
</author>
<published>2014-11-26T17:09:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=942080643bce061c3dd9d5718d3b745dcb39a8bc'/>
<id>942080643bce061c3dd9d5718d3b745dcb39a8bc</id>
<content type='text'>
Dmitry Chernenkov used KASAN to discover that eCryptfs writes past the
end of the allocated buffer during encrypted filename decoding. This
fix corrects the issue by getting rid of the unnecessary 0 write when
the current bit offset is 2.

Signed-off-by: Michael Halcrow &lt;mhalcrow@google.com&gt;
Reported-by: Dmitry Chernenkov &lt;dmitryc@google.com&gt;
Suggested-by: Kees Cook &lt;keescook@chromium.org&gt;
Cc: stable@vger.kernel.org # v2.6.29+: 51ca58d eCryptfs: Filename Encryption: Encoding and encryption functions
Signed-off-by: Tyler Hicks &lt;tyhicks@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Dmitry Chernenkov used KASAN to discover that eCryptfs writes past the
end of the allocated buffer during encrypted filename decoding. This
fix corrects the issue by getting rid of the unnecessary 0 write when
the current bit offset is 2.

Signed-off-by: Michael Halcrow &lt;mhalcrow@google.com&gt;
Reported-by: Dmitry Chernenkov &lt;dmitryc@google.com&gt;
Suggested-by: Kees Cook &lt;keescook@chromium.org&gt;
Cc: stable@vger.kernel.org # v2.6.29+: 51ca58d eCryptfs: Filename Encryption: Encoding and encryption functions
Signed-off-by: Tyler Hicks &lt;tyhicks@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>kill f_dentry uses</title>
<updated>2014-11-19T18:01:25+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2014-10-31T05:22:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b583043e99bc6d91e98fae32bd9eff6a5958240a'/>
<id>b583043e99bc6d91e98fae32bd9eff6a5958240a</id>
<content type='text'>
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>vfs: make first argument of dir_context.actor typed</title>
<updated>2014-10-31T21:48:54+00:00</updated>
<author>
<name>Miklos Szeredi</name>
<email>miklos@szeredi.hu</email>
</author>
<published>2014-10-30T16:37:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ac7576f4b1da8c9c6bc1ae026c2b9e86ae617ba5'/>
<id>ac7576f4b1da8c9c6bc1ae026c2b9e86ae617ba5</id>
<content type='text'>
Signed-off-by: Miklos Szeredi &lt;mszeredi@suse.cz&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Miklos Szeredi &lt;mszeredi@suse.cz&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>eCryptfs: Remove unnecessary casts when parsing packet lengths</title>
<updated>2014-10-29T23:32:59+00:00</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@canonical.com</email>
</author>
<published>2014-10-23T14:16:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=831115af5ca36d713355bf1b379081691eca8b3f'/>
<id>831115af5ca36d713355bf1b379081691eca8b3f</id>
<content type='text'>
The elements in the data array are already unsigned chars and do not
need to be casted.

Signed-off-by: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The elements in the data array are already unsigned chars and do not
need to be casted.

Signed-off-by: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: limit filesystem stacking depth</title>
<updated>2014-10-23T22:14:39+00:00</updated>
<author>
<name>Miklos Szeredi</name>
<email>mszeredi@suse.cz</email>
</author>
<published>2014-10-23T22:14:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=69c433ed2ecd2d3264efd7afec4439524b319121'/>
<id>69c433ed2ecd2d3264efd7afec4439524b319121</id>
<content type='text'>
Add a simple read-only counter to super_block that indicates how deep this
is in the stack of filesystems.  Previously ecryptfs was the only stackable
filesystem and it explicitly disallowed multiple layers of itself.

Overlayfs, however, can be stacked recursively and also may be stacked
on top of ecryptfs or vice versa.

To limit the kernel stack usage we must limit the depth of the
filesystem stack.  Initially the limit is set to 2.

Signed-off-by: Miklos Szeredi &lt;mszeredi@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add a simple read-only counter to super_block that indicates how deep this
is in the stack of filesystems.  Previously ecryptfs was the only stackable
filesystem and it explicitly disallowed multiple layers of itself.

Overlayfs, however, can be stacked recursively and also may be stacked
on top of ecryptfs or vice versa.

To limit the kernel stack usage we must limit the depth of the
filesystem stack.  Initially the limit is set to 2.

Signed-off-by: Miklos Szeredi &lt;mszeredi@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>eCryptfs: Force RO mount when encrypted view is enabled</title>
<updated>2014-10-23T13:11:03+00:00</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@canonical.com</email>
</author>
<published>2014-10-07T20:51:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=332b122d39c9cbff8b799007a825d94b2e7c12f2'/>
<id>332b122d39c9cbff8b799007a825d94b2e7c12f2</id>
<content type='text'>
The ecryptfs_encrypted_view mount option greatly changes the
functionality of an eCryptfs mount. Instead of encrypting and decrypting
lower files, it provides a unified view of the encrypted files in the
lower filesystem. The presence of the ecryptfs_encrypted_view mount
option is intended to force a read-only mount and modifying files is not
supported when the feature is in use. See the following commit for more
information:

  e77a56d [PATCH] eCryptfs: Encrypted passthrough

This patch forces the mount to be read-only when the
ecryptfs_encrypted_view mount option is specified by setting the
MS_RDONLY flag on the superblock. Additionally, this patch removes some
broken logic in ecryptfs_open() that attempted to prevent modifications
of files when the encrypted view feature was in use. The check in
ecryptfs_open() was not sufficient to prevent file modifications using
system calls that do not operate on a file descriptor.

Signed-off-by: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Reported-by: Priya Bansal &lt;p.bansal@samsung.com&gt;
Cc: stable@vger.kernel.org # v2.6.21+: e77a56d [PATCH] eCryptfs: Encrypted passthrough
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The ecryptfs_encrypted_view mount option greatly changes the
functionality of an eCryptfs mount. Instead of encrypting and decrypting
lower files, it provides a unified view of the encrypted files in the
lower filesystem. The presence of the ecryptfs_encrypted_view mount
option is intended to force a read-only mount and modifying files is not
supported when the feature is in use. See the following commit for more
information:

  e77a56d [PATCH] eCryptfs: Encrypted passthrough

This patch forces the mount to be read-only when the
ecryptfs_encrypted_view mount option is specified by setting the
MS_RDONLY flag on the superblock. Additionally, this patch removes some
broken logic in ecryptfs_open() that attempted to prevent modifications
of files when the encrypted view feature was in use. The check in
ecryptfs_open() was not sufficient to prevent file modifications using
system calls that do not operate on a file descriptor.

Signed-off-by: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Reported-by: Priya Bansal &lt;p.bansal@samsung.com&gt;
Cc: stable@vger.kernel.org # v2.6.21+: e77a56d [PATCH] eCryptfs: Encrypted passthrough
</pre>
</div>
</content>
</entry>
</feed>
