- 06 Jun, 2014 40 commits
-
-
Oleg Nesterov authored
It has no users and it doesn't look useful. I do not know why/when it was introduced, I can't even find any user in the git history. Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Acked-by:
Geert Uytterhoeven <geert@linux-m68k.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Richard Weinberger <richard@nod.at> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Tejun Heo <tj@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Oleg Nesterov authored
__wake_up_bit() checks waitqueue_active() and thus the caller needs mb() as wake_up_bit() documents, fix task_clear_jobctl_trapping(). Signed-off-by:
-
Matthew Dempsky authored
When tracing a process in another pid namespace, it's important for fork event messages to contain the child's pid as seen from the tracer's pid namespace, not the parent's. Otherwise, the tracer won't be able to correlate the fork event with later SIGTRAP signals it receives from the child. We still risk a race condition if a ptracer from a different pid namespace attaches after we compute the pid_t value. However, sending a bogus fork event message in this unlikely scenario is still a vast improvement over the status quo where we always send bogus fork event messages to debuggers in a different pid namespace than the forking process. Signed-off-by:
Matthew Dempsky <mdempsky@chromium.org> Acked-by:
-
Alexey Dobriyan authored
Examples introducing neccesity of RMB+WMP pair reads as A=3 READ B www rrrrrr B=4 READ A Note the opposite order of reads vs writes. But the first example without barriers reads as A=3 READ A B=4 READ B There are 4 outcomes in the first example. But if someone new to the concept tries to insert barriers like this: A=3 READ A www rrrrrr B=4 READ B he will still get all 4 possible outcomes, because "READ A" is first. All this can be utterly confusing because barrier pair seems to be superfluous. In short, fixup first example to match latter examples with barriers. Signed-off-by:Alexey Dobriyan <adobriyan@gmail.com> Cc: David Howells <dhowells@redhat.com> Signed-off-by:
-
Fabian Frederick authored
Linked article in seq_file.txt still uses create_proc_entry which was removed in commit 80e928f7 ("proc: Kill create_proc_entry()"). This patch adds information for kernel 3.10 and above Signed-off-by:
Fabian Frederick <fabf@skynet.be> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Jacob Keller authored
Update the SubmittingPatches process to include howto about the new 'Fixes:' tag to be used when a patch fixes an issue in a previous commit (found by git-bisect for example). Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Cc: Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Manuel Schölling authored
Initializations like 'char *foo = "bar"' will create two variables: a static string and a pointer (foo) to that static string. Instead 'char foo[] = "bar"' will declare a single variable and will end up in shorter assembly (according to Jeff Garzik on the KernelJanitor's TODO list). Signed-off-by:
Manuel Schölling <manuel.schoelling@gmx.de> Acked-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by:
-
Conrad Meyer authored
Add structure for parsed BPB information, struct fat_bios_param_block, and move all of the deserialization and validation logic from fat_fill_super() into fat_read_bpb(). Add a 'dos1xfloppy' mount option to infer DOS 2.x BIOS Parameter Block defaults from block device geometry for ancient floppies and floppy images, as a fall-back from the default BPB parsing logic. When fat_read_bpb() finds an invalid FAT filesystem and dos1xfloppy is set, fall back to fat_read_static_bpb(). fat_read_static_bpb() validates that the entire BPB is zero, and that the floppy has a DOS-style 8086 code bootstrapping header. Then it fills in default BPB values from media size and a table.[0] Media size is assumed to be static for archaic FAT volumes. See also: [1]. Fixes kernel.org bug #42617. [0]: https://en.wikipedia.org/wiki/File_Allocation_Table#Exceptions [1]: http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html [hirofumi@mail.parknet.co.jp: fix missed error code] Signed-off-by:
Conrad Meyer <cse.cem@gmail.com> Acked-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Fabian Frederick authored
This patch applies a suggestion by Mikulas Patocka asking to increase all pr_warn without commented ones to pr_err Signed-off-by:
-
Fabian Frederick authored
Normalize function display fx() using __func__ Signed-off-by:
-
Fabian Frederick authored
Also remove redundant level names (warning:...) Signed-off-by:
-
Fabian Frederick authored
No level printk in hptfs_error converted to pr_err (others to pr_warn or pr_info) This patch also fixes if/then/else checkpatch warnings Signed-off-by:
-
Fabian Frederick authored
err is used in ufs_new_fragments (ufs_add_fragments only callsite) not in ufs_add_fragments. Signed-off-by:
-
Christian Kujau authored
Commit a99b7069 ("hfsplus: Fix undefined __divdi3 in hfsplus_init_header_node()") introduced do_div() to xattr.c and the warning below too. As Geert remarked: "tmp" is "loff_t" which is "__kernel_loff_t", which is "long long", i.e. signed, while include/asm-generic/div64.h compares its type with "uint64_t". As inode sizes are positive, it should be safe to change the type of "tmp" to "u64". In file included from arch/powerpc/include/asm/div64.h:1:0, from include/linux/kernel.h:124, from include/asm-generic/bug.h:13, from arch/powerpc/include/asm/bug.h:127, from include/linux/bug.h:4, from include/linux/thread_info.h:11, from include/asm-generic/preempt.h:4, from arch/powerpc/include/generated/asm/preempt.h:1, from include/linux/preempt.h:18, from include/linux/spinlock.h:50, from include/linux/wait.h:8, from include/linux/fs.h:6, from fs/hfsplus/hfsplus_fs.h:19, from fs/hfsplus/xattr.c:9: fs/hfsplus/xattr.c: In function 'hfsplus_init_header_node': include/asm-generic/div64.h:43:28: warning: comparison of distinct pointer types lacks a cast [enabled by default] (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ ^ fs/hfsplus/xattr.c:86:2: note: in expansion of macro 'do_div' do_div(tmp, node_size); ^ Signed-off-by:
Christian Kujau <lists@nerdbynature.de> Signed-off-by:
Sergei Antonov <saproj@gmail.com> Signed-off-by:
-
Fabian Frederick authored
Signed-off-by:
Vyacheslav Dubeyko <slava@dubeyko.com> Signed-off-by:
-
Sergei Antonov authored
Some function declarations in hfsplus_fs.h were with argument names, some without, and some were mixed. This patch adds argument names everywhere, sorts function in order they go in .c files, and moves hfs_part_find() to a proper section. Auto-formatting and sorting was done with: cfunctions *.c | indent -linux | sed "s| \* | \*|" Signed-off-by:
-
Fabian Frederick authored
Replace while blocksize;shift by ilog2 Signed-off-by:
-
Sergei Antonov authored
Zero newly allocated extents in the catalog tree if volume attributes tell us to. Not doing so we risk getting the "unused node is not erased" error. See kHFSUnusedNodeFix flag in Apple's source code for reference. There was a previous commit clearing the node when it is freed: commit 899bed05 ("hfsplus: fix issue with unzeroed unused b-tree nodes"). But it did not handle newly allocated extents (this patch fixes it). And it zeroed nodes in all trees unconditionally which is an overkill. This patch adds a condition and also switches to 'tree->node_size' as a simpler method of getting the length to zero. Signed-off-by:
-
Fabian Frederick authored
Also add * before function comments (it was not detected by kernel-doc) Signed-off-by:
-
Fabian Frederick authored
Replace seq_printf where possible Signed-off-by:
-
Fabian Frederick authored
Also fixes some pr_ formats Signed-off-by:
-
Sergei Antonov authored
hfsplus_readdir() incorrectly returned DT_REG for symbolic links and special files. Return DT_REG, DT_LNK, DT_FIFO, DT_CHR, DT_BLK, DT_SOCK, or DT_UNKNOWN according to mode field in catalog record. Programs relying on information from readdir will now work correctly with HFS+. Signed-off-by:
-
Hin-Tak Leung authored
The directory/file catalog b-tree equivalent, hfsplus_build_key_uni(), is used by hfsplus_find_cat() for internal referencing between catalog records. There is no corresponding usage for attributes - attribute records do not refer to one another. Signed-off-by:
Hin-Tak Leung <htl10@users.sourceforge.net> Cc: Sougata Santra <sougata@tuxera.com> Cc: Anton Altaparmakov <anton@tuxera.com> Cc: Vyacheslav Dubeyko <slava@dubeyko.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@infradead.org> Signed-off-by:
-
Hin-Tak Leung authored
HFSPLUS_ATTR_MAX_STRLEN (=127) is the limit of attribute names for the number of unicode character (UTF-16BE) storable in the HFS+ file system. Almost all the current usage of it is wrong, in relation to NLS to on-disk conversion. Except for one use calling hfsplus_asc2uni (which should stay the same) and its uses in calling hfsplus_uni2asc (which was corrected in the earlier patch in this series concerning usage of hfsplus_uni2asc), all the other uses are of the forms: - char buffer[size] - bound check: "if (namespace_adjusted_input_length > size) return failure;" Conversion between on-disk unicode representation and NLS char strings (in whichever direction) always needs to accommodate the worst-case NLS conversion, so all char buffers of that size need to have a NLS_MAX_CHARSET_SIZE x . The bound checks are all wrong, since they compare nls_length derived from strlen() to a unicode length limit. It turns out that all the bound-checks do is to protect hfsplus_asc2uni(), which can fail if the input is too large. There is only one usage of it as far as attributes are concerned, in hfsplus_attr_build_key(). It is in turn used by hfsplus_find_attr(), hfsplus_create_attr(), hfsplus_delete_attr(). Thus making sure that errors from hfsplus_asc2uni() is caught in hfsplus_attr_build_key() and propagated is sufficient to replace all the bound checks. Unpropagated errors from hfsplus_asc2uni() in the file catalog code was addressed recently in an independent patch "hfsplus: fix longname handling" by Sougata Santra. Before this patch, trying to set a 55 CJK character (in a UTF-8 locale, > 127/3=42) attribute plus user prefix fails with: $ setfattr -n user.`cat testing-string` -v `cat testing-string` \ testing-string setfattr: testing-string: Operation not supported and retrieving a stored long attributes is particular ugly(!): find /mnt/* -type f -exec getfattr -d {} \; getfattr: /mnt/testing-string: Input/output error with console log: [268008.389781] hfsplus: unicode conversion failed After the patch, both of the above works. FYI, the test attribute string is prepared with: echo -e -n \ "\xe9\x80\x99\xe6\x98\xaf\xe4\xb8\x80\xe5\x80\x8b\xe9\x9d\x9e\xe5" \ "\xb8\xb8\xe6\xbc\xab\xe9\x95\xb7\xe8\x80\x8c\xe6\xa5\xb5\xe5\x85" \ "\xb6\xe4\xb9\x8f\xe5\x91\xb3\xe5\x92\x8c\xe7\x9b\xb8\xe7\x95\xb6" \ "\xe7\x84\xa1\xe8\xb6\xa3\xe3\x80\x81\xe4\xbb\xa5\xe5\x8f\x8a\xe7" \ "\x84\xa1\xe7\x94\xa8\xe7\x9a\x84\xe3\x80\x81\xe5\x86\x8d\xe5\x8a" \ "\xa0\xe4\xb8\x8a\xe6\xaf\xab\xe7\x84\xa1\xe6\x84\x8f\xe7\xbe\xa9" \ "\xe7\x9a\x84\xe6\x93\xb4\xe5\xb1\x95\xe5\xb1\xac\xe6\x80\xa7\xef" \ "\xbc\x8c\xe8\x80\x8c\xe5\x85\xb6\xe5\x94\xaf\xe4\xb8\x80\xe5\x89" \ "\xb5\xe5\xbb\xba\xe7\x9b\xae\xe7\x9a\x84\xe5\x83\x85\xe6\x98\xaf" \ "\xe7\x82\xba\xe4\xba\x86\xe6\xb8\xac\xe8\xa9\xa6\xe4\xbd\x9c\xe7" \ "\x94\xa8\xe3\x80\x82" | tr -d ' ' (= "pointlessly long attribute for testing", elaborate Chinese in UTF-8 enoding). However, it is not possible to set double the size (110 + 5 is still under 127) in a UTF-8 locale: $setfattr -n user.`cat testing-string testing-string` -v \ `cat testing-string testing-string` testing-string setfattr: testing-string: Numerical result out of range 110 CJK char in UTF-8 is 330 bytes - the generic get/set attribute system call code in linux/fs/xattr.c imposes a 255 byte limit. One can use a combination of iconv to encode content, changing terminal locale for viewing, and an nls=cp932/cp936/cp949/cp950 mount option to fully use 127-unicode attribute in a double-byte locale. Also, as an additional information, it is possible to (mis-)use unicode half-width/full-width forms (U+FFxx) to write attributes which looks like english but not actually ascii. Thanks Anton Altaparmakov for reviewing the earlier ideas behind this change. [akpm@linux-foundation.org: fix build] [akpm@linux-foundation.org: fix build] Signed-off-by: -
Hin-Tak Leung authored
This is a series of 3 patches which corrects issues in HFS+ concerning the use of non-english file names and attributes. Names and attributes are stored internally as UTF-16 units up to a fixed maximum size, and convert to and from user-representation by NLS. The code incorrectly assume that NLS string lengths are equal to unicode lengths, which is only true for English ascii usage. This patch (of 3): The HFS Plus Volume Format specification (TN1150) states that file names are stored internally as a maximum of 255 unicode characters, as defined by The Unicode Standard, Version 2.0 [Unicode, Inc. ISBN 0-201-48345-9]. File names are converted by the NLS system on Linux before presented to the user. 255 CJK characters converts to UTF-8 with 1 unicode character to up to 3 bytes, and to GB18030 with 1 unicode character to up to 4 bytes. Thus, trying in a UTF-8 locale to list files with names of more than 85 CJK characters results in: $ ls /mnt ls: reading directory /mnt: File name too long The receiving buffer to hfsplus_uni2asc() needs to be 255 x NLS_MAX_CHARSET_SIZE bytes, not 255 bytes as the code has always been. Similar consideration applies to attributes, which are stored internally as a maximum of 127 UTF-16BE units. See XNU source for an up-to-date reference on attributes. Strictly speaking, the maximum value of NLS_MAX_CHARSET_SIZE = 6 is not attainable in the case of conversion to UTF-8, as going beyond 3 bytes requires the use of surrogate pairs, i.e. consuming two input units. Thanks Anton Altaparmakov for reviewing an earlier version of this change. This patch fixes all callers of hfsplus_uni2asc(), and also enables the use of long non-English file names in HFS+. The getting and setting, and general usage of long non-English attributes requires further forthcoming work, in the following patches of this series. [akpm@linux-foundation.org: fix build] Signed-off-by:Anton Altaparmakov <anton@tuxera.com> Cc: Vyacheslav Dubeyko <slava@dubeyko.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@infradead.org> Cc: Sougata Santra <sougata@tuxera.com> Signed-off-by:
-
Fabian Frederick authored
Replace all function names by __func__ in pr_foo() Signed-off-by:
-
Fabian Frederick authored
- Add pr_fmt based on module name. - Remove Coda: coda: from pr_foo() Signed-off-by:
-
Fabian Frederick authored
No level printk converted to pr_warn or pr_info Signed-off-by:
-
Fabian Frederick authored
Fix some comment errors. Signed-off-by:
-
Fabian Frederick authored
sector_t is unsigned. Signed-off-by:
-
Fabian Frederick authored
- strncpy + end of string assignement replaced by strlcpy - Fix endif }; - Fix typo Signed-off-by:
-
Fabian Frederick authored
strncpy + end of string assignment replaced by strlcpy Signed-off-by:
-
Jingoo Han authored
Make of_device_id array const, because all OF functions handle it as const. Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
Jingoo Han authored
Make of_device_id array const, because all OF functions handle it as const. Signed-off-by:
-
Lokesh Vutla authored
When RTC CLKTRCTRL bit is configured in HW_AUTO, module goes to sleep in IDLE state. The Alarm SWakeup event can be used to wakeup the RTC when it is in IDLE state. In order to do so, the alarm needs to be set and enabled before RTC enters the IDLE state. Also the wakeup generation for alarm/timer event needs to be set (bits [1:0] in RTC_IRQWAKEEN register). Currently RTC_IRQWAKEEN bits are set only in suspend/resume paths. With this ALARM interrupts are not generated when it enters IDLE state. So programming the RTC_IRQWAKEEN bits when ever ALARM is set. Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Acked-by:
Sekhar Nori <nsekhar@ti.com> Cc: Grant Likely <grant.likely@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Boris BREZILLON authored
sam9x5 SoCs have the following errata: "RTC: Interrupt Mask Register cannot be used Interrupt Mask Register read always returns 0." Hence we should not rely on what IMR claims about already masked IRQs and just disable all IRQs. Signed-off-by:
Boris BREZILLON <boris.brezillon@free-electrons.com> Reported-by:
Bryan Evenson <bevenson@melinkcorp.com> Reviewed-by:
Johan Hovold <johan@hovold.com> Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Bryan Evenson <bevenson@melinkcorp.com> Cc: Andrew Victor <linux@maxim.org.za> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Mark Roszko <mark.roszko@gmail.com> Signed-off-by:
-
Boris BREZILLON authored
The rtc user must wait at least 1 sec between each time/calandar update (see atmel's datasheet chapter "Updating Time/Calendar"). Use the 1Hz interrupt to update the at91_rtc_upd_rdy flag and wait for the at91_rtc_wait_upd_rdy event if the rtc is not ready. This patch fixes a deadlock in an uninterruptible wait when the RTC is updated more than once every second. AFAICT the bug is here from the beginning, but I think we should at least backport this fix to 3.10 and the following longterm and stable releases. Signed-off-by:
-
Heiko Stuebner authored
This enables the setting of a custom clock name for the clock provided by the hym8563 rtc. Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Reviewed-by:
Mike Turquette <mturquette@linaro.org> Signed-off-by:
-
Mike Frysinger authored
The RTC framework does not let you return an error once a call to devm_rtc_device_register has succeeded. Avoid doing that when the IRQ request fails as we can still support reading/writing the clock without the IRQ. Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Reported-by:
Ales Novak <alnovak@suse.cz> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Sekhar Nori authored
Newer versions of OMAP RTC IP such as those found in AM335x and DRA7x need an explicit enable of 32khz functional clock which ticks the RTC. AM335x support was working so far because of settings done in U-Boot. However, the DRA7x U-Boot does no such enable of 32khz clock and this patch is need to get the RTC to work on DRA7x at least. In general, it is better to not depend on settings done in U-Boot. Thanks to Lokesh Vutla for noticing this. Signed-off-by:
-
