This patch adds polling mode support for i2c s3c-2410 driver.
The I2C_SATAPHY controller lacks an interrupt line but the s3c-2410 driver
is interrupt driven. Hence this support is required for functioning
of the I2C_SATAPHY controller.
Vasanth Ananthan [Tue, 30 Oct 2012 11:29:33 +0000 (12:29 +0100)]
DRIVERS: ATA: SATA PHY utility framework
This patch adds SATA PHY utility framework APIs. The framework acts as an
interface between the SATA device and the PHY device. The SATA PHY device
registers itself with the framework through the APIs provided and the SATA
device finds and requests for an appropriate PHY device.
thermal: exynos: Use the new thermal trend type for quick cooling action.
This patch uses the quick thermal cooling trend type macros. This is needed
as exynos5 and other thermal sensors now supports only interrupt method for
thresold temperature check.
Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@linaro.org>
thermal: exynos: Miscellaneous fixes to support falling threshold interrupt
Below fixes are done to support falling threshold interrupt,
* Falling interrupt status macro corrected according to exynos5 data sheet.
* The get trend function modified to calculate trip temperature correctly.
* The clearing of interrupt status in the isr is now done after handling
the event that caused the interrupt.
Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@linaro.org>
Thermal: exynos: Add support for temperature falling interrupt.
This patch introduces using temperature falling interrupt in exynos
thermal driver. Former patch, it only use polling way to check
whether if system themperature is fallen. However, exynos SOC also
provides temperature falling interrupt way to do same things by hw.
This feature is not supported in exynos4210.
Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com> Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
regulator: s5m8767: Fix to read the first DVS register.
This patch modifies the DVS register read function to select correct DVS1
register. This change is required because the GPIO select pin is 000 in
unintialized state and hence selects the DVS1 register.
Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
exynos:exynos5: Change I2C interrupt to low speed mode
By default the I2C controllers(0,1,2,3) are configured as high speed so resetting
them to low speed during bootup. As and when needed they can reconfigured again
to speed.
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Thomas Abraham [Fri, 23 Nov 2012 08:03:14 +0000 (13:33 +0530)]
regulator: max8997: limit the number of dvs registers programmed in non-dvs mode
In case the gpio based volatage selection mode is not used for either of
buck 1/2/5, then only the BUCKxDVS1 register need to be programmed. So
determine whether dvs mode is used and limit the loop count appropriately.
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org> Reviewed-by: Tomasz Figa <t.figa@samsung.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The BUCKxDVSx register programming is now moved prior to setting up of the
gpio based dvs mode. This will ensure that all the BUCKxDVSx registers
are programmed with appropriate voltage values before the gpio based dvs
mode is selected for buck1/2/5.
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org> Reviewed-by: Tomasz Figa <t.figa@samsung.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Steve Capper [Wed, 26 Dec 2012 05:42:13 +0000 (11:12 +0530)]
RM: mm: Add NUMA support.
This patch adds support for NUMA (running on either discontiguous
and sparse memory).
At the moment, the number of nodes has to be specified on the
commandline. One can also, optionally, specify the memory size of
each node. (Otherwise the memory range is split roughly equally
between nodes).
CPUs can be striped across nodes (cpu number modulo the number of
nodes), or assigned to a node based on their
topology_physical_package_id. So for instance on a TC2, the A7
cores can be grouped together in one node and the A15s grouped
together in another node.
Signed-off-by: Steve Capper <steve.capper@arm.com>
Steve Capper [Thu, 29 Nov 2012 15:14:14 +0000 (15:14 +0000)]
ARM: Consider memblocks in mem_init and show_mem.
This is based on Michael Spang's patch [1]; and is my attempt at
applying the feedback from Russell [2].
With discontiguous memory (a requirement for running NUMA on some
systems), membanks may not necessarily be representable as
contiguous blocks of struct page *s. This patch updates the page
scanning code in mem_init and show_mem to consider pages in the
intersection of membanks and memblocks instead.
We can't consider memblocks solely as under sparse memory
configurations, contiguous physical membanks won't necessarily have
a contiguous memory map (but may be merged into the same memblock).
Only memory blocks in the "memory" region were considered as the
"reserved" region was found to always overlap "memory"; all the
memory banks are added with memblock_add (which adds to "memory")
and no instances were found where memory was added to "reserved"
then removed from "memory".
In mem_init we are running on one CPU, and I can't see the
memblocks changing whilst being enumerated.
In show_mem, we can be running on multiple CPUs; whilst the
memblock manipulation functions are annotated as __init, this
doesn't stop memblocks being manipulated during bootup. I can't
see any place where memblocks are removed or merged other than
driver initialisation (memblock_steal) or boot memory
initialisation.
One consequence of using memblocks in show_mem, is that we are
unable to define ARCH_DISCARD_MEMBLOCK.
ARM: mm: Transparent huge page support for LPAE systems.
The patch adds support for THP (transparent huge pages) to LPAE systems. When
this feature is enabled, the kernel tries to map anonymous pages as 2MB
sections where possible.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
[steve.capper@arm.com: symbolic constants used, value of PMD_SECT_SPLITTING
adjusted, tlbflush.h included in pgtable.h] Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Steve Capper <steve.capper@arm.com>
Steve Capper [Thu, 19 Jul 2012 10:57:45 +0000 (11:57 +0100)]
ARM: mm: HugeTLB support for non-LPAE systems.
Based on Bill Carson's HugeTLB patch, with the big difference being in the way
PTEs are passed back to the memory manager. Rather than store a "Linux Huge
PTE" separately; we make one up on the fly in huge_ptep_get. Also rather than
consider 16M supersections, we focus solely on 2x1M sections.
To construct a huge PTE on the fly we need additional information (such as the
accessed flag and dirty bit) which we choose to store in the domain bits of the
short section descriptor. In order to use these domain bits for storage, we need
to make ourselves a client for all 16 domains and this is done in head.S.
Storing extra information in the domain bits also makes it a lot easier to
implement Transparent Huge Pages, and some of the code in pgtable-2level.h is
arranged to facilitate THP support in a later patch.
Non-LPAE HugeTLB pages are incompatible with the huge page migration code
(enabled when CONFIG_MEMORY_FAILURE is selected) as that code dereferences PTEs
directly, rather than calling huge_ptep_get and set_huge_pte_at.
Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Steve Capper <steve.capper@arm.com>
This patch adds support for hugetlbfs based on the x86 implementation.
It allows mapping of 2MB sections (see Documentation/vm/hugetlbpage.txt
for usage). The 64K pages configuration is not supported (section size
is 512MB in this case).
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
[steve.capper@arm.com: symbolic constants replace numbers in places.
Split up into multiple files, to simplify future non-LPAE support]. Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Steve Capper <steve.capper@arm.com>
Steve Capper [Thu, 19 Jul 2012 10:51:50 +0000 (11:51 +0100)]
ARM: mm: Add support for flushing HugeTLB pages.
On ARM we use the __flush_dcache_page function to flush the dcache of pages
when needed; usually when the PG_dcache_clean bit is unset and we are setting a
PTE.
A HugeTLB page is represented as a compound page consisting of an array of
pages. Thus to flush the dcache of a HugeTLB page, one must flush more than a
single page.
This patch modifies __flush_dcache_page such that all constituent pages of a
HugeTLB page are flushed.
Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Steve Capper <steve.capper@arm.com>
This allows us to define L_PTE_PRESENT as (3 << 0) and use this value to
create ptes directly. However, when determining whether a given pte
value is present in the low-level page table accessors, we only need to
check the least significant bit of the descriptor, allowing us to write
faulting, present entries which are required for PROT_NONE mappings.
This patch introduces L_PTE_VALID, which can be used to test whether a
pte should fault, and updates the low-level page table accessors
accordingly.
Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Steve Capper <steve.capper@arm.com>
Will Deacon [Tue, 2 Oct 2012 10:18:52 +0000 (11:18 +0100)]
mm: thp: Set the accessed flag for old pages on access fault.
On x86 memory accesses to pages without the ACCESSED flag set result in the
ACCESSED flag being set automatically. With the ARM architecture a page access
fault is raised instead (and it will continue to be raised until the ACCESSED
flag is set for the appropriate PTE/PMD).
For normal memory pages, handle_pte_fault will call pte_mkyoung (effectively
setting the ACCESSED flag). For transparent huge pages, pmd_mkyoung will only
be called for a write fault.
This patch ensures that faults on transparent hugepages which do not result
in a CoW update the access flags for the faulting pmd.
Cc: Chris Metcalf <cmetcalf@tilera.com> Acked-by: Kirill A. Shutemov <kirill@shutemov.name> Reviewed-by: Andrea Arcangeli <aarcange@redhat.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Steve Capper <steve.capper@arm.com>
Subash Patel [Mon, 10 Dec 2012 11:50:45 +0000 (17:20 +0530)]
ARM: OF: update coherent_dma_mask
This patch is tested in ARM:exynos5250 with LPAE enabled. The coherent_dma_mask
needs to be defined to DMA_BIT_MASK(64) as dma-mapping API's check it against
64-bit mask.
Subash Patel [Wed, 5 Dec 2012 05:07:49 +0000 (10:37 +0530)]
ARM: exynos: add coherent dma mask
This patch adds the coherent_dma_mask to usb/dwc3 node. This is
needed as check is performed before allocating any coherent buffer
in the dma-mapping framework.
Subash Patel [Wed, 5 Dec 2012 05:04:19 +0000 (10:34 +0530)]
ARM: exynos: add coherent_dma_mask
This patch adds the coherent_dma_mask for the dw_mmc device.
This is needed as check is now done in dma-mapping framework before
allocating the buffers.
Subash Patel [Tue, 4 Dec 2012 12:35:18 +0000 (18:05 +0530)]
NET: eth: ax88796: fixup for LPAE
This patch adds condition for variables declared of type
resource_size_t. When LPAE is enabled, these will be 64-bit,
but the linker will throw error for missing __aeabi_uldivmod
support in lib1funcs.s. This patch may be safetly reverted
when this is added.
Subash Patel [Mon, 3 Dec 2012 09:21:55 +0000 (14:51 +0530)]
ARM: LPAE: accomodate >32-bit addresses for page table base
This patch redefines the early boot time use of the R4 register to steal a few
low order bits (ARCH_PGD_SHIFT bits) on LPAE systems. This allows for up to
38-bit physical addresses.
Signed-off-by: Cyril Chemparathy <cyril@ti.com> Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Hand-edited as this patch in eml format doesnt apply due to missing blob data
for arch/arm/include/asm/memory.h Signed-off-by: Subash Patel <subash.rp@samsung.com>
This patch cleans up the highmem sanity check code by simplifying the range
checks with a pre-calculated size_limit. This patch should otherwise have no
functional impact on behavior.
This patch also removes a redundant (bank->start < vmalloc_limit) check, since
this is already covered by the !highmem condition.
ARM: mm: cleanup checks for membank overlap with vmalloc area
On Keystone platforms, physical memory is entirely outside the 32-bit
addressible range. Therefore, the (bank->start > ULONG_MAX) check below marks
the entire system memory as highmem, and this causes unpleasentness all over.
This patch eliminates the extra bank start check (against ULONG_MAX) by
checking bank->start against the physical address corresponding to vmalloc_min
instead.
In the process, this patch also cleans up parts of the highmem sanity check
code by removing what has now become a redundant check for banks that entirely
overlap with the vmalloc range.
ARM: mm: use physical addresses in highmem sanity checks
This patch modifies the highmem sanity checking code to use physical addresses
instead. This change eliminates the wrap-around problems associated with the
original virtual address based checks, and this simplifies the code a bit.
The one constraint imposed here is that low physical memory must be mapped in
a monotonically increasing fashion if there are multiple banks of memory,
i.e., x < y must => pa(x) < pa(y).
This patch moves the TTBR1 offset calculation and the T1SZ calculation out
of the TTB setup assembly code. This should not affect functionality in
any way, but improves code readability as well as readability of subsequent
patches in this series.
ARM: LPAE: define ARCH_LOW_ADDRESS_LIMIT for bootmem
This patch adds an architecture defined override for ARCH_LOW_ADDRESS_LIMIT.
On PAE systems, the absence of this override causes bootmem to incorrectly
limit itself to 32-bit addressable physical memory.
This patch modifies the switch_mm() processor functions to use phys_addr_t.
On LPAE systems, we now honor the upper 32-bits of the physical address that
is being passed in, and program these into TTBR as expected.
ARM: LPAE: use phys_addr_t for initrd location and size
This patch fixes the initrd setup code to use phys_addr_t instead of assuming
32-bit addressing. Without this we cannot boot on systems where initrd is
located above the 4G physical address limit.
The free_memmap() was mistakenly using unsigned long type to represent
physical addresses. This breaks on PAE systems where memory could be placed
above the 32-bit addressible limit.
This patch fixes this function to properly use phys_addr_t instead.
This patch fixes the alloc_init_pud() function to use phys_addr_t instead of
unsigned long when passing in the phys argument.
This is an extension to commit 97092e0c56830457af0639f6bd904537a150ea4a (ARM:
pgtable: use phys_addr_t for physical addresses), which applied similar changes
elsewhere in the ARM memory management code.
ARM: LPAE: use signed arithmetic for mask definitions
This patch applies to PAGE_MASK, PMD_MASK, and PGDIR_MASK, where forcing
unsigned long math truncates the mask at the 32-bits. This clearly does bad
things on PAE systems.
This patch fixes this problem by defining these masks as signed quantities.
We then rely on sign extension to do the right thing.
This patch adds support for 64-bit physical addresses in virt_to_phys()
patching. This does not do real 64-bit add/sub, but instead patches in the
upper 32-bits of the phys_offset directly into the output of virt_to_phys.
There is no corresponding change on the phys_to_virt() side, because
computations on the upper 32-bits would be discarded anyway.
This patch adds basic sanity tests to ensure that the instruction patching
results in valid instruction encodings. This is done by verifying the output
of the patch process against a vector of assembler generated instructions at
init time.
The original phys_to_virt/virt_to_phys patching implementation relied on early
patching prior to MMU initialization. On PAE systems running out of >4G
address space, this would have entailed an additional round of patching after
switching over to the high address space.
The approach implemented here conceptually extends the original PHYS_OFFSET
patching implementation with the introduction of "early" patch stubs. Early
patch code is required to be functional out of the box, even before the patch
is applied. This is implemented by inserting functional (but inefficient)
load code into the .runtime.patch.code init section. Having functional code
out of the box then allows us to defer the init time patch application until
later in the init sequence.
In addition to fitting better with our need for physical address-space
switch-over, this implementation should be somewhat more extensible by virtue
of its more readable (and hackable) C implementation. This should prove
useful for other similar init time specialization needs, especially in light
of our multi-platform kernel initiative.
This code has been boot tested in both ARM and Thumb-2 modes on an ARMv7
(Cortex-A8) device.
Note: the obtuse use of stringified symbols in patch_stub() and
early_patch_stub() is intentional. Theoretically this should have been
accomplished with formal operands passed into the asm block, but this requires
the use of the 'c' modifier for instantiating the long (e.g. .long %c0).
However, the 'c' modifier has been found to ICE certain versions of GCC, and
therefore we resort to stringified symbols here.
Signed-off-by: Cyril Chemparathy <cyril@ti.com> Reviewed-by: Nicolas Pitre <nico@linaro.org>
Florian Fainelli [Mon, 10 Dec 2012 20:25:32 +0000 (12:25 -0800)]
Input: matrix-keymap - provide proper module license
The matrix-keymap module is currently lacking a proper module license,
add one so we don't have this module tainting the entire kernel. This
issue has been present since commit 1932811f426f ("Input: matrix-keymap
- uninline and prepare for device tree support")
1) Netlink socket dumping had several missing verifications and checks.
In particular, address comparisons in the request byte code
interpreter could access past the end of the address in the
inet_request_sock.
Also, address family and address prefix lengths were not validated
properly at all.
This means arbitrary applications can read past the end of certain
kernel data structures.
Fixes from Neal Cardwell.
2) ip_check_defrag() operates in contexts where we're in the process
of, or about to, input the packet into the real protocols
(specifically macvlan and AF_PACKET snooping).
Unfortunately, it does a pskb_may_pull() which can modify the
backing packet data which is not legal if the SKB is shared. It
very much can be shared in this context.
Deal with the possibility that the SKB is segmented by using
skb_copy_bits().
Fix from Johannes Berg based upon a report by Eric Leblond.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
ipv4: ip_check_defrag must not modify skb before unsharing
inet_diag: validate port comparison byte code to prevent unsafe reads
inet_diag: avoid unsafe and nonsensical prefix matches in inet_diag_bc_run()
inet_diag: validate byte code to prevent oops in inet_diag_bc_run()
inet_diag: fix oops for IPv4 AF_INET6 TCP SYN-RECV state
This is a revert of a revert of a revert. In addition, it reverts the
even older i915 change to stop using the __GFP_NO_KSWAPD flag due to the
original commits in linux-next.
It turns out that the original patch really was bogus, and that the
original revert was the correct thing to do after all. We thought we
had fixed the problem, and then reverted the revert, but the problem
really is fundamental: waking up kswapd simply isn't the right thing to
do, and direct reclaim sometimes simply _is_ the right thing to do.
When certain allocations fail, we simply should try some direct reclaim,
and if that fails, fail the allocation. That's the right thing to do
for THP allocations, which can easily fail, and the GPU allocations want
to do that too.
So starting kswapd is sometimes simply wrong, and removing the flag that
said "don't start kswapd" was a mistake. Let's hope we never revisit
this mistake again - and certainly not this many times ;)
Acked-by: Mel Gorman <mgorman@suse.de> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Rik van Riel <riel@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Johannes Berg [Sun, 9 Dec 2012 23:41:06 +0000 (23:41 +0000)]
ipv4: ip_check_defrag must not modify skb before unsharing
ip_check_defrag() might be called from af_packet within the
RX path where shared SKBs are used, so it must not modify
the input SKB before it has unshared it for defragmentation.
Use skb_copy_bits() to get the IP header and only pull in
everything later.
The same is true for the other caller in macvlan as it is
called from dev->rx_handler which can also get a shared SKB.
Reported-by: Eric Leblond <eric@regit.org> Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
We are going to reinstate the __GFP_NO_KSWAPD flag that has been
removed, the removal reverted, and then removed again. Making this
commit a pointless fixup for a problem that was caused by the removal of
__GFP_NO_KSWAPD flag.
The thing is, we really don't want to wake up kswapd for THP allocations
(because they fail quite commonly under any kind of memory pressure,
including when there is tons of memory free), and these patches were
just trying to fix up the underlying bug: the original removal of
__GFP_NO_KSWAPD in commit c654345924f7 ("mm: remove __GFP_NO_KSWAPD")
was simply bogus.
Neal Cardwell [Sun, 9 Dec 2012 11:09:54 +0000 (11:09 +0000)]
inet_diag: validate port comparison byte code to prevent unsafe reads
Add logic to verify that a port comparison byte code operation
actually has the second inet_diag_bc_op from which we read the port
for such operations.
Previously the code blindly referenced op[1] without first checking
whether a second inet_diag_bc_op struct could fit there. So a
malicious user could make the kernel read 4 bytes beyond the end of
the bytecode array by claiming to have a whole port comparison byte
code (2 inet_diag_bc_op structs) when in fact the bytecode was not
long enough to hold both.
Signed-off-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Neal Cardwell [Sat, 8 Dec 2012 19:43:23 +0000 (19:43 +0000)]
inet_diag: avoid unsafe and nonsensical prefix matches in inet_diag_bc_run()
Add logic to check the address family of the user-supplied conditional
and the address family of the connection entry. We now do not do
prefix matching of addresses from different address families (AF_INET
vs AF_INET6), except for the previously existing support for having an
IPv4 prefix match an IPv4-mapped IPv6 address (which this commit
maintains as-is).
This change is needed for two reasons:
(1) The addresses are different lengths, so comparing a 128-bit IPv6
prefix match condition to a 32-bit IPv4 connection address can cause
us to unwittingly walk off the end of the IPv4 address and read
garbage or oops.
(2) The IPv4 and IPv6 address spaces are semantically distinct, so a
simple bit-wise comparison of the prefixes is not meaningful, and
would lead to bogus results (except for the IPv4-mapped IPv6 case,
which this commit maintains).
Signed-off-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Neal Cardwell [Sat, 8 Dec 2012 19:43:22 +0000 (19:43 +0000)]
inet_diag: validate byte code to prevent oops in inet_diag_bc_run()
Add logic to validate INET_DIAG_BC_S_COND and INET_DIAG_BC_D_COND
operations.
Previously we did not validate the inet_diag_hostcond, address family,
address length, and prefix length. So a malicious user could make the
kernel read beyond the end of the bytecode array by claiming to have a
whole inet_diag_hostcond when the bytecode was not long enough to
contain a whole inet_diag_hostcond of the given address family. Or
they could make the kernel read up to about 27 bytes beyond the end of
a connection address by passing a prefix length that exceeded the
length of addresses of the given family.
Signed-off-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Neal Cardwell [Sat, 8 Dec 2012 19:43:21 +0000 (19:43 +0000)]
inet_diag: fix oops for IPv4 AF_INET6 TCP SYN-RECV state
Fix inet_diag to be aware of the fact that AF_INET6 TCP connections
instantiated for IPv4 traffic and in the SYN-RECV state were actually
created with inet_reqsk_alloc(), instead of inet6_reqsk_alloc(). This
means that for such connections inet6_rsk(req) returns a pointer to a
random spot in memory up to roughly 64KB beyond the end of the
request_sock.
With this bug, for a server using AF_INET6 TCP sockets and serving
IPv4 traffic, an inet_diag user like `ss state SYN-RECV` would lead to
inet_diag_fill_req() causing an oops or the export to user space of 16
bytes of kernel memory as a garbage IPv6 address, depending on where
the garbage inet6_rsk(req) pointed.
Signed-off-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Johannes Weiner [Thu, 6 Dec 2012 20:23:25 +0000 (15:23 -0500)]
mm: vmscan: fix inappropriate zone congestion clearing
commit c702418f8a2f ("mm: vmscan: do not keep kswapd looping forever due
to individual uncompactable zones") removed zone watermark checks from
the compaction code in kswapd but left in the zone congestion clearing,
which now happens unconditionally on higher order reclaim.
This messes up the reclaim throttling logic for zones with
dirty/writeback pages, where zones should only lose their congestion
status when their watermarks have been restored.
Remove the clearing from the zone compaction section entirely. The
preliminary zone check and the reclaim loop in kswapd will clear it if
the zone is considered balanced.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Reviewed-by: Rik van Riel <riel@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Sat, 8 Dec 2012 00:48:39 +0000 (16:48 -0800)]
vfs: fix O_DIRECT read past end of block device
The direct-IO write path already had the i_size checks in mm/filemap.c,
but it turns out the read path did not, and removing the block size
checks in fs/block_dev.c (commit bbec0270bdd8: "blkdev_max_block: make
private to fs/buffer.c") removed the magic "shrink IO to past the end of
the device" code there.
Fix it by truncating the IO to the size of the block device, like the
write path already does.
NOTE! I suspect the write path would be *much* better off doing it this
way in fs/block_dev.c, rather than hidden deep in mm/filemap.c. The
mm/filemap.c code is extremely hard to follow, and has various
conditionals on the target being a block device (ie the flag passed in
to 'generic_write_checks()', along with a conditional update of the
inode timestamp etc).
It is also quite possible that we should treat this whole block device
size as a "s_maxbytes" issue, and try to make the logic even more
generic. However, in the meantime this is the fairly minimal targeted
fix.
Noted by Milan Broz thanks to a regression test for the cryptsetup
reencrypt tool.
Reported-and-tested-by: Milan Broz <mbroz@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
projects / people / aperard / linux-arndale.git / log