Skip to content
  1. Apr 20, 2010
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ecryptfs/ecryptfs-2.6 · 9b030e20
      Linus Torvalds authored 
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ecryptfs/ecryptfs-2.6:
  eCryptfs: Turn lower lookup error messages into debug messages
  eCryptfs: Copy lower directory inode times and size on link
  ecryptfs: fix use with tmpfs by removing d_drop from ecryptfs_destroy_inode
  ecryptfs: fix error code for missing xattrs in lower fs
  eCryptfs: Decrypt symlink target for stat size
  eCryptfs: Strip metadata in xattr flag in encrypted view
  eCryptfs: Clear buffer before reading in metadata xattr
  eCryptfs: Rename ecryptfs_crypt_stat.num_header_bytes_at_front
  eCryptfs: Fix metadata in xattr feature regression
      9b030e20
    • Tyler Hicks's avatar
      eCryptfs: Turn lower lookup error messages into debug messages · 9f37622f
      Tyler Hicks authored 
      

Vaugue warnings about ENAMETOOLONG errors when looking up an encrypted
file name have caused many users to become concerned about their data.
Since this is a rather harmless condition, I'm moving this warning to
only be printed when the ecryptfs_verbosity module param is 1.

Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      9f37622f
    • Tyler Hicks's avatar
      eCryptfs: Copy lower directory inode times and size on link · 3a8380c0
      Tyler Hicks authored 
      

The timestamps and size of a lower inode involved in a link() call was
being copied to the upper parent inode.  Instead, we should be
copying lower parent inode's timestamps and size to the upper parent
inode.  I discovered this bug using the POSIX test suite at Tuxera.

Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      3a8380c0
    • Jeff Mahoney's avatar
      ecryptfs: fix use with tmpfs by removing d_drop from ecryptfs_destroy_inode · 133b8f9d
      Jeff Mahoney authored 
      Since tmpfs has no persistent storage, it pins all its dentries in memory
so they have d_count=1 when other file systems would have d_count=0.
->lookup is only used to create new dentries. If the caller doesn't
instantiate it, it's freed immediately at dput(). ->readdir reads
directly from the dcache and depends on the dentries being hashed.

When an ecryptfs mount is mounted, it associates the lower file and dentry
with the ecryptfs files as they're accessed. When it's umounted and
destroys all the in-memory ecryptfs inodes, it fput's the lower_files and
d_drop's the lower_dentries. Commit 4981e081 added this and a d_delete in
2008 and several months later commit caeeeecf

 removed the d_delete. I
believe the d_drop() needs to be removed as well.

The d_drop effectively hides any file that has been accessed via ecryptfs
from the underlying tmpfs since it depends on it being hashed for it to
be accessible. I've removed the d_drop on my development node and see no
ill effects with basic testing on both tmpfs and persistent storage.

As a side effect, after ecryptfs d_drops the dentries on tmpfs, tmpfs
BUGs on umount. This is due to the dentries being unhashed.
tmpfs->kill_sb is kill_litter_super which calls d_genocide to drop
the reference pinning the dentry. It skips unhashed and negative dentries,
but shrink_dcache_for_umount_subtree doesn't. Since those dentries
still have an elevated d_count, we get a BUG().

This patch removes the d_drop call and fixes both issues.

This issue was reported at:
https://bugzilla.novell.com/show_bug.cgi?id=567887

Reported-by: default avatarÁrpád Bíró <biroa@demasz.hu>
Signed-off-by: default avatarJeff Mahoney <jeffm@suse.com>
Cc: Dustin Kirkland <kirkland@canonical.com>
Cc: stable@kernel.org
Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      133b8f9d
    • Christian Pulvermacher's avatar
      ecryptfs: fix error code for missing xattrs in lower fs · cfce08c6
      Christian Pulvermacher authored 
      

If the lower file system driver has extended attributes disabled,
ecryptfs' own access functions return -ENOSYS instead of -EOPNOTSUPP.
This breaks execution of programs in the ecryptfs mount, since the
kernel expects the latter error when checking for security
capabilities in xattrs.

Signed-off-by: default avatarChristian Pulvermacher <pulvermacher@gmx.de>
Cc: stable@kernel.org
Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      cfce08c6
    • Tyler Hicks's avatar
      eCryptfs: Decrypt symlink target for stat size · 3a60a168
      Tyler Hicks authored 
      

Create a getattr handler for eCryptfs symlinks that is capable of
reading the lower target and decrypting its path.  Prior to this patch,
a stat's st_size field would represent the strlen of the encrypted path,
while readlink() would return the strlen of the decrypted path.  This
could lead to confusion in some userspace applications, since the two
values should be equal.

https://bugs.launchpad.net/bugs/524919

Reported-by: default avatarLoïc Minier <loic.minier@canonical.com>
Cc: stable@kernel.org
Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      3a60a168
    • Linus Torvalds's avatar
      Fix ISDN/Gigaset build failure · 76e506a7
      Linus Torvalds authored 
      Commit b91ecb00

 ("gigaset: include cleanup cleanup") removed an implicit
sched.h inclusion that came in via slab.h, and caused various compile
problems as a result.

This should fix it.

Reported-by: default avatarIngo Molnar <mingo@elte.hu>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      76e506a7
  3. Apr 19, 2010
  5. Apr 18, 2010
  7. Apr 17, 2010
    • Daniel Lezcano's avatar
      packet : remove init_net restriction · 1c4f0197
      Daniel Lezcano authored 
      

The af_packet protocol is used by Perl to do ioctls as reported by
Stephane Riviere:

"Net::RawIP relies on SIOCGIFADDR et SIOCGIFHWADDR to get the IP and MAC
addresses of the network interface."

But in a new network namespace these ioctl fail because it is disabled for
a namespace different from the init_net_ns.

These two lines should not be there as af_inet and af_packet are
namespace aware since a long time now. I suppose we forget to remove these
lines because we sent the af_packet first, before af_inet was supported.

Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@free.fr>
Reported-by: default avatarStephane Riviere <stephane.riviere@regis-dgac.net>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1c4f0197
    • Krzysztof Halasa's avatar
      WAN: flush tx_queue in hdlc_ppp to prevent panic on rmmod hw_driver. · 31f634a6
      Krzysztof Halasa authored 
      

tx_queue is used as a temporary queue when not allowed to queue skb
directly to the hw device driver (which may sleep). Most paths flush
it before returning, but ppp_start() currently cannot. Make sure we
don't leave skbs pointing to a non-existent device.

Thanks to Michael Barkowski for reporting this problem.

Signed-off-by: default avatarKrzysztof Hałasa <khc@pm.waw.pl>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      31f634a6
    • Len Brown's avatar
      Merge branch 'bugzilla-15749' into release · bc396692
      Len Brown authored
      bc396692
    • Alexey Starikovskiy's avatar
      ACPI: EC: Limit burst to 64 bits · 2060c445
      Alexey Starikovskiy authored 
      

access_bit_width field is u8 in ACPICA, thus 256 value written to it
becomes 0, causing divide by zero later.

Proper fix would be to remove access_bit_width at all, just because
we already have access_byte_width, which is access_bit_width / 8.
Limit access width to 64 bit for now.

https://bugzilla.kernel.org/show_bug.cgi?id=15749
fixes regression caused by the fix for:
https://bugzilla.kernel.org/show_bug.cgi?id=14667

Signed-off-by: default avatarAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      2060c445
    • Dave Chinner's avatar
      xfs: don't warn on EAGAIN in inode reclaim · f1d486a3
      Dave Chinner authored 
      

Any inode reclaim flush that returns EAGAIN will result in the inode
reclaim being attempted again later. There is no need to issue a
warning into the logs about this situation.

Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
Reviewed-by: default avatarAlex Elder <aelder@sgi.com>
Signed-off-by: default avatarAlex Elder <aelder@sgi.com>
      f1d486a3
    • Dave Chinner's avatar
      xfs: ensure that sync updates the log tail correctly · b6f8dd49
      Dave Chinner authored 
      

Updates to the VFS layer removed an extra ->sync_fs call into the
filesystem during the sync process (from the quota code).
Unfortunately the sync code was unknowingly relying on this call to
make sure metadata buffers were flushed via a xfs_buftarg_flush()
call to move the tail of the log forward in memory before the final
transactions of the sync process were issued.

As a result, the old code would write a very recent log tail value
to the log by the end of the sync process, and so a subsequent crash
would leave nothing for log recovery to do. Hence in qa test 182,
log recovery only replayed a small handle for inode fsync
transactions in this case.

However, with the removal of the extra ->sync_fs call, the log tail
was now not moved forward with the inode fsync transactions near the
end of the sync procese the first (and only) buftarg flush occurred
after these transactions went to disk. The result is that log
recovery now sees a large number of transactions for metadata that
is already on disk.

This usually isn't a problem, but when the transactions include
inode chunk allocation, the inode create transactions and all
subsequent changes are replayed as we cannt rely on what is on disk
is valid. As a result, if the inode was written and contains
unlogged changes, the unlogged changes are lost, thereby violating
sync semantics.

The fix is to always issue a transaction after the buftarg flush
occurs is the log iѕ not idle or covered. This results in a dummy
transaction being written that contains the up-to-date log tail
value, which will be very recent. Indeed, it will be at least as
recent as the old code would have left on disk, so log recovery
will behave exactly as it used to in this situation.

Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
Signed-off-by: default avatarAlex Elder <aelder@sgi.com>
      b6f8dd49
  9. Apr 16, 2010