linux-stable.git/drivers/char, branch v4.1.38

tpm xen: Remove bogus tpm_chip_unregister

2017-01-13T01:56:54+00:00

[ Upstream commit 1f0f30e404b3d8f4597a2d9b77fba55452f8fd0e ]

tpm_chip_unregister can only be called after tpm_chip_register.
devm manages the allocation so no unwind is needed here.

Cc: stable@vger.kernel.org
Fixes: afb5abc262e96 ("tpm: two-phase chip management functions")
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Sasha Levin

virtio: console: Unlock vqs while freeing buffers

2016-11-26T03:57:03+00:00

[ Upstream commit 34563769e438d2881f62cf4d9badc4e589ac0ec0 ]

Commit c6017e793b93 ("virtio: console: add locks around buffer removal
in port unplug path") added locking around the freeing of buffers in the
vq. However, when free_buf() is called with can_sleep = true and rproc
is enabled, it calls dma_free_coherent() directly, requiring interrupts
to be enabled. Currently a WARNING is triggered due to the spin locking
around free_buf, with a call stack like this:

WARNING: CPU: 3 PID: 121 at ./include/linux/dma-mapping.h:433
free_buf+0x1a8/0x288
Call Trace:
[<8040c538>] show_stack+0x74/0xc0
[<80757240>] dump_stack+0xd0/0x110
[<80430d98>] __warn+0xfc/0x130
[<80430ee0>] warn_slowpath_null+0x2c/0x3c
[<807e7c6c>] free_buf+0x1a8/0x288
[<807ea590>] remove_port_data+0x50/0xac
[<807ea6a0>] unplug_port+0xb4/0x1bc
[<807ea858>] virtcons_remove+0xb0/0xfc
[<807b6734>] virtio_dev_remove+0x58/0xc0
[<807f918c>] __device_release_driver+0xac/0x134
[<807f924c>] device_release_driver+0x38/0x50
[<807f7edc>] bus_remove_device+0xfc/0x130
[<807f4b74>] device_del+0x17c/0x21c
[<807f4c38>] device_unregister+0x24/0x38
[<807b6b50>] unregister_virtio_device+0x28/0x44

Fix this by restructuring the loops to allow the locks to only be taken
where it is necessary to protect the vqs, and release it while the
buffer is being freed.

Fixes: c6017e793b93 ("virtio: console: add locks around buffer removal in port unplug path")
Cc: stable@vger.kernel.org
Signed-off-by: Matt Redfearn 
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Sasha Levin

tpm: fix the cleanup of struct tpm_chip

2016-07-11T03:06:55+00:00

[ Upstream commit 8e0ee3c9faed7ca68807ea45141775856c438ac0 ]

If the initialization fails before tpm_chip_register(), put_device()
will be not called, which causes release callback not to be called.
This patch fixes the issue by adding put_device() to devres list of
the parent device.

Fixes: 313d21eeab ("tpm: device class for tpm")
Signed-off-by: Jarkko Sakkinen 
cc: stable@vger.kernel.org
Reviewed-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin

ipmi: Remove smi_msg from waiting_rcv_msgs list before handle_one_recv_msg()

2016-07-11T00:19:55+00:00

[ Upstream commit ae4ea9a2460c7fee2ae8feeb4dfe96f5f6c3e562 ]

Commit 7ea0ed2b5be8 ("ipmi: Make the message handler easier to use for
SMI interfaces") changed handle_new_recv_msgs() to call handle_one_recv_msg()
for a smi_msg while the smi_msg is still connected to waiting_rcv_msgs list.
That could lead to following list corruption problems:

1) low-level function treats smi_msg as not connected to list

  handle_one_recv_msg() could end up calling smi_send(), which
  assumes the msg is not connected to list.

  For example, the following sequence could corrupt list by
  doing list_add_tail() for the entry still connected to other list.

    handle_new_recv_msgs()
      msg = list_entry(waiting_rcv_msgs)
      handle_one_recv_msg(msg)
        handle_ipmb_get_msg_cmd(msg)
          smi_send(msg)
            spin_lock(xmit_msgs_lock)
            list_add_tail(msg)
            spin_unlock(xmit_msgs_lock)

2) race between multiple handle_new_recv_msgs() instances

  handle_new_recv_msgs() once releases waiting_rcv_msgs_lock before calling
  handle_one_recv_msg() then retakes the lock and list_del() it.

  If others call handle_new_recv_msgs() during the window shown below
  list_del() will be done twice for the same smi_msg.

  handle_new_recv_msgs()
    spin_lock(waiting_rcv_msgs_lock)
    msg = list_entry(waiting_rcv_msgs)
    spin_unlock(waiting_rcv_msgs_lock)
  |
  | handle_one_recv_msg(msg)
  |
    spin_lock(waiting_rcv_msgs_lock)
    list_del(msg)
    spin_unlock(waiting_rcv_msgs_lock)

Fixes: 7ea0ed2b5be8 ("ipmi: Make the message handler easier to use for SMI interfaces")
Signed-off-by: Jun'ichi Nomura 
[Added a comment to describe why this works.]
Signed-off-by: Corey Minyard 
Cc: stable@vger.kernel.org # 3.19
Tested-by: Ye Feng 

Signed-off-by: Sasha Levin

tpm_crb: tpm2_shutdown() must be called before tpm_chip_unregister()

2016-04-18T12:50:37+00:00

[ Upstream commit 99cda8cb4639de81cde785b5bab9bc52e916e594 ]

Wrong call order.

Reported-by: Jason Gunthorpe 
Fixes: 74d6b3ceaa17
Signed-off-by: Jarkko Sakkinen 
cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

ipmi: move timer init to before irq is setup

2016-01-31T19:23:31+00:00

commit 27f972d3e00b50639deb4cc1392afaeb08d3cecc upstream.

We encountered a panic on boot in ipmi_si on a dell per320 due to an
uninitialized timer as follows.

static int smi_start_processing(void       *send_info,
                                ipmi_smi_t intf)
{
        /* Try to claim any interrupts. */
        if (new_smi->irq_setup)
                new_smi->irq_setup(new_smi);

 --> IRQ arrives here and irq handler tries to modify uninitialized timer

    which triggers BUG_ON(!timer->function) in __mod_timer().

 Call Trace:
   
   [] start_new_msg+0x47/0x80 [ipmi_si]
   [] start_check_enables+0x4e/0x60 [ipmi_si]
   [] smi_event_handler+0x1e8/0x640 [ipmi_si]
   [] ? __rcu_process_callbacks+0x54/0x350
   [] si_irq_handler+0x3c/0x60 [ipmi_si]
   [] handle_IRQ_event+0x60/0x170
   [] handle_edge_irq+0xde/0x180
   [] handle_irq+0x49/0xa0
   [] do_IRQ+0x6c/0xf0
   [] ret_from_intr+0x0/0x11

        /* Set up the timer that drives the interface. */
        setup_timer(&new_smi->si_timer, smi_timeout, (long)new_smi);

The following patch fixes the problem.

To: Openipmi-developer@lists.sourceforge.net
To: Corey Minyard 
CC: linux-kernel@vger.kernel.org

Signed-off-by: Jan Stancek 
Signed-off-by: Tony Camuso 
Signed-off-by: Corey Minyard 
Signed-off-by: Greg Kroah-Hartman

ipmi: Start the timer and thread on internal msgs

2016-01-31T19:23:31+00:00

commit 0cfec916e86d881e209de4b4ae9959a6271e6660 upstream.

The timer and thread were not being started for internal messages,
so in interrupt mode if something hung the timer would never go
off and clean things up.  Factor out the internal message sending
and start the timer for those messages, too.

Signed-off-by: Corey Minyard 
Tested-by: Gouji, Masayuki 
Signed-off-by: Greg Kroah-Hartman

tpm, tpm_tis: fix tpm_tis ACPI detection issue with TPM 2.0

2016-01-23T04:54:09+00:00

commit 399235dc6e95400a1322a9999e92073bc572f0c8 upstream.

Both for FIFO and CRB interface TCG has decided to use the same HID
MSFT0101. They can be differentiated by looking at the start method from
TPM2 ACPI table. This patches makes necessary fixes to tpm_tis and
tpm_crb modules in order to correctly detect, which module should be
used.

For MSFT0101 we must use struct acpi_driver because struct pnp_driver
has a 7 character limitation.

It turned out that the root cause in b371616b8 was not correct for
https://bugzilla.kernel.org/show_bug.cgi?id=98181.

v2:

* One fixup was missing from v1: is_tpm2_fifo -> is_fifo

v3:

* Use pnp_driver for existing HIDs and acpi_driver only for MSFT0101 in
  order ensure backwards compatibility.

v4:

* Check for FIFO before doing *anything* in crb_acpi_add().
* There was return immediately after acpi_bus_unregister_driver() in
  cleanup_tis(). This caused pnp_unregister_driver() not to be called.

Reported-by: Michael Saunders 
Reported-by: Michael Marley 
Reported-by: Jethro Beekman 
Reported-by: Matthew Garrett 
Signed-off-by: Jarkko Sakkinen 
Tested-by: Michael Marley 
Tested-by: Mimi Zohar  (on TPM 1.2)
Reviewed-by: Peter Huewe 
Signed-off-by: Peter Huewe 
Signed-off-by: Greg Kroah-Hartman

hwmon: (dell-smm) Blacklist Dell Studio XPS 8100

2015-08-17T03:52:21+00:00

commit a4b45b25f18d1e798965efec429ba5fc01b9f0b6 upstream.

CPU fan speed going up and down on Dell Studio XPS 8100 for
unknown reasons. Without further debugging on the affected
machine, it is not possible to find the problem.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=100121
Signed-off-by: Pali Rohár 
Tested-by: Jan C Peters 
[groeck: cleaned up description, comments]
Signed-off-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

hwrng: core - correct error check of kthread_run call

2015-08-17T03:52:19+00:00

commit 17fb874dee093139923af8ed36061faa92cc8e79 upstream.

The kthread_run() function can return two different error values
but the hwrng core only checks for -ENOMEM. If the other error
value -EINTR is returned it is assigned to hwrng_fill and later
used on a kthread_stop() call which naturally crashes.

Signed-off-by: Martin Schwidefsky 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman