30 Sep, 2015
40 commits
-
commit c54839a722a02818677bcabe57e957f0ce4f841d upstream.
reclaim_clean_pages_from_list() assumes that shrink_page_list() returns
number of pages removed from the candidate list. But shrink_page_list()
puts back mlocked pages without passing it to caller and without
counting as nr_reclaimed. This increases nr_isolated.To fix this, this patch changes shrink_page_list() to pass unevictable
pages back to caller. Caller will take care those pages.Minchan said:
It fixes two issues.
1. With unevictable page, cma_alloc will be successful.
Exactly speaking, cma_alloc of current kernel will fail due to
unevictable pages.2. fix leaking of NR_ISOLATED counter of vmstat
With it, too_many_isolated works. Otherwise, it could make hang until
the process get SIGKILL.Signed-off-by: Jaewon Kim
Acked-by: Minchan Kim
Cc: Mel Gorman
Acked-by: Vlastimil Babka
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit b1b4e435e4ef7de77f07bf2a42c8380b960c2d44 upstream.
When detecting a serial port on newer PA-RISC machines (with iosapic) we have a
long way to go to find the right IRQ line, registering it, then registering the
serial port and the irq handler for the serial port. During this phase spurious
interrupts for the serial port may happen which then crashes the kernel because
the action handler might not have been set up yet.So, basically it's a race condition between the serial port hardware and the
CPU which sets up the necessary fields in the irq sructs. The main reason for
this race is, that we unmask the serial port irqs too early without having set
up everything properly before (which isn't easily possible because we need the
IRQ number to register the serial ports).This patch is a work-around for this problem. It adds checks to the CPU irq
handler to verify if the IRQ action field has been initialized already. If not,
we just skip this interrupt (which isn't critical for a serial port at bootup).
The real fix would probably involve rewriting all PA-RISC specific IRQ code
(for CPU, IOSAPIC, GSC and EISA) to use IRQ domains with proper parenting of
the irq chips and proper irq enabling along this line.This bug has been in the PA-RISC port since the beginning, but the crashes
happened very rarely with currently used hardware. But on the latest machine
which I bought (a C8000 workstation), which uses the fastest CPUs (4 x PA8900,
1GHz) and which has the largest possible L1 cache size (64MB each), the kernel
crashed at every boot because of this race. So, without this patch the machine
would currently be unuseable.For the record, here is the flow logic:
1. serial_init_chip() in 8250_gsc.c calls iosapic_serial_irq().
2. iosapic_serial_irq() calls txn_alloc_irq() to find the irq.
3. iosapic_serial_irq() calls cpu_claim_irq() to register the CPU irq
4. cpu_claim_irq() unmasks the CPU irq (which it shouldn't!)
5. serial_init_chip() then registers the 8250 port.
Problems:
- In step 4 the CPU irq shouldn't have been registered yet, but after step 5
- If serial irq happens between 4 and 5 have finished, the kernel will crashSigned-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman -
commit 1b59ddfcf1678de38a1f8ca9fb8ea5eebeff1843 upstream.
The attached change fixes the condition used in the "sub" instruction.
A double word comparison is needed. This fixes the 64-bit LWS CAS
operation on 64-bit kernels.I can now enable 64-bit atomic support in GCC.
Signed-off-by: John David Anglin
Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman -
commit e02a653e15d8d32e9e768fd99a3271aafe5c5d77 upstream.
Commit 3a9ad0b ("PCI: Add pci_bus_addr_t") unconditionally introduced usage of
64-bit PCI bus addresses on all 64-bit platforms which broke PA-RISC.It turned out that due to enabling the 64-bit addresses, the PCI logic decided
to use the GMMIO instead of the LMMIO region. This commit simply disables
registering the GMMIO and thus we fall back to use the LMMIO region as before.Reverts commit 45ea2a5fed6dacb9bb0558d8b21eacc1c45d5bb4
("PCI: Don't use 64-bit bus addresses on PA-RISC")To: linux-parisc@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: Bjorn Helgaas
Cc: Meelis Roos
Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman -
commit 5f1b2f77646fc0ef2f36fc554f5722a1381d0892 upstream.
Fix RTC write bit as per application manual
Signed-off-by: Mitja Spes
Signed-off-by: Alexandre Belloni
Signed-off-by: Greg Kroah-Hartman -
commit ff02c0444b83201ff76cc49deccac8cf2bffc7bc upstream.
According to datasheet, the S2MPS13X and S2MPS14X should update write
buffer via setting WUDR bit to high after ctrl register is written.If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
tools/testing/selftests/timers/rtctest.c test program and hour format is
used to 12 hour mode in Odroid-XU3 board.One more issue is the RTC doesn't keep time on Odroid-XU3 board when i
turn on board after power off even if RTC battery is connected. It can
be solved as setting WUDR & RUDR bits to high at the same time after
RTC_CTRL register is written. It's same with condition of only writing
ALARM registers, so this is for only S2MPS14 and we should set WUDR &
A_UDR bits to high on S2MPS13.I can't find any reasonable description about this like fix from
datasheet, but can find similar codes from rtc driver source of
hardkernel kernel and vendor kernel.Signed-off-by: Joonyoung Shim
Reviewed-by: Krzysztof Kozlowski
Tested-by: Krzysztof Kozlowski
Signed-off-by: Alexandre Belloni
Signed-off-by: Greg Kroah-Hartman -
commit 1fb1c35f56bb6ab4a65920c648154b0f78f634a5 upstream.
The clock enable/disable codes for alarm have been removed from
commit 24e1455493da ("drivers/rtc/rtc-s3c.c: delete duplicate clock
control") and the clocks are disabled even if alarm is set, so alarm
interrupt can't happen.The s3c_rtc_setaie function can be called several times with 'enabled'
argument having same value, so it needs to check whether clocks are
enabled or not.Signed-off-by: Joonyoung Shim
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Alexandre Belloni
Signed-off-by: Greg Kroah-Hartman -
commit 79234c3db6842a3de03817211d891e0c2878f756 upstream.
Avoid all races with the connect/disconnect handlers by taking the
transport lock.Reported-by:"Suzuki K. Poulose"
Acked-by: Jeff Layton
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 0fdea1e8a2853f79d39b8555cc9de16a7e0ab26f upstream.
Commit 718ba5b87343, moved the responsibility for unlocking the socket to
xs_tcp_setup_socket, meaning that the socket will be unlocked before we
know that it has finished trying to connect. The following patch is based on
an initial patch by Russell King to ensure that we delay clearing the
XPRT_CONNECTING flag until we either know that we failed to initiate
a connection attempt, or the connection attempt itself failed.Fixes: 718ba5b87343 ("SUNRPC: Add helpers to prevent socket create from racing")
Reported-by: Russell King
Reported-by: Russell King
Tested-by: Russell King
Tested-by: Benjamin Coddington
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 0c78789e3a030615c6650fde89546cadf40ec2cc upstream.
In case the reconnection attempt fails.
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 99b1a4c32ad22024ac6198a4337aaec5ea23168f upstream.
It is rather pointless to test the value of transport->inet after
calling xs_reset_transport(), since it will always be zero, and
so we will never see any exponential back off behaviour.
Also don't force early connections for SOFTCONN tasks. If the server
disconnects us, we should respect the exponential backoff.Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 051ac3848a94f21cfdec899cc9c65ce7f9f116fa upstream.
`perf stat -e sunrpc:svc_xprt_do_enqueue true` results in
Warning: unknown op '->'
Warning: [sunrpc:svc_xprt_do_enqueue] unknown op '->'Similar warning for svc_handle_xprt as well.
Actually TP_printk() should never dereference an address saved in the ring
buffer that points somewhere in the kernel. There's no guarantee that that
object still exists (with the exception of static strings).Therefore change all the arguments for TP_printk(), so that it references
values existing in the ring buffer only.While doing that, also fix another possible bug when argument xprt could be
NULL and TP_fast_assign() tries to access it's elements.Signed-off-by: Pratyush Anand
Reviewed-by: Jeff Layton
Acked-by: Steven Rostedt
Fixes: 83a712e0afef "sunrpc: add some tracepoints around ..."
Signed-off-by: J. Bruce Fields
Signed-off-by: Greg Kroah-Hartman -
commit 36319608e28701c07cad80ae3be8b0fdfb1ab40f upstream.
This reverts commit 4e379d36c050b0117b5d10048be63a44f5036115.
This commit opens up a race between the recovery code and the open code.
Reported-by: Olga Kornievskaia
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 4a1e2feb9d246775dee0f78ed5b18826bae2b1c5 upstream.
According to RFC5661 Section 18.2.4, CLOSE is supposed to return
the zero stateid. This means that nfs_clear_open_stateid_locked()
cannot assume that the result stateid will always match the 'other'
field of the existing open stateid when trying to determine a race
with a parallel OPEN.Instead, we look at the argument, and check for matches.
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit d13549074cf066d6d5bb29903d044beffea342d3 upstream.
According to the flexfiles protocol, the layoutreturn should specify an
array of errors in the following format:struct ff_ioerr4 {
offset4 ffie_offset;
length4 ffie_length;
stateid4 ffie_stateid;
device_error4 ffie_errors<>;
};This patch fixes up the code to ensure that our ffie_errors is indeed
encoded as an array (albeit with only a single entry).Reported-by: Tom Haynes
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 5420401079e152ff68a8024f6a375804b1c21505 upstream.
We do not want to update inode attributes with DS values.
Signed-off-by: Peng Tao
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit aaae3f00d3f67f681a1f3cb7af999e976e8a24ce upstream.
If the ctime or mtime or change attribute have changed because
of an operation we initiated, we should make sure that we force
an attribute update. However we do not want to mark the page cache
for revalidation.Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 69f230d907e8c1ca3f9bd528993eeb98f712b0dd upstream.
Otherwise we break fstest case tests/read_write/mctime.t
Does files layout need the same fix as well?
Cc: Anna Schumaker
Signed-off-by: Peng Tao
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit e9ae58aeee8842a50f7e199d602a5ccb2e41a95f upstream.
We should ensure that we always set the pgio_header's error field
if a READ or WRITE RPC call returns an error. The current code depends
on 'hdr->good_bytes' always being initialised to a large value, which
is not always done correctly by callers.
When this happens, applications may end up missing important errors.Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 18e3b739fdc826481c6a1335ce0c5b19b3d415da upstream.
---Steps to Reproduce--
# cat /etc/exports
/nfs/referal *(rw,insecure,no_subtree_check,no_root_squash,crossmnt)
/nfs/old *(ro,insecure,subtree_check,root_squash,crossmnt)# mount -t nfs nfs-server:/nfs/ /mnt/
# ll /mnt/*/# cat /etc/exports
/nfs/referal *(rw,insecure,no_subtree_check,no_root_squash,crossmnt,refer=/nfs/old/@nfs-server)
/nfs/old *(ro,insecure,subtree_check,root_squash,crossmnt)
# service nfs restart# ll /mnt/*/ --->>>>> oops here
[ 5123.102925] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 5123.103363] IP: [] nfs4_proc_get_locations+0x9b/0x120 [nfsv4]
[ 5123.103752] PGD 587b9067 PUD 3cbf5067 PMD 0
[ 5123.104131] Oops: 0000 [#1]
[ 5123.104529] Modules linked in: nfsv4(OE) nfs(OE) fscache(E) nfsd(OE) xfs libcrc32c iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi coretemp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel ppdev vmw_balloon parport_pc parport i2c_piix4 shpchp auth_rpcgss nfs_acl vmw_vmci lockd grace sunrpc vmwgfx drm_kms_helper ttm drm mptspi serio_raw scsi_transport_spi e1000 mptscsih mptbase ata_generic pata_acpi [last unloaded: nfsd]
[ 5123.105887] CPU: 0 PID: 15853 Comm: ::1-manager Tainted: G OE 4.2.0-rc6+ #214
[ 5123.106358] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014
[ 5123.106860] task: ffff88007620f300 ti: ffff88005877c000 task.ti: ffff88005877c000
[ 5123.107363] RIP: 0010:[] [] nfs4_proc_get_locations+0x9b/0x120 [nfsv4]
[ 5123.107909] RSP: 0018:ffff88005877fdb8 EFLAGS: 00010246
[ 5123.108435] RAX: ffff880053f3bc00 RBX: ffff88006ce6c908 RCX: ffff880053a0d240
[ 5123.108968] RDX: ffffea0000e6d940 RSI: ffff8800399a0000 RDI: ffff88006ce6c908
[ 5123.109503] RBP: ffff88005877fe28 R08: ffffffff81c708a0 R09: 0000000000000000
[ 5123.110045] R10: 00000000000001a2 R11: ffff88003ba7f5c8 R12: ffff880054c55800
[ 5123.110618] R13: 0000000000000000 R14: ffff880053a0d240 R15: ffff880053a0d240
[ 5123.111169] FS: 0000000000000000(0000) GS:ffffffff81c27000(0000) knlGS:0000000000000000
[ 5123.111726] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 5123.112286] CR2: 0000000000000000 CR3: 0000000054cac000 CR4: 00000000001406f0
[ 5123.112888] Stack:
[ 5123.113458] ffffea0000e6d940 ffff8800399a0000 00000000000167d0 0000000000000000
[ 5123.114049] 0000000000000000 0000000000000000 0000000000000000 00000000a7ec82c6
[ 5123.114662] ffff88005877fe18 ffffea0000e6d940 ffff8800399a0000 ffff880054c55800
[ 5123.115264] Call Trace:
[ 5123.115868] [] nfs4_try_migration+0xbb/0x220 [nfsv4]
[ 5123.116487] [] nfs4_run_state_manager+0x4ab/0x7b0 [nfsv4]
[ 5123.117104] [] ? nfs4_do_reclaim+0x510/0x510 [nfsv4]
[ 5123.117813] [] kthread+0xd7/0xf0
[ 5123.118456] [] ? kthread_worker_fn+0x160/0x160
[ 5123.119108] [] ret_from_fork+0x3f/0x70
[ 5123.119723] [] ? kthread_worker_fn+0x160/0x160
[ 5123.120329] Code: 4c 8b 6a 58 74 17 eb 52 48 8d 55 a8 89 c6 4c 89 e7 e8 4a b5 ff ff 8b 45 b0 85 c0 74 1c 4c 89 f9 48 8b 55 90 48 8b 75 98 48 89 df ff 55 00 3d e8 d8 ff ff 41 89 c6 74 cf 48 8b 4d c8 65 48 33
[ 5123.121643] RIP [] nfs4_proc_get_locations+0x9b/0x120 [nfsv4]
[ 5123.122308] RSP
[ 5123.122942] CR2: 0000000000000000Fixes: ec011fe847 ("NFS: Introduce a vector of migration recovery ops")
Signed-off-by: Kinglong Mee
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 6f536936b79bd4b5cea8fb0e5b8b0bce8cd1ea4a upstream.
- Switch back to using list_for_each_entry(). Fixes an incorrect test
for list NULL termination.
- Do not assume that lists are sorted.
- Finally, consider an existing entry to match if it consists of a subset
of the addresses in the new entry.Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 7c2dad99d60c86ec686b3bfdcb787c450a7ea89f upstream.
Chuck reports seeing cases where a GETATTR that happens to race
with an asynchronous WRITE is overriding the file size, despite
the attribute barrier being set by the writeback code.The culprit turns out to be the check in nfs_ctime_need_update(),
which sees that the ctime is newer than the cached ctime, and
assumes that it is safe to override the attribute barrier.
This patch removes that override, and ensures that attribute
barriers are always respected.Reported-by: Chuck Lever
Fixes: a08a8cd375db9 ("NFS: Add attribute update barriers to NFS writebacks")
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit efcbc04e16dfa95fef76309f89710dd1d99a5453 upstream.
It is unusual to combine the open flags O_RDONLY and O_EXCL, but
it appears that libre-office does just that.[pid 3250] stat("/home/USER/.config", {st_mode=S_IFDIR|0700, st_size=8192, ...}) = 0
[pid 3250] open("/home/USER/.config/libreoffice/4-suse/user/extensions/buildid", O_RDONLY|O_EXCLNFSv4 takes O_EXCL as a sign that a setattr command should be sent,
probably to reset the timestamps.When it was an O_RDONLY open, the SETATTR command does not
identify any actual attributes to change.
If no delegation was provided to the open, the SETATTR uses the
all-zeros stateid and the request is accepted (at least by the
Linux NFS server - no harm, no foul).If a read-delegation was provided, this is used in the SETATTR
request, and a Netapp filer will justifiably claim
NFS4ERR_BAD_STATEID, which the Linux client takes as a sign
to retry - indefinitely.So only treat O_EXCL specially if O_CREAT was also given.
Signed-off-by: NeilBrown
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 3fcbbd244ed1d20dc0eb7d48d729503992fa9b7d upstream.
It's possible that a DELEGRETURN could race with (e.g.) client expiry,
in which case we could end up putting the delegation hash reference more
than once.Have unhash_delegation_locked return a bool that indicates whether it
was already unhashed. In the case of destroy_delegation we only
conditionally put the hash reference if that returns true.The other callers of unhash_delegation_locked call it while walking
list_heads that shouldn't yet be detached. If we find that it doesn't
return true in those cases, then throw a WARN_ON as that indicates that
we have a partially hashed delegation, and that something is likely very
wrong.Tested-by: Andrew W Elble
Tested-by: Anna Schumaker
Signed-off-by: Jeff Layton
Signed-off-by: J. Bruce Fields
Signed-off-by: Greg Kroah-Hartman -
commit e85687393f3ee0a77ccca016f903d1558bb69258 upstream.
When an open or lock stateid is hashed, we take an extra reference to
it. When we unhash it, we drop that reference. The code however does
not properly account for the case where we have two callers concurrently
trying to unhash the stateid. This can lead to list corruption and the
hash reference being put more than once.Fix this by having unhash_ol_stateid use list_del_init on the st_perfile
list_head, and then testing to see if that list_head is empty before
releasing the hash reference. This means that some of the unhashing
wrappers now become bool return functions so we can test to see whether
the stateid was unhashed before we put the reference.Reported-by: Andrew W Elble
Tested-by: Andrew W Elble
Reported-by: Anna Schumaker
Tested-by: Anna Schumaker
Signed-off-by: Jeff Layton
Signed-off-by: J. Bruce Fields
Signed-off-by: Greg Kroah-Hartman -
commit 6896f15aabde505b35888039af93d1d182a0108a upstream.
Currently we'll respond correctly to a request for either
FS_LAYOUT_TYPES or LAYOUT_TYPES, but not to a request for both
attributes simultaneously.Signed-off-by: Kinglong Mee
Reviewed-by: Christoph Hellwig
Signed-off-by: J. Bruce Fields
Signed-off-by: Greg Kroah-Hartman -
commit 2b83d3de4c18af49800e0b26ae013db4fcf43a4a upstream.
pNFS writes don't return attributes, however that doesn't mean that we
should ignore the fact that they may be extending the file. This patch
ensures that if a write is seen to extend the file, then we always set
an attribute barrier, and update the cached file size.Signed-off-by: Trond Myklebust
Cc: Peng Tao
Signed-off-by: Greg Kroah-Hartman -
commit 1f9b8c8fbc9a4d029760b16f477b9d15500e3a34 upstream.
While we are committing a transaction, it's possible the previous one is
still finishing its commit and therefore we wait for it to finish first.
However we were not checking if that previous transaction ended up getting
aborted after we waited for it to commit, so we ended up committing the
current transaction which can lead to fs corruption because the new
superblock can point to trees that have had one or more nodes/leafs that
were never durably persisted.
The following sequence diagram exemplifies how this is possible:CPU 0 CPU 1
transaction N starts
(...)
btrfs_commit_transaction(N)
cur_trans->state = TRANS_STATE_COMMIT_START;
(...)
cur_trans->state = TRANS_STATE_COMMIT_DOING;
(...)cur_trans->state = TRANS_STATE_UNBLOCKED;
root->fs_info->running_transaction = NULL;btrfs_start_transaction()
--> starts transaction N + 1btrfs_write_and_wait_transaction(trans, root);
--> starts writing all new or COWed ebs created
at transaction Ncreates some new ebs, COWs some
existing ebs but doesn't COW or
deletes eb Xbtrfs_commit_transaction(N + 1)
(...)
cur_trans->state = TRANS_STATE_COMMIT_START;
(...)
wait_for_commit(root, prev_trans);
--> prev_trans == transaction Nbtrfs_write_and_wait_transaction() continues
writing ebs
--> fails writing eb X, we abort transaction N
and set bit BTRFS_FS_STATE_ERROR on
fs_info->fs_state, so no new transactions
can start after setting that bitcleanup_transaction()
btrfs_cleanup_one_transaction()
wakes up task at CPU 1continues, doesn't abort because
cur_trans->aborted (transaction N + 1)
is zero, and no checks for bit
BTRFS_FS_STATE_ERROR in fs_info->fs_state
are madebtrfs_write_and_wait_transaction(trans, root);
--> succeeds, no errors during writebackwrite_ctree_super(trans, root, 0);
--> succeeds
--> we have now a superblock that points us
to some root that uses eb X, which was
never written to diskIn this scenario future attempts to read eb X from disk results in an
error message like "parent transid verify failed on X wanted Y found Z".So fix this by aborting the current transaction if after waiting for the
previous transaction we verify that it was aborted.Signed-off-by: Filipe Manana
Reviewed-by: Josef Bacik
Reviewed-by: Liu Bo
Signed-off-by: Chris Mason
Signed-off-by: Greg Kroah-Hartman -
commit c99235fa3ef833c3c23926085f2bb68851c8460a upstream.
There was a race condition where during cleanup/release operation
on-going streaming would cause a kernel panic because the hardware
module was disabled prematurely with IRQ still pending.Fixes: 417d2e507edc ("[media] media: platform: add VPFE capture driver support for AM437X")
Signed-off-by: Benoit Parrot
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit f47c9045643f91e76d8a9030828b9fe1cf4a6bcf upstream.
Upon a S_FMT the input/requested frame size and pixel format is
overwritten by the current sub-device settings.
Fix this so application can actually set the frame size and format.Fixes: 417d2e507edc ("[media] media: platform: add VPFE capture driver support for AM437X")
Signed-off-by: Benoit Parrot
Acked-by: Lad, Prabhakar
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 9d39f05490115bf145e5ea03c0b7ec9d3d015b01 upstream.
Commit 813f5c0ac5cc ("media: Change media device link_notify behaviour")
modified the media controller link setup notification API and updated the
OMAP3 ISP driver accordingly. As a side effect it introduced a bug by
turning power on after setting the link instead of before. This results in
sub-devices not being powered down in some cases when they should be. Fix
it.Fixes: 813f5c0ac5cc [media] media: Change media device link_notify behaviour
Signed-off-by: Sakari Ailus
Signed-off-by: Laurent Pinchart
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit a66b0c41ad277ae62a3ae6ac430a71882f899557 upstream.
The input_dev is already gone when the rc device is being unregistered
so checking for its presence only means that no remove uevent will be
generated.Signed-off-by: David Härdeman
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 2f064f3485cd29633ad1b3cfb00cc519509a3d72 upstream.
Commit c48a11c7ad26 ("netvm: propagate page->pfmemalloc to skb") added
checks for page->pfmemalloc to __skb_fill_page_desc():if (page->pfmemalloc && !page->mapping)
skb->pfmemalloc = true;It assumes page->mapping == NULL implies that page->pfmemalloc can be
trusted. However, __delete_from_page_cache() can set set page->mapping
to NULL and leave page->index value alone. Due to being in union, a
non-zero page->index will be interpreted as true page->pfmemalloc.So the assumption is invalid if the networking code can see such a page.
And it seems it can. We have encountered this with a NFS over loopback
setup when such a page is attached to a new skbuf. There is no copying
going on in this case so the page confuses __skb_fill_page_desc which
interprets the index as pfmemalloc flag and the network stack drops
packets that have been allocated using the reserves unless they are to
be queued on sockets handling the swapping which is the case here and
that leads to hangs when the nfs client waits for a response from the
server which has been dropped and thus never arrive.The struct page is already heavily packed so rather than finding another
hole to put it in, let's do a trick instead. We can reuse the index
again but define it to an impossible value (-1UL). This is the page
index so it should never see the value that large. Replace all direct
users of page->pfmemalloc by page_is_pfmemalloc which will hide this
nastiness from unspoiled eyes.The information will get lost if somebody wants to use page->index
obviously but that was the case before and the original code expected
that the information should be persisted somewhere else if that is
really needed (e.g. what SLAB and SLUB do).[akpm@linux-foundation.org: fix blooper in slub]
Fixes: c48a11c7ad26 ("netvm: propagate page->pfmemalloc to skb")
Signed-off-by: Michal Hocko
Debugged-by: Vlastimil Babka
Debugged-by: Jiri Bohac
Cc: Eric Dumazet
Cc: David Miller
Acked-by: Mel Gorman
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 9962eea9e55f797f05f20ba6448929cab2a9f018 upstream.
The variable pmd_idx is not initialized for the first iteration of the
for loop.Assign the proper value which indexes the start address.
Fixes: 719272c45b82 'x86, mm: only call early_ioremap_page_table_range_init() once'
Signed-off-by: Minfei Huang
Cc: tony.luck@intel.com
Cc: wangnan0@huawei.com
Cc: david.vrabel@citrix.com
Reviewed-by: yinghai@kernel.org
Link: http://lkml.kernel.org/r/1436703522-29552-1-git-send-email-mhuang@redhat.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 04697858d89e4bf2650364f8d6956e2554e8ef88 upstream.
Tony Luck found on his setup, if memory block size 512M will cause crash
during booting.BUG: unable to handle kernel paging request at ffffea0074000020
IP: get_nid_for_pfn+0x17/0x40
PGD 128ffcb067 PUD 128ffc9067 PMD 0
Oops: 0000 [#1] SMP
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.2.0-rc8 #1
...
Call Trace:
? register_mem_sect_under_node+0x66/0xe0
register_one_node+0x17b/0x240
? pci_iommu_alloc+0x6e/0x6e
topology_init+0x3c/0x95
do_one_initcall+0xcd/0x1f0The system has non continuous RAM address:
BIOS-e820: [mem 0x0000001300000000-0x0000001cffffffff] usable
BIOS-e820: [mem 0x0000001d70000000-0x0000001ec7ffefff] usable
BIOS-e820: [mem 0x0000001f00000000-0x0000002bffffffff] usable
BIOS-e820: [mem 0x0000002c18000000-0x0000002d6fffefff] usable
BIOS-e820: [mem 0x0000002e00000000-0x00000039ffffffff] usableSo there are start sections in memory block not present. For example:
memory block : [0x2c18000000, 0x2c20000000) 512M
first three sections are not present.
The current register_mem_sect_under_node() assume first section is
present, but memory block section number range [start_section_nr,
end_section_nr] would include not present section.For arch that support vmemmap, we don't setup memmap for struct page
area within not present sections area.So skip the pfn range that belong to absent section.
[akpm@linux-foundation.org: simplification]
[rientjes@google.com: more simplification]
Fixes: bdee237c0343 ("x86: mm: Use 2GB memory block size on large memory x86-64 systems")
Fixes: 982792c782ef ("x86, mm: probe memory block size for generic x86 64bit")
Signed-off-by: Yinghai Lu
Signed-off-by: David Rientjes
Reported-by: Tony Luck
Tested-by: Tony Luck
Cc: Greg KH
Cc: Ingo Molnar
Tested-by: David Rientjes
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 09bfda10e6efd7b65bcc29237bee1765ed779657 upstream.
With the radeon driver loaded the HP Compaq dc5750
Small Form Factor machine fails to resume from suspend.
Adding a quirk similar to other devices avoids
the problem and the system resumes properly.Signed-off-by: Jeffery Miller
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 4c17a6d56bb0cad3066a714e94f7185a24b40f49 upstream.
This might lead to local privilege escalation (code execution as
kernel) for systems where the following conditions are met:- CONFIG_CIFS_SMB2 and CONFIG_CIFS_POSIX are enabled
- a cifs filesystem is mounted where:
- the mount option "vers" was used and set to a value >=2.0
- the attacker has write access to at least one file on the filesystemTo attack this, an attacker would have to guess the target_tcon
pointer (but guessing wrong doesn't cause a crash, it just returns an
error code) and win a narrow race.Signed-off-by: Jann Horn
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman -
commit 36b35d5d807b7e57aff7d08e63de8b17731ee211 upstream.
If we had secondary hash flag set, we ended up modifying hash value in
the updatepp code path. Hence with a failed updatepp we will be using
a wrong hash value for the following hash insert. Fix this by
recomputing hash before insert.Without this patch we can end up with using wrong slot number in linux
pte. That can result in us missing an hash pte update or invalidate
which can cause memory corruption or even machine check.Fixes: 6d492ecc6489 ("powerpc/THP: Add code to handle HPTE faults for hugepages")
Signed-off-by: Aneesh Kumar K.V
Reviewed-by: Paul Mackerras
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman -
commit 655471f54c2e395ba29ae4156ba0f49928177cc1 upstream.
The kernel does it, not the boot wrapper, which breaks with some
cross compilers that still default to ABI v1.Fixes: 147c05168fc8 ("powerpc/boot: Add support for 64bit little endian wrapper")
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman -
commit 2d6f0600b2cd755959527230ef5a6fba97bb762a upstream.
vmx-crypto driver make use of some VSX instructions which are
only available if VSX is enabled. Running in cases where VSX
are not enabled vmx-crypto fails in a VSX exception.In order to fix this enable_kernel_vsx() was added to turn on
VSX instructions for vmx-crypto.Signed-off-by: Leonidas S. Barbosa
Signed-off-by: Herbert Xu
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman
