* [PATCH 4.8 091/138] Input: i8042 - add XMG C504 to keyboard reset table
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Patrick Scheuring, Dmitry Torokhov
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Patrick Scheuring <patrick.scheuring.dev@gmail.com>
commit da25311c7ca8b0254a686fc0d597075b9aa3b683 upstream.
The Schenker XMG C504 is a rebranded Gigabyte P35 v2 laptop.
Therefore it also needs a keyboard reset to detect the Elantech touchpad.
Otherwise the touchpad appears to be dead.
With this patch the touchpad is detected:
$ dmesg | grep -E "(i8042|Elantech|elantech)"
[ 2.675399] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[ 2.680372] i8042: Attempting to reset device connected to KBD port
[ 2.789037] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 2.791586] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 2.813840] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input4
[ 3.811431] psmouse serio1: elantech: assuming hardware version 4 (with firmware version 0x361f0e)
[ 3.825424] psmouse serio1: elantech: Synaptics capabilities query result 0x00, 0x15, 0x0f.
[ 3.839424] psmouse serio1: elantech: Elan sample query result 03, 58, 74
[ 3.911349] input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input6
Signed-off-by: Patrick Scheuring <patrick.scheuring.dev@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/serio/i8042-x86ia64io.h | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -877,6 +877,13 @@ static const struct dmi_system_id __init
DMI_MATCH(DMI_PRODUCT_NAME, "P34"),
},
},
+ {
+ /* Schenker XMG C504 - Elantech touchpad */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "XMG"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "C504"),
+ },
+ },
{ }
};
^ permalink raw reply
* [PATCH 4.8 087/138] dm raid: fix activation of existing raid4/10 devices
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Heinz Mauelshagen, Mike Snitzer
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heinz Mauelshagen <heinzm@redhat.com>
commit b052b07c39d593c9954a84d5bbe1563999483f38 upstream.
dm-raid 1.9.0 fails to activate existing RAID4/10 devices that have the
old superblock format (which does not have takeover/reshaping support
that was added via commit 33e53f06850f).
Fix validation path for old superblocks by reverting to the old raid4
layout and basing checks on mddev->new_{level,layout,...} members in
super_init_validation().
Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/device-mapper/dm-raid.txt | 1 +
drivers/md/dm-raid.c | 12 +++++++-----
2 files changed, 8 insertions(+), 5 deletions(-)
--- a/Documentation/device-mapper/dm-raid.txt
+++ b/Documentation/device-mapper/dm-raid.txt
@@ -309,3 +309,4 @@ Version History
with a reshape in progress.
1.9.0 Add support for RAID level takeover/reshape/region size
and set size reduction.
+1.9.1 Fix activation of existing RAID 4/10 mapped devices
--- a/drivers/md/dm-raid.c
+++ b/drivers/md/dm-raid.c
@@ -266,7 +266,7 @@ static struct raid_type {
{"raid10_offset", "raid10 offset (striped mirrors)", 0, 2, 10, ALGORITHM_RAID10_OFFSET},
{"raid10_near", "raid10 near (striped mirrors)", 0, 2, 10, ALGORITHM_RAID10_NEAR},
{"raid10", "raid10 (striped mirrors)", 0, 2, 10, ALGORITHM_RAID10_DEFAULT},
- {"raid4", "raid4 (dedicated last parity disk)", 1, 2, 4, ALGORITHM_PARITY_N}, /* raid4 layout = raid5_n */
+ {"raid4", "raid4 (dedicated first parity disk)", 1, 2, 5, ALGORITHM_PARITY_0}, /* raid4 layout = raid5_0 */
{"raid5_n", "raid5 (dedicated last parity disk)", 1, 2, 5, ALGORITHM_PARITY_N},
{"raid5_ls", "raid5 (left symmetric)", 1, 2, 5, ALGORITHM_LEFT_SYMMETRIC},
{"raid5_rs", "raid5 (right symmetric)", 1, 2, 5, ALGORITHM_RIGHT_SYMMETRIC},
@@ -2087,11 +2087,11 @@ static int super_init_validation(struct
/*
* No takeover/reshaping, because we don't have the extended v1.9.0 metadata
*/
- if (le32_to_cpu(sb->level) != mddev->level) {
+ if (le32_to_cpu(sb->level) != mddev->new_level) {
DMERR("Reshaping/takeover raid sets not yet supported. (raid level/stripes/size change)");
return -EINVAL;
}
- if (le32_to_cpu(sb->layout) != mddev->layout) {
+ if (le32_to_cpu(sb->layout) != mddev->new_layout) {
DMERR("Reshaping raid sets not yet supported. (raid layout change)");
DMERR(" 0x%X vs 0x%X", le32_to_cpu(sb->layout), mddev->layout);
DMERR(" Old layout: %s w/ %d copies",
@@ -2102,7 +2102,7 @@ static int super_init_validation(struct
raid10_md_layout_to_copies(mddev->layout));
return -EINVAL;
}
- if (le32_to_cpu(sb->stripe_sectors) != mddev->chunk_sectors) {
+ if (le32_to_cpu(sb->stripe_sectors) != mddev->new_chunk_sectors) {
DMERR("Reshaping raid sets not yet supported. (stripe sectors change)");
return -EINVAL;
}
@@ -2115,6 +2115,8 @@ static int super_init_validation(struct
return -EINVAL;
}
+ DMINFO("Discovered old metadata format; upgrading to extended metadata format");
+
/* Table line is checked vs. authoritative superblock */
rs_set_new(rs);
}
@@ -3647,7 +3649,7 @@ static void raid_resume(struct dm_target
static struct target_type raid_target = {
.name = "raid",
- .version = {1, 9, 0},
+ .version = {1, 9, 1},
.module = THIS_MODULE,
.ctr = raid_ctr,
.dtr = raid_dtr,
^ permalink raw reply
* [PATCH 4.8 089/138] rtl8xxxu: Fix big-endian problem reporting mactime
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jes Sorensen, Kalle Valo
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jes Sorensen <Jes.Sorensen@redhat.com>
commit 8a55698f2f29d227825173420d7b99b9277ca88c upstream.
The full RX descriptor is converted so converting tsfl again would
return it to it's original endian value.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 4 ++--
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -231,7 +231,7 @@ struct rtl8xxxu_rxdesc16 {
u32 pattern1match:1;
u32 pattern0match:1;
#endif
- __le32 tsfl;
+ u32 tsfl;
#if 0
u32 bassn:12;
u32 bavld:1;
@@ -361,7 +361,7 @@ struct rtl8xxxu_rxdesc24 {
u32 ldcp:1;
u32 splcp:1;
#endif
- __le32 tsfl;
+ u32 tsfl;
};
struct rtl8xxxu_txdesc32 {
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -5224,7 +5224,7 @@ int rtl8xxxu_parse_rxdesc16(struct rtl8x
rtl8xxxu_rx_parse_phystats(priv, rx_status, phy_stats,
rx_desc->rxmcs);
- rx_status->mactime = le32_to_cpu(rx_desc->tsfl);
+ rx_status->mactime = rx_desc->tsfl;
rx_status->flag |= RX_FLAG_MACTIME_START;
if (!rx_desc->swdec)
@@ -5294,7 +5294,7 @@ int rtl8xxxu_parse_rxdesc24(struct rtl8x
rtl8xxxu_rx_parse_phystats(priv, rx_status, phy_stats,
rx_desc->rxmcs);
- rx_status->mactime = le32_to_cpu(rx_desc->tsfl);
+ rx_status->mactime = rx_desc->tsfl;
rx_status->flag |= RX_FLAG_MACTIME_START;
if (!rx_desc->swdec)
^ permalink raw reply
* [PATCH 4.8 090/138] rtl8xxxu: Fix rtl8723bu driver reload issue
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jes Sorensen, Kalle Valo
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jes Sorensen <Jes.Sorensen@redhat.com>
commit ab05e5ec81c76f3a852919c22984c885edd2414a upstream.
The generic disable_rf() function clears bits 22 and 23 in
REG_RX_WAIT_CCA, however we did not re-enable them again in
rtl8723b_enable_rf()
This resolves the problem for me with 8723bu devices not working again
after reloading the driver.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
@@ -1498,6 +1498,10 @@ static void rtl8723b_enable_rf(struct rt
u32 val32;
u8 val8;
+ val32 = rtl8xxxu_read32(priv, REG_RX_WAIT_CCA);
+ val32 |= (BIT(22) | BIT(23));
+ rtl8xxxu_write32(priv, REG_RX_WAIT_CCA, val32);
+
/*
* No indication anywhere as to what 0x0790 does. The 2 antenna
* vendor code preserves bits 6-7 here.
^ permalink raw reply
* [PATCH 4.8 088/138] rtl8xxxu: Fix memory leak in handling rxdesc16 packets
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jes Sorensen, Kalle Valo
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jes Sorensen <Jes.Sorensen@redhat.com>
commit 1e54134ccad00f76ddf00f3e77db3dc8fdefbb47 upstream.
A device running without RX package aggregation could return more data
in the USB packet than the actual network packet. In this case we
could would clone the skb but then determine that that there was no
packet to handle and exit without freeing the cloned skb first.
This has so far only been observed with 8188eu devices, but could
affect others.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -5201,7 +5201,12 @@ int rtl8xxxu_parse_rxdesc16(struct rtl8x
pkt_offset = roundup(pkt_len + drvinfo_sz + desc_shift +
sizeof(struct rtl8xxxu_rxdesc16), 128);
- if (pkt_cnt > 1)
+ /*
+ * Only clone the skb if there's enough data at the end to
+ * at least cover the rx descriptor
+ */
+ if (pkt_cnt > 1 &&
+ urb_len > (pkt_offset + sizeof(struct rtl8xxxu_rxdesc16)))
next_skb = skb_clone(skb, GFP_ATOMIC);
rx_status = IEEE80211_SKB_RXCB(skb);
^ permalink raw reply
* [PATCH 4.8 086/138] dm raid: fix compat_features validation
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andy Whitcroft, Heinz Mauelshagen,
Mike Snitzer
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Whitcroft <apw@canonical.com>
commit 5c33677c87cbe44ae04df69c4a29c1750a9ec4e5 upstream.
In ecbfb9f118bce4 ("dm raid: add raid level takeover support") a new
compatible feature flag was added. Validation for these compat_features
was added but this only passes for new raid mappings with this feature
flag. This causes previously created raid mappings to be failed at
import.
Check compat_features for the only valid combination.
Fixes: ecbfb9f118bce4 ("dm raid: add raid level takeover support")
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-raid.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/md/dm-raid.c
+++ b/drivers/md/dm-raid.c
@@ -2258,7 +2258,8 @@ static int super_validate(struct raid_se
if (!mddev->events && super_init_validation(rs, rdev))
return -EINVAL;
- if (le32_to_cpu(sb->compat_features) != FEATURE_FLAG_SUPPORTS_V190) {
+ if (le32_to_cpu(sb->compat_features) &&
+ le32_to_cpu(sb->compat_features) != FEATURE_FLAG_SUPPORTS_V190) {
rs->ti->error = "Unable to assemble array: Unknown flag(s) in compatible feature flags";
return -EINVAL;
}
^ permalink raw reply
* [PATCH 4.8 085/138] dm rq: clear kworker_task if kthread_run() returned an error
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Tahsin Erdogan, Mike Snitzer
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mike Snitzer <snitzer@redhat.com>
commit 937fa62e8a00d0b4bc2c0a40567d7c88ab2b2e8d upstream.
cleanup_mapped_device() calls kthread_stop() if kworker_task is
non-NULL. Currently the assigned value could be a valid task struct or
an error code (e.g -ENOMEM). Reset md->kworker_task to NULL if
kthread_run() returned an erorr.
Fixes: 7193a9defc ("dm rq: check kthread_run return for .request_fn request-based DM")
Reported-by: Tahsin Erdogan <tahsin@google.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-rq.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/md/dm-rq.c
+++ b/drivers/md/dm-rq.c
@@ -835,8 +835,11 @@ int dm_old_init_request_queue(struct map
init_kthread_worker(&md->kworker);
md->kworker_task = kthread_run(kthread_worker_fn, &md->kworker,
"kdmwork-%s", dm_device_name(md));
- if (IS_ERR(md->kworker_task))
- return PTR_ERR(md->kworker_task);
+ if (IS_ERR(md->kworker_task)) {
+ int error = PTR_ERR(md->kworker_task);
+ md->kworker_task = NULL;
+ return error;
+ }
elv_register_queue(md->queue);
^ permalink raw reply
* [PATCH 4.8 083/138] dm mirror: fix read error on recovery after default leg failure
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Heinz Mauelshagen, Mike Snitzer
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heinz Mauelshagen <heinzm@redhat.com>
commit dcb2ff56417362c31f6b430c3c531a84581e8721 upstream.
If a default leg has failed, any read will cause a new operational
default leg to be selected and the read is resubmitted. But until now
the read will return failure even though it was successful due to
resubmission. The reason for this is bio->bi_error was not being
cleared before resubmitting the bio.
Fix by clearing bio->bi_error before resubmission.
Fixes: 4246a0b63bd8 ("block: add a bi_error field to struct bio")
Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-raid1.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/md/dm-raid1.c
+++ b/drivers/md/dm-raid1.c
@@ -1292,6 +1292,7 @@ static int mirror_end_io(struct dm_targe
dm_bio_restore(bd, bio);
bio_record->details.bi_bdev = NULL;
+ bio->bi_error = 0;
queue_bio(ms, bio, rw);
return DM_ENDIO_INCOMPLETE;
^ permalink raw reply
* Re: Announcing btrfs-dedupe
From: Niccolò Belli @ 2016-11-09 11:24 UTC (permalink / raw)
To: Saint Germain; +Cc: linux-btrfs, James Pharaoh
In-Reply-To: <20161108233625.1eff15df@system>
Hi,
What do you think about jdupes? I'm searching an alternative to duperemove
and rmlint doesn't seem to support btrfs deduplication, so I would like to
try jdupes. My main problem with duperemove is a memory leak, also it seems
to lead to greater disk usage:
https://github.com/markfasheh/duperemove/issues/163
Niccolo' Belli
On martedì 8 novembre 2016 23:36:25 CET, Saint Germain wrote:
> Please be aware of these other similar softwares:
> - jdupes: https://github.com/jbruchon/jdupes
> - rmlint: https://github.com/sahib/rmlint
> And of course fdupes.
>
> Some intesting points I have seen in them:
> - use xxhash to identify potential duplicates (huge speedup)
> - ability to deduplicate read-only snapshots
> - identify potential reflinked files (see also my email here:
> https://www.spinics.net/lists/linux-btrfs/msg60081.html)
> - ability to filter out hardlinks
> - triangle problem: see jdupes readme
> - jdupes has started the process to be included in Debian
>
> I hope that will help and that you can share some codes with them !
^ permalink raw reply
* [PATCH 4.8 081/138] virtio_pci: Limit DMA mask to 44 bits for legacy virtio devices
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andy Lutomirski, Michael S. Tsirkin,
Benjamin Serebrin, Will Deacon
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Will Deacon <will.deacon@arm.com>
commit a0be1db4304f51c99af6b6e515549794182a94df upstream.
Legacy virtio defines the virtqueue base using a 32-bit PFN field, with
a read-only register indicating a fixed page size of 4k.
This can cause problems for DMA allocators that allocate top down from
the DMA mask, which is set to 64 bits. In this case, the addresses are
silently truncated to 44-bit, leading to IOMMU faults, failure to read
from the queue or data corruption.
This patch restricts the coherent DMA mask for legacy PCI virtio devices
to 44 bits, which matches the specification.
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Benjamin Serebrin <serebrin@google.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/virtio/virtio_pci_legacy.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
--- a/drivers/virtio/virtio_pci_legacy.c
+++ b/drivers/virtio/virtio_pci_legacy.c
@@ -212,10 +212,18 @@ int virtio_pci_legacy_probe(struct virti
return -ENODEV;
}
- rc = dma_set_mask_and_coherent(&pci_dev->dev, DMA_BIT_MASK(64));
- if (rc)
- rc = dma_set_mask_and_coherent(&pci_dev->dev,
- DMA_BIT_MASK(32));
+ rc = dma_set_mask(&pci_dev->dev, DMA_BIT_MASK(64));
+ if (rc) {
+ rc = dma_set_mask_and_coherent(&pci_dev->dev, DMA_BIT_MASK(32));
+ } else {
+ /*
+ * The virtio ring base address is expressed as a 32-bit PFN,
+ * with a page size of 1 << VIRTIO_PCI_QUEUE_ADDR_SHIFT.
+ */
+ dma_set_coherent_mask(&pci_dev->dev,
+ DMA_BIT_MASK(32 + VIRTIO_PCI_QUEUE_ADDR_SHIFT));
+ }
+
if (rc)
dev_warn(&pci_dev->dev, "Failed to enable 64-bit or 32-bit DMA. Trying to continue, but this might not work.\n");
^ permalink raw reply
* [PATCH 4.8 084/138] dm table: fix missing dm_put_target_type() in dm_table_add_target()
From: Greg Kroah-Hartman @ 2016-11-09 10:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, tang.junhui, Mike Snitzer
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: tang.junhui <tang.junhui@zte.com.cn>
commit dafa724bf582181d9a7d54f5cb4ca0bf8ef29269 upstream.
dm_get_target_type() was previously called so any error returned from
dm_table_add_target() must first call dm_put_target_type(). Otherwise
the DM target module's reference count will leak and the associated
kernel module will be unable to be removed.
Also, leverage the fact that r is already -EINVAL and remove an extra
newline.
Fixes: 36a0456 ("dm table: add immutable feature")
Fixes: cc6cbe1 ("dm table: add always writeable feature")
Fixes: 3791e2f ("dm table: add singleton feature")
Signed-off-by: tang.junhui <tang.junhui@zte.com.cn>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-table.c | 24 +++++++++---------------
1 file changed, 9 insertions(+), 15 deletions(-)
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -695,37 +695,32 @@ int dm_table_add_target(struct dm_table
tgt->type = dm_get_target_type(type);
if (!tgt->type) {
- DMERR("%s: %s: unknown target type", dm_device_name(t->md),
- type);
+ DMERR("%s: %s: unknown target type", dm_device_name(t->md), type);
return -EINVAL;
}
if (dm_target_needs_singleton(tgt->type)) {
if (t->num_targets) {
- DMERR("%s: target type %s must appear alone in table",
- dm_device_name(t->md), type);
- return -EINVAL;
+ tgt->error = "singleton target type must appear alone in table";
+ goto bad;
}
t->singleton = true;
}
if (dm_target_always_writeable(tgt->type) && !(t->mode & FMODE_WRITE)) {
- DMERR("%s: target type %s may not be included in read-only tables",
- dm_device_name(t->md), type);
- return -EINVAL;
+ tgt->error = "target type may not be included in a read-only table";
+ goto bad;
}
if (t->immutable_target_type) {
if (t->immutable_target_type != tgt->type) {
- DMERR("%s: immutable target type %s cannot be mixed with other target types",
- dm_device_name(t->md), t->immutable_target_type->name);
- return -EINVAL;
+ tgt->error = "immutable target type cannot be mixed with other target types";
+ goto bad;
}
} else if (dm_target_is_immutable(tgt->type)) {
if (t->num_targets) {
- DMERR("%s: immutable target type %s cannot be mixed with other target types",
- dm_device_name(t->md), tgt->type->name);
- return -EINVAL;
+ tgt->error = "immutable target type cannot be mixed with other target types";
+ goto bad;
}
t->immutable_target_type = tgt->type;
}
@@ -740,7 +735,6 @@ int dm_table_add_target(struct dm_table
*/
if (!adjoin(t, tgt)) {
tgt->error = "Gap in table";
- r = -EINVAL;
goto bad;
}
^ permalink raw reply
* [PATCH 4.8 057/138] GenWQE: Fix bad page access during abort of resource allocation
From: Greg Kroah-Hartman @ 2016-11-09 10:45 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Gerald Schaefer, Frank Haverkamp
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
commit a7a7aeefbca2982586ba2c9fd7739b96416a6d1d upstream.
When interrupting an application which was allocating DMAable
memory, it was possible, that the DMA memory was deallocated
twice, leading to the error symptoms below.
Thanks to Gerald, who analyzed the problem and provided this
patch.
I agree with his analysis of the problem: ddcb_cmd_fixups() ->
genwqe_alloc_sync_sgl() (fails in f/lpage, but sgl->sgl != NULL
and f/lpage maybe also != NULL) -> ddcb_cmd_cleanup() ->
genwqe_free_sync_sgl() (double free, because sgl->sgl != NULL and
f/lpage maybe also != NULL)
In this scenario we would have exactly the kind of double free that
would explain the WARNING / Bad page state, and as expected it is
caused by broken error handling (cleanup).
Using the Ubuntu git source, tag Ubuntu-4.4.0-33.52, he was able to reproduce
the "Bad page state" issue, and with the patch on top he could not reproduce
it any more.
------------[ cut here ]------------
WARNING: at /build/linux-o03cxz/linux-4.4.0/arch/s390/include/asm/pci_dma.h:141
Modules linked in: qeth_l2 ghash_s390 prng aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 sha_common genwqe_card qeth crc_itu_t qdio ccwgroup vmur dm_multipath dasd_eckd_mod dasd_mod
CPU: 2 PID: 3293 Comm: genwqe_gunzip Not tainted 4.4.0-33-generic #52-Ubuntu
task: 0000000032c7e270 ti: 00000000324e4000 task.ti: 00000000324e4000
Krnl PSW : 0404c00180000000 0000000000156346 (dma_update_cpu_trans+0x9e/0xa8)
R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
Krnl GPRS: 00000000324e7bcd 0000000000c3c34a 0000000027628298 000000003215b400
0000000000000400 0000000000001fff 0000000000000400 0000000116853000
07000000324e7b1e 0000000000000001 0000000000000001 0000000000000001
0000000000001000 0000000116854000 0000000000156402 00000000324e7a38
Krnl Code: 000000000015633a: 95001000 cli 0(%r1),0
000000000015633e: a774ffc3 brc 7,1562c4
#0000000000156342: a7f40001 brc 15,156344
>0000000000156346: 92011000 mvi 0(%r1),1
000000000015634a: a7f4ffbd brc 15,1562c4
000000000015634e: 0707 bcr 0,%r7
0000000000156350: c00400000000 brcl 0,156350
0000000000156356: eb7ff0500024 stmg %r7,%r15,80(%r15)
Call Trace:
([<00000000001563e0>] dma_update_trans+0x90/0x228)
[<00000000001565dc>] s390_dma_unmap_pages+0x64/0x160
[<00000000001567c2>] s390_dma_free+0x62/0x98
[<000003ff801310ce>] __genwqe_free_consistent+0x56/0x70 [genwqe_card]
[<000003ff801316d0>] genwqe_free_sync_sgl+0xf8/0x160 [genwqe_card]
[<000003ff8012bd6e>] ddcb_cmd_cleanup+0x86/0xa8 [genwqe_card]
[<000003ff8012c1c0>] do_execute_ddcb+0x110/0x348 [genwqe_card]
[<000003ff8012c914>] genwqe_ioctl+0x51c/0xc20 [genwqe_card]
[<000000000032513a>] do_vfs_ioctl+0x3b2/0x518
[<0000000000325344>] SyS_ioctl+0xa4/0xb8
[<00000000007b86c6>] system_call+0xd6/0x264
[<000003ff9e8e520a>] 0x3ff9e8e520a
Last Breaking-Event-Address:
[<0000000000156342>] dma_update_cpu_trans+0x9a/0xa8
---[ end trace 35996336235145c8 ]---
BUG: Bad page state in process jbd2/dasdb1-8 pfn:3215b
page:000003d100c856c0 count:-1 mapcount:0 mapping: (null) index:0x0
flags: 0x3fffc0000000000()
page dumped because: nonzero _count
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Frank Haverkamp <haver@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/misc/genwqe/card_utils.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- a/drivers/misc/genwqe/card_utils.c
+++ b/drivers/misc/genwqe/card_utils.c
@@ -352,17 +352,27 @@ int genwqe_alloc_sync_sgl(struct genwqe_
if (copy_from_user(sgl->lpage, user_addr + user_size -
sgl->lpage_size, sgl->lpage_size)) {
rc = -EFAULT;
- goto err_out1;
+ goto err_out2;
}
}
return 0;
+ err_out2:
+ __genwqe_free_consistent(cd, PAGE_SIZE, sgl->lpage,
+ sgl->lpage_dma_addr);
+ sgl->lpage = NULL;
+ sgl->lpage_dma_addr = 0;
err_out1:
__genwqe_free_consistent(cd, PAGE_SIZE, sgl->fpage,
sgl->fpage_dma_addr);
+ sgl->fpage = NULL;
+ sgl->fpage_dma_addr = 0;
err_out:
__genwqe_free_consistent(cd, sgl->sgl_size, sgl->sgl,
sgl->sgl_dma_addr);
+ sgl->sgl = NULL;
+ sgl->sgl_dma_addr = 0;
+ sgl->sgl_size = 0;
return -ENOMEM;
}
^ permalink raw reply
* Re: [PATCH] clk: gate: fix coding style
From: Masahiro Yamada @ 2016-11-09 11:25 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Michael Turquette, Stephen Boyd, linux-clk, Jiri Kosina,
Sascha Hauer
In-Reply-To: <20161109110046.9594-1-u.kleine-koenig@pengutronix.de>
2016-11-09 20:00 GMT+09:00 Uwe Kleine-K=C3=B6nig <u.kleine-koenig@pengutron=
ix.de>:
> The : of the ?: operator should have a leading space.
>
> Signed-off-by: Uwe Kleine-K=C3=B6nig <u.kleine-koenig@pengutronix.de>
> ---
> Hello,
>
> I always wonder if I should send such patches or if they hurt more than
> they are worth. *shrug* ignore at will.
>
> Best regards
> Uwe
>
> drivers/clk/clk-gate.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
> index 4e691e35483a..59e302538d23 100644
> --- a/drivers/clk/clk-gate.c
> +++ b/drivers/clk/clk-gate.c
> @@ -145,7 +145,7 @@ struct clk_hw *clk_hw_register_gate(struct device *de=
v, const char *name,
> init.name =3D name;
> init.ops =3D &clk_gate_ops;
> init.flags =3D flags | CLK_IS_BASIC;
> - init.parent_names =3D (parent_name ? &parent_name: NULL);
> + init.parent_names =3D (parent_name ? &parent_name : NULL);
> init.num_parents =3D (parent_name ? 1 : 0);
>
Do we need the parentheses?
--=20
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
From: Laszlo Ersek @ 2016-11-09 11:26 UTC (permalink / raw)
To: Andrew Jones, Dave Young; +Cc: wency, qiaonuohan, anderson, qemu-devel, bhe
In-Reply-To: <20161109104059.bvw5h4k4v77pw2rl@kamzik.brq.redhat.com>
On 11/09/16 11:40, Andrew Jones wrote:
> On Wed, Nov 09, 2016 at 11:01:46AM +0800, Dave Young wrote:
>> Hi,
>>
>> Latest linux kernel enabled kaslr to randomiz phys/virt memory
>> addresses, we had some effort to support kexec/kdump so that crash
>> utility can still works in case crashed kernel has kaslr enabled.
>>
>> But according to Dave Anderson virsh dump does not work, quoted messages
>> from Dave below:
>>
>> """
>> with virsh dump, there's no way of even knowing that KASLR
>> has randomized the kernel __START_KERNEL_map region, because there is no
>> virtual address information -- e.g., like "SYMBOL(_stext)" in the kdump
>> vmcoreinfo data to compare against the vmlinux file symbol value.
>> Unless virsh dump can export some basic virtual memory data, which
>> they say it can't, I don't see how KASLR can ever be supported.
>> """
>>
>> I assume virsh dump is using qemu guest memory dump facility so it
>> should be first addressed in qemu. Thus post this query to qemu devel
>> list. If this is not correct please let me know.
>>
>> Could you qemu dump people make it work? Or we can not support virt dump
>> as long as KASLR being enabled. Latest Fedora kernel has enabled it in x86_64.
>>
>
> When the -kernel command line option is used, then it may be possible
> to extract some information that could be used to supplement the memory
> dump that dump-guest-memory provides. However, that would be a specific
> use. In general, QEMU knows nothing about the guest kernel. It doesn't
> know where it is in the disk image, and it doesn't even know if it's
> Linux.
>
> Is there anything a guest userspace application could probe from e.g.
> /proc that would work? If so, then the guest agent could gain a new
> feature providing that.
I fully agree. This is exactly what I suggested too, independently, in
the downstream thread, before arriving at this upstream thread. Let me
quote that email:
On 11/09/16 12:09, Laszlo Ersek wrote:
> [...] the dump-guest-memory QEMU command supports an option called
> "paging". Here's its documentation, from the "qapi-schema.json" source
> file:
>
>> # @paging: if true, do paging to get guest's memory mapping. This allows
>> # using gdb to process the core file.
>> #
>> # IMPORTANT: this option can make QEMU allocate several gigabytes
>> # of RAM. This can happen for a large guest, or a
>> # malicious guest pretending to be large.
>> #
>> # Also, paging=true has the following limitations:
>> #
>> # 1. The guest may be in a catastrophic state or can have corrupted
>> # memory, which cannot be trusted
>> # 2. The guest can be in real-mode even if paging is enabled. For
>> # example, the guest uses ACPI to sleep, and ACPI sleep state
>> # goes in real-mode
>> # 3. Currently only supported on i386 and x86_64.
>> #
>
> "virsh dump --memory-only" sets paging=false, for obvious reasons.
>
> [...] the dump-guest-memory command provides a raw snapshot of the
> virtual machine's memory (and of the registers of the VCPUs); it is
> not enlightened about the guest.
>
> If the additional information you are looking for can be retrieved
> within the running Linux guest, using an appropriately privieleged
> userspace process, then I would recommend considering an extension to
> the qemu guest agent. The management layer (libvirt, [...]) could
> first invoke the guest agent (a process with root privileges running
> in the guest) from the host side, through virtio-serial. The new guest
> agent command would return the information necessary to deal with
> KASLR. Then the management layer would initiate the dump like always.
> Finally, the extra information would be combined with (or placed
> beside) the dump file in some way.
>
> So, this proposal would affect the guest agent and the management
> layer (= libvirt).
Given that we already dislike "paging=true", enlightening
dump-guest-memory with even more guest-specific insight is the wrong
approach, IMO. That kind of knowledge belongs to the guest agent.
Thanks
Laszlo
^ permalink raw reply
* [PATCH 4.8 031/138] ALSA: hda - Fix surround output pins for ASRock B150M mobo
From: Greg Kroah-Hartman @ 2016-11-09 10:45 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Takashi Iwai
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit 1a3f099101b85cc93d864eb030d97e7725c72ea7 upstream.
ASRock B150M Pro4/D3 mobo with ALC892 codec doesn't seem to provide
proper pins for the surround outputs, hence we need to specify the
pincfgs manually with a couple of other corrections.
Reported-and-tested-by: Benjamin Valentin <benpicco@googlemail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6615,6 +6615,7 @@ enum {
ALC891_FIXUP_HEADSET_MODE,
ALC891_FIXUP_DELL_MIC_NO_PRESENCE,
ALC662_FIXUP_ACER_VERITON,
+ ALC892_FIXUP_ASROCK_MOBO,
};
static const struct hda_fixup alc662_fixups[] = {
@@ -6891,6 +6892,16 @@ static const struct hda_fixup alc662_fix
{ }
}
},
+ [ALC892_FIXUP_ASROCK_MOBO] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x15, 0x40f000f0 }, /* disabled */
+ { 0x16, 0x40f000f0 }, /* disabled */
+ { 0x18, 0x01014011 }, /* LO */
+ { 0x1a, 0x01014012 }, /* LO */
+ { }
+ }
+ },
};
static const struct snd_pci_quirk alc662_fixup_tbl[] = {
@@ -6928,6 +6939,7 @@ static const struct snd_pci_quirk alc662
SND_PCI_QUIRK(0x144d, 0xc051, "Samsung R720", ALC662_FIXUP_IDEAPAD),
SND_PCI_QUIRK(0x17aa, 0x38af, "Lenovo Ideapad Y550P", ALC662_FIXUP_IDEAPAD),
SND_PCI_QUIRK(0x17aa, 0x3a0d, "Lenovo Ideapad Y550", ALC662_FIXUP_IDEAPAD),
+ SND_PCI_QUIRK(0x1849, 0x5892, "ASRock B150M", ALC892_FIXUP_ASROCK_MOBO),
SND_PCI_QUIRK(0x19da, 0xa130, "Zotac Z68", ALC662_FIXUP_ZOTAC_Z68),
SND_PCI_QUIRK(0x1b0a, 0x01b8, "ACER Veriton", ALC662_FIXUP_ACER_VERITON),
SND_PCI_QUIRK(0x1b35, 0x2206, "CZC P10T", ALC662_FIXUP_CZC_P10T),
^ permalink raw reply
* [LTP] [PATCH 1/1] network: load test_net.sh after getopts
From: Alexey Kodanev @ 2016-11-09 11:26 UTC (permalink / raw)
To: ltp
In-Reply-To: <20161107121952.24933-1-pvorel@suse.cz>
Hi,
On 11/07/2016 03:19 PM, Petr Vorel wrote:
> We shouldn't ask rsh/ssh password or require having set ssh pub keys
> just for displaying help.
>
> Signed-off-by: Petr Vorel <pvorel@suse.cz>
> ---
> testscripts/network.sh | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/testscripts/network.sh b/testscripts/network.sh
> index 66bacef..fea2f68 100755
> --- a/testscripts/network.sh
> +++ b/testscripts/network.sh
> @@ -11,8 +11,6 @@ if [ $? -eq 0 ]; then
> export LTPROOT=${PWD}
> fi
>
> -. test_net.sh
> -
> export TMPDIR=/tmp/netpan-$$
> mkdir -p $TMPDIR
> CMDFILE=${TMPDIR}/network.tests
> @@ -81,6 +79,8 @@ if [ "$OPTIND" -eq 1 ]; then
> exit 1
> fi
>
> +. test_net.sh
> +
Agree, but we should reset TCID and TST_TOTAL after test_net.sh
inclusion (not before).
May be something like this where they were moved close to each other:
@@ -81,6 +79,8 @@ if [ "$OPTIND" -eq 1 ]; then
exit 1
fi
+TST_TOTAL=1
+TCID="network_settings"
+
+. test_net.sh
+
+# Reset variables.
+# Don't break the tests which are using 'testcases/lib/cmdlib.sh'
+export TCID=
+export TST_LIB_LOADED=
+
rm -f $CMDFILE
Best regards,
Alexey
> rm -f $CMDFILE
>
> for t in $TEST_CASES; do
^ permalink raw reply
* [PATCH 4.8 029/138] ALSA: hda - allow 40 bit DMA mask for NVidia devices
From: Greg Kroah-Hartman @ 2016-11-09 10:45 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ard Biesheuvel, Takashi Iwai
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
commit 3ab7511eafdd5c4f40d2832f09554478dfbea170 upstream.
Commit 49d9e77e72cf ("ALSA: hda - Fix system panic when DMA > 40 bits
for Nvidia audio controllers") simply disabled any DMA exceeding 32
bits for NVidia devices, even though they are capable of performing
DMA up to 40 bits. On some architectures (such as arm64), system memory
is not guaranteed to be 32-bit addressable by PCI devices, and so this
change prevents NVidia devices from working on platforms such as AMD
Seattle.
Since the original commit already mentioned that up to 40 bits of DMA
is supported, and given that the code has been updated in the meantime
to support a 40 bit DMA mask on other devices, revert commit 49d9e77e72cf
and explicitly set the DMA mask to 40 bits for NVidia devices.
Fixes: 49d9e77e72cf ('ALSA: hda - Fix system panic when DMA > 40 bits...')
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/hda_intel.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -340,8 +340,7 @@ enum {
/* quirks for Nvidia */
#define AZX_DCAPS_PRESET_NVIDIA \
- (AZX_DCAPS_NO_MSI | /*AZX_DCAPS_ALIGN_BUFSIZE |*/ \
- AZX_DCAPS_NO_64BIT | AZX_DCAPS_CORBRP_SELF_CLEAR |\
+ (AZX_DCAPS_NO_MSI | AZX_DCAPS_CORBRP_SELF_CLEAR |\
AZX_DCAPS_SNOOP_TYPE(NVIDIA))
#define AZX_DCAPS_PRESET_CTHDA \
@@ -1699,6 +1698,10 @@ static int azx_first_init(struct azx *ch
}
}
+ /* NVidia hardware normally only supports up to 40 bits of DMA */
+ if (chip->pci->vendor == PCI_VENDOR_ID_NVIDIA)
+ dma_bits = 40;
+
/* disable 64bit DMA address on some devices */
if (chip->driver_caps & AZX_DCAPS_NO_64BIT) {
dev_dbg(card->dev, "Disabling 64bit DMA\n");
^ permalink raw reply
* Re: [Ksummit-discuss] Including images on Sphinx documents
From: Mauro Carvalho Chehab @ 2016-11-09 11:27 UTC (permalink / raw)
To: Jani Nikula
Cc: Markus Heiser, ksummit-discuss, linux-doc, linux-kernel,
linux-media
In-Reply-To: <8737j0hpi0.fsf@intel.com>
Em Wed, 09 Nov 2016 13:16:55 +0200
Jani Nikula <jani.nikula@linux.intel.com> escreveu:
> >> 1) copy (or symlink) all rst files to Documentation/output (or to the
> >> build dir specified via O= directive) and generate the *.pdf there,
> >> and produce those converted images via Makefile.;
>
> We're supposed to solve problems, not create new ones.
So, what's your proposal?
Thanks,
Mauro
^ permalink raw reply
* Re: [Ksummit-discuss] Including images on Sphinx documents
From: Mauro Carvalho Chehab @ 2016-11-09 11:27 UTC (permalink / raw)
To: Jani Nikula
Cc: Markus Heiser, Josh Triplett, Jonathan Corbet, linux-kernel,
linux-media, ksummit-discuss, linux-doc
In-Reply-To: <8737j0hpi0.fsf@intel.com>
Em Wed, 09 Nov 2016 13:16:55 +0200
Jani Nikula <jani.nikula@linux.intel.com> escreveu:
> >> 1) copy (or symlink) all rst files to Documentation/output (or to the
> >> build dir specified via O= directive) and generate the *.pdf there,
> >> and produce those converted images via Makefile.;
>
> We're supposed to solve problems, not create new ones.
So, what's your proposal?
Thanks,
Mauro
^ permalink raw reply
* [PATCH 4.8 028/138] ALSA: seq: Fix time account regression
From: Greg Kroah-Hartman @ 2016-11-09 10:45 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Yves Guillemot, Takashi Iwai
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit 9b50898ad96c793a8f7cde9d8f281596d752a7dd upstream.
The recent rewrite of the sequencer time accounting using timespec64
in the commit [3915bf294652: ALSA: seq_timer: use monotonic times
internally] introduced a bad regression. Namely, the time reported
back doesn't increase but goes back and forth.
The culprit was obvious: the delta is stored to the result (cur_time =
delta), instead of adding the delta (cur_time += delta)!
Let's fix it.
Fixes: 3915bf294652 ('ALSA: seq_timer: use monotonic times internally')
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177571
Reported-by: Yves Guillemot <yc.guillemot@wanadoo.fr>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/seq/seq_timer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/sound/core/seq/seq_timer.c
+++ b/sound/core/seq/seq_timer.c
@@ -448,8 +448,8 @@ snd_seq_real_time_t snd_seq_timer_get_cu
ktime_get_ts64(&tm);
tm = timespec64_sub(tm, tmr->last_update);
- cur_time.tv_nsec = tm.tv_nsec;
- cur_time.tv_sec = tm.tv_sec;
+ cur_time.tv_nsec += tm.tv_nsec;
+ cur_time.tv_sec += tm.tv_sec;
snd_seq_sanity_real_time(&cur_time);
}
spin_unlock_irqrestore(&tmr->lock, flags);
^ permalink raw reply
* Re: [Qemu-devel] Crashing in tcp_close
From: Stefan Hajnoczi @ 2016-11-09 11:27 UTC (permalink / raw)
To: Brian Candler; +Cc: Samuel Thibault, qemu-devel, Jan Kiszka
In-Reply-To: <466003bb-a2c4-bb9b-7b0b-7b2d6dcb16d7@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 5571 bytes --]
On Tue, Nov 08, 2016 at 09:22:25PM +0000, Brian Candler wrote:
> On 07/11/2016 10:42, Stefan Hajnoczi wrote:
> > On Mon, Nov 07, 2016 at 08:42:17AM +0000, Brian Candler wrote:
> > > >On 06/11/2016 18:04, Samuel Thibault wrote:
> > > > > >Brian, could you run it with
> > > > > >
> > > > > >export MALLOC_CHECK_=2
> > > > > >
> > > > > >and also this could be useful:
> > > > > >
> > > > > >export MALLOC_PERTURB_=1234
> > > > > >
> > > > > >Also, to rule out the double-free scenario, and try to catch a buffer
> > > > > >overflow coming from the socket structure itself, I have attached a
> > > > > >patch which adds some debugging.
> > > >
> > > >Thanks. I've added the patch, and re-run the stress test.
>
> Back to the original setup, I can still get dumps. I notice I'm now getting
> "malloc_printerr" in the backtrace, but unfortunately I don't get to see the
> actual error message. It would seem that the malloc_check is being done and
> finding an issue. I haven't been able to get one in tcp_close again though
> :-(
Heap corruption. Valgrind's memcheck tool could be fruitful here:
http://valgrind.org/docs/manual/quick-start.html#quick-start.mcrun
Stefan
> Regards,
>
> Brian.
>
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `/usr/local/bin/qemu-system-x86_64 -m 4G -machine
> type=pc,accel=kvm -device virt'.
> Program terminated with signal SIGABRT, Aborted.
> #0 0x00007eff4f3df428 in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:54
> 54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> [Current thread is 1 (Thread 0x7eff50dffa80 (LWP 13616))]
> (gdb) bt
> #0 0x00007eff4f3df428 in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1 0x00007eff4f3e102a in __GI_abort () at abort.c:89
> #2 0x00007eff4f42bc1f in malloc_printerr (ar_ptr=<optimised out>,
> ptr=<optimised out>, str=<optimised out>,
> action=<optimised out>) at malloc.c:5008
> #3 _int_malloc (av=av@entry=0x7eff4f76db20 <main_arena>,
> bytes=bytes@entry=89) at malloc.c:3384
> #4 0x00007eff4f42c409 in malloc_check (sz=88, caller=<optimised out>) at
> hooks.c:295
> #5 0x00007eff50106729 in g_malloc () from
> /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #6 0x0000563ca16930cf in qemu_aio_get
> (aiocb_info=aiocb_info@entry=0x563ca1841190 <blk_aio_em_aiocb_info>,
> bs=0x563ca4132f40, cb=cb@entry=0x563ca14d85e0 <dma_blk_cb>,
> opaque=opaque@entry=0x563ca5b78910)
> at /home/nsrc/qemu-2.7.0/block/io.c:2231
> #7 0x0000563ca1687aa8 in blk_aio_get (opaque=0x563ca5b78910,
> cb=0x563ca14d85e0 <dma_blk_cb>, blk=0x563ca4132d70,
> aiocb_info=0x563ca1841190 <blk_aio_em_aiocb_info>) at
> /home/nsrc/qemu-2.7.0/block/block-backend.c:1477
> #8 blk_aio_prwv (blk=0x563ca4132d70, offset=5278244864, bytes=4096,
> qiov=0x563ca5b78968,
> co_entry=co_entry@entry=0x563ca16872b0 <blk_aio_write_entry>, flags=0,
> cb=0x563ca14d85e0 <dma_blk_cb>,
> opaque=0x563ca5b78910) at
> /home/nsrc/qemu-2.7.0/block/block-backend.c:941
> #9 0x0000563ca1687bc0 in blk_aio_pwritev (blk=<optimised out>,
> offset=<optimised out>, qiov=<optimised out>,
> flags=<optimised out>, cb=<optimised out>, opaque=<optimised out>)
> at /home/nsrc/qemu-2.7.0/block/block-backend.c:1054
> #10 0x0000563ca14d8718 in dma_blk_cb (opaque=0x563ca5b78910, ret=<optimised
> out>)
> at /home/nsrc/qemu-2.7.0/dma-helpers.c:167
> #11 0x0000563ca14d8bf8 in dma_blk_io (ctx=0x563ca41184a0,
> sg=sg@entry=0x563ca59a08f0,
> offset=offset@entry=5278244864, io_func=io_func@entry=0x563ca15a58e0
> <scsi_dma_writev>,
> io_func_opaque=io_func_opaque@entry=0x563ca5c8a350,
> cb=cb@entry=0x563ca15a7250 <scsi_dma_complete>,
> opaque=0x563ca5c8a350, dir=DMA_DIRECTION_TO_DEVICE) at
> /home/nsrc/qemu-2.7.0/dma-helpers.c:222
> #12 0x0000563ca15a764e in scsi_write_data (req=0x563ca5c8a350) at
> /home/nsrc/qemu-2.7.0/hw/scsi/scsi-disk.c:540
> #13 0x0000563ca15ac743 in scsi_req_continue (req=req@entry=0x563ca5c8a350)
> at /home/nsrc/qemu-2.7.0/hw/scsi/scsi-bus.c:1680
> #14 0x0000563ca14381a2 in virtio_scsi_handle_cmd_req_submit
> (s=0x563ca5abc1d0, req=<optimised out>)
> at /home/nsrc/qemu-2.7.0/hw/scsi/virtio-scsi.c:565
> #15 virtio_scsi_handle_cmd_vq (s=0x563ca5abc1d0, vq=0x7eff4963f110)
> at /home/nsrc/qemu-2.7.0/hw/scsi/virtio-scsi.c:583
> #16 0x0000563ca144a0d6 in virtio_queue_notify_vq (vq=0x7eff4963f110)
> ---Type <return> to continue, or q <return> to quit---
> at /home/nsrc/qemu-2.7.0/hw/virtio/virtio.c:1113
> #17 0x0000563ca1654965 in aio_dispatch (ctx=0x563ca41184a0) at
> /home/nsrc/qemu-2.7.0/aio-posix.c:330
> #18 0x0000563ca164a3ae in aio_ctx_dispatch (source=<optimised out>,
> callback=<optimised out>,
> user_data=<optimised out>) at /home/nsrc/qemu-2.7.0/async.c:234
> #19 0x00007eff501011a7 in g_main_context_dispatch () from
> /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #20 0x0000563ca16531db in glib_pollfds_poll () at
> /home/nsrc/qemu-2.7.0/main-loop.c:213
> #21 os_host_main_loop_wait (timeout=<optimised out>) at
> /home/nsrc/qemu-2.7.0/main-loop.c:258
> #22 main_loop_wait (nonblocking=<optimised out>) at
> /home/nsrc/qemu-2.7.0/main-loop.c:506
> #23 0x0000563ca13be431 in main_loop () at /home/nsrc/qemu-2.7.0/vl.c:1908
> #24 main (argc=<optimised out>, argv=<optimised out>, envp=<optimised out>)
> at /home/nsrc/qemu-2.7.0/vl.c:4604
> (gdb)
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* [PATCH 4.8 027/138] ALSA: usb-audio: Add quirk for Syntek STK1160
From: Greg Kroah-Hartman @ 2016-11-09 10:45 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Marcel Hasler, Takashi Iwai
In-Reply-To: <20161109102844.808685475@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marcel Hasler <mahasler@gmail.com>
commit bdc3478f90cd4d2928197f36629d5cf93b64dbe9 upstream.
The stk1160 chip needs QUIRK_AUDIO_ALIGN_TRANSFER. This patch resolves
the issue reported on the mailing list
(http://marc.info/?l=linux-sound&m=139223599126215&w=2) and also fixes
bug 180071 (https://bugzilla.kernel.org/show_bug.cgi?id=180071).
Signed-off-by: Marcel Hasler <mahasler@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/usb/quirks-table.h | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
--- a/sound/usb/quirks-table.h
+++ b/sound/usb/quirks-table.h
@@ -2907,6 +2907,23 @@ AU0828_DEVICE(0x2040, 0x7260, "Hauppauge
AU0828_DEVICE(0x2040, 0x7213, "Hauppauge", "HVR-950Q"),
AU0828_DEVICE(0x2040, 0x7270, "Hauppauge", "HVR-950Q"),
+/* Syntek STK1160 */
+{
+ .match_flags = USB_DEVICE_ID_MATCH_DEVICE |
+ USB_DEVICE_ID_MATCH_INT_CLASS |
+ USB_DEVICE_ID_MATCH_INT_SUBCLASS,
+ .idVendor = 0x05e1,
+ .idProduct = 0x0408,
+ .bInterfaceClass = USB_CLASS_AUDIO,
+ .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL,
+ .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) {
+ .vendor_name = "Syntek",
+ .product_name = "STK1160",
+ .ifnum = QUIRK_ANY_INTERFACE,
+ .type = QUIRK_AUDIO_ALIGN_TRANSFER
+ }
+},
+
/* Digidesign Mbox */
{
/* Thanks to Clemens Ladisch <clemens@ladisch.de> */
^ permalink raw reply
* Re: [PATCH] examples/l3fwd: force CRC stripping for i40evf
From: Björn Töpel @ 2016-11-09 11:27 UTC (permalink / raw)
To: Ananyev, Konstantin, dev@dpdk.org, Zhang, Helin
Cc: Xu, Qian Q, Yao, Lei A, Wu, Jingjing, thomas.monjalon@6wind.com
In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0D2FD9@irsmsx105.ger.corp.intel.com>
>> Correct, so the broader question would be "what is the correct
>> behavior for an example application, when a port configuration
>> isn't supported by the hardware?".
>>
>> My stand, FWIW, is that igb and ixgbe should have the same
>> semantics as i40e currently has, i.e. return an error to the user
>> if the port is mis-configured, NOT changing the setting behind the
>> users back.
>>
>
> Fine by me, but then it means that the fix haw to include changes
> for all apps plus ixgbe and igb PMDs, correct? :)
Ugh. Correct, I guess. :-)
As for ixgbe and igb - they need a patch changing from silent ignore to
explicit error. Regarding the apps, I guess all the apps that rely on
that disabling CRC stripping always work, need some work. Or should all
the example applications have CRC stripping *enabled* by default? I'd
assume that all DPDK supported NICs has support for CRC stripping and I
guess this is the rational for having it on by default for Intel VFs.
In general, for the example applications, if an application relies on a
property for a port, that the hardware doesn't support -- what would be
the desired behavior? Or is it implied that the example applications
only use a common, minimal set of features that are know to be supported
by all DPDK supported hardware?
Isn't it perfectly valid that some example applications wont run for all
hardware?
Finally, why doesn't l3fwd have the CRC stripped?
Björn
^ permalink raw reply
* Re: [Ksummit-discuss] Including images on Sphinx documents
From: Markus Heiser @ 2016-11-09 11:27 UTC (permalink / raw)
To: Jani Nikula
Cc: Josh Triplett, Mauro Carvalho Chehab, Jonathan Corbet,
linux-kernel, linux-media, ksummit-discuss, linux-doc
In-Reply-To: <8737j0hpi0.fsf@intel.com>
Am 09.11.2016 um 12:16 schrieb Jani Nikula <jani.nikula@linux.intel.com>:
>> So I vote for :
>>
>>> 1) copy (or symlink) all rst files to Documentation/output (or to the
>>> build dir specified via O= directive) and generate the *.pdf there,
>>> and produce those converted images via Makefile.;
>
> We're supposed to solve problems, not create new ones.
... new ones? ...
>> IMO placing 'sourcedir' to O= is more sane since this marries the
>> Linux Makefile concept (relative to $PWD) with the sphinx concept
>> (in or below 'sourcedir').
-- Markus --
^ permalink raw reply
* Re: [Ksummit-discuss] Including images on Sphinx documents
From: Markus Heiser @ 2016-11-09 11:27 UTC (permalink / raw)
To: Jani Nikula
Cc: ksummit-discuss, linux-doc, linux-kernel, Mauro Carvalho Chehab,
linux-media
In-Reply-To: <8737j0hpi0.fsf@intel.com>
Am 09.11.2016 um 12:16 schrieb Jani Nikula <jani.nikula@linux.intel.com>:
>> So I vote for :
>>
>>> 1) copy (or symlink) all rst files to Documentation/output (or to the
>>> build dir specified via O= directive) and generate the *.pdf there,
>>> and produce those converted images via Makefile.;
>
> We're supposed to solve problems, not create new ones.
... new ones? ...
>> IMO placing 'sourcedir' to O= is more sane since this marries the
>> Linux Makefile concept (relative to $PWD) with the sphinx concept
>> (in or below 'sourcedir').
-- Markus --
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.