- 24 Jan, 2014 40 commits
-
-
Mike Frysinger authored
The u64 type is not defined in any exported kernel headers, so trying to use it will lead to build failures. Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Acked-by:
David Rientjes <rientjes@google.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Mike Frysinger authored
This header uses _IOW/_IOR defines but doesn't include ioctl.h for it. If you try to use this w/out including ioctl.h yourself, it can fail to build, so add the explicit include. Signed-off-by:
-
Mike Frysinger authored
This header uses enum NPmode but doesn't include ppp_defs.h. If you try to use this header w/out including the defs header first, it leads to a build failure. So add the explicit include to fix it. Don't know of any packages directly impacted, but noticed while building some ppp code by hand. Signed-off-by:
-
Paul Bolle authored
"make headers_check" warns about soundcard.h for (at least) five years now: [...]/usr/include/linux/soundcard.h:1054: userspace cannot reference function or variable defined in the kernel We're apparently stuck with providing OSSlib-3.8 compatibility, so let's special case this declaration just to silence it. Notes: 0) Support for OSSlib post 3.8 was already removed in commit 43a99076 ("sound: Remove OSSlib stuff from linux/soundcard.h"). Five years have passed since that commit: do people still care about OSSlib-3.8? If not, quite a bit of code could be remove from soundcard.h (and probably ultrasound.h). 2) By the way, what is actually meant by: It is no longer possible to actually link against OSSlib with this header, but we still provide these macros for programs using them. Doesn't that mean compatibility to OSSlib isn't even useful? 3) Anyhow, a previous discussion soundcard.h, which led to that commit, starts at https://lkml.org/lkml/2009/1/20/349 . 4) And, yes, I sneaked in a whitespace fix. Signed-off-by:Paul Bolle <pebolle@tiscali.nl> Cc: Takashi Iwai <tiwai@suse.de> Acked-by:
Arnd Bergmann <arnd@arndb.de> Cc: Michal Marek <mmarek@suse.cz> Signed-off-by:
-
Dan Carpenter authored
We fixed the call to request_mem_region() in commit 3354f73b ("drivers/vlynq/vlynq.c: fix resource size off by 1 error"). But we need to fix the call the release_mem_region() as well. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Florian Fainelli <florian@openwrt.org> Signed-off-by:
-
David Howells authored
Fix the following warning in the aty128fb driver: drivers/video/aty/aty128fb.c:363:12: warning: 'backlight' defined but not used [-Wunused-variable] static int backlight = 0; ^ as the variable's value is only read if CONFIG_FB_ATY128_BACKLIGHT=y. The variable is also set if MODULE is unset[*]. [*] I wonder if the conditional wrapper around aty128fb_setup() should be using CONFIG_MODULE rather than MODULE. Signed-off-by:David Howells <dhowells@redhat.com> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by:
-
David Howells authored
Fix up the following pointer-integer size mismatch warning in tps65217_probe(): drivers/mfd/tps65217.c: In function 'tps65217_probe': drivers/mfd/tps65217.c:173:13: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] chip_id = (unsigned int)match->data; ^ Signed-off-by:
-
David Howells authored
Fix up the following pointer-integer size mismatch warning in max8998_i2c_get_driver_data(): drivers/mfd/max8998.c: In function 'max8998_i2c_get_driver_data': drivers/mfd/max8998.c:178:10: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] return (int)match->data; ^ Signed-off-by:
-
David Howells authored
Fix the following warning: drivers/gpu/drm/gma500/backlight.c:29:13: warning: 'do_gma_backlight_set' defined but not used [-Wunused-function] by moving the entire function inside the conditional section currently inside of it. All the places that call it are so conditionalised. Signed-off-by:
-
David Howells authored
Make for_each_child_of_node() reference its args when CONFIG_OF=n to avoid warnings like: drivers/leds/leds-pwm.c:88:22: warning: unused variable 'node' [-Wunused-variable] struct device_node *node = pdev->dev.of_node; ^ Signed-off-by:
-
Alex Elder authored
Now that the definition is centralized in <linux/kernel.h>, the definitions of U32_MAX (and related) elsewhere in the kernel can be removed. Signed-off-by:
Alex Elder <elder@linaro.org> Acked-by:
Sage Weil <sage@inktank.com> Acked-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Alex Elder authored
Create constants that define the maximum and minimum values representable by the kernel types u8, s8, u16, s16, and so on. Signed-off-by:
-
Alex Elder authored
The symbol U32_MAX is defined in several spots. Change these definitions to be conditional. This is in preparation for the next patch, which centralizes the definition in <linux/kernel.h>. Signed-off-by:
-
Mark Salter authored
Signed-off-by:
Mark Salter <msalter@redhat.com> Acked-by:
Richard Weinberger <richard@nod.at> Cc: Jeff Dike <jdike@addtoit.com> Signed-off-by:
-
Mark Salter authored
Signed-off-by:
Chris Metcalf <cmetcalf@tilera.com> Signed-off-by:
-
Mark Salter authored
Signed-off-by:
-
Mark Salter authored
Signed-off-by:
-
Mark Salter authored
Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Mark Salter authored
Signed-off-by:
Michal Simek <monstr@monstr.eu> Signed-off-by:
-
Mark Salter authored
Signed-off-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
-
Mark Salter authored
Signed-off-by:
Richard Kuo <rkuo@codeaurora.org> Signed-off-by:
-
Mark Salter authored
Signed-off-by:
-
Mark Salter authored
Many architectures provide an asm/fixmap.h which defines support for compile-time 'special' virtual mappings which need to be made before paging_init() has run. This support is also used for early ioremap on x86. Much of this support is identical across the architectures. This patch consolidates all of the common bits into asm-generic/fixmap.h which is intended to be included from arch/*/include/asm/fixmap.h. Signed-off-by:
-
Younger Liu authored
In get_mapping_page(), after calling find_or_create_page(), the return value should be checked. This patch has been provided: http://www.spinics.net/lists/linux-fsdevel/msg66948.html but not been applied now. Signed-off-by:
Younger Liu <liuyiyang@hisense.com> Cc: Younger Liu <younger.liucn@gmail.com> Cc: Vyacheslav Dubeyko <slava@dubeyko.com> Reviewed-by:
Prasad Joshi <prasadjoshi.linux@gmail.com> Cc: Jörn Engel <joern@logfs.org> Signed-off-by:
-
Fabian Frederick authored
RAM block device support module name changed to brd.ko some years ago with an "rd" alias to match previous module implementation. This patch updates its Kconfig definition. Signed-off-by:
Fabian Frederick <fabf@skynet.be> Acked-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Dan Carpenter authored
There is a bug in omap2_mbox_probe() where we try do: mbox->irq = platform_get_irq(pdev, info->irq_id); if (mbox->irq < 0) { The problem is that mbox->irq is unsigned so the error handling doesn't work. I've changed it to a signed integer. Signed-off-by: -
Geert Uytterhoeven authored
Now all 64-bit architectures have been converted to int-ll64.h, we can remove int-l64.h in kernelspace. For backwards compatibility, alpha, ia64, mips64, and powerpc64 still use int-l64.h in userspace. This is the (reworked for UAPI) non-documentation part of more than two year old "asm/types.h: All architectures use int-ll64.h in kernelspace" (https://lkml.org/lkml/2011/8/13/104) Since <asm/types.h> (from include/uapi/asm-generic/types.h) is used for both kernel and user space, include/asm-generic/int-ll64.h cannot just become include/asm-generic/types.h, as Arnd suggested. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Acked-by:
-
Cyrill Gorcunov authored
The VM_SOFTDIRTY bit affects vma merge routine: if two VMAs has all bits in vm_flags matched except dirty bit the kernel can't longer merge them and this forces the kernel to generate new VMAs instead. It finally may lead to the situation when userspace application reaches vm.max_map_count limit and get crashed in worse case | (gimp:11768): GLib-ERROR **: gmem.c:110: failed to allocate 4096 bytes | | (file-tiff-load:12038): LibGimpBase-WARNING **: file-tiff-load: gimp_wire_read(): error | xinit: connection to X server lost | | waiting for X server to shut down | /usr/lib64/gimp/2.0/plug-ins/file-tiff-load terminated: Hangup | /usr/lib64/gimp/2.0/plug-ins/script-fu terminated: Hangup | /usr/lib64/gimp/2.0/plug-ins/script-fu terminated: Hangup https://bugzilla.kernel.org/show_bug.cgi?id=67651 https://bugzilla.gnome.org/show_bug.cgi?id=719619#c0 Initial problem came from missed VM_SOFTDIRTY in do_brk() routine but even if we would set up VM_SOFTDIRTY here, there is still a way to prevent VMAs from merging: one can call | echo 4 > /proc/$PID/clear_refs and clear all VM_SOFTDIRTY over all VMAs presented in memory map, then new do_brk() will try to extend old VMA and finds that dirty bit doesn't match thus new VMA will be generated. As discussed with Pavel, the right approach should be to ignore VM_SOFTDIRTY bit when we're trying to merge VMAs and if merge successed we mark extended VMA with dirty bit where needed. Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Reported-by:
Bastian Hougaard <gnome@rvzt.net> Reported-by:
Mel Gorman <mgorman@suse.de> Cc: Pavel Emelyanov <xemul@parallels.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Fengguang Wu authored
mm/rmap.c:851:9-10: WARNING: return of 0/1 in function 'invalid_mkclean_vma' with return type bool Return statements in functions returning bool should use true/false instead of 1/0. Generated by: coccinelle/misc/boolreturn.cocci Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
Jamie Liu authored
In the second half of scan_swap_map()'s scan loop, offset is set to si->lowest_bit and then incremented before entering the loop for the first time, causing si->swap_map[si->lowest_bit] to be skipped. Signed-off-by:
Jamie Liu <jamieliu@google.com> Cc: Shaohua Li <shli@fusionio.com> Acked-by:
Hugh Dickins <hughd@google.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by:
-
Vladimir Davydov authored
Signed-off-by:
Vladimir Davydov <vdavydov@parallels.com> Reviewed-by:
Michal Hocko <mhocko@suse.cz> Cc: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by:
-
Mel Gorman authored
Developers occasionally try and optimise PFN scanners by using page_order but miss that in general it requires zone->lock. This has happened twice for compaction.c and rejected both times. This patch clarifies the documentation of page_order and adds a note to compaction.c why page_order is not used. [akpm@linux-foundation.org: tweaks] [lauraa@codeaurora.org: Corrected a page_zone(page)->lock reference] Signed-off-by:
Rafael Aquini <aquini@redhat.com> Acked-by:
Minchan Kim <minchan@kernel.org> Cc: Laura Abbott <lauraa@codeaurora.org> Signed-off-by:
-
Michal Hocko authored
Commit 19f39402 ("memcg: simplify mem_cgroup_iter") has reorganized mem_cgroup_iter code in order to simplify it. A part of that change was dropping an optimization which didn't call css_tryget on the root of the walked tree. The patch however didn't change the css_put part in mem_cgroup_iter which excludes root. This wasn't an issue at the time because __mem_cgroup_iter_next bailed out for root early without taking a reference as cgroup iterators (css_next_descendant_pre) didn't visit root themselves. Nevertheless cgroup iterators have been reworked to visit root by commit bd8815a6 ("cgroup: make css_for_each_descendant() and friends include the origin css in the iteration") when the root bypass have been dropped in __mem_cgroup_iter_next. This means that css_put is not called for root and so css along with mem_cgroup and other cgroup internal object tied by css lifetime are never freed. Fix the issue by reintroducing root check in __mem_cgroup_iter_next and do not take css reference for it. This reference counting magic protects us also from another issue, an endless loop reported by Hugh Dickins when reclaim races with root removal and css_tryget called by iterator internally would fail. There would be no other nodes to visit so __mem_cgroup_iter_next would return NULL and mem_cgroup_iter would interpret it as "start looping from root again" and so mem_cgroup_iter would loop forever internally. Signed-off-by:
-
Michal Hocko authored
Hugh has reported an endless loop when the hardlimit reclaim sees the same group all the time. This might happen when the reclaim races with the memcg removal. shrink_zone [rmdir root] mem_cgroup_iter(root, NULL, reclaim) // prev = NULL rcu_read_lock() mem_cgroup_iter_load last_visited = iter->last_visited // gets root || NULL css_tryget(last_visited) // failed last_visited = NULL [1] memcg = root = __mem_cgroup_iter_next(root, NULL) mem_cgroup_iter_update iter->last_visited = root; reclaim->generation = iter->generation mem_cgroup_iter(root, root, reclaim) // prev = root rcu_read_lock mem_cgroup_iter_load last_visited = iter->last_visited // gets root css_tryget(last_visited) // failed [1] The issue seemed to be introduced by commit 5f578161 ("memcg: relax memcg iter caching") which has replaced unconditional css_get/css_put by css_tryget/css_put for the cached iterator. This patch fixes the issue by skipping css_tryget on the root of the tree walk in mem_cgroup_iter_load and symmetrically doesn't release it in mem_cgroup_iter_update. Signed-off-by: -
David Rientjes authored
When two threads have the same badness score, it's preferable to kill the thread group leader so that the actual process name is printed to the kernel log rather than the thread group name which may be shared amongst several processes. This was the behavior when select_bad_process() used to do for_each_process(), but it now iterates threads instead and leads to ambiguity. Signed-off-by:
-
Xishi Qiu authored
Add "kmemcheck=xx" to Documentation/kernel-parameters.txt. Signed-off-by:
Xishi Qiu <qiuxishi@huawei.com> Cc: Vegard Nossum <vegardno@ifi.uio.no> Cc: Pekka Enberg <penberg@kernel.org> Cc: Rob Landley <rob@landley.net> Signed-off-by:
-
Hugh Dickins authored
It is surprising that the mem_cgroup iterator can return memcgs which have not yet been fully initialized. By accident (or trial and error?) this appears not to present an actual problem; but it may be better to prevent such surprises, by skipping memcgs not yet online. Signed-off-by:
-
Hugh Dickins authored
Shorten mem_cgroup_reclaim_iter.last_dead_count from unsigned long to int: it's assigned from an int and compared with an int, and adjacent to an unsigned int: so there's no point to it being unsigned long, which wasted 104 bytes in every mem_cgroup_per_zone. Signed-off-by:
-
Paul Gortmaker authored
Code that is obj-y (always built-in) or dependent on a bool Kconfig (built-in or absent) can never be modular. So using module_init as an alias for __initcall can be somewhat misleading. Fix these up now, so that we can relocate module_init from init.h into module.h in the future. If we don't do this, we'd have to add module.h to obviously non-modular code, and that would be a worse thing. The audit targets the following module_init users for change: mm/ksm.c bool KSM mm/mmap.c bool MMU mm/huge_memory.c bool TRANSPARENT_HUGEPAGE mm/mmu_notifier.c bool MMU_NOTIFIER Note that direct use of __initcall is discouraged, vs. one of the priority categorized subgroups. As __initcall gets mapped onto device_initcall, our use of subsys_initcall (which makes sense for these files) will thus change this registration from level 6-device to level 4-subsys (i.e. slightly earlier). However no observable impact of that difference has been observed during testing. One might think that core_initcall (l2) or postcore_initcall (l3) would be more appropriate for anything in mm/ but if we look at some actual init functions themselves, we see things like: mm/huge_memory.c --> hugepage_init --> hugepage_init_sysfs mm/mmap.c --> init_user_reserve --> sysctl_user_reserve_kbytes mm/ksm.c --> ksm_init --> sysfs_create_group and hence the choice of subsys_initcall (l4) seems reasonable, and at the same time minimizes the risk of changing the priority too drastically all at once. We can adjust further in the future. Also, several instances of missing ";" at EOL are fixed. Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
Paul Gortmaker authored
The use of __initcall is to be eventually replaced by choosing one from the prioritized groupings laid out in init.h header: pure_initcall 0 core_initcall 1 postcore_initcall 2 arch_initcall 3 subsys_initcall 4 fs_initcall 5 device_initcall 6 late_initcall 7 In the interim, all __initcall are mapped onto device_initcall, which as can be seen above, comes quite late in the ordering. Currently the mm_kobj is created with __initcall in mm_sysfs_init(). This means that any other initcalls that want to reference the mm_kobj have to be device_initcall (or later), otherwise we will for example, trip the BUG_ON(!kobj) in sysfs's internal_create_group(). This unfairly restricts those users; for example something that clearly makes sense to be an arch_initcall will not be able to choose that. However, upon examination, it is only this way for historical reasons (i.e. simply not reprioritized yet). We see that sysfs is ready quite earlier in init/main.c via: vfs_caches_init |_ mnt_init |_ sysfs_init well ahead of the processing of the prioritized calls listed above. So we can recategorize mm_sysfs_init to be a pure_initcall, which in turn allows any mm_kobj initcall users a wider range (1 --> 7) of initcall priorities to choose from. Signed-off-by:
-
