Merge branch 'linus' into x86/urgent (83f2f0ed) · Commits · e / devices / android_kernel_sony_msm8994

CREDITS

+9 −0

Original line number	Diff line number	Diff line
		@@ -495,6 +495,11 @@ S: Kopmansg 2
		S: 411 13 Goteborg
		S: Sweden

		N: Paul Bristow
		E: paul@paulbristow.net
		W: http://paulbristow.net/linux/idefloppy.html
		D: Maintainer of IDE/ATAPI floppy driver

		N: Dominik Brodowski
		E: linux@brodo.de
		W: http://www.brodo.de/
		@@ -2642,6 +2647,10 @@ S: C/ Mieses 20, 9-B
		S: Valladolid 47009
		S: Spain

		N: Gadi Oxman
		E: gadio@netvision.net.il
		D: Original author and maintainer of IDE/ATAPI floppy/tape drivers

		N: Greg Page
		E: gpage@sovereign.org
		D: IPX development and support

Documentation/ABI/testing/ima_policy

0 → 100644

+61 −0

Original line number	Diff line number	Diff line
		What: security/ima/policy
		Date: May 2008
		Contact: Mimi Zohar <zohar@us.ibm.com>
		Description:
		The Trusted Computing Group(TCG) runtime Integrity
		Measurement Architecture(IMA) maintains a list of hash
		values of executables and other sensitive system files
		loaded into the run-time of this system. At runtime,
		the policy can be constrained based on LSM specific data.
		Policies are loaded into the securityfs file ima/policy
		by opening the file, writing the rules one at a time and
		then closing the file. The new policy takes effect after
		the file ima/policy is closed.

		rule format: action [condition ...]

		action: measure \| dont_measure
		condition:= base \| lsm
		base: [[func=] [mask=] [fsmagic=] [uid=]]
		lsm: [[subj_user=] [subj_role=] [subj_type=]
		[obj_user=] [obj_role=] [obj_type=]]

		base: func:= [BPRM_CHECK][FILE_MMAP][INODE_PERMISSION]
		mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]
		fsmagic:= hex value
		uid:= decimal value
		lsm: are LSM specific

		default policy:
		# PROC_SUPER_MAGIC
		dont_measure fsmagic=0x9fa0
		# SYSFS_MAGIC
		dont_measure fsmagic=0x62656572
		# DEBUGFS_MAGIC
		dont_measure fsmagic=0x64626720
		# TMPFS_MAGIC
		dont_measure fsmagic=0x01021994
		# SECURITYFS_MAGIC
		dont_measure fsmagic=0x73636673

		measure func=BPRM_CHECK
		measure func=FILE_MMAP mask=MAY_EXEC
		measure func=INODE_PERM mask=MAY_READ uid=0

		The default policy measures all executables in bprm_check,
		all files mmapped executable in file_mmap, and all files
		open for read by root in inode_permission.

		Examples of LSM specific definitions:

		SELinux:
		# SELINUX_MAGIC
		dont_measure fsmagic=0xF97CFF8C

		dont_measure obj_type=var_log_t
		dont_measure obj_type=auditd_log_t
		measure subj_user=system_u func=INODE_PERM mask=MAY_READ
		measure subj_role=system_r func=INODE_PERM mask=MAY_READ

		Smack:
		measure subj_user=_ func=INODE_PERM mask=MAY_READ

Documentation/ABI/testing/sysfs-bus-pci

+70 −0

Original line number	Diff line number	Diff line
		@@ -41,6 +41,49 @@ Description:
		for the device and attempt to bind to it. For example:
		# echo "8086 10f5" > /sys/bus/pci/drivers/foo/new_id

		What: /sys/bus/pci/drivers/.../remove_id
		Date: February 2009
		Contact: Chris Wright <chrisw@sous-sol.org>
		Description:
		Writing a device ID to this file will remove an ID
		that was dynamically added via the new_id sysfs entry.
		The format for the device ID is:
		VVVV DDDD SVVV SDDD CCCC MMMM. That is Vendor ID, Device
		ID, Subsystem Vendor ID, Subsystem Device ID, Class,
		and Class Mask. The Vendor ID and Device ID fields are
		required, the rest are optional. After successfully
		removing an ID, the driver will no longer support the
		device. This is useful to ensure auto probing won't
		match the driver to the device. For example:
		# echo "8086 10f5" > /sys/bus/pci/drivers/foo/remove_id

		What: /sys/bus/pci/rescan
		Date: January 2009
		Contact: Linux PCI developers <linux-pci@vger.kernel.org>
		Description:
		Writing a non-zero value to this attribute will
		force a rescan of all PCI buses in the system, and
		re-discover previously removed devices.
		Depends on CONFIG_HOTPLUG.

		What: /sys/bus/pci/devices/.../remove
		Date: January 2009
		Contact: Linux PCI developers <linux-pci@vger.kernel.org>
		Description:
		Writing a non-zero value to this attribute will
		hot-remove the PCI device and any of its children.
		Depends on CONFIG_HOTPLUG.

		What: /sys/bus/pci/devices/.../rescan
		Date: January 2009
		Contact: Linux PCI developers <linux-pci@vger.kernel.org>
		Description:
		Writing a non-zero value to this attribute will
		force a rescan of the device's parent bus and all
		child buses, and re-discover devices removed earlier
		from this part of the device tree.
		Depends on CONFIG_HOTPLUG.

		What: /sys/bus/pci/devices/.../vpd
		Date: February 2008
		Contact: Ben Hutchings <bhutchings@solarflare.com>
		@@ -52,3 +95,30 @@ Description:
		that some devices may have malformatted data. If the
		underlying VPD has a writable section then the
		corresponding section of this file will be writable.

		What: /sys/bus/pci/devices/.../virtfnN
		Date: March 2009
		Contact: Yu Zhao <yu.zhao@intel.com>
		Description:
		This symbolic link appears when hardware supports the SR-IOV
		capability and the Physical Function driver has enabled it.
		The symbolic link points to the PCI device sysfs entry of the
		Virtual Function whose index is N (0...MaxVFs-1).

		What: /sys/bus/pci/devices/.../dep_link
		Date: March 2009
		Contact: Yu Zhao <yu.zhao@intel.com>
		Description:
		This symbolic link appears when hardware supports the SR-IOV
		capability and the Physical Function driver has enabled it,
		and this device has vendor specific dependencies with others.
		The symbolic link points to the PCI device sysfs entry of
		Physical Function this device depends on.

		What: /sys/bus/pci/devices/.../physfn
		Date: March 2009
		Contact: Yu Zhao <yu.zhao@intel.com>
		Description:
		This symbolic link appears when a device is a Virtual Function.
		The symbolic link points to the PCI device sysfs entry of the
		Physical Function this device associates with.

Documentation/ABI/testing/sysfs-fs-ext4

0 → 100644

+81 −0

Original line number	Diff line number	Diff line
		What: /sys/fs/ext4/<disk>/mb_stats
		Date: March 2008
		Contact: "Theodore Ts'o" <tytso@mit.edu>
		Description:
		Controls whether the multiblock allocator should
		collect statistics, which are shown during the unmount.
		1 means to collect statistics, 0 means not to collect
		statistics

		What: /sys/fs/ext4/<disk>/mb_group_prealloc
		Date: March 2008
		Contact: "Theodore Ts'o" <tytso@mit.edu>
		Description:
		The multiblock allocator will round up allocation
		requests to a multiple of this tuning parameter if the
		stripe size is not set in the ext4 superblock

		What: /sys/fs/ext4/<disk>/mb_max_to_scan
		Date: March 2008
		Contact: "Theodore Ts'o" <tytso@mit.edu>
		Description:
		The maximum number of extents the multiblock allocator
		will search to find the best extent

		What: /sys/fs/ext4/<disk>/mb_min_to_scan
		Date: March 2008
		Contact: "Theodore Ts'o" <tytso@mit.edu>
		Description:
		The minimum number of extents the multiblock allocator
		will search to find the best extent

		What: /sys/fs/ext4/<disk>/mb_order2_req
		Date: March 2008
		Contact: "Theodore Ts'o" <tytso@mit.edu>
		Description:
		Tuning parameter which controls the minimum size for
		requests (as a power of 2) where the buddy cache is
		used

		What: /sys/fs/ext4/<disk>/mb_stream_req
		Date: March 2008
		Contact: "Theodore Ts'o" <tytso@mit.edu>
		Description:
		Files which have fewer blocks than this tunable
		parameter will have their blocks allocated out of a
		block group specific preallocation pool, so that small
		files are packed closely together. Each large file
		will have its blocks allocated out of its own unique
		preallocation pool.

		What: /sys/fs/ext4/<disk>/inode_readahead
		Date: March 2008
		Contact: "Theodore Ts'o" <tytso@mit.edu>
		Description:
		Tuning parameter which controls the maximum number of
		inode table blocks that ext4's inode table readahead
		algorithm will pre-read into the buffer cache

		What: /sys/fs/ext4/<disk>/delayed_allocation_blocks
		Date: March 2008
		Contact: "Theodore Ts'o" <tytso@mit.edu>
		Description:
		This file is read-only and shows the number of blocks
		that are dirty in the page cache, but which do not
		have their location in the filesystem allocated yet.

		What: /sys/fs/ext4/<disk>/lifetime_write_kbytes
		Date: March 2008
		Contact: "Theodore Ts'o" <tytso@mit.edu>
		Description:
		This file is read-only and shows the number of kilobytes
		of data that have been written to this filesystem since it was
		created.

		What: /sys/fs/ext4/<disk>/session_write_kbytes
		Date: March 2008
		Contact: "Theodore Ts'o" <tytso@mit.edu>
		Description:
		This file is read-only and shows the number of
		kilobytes of data that have been written to this
		filesystem since it was mounted.

Documentation/DMA-API.txt

+106 −0

Original line number	Diff line number	Diff line
		@@ -609,3 +609,109 @@ size is the size (and should be a page-sized multiple).
		The return value will be either a pointer to the processor virtual
		address of the memory, or an error (via PTR_ERR()) if any part of the
		region is occupied.

		Part III - Debug drivers use of the DMA-API
		-------------------------------------------

		The DMA-API as described above as some constraints. DMA addresses must be
		released with the corresponding function with the same size for example. With
		the advent of hardware IOMMUs it becomes more and more important that drivers
		do not violate those constraints. In the worst case such a violation can
		result in data corruption up to destroyed filesystems.

		To debug drivers and find bugs in the usage of the DMA-API checking code can
		be compiled into the kernel which will tell the developer about those
		violations. If your architecture supports it you can select the "Enable
		debugging of DMA-API usage" option in your kernel configuration. Enabling this
		option has a performance impact. Do not enable it in production kernels.

		If you boot the resulting kernel will contain code which does some bookkeeping
		about what DMA memory was allocated for which device. If this code detects an
		error it prints a warning message with some details into your kernel log. An
		example warning message may look like this:

		------------[ cut here ]------------
		WARNING: at /data2/repos/linux-2.6-iommu/lib/dma-debug.c:448
		check_unmap+0x203/0x490()
		Hardware name:
		forcedeth 0000:00:08.0: DMA-API: device driver frees DMA memory with wrong
		function [device address=0x00000000640444be] [size=66 bytes] [mapped as
		single] [unmapped as page]
		Modules linked in: nfsd exportfs bridge stp llc r8169
		Pid: 0, comm: swapper Tainted: G W 2.6.28-dmatest-09289-g8bb99c0 #1
		Call Trace:
		<IRQ> [<ffffffff80240b22>] warn_slowpath+0xf2/0x130
		[<ffffffff80647b70>] _spin_unlock+0x10/0x30
		[<ffffffff80537e75>] usb_hcd_link_urb_to_ep+0x75/0xc0
		[<ffffffff80647c22>] _spin_unlock_irqrestore+0x12/0x40
		[<ffffffff8055347f>] ohci_urb_enqueue+0x19f/0x7c0
		[<ffffffff80252f96>] queue_work+0x56/0x60
		[<ffffffff80237e10>] enqueue_task_fair+0x20/0x50
		[<ffffffff80539279>] usb_hcd_submit_urb+0x379/0xbc0
		[<ffffffff803b78c3>] cpumask_next_and+0x23/0x40
		[<ffffffff80235177>] find_busiest_group+0x207/0x8a0
		[<ffffffff8064784f>] _spin_lock_irqsave+0x1f/0x50
		[<ffffffff803c7ea3>] check_unmap+0x203/0x490
		[<ffffffff803c8259>] debug_dma_unmap_page+0x49/0x50
		[<ffffffff80485f26>] nv_tx_done_optimized+0xc6/0x2c0
		[<ffffffff80486c13>] nv_nic_irq_optimized+0x73/0x2b0
		[<ffffffff8026df84>] handle_IRQ_event+0x34/0x70
		[<ffffffff8026ffe9>] handle_edge_irq+0xc9/0x150
		[<ffffffff8020e3ab>] do_IRQ+0xcb/0x1c0
		[<ffffffff8020c093>] ret_from_intr+0x0/0xa
		<EOI> <4>---[ end trace f6435a98e2a38c0e ]---

		The driver developer can find the driver and the device including a stacktrace
		of the DMA-API call which caused this warning.

		Per default only the first error will result in a warning message. All other
		errors will only silently counted. This limitation exist to prevent the code
		from flooding your kernel log. To support debugging a device driver this can
		be disabled via debugfs. See the debugfs interface documentation below for
		details.

		The debugfs directory for the DMA-API debugging code is called dma-api/. In
		this directory the following files can currently be found:

		dma-api/all_errors This file contains a numeric value. If this
		value is not equal to zero the debugging code
		will print a warning for every error it finds
		into the kernel log. Be carefull with this
		option. It can easily flood your logs.

		dma-api/disabled This read-only file contains the character 'Y'
		if the debugging code is disabled. This can
		happen when it runs out of memory or if it was
		disabled at boot time

		dma-api/error_count This file is read-only and shows the total
		numbers of errors found.

		dma-api/num_errors The number in this file shows how many
		warnings will be printed to the kernel log
		before it stops. This number is initialized to
		one at system boot and be set by writing into
		this file

		dma-api/min_free_entries
		This read-only file can be read to get the
		minimum number of free dma_debug_entries the
		allocator has ever seen. If this value goes
		down to zero the code will disable itself
		because it is not longer reliable.

		dma-api/num_free_entries
		The current number of free dma_debug_entries
		in the allocator.

		If you have this code compiled into your kernel it will be enabled by default.
		If you want to boot without the bookkeeping anyway you can provide
		'dma_debug=off' as a boot parameter. This will disable DMA-API debugging.
		Notice that you can not enable it again at runtime. You have to reboot to do
		so.

		When the code disables itself at runtime this is most likely because it ran
		out of dma_debug_entries. These entries are preallocated at boot. The number
		of preallocated entries is defined per architecture. If it is too low for you
		boot with 'dma_debug_entries=<your_desired_number>' to overwrite the
		architectural default.