09 Jan, 2012
1 commit
-
* 'for-linus2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (165 commits)
reiserfs: Properly display mount options in /proc/mounts
vfs: prevent remount read-only if pending removes
vfs: count unlinked inodes
vfs: protect remounting superblock read-only
vfs: keep list of mounts for each superblock
vfs: switch ->show_options() to struct dentry *
vfs: switch ->show_path() to struct dentry *
vfs: switch ->show_devname() to struct dentry *
vfs: switch ->show_stats to struct dentry *
switch security_path_chmod() to struct path *
vfs: prefer ->dentry->d_sb to ->mnt->mnt_sb
vfs: trim includes a bit
switch mnt_namespace ->root to struct mount
vfs: take /proc/*/mounts and friends to fs/proc_namespace.c
vfs: opencode mntget() mnt_set_mountpoint()
vfs: spread struct mount - remaining argument of next_mnt()
vfs: move fsnotify junk to struct mount
vfs: move mnt_devname
vfs: move mnt_list to struct mount
vfs: switch pnode.h macros to struct mount *
...
07 Jan, 2012
3 commits
-
Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
05 Jan, 2012
1 commit
04 Jan, 2012
14 commits
-
[folded fix for missing magic.h from Tetsuo Handa]
Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
vfs_create() ignores everything outside of 16bit subset of its
mode argument; switching it to umode_t is obviously equivalent
and it's the only caller of the methodSigned-off-by: Al Viro
-
vfs_mkdir() gets int, but immediately drops everything that might not
fit into umode_t and that's the only caller of ->mkdir()...Signed-off-by: Al Viro
-
Signed-off-by: Al Viro
-
it's not needed anymore; we used to, back when we had to do
mount_subtree() by hand, complete with put_mnt_ns() in it.
No more... Apparmor didn't need it since the __d_path() fix.Signed-off-by: Al Viro
-
tomoyo/realpath.c needs exactly one include - that of common.h. It pulls
everything the thing needs, without doing ridiculous garbage such as trying
to include ../../fs/internal.h. If that alone doesn't scream "layering
violation", I don't know what does; and these days it's all for nothing,
since it fortunately does not use any symbols defined in there...Signed-off-by: Al Viro
-
Commit 1e39f384bb01 ("evm: fix build problems") makes the stub version
of security_old_inode_init_security() return 0 when CONFIG_SECURITY is
not set.But that makes callers such as reiserfs_security_init() assume that
security_old_inode_init_security() has set name, value, and len
arguments properly - but security_old_inode_init_security() left them
uninitialized which then results in interesting failures.Revert security_old_inode_init_security() to the old behavior of
returning EOPNOTSUPP since both callers (reiserfs and ocfs2) handle this
just fine.[ Also fixed the S_PRIVATE(inode) case of the actual non-stub
security_old_inode_init_security() function to return EOPNOTSUPP
for the same reason, as pointed out by Mimi Zohar.It got incorrectly changed to match the new function in commit
fb88c2b6cbb1: "evm: fix security/security_old_init_security return
code". - Linus ]Reported-by: Jorge Bastos
Acked-by: James Morris
Acked-by: Mimi Zohar
Signed-off-by: Jan Kara
Signed-off-by: Linus Torvalds
24 Dec, 2011
1 commit
-
Conflicts:
net/bluetooth/l2cap_core.cJust two overlapping changes, one added an initialization of
a local variable, and another change added a new local variable.Signed-off-by: David S. Miller
21 Dec, 2011
1 commit
-
Fix the following bug in sel_netport_insert() where rcu_dereference() should
be rcu_dereference_protected() as sel_netport_lock is held.===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
security/selinux/netport.c:127 invoked rcu_dereference_check() without protection!other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
1 lock held by ossec-rootcheck/3323:
#0: (sel_netport_lock){+.....}, at: [] sel_netport_sid+0xbb/0x226stack backtrace:
Pid: 3323, comm: ossec-rootcheck Not tainted 3.1.0-rc8-fsdevel+ #1095
Call Trace:
[] lockdep_rcu_dereference+0xa7/0xb0
[] sel_netport_sid+0x1b7/0x226
[] ? sel_netport_avc_callback+0xbc/0xbc
[] selinux_socket_bind+0x115/0x230
[] ? might_fault+0x4e/0x9e
[] ? might_fault+0x97/0x9e
[] security_socket_bind+0x11/0x13
[] sys_bind+0x56/0x95
[] ? sysret_check+0x27/0x62
[] ? trace_hardirqs_on_caller+0x11e/0x155
[] ? audit_syscall_entry+0x17b/0x1ae
[] ? trace_hardirqs_on_thunk+0x3a/0x3f
[] system_call_fastpath+0x16/0x1bSigned-off-by: David Howells
Acked-by: Paul Moore
Acked-by: Eric Dumazet
Cc: stable@kernel.org
Signed-off-by: James Morris
20 Dec, 2011
2 commits
-
There is a small chance of racing during tfm allocation.
This patch fixes it.Signed-off-by: Dmitry Kasatkin
Acked-by: Mimi Zohar
Signed-off-by: James Morris -
On multi-core systems, setting of the key before every caclculation,
causes invalid HMAC calculation for other tfm users, because internal
state (ipad, opad) can be invalid before set key call returns.
It needs to be set only once during initialization.Signed-off-by: Dmitry Kasatkin
Acked-by: Mimi Zohar
Signed-off-by: James Morris
09 Dec, 2011
1 commit
-
Current tomoyo_realpath_from_path() implementation returns strange pathname
when calculating pathname of a file which belongs to lazy unmounted tree.
Use local pathname rather than strange absolute pathname in that case.Also, this patch fixes a regression by commit 02125a82 "fix apparmor
dereferencing potentially freed dentry, sanitize __d_path() API".Signed-off-by: Tetsuo Handa
Acked-by: Al Viro
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds
07 Dec, 2011
2 commits
-
__d_path() API is asking for trouble and in case of apparmor d_namespace_path()
getting just that. The root cause is that when __d_path() misses the root
it had been told to look for, it stores the location of the most remote ancestor
in *root. Without grabbing references. Sure, at the moment of call it had
been pinned down by what we have in *path. And if we raced with umount -l, we
could have very well stopped at vfsmount/dentry that got freed as soon as
prepend_path() dropped vfsmount_lock.It is safe to compare these pointers with pre-existing (and known to be still
alive) vfsmount and dentry, as long as all we are asking is "is it the same
address?". Dereferencing is not safe and apparmor ended up stepping into
that. d_namespace_path() really wants to examine the place where we stopped,
even if it's not connected to our namespace. As the result, it looked
at ->d_sb->s_magic of a dentry that might've been already freed by that point.
All other callers had been careful enough to avoid that, but it's really
a bad interface - it invites that kind of trouble.The fix is fairly straightforward, even though it's bigger than I'd like:
* prepend_path() root argument becomes const.
* __d_path() is never called with NULL/NULL root. It was a kludge
to start with. Instead, we have an explicit function - d_absolute_root().
Same as __d_path(), except that it doesn't get root passed and stops where
it stops. apparmor and tomoyo are using it.
* __d_path() returns NULL on path outside of root. The main
caller is show_mountinfo() and that's precisely what we pass root for - to
skip those outside chroot jail. Those who don't want that can (and do)
use d_path().
* __d_path() root argument becomes const. Everyone agrees, I hope.
* apparmor does *NOT* try to use __d_path() or any of its variants
when it sees that path->mnt is an internal vfsmount. In that case it's
definitely not mounted anywhere and dentry_path() is exactly what we want
there. Handling of sysctl()-triggered weirdness is moved to that place.
* if apparmor is asked to do pathname relative to chroot jail
and __d_path() tells it we it's not in that jail, the sucker just calls
d_absolute_path() instead. That's the other remaining caller of __d_path(),
BTW.
* seq_path_root() does _NOT_ return -ENAMETOOLONG (it's stupid anyway -
the normal seq_file logics will take care of growing the buffer and redoing
the call of ->show() just fine). However, if it gets path not reachable
from root, it returns SEQ_SKIP. The only caller adjusted (i.e. stopped
ignoring the return value as it used to do).Reviewed-by: John Johansen
ACKed-by: John Johansen
Signed-off-by: Al Viro
Cc: stable@vger.kernel.org -
The ultimate goal is to get the sock_diag module, that works in
family+protocol terms. Currently this is suitable to do on the
inet_diag basis, so rename parts of the code. It will be moved
to sock_diag.c later.Signed-off-by: Pavel Emelyanov
Signed-off-by: David S. Miller
04 Dec, 2011
1 commit
-
While parsing through IPv6 extension headers, fragment headers are
skipped making them invisible to the caller. This reports the
fragment offset of the last header in order to make it possible to
determine whether the packet is fragmented and, if so whether it is
a first or last fragment.Signed-off-by: Jesse Gross
23 Nov, 2011
1 commit
-
C assignment can handle struct in6_addr copying.
Signed-off-by: Alexey Dobriyan
Signed-off-by: David S. Miller
18 Nov, 2011
2 commits
-
…git/zohar/linux-integrity into for-linus
17 Nov, 2011
2 commits
-
Encrypted keys are encrypted/decrypted using either a trusted or
user-defined key type, which is referred to as the 'master' key.
The master key may be of type trusted iff the trusted key is
builtin or both the trusted key and encrypted keys are built as
modules. This patch resolves the build dependency problem.- Use "masterkey-$(CONFIG_TRUSTED_KEYS)-$(CONFIG_ENCRYPTED_KEYS)" construct
to encapsulate the above logic. (Suggested by Dimtry Kasatkin.)
- Fixing the encrypted-keys Makefile, results in a module name change
from encrypted.ko to encrypted-keys.ko.
- Add module dependency for request_trusted_key() definitionSigned-off-by: Mimi Zohar
-
Fix request_master_key() error return code.
Signed-off-by: Mimi Zohar
16 Nov, 2011
1 commit
-
Fix a NULL pointer deref in the user-defined key type whereby updating a
negative key into a fully instantiated key will cause an oops to occur
when the code attempts to free the non-existent old payload.This results in an oops that looks something like the following:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
IP: [] __call_rcu+0x11/0x13e
PGD 3391d067 PUD 3894a067 PMD 0
Oops: 0002 [#1] SMP
CPU 1
Pid: 4354, comm: keyctl Not tainted 3.1.0-fsdevel+ #1140 /DG965RY
RIP: 0010:[] [] __call_rcu+0x11/0x13e
RSP: 0018:ffff88003d591df8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000006e
RDX: ffffffff8161d0c0 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff88003d591e18 R08: 0000000000000000 R09: ffffffff8152fa6c
R10: 0000000000000000 R11: 0000000000000300 R12: ffff88003b8f9538
R13: ffffffff8161d0c0 R14: ffff88003b8f9d50 R15: ffff88003c69f908
FS: 00007f97eb18c720(0000) GS:ffff88003bd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 000000003d47a000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process keyctl (pid: 4354, threadinfo ffff88003d590000, task ffff88003c78a040)
Stack:
ffff88003e0ffde0 ffff88003b8f9538 0000000000000001 ffff88003b8f9d50
ffff88003d591e28 ffffffff810860f0 ffff88003d591e68 ffffffff8117bfea
ffff88003d591e68 ffffffff00000000 ffff88003e0ffde1 ffff88003e0ffde0
Call Trace:
[] call_rcu_sched+0x10/0x12
[] user_update+0x8d/0xa2
[] key_create_or_update+0x236/0x270
[] sys_add_key+0x123/0x17e
[] system_call_fastpath+0x16/0x1bSigned-off-by: David Howells
Acked-by: Jeff Layton
Acked-by: Neil Horman
Acked-by: Steve Dickson
Acked-by: James Morris
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds
12 Nov, 2011
1 commit
-
Commit 272cd7a8c67dd40a31ecff76a503bbb84707f757 introduced
a change to the way rule lists are handled and reported in
the smackfs filesystem. One of the issues addressed had to
do with the termination of read requests on /smack/load.
This change introduced a error in /smack/cipso, which shares
some of the same list processing code.This patch updates all the file access list handling in
smackfs to use the code introduced for /smack/load.Signed-off-by: Casey Schaufler
07 Nov, 2011
1 commit
-
* 'modsplit-Oct31_2011' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux: (230 commits)
Revert "tracing: Include module.h in define_trace.h"
irq: don't put module.h into irq.h for tracking irqgen modules.
bluetooth: macroize two small inlines to avoid module.h
ip_vs.h: fix implicit use of module_get/module_put from module.h
nf_conntrack.h: fix up fallout from implicit moduleparam.h presence
include: replace linux/module.h with "struct module" wherever possible
include: convert various register fcns to macros to avoid include chaining
crypto.h: remove unused crypto_tfm_alg_modname() inline
uwb.h: fix implicit use of asm/page.h for PAGE_SIZE
pm_runtime.h: explicitly requires notifier.h
linux/dmaengine.h: fix implicit use of bitmap.h and asm/page.h
miscdevice.h: fix up implicit use of lists and types
stop_machine.h: fix implicit use of smp.h for smp_processor_id
of: fix implicit use of errno.h in include/linux/of.h
of_platform.h: delete needless include
acpi: remove module.h include from platform/aclinux.h
miscdevice.h: delete unnecessary inclusion of module.h
device_cgroup.h: delete needless include
net: sch_generic remove redundant use of
net: inet_timewait_sock doesnt need
...Fix up trivial conflicts (other header files, and removal of the ab3550 mfd driver) in
- drivers/media/dvb/frontends/dibx000_common.c
- drivers/media/video/{mt9m111.c,ov6650.c}
- drivers/mfd/ab3550-core.c
- include/linux/dmaengine.h
03 Nov, 2011
2 commits
-
* 'for-linus' of git://git.selinuxproject.org/~jmorris/linux-security:
TOMOYO: Fix interactive judgment functionality. -
* 'for-linus' of git://github.com/richardweinberger/linux: (90 commits)
um: fix ubd cow size
um: Fix kmalloc argument order in um/vdso/vma.c
um: switch to use of drivers/Kconfig
UserModeLinux-HOWTO.txt: fix a typo
UserModeLinux-HOWTO.txt: remove ^H characters
um: we need sys/user.h only on i386
um: merge delay_{32,64}.c
um: distribute exports to where exported stuff is defined
um: kill system-um.h
um: generic ftrace.h will do...
um: segment.h is x86-only and needed only there
um: asm/pda.h is not needed anymore
um: hw_irq.h can go generic as well
um: switch to generic-y
um: clean Kconfig up a bit
um: a couple of missing dependencies...
um: kill useless argument of free_chan() and free_one_chan()
um: unify ptrace_user.h
um: unify KSTK_...
um: fix gcov build breakage
...
02 Nov, 2011
1 commit
-
Signed-off-by: Al Viro
Signed-off-by: Richard Weinberger
01 Nov, 2011
2 commits
-
There is no functional change.
Signed-off-by: Andy Shevchenko
Cc: Mimi Zohar
Cc: James Morris
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The basic idea behind cross memory attach is to allow MPI programs doing
intra-node communication to do a single copy of the message rather than a
double copy of the message via shared memory.The following patch attempts to achieve this by allowing a destination
process, given an address and size from a source process, to copy memory
directly from the source process into its own address space via a system
call. There is also a symmetrical ability to copy from the current
process's address space into a destination process's address space.- Use of /proc/pid/mem has been considered, but there are issues with
using it:
- Does not allow for specifying iovecs for both src and dest, assuming
preadv or pwritev was implemented either the area read from or
written to would need to be contiguous.
- Currently mem_read allows only processes who are currently
ptrace'ing the target and are still able to ptrace the target to read
from the target. This check could possibly be moved to the open call,
but its not clear exactly what race this restriction is stopping
(reason appears to have been lost)
- Having to send the fd of /proc/self/mem via SCM_RIGHTS on unix
domain socket is a bit ugly from a userspace point of view,
especially when you may have hundreds if not (eventually) thousands
of processes that all need to do this with each other
- Doesn't allow for some future use of the interface we would like to
consider adding in the future (see below)
- Interestingly reading from /proc/pid/mem currently actually
involves two copies! (But this could be fixed pretty easily)As mentioned previously use of vmsplice instead was considered, but has
problems. Since you need the reader and writer working co-operatively if
the pipe is not drained then you block. Which requires some wrapping to
do non blocking on the send side or polling on the receive. In all to all
communication it requires ordering otherwise you can deadlock. And in the
example of many MPI tasks writing to one MPI task vmsplice serialises the
copying.There are some cases of MPI collectives where even a single copy interface
does not get us the performance gain we could. For example in an
MPI_Reduce rather than copy the data from the source we would like to
instead use it directly in a mathops (say the reduce is doing a sum) as
this would save us doing a copy. We don't need to keep a copy of the data
from the source. I haven't implemented this, but I think this interface
could in the future do all this through the use of the flags - eg could
specify the math operation and type and the kernel rather than just
copying the data would apply the specified operation between the source
and destination and store it in the destination.Although we don't have a "second user" of the interface (though I've had
some nibbles from people who may be interested in using it for intra
process messaging which is not MPI). This interface is something which
hardware vendors are already doing for their custom drivers to implement
fast local communication. And so in addition to this being useful for
OpenMPI it would mean the driver maintainers don't have to fix things up
when the mm changes.There was some discussion about how much faster a true zero copy would
go. Here's a link back to the email with some testing I did on that:http://marc.info/?l=linux-mm&m=130105930902915&w=2
There is a basic man page for the proposed interface here:
http://ozlabs.org/~cyeoh/cma/process_vm_readv.txt
This has been implemented for x86 and powerpc, other architecture should
mainly (I think) just need to add syscall numbers for the process_vm_readv
and process_vm_writev. There are 32 bit compatibility versions for
64-bit kernels.For arch maintainers there are some simple tests to be able to quickly
verify that the syscalls are working correctly here:http://ozlabs.org/~cyeoh/cma/cma-test-20110718.tgz
Signed-off-by: Chris Yeoh
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Thomas Gleixner
Cc: Arnd Bergmann
Cc: Paul Mackerras
Cc: Benjamin Herrenschmidt
Cc: David Howells
Cc: James Morris
Cc:
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
