- 24 Jan, 2014 40 commits
-
-
Oleg Nesterov authored
Nobody actually needs MMF_DUMPABLE/MMF_DUMP_SECURELY, they are only used to enforce the encoding of SUID_DUMP_* enum in mm->flags & MMF_DUMPABLE_MASK. Now that set_dumpable() updates both bits atomically we can kill them and simply store the value "as is" in 2 lower bits. Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Acked-by:
Kees Cook <keescook@chromium.org> Cc: Alex Kelly <alex.page.kelly@gmail.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Josh Triplett <josh@joshtriplett.org> Cc: Petr Matousek <pmatouse@redhat.com> Cc: Vasily Kulikov <segoon@openwall.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Oleg Nesterov authored
set_dumpable() updates MMF_DUMPABLE_MASK in a non-trivial way to ensure that get_dumpable() can't observe the intermediate state, but this all can't help if multiple threads call set_dumpable() at the same time. And in theory commit_creds()->set_dumpable(SUID_DUMP_ROOT) racing with sys_prctl()->set_dumpable(SUID_DUMP_DISABLE) can result in SUID_DUMP_USER. Change this code to update both bits atomically via cmpxchg(). Note: this assumes that it is safe to mix bitops and cmpxchg. IOW, if, say, an architecture implements cmpxchg() using the locking (like arch/parisc/lib/bitops.c does), then it should use the same locks for set_bit/etc. Signed-off-by:
-
Sangjung Woo authored
As the notifier_block name (i.e. foobar_cpu_notifer) is different from the parameter (i.e.foobar_cpu_notifier) of register function, that is definitely error and it also makes readers confused. Signed-off-by:
Sangjung Woo <sangjung.woo@samsung.com> Reviewed-by:
Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by:
-
Robert Graffham authored
Remove an outdated reference to "most personal computers" having only one CPU, and change the use of "singleprocessor" and "single processor" in CONFIG_SMP's documentation to "uniprocessor" across all arches where that documentation is present. Signed-off-by:
Robert Graffham <psquid@psquid.net> Signed-off-by:
-
Fabian Frederick authored
Add the following documentation-files with description : -autofs4-mount-control.txt -btrfs.txt -debugfs.txt -devpts.txt -fiemap.txt -gfs2-glocks.txt -gfs2-uevents.txt -omfs.txt -path-lookup.txt -qnx6.txt -quota.txt -squashfs.txt -sysfs-tagging.txt -ubifs.txt -xfs-delayed-logging-design.txt -xfs-self-describing-metadata.txt Add the following documentation directories with description : -caching -cifs (replacing cifs.txt) -pohmelfs Remove the following documentation-files reference: -dentry-locking.txt -reiser4.txt Signed-off-by:
Fabian Frederick <fabf@skynet.be> Cc: Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Fabian Frederick authored
- ramdisk_blocksize doesn't exist anymore - Module parameters added to documentation Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Andre Richter authored
Fix a wrong device_attribute declaration example. Signed-off-by:
Andre Richter <andre.o.richter@gmail.com> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
Sougata Santra authored
HFS+ resource fork lookup breaks opendir() library function. Since opendir first calls open() with O_DIRECTORY flag set. O_DIRECTORY means "refuse to open if not a directory". The open system call in the kernel does a check for inode->i_op->lookup and returns -ENOTDIR. So if hfsplus_file_lookup is set it allows opendir() for plain files. Also resource fork lookup in HFS+ does not work. Since it is never invoked after VFS permission checking. It will always return with -EACCES. When we call opendir() on a file, it does not return NULL. opendir() library call is based on open with O_DIRECTORY flag passed and then layered on top of getdents() system call. O_DIRECTORY means "refuse to open if not a directory". The open() system call in the kernel does a check for: do_sys_open() -->..--> can_lookup() i.e it only checks inode->i_op->lookup and returns ENOTDIR if this function pointer is not set. In OSX, we can open "file/rsrc" to get the resource fork of "file". This behavior is emulated inside hfsplus on Linux, which means that to some degree every file acts like a directory. That is the reason lookup() inode operations is supported for files, and it is possible to do a lookup on this specific name. As a result of this open succeeds without returning ENOTDIR for HFS+ Please see the LKML discussion thread on this issue: http://marc.info/?l=linux-fsdevel&m=122823343730412&w=2 I tried to test file/rsrc lookup in HFS+ driver and the feature does not work. From OSX: $ touch test $ echo "1234" > test/..namedfork/rsrc $ ls -l test..namedfork/rsrc --rw-r--r-- 1 tuxera staff 5 10 dec 12:59 test/..namedfork/rsrc [sougata@ultrabook tmp]$ id uid=1000(sougata) gid=1000(sougata) groups=1000(sougata),5(tty),18(dialout),1001(vboxusers) [sougata@ultrabook tmp]$ mount /dev/sdb1 on /mnt/tmp type hfsplus (rw,relatime,umask=0,uid=1000,gid=1000,nls=utf8) [sougata@ultrabook tmp]$ ls -l test/rsrc ls: cannot access test/rsrc: Permission denied According to this LKML thread it is expected behavior. http://marc.info/?t=121139033800008&r=1&w=4 I guess now that permission checking happens in vfs generic_permission() ? So it turns out that even though the lookup() inode_operation exists for HFS+ files. It cannot really get invoked ?. So if we can disable this feature to make opendir() work for HFS+. Signed-off-by:
Sougata Santra <sougata@tuxera.com> Acked-by:
Christoph Hellwig <hch@lst.de> Cc: Vyacheslav Dubeyko <slava@dubeyko.com> Cc: Anton Altaparmakov <aia21@cam.ac.uk> Signed-off-by:
-
Vyacheslav Dubeyko authored
Add comments for ioctls in fs/nilfs2/ioctl.c file and describe NILFS2 specific ioctls in Documentation/filesystems/nilfs2.txt. Signed-off-by:
Vyacheslav Dubeyko <slava@dubeyko.com> Reviewed-by:
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Cc: Wenliang Fan <fanwlexca@gmail.com> Signed-off-by:
-
Wenliang Fan authored
The local variable 'pos' in nilfs_ioctl_wrap_copy function can overflow if a large number was passed to argv->v_index from userspace and the sum of argv->v_index and argv->v_nmembs exceeds the maximum value of __u64 type integer (= ~(__u64)0 = 18446744073709551615). Here, argv->v_index is a 64-bit width argument to specify the start position of target data items (such as segment number, checkpoint number, or virtual block address of nilfs), and argv->v_nmembs gives the total number of the items that userland programs (such as lssu, lscp, or cleanerd) want to get information about, which also gives the maximum element count of argv->v_base[] array. nilfs_ioctl_wrap_copy() calls dofunc() repeatedly and increments the position variable 'pos' at the end of each iteration if dofunc() itself didn't update 'pos': if (pos == ppos) pos += n; This patch prevents the overflow here by rejecting pairs of a start position (argv->v_index) and a total count (argv->v_nmembs) which leads to the overflow. [konishi.ryusuke@lab.ntt.co.jp: fix signedness issue] Signed-off-by:Wenliang Fan <fanwlexca@gmail.com> Cc: Vyacheslav Dubeyko <slava@dubeyko.com> Signed-off-by:
-
Dmitry Monakhov authored
Pipe has no data associated with fs so it is not good idea to block pipe_write() if FS is frozen, but we can not update file's time on such filesystem. Let's use same idea as we use in touch_time(). Addresses https://bugzilla.kernel.org/show_bug.cgi?id=65701Signed-off-by:
Dmitry Monakhov <dmonakhov@openvz.org> Reviewed-by:
Jan Kara <jack@suse.cz> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Andreas Werner authored
Add support for SMBus-only adapters (e.g. i2c-piix4). The driver has implemented only support for I2C adapters which implement the I2C_FUNC_SMBUS_I2C_BLOCK functionality before. With this patch it is possible to load and use the RTC driver with I2C and SMBUS adapters like the rtc-ds1307 does. Tested on AMD G Series Platform (i2c-piix4 adapter driver). Signed-off-by:
Andreas Werner <andreas.werner@men.de> Signed-off-by:
-
Geert Uytterhoeven authored
If CONFIG_PM_SLEEP=n: drivers/rtc/rtc-s5m.c:643: warning: `s5m_rtc_resume' defined but not used drivers/rtc/rtc-s5m.c:654: warning: `s5m_rtc_suspend' defined but not used Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Stephen Warren authored
The current MAX8907 driver has two issues related to weekday value handling: 1) The HW WEEKDAY register has range 0..6 rather than 1..7 as documented. Note that I validated the actual HW range by observing the HW register roll from 6->0 rather than 6->7->1 as would otherwise be expected. This matches Linux's tm_wday range of 0..6. When the CMOS RAM content is lost, the date returned from the device is 2007-01-01 00:00:00, which is a Monday. The WEEKDAY register reads 1 in this case. This matches the numbering in Linux's tm_wday field. Hence we should write Linux's tm_wday value to the register without modifying it. Hence, remove the +1/-1 calculations for WEEKDAY/tm_wday. 2) There's no need to make alarms match on the WEEKDAY register, since the other fields together uniquely define the alarm date/time. Ignoring the WEEKDAY value in the match isolates the driver from any incorrect value in the current time copy of the WEEKDAY register. Each change individually, or both together, solves an issue that I observed; "hwclock -r" would time out waiting for its alarm to fire if the CMOS RAM content had been lost, and hence the WEEKDAY register value mismatched what the driver expected it to be. "hwclock -w" would solve this by over-writing the HW default WEEKDAY register value with what the driver expected. Signed-off-by:
Stephen Warren <swarren@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Sachin Kamat authored
'hym8563_clkout_ops' is used only in this file. Signed-off-by:
Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by:
-
Sachin Kamat authored
'hym8563_dt_idtable' is always compiled in. Hence the helper macro is not needed. Signed-off-by:
-
Sachin Kamat authored
'ds1742_rtc_of_match' is always compiled in. Hence the helper macro is not needed. Signed-off-by:
-
Andrew Morton authored
If hpet_register_irq_handler() fails, cmos_do_probe() will incorrectly return 0. Reported-by:
Julia Lawall <julia.lawall@lip6.fr> Cc: John Stultz <john.stultz@linaro.org> Cc: Grant Likely <grant.likely@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Signed-off-by:
-
Stephen Warren authored
Assign RTC device IDs based on device tree /aliases entries if present, falling back to the existing numbering scheme if there is no /aliases entry (which includes when the system isn't booted using DT), or there is a numbering conflict. This is useful in systems with multiple RTC devices, to ensure that the best RTC device is selected as /dev/rtc0, which provides the overall system time. For example, Tegra has an on-SoC RTC that is not battery backed, typically coupled with an off-SoC RTC that is battery backed. Only the latter is useful for populating the system time, yet the former is useful e.g. for wakeup timing, since the time is not lost when the system is sleeps. Signed-off-by:
-
Duan Jiong authored
Fix a coccinelle error regarding usage of IS_ERR and PTR_ERR instead of PTR_ERR_OR_ZERO. Signed-off-by:
Duan Jiong <duanj.fnst@cn.fujitsu.com> Signed-off-by:
-
Geert Uytterhoeven authored
On ARAnyM (emulating an Atari Falcon, which doesn't have an RTC IRQ, as the Second Multi Function Peripheral MFP 68901 is available on Atari TT only), rtc-cmos doesn't work well: - The date is of by 32 years (2045 instead of 2013): rtc_cmos rtc_cmos: setting system clock to 2045-12-02 10:56:17 UTC (2395824977) - The hwclock utility doesn't work: hwclock: ioctl() to /dev/rtc to turn on update interrupts failed unexpectedly, errno=5: Input/output error. As rtc-generic works fine for the RTC part, and nvram works for the NVRAM part, we'll continue on using that. Signed-off-by: -
Geert Uytterhoeven authored
device_driver.name is "const char *" Signed-off-by:
-
Heiko Stuebner authored
The Haoyu Microelectronics HYM8563 provides rtc and alarm functions as well as a clock output of up to 32kHz. Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Cc: Rob Herring <rob.herring@calxeda.com> Cc: Pawel Moll <pawel.moll@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Stephen Warren <swarren@wwwdotorg.org> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk> Cc: Grant Likely <grant.likely@linaro.org> Cc: Mike Turquette <mturquette@linaro.org> Cc: Richard Weinberger <richard.weinberger@gmail.com> Cc: Mark Brown <broonie@kernel.org> Signed-off-by:
-
Heiko Stuebner authored
Add binding documentation for the hym8563 rtc chip. Signed-off-by:
-
Jingoo Han authored
Use devm_*() functions to make cleanup paths simpler, and remove unnecessary remove(). Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Cc: Yoichi Yuasa <yuasa@linux-mips.org> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
Jingoo Han authored
Use devm_*() functions to make cleanup paths simpler, and remove unnecessary remove(). Signed-off-by:
-
Alexander Shiyan authored
This patch allows the driver to be enabled with devicetree. Signed-off-by:
Alexander Shiyan <shc_work@mail.ru> Acked-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
-
Fabio Estevam authored
clk_prepare_enable() may fail, so let's check its return value and propagate it in the case of error. Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
-
Fabio Estevam authored
There is no need to jump to the 'exit_free_pdata' label when devm_clk_get() fails, as we can directly return the error and simplify the code a bit. Signed-off-by:
-
Jingoo Han authored
The driver core clears the driver data to NULL after device_release or on probe failure. Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by:
-
Laxman Dewangan authored
Use devm_* calls for rtc and irq registration and get rid of remove callback for platform driver. Signed-off-by:
Laxman Dewangan <ldewangan@nvidia.com> Cc: Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
Ian Kent authored
The autofs4 module doesn't consider symlinks for expire as it did in the older autofs v3 module (so it's actually a long standing regression). The user space daemon has focused on the use of bind mounts instead of symlinks for a long time now and that's why this has not been noticed. But with the future addition of amd map parsing to automount(8), not to mention amd itself (of am-utils), symlink expiry will be needed. The direct and offset mount types can't be symlinks and the tree mounts of version 4 were always real mounts so only indirect mounts need expire symlinks. Since the current users of the autofs4 module haven't reported this as a problem to date this patch probably isn't a candidate for backport to stable. Signed-off-by:
Ian Kent <ikent@redhat.com> Signed-off-by:
-
Rui Xiang authored
Use the helper macro !IS_ROOT to replace parent != dentry->d_parent. Just clean up. Signed-off-by:
Rui Xiang <rui.xiang@huawei.com> Signed-off-by:
Ian Kent <raven@themaw.net> Signed-off-by:
-
Rui Xiang authored
While kzallocing sbi/ino fails, it should return -ENOMEM. And it should return the err value from autofs_prepare_pipe. Signed-off-by:
-
Miklos Szeredi authored
The PID and the TGID of the process triggering the mount are sent to the daemon. Currently the global pid values are sent (ones valid in the initial pid namespace) but this is wrong if the autofs daemon itself is not running in the initial pid namespace. So send the pid values that are valid in the namespace of the autofs daemon. The namespace to use is taken from the oz_pgrp pid pointer, which was set at mount time to the mounting process' pid namespace. If the pid translation fails (the triggering process is in an unrelated pid namespace) then the automount fails with ENOENT. Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Acked-by:
Serge Hallyn <serge.hallyn@canonical.com> Cc: Eric Biederman <ebiederm@xmission.com> Acked-by:
-
Sukadev Bhattiprolu authored
Enable autofs4 to work in a "container". oz_pgrp is converted from pid_t to struct pid and this is stored at mount time based on the "pgrp=" option or if the option is missing then the current pgrp. The "pgrp=" option is interpreted in the PID namespace of the current process. This option is flawed in that it doesn't carry the namespace information, so it should be deprecated. AFAICS the autofs daemon always sends the current pgrp, which is the default anyway. The oz_pgrp is also set from the AUTOFS_DEV_IOCTL_SETPIPEFD_CMD ioctl. This ioctl sets oz_pgrp to the current pgrp. It is not allowed to change the pid namespace. oz_pgrp is used mainly to determine whether the process traversing the autofs mount tree is the autofs daemon itself or not. This function now compares the pid pointers instead of the pid_t values. One other use of oz_pgrp is in autofs4_show_options. There is shows the virtual pid number (i.e. the one that is valid inside the PID namespace of the calling process) For debugging printk convert oz_pgrp to the value in the initial pid namespace. Signed-off-by:
Sukadev Bhattiprolu <sukadev@us.ibm.com> Signed-off-by:
-
Tetsuo Handa authored
Use constant format string in case message changes. Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by:
-
Geert Uytterhoeven authored
Its user was removed in v2.5.2.4. Signed-off-by:
-
Axel Lin authored
ramfs_aops is identical in file-mmu.c and file-nommu.c. Thus move it to fs/ramfs/inode.c and make it static. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Axel Lin authored
Since commit 853ac43a ("shmem: unify regular and tiny shmem"), ramfs_nommu_get_unmapped_area() and ramfs_nommu_mmap() are not directly referenced outside of file-nommu.c. Thus make them static. Signed-off-by:
-
