- 15 Sep, 2016 40 commits
-
-
Matthew R. Ochs authored
[ Upstream commit d5e26bb1 ] Applications which use virtual LUN's that are backed by a physical LUN over both adapter ports may experience an I/O failure in the event of a link loss (e.g. cable pull). Virtual LUNs may be accessed through one or both ports of the adapter. This access is encoded in the translation entries that comprise the virtual LUN and used by the AFU for load-balancing I/O and handling failover scenarios. In a link loss scenario, even though the AFU is able to maintain connectivity to the LUN, it is up to the application to retry the failed I/O. When applications are unaware of the virtual LUN's underlying topology, they are unable to make a sound decision of when to retry an I/O and therefore are forced to make their reaction to a failed I/O absolute. The result is either a failure to retry I/O or increased latency for scenarios where a retry is pointless. To remedy this scenario, provide feedback back to the application on virtual LUN creation as to which ports the LUN may be accessed. LUN's spanning both ports are candidates for a retry in a presence of an I/O failure. Signed-off-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Acked-by:
Manoj Kumar <manoj@linux.vnet.ibm.com> Reviewed-by:
Uma Krishnan <ukrishn@linux.vnet.ibm.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Sasha Levin <alexander.levin@verizon.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Manoj Kumar authored
[ Upstream commit a9be294e ] The original fix to escalate a 'login timed out' error to a LINK_RESET was only made for one of the two ports on the card. This fix resolves the same issue for the second port (port 1). Signed-off-by:
-
Richard Alpe authored
[ Upstream commit 55e77a3e ] Fix incorrect use of nla_strlcpy() where the first NLA_HDRLEN bytes of the link name where left out. Making the output of tipc-config -ls look something like: Link statistics: dcast-link 1:data0-1.1.2:data0 1:data0-1.1.3:data0 Also, for the record, the patch that introduce this regression claims "Sending the whole object out can cause a leak". Which isn't very likely as this is a compat layer, where the data we are parsing is generated by us and we know the string to be NULL terminated. But you can of course never be to secure. Fixes: 5d2be142 (tipc: fix an infoleak in tipc_nl_compat_link_dump) Signed-off-by:
Richard Alpe <richard.alpe@ericsson.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Kangjie Lu authored
[ Upstream commit 5d2be142 ] link_info.str is a char array of size 60. Memory after the NULL byte is not initialized. Sending the whole object out can cause a leak. Signed-off-by:
Kangjie Lu <kjlu@gatech.edu> Signed-off-by:
-
Florian Westphal authored
[ Upstream commit d157bd76 ] Ben Hawkes says: integer overflow in xt_alloc_table_info, which on 32-bit systems can lead to small structure allocation and a copy_from_user based heap corruption. Reported-by:
Ben Hawkes <hawkes@google.com> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Tedd Ho-Jeong An authored
[ Upstream commit a0af53b5 ] This patch adds support for Intel Bluetooth device 8265 also known as Windstorm Peak (WsP). T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 6 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=8087 ProdID=0a2b Rev= 0.10 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by:
Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Ville Syrjälä authored
[ Upstream commit 22f35042 ] Apparently some CHV boards failed to hook up the port presence straps for HDMI ports as well (earlier we assumed this problem only affected eDP ports). So let's check the VBT in addition to the strap, and if either one claims that the port is present go ahead and register the relevant connector. While at it, change port D to register DP before HDMI as we do for ports B and C since commit 457c52d8 ("drm/i915: Only ignore eDP ports that are connected") Also print a debug message when we register a HDMI connector to aid in diagnosing missing/incorrect ports. We already had such a print for DP/eDP. v2: Improve the comment in the code a bit, note the port D change in the commit message Cc: Radoslav Duda <radosd@radosd.com> Tested-by:
Radoslav Duda <radosd@radosd.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96321Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1464945463-14364-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Chris Wilson authored
[ Upstream commit 457c52d8 ] If the VBT says that a certain port should be eDP (and hence fused off from HDMI), but in reality it isn't, we need to try and acquire the HDMI connection instead. So only trust the VBT edp setting if we can connect to an eDP device on that port. Fixes: d2182a66 (drm/i915: Don't register HDMI connectors for eDP ports on VLV/CHV) References: https://bugs.freedesktop.org/show_bug.cgi?id=96288Signed-off-by:
Phidias Chiang <phidias.chiang@canonical.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Pavel Rojtberg authored
[ Upstream commit 4efc6939 ] otherwise we lose ff commands: https://github.com/paroj/xpad/issues/27Signed-off-by:
Pavel Rojtberg <rojtberg@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Sunil Goutham authored
[ Upstream commit 3f4c68cf ] Check for SMU RX local/remote faults along with SPU LINK status. Otherwise at times link is UP at our end but DOWN at link partner's side. Also due to an issue in BGX it's rarely seen that initialization doesn't happen properly and SMU RX reports faults with everything fine at SPU. This patch tries to reinitialize LMAC to fix it. Also fixed LMAC disable sequence to properly bring down link. Signed-off-by:
Sunil Goutham <sgoutham@cavium.com> Signed-off-by:
Tao Wang <tao.wang@cavium.com> Signed-off-by:
-
Vitaly Kuznetsov authored
[ Upstream commit 1e2ae9ec ] Generation2 instances don't support reporting the NMI status on port 0x61, read from there returns 'ff' and we end up reporting nonsensical PCI error (as there is no PCI bus in these instances) on all NMIs: NMI: PCI system error (SERR) for reason ff on CPU 0. Dazed and confused, but trying to continue Fix the issue by overriding x86_platform.get_nmi_reason. Use 'booted on EFI' flag to detect Gen2 instances. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Cathy Avery <cavery@redhat.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: K. Y. Srinivasan <kys@microsoft.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: devel@linuxdriverproject.org Link: http://lkml.kernel.org/r/1460728232-31433-1-git-send-email-vkuznets@redhat.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Leonidas Da Silva Barbosa authored
[ Upstream commit 0d3d054b ] IV size was zero on CBC and CTR modes, causing a bug triggered by skcipher. Fixing this adding a correct size. Signed-off-by:
Leonidas Da Silva Barbosa <leosilva@linux.vnet.ibm.com> Signed-off-by:
Paulo Smorigo <pfsmorigo@linux.vnet.ibm.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Matthias Schwarzott authored
[ Upstream commit b046d3ad ] Without I get this error for by dvb-card: tda10071: Unknown symbol devm_regmap_init_i2c (err 0) cx23885_dvb_register() dvb_register failed err = -22 cx23885_dev_setup() Failed to register dvb adapters on VID_B Signed-off-by:
Matthias Schwarzott <zzam@gentoo.org> Reviewed-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Anton Blanchard authored
[ Upstream commit 975f57fd ] When calling ppc-xlate.pl, we pass it either linux-ppc64 or linux-ppc64le. The script however was expecting linux64le, a result of its OpenSSL origins. This means we aren't obeying the ppc64le ABIv2 rules. Fix this by checking for linux-ppc64le. Fixes: 5ca55738 ("crypto: vmx - comply with ABIs that specify vrsave as reserved.") Cc: stable@vger.kernel.org Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
Paulo Flabiano Smorigo authored
[ Upstream commit 5ca55738 ] It gives significant improvements ( ~+15%) on some modes. These code has been adopted from OpenSSL project in collaboration with the original author (Andy Polyakov <appro@openssl.org>). Signed-off-by:
-
Benjamin Tissoires authored
[ Upstream commit 50220dea ] Plugging a Logitech DJ receiver with KASAN activated raises a bunch of out-of-bound readings. The fields are allocated up to MAX_USAGE, meaning that potentially, we do not have enough fields to fit the incoming values. Add checks and silence KASAN. Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
James Smart authored
[ Upstream commit ae09c765 ] Driver didn't program the REG_VFI mailbox correctly, giving the adapter bad addresses. Signed-off-by:
Dick Kennedy <dick.kennedy@avagotech.com> Signed-off-by:
James Smart <james.smart@avagotech.com> Signed-off-by:
-
Christoph Hellwig authored
[ Upstream commit f2101842 ] Driver private request types should not get the artifical cap for the FS requests. This is important to use the full device capabilities for internal command or NVMe pass through commands. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reported-by:
Jeff Lien <Jeff.Lien@hgst.com> Tested-by:
Keith Busch <keith.busch@intel.com> Updated by me to use an explicit check for the one command type that does support extended checking, instead of relying on the ordering of the enum command values - as suggested by Keith. Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Ganapatrao Kulkarni authored
[ Upstream commit fbf8f40e ] The erratum fixes the hang of ITS SYNC command by avoiding inter node io and collections/cpu mapping on thunderx dual-socket platform. This fix is only applicable for Cavium's ThunderX dual-socket platform. Reviewed-by:
Robert Richter <rrichter@cavium.com> Signed-off-by:
Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
Vitaly Kuznetsov authored
[ Upstream commit bbf66d89 ] Hyper-V vmbus module registers TSC page clocksource when loaded. This is the clocksource with the highest rating and thus it becomes the watchdog making unloading of the vmbus module impossible. Separate clocksource_select_watchdog() from clocksource_enqueue_watchdog() and use it on clocksource register/rating change/unregister. After all, lobotomized monkeys may need some love too. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Zhao Lei authored
[ Upstream commit 4da2e26a ] btrfs failed in xfstests btrfs/080 with -o nodatacow. Can be reproduced by following script: DEV=/dev/vdg MNT=/mnt/tmp umount $DEV &>/dev/null mkfs.btrfs -f $DEV mount -o nodatacow $DEV $MNT dd if=/dev/zero of=$MNT/test bs=1 count=2048 & btrfs subvolume snapshot -r $MNT $MNT/test_snap & wait -- We can see dd failed on NO_SPACE. Reason: __btrfs_buffered_write should run cow write when no_cow impossible, and current code is designed with above logic. But check_can_nocow() have 2 type of return value(0 and <0) on can_not_no_cow, and current code only continue write on first case, the second case happened in doing subvolume. Fix: Continue write when check_can_nocow() return 0 and <0. Reviewed-by:
Filipe Manana <fdmanana@suse.com> Signed-off-by:
Zhao Lei <zhaolei@cn.fujitsu.com> Signed-off-by:
-
Keith Busch authored
[ Upstream commit a59e0f57 ] Go directly to ending a request if it wasn't started. Previously, completing a request may invoke a driver callback for a request it didn't initialize. Signed-off-by:
Sagi Grimberg <sagig@mellanox.com> Reviewed-by: Johannes Thumshirn <jthumshirn at suse.de> Acked-by:
-
Manoj N. Kumar authored
[ Upstream commit 635f6b08 ] When a cxlflash adapter goes into EEH recovery and multiple processes (each having established its own context) are active, the EEH recovery can hang if the processes attempt to recover in parallel. The symptom logged after a couple of minutes is: INFO: task eehd:48 blocked for more than 120 seconds. Not tainted 4.5.0-491-26f710d+ #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. eehd 0 48 2 Call Trace: __switch_to+0x2f0/0x410 __schedule+0x300/0x980 schedule+0x48/0xc0 rwsem_down_write_failed+0x294/0x410 down_write+0x88/0xb0 cxlflash_pci_error_detected+0x100/0x1c0 [cxlflash] cxl_vphb_error_detected+0x88/0x110 [cxl] cxl_pci_error_detected+0xb0/0x1d0 [cxl] eeh_report_error+0xbc/0x130 eeh_pe_dev_traverse+0x94/0x160 eeh_handle_normal_event+0x17c/0x450 eeh_handle_event+0x184/0x370 eeh_event_handler+0x1c8/0x1d0 kthread+0x110/0x130 ret_from_kernel_thread+0x5c/0xa4 INFO: task blockio:33215 blocked for more than 120 seconds. Not tainted 4.5.0-491-26f710d+ #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. blockio 0 33215 33213 Call Trace: 0x1 (unreliable) __switch_to+0x2f0/0x410 __schedule+0x300/0x980 schedule+0x48/0xc0 rwsem_down_read_failed+0x124/0x1d0 down_read+0x68/0x80 cxlflash_ioctl+0x70/0x6f0 [cxlflash] scsi_ioctl+0x3b0/0x4c0 sg_ioctl+0x960/0x1010 do_vfs_ioctl+0xd8/0x8c0 SyS_ioctl+0xd4/0xf0 system_call+0x38/0xb4 INFO: task eehd:48 blocked for more than 120 seconds. The hang is because of a 3 way dead-lock: Process A holds the recovery mutex, and waits for eehd to complete. Process B holds the semaphore and waits for the recovery mutex. eehd waits for semaphore. The fix is to have Process B above release the semaphore before attempting to acquire the recovery mutex. This will allow eehd to proceed to completion. Signed-off-by:
-
Dave Airlie authored
[ Upstream commit b36f7d26 ] The function this used changed in 092c96a8 drm/radeon: fix dp link rate selection (v2) However for MST we should just always train to the max link/rate. Though we probably need to limit this for future hw, in theory radeon won't support it. This fixes my 30" monitor with MST enabled. Cc: stable@vger.kernel.org # v4.4 Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Al Viro authored
[ Upstream commit 6a480a78 ] First of all, trying to open them r/w is idiocy; it's guaranteed to fail. Moreover, assigning ->f_pos and assuming that everything will work is blatantly broken - try that with e.g. tmpfs as underlying layer and watch the fireworks. There may be a non-trivial amount of state associated with current IO position, well beyond the numeric offset. Using the single struct file associated with underlying inode is really not a good idea; we ought to open one for each ecryptfs directory struct file. Additionally, file_operations both for directories and non-directories are full of pointless methods; non-directories should *not* have ->iterate(), directories should not have ->flush(), ->fasync() and ->splice_read(). Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Maruthi Srinivas Bayyavarapu authored
[ Upstream commit 8eb22214 ] This commit fixes garbled audio on Polaris-10/11 variants Signed-off-by:
Maruthi Bayyavarapu <maruthi.bayyavarapu@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Chris Wilson authored
[ Upstream commit 6984128d ] The current error path for failure when establishing a handle for a GEM object is unbalance, e.g. we call object_close() without calling first object_open(). Use the typical onion structure to only undo what has been set up prior to the error. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
John Stultz authored
[ Upstream commit dd4e17ab ] Recently, in commit 37cf4dc3 I forgot to check if the timeval being passed was actually a timespec (as is signaled with ADJ_NANO). This resulted in that patch breaking ADJ_SETOFFSET users who set ADJ_NANO, by rejecting valid timespecs that were compared with valid timeval ranges. This patch addresses this by checking for the ADJ_NANO flag and using the timepsec check instead in that case. Reported-by:
Harald Hoyer <harald@redhat.com> Reported-by:
Kay Sievers <kay@vrfy.org> Fixes: 37cf4dc3 "time: Verify time values in adjtimex ADJ_SETOFFSET to avoid overflow" Signed-off-by:
John Stultz <john.stultz@linaro.org> Cc: Sasha Levin <sasha.levin@oracle.com> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: David Herrmann <dh.herrmann@gmail.com> Link: http://lkml.kernel.org/r/1453417415-19110-2-git-send-email-john.stultz@linaro.orgSigned-off-by:
-
John Stultz authored
[ Upstream commit 37cf4dc3 ] For adjtimex()'s ADJ_SETOFFSET, make sure the tv_usec value is sane. We might multiply them later which can cause an overflow and undefined behavior. This patch introduces new helper functions to simplify the checking code and adds comments to clarify Orginally this patch was by Sasha Levin, but I've basically rewritten it, so he should get credit for finding the issue and I should get the blame for any mistakes made since. Also, credit to Richard Cochran for the phrasing used in the comment for what is considered valid here. Cc: Sasha Levin <sasha.levin@oracle.com> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Reported-by:
Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
-
Pavel Rojtberg authored
[ Upstream commit 7fc595f4 ] Track the status of the irq_out URB to prevent submission iof new requests while current one is active. Failure to do so results in the "URB submitted while active" warning/stack trace. Store pending brightness and FF effect in the driver structure and replace it with the latest requests until the device is ready to process next request. Alternate serving LED vs FF requests to make sure one does not starve another. See [1] for discussion. Inspired by patch of Sarah Bessmer [2]. [1]: http://www.spinics.net/lists/linux-input/msg40708.html [2]: http://www.spinics.net/lists/linux-input/msg31450.htmlSigned-off-by:
-
Sunil Goutham authored
[ Upstream commit ad2ecebd ] Counting rx packets for every CQE_RX in CQ irq handler is incorrect. Synchronization is missing when multiple queues are receiving packets simultaneously. Like transmit packet stats use HW stats here. Also removed unused 'cqe_type' parameter in nicvf_rcv_pkt_handler(). Signed-off-by:
-
Sunil Goutham authored
[ Upstream commit 6a9bab79 ] When a interface is assigned morethan 8 queues and the logical interface is toggled i.e down & up, additional queues or qsets are not initialized as secondary qset count is being set to zero while tearing down. Signed-off-by:
-
Vikas Shivappa authored
[ Upstream commit ada2f634 ] Fixes the hotcpu notifier leak and other global variable memory leaks during CQM (cache quality of service monitoring) initialization. Signed-off-by:
Vikas Shivappa <vikas.shivappa@linux.intel.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by:
Tony Luck <tony.luck@intel.com> Acked-by:
-
Vikas Shivappa authored
[ Upstream commit a223c1c7 ] Currently CQM (cache quality of service monitoring) is grouping all events belonging to same PID to use one RMID. However its not counting all of these different events. Hence we end up with a count of zero for all events other than the group leader. The patch tries to address the issue by keeping a flag in the perf_event.hw which has other CQM related fields. The field is updated at event creation and during grouping. Signed-off-by:
-
Harald Freudenberger authored
[ Upstream commit 74b2375e ] When the prng device driver calls misc_register() there is the possibility to also provide the recommented file permissions. This fix now gives useful values (0644) where previously just the default was used (resulting in 0600 for the device file). Signed-off-by:
Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Johannes Weiner authored
[ Upstream commit 65376df5 ] Commit b7643757 ("procfs: mark thread stack correctly in proc/<pid>/maps") added [stack:TID] annotation to /proc/<pid>/maps. Finding the task of a stack VMA requires walking the entire thread list, turning this into quadratic behavior: a thousand threads means a thousand stacks, so the rendering of /proc/<pid>/maps needs to look at a million combinations. The cost is not in proportion to the usefulness as described in the patch. Drop the [stack:TID] annotation to make /proc/<pid>/maps (and /proc/<pid>/numa_maps) usable again for higher thread counts. The [stack] annotation inside /proc/<pid>/task/<tid>/maps is retained, as identifying the stack VMA there is an O(1) operation. Siddesh said: "The end users needed a way to identify thread stacks programmatically and there wasn't a way to do that. I'm afraid I no longer remember (or have access to the resources that would aid my memory since I changed employers) the details of their requirement. However, I did do this on my own time because I thought it was an interesting project for me and nobody really gave any feedback then as to its utility, so as far as I am concerned you could roll back the main thread maps information since the information is available in the thread-specific files" Signed-off-by:
Johannes Weiner <hannes@cmpxchg.org> Cc: "Kirill A. Shutemov" <kirill@shutemov.name> Cc: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> Cc: Shaohua Li <shli@fb.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Dasaratharaman Chandramouli authored
[ Upstream commit 281baf7a ] Enables "Intel(R) Xeon Phi(TM) Processor x200 Product Family" support, formerly code-named KNL. It is based on modified Intel Atom Silvermont microarchitecture. Signed-off-by:
Dasaratharaman Chandramouli <dasaratharaman.chandramouli@intel.com> [micah.barany@intel.com: adjusted values of residency and latency] Signed-off-by:
Micah Barany <micah.barany@intel.com> [hubert.chrzaniuk@intel.com: removed deprecated CPUIDLE_FLAG_TIME_VALID flag] Signed-off-by:
Hubert Chrzaniuk <hubert.chrzaniuk@intel.com> Signed-off-by:
Pawel Karczewski <pawel.karczewski@intel.com> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Manoj N. Kumar authored
[ Upstream commit 603ecce9 ] When switching to the internal LUN defined on the IBM CXL flash adapter, there is an unnecessary scan occurring on the second port. This scan leads to the following extra lines in the log: Dec 17 10:09:00 tul83p1 kernel: [ 3708.561134] cxlflash 0008:00:00.0: cxlflash_queuecommand: (scp=c0000000fc1f0f00) 11/1/0/0 cdb=(A0000000-00000000-10000000-00000000) Dec 17 10:09:00 tul83p1 kernel: [ 3708.561147] process_cmd_err: cmd failed afu_rc=32 scsi_rc=0 fc_rc=0 afu_extra=0xE, scsi_extra=0x0, fc_extra=0x0 By definition, both of the internal LUNs are on the first port/channel. When the lun_mode is switched to internal LUN the same value for host->max_channel is retained. This causes an unnecessary scan over the second port/channel. This fix alters the host->max_channel to 0 (1 port), if internal LUNs are configured and switches it back to 1 (2 ports) while going back to external LUNs. Signed-off-by:
-
Vitaly Kuznetsov authored
[ Upstream commit 3ccb4fd8 ] clocksource_change_rating() involves mutex usage and can't be called in interrupt context. It also makes sense to avoid doing redundant work on crash. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
Vitaly Kuznetsov authored
[ Upstream commit 41571916 ] We have to call vmbus_initiate_unload() on crash to make kdump work but the crash can also be happening in interrupt (e.g. Sysrq + c results in such) where we can't schedule or the following will happen: [ 314.905786] bad: scheduling from the idle thread! Just skipping the wait (and even adding some random wait here) won't help: to make host-side magic working we're supposed to receive CHANNELMSG_UNLOAD (and actually confirm the fact that we received it) but we can't use interrupt-base path (vmbus_isr()-> vmbus_on_msg_dpc()). Implement a simple busy wait ignoring all the other messages and use it if we're in an interrupt context. Signed-off-by:
-
