Skip to content

L
linux
Switch branch/tag
  1. 27 Apr, 2015 22 commits
  3. 22 Apr, 2015 18 commits
    • Mark Brown's avatar
      video: vgacon: Don't build on arm64 · 1d458a6c
      Mark Brown authored 
      commit ee23794b upstream.

arm64 is unlikely to have a VGA console and does not export screen_info
causing build failures if the driver is build, for example in all*config.
Add a dependency on !ARM64 to prevent this.

This list is getting quite long, it may be easier to depend on a symbol
which architectures that do support the driver can select.
Signed-off-by: default avatarMark Brown <broonie@linaro.org>
[tomi.valkeinen@ti.com: moved && to first modified line]
Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      1d458a6c
    • Chen Gang's avatar
      [media] drivers: media: usb: b2c2: use usb_*_coherent() instead of... · 147ff1a3
      Chen Gang authored 
      [media] drivers: media: usb: b2c2: use usb_*_coherent() instead of pci_*_consistent() in flexcop-usb.c

commit 6c7e3469 upstream.

Some architectures do not support PCI, but still support USB, so need
let our usb driver try to use usb_* instead of pci_* to support these
architectures, or can not pass compiling.
The related error (with allmodconfig for arc):
    CC [M]  drivers/media/usb/b2c2/flexcop-usb.o
  drivers/media/usb/b2c2/flexcop-usb.c: In function ‘flexcop_usb_transfer_exit’:
  drivers/media/usb/b2c2/flexcop-usb.c:393: error: implicit declaration of function ‘pci_free_consistent’
  drivers/media/usb/b2c2/flexcop-usb.c: In function ‘flexcop_usb_transfer_init’:
  drivers/media/usb/b2c2/flexcop-usb.c:410: error: implicit declaration of function ‘pci_alloc_consistent’
Signed-off-by: default avatarChen Gang <gang.chen@asianux.com>
Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      147ff1a3
    • Majd Dibbiny's avatar
      IB/mlx4: Saturate RoCE port PMA counters in case of overflow · c2b885ae
      Majd Dibbiny authored 
      commit 61a3855b upstream.

For RoCE ports, we set the u32 PMA values based on u64 HCA counters. In case of
overflow, according to the IB spec, we have to saturate a counter to its
max value, do that.

Fixes: c3779134 ('IB/mlx4: Support PMA counters for IBoE')
Signed-off-by: default avatarMajd Dibbiny <majd@mellanox.com>
Signed-off-by: default avatarEran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: default avatarHadar Hen Zion <hadarh@mellanox.com>
Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      c2b885ae
    • Sasha Levin's avatar
      net: llc: use correct size for sysctl timeout entries · 553dd569
      Sasha Levin authored 
      commit 6b8d9117 upstream.

The timeout entries are sizeof(int) rather than sizeof(long), which
means that when they were getting read we'd also leak kernel memory
to userspace along with the timeout values.
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      553dd569
    • Sasha Levin's avatar
      net: rds: use correct size for max unacked packets and bytes · b4482b53
      Sasha Levin authored 
      commit db27ebb1 upstream.

Max unacked packets/bytes is an int while sizeof(long) was used in the
sysctl table.

This means that when they were getting read we'd also leak kernel memory
to userspace along with the timeout values.
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      b4482b53
    • Marek Szyprowski's avatar
      media: s5p-mfc: fix mmap support for 64bit arch · 95ed43f1
      Marek Szyprowski authored 
      commit 05b676ab upstream.

TASK_SIZE is depends on the systems architecture (32 or 64 bits) and it
should not be used for defining offset boundary for mmaping buffers for
CAPTURE and OUTPUT queues. This patch fixes support for MMAP calls on
the CAPTURE queue on 64bit architectures (like ARM64).
Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: default avatarKamil Debski <k.debski@samsung.com>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      95ed43f1
    • Hans Verkuil's avatar
      sh_veu: v4l2_dev wasn't set · 145fc8e8
      Hans Verkuil authored 
      commit ab312030 upstream.

The v4l2_dev field of struct video_device must be set correctly.
This was never done for this driver, so no video nodes were created
anymore.
Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      145fc8e8
    • Mike Christie's avatar
      iscsi target: fix oops when adding reject pdu · e0e2e64b
      Mike Christie authored 
      commit b815fc12 upstream.

This fixes a oops due to a double list add when adding a reject PDU for
iscsit_allocate_iovecs allocation failures. The cmd has already been
added to the conn_cmd_list in iscsit_setup_scsi_cmd, so this has us call
iscsit_reject_cmd.

Note that for ERL0 the reject PDU is not actually sent, so this patch
is not completely tested. Just verified we do not oops. The problem is the
add reject functions return -1 which is returned all the way up to
iscsi_target_rx_thread which for ERL0 will drop the connection.
Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      e0e2e64b
    • Al Viro's avatar
      ioctx_alloc(): fix vma (and file) leak on failure · f9324979
      Al Viro authored 
      commit deeb8525 upstream.

If we fail past the aio_setup_ring(), we need to destroy the
mapping.  We don't need to care about anybody having found ctx,
or added requests to it, since the last failure exit is exactly
the failure to make ctx visible to lookups.

Reproducer (based on one by Joe Mario <jmario@redhat.com>):

void count(char *p)
{
	char s[80];
	printf("%s: ", p);
	fflush(stdout);
	sprintf(s, "/bin/cat /proc/%d/maps|/bin/fgrep -c '/[aio] (deleted)'", getpid());
	system(s);
}

int main()
{
	io_context_t *ctx;
	int created, limit, i, destroyed;
	FILE *f;

	count("before");
	if ((f = fopen("/proc/sys/fs/aio-max-nr", "r")) == NULL)
		perror("opening aio-max-nr");
	else if (fscanf(f, "%d", &limit) != 1)
		fprintf(stderr, "can't parse aio-max-nr\n");
	else if ((ctx = calloc(limit, sizeof(io_context_t))) == NULL)
		perror("allocating aio_context_t array");
	else {
		for (i = 0, created = 0; i < limit; i++) {
			if (io_setup(1000, ctx + created) == 0)
				created++;
		}
		for (i = 0, destroyed = 0; i < created; i++)
			if (io_destroy(ctx[i]) == 0)
				destroyed++;
		printf("created %d, failed %d, destroyed %d\n",
			created, limit - created, destroyed);
		count("after");
	}
}
Found-by: default avatarJoe Mario <jmario@redhat.com>
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      f9324979
    • Al Viro's avatar
      ocfs2: _really_ sync the right range · 6b71b6af
      Al Viro authored 
      commit 64b4e252 upstream.

"ocfs2 syncs the wrong range" had been broken; prior to it the
code was doing the wrong thing in case of O_APPEND, all right,
but _after_ it we were syncing the wrong range in 100% cases.
*ppos, aka iocb->ki_pos is incremented prior to that point,
so we are always doing sync on the area _after_ the one we'd
written to.

Spotted by Joseph Qi <joseph.qi@huawei.com> back in January;
unfortunately, I'd missed his mail back then ;-/
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      6b71b6af
    • John Soni Jose's avatar
      be2iscsi: Fix kernel panic when device initialization fails · b76a0413
      John Soni Jose authored 
      commit 2e7cee02 upstream.

Kernel panic was happening as iscsi_host_remove() was called on
a host which was not yet added.
Signed-off-by: default avatarJohn Soni Jose <sony.john-n@emulex.com>
Reviewed-by: default avatarMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      b76a0413
    • David Disseldorp's avatar
      cifs: fix use-after-free bug in find_writable_file · 175bf82c
      David Disseldorp authored 
      commit e1e9bda2 upstream.

Under intermittent network outages, find_writable_file() is susceptible
to the following race condition, which results in a user-after-free in
the cifs_writepages code-path:

Thread 1                                        Thread 2
========                                        ========

inv_file = NULL
refind = 0
spin_lock(&cifs_file_list_lock)

// invalidHandle found on openFileList

inv_file = open_file
// inv_file->count currently 1

cifsFileInfo_get(inv_file)
// inv_file->count = 2

spin_unlock(&cifs_file_list_lock);

cifs_reopen_file()                            cifs_close()
// fails (rc != 0)                            ->cifsFileInfo_put()
                                       spin_lock(&cifs_file_list_lock)
                                       // inv_file->count = 1
                                       spin_unlock(&cifs_file_list_lock)

spin_lock(&cifs_file_list_lock);
list_move_tail(&inv_file->flist,
      &cifs_inode->openFileList);
spin_unlock(&cifs_file_list_lock);

cifsFileInfo_put(inv_file);
->spin_lock(&cifs_file_list_lock)

  // inv_file->count = 0
  list_del(&cifs_file->flist);
  // cleanup!!
  kfree(cifs_file);

  spin_unlock(&cifs_file_list_lock);

spin_lock(&cifs_file_list_lock);
++refind;
// refind = 1
goto refind_writable;

At this point we loop back through with an invalid inv_file pointer
and a refind value of 1. On second pass, inv_file is not overwritten on
openFileList traversal, and is subsequently dereferenced.
Signed-off-by: default avatarDavid Disseldorp <ddiss@suse.de>
Reviewed-by: default avatarJeff Layton <jlayton@samba.org>
Signed-off-by: default avatarSteve French <smfrench@gmail.com>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      175bf82c
    • Peter Hurley's avatar
      n_tty: Fix read buffer overwrite when no newline · ac02633d
      Peter Hurley authored 
      commit fb5ef9e7 upstream.

In canon mode, the read buffer head will advance over the buffer tail
if the input > 4095 bytes without receiving a line termination char.

Discard additional input until a line termination is received.
Before evaluating for overflow, the 'room' value is normalized for
I_PARMRK and 1 byte is reserved for line termination (even in !icanon
mode, in case the mode is switched). The following table shows the
transform:

 actual buffer |  'room' value before overflow calc
  space avail  |    !I_PARMRK    |    I_PARMRK
 --------------------------------------------------
      0        |       -1        |       -1
      1        |        0        |        0
      2        |        1        |        0
      3        |        2        |        0
      4+       |        3        |        1

When !icanon or when icanon and the read buffer contains newlines,
normalized 'room' values of -1 and 0 are clamped to 0, and
'overflow' is 0, so read_head is not adjusted and the input i/o loop
exits (setting no_room if called from flush_to_ldisc()). No input
is discarded since the reader does have input available to read
which ensures forward progress.

When icanon and the read buffer does not contain newlines and the
normalized 'room' value is 0, then overflow and room are reset to 1,
so that the i/o loop will process the next input char normally
(except for parity errors which are ignored). Thus, erasures, signalling
chars, 7-bit mode, etc. will continue to be handled properly.

If the input char processed was not a line termination char, then
the canon_head index will not have advanced, so the normalized 'room'
value will now be -1 and 'overflow' will be set, which indicates the
read_head can safely be reset, effectively erasing the last char
processed.

If the input char processed was a line termination, then the
canon_head index will have advanced, so 'overflow' is cleared to 0,
the read_head is not reset, and 'room' is cleared to 0, which exits
the i/o loop (because the reader now have input available to read
which ensures forward progress).

Note that it is possible for a line termination to be received, and
for the reader to copy the line to the user buffer before the
input i/o loop is ready to process the next input char. This is
why the i/o loop recomputes the room/overflow state with every
input char while handling overflow.

Finally, if the input data was processed without receiving
a line termination (so that overflow is still set), the pty
driver must receive a write wakeup. A pty writer may be waiting
to write more data in n_tty_write() but without unthrottling
here that wakeup will not arrive, and forward progress will halt.
(Normally, the pty writer is woken when the reader reads data out
of the buffer and more space become available).
Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
(backported from commit fb5ef9e7)
Signed-off-by: default avatarJoseph Salisbury <joseph.salisbury@canonical.com>
      ac02633d
    • Stefan Agner's avatar
      tty: serial: fsl_lpuart: clear receive flag on FIFO flush · dabdec3b
      Stefan Agner authored 
      commit 8e4934c6 upstream.

When the receiver was enabled during startup, a character could
have been in the FIFO when the UART get initially used. The
driver configures the (receive) watermark level, and flushes the
FIFO. However, the receive flag (RDRF) could still be set at that
stage (as mentioned in the register description of UARTx_RWFIFO).
This leads to an interrupt which won't be handled properly in
interrupt mode: The receive interrupt function lpuart_rxint checks
the FIFO count, which is 0 at that point (due to the flush
during initialization). The problem does not manifest when using
DMA to receive characters.

Fix this situation by explicitly read the status register, which
leads to clearing of the RDRF flag. Due to the flush just after
the status flag read, a explicit data read is not to required.
Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      dabdec3b
    • Lu Baolu's avatar
      usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers · 0bd26503
      Lu Baolu authored 
      commit 227a4fd8 upstream.

When a device with an isochronous endpoint is plugged into the Intel
xHCI host controller, and the driver submits multiple frames per URB,
the xHCI driver will set the Block Event Interrupt (BEI) flag on all
but the last TD for the URB. This causes the host controller to place
an event on the event ring, but not send an interrupt. When the last
TD for the URB completes, BEI is cleared, and we get an interrupt for
the whole URB.

However, under Intel xHCI host controllers, if the event ring is full
of events from transfers with BEI set,  an "Event Ring is Full" event
will be posted to the last entry of the event ring,  but no interrupt
is generated. Host will cease all transfer and command executions and
wait until software completes handling the pending events in the event
ring.  That means xHC stops, but event of "event ring is full" is not
notified. As the result, the xHC looks like dead to user.

This patch is to apply XHCI_AVOID_BEI quirk to Intel xHC devices. And
it should be backported to kernels as old as 3.0, that contains the
commit 69e848c2 ("Intel xhci: Support EHCI/xHCI port switching.").
Signed-off-by: default avatarLu Baolu <baolu.lu@linux.intel.com>
Tested-by: default avatarAlistair Grant <akgrant0710@gmail.com>
Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      0bd26503
    • Lu Baolu's avatar
      usb: xhci: handle Config Error Change (CEC) in xhci driver · 55d572b9
      Lu Baolu authored 
      commit 9425183d upstream.

Linux xHCI driver doesn't report and handle port cofig error change.
If Port Configure Error for root hub port occurs, CEC bit in PORTSC
would be set by xHC and remains 1. This happends when the root port
fails to configure its link partner, e.g. the port fails to exchange
port capabilities information using Port Capability LMPs.

Then the Port Status Change Events will be blocked until all status
change bits(CEC is one of the change bits) are cleared('0') (refer to
xHCI spec 4.19.2). Otherwise, the port status change event for this
root port will not be generated anymore, then root port would look
like dead for user and can't be recovered until a Host Controller
Reset(HCRST).

This patch is to check CEC bit in PORTSC in xhci_get_port_status()
and set a Config Error in the return status if CEC is set. This will
cause a ClearPortFeature request, where CEC bit is cleared in
xhci_clear_port_change_bit().

[The commit log is based on initial Marvell patch posted at
http://marc.info/?l=linux-kernel&m=142323612321434&w=2]
Reported-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: default avatarLu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      55d572b9
    • Andreas Werner's avatar
      can: flexcan: Deferred on Regulator return EPROBE_DEFER · a261251a
      Andreas Werner authored 
      commit 555828ef upstream.

Return EPROBE_DEFER if Regulator returns EPROBE_DEFER

If the Flexcan driver is built into kernel and a regulator is used to
enable the CAN transceiver, the Flexcan driver may not use the regulator.

When initializing the Flexcan device with a regulator defined in the device
tree, but not initialized, the regulator subsystem returns EPROBE_DEFER, hence
the Flexcan init fails.

The solution for this is to return EPROBE_DEFER if regulator is not initialized
and wait until the regulator is initialized.
Signed-off-by: default avatarAndreas Werner <kernel@andy89.org>
Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      a261251a
    • Stefan Lippers-Hollmann's avatar
      x86/reboot: Add ASRock Q1900DC-ITX mainboard reboot quirk · fb2f660d
      Stefan Lippers-Hollmann authored 
      commit 80313b30 upstream.

The ASRock Q1900DC-ITX mainboard (Baytrail-D) hangs randomly in
both BIOS and UEFI mode while rebooting unless reboot=pci is
used. Add a quirk to reboot via the pci method.

The problem is very intermittent and hard to debug, it might succeed
rebooting just fine 40 times in a row - but fails half a dozen times
the next day. It seems to be slightly less common in BIOS CSM mode
than native UEFI (with the CSM disabled), but it does happen in either
mode. Since I've started testing this patch in late january, rebooting
has been 100% reliable.

Most of the time it already hangs during POST, but occasionally it
might even make it through the bootloader and the kernel might even
start booting, but then hangs before the mode switch. The same symptoms
occur with grub-efi, gummiboot and grub-pc, just as well as (at least)
kernel 3.16-3.19 and 4.0-rc6 (I haven't tried older kernels than 3.16).
Upgrading to the most current mainboard firmware of the ASRock
Q1900DC-ITX, version 1.20, does not improve the situation.

( Searching the web seems to suggest that other Bay Trail-D mainboards
  might be affected as well. )
--
Signed-off-by: default avatarStefan Lippers-Hollmann <s.l-h@gmx.de>
Cc: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/20150330224427.0fb58e42@mirSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      fb2f660d
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7