aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2016-12-12libceph: drop len argument of *verify_authorizer_reply()Ilya Dryomov7-12/+11
The length of the reply is protocol-dependent - for cephx it's ceph_x_authorize_reply. Nothing sensible can be passed from the messenger layer anyway. Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Sage Weil <sage@redhat.com>
2016-12-12libceph: verify authorize reply on connectIlya Dryomov1-0/+13
After sending an authorizer (ceph_x_authorize_a + ceph_x_authorize_b), the client gets back a ceph_x_authorize_reply, which it is supposed to verify to ensure the authenticity and protect against replay attacks. The code for doing this is there (ceph_x_verify_authorizer_reply(), ceph_auth_verify_authorizer_reply() + plumbing), but it is never invoked by the the messenger. AFAICT this goes back to 2009, when ceph authentication protocols support was added to the kernel client in 4e7a5dcd1bba ("ceph: negotiate authentication protocol; implement AUTH_NONE protocol"). The second param of ceph_connection_operations::verify_authorizer_reply is unused all the way down. Pass 0 to facilitate backporting, and kill it in the next commit. Cc: stable@vger.kernel.org Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Sage Weil <sage@redhat.com>
2016-12-12libceph: no need for GFP_NOFS in ceph_monc_init()Ilya Dryomov1-6/+6
It's called during inital setup, when everything should be allocated with GFP_KERNEL. Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Sage Weil <sage@redhat.com>
2016-12-12libceph: stop allocating a new cipher on every crypto requestIlya Dryomov2-25/+61
This is useless and more importantly not allowed on the writeback path, because crypto_alloc_skcipher() allocates memory with GFP_KERNEL, which can recurse back into the filesystem: kworker/9:3 D ffff92303f318180 0 20732 2 0x00000080 Workqueue: ceph-msgr ceph_con_workfn [libceph] ffff923035dd4480 ffff923038f8a0c0 0000000000000001 000000009eb27318 ffff92269eb28000 ffff92269eb27338 ffff923036b145ac ffff923035dd4480 00000000ffffffff ffff923036b145b0 ffffffff951eb4e1 ffff923036b145a8 Call Trace: [<ffffffff951eb4e1>] ? schedule+0x31/0x80 [<ffffffff951eb77a>] ? schedule_preempt_disabled+0xa/0x10 [<ffffffff951ed1f4>] ? __mutex_lock_slowpath+0xb4/0x130 [<ffffffff951ed28b>] ? mutex_lock+0x1b/0x30 [<ffffffffc0a974b3>] ? xfs_reclaim_inodes_ag+0x233/0x2d0 [xfs] [<ffffffff94d92ba5>] ? move_active_pages_to_lru+0x125/0x270 [<ffffffff94f2b985>] ? radix_tree_gang_lookup_tag+0xc5/0x1c0 [<ffffffff94dad0f3>] ? __list_lru_walk_one.isra.3+0x33/0x120 [<ffffffffc0a98331>] ? xfs_reclaim_inodes_nr+0x31/0x40 [xfs] [<ffffffff94e05bfe>] ? super_cache_scan+0x17e/0x190 [<ffffffff94d919f3>] ? shrink_slab.part.38+0x1e3/0x3d0 [<ffffffff94d9616a>] ? shrink_node+0x10a/0x320 [<ffffffff94d96474>] ? do_try_to_free_pages+0xf4/0x350 [<ffffffff94d967ba>] ? try_to_free_pages+0xea/0x1b0 [<ffffffff94d863bd>] ? __alloc_pages_nodemask+0x61d/0xe60 [<ffffffff94ddf42d>] ? cache_grow_begin+0x9d/0x560 [<ffffffff94ddfb88>] ? fallback_alloc+0x148/0x1c0 [<ffffffff94ed84e7>] ? __crypto_alloc_tfm+0x37/0x130 [<ffffffff94de09db>] ? __kmalloc+0x1eb/0x580 [<ffffffffc09fe2db>] ? crush_choose_firstn+0x3eb/0x470 [libceph] [<ffffffff94ed84e7>] ? __crypto_alloc_tfm+0x37/0x130 [<ffffffff94ed9c19>] ? crypto_spawn_tfm+0x39/0x60 [<ffffffffc08b30a3>] ? crypto_cbc_init_tfm+0x23/0x40 [cbc] [<ffffffff94ed857c>] ? __crypto_alloc_tfm+0xcc/0x130 [<ffffffff94edcc23>] ? crypto_skcipher_init_tfm+0x113/0x180 [<ffffffff94ed7cc3>] ? crypto_create_tfm+0x43/0xb0 [<ffffffff94ed83b0>] ? crypto_larval_lookup+0x150/0x150 [<ffffffff94ed7da2>] ? crypto_alloc_tfm+0x72/0x120 [<ffffffffc0a01dd7>] ? ceph_aes_encrypt2+0x67/0x400 [libceph] [<ffffffffc09fd264>] ? ceph_pg_to_up_acting_osds+0x84/0x5b0 [libceph] [<ffffffff950d40a0>] ? release_sock+0x40/0x90 [<ffffffff95139f94>] ? tcp_recvmsg+0x4b4/0xae0 [<ffffffffc0a02714>] ? ceph_encrypt2+0x54/0xc0 [libceph] [<ffffffffc0a02b4d>] ? ceph_x_encrypt+0x5d/0x90 [libceph] [<ffffffffc0a02bdf>] ? calcu_signature+0x5f/0x90 [libceph] [<ffffffffc0a02ef5>] ? ceph_x_sign_message+0x35/0x50 [libceph] [<ffffffffc09e948c>] ? prepare_write_message_footer+0x5c/0xa0 [libceph] [<ffffffffc09ecd18>] ? ceph_con_workfn+0x2258/0x2dd0 [libceph] [<ffffffffc09e9903>] ? queue_con_delay+0x33/0xd0 [libceph] [<ffffffffc09f68ed>] ? __submit_request+0x20d/0x2f0 [libceph] [<ffffffffc09f6ef8>] ? ceph_osdc_start_request+0x28/0x30 [libceph] [<ffffffffc0b52603>] ? rbd_queue_workfn+0x2f3/0x350 [rbd] [<ffffffff94c94ec0>] ? process_one_work+0x160/0x410 [<ffffffff94c951bd>] ? worker_thread+0x4d/0x480 [<ffffffff94c95170>] ? process_one_work+0x410/0x410 [<ffffffff94c9af8d>] ? kthread+0xcd/0xf0 [<ffffffff951efb2f>] ? ret_from_fork+0x1f/0x40 [<ffffffff94c9aec0>] ? kthread_create_on_node+0x190/0x190 Allocating the cipher along with the key fixes the issue - as long the key doesn't change, a single cipher context can be used concurrently in multiple requests. We still can't take that GFP_KERNEL allocation though. Both ceph_crypto_key_clone() and ceph_crypto_key_decode() are called from GFP_NOFS context, so resort to memalloc_noio_{save,restore}() here. Reported-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Sage Weil <sage@redhat.com>
2016-12-12libceph: uninline ceph_crypto_key_destroy()Ilya Dryomov2-8/+9
Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Sage Weil <sage@redhat.com>
2016-12-12libceph: remove now unused ceph_*{en,de}crypt*() functionsIlya Dryomov2-383/+0
Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Sage Weil <sage@redhat.com>
2016-12-12libceph: switch ceph_x_decrypt() to ceph_crypt()Ilya Dryomov1-46/+32
Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Sage Weil <sage@redhat.com>
2016-12-12libceph: switch ceph_x_encrypt() to ceph_crypt()Ilya Dryomov1-34/+37
Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Sage Weil <sage@redhat.com>
2016-12-12libceph: tweak calcu_signature() a littleIlya Dryomov1-15/+28
- replace an ad-hoc array with a struct - rename to calc_signature() for consistency Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Sage Weil <sage@redhat.com>
2016-12-12libceph: rename and align ceph_x_authorizer::reply_bufIlya Dryomov2-6/+7
It's going to be used as a temporary buffer for in-place en/decryption with ceph_crypt() instead of on-stack buffers, so rename to enc_buf. Ensure alignment to avoid GFP_ATOMIC allocations in the crypto stack. Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Sage Weil <sage@redhat.com>
2016-12-12libceph: introduce ceph_crypt() for in-place en/decryptionIlya Dryomov2-0/+89
Starting with 4.9, kernel stacks may be vmalloced and therefore not guaranteed to be physically contiguous; the new CONFIG_VMAP_STACK option is enabled by default on x86. This makes it invalid to use on-stack buffers with the crypto scatterlist API, as sg_set_buf() expects a logical address and won't work with vmalloced addresses. There isn't a different (e.g. kvec-based) crypto API we could switch net/ceph/crypto.c to and the current scatterlist.h API isn't getting updated to accommodate this use case. Allocating a new header and padding for each operation is a non-starter, so do the en/decryption in-place on a single pre-assembled (header + data + padding) heap buffer. This is explicitly supported by the crypto API: "... the caller may provide the same scatter/gather list for the plaintext and cipher text. After the completion of the cipher operation, the plaintext data is replaced with the ciphertext data in case of an encryption and vice versa for a decryption." Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Sage Weil <sage@redhat.com>
2016-12-12libceph: introduce ceph_x_encrypt_offset()Ilya Dryomov1-2/+6
Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Sage Weil <sage@redhat.com>
2016-12-12libceph: old_key in process_one_ticket() is redundantIlya Dryomov1-3/+1
Since commit 0a990e709356 ("ceph: clean up service ticket decoding"), th->session_key isn't assigned until everything is decoded. Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Sage Weil <sage@redhat.com>
2016-12-12libceph: ceph_x_encrypt_buflen() takes in_lenIlya Dryomov1-3/+4
Pass what's going to be encrypted - that's msg_b, not ticket_blob. ceph_x_encrypt_buflen() returns the upper bound, so this doesn't change the maxlen calculation, but makes it a bit clearer. Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Sage Weil <sage@redhat.com>
2016-12-11Linux 4.9Linus Torvalds1-2/+2
2016-12-11MIPS: Lantiq: Fix mask of GPE frequencyHauke Mehrtens1-1/+1
The hardware documentation says bit 11:10 are used for the GPE frequency selection. Fix the mask in the define to match these bits. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Thomas Langer <thomas.langer@intel.com> Cc: linux-mips@linux-mips.org Cc: john@phrozen.org Patchwork: https://patchwork.linux-mips.org/patch/14648/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-12-11MIPS: Return -ENODEV from weak implementation of rtc_mips_set_timeLuuk Paulussen1-1/+1
The sync_cmos_clock function in kernel/time/ntp.c first tries to update the internal clock of the cpu by calling the "update_persistent_clock64" architecture specific function. If this returns -ENODEV, it then tries to update an external RTC using "rtc_set_ntp_time". On the mips architecture, the weak implementation of the underlying function would return 0 if it wasn't overridden. This meant that the sync_cmos_clock function would never try to update an external RTC (if both CONFIG_GENERIC_CMOS_UPDATE and CONFIG_RTC_SYSTOHC are configured) Returning -ENODEV instead, means that an external RTC will be tried. Signed-off-by: Luuk Paulussen <luuk.paulussen@alliedtelesis.co.nz> Reviewed-by: Richard Laing <richard.laing@alliedtelesis.co.nz> Reviewed-by: Scott Parlane <scott.parlane@alliedtelesis.co.nz> Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14649/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-12-09net: mlx5: Fix Kconfig help textChristopher Covington1-2/+0
Since the following commit, Infiniband and Ethernet have not been mutually exclusive. Fixes: 4aa17b28 mlx5: Enable mutual support for IB and Ethernet Signed-off-by: Christopher Covington <cov@codeaurora.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-09net: smsc911x: back out silently on probe deferralsLinus Walleij1-1/+8
When trying to get a regulator we may get deferred and we see this noise: smsc911x 1b800000.ethernet-ebi2 (unnamed net_device) (uninitialized): couldn't get regulators -517 Then the driver continues anyway. Which means that the regulator may not be properly retrieved and reference counted, and may be switched off in case noone else is using it. Fix this by returning silently on deferred probe and let the system work it out. Cc: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-09ibmveth: set correct gso_size and gso_typeThomas Falcon2-2/+64
This patch is based on an earlier one submitted by Jon Maxwell with the following commit message: "We recently encountered a bug where a few customers using ibmveth on the same LPAR hit an issue where a TCP session hung when large receive was enabled. Closer analysis revealed that the session was stuck because the one side was advertising a zero window repeatedly. We narrowed this down to the fact the ibmveth driver did not set gso_size which is translated by TCP into the MSS later up the stack. The MSS is used to calculate the TCP window size and as that was abnormally large, it was calculating a zero window, even although the sockets receive buffer was completely empty." We rely on the Virtual I/O Server partition in a pseries environment to provide the MSS through the TCP header checksum field. The stipulation is that users should not disable checksum offloading if rx packet aggregation is enabled through VIOS. Some firmware offerings provide the MSS in the RX buffer. This is signalled by a bit in the RX queue descriptor. Reviewed-by: Brian King <brking@linux.vnet.ibm.com> Reviewed-by: Pradeep Satyanarayana <pradeeps@linux.vnet.ibm.com> Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Reviewed-by: Jonathan Maxwell <jmaxwell37@gmail.com> Reviewed-by: David Dai <zdai@us.ibm.com> Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-09Revert "radix tree test suite: fix compilation"Linus Torvalds3-1/+30
This reverts commit 53855d10f4567a0577360b6448d52a863929775b. It shouldn't have come in yet - it depends on the changes in linux-next that will come in during the next merge window. As Matthew Wilcox says, the test suite is broken with the current state without the revert. Requested-by: Matthew Wilcox <mawilcox@microsoft.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-12-08net: ethernet: cpmac: Call SET_NETDEV_DEV()Florian Fainelli1-0/+1
The TI CPMAC driver calls into PHYLIB which now checks for net_device->dev.parent, so make sure we do set it before calling into any MDIO/PHYLIB related function. Fixes: ec988ad78ed6 ("phy: Don't increment MDIO bus refcount unless it's a different owner") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-08net: ethernet: lantiq_etop: Call SET_NETDEV_DEV()Florian Fainelli1-0/+1
The Lantiq Etop driver calls into PHYLIB which now checks for net_device->dev.parent, so make sure we do set it before calling into any MDIO/PHYLIB related function. Fixes: ec988ad78ed6 ("phy: Don't increment MDIO bus refcount unless it's a different owner") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-08vhost-vsock: fix orphan connection resetPeng Tao1-1/+1
local_addr.svm_cid is host cid. We should check guest cid instead, which is remote_addr.svm_cid. Otherwise we end up resetting all connections to all guests. Cc: stable@vger.kernel.org [4.8+] Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Peng Tao <bergwolf@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-08cxgb4/cxgb4vf: Assign netdev->dev_port with port IDArjun V3-1/+2
Added missing dev_port assignment in cxgb4vf driver. Also made dev_port assignment of cxgb4 in sync with cxgb4vf driver. Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: Arjun V <arjun@chelsio.com> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-08parisc: Fix TLB related boot crash on SMP machinesHelge Deller1-0/+11
At bootup we run measurements to calculate the best threshold for when we should be using full TLB flushes instead of just flushing a specific amount of TLB entries. This performance test is run over the kernel text segment. But running this TLB performance test on the kernel text segment turned out to crash some SMP machines when the kernel text pages were mapped as huge pages. To avoid those crashes this patch simply skips this test on some SMP machines and calculates an optimal threshold based on the maximum number of available TLB entries and number of online CPUs. On a technical side, this seems to happen: The TLB measurement code uses flush_tlb_kernel_range() to flush specific TLB entries with a page size of 4k (pdtlb 0(sr1,addr)). On UP systems this purge instruction seems to work without problems even if the pages were mapped as huge pages. But on SMP systems the TLB purge instruction is broadcasted to other CPUs. Those CPUs then crash the machine because the page size is not as expected. C8000 machines with PA8800/PA8900 CPUs were not affected by this problem, because the required cache coherency prohibits to use huge pages at all. Sadly I didn't found any documentation about this behaviour, so this finding is purely based on testing with phyiscal SMP machines (A500-44 and J5000, both were 2-way boxes). Cc: <stable@vger.kernel.org> # v3.18+ Signed-off-by: Helge Deller <deller@gmx.de>
2016-12-08driver: ipvlan: Unlink the upper dev when ipvlan_link_new failedGao Feng1-1/+3
When netdev_upper_dev_unlink failed in ipvlan_link_new, need to unlink the ipvlan dev with upper dev. Signed-off-by: Gao Feng <fgao@ikuai8.com> Acked-by: Mahesh Bandewar <maheshb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-08ser_gigaset: return -ENOMEM on error instead of successDan Carpenter1-1/+3
If we can't allocate the resources in gigaset_initdriver() then we should return -ENOMEM instead of zero. Fixes: 2869b23e4b95 ("[PATCH] drivers/isdn/gigaset: new M101 driver (v2)") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-08ARM: dts: orion5x: fix number of sata port for linkstation ls-glRoger Shimizu1-0/+4
Bug report from Debian [0] shows there's minor changed model of Linkstation LS-GL that uses the 2nd SATA port of the SoC. So it's necessary to enable two SATA ports, though for that specific model only the 2nd one is used. [0] https://bugs.debian.org/845611 Fixes: b1742ffa9ddb ("ARM: dts: orion5x: add device tree for buffalo linkstation ls-gl") Reported-by: Ryan Tandy <ryan@nardis.ca> Tested-by: Ryan Tandy <ryan@nardis.ca> Signed-off-by: Roger Shimizu <rogershimizu@gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2016-12-08NET: usb: cdc_mbim: add quirk for supporting Telit LE922ADaniele Palmas3-6/+32
Telit LE922A MBIM based composition does not work properly with altsetting toggle done in cdc_ncm_bind_common. This patch adds CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE quirk to avoid this procedure that, instead, is mandatory for other modems. Signed-off-by: Daniele Palmas <dnlplm@gmail.com> Reviewed-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-08can: peak: fix bad memory access and free sequence추지호1-2/+4
Fix for bad memory access while disconnecting. netdev is freed before private data free, and dev is accessed after freeing netdev. This makes a slub problem, and it raise kernel oops with slub debugger config. Signed-off-by: Jiho Chu <jiho.chu@samsung.com> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2016-12-08ceph: don't set req->r_locked_dir in ceph_d_revalidateJeff Layton1-10/+14
This function sets req->r_locked_dir which is supposed to indicate to ceph_fill_trace that the parent's i_rwsem is locked for write. Unfortunately, there is no guarantee that the dir will be locked when d_revalidate is called, so we really don't want ceph_fill_trace to do any dcache manipulation from this context. Clear req->r_locked_dir since it's clearly not safe to do that. What we really want to know with d_revalidate is whether the dentry still points to the same inode. ceph_fill_trace installs a pointer to the inode in req->r_target_inode, so we can just compare that to d_inode(dentry) to see if it's the same one after the lookup. Also, since we aren't generally interested in the parent here, we can switch to using a GETATTR to hint that to the MDS, which also means that we only need to reserve one cap. Finally, just remove the d_unhashed check. That's really outside the purview of a filesystem's d_revalidate. If the thing became unhashed while we're checking it, then that's up to the VFS to handle anyway. Fixes: 200fd27c8fa2 ("ceph: use lookup request to revalidate dentry") Link: http://tracker.ceph.com/issues/18041 Reported-by: Donatas Abraitis <donatas.abraitis@gmail.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Reviewed-by: "Yan, Zheng" <zyan@redhat.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2016-12-08crypto: algif_aead - fix uninitialized variable warningStephan Mueller1-1/+1
In case the user provided insufficient data, the code may return prematurely without any operation. In this case, the processed data indicated with outlen is zero. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-12-07kcov: add missing #include <linux/sched.h>Kefeng Wang1-0/+1
In __sanitizer_cov_trace_pc we use task_struct and fields within it, but as we haven't included <linux/sched.h>, it is not guaranteed to be defined. While we usually happen to acquire the definition through a transitive include, this is fragile (and hasn't been true in the past, causing issues with backports). Include <linux/sched.h> to avoid any fragility. [mark.rutland@arm.com: rewrote changelog] Link: http://lkml.kernel.org/r/1481007384-27529-1-git-send-email-wangkefeng.wang@huawei.com Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: James Morse <james.morse@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-12-07radix tree test suite: fix compilationMatthew Wilcox3-30/+1
Patch "lib/radix-tree: Convert to hotplug state machine" breaks the test suite as it adds a call to cpuhp_setup_state_nocalls() which is not currently emulated in the test suite. Add it, and delete the emulation of the old CPU hotplug mechanism. Link: http://lkml.kernel.org/r/1480369871-5271-36-git-send-email-mawilcox@linuxonhyperv.com Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com> Tested-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Konstantin Khlebnikov <koct9i@gmail.com> Cc: Ross Zwisler <ross.zwisler@linux.intel.com> Cc: Matthew Wilcox <mawilcox@microsoft.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-12-07zram: restrict add/remove attributes to root onlySergey Senozhatsky1-1/+7
zram hot_add sysfs attribute is a very 'special' attribute - reading from it creates a new uninitialized zram device. This file, by a mistake, can be read by a 'normal' user at the moment, while only root must be able to create a new zram device, therefore hot_add attribute must have S_IRUSR mode, not S_IRUGO. [akpm@linux-foundation.org: s/sence/sense/, reflow comment to use 80 cols] Fixes: 6566d1a32bf72 ("zram: add dynamic device add/remove functionality") Link: http://lkml.kernel.org/r/20161205155845.20129-1-sergey.senozhatsky@gmail.com Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Reported-by: Steven Allen <steven@stebalien.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Minchan Kim <minchan@kernel.org> Cc: <stable@vger.kernel.org> [4.2+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-12-07libata-scsi: disable SCT Write Same for the momentNicolai Stange1-0/+1
SCT Write Same support had been introduced with commit 7b2030942859 ("libata: Add support for SCT Write Same") Some problems, namely excessive userspace segfaults, had been reported at http://lkml.kernel.org/r/20160908192736.GA4356@gmail.com This lead to commit 0ce1b18c42a5 ("libata: Some drives failing on SCT Write Same") which strived to disable SCT Write Same on !ZAC devices. Due to the way this was done and to the logic in sd_config_write_same(), this didn't work for those devices that have ->max_ws_blocks > SD_MAX_WS10_BLOCKS: for these, ->no_write_same and ->max_write_same_sectors would still be non-zero, but ->ws10 == ->ws16 == 0. This would cause sd_setup_write_same_cmnd() to demultiplex REQ_OP_WRITE_SAME requests to WRITE_SAME, and these in turn aren't supported by libata-scsi: EXT4-fs (dm-1): Delayed block allocation failed for inode 2625094 at logical offset 2032 with max blocks 2 with error 121 EXT4-fs (dm-1): This should not happen!! Data will be lost 121 == EREMOTEIO is what scsi_io_completion() asserts in case of invalid opcodes. Back to the original problem of userspace segfaults: this can be tracked down to ata_format_sct_write_same() overwriting the input page. Sometimes, this page is ZERO_PAGE(0) which ceases to be filled with zeros from that point on. Since ZERO_PAGE(0) is used for userspace .bss mappings, code of the following is doomed: static char *a = NULL; /* .bss */ ... if (a) *a = 'a'; This problem is not solved by disabling SCT Write Same for !ZAC devices only. It can certainly be fixed, but the final release is quite close -- so disable SCT Write Same for all ATA devices rather than introducing some SCT key buffer allocation schemes at this point. Fixes: 7b2030942859 ("libata: Add support for SCT Write Same") Signed-off-by: Nicolai Stange <nicstange@gmail.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2016-12-07ARM: dts: imx7d: fix LCDIF clock assignmentStefan Agner1-3/+2
The eLCDIF IP of the i.MX 7 SoC knows multiple clocks and lists them separately: Clock Clock Root Description apb_clk MAIN_AXI_CLK_ROOT AXI clock pix_clk LCDIF_PIXEL_CLK_ROOT Pixel clock ipg_clk_s MAIN_AXI_CLK_ROOT Peripheral access clock All of them are switched by a single gate, which is part of the IMX7D_LCDIF_PIXEL_ROOT_CLK clock. Hence using that clock also for the AXI bus clock (clock-name "axi") makes sure the gate gets enabled when accessing registers. There seem to be no separate AXI display clock, and the clock is optional. Hence remove the dummy clock. This fixes kernel freezes when starting the X-Server (which disables/re-enables the display controller). Fixes: e8ed73f691bd ("ARM: dts: imx7d: add lcdif support") Signed-off-by: Stefan Agner <stefan@agner.ch> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com> Acked-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Olof Johansson <olof@lixom.net>
2016-12-07dts: sun8i-h3: correct UART3 pin definitionsJorik Jonker1-1/+1
In a previous commit, I made a copy/paste error in the pinmux definitions of UART3: PG{13,14} instead of PA{13,14}. This commit takes care of that. I have tested this commit on Orange Pi PC and Orange Pi Plus, and it works for these boards. Fixes: e3d11d3c45c5 ("dts: sun8i-h3: add pinmux definitions for UART2-3") Signed-off-by: Jorik Jonker <jorik@kippendief.biz> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2016-12-07phy: Don't increment MDIO bus refcount unless it's a different ownerFlorian Fainelli1-3/+13
Commit 3e3aaf649416 ("phy: fix mdiobus module safety") fixed the way we dealt with MDIO bus module reference count, but sort of introduced a regression in that, if an Ethernet driver registers its own MDIO bus driver, as is common, we will end up with the Ethernet driver's module->refnct set to 1, thus preventing this driver from any removal. Fix this by comparing the network device's device driver owner against the MDIO bus driver owner, and only if they are different, increment the MDIO bus module refcount. Fixes: 3e3aaf649416 ("phy: fix mdiobus module safety") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-07netvsc: reduce maximum GSO sizestephen hemminger1-0/+5
Hyper-V (and Azure) support using NVGRE which requires some extra space for encapsulation headers. Because of this the largest allowed TSO packet is reduced. For older releases, hard code a fixed reduced value. For next release, there is a better solution which uses result of host offload negotiation. Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-07drivers: net: cpsw-phy-sel: Clear RGMII_IDMODE on "rgmii" linksAlex1-0/+1
Support for setting the RGMII_IDMODE bit was added in the commit referenced below. However, that commit did not add the symmetrical clearing of the bit by way of setting it in "mask". Add it here. Note that the documentation marks clearing this bit as "reserved", however, according to TI, support for delaying the clock does exist in the MAC, although it is not officially supported. We tested this on a board with an RGMII to RGMII link that will not work unless this bit is cleared. Fixes: 0fb26c3063ea ("drivers: net: cpsw-phy-sel: add support to configure rgmii internal delay") Signed-off-by: Alexandru Gagniuc <alex.g@adaptrum.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-07Revert "default exported asm symbols to zero"Linus Torvalds1-1/+0
This reverts commit 8ab2ae655bfe384335c5b6b0d6041e0ddce26b00. I loved that commit because of how it explained what the problem with newer versions of binutils were, but the actual patch itself turns out to not work very well. It has two problems: - a zero CRC value isn't actually right. It happens to work for the case where both sides of the equation fail at giving the symbol a crc, but there are cases where the users of the exported symbol get the right crc (due to seeing the C declarations), but the actual exporting itself does not (due to the whole weak asm symbol issue). So then the module load fails after all - we did have a crc for the symbol, but we couldn't match it with the loaded module. - it seems that the alpha assembler has special semantics for the '.set' directive, and on alpha it doesn't actually set the value of the specified symbol at all, it is instead used to set various assembly modes (eg ".set noat" and ".set noreorder"). So using ".set" to set the symbol value would just cause build failures on alpha. I'm sure we'll find some other workaround for these issues (hopefully that involves getting rid of modversions entirely some day, but people are also talking about just using smarter tools). But for now we'll just fall back on commit faaae2a58143 ("Re-enable CONFIG_MODVERSIONS in a slightly weaker form") that just let's a missing crc through. Reported-by: Jan Stancek <jstancek@redhat.com> Reported-by: Philip Müller <philm@manjaro.org> Reported-by: Guenter Roeck <linux@roeck-us.net> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-12-07Don't feed anything but regular iovec's to blk_rq_map_user_iovLinus Torvalds1-0/+4
In theory we could map other things, but there's a reason that function is called "user_iov". Using anything else (like splice can do) just confuses it. Reported-and-tested-by: Johannes Thumshirn <jthumshirn@suse.de> Cc: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-12-07drm/amdgpu: just suspend the hw on pci shutdownAlex Deucher3-2/+6
We can't just reuse pci_remove as there may be userspace still doing things. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98638 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97980 Reviewed-by: Christian König <christian.koenig@amd.com> Reported-and-tested-by: Mike Lothian <mike@fireburn.co.uk> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-12-07crypto: mcryptd - Check mcryptd algorithm compatibilitytim1-7/+12
Algorithms not compatible with mcryptd could be spawned by mcryptd with a direct crypto_alloc_tfm invocation using a "mcryptd(alg)" name construct. This causes mcryptd to crash the kernel if an arbitrary "alg" is incompatible and not intended to be used with mcryptd. It is an issue if AF_ALG tries to spawn mcryptd(alg) to expose it externally. But such algorithms must be used internally and not be exposed. We added a check to enforce that only internal algorithms are allowed with mcryptd at the time mcryptd is spawning an algorithm. Link: http://marc.info/?l=linux-crypto-vger&m=148063683310477&w=2 Cc: stable@vger.kernel.org Reported-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-12-07crypto: algif_aead - fix AEAD tag memory handlingStephan Mueller1-21/+36
For encryption, the AEAD ciphers require AAD || PT as input and generate AAD || CT || Tag as output and vice versa for decryption. Prior to this patch, the AF_ALG interface for AEAD ciphers requires the buffer to be present as input for encryption. Similarly, the output buffer for decryption required the presence of the tag buffer too. This implies that the kernel reads / writes data buffers from/to kernel space even though this operation is not required. This patch changes the AF_ALG AEAD interface to be consistent with the in-kernel AEAD cipher requirements. Due to this handling, he changes are transparent to user space with one exception: the return code of recv indicates the mount of output buffer. That output buffer has a different size compared to before the patch which implies that the return code of recv will also be different. For example, a decryption operation uses 16 bytes AAD, 16 bytes CT and 16 bytes tag, the AF_ALG AEAD interface before showed a recv return code of 48 (bytes) whereas after this patch, the return code is 32 since the tag is not returned any more. Reported-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-12-07crypto: caam - fix pointer size for AArch64 boot loader, AArch32 kernelHoria Geantă1-2/+3
Start with a clean slate before dealing with bit 16 (pointer size) of Master Configuration Register. This fixes the case of AArch64 boot loader + AArch32 kernel, when the boot loader might set MCFGR[PS] and kernel would fail to clear it. Cc: <stable@vger.kernel.org> Reported-by: Alison Wang <alison.wang@nxp.com> Signed-off-by: Horia Geantă <horia.geanta@nxp.com> Reviewed-By: Alison Wang <Alison.wang@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-12-07crypto: marvell - Don't corrupt state of an STD req for re-stepped ahashRomain Perier1-3/+5
mv_cesa_hash_std_step() copies the creq->state into the SRAM at each step, but this is only required on the first one. By doing that, we overwrite the engine state, and get erroneous results when the crypto request is split in several chunks to fit in the internal SRAM. This commit changes the function to copy the state only on the first step. Fixes: commit 2786cee8e50b ("crypto: marvell - Move SRAM I/O op...") Signed-off-by: Romain Perier <romain.perier@free-electrons.com> Cc: <stable@vger.kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-12-07crypto: marvell - Don't copy hash operation twice into the SRAMRomain Perier1-3/+0
No need to copy the template of an hash operation twice into the SRAM from the step function. Fixes: commit 85030c5168f1 ("crypto: marvell - Add support for chai...") Signed-off-by: Romain Perier <romain.perier@free-electrons.com> Cc: <stable@vger.kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.