* [PATCH 3.12 001/118] arm64: mm: Fix PMD_SECT_PROT_NONE definition
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
@ 2013-12-18 21:10 ` Greg Kroah-Hartman
2013-12-18 21:10 ` [PATCH 3.12 002/118] udl: fix issue with imported prime buffers Greg Kroah-Hartman
` (115 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Steve Capper, Catalin Marinas
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steve Capper <steve.capper@linaro.org>
commit db4ed53cfe9f5a00355891a631d47dfa3fd4541f upstream.
Modify the value of PMD_SECT_PROT_NONE to match that of PTE_NONE. This
should have been in commit 3676f9ef5481 (Move PTE_PROT_NONE higher up).
Signed-off-by: Steve Capper <steve.capper@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/include/asm/pgtable-hwdef.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -43,7 +43,7 @@
* Section
*/
#define PMD_SECT_VALID (_AT(pmdval_t, 1) << 0)
-#define PMD_SECT_PROT_NONE (_AT(pmdval_t, 1) << 2)
+#define PMD_SECT_PROT_NONE (_AT(pmdval_t, 1) << 58)
#define PMD_SECT_USER (_AT(pmdval_t, 1) << 6) /* AP[1] */
#define PMD_SECT_RDONLY (_AT(pmdval_t, 1) << 7) /* AP[2] */
#define PMD_SECT_S (_AT(pmdval_t, 3) << 8)
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 002/118] udl: fix issue with imported prime buffers
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
2013-12-18 21:10 ` [PATCH 3.12 001/118] arm64: mm: Fix PMD_SECT_PROT_NONE definition Greg Kroah-Hartman
@ 2013-12-18 21:10 ` Greg Kroah-Hartman
2013-12-18 21:10 ` [PATCH 3.12 003/118] ALSA: compress: Fix 64bit ABI incompatibility Greg Kroah-Hartman
` (114 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Rob Clark, Dave Airlie, Thomas Meyer
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rob Clark <robdclark@gmail.com>
commit 1d507b3af40a60e03a3bbc4c897fc2709c075d24 upstream.
5dc9e1e8 was a bit over-ambitious, and accidentially removed handling
for imported prime buffers.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Cc: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/udl/udl_gem.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/gpu/drm/udl/udl_gem.c
+++ b/drivers/gpu/drm/udl/udl_gem.c
@@ -132,6 +132,12 @@ static int udl_gem_get_pages(struct udl_
static void udl_gem_put_pages(struct udl_gem_object *obj)
{
+ if (obj->base.import_attach) {
+ drm_free_large(obj->pages);
+ obj->pages = NULL;
+ return;
+ }
+
drm_gem_put_pages(&obj->base, obj->pages, false, false);
obj->pages = NULL;
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 003/118] ALSA: compress: Fix 64bit ABI incompatibility
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
2013-12-18 21:10 ` [PATCH 3.12 001/118] arm64: mm: Fix PMD_SECT_PROT_NONE definition Greg Kroah-Hartman
2013-12-18 21:10 ` [PATCH 3.12 002/118] udl: fix issue with imported prime buffers Greg Kroah-Hartman
@ 2013-12-18 21:10 ` Greg Kroah-Hartman
2013-12-18 21:10 ` Greg Kroah-Hartman
` (113 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Vinod Koul, Takashi Iwai
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit 6733cf572a9e20db2b7580a5dd39d5782d571eec upstream.
snd_pcm_uframes_t is defined as unsigned long so it would take
different sizes depending on 32 or 64bit architectures. As we don't
want this ABI incompatibility, and there is no real 64bit user yet,
let's make it the fixed size with __u32.
Also bump the protocol version number to 0.1.2.
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/uapi/sound/compress_offload.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/include/uapi/sound/compress_offload.h
+++ b/include/uapi/sound/compress_offload.h
@@ -30,7 +30,7 @@
#include <sound/compress_params.h>
-#define SNDRV_COMPRESS_VERSION SNDRV_PROTOCOL_VERSION(0, 1, 1)
+#define SNDRV_COMPRESS_VERSION SNDRV_PROTOCOL_VERSION(0, 1, 2)
/**
* struct snd_compressed_buffer: compressed buffer
* @fragment_size: size of buffer fragment in bytes
@@ -67,8 +67,8 @@ struct snd_compr_params {
struct snd_compr_tstamp {
__u32 byte_offset;
__u32 copied_total;
- snd_pcm_uframes_t pcm_frames;
- snd_pcm_uframes_t pcm_io_frames;
+ __u32 pcm_frames;
+ __u32 pcm_io_frames;
__u32 sampling_rate;
};
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 004/118] ALSA: memalloc.h - fix wrong truncation of dma_addr_t
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
@ 2013-12-18 21:10 ` Greg Kroah-Hartman
2013-12-18 21:10 ` [PATCH 3.12 002/118] udl: fix issue with imported prime buffers Greg Kroah-Hartman
` (115 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stefano Panella, Frediano Ziglio,
Takashi Iwai
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefano Panella <stefano.panella@citrix.com>
commit 932e9dec380c67ec15ac3eb073bb55797d8b4801 upstream.
When running a 32bit kernel the hda_intel driver is still reporting
a 64bit dma_mask if the HW supports it.
>From sound/pci/hda/hda_intel.c:
/* allow 64bit DMA address if supported by H/W */
if ((gcap & ICH6_GCAP_64OK) && !pci_set_dma_mask(pci, DMA_BIT_MASK(64)))
pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(64));
else {
pci_set_dma_mask(pci, DMA_BIT_MASK(32));
pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(32));
}
which means when there is a call to dma_alloc_coherent from
snd_malloc_dev_pages a machine address bigger than 32bit can be returned.
This can be true in particular if running the 32bit kernel as a pv dom0
under the Xen Hypervisor or PAE on bare metal.
The problem is that when calling setup_bdle to program the BLE the
dma_addr_t returned from the dma_alloc_coherent is wrongly truncated
from snd_sgbuf_get_addr if running a 32bit kernel:
static inline dma_addr_t snd_sgbuf_get_addr(struct snd_dma_buffer *dmab,
size_t offset)
{
struct snd_sg_buf *sgbuf = dmab->private_data;
dma_addr_t addr = sgbuf->table[offset >> PAGE_SHIFT].addr;
addr &= PAGE_MASK;
return addr + offset % PAGE_SIZE;
}
where PAGE_MASK in a 32bit kernel is zeroing the upper 32bit af addr.
Without this patch the HW will fetch the 32bit truncated address,
which is not the one obtained from dma_alloc_coherent and will result
to a non working audio but can corrupt host memory at a random location.
The current patch apply to v3.13-rc3-74-g6c843f5
Signed-off-by: Stefano Panella <stefano.panella@citrix.com>
Reviewed-by: Frediano Ziglio <frediano.ziglio@citrix.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/sound/memalloc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/include/sound/memalloc.h
+++ b/include/sound/memalloc.h
@@ -103,7 +103,7 @@ static inline dma_addr_t snd_sgbuf_get_a
{
struct snd_sg_buf *sgbuf = dmab->private_data;
dma_addr_t addr = sgbuf->table[offset >> PAGE_SHIFT].addr;
- addr &= PAGE_MASK;
+ addr &= ~((dma_addr_t)PAGE_SIZE - 1);
return addr + offset % PAGE_SIZE;
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 004/118] ALSA: memalloc.h - fix wrong truncation of dma_addr_t
@ 2013-12-18 21:10 ` Greg Kroah-Hartman
0 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stefano Panella, Frediano Ziglio,
Takashi Iwai
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefano Panella <stefano.panella@citrix.com>
commit 932e9dec380c67ec15ac3eb073bb55797d8b4801 upstream.
When running a 32bit kernel the hda_intel driver is still reporting
a 64bit dma_mask if the HW supports it.
>>From sound/pci/hda/hda_intel.c:
/* allow 64bit DMA address if supported by H/W */
if ((gcap & ICH6_GCAP_64OK) && !pci_set_dma_mask(pci, DMA_BIT_MASK(64)))
pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(64));
else {
pci_set_dma_mask(pci, DMA_BIT_MASK(32));
pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(32));
}
which means when there is a call to dma_alloc_coherent from
snd_malloc_dev_pages a machine address bigger than 32bit can be returned.
This can be true in particular if running the 32bit kernel as a pv dom0
under the Xen Hypervisor or PAE on bare metal.
The problem is that when calling setup_bdle to program the BLE the
dma_addr_t returned from the dma_alloc_coherent is wrongly truncated
from snd_sgbuf_get_addr if running a 32bit kernel:
static inline dma_addr_t snd_sgbuf_get_addr(struct snd_dma_buffer *dmab,
size_t offset)
{
struct snd_sg_buf *sgbuf = dmab->private_data;
dma_addr_t addr = sgbuf->table[offset >> PAGE_SHIFT].addr;
addr &= PAGE_MASK;
return addr + offset % PAGE_SIZE;
}
where PAGE_MASK in a 32bit kernel is zeroing the upper 32bit af addr.
Without this patch the HW will fetch the 32bit truncated address,
which is not the one obtained from dma_alloc_coherent and will result
to a non working audio but can corrupt host memory at a random location.
The current patch apply to v3.13-rc3-74-g6c843f5
Signed-off-by: Stefano Panella <stefano.panella@citrix.com>
Reviewed-by: Frediano Ziglio <frediano.ziglio@citrix.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/sound/memalloc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/include/sound/memalloc.h
+++ b/include/sound/memalloc.h
@@ -103,7 +103,7 @@ static inline dma_addr_t snd_sgbuf_get_a
{
struct snd_sg_buf *sgbuf = dmab->private_data;
dma_addr_t addr = sgbuf->table[offset >> PAGE_SHIFT].addr;
- addr &= PAGE_MASK;
+ addr &= ~((dma_addr_t)PAGE_SIZE - 1);
return addr + offset % PAGE_SIZE;
}
^ permalink raw reply [flat|nested] 196+ messages in thread
* [PATCH 3.12 005/118] ALSA: hda - Add static DAC/pin mapping for AD1986A codec
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2013-12-18 21:10 ` Greg Kroah-Hartman
@ 2013-12-18 21:10 ` Greg Kroah-Hartman
2013-12-18 21:10 ` [PATCH 3.12 006/118] ALSA: hda - Mute all aamix inputs as default Greg Kroah-Hartman
` (111 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Takashi Iwai
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit 3690739b013504d33fe9348dd45f6b126aa370fb upstream.
AD1986A codec is a pretty old codec and has really many hidden
restrictions. One of such is that each DAC is dedicated to certain
pin although there are possible connections. Currently, the generic
parser tries to assign individual DACs as much as possible, and this
lead to two bad situations: connections where the sound actually
doesn't work, and connections conflicting other channels.
We may fix this by trying to find the best connections more harder,
but as of now, it's easier to give some hints for paired DAC/pin
connections and honor them if available, since such a hint is needed
only for specific codecs (right now only AD1986A, and there will be
unlikely any others in future).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64971
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66621
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/hda_generic.c | 23 ++++++++++++++++++++++-
sound/pci/hda/hda_generic.h | 3 +++
sound/pci/hda/patch_analog.c | 10 ++++++++++
3 files changed, 35 insertions(+), 1 deletion(-)
--- a/sound/pci/hda/hda_generic.c
+++ b/sound/pci/hda/hda_generic.c
@@ -474,6 +474,20 @@ static void invalidate_nid_path(struct h
memset(path, 0, sizeof(*path));
}
+/* return a DAC if paired to the given pin by codec driver */
+static hda_nid_t get_preferred_dac(struct hda_codec *codec, hda_nid_t pin)
+{
+ struct hda_gen_spec *spec = codec->spec;
+ const hda_nid_t *list = spec->preferred_dacs;
+
+ if (!list)
+ return 0;
+ for (; *list; list += 2)
+ if (*list == pin)
+ return list[1];
+ return 0;
+}
+
/* look for an empty DAC slot */
static hda_nid_t look_for_dac(struct hda_codec *codec, hda_nid_t pin,
bool is_digital)
@@ -1192,7 +1206,14 @@ static int try_assign_dacs(struct hda_co
continue;
}
- dacs[i] = look_for_dac(codec, pin, false);
+ dacs[i] = get_preferred_dac(codec, pin);
+ if (dacs[i]) {
+ if (is_dac_already_used(codec, dacs[i]))
+ badness += bad->shared_primary;
+ }
+
+ if (!dacs[i])
+ dacs[i] = look_for_dac(codec, pin, false);
if (!dacs[i] && !i) {
/* try to steal the DAC of surrounds for the front */
for (j = 1; j < num_outs; j++) {
--- a/sound/pci/hda/hda_generic.h
+++ b/sound/pci/hda/hda_generic.h
@@ -249,6 +249,9 @@ struct hda_gen_spec {
const struct badness_table *main_out_badness;
const struct badness_table *extra_out_badness;
+ /* preferred pin/DAC pairs; an array of paired NIDs */
+ const hda_nid_t *preferred_dacs;
+
/* loopback mixing mode */
bool aamix_mode;
--- a/sound/pci/hda/patch_analog.c
+++ b/sound/pci/hda/patch_analog.c
@@ -324,6 +324,14 @@ static int patch_ad1986a(struct hda_code
{
int err;
struct ad198x_spec *spec;
+ static hda_nid_t preferred_pairs[] = {
+ 0x1a, 0x03,
+ 0x1b, 0x03,
+ 0x1c, 0x04,
+ 0x1d, 0x05,
+ 0x1e, 0x03,
+ 0
+ };
err = alloc_ad_spec(codec);
if (err < 0)
@@ -344,6 +352,8 @@ static int patch_ad1986a(struct hda_code
* So, let's disable the shared stream.
*/
spec->gen.multiout.no_share_stream = 1;
+ /* give fixed DAC/pin pairs */
+ spec->gen.preferred_dacs = preferred_pairs;
/* AD1986A can't manage the dynamic pin on/off smoothly */
spec->gen.auto_mute_via_amp = 1;
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 006/118] ALSA: hda - Mute all aamix inputs as default
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2013-12-18 21:10 ` [PATCH 3.12 005/118] ALSA: hda - Add static DAC/pin mapping for AD1986A codec Greg Kroah-Hartman
@ 2013-12-18 21:10 ` Greg Kroah-Hartman
2013-12-18 21:10 ` [PATCH 3.12 007/118] ALSA: hda - hdmi: Fix IEC958 ctl indexes for some simple HDMI devices Greg Kroah-Hartman
` (110 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Takashi Iwai
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit ebb93c057dda376414fbc499ad6ace9b527dff5a upstream.
Not all channels have been initialized, so far, especially when aamix
NID itself doesn't have amps but its leaves have. This patch fixes
these holes. Otherwise you might get unexpected loopback inputs,
e.g. from surround channels.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/hda_generic.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
--- a/sound/pci/hda/hda_generic.c
+++ b/sound/pci/hda/hda_generic.c
@@ -4318,6 +4318,26 @@ static unsigned int snd_hda_gen_path_pow
return AC_PWRST_D3;
}
+/* mute all aamix inputs initially; parse up to the first leaves */
+static void mute_all_mixer_nid(struct hda_codec *codec, hda_nid_t mix)
+{
+ int i, nums;
+ const hda_nid_t *conn;
+ bool has_amp;
+
+ nums = snd_hda_get_conn_list(codec, mix, &conn);
+ has_amp = nid_has_mute(codec, mix, HDA_INPUT);
+ for (i = 0; i < nums; i++) {
+ if (has_amp)
+ snd_hda_codec_amp_stereo(codec, mix,
+ HDA_INPUT, i,
+ 0xff, HDA_AMP_MUTE);
+ else if (nid_has_volume(codec, conn[i], HDA_OUTPUT))
+ snd_hda_codec_amp_stereo(codec, conn[i],
+ HDA_OUTPUT, 0,
+ 0xff, HDA_AMP_MUTE);
+ }
+}
/*
* Parse the given BIOS configuration and set up the hda_gen_spec
@@ -4456,6 +4476,10 @@ int snd_hda_gen_parse_auto_config(struct
}
}
+ /* mute all aamix input initially */
+ if (spec->mixer_nid)
+ mute_all_mixer_nid(codec, spec->mixer_nid);
+
dig_only:
parse_digital(codec);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 007/118] ALSA: hda - hdmi: Fix IEC958 ctl indexes for some simple HDMI devices
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2013-12-18 21:10 ` [PATCH 3.12 006/118] ALSA: hda - Mute all aamix inputs as default Greg Kroah-Hartman
@ 2013-12-18 21:10 ` Greg Kroah-Hartman
2013-12-18 21:10 ` [PATCH 3.12 008/118] ARM: pxa: tosa: fix keys mapping Greg Kroah-Hartman
` (109 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Anssi Hannula, Takashi Iwai
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anssi Hannula <anssi.hannula@iki.fi>
commit c9a6338aecdb92f9d015ecc26d203e54250bebbb upstream.
In case a single HDA card has both HDMI and S/PDIF outputs, the S/PDIF
outputs will have their IEC958 controls created starting from index 16
and the HDMI controls will be created starting from index 0.
However, HDMI simple_playback_build_controls() as used by old VIA and
NVIDIA codecs incorrectly requests the IEC958 controls to be created
with an S/PDIF type instead of HDMI.
In case the card has other codecs that have HDMI outputs, the controls
will be created with wrong index=16, causing them to e.g. be unreachable
by the ALSA "hdmi" alias.
Fix that by making simple_playback_build_controls() request controls
with HDMI indexes.
Not many cards have an affected configuration, but e.g. ASUS M3N78-VM
contains an integrated NVIDIA HDA "card" with:
- a VIA codec that has, among others, an S/PDIF pin incorrectly
labelled as an HDMI pin, and
- an NVIDIA MCP7x HDMI codec.
Reported-by: MysterX on #openelec
Tested-by: MysterX on #openelec
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_hdmi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -2085,8 +2085,9 @@ static int simple_playback_build_control
int err;
per_cvt = get_cvt(spec, 0);
- err = snd_hda_create_spdif_out_ctls(codec, per_cvt->cvt_nid,
- per_cvt->cvt_nid);
+ err = snd_hda_create_dig_out_ctls(codec, per_cvt->cvt_nid,
+ per_cvt->cvt_nid,
+ HDA_PCM_TYPE_HDMI);
if (err < 0)
return err;
return simple_hdmi_build_jack(codec, 0);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 008/118] ARM: pxa: tosa: fix keys mapping
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2013-12-18 21:10 ` [PATCH 3.12 007/118] ALSA: hda - hdmi: Fix IEC958 ctl indexes for some simple HDMI devices Greg Kroah-Hartman
@ 2013-12-18 21:10 ` Greg Kroah-Hartman
2013-12-18 21:10 ` [PATCH 3.12 009/118] ARM: highbank: handle soft poweroff and reset key events Greg Kroah-Hartman
` (108 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dmitry Eremin-Solenikov,
Haojian Zhuang, Olof Johansson
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
commit 506cac15ac86f204b83e3cfccde73eeb4e7c5f34 upstream.
When converting from tosa-keyboard driver to matrix keyboard, tosa keys
received extra 1 column shift. Replace that with correct values to make
keyboard work again.
Fixes: f69a6548c9d5 ('[ARM] pxa/tosa: make use of the matrix keypad driver')
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/mach-pxa/tosa.c | 102 +++++++++++++++++++++++------------------------
1 file changed, 51 insertions(+), 51 deletions(-)
--- a/arch/arm/mach-pxa/tosa.c
+++ b/arch/arm/mach-pxa/tosa.c
@@ -425,57 +425,57 @@ static struct platform_device tosa_power
* Tosa Keyboard
*/
static const uint32_t tosakbd_keymap[] = {
- KEY(0, 2, KEY_W),
- KEY(0, 6, KEY_K),
- KEY(0, 7, KEY_BACKSPACE),
- KEY(0, 8, KEY_P),
- KEY(1, 1, KEY_Q),
- KEY(1, 2, KEY_E),
- KEY(1, 3, KEY_T),
- KEY(1, 4, KEY_Y),
- KEY(1, 6, KEY_O),
- KEY(1, 7, KEY_I),
- KEY(1, 8, KEY_COMMA),
- KEY(2, 1, KEY_A),
- KEY(2, 2, KEY_D),
- KEY(2, 3, KEY_G),
- KEY(2, 4, KEY_U),
- KEY(2, 6, KEY_L),
- KEY(2, 7, KEY_ENTER),
- KEY(2, 8, KEY_DOT),
- KEY(3, 1, KEY_Z),
- KEY(3, 2, KEY_C),
- KEY(3, 3, KEY_V),
- KEY(3, 4, KEY_J),
- KEY(3, 5, TOSA_KEY_ADDRESSBOOK),
- KEY(3, 6, TOSA_KEY_CANCEL),
- KEY(3, 7, TOSA_KEY_CENTER),
- KEY(3, 8, TOSA_KEY_OK),
- KEY(3, 9, KEY_LEFTSHIFT),
- KEY(4, 1, KEY_S),
- KEY(4, 2, KEY_R),
- KEY(4, 3, KEY_B),
- KEY(4, 4, KEY_N),
- KEY(4, 5, TOSA_KEY_CALENDAR),
- KEY(4, 6, TOSA_KEY_HOMEPAGE),
- KEY(4, 7, KEY_LEFTCTRL),
- KEY(4, 8, TOSA_KEY_LIGHT),
- KEY(4, 10, KEY_RIGHTSHIFT),
- KEY(5, 1, KEY_TAB),
- KEY(5, 2, KEY_SLASH),
- KEY(5, 3, KEY_H),
- KEY(5, 4, KEY_M),
- KEY(5, 5, TOSA_KEY_MENU),
- KEY(5, 7, KEY_UP),
- KEY(5, 11, TOSA_KEY_FN),
- KEY(6, 1, KEY_X),
- KEY(6, 2, KEY_F),
- KEY(6, 3, KEY_SPACE),
- KEY(6, 4, KEY_APOSTROPHE),
- KEY(6, 5, TOSA_KEY_MAIL),
- KEY(6, 6, KEY_LEFT),
- KEY(6, 7, KEY_DOWN),
- KEY(6, 8, KEY_RIGHT),
+ KEY(0, 1, KEY_W),
+ KEY(0, 5, KEY_K),
+ KEY(0, 6, KEY_BACKSPACE),
+ KEY(0, 7, KEY_P),
+ KEY(1, 0, KEY_Q),
+ KEY(1, 1, KEY_E),
+ KEY(1, 2, KEY_T),
+ KEY(1, 3, KEY_Y),
+ KEY(1, 5, KEY_O),
+ KEY(1, 6, KEY_I),
+ KEY(1, 7, KEY_COMMA),
+ KEY(2, 0, KEY_A),
+ KEY(2, 1, KEY_D),
+ KEY(2, 2, KEY_G),
+ KEY(2, 3, KEY_U),
+ KEY(2, 5, KEY_L),
+ KEY(2, 6, KEY_ENTER),
+ KEY(2, 7, KEY_DOT),
+ KEY(3, 0, KEY_Z),
+ KEY(3, 1, KEY_C),
+ KEY(3, 2, KEY_V),
+ KEY(3, 3, KEY_J),
+ KEY(3, 4, TOSA_KEY_ADDRESSBOOK),
+ KEY(3, 5, TOSA_KEY_CANCEL),
+ KEY(3, 6, TOSA_KEY_CENTER),
+ KEY(3, 7, TOSA_KEY_OK),
+ KEY(3, 8, KEY_LEFTSHIFT),
+ KEY(4, 0, KEY_S),
+ KEY(4, 1, KEY_R),
+ KEY(4, 2, KEY_B),
+ KEY(4, 3, KEY_N),
+ KEY(4, 4, TOSA_KEY_CALENDAR),
+ KEY(4, 5, TOSA_KEY_HOMEPAGE),
+ KEY(4, 6, KEY_LEFTCTRL),
+ KEY(4, 7, TOSA_KEY_LIGHT),
+ KEY(4, 9, KEY_RIGHTSHIFT),
+ KEY(5, 0, KEY_TAB),
+ KEY(5, 1, KEY_SLASH),
+ KEY(5, 2, KEY_H),
+ KEY(5, 3, KEY_M),
+ KEY(5, 4, TOSA_KEY_MENU),
+ KEY(5, 6, KEY_UP),
+ KEY(5, 10, TOSA_KEY_FN),
+ KEY(6, 0, KEY_X),
+ KEY(6, 1, KEY_F),
+ KEY(6, 2, KEY_SPACE),
+ KEY(6, 3, KEY_APOSTROPHE),
+ KEY(6, 4, TOSA_KEY_MAIL),
+ KEY(6, 5, KEY_LEFT),
+ KEY(6, 6, KEY_DOWN),
+ KEY(6, 7, KEY_RIGHT),
};
static struct matrix_keymap_data tosakbd_keymap_data = {
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 009/118] ARM: highbank: handle soft poweroff and reset key events
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2013-12-18 21:10 ` [PATCH 3.12 008/118] ARM: pxa: tosa: fix keys mapping Greg Kroah-Hartman
@ 2013-12-18 21:10 ` Greg Kroah-Hartman
2013-12-18 21:10 ` [PATCH 3.12 010/118] ARM: sun6i: dt: Fix interrupt trigger types Greg Kroah-Hartman
` (107 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Rob Herring, Olof Johansson
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rob Herring <rob.herring@calxeda.com>
commit 3843114856728075d0a80e7151197c19fb3a9e08 upstream.
Graceful reboot and poweroff via IPMI commands to the management
processor don't work. Power and reset keys are events from the
management processor which are generated via IPC messages. Passing
the keys to userspace does not work as neither acpid nor a desktop
environment are present.
This adds a notifier handler for the IPC messages so the kernel can
handle the key events directly and IPMI graceful shutdown will work.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/mach-highbank/highbank.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -17,12 +17,15 @@
#include <linux/clkdev.h>
#include <linux/clocksource.h>
#include <linux/dma-mapping.h>
+#include <linux/input.h>
#include <linux/io.h>
#include <linux/irqchip.h>
+#include <linux/mailbox.h>
#include <linux/of.h>
#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <linux/of_address.h>
+#include <linux/reboot.h>
#include <linux/amba/bus.h>
#include <linux/clk-provider.h>
@@ -153,6 +156,24 @@ static struct notifier_block highbank_pl
.notifier_call = highbank_platform_notifier,
};
+static int hb_keys_notifier(struct notifier_block *nb, unsigned long event, void *data)
+{
+ u32 key = *(u32 *)data;
+
+ if (event != 0x1000)
+ return 0;
+
+ if (key == KEY_POWER)
+ orderly_poweroff(false);
+ else if (key == 0xffff)
+ ctrl_alt_del();
+
+ return 0;
+}
+static struct notifier_block hb_keys_nb = {
+ .notifier_call = hb_keys_notifier,
+};
+
static void __init highbank_init(void)
{
pm_power_off = highbank_power_off;
@@ -161,6 +182,8 @@ static void __init highbank_init(void)
bus_register_notifier(&platform_bus_type, &highbank_platform_nb);
bus_register_notifier(&amba_bustype, &highbank_amba_nb);
+ pl320_ipc_register_notifier(&hb_keys_nb);
+
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 010/118] ARM: sun6i: dt: Fix interrupt trigger types
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2013-12-18 21:10 ` [PATCH 3.12 009/118] ARM: highbank: handle soft poweroff and reset key events Greg Kroah-Hartman
@ 2013-12-18 21:10 ` Greg Kroah-Hartman
2013-12-18 21:10 ` [PATCH 3.12 011/118] ARM: pxa: prevent PXA270 occasional reboot freezes Greg Kroah-Hartman
` (106 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Maxime Ripard, Hans de Goede, Olof Johansson
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maxime Ripard <maxime.ripard@free-electrons.com>
commit 6f97dc8d4663abed96fa30e3ea4a1d4cfd1c4276 upstream.
The Allwinner A31 uses the ARM GIC as its internal interrupts controller. The
GIC can work on several interrupt triggers, and the A31 was actually setting it
up to use a rising edge as a trigger, while it was actually a level high
trigger, leading to some interrupts that would be completely ignored if the
edge was missed.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/sun6i-a31.dtsi | 27 +++++++++++++++------------
1 file changed, 15 insertions(+), 12 deletions(-)
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -193,7 +193,10 @@
pio: pinctrl@01c20800 {
compatible = "allwinner,sun6i-a31-pinctrl";
reg = <0x01c20800 0x400>;
- interrupts = <0 11 1>, <0 15 1>, <0 16 1>, <0 17 1>;
+ interrupts = <0 11 4>,
+ <0 15 4>,
+ <0 16 4>,
+ <0 17 4>;
clocks = <&apb1_gates 5>;
gpio-controller;
interrupt-controller;
@@ -212,11 +215,11 @@
timer@01c20c00 {
compatible = "allwinner,sun4i-timer";
reg = <0x01c20c00 0xa0>;
- interrupts = <0 18 1>,
- <0 19 1>,
- <0 20 1>,
- <0 21 1>,
- <0 22 1>;
+ interrupts = <0 18 4>,
+ <0 19 4>,
+ <0 20 4>,
+ <0 21 4>,
+ <0 22 4>;
clocks = <&osc24M>;
};
@@ -228,7 +231,7 @@
uart0: serial@01c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
- interrupts = <0 0 1>;
+ interrupts = <0 0 4>;
reg-shift = <2>;
reg-io-width = <4>;
clocks = <&apb2_gates 16>;
@@ -238,7 +241,7 @@
uart1: serial@01c28400 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28400 0x400>;
- interrupts = <0 1 1>;
+ interrupts = <0 1 4>;
reg-shift = <2>;
reg-io-width = <4>;
clocks = <&apb2_gates 17>;
@@ -248,7 +251,7 @@
uart2: serial@01c28800 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28800 0x400>;
- interrupts = <0 2 1>;
+ interrupts = <0 2 4>;
reg-shift = <2>;
reg-io-width = <4>;
clocks = <&apb2_gates 18>;
@@ -258,7 +261,7 @@
uart3: serial@01c28c00 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28c00 0x400>;
- interrupts = <0 3 1>;
+ interrupts = <0 3 4>;
reg-shift = <2>;
reg-io-width = <4>;
clocks = <&apb2_gates 19>;
@@ -268,7 +271,7 @@
uart4: serial@01c29000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c29000 0x400>;
- interrupts = <0 4 1>;
+ interrupts = <0 4 4>;
reg-shift = <2>;
reg-io-width = <4>;
clocks = <&apb2_gates 20>;
@@ -278,7 +281,7 @@
uart5: serial@01c29400 {
compatible = "snps,dw-apb-uart";
reg = <0x01c29400 0x400>;
- interrupts = <0 5 1>;
+ interrupts = <0 5 4>;
reg-shift = <2>;
reg-io-width = <4>;
clocks = <&apb2_gates 21>;
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 011/118] ARM: pxa: prevent PXA270 occasional reboot freezes
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2013-12-18 21:10 ` [PATCH 3.12 010/118] ARM: sun6i: dt: Fix interrupt trigger types Greg Kroah-Hartman
@ 2013-12-18 21:10 ` Greg Kroah-Hartman
2013-12-18 21:10 ` [PATCH 3.12 012/118] ARM: OMAP3: hwmod data: Dont prevent RESET of USB Host module Greg Kroah-Hartman
` (105 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sergei Ianovich, Marek Vasut,
Haojian Zhuang, Olof Johansson
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergei Ianovich <ynvich@gmail.com>
commit ff88b4724fde18056a4c539f7327389aec0f4c2d upstream.
Erratum 71 of PXA270M Processor Family Specification Update
(April 19, 2010) explains that watchdog reset time is just
8us insead of 10ms in EMTS.
If SDRAM is not reset, it causes memory bus congestion and
the device hangs. We put SDRAM in selfresh mode before watchdog
reset, removing potential freezes.
Without this patch PXA270-based ICP DAS LP-8x4x hangs after up to 40
reboots. With this patch it has successfully rebooted 500 times.
Signed-off-by: Sergei Ianovich <ynvich@gmail.com>
Tested-by: Marek Vasut <marex@denx.de>
Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/mach-pxa/reset.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/arch/arm/mach-pxa/reset.c
+++ b/arch/arm/mach-pxa/reset.c
@@ -13,6 +13,7 @@
#include <mach/regs-ost.h>
#include <mach/reset.h>
+#include <mach/smemc.h>
unsigned int reset_status;
EXPORT_SYMBOL(reset_status);
@@ -81,6 +82,12 @@ static void do_hw_reset(void)
writel_relaxed(OSSR_M3, OSSR);
/* ... in 100 ms */
writel_relaxed(readl_relaxed(OSCR) + 368640, OSMR3);
+ /*
+ * SDRAM hangs on watchdog reset on Marvell PXA270 (erratum 71)
+ * we put SDRAM into self-refresh to prevent that
+ */
+ while (1)
+ writel_relaxed(MDREFR_SLFRSH, MDREFR);
}
void pxa_restart(enum reboot_mode mode, const char *cmd)
@@ -104,4 +111,3 @@ void pxa_restart(enum reboot_mode mode,
break;
}
}
-
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 012/118] ARM: OMAP3: hwmod data: Dont prevent RESET of USB Host module
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2013-12-18 21:10 ` [PATCH 3.12 011/118] ARM: pxa: prevent PXA270 occasional reboot freezes Greg Kroah-Hartman
@ 2013-12-18 21:10 ` Greg Kroah-Hartman
2013-12-18 21:10 ` [PATCH 3.12 013/118] ARM: 7912/1: check stack pointer in get_wchan Greg Kroah-Hartman
` (104 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Roger Quadros, Paul Walmsley
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Roger Quadros <rogerq@ti.com>
commit 7f4d3641e2548d1ac5dee837ff434df668a2810c upstream.
Unlike what the comment states, errata i660 does not state that we
can't RESET the USB host module. Instead it states that RESET is the
only way to recover from a deadlock situation.
RESET ensures that the module is in a known good state irrespective
of what bootloader does with the module, so it must be done at boot.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com> # Panda, BeagleXM
Fixes: de231388cb80 ("ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3")
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1943,7 +1943,8 @@ static struct omap_hwmod_class_sysconfig
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
SYSC_HAS_SIDLEMODE | SYSC_HAS_ENAWAKEUP |
- SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE |
+ SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
.sysc_fields = &omap_hwmod_sysc_type1,
@@ -2021,15 +2022,7 @@ static struct omap_hwmod omap3xxx_usb_ho
* hence HWMOD_SWSUP_MSTANDBY
*/
- /*
- * During system boot; If the hwmod framework resets the module
- * the module will have smart idle settings; which can lead to deadlock
- * (above Errata Id:i660); so, dont reset the module during boot;
- * Use HWMOD_INIT_NO_RESET.
- */
-
- .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
- HWMOD_INIT_NO_RESET,
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
};
/*
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 013/118] ARM: 7912/1: check stack pointer in get_wchan
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2013-12-18 21:10 ` [PATCH 3.12 012/118] ARM: OMAP3: hwmod data: Dont prevent RESET of USB Host module Greg Kroah-Hartman
@ 2013-12-18 21:10 ` Greg Kroah-Hartman
2013-12-18 21:10 ` [PATCH 3.12 014/118] ARM: 7913/1: fix framepointer check in unwind_frame Greg Kroah-Hartman
` (103 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Konstantin Khlebnikov, Will Deacon,
Russell King
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Konstantin Khlebnikov <k.khlebnikov@samsung.com>
commit 1b15ec7a7427d4188ba91b9bbac696250a059d22 upstream.
get_wchan() is lockless. Task may wakeup at any time and change its own stack,
thus each next stack frame may be overwritten and filled with random stuff.
/proc/$pid/stack interface had been disabled for non-current tasks, see [1]
But 'wchan' still allows to trigger stack frame unwinding on volatile stack.
This patch fixes oops in unwind_frame() by adding stack pointer validation on
each step (as x86 code do), unwind_frame() already checks frame pointer.
Also I've found another report of this oops on stackoverflow (irony).
Link: http://www.spinics.net/lists/arm-kernel/msg110589.html [1]
Link: http://stackoverflow.com/questions/18479894/unwind-frame-cause-a-kernel-paging-error
Signed-off-by: Konstantin Khlebnikov <k.khlebnikov@samsung.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/kernel/process.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -404,6 +404,7 @@ EXPORT_SYMBOL(dump_fpu);
unsigned long get_wchan(struct task_struct *p)
{
struct stackframe frame;
+ unsigned long stack_page;
int count = 0;
if (!p || p == current || p->state == TASK_RUNNING)
return 0;
@@ -412,9 +413,11 @@ unsigned long get_wchan(struct task_stru
frame.sp = thread_saved_sp(p);
frame.lr = 0; /* recovered from the stack */
frame.pc = thread_saved_pc(p);
+ stack_page = (unsigned long)task_stack_page(p);
do {
- int ret = unwind_frame(&frame);
- if (ret < 0)
+ if (frame.sp < stack_page ||
+ frame.sp >= stack_page + THREAD_SIZE ||
+ unwind_frame(&frame) < 0)
return 0;
if (!in_sched_functions(frame.pc))
return frame.pc;
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 014/118] ARM: 7913/1: fix framepointer check in unwind_frame
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2013-12-18 21:10 ` [PATCH 3.12 013/118] ARM: 7912/1: check stack pointer in get_wchan Greg Kroah-Hartman
@ 2013-12-18 21:10 ` Greg Kroah-Hartman
2013-12-18 21:10 ` [PATCH 3.12 015/118] ARM: 7917/1: cacheflush: correctly limit range of memory region being flushed Greg Kroah-Hartman
` (102 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Konstantin Khlebnikov, Russell King
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Konstantin Khlebnikov <k.khlebnikov@samsung.com>
commit 3abb6671a9c04479c4bd026798a05f857393b7e2 upstream.
This patch fixes corner case when (fp + 4) overflows unsigned long,
for example: fp = 0xFFFFFFFF -> fp + 4 == 3.
Signed-off-by: Konstantin Khlebnikov <k.khlebnikov@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/kernel/stacktrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/kernel/stacktrace.c
+++ b/arch/arm/kernel/stacktrace.c
@@ -31,7 +31,7 @@ int notrace unwind_frame(struct stackfra
high = ALIGN(low, THREAD_SIZE);
/* check current frame pointer is within bounds */
- if (fp < (low + 12) || fp + 4 >= high)
+ if (fp < low + 12 || fp > high - 4)
return -EINVAL;
/* restore the registers from the stack frame */
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 015/118] ARM: 7917/1: cacheflush: correctly limit range of memory region being flushed
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2013-12-18 21:10 ` [PATCH 3.12 014/118] ARM: 7913/1: fix framepointer check in unwind_frame Greg Kroah-Hartman
@ 2013-12-18 21:10 ` Greg Kroah-Hartman
2013-12-18 21:10 ` [PATCH 3.12 016/118] KVM: Improve create VCPU parameter (CVE-2013-4587) Greg Kroah-Hartman
` (101 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christian Gmeiner, Will Deacon,
Jon Medhurst, Russell King
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jon Medhurst <tixy@linaro.org>
commit b31459adeab018b297541e288ac88873011da82a upstream.
The __do_cache_op function operates with a 'chunk' size of one page
but fails to limit the size of the final chunk so as to not exceed
the specified memory region. Fix this.
Reported-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Tested-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/kernel/traps.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -503,9 +503,10 @@ static inline int
__do_cache_op(unsigned long start, unsigned long end)
{
int ret;
- unsigned long chunk = PAGE_SIZE;
do {
+ unsigned long chunk = min(PAGE_SIZE, end - start);
+
if (signal_pending(current)) {
struct thread_info *ti = current_thread_info();
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 016/118] KVM: Improve create VCPU parameter (CVE-2013-4587)
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (14 preceding siblings ...)
2013-12-18 21:10 ` [PATCH 3.12 015/118] ARM: 7917/1: cacheflush: correctly limit range of memory region being flushed Greg Kroah-Hartman
@ 2013-12-18 21:10 ` Greg Kroah-Hartman
2013-12-18 21:10 ` [PATCH 3.12 017/118] KVM: x86: Fix potential divide by 0 in lapic (CVE-2013-6367) Greg Kroah-Hartman
` (100 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Andrew Honig, Paolo Bonzini
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Honig <ahonig@google.com>
commit 338c7dbadd2671189cec7faf64c84d01071b3f96 upstream.
In multiple functions the vcpu_id is used as an offset into a bitfield. Ag
malicious user could specify a vcpu_id greater than 255 in order to set or
clear bits in kernel memory. This could be used to elevate priveges in the
kernel. This patch verifies that the vcpu_id provided is less than 255.
The api documentation already specifies that the vcpu_id must be less than
max_vcpus, but this is currently not checked.
Reported-by: Andrew Honig <ahonig@google.com>
Signed-off-by: Andrew Honig <ahonig@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
virt/kvm/kvm_main.c | 3 +++
1 file changed, 3 insertions(+)
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1893,6 +1893,9 @@ static int kvm_vm_ioctl_create_vcpu(stru
int r;
struct kvm_vcpu *vcpu, *v;
+ if (id >= KVM_MAX_VCPUS)
+ return -EINVAL;
+
vcpu = kvm_arch_vcpu_create(kvm, id);
if (IS_ERR(vcpu))
return PTR_ERR(vcpu);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 017/118] KVM: x86: Fix potential divide by 0 in lapic (CVE-2013-6367)
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (15 preceding siblings ...)
2013-12-18 21:10 ` [PATCH 3.12 016/118] KVM: Improve create VCPU parameter (CVE-2013-4587) Greg Kroah-Hartman
@ 2013-12-18 21:10 ` Greg Kroah-Hartman
2013-12-18 21:10 ` [PATCH 3.12 018/118] KVM: x86: Convert vapic synchronization to _cached functions (CVE-2013-6368) Greg Kroah-Hartman
` (99 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Andrew Honig, Paolo Bonzini
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Honig <ahonig@google.com>
commit b963a22e6d1a266a67e9eecc88134713fd54775c upstream.
Under guest controllable circumstances apic_get_tmcct will execute a
divide by zero and cause a crash. If the guest cpuid support
tsc deadline timers and performs the following sequence of requests
the host will crash.
- Set the mode to periodic
- Set the TMICT to 0
- Set the mode bits to 11 (neither periodic, nor one shot, nor tsc deadline)
- Set the TMICT to non-zero.
Then the lapic_timer.period will be 0, but the TMICT will not be. If the
guest then reads from the TMCCT then the host will perform a divide by 0.
This patch ensures that if the lapic_timer.period is 0, then the division
does not occur.
Reported-by: Andrew Honig <ahonig@google.com>
Signed-off-by: Andrew Honig <ahonig@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/lapic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -841,7 +841,8 @@ static u32 apic_get_tmcct(struct kvm_lap
ASSERT(apic != NULL);
/* if initial count is 0, current count should also be 0 */
- if (kvm_apic_get_reg(apic, APIC_TMICT) == 0)
+ if (kvm_apic_get_reg(apic, APIC_TMICT) == 0 ||
+ apic->lapic_timer.period == 0)
return 0;
remaining = hrtimer_get_remaining(&apic->lapic_timer.timer);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 018/118] KVM: x86: Convert vapic synchronization to _cached functions (CVE-2013-6368)
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (16 preceding siblings ...)
2013-12-18 21:10 ` [PATCH 3.12 017/118] KVM: x86: Fix potential divide by 0 in lapic (CVE-2013-6367) Greg Kroah-Hartman
@ 2013-12-18 21:10 ` Greg Kroah-Hartman
2013-12-18 21:10 ` [PATCH 3.12 019/118] KVM: x86: fix guest-initiated crash with x2apic (CVE-2013-6376) Greg Kroah-Hartman
` (98 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Andrew Honig, Paolo Bonzini
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Honig <ahonig@google.com>
commit fda4e2e85589191b123d31cdc21fd33ee70f50fd upstream.
In kvm_lapic_sync_from_vapic and kvm_lapic_sync_to_vapic there is the
potential to corrupt kernel memory if userspace provides an address that
is at the end of a page. This patches concerts those functions to use
kvm_write_guest_cached and kvm_read_guest_cached. It also checks the
vapic_address specified by userspace during ioctl processing and returns
an error to userspace if the address is not a valid GPA.
This is generally not guest triggerable, because the required write is
done by firmware that runs before the guest. Also, it only affects AMD
processors and oldish Intel that do not have the FlexPriority feature
(unless you disable FlexPriority, of course; then newer processors are
also affected).
Fixes: b93463aa59d6 ('KVM: Accelerated apic support')
Reported-by: Andrew Honig <ahonig@google.com>
Signed-off-by: Andrew Honig <ahonig@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/lapic.c | 27 +++++++++++++++------------
arch/x86/kvm/lapic.h | 4 ++--
arch/x86/kvm/x86.c | 40 +---------------------------------------
3 files changed, 18 insertions(+), 53 deletions(-)
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1692,7 +1692,6 @@ static void apic_sync_pv_eoi_from_guest(
void kvm_lapic_sync_from_vapic(struct kvm_vcpu *vcpu)
{
u32 data;
- void *vapic;
if (test_bit(KVM_APIC_PV_EOI_PENDING, &vcpu->arch.apic_attention))
apic_sync_pv_eoi_from_guest(vcpu, vcpu->arch.apic);
@@ -1700,9 +1699,8 @@ void kvm_lapic_sync_from_vapic(struct kv
if (!test_bit(KVM_APIC_CHECK_VAPIC, &vcpu->arch.apic_attention))
return;
- vapic = kmap_atomic(vcpu->arch.apic->vapic_page);
- data = *(u32 *)(vapic + offset_in_page(vcpu->arch.apic->vapic_addr));
- kunmap_atomic(vapic);
+ kvm_read_guest_cached(vcpu->kvm, &vcpu->arch.apic->vapic_cache, &data,
+ sizeof(u32));
apic_set_tpr(vcpu->arch.apic, data & 0xff);
}
@@ -1738,7 +1736,6 @@ void kvm_lapic_sync_to_vapic(struct kvm_
u32 data, tpr;
int max_irr, max_isr;
struct kvm_lapic *apic = vcpu->arch.apic;
- void *vapic;
apic_sync_pv_eoi_to_guest(vcpu, apic);
@@ -1754,18 +1751,24 @@ void kvm_lapic_sync_to_vapic(struct kvm_
max_isr = 0;
data = (tpr & 0xff) | ((max_isr & 0xf0) << 8) | (max_irr << 24);
- vapic = kmap_atomic(vcpu->arch.apic->vapic_page);
- *(u32 *)(vapic + offset_in_page(vcpu->arch.apic->vapic_addr)) = data;
- kunmap_atomic(vapic);
+ kvm_write_guest_cached(vcpu->kvm, &vcpu->arch.apic->vapic_cache, &data,
+ sizeof(u32));
}
-void kvm_lapic_set_vapic_addr(struct kvm_vcpu *vcpu, gpa_t vapic_addr)
+int kvm_lapic_set_vapic_addr(struct kvm_vcpu *vcpu, gpa_t vapic_addr)
{
- vcpu->arch.apic->vapic_addr = vapic_addr;
- if (vapic_addr)
+ if (vapic_addr) {
+ if (kvm_gfn_to_hva_cache_init(vcpu->kvm,
+ &vcpu->arch.apic->vapic_cache,
+ vapic_addr, sizeof(u32)))
+ return -EINVAL;
__set_bit(KVM_APIC_CHECK_VAPIC, &vcpu->arch.apic_attention);
- else
+ } else {
__clear_bit(KVM_APIC_CHECK_VAPIC, &vcpu->arch.apic_attention);
+ }
+
+ vcpu->arch.apic->vapic_addr = vapic_addr;
+ return 0;
}
int kvm_x2apic_msr_write(struct kvm_vcpu *vcpu, u32 msr, u64 data)
--- a/arch/x86/kvm/lapic.h
+++ b/arch/x86/kvm/lapic.h
@@ -34,7 +34,7 @@ struct kvm_lapic {
*/
void *regs;
gpa_t vapic_addr;
- struct page *vapic_page;
+ struct gfn_to_hva_cache vapic_cache;
unsigned long pending_events;
unsigned int sipi_vector;
};
@@ -76,7 +76,7 @@ void kvm_set_lapic_tscdeadline_msr(struc
void kvm_apic_write_nodecode(struct kvm_vcpu *vcpu, u32 offset);
void kvm_apic_set_eoi_accelerated(struct kvm_vcpu *vcpu, int vector);
-void kvm_lapic_set_vapic_addr(struct kvm_vcpu *vcpu, gpa_t vapic_addr);
+int kvm_lapic_set_vapic_addr(struct kvm_vcpu *vcpu, gpa_t vapic_addr);
void kvm_lapic_sync_from_vapic(struct kvm_vcpu *vcpu);
void kvm_lapic_sync_to_vapic(struct kvm_vcpu *vcpu);
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3192,8 +3192,7 @@ long kvm_arch_vcpu_ioctl(struct file *fi
r = -EFAULT;
if (copy_from_user(&va, argp, sizeof va))
goto out;
- r = 0;
- kvm_lapic_set_vapic_addr(vcpu, va.vapic_addr);
+ r = kvm_lapic_set_vapic_addr(vcpu, va.vapic_addr);
break;
}
case KVM_X86_SETUP_MCE: {
@@ -5718,36 +5717,6 @@ static void post_kvm_run_save(struct kvm
!kvm_event_needs_reinjection(vcpu);
}
-static int vapic_enter(struct kvm_vcpu *vcpu)
-{
- struct kvm_lapic *apic = vcpu->arch.apic;
- struct page *page;
-
- if (!apic || !apic->vapic_addr)
- return 0;
-
- page = gfn_to_page(vcpu->kvm, apic->vapic_addr >> PAGE_SHIFT);
- if (is_error_page(page))
- return -EFAULT;
-
- vcpu->arch.apic->vapic_page = page;
- return 0;
-}
-
-static void vapic_exit(struct kvm_vcpu *vcpu)
-{
- struct kvm_lapic *apic = vcpu->arch.apic;
- int idx;
-
- if (!apic || !apic->vapic_addr)
- return;
-
- idx = srcu_read_lock(&vcpu->kvm->srcu);
- kvm_release_page_dirty(apic->vapic_page);
- mark_page_dirty(vcpu->kvm, apic->vapic_addr >> PAGE_SHIFT);
- srcu_read_unlock(&vcpu->kvm->srcu, idx);
-}
-
static void update_cr8_intercept(struct kvm_vcpu *vcpu)
{
int max_irr, tpr;
@@ -6047,11 +6016,6 @@ static int __vcpu_run(struct kvm_vcpu *v
struct kvm *kvm = vcpu->kvm;
vcpu->srcu_idx = srcu_read_lock(&kvm->srcu);
- r = vapic_enter(vcpu);
- if (r) {
- srcu_read_unlock(&kvm->srcu, vcpu->srcu_idx);
- return r;
- }
r = 1;
while (r > 0) {
@@ -6110,8 +6074,6 @@ static int __vcpu_run(struct kvm_vcpu *v
srcu_read_unlock(&kvm->srcu, vcpu->srcu_idx);
- vapic_exit(vcpu);
-
return r;
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 019/118] KVM: x86: fix guest-initiated crash with x2apic (CVE-2013-6376)
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (17 preceding siblings ...)
2013-12-18 21:10 ` [PATCH 3.12 018/118] KVM: x86: Convert vapic synchronization to _cached functions (CVE-2013-6368) Greg Kroah-Hartman
@ 2013-12-18 21:10 ` Greg Kroah-Hartman
2013-12-18 21:10 ` [PATCH 3.12 020/118] hwmon: Prevent some divide by zeros in FAN_TO_REG() Greg Kroah-Hartman
` (97 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lars Bull, Gleb Natapov, Paolo Bonzini
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gleb Natapov <gleb@redhat.com>
commit 17d68b763f09a9ce824ae23eb62c9efc57b69271 upstream.
A guest can cause a BUG_ON() leading to a host kernel crash.
When the guest writes to the ICR to request an IPI, while in x2apic
mode the following things happen, the destination is read from
ICR2, which is a register that the guest can control.
kvm_irq_delivery_to_apic_fast uses the high 16 bits of ICR2 as the
cluster id. A BUG_ON is triggered, which is a protection against
accessing map->logical_map with an out-of-bounds access and manages
to avoid that anything really unsafe occurs.
The logic in the code is correct from real HW point of view. The problem
is that KVM supports only one cluster with ID 0 in clustered mode, but
the code that has the bug does not take this into account.
Reported-by: Lars Bull <larsbull@google.com>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/lapic.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -143,6 +143,8 @@ static inline int kvm_apic_id(struct kvm
return (kvm_apic_get_reg(apic, APIC_ID) >> 24) & 0xff;
}
+#define KVM_X2APIC_CID_BITS 0
+
static void recalculate_apic_map(struct kvm *kvm)
{
struct kvm_apic_map *new, *old = NULL;
@@ -180,7 +182,8 @@ static void recalculate_apic_map(struct
if (apic_x2apic_mode(apic)) {
new->ldr_bits = 32;
new->cid_shift = 16;
- new->cid_mask = new->lid_mask = 0xffff;
+ new->cid_mask = (1 << KVM_X2APIC_CID_BITS) - 1;
+ new->lid_mask = 0xffff;
} else if (kvm_apic_sw_enabled(apic) &&
!new->cid_mask /* flat mode */ &&
kvm_apic_get_reg(apic, APIC_DFR) == APIC_DFR_CLUSTER) {
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 020/118] hwmon: Prevent some divide by zeros in FAN_TO_REG()
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (18 preceding siblings ...)
2013-12-18 21:10 ` [PATCH 3.12 019/118] KVM: x86: fix guest-initiated crash with x2apic (CVE-2013-6376) Greg Kroah-Hartman
@ 2013-12-18 21:10 ` Greg Kroah-Hartman
2013-12-18 21:10 ` [PATCH 3.12 022/118] hwmon: (w83l786ng) Fix fan speed control mode setting and reporting Greg Kroah-Hartman
` (96 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Roger Lucas, Jean Delvare
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 3806b45ba4655147a011df03242cc197ab986c43 upstream.
The "rpm * div" operations can overflow here, so this patch adds an
upper limit to rpm to prevent that. Jean Delvare helped me with this
patch.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Roger Lucas <vt8231@hiddenengine.co.uk>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hwmon/lm78.c | 2 ++
drivers/hwmon/sis5595.c | 2 ++
drivers/hwmon/vt8231.c | 2 +-
3 files changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/hwmon/lm78.c
+++ b/drivers/hwmon/lm78.c
@@ -94,6 +94,8 @@ static inline u8 FAN_TO_REG(long rpm, in
{
if (rpm <= 0)
return 255;
+ if (rpm > 1350000)
+ return 1;
return clamp_val((1350000 + rpm * div / 2) / (rpm * div), 1, 254);
}
--- a/drivers/hwmon/sis5595.c
+++ b/drivers/hwmon/sis5595.c
@@ -141,6 +141,8 @@ static inline u8 FAN_TO_REG(long rpm, in
{
if (rpm <= 0)
return 255;
+ if (rpm > 1350000)
+ return 1;
return clamp_val((1350000 + rpm * div / 2) / (rpm * div), 1, 254);
}
--- a/drivers/hwmon/vt8231.c
+++ b/drivers/hwmon/vt8231.c
@@ -145,7 +145,7 @@ static const u8 regtempmin[] = { 0x3a, 0
*/
static inline u8 FAN_TO_REG(long rpm, int div)
{
- if (rpm == 0)
+ if (rpm <= 0 || rpm > 1310720)
return 0;
return clamp_val(1310720 / (rpm * div), 1, 255);
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 022/118] hwmon: (w83l786ng) Fix fan speed control mode setting and reporting
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (19 preceding siblings ...)
2013-12-18 21:10 ` [PATCH 3.12 020/118] hwmon: Prevent some divide by zeros in FAN_TO_REG() Greg Kroah-Hartman
@ 2013-12-18 21:10 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 023/118] hwmon: (w83l768ng) Fix fan speed control range Greg Kroah-Hartman
` (95 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Brian Carnes, Jean Delvare
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brian Carnes <bmcarnes@gmail.com>
commit cf7559bc053471f32373d71d04a9aa19e0b48d59 upstream.
The wrong mask is used, which causes some fan speed control modes
(pwmX_enable) to be incorrectly reported, and some modes to be
impossible to set.
[JD: add subject and description.]
Signed-off-by: Brian Carnes <bmcarnes@gmail.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hwmon/w83l786ng.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/hwmon/w83l786ng.c
+++ b/drivers/hwmon/w83l786ng.c
@@ -510,7 +510,7 @@ store_pwm_enable(struct device *dev, str
mutex_lock(&data->update_lock);
reg = w83l786ng_read_value(client, W83L786NG_REG_FAN_CFG);
data->pwm_enable[nr] = val;
- reg &= ~(0x02 << W83L786NG_PWM_ENABLE_SHIFT[nr]);
+ reg &= ~(0x03 << W83L786NG_PWM_ENABLE_SHIFT[nr]);
reg |= (val - 1) << W83L786NG_PWM_ENABLE_SHIFT[nr];
w83l786ng_write_value(client, W83L786NG_REG_FAN_CFG, reg);
mutex_unlock(&data->update_lock);
@@ -776,7 +776,7 @@ static struct w83l786ng_data *w83l786ng_
((pwmcfg >> W83L786NG_PWM_MODE_SHIFT[i]) & 1)
? 0 : 1;
data->pwm_enable[i] =
- ((pwmcfg >> W83L786NG_PWM_ENABLE_SHIFT[i]) & 2) + 1;
+ ((pwmcfg >> W83L786NG_PWM_ENABLE_SHIFT[i]) & 3) + 1;
data->pwm[i] = w83l786ng_read_value(client,
W83L786NG_REG_PWM[i]);
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 023/118] hwmon: (w83l768ng) Fix fan speed control range
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (20 preceding siblings ...)
2013-12-18 21:10 ` [PATCH 3.12 022/118] hwmon: (w83l786ng) Fix fan speed control mode setting and reporting Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 024/118] xfs: growfs overruns AGFL buffer on V4 filesystems Greg Kroah-Hartman
` (94 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jean Delvare, Guenter Roeck
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jean Delvare <khali@linux-fr.org>
commit 33a7ab91d509fa33b4bcd3ce0038cc80298050da upstream.
The W83L786NG stores the fan speed on 4 bits while the sysfs interface
uses a 0-255 range. Thus the driver should scale the user input down
to map it to the device range, and scale up the value read from the
device before presenting it to the user. The reserved register nibble
should be left unchanged.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hwmon/w83l786ng.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/drivers/hwmon/w83l786ng.c
+++ b/drivers/hwmon/w83l786ng.c
@@ -481,9 +481,11 @@ store_pwm(struct device *dev, struct dev
if (err)
return err;
val = clamp_val(val, 0, 255);
+ val = DIV_ROUND_CLOSEST(val, 0x11);
mutex_lock(&data->update_lock);
- data->pwm[nr] = val;
+ data->pwm[nr] = val * 0x11;
+ val |= w83l786ng_read_value(client, W83L786NG_REG_PWM[nr]) & 0xf0;
w83l786ng_write_value(client, W83L786NG_REG_PWM[nr], val);
mutex_unlock(&data->update_lock);
return count;
@@ -777,8 +779,9 @@ static struct w83l786ng_data *w83l786ng_
? 0 : 1;
data->pwm_enable[i] =
((pwmcfg >> W83L786NG_PWM_ENABLE_SHIFT[i]) & 3) + 1;
- data->pwm[i] = w83l786ng_read_value(client,
- W83L786NG_REG_PWM[i]);
+ data->pwm[i] =
+ (w83l786ng_read_value(client, W83L786NG_REG_PWM[i])
+ & 0x0f) * 0x11;
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 024/118] xfs: growfs overruns AGFL buffer on V4 filesystems
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (21 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 023/118] hwmon: (w83l768ng) Fix fan speed control range Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 025/118] xfs: underflow bug in xfs_attrlist_by_handle() Greg Kroah-Hartman
` (93 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Dave Chinner, Jie Liu, Ben Myers
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Chinner <dchinner@redhat.com>
commit f94c44573e7c22860e2c3dfe349c45f72ba35ad3 upstream.
This loop in xfs_growfs_data_private() is incorrect for V4
superblocks filesystems:
for (bucket = 0; bucket < XFS_AGFL_SIZE(mp); bucket++)
agfl->agfl_bno[bucket] = cpu_to_be32(NULLAGBLOCK);
For V4 filesystems, we don't have a agfl header structure, and so
XFS_AGFL_SIZE() returns an entire sector's worth of entries, which
we then index from an offset into the sector. Hence: buffer overrun.
This problem was introduced in 3.10 by commit 77c95bba ("xfs: add
CRC checks to the AGFL") which changed the AGFL structure but failed
to update the growfs code to handle the different structures.
Fix it by using the correct offset into the buffer for both V4 and
V5 filesystems.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Jie Liu <jeff.liu@oracle.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/xfs/xfs_fsops.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/fs/xfs/xfs_fsops.c
+++ b/fs/xfs/xfs_fsops.c
@@ -217,6 +217,8 @@ xfs_growfs_data_private(
*/
nfree = 0;
for (agno = nagcount - 1; agno >= oagcount; agno--, new -= agsize) {
+ __be32 *agfl_bno;
+
/*
* AG freespace header block
*/
@@ -276,8 +278,10 @@ xfs_growfs_data_private(
agfl->agfl_seqno = cpu_to_be32(agno);
uuid_copy(&agfl->agfl_uuid, &mp->m_sb.sb_uuid);
}
+
+ agfl_bno = XFS_BUF_TO_AGFL_BNO(mp, bp);
for (bucket = 0; bucket < XFS_AGFL_SIZE(mp); bucket++)
- agfl->agfl_bno[bucket] = cpu_to_be32(NULLAGBLOCK);
+ agfl_bno[bucket] = cpu_to_be32(NULLAGBLOCK);
error = xfs_bwrite(bp);
xfs_buf_relse(bp);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 025/118] xfs: underflow bug in xfs_attrlist_by_handle()
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (22 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 024/118] xfs: growfs overruns AGFL buffer on V4 filesystems Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 026/118] iwlwifi: pcie: fix interrupt coalescing for 7260 / 3160 Greg Kroah-Hartman
` (92 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nico Golde, Fabian Yamaguchi,
Dan Carpenter, Dave Chinner, Ben Myers
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 31978b5cc66b8ba8a7e8eef60b12395d41b7b890 upstream.
If we allocate less than sizeof(struct attrlist) then we end up
corrupting memory or doing a ZERO_PTR_SIZE dereference.
This can only be triggered with CAP_SYS_ADMIN.
Reported-by: Nico Golde <nico@ngolde.de>
Reported-by: Fabian Yamaguchi <fabs@goesec.de>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/xfs/xfs_ioctl.c | 3 ++-
fs/xfs/xfs_ioctl32.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
--- a/fs/xfs/xfs_ioctl.c
+++ b/fs/xfs/xfs_ioctl.c
@@ -443,7 +443,8 @@ xfs_attrlist_by_handle(
return -XFS_ERROR(EPERM);
if (copy_from_user(&al_hreq, arg, sizeof(xfs_fsop_attrlist_handlereq_t)))
return -XFS_ERROR(EFAULT);
- if (al_hreq.buflen > XATTR_LIST_MAX)
+ if (al_hreq.buflen < sizeof(struct attrlist) ||
+ al_hreq.buflen > XATTR_LIST_MAX)
return -XFS_ERROR(EINVAL);
/*
--- a/fs/xfs/xfs_ioctl32.c
+++ b/fs/xfs/xfs_ioctl32.c
@@ -357,7 +357,8 @@ xfs_compat_attrlist_by_handle(
if (copy_from_user(&al_hreq, arg,
sizeof(compat_xfs_fsop_attrlist_handlereq_t)))
return -XFS_ERROR(EFAULT);
- if (al_hreq.buflen > XATTR_LIST_MAX)
+ if (al_hreq.buflen < sizeof(struct attrlist) ||
+ al_hreq.buflen > XATTR_LIST_MAX)
return -XFS_ERROR(EINVAL);
/*
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 026/118] iwlwifi: pcie: fix interrupt coalescing for 7260 / 3160
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (23 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 025/118] xfs: underflow bug in xfs_attrlist_by_handle() Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 027/118] PCI: Disable Bus Master only on kexec reboot Greg Kroah-Hartman
` (91 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Johannes Berg, Emmanuel Grumbach
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
commit 6960a059b2c618f32fe549f13287b3d2278c09e9 upstream.
We changed the timeout for the interrupt coealescing for
calibration, but that wasn't effective since we changed
that value back before loading the firmware. Since
calibrations are notification from firmware and not Rx
packets, this doesn't change anyway - the firmware will
fire an interrupt straight away regardless of the interrupt
coalescing value.
Also, a HW issue has been discovered in 7000 devices series.
The work around is to disable the new interrupt coalescing
timeout feature - do this by setting bit 31 in
CSR_INT_COALESCING.
This has been fixed in 7265 which means that we can't rely
on the device family and must have a hint in the iwl_cfg
structure.
Fixes: 99cd47142399 ("iwlwifi: add 7000 series device configuration")
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/iwlwifi/iwl-7000.c | 7 +++++++
drivers/net/wireless/iwlwifi/iwl-config.h | 3 +++
drivers/net/wireless/iwlwifi/iwl-csr.h | 5 +----
drivers/net/wireless/iwlwifi/pcie/rx.c | 4 ++++
drivers/net/wireless/iwlwifi/pcie/trans.c | 3 ---
5 files changed, 15 insertions(+), 7 deletions(-)
--- a/drivers/net/wireless/iwlwifi/iwl-7000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-7000.c
@@ -125,6 +125,7 @@ const struct iwl_cfg iwl7260_2ac_cfg = {
.ht_params = &iwl7000_ht_params,
.nvm_ver = IWL7260_NVM_VERSION,
.nvm_calib_ver = IWL7260_TX_POWER_VERSION,
+ .host_interrupt_operation_mode = true,
};
const struct iwl_cfg iwl7260_2ac_cfg_high_temp = {
@@ -135,6 +136,7 @@ const struct iwl_cfg iwl7260_2ac_cfg_hig
.nvm_ver = IWL7260_NVM_VERSION,
.nvm_calib_ver = IWL7260_TX_POWER_VERSION,
.high_temp = true,
+ .host_interrupt_operation_mode = true,
};
const struct iwl_cfg iwl7260_2n_cfg = {
@@ -144,6 +146,7 @@ const struct iwl_cfg iwl7260_2n_cfg = {
.ht_params = &iwl7000_ht_params,
.nvm_ver = IWL7260_NVM_VERSION,
.nvm_calib_ver = IWL7260_TX_POWER_VERSION,
+ .host_interrupt_operation_mode = true,
};
const struct iwl_cfg iwl7260_n_cfg = {
@@ -153,6 +156,7 @@ const struct iwl_cfg iwl7260_n_cfg = {
.ht_params = &iwl7000_ht_params,
.nvm_ver = IWL7260_NVM_VERSION,
.nvm_calib_ver = IWL7260_TX_POWER_VERSION,
+ .host_interrupt_operation_mode = true,
};
const struct iwl_cfg iwl3160_2ac_cfg = {
@@ -162,6 +166,7 @@ const struct iwl_cfg iwl3160_2ac_cfg = {
.ht_params = &iwl7000_ht_params,
.nvm_ver = IWL3160_NVM_VERSION,
.nvm_calib_ver = IWL3160_TX_POWER_VERSION,
+ .host_interrupt_operation_mode = true,
};
const struct iwl_cfg iwl3160_2n_cfg = {
@@ -171,6 +176,7 @@ const struct iwl_cfg iwl3160_2n_cfg = {
.ht_params = &iwl7000_ht_params,
.nvm_ver = IWL3160_NVM_VERSION,
.nvm_calib_ver = IWL3160_TX_POWER_VERSION,
+ .host_interrupt_operation_mode = true,
};
const struct iwl_cfg iwl3160_n_cfg = {
@@ -180,6 +186,7 @@ const struct iwl_cfg iwl3160_n_cfg = {
.ht_params = &iwl7000_ht_params,
.nvm_ver = IWL3160_NVM_VERSION,
.nvm_calib_ver = IWL3160_TX_POWER_VERSION,
+ .host_interrupt_operation_mode = true,
};
MODULE_FIRMWARE(IWL7260_MODULE_FIRMWARE(IWL7260_UCODE_API_OK));
--- a/drivers/net/wireless/iwlwifi/iwl-config.h
+++ b/drivers/net/wireless/iwlwifi/iwl-config.h
@@ -207,6 +207,8 @@ struct iwl_eeprom_params {
* @rx_with_siso_diversity: 1x1 device with rx antenna diversity
* @internal_wimax_coex: internal wifi/wimax combo device
* @high_temp: Is this NIC is designated to be in high temperature.
+ * @host_interrupt_operation_mode: device needs host interrupt operation
+ * mode set
*
* We enable the driver to be backward compatible wrt. hardware features.
* API differences in uCode shouldn't be handled here but through TLVs
@@ -235,6 +237,7 @@ struct iwl_cfg {
enum iwl_led_mode led_mode;
const bool rx_with_siso_diversity;
const bool internal_wimax_coex;
+ const bool host_interrupt_operation_mode;
bool high_temp;
};
--- a/drivers/net/wireless/iwlwifi/iwl-csr.h
+++ b/drivers/net/wireless/iwlwifi/iwl-csr.h
@@ -463,14 +463,11 @@
* the CSR_INT_COALESCING is an 8 bit register in 32-usec unit
*
* default interrupt coalescing timer is 64 x 32 = 2048 usecs
- * default interrupt coalescing calibration timer is 16 x 32 = 512 usecs
*/
#define IWL_HOST_INT_TIMEOUT_MAX (0xFF)
#define IWL_HOST_INT_TIMEOUT_DEF (0x40)
#define IWL_HOST_INT_TIMEOUT_MIN (0x0)
-#define IWL_HOST_INT_CALIB_TIMEOUT_MAX (0xFF)
-#define IWL_HOST_INT_CALIB_TIMEOUT_DEF (0x10)
-#define IWL_HOST_INT_CALIB_TIMEOUT_MIN (0x0)
+#define IWL_HOST_INT_OPER_MODE BIT(31)
/*****************************************************************************
* 7000/3000 series SHR DTS addresses *
--- a/drivers/net/wireless/iwlwifi/pcie/rx.c
+++ b/drivers/net/wireless/iwlwifi/pcie/rx.c
@@ -489,6 +489,10 @@ static void iwl_pcie_rx_hw_init(struct i
/* Set interrupt coalescing timer to default (2048 usecs) */
iwl_write8(trans, CSR_INT_COALESCING, IWL_HOST_INT_TIMEOUT_DEF);
+
+ /* W/A for interrupt coalescing bug in 7260 and 3160 */
+ if (trans->cfg->host_interrupt_operation_mode)
+ iwl_set_bit(trans, CSR_INT_COALESCING, IWL_HOST_INT_OPER_MODE);
}
static void iwl_pcie_rx_init_rxb_lists(struct iwl_rxq *rxq)
--- a/drivers/net/wireless/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/iwlwifi/pcie/trans.c
@@ -276,9 +276,6 @@ static int iwl_pcie_nic_init(struct iwl_
spin_lock_irqsave(&trans_pcie->irq_lock, flags);
iwl_pcie_apm_init(trans);
- /* Set interrupt coalescing calibration timer to default (512 usecs) */
- iwl_write8(trans, CSR_INT_COALESCING, IWL_HOST_INT_CALIB_TIMEOUT_DEF);
-
spin_unlock_irqrestore(&trans_pcie->irq_lock, flags);
iwl_pcie_set_pwr(trans, false);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 027/118] PCI: Disable Bus Master only on kexec reboot
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (24 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 026/118] iwlwifi: pcie: fix interrupt coalescing for 7260 / 3160 Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 028/118] futex: fix handling of read-only-mapped hugepages Greg Kroah-Hartman
` (90 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Chang Liu, Khalid Aziz,
Bjorn Helgaas, Konstantin Khlebnikov
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Khalid Aziz <khalid.aziz@oracle.com>
commit 4fc9bbf98fd66f879e628d8537ba7c240be2b58e upstream.
Add a flag to tell the PCI subsystem that kernel is shutting down in
preparation to kexec a kernel. Add code in PCI subsystem to use this flag
to clear Bus Master bit on PCI devices only in case of kexec reboot.
This fixes a power-off problem on Acer Aspire V5-573G and likely other
machines and avoids any other issues caused by clearing Bus Master bit on
PCI devices in normal shutdown path. The problem was introduced by
b566a22c2332 ("PCI: disable Bus Master on PCI device shutdown").
This patch is based on discussion at
http://marc.info/?l=linux-pci&m=138425645204355&w=2
Link: https://bugzilla.kernel.org/show_bug.cgi?id=63861
Reported-by: Chang Liu <cl91tp@gmail.com>
Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Konstantin Khlebnikov <koct9i@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/pci-driver.c | 12 +++++++++---
include/linux/kexec.h | 3 +++
kernel/kexec.c | 4 ++++
3 files changed, 16 insertions(+), 3 deletions(-)
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -19,6 +19,7 @@
#include <linux/cpu.h>
#include <linux/pm_runtime.h>
#include <linux/suspend.h>
+#include <linux/kexec.h>
#include "pci.h"
struct pci_dynid {
@@ -388,12 +389,17 @@ static void pci_device_shutdown(struct d
pci_msi_shutdown(pci_dev);
pci_msix_shutdown(pci_dev);
+#ifdef CONFIG_KEXEC
/*
- * Turn off Bus Master bit on the device to tell it to not
- * continue to do DMA. Don't touch devices in D3cold or unknown states.
+ * If this is a kexec reboot, turn off Bus Master bit on the
+ * device to tell it to not continue to do DMA. Don't touch
+ * devices in D3cold or unknown states.
+ * If it is not a kexec reboot, firmware will hit the PCI
+ * devices with big hammer and stop their DMA any way.
*/
- if (pci_dev->current_state <= PCI_D3hot)
+ if (kexec_in_progress && (pci_dev->current_state <= PCI_D3hot))
pci_clear_master(pci_dev);
+#endif
}
#ifdef CONFIG_PM
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -198,6 +198,9 @@ extern u32 vmcoreinfo_note[VMCOREINFO_NO
extern size_t vmcoreinfo_size;
extern size_t vmcoreinfo_max_size;
+/* flag to track if kexec reboot is in progress */
+extern bool kexec_in_progress;
+
int __init parse_crashkernel(char *cmdline, unsigned long long system_ram,
unsigned long long *crash_size, unsigned long long *crash_base);
int parse_crashkernel_high(char *cmdline, unsigned long long system_ram,
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -47,6 +47,9 @@ u32 vmcoreinfo_note[VMCOREINFO_NOTE_SIZE
size_t vmcoreinfo_size;
size_t vmcoreinfo_max_size = sizeof(vmcoreinfo_data);
+/* Flag to indicate we are going to kexec a new kernel */
+bool kexec_in_progress = false;
+
/* Location of the reserved area for the crash kernel */
struct resource crashk_res = {
.name = "Crash kernel",
@@ -1675,6 +1678,7 @@ int kernel_kexec(void)
} else
#endif
{
+ kexec_in_progress = true;
kernel_restart_prepare(NULL);
printk(KERN_EMERG "Starting new kernel\n");
machine_shutdown();
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 028/118] futex: fix handling of read-only-mapped hugepages
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (25 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 027/118] PCI: Disable Bus Master only on kexec reboot Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 029/118] nfsd: when reusing an existing repcache entry, unhash it first Greg Kroah-Hartman
` (89 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Thomas Gleixner, Mel Gorman,
Darren Hart, Andrea Arcangeli, Oleg Nesterov, Linus Torvalds
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Torvalds <torvalds@linux-foundation.org>
commit f12d5bfceb7e1f9051563381ec047f7f13956c3c upstream.
The hugepage code had the exact same bug that regular pages had in
commit 7485d0d3758e ("futexes: Remove rw parameter from
get_futex_key()").
The regular page case was fixed by commit 9ea71503a8ed ("futex: Fix
regression with read only mappings"), but the transparent hugepage case
(added in a5b338f2b0b1: "thp: update futex compound knowledge") case
remained broken.
Found by Dave Jones and his trinity tool.
Reported-and-tested-by: Dave Jones <davej@fedoraproject.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Darren Hart <dvhart@linux.intel.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/futex.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -288,7 +288,7 @@ again:
put_page(page);
/* serialize against __split_huge_page_splitting() */
local_irq_disable();
- if (likely(__get_user_pages_fast(address, 1, 1, &page) == 1)) {
+ if (likely(__get_user_pages_fast(address, 1, !ro, &page) == 1)) {
page_head = compound_head(page);
/*
* page_head is valid pointer but we must pin
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 029/118] nfsd: when reusing an existing repcache entry, unhash it first
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (26 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 028/118] futex: fix handling of read-only-mapped hugepages Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 030/118] usb: hub: Use correct reset for wedged USB3 devices that are NOTATTACHED Greg Kroah-Hartman
` (88 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christoph Hellwig, g. artim,
Jeff Layton, J. Bruce Fields
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeff Layton <jlayton@redhat.com>
commit 781c2a5a5f75eacc04663aced0f0f1a648d4f308 upstream.
The DRC code will attempt to reuse an existing, expired cache entry in
preference to allocating a new one. It'll then search the cache, and if
it gets a hit it'll then free the cache entry that it was going to
reuse.
The cache code doesn't unhash the entry that it's going to reuse
however, so it's possible for it end up designating an entry for reuse
and then subsequently freeing the same entry after it finds it. This
leads it to a later use-after-free situation and usually some list
corruption warnings or an oops.
Fix this by simply unhashing the entry that we intend to reuse. That
will mean that it's not findable via a search and should prevent this
situation from occurring.
Reported-by: Christoph Hellwig <hch@infradead.org>
Reported-by: g. artim <gartim@gmail.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/nfsd/nfscache.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/fs/nfsd/nfscache.c
+++ b/fs/nfsd/nfscache.c
@@ -132,6 +132,13 @@ nfsd_reply_cache_alloc(void)
}
static void
+nfsd_reply_cache_unhash(struct svc_cacherep *rp)
+{
+ hlist_del_init(&rp->c_hash);
+ list_del_init(&rp->c_lru);
+}
+
+static void
nfsd_reply_cache_free_locked(struct svc_cacherep *rp)
{
if (rp->c_type == RC_REPLBUFF && rp->c_replvec.iov_base) {
@@ -417,7 +424,7 @@ nfsd_cache_lookup(struct svc_rqst *rqstp
rp = list_first_entry(&lru_head, struct svc_cacherep, c_lru);
if (nfsd_cache_entry_expired(rp) ||
num_drc_entries >= max_drc_entries) {
- lru_put_end(rp);
+ nfsd_reply_cache_unhash(rp);
prune_cache_entries();
goto search_cache;
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 030/118] usb: hub: Use correct reset for wedged USB3 devices that are NOTATTACHED
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (27 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 029/118] nfsd: when reusing an existing repcache entry, unhash it first Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 031/118] usb: dwc3: fix implementation of endpoint wedge Greg Kroah-Hartman
` (87 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Julius Werner, Alan Stern
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Julius Werner <jwerner@chromium.org>
commit 2d51f3cd11f414c56a87dc018196b85fd50b04a4 upstream.
This patch adds a check for USB_STATE_NOTATTACHED to the
hub_port_warm_reset_required() workaround for ports that end up in
Compliance Mode in hub_events() when trying to decide which reset
function to use. Trying to call usb_reset_device() with a NOTATTACHED
device will just fail and leave the port broken.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/core/hub.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4836,8 +4836,9 @@ static void hub_events(void)
hub->ports[i - 1]->child;
dev_dbg(hub_dev, "warm reset port %d\n", i);
- if (!udev || !(portstatus &
- USB_PORT_STAT_CONNECTION)) {
+ if (!udev ||
+ !(portstatus & USB_PORT_STAT_CONNECTION) ||
+ udev->state == USB_STATE_NOTATTACHED) {
status = hub_port_reset(hub, i,
NULL, HUB_BH_RESET_TIME,
true);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 031/118] usb: dwc3: fix implementation of endpoint wedge
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (28 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 030/118] usb: hub: Use correct reset for wedged USB3 devices that are NOTATTACHED Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 032/118] usb: gadget: composite: reset delayed_status on reset_config Greg Kroah-Hartman
` (86 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alan Stern, Pratyush Anand, Felipe Balbi
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <stern@rowland.harvard.edu>
commit a535d81c92615b8ffb99b7e1fd1fb01effaed1af upstream.
The dwc3 UDC driver doesn't implement endpoint wedging correctly.
When an endpoint is wedged, the gadget driver should be allowed to
clear the wedge by calling usb_ep_clear_halt(). Only the host is
prevented from resetting the endpoint.
This patch fixes the implementation.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Pratyush Anand <pratyush.anand@st.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/dwc3/ep0.c | 2 ++
drivers/usb/dwc3/gadget.c | 5 +----
2 files changed, 3 insertions(+), 4 deletions(-)
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -459,6 +459,8 @@ static int dwc3_ep0_handle_feature(struc
dep = dwc3_wIndex_to_dep(dwc, wIndex);
if (!dep)
return -EINVAL;
+ if (set == 0 && (dep->flags & DWC3_EP_WEDGE))
+ break;
ret = __dwc3_gadget_ep_set_halt(dep, set);
if (ret)
return -EINVAL;
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1200,9 +1200,6 @@ int __dwc3_gadget_ep_set_halt(struct dwc
else
dep->flags |= DWC3_EP_STALL;
} else {
- if (dep->flags & DWC3_EP_WEDGE)
- return 0;
-
ret = dwc3_send_gadget_ep_cmd(dwc, dep->number,
DWC3_DEPCMD_CLEARSTALL, ¶ms);
if (ret)
@@ -1210,7 +1207,7 @@ int __dwc3_gadget_ep_set_halt(struct dwc
value ? "set" : "clear",
dep->name);
else
- dep->flags &= ~DWC3_EP_STALL;
+ dep->flags &= ~(DWC3_EP_STALL | DWC3_EP_WEDGE);
}
return ret;
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 032/118] usb: gadget: composite: reset delayed_status on reset_config
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (29 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 031/118] usb: dwc3: fix implementation of endpoint wedge Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst Greg Kroah-Hartman
` (85 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Michael Grzeschik, Felipe Balbi
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Grzeschik <m.grzeschik@pengutronix.de>
commit 2bac51a1827a18821150ed8c9f9752c02f9c2b02 upstream.
The delayed_status value is used to keep track of status response
packets on ep0. It needs to be reset or the set_config function would
still delay the answer, if the usb device got unplugged while waiting
for setup_continue to be called.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/gadget/composite.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -593,6 +593,7 @@ static void reset_config(struct usb_comp
bitmap_zero(f->endpoints, 32);
}
cdev->config = NULL;
+ cdev->delayed_status = 0;
}
static int set_config(struct usb_composite_dev *cdev,
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (30 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 032/118] usb: gadget: composite: reset delayed_status on reset_config Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-31 20:40 ` walt
2013-12-18 21:11 ` [PATCH 3.12 034/118] usb: musb: musb_cppi41: factor most of cppi41_dma_callback() into cppi41_trans_done() Greg Kroah-Hartman
` (84 subsequent siblings)
116 siblings, 1 reply; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, David Laight, Sarah Sharp, Mark Lord
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Laight <David.Laight@ACULAB.COM>
commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e upstream.
Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB
can only occur at a boundary between underlying USB frames (512 bytes for
high speed devices).
If this isn't done the USB frames aren't formatted correctly and, for example,
the USB3 ethernet ax88179_178a card will stop sending (while still receiving)
when running a netperf tcp transmit test with (say) and 8k buffer.
This should be a candidate for stable, the ax88179_178a driver defaults to
gso and tso enabled so it passes a lot of fragmented skb to the USB stack.
Notes from Sarah:
Discussion: http://marc.info/?l=linux-usb&m=138384509604981&w=2
This patch fixes a long-standing xHCI driver bug that was revealed by a
change in 3.12 in the usb-net driver. Commit
638c5115a794981441246fa8fa5d95c1875af5ba "USBNET: support DMA SG" added
support to use bulk endpoint scatter-gather (urb->sg). Only the USB
ethernet drivers trigger this bug, because the mass storage driver sends
sg list entries in page-sized chunks.
This patch only fixes the issue for bulk endpoint scatter-gather. The
problem will still occur for periodic endpoints, because hosts will
interpret no-op transfers as a request to skip a service interval, which
is not what we want.
Luckily, the USB core isn't set up for scatter-gather on isochronous
endpoints, and no USB drivers use scatter-gather for interrupt
endpoints. Document this known limitation so that developers won't try
to use urb->sg for interrupt endpoints until this issue is fixed. The
more comprehensive fix would be to allow link TRBs in the middle of the
endpoint ring and revert this patch, but that fix would touch too much
code to be allowed in for stable.
This patch should be backported to kernels as old as 3.12, that contain
the commit 638c5115a794981441246fa8fa5d95c1875af5ba "USBNET: support DMA
SG". Without this patch, the USB network device gets wedged, and stops
sending packets. Mark Lord confirms this patch fixes the regression:
http://marc.info/?l=linux-netdev&m=138487107625966&w=2
Signed-off-by: David Laight <david.laight@aculab.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Mark Lord <mlord@pobox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-ring.c | 54 +++++++++++++++++++++++++++++++++++++++++--
include/linux/usb.h | 2 +
2 files changed, 54 insertions(+), 2 deletions(-)
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2929,8 +2929,58 @@ static int prepare_ring(struct xhci_hcd
}
while (1) {
- if (room_on_ring(xhci, ep_ring, num_trbs))
- break;
+ if (room_on_ring(xhci, ep_ring, num_trbs)) {
+ union xhci_trb *trb = ep_ring->enqueue;
+ unsigned int usable = ep_ring->enq_seg->trbs +
+ TRBS_PER_SEGMENT - 1 - trb;
+ u32 nop_cmd;
+
+ /*
+ * Section 4.11.7.1 TD Fragments states that a link
+ * TRB must only occur at the boundary between
+ * data bursts (eg 512 bytes for 480M).
+ * While it is possible to split a large fragment
+ * we don't know the size yet.
+ * Simplest solution is to fill the trb before the
+ * LINK with nop commands.
+ */
+ if (num_trbs == 1 || num_trbs <= usable || usable == 0)
+ break;
+
+ if (ep_ring->type != TYPE_BULK)
+ /*
+ * While isoc transfers might have a buffer that
+ * crosses a 64k boundary it is unlikely.
+ * Since we can't add NOPs without generating
+ * gaps in the traffic just hope it never
+ * happens at the end of the ring.
+ * This could be fixed by writing a LINK TRB
+ * instead of the first NOP - however the
+ * TRB_TYPE_LINK_LE32() calls would all need
+ * changing to check the ring length.
+ */
+ break;
+
+ if (num_trbs >= TRBS_PER_SEGMENT) {
+ xhci_err(xhci, "Too many fragments %d, max %d\n",
+ num_trbs, TRBS_PER_SEGMENT - 1);
+ return -ENOMEM;
+ }
+
+ nop_cmd = cpu_to_le32(TRB_TYPE(TRB_TR_NOOP) |
+ ep_ring->cycle_state);
+ ep_ring->num_trbs_free -= usable;
+ do {
+ trb->generic.field[0] = 0;
+ trb->generic.field[1] = 0;
+ trb->generic.field[2] = 0;
+ trb->generic.field[3] = nop_cmd;
+ trb++;
+ } while (--usable);
+ ep_ring->enqueue = trb;
+ if (room_on_ring(xhci, ep_ring, num_trbs))
+ break;
+ }
if (ep_ring == xhci->cmd_ring) {
xhci_err(xhci, "Do not support expand command ring\n");
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -1262,6 +1262,8 @@ typedef void (*usb_complete_t)(struct ur
* @sg: scatter gather buffer list, the buffer size of each element in
* the list (except the last) must be divisible by the endpoint's
* max packet size if no_sg_constraint isn't set in 'struct usb_bus'
+ * (FIXME: scatter-gather under xHCI is broken for periodic transfers.
+ * Do not use urb->sg for interrupt endpoints for now, only bulk.)
* @num_mapped_sgs: (internal) number of mapped sg entries
* @num_sgs: number of entries in the sg list
* @transfer_buffer_length: How big is transfer_buffer. The transfer may
^ permalink raw reply [flat|nested] 196+ messages in thread* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2013-12-18 21:11 ` [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst Greg Kroah-Hartman
@ 2013-12-31 20:40 ` walt
2013-12-31 22:06 ` Mark Lord
2014-01-02 19:15 ` Sarah Sharp
0 siblings, 2 replies; 196+ messages in thread
From: walt @ 2013-12-31 20:40 UTC (permalink / raw)
To: linux-kernel; +Cc: stable
On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
> 3.12-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: David Laight <David.Laight@ACULAB.COM>
>
> commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e upstream.
>
> Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB
> can only occur at a boundary between underlying USB frames (512 bytes for
> high speed devices).
>
> If this isn't done the USB frames aren't formatted correctly and, for example,
> the USB3 ethernet ax88179_178a card will stop sending...
Unfortunately this patch causes a regression when copying large files to my
outboard USB3 drive. (Nothing at all to do with networking.)
When I try to copy a large (20GB) file to the USB3 drive, the copy dies after
about 7GB, the ext4 journal aborts and the drive is remounted read-only.
This bug is 100% reproducible (always pretty close to 7GB) and reverting this
patch completely fixes the problem.
(Note to Sarah: I recently emailed you about this problem, and I *wrongly*
said that reverting the patch doesn't help. That was a mistake, sorry.)
I'm happy to try any debugging suggestions/tricks.
BTW, please tell me if I've cc'd too many people.
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2013-12-31 20:40 ` walt
@ 2013-12-31 22:06 ` Mark Lord
2014-01-02 19:15 ` Sarah Sharp
1 sibling, 0 replies; 196+ messages in thread
From: Mark Lord @ 2013-12-31 22:06 UTC (permalink / raw)
To: walt, Greg Kroah-Hartman, linux-kernel
Cc: stable, David Laight, Sarah Sharp, stable
On 13-12-31 03:40 PM, walt wrote:
> On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
>> 3.12-stable review patch. If anyone has any objections, please let me know.
>>
>> ------------------
>>
>> From: David Laight <David.Laight@ACULAB.COM>
>>
>> commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e upstream.
>>
>> Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB
>> can only occur at a boundary between underlying USB frames (512 bytes for
>> high speed devices).
>>
>> If this isn't done the USB frames aren't formatted correctly and, for example,
>> the USB3 ethernet ax88179_178a card will stop sending...
>
>
> Unfortunately this patch causes a regression when copying large files to my
> outboard USB3 drive. (Nothing at all to do with networking.)
>
> When I try to copy a large (20GB) file to the USB3 drive, the copy dies after
> about 7GB, the ext4 journal aborts and the drive is remounted read-only.
>
> This bug is 100% reproducible (always pretty close to 7GB) and reverting this
> patch completely fixes the problem.
>
> (Note to Sarah: I recently emailed you about this problem, and I *wrongly*
> said that reverting the patch doesn't help. That was a mistake, sorry.)
..
I have also had USB3 mass-storage issues with kernels since this patch.
Dunno if the patch itself is the problem, but just too much to do with USB3
is very flakey in the most recent 3.12.* kernels, as well as the 3.13-rc* ones.
So I have gone back to running older kernels and patching them.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2013-12-31 20:40 ` walt
2013-12-31 22:06 ` Mark Lord
@ 2014-01-02 19:15 ` Sarah Sharp
2014-01-02 21:01 ` Mark Lord
2014-01-03 15:40 ` walt
1 sibling, 2 replies; 196+ messages in thread
From: Sarah Sharp @ 2014-01-02 19:15 UTC (permalink / raw)
To: walt, Alan Stern
Cc: Greg Kroah-Hartman, linux-kernel, stable, David Laight,
Mark Lord, linux-usb, linux-scsi
On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
> On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
> > 3.12-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: David Laight <David.Laight@ACULAB.COM>
> >
> > commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e upstream.
> >
> > Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB
> > can only occur at a boundary between underlying USB frames (512 bytes for
> > high speed devices).
> >
> > If this isn't done the USB frames aren't formatted correctly and, for example,
> > the USB3 ethernet ax88179_178a card will stop sending...
>
>
> Unfortunately this patch causes a regression when copying large files to my
> outboard USB3 drive. (Nothing at all to do with networking.)
>
> When I try to copy a large (20GB) file to the USB3 drive, the copy dies after
> about 7GB, the ext4 journal aborts and the drive is remounted read-only.
>
> This bug is 100% reproducible (always pretty close to 7GB) and reverting this
> patch completely fixes the problem.
Ok, I had feared that would be a consequence of this patch. I think the
problem is that the usb-storage driver submitted an URB with more
scatter-gather entries than would fit on the ring segment, the xHCI
driver rejected the URB with -ENOMEM, and the SCSI core eventually gave
up on the SCSI command.
Do you have CONFIG_USB_DEBUG turned on for 3.13? If so, you should see
dmesg output from this statement shortly before your drive fails:
if (num_trbs >= TRBS_PER_SEGMENT) {
xhci_err(xhci, "Too many fragments %d, max %d\n",
num_trbs, TRBS_PER_SEGMENT - 1);
return -ENOMEM;
}
> (Note to Sarah: I recently emailed you about this problem, and I *wrongly*
> said that reverting the patch doesn't help. That was a mistake, sorry.)
>
> I'm happy to try any debugging suggestions/tricks.
Unfortunately a real fix for this is going to take a bit. I have a
couple different solutions to the bug the patch solved, but they're much
more invasive than the original patch and will take a couple weeks to
implement and thoroughly test.
If David's patch is just reverted, USB ethernet on 3.12 and later breaks
under xHCI. The networking folks added scatter-gather support in 3.12.
Those patches could be reverted, but I suspect David Miller will not be
happy with that solution, since the real problem is the xHCI driver
itself, and EHCI scatter-gather works fine.
I think the short term solution is to simply turn off scatter-gather all
together under xHCI until this gets fixed. It could mean a big
performance hit for USB storage devices, but that means we get correct
behavior for both USB ethernet and USB storage.
> BTW, please tell me if I've cc'd too many people.
Nope, you're fine. I've Cc'ed the USB and SCSI mailing lists as well.
Sarah Sharp
^ permalink raw reply [flat|nested] 196+ messages in thread* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2014-01-02 19:15 ` Sarah Sharp
@ 2014-01-02 21:01 ` Mark Lord
2014-01-02 21:19 ` James Bottomley
2014-01-02 21:33 ` Sarah Sharp
2014-01-03 15:40 ` walt
1 sibling, 2 replies; 196+ messages in thread
From: Mark Lord @ 2014-01-02 21:01 UTC (permalink / raw)
To: Sarah Sharp, walt, Alan Stern
Cc: Greg Kroah-Hartman, linux-kernel, stable, David Laight,
linux-usb, linux-scsi
On 14-01-02 02:15 PM, Sarah Sharp wrote:
> On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
..
>> Unfortunately this patch causes a regression when copying large files to my
>> outboard USB3 drive. (Nothing at all to do with networking.)
>>
>> When I try to copy a large (20GB) file to the USB3 drive, the copy dies after
>> about 7GB, the ext4 journal aborts and the drive is remounted read-only.
>>
>> This bug is 100% reproducible (always pretty close to 7GB) and reverting this
>> patch completely fixes the problem.
>
> Ok, I had feared that would be a consequence of this patch. I think the
> problem is that the usb-storage driver submitted an URB with more
> scatter-gather entries than would fit on the ring segment, the xHCI
> driver rejected the URB with -ENOMEM, and the SCSI core eventually gave
> up on the SCSI command.
Is there not a block layer / scheduler tunable for max sg entries or something?
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
@ 2014-01-02 21:19 ` James Bottomley
0 siblings, 0 replies; 196+ messages in thread
From: James Bottomley @ 2014-01-02 21:19 UTC (permalink / raw)
To: Mark Lord
Cc: Sarah Sharp, walt, Alan Stern, Greg Kroah-Hartman, linux-kernel,
stable, David Laight, linux-usb, linux-scsi
On Thu, 2014-01-02 at 16:01 -0500, Mark Lord wrote:
> On 14-01-02 02:15 PM, Sarah Sharp wrote:
> > On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
> ..
> >> Unfortunately this patch causes a regression when copying large files to my
> >> outboard USB3 drive. (Nothing at all to do with networking.)
> >>
> >> When I try to copy a large (20GB) file to the USB3 drive, the copy dies after
> >> about 7GB, the ext4 journal aborts and the drive is remounted read-only.
> >>
> >> This bug is 100% reproducible (always pretty close to 7GB) and reverting this
> >> patch completely fixes the problem.
> >
> > Ok, I had feared that would be a consequence of this patch. I think the
> > problem is that the usb-storage driver submitted an URB with more
> > scatter-gather entries than would fit on the ring segment, the xHCI
> > driver rejected the URB with -ENOMEM, and the SCSI core eventually gave
> > up on the SCSI command.
>
>
> Is there not a block layer / scheduler tunable for max sg entries or something?
Yes, it's blk_queue_max_segments() You can also add an indirect limit
from userspace using the queue/max_sectors_kb parameter (it doesn't
limit the number of sg elements directly, but it does limit the overall
size of the transfer, and since each segment is 4k or larger except at
the beginning and end, that limits the total number of sg elements as
well).
James
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
@ 2014-01-02 21:19 ` James Bottomley
0 siblings, 0 replies; 196+ messages in thread
From: James Bottomley @ 2014-01-02 21:19 UTC (permalink / raw)
To: Mark Lord
Cc: Sarah Sharp, walt, Alan Stern, Greg Kroah-Hartman,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
stable-u79uwXL29TY76Z2rM5mHXA, David Laight,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA
On Thu, 2014-01-02 at 16:01 -0500, Mark Lord wrote:
> On 14-01-02 02:15 PM, Sarah Sharp wrote:
> > On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
> ..
> >> Unfortunately this patch causes a regression when copying large files to my
> >> outboard USB3 drive. (Nothing at all to do with networking.)
> >>
> >> When I try to copy a large (20GB) file to the USB3 drive, the copy dies after
> >> about 7GB, the ext4 journal aborts and the drive is remounted read-only.
> >>
> >> This bug is 100% reproducible (always pretty close to 7GB) and reverting this
> >> patch completely fixes the problem.
> >
> > Ok, I had feared that would be a consequence of this patch. I think the
> > problem is that the usb-storage driver submitted an URB with more
> > scatter-gather entries than would fit on the ring segment, the xHCI
> > driver rejected the URB with -ENOMEM, and the SCSI core eventually gave
> > up on the SCSI command.
>
>
> Is there not a block layer / scheduler tunable for max sg entries or something?
Yes, it's blk_queue_max_segments() You can also add an indirect limit
from userspace using the queue/max_sectors_kb parameter (it doesn't
limit the number of sg elements directly, but it does limit the overall
size of the transfer, and since each segment is 4k or larger except at
the beginning and end, that limits the total number of sg elements as
well).
James
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2014-01-02 21:01 ` Mark Lord
2014-01-02 21:19 ` James Bottomley
@ 2014-01-02 21:33 ` Sarah Sharp
1 sibling, 0 replies; 196+ messages in thread
From: Sarah Sharp @ 2014-01-02 21:33 UTC (permalink / raw)
To: Mark Lord
Cc: walt, Alan Stern, Greg Kroah-Hartman, linux-kernel, stable,
David Laight, linux-usb, linux-scsi, Paul Zimmerman
On Thu, Jan 02, 2014 at 04:01:29PM -0500, Mark Lord wrote:
> On 14-01-02 02:15 PM, Sarah Sharp wrote:
> > On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
> ..
> >> Unfortunately this patch causes a regression when copying large files to my
> >> outboard USB3 drive. (Nothing at all to do with networking.)
> >>
> >> When I try to copy a large (20GB) file to the USB3 drive, the copy dies after
> >> about 7GB, the ext4 journal aborts and the drive is remounted read-only.
> >>
> >> This bug is 100% reproducible (always pretty close to 7GB) and reverting this
> >> patch completely fixes the problem.
> >
> > Ok, I had feared that would be a consequence of this patch. I think the
> > problem is that the usb-storage driver submitted an URB with more
> > scatter-gather entries than would fit on the ring segment, the xHCI
> > driver rejected the URB with -ENOMEM, and the SCSI core eventually gave
> > up on the SCSI command.
>
> Is there not a block layer / scheduler tunable for max sg entries or something?
There is a USB host controller tunable for max number of sg entries
that's passed up to the SCSI or block layer. We discussed changing it,
but there wasn't a good consensus on what to change it to:
http://marc.info/?l=linux-usb&m=138496358223904&w=2
http://marc.info/?l=linux-netdev&m=138496706007262&w=2
In the end, we thought we didn't need to limit the sglist size because
Paul thought usb-storage limits the overall transfer size to 120K, which
should fit in 31 TRBs:
http://marc.info/?l=linux-usb&m=138498190419312&w=2
Walt, could you see if limiting the sglist size helps, by setting
hcd->self.sg_tablesize in xhci.c to 31?
Sarah Sharp
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2014-01-02 19:15 ` Sarah Sharp
2014-01-02 21:01 ` Mark Lord
@ 2014-01-03 15:40 ` walt
2014-01-03 19:54 ` Sarah Sharp
` (2 more replies)
1 sibling, 3 replies; 196+ messages in thread
From: walt @ 2014-01-03 15:40 UTC (permalink / raw)
To: Sarah Sharp, Alan Stern
Cc: Greg Kroah-Hartman, linux-kernel, stable, David Laight,
Mark Lord, linux-usb, linux-scsi
On 01/02/2014 11:15 AM, Sarah Sharp wrote:
> On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
>> On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
>>> 3.12-stable review patch. If anyone has any objections, please let me know.
>>>
>>> ------------------
>>>
>>> From: David Laight <David.Laight@ACULAB.COM>
>>>
>>> commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e upstream.
>>>
>>> Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB
>>> can only occur at a boundary between underlying USB frames (512 bytes for
>>> high speed devices).
>>>
>>> If this isn't done the USB frames aren't formatted correctly and, for example,
>>> the USB3 ethernet ax88179_178a card will stop sending...
>>
>>
>> Unfortunately this patch causes a regression when copying large files to my
>> outboard USB3 drive. (Nothing at all to do with networking.)
> Do you have CONFIG_USB_DEBUG turned on for 3.13? If so, you should see
> dmesg output from this statement shortly before your drive fails:
>
> if (num_trbs >= TRBS_PER_SEGMENT) {
> xhci_err(xhci, "Too many fragments %d, max %d\n",
> num_trbs, TRBS_PER_SEGMENT - 1);
> return -ENOMEM;
> }
Well, the answers depend on whether the usb3 drive uses logical volumes or not
(lvm2), which I can't explain. What I've described so far is with lvm2.
When using lvm2 on the usb3 drive, turning on USB_DEBUG has *no* effect -- the
console prints two or three lines stating that the ext4 journal has quit and
the drive is remounted ro. That particular drive stays wedged until the next
reboot, but no other ill effects to the system.
OTOH, when I put a disk with just an ordinary ext4 partition in the usb3 dock,
(no logical volumes) the copy failure becomes catastrophic, with kernel panic
messages, leaving the system unresponsive and needing a hard reset to recover.
I also tried your other suggestion:
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 4265b48..1a6a43d 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4714,7 +4714,7 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks)
int retval;
/* Accept arbitrarily long scatter-gather lists */
- hcd->self.sg_tablesize = ~0;
+ hcd->self.sg_tablesize = 31;
/* support to build packet from discontinuous buffers */
hcd->self.no_sg_constraint = 1;
Sadly it didn't fix the problem. Did I get the patch right?
Thanks for your help, and I'm happy to try more ideas, as always.
^ permalink raw reply related [flat|nested] 196+ messages in thread* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2014-01-03 15:40 ` walt
@ 2014-01-03 19:54 ` Sarah Sharp
2014-01-03 21:21 ` walt
2014-01-04 14:03 ` Mark Lord
2014-01-06 10:35 ` David Laight
2 siblings, 1 reply; 196+ messages in thread
From: Sarah Sharp @ 2014-01-03 19:54 UTC (permalink / raw)
To: walt
Cc: Alan Stern, Greg Kroah-Hartman, linux-kernel, stable,
David Laight, Mark Lord, linux-usb, linux-scsi
On Fri, Jan 03, 2014 at 07:40:33AM -0800, walt wrote:
> On 01/02/2014 11:15 AM, Sarah Sharp wrote:
> > On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
> >> On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
> >>> 3.12-stable review patch. If anyone has any objections, please let me know.
> >>>
> >>> ------------------
> >>>
> >>> From: David Laight <David.Laight@ACULAB.COM>
> >>>
> >>> commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e upstream.
> >>>
> >>> Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB
> >>> can only occur at a boundary between underlying USB frames (512 bytes for
> >>> high speed devices).
> >>>
> >>> If this isn't done the USB frames aren't formatted correctly and, for example,
> >>> the USB3 ethernet ax88179_178a card will stop sending...
> >>
> >>
> >> Unfortunately this patch causes a regression when copying large files to my
> >> outboard USB3 drive. (Nothing at all to do with networking.)
>
> > Do you have CONFIG_USB_DEBUG turned on for 3.13? If so, you should see
> > dmesg output from this statement shortly before your drive fails:
> >
> > if (num_trbs >= TRBS_PER_SEGMENT) {
> > xhci_err(xhci, "Too many fragments %d, max %d\n",
> > num_trbs, TRBS_PER_SEGMENT - 1);
> > return -ENOMEM;
> > }
>
> Well, the answers depend on whether the usb3 drive uses logical volumes or not
> (lvm2), which I can't explain. What I've described so far is with lvm2.
>
> When using lvm2 on the usb3 drive, turning on USB_DEBUG has *no* effect -- the
> console prints two or three lines stating that the ext4 journal has quit and
> the drive is remounted ro. That particular drive stays wedged until the next
> reboot, but no other ill effects to the system.
Odd. In 3.12 xHCI has dynamic debugging, and turning on CONFIG_USB_DEBUG
should turn on debugging by default, so it's confusing that you didn't
see any messages.
Can I see your .config from /boot/? Also, did you try capturing dmesg
with `tail -f /var/log/kern.log` or just dmesg? Perhaps you need to run
`sudo dmesg -n 7`?
> OTOH, when I put a disk with just an ordinary ext4 partition in the usb3 dock,
> (no logical volumes) the copy failure becomes catastrophic, with kernel panic
> messages, leaving the system unresponsive and needing a hard reset to recover.
>
> I also tried your other suggestion:
>
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 4265b48..1a6a43d 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -4714,7 +4714,7 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks)
> int retval;
>
> /* Accept arbitrarily long scatter-gather lists */
> - hcd->self.sg_tablesize = ~0;
> + hcd->self.sg_tablesize = 31;
>
> /* support to build packet from discontinuous buffers */
> hcd->self.no_sg_constraint = 1;
>
> Sadly it didn't fix the problem. Did I get the patch right?
Yes, you did. So perhaps the patch triggers a different bug. I can't
tell until I see xHCI debugging output.
> Thanks for your help, and I'm happy to try more ideas, as always.
Thanks for your patience. :)
Sarah Sharp
^ permalink raw reply [flat|nested] 196+ messages in thread* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2014-01-03 19:54 ` Sarah Sharp
@ 2014-01-03 21:21 ` walt
2014-01-03 23:29 ` Sarah Sharp
0 siblings, 1 reply; 196+ messages in thread
From: walt @ 2014-01-03 21:21 UTC (permalink / raw)
To: Sarah Sharp
Cc: Alan Stern, Greg Kroah-Hartman, Linux Kernel, stable,
David Laight, linux-usb, linux-scsi
[-- Attachment #1: Type: text/plain, Size: 2039 bytes --]
On 01/03/2014 11:54 AM, Sarah Sharp wrote:
> On Fri, Jan 03, 2014 at 07:40:33AM -0800, walt wrote:
>> On 01/02/2014 11:15 AM, Sarah Sharp wrote:
>>> On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
>>>> On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
>>>>> 3.12-stable review patch. If anyone has any objections, please let me know.
>>>>>
>>>>> ------------------
>>>>>
>>>>> From: David Laight <David.Laight@ACULAB.COM>
>>>>>
>>>>> commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e upstream.
>>>>>
>>>>> Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB
>>>>> can only occur at a boundary between underlying USB frames (512 bytes for
>>>>> high speed devices).
>>>>>
>>>>> If this isn't done the USB frames aren't formatted correctly and, for example,
>>>>> the USB3 ethernet ax88179_178a card will stop sending...
>>>>
>>>>
>>>> Unfortunately this patch causes a regression when copying large files to my
>>>> outboard USB3 drive. (Nothing at all to do with networking.)
>>
>>> Do you have CONFIG_USB_DEBUG turned on for 3.13? If so, you should see
>>> dmesg output from this statement shortly before your drive fails:
>>>
>>> if (num_trbs >= TRBS_PER_SEGMENT) {
>>> xhci_err(xhci, "Too many fragments %d, max %d\n",
>>> num_trbs, TRBS_PER_SEGMENT - 1);
>>> return -ENOMEM;
>>> }
>>
>> Well, the answers depend on whether the usb3 drive uses logical volumes or not
>> (lvm2), which I can't explain. What I've described so far is with lvm2.
>>
>> When using lvm2 on the usb3 drive, turning on USB_DEBUG has *no* effect
I'm so sorry Sarah, that was another mistake. The mistake is so stupid I'm not
going to publish it here :(
Once I finally ran the kernel with debugging actually compiled in, dmesg contains
xhci debugging messages. Wow :)
It's a big file so I zipped and attached it, which I hope is acceptable in lkml.
BTW, this dmesg is from a kernel with sg_tablesize = 31, which as I said before
doesn't fix the problem. The cp stopped around 7GB just as before.
Sorry for the noise...
[-- Attachment #2: xhci.dmesg.gz --]
[-- Type: application/gzip, Size: 7578 bytes --]
^ permalink raw reply [flat|nested] 196+ messages in thread* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2014-01-03 21:21 ` walt
@ 2014-01-03 23:29 ` Sarah Sharp
2014-01-07 0:31 ` Sarah Sharp
2014-01-09 1:22 ` walt
0 siblings, 2 replies; 196+ messages in thread
From: Sarah Sharp @ 2014-01-03 23:29 UTC (permalink / raw)
To: walt
Cc: Alan Stern, Greg Kroah-Hartman, Linux Kernel, stable,
David Laight, linux-usb, linux-scsi
On Fri, Jan 03, 2014 at 01:21:18PM -0800, walt wrote:
> I'm so sorry Sarah, that was another mistake. The mistake is so stupid I'm not
> going to publish it here :(
>
> Once I finally ran the kernel with debugging actually compiled in, dmesg contains
> xhci debugging messages. Wow :)
>
> It's a big file so I zipped and attached it, which I hope is acceptable in lkml.
Yep, that's fine. Sticking it in pastebin (or up on your server) is
also fine, if it gets really big.
> BTW, this dmesg is from a kernel with sg_tablesize = 31, which as I said before
> doesn't fix the problem. The cp stopped around 7GB just as before.
>
> Sorry for the noise...
No worries! :) With the dmesg, I can finally see what happened:
[ 188.703059] xhci_hcd 0000:03:00.0: Cancel URB ffff8800b7d2e0c0, dev 1, ep 0x2, starting at offset 0xbb7b9000
[ 188.703072] xhci_hcd 0000:03:00.0: // Ding dong!
[ 193.711022] xhci_hcd 0000:03:00.0: xHCI host not responding to stop endpoint command.
[ 193.711029] xhci_hcd 0000:03:00.0: Assuming host is dying, halting host.
[ 193.711046] xhci_hcd 0000:03:00.0: // Halt the HC
[ 193.711060] xhci_hcd 0000:03:00.0: Killing URBs for slot ID 1, ep index 0
[ 193.711066] xhci_hcd 0000:03:00.0: Killing URBs for slot ID 1, ep index 2
[ 193.711078] xhci_hcd 0000:03:00.0: Killing URBs for slot ID 1, ep index 3
[ 193.711096] xhci_hcd 0000:03:00.0: Calling usb_hc_died()
[ 193.711103] xhci_hcd 0000:03:00.0: HC died; cleaning up
[ 193.711116] xhci_hcd 0000:03:00.0: xHCI host controller is dead.
It seems that the xHCI driver tried to stop the endpoint ring in order
to cancel a SCSI transfer, and the driver never got a response for that.
The offset is rather suspicious (0xbb7b9000), and it probably means the
driver attempted to cancel a transfer that had been moved to the
beginning of the ring segment, with no-op TRBs before the link TRB.
I suspect David's patch triggers a bug in the command cancellation code.
There's also the unlikely possibility that the no-op TRBs did indeed
cause the host to hang. Either way, I'll have to look into it.
I'll let you know when I have some diagnostic patches ready.
Sarah Sharp
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2014-01-03 23:29 ` Sarah Sharp
@ 2014-01-07 0:31 ` Sarah Sharp
2014-01-07 13:29 ` walt
2014-01-09 1:22 ` walt
1 sibling, 1 reply; 196+ messages in thread
From: Sarah Sharp @ 2014-01-07 0:31 UTC (permalink / raw)
To: walt
Cc: Alan Stern, Greg Kroah-Hartman, Linux Kernel, stable,
David Laight, linux-usb, linux-scsi
[-- Attachment #1: Type: text/plain, Size: 2780 bytes --]
On Fri, Jan 03, 2014 at 03:29:29PM -0800, Sarah Sharp wrote:
> On Fri, Jan 03, 2014 at 01:21:18PM -0800, walt wrote:
> > I'm so sorry Sarah, that was another mistake. The mistake is so stupid I'm not
> > going to publish it here :(
> >
> > Once I finally ran the kernel with debugging actually compiled in, dmesg contains
> > xhci debugging messages. Wow :)
> >
> > It's a big file so I zipped and attached it, which I hope is acceptable in lkml.
>
> Yep, that's fine. Sticking it in pastebin (or up on your server) is
> also fine, if it gets really big.
>
> > BTW, this dmesg is from a kernel with sg_tablesize = 31, which as I said before
> > doesn't fix the problem. The cp stopped around 7GB just as before.
> >
> > Sorry for the noise...
>
> No worries! :) With the dmesg, I can finally see what happened:
>
> [ 188.703059] xhci_hcd 0000:03:00.0: Cancel URB ffff8800b7d2e0c0, dev 1, ep 0x2, starting at offset 0xbb7b9000
> [ 188.703072] xhci_hcd 0000:03:00.0: // Ding dong!
> [ 193.711022] xhci_hcd 0000:03:00.0: xHCI host not responding to stop endpoint command.
> [ 193.711029] xhci_hcd 0000:03:00.0: Assuming host is dying, halting host.
> [ 193.711046] xhci_hcd 0000:03:00.0: // Halt the HC
> [ 193.711060] xhci_hcd 0000:03:00.0: Killing URBs for slot ID 1, ep index 0
> [ 193.711066] xhci_hcd 0000:03:00.0: Killing URBs for slot ID 1, ep index 2
> [ 193.711078] xhci_hcd 0000:03:00.0: Killing URBs for slot ID 1, ep index 3
> [ 193.711096] xhci_hcd 0000:03:00.0: Calling usb_hc_died()
> [ 193.711103] xhci_hcd 0000:03:00.0: HC died; cleaning up
> [ 193.711116] xhci_hcd 0000:03:00.0: xHCI host controller is dead.
>
> It seems that the xHCI driver tried to stop the endpoint ring in order
> to cancel a SCSI transfer, and the driver never got a response for that.
>
> The offset is rather suspicious (0xbb7b9000), and it probably means the
> driver attempted to cancel a transfer that had been moved to the
> beginning of the ring segment, with no-op TRBs before the link TRB.
>
> I suspect David's patch triggers a bug in the command cancellation code.
> There's also the unlikely possibility that the no-op TRBs did indeed
> cause the host to hang. Either way, I'll have to look into it.
>
> I'll let you know when I have some diagnostic patches ready.
Hi Walt,
I have a couple of patches for you to test. You can either apply the
attached three patches, or you can pull down a kernel with:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git -b 3.12-td-fragment-failure
Please only apply the first patch (which is diagnostic only), trigger
your issue, and send me the resulting dmesg. Then try applying the
other two patches, and see if the issue goes away. (I suspect it won't
but I can't be sure.)
Sarah Sharp
[-- Attachment #2: 0001-TD-fragment-debugging.patch --]
[-- Type: text/x-diff, Size: 1894 bytes --]
>From 0261dcd2711c010d786dcd940803a44e1bc19512 Mon Sep 17 00:00:00 2001
From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date: Mon, 6 Jan 2014 16:06:27 -0800
Subject: [PATCH 1/3] TD fragment debugging
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
---
drivers/usb/host/xhci-ring.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 55fc0c39b7e1..d05f61dc8359 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -982,6 +982,14 @@ void xhci_stop_endpoint_command_watchdog(unsigned long arg)
* doesn't touch the memory.
*/
}
+
+ xhci_dbg(xhci, "Command ring:\n");
+ xhci_debug_ring(xhci, xhci->cmd_ring);
+ xhci_dbg_ring_ptrs(xhci, xhci->cmd_ring);
+ xhci_dbg(xhci, "Event ring:\n");
+ xhci_debug_ring(xhci, xhci->event_ring);
+ xhci_dbg_ring_ptrs(xhci, xhci->event_ring);
+
for (i = 0; i < MAX_HC_SLOTS; i++) {
if (!xhci->devs[i])
continue;
@@ -1003,6 +1011,12 @@ void xhci_stop_endpoint_command_watchdog(unsigned long arg)
xhci_giveback_urb_in_irq(xhci, cur_td,
-ESHUTDOWN, "killed");
}
+ if (!list_empty(&temp_ep->cancelled_td_list)) {
+ xhci_dbg(xhci, "Dev %i Ep 0x%x:\n", i,
+ xhci_get_endpoint_address(j));
+ xhci_debug_ring(xhci, ring);
+ xhci_dbg_ring_ptrs(xhci, ring);
+ }
while (!list_empty(&temp_ep->cancelled_td_list)) {
cur_td = list_first_entry(
&temp_ep->cancelled_td_list,
@@ -2966,6 +2980,10 @@ static int prepare_ring(struct xhci_hcd *xhci, struct xhci_ring *ep_ring,
num_trbs, TRBS_PER_SEGMENT - 1);
return -ENOMEM;
}
+ xhci_dbg(xhci, "Insert no-op TRBs at 0x%llx\n",
+ (unsigned long long)
+ xhci_trb_virt_to_dma(ep_ring->enq_seg,
+ ep_ring->enqueue));
nop_cmd = cpu_to_le32(TRB_TYPE(TRB_TR_NOOP) |
ep_ring->cycle_state);
--
1.8.3.3
[-- Attachment #3: 0002-xhci-Avoid-infinite-loop-when-sg-urb-requires-too-ma.patch --]
[-- Type: text/x-diff, Size: 1577 bytes --]
>From 380071d6fa2430c7141faefc8acfc0909c75a0ed Mon Sep 17 00:00:00 2001
From: Ben Hutchings <ben@decadent.org.uk>
Date: Mon, 6 Jan 2014 03:16:32 +0000
Subject: [PATCH 2/3] xhci: Avoid infinite loop when sg urb requires too many
trbs
Currently prepare_ring() returns -ENOMEM if the urb won't fit into a
single ring segment. usb_sg_wait() treats this error as a temporary
condition and will keep retrying until something else goes wrong.
The number of retries should be limited in usb_sg_wait(), but also
prepare_ring() should not return an error code that suggests it might
be worth retrying. Change it to -EINVAL.
Reported-by: jidanni@jidanni.org
References: http://bugs.debian.org/733907
Fixes: 35773dac5f86 ('usb: xhci: Link TRB must not occur within a USB payload burst')
Cc: stable <stable@vger.kernel.org> # 3.12
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
---
drivers/usb/host/xhci-ring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index d05f61dc8359..2afaf15009e8 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2978,7 +2978,7 @@ static int prepare_ring(struct xhci_hcd *xhci, struct xhci_ring *ep_ring,
if (num_trbs >= TRBS_PER_SEGMENT) {
xhci_err(xhci, "Too many fragments %d, max %d\n",
num_trbs, TRBS_PER_SEGMENT - 1);
- return -ENOMEM;
+ return -EINVAL;
}
xhci_dbg(xhci, "Insert no-op TRBs at 0x%llx\n",
(unsigned long long)
--
1.8.3.3
[-- Attachment #4: 0003-xhci-Set-scatter-gather-limit-to-avoid-failed-block-.patch --]
[-- Type: text/x-diff, Size: 2790 bytes --]
>From c463a2dec054a5b5f3bc48c1e979dfa5d7cfabfa Mon Sep 17 00:00:00 2001
From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date: Mon, 6 Jan 2014 13:07:03 -0800
Subject: [PATCH 3/3] xhci: Set scatter-gather limit to avoid failed block
writes.
Commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e "usb: xhci: Link TRB
must not occur within a USB payload burst" attempted to fix an issue
found with USB ethernet adapters, and inadvertently broke USB storage
devices. The patch attempts to ensure that transfers never span a
segment, and rejects transfers that have more than 63 entries (or
possibly less, if some entries cross 64KB boundaries).
usb-storage limits the maximum transfer size to 120K, and we had assumed
the block layer would pass a scatter-gather list of 4K entries,
resulting in no more than 31 sglist entries:
http://marc.info/?l=linux-usb&m=138498190419312&w=2
That assumption was wrong, since we've seen the driver reject a write
that was 218 sectors long (of probably 512 bytes each):
Jan 1 07:04:49 jidanni5 kernel: [ 559.624704] xhci_hcd 0000:00:14.0: Too many fragments 79, max 63
...
Jan 1 07:04:58 jidanni5 kernel: [ 568.622583] Write(10): 2a 00 00 06 85 0e 00 00 da 00
Limit the number of scatter-gather entries to half a ring segment. That
should be margin enough in case some entries cross 64KB boundaries.
Increase the number of TRBs per segment from 64 to 256, which should
result in ring segments fitting on a 4K page.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
---
drivers/usb/host/xhci.c | 4 ++--
drivers/usb/host/xhci.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index ed6c186a5393..d834278c7540 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4724,8 +4724,8 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks)
struct device *dev = hcd->self.controller;
int retval;
- /* Accept arbitrarily long scatter-gather lists */
- hcd->self.sg_tablesize = ~0;
+ /* Limit the block layer scatter-gather lists to half a segment. */
+ hcd->self.sg_tablesize = TRBS_PER_SEGMENT / 2;
/* support to build packet from discontinuous buffers */
hcd->self.no_sg_constraint = 1;
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index ed3a425de8ce..6b3164c75c98 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1262,7 +1262,7 @@ union xhci_trb {
* since the command ring is 64-byte aligned.
* It must also be greater than 16.
*/
-#define TRBS_PER_SEGMENT 64
+#define TRBS_PER_SEGMENT 256
/* Allow two commands + a link TRB, along with any reserved command TRBs */
#define MAX_RSVD_CMD_TRBS (TRBS_PER_SEGMENT - 3)
#define TRB_SEGMENT_SIZE (TRBS_PER_SEGMENT*16)
--
1.8.3.3
^ permalink raw reply related [flat|nested] 196+ messages in thread* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2014-01-07 0:31 ` Sarah Sharp
@ 2014-01-07 13:29 ` walt
2014-01-07 13:51 ` David Laight
` (2 more replies)
0 siblings, 3 replies; 196+ messages in thread
From: walt @ 2014-01-07 13:29 UTC (permalink / raw)
To: Sarah Sharp
Cc: Alan Stern, Greg Kroah-Hartman, Linux Kernel, stable,
David Laight, linux-usb, linux-scsi
[-- Attachment #1: Type: text/plain, Size: 2911 bytes --]
On 01/06/2014 04:31 PM, Sarah Sharp wrote:
> On Fri, Jan 03, 2014 at 03:29:29PM -0800, Sarah Sharp wrote:
>> With the dmesg, I can finally see what happened:
>>
>> [ 188.703059] xhci_hcd 0000:03:00.0: Cancel URB ffff8800b7d2e0c0, dev 1, ep 0x2, starting at offset 0xbb7b9000
>> [ 188.703072] xhci_hcd 0000:03:00.0: // Ding dong!
>> [ 193.711022] xhci_hcd 0000:03:00.0: xHCI host not responding to stop endpoint command.
>> [ 193.711029] xhci_hcd 0000:03:00.0: Assuming host is dying, halting host.
>> [ 193.711046] xhci_hcd 0000:03:00.0: // Halt the HC
>> [ 193.711060] xhci_hcd 0000:03:00.0: Killing URBs for slot ID 1, ep index 0
>> [ 193.711066] xhci_hcd 0000:03:00.0: Killing URBs for slot ID 1, ep index 2
>> [ 193.711078] xhci_hcd 0000:03:00.0: Killing URBs for slot ID 1, ep index 3
>> [ 193.711096] xhci_hcd 0000:03:00.0: Calling usb_hc_died()
>> [ 193.711103] xhci_hcd 0000:03:00.0: HC died; cleaning up
>> [ 193.711116] xhci_hcd 0000:03:00.0: xHCI host controller is dead.
>>
>> It seems that the xHCI driver tried to stop the endpoint ring in order
>> to cancel a SCSI transfer, and the driver never got a response for that.
>>
>> The offset is rather suspicious (0xbb7b9000), and it probably means the
>> driver attempted to cancel a transfer that had been moved to the
>> beginning of the ring segment, with no-op TRBs before the link TRB.
>>
>> I suspect David's patch triggers a bug in the command cancellation code.
>> There's also the unlikely possibility that the no-op TRBs did indeed
>> cause the host to hang. Either way, I'll have to look into it.
>>
>> I'll let you know when I have some diagnostic patches ready.
>
> Hi Walt,
>
> I have a couple of patches for you to test.
> Please only apply the first patch (which is diagnostic only), trigger
> your issue, and send me the resulting dmesg. Then try applying the
> other two patches, and see if the issue goes away. (I suspect it won't
> but I can't be sure.)
Thanks Sarah. dmesg0 is from the diagnostic patch only. dmesg1 has all
three patches applied. Some of the messages in dmesg1 fell off the end of
the kernel buffer, so I may need to make the buffer larger next time but
I'll need a reminder of how to do it.
As you suspected, the patches didn't fix the problem, sorry.
I find that I can tell in advance whether the copy is going to succeed,
just by watching the light flicker on the usb3 drive. When the flicker
is absolutely regular, with no variation whatever, I can tell in 10 or
15 seconds that the copy will fail.
At the same time the light on the main drive goes dark after 10 seconds,
implying that the usb3 drive stops receiving any data from the main drive
after 10 seconds, yet the light on the usb3 drive continues to flicker as
if writing data -- even after the cp officially fails. The light on the
usb3 drive never stops flickering until I reboot the machine or unplug
the usb cable.
[-- Attachment #2: dmesg0.gz --]
[-- Type: application/gzip, Size: 5434 bytes --]
[-- Attachment #3: dmesg1.gz --]
[-- Type: application/gzip, Size: 4552 bytes --]
^ permalink raw reply [flat|nested] 196+ messages in thread* RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2014-01-07 13:29 ` walt
@ 2014-01-07 13:51 ` David Laight
2014-01-07 13:58 ` David Laight
2014-01-07 21:21 ` Sarah Sharp
2 siblings, 0 replies; 196+ messages in thread
From: David Laight @ 2014-01-07 13:51 UTC (permalink / raw)
To: 'walt', Sarah Sharp
Cc: Alan Stern, Greg Kroah-Hartman, Linux Kernel, stable, linux-usb,
linux-scsi
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 739 bytes --]
> From: walt
...
> Thanks Sarah. dmesg0 is from the diagnostic patch only. dmesg1 has all
> three patches applied. Some of the messages in dmesg1 fell off the end of
> the kernel buffer, so I may need to make the buffer larger next time but
> I'll need a reminder of how to do it.
>
> As you suspected, the patches didn't fix the problem, sorry.
I think Sarah will want the traces of the transfer being setup (ie just
before the error). Some 'normal' completing transfers are also useful.
You might also find the full trace output in one of the files in /var/log.
David
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
^ permalink raw reply [flat|nested] 196+ messages in thread* RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
@ 2014-01-07 13:51 ` David Laight
0 siblings, 0 replies; 196+ messages in thread
From: David Laight @ 2014-01-07 13:51 UTC (permalink / raw)
To: 'walt', Sarah Sharp
Cc: Alan Stern, Greg Kroah-Hartman, Linux Kernel, stable, linux-usb,
linux-scsi
> From: walt
...
> Thanks Sarah. dmesg0 is from the diagnostic patch only. dmesg1 has all
> three patches applied. Some of the messages in dmesg1 fell off the end of
> the kernel buffer, so I may need to make the buffer larger next time but
> I'll need a reminder of how to do it.
>
> As you suspected, the patches didn't fix the problem, sorry.
I think Sarah will want the traces of the transfer being setup (ie just
before the error). Some 'normal' completing transfers are also useful.
You might also find the full trace output in one of the files in /var/log.
David
^ permalink raw reply [flat|nested] 196+ messages in thread
* RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2014-01-07 13:29 ` walt
@ 2014-01-07 13:58 ` David Laight
2014-01-07 13:58 ` David Laight
2014-01-07 21:21 ` Sarah Sharp
2 siblings, 0 replies; 196+ messages in thread
From: David Laight @ 2014-01-07 13:58 UTC (permalink / raw)
To: 'walt', Sarah Sharp
Cc: Alan Stern, Greg Kroah-Hartman, Linux Kernel, stable, linux-usb,
linux-scsi
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 522 bytes --]
The dmesg contains:
[ 538.728064] EXT4-fs warning (device dm-0): ext4_end_bio:316: I/O error writing to inode 23330865 (offset 0 size 8388608 starting block 812628)
An 8MB transfer will need at least 128 ring entries (TRB) even if the request
is a single contiguous memory block.
Are you using the patch that increases the ring size from 64 to 256?
David
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
^ permalink raw reply [flat|nested] 196+ messages in thread* RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
@ 2014-01-07 13:58 ` David Laight
0 siblings, 0 replies; 196+ messages in thread
From: David Laight @ 2014-01-07 13:58 UTC (permalink / raw)
To: 'walt', Sarah Sharp
Cc: Alan Stern, Greg Kroah-Hartman, Linux Kernel, stable, linux-usb,
linux-scsi
The dmesg contains:
[ 538.728064] EXT4-fs warning (device dm-0): ext4_end_bio:316: I/O error writing to inode 23330865 (offset 0 size 8388608 starting block 812628)
An 8MB transfer will need at least 128 ring entries (TRB) even if the request
is a single contiguous memory block.
Are you using the patch that increases the ring size from 64 to 256?
David
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2014-01-07 13:58 ` David Laight
(?)
@ 2014-01-07 19:15 ` walt
-1 siblings, 0 replies; 196+ messages in thread
From: walt @ 2014-01-07 19:15 UTC (permalink / raw)
To: David Laight, Sarah Sharp
Cc: Alan Stern, Greg Kroah-Hartman, Linux Kernel, stable, linux-usb,
linux-scsi
On 01/07/2014 05:58 AM, David Laight wrote:
> The dmesg contains:
>
> [ 538.728064] EXT4-fs warning (device dm-0): ext4_end_bio:316: I/O error writing to inode 23330865 (offset 0 size 8388608 starting block 812628)
>
> An 8MB transfer will need at least 128 ring entries (TRB) even if the request
> is a single contiguous memory block.
>
> Are you using the patch that increases the ring size from 64 to 256?
Yes, 256. I'll work on getting more debugging output.
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2014-01-07 13:58 ` David Laight
(?)
(?)
@ 2014-01-07 20:00 ` walt
2014-01-07 23:31 ` Sarah Sharp
-1 siblings, 1 reply; 196+ messages in thread
From: walt @ 2014-01-07 20:00 UTC (permalink / raw)
To: David Laight, Sarah Sharp
Cc: Alan Stern, Greg Kroah-Hartman, Linux Kernel, stable, linux-usb,
linux-scsi
[-- Attachment #1: Type: text/plain, Size: 102 bytes --]
Okay, I used log_buf_len to make dmesg bigger and now I think I have
the whole thing. It's attached.
[-- Attachment #2: dmesg2.gz --]
[-- Type: application/gzip, Size: 11231 bytes --]
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2014-01-07 20:00 ` walt
@ 2014-01-07 23:31 ` Sarah Sharp
0 siblings, 0 replies; 196+ messages in thread
From: Sarah Sharp @ 2014-01-07 23:31 UTC (permalink / raw)
To: walt
Cc: David Laight, Alan Stern, Greg Kroah-Hartman, Linux Kernel,
stable, linux-usb, linux-scsi
On Tue, Jan 07, 2014 at 12:00:00PM -0800, walt wrote:
> Okay, I used log_buf_len to make dmesg bigger and now I think I have
> the whole thing. It's attached.
Walt, can you make sure the patch I sent you was applied? The output
doesn't look like it is.
Sarah Sharp
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
@ 2014-01-07 21:27 ` Sarah Sharp
0 siblings, 0 replies; 196+ messages in thread
From: Sarah Sharp @ 2014-01-07 21:27 UTC (permalink / raw)
To: David Laight
Cc: 'walt',
Alan Stern, Greg Kroah-Hartman, Linux Kernel, stable, linux-usb,
linux-scsi
On Tue, Jan 07, 2014 at 01:58:32PM +0000, David Laight wrote:
> The dmesg contains:
>
> [ 538.728064] EXT4-fs warning (device dm-0): ext4_end_bio:316: I/O error writing to inode 23330865 (offset 0 size 8388608 starting block 812628)
>
> An 8MB transfer will need at least 128 ring entries (TRB) even if the request
> is a single contiguous memory block.
>
> Are you using the patch that increases the ring size from 64 to 256?
It's likely that the block layer is breaking up the EXT4 write into
several transfers, since usb-storage limits overall transfer size to
120 KB. In any case, I added more debugging in the last patch to print
the number of TRBs necessary. That way we can verify the patch to limit
the number of scatter-gather list entries is working.
Sarah Sharp
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
@ 2014-01-07 21:27 ` Sarah Sharp
0 siblings, 0 replies; 196+ messages in thread
From: Sarah Sharp @ 2014-01-07 21:27 UTC (permalink / raw)
To: David Laight
Cc: 'walt',
Alan Stern, Greg Kroah-Hartman, Linux Kernel,
stable-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA
On Tue, Jan 07, 2014 at 01:58:32PM +0000, David Laight wrote:
> The dmesg contains:
>
> [ 538.728064] EXT4-fs warning (device dm-0): ext4_end_bio:316: I/O error writing to inode 23330865 (offset 0 size 8388608 starting block 812628)
>
> An 8MB transfer will need at least 128 ring entries (TRB) even if the request
> is a single contiguous memory block.
>
> Are you using the patch that increases the ring size from 64 to 256?
It's likely that the block layer is breaking up the EXT4 write into
several transfers, since usb-storage limits overall transfer size to
120 KB. In any case, I added more debugging in the last patch to print
the number of TRBs necessary. That way we can verify the patch to limit
the number of scatter-gather list entries is working.
Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
@ 2014-01-07 21:21 ` Sarah Sharp
0 siblings, 0 replies; 196+ messages in thread
From: Sarah Sharp @ 2014-01-07 21:21 UTC (permalink / raw)
To: walt
Cc: Alan Stern, Greg Kroah-Hartman, Linux Kernel, stable,
David Laight, linux-usb, linux-scsi
[-- Attachment #1: Type: text/plain, Size: 3443 bytes --]
On Tue, Jan 07, 2014 at 05:29:48AM -0800, walt wrote:
> On 01/06/2014 04:31 PM, Sarah Sharp wrote:
> > Hi Walt,
> >
> > I have a couple of patches for you to test.
>
> > Please only apply the first patch (which is diagnostic only), trigger
> > your issue, and send me the resulting dmesg. Then try applying the
> > other two patches, and see if the issue goes away. (I suspect it won't
> > but I can't be sure.)
>
> Thanks Sarah. dmesg0 is from the diagnostic patch only. dmesg1 has all
> three patches applied. Some of the messages in dmesg1 fell off the end of
> the kernel buffer, so I may need to make the buffer larger next time but
> I'll need a reminder of how to do it.
Set CONFIG_LOG_BUF_SHIFT to 21.
> As you suspected, the patches didn't fix the problem, sorry.
Yep, I thought so. I did glean one bit of information from the logs: it
seems that your host does handle no-op TRBs, at least for a while.
However, after a bigger chunk of TRBs, it goes off into la-la-land.
Assuming one of the rings is comprised of two segments:
0xbb711000 (start)
0xbb7113f0 (end)
0xbb711400 (start)
0xbb7117f0 (end)
The log show no-ops were inserted at:
0xbb7207d0
0xbb7206a0
0xbb720be0
0xbb720be0
0xbb720bd0
0xbb7207e0
0xbb711370 = 8 no-ops
0xbb7117c0 = 3
0xbb7113b0 = 4
0xbb7113a0 = 5
0xbb7117d0 = 2
0xbb711340 = 11
0xbb711770 = 8
0xbb711230 = 28
0xbb7117e0 = 1
0xbb7117b0 = 4
0xbb7113d0 = 2
0xbb7117b0 = 4
0xbb711340 = 11
0xbb711690 = 22
So the host was able to process 28 no-op TRBs, but failed on 22 no-ops
later. The event ring debugging shows the last event was for
0xbb711680, which is the last TRB before the first no-op inserted before
the host died. There's no Stop Endpoint Command completion, and it
looks like the command was correctly put on the command ring, so it
seems the host is actually hanging for some reason.
Unfortunately, I made a mistake in the debugging patch I sent
you, so it didn't print out the endpoint rings when the host died. I
need that info, to see whether the link TRB was still intact, or if we
over-wrote it and caused the host to go fetch some invalid memory.
Can you please try the attached patch, on top of the previous three
patches, and send me dmesg?
> I find that I can tell in advance whether the copy is going to succeed,
> just by watching the light flicker on the usb3 drive. When the flicker
> is absolutely regular, with no variation whatever, I can tell in 10 or
> 15 seconds that the copy will fail.
>
> At the same time the light on the main drive goes dark after 10 seconds,
> implying that the usb3 drive stops receiving any data from the main drive
> after 10 seconds, yet the light on the usb3 drive continues to flicker as
> if writing data -- even after the cp officially fails. The light on the
> usb3 drive never stops flickering until I reboot the machine or unplug
> the usb cable.
Interesting. Without a USB analyzer, we can't really tell what's
happening. However, one hypothesis could be that the blinking light is
triggered by an active SCSI command (read/write, etc).
There are three phases of the command: setup, data, and status. I think
your device is getting the setup phase, and the host is dying before it
sends the data phase. If the light blinks when it gets a setup phase,
and turns off when the devices sends a status phase, that would explain
its behavior.
But that's just a hypothesis, I have no idea whether it's correct.
Sarah Sharp
[-- Attachment #2: 0001-More-debugging.patch --]
[-- Type: text/x-diff, Size: 2416 bytes --]
>From d085fb5b9630e935d7954fe5947b48402e43bdc1 Mon Sep 17 00:00:00 2001
From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date: Tue, 7 Jan 2014 12:39:47 -0800
Subject: [PATCH] More debugging.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
---
drivers/usb/host/xhci-ring.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 2afaf15009e8..228ab8cf868e 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -993,6 +993,9 @@ void xhci_stop_endpoint_command_watchdog(unsigned long arg)
for (i = 0; i < MAX_HC_SLOTS; i++) {
if (!xhci->devs[i])
continue;
+
+ xhci_dbg(xhci, "Slot %d output context\n", i);
+ xhci_dbg_ctx(xhci, xhci->devs[i]->out_ctx, 30);
for (j = 0; j < 31; j++) {
temp_ep = &xhci->devs[i]->eps[j];
ring = temp_ep->ring;
@@ -1001,6 +1004,10 @@ void xhci_stop_endpoint_command_watchdog(unsigned long arg)
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
"Killing URBs for slot ID %u, "
"ep index %u", i, j);
+ xhci_dbg(xhci, "Dev %i Ep 0x%x:\n", i,
+ xhci_get_endpoint_address(j));
+ xhci_debug_ring(xhci, ring);
+ xhci_dbg_ring_ptrs(xhci, ring);
while (!list_empty(&ring->td_list)) {
cur_td = list_first_entry(&ring->td_list,
struct xhci_td,
@@ -1011,12 +1018,6 @@ void xhci_stop_endpoint_command_watchdog(unsigned long arg)
xhci_giveback_urb_in_irq(xhci, cur_td,
-ESHUTDOWN, "killed");
}
- if (!list_empty(&temp_ep->cancelled_td_list)) {
- xhci_dbg(xhci, "Dev %i Ep 0x%x:\n", i,
- xhci_get_endpoint_address(j));
- xhci_debug_ring(xhci, ring);
- xhci_dbg_ring_ptrs(xhci, ring);
- }
while (!list_empty(&temp_ep->cancelled_td_list)) {
cur_td = list_first_entry(
&temp_ep->cancelled_td_list,
@@ -2980,10 +2981,10 @@ static int prepare_ring(struct xhci_hcd *xhci, struct xhci_ring *ep_ring,
num_trbs, TRBS_PER_SEGMENT - 1);
return -EINVAL;
}
- xhci_dbg(xhci, "Insert no-op TRBs at 0x%llx\n",
- (unsigned long long)
+ xhci_dbg(xhci, "Insert %i no-op TRBs from 0x%llx for TD with %i TRBs\n",
+ usable, (unsigned long long)
xhci_trb_virt_to_dma(ep_ring->enq_seg,
- ep_ring->enqueue));
+ ep_ring->enqueue), num_trbs);
nop_cmd = cpu_to_le32(TRB_TYPE(TRB_TR_NOOP) |
ep_ring->cycle_state);
--
1.8.3.3
^ permalink raw reply related [flat|nested] 196+ messages in thread* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
@ 2014-01-07 21:21 ` Sarah Sharp
0 siblings, 0 replies; 196+ messages in thread
From: Sarah Sharp @ 2014-01-07 21:21 UTC (permalink / raw)
To: walt
Cc: Alan Stern, Greg Kroah-Hartman, Linux Kernel,
stable-u79uwXL29TY76Z2rM5mHXA, David Laight,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 3443 bytes --]
On Tue, Jan 07, 2014 at 05:29:48AM -0800, walt wrote:
> On 01/06/2014 04:31 PM, Sarah Sharp wrote:
> > Hi Walt,
> >
> > I have a couple of patches for you to test.
>
> > Please only apply the first patch (which is diagnostic only), trigger
> > your issue, and send me the resulting dmesg. Then try applying the
> > other two patches, and see if the issue goes away. (I suspect it won't
> > but I can't be sure.)
>
> Thanks Sarah. dmesg0 is from the diagnostic patch only. dmesg1 has all
> three patches applied. Some of the messages in dmesg1 fell off the end of
> the kernel buffer, so I may need to make the buffer larger next time but
> I'll need a reminder of how to do it.
Set CONFIG_LOG_BUF_SHIFT to 21.
> As you suspected, the patches didn't fix the problem, sorry.
Yep, I thought so. I did glean one bit of information from the logs: it
seems that your host does handle no-op TRBs, at least for a while.
However, after a bigger chunk of TRBs, it goes off into la-la-land.
Assuming one of the rings is comprised of two segments:
0xbb711000 (start)
0xbb7113f0 (end)
0xbb711400 (start)
0xbb7117f0 (end)
The log show no-ops were inserted at:
0xbb7207d0
0xbb7206a0
0xbb720be0
0xbb720be0
0xbb720bd0
0xbb7207e0
0xbb711370 = 8 no-ops
0xbb7117c0 = 3
0xbb7113b0 = 4
0xbb7113a0 = 5
0xbb7117d0 = 2
0xbb711340 = 11
0xbb711770 = 8
0xbb711230 = 28
0xbb7117e0 = 1
0xbb7117b0 = 4
0xbb7113d0 = 2
0xbb7117b0 = 4
0xbb711340 = 11
0xbb711690 = 22
So the host was able to process 28 no-op TRBs, but failed on 22 no-ops
later. The event ring debugging shows the last event was for
0xbb711680, which is the last TRB before the first no-op inserted before
the host died. There's no Stop Endpoint Command completion, and it
looks like the command was correctly put on the command ring, so it
seems the host is actually hanging for some reason.
Unfortunately, I made a mistake in the debugging patch I sent
you, so it didn't print out the endpoint rings when the host died. I
need that info, to see whether the link TRB was still intact, or if we
over-wrote it and caused the host to go fetch some invalid memory.
Can you please try the attached patch, on top of the previous three
patches, and send me dmesg?
> I find that I can tell in advance whether the copy is going to succeed,
> just by watching the light flicker on the usb3 drive. When the flicker
> is absolutely regular, with no variation whatever, I can tell in 10 or
> 15 seconds that the copy will fail.
>
> At the same time the light on the main drive goes dark after 10 seconds,
> implying that the usb3 drive stops receiving any data from the main drive
> after 10 seconds, yet the light on the usb3 drive continues to flicker as
> if writing data -- even after the cp officially fails. The light on the
> usb3 drive never stops flickering until I reboot the machine or unplug
> the usb cable.
Interesting. Without a USB analyzer, we can't really tell what's
happening. However, one hypothesis could be that the blinking light is
triggered by an active SCSI command (read/write, etc).
There are three phases of the command: setup, data, and status. I think
your device is getting the setup phase, and the host is dying before it
sends the data phase. If the light blinks when it gets a setup phase,
and turns off when the devices sends a status phase, that would explain
its behavior.
But that's just a hypothesis, I have no idea whether it's correct.
Sarah Sharp
[-- Attachment #2: 0001-More-debugging.patch --]
[-- Type: text/x-diff, Size: 2464 bytes --]
>From d085fb5b9630e935d7954fe5947b48402e43bdc1 Mon Sep 17 00:00:00 2001
From: Sarah Sharp <sarah.a.sharp-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Date: Tue, 7 Jan 2014 12:39:47 -0800
Subject: [PATCH] More debugging.
Signed-off-by: Sarah Sharp <sarah.a.sharp-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
drivers/usb/host/xhci-ring.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 2afaf15009e8..228ab8cf868e 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -993,6 +993,9 @@ void xhci_stop_endpoint_command_watchdog(unsigned long arg)
for (i = 0; i < MAX_HC_SLOTS; i++) {
if (!xhci->devs[i])
continue;
+
+ xhci_dbg(xhci, "Slot %d output context\n", i);
+ xhci_dbg_ctx(xhci, xhci->devs[i]->out_ctx, 30);
for (j = 0; j < 31; j++) {
temp_ep = &xhci->devs[i]->eps[j];
ring = temp_ep->ring;
@@ -1001,6 +1004,10 @@ void xhci_stop_endpoint_command_watchdog(unsigned long arg)
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
"Killing URBs for slot ID %u, "
"ep index %u", i, j);
+ xhci_dbg(xhci, "Dev %i Ep 0x%x:\n", i,
+ xhci_get_endpoint_address(j));
+ xhci_debug_ring(xhci, ring);
+ xhci_dbg_ring_ptrs(xhci, ring);
while (!list_empty(&ring->td_list)) {
cur_td = list_first_entry(&ring->td_list,
struct xhci_td,
@@ -1011,12 +1018,6 @@ void xhci_stop_endpoint_command_watchdog(unsigned long arg)
xhci_giveback_urb_in_irq(xhci, cur_td,
-ESHUTDOWN, "killed");
}
- if (!list_empty(&temp_ep->cancelled_td_list)) {
- xhci_dbg(xhci, "Dev %i Ep 0x%x:\n", i,
- xhci_get_endpoint_address(j));
- xhci_debug_ring(xhci, ring);
- xhci_dbg_ring_ptrs(xhci, ring);
- }
while (!list_empty(&temp_ep->cancelled_td_list)) {
cur_td = list_first_entry(
&temp_ep->cancelled_td_list,
@@ -2980,10 +2981,10 @@ static int prepare_ring(struct xhci_hcd *xhci, struct xhci_ring *ep_ring,
num_trbs, TRBS_PER_SEGMENT - 1);
return -EINVAL;
}
- xhci_dbg(xhci, "Insert no-op TRBs at 0x%llx\n",
- (unsigned long long)
+ xhci_dbg(xhci, "Insert %i no-op TRBs from 0x%llx for TD with %i TRBs\n",
+ usable, (unsigned long long)
xhci_trb_virt_to_dma(ep_ring->enq_seg,
- ep_ring->enqueue));
+ ep_ring->enqueue), num_trbs);
nop_cmd = cpu_to_le32(TRB_TYPE(TRB_TR_NOOP) |
ep_ring->cycle_state);
--
1.8.3.3
^ permalink raw reply related [flat|nested] 196+ messages in thread* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2014-01-07 21:21 ` Sarah Sharp
(?)
@ 2014-01-08 0:47 ` Sarah Sharp
2014-01-08 1:35 ` walt
` (2 more replies)
-1 siblings, 3 replies; 196+ messages in thread
From: Sarah Sharp @ 2014-01-08 0:47 UTC (permalink / raw)
To: walt
Cc: Alan Stern, Greg Kroah-Hartman, Linux Kernel, stable,
David Laight, linux-usb, linux-scsi
On Tue, Jan 07, 2014 at 03:57:00PM -0800, walt wrote:
> On 01/07/2014 01:21 PM, Sarah Sharp wrote:
>
> > Can you please try the attached patch, on top of the previous three
> > patches, and send me dmesg?
>
> Hi Sarah, I just now finished running 0001-More-debugging.patch for the
> first time. The previous dmesg didn't include that patch, but this one
> does.
>
> I read through this dmesg but I nodded off somewhere around line 500.
> I hope you can stay awake :)
Well, it has all the info I need, but the results don't make me too
happy. Everything I've checked seems consistent, and I don't know why
the host stopped. The link TRBs are intact, the dequeue pointer for the
endpoint was pointing to the transfer that timed out and it had the
cycle bit set correctly, etc. Perhaps the no-op TRBs are really the
issue.
I'll have to take a look at the log again tomorrow. I posted the dmesg
on pastebin if David wants to check it out as well:
http://pastebin.com/a4AUpsL1
Can you send me the output of `sudo lspci -vvv -n`? Maybe we can just
turn off scatter-gather for your host controller until we get a proper
fix in that uses link TRBs instead of no-op TRBs.
Sarah Sharp
^ permalink raw reply [flat|nested] 196+ messages in thread* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2014-01-08 0:47 ` Sarah Sharp
@ 2014-01-08 1:35 ` walt
2014-01-08 16:09 ` David Laight
2014-01-08 16:39 ` Alan Stern
2 siblings, 0 replies; 196+ messages in thread
From: walt @ 2014-01-08 1:35 UTC (permalink / raw)
To: linux-scsi; +Cc: linux-kernel, stable, linux-usb
[-- Attachment #1: Type: text/plain, Size: 723 bytes --]
On 01/07/2014 04:47 PM, Sarah Sharp wrote:
> On Tue, Jan 07, 2014 at 03:57:00PM -0800, walt wrote:
>> On 01/07/2014 01:21 PM, Sarah Sharp wrote:
>>
>>> Can you please try the attached patch, on top of the previous three
>>> patches, and send me dmesg?
>>
>> Hi Sarah, I just now finished running 0001-More-debugging.patch for the
>> first time. The previous dmesg didn't include that patch, but this one
>> does.
> Well, it has all the info I need, but the results don't make me too
> happy.
Ouch. Sorry :/
> Can you send me the output of `sudo lspci -vvv -n`? Maybe we can just
> turn off scatter-gather for your host controller until we get a proper
> fix in that uses link TRBs instead of no-op TRBs.
Attached.
[-- Attachment #2: lspci.gz --]
[-- Type: application/gzip, Size: 3456 bytes --]
^ permalink raw reply [flat|nested] 196+ messages in thread
* RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2014-01-08 0:47 ` Sarah Sharp
2014-01-08 1:35 ` walt
@ 2014-01-08 16:09 ` David Laight
[not found] ` <52CCA94D.5090700@gmail.com>
2014-01-08 16:39 ` Alan Stern
2 siblings, 1 reply; 196+ messages in thread
From: David Laight @ 2014-01-08 16:09 UTC (permalink / raw)
To: 'Sarah Sharp', walt
Cc: Alan Stern, Greg Kroah-Hartman, Linux Kernel, stable, linux-usb,
linux-scsi
> From: Sarah Sharp
> On Tue, Jan 07, 2014 at 03:57:00PM -0800, walt wrote:
> > On 01/07/2014 01:21 PM, Sarah Sharp wrote:
> >
> > > Can you please try the attached patch, on top of the previous three
> > > patches, and send me dmesg?
> >
> > Hi Sarah, I just now finished running 0001-More-debugging.patch for the
> > first time. The previous dmesg didn't include that patch, but this one
> > does.
> >
> > I read through this dmesg but I nodded off somewhere around line 500.
> > I hope you can stay awake :)
>
> Well, it has all the info I need, but the results don't make me too
> happy. Everything I've checked seems consistent, and I don't know why
> the host stopped. The link TRBs are intact, the dequeue pointer for the
> endpoint was pointing to the transfer that timed out and it had the
> cycle bit set correctly, etc. Perhaps the no-op TRBs are really the
> issue.
>
> I'll have to take a look at the log again tomorrow. I posted the dmesg
> on pastebin if David wants to check it out as well:
> http://pastebin.com/a4AUpsL1
I can't see anything obvious either.
However there is no response to the 'stop endpoint' command.
Section 4.6.9 (page 107 of rev1.0) states that the controller will complete
any USB IN or OUT transaction before raising the command completion event.
Possibly it is too 'stuck' to complete the transaction?
The endpoint status is also still '1' (running).
This also means that the 'TR dequeue pointer' is undefined - so the
controller could easily be processing a later TRB.
This field might even still contain the ring base address written by
the driver much earlier.
This might mean that something 'catastrophic' has happened earlier.
Maybe the controller isn't actually seeing any doorbell writes at all.
Maybe the base addresses it has for the rings have all got corrupted.
At least this looks like amd64 - so there aren't memory coherency issues.
Some hacks that might help isolate the problem:
1) Request an interrupt from the last nop data TRB.
2) Put a command nop (decimal 23) TRB into the command ring before
the 'stop endpoint'.
3) Comment out the code that adds the nop data TRBs.
The first two might need code adding to handle the responses.
Do we know the actual xhci device?
I think it reports version 0x96.
(Sarah - it might be useful if that version were in one of the trace
messages that is output by default.)
David
^ permalink raw reply [flat|nested] 196+ messages in thread* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2014-01-08 0:47 ` Sarah Sharp
@ 2014-01-08 16:39 ` Alan Stern
2014-01-08 16:09 ` David Laight
2014-01-08 16:39 ` Alan Stern
2 siblings, 0 replies; 196+ messages in thread
From: Alan Stern @ 2014-01-08 16:39 UTC (permalink / raw)
To: Sarah Sharp
Cc: walt, Greg Kroah-Hartman, Linux Kernel, stable, David Laight,
linux-usb, linux-scsi
On Tue, 7 Jan 2014, Sarah Sharp wrote:
> On Tue, Jan 07, 2014 at 03:57:00PM -0800, walt wrote:
> > On 01/07/2014 01:21 PM, Sarah Sharp wrote:
> >
> > > Can you please try the attached patch, on top of the previous three
> > > patches, and send me dmesg?
> >
> > Hi Sarah, I just now finished running 0001-More-debugging.patch for the
> > first time. The previous dmesg didn't include that patch, but this one
> > does.
> >
> > I read through this dmesg but I nodded off somewhere around line 500.
> > I hope you can stay awake :)
>
> Well, it has all the info I need, but the results don't make me too
> happy. Everything I've checked seems consistent, and I don't know why
> the host stopped. The link TRBs are intact, the dequeue pointer for the
> endpoint was pointing to the transfer that timed out and it had the
> cycle bit set correctly, etc. Perhaps the no-op TRBs are really the
> issue.
This may be a foolish question, but why is xhci-hcd using no-op TRBs in
the first place?
It makes sense that they would be needed if you have to unlink an URB
that isn't the first one on the endpoint ring. But usb-storage never
does that; whenever it unlinks an URB, it always unlinks the earliest
entry in the endpoint's queue.
After unlinking the first URB on the ring, you don't need to fill in
its TRBs with no-ops. Instead, when you are ready to start the ring
againk, just tell the host controller to move the dequeue pointer up to
the start of the next surviving URB. (You'll also have to adjust the
CYCLE bits of the TRBs that get skipped over, but that's trivial.)
Alan Stern
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
@ 2014-01-08 16:39 ` Alan Stern
0 siblings, 0 replies; 196+ messages in thread
From: Alan Stern @ 2014-01-08 16:39 UTC (permalink / raw)
To: Sarah Sharp
Cc: walt, Greg Kroah-Hartman, Linux Kernel, stable, David Laight,
linux-usb, linux-scsi
On Tue, 7 Jan 2014, Sarah Sharp wrote:
> On Tue, Jan 07, 2014 at 03:57:00PM -0800, walt wrote:
> > On 01/07/2014 01:21 PM, Sarah Sharp wrote:
> >
> > > Can you please try the attached patch, on top of the previous three
> > > patches, and send me dmesg?
> >
> > Hi Sarah, I just now finished running 0001-More-debugging.patch for the
> > first time. The previous dmesg didn't include that patch, but this one
> > does.
> >
> > I read through this dmesg but I nodded off somewhere around line 500.
> > I hope you can stay awake :)
>
> Well, it has all the info I need, but the results don't make me too
> happy. Everything I've checked seems consistent, and I don't know why
> the host stopped. The link TRBs are intact, the dequeue pointer for the
> endpoint was pointing to the transfer that timed out and it had the
> cycle bit set correctly, etc. Perhaps the no-op TRBs are really the
> issue.
This may be a foolish question, but why is xhci-hcd using no-op TRBs in
the first place?
It makes sense that they would be needed if you have to unlink an URB
that isn't the first one on the endpoint ring. But usb-storage never
does that; whenever it unlinks an URB, it always unlinks the earliest
entry in the endpoint's queue.
After unlinking the first URB on the ring, you don't need to fill in
its TRBs with no-ops. Instead, when you are ready to start the ring
againk, just tell the host controller to move the dequeue pointer up to
the start of the next surviving URB. (You'll also have to adjust the
CYCLE bits of the TRBs that get skipped over, but that's trivial.)
Alan Stern
^ permalink raw reply [flat|nested] 196+ messages in thread
* RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
@ 2014-01-08 16:51 ` David Laight
0 siblings, 0 replies; 196+ messages in thread
From: David Laight @ 2014-01-08 16:51 UTC (permalink / raw)
To: 'Alan Stern', Sarah Sharp
Cc: walt, Greg Kroah-Hartman, Linux Kernel, stable, linux-usb, linux-scsi
> From: Alan Stern
>
> This may be a foolish question, but why is xhci-hcd using no-op TRBs in
> the first place?
Because it can't write in a link TRB because other parts of the
code use link TRBs to detect the end of the ring.
The problem is that it can't put a link TRB in the middle of
a chain of data fragments unless it is at a 'suitable' offset
from the start of the data TD. Given arbitrary input fragmentation
this means that you can't put a link TRB in the middle of a TD.
(The documented alignment might be as high as 16kB.)
If the rest of the code used a 'ring end pointer' then a link TRB
could be used instead.
David
^ permalink raw reply [flat|nested] 196+ messages in thread
* RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
@ 2014-01-08 16:51 ` David Laight
0 siblings, 0 replies; 196+ messages in thread
From: David Laight @ 2014-01-08 16:51 UTC (permalink / raw)
To: 'Alan Stern', Sarah Sharp
Cc: walt, Greg Kroah-Hartman, Linux Kernel,
stable-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA
> From: Alan Stern
>
> This may be a foolish question, but why is xhci-hcd using no-op TRBs in
> the first place?
Because it can't write in a link TRB because other parts of the
code use link TRBs to detect the end of the ring.
The problem is that it can't put a link TRB in the middle of
a chain of data fragments unless it is at a 'suitable' offset
from the start of the data TD. Given arbitrary input fragmentation
this means that you can't put a link TRB in the middle of a TD.
(The documented alignment might be as high as 16kB.)
If the rest of the code used a 'ring end pointer' then a link TRB
could be used instead.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 196+ messages in thread
* RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
@ 2014-01-08 17:14 ` Alan Stern
0 siblings, 0 replies; 196+ messages in thread
From: Alan Stern @ 2014-01-08 17:14 UTC (permalink / raw)
To: David Laight
Cc: Sarah Sharp, walt, Greg Kroah-Hartman, Linux Kernel, stable,
linux-usb, linux-scsi
On Wed, 8 Jan 2014, David Laight wrote:
> > From: Alan Stern
> >
> > This may be a foolish question, but why is xhci-hcd using no-op TRBs in
> > the first place?
>
> Because it can't write in a link TRB because other parts of the
> code use link TRBs to detect the end of the ring.
>
> The problem is that it can't put a link TRB in the middle of
> a chain of data fragments unless it is at a 'suitable' offset
> from the start of the data TD. Given arbitrary input fragmentation
> this means that you can't put a link TRB in the middle of a TD.
> (The documented alignment might be as high as 16kB.)
>
> If the rest of the code used a 'ring end pointer' then a link TRB
> could be used instead.
I see. Sounds like a poor design decision in hindsight. Can it be
changed?
Alan Stern
^ permalink raw reply [flat|nested] 196+ messages in thread
* RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
@ 2014-01-08 17:14 ` Alan Stern
0 siblings, 0 replies; 196+ messages in thread
From: Alan Stern @ 2014-01-08 17:14 UTC (permalink / raw)
To: David Laight
Cc: Sarah Sharp, walt, Greg Kroah-Hartman, Linux Kernel,
stable-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA
On Wed, 8 Jan 2014, David Laight wrote:
> > From: Alan Stern
> >
> > This may be a foolish question, but why is xhci-hcd using no-op TRBs in
> > the first place?
>
> Because it can't write in a link TRB because other parts of the
> code use link TRBs to detect the end of the ring.
>
> The problem is that it can't put a link TRB in the middle of
> a chain of data fragments unless it is at a 'suitable' offset
> from the start of the data TD. Given arbitrary input fragmentation
> this means that you can't put a link TRB in the middle of a TD.
> (The documented alignment might be as high as 16kB.)
>
> If the rest of the code used a 'ring end pointer' then a link TRB
> could be used instead.
I see. Sounds like a poor design decision in hindsight. Can it be
changed?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 196+ messages in thread
* RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2014-01-08 17:14 ` Alan Stern
(?)
@ 2014-01-08 17:24 ` David Laight
-1 siblings, 0 replies; 196+ messages in thread
From: David Laight @ 2014-01-08 17:24 UTC (permalink / raw)
To: 'Alan Stern'
Cc: Sarah Sharp, walt, Greg Kroah-Hartman, Linux Kernel, stable,
linux-usb, linux-scsi
> From: Alan Stern
> On Wed, 8 Jan 2014, David Laight wrote:
>
> > > From: Alan Stern
> > >
> > > This may be a foolish question, but why is xhci-hcd using no-op TRBs in
> > > the first place?
> >
> > Because it can't write in a link TRB because other parts of the
> > code use link TRBs to detect the end of the ring.
> >
> > The problem is that it can't put a link TRB in the middle of
> > a chain of data fragments unless it is at a 'suitable' offset
> > from the start of the data TD. Given arbitrary input fragmentation
> > this means that you can't put a link TRB in the middle of a TD.
> > (The documented alignment might be as high as 16kB.)
> >
> > If the rest of the code used a 'ring end pointer' then a link TRB
> > could be used instead.
>
> I see. Sounds like a poor design decision in hindsight. Can it be
> changed?
Anything can be changed :-)
But it is a bit pervasive.
Padding out with nops isolated the change.
David
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2014-01-03 23:29 ` Sarah Sharp
@ 2014-01-09 1:22 ` walt
2014-01-09 1:22 ` walt
1 sibling, 0 replies; 196+ messages in thread
From: walt @ 2014-01-09 1:22 UTC (permalink / raw)
To: Sarah Sharp
Cc: Alan Stern, Greg Kroah-Hartman, Linux Kernel, stable,
David Laight, linux-usb, linux-scsi
On 01/03/2014 03:29 PM, Sarah Sharp wrote:
> I'll let you know when I have some diagnostic patches ready.
Hi Sarah. I see today gregkh committed the patches you've already sent
me, so I assume someone (other than me) has tested those patches and
discovered some benefit from them?
I'm still wondering if I'm suffering from hardware quirks. From the
first day I installed my usb3 adapter card and the usb3 disk docking
station I've noticed some quirky behavior.
e.g. I boot the machine with the docking station powered-off, and then
later I power it on, the usb3 disk is not detected at all -- until I
reboot the machine with the docking station still powered on.
Minor stuff, yes, but maybe relevant? I dunno.
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
@ 2014-01-09 1:22 ` walt
0 siblings, 0 replies; 196+ messages in thread
From: walt @ 2014-01-09 1:22 UTC (permalink / raw)
To: Sarah Sharp
Cc: Alan Stern, Greg Kroah-Hartman, Linux Kernel,
stable-u79uwXL29TY76Z2rM5mHXA, David Laight,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA
On 01/03/2014 03:29 PM, Sarah Sharp wrote:
> I'll let you know when I have some diagnostic patches ready.
Hi Sarah. I see today gregkh committed the patches you've already sent
me, so I assume someone (other than me) has tested those patches and
discovered some benefit from them?
I'm still wondering if I'm suffering from hardware quirks. From the
first day I installed my usb3 adapter card and the usb3 disk docking
station I've noticed some quirky behavior.
e.g. I boot the machine with the docking station powered-off, and then
later I power it on, the usb3 disk is not detected at all -- until I
reboot the machine with the docking station still powered on.
Minor stuff, yes, but maybe relevant? I dunno.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 196+ messages in thread
* RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2014-01-09 1:22 ` walt
@ 2014-01-09 10:05 ` David Laight
-1 siblings, 0 replies; 196+ messages in thread
From: David Laight @ 2014-01-09 10:05 UTC (permalink / raw)
To: 'walt', Sarah Sharp
Cc: Alan Stern, Greg Kroah-Hartman, Linux Kernel, stable, linux-usb,
linux-scsi
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 722 bytes --]
> From: walt
...
> I'm still wondering if I'm suffering from hardware quirks. From the
> first day I installed my usb3 adapter card and the usb3 disk docking
> station I've noticed some quirky behavior.
Ah - this isn't an 'on chip' usb3 adapter.
Some kind of PCIe card ?
> e.g. I boot the machine with the docking station powered-off, and then
> later I power it on, the usb3 disk is not detected at all -- until I
> reboot the machine with the docking station still powered on.
That will be something completely different to failures when running.
David
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
^ permalink raw reply [flat|nested] 196+ messages in thread* RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
@ 2014-01-09 10:05 ` David Laight
0 siblings, 0 replies; 196+ messages in thread
From: David Laight @ 2014-01-09 10:05 UTC (permalink / raw)
To: 'walt', Sarah Sharp
Cc: Alan Stern, Greg Kroah-Hartman, Linux Kernel, stable, linux-usb,
linux-scsi
> From: walt
...
> I'm still wondering if I'm suffering from hardware quirks. From the
> first day I installed my usb3 adapter card and the usb3 disk docking
> station I've noticed some quirky behavior.
Ah - this isn't an 'on chip' usb3 adapter.
Some kind of PCIe card ?
> e.g. I boot the machine with the docking station powered-off, and then
> later I power it on, the usb3 disk is not detected at all -- until I
> reboot the machine with the docking station still powered on.
That will be something completely different to failures when running.
David
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
@ 2014-01-09 15:10 ` walt
0 siblings, 0 replies; 196+ messages in thread
From: walt @ 2014-01-09 15:10 UTC (permalink / raw)
To: David Laight, Sarah Sharp
Cc: Alan Stern, Greg Kroah-Hartman, Linux Kernel, stable, linux-usb,
linux-scsi
On 01/09/2014 02:05 AM, David Laight wrote:
>> From: walt
> ...
>> I'm still wondering if I'm suffering from hardware quirks. From the
>> first day I installed my usb3 adapter card and the usb3 disk docking
>> station I've noticed some quirky behavior.
>
> Ah - this isn't an 'on chip' usb3 adapter.
> Some kind of PCIe card ?
This one:
http://www.sabrent.com/category/controller-cards/PCIX-USB3/
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
@ 2014-01-09 15:10 ` walt
0 siblings, 0 replies; 196+ messages in thread
From: walt @ 2014-01-09 15:10 UTC (permalink / raw)
To: David Laight, Sarah Sharp
Cc: Alan Stern, Greg Kroah-Hartman, Linux Kernel,
stable-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA
On 01/09/2014 02:05 AM, David Laight wrote:
>> From: walt
> ...
>> I'm still wondering if I'm suffering from hardware quirks. From the
>> first day I installed my usb3 adapter card and the usb3 disk docking
>> station I've noticed some quirky behavior.
>
> Ah - this isn't an 'on chip' usb3 adapter.
> Some kind of PCIe card ?
This one:
http://www.sabrent.com/category/controller-cards/PCIX-USB3/
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2014-01-03 15:40 ` walt
2014-01-03 19:54 ` Sarah Sharp
@ 2014-01-04 14:03 ` Mark Lord
2014-01-06 10:35 ` David Laight
2 siblings, 0 replies; 196+ messages in thread
From: Mark Lord @ 2014-01-04 14:03 UTC (permalink / raw)
To: walt, Sarah Sharp, Alan Stern
Cc: Greg Kroah-Hartman, linux-kernel, stable, David Laight,
linux-usb, linux-scsi
On 14-01-03 10:40 AM, walt wrote:
> On 01/02/2014 11:15 AM, Sarah Sharp wrote:
>> On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
>>> On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
>>>> 3.12-stable review patch. If anyone has any objections, please let me know.
>>>>
>>>> ------------------
>>>>
>>>> From: David Laight <David.Laight@ACULAB.COM>
>>>>
>>>> commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e upstream.
>>>>
>>>> Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB
>>>> can only occur at a boundary between underlying USB frames (512 bytes for
>>>> high speed devices).
>>>>
>>>> If this isn't done the USB frames aren't formatted correctly and, for example,
>>>> the USB3 ethernet ax88179_178a card will stop sending...
>>>
>>>
>>> Unfortunately this patch causes a regression when copying large files to my
>>> outboard USB3 drive. (Nothing at all to do with networking.)
>
>> Do you have CONFIG_USB_DEBUG turned on for 3.13? If so, you should see
>> dmesg output from this statement shortly before your drive fails:
>>
>> if (num_trbs >= TRBS_PER_SEGMENT) {
>> xhci_err(xhci, "Too many fragments %d, max %d\n",
>> num_trbs, TRBS_PER_SEGMENT - 1);
>> return -ENOMEM;
>> }
>
> Well, the answers depend on whether the usb3 drive uses logical volumes or not
> (lvm2), which I can't explain. What I've described so far is with lvm2.
>
> When using lvm2 on the usb3 drive, turning on USB_DEBUG has *no* effect -- the
> console prints two or three lines stating that the ext4 journal has quit and
> the drive is remounted ro. That particular drive stays wedged until the next
> reboot, but no other ill effects to the system.
>
> OTOH, when I put a disk with just an ordinary ext4 partition in the usb3 dock,
> (no logical volumes) the copy failure becomes catastrophic, with kernel panic
> messages, leaving the system unresponsive and needing a hard reset to recover.
>
> I also tried your other suggestion:
>
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 4265b48..1a6a43d 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -4714,7 +4714,7 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks)
> int retval;
>
> /* Accept arbitrarily long scatter-gather lists */
> - hcd->self.sg_tablesize = ~0;
> + hcd->self.sg_tablesize = 31;
>
> /* support to build packet from discontinuous buffers */
> hcd->self.no_sg_constraint = 1;
>
> Sadly it didn't fix the problem. Did I get the patch right?
That sounds almost as if the old version is still being loaded/run,
possibly from the initramfs image?
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply [flat|nested] 196+ messages in thread* RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
2014-01-03 15:40 ` walt
@ 2014-01-06 10:35 ` David Laight
2014-01-04 14:03 ` Mark Lord
2014-01-06 10:35 ` David Laight
2 siblings, 0 replies; 196+ messages in thread
From: David Laight @ 2014-01-06 10:35 UTC (permalink / raw)
To: 'walt', Sarah Sharp, Alan Stern
Cc: Greg Kroah-Hartman, linux-kernel, stable, Mark Lord, linux-usb,
linux-scsi
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1343 bytes --]
> From: walt
...
> /* Accept arbitrarily long scatter-gather lists */
> - hcd->self.sg_tablesize = ~0;
> + hcd->self.sg_tablesize = 31;
Even if that reduces the number of fragments passed to the xhci driver
it may not be enough to limit the actual number of fragments that
need to be placed in the ring itself.
The xhci driver has to split every fragment on any 64k address boundary.
One possibility is to scan long SG lists to see it they are actually
problematic. If all the fragments are suitably aligned let them through
(without any nops).
My gut feeling is that problems only arise when the ring end isn't at
a 1k boundary in the data.
So provided all the fragments are multiples of 1k (after splitting on 64k
boundaries) the transfer will be processed correctly.
Alternatively, if the fragments are all longer than 1k (after the 64k split),
the one that crosses the ring end can be split in two.
A quick 'fix' would be to assume that anything with too many fragments is
probably ok - maybe check the first fragment is suitably aligned.
That would recover the old behaviour for usb disk transfers with a lot
of fragments - yes it is a hack...
David
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
^ permalink raw reply [flat|nested] 196+ messages in thread* RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
@ 2014-01-06 10:35 ` David Laight
0 siblings, 0 replies; 196+ messages in thread
From: David Laight @ 2014-01-06 10:35 UTC (permalink / raw)
To: 'walt', Sarah Sharp, Alan Stern
Cc: Greg Kroah-Hartman, linux-kernel, stable, Mark Lord, linux-usb,
linux-scsi
> From: walt
...
> /* Accept arbitrarily long scatter-gather lists */
> - hcd->self.sg_tablesize = ~0;
> + hcd->self.sg_tablesize = 31;
Even if that reduces the number of fragments passed to the xhci driver
it may not be enough to limit the actual number of fragments that
need to be placed in the ring itself.
The xhci driver has to split every fragment on any 64k address boundary.
One possibility is to scan long SG lists to see it they are actually
problematic. If all the fragments are suitably aligned let them through
(without any nops).
My gut feeling is that problems only arise when the ring end isn't at
a 1k boundary in the data.
So provided all the fragments are multiples of 1k (after splitting on 64k
boundaries) the transfer will be processed correctly.
Alternatively, if the fragments are all longer than 1k (after the 64k split),
the one that crosses the ring end can be split in two.
A quick 'fix' would be to assume that anything with too many fragments is
probably ok - maybe check the first fragment is suitably aligned.
That would recover the old behaviour for usb disk transfers with a lot
of fragments - yes it is a hack...
David
^ permalink raw reply [flat|nested] 196+ messages in thread
* [PATCH 3.12 034/118] usb: musb: musb_cppi41: factor most of cppi41_dma_callback() into cppi41_trans_done()
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (31 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 035/118] usb: musb: musb_cppi41: handle pre-mature TX complete interrupt Greg Kroah-Hartman
` (83 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sebastian Andrzej Siewior, Felipe Balbi
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
commit d373a8534d5e1e7a350e40d3c11961a7cd8d530b upstream.
This patch moves most of the logic in cppi41_dma_callback() into
cppi41_trans_done() where it can be called from another function.
Instead of computing "transferred" (the number of bytes transferred in
the last transaction) in cppi41_trans_done() the member
"cppi41_channel->prog_len" is now set to 0 if the transfer as a whole
can be considered as done. If it is != 0 then the next iteration is
assumed.
This is a preparation for a workaround.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/musb/musb_cppi41.c | 59 +++++++++++++++++++++++++----------------
1 file changed, 36 insertions(+), 23 deletions(-)
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -96,31 +96,15 @@ static void update_rx_toggle(struct cppi
cppi41_channel->usb_toggle = toggle;
}
-static void cppi41_dma_callback(void *private_data)
+static void cppi41_dma_callback(void *private_data);
+
+static void cppi41_trans_done(struct dma_channel *channel)
{
- struct dma_channel *channel = private_data;
struct cppi41_dma_channel *cppi41_channel = channel->private_data;
struct musb_hw_ep *hw_ep = cppi41_channel->hw_ep;
struct musb *musb = hw_ep->musb;
- unsigned long flags;
- struct dma_tx_state txstate;
- u32 transferred;
- spin_lock_irqsave(&musb->lock, flags);
-
- dmaengine_tx_status(cppi41_channel->dc, cppi41_channel->cookie,
- &txstate);
- transferred = cppi41_channel->prog_len - txstate.residue;
- cppi41_channel->transferred += transferred;
-
- dev_dbg(musb->controller, "DMA transfer done on hw_ep=%d bytes=%d/%d\n",
- hw_ep->epnum, cppi41_channel->transferred,
- cppi41_channel->total_len);
-
- update_rx_toggle(cppi41_channel);
-
- if (cppi41_channel->transferred == cppi41_channel->total_len ||
- transferred < cppi41_channel->packet_sz) {
+ if (!cppi41_channel->prog_len) {
/* done, complete */
cppi41_channel->channel.actual_len =
@@ -150,10 +134,8 @@ static void cppi41_dma_callback(void *pr
remain_bytes,
direction,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
- if (WARN_ON(!dma_desc)) {
- spin_unlock_irqrestore(&musb->lock, flags);
+ if (WARN_ON(!dma_desc))
return;
- }
dma_desc->callback = cppi41_dma_callback;
dma_desc->callback_param = channel;
@@ -166,6 +148,37 @@ static void cppi41_dma_callback(void *pr
musb_writew(epio, MUSB_RXCSR, csr);
}
}
+}
+
+static void cppi41_dma_callback(void *private_data)
+{
+ struct dma_channel *channel = private_data;
+ struct cppi41_dma_channel *cppi41_channel = channel->private_data;
+ struct musb_hw_ep *hw_ep = cppi41_channel->hw_ep;
+ struct musb *musb = hw_ep->musb;
+ unsigned long flags;
+ struct dma_tx_state txstate;
+ u32 transferred;
+
+ spin_lock_irqsave(&musb->lock, flags);
+
+ dmaengine_tx_status(cppi41_channel->dc, cppi41_channel->cookie,
+ &txstate);
+ transferred = cppi41_channel->prog_len - txstate.residue;
+ cppi41_channel->transferred += transferred;
+
+ dev_dbg(musb->controller, "DMA transfer done on hw_ep=%d bytes=%d/%d\n",
+ hw_ep->epnum, cppi41_channel->transferred,
+ cppi41_channel->total_len);
+
+ update_rx_toggle(cppi41_channel);
+
+ if (cppi41_channel->transferred == cppi41_channel->total_len ||
+ transferred < cppi41_channel->packet_sz)
+ cppi41_channel->prog_len = 0;
+
+ cppi41_trans_done(channel);
+
spin_unlock_irqrestore(&musb->lock, flags);
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 035/118] usb: musb: musb_cppi41: handle pre-mature TX complete interrupt
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (32 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 034/118] usb: musb: musb_cppi41: factor most of cppi41_dma_callback() into cppi41_trans_done() Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 036/118] USB: serial: option: blacklist interface 1 for Huawei E173s-6 Greg Kroah-Hartman
` (82 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bin Liu, Sebastian Andrzej Siewior,
Felipe Balbi
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
commit a655f481d83d6d37bec0a2ddfdd24c30ff8f541f upstream.
The TX-complete interrupt of the CPPI41 on AM335x fires too early.
Adding a loop and counting how long it takes until the
MUSB_TXCSR_TXPKTRDY bit is cleared I see
FS:
|musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=64, mode=0, dma_addr=0xadc54002, len=1514 is_tx=1
|cppi41_dma_callback() 74 loops
|musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=64, mode=0, dma_addr=0xadcd8802, len=1514 is_tx=1
|cppi41_dma_callback() 66 loops
|musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=64, mode=0, dma_addr=0xadcd8002, len=1514 is_tx=1
|cppi41_dma_callback() 136 loops
|musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=64, mode=0, dma_addr=0xadf55802, len=1514 is_tx=1
|cppi41_dma_callback() 136 loops
avg: 110 - 150us
HS:
|musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=512, mode=0, dma_addr=0xaca6f002, len=1514 is_tx=1
|cppi41_dma_callback() 0 loops
|musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=512, mode=0, dma_addr=0xadd6f802, len=1514 is_tx=1
|cppi41_dma_callback() 2 loops
|musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=512, mode=0, dma_addr=0xadd6f002, len=1514 is_tx=1
|cppi41_dma_callback() 13 loops
avg: 2us
for the same test case. One loop means a udelay(1). The delay seems to
depend on the packet size. On HS the bit is always cleared for small
packet sizes while on FS it is never the case, it mostly around 110us.
This testing has been performed with g_ether (musb as device) and using BULK
transfers.
INTR transfers are way more fun: during init the gadget sends a INT
packet to the host and cppi41 says "transfer done" shortly after. The
MUSB_TXCSR_TXPKTRDY bit is set even seconds later. The reason is that the host
did not try to receive it, it does so after the interface (on host side) has
been configured. Until this happens, that packet remains in musb's FIFO.
To fix this, two things are done:
- No DMA transfers for INT based endpoints. These transfer are usually
very small and rare so it is likely better to skip the DMA engine and
stuff the four bytes directly into the FIFO
- on HS we poll up to 25us and hope that bit goes away. If not we setup
a hrtimer to poll for it. The 140us delay is a rule of thumb. In FS
the command
| ping 10.10.10.10 -c1 -s65130
creates about 44 1514bytes transfers. About 19 of them need a second
timer to complete.
Reported-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/musb/musb_cppi41.c | 113 +++++++++++++++++++++++++++++++++++++++--
1 file changed, 108 insertions(+), 5 deletions(-)
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -38,6 +38,7 @@ struct cppi41_dma_channel {
u32 prog_len;
u32 transferred;
u32 packet_sz;
+ struct list_head tx_check;
};
#define MUSB_DMA_NUM_CHANNELS 15
@@ -47,6 +48,8 @@ struct cppi41_dma_controller {
struct cppi41_dma_channel rx_channel[MUSB_DMA_NUM_CHANNELS];
struct cppi41_dma_channel tx_channel[MUSB_DMA_NUM_CHANNELS];
struct musb *musb;
+ struct hrtimer early_tx;
+ struct list_head early_tx_list;
u32 rx_mode;
u32 tx_mode;
u32 auto_req;
@@ -96,11 +99,23 @@ static void update_rx_toggle(struct cppi
cppi41_channel->usb_toggle = toggle;
}
+static bool musb_is_tx_fifo_empty(struct musb_hw_ep *hw_ep)
+{
+ u8 epnum = hw_ep->epnum;
+ struct musb *musb = hw_ep->musb;
+ void __iomem *epio = musb->endpoints[epnum].regs;
+ u16 csr;
+
+ csr = musb_readw(epio, MUSB_TXCSR);
+ if (csr & MUSB_TXCSR_TXPKTRDY)
+ return false;
+ return true;
+}
+
static void cppi41_dma_callback(void *private_data);
-static void cppi41_trans_done(struct dma_channel *channel)
+static void cppi41_trans_done(struct cppi41_dma_channel *cppi41_channel)
{
- struct cppi41_dma_channel *cppi41_channel = channel->private_data;
struct musb_hw_ep *hw_ep = cppi41_channel->hw_ep;
struct musb *musb = hw_ep->musb;
@@ -138,7 +153,7 @@ static void cppi41_trans_done(struct dma
return;
dma_desc->callback = cppi41_dma_callback;
- dma_desc->callback_param = channel;
+ dma_desc->callback_param = &cppi41_channel->channel;
cppi41_channel->cookie = dma_desc->tx_submit(dma_desc);
dma_async_issue_pending(dc);
@@ -150,6 +165,41 @@ static void cppi41_trans_done(struct dma
}
}
+static enum hrtimer_restart cppi41_recheck_tx_req(struct hrtimer *timer)
+{
+ struct cppi41_dma_controller *controller;
+ struct cppi41_dma_channel *cppi41_channel, *n;
+ struct musb *musb;
+ unsigned long flags;
+ enum hrtimer_restart ret = HRTIMER_NORESTART;
+
+ controller = container_of(timer, struct cppi41_dma_controller,
+ early_tx);
+ musb = controller->musb;
+
+ spin_lock_irqsave(&musb->lock, flags);
+ list_for_each_entry_safe(cppi41_channel, n, &controller->early_tx_list,
+ tx_check) {
+ bool empty;
+ struct musb_hw_ep *hw_ep = cppi41_channel->hw_ep;
+
+ empty = musb_is_tx_fifo_empty(hw_ep);
+ if (empty) {
+ list_del_init(&cppi41_channel->tx_check);
+ cppi41_trans_done(cppi41_channel);
+ }
+ }
+
+ if (!list_empty(&controller->early_tx_list)) {
+ ret = HRTIMER_RESTART;
+ hrtimer_forward_now(&controller->early_tx,
+ ktime_set(0, 150 * NSEC_PER_USEC));
+ }
+
+ spin_unlock_irqrestore(&musb->lock, flags);
+ return ret;
+}
+
static void cppi41_dma_callback(void *private_data)
{
struct dma_channel *channel = private_data;
@@ -159,6 +209,7 @@ static void cppi41_dma_callback(void *pr
unsigned long flags;
struct dma_tx_state txstate;
u32 transferred;
+ bool empty;
spin_lock_irqsave(&musb->lock, flags);
@@ -177,8 +228,52 @@ static void cppi41_dma_callback(void *pr
transferred < cppi41_channel->packet_sz)
cppi41_channel->prog_len = 0;
- cppi41_trans_done(channel);
-
+ empty = musb_is_tx_fifo_empty(hw_ep);
+ if (empty) {
+ cppi41_trans_done(cppi41_channel);
+ } else {
+ struct cppi41_dma_controller *controller;
+ /*
+ * On AM335x it has been observed that the TX interrupt fires
+ * too early that means the TXFIFO is not yet empty but the DMA
+ * engine says that it is done with the transfer. We don't
+ * receive a FIFO empty interrupt so the only thing we can do is
+ * to poll for the bit. On HS it usually takes 2us, on FS around
+ * 110us - 150us depending on the transfer size.
+ * We spin on HS (no longer than than 25us and setup a timer on
+ * FS to check for the bit and complete the transfer.
+ */
+ controller = cppi41_channel->controller;
+
+ if (musb->g.speed == USB_SPEED_HIGH) {
+ unsigned wait = 25;
+
+ do {
+ empty = musb_is_tx_fifo_empty(hw_ep);
+ if (empty)
+ break;
+ wait--;
+ if (!wait)
+ break;
+ udelay(1);
+ } while (1);
+
+ empty = musb_is_tx_fifo_empty(hw_ep);
+ if (empty) {
+ cppi41_trans_done(cppi41_channel);
+ goto out;
+ }
+ }
+ list_add_tail(&cppi41_channel->tx_check,
+ &controller->early_tx_list);
+ if (!hrtimer_active(&controller->early_tx)) {
+ hrtimer_start_range_ns(&controller->early_tx,
+ ktime_set(0, 140 * NSEC_PER_USEC),
+ 40 * NSEC_PER_USEC,
+ HRTIMER_MODE_REL);
+ }
+ }
+out:
spin_unlock_irqrestore(&musb->lock, flags);
}
@@ -377,6 +472,8 @@ static int cppi41_is_compatible(struct d
WARN_ON(1);
return 1;
}
+ if (cppi41_channel->hw_ep->ep_in.type != USB_ENDPOINT_XFER_BULK)
+ return 0;
if (cppi41_channel->is_tx)
return 1;
/* AM335x Advisory 1.0.13. No workaround for device RX mode */
@@ -401,6 +498,7 @@ static int cppi41_dma_channel_abort(stru
if (cppi41_channel->channel.status == MUSB_DMA_STATUS_FREE)
return 0;
+ list_del_init(&cppi41_channel->tx_check);
if (is_tx) {
csr = musb_readw(epio, MUSB_TXCSR);
csr &= ~MUSB_TXCSR_DMAENAB;
@@ -507,6 +605,7 @@ static int cppi41_dma_controller_start(s
cppi41_channel->controller = controller;
cppi41_channel->port_num = port;
cppi41_channel->is_tx = is_tx;
+ INIT_LIST_HEAD(&cppi41_channel->tx_check);
musb_dma = &cppi41_channel->channel;
musb_dma->private_data = cppi41_channel;
@@ -531,6 +630,7 @@ void dma_controller_destroy(struct dma_c
struct cppi41_dma_controller *controller = container_of(c,
struct cppi41_dma_controller, controller);
+ hrtimer_cancel(&controller->early_tx);
cppi41_dma_controller_stop(controller);
kfree(controller);
}
@@ -550,6 +650,9 @@ struct dma_controller *dma_controller_cr
if (!controller)
goto kzalloc_fail;
+ hrtimer_init(&controller->early_tx, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+ controller->early_tx.function = cppi41_recheck_tx_req;
+ INIT_LIST_HEAD(&controller->early_tx_list);
controller->musb = musb;
controller->controller.channel_alloc = cppi41_dma_channel_allocate;
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 036/118] USB: serial: option: blacklist interface 1 for Huawei E173s-6
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (33 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 035/118] usb: musb: musb_cppi41: handle pre-mature TX complete interrupt Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 037/118] USB: option: support new huawei devices Greg Kroah-Hartman
` (81 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Gustavo Zacarias
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gustavo Zacarias <gustavo@zacarias.com.ar>
commit 8f173e22abf2258ddfa73f46eadbb6a6c29f1631 upstream.
Interface 1 on this device isn't for option to bind to otherwise an oops
on usb_wwan with log flooding will happen when accessing the port:
tty_release: ttyUSB1: read/write wait queue active!
It doesn't seem to respond to QMI if it's added to qmi_wwan so don't add
it there - it's likely used by the card reader.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/option.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -85,6 +85,7 @@ static void option_instat_callback(struc
#define HUAWEI_PRODUCT_K4505 0x1464
#define HUAWEI_PRODUCT_K3765 0x1465
#define HUAWEI_PRODUCT_K4605 0x14C6
+#define HUAWEI_PRODUCT_E173S6 0x1C07
#define QUANTA_VENDOR_ID 0x0408
#define QUANTA_PRODUCT_Q101 0xEA02
@@ -572,6 +573,8 @@ static const struct usb_device_id option
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x1c23, USB_CLASS_COMM, 0x02, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E173, 0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t) &net_intf1_blacklist },
+ { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E173S6, 0xff, 0xff, 0xff),
+ .driver_info = (kernel_ulong_t) &net_intf1_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1750, 0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t) &net_intf2_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x1441, USB_CLASS_COMM, 0x02, 0xff) },
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 037/118] USB: option: support new huawei devices
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (34 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 036/118] USB: serial: option: blacklist interface 1 for Huawei E173s-6 Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 038/118] Input: usbtouchscreen - separate report and transmit buffer size handling Greg Kroah-Hartman
` (80 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, fangxiaozhi
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Fangxiaozhi (Franko)" <fangxiaozhi@huawei.com>
commit 2bf308d7bc5e8cdd69672199f59532f35339133c upstream.
Add new supporting declarations to option.c, to support Huawei new
devices with new bInterfaceProtocol value.
Signed-off-by: fangxiaozhi <huananhu@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/option.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -637,6 +637,10 @@ static const struct usb_device_id option
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x6D) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x6E) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x6F) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x72) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x73) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x74) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x75) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x78) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x79) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x7A) },
@@ -691,6 +695,10 @@ static const struct usb_device_id option
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x6D) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x6E) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x6F) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x72) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x73) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x74) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x75) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x78) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x79) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x7A) },
@@ -745,6 +753,10 @@ static const struct usb_device_id option
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x6D) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x6E) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x6F) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x72) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x73) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x74) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x75) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x78) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x79) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x7A) },
@@ -799,6 +811,10 @@ static const struct usb_device_id option
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x6D) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x6E) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x6F) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x72) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x73) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x74) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x75) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x78) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x79) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x7A) },
@@ -853,6 +869,10 @@ static const struct usb_device_id option
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x05, 0x6D) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x05, 0x6E) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x05, 0x6F) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x05, 0x72) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x05, 0x73) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x05, 0x74) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x05, 0x75) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x05, 0x78) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x05, 0x79) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x05, 0x7A) },
@@ -907,6 +927,10 @@ static const struct usb_device_id option
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x06, 0x6D) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x06, 0x6E) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x06, 0x6F) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x06, 0x72) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x06, 0x73) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x06, 0x74) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x06, 0x75) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x06, 0x78) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x06, 0x79) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x06, 0x7A) },
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 038/118] Input: usbtouchscreen - separate report and transmit buffer size handling
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (35 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 037/118] USB: option: support new huawei devices Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 039/118] media: af9035: fix broken I2C and USB I/O Greg Kroah-Hartman
` (79 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christian Engelmayer, Dmitry Torokhov
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian Engelmayer <christian.engelmayer@frequentis.com>
commit 4ef38351d770cc421f4a0c7a849fd13207fc5741 upstream.
This patch supports the separate handling of the USB transfer buffer length
and the length of the buffer used for multi packet support. For devices
supporting multiple report or diagnostic packets, the USB transfer size is now
limited to the USB endpoints wMaxPacketSize - otherwise it defaults to the
configured report packet size as before.
This fixes an issue where event reporting can be delayed for an arbitrary
time for multi packet devices. For instance the report size for eGalax devices
is defined to the 16 byte maximum diagnostic packet size as opposed to the 5
byte report packet size. In case the driver requests 16 byte from the USB
interrupt endpoint, the USB host controller driver needs to split up the
request into 2 accesses according to the endpoints wMaxPacketSize of 8 byte.
When the first transfer is answered by the eGalax device with not less than
the full 8 byte requested, the host controller has got no way of knowing
whether the touch controller has got additional data queued and will issue
the second transfer. If per example a liftoff event finishes at such a
wMaxPacketSize boundary, the data will not be available to the usbtouch driver
until a further event is triggered and transfered to the host. From user
perspective the BTN_TOUCH release event in this case is stuck until the next
touch down event.
Signed-off-by: Christian Engelmayer <christian.engelmayer@frequentis.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/touchscreen/usbtouchscreen.c | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
--- a/drivers/input/touchscreen/usbtouchscreen.c
+++ b/drivers/input/touchscreen/usbtouchscreen.c
@@ -106,6 +106,7 @@ struct usbtouch_device_info {
struct usbtouch_usb {
unsigned char *data;
dma_addr_t data_dma;
+ int data_size;
unsigned char *buffer;
int buf_len;
struct urb *irq;
@@ -1521,7 +1522,7 @@ static int usbtouch_reset_resume(struct
static void usbtouch_free_buffers(struct usb_device *udev,
struct usbtouch_usb *usbtouch)
{
- usb_free_coherent(udev, usbtouch->type->rept_size,
+ usb_free_coherent(udev, usbtouch->data_size,
usbtouch->data, usbtouch->data_dma);
kfree(usbtouch->buffer);
}
@@ -1566,7 +1567,20 @@ static int usbtouch_probe(struct usb_int
if (!type->process_pkt)
type->process_pkt = usbtouch_process_pkt;
- usbtouch->data = usb_alloc_coherent(udev, type->rept_size,
+ usbtouch->data_size = type->rept_size;
+ if (type->get_pkt_len) {
+ /*
+ * When dealing with variable-length packets we should
+ * not request more than wMaxPacketSize bytes at once
+ * as we do not know if there is more data coming or
+ * we filled exactly wMaxPacketSize bytes and there is
+ * nothing else.
+ */
+ usbtouch->data_size = min(usbtouch->data_size,
+ usb_endpoint_maxp(endpoint));
+ }
+
+ usbtouch->data = usb_alloc_coherent(udev, usbtouch->data_size,
GFP_KERNEL, &usbtouch->data_dma);
if (!usbtouch->data)
goto out_free;
@@ -1626,12 +1640,12 @@ static int usbtouch_probe(struct usb_int
if (usb_endpoint_type(endpoint) == USB_ENDPOINT_XFER_INT)
usb_fill_int_urb(usbtouch->irq, udev,
usb_rcvintpipe(udev, endpoint->bEndpointAddress),
- usbtouch->data, type->rept_size,
+ usbtouch->data, usbtouch->data_size,
usbtouch_irq, usbtouch, endpoint->bInterval);
else
usb_fill_bulk_urb(usbtouch->irq, udev,
usb_rcvbulkpipe(udev, endpoint->bEndpointAddress),
- usbtouch->data, type->rept_size,
+ usbtouch->data, usbtouch->data_size,
usbtouch_irq, usbtouch);
usbtouch->irq->dev = udev;
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 039/118] media: af9035: fix broken I2C and USB I/O
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (36 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 038/118] Input: usbtouchscreen - separate report and transmit buffer size handling Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 040/118] powerpc: Fix PTE page address mismatch in pgtable ctor/dtor Greg Kroah-Hartman
` (78 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Antti Palosaari, Mauro Carvalho Chehab
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Antti Palosaari <crope@iki.fi>
commit 9323297dc0ea9141f8099e474657391bb3ad98f8 upstream.
There was three small buffer len calculation bugs which caused
driver non-working. These are coming from recent commit:
commit 7760e148350bf6df95662bc0db3734e9d991cb03
[media] af9035: Don't use dynamic static allocation
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/dvb-usb-v2/af9035.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -131,7 +131,7 @@ static int af9035_wr_regs(struct dvb_usb
{
u8 wbuf[MAX_XFER_SIZE];
u8 mbox = (reg >> 16) & 0xff;
- struct usb_req req = { CMD_MEM_WR, mbox, sizeof(wbuf), wbuf, 0, NULL };
+ struct usb_req req = { CMD_MEM_WR, mbox, 6 + len, wbuf, 0, NULL };
if (6 + len > sizeof(wbuf)) {
dev_warn(&d->udev->dev, "%s: i2c wr: len=%d is too big!\n",
@@ -238,7 +238,7 @@ static int af9035_i2c_master_xfer(struct
} else {
/* I2C */
u8 buf[MAX_XFER_SIZE];
- struct usb_req req = { CMD_I2C_RD, 0, sizeof(buf),
+ struct usb_req req = { CMD_I2C_RD, 0, 5 + msg[0].len,
buf, msg[1].len, msg[1].buf };
if (5 + msg[0].len > sizeof(buf)) {
@@ -274,8 +274,8 @@ static int af9035_i2c_master_xfer(struct
} else {
/* I2C */
u8 buf[MAX_XFER_SIZE];
- struct usb_req req = { CMD_I2C_WR, 0, sizeof(buf), buf,
- 0, NULL };
+ struct usb_req req = { CMD_I2C_WR, 0, 5 + msg[0].len,
+ buf, 0, NULL };
if (5 + msg[0].len > sizeof(buf)) {
dev_warn(&d->udev->dev,
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 040/118] powerpc: Fix PTE page address mismatch in pgtable ctor/dtor
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (37 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 039/118] media: af9035: fix broken I2C and USB I/O Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 041/118] drivers/rtc/rtc-at91rm9200.c: correct alarm over day/month wrap Greg Kroah-Hartman
` (77 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Paul Mackerras, Aneesh Kumar K.V,
Benjamin Herrenschmidt, Hong H. Pham
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Hong H. Pham" <hong.pham@windriver.com>
commit cf77ee54362a245f9a01f240adce03a06c05eb68 upstream.
In pte_alloc_one(), pgtable_page_ctor() is passed an address that has
not been converted by page_address() to the newly allocated PTE page.
When the PTE is freed, __pte_free_tlb() calls pgtable_page_dtor()
with an address to the PTE page that has been converted by page_address().
The mismatch in the PTE's page address causes pgtable_page_dtor() to access
invalid memory, so resources for that PTE (such as the page lock) is not
properly cleaned up.
On PPC32, only SMP kernels are affected.
On PPC64, only SMP kernels with 4K page size are affected.
This bug was introduced by commit d614bb041209fd7cb5e4b35e11a7b2f6ee8f62b8
"powerpc: Move the pte free routines from common header".
On a preempt-rt kernel, a spinlock is dynamically allocated for each
PTE in pgtable_page_ctor(). When the PTE is freed, calling
pgtable_page_dtor() with a mismatched page address causes a memory leak,
as the pointer to the PTE's spinlock is bogus.
On mainline, there isn't any immediately obvious symptoms, but the
problem still exists here.
Fixes: d614bb041209fd7c "powerpc: Move the pte free routes from common header"
Cc: Paul Mackerras <paulus@samba.org>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Hong H. Pham <hong.pham@windriver.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/include/asm/pgalloc-32.h | 6 ++----
arch/powerpc/include/asm/pgalloc-64.h | 6 ++----
2 files changed, 4 insertions(+), 8 deletions(-)
--- a/arch/powerpc/include/asm/pgalloc-32.h
+++ b/arch/powerpc/include/asm/pgalloc-32.h
@@ -84,10 +84,8 @@ static inline void pgtable_free_tlb(stru
static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t table,
unsigned long address)
{
- struct page *page = page_address(table);
-
tlb_flush_pgtable(tlb, address);
- pgtable_page_dtor(page);
- pgtable_free_tlb(tlb, page, 0);
+ pgtable_page_dtor(table);
+ pgtable_free_tlb(tlb, page_address(table), 0);
}
#endif /* _ASM_POWERPC_PGALLOC_32_H */
--- a/arch/powerpc/include/asm/pgalloc-64.h
+++ b/arch/powerpc/include/asm/pgalloc-64.h
@@ -144,11 +144,9 @@ static inline void pgtable_free_tlb(stru
static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t table,
unsigned long address)
{
- struct page *page = page_address(table);
-
tlb_flush_pgtable(tlb, address);
- pgtable_page_dtor(page);
- pgtable_free_tlb(tlb, page, 0);
+ pgtable_page_dtor(table);
+ pgtable_free_tlb(tlb, page_address(table), 0);
}
#else /* if CONFIG_PPC_64K_PAGES */
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 041/118] drivers/rtc/rtc-at91rm9200.c: correct alarm over day/month wrap
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (38 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 040/118] powerpc: Fix PTE page address mismatch in pgtable ctor/dtor Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 042/118] mm: memcg: do not declare OOM from __GFP_NOFAIL allocations Greg Kroah-Hartman
` (76 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Linus Pizunski, Nicolas Ferre,
Andrew Morton, Linus Torvalds
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Pizunski <linus@narrativeteam.com>
commit eb3c227289840eed95ddfb0516046f08d8993940 upstream.
Update month and day of month to the alarm month/day instead of current
day/month when setting the RTC alarm mask.
Signed-off-by: Linus Pizunski <linus@narrativeteam.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/rtc/rtc-at91rm9200.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/rtc/rtc-at91rm9200.c
+++ b/drivers/rtc/rtc-at91rm9200.c
@@ -220,6 +220,8 @@ static int at91_rtc_setalarm(struct devi
at91_alarm_year = tm.tm_year;
+ tm.tm_mon = alrm->time.tm_mon;
+ tm.tm_mday = alrm->time.tm_mday;
tm.tm_hour = alrm->time.tm_hour;
tm.tm_min = alrm->time.tm_min;
tm.tm_sec = alrm->time.tm_sec;
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 042/118] mm: memcg: do not declare OOM from __GFP_NOFAIL allocations
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (39 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 041/118] drivers/rtc/rtc-at91rm9200.c: correct alarm over day/month wrap Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 043/118] mm: memcg: do not allow task about to OOM kill to bypass the limit Greg Kroah-Hartman
` (75 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, William Dauchy, Johannes Weiner,
Michal Hocko, David Rientjes, Andrew Morton, Linus Torvalds
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Weiner <hannes@cmpxchg.org>
commit a0d8b00a3381f9d75764b3377590451cb0b4fe41 upstream.
Commit 84235de394d9 ("fs: buffer: move allocation failure loop into the
allocator") started recognizing __GFP_NOFAIL in memory cgroups but
forgot to disable the OOM killer.
Any task that does not fail allocation will also not enter the OOM
completion path. So don't declare an OOM state in this case or it'll be
leaked and the task be able to bypass the limit until the next
userspace-triggered page fault cleans up the OOM state.
Reported-by: William Dauchy <wdauchy@gmail.com>
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Michal Hocko <mhocko@suse.cz>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/memcontrol.c | 3 +++
1 file changed, 3 insertions(+)
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2677,6 +2677,9 @@ static int __mem_cgroup_try_charge(struc
if (unlikely(task_in_memcg_oom(current)))
goto bypass;
+ if (gfp_mask & __GFP_NOFAIL)
+ oom = false;
+
/*
* We always charge the cgroup the mm_struct belongs to.
* The mm_struct's mem_cgroup changes on task migration if the
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 043/118] mm: memcg: do not allow task about to OOM kill to bypass the limit
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (40 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 042/118] mm: memcg: do not declare OOM from __GFP_NOFAIL allocations Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 044/118] mm: memcg: fix race condition between memcg teardown and swapin Greg Kroah-Hartman
` (74 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Johannes Weiner, David Rientjes,
Michal Hocko, stable, Andrew Morton, Linus Torvalds
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Weiner <hannes@cmpxchg.org>
commit 1f14c1ac19aa45118054b6d5425873c5c7fc23a1 upstream.
Commit 4942642080ea ("mm: memcg: handle non-error OOM situations more
gracefully") allowed tasks that already entered a memcg OOM condition to
bypass the memcg limit on subsequent allocation attempts hoping this
would expedite finishing the page fault and executing the kill.
David Rientjes is worried that this breaks memcg isolation guarantees
and since there is no evidence that the bypass actually speeds up fault
processing just change it so that these subsequent charge attempts fail
outright. The notable exception being __GFP_NOFAIL charges which are
required to bypass the limit regardless.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Reported-by: David Rientjes <rientjes@google.com>
Acked-by: Michal Hocko <mhocko@suse.cz>
Acked-bt: David Rientjes <rientjes@google.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/memcontrol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2675,7 +2675,7 @@ static int __mem_cgroup_try_charge(struc
goto bypass;
if (unlikely(task_in_memcg_oom(current)))
- goto bypass;
+ goto nomem;
if (gfp_mask & __GFP_NOFAIL)
oom = false;
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 044/118] mm: memcg: fix race condition between memcg teardown and swapin
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (41 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 043/118] mm: memcg: do not allow task about to OOM kill to bypass the limit Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 045/118] regulator: pfuze100: Fix address of FABID Greg Kroah-Hartman
` (73 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Johannes Weiner, Michal Hocko,
David Rientjes, Andrew Morton, Linus Torvalds
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Weiner <hannes@cmpxchg.org>
commit 96f1c58d853497a757463e0b57fed140d6858f3a upstream.
There is a race condition between a memcg being torn down and a swapin
triggered from a different memcg of a page that was recorded to belong
to the exiting memcg on swapout (with CONFIG_MEMCG_SWAP extension). The
result is unreclaimable pages pointing to dead memcgs, which can lead to
anything from endless loops in later memcg teardown (the page is charged
to all hierarchical parents but is not on any LRU list) or crashes from
following the dangling memcg pointer.
Memcgs with tasks in them can not be torn down and usually charges don't
show up in memcgs without tasks. Swapin with the CONFIG_MEMCG_SWAP
extension is the notable exception because it charges the cgroup that
was recorded as owner during swapout, which may be empty and in the
process of being torn down when a task in another memcg triggers the
swapin:
teardown: swapin:
lookup_swap_cgroup_id()
rcu_read_lock()
mem_cgroup_lookup()
css_tryget()
rcu_read_unlock()
disable css_tryget()
call_rcu()
offline_css()
reparent_charges()
res_counter_charge() (hierarchical!)
css_put()
css_free()
pc->mem_cgroup = dead memcg
add page to dead lru
Add a final reparenting step into css_free() to make sure any such raced
charges are moved out of the memcg before it's finally freed.
In the longer term it would be cleaner to have the css_tryget() and the
res_counter charge under the same RCU lock section so that the charge
reparenting is deferred until the last charge whose tryget succeeded is
visible. But this will require more invasive changes that will be
harder to evaluate and backport into stable, so better defer them to a
separate change set.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Michal Hocko <mhocko@suse.cz>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/memcontrol.c | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -6341,6 +6341,42 @@ static void mem_cgroup_css_offline(struc
static void mem_cgroup_css_free(struct cgroup_subsys_state *css)
{
struct mem_cgroup *memcg = mem_cgroup_from_css(css);
+ /*
+ * XXX: css_offline() would be where we should reparent all
+ * memory to prepare the cgroup for destruction. However,
+ * memcg does not do css_tryget() and res_counter charging
+ * under the same RCU lock region, which means that charging
+ * could race with offlining. Offlining only happens to
+ * cgroups with no tasks in them but charges can show up
+ * without any tasks from the swapin path when the target
+ * memcg is looked up from the swapout record and not from the
+ * current task as it usually is. A race like this can leak
+ * charges and put pages with stale cgroup pointers into
+ * circulation:
+ *
+ * #0 #1
+ * lookup_swap_cgroup_id()
+ * rcu_read_lock()
+ * mem_cgroup_lookup()
+ * css_tryget()
+ * rcu_read_unlock()
+ * disable css_tryget()
+ * call_rcu()
+ * offline_css()
+ * reparent_charges()
+ * res_counter_charge()
+ * css_put()
+ * css_free()
+ * pc->mem_cgroup = dead memcg
+ * add page to lru
+ *
+ * The bulk of the charges are still moved in offline_css() to
+ * avoid pinning a lot of pages in case a long-term reference
+ * like a swapout record is deferring the css_free() to long
+ * after offlining. But this makes sure we catch any charges
+ * made after offlining:
+ */
+ mem_cgroup_reparent_charges(memcg);
memcg_destroy_kmem(memcg);
__mem_cgroup_free(memcg);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 045/118] regulator: pfuze100: Fix address of FABID
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (42 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 044/118] mm: memcg: fix race condition between memcg teardown and swapin Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 046/118] Partially revert "mtd: nand: pxa3xx: Introduce marvell,armada370-nand compatible string" Greg Kroah-Hartman
` (72 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Axel Lin, Robin Gong, Mark Brown
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Axel Lin <axel.lin@ingics.com>
commit a1b6fa85c639ad0d5447d1a5e7d1463bbe29fcd3 upstream.
According to the datasheet, the address of FABID is 0x4. Fix it.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Robin Gong <b38343@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/regulator/pfuze100-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/regulator/pfuze100-regulator.c
+++ b/drivers/regulator/pfuze100-regulator.c
@@ -38,7 +38,7 @@
#define PFUZE100_DEVICEID 0x0
#define PFUZE100_REVID 0x3
-#define PFUZE100_FABID 0x3
+#define PFUZE100_FABID 0x4
#define PFUZE100_SW1ABVOL 0x20
#define PFUZE100_SW1CVOL 0x2e
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 046/118] Partially revert "mtd: nand: pxa3xx: Introduce marvell,armada370-nand compatible string"
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (43 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 045/118] regulator: pfuze100: Fix address of FABID Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 047/118] iommu/arm-smmu: use mutex instead of spinlock for locking page tables Greg Kroah-Hartman
` (71 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ezequiel Garcia, Jason Cooper, Brian Norris
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
commit 9c59ac616137fb62f6cb3f1219201b09cbcf30be upstream.
This partially reverts c0f3b8643a6fa2461d70760ec49d21d2b031d611.
The "armada370-nand" compatible support is not complete, and it was mistake
to add it. Revert it and postpone the support until the infrastructure is
in place.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mtd/nand/pxa3xx_nand.c | 4 ----
1 file changed, 4 deletions(-)
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -1241,10 +1241,6 @@ static struct of_device_id pxa3xx_nand_d
.compatible = "marvell,pxa3xx-nand",
.data = (void *)PXA3XX_NAND_VARIANT_PXA,
},
- {
- .compatible = "marvell,armada370-nand",
- .data = (void *)PXA3XX_NAND_VARIANT_ARMADA370,
- },
{}
};
MODULE_DEVICE_TABLE(of, pxa3xx_nand_dt_ids);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 047/118] iommu/arm-smmu: use mutex instead of spinlock for locking page tables
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (44 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 046/118] Partially revert "mtd: nand: pxa3xx: Introduce marvell,armada370-nand compatible string" Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 049/118] ath9k: Fix QuickDrop usage Greg Kroah-Hartman
` (70 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Will Deacon
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Will Deacon <will.deacon@arm.com>
commit a44a9791e778d9ccda50d5534028ed4057a9a45b upstream.
When creating IO mappings, we lazily allocate our page tables using the
standard, non-atomic allocator functions. This presents us with a
problem, since our page tables are protected with a spinlock.
This patch reworks the smmu_domain lock to use a mutex instead of a
spinlock. iova_to_phys is then reworked so that it only reads the page
tables, and can run in a lockless fashion, leaving the mutex to guard
against concurrent mapping threads.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iommu/arm-smmu.c | 62 +++++++++++++++++++----------------------------
1 file changed, 26 insertions(+), 36 deletions(-)
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -392,7 +392,7 @@ struct arm_smmu_domain {
struct arm_smmu_cfg root_cfg;
phys_addr_t output_mask;
- spinlock_t lock;
+ struct mutex lock;
};
static DEFINE_SPINLOCK(arm_smmu_devices_lock);
@@ -897,7 +897,7 @@ static int arm_smmu_domain_init(struct i
goto out_free_domain;
smmu_domain->root_cfg.pgd = pgd;
- spin_lock_init(&smmu_domain->lock);
+ mutex_init(&smmu_domain->lock);
domain->priv = smmu_domain;
return 0;
@@ -1134,7 +1134,7 @@ static int arm_smmu_attach_dev(struct io
* Sanity check the domain. We don't currently support domains
* that cross between different SMMU chains.
*/
- spin_lock(&smmu_domain->lock);
+ mutex_lock(&smmu_domain->lock);
if (!smmu_domain->leaf_smmu) {
/* Now that we have a master, we can finalise the domain */
ret = arm_smmu_init_domain_context(domain, dev);
@@ -1149,7 +1149,7 @@ static int arm_smmu_attach_dev(struct io
dev_name(device_smmu->dev));
goto err_unlock;
}
- spin_unlock(&smmu_domain->lock);
+ mutex_unlock(&smmu_domain->lock);
/* Looks ok, so add the device to the domain */
master = find_smmu_master(smmu_domain->leaf_smmu, dev->of_node);
@@ -1159,7 +1159,7 @@ static int arm_smmu_attach_dev(struct io
return arm_smmu_domain_add_master(smmu_domain, master);
err_unlock:
- spin_unlock(&smmu_domain->lock);
+ mutex_unlock(&smmu_domain->lock);
return ret;
}
@@ -1388,7 +1388,7 @@ static int arm_smmu_handle_mapping(struc
if (paddr & ~output_mask)
return -ERANGE;
- spin_lock(&smmu_domain->lock);
+ mutex_lock(&smmu_domain->lock);
pgd += pgd_index(iova);
end = iova + size;
do {
@@ -1404,7 +1404,7 @@ static int arm_smmu_handle_mapping(struc
} while (pgd++, iova != end);
out_unlock:
- spin_unlock(&smmu_domain->lock);
+ mutex_unlock(&smmu_domain->lock);
/* Ensure new page tables are visible to the hardware walker */
if (smmu->features & ARM_SMMU_FEAT_COHERENT_WALK)
@@ -1443,44 +1443,34 @@ static size_t arm_smmu_unmap(struct iomm
static phys_addr_t arm_smmu_iova_to_phys(struct iommu_domain *domain,
dma_addr_t iova)
{
- pgd_t *pgd;
- pud_t *pud;
- pmd_t *pmd;
- pte_t *pte;
+ pgd_t *pgdp, pgd;
+ pud_t pud;
+ pmd_t pmd;
+ pte_t pte;
struct arm_smmu_domain *smmu_domain = domain->priv;
struct arm_smmu_cfg *root_cfg = &smmu_domain->root_cfg;
- struct arm_smmu_device *smmu = root_cfg->smmu;
- spin_lock(&smmu_domain->lock);
- pgd = root_cfg->pgd;
- if (!pgd)
- goto err_unlock;
+ pgdp = root_cfg->pgd;
+ if (!pgdp)
+ return 0;
- pgd += pgd_index(iova);
- if (pgd_none_or_clear_bad(pgd))
- goto err_unlock;
+ pgd = *(pgdp + pgd_index(iova));
+ if (pgd_none(pgd))
+ return 0;
- pud = pud_offset(pgd, iova);
- if (pud_none_or_clear_bad(pud))
- goto err_unlock;
+ pud = *pud_offset(&pgd, iova);
+ if (pud_none(pud))
+ return 0;
- pmd = pmd_offset(pud, iova);
- if (pmd_none_or_clear_bad(pmd))
- goto err_unlock;
+ pmd = *pmd_offset(&pud, iova);
+ if (pmd_none(pmd))
+ return 0;
- pte = pmd_page_vaddr(*pmd) + pte_index(iova);
+ pte = *(pmd_page_vaddr(pmd) + pte_index(iova));
if (pte_none(pte))
- goto err_unlock;
-
- spin_unlock(&smmu_domain->lock);
- return __pfn_to_phys(pte_pfn(*pte)) | (iova & ~PAGE_MASK);
+ return 0;
-err_unlock:
- spin_unlock(&smmu_domain->lock);
- dev_warn(smmu->dev,
- "invalid (corrupt?) page tables detected for iova 0x%llx\n",
- (unsigned long long)iova);
- return -EINVAL;
+ return __pfn_to_phys(pte_pfn(pte)) | (iova & ~PAGE_MASK);
}
static int arm_smmu_domain_has_cap(struct iommu_domain *domain,
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 049/118] ath9k: Fix QuickDrop usage
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (45 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 047/118] iommu/arm-smmu: use mutex instead of spinlock for locking page tables Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 050/118] ath9k: Fix XLNA bias strength Greg Kroah-Hartman
` (69 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sujith Manoharan, John W. Linville
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
commit 93c1cfbe598f72cfa7be49e4a7d2a1d482e15119 upstream.
Bit 5 in the miscConfiguration field of the base EEPROM
header denotes whether QuickDrop is enabled or not. Fix
the incorrect usage of BIT(1) and also make sure that
this is done only for the required chips.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -3966,18 +3966,20 @@ static void ar9003_hw_quick_drop_apply(s
int quick_drop;
s32 t[3], f[3] = {5180, 5500, 5785};
- if (!(pBase->miscConfiguration & BIT(1)))
+ if (!(pBase->miscConfiguration & BIT(4)))
return;
- if (freq < 4000)
- quick_drop = eep->modalHeader2G.quick_drop;
- else {
- t[0] = eep->base_ext1.quick_drop_low;
- t[1] = eep->modalHeader5G.quick_drop;
- t[2] = eep->base_ext1.quick_drop_high;
- quick_drop = ar9003_hw_power_interpolate(freq, f, t, 3);
+ if (AR_SREV_9300(ah) || AR_SREV_9580(ah) || AR_SREV_9340(ah)) {
+ if (freq < 4000) {
+ quick_drop = eep->modalHeader2G.quick_drop;
+ } else {
+ t[0] = eep->base_ext1.quick_drop_low;
+ t[1] = eep->modalHeader5G.quick_drop;
+ t[2] = eep->base_ext1.quick_drop_high;
+ quick_drop = ar9003_hw_power_interpolate(freq, f, t, 3);
+ }
+ REG_RMW_FIELD(ah, AR_PHY_AGC, AR_PHY_AGC_QUICK_DROP, quick_drop);
}
- REG_RMW_FIELD(ah, AR_PHY_AGC, AR_PHY_AGC_QUICK_DROP, quick_drop);
}
static void ar9003_hw_txend_to_xpa_off_apply(struct ath_hw *ah, bool is2ghz)
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 050/118] ath9k: Fix XLNA bias strength
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (46 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 049/118] ath9k: Fix QuickDrop usage Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 051/118] ath9k: fix duration calculation for non-aggregated packets Greg Kroah-Hartman
` (68 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sujith Manoharan, John W. Linville
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
commit a1783a7b0846fc6414483e6caf646db72023fffd upstream.
The EEPROM parameter to determine whether the bias
strength values for XLNA have to be applied is part
of the miscConfiguration field and not featureEnable.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -4019,7 +4019,7 @@ static void ar9003_hw_xlna_bias_strength
struct ar9300_eeprom *eep = &ah->eeprom.ar9300_eep;
u8 bias;
- if (!(eep->baseEepHeader.featureEnable & 0x40))
+ if (!(eep->baseEepHeader.miscConfiguration & 0x40))
return;
if (!AR_SREV_9300(ah))
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 051/118] ath9k: fix duration calculation for non-aggregated packets
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (47 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 050/118] ath9k: Fix XLNA bias strength Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 052/118] cfg80211: disable 5/10 MHz support for all drivers Greg Kroah-Hartman
` (67 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Simon Wunderlich, Felix Fietkau,
John W. Linville
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <nbd@openwrt.org>
commit bbf807bc0697e577c137a5fffb30fca7c6a45da1 upstream.
When not aggregating packets, fi->framelen should be passed in as length
to calculate the duration. Before the tx path rework, ath_tx_fill_desc
was called for either one aggregate, or one single frame, with the
length of the packet or the aggregate as a parameter.
After the rework, ath_tx_sched_aggr can pass a burst of single frames to
ath_tx_fill_desc and sets len=0.
Fix broken duration calculation by overriding the length in ath_tx_fill_desc
before passing it to ath_buf_set_rate.
Reported-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/ath/ath9k/xmit.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1275,6 +1275,10 @@ static void ath_tx_fill_desc(struct ath_
if (!rts_thresh || (len > rts_thresh))
rts = true;
}
+
+ if (!aggr)
+ len = fi->framelen;
+
ath_buf_set_rate(sc, bf, &info, len, rts);
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 052/118] cfg80211: disable 5/10 MHz support for all drivers
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (48 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 051/118] ath9k: fix duration calculation for non-aggregated packets Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 053/118] selinux: handle TCP SYN-ACK packets correctly in selinux_ip_output() Greg Kroah-Hartman
` (66 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Johannes Berg
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Berg <johannes.berg@intel.com>
commit 9f16d84ad73ea04145a5dc85c8f1067915b37eea upstream.
Due to nl80211 API breakage, 5/10 MHz support is broken for
all drivers. Fixing it requires adding new API, but that
can't be done as a bugfix commit since that would require
either updating all APIs in the trees needing the bugfix or
cause different kernels to have incompatible API.
Therefore, just disable 5/10 MHz support for all drivers.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/wireless/core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -451,6 +451,9 @@ int wiphy_register(struct wiphy *wiphy)
int i;
u16 ifmodes = wiphy->interface_modes;
+ /* support for 5/10 MHz is broken due to nl80211 API mess - disable */
+ wiphy->flags &= ~WIPHY_FLAG_SUPPORTS_5_10_MHZ;
+
#ifdef CONFIG_PM
if (WARN_ON(wiphy->wowlan &&
(wiphy->wowlan->flags & WIPHY_WOWLAN_GTK_REKEY_FAILURE) &&
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 053/118] selinux: handle TCP SYN-ACK packets correctly in selinux_ip_output()
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (49 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 052/118] cfg80211: disable 5/10 MHz support for all drivers Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 054/118] selinux: handle TCP SYN-ACK packets correctly in selinux_ip_postroute() Greg Kroah-Hartman
` (65 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Janak Desai, Paul Moore
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Moore <pmoore@redhat.com>
commit 47180068276a04ed31d24fe04c673138208b07a9 upstream.
In selinux_ip_output() we always label packets based on the parent
socket. While this approach works in almost all cases, it doesn't
work in the case of TCP SYN-ACK packets when the correct label is not
the label of the parent socket, but rather the label of the larval
socket represented by the request_sock struct.
Unfortunately, since the request_sock isn't queued on the parent
socket until *after* the SYN-ACK packet is sent, we can't lookup the
request_sock to determine the correct label for the packet; at this
point in time the best we can do is simply pass/NF_ACCEPT the packet.
It must be said that simply passing the packet without any explicit
labeling action, while far from ideal, is not terrible as the SYN-ACK
packet will inherit any IP option based labeling from the initial
connection request so the label *should* be correct and all our
access controls remain in place so we shouldn't have to worry about
information leaks.
Reported-by: Janak Desai <Janak.Desai@gtri.gatech.edu>
Tested-by: Janak Desai <Janak.Desai@gtri.gatech.edu>
Signed-off-by: Paul Moore <pmoore@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
security/selinux/hooks.c | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -53,6 +53,7 @@
#include <net/ip.h> /* for local_port_range[] */
#include <net/sock.h>
#include <net/tcp.h> /* struct or_callable used in sock_rcv_skb */
+#include <net/inet_connection_sock.h>
#include <net/net_namespace.h>
#include <net/netlabel.h>
#include <linux/uaccess.h>
@@ -4690,6 +4691,7 @@ static unsigned int selinux_ipv6_forward
static unsigned int selinux_ip_output(struct sk_buff *skb,
u16 family)
{
+ struct sock *sk;
u32 sid;
if (!netlbl_enabled())
@@ -4698,8 +4700,27 @@ static unsigned int selinux_ip_output(st
/* we do this in the LOCAL_OUT path and not the POST_ROUTING path
* because we want to make sure we apply the necessary labeling
* before IPsec is applied so we can leverage AH protection */
- if (skb->sk) {
- struct sk_security_struct *sksec = skb->sk->sk_security;
+ sk = skb->sk;
+ if (sk) {
+ struct sk_security_struct *sksec;
+
+ if (sk->sk_state == TCP_LISTEN)
+ /* if the socket is the listening state then this
+ * packet is a SYN-ACK packet which means it needs to
+ * be labeled based on the connection/request_sock and
+ * not the parent socket. unfortunately, we can't
+ * lookup the request_sock yet as it isn't queued on
+ * the parent socket until after the SYN-ACK is sent.
+ * the "solution" is to simply pass the packet as-is
+ * as any IP option based labeling should be copied
+ * from the initial connection request (in the IP
+ * layer). it is far from ideal, but until we get a
+ * security label in the packet itself this is the
+ * best we can do. */
+ return NF_ACCEPT;
+
+ /* standard practice, label using the parent socket */
+ sksec = sk->sk_security;
sid = sksec->sid;
} else
sid = SECINITSID_KERNEL;
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 054/118] selinux: handle TCP SYN-ACK packets correctly in selinux_ip_postroute()
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (50 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 053/118] selinux: handle TCP SYN-ACK packets correctly in selinux_ip_output() Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 055/118] Revert "mac80211: allow disable power save in mesh" Greg Kroah-Hartman
` (64 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Janak Desai, Paul Moore
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Moore <pmoore@redhat.com>
commit 446b802437f285de68ffb8d6fac3c44c3cab5b04 upstream.
In selinux_ip_postroute() we perform access checks based on the
packet's security label. For locally generated traffic we get the
packet's security label from the associated socket; this works in all
cases except for TCP SYN-ACK packets. In the case of SYN-ACK packet's
the correct security label is stored in the connection's request_sock,
not the server's socket. Unfortunately, at the point in time when
selinux_ip_postroute() is called we can't query the request_sock
directly, we need to recreate the label using the same logic that
originally labeled the associated request_sock.
See the inline comments for more explanation.
Reported-by: Janak Desai <Janak.Desai@gtri.gatech.edu>
Tested-by: Janak Desai <Janak.Desai@gtri.gatech.edu>
Signed-off-by: Paul Moore <pmoore@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
security/selinux/hooks.c | 68 ++++++++++++++++++++++++++++++++++++-----------
1 file changed, 53 insertions(+), 15 deletions(-)
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -3806,6 +3806,30 @@ static int selinux_skb_peerlbl_sid(struc
return 0;
}
+/**
+ * selinux_conn_sid - Determine the child socket label for a connection
+ * @sk_sid: the parent socket's SID
+ * @skb_sid: the packet's SID
+ * @conn_sid: the resulting connection SID
+ *
+ * If @skb_sid is valid then the user:role:type information from @sk_sid is
+ * combined with the MLS information from @skb_sid in order to create
+ * @conn_sid. If @skb_sid is not valid then then @conn_sid is simply a copy
+ * of @sk_sid. Returns zero on success, negative values on failure.
+ *
+ */
+static int selinux_conn_sid(u32 sk_sid, u32 skb_sid, u32 *conn_sid)
+{
+ int err = 0;
+
+ if (skb_sid != SECSID_NULL)
+ err = security_sid_mls_copy(sk_sid, skb_sid, conn_sid);
+ else
+ *conn_sid = sk_sid;
+
+ return err;
+}
+
/* socket security operations */
static int socket_sockcreate_sid(const struct task_security_struct *tsec,
@@ -4412,7 +4436,7 @@ static int selinux_inet_conn_request(str
struct sk_security_struct *sksec = sk->sk_security;
int err;
u16 family = sk->sk_family;
- u32 newsid;
+ u32 connsid;
u32 peersid;
/* handle mapped IPv4 packets arriving via IPv6 sockets */
@@ -4422,16 +4446,11 @@ static int selinux_inet_conn_request(str
err = selinux_skb_peerlbl_sid(skb, family, &peersid);
if (err)
return err;
- if (peersid == SECSID_NULL) {
- req->secid = sksec->sid;
- req->peer_secid = SECSID_NULL;
- } else {
- err = security_sid_mls_copy(sksec->sid, peersid, &newsid);
- if (err)
- return err;
- req->secid = newsid;
- req->peer_secid = peersid;
- }
+ err = selinux_conn_sid(sksec->sid, peersid, &connsid);
+ if (err)
+ return err;
+ req->secid = connsid;
+ req->peer_secid = peersid;
return selinux_netlbl_inet_conn_request(req, family);
}
@@ -4805,12 +4824,12 @@ static unsigned int selinux_ip_postroute
if (!secmark_active && !peerlbl_active)
return NF_ACCEPT;
- /* if the packet is being forwarded then get the peer label from the
- * packet itself; otherwise check to see if it is from a local
- * application or the kernel, if from an application get the peer label
- * from the sending socket, otherwise use the kernel's sid */
sk = skb->sk;
if (sk == NULL) {
+ /* Without an associated socket the packet is either coming
+ * from the kernel or it is being forwarded; check the packet
+ * to determine which and if the packet is being forwarded
+ * query the packet directly to determine the security label. */
if (skb->skb_iif) {
secmark_perm = PACKET__FORWARD_OUT;
if (selinux_skb_peerlbl_sid(skb, family, &peer_sid))
@@ -4819,7 +4838,26 @@ static unsigned int selinux_ip_postroute
secmark_perm = PACKET__SEND;
peer_sid = SECINITSID_KERNEL;
}
+ } else if (sk->sk_state == TCP_LISTEN) {
+ /* Locally generated packet but the associated socket is in the
+ * listening state which means this is a SYN-ACK packet. In
+ * this particular case the correct security label is assigned
+ * to the connection/request_sock but unfortunately we can't
+ * query the request_sock as it isn't queued on the parent
+ * socket until after the SYN-ACK packet is sent; the only
+ * viable choice is to regenerate the label like we do in
+ * selinux_inet_conn_request(). See also selinux_ip_output()
+ * for similar problems. */
+ u32 skb_sid;
+ struct sk_security_struct *sksec = sk->sk_security;
+ if (selinux_skb_peerlbl_sid(skb, family, &skb_sid))
+ return NF_DROP;
+ if (selinux_conn_sid(sksec->sid, skb_sid, &peer_sid))
+ return NF_DROP;
+ secmark_perm = PACKET__SEND;
} else {
+ /* Locally generated packet, fetch the security label from the
+ * associated socket. */
struct sk_security_struct *sksec = sk->sk_security;
peer_sid = sksec->sid;
secmark_perm = PACKET__SEND;
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 055/118] Revert "mac80211: allow disable power save in mesh"
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (51 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 054/118] selinux: handle TCP SYN-ACK packets correctly in selinux_ip_postroute() Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 056/118] mac80211: fix scheduled scan rtnl deadlock Greg Kroah-Hartman
` (63 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Bob Copeland, Johannes Berg
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bob Copeland <me@bobcopeland.com>
commit 2d3db210860f1df099a35b1dd54cca35454e0361 upstream.
This reverts commit ee1f668136b2fb6640ee2d54c2a525ea41f98211.
The aformentioned commit added a check to allow
'iw wlan0 set power_save off' to work for mesh interfaces.
However, this is problematic because it also allows
'iw wlan0 set power_save on', which will crash in short order
because all of the subsequent code manipulates sdata->u.mgd.
The power-saving states for mesh interfaces can be manipulated
through the mesh config, e.g:
'iw wlan0 set mesh_param mesh_power_save=active' (which,
despite the name, actualy disables power saving since the
setting refers to the type of sleep the interface undergoes).
Fixes: ee1f668136b2 ("mac80211: allow disable power save in mesh")
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/mac80211/cfg.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2386,8 +2386,7 @@ static int ieee80211_set_power_mgmt(stru
struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr);
- if (sdata->vif.type != NL80211_IFTYPE_STATION &&
- sdata->vif.type != NL80211_IFTYPE_MESH_POINT)
+ if (sdata->vif.type != NL80211_IFTYPE_STATION)
return -EOPNOTSUPP;
if (!(local->hw.flags & IEEE80211_HW_SUPPORTS_PS))
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 056/118] mac80211: fix scheduled scan rtnl deadlock
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (52 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 055/118] Revert "mac80211: allow disable power save in mesh" Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 057/118] mac80211: dont attempt to reorder multicast frames Greg Kroah-Hartman
` (62 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Johannes Berg
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Berg <johannes.berg@intel.com>
commit 18db594a1005d908d995a2fc8f5a7bf4286fdca0 upstream.
When changing cfg80211 to use RTNL locking, this caused a
deadlock in mac80211 as it calls cfg80211_sched_scan_stopped()
from a work item that's on a workqueue that is flushed with
the RTNL held.
Fix this by simply using schedule_work(), the work only needs
to finish running before the wiphy is unregistered, no other
synchronisation (e.g. with suspend) is really required since
for suspend userspace is already blocked anyway when we flush
the workqueue so will only pick up the event after resume.
Fixes: 5fe231e87372 ("cfg80211: vastly simplify locking")
Reported-and-tested-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/mac80211/main.c | 1 +
net/mac80211/scan.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -1047,6 +1047,7 @@ void ieee80211_unregister_hw(struct ieee
cancel_work_sync(&local->restart_work);
cancel_work_sync(&local->reconfig_filter);
+ flush_work(&local->sched_scan_stopped_work);
ieee80211_clear_tx_pending(local);
rate_control_deinitialize(local);
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -1089,6 +1089,6 @@ void ieee80211_sched_scan_stopped(struct
trace_api_sched_scan_stopped(local);
- ieee80211_queue_work(&local->hw, &local->sched_scan_stopped_work);
+ schedule_work(&local->sched_scan_stopped_work);
}
EXPORT_SYMBOL(ieee80211_sched_scan_stopped);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 057/118] mac80211: dont attempt to reorder multicast frames
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (53 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 056/118] mac80211: fix scheduled scan rtnl deadlock Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 058/118] iwlwifi: mvm: check sta_id/drain values in debugfs Greg Kroah-Hartman
` (61 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Blaise Gassend, Johannes Berg
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Berg <johannes.berg@intel.com>
commit 051a41fa4ee14f5c39668f0980973b9a195de560 upstream.
Multicast frames can't be transmitted as part of an aggregation
session (such a session couldn't even be set up) so don't try to
reorder them. Trying to do so would cause the reorder to stop
working correctly since multicast QoS frames (as transmitted by
the Aruba APs this was found with) would cause sequence number
confusion in the buffer.
Reported-by: Blaise Gassend <blaise@suitabletech.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/mac80211/rx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -911,7 +911,8 @@ static void ieee80211_rx_reorder_ampdu(s
u16 sc;
u8 tid, ack_policy;
- if (!ieee80211_is_data_qos(hdr->frame_control))
+ if (!ieee80211_is_data_qos(hdr->frame_control) ||
+ is_multicast_ether_addr(hdr->addr1))
goto dont_reorder;
/*
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 058/118] iwlwifi: mvm: check sta_id/drain values in debugfs
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (54 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 057/118] mac80211: dont attempt to reorder multicast frames Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 059/118] mwifiex: fix memory leak issue for ibss join Greg Kroah-Hartman
` (60 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Johannes Berg, Emmanuel Grumbach
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Berg <johannes.berg@intel.com>
commit 60765a47a433d54e4744c285ad127f182dcd80aa upstream.
The station ID must be valid, if it's out of range then
the array access may crash. Validate the station ID to
the array length, and also validate the drain value even
if that doesn't matter all that much.
Fixes: 8ca151b568b6 ("iwlwifi: add the MVM driver")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/iwlwifi/mvm/debugfs.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/net/wireless/iwlwifi/mvm/debugfs.c
+++ b/drivers/net/wireless/iwlwifi/mvm/debugfs.c
@@ -119,6 +119,10 @@ static ssize_t iwl_dbgfs_sta_drain_write
if (sscanf(buf, "%d %d", &sta_id, &drain) != 2)
return -EINVAL;
+ if (sta_id < 0 || sta_id >= IWL_MVM_STATION_COUNT)
+ return -EINVAL;
+ if (drain < 0 || drain > 1)
+ return -EINVAL;
mutex_lock(&mvm->mutex);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 059/118] mwifiex: fix memory leak issue for ibss join
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (55 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 058/118] iwlwifi: mvm: check sta_id/drain values in debugfs Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 060/118] net: allwinner: emac: Add missing free_irq Greg Kroah-Hartman
` (59 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ujjal Roy, Bing Zhao, John W. Linville
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ujjal Roy <royujjal@gmail.com>
commit 517543fd72d577dde2ebd9505dc4abf26d589f9a upstream.
For IBSS join if the requested SSID matches current SSID,
it returns without freeing the allocated beacon IE buffer.
Signed-off-by: Ujjal Roy <royujjal@gmail.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/mwifiex/sta_ioctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/wireless/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/mwifiex/sta_ioctl.c
@@ -319,8 +319,8 @@ int mwifiex_bss_start(struct mwifiex_pri
if (bss_desc && bss_desc->ssid.ssid_len &&
(!mwifiex_ssid_cmp(&priv->curr_bss_params.bss_descriptor.
ssid, &bss_desc->ssid))) {
- kfree(bss_desc);
- return 0;
+ ret = 0;
+ goto done;
}
/* Exit Adhoc mode first */
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 060/118] net: allwinner: emac: Add missing free_irq
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (56 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 059/118] mwifiex: fix memory leak issue for ibss join Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 061/118] igb: Fix for issue where values could be too high for udelay function Greg Kroah-Hartman
` (58 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Maxime Ripard, David S. Miller
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maxime Ripard <maxime.ripard@free-electrons.com>
commit e9c56f8d2f851fb6d6ce6794c0f5463b862a878e upstream.
The sun4i-emac driver uses devm_request_irq at .ndo_open time, but relies on
the managed device mechanism to actually free it. This causes an issue whenever
someone wants to restart the interface, the interrupt still being held, and not
yet released.
Fall back to using the regular request_irq at .ndo_open time, and introduce a
free_irq during .ndo_stop.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/allwinner/sun4i-emac.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/allwinner/sun4i-emac.c
+++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
@@ -717,8 +717,7 @@ static int emac_open(struct net_device *
if (netif_msg_ifup(db))
dev_dbg(db->dev, "enabling %s\n", dev->name);
- if (devm_request_irq(db->dev, dev->irq, &emac_interrupt,
- 0, dev->name, dev))
+ if (request_irq(dev->irq, &emac_interrupt, 0, dev->name, dev))
return -EAGAIN;
/* Initialize EMAC board */
@@ -774,6 +773,8 @@ static int emac_stop(struct net_device *
emac_shutdown(ndev);
+ free_irq(ndev->irq, ndev);
+
return 0;
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 061/118] igb: Fix for issue where values could be too high for udelay function.
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (57 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 060/118] net: allwinner: emac: Add missing free_irq Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 062/118] drm/i915: use the correct force_wake function at the PC8 code Greg Kroah-Hartman
` (57 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sunil K Pandey, Kevin B Smith,
Carolyn Wyborny, Aaron Brown, Jeff Kirsher, David S. Miller
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Carolyn Wyborny <carolyn.wyborny@intel.com>
commit df29df92adda751ac04ca5149d30014b5199db81 upstream.
This patch changes the igb_phy_has_link function to check the value of the
parameter before deciding to use udelay or mdelay in order to be sure that
the value is not too high for udelay function.
Signed-off-by: Sunil K Pandey <sunil.k.pandey@intel.com>
Signed-off-by: Kevin B Smith <kevin.b.smith@intel.com>
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/intel/igb/e1000_phy.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/intel/igb/e1000_phy.c
+++ b/drivers/net/ethernet/intel/igb/e1000_phy.c
@@ -1730,7 +1730,10 @@ s32 igb_phy_has_link(struct e1000_hw *hw
* ownership of the resources, wait and try again to
* see if they have relinquished the resources yet.
*/
- udelay(usec_interval);
+ if (usec_interval >= 1000)
+ mdelay(usec_interval/1000);
+ else
+ udelay(usec_interval);
}
ret_val = hw->phy.ops.read_reg(hw, PHY_STATUS, &phy_status);
if (ret_val)
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 062/118] drm/i915: use the correct force_wake function at the PC8 code
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (58 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 061/118] igb: Fix for issue where values could be too high for udelay function Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 063/118] drm/radeon: fix typo in fetching mpll params Greg Kroah-Hartman
` (56 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Paulo Zanoni, Rodrigo Vivi, Daniel Vetter
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paulo Zanoni <paulo.r.zanoni@intel.com>
commit a1216444283e81fd904593a4a77c90adfe5d14d1 upstream.
When I submitted the first patch adding these force wake functions,
Chris Wilson observed that I was using the wrong functions, so I sent
a second version of the patch to correct this problem. The problem is
that v1 was merged instead of v2.
I was able to notice the problem when running the
debugfs-forcewake-user subtest of pm_pc8 from intel-gpu-tools.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6062,7 +6062,7 @@ void hsw_restore_lcpll(struct drm_i915_p
/* Make sure we're not on PC8 state before disabling PC8, otherwise
* we'll hang the machine! */
- dev_priv->uncore.funcs.force_wake_get(dev_priv);
+ gen6_gt_force_wake_get(dev_priv);
if (val & LCPLL_POWER_DOWN_ALLOW) {
val &= ~LCPLL_POWER_DOWN_ALLOW;
@@ -6093,7 +6093,7 @@ void hsw_restore_lcpll(struct drm_i915_p
DRM_ERROR("Switching back to LCPLL failed\n");
}
- dev_priv->uncore.funcs.force_wake_put(dev_priv);
+ gen6_gt_force_wake_put(dev_priv);
}
void hsw_enable_pc8_work(struct work_struct *__work)
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 063/118] drm/radeon: fix typo in fetching mpll params
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (59 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 062/118] drm/i915: use the correct force_wake function at the PC8 code Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 064/118] drm/radeon: program DCE2 audio dto just like DCE3 Greg Kroah-Hartman
` (55 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Alex Deucher
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
commit 180f805f4f03b2894701f9831b4e96a308330b22 upstream.
Copy-paste typo. Value should be 0-2, not 0-1.
Noticed-by: Sylvain BERTRAND <sylware@legeek.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/radeon_atombios.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -2918,7 +2918,7 @@ int radeon_atom_get_memory_pll_dividers(
mpll_param->dll_speed = args.ucDllSpeed;
mpll_param->bwcntl = args.ucBWCntl;
mpll_param->vco_mode =
- (args.ucPllCntlFlag & MPLL_CNTL_FLAG_VCO_MODE_MASK) ? 1 : 0;
+ (args.ucPllCntlFlag & MPLL_CNTL_FLAG_VCO_MODE_MASK);
mpll_param->yclk_sel =
(args.ucPllCntlFlag & MPLL_CNTL_FLAG_BYPASS_DQ_PLL) ? 1 : 0;
mpll_param->qdr =
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 064/118] drm/radeon: program DCE2 audio dto just like DCE3
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (60 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 063/118] drm/radeon: fix typo in fetching mpll params Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 065/118] drm/radeon: fixup bad vram size on SI Greg Kroah-Hartman
` (54 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Alex Deucher
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
commit 55d4e020fb8ddd3896a8cd3351028f5c3a2c4bd3 upstream.
Seems to work like the DCE3 version despite what
the register spec says.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=71975
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/r600_hdmi.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -304,9 +304,9 @@ void r600_audio_set_dto(struct drm_encod
WREG32(DCCG_AUDIO_DTO1_MODULE, dto_modulo);
WREG32(DCCG_AUDIO_DTO_SELECT, 1); /* select DTO1 */
}
- } else if (ASIC_IS_DCE3(rdev)) {
+ } else {
/* according to the reg specs, this should DCE3.2 only, but in
- * practice it seems to cover DCE3.0/3.1 as well.
+ * practice it seems to cover DCE2.0/3.0/3.1 as well.
*/
if (dig->dig_encoder == 0) {
WREG32(DCCG_AUDIO_DTO0_PHASE, base_rate * 100);
@@ -317,10 +317,6 @@ void r600_audio_set_dto(struct drm_encod
WREG32(DCCG_AUDIO_DTO1_MODULE, clock * 100);
WREG32(DCCG_AUDIO_DTO_SELECT, 1); /* select DTO1 */
}
- } else {
- /* according to the reg specs, this should be DCE2.0 and DCE3.0/3.1 */
- WREG32(AUDIO_DTO, AUDIO_DTO_PHASE(base_rate / 10) |
- AUDIO_DTO_MODULE(clock / 10));
}
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 065/118] drm/radeon: fixup bad vram size on SI
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (61 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 064/118] drm/radeon: program DCE2 audio dto just like DCE3 Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 066/118] drm/radeon/atom: fix bus probes when hw_i2c is set (v2) Greg Kroah-Hartman
` (53 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Alex Deucher
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
commit 0ca223b029a261e82fb2f50c52eb85d510f4260e upstream.
Some boards seem to have garbage in the upper
16 bits of the vram size register. Check for
this and clamp the size properly. Fixes
boards reporting bogus amounts of vram.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/si.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -3887,8 +3887,15 @@ static int si_mc_init(struct radeon_devi
rdev->mc.aper_base = pci_resource_start(rdev->pdev, 0);
rdev->mc.aper_size = pci_resource_len(rdev->pdev, 0);
/* size in MB on si */
- rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 1024ULL;
- rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 1024ULL;
+ tmp = RREG32(CONFIG_MEMSIZE);
+ /* some boards may have garbage in the upper 16 bits */
+ if (tmp & 0xffff0000) {
+ DRM_INFO("Probable bad vram size: 0x%08x\n", tmp);
+ if (tmp & 0xffff)
+ tmp &= 0xffff;
+ }
+ rdev->mc.mc_vram_size = tmp * 1024ULL * 1024ULL;
+ rdev->mc.real_vram_size = rdev->mc.mc_vram_size;
rdev->mc.visible_vram_size = rdev->mc.aper_size;
si_vram_gtt_location(rdev, &rdev->mc);
radeon_update_bandwidth_info(rdev);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 066/118] drm/radeon/atom: fix bus probes when hw_i2c is set (v2)
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (62 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 065/118] drm/radeon: fixup bad vram size on SI Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 067/118] x86, efi: Dont use (U)EFI time services on 32 bit Greg Kroah-Hartman
` (52 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Alex Deucher
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
commit ffd3d3361d583cb73fa65a5fed3a196ba6f261bb upstream.
When probing the bus, we need to set the byte count
to 0 rather than 1.
v2: Don't count the first byte.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=66241
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/atombios_i2c.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
--- a/drivers/gpu/drm/radeon/atombios_i2c.c
+++ b/drivers/gpu/drm/radeon/atombios_i2c.c
@@ -44,7 +44,7 @@ static int radeon_process_i2c_ch(struct
PROCESS_I2C_CHANNEL_TRANSACTION_PS_ALLOCATION args;
int index = GetIndexIntoMasterTable(COMMAND, ProcessI2cChannelTransaction);
unsigned char *base;
- u16 out;
+ u16 out = cpu_to_le16(0);
memset(&args, 0, sizeof(args));
@@ -55,11 +55,14 @@ static int radeon_process_i2c_ch(struct
DRM_ERROR("hw i2c: tried to write too many bytes (%d vs 3)\n", num);
return -EINVAL;
}
- args.ucRegIndex = buf[0];
- if (num > 1) {
+ if (buf == NULL)
+ args.ucRegIndex = 0;
+ else
+ args.ucRegIndex = buf[0];
+ if (num)
num--;
+ if (num)
memcpy(&out, &buf[1], num);
- }
args.lpI2CDataOut = cpu_to_le16(out);
} else {
if (num > ATOM_MAX_HW_I2C_READ) {
@@ -96,14 +99,14 @@ int radeon_atom_hw_i2c_xfer(struct i2c_a
struct radeon_i2c_chan *i2c = i2c_get_adapdata(i2c_adap);
struct i2c_msg *p;
int i, remaining, current_count, buffer_offset, max_bytes, ret;
- u8 buf = 0, flags;
+ u8 flags;
/* check for bus probe */
p = &msgs[0];
if ((num == 1) && (p->len == 0)) {
ret = radeon_process_i2c_ch(i2c,
p->addr, HW_I2C_WRITE,
- &buf, 1);
+ NULL, 0);
if (ret)
return ret;
else
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 067/118] x86, efi: Dont use (U)EFI time services on 32 bit
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (63 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 066/118] drm/radeon/atom: fix bus probes when hw_i2c is set (v2) Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 068/118] x86/UV: Fix NULL pointer dereference in uv_flush_tlb_others() if the nobau boot option is used Greg Kroah-Hartman
` (51 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Matthew Garrett, Matt Fleming,
H. Peter Anvin
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthew Garrett <matthew.garrett@nebula.com>
commit 04bf9ba720fcc4fa313fa122b799ae0989b6cd50 upstream.
UEFI time services are often broken once we're in virtual mode. We were
already refusing to use them on 64-bit systems, but it turns out that
they're also broken on some 32-bit firmware, including the Dell Venue.
Disable them for now, we can revisit once we have the 1:1 mappings code
incorporated.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Link: http://lkml.kernel.org/r/1385754283-2464-1-git-send-email-matthew.garrett@nebula.com
Cc: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/platform/efi/efi.c | 7 -------
1 file changed, 7 deletions(-)
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -768,13 +768,6 @@ void __init efi_init(void)
set_bit(EFI_MEMMAP, &x86_efi_facility);
-#ifdef CONFIG_X86_32
- if (efi_is_native()) {
- x86_platform.get_wallclock = efi_get_time;
- x86_platform.set_wallclock = efi_set_rtc_mmss;
- }
-#endif
-
#if EFI_DEBUG
print_efi_memmap();
#endif
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 068/118] x86/UV: Fix NULL pointer dereference in uv_flush_tlb_others() if the nobau boot option is used
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (64 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 067/118] x86, efi: Dont use (U)EFI time services on 32 bit Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 069/118] x86, build: Pass in additional -mno-mmx, -mno-sse options Greg Kroah-Hartman
` (50 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Cliff Wickman, Ingo Molnar
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: cpw <cpw@sgi.com>
commit 3eae49ca8954f958b2001ab5643ef302cb7b67c7 upstream.
The SGI UV tlb shootdown code panics the system with a NULL
pointer deference if 'nobau' is specified on the boot
commandline.
uv_flush_tlb_other() gets called for every flush, whether the
BAU is disabled or not. It should not be keeping the s_enters
statistic while the BAU is disabled.
The panic occurs because during initialization
init_per_cpu_tunables() does not set the bcp->statp pointer if
'nobau' was specified.
Signed-off-by: Cliff Wickman <cpw@sgi.com>
Link: http://lkml.kernel.org/r/E1VnzBi-0005yF-MU@eag09.americas.sgi.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/platform/uv/tlb_uv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -1070,12 +1070,13 @@ const struct cpumask *uv_flush_tlb_other
unsigned long status;
bcp = &per_cpu(bau_control, cpu);
- stat = bcp->statp;
- stat->s_enters++;
if (bcp->nobau)
return cpumask;
+ stat = bcp->statp;
+ stat->s_enters++;
+
if (bcp->busy) {
descriptor_status =
read_lmmr(UVH_LB_BAU_SB_ACTIVATION_STATUS_0);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 069/118] x86, build: Pass in additional -mno-mmx, -mno-sse options
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (65 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 068/118] x86/UV: Fix NULL pointer dereference in uv_flush_tlb_others() if the nobau boot option is used Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 070/118] x86, build, icc: Remove uninitialized_var() from compiler-intel.h Greg Kroah-Hartman
` (49 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kevin B. Smith, Sunil K. Pandey,
H. Peter Anvin, H. J. Lu
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: "H. Peter Anvin" <hpa@linux.intel.com>
commit 8b3b005d675726e38bc504d2e35a991e55819155 upstream.
In checkin
5551a34e5aea x86-64, build: Always pass in -mno-sse
we unconditionally added -mno-sse to the main build, to keep newer
compilers from generating SSE instructions from autovectorization.
However, this did not extend to the special environments
(arch/x86/boot, arch/x86/boot/compressed, and arch/x86/realmode/rm).
Add -mno-sse to the compiler command line for these environments, and
add -mno-mmx to all the environments as well, as we don't want a
compiler to generate MMX code either.
This patch also removes a $(cc-option) call for -m32, since we have
long since stopped supporting compilers too old for the -m32 option,
and in fact hardcode it in other places in the Makefiles.
Reported-by: Kevin B. Smith <kevin.b.smith@intel.com>
Cc: Sunil K. Pandey <sunil.k.pandey@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: H. J. Lu <hjl.tools@gmail.com>
Link: http://lkml.kernel.org/n/tip-j21wzqv790q834n7yc6g80j1@git.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/Makefile | 8 ++++----
arch/x86/boot/Makefile | 6 +++---
arch/x86/boot/compressed/Makefile | 1 +
arch/x86/realmode/rm/Makefile | 3 ++-
4 files changed, 10 insertions(+), 8 deletions(-)
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -31,8 +31,8 @@ ifeq ($(CONFIG_X86_32),y)
KBUILD_CFLAGS += -msoft-float -mregparm=3 -freg-struct-return
- # Don't autogenerate SSE instructions
- KBUILD_CFLAGS += -mno-sse
+ # Don't autogenerate MMX or SSE instructions
+ KBUILD_CFLAGS += -mno-mmx -mno-sse
# Never want PIC in a 32-bit kernel, prevent breakage with GCC built
# with nonstandard options
@@ -60,8 +60,8 @@ else
KBUILD_AFLAGS += -m64
KBUILD_CFLAGS += -m64
- # Don't autogenerate SSE instructions
- KBUILD_CFLAGS += -mno-sse
+ # Don't autogenerate MMX or SSE instructions
+ KBUILD_CFLAGS += -mno-mmx -mno-sse
# Use -mpreferred-stack-boundary=3 if supported.
KBUILD_CFLAGS += $(call cc-option,-mpreferred-stack-boundary=3)
--- a/arch/x86/boot/Makefile
+++ b/arch/x86/boot/Makefile
@@ -53,18 +53,18 @@ $(obj)/cpustr.h: $(obj)/mkcpustr FORCE
# How to compile the 16-bit code. Note we always compile for -march=i386,
# that way we can complain to the user if the CPU is insufficient.
-KBUILD_CFLAGS := $(USERINCLUDE) -g -Os -D_SETUP -D__KERNEL__ \
+KBUILD_CFLAGS := $(USERINCLUDE) -m32 -g -Os -D_SETUP -D__KERNEL__ \
-DDISABLE_BRANCH_PROFILING \
-Wall -Wstrict-prototypes \
-march=i386 -mregparm=3 \
-include $(srctree)/$(src)/code16gcc.h \
-fno-strict-aliasing -fomit-frame-pointer -fno-pic \
+ -mno-mmx -mno-sse \
$(call cc-option, -ffreestanding) \
$(call cc-option, -fno-toplevel-reorder,\
- $(call cc-option, -fno-unit-at-a-time)) \
+ $(call cc-option, -fno-unit-at-a-time)) \
$(call cc-option, -fno-stack-protector) \
$(call cc-option, -mpreferred-stack-boundary=2)
-KBUILD_CFLAGS += $(call cc-option, -m32)
KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__
GCOV_PROFILE := n
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -13,6 +13,7 @@ KBUILD_CFLAGS += -DDISABLE_BRANCH_PROFIL
cflags-$(CONFIG_X86_32) := -march=i386
cflags-$(CONFIG_X86_64) := -mcmodel=small
KBUILD_CFLAGS += $(cflags-y)
+KBUILD_CFLAGS += -mno-mmx -mno-sse
KBUILD_CFLAGS += $(call cc-option,-ffreestanding)
KBUILD_CFLAGS += $(call cc-option,-fno-stack-protector)
--- a/arch/x86/realmode/rm/Makefile
+++ b/arch/x86/realmode/rm/Makefile
@@ -73,9 +73,10 @@ KBUILD_CFLAGS := $(LINUXINCLUDE) -m32 -g
-march=i386 -mregparm=3 \
-include $(srctree)/$(src)/../../boot/code16gcc.h \
-fno-strict-aliasing -fomit-frame-pointer -fno-pic \
+ -mno-mmx -mno-sse \
$(call cc-option, -ffreestanding) \
$(call cc-option, -fno-toplevel-reorder,\
- $(call cc-option, -fno-unit-at-a-time)) \
+ $(call cc-option, -fno-unit-at-a-time)) \
$(call cc-option, -fno-stack-protector) \
$(call cc-option, -mpreferred-stack-boundary=2)
KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 070/118] x86, build, icc: Remove uninitialized_var() from compiler-intel.h
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (66 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 069/118] x86, build: Pass in additional -mno-mmx, -mno-sse options Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 071/118] media: saa7164: fix return value check in saa7164_initdev() Greg Kroah-Hartman
` (48 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sunil K. Pandey, Kevin B. Smith,
H. Peter Anvin
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: "H. Peter Anvin" <hpa@linux.intel.com>
commit 503cf95c061a0551eb684da364509297efbe55d9 upstream.
When compiling with icc, <linux/compiler-gcc.h> ends up included
because the icc environment defines __GNUC__. Thus, we neither need
nor want to have this macro defined in both compiler-gcc.h and
compiler-intel.h, and the fact that they are inconsistent just makes
the compiler spew warnings.
Reported-by: Sunil K. Pandey <sunil.k.pandey@intel.com>
Cc: Kevin B. Smith <kevin.b.smith@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/n/tip-0mbwou1zt7pafij09b897lg3@git.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/compiler-intel.h | 2 --
1 file changed, 2 deletions(-)
--- a/include/linux/compiler-intel.h
+++ b/include/linux/compiler-intel.h
@@ -28,8 +28,6 @@
#endif
-#define uninitialized_var(x) x
-
#ifndef __HAVE_BUILTIN_BSWAP16__
/* icc has this, but it's called _bswap16 */
#define __HAVE_BUILTIN_BSWAP16__
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 071/118] media: saa7164: fix return value check in saa7164_initdev()
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (67 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 070/118] x86, build, icc: Remove uninitialized_var() from compiler-intel.h Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 072/118] media: tef6862/radio-tea5764: actually assign clamp result Greg Kroah-Hartman
` (47 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Wei Yongjun, Hans Verkuil,
Mauro Carvalho Chehab
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
commit 89f4d45b2752df5d222b5f63919ce59e2d8afaf4 upstream.
In case of error, the function kthread_run() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check
should be replaced with IS_ERR().
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/pci/saa7164/saa7164-core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/media/pci/saa7164/saa7164-core.c
+++ b/drivers/media/pci/saa7164/saa7164-core.c
@@ -1354,9 +1354,11 @@ static int saa7164_initdev(struct pci_de
if (fw_debug) {
dev->kthread = kthread_run(saa7164_thread_function, dev,
"saa7164 debug");
- if (!dev->kthread)
+ if (IS_ERR(dev->kthread)) {
+ dev->kthread = NULL;
printk(KERN_ERR "%s() Failed to create "
"debug kernel thread\n", __func__);
+ }
}
} /* != BOARD_UNKNOWN */
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 072/118] media: tef6862/radio-tea5764: actually assign clamp result
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (68 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 071/118] media: saa7164: fix return value check in saa7164_initdev() Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 074/118] media: af9033: fix broken I2C Greg Kroah-Hartman
` (46 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hans Verkuil, Hans Petter Selasky,
Mauro Carvalho Chehab
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans Verkuil <hverkuil@xs4all.nl>
commit 9ba6a91f19b8c118d11c549495fa4f7a20505d80 upstream.
When adding frequency clamping to the tef6862 and radio-tea5764 drivers
I forgot to actually *assign* the clamp result to the frequency.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Reported-by: Hans Petter Selasky <hps@bitfrost.no>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/radio/radio-tea5764.c | 2 +-
drivers/media/radio/tef6862.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/media/radio/radio-tea5764.c
+++ b/drivers/media/radio/radio-tea5764.c
@@ -356,7 +356,7 @@ static int vidioc_s_frequency(struct fil
So we keep it as-is. */
return -EINVAL;
}
- clamp(freq, FREQ_MIN * FREQ_MUL, FREQ_MAX * FREQ_MUL);
+ freq = clamp(freq, FREQ_MIN * FREQ_MUL, FREQ_MAX * FREQ_MUL);
tea5764_power_up(radio);
tea5764_tune(radio, (freq * 125) / 2);
return 0;
--- a/drivers/media/radio/tef6862.c
+++ b/drivers/media/radio/tef6862.c
@@ -112,7 +112,7 @@ static int tef6862_s_frequency(struct v4
if (f->tuner != 0)
return -EINVAL;
- clamp(freq, TEF6862_LO_FREQ, TEF6862_HI_FREQ);
+ freq = clamp(freq, TEF6862_LO_FREQ, TEF6862_HI_FREQ);
pll = 1964 + ((freq - TEF6862_LO_FREQ) * 20) / FREQ_MUL;
i2cmsg[0] = (MODE_PRESET << MODE_SHIFT) | WM_SUB_PLLM;
i2cmsg[1] = (pll >> 8) & 0xff;
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 074/118] media: af9033: fix broken I2C
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (69 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 072/118] media: tef6862/radio-tea5764: actually assign clamp result Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 075/118] media: wm8775: fix broken audio routing Greg Kroah-Hartman
` (45 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Antti Palosaari, Mauro Carvalho Chehab
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Antti Palosaari <crope@iki.fi>
commit d18a88b1f535d627412b2a265d71b2f7d464860e upstream.
Driver did not work anymore since I2C has gone broken due
to recent commit:
commit 37ebaf6891ee81687bb558e8375c0712d8264ed8
[media] dvb-frontends: Don't use dynamic static allocation
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/dvb-frontends/af9033.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -170,18 +170,18 @@ static int af9033_rd_reg_mask(struct af9
static int af9033_wr_reg_val_tab(struct af9033_state *state,
const struct reg_val *tab, int tab_len)
{
+#define MAX_TAB_LEN 212
int ret, i, j;
- u8 buf[MAX_XFER_SIZE];
+ u8 buf[1 + MAX_TAB_LEN];
+
+ dev_dbg(&state->i2c->dev, "%s: tab_len=%d\n", __func__, tab_len);
if (tab_len > sizeof(buf)) {
- dev_warn(&state->i2c->dev,
- "%s: i2c wr len=%d is too big!\n",
- KBUILD_MODNAME, tab_len);
+ dev_warn(&state->i2c->dev, "%s: tab len %d is too big\n",
+ KBUILD_MODNAME, tab_len);
return -EINVAL;
}
- dev_dbg(&state->i2c->dev, "%s: tab_len=%d\n", __func__, tab_len);
-
for (i = 0, j = 0; i < tab_len; i++) {
buf[j] = tab[i].val;
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 075/118] media: wm8775: fix broken audio routing
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (70 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 074/118] media: af9033: fix broken I2C Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 076/118] media: af9035: add [0413:6a05] Leadtek WinFast DTV Dongle Dual Greg Kroah-Hartman
` (44 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andy Walls, Rajil Saraswat,
Hans Verkuil, Mauro Carvalho Chehab
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans Verkuil <hans.verkuil@cisco.com>
commit 3af41a337a5b270de3e65466a07f106ad97ad0c6 upstream.
Commit 5aa9ae5ed5d449a85fbf7aac3d1fdc241c542a79 inverted the mute control
state test in s_routing which caused the audio routing to fail. This broke
ivtv support for the Hauppauge video/audio input bracket (which adds additional
video and audio inputs) all the way back in kernel 2.6.36.
This fix fixes the condition and it also removes a nonsense check on the
balance control.
Bisected-by: Rajil Saraswat <rajil.s@gmail.com>
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Reported-by: Rajil Saraswat <rajil.s@gmail.com>
Tested-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/i2c/wm8775.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/media/i2c/wm8775.c
+++ b/drivers/media/i2c/wm8775.c
@@ -130,12 +130,10 @@ static int wm8775_s_routing(struct v4l2_
return -EINVAL;
}
state->input = input;
- if (!v4l2_ctrl_g_ctrl(state->mute))
+ if (v4l2_ctrl_g_ctrl(state->mute))
return 0;
if (!v4l2_ctrl_g_ctrl(state->vol))
return 0;
- if (!v4l2_ctrl_g_ctrl(state->bal))
- return 0;
wm8775_set_audio(sd, 1);
return 0;
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 076/118] media: af9035: add [0413:6a05] Leadtek WinFast DTV Dongle Dual
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (71 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 075/118] media: wm8775: fix broken audio routing Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 077/118] media: af9035: unlock on error in af9035_i2c_master_xfer() Greg Kroah-Hartman
` (43 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Michael Piko, Antti Palosaari,
Mauro Carvalho Chehab
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Antti Palosaari <crope@iki.fi>
commit 0c413d10515feae02cee967b31bb8afea8aa0d29 upstream.
It is IT9135 dual design.
Thanks to Michael Piko for reporting that!
Reported-by: Michael Piko <michael@piko.com.au>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/dvb-usb-v2/af9035.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -1534,6 +1534,8 @@ static const struct usb_device_id af9035
/* XXX: that same ID [0ccd:0099] is used by af9015 driver too */
{ DVB_USB_DEVICE(USB_VID_TERRATEC, 0x0099,
&af9035_props, "TerraTec Cinergy T Stick Dual RC (rev. 2)", NULL) },
+ { DVB_USB_DEVICE(USB_VID_LEADTEK, 0x6a05,
+ &af9035_props, "Leadtek WinFast DTV Dongle Dual", NULL) },
{ }
};
MODULE_DEVICE_TABLE(usb, af9035_id_table);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 077/118] media: af9035: unlock on error in af9035_i2c_master_xfer()
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (72 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 076/118] media: af9035: add [0413:6a05] Leadtek WinFast DTV Dongle Dual Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 078/118] Btrfs: fix access_ok() check in btrfs_ioctl_send() Greg Kroah-Hartman
` (42 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Antti Palosaari,
Mauro Carvalho Chehab
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 3189ef0290dcc9f44782672fade35847cb30da00 upstream.
We introduced a couple new error paths which are missing unlocks.
Fixes: 7760e148350b ('[media] af9035: Don't use dynamic static allocation')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/dvb-usb-v2/af9035.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -245,7 +245,8 @@ static int af9035_i2c_master_xfer(struct
dev_warn(&d->udev->dev,
"%s: i2c xfer: len=%d is too big!\n",
KBUILD_MODNAME, msg[0].len);
- return -EOPNOTSUPP;
+ ret = -EOPNOTSUPP;
+ goto unlock;
}
req.mbox |= ((msg[0].addr & 0x80) >> 3);
buf[0] = msg[1].len;
@@ -281,7 +282,8 @@ static int af9035_i2c_master_xfer(struct
dev_warn(&d->udev->dev,
"%s: i2c xfer: len=%d is too big!\n",
KBUILD_MODNAME, msg[0].len);
- return -EOPNOTSUPP;
+ ret = -EOPNOTSUPP;
+ goto unlock;
}
req.mbox |= ((msg[0].addr & 0x80) >> 3);
buf[0] = msg[0].len;
@@ -319,6 +321,7 @@ static int af9035_i2c_master_xfer(struct
ret = -EOPNOTSUPP;
}
+unlock:
mutex_unlock(&d->i2c_mutex);
if (ret < 0)
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 078/118] Btrfs: fix access_ok() check in btrfs_ioctl_send()
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (73 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 077/118] media: af9035: unlock on error in af9035_i2c_master_xfer() Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 079/118] btrfs: call mnt_drop_write after interrupted subvol deletion Greg Kroah-Hartman
` (41 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Jie Liu, Chris Mason
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 700ff4f095d78af0998953e922e041d75254518b upstream.
The closing parenthesis is in the wrong place. We want to check
"sizeof(*arg->clone_sources) * arg->clone_sources_count" instead of
"sizeof(*arg->clone_sources * arg->clone_sources_count)".
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Jie Liu <jeff.liu@oracle.com>
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/send.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -4756,8 +4756,8 @@ long btrfs_ioctl_send(struct file *mnt_f
}
if (!access_ok(VERIFY_READ, arg->clone_sources,
- sizeof(*arg->clone_sources *
- arg->clone_sources_count))) {
+ sizeof(*arg->clone_sources) *
+ arg->clone_sources_count)) {
ret = -EFAULT;
goto out;
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 079/118] btrfs: call mnt_drop_write after interrupted subvol deletion
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (74 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 078/118] Btrfs: fix access_ok() check in btrfs_ioctl_send() Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 080/118] dm bufio: initialize read-only module parameters Greg Kroah-Hartman
` (40 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, David Sterba, Chris Mason
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Sterba <dsterba@suse.cz>
commit e43f998e47bae27e37e159915625e8d4b130153b upstream.
If btrfs_ioctl_snap_destroy blocks on the mutex and the process is
killed, mnt_write count is unbalanced and leads to unmountable
filesystem.
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/ioctl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2130,7 +2130,7 @@ static noinline int btrfs_ioctl_snap_des
err = mutex_lock_killable_nested(&dir->i_mutex, I_MUTEX_PARENT);
if (err == -EINTR)
- goto out;
+ goto out_drop_write;
dentry = lookup_one_len(vol_args->name, parent, namelen);
if (IS_ERR(dentry)) {
err = PTR_ERR(dentry);
@@ -2293,6 +2293,7 @@ out_dput:
dput(dentry);
out_unlock_dir:
mutex_unlock(&dir->i_mutex);
+out_drop_write:
mnt_drop_write_file(file);
out:
kfree(vol_args);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 080/118] dm bufio: initialize read-only module parameters
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (75 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 079/118] btrfs: call mnt_drop_write after interrupted subvol deletion Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 081/118] dm snapshot: avoid snapshot space leak on crash Greg Kroah-Hartman
` (39 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mikulas Patocka, Mike Snitzer
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikulas Patocka <mpatocka@redhat.com>
commit 4cb57ab4a2e61978f3a9b7d4f53988f30d61c27f upstream.
Some module parameters in dm-bufio are read-only. These parameters
inform the user about memory consumption. They are not supposed to be
changed by the user.
However, despite being read-only, these parameters can be set on
modprobe or insmod command line, for example:
modprobe dm-bufio current_allocated_bytes=12345
The kernel doesn't expect that these variables can be non-zero at module
initialization and if the user sets them, it results in BUG.
This patch initializes the variables in the module init routine, so that
user-supplied values are ignored.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-bufio.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/md/dm-bufio.c
+++ b/drivers/md/dm-bufio.c
@@ -1717,6 +1717,11 @@ static int __init dm_bufio_init(void)
{
__u64 mem;
+ dm_bufio_allocated_kmem_cache = 0;
+ dm_bufio_allocated_get_free_pages = 0;
+ dm_bufio_allocated_vmalloc = 0;
+ dm_bufio_current_allocated = 0;
+
memset(&dm_bufio_caches, 0, sizeof dm_bufio_caches);
memset(&dm_bufio_cache_names, 0, sizeof dm_bufio_cache_names);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 081/118] dm snapshot: avoid snapshot space leak on crash
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (76 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 080/118] dm bufio: initialize read-only module parameters Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:11 ` [PATCH 3.12 082/118] dm stats: initialize read-only module parameter Greg Kroah-Hartman
` (38 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mikulas Patocka, Mike Snitzer
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikulas Patocka <mpatocka@redhat.com>
commit 230c83afdd9cd384348475bea1e14b80b3b6b1b8 upstream.
There is a possible leak of snapshot space in case of crash.
The reason for space leaking is that chunks in the snapshot device are
allocated sequentially, but they are finished (and stored in the metadata)
out of order, depending on the order in which copying finished.
For example, supposed that the metadata contains the following records
SUPERBLOCK
METADATA (blocks 0 ... 250)
DATA 0
DATA 1
DATA 2
...
DATA 250
Now suppose that you allocate 10 new data blocks 251-260. Suppose that
copying of these blocks finish out of order (block 260 finished first
and the block 251 finished last). Now, the snapshot device looks like
this:
SUPERBLOCK
METADATA (blocks 0 ... 250, 260, 259, 258, 257, 256)
DATA 0
DATA 1
DATA 2
...
DATA 250
DATA 251
DATA 252
DATA 253
DATA 254
DATA 255
METADATA (blocks 255, 254, 253, 252, 251)
DATA 256
DATA 257
DATA 258
DATA 259
DATA 260
Now, if the machine crashes after writing the first metadata block but
before writing the second metadata block, the space for areas DATA 250-255
is leaked, it contains no valid data and it will never be used in the
future.
This patch makes dm-snapshot complete exceptions in the same order they
were allocated, thus fixing this bug.
Note: when backporting this patch to the stable kernel, change the version
field in the following way:
* if version in the stable kernel is {1, 11, 1}, change it to {1, 12, 0}
* if version in the stable kernel is {1, 10, 0} or {1, 10, 1}, change it
to {1, 10, 2}
Userspace reads the version to determine if the bug was fixed, so the
version change is needed.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-snap.c | 71 +++++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 64 insertions(+), 7 deletions(-)
--- a/drivers/md/dm-snap.c
+++ b/drivers/md/dm-snap.c
@@ -66,6 +66,18 @@ struct dm_snapshot {
atomic_t pending_exceptions_count;
+ /* Protected by "lock" */
+ sector_t exception_start_sequence;
+
+ /* Protected by kcopyd single-threaded callback */
+ sector_t exception_complete_sequence;
+
+ /*
+ * A list of pending exceptions that completed out of order.
+ * Protected by kcopyd single-threaded callback.
+ */
+ struct list_head out_of_order_list;
+
mempool_t *pending_pool;
struct dm_exception_table pending;
@@ -173,6 +185,14 @@ struct dm_snap_pending_exception {
*/
int started;
+ /* There was copying error. */
+ int copy_error;
+
+ /* A sequence number, it is used for in-order completion. */
+ sector_t exception_sequence;
+
+ struct list_head out_of_order_entry;
+
/*
* For writing a complete chunk, bypassing the copy.
*/
@@ -1094,6 +1114,9 @@ static int snapshot_ctr(struct dm_target
s->valid = 1;
s->active = 0;
atomic_set(&s->pending_exceptions_count, 0);
+ s->exception_start_sequence = 0;
+ s->exception_complete_sequence = 0;
+ INIT_LIST_HEAD(&s->out_of_order_list);
init_rwsem(&s->lock);
INIT_LIST_HEAD(&s->list);
spin_lock_init(&s->pe_lock);
@@ -1443,6 +1466,19 @@ static void commit_callback(void *contex
pending_complete(pe, success);
}
+static void complete_exception(struct dm_snap_pending_exception *pe)
+{
+ struct dm_snapshot *s = pe->snap;
+
+ if (unlikely(pe->copy_error))
+ pending_complete(pe, 0);
+
+ else
+ /* Update the metadata if we are persistent */
+ s->store->type->commit_exception(s->store, &pe->e,
+ commit_callback, pe);
+}
+
/*
* Called when the copy I/O has finished. kcopyd actually runs
* this code so don't block.
@@ -1452,13 +1488,32 @@ static void copy_callback(int read_err,
struct dm_snap_pending_exception *pe = context;
struct dm_snapshot *s = pe->snap;
- if (read_err || write_err)
- pending_complete(pe, 0);
+ pe->copy_error = read_err || write_err;
- else
- /* Update the metadata if we are persistent */
- s->store->type->commit_exception(s->store, &pe->e,
- commit_callback, pe);
+ if (pe->exception_sequence == s->exception_complete_sequence) {
+ s->exception_complete_sequence++;
+ complete_exception(pe);
+
+ while (!list_empty(&s->out_of_order_list)) {
+ pe = list_entry(s->out_of_order_list.next,
+ struct dm_snap_pending_exception, out_of_order_entry);
+ if (pe->exception_sequence != s->exception_complete_sequence)
+ break;
+ s->exception_complete_sequence++;
+ list_del(&pe->out_of_order_entry);
+ complete_exception(pe);
+ }
+ } else {
+ struct list_head *lh;
+ struct dm_snap_pending_exception *pe2;
+
+ list_for_each_prev(lh, &s->out_of_order_list) {
+ pe2 = list_entry(lh, struct dm_snap_pending_exception, out_of_order_entry);
+ if (pe2->exception_sequence < pe->exception_sequence)
+ break;
+ }
+ list_add(&pe->out_of_order_entry, lh);
+ }
}
/*
@@ -1553,6 +1608,8 @@ __find_pending_exception(struct dm_snaps
return NULL;
}
+ pe->exception_sequence = s->exception_start_sequence++;
+
dm_insert_exception(&s->pending, &pe->e);
return pe;
@@ -2192,7 +2249,7 @@ static struct target_type origin_target
static struct target_type snapshot_target = {
.name = "snapshot",
- .version = {1, 11, 1},
+ .version = {1, 12, 0},
.module = THIS_MODULE,
.ctr = snapshot_ctr,
.dtr = snapshot_dtr,
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 082/118] dm stats: initialize read-only module parameter
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (77 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 081/118] dm snapshot: avoid snapshot space leak on crash Greg Kroah-Hartman
@ 2013-12-18 21:11 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 083/118] dm array: fix a reference counting bug in shadow_ablock Greg Kroah-Hartman
` (37 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mikulas Patocka, Mike Snitzer
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikulas Patocka <mpatocka@redhat.com>
commit 76f5bee5c3b45c617f91243e85547fc8f67bc678 upstream.
The module parameter stats_current_allocated_bytes in dm-mod is
read-only. This parameter informs the user about memory
consumption. It is not supposed to be changed by the user.
However, despite being read-only, this parameter can be set on
modprobe or insmod command line:
modprobe dm-mod stats_current_allocated_bytes=12345
The kernel doesn't expect that this variable can be non-zero at module
initialization and if the user sets it, it results in warning.
This patch initializes the variable in the module init routine, so
that user-supplied value is ignored.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-stats.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/md/dm-stats.c
+++ b/drivers/md/dm-stats.c
@@ -964,6 +964,7 @@ int dm_stats_message(struct mapped_devic
int __init dm_statistics_init(void)
{
+ shared_memory_amount = 0;
dm_stat_need_rcu_barrier = 0;
return 0;
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 083/118] dm array: fix a reference counting bug in shadow_ablock
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (78 preceding siblings ...)
2013-12-18 21:11 ` [PATCH 3.12 082/118] dm stats: initialize read-only module parameter Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 084/118] dm delay: fix a possible deadlock due to shared workqueue Greg Kroah-Hartman
` (36 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Joe Thornber, Mike Snitzer
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joe Thornber <ejt@redhat.com>
commit ed9571f0cf1fe09d3506302610f3ccdfa1d22c4a upstream.
An old array block could have its reference count decremented below
zero when it is being replaced in the btree by a new array block.
The fix is to increment the old ablock's reference count just before
inserting a new ablock into the btree.
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/persistent-data/dm-array.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/md/persistent-data/dm-array.c
+++ b/drivers/md/persistent-data/dm-array.c
@@ -317,8 +317,16 @@ static int shadow_ablock(struct dm_array
* The shadow op will often be a noop. Only insert if it really
* copied data.
*/
- if (dm_block_location(*block) != b)
+ if (dm_block_location(*block) != b) {
+ /*
+ * dm_tm_shadow_block will have already decremented the old
+ * block, but it is still referenced by the btree. We
+ * increment to stop the insert decrementing it below zero
+ * when overwriting the old value.
+ */
+ dm_tm_inc(info->btree_info.tm, b);
r = insert_ablock(info, index, *block, root);
+ }
return r;
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 084/118] dm delay: fix a possible deadlock due to shared workqueue
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (79 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 083/118] dm array: fix a reference counting bug in shadow_ablock Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 085/118] dm space map metadata: return on failure in sm_metadata_new_block Greg Kroah-Hartman
` (35 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mikulas Patocka, Mike Snitzer
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikulas Patocka <mpatocka@redhat.com>
commit 718822c1c112dc99e0c72c8968ee1db9d9d910f0 upstream.
The dm-delay target uses a shared workqueue for multiple instances. This
can cause deadlock if two or more dm-delay targets are stacked on the top
of each other.
This patch changes dm-delay to use a per-instance workqueue.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-delay.c | 23 +++++++++++------------
1 file changed, 11 insertions(+), 12 deletions(-)
--- a/drivers/md/dm-delay.c
+++ b/drivers/md/dm-delay.c
@@ -20,6 +20,7 @@
struct delay_c {
struct timer_list delay_timer;
struct mutex timer_lock;
+ struct workqueue_struct *kdelayd_wq;
struct work_struct flush_expired_bios;
struct list_head delayed_bios;
atomic_t may_delay;
@@ -45,14 +46,13 @@ struct dm_delay_info {
static DEFINE_MUTEX(delayed_bios_lock);
-static struct workqueue_struct *kdelayd_wq;
static struct kmem_cache *delayed_cache;
static void handle_delayed_timer(unsigned long data)
{
struct delay_c *dc = (struct delay_c *)data;
- queue_work(kdelayd_wq, &dc->flush_expired_bios);
+ queue_work(dc->kdelayd_wq, &dc->flush_expired_bios);
}
static void queue_timeout(struct delay_c *dc, unsigned long expires)
@@ -191,6 +191,12 @@ out:
goto bad_dev_write;
}
+ dc->kdelayd_wq = alloc_workqueue("kdelayd", WQ_MEM_RECLAIM, 0);
+ if (!dc->kdelayd_wq) {
+ DMERR("Couldn't start kdelayd");
+ goto bad_queue;
+ }
+
setup_timer(&dc->delay_timer, handle_delayed_timer, (unsigned long)dc);
INIT_WORK(&dc->flush_expired_bios, flush_expired_bios);
@@ -203,6 +209,8 @@ out:
ti->private = dc;
return 0;
+bad_queue:
+ mempool_destroy(dc->delayed_pool);
bad_dev_write:
if (dc->dev_write)
dm_put_device(ti, dc->dev_write);
@@ -217,7 +225,7 @@ static void delay_dtr(struct dm_target *
{
struct delay_c *dc = ti->private;
- flush_workqueue(kdelayd_wq);
+ destroy_workqueue(dc->kdelayd_wq);
dm_put_device(ti, dc->dev_read);
@@ -350,12 +358,6 @@ static int __init dm_delay_init(void)
{
int r = -ENOMEM;
- kdelayd_wq = alloc_workqueue("kdelayd", WQ_MEM_RECLAIM, 0);
- if (!kdelayd_wq) {
- DMERR("Couldn't start kdelayd");
- goto bad_queue;
- }
-
delayed_cache = KMEM_CACHE(dm_delay_info, 0);
if (!delayed_cache) {
DMERR("Couldn't create delayed bio cache.");
@@ -373,8 +375,6 @@ static int __init dm_delay_init(void)
bad_register:
kmem_cache_destroy(delayed_cache);
bad_memcache:
- destroy_workqueue(kdelayd_wq);
-bad_queue:
return r;
}
@@ -382,7 +382,6 @@ static void __exit dm_delay_exit(void)
{
dm_unregister_target(&delay_target);
kmem_cache_destroy(delayed_cache);
- destroy_workqueue(kdelayd_wq);
}
/* Module hooks */
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 085/118] dm space map metadata: return on failure in sm_metadata_new_block
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (80 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 084/118] dm delay: fix a possible deadlock due to shared workqueue Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 086/118] dm space map: disallow decrementing a reference count below zero Greg Kroah-Hartman
` (34 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mike Snitzer, Joe Thornber
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mike Snitzer <snitzer@redhat.com>
commit f62b6b8f498658a9d537c7d380e9966f15e1b2a1 upstream.
Commit 2fc48021f4afdd109b9e52b6eef5db89ca80bac7 ("dm persistent
metadata: add space map threshold callback") introduced a regression
to the metadata block allocation path that resulted in errors being
ignored. This regression was uncovered by running the following
device-mapper-test-suite test:
dmtest run --suite thin-provisioning -n /exhausting_metadata_space_causes_fail_mode/
The ignored error codes in sm_metadata_new_block() could crash the
kernel through use of either the dm-thin or dm-cache targets, e.g.:
device-mapper: thin: 253:4: reached low water mark for metadata device: sending event.
device-mapper: space map metadata: unable to allocate new metadata block
general protection fault: 0000 [#1] SMP
...
Workqueue: dm-thin do_worker [dm_thin_pool]
task: ffff880035ce2ab0 ti: ffff88021a054000 task.ti: ffff88021a054000
RIP: 0010:[<ffffffffa0331385>] [<ffffffffa0331385>] metadata_ll_load_ie+0x15/0x30 [dm_persistent_data]
RSP: 0018:ffff88021a055a68 EFLAGS: 00010202
RAX: 003fc8243d212ba0 RBX: ffff88021a780070 RCX: ffff88021a055a78
RDX: ffff88021a055a78 RSI: 0040402222a92a80 RDI: ffff88021a780070
RBP: ffff88021a055a68 R08: ffff88021a055ba4 R09: 0000000000000010
R10: 0000000000000000 R11: 00000002a02e1000 R12: ffff88021a055ad4
R13: 0000000000000598 R14: ffffffffa0338470 R15: ffff88021a055ba4
FS: 0000000000000000(0000) GS:ffff88033fca0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007f467c0291b8 CR3: 0000000001a0b000 CR4: 00000000000007e0
Stack:
ffff88021a055ab8 ffffffffa0332020 ffff88021a055b30 0000000000000001
ffff88021a055b30 0000000000000000 ffff88021a055b18 0000000000000000
ffff88021a055ba4 ffff88021a055b98 ffff88021a055ae8 ffffffffa033304c
Call Trace:
[<ffffffffa0332020>] sm_ll_lookup_bitmap+0x40/0xa0 [dm_persistent_data]
[<ffffffffa033304c>] sm_metadata_count_is_more_than_one+0x8c/0xc0 [dm_persistent_data]
[<ffffffffa0333825>] dm_tm_shadow_block+0x65/0x110 [dm_persistent_data]
[<ffffffffa0331b00>] sm_ll_mutate+0x80/0x300 [dm_persistent_data]
[<ffffffffa0330e60>] ? set_ref_count+0x10/0x10 [dm_persistent_data]
[<ffffffffa0331dba>] sm_ll_inc+0x1a/0x20 [dm_persistent_data]
[<ffffffffa0332270>] sm_disk_new_block+0x60/0x80 [dm_persistent_data]
[<ffffffff81520036>] ? down_write+0x16/0x40
[<ffffffffa001e5c4>] dm_pool_alloc_data_block+0x54/0x80 [dm_thin_pool]
[<ffffffffa001b23c>] alloc_data_block+0x9c/0x130 [dm_thin_pool]
[<ffffffffa001c27e>] provision_block+0x4e/0x180 [dm_thin_pool]
[<ffffffffa001fe9a>] ? dm_thin_find_block+0x6a/0x110 [dm_thin_pool]
[<ffffffffa001c57a>] process_bio+0x1ca/0x1f0 [dm_thin_pool]
[<ffffffff8111e2ed>] ? mempool_free+0x8d/0xa0
[<ffffffffa001d755>] process_deferred_bios+0xc5/0x230 [dm_thin_pool]
[<ffffffffa001d911>] do_worker+0x51/0x60 [dm_thin_pool]
[<ffffffff81067872>] process_one_work+0x182/0x3b0
[<ffffffff81068c90>] worker_thread+0x120/0x3a0
[<ffffffff81068b70>] ? manage_workers+0x160/0x160
[<ffffffff8106eb2e>] kthread+0xce/0xe0
[<ffffffff8106ea60>] ? kthread_freezable_should_stop+0x70/0x70
[<ffffffff8152af6c>] ret_from_fork+0x7c/0xb0
[<ffffffff8106ea60>] ? kthread_freezable_should_stop+0x70/0x70
[<ffffffff8152af6c>] ret_from_fork+0x7c/0xb0
[<ffffffff8106ea60>] ? kthread_freezable_should_stop+0x70/0x70
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/persistent-data/dm-space-map-metadata.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/md/persistent-data/dm-space-map-metadata.c
+++ b/drivers/md/persistent-data/dm-space-map-metadata.c
@@ -384,12 +384,16 @@ static int sm_metadata_new_block(struct
struct sm_metadata *smm = container_of(sm, struct sm_metadata, sm);
int r = sm_metadata_new_block_(sm, b);
- if (r)
+ if (r) {
DMERR("unable to allocate new metadata block");
+ return r;
+ }
r = sm_metadata_get_nr_free(sm, &count);
- if (r)
+ if (r) {
DMERR("couldn't get free block count");
+ return r;
+ }
check_threshold(&smm->threshold, count);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 086/118] dm space map: disallow decrementing a reference count below zero
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (81 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 085/118] dm space map metadata: return on failure in sm_metadata_new_block Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 087/118] dm table: fail dm_table_create on dm_round_up overflow Greg Kroah-Hartman
` (33 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Joe Thornber, Mike Snitzer
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joe Thornber <ejt@redhat.com>
commit 5b564d80f8bc21094c0cd2b19b679d983aabcc29 upstream.
The old behaviour, returning -EINVAL if a ref_count of 0 would be
decremented, was removed in commit f722063 ("dm space map: optimise
sm_ll_dec and sm_ll_inc"). To fix this regression we return an error
code from the mutator function pointer passed to sm_ll_mutate() and have
dec_ref_count() return -EINVAL if the old ref_count is 0.
Add a DMERR to reflect the potential seriousness of this error.
Also, add missing dm_tm_unlock() to sm_ll_mutate()'s error path.
With this fix the following dmts regression test now passes:
dmtest run --suite cache -n /metadata_use_kernel/
The next patch fixes the higher-level dm-array code that exposed this
regression.
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/persistent-data/dm-space-map-common.c | 32 ++++++++++++++++-------
1 file changed, 23 insertions(+), 9 deletions(-)
--- a/drivers/md/persistent-data/dm-space-map-common.c
+++ b/drivers/md/persistent-data/dm-space-map-common.c
@@ -381,7 +381,7 @@ int sm_ll_find_free_block(struct ll_disk
}
static int sm_ll_mutate(struct ll_disk *ll, dm_block_t b,
- uint32_t (*mutator)(void *context, uint32_t old),
+ int (*mutator)(void *context, uint32_t old, uint32_t *new),
void *context, enum allocation_event *ev)
{
int r;
@@ -410,11 +410,17 @@ static int sm_ll_mutate(struct ll_disk *
if (old > 2) {
r = sm_ll_lookup_big_ref_count(ll, b, &old);
- if (r < 0)
+ if (r < 0) {
+ dm_tm_unlock(ll->tm, nb);
return r;
+ }
}
- ref_count = mutator(context, old);
+ r = mutator(context, old, &ref_count);
+ if (r) {
+ dm_tm_unlock(ll->tm, nb);
+ return r;
+ }
if (ref_count <= 2) {
sm_set_bitmap(bm_le, bit, ref_count);
@@ -465,9 +471,10 @@ static int sm_ll_mutate(struct ll_disk *
return ll->save_ie(ll, index, &ie_disk);
}
-static uint32_t set_ref_count(void *context, uint32_t old)
+static int set_ref_count(void *context, uint32_t old, uint32_t *new)
{
- return *((uint32_t *) context);
+ *new = *((uint32_t *) context);
+ return 0;
}
int sm_ll_insert(struct ll_disk *ll, dm_block_t b,
@@ -476,9 +483,10 @@ int sm_ll_insert(struct ll_disk *ll, dm_
return sm_ll_mutate(ll, b, set_ref_count, &ref_count, ev);
}
-static uint32_t inc_ref_count(void *context, uint32_t old)
+static int inc_ref_count(void *context, uint32_t old, uint32_t *new)
{
- return old + 1;
+ *new = old + 1;
+ return 0;
}
int sm_ll_inc(struct ll_disk *ll, dm_block_t b, enum allocation_event *ev)
@@ -486,9 +494,15 @@ int sm_ll_inc(struct ll_disk *ll, dm_blo
return sm_ll_mutate(ll, b, inc_ref_count, NULL, ev);
}
-static uint32_t dec_ref_count(void *context, uint32_t old)
+static int dec_ref_count(void *context, uint32_t old, uint32_t *new)
{
- return old - 1;
+ if (!old) {
+ DMERR_LIMIT("unable to decrement a reference count below 0");
+ return -EINVAL;
+ }
+
+ *new = old - 1;
+ return 0;
}
int sm_ll_dec(struct ll_disk *ll, dm_block_t b, enum allocation_event *ev)
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 087/118] dm table: fail dm_table_create on dm_round_up overflow
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (82 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 086/118] dm space map: disallow decrementing a reference count below zero Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 088/118] dm thin: switch to read only mode if a mapping insert fails Greg Kroah-Hartman
` (32 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mikulas Patocka, Mike Snitzer
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikulas Patocka <mpatocka@redhat.com>
commit 5b2d06576c5410c10d95adfd5c4d8b24de861d87 upstream.
The dm_round_up function may overflow to zero. In this case,
dm_table_create() must fail rather than go on to allocate an empty array
with alloc_targets().
This fixes a possible memory corruption that could be caused by passing
too large a number in "param->target_count".
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-table.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -200,6 +200,11 @@ int dm_table_create(struct dm_table **re
num_targets = dm_round_up(num_targets, KEYS_PER_NODE);
+ if (!num_targets) {
+ kfree(t);
+ return -ENOMEM;
+ }
+
if (alloc_targets(t, num_targets)) {
kfree(t);
return -ENOMEM;
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 088/118] dm thin: switch to read only mode if a mapping insert fails
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (83 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 087/118] dm table: fail dm_table_create on dm_round_up overflow Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 089/118] dm thin: switch to read-only mode if metadata space is exhausted Greg Kroah-Hartman
` (31 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Joe Thornber, Mike Snitzer
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joe Thornber <ejt@redhat.com>
commit fafc7a815e40255d24e80a1cb7365892362fa398 upstream.
Switch the thin pool to read-only mode when dm_thin_insert_block() fails
since there is little reason to expect the cause of the failure to be
resolved without further action by user space.
This issue was noticed with the device-mapper-test-suite using:
dmtest run --suite thin-provisioning -n /exhausting_metadata_space_causes_fail_mode/
The quantity of errors logged in this case must be reduced.
before patch:
device-mapper: thin: dm_thin_insert_block() failed
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: thin: dm_thin_insert_block() failed
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: thin: dm_thin_insert_block() failed
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: thin: dm_thin_insert_block() failed
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: thin: dm_thin_insert_block() failed
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: thin: dm_thin_insert_block() failed
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: thin: dm_thin_insert_block() failed
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: thin: dm_thin_insert_block() failed
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: thin: dm_thin_insert_block() failed
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: thin: dm_thin_insert_block() failed
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: space map metadata: unable to allocate new metadata block
<snip ... these repeat for a long while ... >
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: space map common: dm_tm_shadow_block() failed
device-mapper: thin: 253:4: no free metadata space available.
device-mapper: thin: 253:4: switching pool to read-only mode
after patch:
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: thin: 253:4: dm_thin_insert_block() failed: error = -28
device-mapper: thin: 253:4: switching pool to read-only mode
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-thin.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/md/dm-thin.c
+++ b/drivers/md/dm-thin.c
@@ -640,7 +640,9 @@ static void process_prepared_mapping(str
*/
r = dm_thin_insert_block(tc->td, m->virt_block, m->data_block);
if (r) {
- DMERR_LIMIT("dm_thin_insert_block() failed");
+ DMERR_LIMIT("%s: dm_thin_insert_block() failed: error = %d",
+ dm_device_name(pool->pool_md), r);
+ set_pool_mode(pool, PM_READ_ONLY);
cell_error(pool, m->cell);
goto out;
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 089/118] dm thin: switch to read-only mode if metadata space is exhausted
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (84 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 088/118] dm thin: switch to read only mode if a mapping insert fails Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 090/118] dm thin: always fallback the pool mode if commit fails Greg Kroah-Hartman
` (30 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mike Snitzer, Joe Thornber
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mike Snitzer <snitzer@redhat.com>
commit 4a02b34e0cf1d0d0dd3737702841da4bf615a50a upstream.
Switch the thin pool to read-only mode in alloc_data_block() if
dm_pool_alloc_data_block() fails because the pool's metadata space is
exhausted.
Differentiate between data and metadata space in messages about no
free space available.
This issue was noticed with the device-mapper-test-suite using:
dmtest run --suite thin-provisioning -n /exhausting_metadata_space_causes_fail_mode/
The quantity of errors logged in this case must be reduced.
before patch:
device-mapper: thin: 253:4: reached low water mark for metadata device: sending event.
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: space map common: dm_tm_shadow_block() failed
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: space map common: dm_tm_shadow_block() failed
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: space map common: dm_tm_shadow_block() failed
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: space map common: dm_tm_shadow_block() failed
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: space map common: dm_tm_shadow_block() failed
<snip ... these repeat for a _very_ long while ... >
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: thin: 253:4: commit failed: error = -28
device-mapper: thin: 253:4: switching pool to read-only mode
after patch:
device-mapper: thin: 253:4: reached low water mark for metadata device: sending event.
device-mapper: space map metadata: unable to allocate new metadata block
device-mapper: thin: 253:4: no free metadata space available.
device-mapper: thin: 253:4: switching pool to read-only mode
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-thin.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
--- a/drivers/md/dm-thin.c
+++ b/drivers/md/dm-thin.c
@@ -959,7 +959,7 @@ static int alloc_data_block(struct thin_
* table reload).
*/
if (!free_blocks) {
- DMWARN("%s: no free space available.",
+ DMWARN("%s: no free data space available.",
dm_device_name(pool->pool_md));
spin_lock_irqsave(&pool->lock, flags);
pool->no_free_space = 1;
@@ -969,8 +969,16 @@ static int alloc_data_block(struct thin_
}
r = dm_pool_alloc_data_block(pool->pmd, result);
- if (r)
+ if (r) {
+ if (r == -ENOSPC &&
+ !dm_pool_get_free_metadata_block_count(pool->pmd, &free_blocks) &&
+ !free_blocks) {
+ DMWARN("%s: no free metadata space available.",
+ dm_device_name(pool->pool_md));
+ set_pool_mode(pool, PM_READ_ONLY);
+ }
return r;
+ }
return 0;
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 090/118] dm thin: always fallback the pool mode if commit fails
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (85 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 089/118] dm thin: switch to read-only mode if metadata space is exhausted Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 091/118] dm thin: re-establish read-only state when switching to fail mode Greg Kroah-Hartman
` (29 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Joe Thornber, Mike Snitzer
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joe Thornber <ejt@redhat.com>
commit 020cc3b5e28c2e24f59f53a9154faf08564f308e upstream.
Rename commit_or_fallback() to commit(). Now all previous calls to
commit() will trigger the pool mode to fallback if the commit fails.
Also, check the error returned from commit() in alloc_data_block().
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-thin.c | 37 +++++++++++++++----------------------
1 file changed, 15 insertions(+), 22 deletions(-)
--- a/drivers/md/dm-thin.c
+++ b/drivers/md/dm-thin.c
@@ -883,32 +883,23 @@ static void schedule_zero(struct thin_c
}
}
-static int commit(struct pool *pool)
-{
- int r;
-
- r = dm_pool_commit_metadata(pool->pmd);
- if (r)
- DMERR_LIMIT("%s: commit failed: error = %d",
- dm_device_name(pool->pool_md), r);
-
- return r;
-}
-
/*
* A non-zero return indicates read_only or fail_io mode.
* Many callers don't care about the return value.
*/
-static int commit_or_fallback(struct pool *pool)
+static int commit(struct pool *pool)
{
int r;
if (get_pool_mode(pool) != PM_WRITE)
return -EINVAL;
- r = commit(pool);
- if (r)
+ r = dm_pool_commit_metadata(pool->pmd);
+ if (r) {
+ DMERR_LIMIT("%s: dm_pool_commit_metadata failed: error = %d",
+ dm_device_name(pool->pool_md), r);
set_pool_mode(pool, PM_READ_ONLY);
+ }
return r;
}
@@ -945,7 +936,9 @@ static int alloc_data_block(struct thin_
* Try to commit to see if that will free up some
* more space.
*/
- (void) commit_or_fallback(pool);
+ r = commit(pool);
+ if (r)
+ return r;
r = dm_pool_get_free_block_count(pool->pmd, &free_blocks);
if (r)
@@ -1359,7 +1352,7 @@ static void process_deferred_bios(struct
if (bio_list_empty(&bios) && !need_commit_due_to_time(pool))
return;
- if (commit_or_fallback(pool)) {
+ if (commit(pool)) {
while ((bio = bio_list_pop(&bios)))
bio_io_error(bio);
return;
@@ -2276,7 +2269,7 @@ static int pool_preresume(struct dm_targ
return r;
if (need_commit1 || need_commit2)
- (void) commit_or_fallback(pool);
+ (void) commit(pool);
return 0;
}
@@ -2303,7 +2296,7 @@ static void pool_postsuspend(struct dm_t
cancel_delayed_work(&pool->waker);
flush_workqueue(pool->wq);
- (void) commit_or_fallback(pool);
+ (void) commit(pool);
}
static int check_arg_count(unsigned argc, unsigned args_required)
@@ -2437,7 +2430,7 @@ static int process_reserve_metadata_snap
if (r)
return r;
- (void) commit_or_fallback(pool);
+ (void) commit(pool);
r = dm_pool_reserve_metadata_snap(pool->pmd);
if (r)
@@ -2499,7 +2492,7 @@ static int pool_message(struct dm_target
DMWARN("Unrecognised thin pool target message received: %s", argv[0]);
if (!r)
- (void) commit_or_fallback(pool);
+ (void) commit(pool);
return r;
}
@@ -2554,7 +2547,7 @@ static void pool_status(struct dm_target
/* Commit to ensure statistics aren't out-of-date */
if (!(status_flags & DM_STATUS_NOFLUSH_FLAG) && !dm_suspended(ti))
- (void) commit_or_fallback(pool);
+ (void) commit(pool);
r = dm_pool_get_metadata_transaction_id(pool->pmd, &transaction_id);
if (r) {
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 091/118] dm thin: re-establish read-only state when switching to fail mode
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (86 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 090/118] dm thin: always fallback the pool mode if commit fails Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 092/118] dm thin: allow pool in read-only mode to transition to read-write mode Greg Kroah-Hartman
` (28 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Joe Thornber, Mike Snitzer
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joe Thornber <ejt@redhat.com>
commit 5383ef3a929a1366e2ced45cd6d74be7aa2a2281 upstream.
If the thin-pool transitioned to fail mode and the thin-pool's table
were reloaded for some reason: the new table's default pool mode would
be read-write, though it will transition to fail mode during resume.
When the pool mode transitions directly from PM_WRITE to PM_FAIL we need
to re-establish the intermediate read-only state in both the metadata
and persistent-data block manager (as is usually done with the normal
pool mode transition sequence: PM_WRITE -> PM_READ_ONLY -> PM_FAIL).
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-thin.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/md/dm-thin.c
+++ b/drivers/md/dm-thin.c
@@ -1400,6 +1400,7 @@ static void set_pool_mode(struct pool *p
case PM_FAIL:
DMERR("%s: switching pool to failure mode",
dm_device_name(pool->pool_md));
+ dm_pool_metadata_read_only(pool->pmd);
pool->process_bio = process_bio_fail;
pool->process_discard = process_bio_fail;
pool->process_prepared_mapping = process_prepared_mapping_fail;
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 092/118] dm thin: allow pool in read-only mode to transition to read-write mode
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (87 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 091/118] dm thin: re-establish read-only state when switching to fail mode Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 093/118] vfs: split out vfs_getattr_nosec Greg Kroah-Hartman
` (27 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Joe Thornber, Mike Snitzer
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joe Thornber <ejt@redhat.com>
commit 9b7aaa64f96f7ca280d75326fca42f42017b89ef upstream.
A thin-pool may be in read-only mode because the pool's data or metadata
space was exhausted. To allow for recovery, by adding more space to the
pool, we must allow a pool to transition from PM_READ_ONLY to PM_WRITE
mode. Otherwise, running out of space will render the pool permanently
read-only.
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-thin-metadata.c | 8 ++++++++
drivers/md/dm-thin-metadata.h | 1 +
drivers/md/dm-thin.c | 12 ++++++++++--
drivers/md/persistent-data/dm-block-manager.c | 6 ++++++
drivers/md/persistent-data/dm-block-manager.h | 7 ++++---
5 files changed, 29 insertions(+), 5 deletions(-)
--- a/drivers/md/dm-thin-metadata.c
+++ b/drivers/md/dm-thin-metadata.c
@@ -1697,6 +1697,14 @@ void dm_pool_metadata_read_only(struct d
up_write(&pmd->root_lock);
}
+void dm_pool_metadata_read_write(struct dm_pool_metadata *pmd)
+{
+ down_write(&pmd->root_lock);
+ pmd->read_only = false;
+ dm_bm_set_read_write(pmd->bm);
+ up_write(&pmd->root_lock);
+}
+
int dm_pool_register_metadata_threshold(struct dm_pool_metadata *pmd,
dm_block_t threshold,
dm_sm_threshold_fn fn,
--- a/drivers/md/dm-thin-metadata.h
+++ b/drivers/md/dm-thin-metadata.h
@@ -193,6 +193,7 @@ int dm_pool_resize_metadata_dev(struct d
* that nothing is changing.
*/
void dm_pool_metadata_read_only(struct dm_pool_metadata *pmd);
+void dm_pool_metadata_read_write(struct dm_pool_metadata *pmd);
int dm_pool_register_metadata_threshold(struct dm_pool_metadata *pmd,
dm_block_t threshold,
--- a/drivers/md/dm-thin.c
+++ b/drivers/md/dm-thin.c
@@ -1425,6 +1425,7 @@ static void set_pool_mode(struct pool *p
break;
case PM_WRITE:
+ dm_pool_metadata_read_write(pool->pmd);
pool->process_bio = process_bio;
pool->process_discard = process_discard;
pool->process_prepared_mapping = process_prepared_mapping;
@@ -1641,12 +1642,19 @@ static int bind_control_target(struct po
struct pool_c *pt = ti->private;
/*
- * We want to make sure that degraded pools are never upgraded.
+ * We want to make sure that a pool in PM_FAIL mode is never upgraded.
*/
enum pool_mode old_mode = pool->pf.mode;
enum pool_mode new_mode = pt->adjusted_pf.mode;
- if (old_mode > new_mode)
+ /*
+ * If we were in PM_FAIL mode, rollback of metadata failed. We're
+ * not going to recover without a thin_repair. So we never let the
+ * pool move out of the old mode. On the other hand a PM_READ_ONLY
+ * may have been due to a lack of metadata or data space, and may
+ * now work (ie. if the underlying devices have been resized).
+ */
+ if (old_mode == PM_FAIL)
new_mode = old_mode;
pool->ti = ti;
--- a/drivers/md/persistent-data/dm-block-manager.c
+++ b/drivers/md/persistent-data/dm-block-manager.c
@@ -626,6 +626,12 @@ void dm_bm_set_read_only(struct dm_block
}
EXPORT_SYMBOL_GPL(dm_bm_set_read_only);
+void dm_bm_set_read_write(struct dm_block_manager *bm)
+{
+ bm->read_only = false;
+}
+EXPORT_SYMBOL_GPL(dm_bm_set_read_write);
+
u32 dm_bm_checksum(const void *data, size_t len, u32 init_xor)
{
return crc32c(~(u32) 0, data, len) ^ init_xor;
--- a/drivers/md/persistent-data/dm-block-manager.h
+++ b/drivers/md/persistent-data/dm-block-manager.h
@@ -108,9 +108,9 @@ int dm_bm_unlock(struct dm_block *b);
int dm_bm_flush_and_unlock(struct dm_block_manager *bm,
struct dm_block *superblock);
- /*
- * Request data be prefetched into the cache.
- */
+/*
+ * Request data is prefetched into the cache.
+ */
void dm_bm_prefetch(struct dm_block_manager *bm, dm_block_t b);
/*
@@ -125,6 +125,7 @@ void dm_bm_prefetch(struct dm_block_mana
* be returned if you do.
*/
void dm_bm_set_read_only(struct dm_block_manager *bm);
+void dm_bm_set_read_write(struct dm_block_manager *bm);
u32 dm_bm_checksum(const void *data, size_t len, u32 init_xor);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 093/118] vfs: split out vfs_getattr_nosec
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (88 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 092/118] dm thin: allow pool in read-only mode to transition to read-write mode Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 094/118] exportfs: fix 32-bit nfsd handling of 64-bit inode numbers Greg Kroah-Hartman
` (26 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christoph Hellwig, J. Bruce Fields, Al Viro
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: "J. Bruce Fields" <bfields@redhat.com>
commit b7a6ec52dd4eced4a9bcda9ca85b3c8af84d3c90 upstream.
The filehandle lookup code wants this version of getattr.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/stat.c | 31 +++++++++++++++++++++++++------
include/linux/fs.h | 1 +
2 files changed, 26 insertions(+), 6 deletions(-)
--- a/fs/stat.c
+++ b/fs/stat.c
@@ -37,14 +37,21 @@ void generic_fillattr(struct inode *inod
EXPORT_SYMBOL(generic_fillattr);
-int vfs_getattr(struct path *path, struct kstat *stat)
+/**
+ * vfs_getattr_nosec - getattr without security checks
+ * @path: file to get attributes from
+ * @stat: structure to return attributes in
+ *
+ * Get attributes without calling security_inode_getattr.
+ *
+ * Currently the only caller other than vfs_getattr is internal to the
+ * filehandle lookup code, which uses only the inode number and returns
+ * no attributes to any user. Any other code probably wants
+ * vfs_getattr.
+ */
+int vfs_getattr_nosec(struct path *path, struct kstat *stat)
{
struct inode *inode = path->dentry->d_inode;
- int retval;
-
- retval = security_inode_getattr(path->mnt, path->dentry);
- if (retval)
- return retval;
if (inode->i_op->getattr)
return inode->i_op->getattr(path->mnt, path->dentry, stat);
@@ -53,6 +60,18 @@ int vfs_getattr(struct path *path, struc
return 0;
}
+EXPORT_SYMBOL(vfs_getattr_nosec);
+
+int vfs_getattr(struct path *path, struct kstat *stat)
+{
+ int retval;
+
+ retval = security_inode_getattr(path->mnt, path->dentry);
+ if (retval)
+ return retval;
+ return vfs_getattr_nosec(path, stat);
+}
+
EXPORT_SYMBOL(vfs_getattr);
int vfs_fstat(unsigned int fd, struct kstat *stat)
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2504,6 +2504,7 @@ extern int page_symlink(struct inode *in
extern const struct inode_operations page_symlink_inode_operations;
extern int generic_readlink(struct dentry *, char __user *, int);
extern void generic_fillattr(struct inode *, struct kstat *);
+int vfs_getattr_nosec(struct path *path, struct kstat *stat);
extern int vfs_getattr(struct path *, struct kstat *);
void __inode_add_bytes(struct inode *inode, loff_t bytes);
void inode_add_bytes(struct inode *inode, loff_t bytes);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 094/118] exportfs: fix 32-bit nfsd handling of 64-bit inode numbers
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (89 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 093/118] vfs: split out vfs_getattr_nosec Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 095/118] HID: kye: Add report fixup for Genius Manticore Keyboard Greg Kroah-Hartman
` (25 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christoph Hellwig, Trevor Cordes,
J. Bruce Fields, Al Viro
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: "J. Bruce Fields" <bfields@redhat.com>
commit 950ee9566a5b6cc45d15f5fe044bab4f1e8b62cb upstream.
Symptoms were spurious -ENOENTs on stat of an NFS filesystem from a
32-bit NFS server exporting a very large XFS filesystem, when the
server's cache is cold (so the inodes in question are not in cache).
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reported-by: Trevor Cordes <trevor@tecnopolis.ca>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/exportfs/expfs.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
--- a/fs/exportfs/expfs.c
+++ b/fs/exportfs/expfs.c
@@ -215,7 +215,7 @@ struct getdents_callback {
struct dir_context ctx;
char *name; /* name that was found. It already points to a
buffer NAME_MAX+1 is size */
- unsigned long ino; /* the inum we are looking for */
+ u64 ino; /* the inum we are looking for */
int found; /* inode matched? */
int sequence; /* sequence counter */
};
@@ -255,10 +255,14 @@ static int get_name(const struct path *p
struct inode *dir = path->dentry->d_inode;
int error;
struct file *file;
+ struct kstat stat;
+ struct path child_path = {
+ .mnt = path->mnt,
+ .dentry = child,
+ };
struct getdents_callback buffer = {
.ctx.actor = filldir_one,
.name = name,
- .ino = child->d_inode->i_ino
};
error = -ENOTDIR;
@@ -268,6 +272,16 @@ static int get_name(const struct path *p
if (!dir->i_fop)
goto out;
/*
+ * inode->i_ino is unsigned long, kstat->ino is u64, so the
+ * former would be insufficient on 32-bit hosts when the
+ * filesystem supports 64-bit inode numbers. So we need to
+ * actually call ->getattr, not just read i_ino:
+ */
+ error = vfs_getattr_nosec(&child_path, &stat);
+ if (error)
+ return error;
+ buffer.ino = stat.ino;
+ /*
* Open the directory ...
*/
file = dentry_open(path, O_RDONLY, cred);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 095/118] HID: kye: Add report fixup for Genius Manticore Keyboard
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (90 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 094/118] exportfs: fix 32-bit nfsd handling of 64-bit inode numbers Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 096/118] HID: kye: Fix missing break in kye_report_fixup() Greg Kroah-Hartman
` (24 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Benjamin Tissoires, Jiri Kosina
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
commit 4a2c94c9b6c03af61b04993340bd9559e2277de4 upstream.
Genius Manticore Keyboard presents the same problem in its report
descriptors than Genius Gila Gaming Mouse and Genius Imperator Keyboard.
Use the same fixup.
Reported-and-tested-by: Adam Kulagowski <fidor@fidor.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-kye.c | 5 +++++
3 files changed, 7 insertions(+)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1725,6 +1725,7 @@ static const struct hid_device_id hid_ha
{ HID_USB_DEVICE(USB_VENDOR_ID_KENSINGTON, USB_DEVICE_ID_KS_SLIMBLADE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KEYTOUCH, USB_DEVICE_ID_KEYTOUCH_IEC) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_GENIUS_GILA_GAMING_MOUSE) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_GENIUS_MANTICORE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_GENIUS_GX_IMPERATOR) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_ERGO_525V) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_EASYPEN_I405X) },
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -489,6 +489,7 @@
#define USB_VENDOR_ID_KYE 0x0458
#define USB_DEVICE_ID_KYE_ERGO_525V 0x0087
#define USB_DEVICE_ID_GENIUS_GILA_GAMING_MOUSE 0x0138
+#define USB_DEVICE_ID_GENIUS_MANTICORE 0x0153
#define USB_DEVICE_ID_GENIUS_GX_IMPERATOR 0x4018
#define USB_DEVICE_ID_KYE_GPEN_560 0x5003
#define USB_DEVICE_ID_KYE_EASYPEN_I405X 0x5010
--- a/drivers/hid/hid-kye.c
+++ b/drivers/hid/hid-kye.c
@@ -341,6 +341,9 @@ static __u8 *kye_report_fixup(struct hid
case USB_DEVICE_ID_GENIUS_GX_IMPERATOR:
rdesc = kye_consumer_control_fixup(hdev, rdesc, rsize, 83,
"Genius Gx Imperator Keyboard");
+ case USB_DEVICE_ID_GENIUS_MANTICORE:
+ rdesc = kye_consumer_control_fixup(hdev, rdesc, rsize, 104,
+ "Genius Manticore Keyboard");
break;
}
return rdesc;
@@ -439,6 +442,8 @@ static const struct hid_device_id kye_de
USB_DEVICE_ID_GENIUS_GILA_GAMING_MOUSE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE,
USB_DEVICE_ID_GENIUS_GX_IMPERATOR) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_KYE,
+ USB_DEVICE_ID_GENIUS_MANTICORE) },
{ }
};
MODULE_DEVICE_TABLE(hid, kye_devices);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 096/118] HID: kye: Fix missing break in kye_report_fixup()
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (91 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 095/118] HID: kye: Add report fixup for Genius Manticore Keyboard Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 098/118] [media] cxd2820r_core: fix sparse warnings Greg Kroah-Hartman
` (23 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ben Hutchings, Jiri Kosina
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Hutchings <ben@decadent.org.uk>
commit 0a5f99cfff2297f6c350b7f54878cbbf1b1253d5 upstream.
The change to support Genius Manticore Keyboard also changed behaviour
for Genius Gx Imperator Keyboard, as there is no break between the
cases. This is presumably a mistake.
Reported by Coverity as CID 1134029.
Fixes: 4a2c94c9b6c0 ('HID: kye: Add report fixup for Genius Manticore Keyboard')
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-kye.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/hid/hid-kye.c
+++ b/drivers/hid/hid-kye.c
@@ -341,6 +341,7 @@ static __u8 *kye_report_fixup(struct hid
case USB_DEVICE_ID_GENIUS_GX_IMPERATOR:
rdesc = kye_consumer_control_fixup(hdev, rdesc, rsize, 83,
"Genius Gx Imperator Keyboard");
+ break;
case USB_DEVICE_ID_GENIUS_MANTICORE:
rdesc = kye_consumer_control_fixup(hdev, rdesc, rsize, 104,
"Genius Manticore Keyboard");
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 098/118] [media] cxd2820r_core: fix sparse warnings
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (92 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 096/118] HID: kye: Fix missing break in kye_report_fixup() Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 099/118] sched: Avoid throttle_cfs_rq() racing with period_timer stopping Greg Kroah-Hartman
` (22 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hans Verkuil, Antti Palosaari,
Michael Krufky, Mauro Carvalho Chehab, Frederik Himpe
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans Verkuil <hans.verkuil@cisco.com>
commit 0db3fa2741ad8371c21b3a6785416a4afc0cc1d4 upstream.
drivers/media/dvb-frontends/cxd2820r_core.c:34:32: error: cannot size expression
drivers/media/dvb-frontends/cxd2820r_core.c:68:32: error: cannot size expression
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Antti Palosaari <crope@iki.fi>
Reviewed-by: Antti Palosaari <crope@iki.fi>
Reviewed-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Frederik Himpe <fhimpe@telenet.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/dvb-frontends/cxd2820r_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/media/dvb-frontends/cxd2820r_core.c
+++ b/drivers/media/dvb-frontends/cxd2820r_core.c
@@ -34,7 +34,7 @@ static int cxd2820r_wr_regs_i2c(struct c
{
.addr = i2c,
.flags = 0,
- .len = sizeof(buf),
+ .len = len + 1,
.buf = buf,
}
};
@@ -75,7 +75,7 @@ static int cxd2820r_rd_regs_i2c(struct c
}, {
.addr = i2c,
.flags = I2C_M_RD,
- .len = sizeof(buf),
+ .len = len,
.buf = buf,
}
};
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 099/118] sched: Avoid throttle_cfs_rq() racing with period_timer stopping
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (93 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 098/118] [media] cxd2820r_core: fix sparse warnings Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 100/118] staging: comedi: drivers: use comedi_dio_update_state() for simple cases Greg Kroah-Hartman
` (21 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ben Segall, Peter Zijlstra, pjt,
Ingo Molnar, Chris J Arges
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Segall <bsegall@google.com>
commit f9f9ffc237dd924f048204e8799da74f9ecf40cf upstream.
throttle_cfs_rq() doesn't check to make sure that period_timer is running,
and while update_curr/assign_cfs_runtime does, a concurrently running
period_timer on another cpu could cancel itself between this cpu's
update_curr and throttle_cfs_rq(). If there are no other cfs_rqs running
in the tg to restart the timer, this causes the cfs_rq to be stranded
forever.
Fix this by calling __start_cfs_bandwidth() in throttle if the timer is
inactive.
(Also add some sched_debug lines for cfs_bandwidth.)
Tested: make a run/sleep task in a cgroup, loop switching the cgroup
between 1ms/100ms quota and unlimited, checking for timer_active=0 and
throttled=1 as a failure. With the throttle_cfs_rq() change commented out
this fails, with the full patch it passes.
Signed-off-by: Ben Segall <bsegall@google.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: pjt@google.com
Link: http://lkml.kernel.org/r/20131016181632.22647.84174.stgit@sword-of-the-dawn.mtv.corp.google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Chris J Arges <chris.j.arges@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/sched/debug.c | 8 ++++++++
kernel/sched/fair.c | 2 ++
2 files changed, 10 insertions(+)
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -225,6 +225,14 @@ void print_cfs_rq(struct seq_file *m, in
atomic_read(&cfs_rq->tg->runnable_avg));
#endif
#endif
+#ifdef CONFIG_CFS_BANDWIDTH
+ SEQ_printf(m, " .%-30s: %d\n", "tg->cfs_bandwidth.timer_active",
+ cfs_rq->tg->cfs_bandwidth.timer_active);
+ SEQ_printf(m, " .%-30s: %d\n", "throttled",
+ cfs_rq->throttled);
+ SEQ_printf(m, " .%-30s: %d\n", "throttle_count",
+ cfs_rq->throttle_count);
+#endif
#ifdef CONFIG_FAIR_GROUP_SCHED
print_cfs_group_stats(m, cpu, cfs_rq->tg);
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2335,6 +2335,8 @@ static void throttle_cfs_rq(struct cfs_r
cfs_rq->throttled_clock = rq_clock(rq);
raw_spin_lock(&cfs_b->lock);
list_add_tail_rcu(&cfs_rq->throttled_list, &cfs_b->throttled_cfs_rq);
+ if (!cfs_b->timer_active)
+ __start_cfs_bandwidth(cfs_b);
raw_spin_unlock(&cfs_b->lock);
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 100/118] staging: comedi: drivers: use comedi_dio_update_state() for simple cases
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (94 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 099/118] sched: Avoid throttle_cfs_rq() racing with period_timer stopping Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 101/118] staging: comedi: ssv_dnp: use comedi_dio_update_state() Greg Kroah-Hartman
` (20 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, H Hartley Sweeten, Ian Abbott
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: H Hartley Sweeten <hsweeten@visionengravers.com>
commit 97f4289ad08cffe55de06d4ac4f89ac540450aee upstream.
[Split from original patch subject: "staging: comedi: drivers: use
comedi_dio_update_state() for simple cases"]
Use comedi_dio_update_state() to handle the boilerplate code to update
the subdevice s->state for simple cases where the hardware is updated
when any channel is modified.
Also, fix a bug in the amplc_pc263 and amplc_pci263 drivers where the
current state is not returned in data[1].
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/comedi/drivers/amplc_pc263.c | 3 +++
drivers/staging/comedi/drivers/amplc_pci263.c | 3 +++
2 files changed, 6 insertions(+)
--- a/drivers/staging/comedi/drivers/amplc_pc263.c
+++ b/drivers/staging/comedi/drivers/amplc_pc263.c
@@ -68,6 +68,9 @@ static int pc263_do_insn_bits(struct com
outb(s->state & 0xFF, dev->iobase);
outb(s->state >> 8, dev->iobase + 1);
}
+
+ data[1] = s->state;
+
return insn->n;
}
--- a/drivers/staging/comedi/drivers/amplc_pci263.c
+++ b/drivers/staging/comedi/drivers/amplc_pci263.c
@@ -55,6 +55,9 @@ static int pci263_do_insn_bits(struct co
outb(s->state & 0xFF, dev->iobase);
outb(s->state >> 8, dev->iobase + 1);
}
+
+ data[1] = s->state;
+
return insn->n;
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 101/118] staging: comedi: ssv_dnp: use comedi_dio_update_state()
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (95 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 100/118] staging: comedi: drivers: use comedi_dio_update_state() for simple cases Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 102/118] sc1200_wdt: Fix oops Greg Kroah-Hartman
` (19 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, H Hartley Sweeten, Ian Abbott
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: H Hartley Sweeten <hsweeten@visionengravers.com>
commit f6b316bcd8c421acd6fa5a6e18b4c846ecb9d965 upstream.
Use comedi_dio_update_state() to handle the boilerplate code to update
the subdevice s->state.
Also, fix a bug where the state of the channels is returned in data[0].
The comedi core expects it to be returned in data[1].
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/comedi/drivers/ssv_dnp.c | 48 ++++++++++++-------------------
1 file changed, 20 insertions(+), 28 deletions(-)
--- a/drivers/staging/comedi/drivers/ssv_dnp.c
+++ b/drivers/staging/comedi/drivers/ssv_dnp.c
@@ -46,51 +46,43 @@ Status: unknown
#define PCMR 0xa3 /* Port C Mode Register */
#define PCDR 0xa7 /* Port C Data Register */
-/* ------------------------------------------------------------------------- */
-/* The insn_bits interface allows packed reading/writing of DIO channels. */
-/* The comedi core can convert between insn_bits and insn_read/write, so you */
-/* are able to use these instructions as well. */
-/* ------------------------------------------------------------------------- */
-
static int dnp_dio_insn_bits(struct comedi_device *dev,
struct comedi_subdevice *s,
- struct comedi_insn *insn, unsigned int *data)
+ struct comedi_insn *insn,
+ unsigned int *data)
{
- /* The insn data is a mask in data[0] and the new data in data[1], */
- /* each channel cooresponding to a bit. */
-
- /* Ports A and B are straight forward: each bit corresponds to an */
- /* output pin with the same order. Port C is different: bits 0...3 */
- /* correspond to bits 4...7 of the output register (PCDR). */
+ unsigned int mask;
+ unsigned int val;
- if (data[0]) {
+ /*
+ * Ports A and B are straight forward: each bit corresponds to an
+ * output pin with the same order. Port C is different: bits 0...3
+ * correspond to bits 4...7 of the output register (PCDR).
+ */
+ mask = comedi_dio_update_state(s, data);
+ if (mask) {
outb(PADR, CSCIR);
- outb((inb(CSCDR)
- & ~(u8) (data[0] & 0x0000FF))
- | (u8) (data[1] & 0x0000FF), CSCDR);
+ outb(s->state & 0xff, CSCDR);
outb(PBDR, CSCIR);
- outb((inb(CSCDR)
- & ~(u8) ((data[0] & 0x00FF00) >> 8))
- | (u8) ((data[1] & 0x00FF00) >> 8), CSCDR);
+ outb((s->state >> 8) & 0xff, CSCDR);
outb(PCDR, CSCIR);
- outb((inb(CSCDR)
- & ~(u8) ((data[0] & 0x0F0000) >> 12))
- | (u8) ((data[1] & 0x0F0000) >> 12), CSCDR);
+ val = inb(CSCDR) & 0x0f;
+ outb(((s->state >> 12) & 0xf0) | val, CSCDR);
}
- /* on return, data[1] contains the value of the digital input lines. */
outb(PADR, CSCIR);
- data[0] = inb(CSCDR);
+ val = inb(CSCDR);
outb(PBDR, CSCIR);
- data[0] += inb(CSCDR) << 8;
+ val |= (inb(CSCDR) << 8);
outb(PCDR, CSCIR);
- data[0] += ((inb(CSCDR) & 0xF0) << 12);
+ val |= ((inb(CSCDR) & 0xf0) << 12);
- return insn->n;
+ data[1] = val;
+ return insn->n;
}
static int dnp_dio_insn_config(struct comedi_device *dev,
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 102/118] sc1200_wdt: Fix oops
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (96 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 101/118] staging: comedi: ssv_dnp: use comedi_dio_update_state() Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 103/118] NFSv4 wait on recovery for async session errors Greg Kroah-Hartman
` (18 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alan Cox, Guenter Roeck, Wim Van Sebroeck
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan <gnomes@lxorguk.ukuu.org.uk>
commit dace8bbfccfd9e4fcccfffcfbd82881fda3e756f upstream.
If loaded with isapnp = 0 the driver explodes. This is catching
people out now and then. What should happen in the working case is
a complete mystery and the code appears terminally confused, but we
can at least make the error path work properly.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Partially-Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=53991
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/watchdog/sc1200wdt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/watchdog/sc1200wdt.c
+++ b/drivers/watchdog/sc1200wdt.c
@@ -409,8 +409,9 @@ static int __init sc1200wdt_init(void)
#if defined CONFIG_PNP
/* now that the user has specified an IO port and we haven't detected
* any devices, disable pnp support */
+ if (isapnp)
+ pnp_unregister_driver(&scl200wdt_pnp_driver);
isapnp = 0;
- pnp_unregister_driver(&scl200wdt_pnp_driver);
#endif
if (!request_region(io, io_len, SC1200_MODULE_NAME)) {
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 103/118] NFSv4 wait on recovery for async session errors
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (97 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 102/118] sc1200_wdt: Fix oops Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 104/118] Input: elantech - add support for newer (August 2013) devices Greg Kroah-Hartman
` (17 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Andy Adamson, Trond Myklebust
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Adamson <andros@netapp.com>
commit 4a82fd7c4e78a1b7a224f9ae8bb7e1fd95f670e0 upstream.
When the state manager is processing the NFS4CLNT_DELEGRETURN flag, session
draining is off, but DELEGRETURN can still get a session error.
The async handler calls nfs4_schedule_session_recovery returns -EAGAIN, and
the DELEGRETURN done then restarts the RPC task in the prepare state.
With the state manager still processing the NFS4CLNT_DELEGRETURN flag with
session draining off, these DELEGRETURNs will cycle with errors filling up the
session slots.
This prevents OPEN reclaims (from nfs_delegation_claim_opens) required by the
NFS4CLNT_DELEGRETURN state manager processing from completing, hanging the
state manager in the __rpc_wait_for_completion_task in nfs4_run_open_task
as seen in this kernel thread dump:
kernel: 4.12.32.53-ma D 0000000000000000 0 3393 2 0x00000000
kernel: ffff88013995fb60 0000000000000046 ffff880138cc5400 ffff88013a9df140
kernel: ffff8800000265c0 ffffffff8116eef0 ffff88013fc10080 0000000300000001
kernel: ffff88013a4ad058 ffff88013995ffd8 000000000000fbc8 ffff88013a4ad058
kernel: Call Trace:
kernel: [<ffffffff8116eef0>] ? cache_alloc_refill+0x1c0/0x240
kernel: [<ffffffffa0358110>] ? rpc_wait_bit_killable+0x0/0xa0 [sunrpc]
kernel: [<ffffffffa0358152>] rpc_wait_bit_killable+0x42/0xa0 [sunrpc]
kernel: [<ffffffff8152914f>] __wait_on_bit+0x5f/0x90
kernel: [<ffffffffa0358110>] ? rpc_wait_bit_killable+0x0/0xa0 [sunrpc]
kernel: [<ffffffff815291f8>] out_of_line_wait_on_bit+0x78/0x90
kernel: [<ffffffff8109b520>] ? wake_bit_function+0x0/0x50
kernel: [<ffffffffa035810d>] __rpc_wait_for_completion_task+0x2d/0x30 [sunrpc]
kernel: [<ffffffffa040d44c>] nfs4_run_open_task+0x11c/0x160 [nfs]
kernel: [<ffffffffa04114e7>] nfs4_open_recover_helper+0x87/0x120 [nfs]
kernel: [<ffffffffa0411646>] nfs4_open_recover+0xc6/0x150 [nfs]
kernel: [<ffffffffa040cc6f>] ? nfs4_open_recoverdata_alloc+0x2f/0x60 [nfs]
kernel: [<ffffffffa0414e1a>] nfs4_open_delegation_recall+0x6a/0xa0 [nfs]
kernel: [<ffffffffa0424020>] nfs_end_delegation_return+0x120/0x2e0 [nfs]
kernel: [<ffffffff8109580f>] ? queue_work+0x1f/0x30
kernel: [<ffffffffa0424347>] nfs_client_return_marked_delegations+0xd7/0x110 [nfs]
kernel: [<ffffffffa04225d8>] nfs4_run_state_manager+0x548/0x620 [nfs]
kernel: [<ffffffffa0422090>] ? nfs4_run_state_manager+0x0/0x620 [nfs]
kernel: [<ffffffff8109b0f6>] kthread+0x96/0xa0
kernel: [<ffffffff8100c20a>] child_rip+0xa/0x20
kernel: [<ffffffff8109b060>] ? kthread+0x0/0xa0
kernel: [<ffffffff8100c200>] ? child_rip+0x0/0x20
The state manager can not therefore process the DELEGRETURN session errors.
Change the async handler to wait for recovery on session errors.
Signed-off-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/nfs/nfs4proc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -4752,8 +4752,7 @@ nfs4_async_handle_error(struct rpc_task
dprintk("%s ERROR %d, Reset session\n", __func__,
task->tk_status);
nfs4_schedule_session_recovery(clp->cl_session, task->tk_status);
- task->tk_status = 0;
- return -EAGAIN;
+ goto wait_on_recovery;
#endif /* CONFIG_NFS_V4_1 */
case -NFS4ERR_DELAY:
nfs_inc_server_stats(server, NFSIOS_DELAY);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 104/118] Input: elantech - add support for newer (August 2013) devices
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (98 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 103/118] NFSv4 wait on recovery for async session errors Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 105/118] Revert "net: update consumers of MSG_MORE to recognize MSG_SENDPAGE_NOTLAST" Greg Kroah-Hartman
` (16 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Dmitry Torokhov
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matt Walker <matt.g.d.walker@gmail.com>
commit 9cb80b965eaf7af1369f6e16f48a05fbaaccc021 upstream.
Added detection for newer Elantech touchpads, so that kernel doesn't
fall-back to default PS/2 driver. Supports touchpads released after
~August 2013. Fixes bug:
https://lists.launchpad.net/kernel-packages/msg18481.html
Tested on an Acer Aspire S7-392-6302.
Signed-off by: Matt Walker <matt.g.d.walker@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/mouse/elantech.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1313,6 +1313,7 @@ static int elantech_set_properties(struc
break;
case 6:
case 7:
+ case 8:
etd->hw_version = 4;
break;
default:
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 105/118] Revert "net: update consumers of MSG_MORE to recognize MSG_SENDPAGE_NOTLAST"
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (99 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 104/118] Input: elantech - add support for newer (August 2013) devices Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 106/118] Btrfs: do a full search everytime in btrfs_search_old_slot Greg Kroah-Hartman
` (15 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Veaceslav Falico, David S. Miller,
Eric Dumazet, Richard Weinberger, Shawn Landden, Tom Herbert
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
It turns out that commit: d3f7d56a7a4671d395e8af87071068a195257bf6 was
applied to the tree twice, which didn't hurt anything, but it's good to
fix this up.
Reported-by: Veaceslav Falico <veaceslav@falico.eu>
Cc: David S. Miller <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Shawn Landden <shawnlandden@gmail.com>
Cc: Tom Herbert <therbert@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
crypto/algif_hash.c | 3 ---
crypto/algif_skcipher.c | 3 ---
net/ipv4/udp.c | 3 ---
3 files changed, 9 deletions(-)
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -117,9 +117,6 @@ static ssize_t hash_sendpage(struct sock
if (flags & MSG_SENDPAGE_NOTLAST)
flags |= MSG_MORE;
- if (flags & MSG_SENDPAGE_NOTLAST)
- flags |= MSG_MORE;
-
lock_sock(sk);
sg_init_table(ctx->sgl.sg, 1);
sg_set_page(ctx->sgl.sg, page, size, offset);
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -381,9 +381,6 @@ static ssize_t skcipher_sendpage(struct
if (flags & MSG_SENDPAGE_NOTLAST)
flags |= MSG_MORE;
- if (flags & MSG_SENDPAGE_NOTLAST)
- flags |= MSG_MORE;
-
lock_sock(sk);
if (!ctx->more && ctx->used)
goto unlock;
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1075,9 +1075,6 @@ int udp_sendpage(struct sock *sk, struct
if (flags & MSG_SENDPAGE_NOTLAST)
flags |= MSG_MORE;
- if (flags & MSG_SENDPAGE_NOTLAST)
- flags |= MSG_MORE;
-
if (!up->pending) {
struct msghdr msg = { .msg_flags = flags|MSG_MORE };
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 106/118] Btrfs: do a full search everytime in btrfs_search_old_slot
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (100 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 105/118] Revert "net: update consumers of MSG_MORE to recognize MSG_SENDPAGE_NOTLAST" Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 107/118] Btrfs: reset intwrite on transaction abort Greg Kroah-Hartman
` (14 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Josef Bacik, Chris Mason
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josef Bacik <jbacik@fusionio.com>
commit d4b4087c43cc00a196c5be57fac41f41309f1d56 upstream.
While running some snashot aware defrag tests I noticed I was panicing every
once and a while in key_search. This is because of the optimization that says
if we find a key at slot 0 it will be at slot 0 all the way down the rest of the
tree. This isn't the case for btrfs_search_old_slot since it will likely replay
changes to a buffer if something has changed since we took our sequence number.
So short circuit this optimization by setting prev_cmp to -1 every time we call
key_search so we will do our normal binary search. With this patch I am no
longer seeing the panics I was seeing before. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/ctree.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -2758,7 +2758,7 @@ int btrfs_search_old_slot(struct btrfs_r
int level;
int lowest_unlock = 1;
u8 lowest_level = 0;
- int prev_cmp;
+ int prev_cmp = -1;
lowest_level = p->lowest_level;
WARN_ON(p->nodes[0] != NULL);
@@ -2769,7 +2769,6 @@ int btrfs_search_old_slot(struct btrfs_r
}
again:
- prev_cmp = -1;
b = get_old_root(root, time_seq);
level = btrfs_header_level(b);
p->locks[level] = BTRFS_READ_LOCK;
@@ -2787,6 +2786,11 @@ again:
*/
btrfs_unlock_up_safe(p, level + 1);
+ /*
+ * Since we can unwind eb's we want to do a real search every
+ * time.
+ */
+ prev_cmp = -1;
ret = key_search(b, key, level, &prev_cmp, &slot);
if (level != 0) {
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 107/118] Btrfs: reset intwrite on transaction abort
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (101 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 106/118] Btrfs: do a full search everytime in btrfs_search_old_slot Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 108/118] Btrfs: fix memory leak of chunks extent map Greg Kroah-Hartman
` (13 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Josef Bacik, Chris Mason
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josef Bacik <jbacik@fusionio.com>
commit e0228285a8cad70e4b7b4833cc650e36ecd8de89 upstream.
If we abort a transaction in the middle of a commit we weren't undoing the
intwrite locking. This patch fixes that problem.
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/transaction.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -1552,6 +1552,8 @@ static void cleanup_transaction(struct b
root->fs_info->running_transaction = NULL;
spin_unlock(&root->fs_info->trans_lock);
+ if (trans->type & __TRANS_FREEZABLE)
+ sb_end_intwrite(root->fs_info->sb);
put_transaction(cur_trans);
put_transaction(cur_trans);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 108/118] Btrfs: fix memory leak of chunks extent map
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (102 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 107/118] Btrfs: reset intwrite on transaction abort Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 109/118] Btrfs: fix hole check in log_one_extent Greg Kroah-Hartman
` (12 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Liu Bo, Josef Bacik, Chris Mason
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liu Bo <bo.li.liu@oracle.com>
commit 7d3d1744f8a7d62e4875bd69cc2192a939813880 upstream.
As we're hold a ref on looking up the extent map, we need to drop the ref
before returning to callers.
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/volumes.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -4488,6 +4488,7 @@ int btrfs_num_copies(struct btrfs_fs_inf
btrfs_crit(fs_info, "Invalid mapping for %Lu-%Lu, got "
"%Lu-%Lu\n", logical, logical+len, em->start,
em->start + em->len);
+ free_extent_map(em);
return 1;
}
@@ -4668,6 +4669,7 @@ static int __btrfs_map_block(struct btrf
btrfs_crit(fs_info, "found a bad mapping, wanted %Lu, "
"found %Lu-%Lu\n", logical, em->start,
em->start + em->len);
+ free_extent_map(em);
return -EINVAL;
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 109/118] Btrfs: fix hole check in log_one_extent
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (103 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 108/118] Btrfs: fix memory leak of chunks extent map Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 110/118] Btrfs: fix incorrect inode acl reset Greg Kroah-Hartman
` (11 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Josef Bacik, Chris Mason
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josef Bacik <jbacik@fusionio.com>
commit ed9e8af88e2551aaa6bf51d8063a2493e2d71597 upstream.
I added an assert to make sure we were looking up aligned offsets for csums and
I tripped it when running xfstests. This is because log_one_extent was checking
if block_start == 0 for a hole instead of EXTENT_MAP_HOLE. This worked out fine
in practice it seems, but it adds a lot of extra work that is uneeded. With
this fix I'm no longer tripping my assert. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/tree-log.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -3375,7 +3375,7 @@ static int log_one_extent(struct btrfs_t
btrfs_set_token_file_extent_type(leaf, fi,
BTRFS_FILE_EXTENT_REG,
&token);
- if (em->block_start == 0)
+ if (em->block_start == EXTENT_MAP_HOLE)
skip_csum = true;
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 110/118] Btrfs: fix incorrect inode acl reset
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (104 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 109/118] Btrfs: fix hole check in log_one_extent Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 111/118] Btrfs: stop using vfs_read in send Greg Kroah-Hartman
` (10 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Giuseppe Fierro,
Filipe David Borba Manana, Josef Bacik, Chris Mason
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe David Borba Manana <fdmanana@gmail.com>
commit 8185554d3eb09d23a805456b6fa98dcbb34aa518 upstream.
When a directory has a default ACL and a subdirectory is created
under that directory, btrfs_init_acl() is called when the
subdirectory's inode is created to initialize the inode's ACL
(inherited from the parent directory) but it was clearing the ACL
from the inode after setting it if posix_acl_create() returned
success, instead of clearing it only if it returned an error.
To reproduce this issue:
$ mkfs.btrfs -f /dev/loop0
$ mount /dev/loop0 /mnt
$ mkdir /mnt/acl
$ setfacl -d --set u::rwx,g::rwx,o::- /mnt/acl
$ getfacl /mnt/acl
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:other::---
$ mkdir /mnt/acl/dir1
$ getfacl /mnt/acl/dir1
user::rwx
group::rwx
other::---
After unmounting and mounting again the filesystem, fgetacl returned the
expected ACL:
$ umount /mnt/acl
$ mount /dev/loop0 /mnt
$ getfacl /mnt/acl/dir1
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:other::---
Meaning that the underlying xattr was persisted.
Reported-by: Giuseppe Fierro <giuseppe@fierro.org>
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/acl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/btrfs/acl.c
+++ b/fs/btrfs/acl.c
@@ -229,7 +229,7 @@ int btrfs_init_acl(struct btrfs_trans_ha
if (ret > 0) {
/* we need an acl */
ret = btrfs_set_acl(trans, inode, acl, ACL_TYPE_ACCESS);
- } else {
+ } else if (ret < 0) {
cache_no_acl(inode);
}
} else {
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 111/118] Btrfs: stop using vfs_read in send
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (105 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 110/118] Btrfs: fix incorrect inode acl reset Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 112/118] Btrfs: take ordered root lock when removing ordered operations inode Greg Kroah-Hartman
` (9 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Josef Bacik, Chris Mason
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josef Bacik <jbacik@fusionio.com>
commit ed2590953bd06b892f0411fc94e19175d32f197a upstream.
Apparently we don't actually close the files until we return to userspace, so
stop using vfs_read in send. This is actually better for us since we can avoid
all the extra logic of holding the file we're sending open and making sure to
clean it up. This will fix people who have been hitting too many files open
errors when trying to send. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/send.c | 175 +++++++++++++++++++++++---------------------------------
1 file changed, 72 insertions(+), 103 deletions(-)
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -121,7 +121,6 @@ struct send_ctx {
struct list_head name_cache_list;
int name_cache_size;
- struct file *cur_inode_filp;
char *read_buf;
};
@@ -2120,77 +2119,6 @@ out:
}
/*
- * Called for regular files when sending extents data. Opens a struct file
- * to read from the file.
- */
-static int open_cur_inode_file(struct send_ctx *sctx)
-{
- int ret = 0;
- struct btrfs_key key;
- struct path path;
- struct inode *inode;
- struct dentry *dentry;
- struct file *filp;
- int new = 0;
-
- if (sctx->cur_inode_filp)
- goto out;
-
- key.objectid = sctx->cur_ino;
- key.type = BTRFS_INODE_ITEM_KEY;
- key.offset = 0;
-
- inode = btrfs_iget(sctx->send_root->fs_info->sb, &key, sctx->send_root,
- &new);
- if (IS_ERR(inode)) {
- ret = PTR_ERR(inode);
- goto out;
- }
-
- dentry = d_obtain_alias(inode);
- inode = NULL;
- if (IS_ERR(dentry)) {
- ret = PTR_ERR(dentry);
- goto out;
- }
-
- path.mnt = sctx->mnt;
- path.dentry = dentry;
- filp = dentry_open(&path, O_RDONLY | O_LARGEFILE, current_cred());
- dput(dentry);
- dentry = NULL;
- if (IS_ERR(filp)) {
- ret = PTR_ERR(filp);
- goto out;
- }
- sctx->cur_inode_filp = filp;
-
-out:
- /*
- * no xxxput required here as every vfs op
- * does it by itself on failure
- */
- return ret;
-}
-
-/*
- * Closes the struct file that was created in open_cur_inode_file
- */
-static int close_cur_inode_file(struct send_ctx *sctx)
-{
- int ret = 0;
-
- if (!sctx->cur_inode_filp)
- goto out;
-
- ret = filp_close(sctx->cur_inode_filp, NULL);
- sctx->cur_inode_filp = NULL;
-
-out:
- return ret;
-}
-
-/*
* Sends a BTRFS_SEND_C_SUBVOL command/item to userspace
*/
static int send_subvol_begin(struct send_ctx *sctx)
@@ -3622,6 +3550,72 @@ out:
return ret;
}
+static ssize_t fill_read_buf(struct send_ctx *sctx, u64 offset, u32 len)
+{
+ struct btrfs_root *root = sctx->send_root;
+ struct btrfs_fs_info *fs_info = root->fs_info;
+ struct inode *inode;
+ struct page *page;
+ char *addr;
+ struct btrfs_key key;
+ pgoff_t index = offset >> PAGE_CACHE_SHIFT;
+ pgoff_t last_index;
+ unsigned pg_offset = offset & ~PAGE_CACHE_MASK;
+ ssize_t ret = 0;
+
+ key.objectid = sctx->cur_ino;
+ key.type = BTRFS_INODE_ITEM_KEY;
+ key.offset = 0;
+
+ inode = btrfs_iget(fs_info->sb, &key, root, NULL);
+ if (IS_ERR(inode))
+ return PTR_ERR(inode);
+
+ if (offset + len > i_size_read(inode)) {
+ if (offset > i_size_read(inode))
+ len = 0;
+ else
+ len = offset - i_size_read(inode);
+ }
+ if (len == 0)
+ goto out;
+
+ last_index = (offset + len - 1) >> PAGE_CACHE_SHIFT;
+ while (index <= last_index) {
+ unsigned cur_len = min_t(unsigned, len,
+ PAGE_CACHE_SIZE - pg_offset);
+ page = find_or_create_page(inode->i_mapping, index, GFP_NOFS);
+ if (!page) {
+ ret = -ENOMEM;
+ break;
+ }
+
+ if (!PageUptodate(page)) {
+ btrfs_readpage(NULL, page);
+ lock_page(page);
+ if (!PageUptodate(page)) {
+ unlock_page(page);
+ page_cache_release(page);
+ ret = -EIO;
+ break;
+ }
+ }
+
+ addr = kmap(page);
+ memcpy(sctx->read_buf + ret, addr + pg_offset, cur_len);
+ kunmap(page);
+ unlock_page(page);
+ page_cache_release(page);
+ index++;
+ pg_offset = 0;
+ len -= cur_len;
+ ret += cur_len;
+ }
+out:
+ iput(inode);
+ return ret;
+}
+
/*
* Read some bytes from the current inode/file and send a write command to
* user space.
@@ -3630,35 +3624,20 @@ static int send_write(struct send_ctx *s
{
int ret = 0;
struct fs_path *p;
- loff_t pos = offset;
- int num_read = 0;
- mm_segment_t old_fs;
+ ssize_t num_read = 0;
p = fs_path_alloc();
if (!p)
return -ENOMEM;
- /*
- * vfs normally only accepts user space buffers for security reasons.
- * we only read from the file and also only provide the read_buf buffer
- * to vfs. As this buffer does not come from a user space call, it's
- * ok to temporary allow kernel space buffers.
- */
- old_fs = get_fs();
- set_fs(KERNEL_DS);
-
verbose_printk("btrfs: send_write offset=%llu, len=%d\n", offset, len);
- ret = open_cur_inode_file(sctx);
- if (ret < 0)
- goto out;
-
- ret = vfs_read(sctx->cur_inode_filp, sctx->read_buf, len, &pos);
- if (ret < 0)
- goto out;
- num_read = ret;
- if (!num_read)
+ num_read = fill_read_buf(sctx, offset, len);
+ if (num_read <= 0) {
+ if (num_read < 0)
+ ret = num_read;
goto out;
+ }
ret = begin_cmd(sctx, BTRFS_SEND_C_WRITE);
if (ret < 0)
@@ -3677,7 +3656,6 @@ verbose_printk("btrfs: send_write offset
tlv_put_failure:
out:
fs_path_free(p);
- set_fs(old_fs);
if (ret < 0)
return ret;
return num_read;
@@ -4222,10 +4200,6 @@ static int changed_inode(struct send_ctx
u64 left_gen = 0;
u64 right_gen = 0;
- ret = close_cur_inode_file(sctx);
- if (ret < 0)
- goto out;
-
sctx->cur_ino = key->objectid;
sctx->cur_inode_new_gen = 0;
@@ -4686,11 +4660,6 @@ static int send_subvol(struct send_ctx *
}
out:
- if (!ret)
- ret = close_cur_inode_file(sctx);
- else
- close_cur_inode_file(sctx);
-
free_recorded_refs(sctx);
return ret;
}
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 112/118] Btrfs: take ordered root lock when removing ordered operations inode
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (106 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 111/118] Btrfs: stop using vfs_read in send Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 113/118] Btrfs: do not run snapshot-aware defragment on error Greg Kroah-Hartman
` (8 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Josef Bacik, Chris Mason
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josef Bacik <jbacik@fusionio.com>
commit 93858769172c4e3678917810e9d5de360eb991cc upstream.
A user reported a list corruption warning from btrfs_remove_ordered_extent, it
is because we aren't taking the ordered_root_lock when we remove the inode from
the ordered operations list. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/ordered-data.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/btrfs/ordered-data.c
+++ b/fs/btrfs/ordered-data.c
@@ -537,7 +537,9 @@ void btrfs_remove_ordered_extent(struct
*/
if (RB_EMPTY_ROOT(&tree->tree) &&
!mapping_tagged(inode->i_mapping, PAGECACHE_TAG_DIRTY)) {
+ spin_lock(&root->fs_info->ordered_root_lock);
list_del_init(&BTRFS_I(inode)->ordered_operations);
+ spin_unlock(&root->fs_info->ordered_root_lock);
}
if (!root->nr_ordered_extents) {
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 113/118] Btrfs: do not run snapshot-aware defragment on error
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (107 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 112/118] Btrfs: take ordered root lock when removing ordered operations inode Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 114/118] Btrfs: fix a crash when running balance and defrag concurrently Greg Kroah-Hartman
` (7 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Liu Bo, Josef Bacik, Chris Mason
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liu Bo <bo.li.liu@oracle.com>
commit 6f519564d7d978c00351d9ab6abac3deeac31621 upstream.
If something wrong happens in write endio, running snapshot-aware defragment
can end up with undefined results, maybe a crash, so we should avoid it.
In order to share similar code, this also adds a helper to free the struct for
snapshot-aware defrag.
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/inode.c | 47 ++++++++++++++++++++++++++++-------------------
1 file changed, 28 insertions(+), 19 deletions(-)
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2367,10 +2367,23 @@ out_unlock:
return ret;
}
+static void free_sa_defrag_extent(struct new_sa_defrag_extent *new)
+{
+ struct old_sa_defrag_extent *old, *tmp;
+
+ if (!new)
+ return;
+
+ list_for_each_entry_safe(old, tmp, &new->head, list) {
+ list_del(&old->list);
+ kfree(old);
+ }
+ kfree(new);
+}
+
static void relink_file_extents(struct new_sa_defrag_extent *new)
{
struct btrfs_path *path;
- struct old_sa_defrag_extent *old, *tmp;
struct sa_defrag_extent_backref *backref;
struct sa_defrag_extent_backref *prev = NULL;
struct inode *inode;
@@ -2413,16 +2426,11 @@ static void relink_file_extents(struct n
kfree(prev);
btrfs_free_path(path);
-
- list_for_each_entry_safe(old, tmp, &new->head, list) {
- list_del(&old->list);
- kfree(old);
- }
out:
+ free_sa_defrag_extent(new);
+
atomic_dec(&root->fs_info->defrag_running);
wake_up(&root->fs_info->transaction_wait);
-
- kfree(new);
}
static struct new_sa_defrag_extent *
@@ -2432,7 +2440,7 @@ record_old_file_extents(struct inode *in
struct btrfs_root *root = BTRFS_I(inode)->root;
struct btrfs_path *path;
struct btrfs_key key;
- struct old_sa_defrag_extent *old, *tmp;
+ struct old_sa_defrag_extent *old;
struct new_sa_defrag_extent *new;
int ret;
@@ -2480,7 +2488,7 @@ record_old_file_extents(struct inode *in
if (slot >= btrfs_header_nritems(l)) {
ret = btrfs_next_leaf(root, path);
if (ret < 0)
- goto out_free_list;
+ goto out_free_path;
else if (ret > 0)
break;
continue;
@@ -2509,7 +2517,7 @@ record_old_file_extents(struct inode *in
old = kmalloc(sizeof(*old), GFP_NOFS);
if (!old)
- goto out_free_list;
+ goto out_free_path;
offset = max(new->file_pos, key.offset);
end = min(new->file_pos + new->len, key.offset + num_bytes);
@@ -2531,15 +2539,10 @@ next:
return new;
-out_free_list:
- list_for_each_entry_safe(old, tmp, &new->head, list) {
- list_del(&old->list);
- kfree(old);
- }
out_free_path:
btrfs_free_path(path);
out_kfree:
- kfree(new);
+ free_sa_defrag_extent(new);
return NULL;
}
@@ -2710,8 +2713,14 @@ out:
btrfs_remove_ordered_extent(inode, ordered_extent);
/* for snapshot-aware defrag */
- if (new)
- relink_file_extents(new);
+ if (new) {
+ if (ret) {
+ free_sa_defrag_extent(new);
+ atomic_dec(&root->fs_info->defrag_running);
+ } else {
+ relink_file_extents(new);
+ }
+ }
/* once for us */
btrfs_put_ordered_extent(ordered_extent);
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 114/118] Btrfs: fix a crash when running balance and defrag concurrently
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (108 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 113/118] Btrfs: do not run snapshot-aware defragment on error Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 21:12 ` [PATCH 3.12 115/118] Btrfs: fix lockdep error in async commit Greg Kroah-Hartman
` (6 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Liu Bo, Josef Bacik, Chris Mason
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liu Bo <bo.li.liu@oracle.com>
commit 48ec47364b6d493f0a9cdc116977bf3f34e5c3ec upstream.
Running balance and defrag concurrently can end up with a crash:
kernel BUG at fs/btrfs/relocation.c:4528!
RIP: 0010:[<ffffffffa01ac33b>] [<ffffffffa01ac33b>] btrfs_reloc_cow_block+ 0x1eb/0x230 [btrfs]
Call Trace:
[<ffffffffa01398c1>] ? update_ref_for_cow+0x241/0x380 [btrfs]
[<ffffffffa0180bad>] ? copy_extent_buffer+0xad/0x110 [btrfs]
[<ffffffffa0139da1>] __btrfs_cow_block+0x3a1/0x520 [btrfs]
[<ffffffffa013a0b6>] btrfs_cow_block+0x116/0x1b0 [btrfs]
[<ffffffffa013ddad>] btrfs_search_slot+0x43d/0x970 [btrfs]
[<ffffffffa0153c57>] btrfs_lookup_file_extent+0x37/0x40 [btrfs]
[<ffffffffa0172a5e>] __btrfs_drop_extents+0x11e/0xae0 [btrfs]
[<ffffffffa013b3fd>] ? generic_bin_search.constprop.39+0x8d/0x1a0 [btrfs]
[<ffffffff8117d14a>] ? kmem_cache_alloc+0x1da/0x200
[<ffffffffa0138e7a>] ? btrfs_alloc_path+0x1a/0x20 [btrfs]
[<ffffffffa0173ef0>] btrfs_drop_extents+0x60/0x90 [btrfs]
[<ffffffffa016b24d>] relink_extent_backref+0x2ed/0x780 [btrfs]
[<ffffffffa0162fe0>] ? btrfs_submit_bio_hook+0x1e0/0x1e0 [btrfs]
[<ffffffffa01b8ed7>] ? iterate_inodes_from_logical+0x87/0xa0 [btrfs]
[<ffffffffa016b909>] btrfs_finish_ordered_io+0x229/0xac0 [btrfs]
[<ffffffffa016c3b5>] finish_ordered_fn+0x15/0x20 [btrfs]
[<ffffffffa018cbe5>] worker_loop+0x125/0x4e0 [btrfs]
[<ffffffffa018cac0>] ? btrfs_queue_worker+0x300/0x300 [btrfs]
[<ffffffff81075ea0>] kthread+0xc0/0xd0
[<ffffffff81075de0>] ? insert_kthread_work+0x40/0x40
[<ffffffff8164796c>] ret_from_fork+0x7c/0xb0
[<ffffffff81075de0>] ? insert_kthread_work+0x40/0x40
----------------------------------------------------------------------
It turns out to be that balance operation will bump root's @last_snapshot,
which enables snapshot-aware defrag path, and backref walking stuff will
find data reloc tree as refs' parent, and hit the BUG_ON() during COW.
As data reloc tree's data is just for relocation purpose, and will be deleted right
after relocation is done, it's unnecessary to walk those refs belonged to data reloc
tree, it'd be better to skip them.
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/backref.c | 3 +++
1 file changed, 3 insertions(+)
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -185,6 +185,9 @@ static int __add_prelim_ref(struct list_
{
struct __prelim_ref *ref;
+ if (root_id == BTRFS_DATA_RELOC_TREE_OBJECTID)
+ return 0;
+
ref = kmem_cache_alloc(btrfs_prelim_ref_cache, gfp_mask);
if (!ref)
return -ENOMEM;
^ permalink raw reply [flat|nested] 196+ messages in thread* [PATCH 3.12 115/118] Btrfs: fix lockdep error in async commit
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (109 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 114/118] Btrfs: fix a crash when running balance and defrag concurrently Greg Kroah-Hartman
@ 2013-12-18 21:12 ` Greg Kroah-Hartman
2013-12-18 23:48 ` [PATCH 3.12 000/118] 3.12.6-stable review Guenter Roeck
` (5 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-18 21:12 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ma Jianpeng, Liu Bo, Miao Xie,
Josef Bacik, Chris Mason
3.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liu Bo <bo.li.liu@oracle.com>
commit b1a06a4b574996692b72b742bf6e6aa0c711a948 upstream.
Lockdep complains about btrfs's async commit:
[ 2372.462171] [ BUG: bad unlock balance detected! ]
[ 2372.462191] 3.12.0+ #32 Tainted: G W
[ 2372.462209] -------------------------------------
[ 2372.462228] ceph-osd/14048 is trying to release lock (sb_internal) at:
[ 2372.462275] [<ffffffffa022cb10>] btrfs_commit_transaction_async+0x1b0/0x2a0 [btrfs]
[ 2372.462305] but there are no more locks to release!
[ 2372.462324]
[ 2372.462324] other info that might help us debug this:
[ 2372.462349] no locks held by ceph-osd/14048.
[ 2372.462367]
[ 2372.462367] stack backtrace:
[ 2372.462386] CPU: 2 PID: 14048 Comm: ceph-osd Tainted: G W 3.12.0+ #32
[ 2372.462414] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080015 11/09/2011
[ 2372.462455] ffffffffa022cb10 ffff88007490fd28 ffffffff816f094a ffff8800378aa320
[ 2372.462491] ffff88007490fd50 ffffffff810adf4c ffff8800378aa320 ffff88009af97650
[ 2372.462526] ffffffffa022cb10 ffff88007490fd88 ffffffff810b01ee ffff8800898c0000
[ 2372.462562] Call Trace:
[ 2372.462584] [<ffffffffa022cb10>] ? btrfs_commit_transaction_async+0x1b0/0x2a0 [btrfs]
[ 2372.462619] [<ffffffff816f094a>] dump_stack+0x45/0x56
[ 2372.462642] [<ffffffff810adf4c>] print_unlock_imbalance_bug+0xec/0x100
[ 2372.462677] [<ffffffffa022cb10>] ? btrfs_commit_transaction_async+0x1b0/0x2a0 [btrfs]
[ 2372.462710] [<ffffffff810b01ee>] lock_release+0x18e/0x210
[ 2372.462742] [<ffffffffa022cb36>] btrfs_commit_transaction_async+0x1d6/0x2a0 [btrfs]
[ 2372.462783] [<ffffffffa025a7ce>] btrfs_ioctl_start_sync+0x3e/0xc0 [btrfs]
[ 2372.462822] [<ffffffffa025f1d3>] btrfs_ioctl+0x4c3/0x1f70 [btrfs]
[ 2372.462849] [<ffffffff812c0321>] ? avc_has_perm+0x121/0x1b0
[ 2372.462873] [<ffffffff812c0224>] ? avc_has_perm+0x24/0x1b0
[ 2372.462897] [<ffffffff8107ecc8>] ? sched_clock_cpu+0xa8/0x100
[ 2372.462922] [<ffffffff8117b145>] do_vfs_ioctl+0x2e5/0x4e0
[ 2372.462946] [<ffffffff812c19e6>] ? file_has_perm+0x86/0xa0
[ 2372.462969] [<ffffffff8117b3c1>] SyS_ioctl+0x81/0xa0
[ 2372.462991] [<ffffffff817045a4>] tracesys+0xdd/0xe2
====================================================
It's because that we don't do the right thing when checking if it's ok to
tell lockdep that we're trying to release the rwsem.
If the trans handle's type is TRANS_ATTACH, we won't acquire the freeze rwsem, but
as TRANS_ATTACH fits the check (trans < TRANS_JOIN_NOLOCK), we'll release the freeze
rwsem, which makes lockdep complains a lot.
Reported-by: Ma Jianpeng <majianpeng@gmail.com>
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/transaction.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -1453,7 +1453,7 @@ static void do_async_commit(struct work_
* We've got freeze protection passed with the transaction.
* Tell lockdep about it.
*/
- if (ac->newtrans->type < TRANS_JOIN_NOLOCK)
+ if (ac->newtrans->type & __TRANS_FREEZABLE)
rwsem_acquire_read(
&ac->root->fs_info->sb->s_writers.lock_map[SB_FREEZE_FS-1],
0, 1, _THIS_IP_);
@@ -1494,7 +1494,7 @@ int btrfs_commit_transaction_async(struc
* Tell lockdep we've released the freeze rwsem, since the
* async commit thread will be the one to unlock it.
*/
- if (trans->type < TRANS_JOIN_NOLOCK)
+ if (ac->newtrans->type & __TRANS_FREEZABLE)
rwsem_release(
&root->fs_info->sb->s_writers.lock_map[SB_FREEZE_FS-1],
1, _THIS_IP_);
^ permalink raw reply [flat|nested] 196+ messages in thread* Re: [PATCH 3.12 000/118] 3.12.6-stable review
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (110 preceding siblings ...)
2013-12-18 21:12 ` [PATCH 3.12 115/118] Btrfs: fix lockdep error in async commit Greg Kroah-Hartman
@ 2013-12-18 23:48 ` Guenter Roeck
2013-12-19 2:56 ` Greg Kroah-Hartman
2013-12-19 2:07 ` Guenter Roeck
` (4 subsequent siblings)
116 siblings, 1 reply; 196+ messages in thread
From: Guenter Roeck @ 2013-12-18 23:48 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, torvalds, akpm, stable
On Wed, Dec 18, 2013 at 01:10:37PM -0800, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.12.6 release.
> There are 118 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri Dec 20 21:12:03 UTC 2013.
> Anything received after that time might be too late.
>
Hi greg,
I see a couple of failed builds.
m68k:allmodconfig ... failed
mips:allmodconfig ... failed
sparc64:allmodconfig ... failed
x86_64:allyesconfig ... failed
x86_64:allmodconfig ... failed
Build is still going on, so there may be more.
Error log:
drivers/staging/comedi/drivers/ssv_dnp.c: In function 'dnp_dio_insn_bits':
drivers/staging/comedi/drivers/ssv_dnp.c:63:2: error: implicit declaration of function 'comedi_dio_update_state' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[4]: *** [drivers/staging/comedi/drivers/ssv_dnp.o] Error 1
Function comedi_dio_update_state() is not defined anywhere in 3.12,
so patches
staging: comedi: ssv_dnp: use comedi_dio_update_state()
staging: comedi: drivers: use comedi_dio_update_state() for simple cases
won't apply without additional changes.
Guenter
^ permalink raw reply [flat|nested] 196+ messages in thread* Re: [PATCH 3.12 000/118] 3.12.6-stable review
2013-12-18 23:48 ` [PATCH 3.12 000/118] 3.12.6-stable review Guenter Roeck
@ 2013-12-19 2:56 ` Greg Kroah-Hartman
2013-12-19 3:00 ` Greg Kroah-Hartman
0 siblings, 1 reply; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-19 2:56 UTC (permalink / raw)
To: Guenter Roeck; +Cc: linux-kernel, torvalds, akpm, stable
On Wed, Dec 18, 2013 at 03:48:57PM -0800, Guenter Roeck wrote:
> On Wed, Dec 18, 2013 at 01:10:37PM -0800, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.12.6 release.
> > There are 118 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Fri Dec 20 21:12:03 UTC 2013.
> > Anything received after that time might be too late.
> >
>
> Hi greg,
>
> I see a couple of failed builds.
>
> m68k:allmodconfig ... failed
> mips:allmodconfig ... failed
> sparc64:allmodconfig ... failed
> x86_64:allyesconfig ... failed
> x86_64:allmodconfig ... failed
>
> Build is still going on, so there may be more.
>
> Error log:
>
> drivers/staging/comedi/drivers/ssv_dnp.c: In function 'dnp_dio_insn_bits':
> drivers/staging/comedi/drivers/ssv_dnp.c:63:2: error: implicit declaration of function 'comedi_dio_update_state' [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
> make[4]: *** [drivers/staging/comedi/drivers/ssv_dnp.o] Error 1
>
> Function comedi_dio_update_state() is not defined anywhere in 3.12,
> so patches
> staging: comedi: ssv_dnp: use comedi_dio_update_state()
> staging: comedi: drivers: use comedi_dio_update_state() for simple cases
>
> won't apply without additional changes.
Odd, let me see what happened, as I thought this was building properly
on my test boxes...
greg k-h
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 000/118] 3.12.6-stable review
2013-12-19 2:56 ` Greg Kroah-Hartman
@ 2013-12-19 3:00 ` Greg Kroah-Hartman
2013-12-19 3:20 ` Greg Kroah-Hartman
0 siblings, 1 reply; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-19 3:00 UTC (permalink / raw)
To: Guenter Roeck; +Cc: linux-kernel, torvalds, akpm, stable
On Wed, Dec 18, 2013 at 06:56:58PM -0800, Greg Kroah-Hartman wrote:
> On Wed, Dec 18, 2013 at 03:48:57PM -0800, Guenter Roeck wrote:
> > On Wed, Dec 18, 2013 at 01:10:37PM -0800, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 3.12.6 release.
> > > There are 118 patches in this series, all will be posted as a response
> > > to this one. If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Fri Dec 20 21:12:03 UTC 2013.
> > > Anything received after that time might be too late.
> > >
> >
> > Hi greg,
> >
> > I see a couple of failed builds.
> >
> > m68k:allmodconfig ... failed
> > mips:allmodconfig ... failed
> > sparc64:allmodconfig ... failed
> > x86_64:allyesconfig ... failed
> > x86_64:allmodconfig ... failed
> >
> > Build is still going on, so there may be more.
> >
> > Error log:
> >
> > drivers/staging/comedi/drivers/ssv_dnp.c: In function 'dnp_dio_insn_bits':
> > drivers/staging/comedi/drivers/ssv_dnp.c:63:2: error: implicit declaration of function 'comedi_dio_update_state' [-Werror=implicit-function-declaration]
> > cc1: some warnings being treated as errors
> > make[4]: *** [drivers/staging/comedi/drivers/ssv_dnp.o] Error 1
> >
> > Function comedi_dio_update_state() is not defined anywhere in 3.12,
> > so patches
> > staging: comedi: ssv_dnp: use comedi_dio_update_state()
> > staging: comedi: drivers: use comedi_dio_update_state() for simple cases
> >
> > won't apply without additional changes.
>
> Odd, let me see what happened, as I thought this was building properly
> on my test boxes...
Ah, I didn't have COMPILE_TEST enabled, now I see the problem, my fault,
I'll go fix this up now...
greg k-h
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 000/118] 3.12.6-stable review
2013-12-19 3:00 ` Greg Kroah-Hartman
@ 2013-12-19 3:20 ` Greg Kroah-Hartman
0 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-19 3:20 UTC (permalink / raw)
To: Guenter Roeck; +Cc: linux-kernel, torvalds, akpm, stable
On Wed, Dec 18, 2013 at 07:00:22PM -0800, Greg Kroah-Hartman wrote:
> On Wed, Dec 18, 2013 at 06:56:58PM -0800, Greg Kroah-Hartman wrote:
> > On Wed, Dec 18, 2013 at 03:48:57PM -0800, Guenter Roeck wrote:
> > > On Wed, Dec 18, 2013 at 01:10:37PM -0800, Greg Kroah-Hartman wrote:
> > > > This is the start of the stable review cycle for the 3.12.6 release.
> > > > There are 118 patches in this series, all will be posted as a response
> > > > to this one. If anyone has any issues with these being applied, please
> > > > let me know.
> > > >
> > > > Responses should be made by Fri Dec 20 21:12:03 UTC 2013.
> > > > Anything received after that time might be too late.
> > > >
> > >
> > > Hi greg,
> > >
> > > I see a couple of failed builds.
> > >
> > > m68k:allmodconfig ... failed
> > > mips:allmodconfig ... failed
> > > sparc64:allmodconfig ... failed
> > > x86_64:allyesconfig ... failed
> > > x86_64:allmodconfig ... failed
> > >
> > > Build is still going on, so there may be more.
> > >
> > > Error log:
> > >
> > > drivers/staging/comedi/drivers/ssv_dnp.c: In function 'dnp_dio_insn_bits':
> > > drivers/staging/comedi/drivers/ssv_dnp.c:63:2: error: implicit declaration of function 'comedi_dio_update_state' [-Werror=implicit-function-declaration]
> > > cc1: some warnings being treated as errors
> > > make[4]: *** [drivers/staging/comedi/drivers/ssv_dnp.o] Error 1
> > >
> > > Function comedi_dio_update_state() is not defined anywhere in 3.12,
> > > so patches
> > > staging: comedi: ssv_dnp: use comedi_dio_update_state()
> > > staging: comedi: drivers: use comedi_dio_update_state() for simple cases
> > >
> > > won't apply without additional changes.
> >
> > Odd, let me see what happened, as I thought this was building properly
> > on my test boxes...
>
> Ah, I didn't have COMPILE_TEST enabled, now I see the problem, my fault,
> I'll go fix this up now...
Ok, found this, it was my fault, I tried to take more of one of Ian's
patches than what he had actually sent me. I'll do a -rc2 in a few
minutes, thanks so much for the build testing.
greg k-h
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 000/118] 3.12.6-stable review
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (111 preceding siblings ...)
2013-12-18 23:48 ` [PATCH 3.12 000/118] 3.12.6-stable review Guenter Roeck
@ 2013-12-19 2:07 ` Guenter Roeck
2013-12-19 3:27 ` Greg Kroah-Hartman
` (3 subsequent siblings)
116 siblings, 0 replies; 196+ messages in thread
From: Guenter Roeck @ 2013-12-19 2:07 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel; +Cc: torvalds, akpm, stable
On 12/18/2013 01:10 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.12.6 release.
> There are 118 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri Dec 20 21:12:03 UTC 2013.
> Anything received after that time might be too late.
>
Build results:
total: 110 pass: 96 skipped: 3 fail: 11
qemu tests all passed.
Build failure log:
drivers/staging/comedi/drivers/ssv_dnp.c: In function 'dnp_dio_insn_bits':
drivers/staging/comedi/drivers/ssv_dnp.c:63:2: error: implicit declaration of function 'comedi_dio_update_state' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[4]: *** [drivers/staging/comedi/drivers/ssv_dnp.o] Error 1
due to the two patches I mentioned earlier.
Details are available as usual at http://server.roeck-us.net:8010/builders.
Guenter
^ permalink raw reply [flat|nested] 196+ messages in thread* Re: [PATCH 3.12 000/118] 3.12.6-stable review
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (112 preceding siblings ...)
2013-12-19 2:07 ` Guenter Roeck
@ 2013-12-19 3:27 ` Greg Kroah-Hartman
2013-12-19 6:17 ` Guenter Roeck
2013-12-19 15:58 ` Ryo Munakata
` (2 subsequent siblings)
116 siblings, 1 reply; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-19 3:27 UTC (permalink / raw)
To: linux-kernel; +Cc: torvalds, akpm, stable
On Wed, Dec 18, 2013 at 01:10:37PM -0800, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.12.6 release.
> There are 118 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri Dec 20 21:12:03 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.12.6-rc1.gz
> and the diffstat can be found below.
Thanks to a bug on my part, there's now a -rc2 out for people to test
with:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.12.6-rc2.gz
Note, if you didn't have a build-failure with -rc1 then no need to test
-rc2, it's only a specific staging driver that had an issue.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 196+ messages in thread* Re: [PATCH 3.12 000/118] 3.12.6-stable review
2013-12-19 3:27 ` Greg Kroah-Hartman
@ 2013-12-19 6:17 ` Guenter Roeck
2013-12-19 6:34 ` Greg Kroah-Hartman
0 siblings, 1 reply; 196+ messages in thread
From: Guenter Roeck @ 2013-12-19 6:17 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel; +Cc: torvalds, akpm, stable
On 12/18/2013 07:27 PM, Greg Kroah-Hartman wrote:
> On Wed, Dec 18, 2013 at 01:10:37PM -0800, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 3.12.6 release.
>> There are 118 patches in this series, all will be posted as a response
>> to this one. If anyone has any issues with these being applied, please
>> let me know.
>>
>> Responses should be made by Fri Dec 20 21:12:03 UTC 2013.
>> Anything received after that time might be too late.
>>
>> The whole patch series can be found in one patch at:
>> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.12.6-rc1.gz
>> and the diffstat can be found below.
>
> Thanks to a bug on my part, there's now a -rc2 out for people to test
> with:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.12.6-rc2.gz
>
> Note, if you didn't have a build-failure with -rc1 then no need to test
> -rc2, it's only a specific staging driver that had an issue.
>
Build results are much better:
total: 110 pass: 107 skipped: 3 fail: 0
qemu tests still all pass.
Guenter
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 000/118] 3.12.6-stable review
2013-12-19 6:17 ` Guenter Roeck
@ 2013-12-19 6:34 ` Greg Kroah-Hartman
0 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-19 6:34 UTC (permalink / raw)
To: Guenter Roeck; +Cc: linux-kernel, torvalds, akpm, stable
On Wed, Dec 18, 2013 at 10:17:23PM -0800, Guenter Roeck wrote:
> On 12/18/2013 07:27 PM, Greg Kroah-Hartman wrote:
> > On Wed, Dec 18, 2013 at 01:10:37PM -0800, Greg Kroah-Hartman wrote:
> >> This is the start of the stable review cycle for the 3.12.6 release.
> >> There are 118 patches in this series, all will be posted as a response
> >> to this one. If anyone has any issues with these being applied, please
> >> let me know.
> >>
> >> Responses should be made by Fri Dec 20 21:12:03 UTC 2013.
> >> Anything received after that time might be too late.
> >>
> >> The whole patch series can be found in one patch at:
> >> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.12.6-rc1.gz
> >> and the diffstat can be found below.
> >
> > Thanks to a bug on my part, there's now a -rc2 out for people to test
> > with:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.12.6-rc2.gz
> >
> > Note, if you didn't have a build-failure with -rc1 then no need to test
> > -rc2, it's only a specific staging driver that had an issue.
> >
>
> Build results are much better:
> total: 110 pass: 107 skipped: 3 fail: 0
>
> qemu tests still all pass.
Wonderful, thanks for testing and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 000/118] 3.12.6-stable review
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (113 preceding siblings ...)
2013-12-19 3:27 ` Greg Kroah-Hartman
@ 2013-12-19 15:58 ` Ryo Munakata
2013-12-19 16:10 ` Greg Kroah-Hartman
2013-12-19 20:48 ` Shuah Khan
2013-12-19 22:34 ` Satoru Takeuchi
116 siblings, 1 reply; 196+ messages in thread
From: Ryo Munakata @ 2013-12-19 15:58 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, torvalds, akpm, stable
On Wed, 18 Dec 2013 13:10:37 -0800
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> This is the start of the stable review cycle for the 3.12.6 release.
> There are 118 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri Dec 20 21:12:03 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.12.6-rc1.gz
> and the diffstat can be found below.
Results:
Target: 3.12.6-rc2
Patching: No errors
Compilation: No errors
Boot: No errors
dmesg: No regressions compared to the previous stable kernel
Looks good to me.
Test and build environment:
Dell System XPS L502X/0NJT03, BIOS A12 09/07/2012
CPU: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz
RAM: 4 GB
OS: Arch Linux
Arch: i686
Compiler: gcc (GCC) 4.8.2
Thanks.
--
Ryo Munakata <ryomnktml@gmail.com>
^ permalink raw reply [flat|nested] 196+ messages in thread* Re: [PATCH 3.12 000/118] 3.12.6-stable review
2013-12-19 15:58 ` Ryo Munakata
@ 2013-12-19 16:10 ` Greg Kroah-Hartman
0 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-19 16:10 UTC (permalink / raw)
To: Ryo Munakata; +Cc: linux-kernel, torvalds, akpm, stable
On Fri, Dec 20, 2013 at 12:58:51AM +0900, Ryo Munakata wrote:
> On Wed, 18 Dec 2013 13:10:37 -0800
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> > This is the start of the stable review cycle for the 3.12.6 release.
> > There are 118 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Fri Dec 20 21:12:03 UTC 2013.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.12.6-rc1.gz
> > and the diffstat can be found below.
>
>
> Results:
> Target: 3.12.6-rc2
> Patching: No errors
> Compilation: No errors
> Boot: No errors
> dmesg: No regressions compared to the previous stable kernel
>
> Looks good to me.
Thanks for testing and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 000/118] 3.12.6-stable review
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (114 preceding siblings ...)
2013-12-19 15:58 ` Ryo Munakata
@ 2013-12-19 20:48 ` Shuah Khan
2013-12-19 21:25 ` Greg Kroah-Hartman
2013-12-19 22:34 ` Satoru Takeuchi
116 siblings, 1 reply; 196+ messages in thread
From: Shuah Khan @ 2013-12-19 20:48 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, stable, Shuah Khan, shuahkhan
On 12/18/2013 02:10 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.12.6 release.
> There are 118 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri Dec 20 21:12:03 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.12.6-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Patch applied cleanly
Compile testing - passed
Boot testing - passed
dmesg regression testing - passed
dmesgs look good. No regressions compared to the previous dmesgs for
this release. dmesg emerg, crit, alert, err are clean. No regressions in
warn.
Test systems
Samsung Series 9 900X4C Intel Corei5 (3.4 and later)
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics
Dell OptiPlex 790 Intel(R) Core(TM) i5-2400
-- Shuah
--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah.kh@samsung.com | (970) 672-0658
^ permalink raw reply [flat|nested] 196+ messages in thread* Re: [PATCH 3.12 000/118] 3.12.6-stable review
2013-12-19 20:48 ` Shuah Khan
@ 2013-12-19 21:25 ` Greg Kroah-Hartman
0 siblings, 0 replies; 196+ messages in thread
From: Greg Kroah-Hartman @ 2013-12-19 21:25 UTC (permalink / raw)
To: Shuah Khan; +Cc: linux-kernel, torvalds, akpm, stable, shuahkhan
On Thu, Dec 19, 2013 at 01:48:13PM -0700, Shuah Khan wrote:
> On 12/18/2013 02:10 PM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.12.6 release.
> >There are 118 patches in this series, all will be posted as a response
> >to this one. If anyone has any issues with these being applied, please
> >let me know.
> >
> >Responses should be made by Fri Dec 20 21:12:03 UTC 2013.
> >Anything received after that time might be too late.
> >
> >The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.12.6-rc1.gz
> >and the diffstat can be found below.
> >
> >thanks,
> >
> >greg k-h
> >
>
> Patch applied cleanly
> Compile testing - passed
> Boot testing - passed
> dmesg regression testing - passed
>
> dmesgs look good. No regressions compared to the previous dmesgs for this
> release. dmesg emerg, crit, alert, err are clean. No regressions in warn.
Thanks for testing all 3 of these and letting me know they work.
greg k-h
^ permalink raw reply [flat|nested] 196+ messages in thread
* Re: [PATCH 3.12 000/118] 3.12.6-stable review
2013-12-18 21:10 [PATCH 3.12 000/118] 3.12.6-stable review Greg Kroah-Hartman
` (115 preceding siblings ...)
2013-12-19 20:48 ` Shuah Khan
@ 2013-12-19 22:34 ` Satoru Takeuchi
116 siblings, 0 replies; 196+ messages in thread
From: Satoru Takeuchi @ 2013-12-19 22:34 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, torvalds, akpm, stable
At Wed, 18 Dec 2013 13:10:37 -0800,
Greg Kroah-Hartman wrote:
>
> This is the start of the stable review cycle for the 3.12.6 release.
> There are 118 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri Dec 20 21:12:03 UTC 2013.
> Anything received after that time might be too late.
All 3.4.75-rc1, 3.10.25-rc1, and 3.12.6-rc1 can be built and boot without
any problem. Building a kernel with these kernels also works fine.
- test tool:
https://github.com/satoru-takeuchi/test-linux-stable
- test results(kernel .config, ktest config and test log):
http://satoru-takeuchi.org/test-linux-stable/results/<version>-<test datetime>
- Build Machine: debian jessy x86_64
CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
memory: 8GB
- Test machine: debian jessy x86_64(KVM guest on the Build Machine)
vCPU: x2
memory: 2GB
Thanks,
Satoru
^ permalink raw reply [flat|nested] 196+ messages in thread