1. 07 8月, 2015 2 次提交
    • H
      KVM: x86: Use adjustment in guest cycles when handling MSR_IA32_TSC_ADJUST · d7add054
      Haozhong Zhang 提交于
      When kvm_set_msr_common() handles a guest's write to
      MSR_IA32_TSC_ADJUST, it will calcuate an adjustment based on the data
      written by guest and then use it to adjust TSC offset by calling a
      call-back adjust_tsc_offset(). The 3rd parameter of adjust_tsc_offset()
      indicates whether the adjustment is in host TSC cycles or in guest TSC
      cycles. If SVM TSC scaling is enabled, adjust_tsc_offset()
      [i.e. svm_adjust_tsc_offset()] will first scale the adjustment;
      otherwise, it will just use the unscaled one. As the MSR write here
      comes from the guest, the adjustment is in guest TSC cycles. However,
      the current kvm_set_msr_common() uses it as a value in host TSC
      cycles (by using true as the 3rd parameter of adjust_tsc_offset()),
      which can result in an incorrect adjustment of TSC offset if SVM TSC
      scaling is enabled. This patch fixes this problem.
      Signed-off-by: NHaozhong Zhang <haozhong.zhang@intel.com>
      Cc: stable@vger.linux.org
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      d7add054
    • P
      KVM: x86: zero IDT limit on entry to SMM · 18c3626e
      Paolo Bonzini 提交于
      The recent BlackHat 2015 presentation "The Memory Sinkhole"
      mentions that the IDT limit is zeroed on entry to SMM.
      
      This is not documented, and must have changed some time after 2010
      (see http://www.ssi.gouv.fr/uploads/IMG/pdf/IT_Defense_2010_final.pdf).
      KVM was not doing it, but the fix is easy.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      18c3626e
  2. 05 8月, 2015 1 次提交
  3. 30 7月, 2015 2 次提交
    • P
      Merge tag 'kvm-s390-master-20150730' of... · 7307f70c
      Paolo Bonzini 提交于
      Merge tag 'kvm-s390-master-20150730' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into kvm-master
      
      KVM: s390: bugfix for kvm/master (4.2)
      
      Here is a bugfix for a regression that was introduced after 4.1
      with the commit commit 785dbef4 ("KVM: s390: optimize round
      trip time in request handling"). After lots of cpu hotplugs in the
      guest (online/offline) sometimes a guest CPU did loop within host
      KVM code. Reason was that PROG_REQUEST was set in the sie control
      block, but no request was pending. This made commit 785dbef4
      the suspect and changing that area to always reset PROG_REQUEST
      did indeed fix the problem.
      
      Special thanks to David Hildenbrand, who helped understanding the
      exact sequence that led to the problem.
      7307f70c
    • C
      KVM: s390: Fix hang VCPU hang/loop regression · 586b7ccd
      Christian Borntraeger 提交于
      commit 785dbef4 ("KVM: s390: optimize round trip time in request
      handling") introduced a regression. This regression was seen with
      CPU hotplug in the guest and switching between 1 or 2 CPUs. This will
      set/reset the IBS control via synced request.
      
      Whenever we make a synced request, we first set the vcpu->requests
      bit and then block the vcpu. The handler, on the other hand, unblocks
      itself, processes vcpu->requests (by clearing them) and unblocks itself
      once again.
      
      Now, if the requester sleeps between setting of vcpu->requests and
      blocking, the handler will clear the vcpu->requests bit and try to
      unblock itself (although no bit is set). When the requester wakes up,
      it blocks the VCPU and we have a blocked VCPU without requests.
      
      Solution is to always unset the block bit.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Reviewed-by: NDavid Hildenbrand <dahi@linux.vnet.ibm.com>
      Fixes: 785dbef4 ("KVM: s390: optimize round trip time in request handling")
      586b7ccd
  4. 29 7月, 2015 9 次提交
  5. 28 7月, 2015 5 次提交
    • K
      nfs: Fix an oops caused by using other thread's stack space in ASYNC mode · a49c2691
      Kinglong Mee 提交于
      An oops caused by using other thread's stack space in sunrpc ASYNC sending thread.
      
      [ 9839.007187] ------------[ cut here ]------------
      [ 9839.007923] kernel BUG at fs/nfs/nfs4xdr.c:910!
      [ 9839.008069] invalid opcode: 0000 [#1] SMP
      [ 9839.008069] Modules linked in: blocklayoutdriver rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm joydev iosf_mbi crct10dif_pclmul snd_timer crc32_pclmul crc32c_intel ghash_clmulni_intel snd soundcore ppdev pvpanic parport_pc i2c_piix4 serio_raw virtio_balloon parport acpi_cpufreq nfsd nfs_acl lockd grace auth_rpcgss sunrpc qxl drm_kms_helper virtio_net virtio_console virtio_blk ttm drm virtio_pci virtio_ring virtio ata_generic pata_acpi
      [ 9839.008069] CPU: 0 PID: 308 Comm: kworker/0:1H Not tainted 4.0.0-0.rc4.git1.3.fc23.x86_64 #1
      [ 9839.008069] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      [ 9839.008069] Workqueue: rpciod rpc_async_schedule [sunrpc]
      [ 9839.008069] task: ffff8800d8b4d8e0 ti: ffff880036678000 task.ti: ffff880036678000
      [ 9839.008069] RIP: 0010:[<ffffffffa0339cc9>]  [<ffffffffa0339cc9>] reserve_space.part.73+0x9/0x10 [nfsv4]
      [ 9839.008069] RSP: 0018:ffff88003667ba58  EFLAGS: 00010246
      [ 9839.008069] RAX: 0000000000000000 RBX: 000000001fc15e18 RCX: ffff8800c0193800
      [ 9839.008069] RDX: ffff8800e4ae3f24 RSI: 000000001fc15e2c RDI: ffff88003667bcd0
      [ 9839.008069] RBP: ffff88003667ba58 R08: ffff8800d9173008 R09: 0000000000000003
      [ 9839.008069] R10: ffff88003667bcd0 R11: 000000000000000c R12: 0000000000010000
      [ 9839.008069] R13: ffff8800d9173350 R14: 0000000000000000 R15: ffff8800c0067b98
      [ 9839.008069] FS:  0000000000000000(0000) GS:ffff88011fc00000(0000) knlGS:0000000000000000
      [ 9839.008069] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 9839.008069] CR2: 00007f988c9c8bb0 CR3: 00000000d99b6000 CR4: 00000000000407f0
      [ 9839.008069] Stack:
      [ 9839.008069]  ffff88003667bbc8 ffffffffa03412c5 00000000c6c55680 ffff880000000003
      [ 9839.008069]  0000000000000088 00000010c6c55680 0001000000000002 ffffffff816e87e9
      [ 9839.008069]  0000000000000000 00000000477290e2 ffff88003667bab8 ffffffff81327ba3
      [ 9839.008069] Call Trace:
      [ 9839.008069]  [<ffffffffa03412c5>] encode_attrs+0x435/0x530 [nfsv4]
      [ 9839.008069]  [<ffffffff816e87e9>] ? inet_sendmsg+0x69/0xb0
      [ 9839.008069]  [<ffffffff81327ba3>] ? selinux_socket_sendmsg+0x23/0x30
      [ 9839.008069]  [<ffffffff8164c1df>] ? do_sock_sendmsg+0x9f/0xc0
      [ 9839.008069]  [<ffffffff8164c278>] ? kernel_sendmsg+0x58/0x70
      [ 9839.008069]  [<ffffffffa011acc0>] ? xdr_reserve_space+0x20/0x170 [sunrpc]
      [ 9839.008069]  [<ffffffffa011acc0>] ? xdr_reserve_space+0x20/0x170 [sunrpc]
      [ 9839.008069]  [<ffffffffa0341b40>] ? nfs4_xdr_enc_open_noattr+0x130/0x130 [nfsv4]
      [ 9839.008069]  [<ffffffffa03419a5>] encode_open+0x2d5/0x340 [nfsv4]
      [ 9839.008069]  [<ffffffffa0341b40>] ? nfs4_xdr_enc_open_noattr+0x130/0x130 [nfsv4]
      [ 9839.008069]  [<ffffffffa011ab89>] ? xdr_encode_opaque+0x19/0x20 [sunrpc]
      [ 9839.008069]  [<ffffffffa0339cfb>] ? encode_string+0x2b/0x40 [nfsv4]
      [ 9839.008069]  [<ffffffffa0341bf3>] nfs4_xdr_enc_open+0xb3/0x140 [nfsv4]
      [ 9839.008069]  [<ffffffffa0110a4c>] rpcauth_wrap_req+0xac/0xf0 [sunrpc]
      [ 9839.008069]  [<ffffffffa01017db>] call_transmit+0x18b/0x2d0 [sunrpc]
      [ 9839.008069]  [<ffffffffa0101650>] ? call_decode+0x860/0x860 [sunrpc]
      [ 9839.008069]  [<ffffffffa0101650>] ? call_decode+0x860/0x860 [sunrpc]
      [ 9839.008069]  [<ffffffffa010caa0>] __rpc_execute+0x90/0x460 [sunrpc]
      [ 9839.008069]  [<ffffffffa010ce85>] rpc_async_schedule+0x15/0x20 [sunrpc]
      [ 9839.008069]  [<ffffffff810b452b>] process_one_work+0x1bb/0x410
      [ 9839.008069]  [<ffffffff810b47d3>] worker_thread+0x53/0x470
      [ 9839.008069]  [<ffffffff810b4780>] ? process_one_work+0x410/0x410
      [ 9839.008069]  [<ffffffff810b4780>] ? process_one_work+0x410/0x410
      [ 9839.008069]  [<ffffffff810ba7b8>] kthread+0xd8/0xf0
      [ 9839.008069]  [<ffffffff810ba6e0>] ? kthread_worker_fn+0x180/0x180
      [ 9839.008069]  [<ffffffff81786418>] ret_from_fork+0x58/0x90
      [ 9839.008069]  [<ffffffff810ba6e0>] ? kthread_worker_fn+0x180/0x180
      [ 9839.008069] Code: 00 00 48 c7 c7 21 fa 37 a0 e8 94 1c d6 e0 c6 05 d2 17 05 00 01 8b 03 eb d7 66 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 89 e5 <0f> 0b 0f 1f 44 00 00 66 66 66 66 90 55 48 89 e5 41 54 53 89 f3
      [ 9839.008069] RIP  [<ffffffffa0339cc9>] reserve_space.part.73+0x9/0x10 [nfsv4]
      [ 9839.008069]  RSP <ffff88003667ba58>
      [ 9839.071114] ---[ end trace cc14c03adb522e94 ]---
      Signed-off-by: NKinglong Mee <kinglongmee@gmail.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      a49c2691
    • J
      nfs: plug memory leak when ->prepare_layoutcommit fails · 3471648a
      Jeff Layton 提交于
      "data" is currently leaked when the prepare_layoutcommit operation
      returns an error. Put the cred before taking the spinlock in that
      case, take the lock and then goto out_unlock which will drop the
      lock and then free "data".
      Signed-off-by: NJeff Layton <jeff.layton@primarydata.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      3471648a
    • C
      KEYS: ensure we free the assoc array edit if edit is valid · ca4da5dd
      Colin Ian King 提交于
      __key_link_end is not freeing the associated array edit structure
      and this leads to a 512 byte memory leak each time an identical
      existing key is added with add_key().
      
      The reason the add_key() system call returns okay is that
      key_create_or_update() calls __key_link_begin() before checking to see
      whether it can update a key directly rather than adding/replacing - which
      it turns out it can.  Thus __key_link() is not called through
      __key_instantiate_and_link() and __key_link_end() must cancel the edit.
      
      CVE-2015-1333
      Signed-off-by: NColin Ian King <colin.king@canonical.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      ca4da5dd
    • T
      f580dd04
    • A
      arm64/efi: map the entire UEFI vendor string before reading it · f91b1fea
      Ard Biesheuvel 提交于
      At boot, the UTF-16 UEFI vendor string is copied from the system
      table into a char array with a size of 100 bytes. However, this
      size of 100 bytes is also used for memremapping() the source,
      which may not be sufficient if the vendor string exceeds 50
      UTF-16 characters, and the placement of the vendor string inside
      a 4 KB page happens to leave the end unmapped.
      
      So use the correct '100 * sizeof(efi_char16_t)' for the size of
      the mapping.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Fixes: f84d0275 ("arm64: add EFI runtime services")
      Cc: <stable@vger.kernel.org> # 3.16+
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      f91b1fea
  6. 27 7月, 2015 14 次提交
  7. 26 7月, 2015 7 次提交
    • T
      x86/mm/pat: Revert 'Adjust default caching mode translation tables' · 1a4e8795
      Thomas Gleixner 提交于
      Toshi explains:
      
      "No, the default values need to be set to the fallback types,
       i.e. minimal supported mode.  For WC and WT, UC is the fallback type.
      
       When PAT is disabled, pat_init() does update the tables below to
       enable WT per the default BIOS setup.  However, when PAT is enabled,
       but CPU has PAT -errata, WT falls back to UC per the default values."
      
      Revert: ca1fec58 'x86/mm/pat: Adjust default caching mode translation tables'
      Requested-by: NToshi Kani <toshi.kani@hp.com>
      Cc: Jan Beulich <jbeulich@suse.de>
      Link: http://lkml.kernel.org/r/1437577776.3214.252.camel@hp.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      1a4e8795
    • M
      perf/x86/intel/cqm: Return cached counter value from IRQ context · 2c534c0d
      Matt Fleming 提交于
      Peter reported the following potential crash which I was able to
      reproduce with his test program,
      
      [  148.765788] ------------[ cut here ]------------
      [  148.765796] WARNING: CPU: 34 PID: 2840 at kernel/smp.c:417 smp_call_function_many+0xb6/0x260()
      [  148.765797] Modules linked in:
      [  148.765800] CPU: 34 PID: 2840 Comm: perf Not tainted 4.2.0-rc1+ #4
      [  148.765803]  ffffffff81cdc398 ffff88085f105950 ffffffff818bdfd5 0000000000000007
      [  148.765805]  0000000000000000 ffff88085f105990 ffffffff810e413a 0000000000000000
      [  148.765807]  ffffffff82301080 0000000000000022 ffffffff8107f640 ffffffff8107f640
      [  148.765809] Call Trace:
      [  148.765810]  <NMI>  [<ffffffff818bdfd5>] dump_stack+0x45/0x57
      [  148.765818]  [<ffffffff810e413a>] warn_slowpath_common+0x8a/0xc0
      [  148.765822]  [<ffffffff8107f640>] ? intel_cqm_stable+0x60/0x60
      [  148.765824]  [<ffffffff8107f640>] ? intel_cqm_stable+0x60/0x60
      [  148.765825]  [<ffffffff810e422a>] warn_slowpath_null+0x1a/0x20
      [  148.765827]  [<ffffffff811613f6>] smp_call_function_many+0xb6/0x260
      [  148.765829]  [<ffffffff8107f640>] ? intel_cqm_stable+0x60/0x60
      [  148.765831]  [<ffffffff81161748>] on_each_cpu_mask+0x28/0x60
      [  148.765832]  [<ffffffff8107f6ef>] intel_cqm_event_count+0x7f/0xe0
      [  148.765836]  [<ffffffff811cdd35>] perf_output_read+0x2a5/0x400
      [  148.765839]  [<ffffffff811d2e5a>] perf_output_sample+0x31a/0x590
      [  148.765840]  [<ffffffff811d333d>] ? perf_prepare_sample+0x26d/0x380
      [  148.765841]  [<ffffffff811d3497>] perf_event_output+0x47/0x60
      [  148.765843]  [<ffffffff811d36c5>] __perf_event_overflow+0x215/0x240
      [  148.765844]  [<ffffffff811d4124>] perf_event_overflow+0x14/0x20
      [  148.765847]  [<ffffffff8107e7f4>] intel_pmu_handle_irq+0x1d4/0x440
      [  148.765849]  [<ffffffff811d07a6>] ? __perf_event_task_sched_in+0x36/0xa0
      [  148.765853]  [<ffffffff81219bad>] ? vunmap_page_range+0x19d/0x2f0
      [  148.765854]  [<ffffffff81219d11>] ? unmap_kernel_range_noflush+0x11/0x20
      [  148.765859]  [<ffffffff814ce6fe>] ? ghes_copy_tofrom_phys+0x11e/0x2a0
      [  148.765863]  [<ffffffff8109e5db>] ? native_apic_msr_write+0x2b/0x30
      [  148.765865]  [<ffffffff8109e44d>] ? x2apic_send_IPI_self+0x1d/0x20
      [  148.765869]  [<ffffffff81065135>] ? arch_irq_work_raise+0x35/0x40
      [  148.765872]  [<ffffffff811c8d86>] ? irq_work_queue+0x66/0x80
      [  148.765875]  [<ffffffff81075306>] perf_event_nmi_handler+0x26/0x40
      [  148.765877]  [<ffffffff81063ed9>] nmi_handle+0x79/0x100
      [  148.765879]  [<ffffffff81064422>] default_do_nmi+0x42/0x100
      [  148.765880]  [<ffffffff81064563>] do_nmi+0x83/0xb0
      [  148.765884]  [<ffffffff818c7c0f>] end_repeat_nmi+0x1e/0x2e
      [  148.765886]  [<ffffffff811d07a6>] ? __perf_event_task_sched_in+0x36/0xa0
      [  148.765888]  [<ffffffff811d07a6>] ? __perf_event_task_sched_in+0x36/0xa0
      [  148.765890]  [<ffffffff811d07a6>] ? __perf_event_task_sched_in+0x36/0xa0
      [  148.765891]  <<EOE>>  [<ffffffff8110ab66>] finish_task_switch+0x156/0x210
      [  148.765898]  [<ffffffff818c1671>] __schedule+0x341/0x920
      [  148.765899]  [<ffffffff818c1c87>] schedule+0x37/0x80
      [  148.765903]  [<ffffffff810ae1af>] ? do_page_fault+0x2f/0x80
      [  148.765905]  [<ffffffff818c1f4a>] schedule_user+0x1a/0x50
      [  148.765907]  [<ffffffff818c666c>] retint_careful+0x14/0x32
      [  148.765908] ---[ end trace e33ff2be78e14901 ]---
      
      The CQM task events are not safe to be called from within interrupt
      context because they require performing an IPI to read the counter value
      on all sockets. And performing IPIs from within IRQ context is a
      "no-no".
      
      Make do with the last read counter value currently event in
      event->count when we're invoked in this context.
      Reported-by: NPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vikas Shivappa <vikas.shivappa@intel.com>
      Cc: Kanaka Juvva <kanaka.d.juvva@intel.com>
      Cc: Will Auld <will.auld@intel.com>
      Cc: <stable@vger.kernel.org>
      Link: http://lkml.kernel.org/r/1437490509-15373-1-git-send-email-matt@codeblueprint.co.ukSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      2c534c0d
    • L
      Merge tag 'usb-4.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb · 26ae19a3
      Linus Torvalds 提交于
      Pull USB fixes from Greg KH:
       "Here's a few USB and PHY fixes for 4.2-rc4.
      
        Nothing major, the shortlog has the full details.
      
        All of these have been in linux-next successfully"
      
      * tag 'usb-4.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (21 commits)
        USB: OHCI: fix bad #define in ohci-tmio.c
        cdc-acm: Destroy acm_minors IDR on module exit
        usb-storage: Add ignore-device quirk for gm12u320 based usb mini projectors
        usb-storage: ignore ZTE MF 823 card reader in mode 0x1225
        USB: OHCI: Fix race between ED unlink and URB submission
        usb: core: lpm: set lpm_capable for root hub device
        xhci: do not report PLC when link is in internal resume state
        xhci: prevent bus_suspend if SS port resuming in phase 1
        xhci: report U3 when link is in resume state
        xhci: Calculate old endpoints correctly on device reset
        usb: xhci: Bugfix for NULL pointer deference in xhci_endpoint_init() function
        xhci: Workaround to get D3 working in Intel xHCI
        xhci: call BIOS workaround to enable runtime suspend on Intel Braswell
        usb: dwc3: Reset the transfer resource index on SET_INTERFACE
        usb: gadget: udc: core: Fix argument of dma_map_single for IOMMU
        usb: gadget: mv_udc_core: fix phy_regs I/O memory leak
        usb: ulpi: ulpi_init should be executed in subsys_initcall
        phy: berlin-usb: fix divider for BG2
        phy: berlin-usb: fix divider for BG2CD
        phy/pxa: add HAS_IOMEM dependency
        ...
      26ae19a3
    • L
      Merge tag 'tty-4.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty · 82b35f37
      Linus Torvalds 提交于
      Pull tty/serial driver fixes from Greg KH:
       "Here are a number of small serial and tty fixes for reported issues.
      
        All have been in linux-next successfully"
      
      * tag 'tty-4.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
        tty: vt: Fix !TASK_RUNNING diagnostic warning from paste_selection()
        serial: core: Fix crashes while echoing when closing
        m32r: Add ioreadXX/iowriteXX big-endian mmio accessors
        Revert "serial: imx: initialized DMA w/o HW flow enabled"
        sc16is7xx: fix FIFO address of secondary UART
        sc16is7xx: fix Kconfig dependencies
        serial: etraxfs-uart: Fix release etraxfs_uart_ports
        tty/vt: Fix the memory leak in visual_init
        serial: amba-pl011: Fix devm_ioremap_resource return value check
        n_tty: signal and flush atomically
      82b35f37
    • L
      Merge tag 'staging-4.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging · b0de415a
      Linus Torvalds 提交于
      Pull staging driver fixes from Greg KH:
       "Here are a number of iio and staging driver fixes for reported issues
        for 4.2-rc4.
      
        All have been in linux-next for a while with no problems"
      
      * tag 'staging-4.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (34 commits)
        iio:light:stk3310: make endianness independent of host
        iio:light:stk3310: move device register to end of probe
        iio: mma8452: use iio event type IIO_EV_TYPE_MAG
        iio: mcp320x: Fix NULL pointer dereference
        iio: adc: vf610: fix the adc register read fail issue
        iio: mlx96014: Replace offset sign
        iio: magnetometer: mmc35240: fix SET/RESET sequence
        iio: magnetometer: mmc35240: Fix SET/RESET mask
        iio: magnetometer: mmc35240: Fix crash in pm suspend
        iio:magnetometer:bmc150_magn: output intended variable
        iio:magnetometer:bmc150_magn: add regmap dependency
        staging: vt6656: check ieee80211_bss_conf bssid not NULL
        staging: vt6655: check ieee80211_bss_conf bssid not NULL
        iio: tmp006: Check channel info on write
        iio: sx9500: Add missing init in sx9500_buffer_pre{en,dis}able()
        iio:light:ltr501: fix regmap dependency
        iio:light:ltr501: fix variable in ltr501_init
        iio: sx9500: fix bug in compensation code
        iio: sx9500: rework error handling of raw readings
        iio: magnetometer: mmc35240: fix available sampling frequencies
        ...
      b0de415a
    • L
      Merge tag 'char-misc-4.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc · e433b656
      Linus Torvalds 提交于
      Pull char/misc driver fixes from Greg KH:
       "Here are some char and misc driver fixes for reported issues.
      
        One parport patch is reverted as it was incorrect, thanks to testing
        by the 0-day bot"
      
      * tag 'char-misc-4.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
        parport: Revert "parport: fix memory leak"
        mei: prevent unloading mei hw modules while the device is opened.
        misc: mic: scif bug fix for vmalloc_to_page crash
        parport: fix freeing freed memory
        parport: fix memory leak
        parport: fix error handling
      e433b656
    • S
      parport: Revert "parport: fix memory leak" · 4e5a74f1
      Sudip Mukherjee 提交于
      This reverts commit 23c40591 ("parport: fix memory leak")
      
      par_dev->state was already being removed in parport_unregister_device().
      Reported-by: NYing Huang <ying.huang@intel.com>
      Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e5a74f1