summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-04-12xtensa: Remove signal translation and exec_domainRichard Weinberger2-11/+2
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12xtensa: Autogenerate offsets in struct thread_infoRichard Weinberger2-11/+8
Maintaining offsets by hand is no fun. Reported-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12x86: Remove signal translation and exec_domainRichard Weinberger2-18/+1
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12unicore32: Remove signal translation and exec_domainRichard Weinberger3-11/+0
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12um: Remove signal translation and exec_domainRichard Weinberger2-9/+0
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12tile: Remove signal translation and exec_domainRichard Weinberger3-18/+2
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12sparc: Remove signal translation and exec_domainRichard Weinberger4-33/+23
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at> Acked-by: David S. Miller <davem@davemloft.net>
2015-04-12sh: Remove signal translation and exec_domainRichard Weinberger5-38/+6
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12s390: Remove signal translation and exec_domainRichard Weinberger4-27/+4
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12mn10300: Remove signal translation and exec_domainRichard Weinberger3-20/+4
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12microblaze: Remove signal translation and exec_domainRichard Weinberger2-10/+1
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12m68k: Remove signal translation and exec_domainRichard Weinberger2-14/+2
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12m32r: Remove signal translation and exec_domainRichard Weinberger2-11/+3
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12m32r: Autogenerate offsets in struct thread_infoRichard Weinberger4-13/+17
Maintaining offsets by hand is no fun. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12frv: Remove signal translation and exec_domainRichard Weinberger4-20/+5
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12blackfin: Remove exec_domain usageRichard Weinberger2-7/+1
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12blackfin: Autogenerate offsets in struct thread_infoRichard Weinberger3-9/+7
Maintaining offsets by hand is no fun. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12arm64: Remove signal translation and exec_domainRichard Weinberger3-10/+0
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12arm: Remove signal translation and exec_domainRichard Weinberger4-20/+3
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12Remove execution domain supportRichard Weinberger3-105/+1
All users of exec_domain are gone, now we can get rid of that abandoned feature. To not break existing userspace we keep a dummy /proc/execdomains file which will always contain "0-0 Linux [kernel]". Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12ia64: Remove Linux/x86 exec domain supportRichard Weinberger1-25/+0
As this series removes exec domain support we can get rid of this hack. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12arm: Remove RISC OS personalityRichard Weinberger4-106/+0
The RISC OS personality seems to be unused and untested for a long time. It is doubtful whether this personality worked ever as expected. Let's rip it out. Signed-off-by: Richard Weinberger <richard@nod.at> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-04-12Merge branch 'for-linus' of ↵Linus Torvalds4-15/+34
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull vfs and fs fixes from Al Viro: "Several AIO and OCFS2 fixes" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: ocfs2: _really_ sync the right range ocfs2_file_write_iter: keep return value and current position update in sync [regression] ocfs2: do *not* increment ->ki_pos twice ioctx_alloc(): fix vma (and file) leak on failure fix mremap() vs. ioctx_kill() race
2015-04-12Merge branch 'fixes' of ↵Linus Torvalds5-16/+18
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal Pull last minute thermal-SoC management fixes from Eduardo Valentin: "Specifics: - Minor fixes on ST and RCAR thermal drivers. - Avoid flooding kernel log when driver returns -EAGAIN. Note: I am sending this pull on Rui's behalf while he fixes issues in his Linux box" * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal: drivers: thermal: st: remove several sparse warnings thermal: constify of_device_id array thermal: Do not log an error if thermal_zone_get_temp returns -EAGAIN thermal: rcar: Fix typo in r8a73a4 SoC name
2015-04-12perf/x86/intel/pt: Clean up the control flow in pt_pmu_hw_init()Ingo Molnar1-23/+30
Dan Carpenter pointed out that the control flow in pt_pmu_hw_init() is a bit messy: for example the kfree(de_attrs) is entirely superfluous. Another problem is the inconsistent mixing of label based and direct return error handling. Add modern, label based error handling instead and clean up the code a bit as well. Note that we'll still do a kfree(NULL) in the normal case - this does not matter as this is an init path and kfree() returns early if it sees a NULL. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/20150409090805.GG17605@mwanda Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-04-12->aio_read and ->aio_write removedAl Viro8-54/+9
no remaining users Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12pcm: another weird API abuseAl Viro1-19/+20
readv() and writev() should _not_ ignore all but the first ->iov_len, among other things. Really weird abuse of those syscalls - it expects a vector element per channel, with identical lengths (it actually assumes them to be identical - no checking is done). readv() and writev() are really bad match for that. Unfortunately, userland API is userland API and we can't do anything about them. Converted to ->read_iter/->write_iter. Please, _please_ don't do anything of that kind when designing new interfaces. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12infinibad: weird APIs switched to ->write_iter()Al Viro2-15/+23
Things Not To Do When Writing A Driver, part 1001st: have writev() and write() on the same file doing completely different things. As in, "interpret very different sets of commands". We _can_ handle that, but it's a bloody bad idea. Don't do that in new drivers. Ever. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12kill do_sync_read/do_sync_writeAl Viro2-40/+0
all remaining instances of aio_{read,write} (all 4 of them) have explicit ->read and ->write resp.; do_sync_read/do_sync_write is never called by __vfs_read/__vfs_write anymore and no other users had been left. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12fuse: use iov_iter_get_pages() for non-splice pathAl Viro1-24/+17
store reference to iter instead of that to iovec Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12fuse: switch to ->read_iter/->write_iterAl Viro1-12/+14
we just change the calling conventions here; more work to follow. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12switch drivers/char/mem.c to ->read_iter/->write_iterAl Viro1-9/+9
Note that _these_ guys have ->read() and ->write() left in place - they are eqiuvalent to what we'd get if we replaced those with NULL, but we are talking about hot paths here. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12make new_sync_{read,write}() staticAl Viro59-153/+11
All places outside of core VFS that checked ->read and ->write for being NULL or called the methods directly are gone now, so NULL {read,write} with non-NULL {read,write}_iter will do the right thing in all cases. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12coredump: accept any write methodAl Viro1-1/+1
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12switch /dev/loop to vfs_iter_write()Al Viro1-5/+7
all writable files that might be used as backing store for /dev/loop already support ->write_iter() Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12serial2002: switch to __vfs_read/__vfs_writeAl Viro1-12/+6
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12ashmem: use __vfs_read()Al Viro1-1/+1
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12export __vfs_read()Al Viro1-8/+5
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12autofs: switch to __vfs_write()Al Viro2-2/+2
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12new helper: __vfs_write()Al Viro2-12/+17
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12Merge branch '9p-iov_iter' into for-nextAl Viro12-627/+355
2015-04-12switch hugetlbfs to ->read_iter()Al Viro1-58/+34
... and fix the case when the area we are asked to read crosses a hugepage boundary Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12coda: switch to ->read_iter/->write_iterAl Viro1-25/+15
... and request the same from the local cache - all filesystems with anything usable for that support those already. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12ncpfs: switch to ->read_iter/->write_iterAl Viro3-63/+37
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12net/9p: remove (now-)unused helpersAl Viro2-43/+1
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-12p9_client_attach(): set fid->uid correctlyAl Viro1-0/+1
it's almost always equal to current_fsuid(), but there's an exception - if the first writeback fid is opened by non-root *and* that happens before root has done any lookups in /, we end up doing attach for root. The current code leaves the resulting FID owned by root from the server POV and by non-root from the client one. Unfortunately, it means that e.g. massive dcache eviction will leave that user buggered - they'll end up redoing walks from / *and* picking that FID every time. As soon as they try to create something, the things will get nasty. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-129p: we are leaking glock.client_id in v9fs_file_getlock()Al Viro1-0/+2
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-129p: switch to ->read_iter/->write_iterAl Viro1-44/+39
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-129p: get rid of v9fs_direct_file_read()Al Viro2-51/+12
do it in ->direct_IO()... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-129p: switch p9_client_read() to passing struct iov_iter *Al Viro7-183/+108
... and make it loop Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-02 11:56:08 +0300