- 29 Aug, 2016 27 commits
-
-
Lyude authored
BugLink: http://bugs.launchpad.net/bugs/1616894 One of the things preventing us from using polling is the fact that calling valleyview_crt_detect_hotplug() when there's a VGA cable connected results in sending another hotplug. With polling enabled when HPD is disabled, this results in a scenario like this: - We enable power wells and reset the ADPA - output_poll_exec does force probe on VGA, triggering a hpd - HPD handler waits for poll to unlock dev->mode_config.mutex - output_poll_exec shuts off the ADPA, unlocks dev->mode_config.mutex - HPD handler runs, resets ADPA and brings us back to the start This results in an endless irq storm getting sent from the ADPA whenever a VGA connector gets detected in the middle of polling. Somewhat based off of the "drm/i915: Disable CRT HPD around force trigger" patch Ville Syrjälä sent a while back Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Lyude <cpaul@redhat.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit b236d7c8) (backported from commit 21842ea8) Signed-off-by:
Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Acked-by:
Kamal Mostafa <kamal@canonical.com>
-
Lyude authored
BugLink: http://bugs.launchpad.net/bugs/1616894 While VGA hotplugging worked(ish) before, it looks like that was mainly because we'd unintentionally enable it in valleyview_crt_detect_hotplug() when we did a force trigger. This doesn't work reliably enough because whenever the display powerwell on vlv gets disabled, the values set in VLV_ADPA get cleared and consequently VGA hotplugging gets disabled. This causes bugs such as one we found on an Intel NUC, where doing the following sequence of hotplugs: - Disconnect all monitors - Connect VGA - Disconnect VGA - Connect HDMI Would result in VGA hotplugging becoming disabled, due to the powerwells getting toggled in the process of connecting HDMI. Changes since v3: - Expose intel_crt_reset() through intel_drv.h and call that in vlv_display_power_well_init() instead of encoder->base.funcs->reset(&encoder->base); Changes since v2: - Use intel_encoder structs instead of drm_encoder structs Changes since v1: - Instead of handling the register writes ourself, we just reuse intel_crt_detect() - Instead of resetting the ADPA during display IRQ installation, we now reset them in vlv_display_power_well_init() Cc: stable@vger.kernel.org Acked-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Rebase over dev_priv/drm_device embedding.] Signed-off-by:
-
Lyude authored
BugLink: http://bugs.launchpad.net/bugs/1616894 This lets call intel_crt_reset() in contexts where IRQs are disabled and as such, can't hold the locks required to work with the connectors. Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1520446 Broxton has all the HSW C-states, except C3. BXT C-state timing is slightly different. Here we trust the IRTL MSRs as authority on maximum C-state latency, and override the driver's tables with the values found in the associated IRTL MSRs. Further we set the target_residency to 1x maximum latency, trusting the hardware demotion logic. Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 5dcef694) Signed-off-by:
Brad Figg <brad.figg@canonical.com>
-
Tony Luck authored
BugLink: http://bugs.launchpad.net/bugs/1591815 This is an entirely new driver instead of yet another set of patches to sb_edac.c because: 1) Mapping from PCI devices to socket/memory controller is significantly different. Skylake scatters devices on a socket across a number of PCI buses. 2) There is an extra level of interleaving via the "mcroute" register that would be a little messy to squeeze into the old driver. 3) Validation is getting too expensive. Changes to sb_edac need to be checked against Sandy Bridge, Ivy Bridge, Haswell, Broadwell and Knights Landing. Acked-by:
Aristeu Rozanski <aris@redhat.com> Acked-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 4ec656bd) Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1591815Signed-off-by:
-
Tedd Ho-Jeong An authored
BugLink: http://bugs.launchpad.net/bugs/1591648 This patch adds support for Intel Bluetooth device 3168 also known as Sandy Peak (SdP). T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=8087 ProdID=0aa7 Rev= 0.01 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> (cherry picked from commit 439e65d3) Signed-off-by:
-
Chen Yu authored
BugLink: http://bugs.launchpad.net/bugs/1587714 People reported that they can not do a poweroff nor a suspend to ram on their Mac Pro 11. After some investigations it was found that, once the PCI bridge 0000:00:1c.0 reassigns its mm windows to ([mem 0x7fa00000-0x7fbfffff] and [mem 0x7fc00000-0x7fdfffff 64bit pref]), the region of ACPI io resource 0x1804 becomes unaccessible immediately, where the ACPI Sleep register is located, as a result neither poweroff(S5) nor suspend to ram(S3) works. As suggested by Bjorn, further testing shows that, there is an unreported device may be (using) conflict with above aperture, which brings unpredictable result such as the failure of accessing the io port, which blocks the poweroff(S5). Besides if we reassign the memory aperture to the other place, the poweroff works again. As we do not find any resource declared in _CRS which contain above memory aperture, and Mac OS does not use this pci bridge neither, we choose a simple workaround to clear the hotplug flag(suggested by Yinghai Lu), thus do not allocate any resource for this pci bridge, and thereby no conflict anymore. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211 Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Rafael J. Wysocki <rafael@kernel.org> Cc: Lukas Wunner <lukas@wunner.de> Signed-off-by:
Chen Yu <yu.c.chen@intel.com> Reference: https://patchwork.kernel.org/patch/9289777/Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
-
Wen-chien Jesse Sung authored
BugLink: https://launchpad.net/bugs/1512999 Since DMI IDs may be different between models while subsystem IDs of host bridge will stay the same, use pci_get_subsys() instead of dmi_match() to identify Edge Gateways. Signed-off-by:
Wen-chien Jesse Sung <jesse.sung@canonical.com> Acked-by:
-
Masaki Ota authored
Remove an unnecessary codes. Change input_ivent() function to appropriate function. Add the device ID of "HID_DEVICE_ID_ALPS_U1_DUAL". [jkosina@suse.cz: removed unnecessary bitshifts of values passed input_report_key() as spotted by Dmitry] Signed-off-by:
Masaki Ota <masaki.ota@jp.alps.com> Reviewed-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> BugLink: https://bugs.launchpad.net/bugs/1616813 (cherry picked from commit 819d64e5) Signed-off-by:
Ying-Chun Liu (PaulLiu) <paul.liu@canonical.com> Acked-by:
-
Jiri Kosina authored
All devices with ALPS_JP VID are handled by hid-alps driver, hence they require an entry in hid_have_special_driver[]. BugLink: https://bugs.launchpad.net/bugs/1616813Signed-off-by:
-
Jiri Kosina authored
Calculating size of the report as sizeof(pointer) always passess the length corresponding to the pointer type, not the underlying data report. BugLink: https://bugs.launchpad.net/bugs/1616813Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
Jiri Kosina authored
... and therefore should be marked static. BugLink: https://bugs.launchpad.net/bugs/1616813Signed-off-by:
-
Masaki Ota authored
Add support Alps I2C HID Touchpad and Stick device. BugLink: https://bugs.launchpad.net/bugs/1616813Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1616813Signed-off-by:
-
Rafael J. Wysocki authored
BugLink: https://bugs.launchpad.net/bugs/1616781 Logan Gunthorpe reports that hibernation stopped working reliably for him after commit ab76f7b4 (x86/mm: Set NX on gap between __ex_table and rodata). That turns out to be a consequence of a long-standing issue with the 64-bit image restoration code on x86, which is that the temporary page tables set up by it to avoid page tables corruption when the last bits of the image kernel's memory contents are copied into their original page frames re-use the boot kernel's text mapping, but that mapping may very well get corrupted just like any other part of the page tables. Of course, if that happens, the final jump to the image kernel's entry point will go to nowhere. The exact reason why commit ab76f7b4 matters here is that it sometimes causes a PMD of a large page to be split into PTEs that are allocated dynamically and get corrupted during image restoration as described above. To fix that issue note that the code copying the last bits of the image kernel's memory contents to the page frames occupied by them previoulsy doesn't use the kernel text mapping, because it runs from a special page covered by the identity mapping set up for that code from scratch. Hence, the kernel text mapping is only needed before that code starts to run and then it will only be used just for the final jump to the image kernel's entry point. Accordingly, the temporary page tables set up in swsusp_arch_resume() on x86-64 need to contain the kernel text mapping too. That mapping is only going to be used for the final jump to the image kernel, so it only needs to cover the image kernel's entry point, because the first thing the image kernel does after getting control back is to switch over to its own original page tables. Moreover, the virtual address of the image kernel's entry point in that mapping has to be the same as the one mapped by the image kernel's page tables. With that in mind, modify the x86-64's arch_hibernation_header_save() and arch_hibernation_header_restore() routines to pass the physical address of the image kernel's entry point (in addition to its virtual address) to the boot kernel (a small piece of assembly code involved in passing the entry point's virtual address to the image kernel is not necessary any more after that, so drop it). Update RESTORE_MAGIC too to reflect the image header format change. Next, in set_up_temporary_mappings(), use the physical and virtual addresses of the image kernel's entry point passed in the image header to set up a minimum kernel text mapping (using memory pages that won't be overwritten by the image kernel's memory contents) that will map those addresses to each other as appropriate. This makes the concern about the possible corruption of the original boot kernel text mapping go away and if the the minimum kernel text mapping used for the final jump marks the image kernel's entry point memory as executable, the jump to it is guaraneed to succeed. Fixes: ab76f7b4 (x86/mm: Set NX on gap between __ex_table and rodata) Link: http://marc.info/?l=linux-pm&m=146372852823760&w=2Reported-by:
Logan Gunthorpe <logang@deltatee.com> Reported-and-tested-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Acked-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
-
Jan Beulich authored
This should really only be done for XS_TRANSACTION_END messages, or else at least some of the xenstore-* tools don't work anymore. Fixes: 0beef634 ("xenbus: don't BUG() on user mode induced condition") Reported-by:
Richard Schütz <rschuetz@uni-koblenz.de> Cc: <stable@vger.kernel.org> Signed-off-by:
Jan Beulich <jbeulich@suse.com> Tested-by:
David Vrabel <david.vrabel@citrix.com> BugLink: http://bugs.launchpad.net/bugs/1611833 (cherry-picked from commit 9a035a40 upstream) Signed-off-by:
-
Bryant G. Ly authored
BugLink: http://bugs.launchpad.net/bugs/1615665 This driver is a pick up of the old IBM VIO scsi Target Driver that was started by Nick and Fujita 2-4 years ago. http://comments.gmane.org/gmane.linux.scsi/90119 The driver provides a virtual SCSI device on IBM Power Servers. This patch contains the fifth version for an initial merge of the tcm ibmvscsis driver. More information on this driver and config can be found: https://github.com/powervm/ibmvscsis/wiki/Configuration http://www.linux-iscsi.org/wiki/IBM_vSCSI (Drop extra libsrp review breakage + Fix kconfig typo - nab) Signed-off-by:
Steven Royer <seroyer@linux.vnet.ibm.com> Signed-off-by:
Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Signed-off-by:
Michael Cyr <mikecyr@linux.vnet.ibm.com> Signed-off-by:
Bryant G. Ly <bryantly@linux.vnet.ibm.com> Cc: FUJITA Tomonori <tomof@acm.org> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> (cherry picked from commit 88a678bb) Signed-off-by:
-
Nicholas Bellinger authored
BugLink: http://bugs.launchpad.net/bugs/1615665 Based on HCH's original patch, this adds a full version to support percpu-ida tag pre-allocation and callback function pointer into fabric driver code to complete session setup. Reported-by:
Christoph Hellwig <hch@lst.de> Cc: Sagi Grimberg <sagig@mellanox.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.de> Cc: Andy Grover <agrover@redhat.com> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1615665Signed-off-by:
-
Herbert Xu authored
BugLink: http://bugs.launchpad.net/bugs/1613295 We use _GLOBAL so there is no need to do the manual alignment, in fact it causes a build failure. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 16dee780) Signed-off-by:
Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by:
-
Leonidas S. Barbosa authored
BugLink: http://bugs.launchpad.net/bugs/1613295 This patch add XTS support using VMX-crypto driver. Signed-off-by:
Leonidas S. Barbosa <leosilva@linux.vnet.ibm.com> Signed-off-by:
Paulo Flabiano Smorigo <pfsmorigo@linux.vnet.ibm.com> Signed-off-by:
-
Stephan Mueller authored
BugLink: http://bugs.launchpad.net/bugs/1613295 The patch centralizes the XTS key check logic into the service function xts_check_key which is invoked from the different XTS implementations. With this, the XTS implementations in ARM, ARM64, PPC and S390 have now a sanity check for the XTS keys similar to the other arches. In addition, this service function received a check to ensure that the key != the tweak key which is mandated by FIPS 140-2 IG A.9. As the check is not present in the standards defining XTS, it is only enforced in FIPS mode of the kernel. Signed-off-by:
Stephan Mueller <smueller@chronox.de> Signed-off-by:
-
Paulo Flabiano Smorigo authored
BugLink: http://bugs.launchpad.net/bugs/1613295 This patch add XTS subroutines using VMX-crypto driver. It gives a boost of 20 times using XTS. These code has been adopted from OpenSSL project in collaboration with the original author (Andy Polyakov <appro@openssl.org>). Signed-off-by:
-
Anton Blanchard authored
BugLink: http://bugs.launchpad.net/bugs/1613295 The enable_kernel_*() functions leave the relevant MSR bits enabled until we exit the kernel sometime later. Create disable versions that wrap the kernel use of FP, Altivec VSX or SPE. While we don't want to disable it normally for performance reasons (MSR writes are slow), it will be used for a debug boot option that does this and catches bad uses in other areas of the kernel. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> (back ported from commit dc4fbba1) Signed-off-by:
-
Anton Blanchard authored
BugLink: http://bugs.launchpad.net/bugs/1613295 With the recent change to enable_kernel_vsx(), we no longer need to call enable_kernel_fp() and enable_kernel_altivec(). Signed-off-by:
-
Stephan Mueller authored
BugLink: http://bugs.launchpad.net/bugs/1613295 Commit 28856a9e missed the addition of the crypto/xts.h include file for different architecture-specific AES implementations. Signed-off-by:
-
- 24 Aug, 2016 2 commits
-
-
Alan Stern authored
BugLink: https://bugs.launchpad.net/bugs/1616318 The USB core contains a bug that can show up when a USB-3 host controller is removed. If the primary (USB-2) hcd structure is released before the shared (USB-3) hcd, the core will try to do a double-free of the common bandwidth_mutex. The problem was described in graphical form by Chung-Geol Kim, who first reported it: ================================================= At *remove USB(3.0) Storage sequence <1> --> <5> ((Problem Case)) ================================================= VOLD ------------------------------------|------------ (uevent) ________|_________ |<1> | |dwc3_otg_sm_work | |usb_put_hcd | |peer_hcd(kref=2)| |__________________| ________|_________ |<2> | |New USB BUS #2 | | | |peer_hcd(kref=1) | | | --(Link)-bandXX_mutex| | |__________________| | ___________________ | |<3> | | |dwc3_otg_sm_work | | |usb_put_hcd | | |primary_hcd(kref=1)| | |___________________| | _________|_________ | |<4> | | |New USB BUS #1 | | |hcd_release | | |primary_hcd(kref=0)| | | | | |bandXX_mutex(free) |<- |___________________| (( VOLD )) ______|___________ |<5> | | SCSI | |usb_put_hcd | |peer_hcd(kref=0) | |*hcd_release | |bandXX_mutex(free*)|<- double free |__________________| ================================================= This happens because hcd_release() frees the bandwidth_mutex whenever it sees a primary hcd being released (which is not a very good idea in any case), but in the course of releasing the primary hcd, it changes the pointers in the shared hcd in such a way that the shared hcd will appear to be primary when it gets released. This patch fixes the problem by changing hcd_release() so that it deallocates the bandwidth_mutex only when the _last_ hcd structure referencing it is released. The patch also removes an unnecessary test, so that when an hcd is released, both the shared_hcd and primary_hcd pointers in the hcd's peer will be cleared. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
Chung-Geol Kim <chunggeol.kim@samsung.com> Tested-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit ab2a4bf8) Signed-off-by:
Andy Whitcroft <apw@canonical.com> Acked-by:
Christopher Arges <chris.j.arges@canonical.com> Signed-off-by:
-
Gabriel Krisman Bertazi authored
BugLink: http://bugs.launchpad.net/bugs/1602724 When nvme_delete_queue fails in the first pass of the nvme_disable_io_queues() loop, we return early, failing to suspend all of the IO queues. Later, on the nvme_pci_disable path, this causes us to disable MSI without actually having freed all the IRQs, which triggers the BUG_ON in free_msi_irqs(), as show below. This patch refactors nvme_disable_io_queues to suspend all queues before start submitting delete queue commands. This way, we ensure that we have at least returned every IRQ before continuing with the removal path. [ 487.529200] kernel BUG at ../drivers/pci/msi.c:368! cpu 0x46: Vector: 700 (Program Check) at [c0000078c5b83650] pc: c000000000627a50: free_msi_irqs+0x90/0x200 lr: c000000000627a40: free_msi_irqs+0x80/0x200 sp: c0000078c5b838d0 msr: 9000000100029033 current = 0xc0000078c5b40000 paca = 0xc000000002bd7600 softe: 0 irq_happened: 0x01 pid = 1376, comm = kworker/70:1H kernel BUG at ../drivers/pci/msi.c:368! Linux version 4.7.0.mainline+ (root@iod76) (gcc version 5.3.1 20160413 (Ubuntu/IBM 5.3.1-14ubuntu2.1) ) #104 SMP Fri Jul 29 09:20:17 CDT 2016 enter ? for help [c0000078c5b83920] d0000000363b0cd8 nvme_dev_disable+0x208/0x4f0 [nvme] [c0000078c5b83a10] d0000000363b12a4 nvme_timeout+0xe4/0x250 [nvme] [c0000078c5b83ad0] c0000000005690e4 blk_mq_rq_timed_out+0x64/0x110 [c0000078c5b83b40] c00000000056c930 bt_for_each+0x160/0x170 [c0000078c5b83bb0] c00000000056d928 blk_mq_queue_tag_busy_iter+0x78/0x110 [c0000078c5b83c00] c0000000005675d8 blk_mq_timeout_work+0xd8/0x1b0 [c0000078c5b83c50] c0000000000e8cf0 process_one_work+0x1e0/0x590 [c0000078c5b83ce0] c0000000000e9148 worker_thread+0xa8/0x660 [c0000078c5b83d80] c0000000000f2090 kthread+0x110/0x130 [c0000078c5b83e30] c0000000000095f0 ret_from_kernel_thread+0x5c/0x6c Signed-off-by:
Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Cc: Brian King <brking@linux.vnet.ibm.com> Cc: Keith Busch <keith.busch@intel.com> Cc: linux-nvme@lists.infradead.org Signed-off-by:
Jens Axboe <axboe@fb.com> (cherry picked from commit c21377f8) Signed-off-by:
-
- 23 Aug, 2016 11 commits
-
-
John Johansen authored
change_hat using probing to find and transition to the first available hat. Hats missing as part of this probe are expected and should not be logged except in complain mode. BugLink: http://bugs.launchpad.net/bugs/1615893Signed-off-by:
John Johansen <john.johansen@canonical.com> Acked-by:
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1615892Signed-off-by:
-
John Johansen authored
when viewing a stack involving unconfined from across a ns boundary the mode is reported as mixed. Eg. lxc-container-default//&:lxdns1://unconfined (mixed) This is because the unconfined profile is in the special unconfined mode. Which will result in a (mixed) mode for any stack with profiles in enforcing or complain mode. This can however lead to confusion as to what mode is being used as mixed is also used for enforcing stacked with complain. Since unconfined doesn't affect the stack just special case it. BugLink: http://bugs.launchpad.net/bugs/1615890Signed-off-by:
-
John Johansen authored
the policy_lock parameter is a one way switch that prevents policy from being further modified. Unfortunately some of the module parameters can effectively modify policy by turning off enforcement. split policy_admin_capable into a view check and a full admin check, and update the admin check to test the policy_lock parameter. BugLink: http://bugs.launchpad.net/bugs/1615895Signed-off-by:
-
John Johansen authored
the vec_unique path for large vectors is broken, leading to oopses when a file handle is shared between 8 different security domains, and then a profile replacement/removal causing a label invalidation (ie. not all replacements) is done. BugLink: http://bugs.launchpad.net/bugs/1579135Signed-off-by:
-
John Johansen authored
If the result of a merge/update/parse is a vec with a single entry we should not be returning a reference label, but just the label it self. BugLink: http://bugs.launchpad.net/bugs/1615889Signed-off-by:
-
John Johansen authored
When the ns hierarchy a//foo and b//foo are compared the are incorrectly identified as being the same as they have the same depth and the same basename. Instead make sure to compare the full hname to distinguish this case. BugLink: http://bugs.launchpad.net/bugs/1615887Signed-off-by:
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1592547 If unpack_dfa() returns NULL due to the dfa not being present, profile_unpack() is not checking if the dfa is not present (NULL). Signed-off-by:
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1615885Signed-off-by:
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1615882Signed-off-by:
-
John Johansen authored
The label build for onexec when crossing a namespace boundry is not quite correct. The label needs to be built per profile and not based on the whole label because the onexec transition only applies to profiles within the ns. Where merging against the label could include profile that are transitioned via the profile_transition callback and should not be in the final label. BugLink: http://bugs.launchpad.net/bugs/1615881Signed-off-by:
-
