summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2016-07-22tools build: Fix objtool build with ARCH=x86_64Josh Poimboeuf
The objtool build fails in a cross-compiled environment on a non-x86 host with "ARCH=x86_64": tools/objtool/objtool-in.o: In function `decode_instructions': tools/objtool/builtin-check.c:276: undefined reference to `arch_decode_instruction' We could override the ARCH environment variable and change it back to x86, similar to what the objtool Makefile was doing before; but it's tricky to override environment variables consistently. Instead, take a similar approach used by the Linux top-level Makefile and introduce a SRCARCH Makefile variable which evaluates to "x86" when ARCH is either "x86_64" or "x86". Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20160722191920.ej62fnspnqurbaa7@treble Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2016-07-22objtool: Always use host headersArnaldo Carvalho de Melo
From a conversation with Josh: From http://lkml.kernel.org/r/20160722034118.guckaniobf3f7czc@treble : It needs to be compiled with the host (powerpc) compiler, but then it needs to disassemble target (x86) files. ---- So use HOSTARCH instead of ARCH. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/r/20160722034118.guckaniobf3f7czc@treble Link: http://lkml.kernel.org/n/tip-le1m1yzxnfpt3msbblu40nm8@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2016-07-22objtool: Use tools/scripts/Makefile.arch to get ARCH and HOSTARCHArnaldo Carvalho de Melo
objtool's Makefile was setting up ARCH but fixing up just the x86_64 -> x86, using Makefile.arch will do the necessary fixups for all arches. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-hbq0bbh03u2b722vozcyql31@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2016-07-22tools build: Add HOSTARCH Makefile variableArnaldo Carvalho de Melo
For tools that needs to be always compiled with the host headers. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-907q32k2nep6q670dkxypmu6@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2016-07-22perf tests kmod-path: Fix build on ubuntu:16.04-x-armhfArnaldo Carvalho de Melo
Cross building it on Ubuntu 16.04 to ARM ends up showing we get the free() prototype by luck in other environments, fix it. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-0ktfgmmyhcfw8ondka2013f3@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2016-07-22nfs: don't create zero-length requestsBenjamin Coddington
NFS doesn't expect requests with wb_bytes set to zero and may make unexpected decisions about how to handle that request at the page IO layer. Skip request creation if we won't have any wb_bytes in the request. Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Reviewed-by: Weston Andros Adamson <dros@primarydata.com> Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2016-07-22Fix NULL pointer dereference in bl_free_device().Artem Savkov
When bl_parse_deviceid() fails in bl_alloc_deviceid_node() on blkdev_get_by_*() step we get an pnfs_block_dev struct that is uninitialized except for bdev field which is set to whatever error blkdev_get_by_*() returns. bl_free_device() then tries to call blkdev_put() if bdev is not 0 resulting in a wrong pointer dereference. Fixing this by setting bdev in struct pnfs_block_dev only if we didn't get an error from blkdev_get_by_*(). Signed-off-by: Artem Savkov <asavkov@redhat.com> Reviewed-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2016-07-22f2fs: get victim segment again after new cpYunlei He
Previous selected segment may become free after write_checkpoint, if we do garbage collect on this segment, and then new_curseg happen to reuse it, it may cause f2fs_bug_on as below. panic+0x154/0x29c do_garbage_collect+0x15c/0xaf4 f2fs_gc+0x2dc/0x444 f2fs_balance_fs.part.22+0xcc/0x14c f2fs_balance_fs+0x28/0x34 f2fs_map_blocks+0x5ec/0x790 f2fs_preallocate_blocks+0xe0/0x100 f2fs_file_write_iter+0x64/0x11c new_sync_write+0xac/0x11c vfs_write+0x144/0x1e4 SyS_write+0x60/0xc0 Here, maybe we check sit and ssa type during reset_curseg. So, we check segment is stale or not, and select a new victim to avoid this. Signed-off-by: Yunlei He <heyunlei@huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2016-07-22Merge tag 'kvm-arm-for-4.8' of ↵Radim Krčmář
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into next KVM/ARM changes for Linux 4.8 - GICv3 ITS emulation - Simpler idmap management that fixes potential TLB conflicts - Honor the kernel protection in HYP mode - Removal of the old vgic implementation
2016-07-22drm/etnaviv: Optimize error handling in etnaviv_gem_new_userptr()Markus Elfring
Refactor this function implementation so that the drm_gem_object_unreference_unlocked() function will only be called once in case of a failure according to the Linux coding style recommendation for centralized exiting of functions. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> [seanpaul tweaked subject] Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/4af34ce6-62c6-7966-1ae3-0877d5ac909d@users.sourceforge.net
2016-07-22drm/etnaviv: Delete unnecessary checks before two function callsMarkus Elfring
The functions drm_gem_object_unreference_unlocked() and vunmap() perform also input parameter validation. Thus the tests around their calls are not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> [seanpaul tweaked subject] Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/9638cd74-ffc5-d9ee-a40c-9b60e860ad8b@users.sourceforge.net
2016-07-22pinctrl: xway: fix typoLinus Walleij
A typo in the previous commit to this file needs fixing. Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com> Reported-by: kbuild test robot <fengguang.wu@intel.com> Fixes: 6b4316aecec0 ("pinctrl: xway: Change structure initialisation to c99 style") Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-07-22Revert "pinctrl: amd: make it explicitly non-modular"Paul Gortmaker
This reverts commit b8c2b10a9bc0272a20e096852f8fbbf361749dda. This patch was in my queue at the same time that a conversion of the same driver from bool --> tristate was pending and merged. That is commit 337ea0fb1535 ("pinctrl: Turn AMD support to tristate") Normally the conflict would show up in the build coverage I do, however in this case an avoidable instance of linux/module.h in linux/gpio/driver.h (!) causes the build failure to be masked and instead the tristate gets built-in even for selected "=m". In working on removing module.h from driver.h this issue was then revealed (along with other implicit module.h assumptions in gpio, and mfd -- which will be fixed separately.) Cc: linux-gpio@vger.kernel.org Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-07-22drm/vmwgfx: Delete an unnecessary check before the function call "vfree"Markus Elfring
The vfree() function performs also input parameter validation. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/8060f2e9-5070-3c10-d55c-dc058e4ca20d@users.sourceforge.net Link: http://patchwork.freedesktop.org/patch/msgid/f1a0fd83-4320-f3db-e1bb-3b9832a4429f@users.sourceforge.net
2016-07-22drm/qxl: Delete an unnecessary check before ↵Markus Elfring
drm_gem_object_unreference_unlocked() The drm_gem_object_unreference_unlocked() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/913198fa-2aa4-4804-8616-dd495428c0a5@users.sourceforge.net
2016-07-22drm/mgag200: Delete an unnecessary check before ↵Markus Elfring
drm_gem_object_unreference_unlocked() The drm_gem_object_unreference_unlocked() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/05b266e4-2bae-b70b-5a96-ae609496d173@users.sourceforge.net
2016-07-22drm/bridge: ps8622: Delete an unnecessary check before ↵Markus Elfring
backlight_device_unregister() The backlight_device_unregister() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/791089e4-201c-ad01-9c3b-f49835765177@users.sourceforge.net
2016-07-22netfilter: connlabels: move set helper to xt_connlabelFlorian Westphal
xt_connlabel is the only user so move it. Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2016-07-22netfilter: conntrack: support a fixed size of 128 distinct labelsFlorian Westphal
The conntrack label extension is currently variable-sized, e.g. if only 2 labels are used by iptables rules then the labels->bits[] array will only contain one element. We track size of each label storage area in the 'words' member. But in nftables and openvswitch we always have to ask for worst-case since we don't know what bit will be used at configuration time. As most arches are 64bit we need to allocate 24 bytes in this case: struct nf_conn_labels { u8 words; /* 0 1 */ /* XXX 7 bytes hole, try to pack */ long unsigned bits[2]; /* 8 24 */ Make bits a fixed size and drop the words member, it simplifies the code and only increases memory requirements on x86 when less than 64bit labels are required. We still only allocate the extension if its needed. Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2016-07-22pinctrl: iproc: Add NSP and Stingray GPIO supportRay Jui
The iProc GPIO controller is shared among multiple iProc based SoCs. In the NSP integration, the drive strength pinctrl function is disabled. In the integration of Stingray, pinctrl is handled by another block and this GPIO controller is solely used as a GPIO controller, and therefore should not be registered to the pinconf framework This patch introduces new SoC specific compatible strings "brcm,iproc-nsp-gpio" for NSP with drive strength feature disabled and "brcm,iproc-stingray-gpio" for Stingray with all PINCONF features disabled This patch is developed based on the initial work from Yendapally Reddy Dhananjaya <yendapally.reddy@broadcom.com> who attempted to disable drive strength configuration for the iProc based NSP chip. In addition, Pramod Kumar <pramod.kumar@broadcom.com> also contributed to make the support more generic across all currently supported PINCONF functions in the iProc GPIO/PINCONF driver Signed-off-by: Pramod Kumar <pramodku@broadcom.com> Signed-off-by: Ray Jui <ray.jui@broadcom.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-07-22pinctrl: Update iProc GPIO DT bindingsRay Jui
Update the iProc GPIO binding document to add new compatible strings "brcm,iproc-nsp-gpio" and "brcm,iproc-stingray-gpio" to support the iProc based GPIO controller used in the NSP and Stingray SoCs, respectively Signed-off-by: Ray Jui <ray.jui@broadcom.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-07-22pinctrl: bcm: add OF dependenciesArnd Bergmann
Building without CONFIG_OF gives us these warnings for the broadcom pinctrl drivers: drivers/pinctrl/bcm/pinctrl-nsp-mux.c:356:20: error: 'pinconf_generic_dt_node_to_map_group' undeclared here (not in a function) drivers/pinctrl/bcm/pinctrl-cygnus-mux.c:739:20: error: 'pinconf_generic_dt_node_to_map_group' undeclared here (not in a function) The function is only available when CONFIG_OF is set, so we should add a Kconfig dependency for both drivers. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: cc4fa83f66e9 ("pinctrl: nsp: add pinmux driver support for Broadcom NSP SoC") Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-07-22pinctrl: ns2: remove redundant dev_err call in ns2_pinmux_probe()Wei Yongjun
There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Acked-by: Ray Jui <ray.jui@broadcom.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-07-22MAINTAINERS: Add INTEL MERRIFIELD GPIO entryAndy Shevchenko
Add gpio-merrifield.c to MAINTAINERS database per Linus' ask. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-07-22gpio: dwapb: add missing fwnode_handle_put() in dwapb_gpio_get_pdata()Wei Yongjun
fwnode_handle_put() should be used when terminating device_for_each_child_node() iteration with break or return to prevent stale device node references from being left behind. Generated by Coccinelle. Fixes: 4ba8cfa79f44 ("gpio: dwapb: convert device node to fwnode") Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-07-22gpio: merrifield: Protect irq_ack() and gpio_set() by lockAndy Shevchenko
There is a potential race when two threads do the writes to the same register in parallel. Prevent out of order in such case by protecting I/O access by spin lock. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-07-22gpio: merrifield: Introduce GPIO driver to support MerrifieldAndy Shevchenko
Intel Merrifield platform has a special GPIO controller to drive pads when they are muxed in corresponding mode. Intel Merrifield GPIO IP is slightly different here and there in comparison to the older Intel MID platforms. These differences include in particular the shaked register offsets, specific support of level triggered interrupts and wake capable sources, as well as a pinctrl which is a separate IP. Instead of uglifying existing driver I decide to provide a new one slightly based on gpio-intel-mid.c. So, anyone can easily compare what changes are happened to be here. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Brian J Wood <brian.j.wood@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-07-22gpio: intel-mid: Make it depend to X86_INTEL_MIDAndy Shevchenko
This GPIO controller is a part of Intel MID platforms which are somehow different to pure PCs. Thus, there is no need that driver is compiled for them. Replace dependency to X86_INTEL_MID. While here, fix capitalization of MID abbreviation. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-07-22gpio: intel-mid: Sort header block alphabeticallyAndy Shevchenko
Sort the header inclusion lines by alphabetical order. While here, update Intel Copyright. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-07-22gpio: intel-mid: Remove potentially harmful codeAndy Shevchenko
The commit d56d6b3d7d69 ("gpio: langwell: add Intel Merrifield support") doesn't look at all as a proper support for Intel Merrifield and I dare to say that it distorts the behaviour of the hardware. The register map is different on Intel Merrifield, i.e. only 6 out of 8 register have the same purpose but none of them has same location in the address space. The current case potentially harmful to existing hardware since it's poking registers on wrong offsets and may set some pin to be GPIO output when connected hardware doesn't expect such. Besides the above GPIO and pinctrl on Intel Merrifield have been located in different IP blocks. The functionality has been extended as well, i.e. added support of level interrupts, special registers for wake capable sources and thus, in my opinion, requires a completele separate driver. If someone wondering the existing gpio-intel-mid.c would be converted to actual pinctrl (which by the fact it is now), though I wouldn't be a volunteer to do that. Fixes: d56d6b3d7d69 ("gpio: langwell: add Intel Merrifield support") Cc: stable@vger.kernel.org # v3.13+ Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-07-22gpio: rcar: add R8A7792 supportSergei Shtylyov
Renesas R8A7792 SoC is a member of the R-Car gen2 family, add support for its GPIO controllers. Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-07-22gpiolib: remove duplicated include from gpiolib.cWei Yongjun
Remove duplicated include. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-07-22gpio: tegra: don't auto-enable for COMPILE_TESTArnd Bergmann
I stumbled over a build error with COMPILE_TEST and CONFIG_OF disabled: drivers/gpio/gpio-tegra.c: In function 'tegra_gpio_probe': drivers/gpio/gpio-tegra.c:603:9: error: 'struct gpio_chip' has no member named 'of_node' The problem is that the newly added GPIO_TEGRA Kconfig symbol does not have a dependency on CONFIG_OF. However, there is another problem here as the driver gets enabled unconditionally whenever COMPILE_TEST is set. This fixes both problems, by making the symbol user-visible when COMPILE_TEST is set and default-enabled for ARCH_TEGRA=y. As a side-effect, it is now possible to compile-test a Tegra kernel with GPIO support disabled, which is harmless. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 4dd4dd1d2120 ("gpio: tegra: Allow compile test") Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-07-22libceph: apply new_state before new_up_client on incrementalsIlya Dryomov
Currently, osd_weight and osd_state fields are updated in the encoding order. This is wrong, because an incremental map may look like e.g. new_up_client: { osd=6, addr=... } # set osd_state and addr new_state: { osd=6, xorstate=EXISTS } # clear osd_state Suppose osd6's current osd_state is EXISTS (i.e. osd6 is down). After applying new_up_client, osd_state is changed to EXISTS | UP. Carrying on with the new_state update, we flip EXISTS and leave osd6 in a weird "!EXISTS but UP" state. A non-existent OSD is considered down by the mapping code 2087 for (i = 0; i < pg->pg_temp.len; i++) { 2088 if (ceph_osd_is_down(osdmap, pg->pg_temp.osds[i])) { 2089 if (ceph_can_shift_osds(pi)) 2090 continue; 2091 2092 temp->osds[temp->size++] = CRUSH_ITEM_NONE; and so requests get directed to the second OSD in the set instead of the first, resulting in OSD-side errors like: [WRN] : client.4239 192.168.122.21:0/2444980242 misdirected client.4239.1:2827 pg 2.5df899f2 to osd.4 not [1,4,6] in e680/680 and hung rbds on the client: [ 493.566367] rbd: rbd0: write 400000 at 11cc00000 (0) [ 493.566805] rbd: rbd0: result -6 xferred 400000 [ 493.567011] blk_update_request: I/O error, dev rbd0, sector 9330688 The fix is to decouple application from the decoding and: - apply new_weight first - apply new_state before new_up_client - twiddle osd_state flags if marking in - clear out some of the state if osd is destroyed Fixes: http://tracker.ceph.com/issues/14901 Cc: stable@vger.kernel.org # 3.15+: 6dd74e44dc1d: libceph: set 'exists' flag for newly up osd Cc: stable@vger.kernel.org # 3.15+ Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Josh Durgin <jdurgin@redhat.com>
2016-07-22xen-blkback: really don't leak mode propertyJan Beulich
Commit 9d092603cc ("xen-blkback: do not leak mode property") left one path unfixed; correct this. Acked-by: Jens Axboe <axboe@kernel.dk> Acked-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2016-07-22xen-blkback: constify instance of "struct attribute_group"Jan Beulich
The functions these get passed to have been taking pointers to const since at least 2.6.16. Acked-by: Jens Axboe <axboe@kernel.dk> Acked-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2016-07-22xen-blkfront: prefer xenbus_scanf() over xenbus_gather()Jan Beulich
... for single items being collected: It is more typesafe (as the compiler can check format string and to-be-written-to variable match) and requires one less parameter to be passed. Acked-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2016-07-22xen-blkback: prefer xenbus_scanf() over xenbus_gather()Jan Beulich
... for single items being collected: It is more typesafe (as the compiler can check format string and to-be-written-to variable match) and requires one less parameter to be passed. Signed-off-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Jens Axboe <axboe@kernel.dk>
2016-07-22scripts: Fix size mismatch of kexec_purgatory_sizeTautschnig, Michael
bin2c is used to create a valid C file out of a binary file where two symbols will be globally defined: <name> and <name>_size. <name> is passed as the first parameter of the host binary. Building using goto-cc reported that the purgatory binary code (the only current user of this utility) declares kexec_purgatory_size as 'size_t' where bin2c generate <name>_size to be 'int' so in a 64-bit host where sizeof(size_t) > sizeof(int) this type mismatch will always yield the wrong value for big-endian architectures while for little-endian it will be wrong if the object laid in memory directly after kexec_purgatory_size contains non-zero value at the time of reading. This commit changes <name>_size to be size_t instead. Note: Another way to fix the problem is to change the type of kexec_purgatory_size to be 'int' as there's this check in code: (kexec_purgatory_size <= 0) Signed-off-by: Michael Tautschnig <tautschn@amazon.com> Cc: Vivek Goyal <vgoyal@redhat.com> Acked-by: Dave Young <dyoung@redhat.com> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-07-22kbuild: make samples depend on headers_installArnd Bergmann
Olof's build test setup keeps failing to compile arm64 kernels because of a toolchain that uses outdated kernel headers: /work/build/batch/samples/seccomp/bpf-fancy.c:13:27: fatal error: linux/seccomp.h: No such file or directory This is of course something he could change, but it also indicates that others may run into the same problem. Running 'make headers_install' avoids the issue by ensuring that the kernel headers are put into the $(objdir)/usr/include path before we build the samples. The same problem happened for the Documentation build in the past and was fixed up with commit 8e2faea877eb ("Make Documenation depend on headers_install"). This adds an identical Makefile dependency for the samples/ subdirectory. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-07-22PM / hibernate: Introduce test_resume mode for hibernationChen Yu
test_resume mode is to verify if the snapshot data written to swap device can be successfully restored to memory. It is useful to ease the debugging process on hibernation, since this mode can not only bypass the BIOSes/bootloader, but also the system re-initialization. To avoid the risk to break the filesystm on persistent storage, this patch resumes the image with tasks frozen. For example: echo test_resume > /sys/power/disk echo disk > /sys/power/state [ 187.306470] PM: Image saving progress: 70% [ 187.395298] PM: Image saving progress: 80% [ 187.476697] PM: Image saving progress: 90% [ 187.554641] PM: Image saving done. [ 187.558896] PM: Wrote 594600 kbytes in 0.90 seconds (660.66 MB/s) [ 187.566000] PM: S| [ 187.589742] PM: Basic memory bitmaps freed [ 187.594694] PM: Checking hibernation image [ 187.599865] PM: Image signature found, resuming [ 187.605209] PM: Loading hibernation image. [ 187.665753] PM: Basic memory bitmaps created [ 187.691397] PM: Using 3 thread(s) for decompression. [ 187.691397] PM: Loading and decompressing image data (148650 pages)... [ 187.889719] PM: Image loading progress: 0% [ 188.100452] PM: Image loading progress: 10% [ 188.244781] PM: Image loading progress: 20% [ 189.057305] PM: Image loading done. [ 189.068793] PM: Image successfully loaded Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Chen Yu <yu.c.chen@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-07-22cpufreq: export cpufreq_driver_resolve_freq()Steve Muckle
Export cpufreq_driver_resolve_freq() since governors may be compiled as modules. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Steve Muckle <smuckle@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-07-22scripts/coccinelle: require coccinelle >= 1.0.4 on device_node_continue.cocciLuis R. Rodriguez
Make use of the new Requires: tag to be able to specify coccinelle binary version requirements. The cocci file device_node_continue.cocci requires at least coccinelle 1.0.4. Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> Acked-by: Julia Lawall <julia.lawall@lip6.fr> Acked-by: Nicolas Palix <nicolas.palix@imag.fr> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-07-22coccicheck: refer to Documentation/coccinelle.txt and wikiLuis R. Rodriguez
Refer to the Documentation/coccinelle.txt and supplemental documentation on the wiki: https://bottest.wiki.kernel.org/coccicheck This page shall always refer to the linux-next iteration of scripts/coccicheck. v4: only refer to the wiki as supplemental documentation, and also update Documentation/coccinelle.txt. Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> Acked-by: Nicolas Palix <nicolas.palix@imag.fr> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-07-22coccicheck: add support for requring a coccinelle versionLuis R. Rodriguez
Enable Coccinelle SmPL patches to require a specific version of Coccinelle. In the event that the version does not match we just inform the user, if the user asked to go through all SmPL patches we just inform them of the need for a new version of coccinelle for the SmPL patch and continue on with the rest. This uses the simple kernel scripts/ld-version.sh to create a weight on the version provided by spatch. The -dirty attribute is ignored if supplied, the benefit of scripts/ld-version.sh is it has a long history and well tested. While at it, document the // Options stuff as well. v4: Document // Options and // Requires as well on Documentation/coccinelle.txt. Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> Acked-by: Nicolas Palix <nicolas.palix@imag.fr> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-07-22scripts: add Linux .cocciconfig for coccinelleLuis R. Rodriguez
Coccinelle supports reading .cocciconfig, the order of precedence for variables for .cocciconfig is as follows: o Your current user's home directory is processed first o Your directory from which spatch is called is processed next o The directory provided with the --dir option is processed last, if used Since coccicheck runs through make, it naturally runs from the kernel proper dir, as such the second rule above would be implied for picking up a .cocciconfig when using 'make coccicheck'. 'make coccicheck' also supports using M= targets.If you do not supply any M= target, it is assumed you want to target the entire kernel. The kernel coccicheck script has: if [ "$KBUILD_EXTMOD" = "" ] ; then OPTIONS="--dir $srctree $COCCIINCLUDE" else OPTIONS="--dir $KBUILD_EXTMOD $COCCIINCLUDE" fi KBUILD_EXTMOD is set when an explicit target with M= is used. For both cases the spatch --dir argument is used, as such third rule applies when whether M= is used or not, and when M= is used the target directory can have its own .cocciconfig file. When M= is not passed as an argument to coccicheck the target directory is the same as the directory from where spatch was called. If not using the kernel's coccicheck target, keep the above precedence order logic of .cocciconfig reading. If using the kernel's coccicheck target, override any of the kernel's .coccicheck's settings using SPFLAGS. We help Coccinelle when used against Linux with a set of sensible defaults options for Linux with our own Linux .cocciconfig. This hints to coccinelle git can be used for 'git grep' queries over coccigrep. A timeout of 200 seconds should suffice for now. The options picked up by coccinelle when reading a .cocciconfig do not appear as arguments to spatch processes running on your system, to confirm what options will be used by Coccinelle run: spatch --print-options-only You can override with your own preferred index option by using SPFLAGS. Coccinelle supports both glimpse and idutils. Glimpse had historically provided the best performance, however recent benchmarks reveal idutils is performing just as well. Due to some recent fixes however you however will need at least coccinelle >= 1.0.6 if using idutils. Coccinelle carries a script scripts/idutils_index.sh which creates the idutils database with as follows: mkid -i C --output .id-utils.index If using just "--use-idutils" coccinelle expects your idutils database to be on the top level of the kernel as a file named ".id-utils.index". If you do not use this you can symlink your database file to it, or you can specify the database file following the "--use-idutils" argument. Examples: make SPFLAGS=--use-idutils coccicheck This assumes you have $srctree/.id-utils.index, where $srctree is the top level of the kernel. make SPFLAGS="--use-idutils /full-path/to/ID" coccicheck Here you specify the full path of the idutils ID database. Using .cocciconfig is possible, however given the order of precedence followed by Coccinelle, and since the kernel now carries its own .cocciconfig, you will need to use SPFLAGS to use idutils if desired. v4: o Recommend upgrade for using idutils with coccinelle due to some recent fixes. o Refer to using --print-options-only for testing what options are picked up by .cocciconfig reading. o Expand commit log considerably explaining *why* .cocconfig from two precedence rules are used when using coccicheck, and how to properly override these if needed. o Expand Documentation/coccinelle.txt v3: Expand commit log a bit more Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> Acked-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-07-22coccicheck: replace --very-quiet with --quiet when debuggingLuis R. Rodriguez
When debugging (using --profile or --show-trying) you want to avoid supressing output, use --quiet instead. While at it, extend documentation for SPFLAGS use. For instance one can use: $ export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci $ make coccicheck DEBUG_FILE="poo.err" MODE=report SPFLAGS="--profile --show-trying" M=./drivers/mfd/arizona-irq.c Expand Documentation/coccinelle.txt as well. v4: expand Documentation/coccinelle.txt v3: rebased, resolve conflicts, expand Documentation/coccinelle.txt v2: use egrep instead of the *"=--option"* check, this doesn't work for disjunctions. Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> Acked-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-07-22coccicheck: add support for DEBUG_FILELuis R. Rodriguez
Enable to capture stderr via a DEBUG_FILE variable passed to coccicheck. You can now do: $ rm -f cocci.err $ export COCCI=scripts/coccinelle/free/kfree.cocci $ make coccicheck MODE=report DEBUG_FILE=cocci.err ... $ cat cocci.err This will be come more useful once we add support to use more things which would go into stderr, such as profiling. That will be done separately in another commit. Expand Documentation/coccinelle.txt with details. Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> Acked-by: Nicolas Palix <nicolas.palix@imag.fr> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-07-22coccicheck: enable parmap supportLuis R. Rodriguez
Coccinelle has had parmap support since 1.0.2, this means it supports --jobs, enabling built-in multithreaded functionality, instead of needing one to script it out. Just look for --jobs in the help output to determine if this is supported and use it only if your number of processors detected is > 1. If parmap is enabled also enable the load balancing to be dynamic, so that if a thread finishes early we keep feeding it. stderr is currently sent to /dev/null, addressing a way to capture that will be addressed next. If --jobs is not supported we fallback to the old mechanism. We expect to deprecate the old mechanism as soon as we can get confirmation all users are ready. While at it propagate back into the shell script any coccinelle error code. When used in serialized mode where all cocci files are run this also stops processing if an error has occured. This lets us handle some errors in coccinelle cocci files and if they bail out we should inspect the errors. This will be more useful later to help annotate coccinelle version dependency requirements. This will let you run only SmPL files that your system supports. Extend Documentation/coccinelle.txt as well. As a small example, prior to this change, on an 8-core system: Before: $ export COCCI=scripts/coccinelle/free/kfree.cocci $ time make coccicheck MODE=report ... real 29m14.912s user 103m1.796s sys 0m4.464s After: real 16m22.435s user 128m30.060s sys 0m2.712s v4: o expand Documentation/coccinelle.txt to reflect parmap support info o update commit log to reflect what we actually do now with stderr o split out DEBUG_FILE use into another patch o detect number of CPUs and if its 1 then skip parmap support, note that if you still support parmap, but have 1 CPU you will also go through the new branches, so the old complex multithreaded process is skipped as well. v3: o move USE_JOBS to avoid being overriden v2: o redirect coccinelle stderr to /dev/null by default and only if DEBUG_FILE is used do we pass it to a file o fix typo of paramap/parmap Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> Acked-by: Nicolas Palix <nicolas.palix@imag.fr> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-07-22coccicheck: make SPFLAGS more usefulLuis R. Rodriguez
SPFLAGS is set early, it means that any heuristics done on coccicheck cannot be overridden currently. Move SPFLAGS after OPTIONS and set this at the end. This lets you override any heuristics as coccinelle treats conflicts by only listening to the last option that makes sense. v3: this patch was added in the v3 series v4: Update Documentation/coccinelle.txt explaining how SPFLAGS works as well. Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> Acked-by: Nicolas Palix <nicolas.palix@imag.fr> Signed-off-by: Michal Marek <mmarek@suse.com>