- 18 Mar, 2014 1 commit
-
-
Ingo Molnar authored
Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Pull perf/core improvements and fixes from Arnaldo: User visible: * Add several futex 'perf bench' microbenchmarks (Davidlohr Bueso) * Speed up thread map generation (Don Zickus) * Fix synthesizing mmaps for threads (Don Zickus) * Fix invalid output on event group stdio report (Namhyung Kim) * Introduce 'perf kvm --list-cmds' command line option for use by scripts (Ramkumar Ramachandra) Documentation: * Clarify load-latency information in the 'perf mem' docs (Andi Kleen) * Clarify x86 register naming in 'perf probe' docs (Andi Kleen) Refactorings: * hists browser refactorings to reuse code accross UIs (Namhyung Kim) Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
- 14 Mar, 2014 17 commits
-
-
Jiri Olsa authored
Forcing the code to always search thread by pid/tid pair. The PID value will be needed in future to determine the process thread leader for map groups sharing. Signed-off-by:
Jiri Olsa <jolsa@redhat.com> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: David Ahern <dsahern@gmail.com> Cc: Don Zickus <dzickus@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1394805606-25883-3-git-send-email-jolsa@redhat.comSigned-off-by:
-
Don Zickus authored
When trying to capture perf data on a system running spejbb2013, perf hung for about 15 minutes. This is because it took that long to gather about 10,000 thread maps and process them. I don't think a user wants to wait that long. Instead, recognize that thread maps are roughly equivalent to pid maps and just quickly copy those instead. To do this, I synthesize 'fork' events, this eventually calls thread__fork() and copies the maps over. The overhead goes from 15 minutes down to about a few seconds. -- V2: based on Jiri's comments, moved malloc up a level and made sure the memory was freed Signed-off-by:Don Zickus <dzickus@redhat.com> Acked-by:
-
Ramkumar Ramachandra authored
Introduce $ perf kvm --list-cmds to dump a raw list of commands for use by the completion script. In order to do this, introduce parse_options_subcommand() for handling subcommands as a special case in the parse-options machinery. Signed-off-by:
Ramkumar Ramachandra <artagnon@gmail.com> Acked-by:
David Ahern <dsahern@gmail.com> Acked-by:
-
Namhyung Kim authored
Those functions need evsel to investigate event group and it's passed via hpp->ptr. However as it can be missed easily so it's better to pass it via an argument IMHO. Signed-off-by:
Namhyung Kim <namhyung@kernel.org> Cc: Andi Kleen <andi@firstfloor.org> Cc: David Ahern <dsahern@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung.kim@lge.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1394437440-11609-2-git-send-email-namhyung@kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
Its one level up thread__find_addr_location, where it will look in different domains for a sample: user, kernel, hypervisor, etc. Will soon be used by a patchkit by Andi Kleen. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-so6nxkh7xj48bc5kq4jpj991@git.kernel.orgSigned-off-by:
-
Don Zickus authored
When printing the raw dump of a data file, the header.misc is printed as a decimal. Unfortunately, that field is a bit mask, so it is hard to interpret as a decimal. Print in hex, so the user can easily see what bits are set and more importantly what type of info it is conveying. V2: add 0x in front per Jiri Olsa Signed-off-by:
-
Namhyung Kim authored
The __hpp__color_fmt used in the TUI code can be replace by the generic code with small change in print_fn callback. And it also needs to move callback function to the generic __hpp__fmt(). No functional changes intended. Signed-off-by:
-
Namhyung Kim authored
Instead of the pointer to buffer and its size so that it can also get private argument passed along with hpp. This is a preparation of further change. Signed-off-by:
-
Namhyung Kim authored
The __hpp__color_fmt used in the gtk code can be replace by the generic code with small change in print_fn callback. This is a preparation to upcoming changes and no functional changes intended. Signed-off-by:
Pekka Enberg <penberg@kernel.org> Cc: Andi Kleen <andi@firstfloor.org> Cc: David Ahern <dsahern@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung.kim@lge.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Pekka Enberg <penberg@kernel.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1393809254-4480-3-git-send-email-namhyung@kernel.orgSigned-off-by:
-
Namhyung Kim authored
When some of group member has 0 overhead, it printed previous percentage instead of 0.00%. It's because passing integer 0 as a percent rather than double 0.0 so the remaining bits came from garbage. The TUI and GTK don't have this problem since they pass 0.0. Before: # Samples: 845 of event 'anon group { cycles, cache-references, cache-misses }' # Event count (approx.): 174775051 # # Overhead Samples # ........................ .................................... # 20.32% 8.58% 73.51% 45 30 138 6.87% 6.87% 6.87% 21 0 0 5.29% 0.31% 0.31% 10 1 0 1.89% 1.89% 1.89% 6 0 0 1.76% 1.76% 1.76% 2 0 0 After: # Overhead Samples # ........................ .................................... # 20.32% 8.58% 73.51% 45 30 138 6.87% 0.00% 0.00% 21 0 0 5.29% 0.31% 0.00% 10 1 0 1.89% 0.00% 0.00% 6 0 0 1.76% 0.00% 0.00% 2 0 0 Signed-off-by: -
Don Zickus authored
Currently if a process creates a bunch of threads using pthread_create and then perf is run in system_wide mode, the mmaps for those threads are not captured with a synthesized mmap event. The reason is those threads are not visible when walking the /proc/ directory looking for /proc/<pid>/maps files. Instead they are discovered using the /proc/<pid>/tasks file (which the synthesized comm event uses). This causes problems when a program is trying to map a data address to a tid. Because the tid has no maps, the event is dropped. Changing the program to look up using the pid instead of the tid, finds the correct maps but creates ugly hacks in the program to carry the correct tid around. Fix this by moving the walking of the /proc/<pid>/tasks up a level (out of the comm function) based on Arnaldo's suggestion. Tweaked things a bit to special case the 'full' bit and 'guest' check. Signed-off-by:
-
Andi Kleen authored
Clarify how to specify x86 registers in perf probe. I recently ran into this problem and had to figure it out from the source. Signed-off-by:
Andi Kleen <ak@linux.intel.com> Acked-by:
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Link: http://lkml.kernel.org/r/1393596135-4227-3-git-send-email-andi@firstfloor.orgSigned-off-by:
-
Andi Kleen authored
Clarify in the documentation that 'perf mem report' reports use-latency, not load/store-latency on Intel systems. This often causes confusion with users. Signed-off-by:
-
Davidlohr Bueso authored
Block a bunch of threads on a futex and requeue them on another, N at a time. This program is particularly useful to measure the latency of nthread requeues without waking up any tasks -- thus mimicking a regular futex_wait. An example run: $ perf bench futex requeue -r 100 -t 64 Run summary [PID 151011]: Requeuing 64 threads (from 0x7d15c4 to 0x7d15c8), 1 at a time. [Run 1]: Requeued 64 of 64 threads in 0.0400 ms [Run 2]: Requeued 64 of 64 threads in 0.0390 ms [Run 3]: Requeued 64 of 64 threads in 0.0400 ms ... [Run 100]: Requeued 64 of 64 threads in 0.0390 ms Requeued 64 of 64 threads in 0.0399 ms (+-0.37%) Signed-off-by:
Davidlohr Bueso <davidlohr@hp.com> Acked-by:
Darren Hart <dvhart@linux.intel.com> Cc: Aswin Chandramouleeswaran <aswin@hp.com> Cc: Darren Hart <dvhart@linux.intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jason Low <jason.low2@hp.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Scott J Norton <scott.norton@hp.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Waiman Long <Waiman.Long@hp.com> Link: http://lkml.kernel.org/r/1387081917-9102-4-git-send-email-davidlohr@hp.comSigned-off-by:
-
Davidlohr Bueso authored
Block a bunch of threads on a futex and wake them up, N at a time. This program is particularly useful to measure the latency of nthread wakeups in non-error situations: all waiters are queued and all wake calls wakeup one or more tasks. An example run: $ perf bench futex wake -t 512 -r 100 Run summary [PID 27823]: blocking on 512 threads (at futex 0x7e10d4), waking up 1 at a time. [Run 1]: Wokeup 512 of 512 threads in 6.0080 ms [Run 2]: Wokeup 512 of 512 threads in 5.2280 ms [Run 3]: Wokeup 512 of 512 threads in 4.8300 ms ... [Run 100]: Wokeup 512 of 512 threads in 5.0100 ms Wokeup 512 of 512 threads in 5.0109 ms (+-2.25%) Signed-off-by:
-
Davidlohr Bueso authored
Introduce futexes to perf-bench and add a program that stresses and measures the kernel's implementation of the hash table. This is a multi-threaded program that simply measures the amount of failed futex wait calls - we only want to deal with the hashing overhead, so a negative return of futex_wait_setup() is enough to do the trick. An example run: $ perf bench futex hash -t 32 Run summary [PID 10989]: 32 threads, each operating on 1024 [private] futexes for 10 secs. [thread 0] futexes: 0x19d9b10 ... 0x19dab0c [ 418713 ops/sec ] [thread 1] futexes: 0x19daca0 ... 0x19dbc9c [ 469913 ops/sec ] [thread 2] futexes: 0x19dbe30 ... 0x19dce2c [ 479744 ops/sec ] ... [thread 31] futexes: 0x19fbb80 ... 0x19fcb7c [ 464179 ops/sec ] Averaged 454310 operations/sec (+- 0.84%), total secs = 10 Signed-off-by:
-
Stephane Eranian authored
This patch fixes a bug with the SNB/IVB/HSW uncore mmeory controller support. The PCI Ids tables for the memory controller were missing end markers. That could cause random crashes on boot during or after PCI device registration. Signed-off-by:
Stephane Erainan <eranian@google.com> Cc: peterz@infradead.org Cc: zheng.z.yan@intel.com Cc: bp@alien8.de Cc: ak@linux.intel.com Link: http://lkml.kernel.org/r/20140313120436.GA14236@quadSigned-off-by:
-
- 12 Mar, 2014 1 commit
-
-
Stephane Eranian authored
This patch fixes a compilation problem (unused variable) with the new SNB/IVB/HSW uncore IMC code. [ In -v2 we simplify the fix as suggested by Peter Zjilstra. ] Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20140311235329.GA28624@quadSigned-off-by:
-
- 11 Mar, 2014 16 commits
-
-
Jiri Olsa authored
User space callchains and user space stack dump were disabled for function trace event. Mailing list discussions: http://marc.info/?t=139302086500001&r=1&w=2 http://marc.info/?t=139301437300003&r=1&w=2 Catching up with perf and disabling user space callchains and DWARF unwind (uses user stack dump) for function trace event. Adding following warnings when callchains are used for function trace event: # perf record -g -e ftrace:function ... Disabling user space callchains for function trace event. ... # ./perf record --call-graph=dwarf -e ftrace:function ... Cannot use DWARF unwind for function trace event, falling back to framepointers. Disabling user space callchains for function trace event. ... Signed-off-by:
-
Jiri Olsa authored
Recent issues with user space callchains processing within page fault handler tracing showed as Peter said 'there's just too much fail surface'. The user space stack dump is just another source of the this issue. Related list discussions: http://marc.info/?t=139302086500001&r=1&w=2 http://marc.info/?t=139301437300003&r=1&w=2Suggested-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Jiri Olsa authored
Recent issues with user space callchains processing within page fault handler tracing showed as Peter said 'there's just too much fail surface'. Related list discussions: http://marc.info/?t=139302086500001&r=1&w=2 http://marc.info/?t=139301437300003&r=1&w=2Suggested-by:
-
Dongsheng Yang authored
Commit: 411cf180 perf/x86/uncore: fix initialization of cpumask introduced the function uncore_cpumask_init(), which is only called in __init intel_uncore_init(). But it is not marked with __init, which produces the following warning: WARNING: vmlinux.o(.text+0x2464a): Section mismatch in reference from the function uncore_cpumask_init() to the function .init.text:uncore_cpu_setup() The function uncore_cpumask_init() references the function __init uncore_cpu_setup(). This is often because uncore_cpumask_init lacks a __init annotation or the annotation of uncore_cpu_setup is wrong. This patch marks uncore_cpumask_init() with __init. Signed-off-by:
Dongsheng Yang <yangds.fnst@cn.fujitsu.com> Acked-by:
-
Ingo Molnar authored
Merge the latest fixes. Signed-off-by: -
Ingo Molnar authored
Merge tag 'perf-urgent-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent Pull perf/urgent fixes from Arnaldo Carvalho de Melo: * Fix build of 'trace' in some systems due to using some architecture-specific signal numbers (Ben Hutchings) * Stop resolving when finding a map in in ip__resolve_ams, this way at least the DSO will be resolved when a symbol isn't (Don Zickus) * Fix crash in elf_section_by_name when not checking if some section string index is valid (Jiri Olsa) Signed-off-by:
-
Linus Torvalds authored
Merge misc fixes from Andrew Morton: "Nine fixes" * emailed patches from Andrew Morton akpm@linux-foundation.org>: cris: convert ffs from an object-like macro to a function-like macro hfsplus: add HFSX subfolder count support tools/testing/selftests/ipc/msgque.c: handle msgget failure return correctly MAINTAINERS: blackfin: add git repository revert "kallsyms: fix absolute addresses for kASLR" mm/Kconfig: fix URL for zsmalloc benchmark fs/proc/base.c: fix GPF in /proc/$PID/map_files mm/compaction: break out of loop on !PageBuddy in isolate_freepages_block mm: fix GFP_THISNODE callers and clarify
-
Geert Uytterhoeven authored
This avoids bad interactions with code using identifiers called "ffs": drivers/usb/gadget/f_fs.c: In function 'ffsmod_init': drivers/usb/gadget/f_fs.c:2693:494: error: 'ffsusb_func' undeclared (first use in this function) drivers/usb/gadget/f_fs.c:2693:494: note: each undeclared identifier is reported only once for each function it appears in drivers/usb/gadget/f_fs.c: In function 'ffsmod_exit': drivers/usb/gadget/f_fs.c:2693:677: error: 'ffsusb_func' undeclared (first use in this function) drivers/usb/gadget/f_fs.c: At top level: drivers/usb/gadget/f_fs.c:2693:35: warning: 'kernel_ffsusb_func' defined but not used [-Wunused-variable] drivers/usb/gadget/f_fs.c: In function 'ffsmod_init': drivers/usb/gadget/f_fs.c:2693:15: warning: control reaches end of non-void function [-Wreturn-type] See http://kisskb.ellerman.id.au/kisskb/buildresult/10715817/Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Cc: Mikael Starvik <starvik@axis.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Sergei Antonov authored
Adds support for HFSX 'HasFolderCount' flag and a corresponding 'folderCount' field in folder records. (For reference see HFS_FOLDERCOUNT and kHFSHasFolderCountBit/kHFSHasFolderCountMask in Apple's source code.) Ignoring subfolder count leads to fs errors found by Mac: ... Checking catalog hierarchy. HasFolderCount flag needs to be set (id = 105) (It should be 0x10 instead of 0) Incorrect folder count in a directory (id = 2) (It should be 7 instead of 6) ... Steps to reproduce: Format with "newfs_hfs -s /dev/diskXXX". Mount in Linux. Create a new directory in root. Unmount. Run "fsck_hfs /dev/diskXXX". The patch handles directory creation, deletion, and rename. Signed-off-by:
Sergei Antonov <saproj@gmail.com> Reviewed-by:
Vyacheslav Dubeyko <slava@dubeyko.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@infradead.org> Signed-off-by:
-
Colin Ian King authored
A failed msgget causes the test to return an uninitialised value in ret. Assign ret to -errno on error exit. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
-
Michael Opdenacker authored
Add the git repository currently in use for blackfin architecture development. This information was obtained from Steven Miao. Signed-off-by:
Michael Opdenacker <michael.opdenacker@free-electrons.com> Cc: Steven Miao <realmz6@gmail.com> Signed-off-by:
-
Andrew Morton authored
Revert the recently applied 0f55159d ("kallsyms: fix absolute addresses for kASLR"). Kees said : This got NAKed, please don't apply -- this patch works for x86 and : ARM, but may cause problems for others: : : https://lkml.org/lkml/2014/2/24/718 It appears that Kees will be fixing all this up for 3.15. Cc: Andy Honig <ahonig@google.com> Cc: Kees Cook <keescook@chromium.org> Cc: Michal Marek <mmarek@suse.cz> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Ben Hutchings authored
The help text for CONFIG_PGTABLE_MAPPING has an incorrect URL. While we're at it, remove the unnecessary footnote notation. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Acked-by:
Minchan Kim <minchan@kernel.org> Signed-off-by:
-
Artem Fetishev authored
The expected logic of proc_map_files_get_link() is either to return 0 and initialize 'path' or return an error and leave 'path' uninitialized. By the time dname_to_vma_addr() returns 0 the corresponding vma may have already be gone. In this case the path is not initialized but the return value is still 0. This results in 'general protection fault' inside d_path(). Steps to reproduce: CONFIG_CHECKPOINT_RESTORE=y fd = open(...); while (1) { mmap(fd, ...); munmap(fd, ...); } ls -la /proc/$PID/map_files Addresses https://bugzilla.kernel.org/show_bug.cgi?id=68991Signed-off-by:Artem Fetishev <artem_fetishev@epam.com> Signed-off-by:
Aleksandr Terekhov <aleksandr_terekhov@epam.com> Reported-by: <wiebittewas@gmail.com> Acked-by:
Pavel Emelyanov <xemul@parallels.com> Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Reviewed-by:
"Eric W. Biederman" <ebiederm@xmission.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Laura Abbott authored
We received several reports of bad page state when freeing CMA pages previously allocated with alloc_contig_range: BUG: Bad page state in process Binder_A pfn:63202 page:d21130b0 count:0 mapcount:1 mapping: (null) index:0x7dfbf page flags: 0x40080068(uptodate|lru|active|swapbacked) Based on the page state, it looks like the page was still in use. The page flags do not make sense for the use case though. Further debugging showed that despite alloc_contig_range returning success, at least one page in the range still remained in the buddy allocator. There is an issue with isolate_freepages_block. In strict mode (which CMA uses), if any pages in the range cannot be isolated, isolate_freepages_block should return failure 0. The current check keeps track of the total number of isolated pages and compares against the size of the range: if (strict && nr_strict_required > total_isolated) total_isolated = 0; After taking the zone lock, if one of the pages in the range is not in the buddy allocator, we continue through the loop and do not increment total_isolated. If in the last iteration of the loop we isolate more than one page (e.g. last page needed is a higher order page), the check for total_isolated may pass and we fail to detect that a page was skipped. The fix is to bail out if the loop immediately if we are in strict mode. There's no benfit to continuing anyway since we need all pages to be isolated. Additionally, drop the error checking based on nr_strict_required and just check the pfn ranges. This matches with what isolate_freepages_range does. Signed-off-by:Laura Abbott <lauraa@codeaurora.org> Acked-by:
Vlastimil Babka <vbabka@suse.cz> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Acked-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by:
Michal Nazarewicz <mina86@mina86.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Johannes Weiner authored
GFP_THISNODE is for callers that implement their own clever fallback to remote nodes. It restricts the allocation to the specified node and does not invoke reclaim, assuming that the caller will take care of it when the fallback fails, e.g. through a subsequent allocation request without GFP_THISNODE set. However, many current GFP_THISNODE users only want the node exclusive aspect of the flag, without actually implementing their own fallback or triggering reclaim if necessary. This results in things like page migration failing prematurely even when there is easily reclaimable memory available, unless kswapd happens to be running already or a concurrent allocation attempt triggers the necessary reclaim. Convert all callsites that don't implement their own fallback strategy to __GFP_THISNODE. This restricts the allocation a single node too, but at the same time allows the allocator to enter the slowpath, wake kswapd, and invoke direct reclaim if necessary, to make the allocation happen when memory is full. Signed-off-by:
Johannes Weiner <hannes@cmpxchg.org> Acked-by:
Rik van Riel <riel@redhat.com> Cc: Jan Stancek <jstancek@redhat.com> Cc: Mel Gorman <mgorman@suse.de> Signed-off-by:
-
- 10 Mar, 2014 5 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull vfs fixes from Al Viro. Clean up file table accesses (get rid of fget_light() in favor of the fdget() interface), add proper file position locking. * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: get rid of fget_light() sockfd_lookup_light(): switch to fdget^W^Waway from fget_light vfs: atomic f_pos accesses as per POSIX ocfs2 syncs the wrong range...
-
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libataLinus Torvalds authored
Pull libata fixlet from Tejun Heo: "I merged the two blaclist entries into 'Crucial_CT???M500SSD*'" * 'for-3.14-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata: libata: use wider match for blacklisting Crucial M500
-
Al Viro authored
instead of returning the flags by reference, we can just have the low-level primitive return those in lower bits of unsigned long, with struct file * derived from the rest. Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by: -
Linus Torvalds authored
Our write() system call has always been atomic in the sense that you get the expected thread-safe contiguous write, but we haven't actually guaranteed that concurrent writes are serialized wrt f_pos accesses, so threads (or processes) that share a file descriptor and use "write()" concurrently would quite likely overwrite each others data. This violates POSIX.1-2008/SUSv4 Section XSI 2.9.7 that says: "2.9.7 Thread Interactions with Regular File Operations All of the following functions shall be atomic with respect to each other in the effects specified in POSIX.1-2008 when they operate on regular files or symbolic links: [...]" and one of the effects is the file position update. This unprotected file position behavior is not new behavior, and nobody has ever cared. Until now. Yongzhi Pan reported unexpected behavior to Michael Kerrisk that was due to this. This resolves the issue with a f_pos-specific lock that is taken by read/write/lseek on file descriptors that may be shared across threads or processes. Reported-by:
Yongzhi Pan <panyongzhi@gmail.com> Reported-by:
Michael Kerrisk <mtk.manpages@gmail.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
