- 22 Aug, 2017 2 commits
-
-
Marcelo Henrique Cerri authored
BugLink: http://bugs.launchpad.net/bugs/1700972 Allow images to be created without the need of an initrd and also allow users to run without an initrd if they want to. Signed-off-by:
Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Thadeu Lima de Souza Cascardo authored
Ignore: yes Signed-off-by:Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
- 11 Aug, 2017 38 commits
-
-
Kleber Sacilotto de Souza authored
Signed-off-by:Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Liping Zhang authored
BugLink: http://bugs.launchpad.net/bugs/1709032 If one cpu is doing nf_ct_extend_unregister while another cpu is doing __nf_ct_ext_add_length, then we may hit BUG_ON(t == NULL). Moreover, there's no synchronize_rcu invocation after set nf_ct_ext_types[id] to NULL, so it's possible that we may access invalid pointer. But actually, most of the ct extends are built-in, so the problem listed above will not happen. However, there are two exceptions: NF_CT_EXT_NAT and NF_CT_EXT_SYNPROXY. For _EXT_NAT, the panic will not happen, since adding the nat extend and unregistering the nat extend are located in the same file(nf_nat_core.c), this means that after the nat module is removed, we cannot add the nat extend too. For _EXT_SYNPROXY, synproxy extend may be added by init_conntrack, while synproxy extend unregister will be done by synproxy_core_exit. So after nf_synproxy_core.ko is removed, we may still try to add the synproxy extend, then kernel panic may happen. I know it's very hard to reproduce this issue, but I can play a tricky game to make it happen very easily :) Step 1. Enable SYNPROXY for tcp dport 1234 at FORWARD hook: # iptables -I FORWARD -p tcp --dport 1234 -j SYNPROXY Step 2. Queue the syn packet to the userspace at raw table OUTPUT hook. Also note, in the userspace we only add a 20s' delay, then reinject the syn packet to the kernel: # iptables -t raw -I OUTPUT -p tcp --syn -j NFQUEUE --queue-num 1 Step 3. Using "nc 2.2.2.2 1234" to connect the server. Step 4. Now remove the nf_synproxy_core.ko quickly: # iptables -F FORWARD # rmmod ipt_SYNPROXY # rmmod nf_synproxy_core Step 5. After 20s' delay, the syn packet is reinjected to the kernel. Now you will see the panic like this: kernel BUG at net/netfilter/nf_conntrack_extend.c:91! Call Trace: ? __nf_ct_ext_add_length+0x53/0x3c0 [nf_conntrack] init_conntrack+0x12b/0x600 [nf_conntrack] nf_conntrack_in+0x4cc/0x580 [nf_conntrack] ipv4_conntrack_local+0x48/0x50 [nf_conntrack_ipv4] nf_reinject+0x104/0x270 nfqnl_recv_verdict+0x3e1/0x5f9 [nfnetlink_queue] ? nfqnl_recv_verdict+0x5/0x5f9 [nfnetlink_queue] ? nla_parse+0xa0/0x100 nfnetlink_rcv_msg+0x175/0x6a9 [nfnetlink] [...] One possible solution is to make NF_CT_EXT_SYNPROXY extend built-in, i.e. introduce nf_conntrack_synproxy.c and only do ct extend register and unregister in it, similar to nf_conntrack_timeout.c. But having such a obscure restriction of nf_ct_extend_unregister is not a good idea, so we should invoke synchronize_rcu after set nf_ct_ext_types to NULL, and check the NULL pointer when do __nf_ct_ext_add_length. Then it will be easier if we add new ct extend in the future. Last, we use kfree_rcu to free nf_ct_ext, so rcu_barrier() is unnecessary anymore, remove it too. Signed-off-by:
Liping Zhang <zlpnobody@gmail.com> Acked-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit 9c3f3794) Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com>
-
Kleber Sacilotto de Souza authored
BugLink: http://bugs.launchpad.net/bugs/1709032 This reverts commit f58e6473. Signed-off-by:
-
Willem de Bruijn authored
CVE-2017-1000112 When iteratively building a UDP datagram with MSG_MORE and that datagram exceeds MTU, consistently choose UFO or fragmentation. Once skb_is_gso, always apply ufo. Conversely, once a datagram is split across multiple skbs, do not consider ufo. Sendpage already maintains the first invariant, only add the second. IPv6 does not have a sendpage implementation to modify. A gso skb must have a partial checksum, do not follow sk_no_check_tx in udp_send_skb. Found by syzkaller. Fixes: e89e9cf5 ("[IPv4/IPv6]: UFO Scatter-gather approach") Reported-by:
Andrey Konovalov <andreyknvl@google.com> Signed-off-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 85f1bd9a) Signed-off-by:
-
Willem de Bruijn authored
CVE-2017-1000111 Updates to tp_reserve can race with reads of the field in packet_set_ring. Avoid this by holding the socket lock during updates in setsockopt PACKET_RESERVE. This bug was discovered by syzkaller. Fixes: 8913336a ("packet: add PACKET_RESERVE sockopt") Reported-by:
-
Kleber Sacilotto de Souza authored
This reverts commit ccf7bb73. CVE-2017-1000111 Signed-off-by:
-
Kleber Sacilotto de Souza authored
This reverts commit 840d468d. CVE-2017-1000112 Signed-off-by:
-
Peter Hurley authored
BugLink: http://bugs.launchpad.net/bugs/1709126 Currently, when the tty is hungup, the ldisc is re-instanced; ie., the current instance is destroyed and a new instance is created. The purpose of this design was to guarantee a valid, open ldisc for the lifetime of the tty. However, now that tty buffers are owned by and have lifetime equivalent to the tty_port (since v3.10), any data received immediately after the ldisc is re-instanced may cause continued driver i/o operations concurrently with the driver's hangup() operation. For drivers that shutdown h/w on hangup, this is unexpected and usually bad. For example, the serial core may free the xmit buffer page concurrently with an in-progress write() operation (triggered by echo). With the existing stable and robust ldisc reference handling, the cleaned-up tty_reopen(), the straggling unsafe ldisc use cleaned up, and the preparation to properly handle a NULL tty->ldisc, the ldisc instance can be destroyed and only re-instanced when the tty is re-opened. If the tty was opened as /dev/console or /dev/tty0, the original behavior of re-instancing the ldisc is retained (the 'reinit' parameter to tty_ldisc_hangup() is true). This is required since those file descriptors are never hungup. This patch has neglible impact on userspace; the tty file_operations ptr is changed to point to the hungup file operations _before_ the ldisc instance is destroyed, so only racing file operations might now retrieve a NULL ldisc reference (which is simply handled as if the hungup file operation had been called instead -- see "tty: Prepare for destroying line discipline on hangup"). This resolves a long-standing FIXME and several crash reports. Signed-off-by:
Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 892d1fa7) Signed-off-by:
Benjamin M Romer <benjamin.romer@canonical.com> Signed-off-by:
-
Peter Hurley authored
BugLink: http://bugs.launchpad.net/bugs/1709126 At tty hangup, the line discipline instance is reinitialized by closing the current ldisc instance and opening a new instance. This operation is complicated by error recovery: if the attempt to reinit the current line discipline fails, the line discipline is reset to N_TTY (which should not but can fail). Re-purpose tty_ldisc_reinit() to return a valid, open line discipline instance, or otherwise, an error. Signed-off-by:
-
Peter Hurley authored
BugLink: http://bugs.launchpad.net/bugs/1709126 tty->ldisc is a ptr to struct tty_ldisc, but unfortunately 'ldisc' is also used as a parameter or local name to refer to the line discipline index value (ie, N_TTY, N_GSM, etc.); instead prefer the name used by the line discipline registration/ref counting functions. Signed-off-by:
-
Peter Hurley authored
BugLink: http://bugs.launchpad.net/bugs/1709126 In preparation for destroying the line discipline instance on hangup, move tty_ldisc_kill() to eliminate needless forward declarations. No functional change. Signed-off-by:
-
Peter Hurley authored
BugLink: http://bugs.launchpad.net/bugs/1709126 In preparation of destroying line discipline on hangup, fix ldisc core operations to properly handle when the tty's ldisc is NULL. Signed-off-by:
-
Peter Hurley authored
BugLink: http://bugs.launchpad.net/bugs/1709126 After the ldisc is released, but before the tty is destroyed, the termios is saved (in tty_free_termios()); this termios is restored if a new tty is created on next open(). However, the line discipline is always reset, which is not obvious in the current method. Instead, reset as part of the restore. Restore the original line discipline, which may not have been N_TTY. Signed-off-by:
-
Peter Hurley authored
BugLink: http://bugs.launchpad.net/bugs/1709126 Perform common exit for both successful and error exit handling in tty_set_ldisc(). Fixes unlikely possibility of failing to restart input kworker when switching to the same line discipline (noop case). Signed-off-by:
-
Laura Abbott authored
BugLink: http://bugs.launchpad.net/bugs/1706833 We've received a number of reports of warnings when coming out of suspend with certain bluetooth firmware configurations: WARNING: CPU: 3 PID: 3280 at drivers/base/firmware_class.c:1126 _request_firmware+0x558/0x810() Modules linked in: ccm ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw binfmt_misc bnep intel_rapl iosf_mbi arc4 x86_pkg_temp_thermal snd_hda_codec_hdmi coretemp kvm_intel joydev snd_hda_codec_realtek iwldvm snd_hda_codec_generic kvm iTCO_wdt mac80211 iTCO_vendor_support snd_hda_intel snd_hda_controller snd_hda_codec crct10dif_pclmul snd_hwdep crc32_pclmul snd_seq crc32c_intel ghash_clmulni_intel uvcvideo snd_seq_device iwlwifi btusb videobuf2_vmalloc snd_pcm videobuf2_core serio_raw bluetooth cfg80211 videobuf2_memops sdhci_pci v4l2_common videodev thinkpad_acpi sdhci i2c_i801 lpc_ich mfd_core wacom mmc_core media snd_timer tpm_tis hid_logitech_hidpp wmi tpm rfkill snd mei_me mei shpchp soundcore nfsd auth_rpcgss nfs_acl lockd grace sunrpc i915 i2c_algo_bit drm_kms_helper e1000e drm hid_logitech_dj ptp pps_core video CPU: 3 PID: 3280 Comm: kworker/u17:0 Not tainted 3.19.3-200.fc21.x86_64 Hardware name: LENOVO 343522U/343522U, BIOS GCET96WW (2.56 ) 10/22/2013 Workqueue: hci0 hci_power_on [bluetooth] 0000000000000000 0000000089944328 ffff88040acffb78 ffffffff8176e215 0000000000000000 0000000000000000 ffff88040acffbb8 ffffffff8109bc1a 0000000000000000 ffff88040acffcd0 00000000fffffff5 ffff8804076bac40 Call Trace: [<ffffffff8176e215>] dump_stack+0x45/0x57 [<ffffffff8109bc1a>] warn_slowpath_common+0x8a/0xc0 [<ffffffff8109bd4a>] warn_slowpath_null+0x1a/0x20 [<ffffffff814dbe78>] _request_firmware+0x558/0x810 [<ffffffff814dc165>] request_firmware+0x35/0x50 [<ffffffffa03a7886>] btusb_setup_bcm_patchram+0x86/0x590 [btusb] [<ffffffff814d40e6>] ? rpm_idle+0xd6/0x230 [<ffffffffa04d4801>] hci_dev_do_open+0xe1/0xa90 [bluetooth] [<ffffffff810c51dd>] ? ttwu_do_activate.constprop.90+0x5d/0x70 [<ffffffffa04d5980>] hci_power_on+0x40/0x200 [bluetooth] [<ffffffff810b487c>] process_one_work+0x14c/0x3f0 [<ffffffff810b52f3>] worker_thread+0x53/0x470 [<ffffffff810b52a0>] ? rescuer_thread+0x300/0x300 [<ffffffff810ba548>] kthread+0xd8/0xf0 [<ffffffff810ba470>] ? kthread_create_on_node+0x1b0/0x1b0 [<ffffffff81774958>] ret_from_fork+0x58/0x90 [<ffffffff810ba470>] ? kthread_create_on_node+0x1b0/0x1b0 This occurs after every resume. When resuming, the bluetooth stack calls hci_register_dev, allocates a new workqueue, and immediately schedules the power_on on the newly created workqueue. Since the new workqueue is not freezable, the work runs immediately and triggers the warning since resume is still happening and usermodehelper has not yet been re-enabled. Fix this by making the request workqueue freezable. This ensures the work will not run until unfreezing occurs and usermodehelper is re-enabled. Signed-off-by:
Laura Abbott <labbott@fedoraproject.org> Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Acked-by:
-
Benjamin Tissoires authored
BugLink: https://bugs.launchpad.net/bugs/1708372 According to https://msdn.microsoft.com/en-us/library/windows/hardware/mt604195(v=vs.85).aspx external buttons have some weird usage mapping: - Button 2 Indicates Button State for external button for primary (default left) clicking. - Button 3 Indicates Button State for external button for secondary (default right) clicking. So in the current state, the buttons are mapped to right and middle. Move the usage by one to correctly map the external buttons. Tested-by:
Chris Chiu <chiu@endlessm.com> Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> (cherry picked from commit 594312b8) Signed-off-by:
Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1703430 This changed from y to m after trusty without justification. Having it built as a module causes issues with booting on some ARM systems. Signed-off-by:
Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by:
-
Brian Foster authored
BugLink: https://bugs.launchpad.net/bugs/1706132 If the filesystem has shut down, xfs_end_io() currently sets an error on the ioend and proceeds to ioend destruction. The ioend might contain a truncate transaction if the I/O extended the size of the file. This transaction is only cleaned up in xfs_setfilesize_ioend(), however, which is skipped in this case. This results in an xfs_log_ticket leak message when the associate cache slab is destroyed (e.g., on rmmod). This was originally reproduced by xfs/141 on a distro kernel. The problem is reproducible on an upstream kernel, but not easily detected in current upstream if the xfs_log_ticket cache happens to be merged with another cache. This can be reproduced more deterministically with the 'slab_nomerge' kernel boot option. Update xfs_end_io() to proceed with normal end I/O processing after an error is set on an ioend due to fs shutdown. The I/O type-based processing is already designed to handle an I/O error and ensure that the ioend is cleaned up correctly. Signed-off-by:
Brian Foster <bfoster@redhat.com> Reviewed-by:
Dave Chinner <dchinner@redhat.com> Signed-off-by:
Dave Chinner <david@fromorbit.com> (cherry picked from commit af055e37) Signed-off-by:
Rafael David Tinoco <rafael.tinoco@canonical.com> Acked-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1705495Signed-off-by:
Andy Whitcroft <apw@canonical.com> Acked-by:
-
Jan Kara authored
CVE-2017-7495 Huang has reported that in his powerfail testing he is seeing stale block contents in some of recently allocated blocks although he mounts ext4 in data=ordered mode. After some investigation I have found out that indeed when delayed allocation is used, we don't add inode to transaction's list of inodes needing flushing before commit. Originally we were doing that but commit f3b59291 removed the logic with a flawed argument that it is not needed. The problem is that although for delayed allocated blocks we write their contents immediately after allocating them, there is no guarantee that the IO scheduler or device doesn't reorder things and thus transaction allocating blocks and attaching them to inode can reach stable storage before actual block contents. Actually whenever we attach freshly allocated blocks to inode using a written extent, we should add inode to transaction's ordered inode list to make sure we properly wait for block contents to be written before committing the transaction. So that is what we do in this patch. This also handles other cases where stale data exposure was possible - like filling hole via mmap in data=ordered,nodelalloc mode. The only exception to the above rule are extending direct IO writes where blkdev_direct_IO() waits for IO to complete before increasing i_size and thus stale data exposure is not possible. For now we don't complicate the code with optimizing this special case since the overhead is pretty low. In case this is observed to be a performance problem we can always handle it using a special flag to ext4_map_blocks(). CC: stable@vger.kernel.org Fixes: f3b59291Reported-by:
"HUANG Weller (CM/ESW12-CN)" <Weller.Huang@cn.bosch.com> Tested-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> (backported from commit 06bd3c36) Signed-off-by:
Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by:
-
Pavani Muthyala authored
BugLink: https://bugs.launchpad.net/bugs/1706991 This patch configures specific uapsd parameters. This setting gives better downlink WLAN throughput when radio is shared between WLAN and BT. Signed-off-by:
Pavani Muthyala <pavani.muthyala@redpinesignals.com> Signed-off-by:
Amitkumar Karwar <amit.karwar@redpinesignals.com> Acked-by:
-
Prameela Rani Garnepudi authored
BugLink: https://bugs.launchpad.net/bugs/1706991 When Coex mode is enabled, enabling power save will improve radio sharing. Hence PS on by default flag is set. Signed-off-by:
Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by:
-
Haiyang Zhang authored
BugLink: http://bugs.launchpad.net/bugs/1690174 Azure hosts are not supporting non-TCP port numbers in vRSS hashing for now. For example, UDP packet loss rate will be high if port numbers are also included in vRSS hash. So, we created this patch to use only IP numbers for hashing in non-TCP traffic. Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by:
Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
-
Norik Dzhandzhapanyan authored
BugLink: http://bugs.launchpad.net/bugs/1706531 Report per chain RSSI to mac80211. Signed-off-by:
Norik Dzhandzhapanyan <norikd@gmail.com> [kvalo@qca.qualcomm.com: fix conflicts and style] Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com> (cherry picked from commit 8241253d) Signed-off-by:
-
Yang Jiaxun authored
BugLink: https://bugs.launchpad.net/linux/+bug/1705378 Some Lenovo ideapad models do not have hardware rfkill switches, but trying to read the rfkill switches through the ideapad-laptop module. It caused to always reported blocking breaking wifi. Fix it by adding those models to no_hw_rfkill_list. Signed-off-by:
Yang Jiaxun <yjx@flygoat.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> (backported from commit 710c059c) Signed-off-by:
Aaron Ma <aaron.ma@canonical.com> Acked-by:
-
Jürg Billeter authored
BugLink: http://bugs.launchpad.net/bugs/1705633 The iBT 3.5 controllers (Intel 8265, Windstorm Peak) need intel/ibt-12-16.sfi and intel/ibt-12-16.ddc firmware files from linux-firmware repository. Signed-off-by:
Jürg Billeter <j@bitron.ch> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> (cherry picked from commit d1b7abae) Signed-off-by:
-
Tedd Ho-Jeong An authored
BugLink: http://bugs.launchpad.net/bugs/1705633 The format of Intel Bluetooth firmware for bootloader product is ibt-<hw_variant>-<device_revision_id>.sfi and .ddc. This patch uses a hw_variant value read from the device during runtime to form the firmware filenames instead of using a constant value, so it can support multiple prouducts. Signed-off-by:
Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by:
-
Tedd Ho-Jeong An authored
BugLink: http://bugs.launchpad.net/bugs/1705633 The format of Intel Bluetooth firmware filename for bootloader product is ibt-<hw_variant>-<device_revision_id>.sfi Currently the driver uses a constant value 11 (0x0b) for hw_variant to support LnP/SfP product. But new product like WsP product has a different value such as 12 (0x0c). To support the multiple products, this patch replaces the constant value of hw_variant to the actual hw_variant value read from the device. Signed-off-by:
-
Tedd Ho-Jeong An authored
BugLink: http://bugs.launchpad.net/bugs/1705633 Multiple new hardware variants are planned and the simple if statement would get really complicated and unreadable. So instead replace it with a simple switch statement. The change is applied to both USB and UART. Based-on-patch-by:
-
Loic Poulain authored
BugLink: http://bugs.launchpad.net/bugs/1705633 The Intel Version Read command is used to retrieve information about hardware and firmware version/revision of Intel Bluetooth controllers. This is an Intel generic command used in USB and UART drivers. Signed-off-by:
Loic Poulain <loic.poulain@intel.com> Signed-off-by:
-
Jiahau Chang authored
BugLink: https://bugs.launchpad.net/bugs/1667750 When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad performance was manifesting in Web browser use (like download large file such as ISO image). It is known limitation of ASM1042A that is not compatible with driver scheduling, As a workaround we can modify flow control handling of ASM1042A. The register we modify is changes the behavior [use quirk bit 28 instead, usleep_range 40-60us -Mathias] Cc: <stable@vger.kernel.org> Signed-off-by:
Jiahau Chang <Lars_chang@asmedia.com.tw> Signed-off-by:
Ian Pilcher <arequipeno@gmail.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> (backported from commit 9da5a109) Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by:
-
Mauricio Faria de Oliveira authored
BugLink: http://bugs.launchpad.net/bugs/1696445 The commit 08024885 ("ses: Add power_status to SES device slot") introduced the 'power_status' attribute to enclosure components and the associated callbacks. There are 2 callbacks available to get the power status of a device: 1) ses_get_power_status() for 'struct enclosure_component_callbacks' 2) get_component_power_status() for the sysfs device attribute (these are available for kernel-space and user-space, respectively.) However, despite both methods being available to get power status on demand, that commit also introduced a call to get power status in ses_enclosure_data_process(). This dramatically increased the total probe time for SCSI devices on larger configurations, because ses_enclosure_data_process() is called several times during the SCSI devices probe and loops over the component devices (but that is another problem, another patch). That results in a tremendous continuous hammering of SCSI Receive Diagnostics commands to the enclosure-services device, which does delay the total probe time for the SCSI devices __significantly__: Originally, ~34 minutes on a system attached to ~170 disks: [ 9214.490703] mpt3sas version 13.100.00.00 loaded ... [11256.580231] scsi 17:0:177:0: qdepth(16), tagged(1), simple(0), ordered(0), scsi_level(6), cmd_que(1) With this patch, it decreased to ~2.5 minutes -- a 13.6x faster [ 1002.992533] mpt3sas version 13.100.00.00 loaded ... [ 1151.978831] scsi 11:0:177:0: qdepth(16), tagged(1), simple(0), ordered(0), scsi_level(6), cmd_que(1) Back to the commit discussion.. on the ses_get_power_status() call introduced in ses_enclosure_data_process(): impact of removing it. That may possibly be in place to initialize the power status value on device probe. However, those 2 functions available to retrieve that value _do_ automatically refresh/update it. So the potential benefit would be a direct access of the 'power_status' field which does not use the callbacks... But the only reader of 'struct enclosure_component::power_status' is the get_component_power_status() callback for sysfs attribute, and it _does_ check for and call the .get_power_status callback, (which indeed is defined and implemented by that commit), so the power status value is, again, automatically updated. So, the remaining potential for a direct/non-callback access to the power_status attribute would be out-of-tree modules -- well, for those, if they are for whatever reason interested in values that are set during device probe and not up-to-date by the time they need it.. well, that would be curious. Well, to handle that more properly, set the initial power state value to '-1' (i.e., uninitialized) instead of '1' (power 'on'), and check for it in that callback which may do an direct access to the field value _if_ a callback function is not defined. Signed-off-by:
Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> Fixes: 08024885 ("ses: Add power_status to SES device slot") Reviewed-by:
Dan Williams <dan.j.williams@intel.com> Reviewed-by:
Song Liu <songliubraving@fb.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> (cherry picked from commit 75106523) Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Signed-off-by:
-
Christian Kellner authored
BugLink: http://bugs.launchpad.net/bugs/1705169 The T470, X270 emits new hkey events in the 0x1311 - 0x1315 range. According to the user manual they should launch a user selected favorite application (star icon, 0x1311), snipping tool (0x1312, currently ignored), enable/disable bluetooth (0x1314) and open they keyboard settings (0x1315). The third nibble (0xf00) is used to differentiate between the original hotkeys, the adaptive keyboard codes and the new, additional ones. Signed-off-by:
Christian Kellner <ckellner@redhat.com> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by:
Alex Hung <alex.hung@canonical.com> Acked-by:
Colin King <colin.king@canonical.com> Acked-by:
Hui Wang <Wang <hui.wang@canonical.com> Signed-off-by:
-
Christian Kellner authored
BugLink: http://bugs.launchpad.net/bugs/1705169 Currently when dispatching hotkeys we check if the scancode is in the range of 0 and TPACPI_HOTKEY_MAP_LEN, although the bottom 20 entries in the hotkey keymap are already adaptive keycodes. Therefore we introduce a TP_ACPI_HOTKEYSCAN_ADAPTIVE_START and ensure that we are in the range 0 and ADAPTIVE_START for the generic keycode case. Signed-off-by:
-
Hui Wang authored
BugLink: http://bugs.launchpad.net/bugs/1705169 Recently we met an issue on lots of Lenovo thinkpad laptops (those laptops are not released to market yet), the issue is that the thinkpad_acpi.ko can't be automatically loaded as before. Through debugging, we found the HKEY_HID is LEN0268 instead of LEN0068 on those machines, and the MHKV is 0x200 instead of 0x100. So adding the new ID into the driver. Signed-off-by:
Darren Hart <dvhart@linux.intel.com> (cherry picked from commit a3c42a46) Signed-off-by:
-
Dave Young authored
Kexec reboot in case secure boot being enabled does not keep the secure boot mode in new kernel, so later one can load unsigned kernel via legacy kexec_load. In this state, the system is missing the protections provided by secure boot. Adding a patch to fix this by retain the secure_boot flag in original kernel. secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the stub. Fixing this issue by copying secure_boot flag across kexec reboot. Signed-off-by:
Dave Young <dyoung@redhat.com> CVE-2015-7837 (cherry-picked from https://github.com/mjg59/linux/commit/4b2b64d5a6ebc84214755ebccd599baef7c1b798) Signed-off-by:
Luis Henriques <luis.henriques@canonical.com> Acked-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1705447 Dmitry reported warnings occurring in __skb_gso_segment() [1] All SKB_GSO_DODGY producers can allow user space to feed packets that trigger the current check. We could prevent them from doing so, rejecting packets, but this might add regressions to existing programs. It turns out our SKB_GSO_DODGY handlers properly set up checksum information that is needed anyway when packets needs to be segmented. By checking again skb_needs_check() after skb_mac_gso_segment(), we should remove these pesky warnings, at a very minor cost. With help from Willem de Bruijn [1] WARNING: CPU: 1 PID: 6768 at net/core/dev.c:2439 skb_warn_bad_offload+0x2af/0x390 net/core/dev.c:2434 lo: caps=(0x000000a2803b7c69, 0x0000000000000000) len=138 data_len=0 gso_size=15883 gso_type=4 ip_summed=0 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 6768 Comm: syz-executor1 Not tainted 4.9.0 #5 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 ffff8801c063ecd8 ffffffff82346bdf ffffffff00000001 1ffff100380c7d2e ffffed00380c7d26 0000000041b58ab3 ffffffff84b37e38 ffffffff823468f1 ffffffff84820740 ffffffff84f289c0 dffffc0000000000 ffff8801c063ee20 Call Trace: [<ffffffff82346bdf>] __dump_stack lib/dump_stack.c:15 [inline] [<ffffffff82346bdf>] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51 [<ffffffff81827e34>] panic+0x1fb/0x412 kernel/panic.c:179 [<ffffffff8141f704>] __warn+0x1c4/0x1e0 kernel/panic.c:542 [<ffffffff8141f7e5>] warn_slowpath_fmt+0xc5/0x100 kernel/panic.c:565 [<ffffffff8356cbaf>] skb_warn_bad_offload+0x2af/0x390 net/core/dev.c:2434 [<ffffffff83585cd2>] __skb_gso_segment+0x482/0x780 net/core/dev.c:2706 [<ffffffff83586f19>] skb_gso_segment include/linux/netdevice.h:3985 [inline] [<ffffffff83586f19>] validate_xmit_skb+0x5c9/0xc20 net/core/dev.c:2969 [<ffffffff835892bb>] __dev_queue_xmit+0xe6b/0x1e70 net/core/dev.c:3383 [<ffffffff8358a2d7>] dev_queue_xmit+0x17/0x20 net/core/dev.c:3424 [<ffffffff83ad161d>] packet_snd net/packet/af_packet.c:2930 [inline] [<ffffffff83ad161d>] packet_sendmsg+0x32ed/0x4d30 net/packet/af_packet.c:2955 [<ffffffff834f0aaa>] sock_sendmsg_nosec net/socket.c:621 [inline] [<ffffffff834f0aaa>] sock_sendmsg+0xca/0x110 net/socket.c:631 [<ffffffff834f329a>] ___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1954 [<ffffffff834f5e58>] __sys_sendmsg+0x138/0x300 net/socket.c:1988 [<ffffffff834f604d>] SYSC_sendmsg net/socket.c:1999 [inline] [<ffffffff834f604d>] SyS_sendmsg+0x2d/0x50 net/socket.c:1995 [<ffffffff84371941>] entry_SYSCALL_64_fastpath+0x1f/0xc2 Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Dmitry Vyukov <dvyukov@google.com> Cc: Willem de Bruijn <willemb@google.com> Signed-off-by:
-
WANG Cong authored
BugLink: http://bugs.launchpad.net/bugs/1704102 As Hongjun/Nicolas summarized in their original patch: " When a device changes from one netns to another, it's first unregistered, then the netns reference is updated and the dev is registered in the new netns. Thus, when a slave moves to another netns, it is first unregistered. This triggers a NETDEV_UNREGISTER event which is caught by the bonding driver. The driver calls bond_release(), which calls dev_set_mtu() and thus triggers NETDEV_CHANGEMTU (the device is still in the old netns). " This is a very special case, because the device is being unregistered no one should still care about the NETDEV_CHANGEMTU event triggered at this point, we can avoid broadcasting this event on this path, and avoid touching inetdev_event()/addrconf_notify() path. It requires to export __dev_set_mtu() to bonding driver. Reported-by:
Hongjun Li <hongjun.li@6wind.com> Reported-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Cc: Jay Vosburgh <j.vosburgh@gmail.com> Cc: Veaceslav Falico <vfalico@gmail.com> Cc: Andy Gospodarek <andy@greyhouse.net> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
