With a cross-compiler based on gcc-4.9, I see warnings like the following:
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'mlx4_SW2HW_CQ_wrapper':
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3048:10: error: 'cq' may be used uninitialized in this function [-Werror=maybe-uninitialized]
cq->mtt = mtt;
I think the warning is spurious because we only use cq when
cq_res_start_move_to() returns zero, and it always initializes *cq in that
case. The srq case is similar. But maybe gcc isn't smart enough to figure
that out.
Initialize cq and srq explicitly to avoid the warnings.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
It was reported that trancerout6 would cause
a kernel to crash when trying to compute checksums
on raw UDP packets. The cause was the check in
__ip6_append_data that would attempt to use
partial checksums on the packet. However,
raw sockets do not initialize partial checksum
fields so partial checksums can't be used.
Solve this the same way IPv4 does it. raw sockets
pass transhdrlen value of 0 to ip_append_data which
causes the checksum to be computed in software. Use
the same check in ip6_append_data (check transhdrlen).
Reported-by: Wolfgang Walter <linux@stwm.de>
CC: Wolfgang Walter <linux@stwm.de>
CC: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
- The recent ACPICA commit that set the ACPI _REV return value to 2
(which is the value always used by Windows and now mandated by the
spec too) in order to prevent the firmware people from using it to
play tricks with us caused a serious audio regression to happen on
Dell XPS 13 (the AML on that machine uses the _REV return value to
decide how to expose audio to the OS and does that to hide the
lack of proper support for its I2S audio in Linux), so revert that
commit for now and we'll revisit the issue in the next cycle.
- Ensure that the ordering of acpi_reserve_resources() with respect
to the rest of the ACPI initialization sequence will always be
the same, or the IO or memory region occupied by the ACPI fixed
registers may be assigned to a PCI host bridge as a result of
a race and random breakage ensues going forward.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJVVS6SAAoJEILEb/54YlRxGNUP/jnRBNZhzIFWJxkbVJ/IQgXI
g5HFO/ebdGqSyAEuXHZFzdNJv52WBsWurESHvCKyh4n+c0m6CIoKpXeNRFZyZJIU
tPZhF9IzeuuLXz+MuR0V+9D45UFoBZFScqTqihw13kM1/DnRmKN/BSO4EdxDSzno
zcUPXfUl8Od8erbAD5E3U0EnzEiM2nrg/PPmVs+DM1qYg5NVAFBniF44R47dvz0D
yAKTjlQg8FouYw4gmD0E79n3ydL0A6S+TdNV+u/MYRHg7cq/P6kXvjNJncKTIof0
WqbXBB9ZvcAfyltf10Me5E61pfhxM0a4Ufjr5z9NtSlXpwadeSUnFqP6zWsAbwBJ
dU0apeZSGT2J+CuDzwyBmBkN3kT0i/97C8Yd7/K2lhy+GR148Zn6X6Cwk3C8LIwd
w1dcXnoN50zk5FqC72GYGUFJEFYrlmmmeT9jQohNFURWlawYZ1HGJoXb3oQzA9j7
HFM1Eor8UdlAMtvQ2aNGeHRorHVqsoSpzWZbQs5sCTL6qh69/ufKJzKRa/eAMm5k
Fnf+hEuALhEe2S7EvbaHC04xvZie0HXoJR91+Tk4I9FUYXuxJojKbwLPKWMcr/p4
ZXBTVdiUxWwd7Ey5Ckt9xNWmVwFKAruZp+hSYhl+iciyHYNHTjbx+a82+cTmcwd/
sWSno6EBixqDfhEN4Fo8
=N6C9
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-4.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fixes from Rafael Wysocki:
"Two fixes here, one revert of a recent ACPICA commit that broke audio
support on one Dell machine and a fix for a long-standing issue that
may cause systems to break randomly during boot.
Specifics:
- The recent ACPICA commit that set the ACPI _REV return value to 2
(which is the value always used by Windows and now mandated by the
spec too) in order to prevent the firmware people from using it to
play tricks with us caused a serious audio regression to happen on
Dell XPS 13 (the AML on that machine uses the _REV return value to
decide how to expose audio to the OS and does that to hide the lack
of proper support for its I2S audio in Linux), so revert that
commit for now and we'll revisit the issue in the next cycle.
- Ensure that the ordering of acpi_reserve_resources() with respect
to the rest of the ACPI initialization sequence will always be the
same, or the IO or memory region occupied by the ACPI fixed
registers may be assigned to a PCI host bridge as a result of a
race and random breakage ensues going forward"
* tag 'pm+acpi-4.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
Revert "ACPICA: Permanently set _REV to the value '2'."
ACPI / init: Fix the ordering of acpi_reserve_resources()
Pull dmi fixes from Jean Delvare.
* 'dmi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging:
firmware: dmi_scan: Fix ordering of product_uuid
firmware: dmi_scan: Simplified displayed version
NUMA balancing is meant to be disabled by default on UMA machines but
the check is using nr_node_ids (highest node) instead of
num_online_nodes (online nodes).
The consequences are that a UMA machine with a node ID of 1 or higher
will enable NUMA balancing. This will incur useless overhead due to
minor faults with the impact depending on the workload. These are the
impact on the stats when running a kernel build on a single node machine
whose node ID happened to be 1:
vanilla patched
NUMA base PTE updates 5113158 0
NUMA huge PMD updates 643 0
NUMA page range updates 5442374 0
NUMA hint faults 2109622 0
NUMA hint local faults 2109622 0
NUMA hint local percent 100 100
NUMA pages migrated 0 0
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: <stable@vger.kernel.org> [3.8+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I had an issue:
Unable to handle kernel NULL pointer dereference at virtual address 0000082a
pgd = cc970000
[0000082a] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
PC is at get_pageblock_flags_group+0x5c/0xb0
LR is at unset_migratetype_isolate+0x148/0x1b0
pc : [<c00cc9a0>] lr : [<c0109874>] psr: 80000093
sp : c7029d00 ip : 00000105 fp : c7029d1c
r10: 00000001 r9 : 0000000a r8 : 00000004
r7 : 60000013 r6 : 000000a4 r5 : c0a357e4 r4 : 00000000
r3 : 00000826 r2 : 00000002 r1 : 00000000 r0 : 0000003f
Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c5387d Table: 2cb7006a DAC: 00000015
Backtrace:
get_pageblock_flags_group+0x0/0xb0
unset_migratetype_isolate+0x0/0x1b0
undo_isolate_page_range+0x0/0xdc
__alloc_contig_range+0x0/0x34c
alloc_contig_range+0x0/0x18
This issue is because when calling unset_migratetype_isolate() to unset
a part of CMA memory, it try to access the buddy page to get its status:
if (order >= pageblock_order) {
page_idx = page_to_pfn(page) & ((1 << MAX_ORDER) - 1);
buddy_idx = __find_buddy_index(page_idx, order);
buddy = page + (buddy_idx - page_idx);
if (!is_migrate_isolate_page(buddy)) {
But the begin addr of this part of CMA memory is very close to a part of
memory that is reserved at boot time (not in buddy system). So add a
check before accessing it.
[akpm@linux-foundation.org: use conventional code layout]
Signed-off-by: Hui Zhu <zhuhui@xiaomi.com>
Suggested-by: Laura Abbott <labbott@redhat.com>
Suggested-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
{u,g}id_valid call {u,g}id_eq, which calls __k{u,g}id_val on both
arguments and compares. With !CONFIG_MULTIUSER, __k{u,g}id_val return a
constant 0, which makes {u,g}id_valid always return false. Change
{u,g}id_valid to compare their argument against -1 instead. That produces
identical results in the normal CONFIG_MULTIUSER=y case, but with
!CONFIG_MULTIUSER will make {u,g}id_valid constant-fold into "return
true;" rather than "return false;".
This fixes uses of devpts without CONFIG_MULTIUSER.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>,
Cc: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
root->ino_ida is used for kernfs inode number allocations. Since IDA has
a layered structure, different IDs can reside on the same layer, which
is currently accounted to some memory cgroup. The problem is that each
kmem cache of a memory cgroup has its own directory on sysfs (under
/sys/fs/kernel/<cache-name>/cgroup). If the inode number of such a
directory or any file in it gets allocated from a layer accounted to the
cgroup which the cache is created for, the cgroup will get pinned for
good, because one has to free all kmem allocations accounted to a cgroup
in order to release it and destroy all its kmem caches. That said we
must not account layers of ino_ida to any memory cgroup.
Since per net init operations may create new sysfs entries directly
(e.g. lo device) or indirectly (nf_conntrack creates a new kmem cache
per each namespace, which, in turn, creates new sysfs entries), an easy
way to reproduce this issue is by creating network namespace(s) from
inside a kmem-active memory cgroup.
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Acked-by: Tejun Heo <tj@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <stable@vger.kernel.org> [4.0.x]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Not all kmem allocations should be accounted to memcg. The following
patch gives an example when accounting of a certain type of allocations to
memcg can effectively result in a memory leak. This patch adds the
__GFP_NOACCOUNT flag which if passed to kmalloc and friends will force the
allocation to go through the root cgroup. It will be used by the next
patch.
Note, since in case of kmemleak enabled each kmalloc implies yet another
allocation from the kmemleak_object cache, we add __GFP_NOACCOUNT to
gfp_kmemleak_mask.
Alternatively, we could introduce a per kmem cache flag disabling
accounting for all allocations of a particular kind, but (a) we would not
be able to bypass accounting for kmalloc then and (b) a kmem cache with
this flag set could not be merged with a kmem cache without this flag,
which would increase the number of global caches and therefore
fragmentation even if the memory cgroup controller is not used.
Despite its generic name, currently __GFP_NOACCOUNT disables accounting
only for kmem allocations while user page allocations are always charged.
To catch abusing of this flag, a warning is issued on an attempt of
passing it to mem_cgroup_try_charge.
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <stable@vger.kernel.org> [4.0.x]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
libabikfs.a doesn't exist anymore, so we now need to link with libapi.a.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Later commits would change the way policies are managed today. Policies
wouldn't be freed on cpu hotplug (currently they aren't freed on
suspend), and while the CPU is offline, the sysfs cpufreq files would
still be present.
Because we don't mark policy->governor as NULL, it still contains
pointer of the last used governor. And if the governor is removed, while
all the CPUs of a policy are hotplugged out, this pointer wouldn't be
valid anymore. And if we try to read the 'scaling_governor', etc. from
sysfs, it will result in kernel OOPs.
To prevent this, mark policy->governor as NULL for all inactive policies
while the governor is removed from kernel.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
History of which governor was used last is common to all CPUs within a
policy and maintaining it per-cpu isn't the best approach for sure.
Apart from wasting memory, this also increases the complexity of
managing this data structure as it has to be updated for all CPUs.
To make that somewhat simpler, lets store this information in a new
field 'last_governor' in struct cpufreq_policy and update it on removal
of last cpu of a policy.
As a side-effect it also solves an old problem, consider a system with
two clusters 0 & 1. And there is one policy per cluster.
Cluster 0: CPU0 and 1.
Cluster 1: CPU2 and 3.
- CPU2 is first brought online, and governor is set to performance
(default as cpufreq_cpu_governor wasn't set).
- Governor is changed to ondemand.
- CPU2 is taken offline and cpufreq_cpu_governor is updated for CPU2.
- CPU3 is brought online.
- Because cpufreq_cpu_governor wasn't set for CPU3, the default governor
performance is picked for CPU3.
This patch fixes the bug as we now have a single variable to update for
policy.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Having this Kconfig sourced outside the clk menu means the option
is under the "Device Drivers" menu instead of the "Common Clock
Framework" menu. Move it so that the bcm clock config options are
in the right place.
Cc: Alex Elder <elder@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
We reach here while adding policy for a CPU and enter into the 'if'
block only if a policy already exists for the CPU.
As cpufreq_cpu_data is set for all policy->related_cpus now, when the
policy is first added, we can use that to find the CPU's policy instead
of traversing the list of all active policies.
Acked-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
We can extract the same information from cpufreq_cpu_data as it is also
available for inactive policies now. And so don't need
cpufreq_cpu_data_fallback anymore.
Also add a WARN_ON() for the case where we try to restore from an active
policy.
Acked-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Now that we can check policy->cpus to find if policy is active or not,
we don't need to clean cpufreq_cpu_data and delete policy from the list
on light weight tear down of policies (like in suspend).
To make it consistent and clean, set cpufreq_cpu_data for all related
CPUs when the policy is first created and clean it only while it is
freed.
Also update cpufreq_cpu_get_raw() to check if cpu is part of
policy->cpus mask, so that we don't end up getting policies for offline
CPUs.
In order to make sure that no users of 'policy' are using an inactive
policy, use cpufreq_cpu_get_raw() instead of directly accessing
cpufreq_cpu_data.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
policy->cpus is cleared unconditionally now on hotplug-out of a CPU and
it can be checked to know if a policy is active or not. Create helper
routines to iterate over all active/inactive policies, based on
policy->cpus field.
Replace all instances of for_each_policy() with for_each_active_policy()
to make them iterate only for active policies. (We haven't made changes
yet to keep inactive policies in the same list, but that will be
followed in a later patch).
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
drivers/clk/clk-u300.c:1175:13: warning: symbol 'u300_clk_init' was not declared. Should it be static?
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
drivers/clk/clk-moxart.c:18:13: warning: symbol 'moxart_of_pll_clk_init' was not declared. Should it be static?
drivers/clk/clk-moxart.c:56:13: warning: symbol 'moxart_of_apb_clk_init' was not declared. Should it be static?
Cc: Jonas Jensen <jonas.jensen@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
drivers/clk/clk-xgene.c:77:43: warning: incorrect type in argument 1 (different address spaces)
drivers/clk/clk-xgene.c:77:43: expected void *csr
drivers/clk/clk-xgene.c:77:43: got void [noderef] <asn:2>*
...
drivers/clk/clk-xgene.c: In function ‘xgene_clk_enable’:
drivers/clk/clk-xgene.c:237:3: warning: format ‘%LX’ expects argument of type ‘long long unsigned int’, but argument 4 has type ‘phys_addr_t’ [-Wformat]
drivers/clk/clk-xgene.c:248:3: warning: format ‘%LX’ expects argument of type ‘long long unsigned int’, but argument 4 has type ‘phys_addr_t’ [-Wformat]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
drivers/clk/mmp/clk-apbc.c:118:16: warning: symbol 'clk_apbc_ops' was not declared. Should it be static?
drivers/clk/mmp/clk-apmu.c:64:16: warning: symbol 'clk_apmu_ops' was not declared. Should it be static?
Cc: Chao Xie <chao.xie@marvell.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
drivers/clk/versatile/clk-sp810.c:159:29: error: incompatible types for operation (<=)
drivers/clk/versatile/clk-sp810.c:159:29: left side has type char const *<noident>
drivers/clk/versatile/clk-sp810.c:159:29: right side has type int
drivers/clk/versatile/clk-sp810.c:159:53: error: incompatible types for operation (<=)
drivers/clk/versatile/clk-sp810.c:159:53: left side has type char const *<noident>
drivers/clk/versatile/clk-sp810.c:159:53: right side has type int
drivers/clk/versatile/clk-sp810.c:138:13: warning: symbol 'clk_sp810_of_setup' was not declared. Should it be static?
Acked: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
drivers/clk/ti/clk.c:125:31: warning: incorrect type in return expression (different address spaces)
drivers/clk/ti/clk.c:125:31: expected void [noderef] <asn:2>*
drivers/clk/ti/clk.c:125:31: got void *
drivers/clk/ti/clk.c:132:31: warning: incorrect type in return expression (different address spaces)
drivers/clk/ti/clk.c:132:31: expected void [noderef] <asn:2>*
drivers/clk/ti/clk.c:132:31: got void *
drivers/clk/ti/dpll.c:180:14: warning: symbol '_get_reg' was not declared. Should it be static?
drivers/clk/ti/fapll.c:624:32: warning: Using plain integer as NULL pointer
drivers/clk/ti/fapll.c:625:31: warning: Using plain integer as NULL pointer
drivers/clk/ti/fapll.c:630:40: warning: Using plain integer as NULL pointer
drivers/clk/ti/clk-dra7-atl.c:158:22: warning: symbol 'atl_clk_ops' was not declared. Should it be static?
drivers/clk/ti/clk-dra7-atl.c:170:39: warning: Using plain integer as NULL pointer
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
drivers/clk/st/clkgen-mux.c:134:4: warning: symbol 'clkgena_divmux_get_parent' was not declared. Should it be static?
drivers/clk/st/clkgen-mux.c:171:15: warning: symbol 'clkgena_divmux_recalc_rate' was not declared. Should it be static?
drivers/clk/st/clkgen-mux.c:218:12: warning: symbol 'clk_register_genamux' was not declared. Should it be static?
drivers/clk/st/clkgen-mux.c:388:13: warning: symbol 'st_of_clkgena_divmux_setup' was not declared. Should it be static?
drivers/clk/st/clkgen-mux.c:488:13: warning: symbol 'st_of_clkgena_prediv_setup' was not declared. Should it be static?
drivers/clk/st/clkgen-mux.c:625:13: warning: symbol 'st_of_clkgen_mux_setup' was not declared. Should it be static?
drivers/clk/st/clkgen-mux.c:702:13: warning: symbol 'st_of_clkgen_vcc_setup' was not declared. Should it be static?
drivers/clk/st/clkgen-pll.c:273:15: warning: symbol 'recalc_stm_pll800c65' was not declared. Should it be static?
drivers/clk/st/clkgen-pll.c:300:15: warning: symbol 'recalc_stm_pll1600c65' was not declared. Should it be static?
drivers/clk/st/clkgen-pll.c:324:15: warning: symbol 'recalc_stm_pll3200c32' was not declared. Should it be static?
drivers/clk/st/clkgen-pll.c:346:15: warning: symbol 'recalc_stm_pll1200c32' was not declared. Should it be static?
drivers/clk/st/clkgen-pll.c:565:19: warning: incorrect type in assignment (different address spaces)
drivers/clk/st/clkgen-pll.c:565:19: expected void [noderef] <asn:2>*reg
drivers/clk/st/clkgen-pll.c:565:19: got void *
drivers/clk/st/clkgen-pll.c:576:18: warning: incorrect type in assignment (different address spaces)
drivers/clk/st/clkgen-pll.c:576:18: expected void [noderef] <asn:2>*reg
drivers/clk/st/clkgen-pll.c:576:18: got void *
drivers/clk/st/clkgen-pll.c:693:53: warning: incorrect type in argument 2 (different address spaces)
drivers/clk/st/clkgen-pll.c:693:53: expected void *[noderef] <asn:2>reg
drivers/clk/st/clkgen-pll.c:693:53: got void [noderef] <asn:2>*[assigned] pll_base
drivers/clk/st/clkgen-fsyn.c:495:5: warning: symbol 'clk_fs660c32_vco_get_rate' was not declared. Should it be static?
drivers/clk/st/clkgen-fsyn.c:522:5: warning: symbol 'clk_fs660c32_vco_get_params' was not declared. Should it be static?
drivers/clk/st/clk-flexgen.c:119:15: warning: symbol 'flexgen_recalc_rate' was not declared. Should it be static?
drivers/clk/st/clk-flexgen.c:177:12: warning: symbol 'clk_register_flexgen' was not declared. Should it be static?
drivers/clk/st/clk-flexgen.c:263:13: warning: symbol 'st_of_flexgen_setup' was not declared. Should it be static?
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
These are __iomem pointers. Mark them appropriately so we don't
get sparse errors like
drivers/clk/sirf/clk-common.c:60:16: warning: incorrect type in argument 1 (different address spaces)
drivers/clk/sirf/clk-common.c:60:16: expected void const volatile [noderef] <asn:2>*addr
drivers/clk/sirf/clk-common.c:60:16: got void *
Cc: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
drivers/clk/shmobile/clk-emev2.c:37:14: warning: symbol 'smu_base' was not declared. Should it be static?
Cc: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
Cc: Magnus Damm <damm@opensource.se>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
drivers/clk/samsung/clk-exynos5260.c:138:40: warning: Using plain integer as NULL pointer
drivers/clk/samsung/clk-exynos5260.c:328:40: warning: Using plain integer as NULL pointer
drivers/clk/samsung/clk-exynos5260.c:392:40: warning: Using plain integer as NULL pointer
drivers/clk/samsung/clk-exynos5260.c:494:40: warning: Using plain integer as NULL pointer
drivers/clk/samsung/clk-exynos5260.c:583:40: warning: Using plain integer as NULL pointer
drivers/clk/samsung/clk-exynos5260.c:644:40: warning: Using plain integer as NULL pointer
drivers/clk/samsung/clk-exynos5260.c:779:40: warning: Using plain integer as NULL pointer
drivers/clk/samsung/clk-exynos5260.c:898:40: warning: Using plain integer as NULL pointer
drivers/clk/samsung/clk-exynos5260.c:962:40: warning: Using plain integer as NULL pointer
drivers/clk/samsung/clk-exynos5260.c:1018:40: warning: Using plain integer as NULL pointer
drivers/clk/samsung/clk-exynos5260.c:1165:40: warning: Using plain integer as NULL pointer
drivers/clk/samsung/clk-exynos5260.c:1373:40: warning: Using plain integer as NULL pointer
drivers/clk/samsung/clk-exynos5260.c:1829:40: warning: Using plain integer as NULL pointer
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
drivers/clk/hisilicon/clk-hix5hd2.c:255:13: warning: symbol 'hix5hd2_clk_register_complex' was not declared. Should it be static?
Acked-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
drivers/clk/berlin/berlin2-pll.c:94:12: warning: symbol 'berlin2_pll_register' was not declared. Should it be static?
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
This list doesn't look to be used. Let's remove it and any
associated code that would be manipulating this list. This also
silences this error:
drivers/clk/bcm/clk-kona-setup.c:24:1: warning: symbol 'ccu_list' was not declared. Should it be static?
Reviewed-by: Alex Elder <elder@linaro.org>
Cc: Tim Kryger <tim.kryger@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
drivers/clk/clk-max-gen.c:82:16: warning: symbol 'max_gen_clk_ops' was not declared. Should it be static?
drivers/clk/clk-max-gen.c:109:5: warning: symbol 'max_gen_clk_probe' was not declared. Should it be static?
drivers/clk/clk-max-gen.c:183:5: warning: symbol 'max_gen_clk_remove' was not declared. Should it be static?
Acked-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
drivers/clk/clk.c:2700:5: warning: symbol '__clk_get' was not declared. Should it be static?
drivers/clk/clk.c:2713:6: warning: symbol '__clk_put' was not declared. Should it be static?
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
This function is marked as __init, so exposing it to modules
doesn't make any sense and it isn't used by modules anyway.
drivers/clk/clk-gpio-gate.c:192:13: warning: symbol 'of_gpio_gate_clk_setup' was not declared. Should it be static?
Cc: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
With the addition of switcher code, there's compile-time dependency on
BIG_LITTLE to get arm_big_little driver compiling on ARM64. Since ARM64
will never add support for bL switcher, it's better to remove the
dependency so that the driver can be reused on ARM64 platforms.
This patch adds stubs to remove BIG_LITTLE dependency in the driver.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Printing an error on kmalloc() failures is unnecessary. Remove
the print and use *ptr in sizeof() for future-proof code.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
The journal revoke block recovery code does not check r_count for
sanity, which means that an evil value of r_count could result in
the kernel reading off the end of the revoke table and into whatever
garbage lies beyond. This could crash the kernel, so fix that.
However, in testing this fix, I discovered that the code to write
out the revoke tables also was not correctly checking to see if the
block was full -- the current offset check is fine so long as the
revoke table space size is a multiple of the record size, but this
is not true when either journal_csum_v[23] are set.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: stable@vger.kernel.org
The following commit introduced a bug when checking for zero length extent
5946d08 ext4: check for overlapping extents in ext4_valid_extent_entries()
Zero length extent could pass the check if lblock is zero.
Adding the explicit check for zero length back.
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
Currently when journal restart fails, we'll have the h_transaction of
the handle set to NULL to indicate that the handle has been effectively
aborted. We handle this situation quietly in the jbd2_journal_stop() and just
free the handle and exit because everything else has been done before we
attempted (and failed) to restart the journal.
Unfortunately there are a number of problems with that approach
introduced with commit
41a5b91319 "jbd2: invalidate handle if jbd2_journal_restart()
fails"
First of all in ext4 jbd2_journal_stop() will be called through
__ext4_journal_stop() where we would try to get a hold of the superblock
by dereferencing h_transaction which in this case would lead to NULL
pointer dereference and crash.
In addition we're going to free the handle regardless of the refcount
which is bad as well, because others up the call chain will still
reference the handle so we might potentially reference already freed
memory.
Moreover it's expected that we'll get aborted handle as well as detached
handle in some of the journalling function as the error propagates up
the stack, so it's unnecessary to call WARN_ON every time we get
detached handle.
And finally we might leak some memory by forgetting to free reserved
handle in jbd2_journal_stop() in the case where handle was detached from
the transaction (h_transaction is NULL).
Fix the NULL pointer dereference in __ext4_journal_stop() by just
calling jbd2_journal_stop() quietly as suggested by Jan Kara. Also fix
the potential memory leak in jbd2_journal_stop() and use proper
handle refcounting before we attempt to free it to avoid use-after-free
issues.
And finally remove all WARN_ON(!transaction) from the code so that we do
not get random traces when something goes wrong because when journal
restart fails we will get to some of those functions.
Cc: stable@vger.kernel.org
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
The ext4_extent_tree_init() function hasn't been in the ext4 code for
a long time ago, except in an unused function prototype in ext4.h
Google-Bug-Id: 4530137
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
For every frontend entry, we need to add the adapter's size. There
are already two patches fixing it. So, it doesn't seem trivial to
keep it there at the right place.
Also, currently, the indentation is wrong on all places.
So, it seems that keeping it right is not too trivial.
Better to use a macro that would do it for us, at least while
this is not converted to dvb-usb-v2.
Compile-tested only.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Such as RHEL5, where CLOEXEC, NONBLOCK flags are not present, use a
ifdef+define approach instead to make it build on all distros.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Vinson Lee <vlee@twitter.com>
Link: http://lkml.kernel.org/n/tip-pioazikk9d9oz5qdeor3eldu@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
