- 15 Dec, 2016 21 commits
-
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Expand the check in should_remove_suid() to keep privileges for CAP_FSETID in s_user_ns rather than init_user_ns. --EWB Changed from ns_capable(sb->s_user_ns, ) to capable_wrt_inode_uidgid Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Acked-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
Luis Henriques <luis.henriques@canonical.com>
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 This reverts commit b50099a2 in order to apply the version in yakkety. Signed-off-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Allow users with CAP_SYS_CHOWN over the superblock of a filesystem to chown files. Ordinarily the capable_wrt_inode_uidgid check is sufficient to allow access to files but when the underlying filesystem has uids or gids that don't map to the current user namespace it is not enough, so the chown permission checks need to be extended to allow this case. Calling chown on filesystem nodes whose uid or gid don't map is necessary if those nodes are going to be modified as writing back inodes which contain uids or gids that don't map is likely to cause filesystem corruption of the uid or gid fields. Once chown has been called the existing capable_wrt_inode_uidgid checks are sufficient, to allow the owner of a superblock to do anything the global root user can do with an appropriate set of capabilities. For the proc filesystem this relaxation of permissions is not safe, as some files are owned by users (particularly GLOBAL_ROOT_UID) outside of the control of the mounter of the proc and that would be unsafe to grant chown access to. So update setattr on proc to disallow changing files whose uids or gids are outside of proc's s_user_ns. The original version of this patch was written by: Seth Forshee. I have rewritten and rethought this patch enough so it's really not the same thing (certainly it needs a different description), but he deserves credit for getting out there and getting the conversation started, and finding the potential gotcha's and putting up with my semi-paranoid feedback. Inspired-by:
-
Seth Forshee authored
(namespace) Revert "UBUNTU: SAUCE: fs: Allow superblock owner to change ownership of inodes with unmappable ids" This reverts commit 6e42b32e in order to apply the version in yakkety. Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 In general the handling of IMA/EVM xattrs is good, but I found a few locations where either the xattr size or the value of the type field in the xattr are not checked. Add a few simple checks to these locations to prevent malformed or malicious xattrs from causing problems. Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 This reverts commit 5d96fa44, as it adds attack surface without any clear use case at this point. Signed-off-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Mostly supporting filesystems outside of init_user_ns is s/&init_usre_ns/dquot->dq_sb->s_user_ns/. An actual need for supporting quotas on filesystems outside of s_user_ns is quite a ways away and to be done responsibily needs an audit on what can happen with hostile quota files. Until that audit is complete don't attempt to support quota files on filesystems outside of s_user_ns. Cc: Jan Kara <jack@suse.cz> Acked-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 In Q_XSETQLIMIT use sb->s_user_ns to detect when we are dealing with the filesystems notion of id 0. Cc: Jan Kara <jack@suse.cz> Acked-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Introduce the helper qid_has_mapping and use it to ensure that the quota system only considers qids that map to the filesystems s_user_ns. In practice for quota supporting filesystems today this is the exact same check as qid_valid. As only 0xffffffff aka (qid_t)-1 does not map into init_user_ns. Replace the qid_valid calls with qid_has_mapping as values come in from userspace. This is harmless today and it prepares the quota system to work on filesystems with quotas but mounted by unprivileged users. Call qid_has_mapping from dqget. This ensures the passed in qid has a prepresentation on the underlying filesystem. Previously this was unnecessary as filesystesm never had qids that could not map. With the introduction of filesystems outside of s_user_ns this will not remain true. All of this ensures the quota code never has to deal with qids that don't map to the underlying filesystem. Cc: Jan Kara <jack@suse.cz> Acked-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 This reverts commit 95317559 in order to apply the corresponding upstream patches. Signed-off-by:
-
Seth Forshee authored
(namespace) Revert "UBUNTU: SAUCE: quota: Require that qids passed to dqget() be valid and map into s_user_ns" BugLink: http://bugs.launchpad.net/bugs/1634964 This reverts commit 2c79b9bf in order to apply the corresponding upstream patches. Signed-off-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 It is expected that filesystems can not represent uids and gids from outside of their user namespace. Keep things simple by not even trying to create filesystem nodes with non-sense uids and gids. Acked-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 When a filesystem outside of init_user_ns is mounted it could have uids and gids stored in it that do not map to init_user_ns. The plan is to allow those filesystems to set i_uid to INVALID_UID and i_gid to INVALID_GID for unmapped uids and gids and then to handle that strange case in the vfs to ensure there is consistent robust handling of the weirdness. Upon a careful review of the vfs and filesystems about the only case where there is any possibility of confusion or trouble is when the inode is written back to disk. In that case filesystems typically read the inode->i_uid and inode->i_gid and write them to disk even when just an inode timestamp is being updated. Which leads to a rule that is very simple to implement and understand inodes whose i_uid or i_gid is not valid may not be written. In dealing with access times this means treat those inodes as if the inode flag S_NOATIME was set. Reads of the inodes appear safe and useful, but any write or modification is disallowed. The only inode write that is allowed is a chown that sets the uid and gid on the inode to valid values. After such a chown the inode is normal and may be treated as such. Denying all writes to inodes with uids or gids unknown to the vfs also prevents several oddball cases where corruption would have occurred because the vfs does not have complete information. One problem case that is prevented is attempting to use the gid of a directory for new inodes where the directories sgid bit is set but the directories gid is not mapped. Another problem case avoided is attempting to update the evm hash after setxattr, removexattr, and setattr. As the evm hash includeds the inode->i_uid or inode->i_gid not knowning the uid or gid prevents a correct evm hash from being computed. evm hash verification also fails when i_uid or i_gid is unknown but that is essentially harmless as it does not cause filesystem corruption. Acked-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Fuse currently lacks comprehensive support for posix ACLs, but some fuse filesystems process the acl xattrs internally. For this to continue to work the ids within the xattrs need to be mapped into s_user_ns when written to the filesystem and mapped from s_user_ns when read. Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Fuse will make use of this function to provide backwards- compatible acl support when proper posix acl support is added. Add a check to return immediately if the to and from namespaces are the same, and remove equivalent checks from its callers. Also return an error code to indicate to callers whether or not the conversion of the id between the user namespaces was successful. For a valid xattr the id will continue to be changed regardless to maintain the current behaviour for existing callers, so they do not require updates to handle failed conversions. Signed-off-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Update posix_acl_valid to verify that an acl is within a user namespace. Update the callers of posix_acl_valid to pass in an appropriate user namespace. For posix_acl_xattr_set and v9fs_xattr_set_acl pass in inode->i_sb->s_user_ns to posix_acl_valid. For md_unpack_acl pass in &init_user_ns as no inode or superblock is in sight. Acked-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 This reverts commit 7efdc167 in order to apply the corresponding upstream patch. Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Add checks to notify_change to verify that uid and gid changes will map into the superblock's user namespace. If they do not fail with -EOVERFLOW. This is mandatory so that fileystems don't have to even think of dealing with ia_uid and ia_gid that --EWB Moved the test from inode_change_ok to notify_change Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 This reverts commit fe50b8ac in order to apply the upstream version of the same patch. Signed-off-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Allowing a filesystem to be mounted by other than root in the initial user namespace is a filesystem property not a mount namespace property and as such should be checked in filesystem specific code. Move the FS_USERNS_MOUNT test into super.c:sget_userns(). Acked-by:
-
Ross Lagerwall authored
BugLink: http://bugs.launchpad.net/bugs/1649821 The following commit: 1fb3a8b2 ("xen/spinlock: Fix locking path engaging too soon under PVHVM.") ... moved the initalization of the kicker interrupt until after native_cpu_up() is called. However, when using qspinlocks, a CPU may try to kick another CPU that is spinning (because it has not yet initialized its kicker interrupt), resulting in the following crash during boot: kernel BUG at /build/linux-Ay7j_C/linux-4.4.0/drivers/xen/events/events_base.c:1210! invalid opcode: 0000 [#1] SMP ... RIP: 0010:[<ffffffff814c97c9>] [<ffffffff814c97c9>] xen_send_IPI_one+0x59/0x60 ... Call Trace: [<ffffffff8102be9e>] xen_qlock_kick+0xe/0x10 [<ffffffff810cabc2>] __pv_queued_spin_unlock+0xb2/0xf0 [<ffffffff810ca6d1>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20 [<ffffffff81052936>] ? check_tsc_warp+0x76/0x150 [<ffffffff81052aa6>] check_tsc_sync_source+0x96/0x160 [<ffffffff81051e28>] native_cpu_up+0x3d8/0x9f0 [<ffffffff8102b315>] xen_hvm_cpu_up+0x35/0x80 [<ffffffff8108198c>] _cpu_up+0x13c/0x180 [<ffffffff81081a4a>] cpu_up+0x7a/0xa0 [<ffffffff81f80dfc>] smp_init+0x7f/0x81 [<ffffffff81f5a121>] kernel_init_freeable+0xef/0x212 [<ffffffff81817f30>] ? rest_init+0x80/0x80 [<ffffffff81817f3e>] kernel_init+0xe/0xe0 [<ffffffff8182488f>] ret_from_fork+0x3f/0x70 [<ffffffff81817f30>] ? rest_init+0x80/0x80 To fix this, only send the kick if the target CPU's interrupt has been initialized. This check isn't racy, because the target is waiting for the spinlock, so it won't have initialized the interrupt in the meantime. Signed-off-by:
Ross Lagerwall <ross.lagerwall@citrix.com> Reviewed-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: David Vrabel <david.vrabel@citrix.com> Cc: Juergen Gross <jgross@suse.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Cc: xen-devel@lists.xenproject.org Signed-off-by:
Ingo Molnar <mingo@kernel.org> (cherry picked from commit 707e59ba) Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
-
- 14 Dec, 2016 6 commits
-
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1642368Signed-off-by:
Robert Hooker <robert.hooker@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1642368 Prevent staging drivers from being loadable in a secure boot environment. Signed-off-by:
-
Michael Pobega authored
BugLink: http://bugs.launchpad.net/bugs/1648279 The Dell Latitude 3350's ethernet card attempts to use a reserved IRQ (18), resulting in ACPI being unable to enable the ethernet. Adding it to acpi_rev_dmi_table[] helps to work around this problem. Signed-off-by:
Michael Pobega <mpobega@neverware.com> [ rjw: Changelog ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> (backported from commit 708f5dcc) Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Acked-by:
-
Eric Dumazet authored
CAP_NET_ADMIN users should not be allowed to set negative sk_sndbuf or sk_rcvbuf values, as it can lead to various memory corruptions, crashes, OOM... Note that before commit 82981930 ("net: cleanups in sock_setsockopt()"), the bug was even more serious, since SO_SNDBUF and SO_RCVBUF were vulnerable. This needs to be backported to all known linux kernels. Again, many thanks to syzkaller team for discovering this gem. Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Andrey Konovalov <andreyknvl@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit b98b0bc8) CVE-2016-9793 Signed-off-by:
John Donnelly <john.donnelly@canonical.com> Acked-by:
Steve Beattie <sbeattie@ubuntu.com>
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1400319 When we crash from NMI context (e.g. after NMI injection from host when 'sysctl -w kernel.unknown_nmi_panic=1' is set) we hit kernel BUG at mm/vmalloc.c:1530! as vfree() is denied. While the issue could be solved with in_nmi() check instead I opted for skipping vfree on all sorts of crashes to reduce the amount of work which can cause consequent crashes. We don't really need to free anything on crash. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit a9f61ca7) Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1636656 The Hyper-V netvsc driver was looking at the incorrect status bits in the checksum info. It was setting the receive checksum unnecessary flag based on the IP header checksum being correct. The checksum flag is skb is about TCP and UDP checksum status. Because of this bug, any packet received with bad TCP checksum would be passed up the stack and to the application causing data corruption. The problem is reproducible via netcat and netem. This had a side effect of not doing receive checksum offload on IPv6. The driver was also also always doing checksum offload independent of the checksum setting done via ethtool. Signed-off-by:
Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
-
- 12 Dec, 2016 1 commit
-
-
Luis Henriques authored
Ignore: yes Signed-off-by:
-
- 09 Dec, 2016 3 commits
-
-
Brad Figg authored
Signed-off-by: -
Brad Figg authored
Signed-off-by: -
Brad Figg authored
Ignore: yes Signed-off-by:
-
- 08 Dec, 2016 9 commits
-
-
Brad Figg authored
Signed-off-by: -
Nicolas Dichtel authored
BugLink: http://bugs.launchpad.net/bugs/1593235 The function geneve_dev_create_fb() (only used by ovs) never calls rtnl_configure_link(). The consequence is that dev->rtnl_link_state is never set to RTNL_LINK_INITIALIZED. During the deletion phase, the function rollback_registered_many() sends a RTM_DELLINK only if dev->rtnl_link_state is set to RTNL_LINK_INITIALIZED. Fixes: e305ac6c ("geneve: Add support to collect tunnel metadata.") CC: Pravin B Shelar <pshelar@nicira.com> CC: Jesse Gross <jesse@nicira.com> CC: Thomas Graf <tgraf@suug.ch> Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <thadeu.cascardo@canonical.com> Acked-by:
-
Nicolas Dichtel authored
BugLink: http://bugs.launchpad.net/bugs/1593235 The function gretap_fb_dev_create() (only used by ovs) never calls rtnl_configure_link(). The consequence is that dev->rtnl_link_state is never set to RTNL_LINK_INITIALIZED. During the deletion phase, the function rollback_registered_many() sends a RTM_DELLINK only if dev->rtnl_link_state is set to RTNL_LINK_INITIALIZED. Fixes: b2acd1dc ("openvswitch: Use regular GRE net_device instead of vport") CC: Thomas Graf <tgraf@suug.ch> CC: Pravin B Shelar <pshelar@nicira.com> Signed-off-by:
-
Nicolas Dichtel authored
BugLink: http://bugs.launchpad.net/bugs/1593235 The function vxlan_dev_create() (only used by ovs) never calls rtnl_configure_link(). The consequence is that dev->rtnl_link_state is never set to RTNL_LINK_INITIALIZED. During the deletion phase, the function rollback_registered_many() sends a RTM_DELLINK only if dev->rtnl_link_state is set to RTNL_LINK_INITIALIZED. Note that the function vxlan_dev_create() is moved after the rtnl stuff so that vxlan_dellink() can be called in this function. Fixes: dcc38c03 ("openvswitch: Re-add CONFIG_OPENVSWITCH_VXLAN") CC: Thomas Graf <tgraf@suug.ch> CC: Pravin B Shelar <pshelar@nicira.com> Signed-off-by:
-
Nicolas Dichtel authored
BugLink: http://bugs.launchpad.net/bugs/1593235 After ipgre_newlink()/geneve_configure() call, the netdev is registered. Fixes: 7e059158 ("vxlan, gre, geneve: Set a large MTU on ovs-created tunnel devices") CC: David Wragg <david@weave.works> Signed-off-by:
-
Jiri Olsa authored
BugLink: http://bugs.launchpad.net/bugs/1648088 Frank reported kernel panic when he disabled several cores in BIOS via following option: Core Disable Bitmap(Hex) [0] with number 0xFFE, which leaves 16 CPUs in system (out of 48). The kernel panic below goes along with following messages: smpboot: Max logical packages: 2^M smpboot: APIC(0) Converting physical 0 to logical package 0^M smpboot: APIC(20) Converting physical 1 to logical package 1^M smpboot: APIC(40) Package 2 exceeds logical package map^M smpboot: CPU 8 APICId 40 disabled^M smpboot: APIC(60) Package 3 exceeds logical package map^M smpboot: CPU 12 APICId 60 disabled^M ... general protection fault: 0000 [#1] SMP^M Modules linked in:^M CPU: 15 PID: 1 Comm: swapper/0 Not tainted 4.7.0-rc5+ #1^M Hardware name: SGI UV300/UV300, BIOS SGI UV 300 series BIOS 05/25/2016^M task: ffff8801673e0000 ti: ffff8801673ac000 task.ti: ffff8801673ac000^M RIP: 0010:[<ffffffff81014d54>] [<ffffffff81014d54>] uncore_change_context+0xd4/0x180^M ... [<ffffffff810158ac>] uncore_event_init_cpu+0x6c/0x70^M [<ffffffff81d8c91c>] intel_uncore_init+0x1c2/0x2dd^M [<ffffffff81d8c75a>] ? uncore_cpu_setup+0x17/0x17^M [<ffffffff81002190>] do_one_initcall+0x50/0x190^M [<ffffffff810ab193>] ? parse_args+0x293/0x480^M [<ffffffff81d87365>] kernel_init_freeable+0x1a5/0x249^M [<ffffffff81d86a35>] ? set_debug_rodata+0x12/0x12^M [<ffffffff816dc19e>] kernel_init+0xe/0x110^M [<ffffffff816e93bf>] ret_from_fork+0x1f/0x40^M [<ffffffff816dc190>] ? rest_init+0x80/0x80^M The reason for the panic is wrong value of __max_logical_packages, which lets logical_package_map uninitialized and the uncore code relying on this map being properly initialized (maybe we should add some safety checks there as well). The __max_logical_packages is computed as: DIV_ROUND_UP(total_cpus, ncpus); - ncpus being number of cores With above BIOS setup we get total_cpus == 16 which set __max_logical_packages to 2 (ncpus is 12). Once topology_update_package_map processes CPU with logical pkg over 2 we display above messages and fail to initialize the physical_to_logical_pkg map, which makes the uncore code crash. The fix is to remove logical_package_map bitmap completely and keep and update the logical_packages number instead. After we enumerate all the present CPUs, we check if the enumerated logical packages count is within its computed maximum from BIOS data. If it's not the case, we set this maximum to the new enumerated value and freeze any new addition of logical packages. The freeze is because lot of init code like uncore/rapl/cqm depends on having maximum logical package value set to allocate their data, so we can't change it later on. Prarit Bhargava tested the patch and confirms that it solves the problem: From dmidecode: Core Count: 24 Core Enabled: 24 Thread Count: 48 Orig kernel boot log: [ 0.464981] smpboot: Max logical packages: 19 [ 0.469861] smpboot: APIC(0) Converting physical 0 to logical package 0 [ 0.477261] smpboot: APIC(40) Converting physical 1 to logical package 1 [ 0.484760] smpboot: APIC(80) Converting physical 2 to logical package 2 [ 0.492258] smpboot: APIC(c0) Converting physical 3 to logical package 3 1. nr_cpus=8, should stop enumerating in package 0: [ 0.533664] smpboot: APIC(0) Converting physical 0 to logical package 0 [ 0.539596] smpboot: Max logical packages: 19 2. max_cpus=8, should still enumerate all packages: [ 0.526494] smpboot: APIC(0) Converting physical 0 to logical package 0 [ 0.532428] smpboot: APIC(40) Converting physical 1 to logical package 1 [ 0.538456] smpboot: APIC(80) Converting physical 2 to logical package 2 [ 0.544486] smpboot: APIC(c0) Converting physical 3 to logical package 3 [ 0.550524] smpboot: Max logical packages: 19 3. nr_cpus=49 ( 2 socket + 1 core on 3rd socket), should stop enumerating in package 2: [ 0.521378] smpboot: APIC(0) Converting physical 0 to logical package 0 [ 0.527314] smpboot: APIC(40) Converting physical 1 to logical package 1 [ 0.533345] smpboot: APIC(80) Converting physical 2 to logical package 2 [ 0.539368] smpboot: Max logical packages: 19 4. maxcpus=49, should still enumerate all packages: [ 0.525591] smpboot: APIC(0) Converting physical 0 to logical package 0 [ 0.531525] smpboot: APIC(40) Converting physical 1 to logical package 1 [ 0.537547] smpboot: APIC(80) Converting physical 2 to logical package 2 [ 0.543579] smpboot: APIC(c0) Converting physical 3 to logical package 3 [ 0.549624] smpboot: Max logical packages: 19 5. kdump (nr_cpus=1) works as well. Reported-by:
Frank Ramsay <framsay@redhat.com> Tested-by:
Prarit Bhargava <prarit@redhat.com> Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Reviewed-by:
Peter Zijlstra <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20160815101700.GA30090@kravaSigned-off-by:
-
Craig Magina authored
BugLink: https://launchpad.net/bugs/1625222 Ubuntu builds the uas and xhci-plat-hcd usb drivers as modules, these module are needed for d-i to use usb in the installer on the merlin platform. Signed-off-by:
Craig Magina <craig.magina@canonical.com> Acked-by:
-
Michal Schmidt authored
BugLink: http://bugs.launchpad.net/bugs/1616107 Since implementing VLAN filtering in commit 05cc5a39 ("bnx2x: add vlan filtering offload") bnx2x refuses to add a VLAN while the interface is down: # ip link add link enp3s0f0 enp3s0f0_10 type vlan id 10 RTNETLINK answers: Bad address and in dmesg (with bnx2x.debug=0x20): bnx2x: [bnx2x_vlan_rx_add_vid:12941(enp3s0f0)]Ignoring VLAN configuration the interface is down Other drivers have no problem with this. Fix this peculiar behavior in the following way: - Accept requests to add/kill VID regardless of the device state. Maintain the requested list of VIDs in the bp->vlan_reg list. - If the device is up, try to configure the VID list into the hardware. If we run out of VLAN credits or encounter a failure configuring an entry, fall back to accepting all VLANs. If we successfully configure all entries from the list, turn the fallback off. - Use the same code for reconfiguring VLANs during NIC load. Signed-off-by:
Michal Schmidt <mschmidt@redhat.com> Acked-by:
Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by:
-
Gabriel Krisman Bertazi authored
BugLink: http://bugs.launchpad.net/bugs/1646857 During a PCI error recovery, like the ones provoked by EEH in the ppc64 platform, all IO to the device must be blocked while the recovery is completed. Current 8250_pci implementation only suspends the port instead of detaching it, which doesn't prevent incoming accesses like TIOCMGET and TIOCMSET calls from reaching the device. Those end up racing with the EEH recovery, crashing it. Similar races were also observed when opening the device and when shutting it down during recovery. This patch implements a more robust IO blockage for the 8250_pci recovery by unregistering the port at the beginning of the procedure and re-adding it afterwards. Since the port is detached from the uart layer, we can be sure that no request will make through to the device during recovery. This is similar to the solution used by the JSM serial driver. I thank Peter Hurley <peter@hurleysoftware.com> for valuable input on this one over one year ago. Signed-off-by:
Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Signed-off-by:
-
