Add new extended inode types that store the xattr_id field.
Also add the necessary code changes to make xattrs visibile.
Signed-off-by: Phillip Lougher <phillip@lougher.demon.co.uk>
This patch adds support for mapping xattr ids (stored in inodes)
into the on-disk location of the xattrs themselves.
Signed-off-by: Phillip Lougher <phillip@lougher.demon.co.uk>
To avoid problems like the one fixed by Stephane Eranian in 3de29ca, now
we'll got this instead:
bench/sched-messaging.c:259: error: negative width in bit-field ‘<anonymous>’
bench/sched-messaging.c:261: error: negative width in bit-field ‘<anonymous>’
Which is rather cryptic, but is how BUILD_BUG_ON_ZERO works, so kernel
hackers should be already used to this.
With it in place found some problems, fixed by changing the affected
variables to sensible types or changed some OPT_INTEGER to OPT_UINTEGER.
Next csets will go thru converting each of the remaining OPT_ so that
review can be made easier by grouping changes per type per patch.
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Cc: Tom Zanussi <tzanussi@gmail.com>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Use the resource_size function instead of manually calculating the
resource size. This reduces the chance of introducing off-by-one
errors.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
If we abort a request, we return to caller, but the request may still
complete. And if we hold the dir FILE_EXCL bit, we may not release a
lease when sending a request. A simple un-tar, control-c, un-tar again
will reproduce the bug (manifested as a 'Cannot open: File exists').
Ensure we invalidate affected dentry leases (as well dir I_COMPLETE) so
we don't have valid (but incorrect) leases. Do the same, consistently, at
other sites where I_COMPLETE is similarly cleared.
Signed-off-by: Sage Weil <sage@newdream.net>
When we abort requests we need to prevent fill_trace et al from doing
anything that relies on locks held by the VFS caller. This fixes a race
between the reply handler and the abort code, ensuring that continue
holding the dir mutex until the reply handler completes.
Signed-off-by: Sage Weil <sage@newdream.net>
We would occasionally BUG out in the reply handler because r_reply was
nonzero, due to a race with ceph_mdsc_do_request temporarily setting
r_reply to an ERR_PTR value. This is unnecessary, messy, and also wrong
in the EIO case.
Clean up by consistently using r_err for errors and r_reply for messages.
Also fix the abort logic to trigger consistently for all errors that return
to the caller early (e.g., EIO from timeout case). If an abort races with
a reply, use the result from the reply.
Also fix locking for r_err, r_reply update in the reply handler.
Signed-off-by: Sage Weil <sage@newdream.net>
The ARCH_REQUIRE_GPIOLIB config option will select GPIOLIB which
in turn will select GENERIC_GPIO. Because of this, there is no
reason to do the select GENERIC_GPIO in arch/arm/Kconfig for the
architectures that have ARCH_REQUIRE_GPIOLIB.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
eeepc-wmi uses backlight*() interfaces so it should depend on
BACKLIGHT_CLASS_DEVICE.
eeepc-wmi.c:(.text+0x2d7f54): undefined reference to `backlight_force_update'
eeepc-wmi.c:(.text+0x2d8012): undefined reference to `backlight_device_register'
eeepc-wmi.c:(.devinit.text+0x1c31c): undefined reference to `backlight_device_unregister'
eeepc-wmi.c:(.devexit.text+0x2f8b): undefined reference to `backlight_device_unregister'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: stable@kernel.org
The IPC (inter processor communications) is used to provide the
communications between kernel and system control units on some embedded
Intel x86 platforms.
(Various bits of clean up and restructuring by Alan Cox)
Signed-off-by: Sreedhara DS <sreedhara.ds@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
The RFKILL device shares the same ACPI device used for backlight. So, it
required a new struct sharing both a backlight_device and a rfkill
device.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
When we build with ftrace enabled its possible that loadcam_entry would
have used the stack pointer (even though the code doesn't need it). We
call loadcam_entry in __secondary_start before the stack is setup. To
ensure that loadcam_entry doesn't use the stack pointer the easiest
solution is to just have it in asm code.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
In CONFIG_PTE_64BIT the PTE format has unique permission bits for user
and supervisor execute. However on !CONFIG_PTE_64BIT we overload the
supervisor bit to imply user execute with _PAGE_USER set. This allows
us to use the same permission check mask for user or supervisor code on
!CONFIG_PTE_64BIT.
However, on CONFIG_PTE_64BIT we map _PAGE_EXEC to _PAGE_BAP_UX so we
need a different permission mask based on the fault coming from a kernel
address or user space.
Without unique permission masks we see issues like the following with
modules:
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0xf938d040
Oops: Kernel access of bad area, sig: 11 [#1]
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Jin Qing <b24347@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
A future version of the MPC8610 HPCD's ASoC DMA driver will probe on individual
DMA channel nodes, so the DMA controller nodes' compatible string must be listed
in mpc8610_ids[] for the probe to work.
Also remove the "gianfar" compatible from mpc8610_ids[], since there is no
gianfar (or any other networking device) on the 8610.
Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
There are two front-panel LEDs on MPC837xRDB and MPC8315RDB boards: PWR
and HDD. After adding appropriate nodes we can program these LEDs from
kernel and user space.
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Since USB2 is shared with local bus, either local bus or USB2
should be disabled. By default U-Boot enables local bus, so we
have to disable USB2, otherwise kernel hangs:
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: irq 28, io base 0xffe22000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
fsl-ehci fsl-ehci.1: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.1: new USB bus registered, assigned bus number 2
<hangs here>
Note that U-Boot doesn't clear 'status' property when it enables
USB2, so we have to comment out the whole node.
To enable USB2, one can issue
'setenv hwconfig usb2:dr_mode=<host|peripheral>' command at the
U-Boot prompt.
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
This patch adds support for eTSEC 2.0 as found in P1020.
The changes include introduction of the group nodes for
the etsec nodes.
Signed-off-by: Sandeep Gopalpet <sandeep.kumar@freescale.com>
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Technically, whilst SEC v3.3 h/w honours the tls_ssl_stream descriptor
type, it lacks the ARC4 algorithm execution unit required to be able
to execute anything meaningful with it. Change the node to agree with
the documentation that declares that the sec3.3 really doesn't have such
a descriptor type.
Reported-by: Haiying Wang <Haiying.Wang@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The -c option defines the user requested sampling period. It was implemented
using an unsigned int variable but the type of the option was OPT_LONG. Thus,
the option parser was overwriting memory belonging to other variables, namely
the mmap_pages leading to a zero page sampling buffer. The bug was exposed only
when compiling at -O0, probably because the compiler was padding variables at
higher optimization levels.
This patch fixes this problem by declaring user_interval as u64. This also
avoids wrap-around issues for large period on 32-bit systems.
Commiter note:
Made it use OPT_U64(user_interval) after implementing OPT_U64 in the
previous patch.
Cc: David S. Miller <davem@davemloft.net>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
LKML-Reference: <4bf11ae9.e88cd80a.06b0.ffffa8e3@mx.google.com>
Signed-off-by: Stephane Eranian <eranian@google.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When looking at a performance problem on PowerPC, I noticed some awful code
generation:
c00000000051fc98: 3b 60 00 01 li r27,1
...
c00000000051fca0: 3b 80 00 00 li r28,0
...
c00000000051fcdc: 93 61 00 70 stw r27,112(r1)
c00000000051fce0: 93 81 00 74 stw r28,116(r1)
c00000000051fce4: 81 21 00 70 lwz r9,112(r1)
c00000000051fce8: 80 01 00 74 lwz r0,116(r1)
c00000000051fcec: 7d 29 07 b4 extsw r9,r9
c00000000051fcf0: 7c 00 07 b4 extsw r0,r0
c00000000051fcf4: 7c 20 04 ac lwsync
c00000000051fcf8: 7d 60 f8 28 lwarx r11,0,r31
c00000000051fcfc: 7c 0b 48 00 cmpw r11,r9
c00000000051fd00: 40 c2 00 10 bne- c00000000051fd10
c00000000051fd04: 7c 00 f9 2d stwcx. r0,0,r31
c00000000051fd08: 40 c2 ff f0 bne+ c00000000051fcf8
c00000000051fd0c: 4c 00 01 2c isync
We create two constants, write them out to the stack, read them straight back
in and sign extend them. What a mess.
It turns out this bad code is a result of us defining atomic_t as a
volatile int.
We removed the volatile attribute from the powerpc atomic_t definition years
ago, but commit ea43546750 (atomic_t: unify all
arch definitions) added it back in.
To dig up an old quote from Linus:
> The fact is, volatile on data structures is a bug. It's a wart in the C
> language. It shouldn't be used.
>
> Volatile accesses in *code* can be ok, and if we have "atomic_read()"
> expand to a "*(volatile int *)&(x)->value", then I'd be ok with that.
>
> But marking data structures volatile just makes the compiler screw up
> totally, and makes code for initialization sequences etc much worse.
And screw up it does :)
With the volatile removed, we see much more reasonable code generation:
c00000000051f5b8: 3b 60 00 01 li r27,1
...
c00000000051f5c0: 3b 80 00 00 li r28,0
...
c00000000051fc7c: 7c 20 04 ac lwsync
c00000000051fc80: 7c 00 f8 28 lwarx r0,0,r31
c00000000051fc84: 7c 00 d8 00 cmpw r0,r27
c00000000051fc88: 40 c2 00 10 bne- c00000000051fc98
c00000000051fc8c: 7f 80 f9 2d stwcx. r28,0,r31
c00000000051fc90: 40 c2 ff f0 bne+ c00000000051fc80
c00000000051fc94: 4c 00 01 2c isync
Six instructions less.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In preparation for removing volatile from the atomic_t definition, this
patch adds a volatile cast to all the atomic read functions.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add a new ext4 state to tell us when a file has been newly created; use
that state in ext4_sync_file in no-journal mode to tell us when we need
to sync the parent directory as well as the inode and data itself. This
fixes a problem in which a panic or power failure may lose the entire
file even when using fsync, since the parent directory entry is lost.
Addresses-Google-Bug: #2480057
Signed-off-by: Frank Mayhar <fmayhar@google.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Add support for the multimedia buttons of the Creative Desktop Wireless 6000
keyboard/mouse combo which are not currently handled by the default/samsung HID
driver.
Signed-off-by: Don Prince <dhprince-devel@yahoo.co.uk>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Filesystems with delalloc support may dirty inode during writepages.
As result inode will have dirty metadata flags even after write_inode.
In fact we have two dedicated functions for proper data and metadata
writeback. It is reasonable to separate flags updates in two stages.
https://bugzilla.kernel.org/show_bug.cgi?id=15906
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
When umount calls sync_filesystem(), we first do a WB_SYNC_NONE
writeback to kick off writeback of pending dirty inodes, then follow
that up with a WB_SYNC_ALL to wait for it. Since umount already holds
the sb s_umount mutex, WB_SYNC_NONE ends up doing nothing and all
writeback happens as WB_SYNC_ALL. This can greatly slow down umount,
since WB_SYNC_ALL writeback is a data integrity operation and thus
a bigger hammer than simple WB_SYNC_NONE. For barrier aware file systems
it's a lot slower.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
This is a reworking of an original patch posted by Aaro Koskinen:
oprofile does not work with PM, because sysdev_suspend() is done with
interrupts disabled and oprofile needs a mutex. Implementing oprofile
as a platform device solves this problem.
Cc: Aaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Enable hardware perf-events if CPU_HAS_PMU and select
HAVE_OPROFILE if HAVE_PERF_EVENTS. If no hardware support
is present, OProfile will fall back to timer mode.
This patch also removes the old OProfile drivers in favour
of the code implemented by perf.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
There are currently two hardware performance monitoring subsystems in
the kernel for ARM: OProfile and perf-events. This creates the
following problems:
1.) Duplicate PMU accessor code. Inevitable code drift may lead to
bugs in one framework that are fixed in the other.
2.) Locking issues. OProfile doesn't reprogram hardware counters
between profiling runs if the events to be monitored have not been
changed. This means that other profiling frameworks cannot use the
counters if OProfile is in use.
3.) Due to differences in the two frameworks, it may not be possible to
compare the results obtained by OProfile with those obtained by perf.
This patch removes the OProfile PMU driver code and replaces it with
calls to perf, therefore solving the issues mentioned above.
The only userspace-visible change is the lack of SCU counter support
for 11MPCore. This is currently unsupported by OProfile userspace tools anyway and therefore shouldn't cause any problems.
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Jamie Iles <jamie.iles@picochip.com>
Cc: Jean Pihet <jpihet@mvista.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
