- 30 Jun, 2016 6 commits
-
-
Hannes Reinecke authored
Fixup submit_rtpg() to always return a standard SCSI return code. Signed-off-by:
Hannes Reinecke <hare@suse.de> Reviewed-by:
Ewan Milne <emilne@redhat.com> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> BugLink: http://bugs.launchpad.net/bugs/1567602 (cherry-picked from commit 5597cafc) Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Hannes Reinecke authored
Use standard logging functions instead of hand-crafted ones. Signed-off-by:
Bart Van Assche <bvanassche@sandisk.com> Reviewed-by:
-
Hannes Reinecke authored
The only check for a valid sense code is calling scsi_normalize_sense() and check the return value. So drop the pointless checks and rely on scsi_normalize_sense() to figure out if the sense code is valid. With that we can also remove the 'senselen' field. Signed-off-by:
-
Hannes Reinecke authored
Issue different logging messages if ALUA is not supported or the TPGS setting is invalid. Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
-
Hannes Reinecke authored
The SCSI device now has the VPD page 0x83 information attached, so there is no need to query it again. [mkp: Fixed a checkpatch warning] Signed-off-by:
-
Hannes Reinecke authored
Non-disk devices might support ALUA, but the firmware implementation is untested and frequently broken. As we're don't actually need it disable ALUA support for non-disk device for now. Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Reviewed-by:
-
- 29 Jun, 2016 1 commit
-
-
Kamal Mostafa authored
Ignore: yes Signed-off-by:
-
- 28 Jun, 2016 26 commits
-
-
Kamal Mostafa authored
Signed-off-by: -
Colin Ian King authored
BugLink: http://bugs.launchpad.net/bugs/1594871 Sync with the latest Xenial zfs-linux 0.6.5.6-0ubuntu10 Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
-
Kamal Mostafa authored
BugLink: http://bugs.launchpad.net/bugs/1589886Signed-off-by:
-
Alex Hung authored
BugLink: http://bugs.launchpad.net/bugs/1589886 This is the same as the original workaround from S3 but for S4. Without this workaround, a rfkill event will be received and it will toggle wireless devices when radio hotkey is not pressed. Signed-off-by:
Alex Hung <alex.hung@canonical.com> Signed-off-by:
Darren Hart <dvhart@linux.intel.com> (cherry picked from commit 45aa56cd) Signed-off-by:
-
Wolfram Sang authored
BugLink: http://bugs.launchpad.net/bugs/1589886 We want the size of the struct, not of a pointer to it. To be future proof, just dereference the pointer to get the desired type. Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Alex Hung authored
BugLink: http://bugs.launchpad.net/bugs/1589886 intel_hid_keymap contains a duplicate entry for KEY_HOME and an incorrect HID index for KEY_PAGEDOWN Reported-by:
Pavel Bludov <pbludov@gmail.com> Signed-off-by:
-
Alex Hung authored
BugLink: http://bugs.launchpad.net/bugs/1589886 This driver supports various HID events including hotkeys. Dell XPS 13 9350 requires it for the wireless hotkey. Signed-off-by:
Andy Lutomirski <luto@kernel.org> [dvhart: Kconfig help typo fix and INPUT_SPARSEKMAP fix from Sedat Dilek] Signed-off-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1588056 Set SB_I_NOEXEC on mqueuefs to ensure small implementation mistakes do not result in executable on mqueuefs by accident. Acked-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> (backported from linux-next commit 3ee69014) Signed-off-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1588056 The cgroup filesystem is in the same boat as sysfs. No one ever permits executables of any kind on the cgroup filesystem, and there is no reasonable future case to support executables in the future. Therefore move the setting of SB_I_NOEXEC which makes the code proof against future mistakes of accidentally creating executables from sysfs to kernfs itself. Making the code simpler and covering the sysfs, cgroup, and cgroup2 filesystems. Acked-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1588056 Sync up with changes from Eric Biederman when merging s_user_ns support upstream. Partial backport of 6e4eab57 from linux-next. Signed-off-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1588056 Today what is normally called data (the mount options) is not passed to fill_super through mount_ns. Pass the mount options and the namespace separately to mount_ns so that filesystems such as proc that have mount options, can use mount_ns. Pass the user namespace to mount_ns so that the standard permission check that verifies the mounter has permissions over the namespace can be performed in mount_ns instead of in each filesystems .mount method. Thus removing the duplication between mqueuefs and proc in terms of permission checks. The extra permission check does not currently affect the rpc_pipefs filesystem and the nfsd filesystem as those filesystems do not currently allow unprivileged mounts. Without unpvileged mounts it is guaranteed that the caller has already passed capable(CAP_SYS_ADMIN) which guarantees extra permission check will pass. Update rpc_pipefs and the nfsd filesystem to ensure that the network namespace reference is always taken in fill_super and always put in kill_sb so that the logic is simpler and so that errors originating inside of fill_super do not cause a network namespace leak. Acked-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1588056 Allow the ipc namespace initialization code to depend on ns->user_ns being set during initialization. In particular this allows mq_init_ns to use ns->user_ns for permission checks and initializating s_user_ns while the the mq filesystem is being mounted. Acked-by:
-
Daniel Borkmann authored
BugLink: http://bugs.launchpad.net/bugs/1588056 Follow-up to commit e27f4a94 ("bpf: Use mount_nodev not mount_ns to mount the bpf filesystem"), which removes the FS_USERNS_MOUNT flag. The original idea was to have a per mountns instance instead of a single global fs instance, but that didn't work out and we had to switch to mount_nodev() model. The intent of that middle ground was that we avoid users who don't play nice to create endless instances of bpf fs which are difficult to control and discover from an admin point of view, but at the same time it would have allowed us to be more flexible with regard to namespaces. Therefore, since we now did the switch to mount_nodev() as a fix where individual instances are created, we also need to remove userns mount flag along with it to avoid running into mentioned situation. I don't expect any breakage at this early point in time with removing the flag and we can revisit this later should the requirement for this come up with future users. This and commit e27f4a94 have been split to facilitate tracking should any of them run into the unlikely case of causing a regression. Fixes: b2197755 ("bpf: add support for persistent maps/progs") Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Acked-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 612bacad) Signed-off-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1588056 While reviewing the filesystems that set FS_USERNS_MOUNT I spotted the bpf filesystem. Looking at the code I saw a broken usage of mount_ns with current->nsproxy->mnt_ns. As the code does not acquire a reference to the mount namespace it can not possibly be correct to store the mount namespace on the superblock as it does. Replace mount_ns with mount_nodev so that each mount of the bpf filesystem returns a distinct instance, and the code is not buggy. In discussion with Hannes Frederic Sowa it was reported that the use of mount_ns was an attempt to have one bpf instance per mount namespace, in an attempt to keep resources that pin resources from hiding. That intent simply does not work, the vfs is not built to allow that kind of behavior. Which means that the bpf filesystem really is buggy both semantically and in it's implemenation as it does not nor can it implement the original intent. This change is userspace visible, but my experience with similar filesystems leads me to believe nothing will break with a model of each mount of the bpf filesystem is distinct from all others. Fixes: b2197755 ("bpf: add support for persistent maps/progs") Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Acked-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1588056 This reverts commit 794fbce4. Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1588056 This reverts commit aadbec3a. Signed-off-by:
-
Seth Forshee authored
Revert "UBUNTU: SAUCE: (namespace) mqueue: Super blocks must be owned by the user ns which owns the ipc ns" BugLink: http://bugs.launchpad.net/bugs/1588056 This reverts commit dec77184. Signed-off-by:
-
Gabriel Krisman Bertazi authored
BugLink: http://bugs.launchpad.net/bugs/1596635 Under stress occasions some TI devices might not return early when reading the status register during the quirk invocation of xhci_irq made by usb_hcd_pci_remove. This means that instead of returning, we end up handling this interruption in the middle of a shutdown. Since xhci->event_ring has already been freed in xhci_mem_cleanup, we end up accessing freed memory, causing the Oops below. commit 8c24d6d7 ("usb: xhci: stop everything on the first call to xhci_stop") is the one that changed the instant in which we clean up the event queue when stopping a device. Before, we didn't call xhci_mem_cleanup at the first time xhci_stop is executed (for the shared HCD), instead, we only did it after the invocation for the primary HCD, much later at the removal path. The code flow for this oops looks like this: xhci_pci_remove() usb_remove_hcd(xhci->shared) xhci_stop(xhci->shared) xhci_halt() xhci_mem_cleanup(xhci); // Free the event_queue usb_hcd_pci_remove(primary) xhci_irq() // Access the event_queue if STS_EINT is set. Crash. xhci_stop() xhci_halt() // return early The fix modifies xhci_stop to only cleanup the xhci data when releasing the primary HCD. This way, we still have the event_queue configured when invoking xhci_irq. We still halt the device on the first call to xhci_stop, though. I could reproduce this issue several times on the mainline kernel by doing a bind-unbind stress test with a specific storage gadget attached. I also ran the same test over-night with my patch applied and didn't observe the issue anymore. [ 113.334124] Unable to handle kernel paging request for data at address 0x00000028 [ 113.335514] Faulting instruction address: 0xd00000000d4f767c [ 113.336839] Oops: Kernel access of bad area, sig: 11 [#1] [ 113.338214] SMP NR_CPUS=1024 NUMA PowerNV [c000000efe47ba90] c000000000720850 usb_hcd_irq+0x50/0x80 [c000000efe47bac0] c00000000073d328 usb_hcd_pci_remove+0x68/0x1f0 [c000000efe47bb00] d00000000daf0128 xhci_pci_remove+0x78/0xb0 [xhci_pci] [c000000efe47bb30] c00000000055cf70 pci_device_remove+0x70/0x110 [c000000efe47bb70] c00000000061c6bc __device_release_driver+0xbc/0x190 [c000000efe47bba0] c00000000061c7d0 device_release_driver+0x40/0x70 [c000000efe47bbd0] c000000000619510 unbind_store+0x120/0x150 [c000000efe47bc20] c0000000006183c4 drv_attr_store+0x64/0xa0 [c000000efe47bc60] c00000000039f1d0 sysfs_kf_write+0x80/0xb0 [c000000efe47bca0] c00000000039e14c kernfs_fop_write+0x18c/0x1f0 [c000000efe47bcf0] c0000000002e962c __vfs_write+0x6c/0x190 [c000000efe47bd90] c0000000002eab40 vfs_write+0xc0/0x200 [c000000efe47bde0] c0000000002ec85c SyS_write+0x6c/0x110 [c000000efe47be30] c000000000009260 system_call+0x38/0x108 Signed-off-by:
Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Cc: Roger Quadros <rogerq@ti.com> Cc: joel@jms.id.au Cc: stable@vger.kernel.org Reviewed-by:
Roger Quadros <rogerq@ti.com> Cc: <stable@vger.kernel.org> #v4.3+ Tested-by:
Joel Stanley <joel@jms.id.au> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 27a41a83) Signed-off-by:
-
Leonidas Da Silva Barbosa authored
BugLink: http://bugs.launchpad.net/bugs/1596557 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> (cherry picked from commit 0d3d054b) Signed-off-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1596469 On my Lenovo x250 the following situation occurs: [18697.813871] tpm_crb MSFT0101:00: can't request region for resource [mem 0xacdff080-0xacdfffff] The mapping of the control area overlaps the mapping of the command buffer. The control area is mapped over page, which is not right. It should mapped over sizeof(struct crb_control_area). Fixing this issue unmasks another issue. Command and response buffers can overlap and they do interleave on this machine. According to the PTP specification the overlapping means that they are mapped to the same buffer. The commit has been also on a Haswell NUC where things worked before applying this fix so that the both code paths for response buffer initialization are tested. Cc: stable@vger.kernel.org Fixes: 1bd047be ("tpm_crb: Use devm_ioremap_resource") Signed-off-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Reviewed-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> (cherry picked from linux-next commit 0af6e0a2da2e4fedaa2743333da438d3b879192b) Signed-off-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1596469 The iomem resource is needed only temporarily so it is better to pass it on instead of storing it permanently. Named the variable as io_res so that the code better documents itself. Signed-off-by:
Stefan Berger <stefanb@linux.vnet.ibm.com> (cherry picked from linux-next commit 3f944075e75e28c9cf1af8f82798398b0e3594b6) Signed-off-by:
-
Uma Krishnan authored
BugLink: http://bugs.launchpad.net/bugs/1592114 Some CXL Flash cards need notification of device shutdown in order to flush pending I/Os. A PCI notification hook for shutdown has been added where the driver notifies the card and returns. When the device is removed in the PCI remove path, notification code will wait for shutdown processing to complete. Signed-off-by:
Uma Krishnan <ukrishn@linux.vnet.ibm.com> Acked-by:
Manoj N. Kumar <manoj@linux.vnet.ibm.com> Acked-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Signed-off-by:
-
Uma Krishnan authored
BugLink: http://bugs.launchpad.net/bugs/1592114 Device dependent flags are needed to support functions that are specific to a particular device. One such case is - some CXL Flash cards need to be notified of device shutdown. For other CXL devices, this feature does not prove to be useful yet. Such distinct features need to be identified in the driver to bypass or invoke specific functionality. In this patch, a member 'flags' has been added to device dependent values. These flags will be used and expanded in the future to support various device specific functions. Signed-off-by:
-
Manoj N. Kumar authored
BugLink: http://bugs.launchpad.net/bugs/1592114 While running 'sg_reset -H' in a loop with a user-space application active, hit the following exception: cpu 0x2: Vector: 300 (Data Access) pc: : afu_attach+0x50/0x240 [cxlflash] lr: : cxlflash_afu_recover+0x3dc/0x7d0 [cxlflash] pid = 20365, comm = run_block_fvt Linux version 4.5.0-491-26f710d+ cxlflash_afu_recover+0x3dc/0x7d0 [cxlflash] cxlflash_ioctl+0x5a8/0x6f0 [cxlflash] scsi_ioctl+0x3b0/0x4c0 sd_ioctl+0x110/0x190 blkdev_ioctl+0x28c/0xc20 block_ioctl+0xa4/0xd0 do_vfs_ioctl+0xd8/0x8c0 SyS_ioctl+0xd4/0xf0 system_call+0x38/0xb4 The problem here is that the problem space area is unmapped while the application issues the DK_CXLFLASH_RECOVER_AFU ioctl. This is the order I observe: proc1 proc2 1) sg_reset 2) ioctl(DK_CXLFLASH_RECOVER_AFU) 3) sg_reset again causing a PSA unmap 4) continues RECOVER_AFU processing The resolution to this problem is to have the reset handler drain all outstanding user space initiated ioctls before proceeding. It is safe to drain after the state has been changed to STATE_RESET. Also since drain_ioctls() was static, it had to be moved up a bit to be before cxlflash_eh_host_reset_handler(). Signed-off-by:
-
Manoj N. Kumar authored
BugLink: http://bugs.launchpad.net/bugs/1592114 While running 'sg_reset -H' back to back the following exception was seen: [ 735.115695] Faulting instruction address: 0xd0000000098c0864 cpu 0x0: Vector: 300 (Data Access) at [c000000ffffafa80] pc: d0000000098c0864: cxlflash_async_err_irq+0x84/0x5c0 [cxlflash] lr: c00000000013aed0: handle_irq_event_percpu+0xa0/0x310 sp: c000000ffffafd00 msr: 9000000000009033 dar: 2010000 dsisr: 40000000 current = 0xc000000001510880 paca = 0xc00000000fb80000 softe: 0 irq_happened: 0x01 pid = 0, comm = swapper/0 Linux version 4.5.0-491-26f710d+ enter ? for help [c000000ffffafe10] c00000000013aed0 handle_irq_event_percpu+0xa0/0x310 [c000000ffffafed0] c00000000013b1a8 handle_irq_event+0x68/0xc0 [c000000ffffaff00] c0000000001404ec handle_fasteoi_irq+0xec/0x2a0 [c000000ffffaff30] c00000000013a084 generic_handle_irq+0x54/0x80 [c000000ffffaff60] c000000000011130 __do_irq+0x80/0x1d0 [c000000ffffaff90] c000000000024d40 call_do_irq+0x14/0x24 [c000000001573a20] c000000000011318 do_IRQ+0x98/0x140 [c000000001573a70] c000000000002594 hardware_interrupt_common+0x114/0x180 This exception is being hit because the async_err interrupt path performs an MMIO to read the interrupt status register. The MMIO region in this case is not available. Commit 6ded8b3c ("cxlflash: Unmap problem state area before detaching master context") re-ordered the sequence in which term_mc() and stop_afu() are called. This introduces a window for interrupts to come in with the problem space area unmapped, that did not exist previously. The fix is to separate the disabling of all AFU interrupts to a distinct function, term_intr() so that it is the first thing that is done in the tear down process. To keep the initialization process symmetric, separate the AFU interrupt setup also to a distinct function: init_intr(). Fixes: 6ded8b3c ("cxlflash: Unmap problem state area before detaching master context") Signed-off-by:
-
Stefan Bader authored
This will add debian installer support for the Adaptec PMC-Sierra SAS HBA controller. BugLink: http://bugs.launchpad.net/bugs/1595628Signed-off-by:
Andy Whitcroft <apw@canonical.com> Signed-off-by:
-
- 27 Jun, 2016 7 commits
-
-
Matthias Schwarzott authored
BugLink: http://bugs.launchpad.net/bugs/1592531 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> (cherry picked from commit b046d3ad) Signed-off-by:
-
Frederic Barrat authored
BugLink: http://bugs.launchpad.net/bugs/1594847 On bare-metal, when a device is attached to the cxl card, lsvpd shows a location code such as (with cxlflash): # lsvpd -l sg22 ... *YL U78CB.001.WZS0073-P1-C33-B0-T0-L0 which makes it hard to easily identify the cxl adapter owning the flash device, since in this example C33 refers to a P8 processor. lsvpd looks in the parent devices until it finds a location code, so the device node for the vPHB ends up being used. By reusing the device node of the adapter for the vPHB, lsvpd shows: # lsvpd -l sg16 ... *YL U78C9.001.WZS09XA-P1-C7-B1-T0-L3 where C7 is the PCI slot of the cxl adapter. On powerVM, the vPHB was already using the adapter device node, so there's no change there. Tested by cxlflash on bare-metal and powerVM. Signed-off-by:
Frederic Barrat <fbarrat@linux.vnet.ibm.com> Reviewed-by:
Ian Munsie <imunsie@au1.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> (cherry picked from linux-next commit a4307390) Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1594455Signed-off-by:
-
Anton Blanchard authored
BugLink: http://bugs.launchpad.net/bugs/1592481 All of the VMX AES ciphers (AES, AES-CBC and AES-CTR) are set at priority 1000. Unfortunately this means we never use AES-CBC and AES-CTR, because the base AES-CBC cipher that is implemented on top of AES inherits its priority. To fix this, AES-CBC and AES-CTR have to be a higher priority. Set them to 2000. Testing on a POWER8 with: cryptsetup benchmark --cipher aes --key-size 256 Shows decryption speed increase from 402.4 MB/s to 3069.2 MB/s, over 7x faster. Thanks to Mike Strosaker for helping me debug this issue. Fixes: 8c755ace ("crypto: vmx - Adding CBC routines for VMX module") Cc: stable@vger.kernel.org Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
Anton Blanchard authored
BugLink: http://bugs.launchpad.net/bugs/1592481 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:
-
Paulo Flabiano Smorigo authored
BugLink: http://bugs.launchpad.net/bugs/1592481 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:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1593134Signed-off-by:
Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by:
-
