Re: [ 11/83] module: fix out-by-one error in kallsyms
On Fri, Nov 23, 2012 at 07:35:36PM +0900, satoru takeuchi wrote:
> Hi,
>
> 2012/11/22 Greg Kroah-Hartman :
> > 3.6-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Rusty Russell
> >
> > commit 59ef28b1f14899b10d6b2682c7057ca00a9a3f47 upstream.
> >
> > Masaki found and patched a kallsyms issue: the last symbol in a
> > module's symtab wasn't transferred. This is because we manually copy
> > the zero'th entry (which is always empty) then copy the rest in a loop
> > starting at 1, though from src[0]. His fix was minimal, I prefer to
> > rewrite the loops in more standard form.
> >
> > There are two loops: one to get the size, and one to copy. Make these
> > identical: always count entry 0 and any defined symbol in an allocated
> > non-init section.
> >
> > This bug exists since the following commit was introduced.
> >module: reduce symbol table for loaded modules (v2)
> >commit: 4a4962263f07d14660849ec134ee42b63e95ea9a
> >
> > LKML: http://lkml.org/lkml/2012/10/24/27
> > Reported-by: Masaki Kimura
> > Signed-off-by: Rusty Russell
> > Signed-off-by: Greg Kroah-Hartman
> >
> > ---
> > kernel/module.c | 27 ---
> > 1 file changed, 16 insertions(+), 11 deletions(-)
> >
> > --- a/kernel/module.c
> > +++ b/kernel/module.c
> > @@ -2273,12 +2273,17 @@ static void layout_symtab(struct module
> > src = (void *)info->hdr + symsect->sh_offset;
> > nsrc = symsect->sh_size / sizeof(*src);
> >
> > + /* strtab always starts with a nul, so offset 0 is the empty
> > string. */
> > + strtab_size = 1;
> > +
>
> I suspect above code sniped is not needed since the size of src[0](always 1)
> is
> counted at the following code("strtab_size += strlen(..) + 1;").
>
> > /* Compute total space required for the core symbols' strtab. */
> > - for (ndst = i = strtab_size = 1; i < nsrc; ++i, ++src)
> > - if (is_core_symbol(src, info->sechdrs, info->hdr->e_shnum))
> > {
> > - strtab_size += strlen(&info->strtab[src->st_name])
> > + 1;
> > + for (ndst = i = 0; i < nsrc; i++) {
> > + if (i == 0 ||
> > + is_core_symbol(src+i, info->sechdrs,
> > info->hdr->e_shnum)) {
>
> src[i] rather than src+1 is better as kallsyms();
>
> > + strtab_size +=
> > strlen(&info->strtab[src[i].st_name])+1;
> > ndst++;
> > }
> > + }
> >
> > /* Append room for core symbols at end of core part. */
> > info->symoffs = ALIGN(mod->core_size, symsect->sh_addralign ?: 1);
> > @@ -2312,15 +2317,15 @@ static void add_kallsyms(struct module *
> > mod->core_symtab = dst = mod->module_core + info->symoffs;
> > mod->core_strtab = s = mod->module_core + info->stroffs;
> > src = mod->symtab;
> > - *dst = *src;
> > *s++ = 0;
>
> This "*s++"line is also not needed since the content of src[0] is copied in
> the
> following loop.
>
> If my understanding is correct, the allsym table becomes as follows by
> applying this patch.
>
> ==
> \0\0\0\0... # "\0" means null
> character in this case
> ==
>
> It should be as follows.
>
>
> \0\0\0...
>
>
> This patch would work, but need extra one byte per module. Olease let
> us know if I misunderstand something.
> I didn't confirm with real machine.
Please confirm with a real machine, and if the problem is there, please
submit a patch to get it changed in Linus's tree, which is where this
patch came from.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ 35/83] ARM: imx: ehci: fix host power mask bit
On Wed, Nov 21, 2012 at 11:52:25PM -0500, Michael D. Burkey wrote: > This patch is definitely needed -- it is obviously setting the wrong > bit -- but I am still doing testing to see what other complications > may arise from actually setting the RIGHT bit (i.e. I've seen some > odd results so far and suspect some other code may have been changed > historically to account for the wrong behaviour this bit was > causing). > > We're currently on vacation for Thanksgiving over here in the USA > and I won't be back in the office til next week. > > If you would, hold off on adding the patch to the stable kernel > until I have a bit more time to check out a couple of things. As it's already in Linus's tree, one would have hoped that the patch would have been tested already :) I'll leave it in the stable tree, if it's a problem, please get the fix into Linus's tree, and then have that fix submitted to the stable kernel trees. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 05/38] ptp: update adjfreq callback description
On Fri, Nov 23, 2012 at 10:26:01PM -0200, Herton Ronaldo Krzesinski wrote:
> On Wed, Nov 21, 2012 at 04:39:48PM -0800, Greg Kroah-Hartman wrote:
> > 3.0-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Jacob Keller
> >
> > commit 87f4d7c1d36f44b0822053b7e5dedc31fdd0ab99 upstream.
> >
> > This patch updates the adjfreq callback description to include a note that
> > the
> > delta in ppb is always relative to the base frequency, and not to the
> > current
> > frequency of the hardware clock.
> >
> > Signed-off-by: Jacob Keller
> > CC: Richard Cochran
> > CC: John Stultz
> > Signed-off-by: Jeff Kirsher
> > Signed-off-by: David S. Miller
> > Signed-off-by: Greg Kroah-Hartman
> >
> > ---
> > include/linux/ptp_clock_kernel.h |3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > --- a/include/linux/ptp_clock_kernel.h
> > +++ b/include/linux/ptp_clock_kernel.h
> > @@ -50,7 +50,8 @@ struct ptp_clock_request {
> > * clock operations
> > *
> > * @adjfreq: Adjusts the frequency of the hardware clock.
> > - *parameter delta: Desired period change in parts per billion.
> > + *parameter delta: Desired frequency offset from nominal
> > frequency
> > + *in parts per billion
> > *
> > * @adjtime: Shifts the time of the hardware clock.
> > *parameter delta: Desired change in nanoseconds.
>
> This was marked for only 3.5 or later on the original changelog:
> "CC: sta...@vger.kernel.org [v3.5+]"
Ugh, my fault, now dropped from the 3.0 and 3.4-stable trees, thanks for
finding my error.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ 37/38] PCI : ability to relocate assigned pci-resources
On Sat, Nov 24, 2012 at 09:41:41AM +0800, Ram Pai wrote: > On Fri, Nov 23, 2012 at 11:29:20AM -0200, Herton Ronaldo Krzesinski wrote: > > On Wed, Nov 21, 2012 at 04:40:20PM -0800, Greg Kroah-Hartman wrote: > > > 3.0-stable review patch. If anyone has any objections, please let me > > > know. > > > > > > -- > > > > > > From: Ram Pai > > > > > > commit 2bbc6942273b5b3097bd265d82227bdd84b351b2 upstream. > > > > > > Currently pci-bridges are allocated enough resources to satisfy their > > > immediate > > > requirements. Any additional resource-requests fail if additional free > > > space, > > > contiguous to the one already allocated, is not available. This behavior > > > is not > > > reasonable since sufficient contiguous resources, that can satisfy the > > > request, > > > are available at a different location. > > > > > > This patch provides the ability to expand and relocate a allocated > > > resource. > > > > > > v2: Changelog: Fixed size calculation in pci_reassign_resource() > > > v3: Changelog : Split this patch. The resource.c changes are already > > > upstream. All the pci driver changes are in here. > > > > > > Signed-off-by: Ram Pai > > > Signed-off-by: Jesse Barnes > > > Cc: Andrew Worsley > > > Signed-off-by: Greg Kroah-Hartman > > > > This change is said to bring a regression: > > http://comments.gmane.org/gmane.linux.kernel.pci/11666 > > > > fixed by: > > commit 47ea91b4052d9e94b9dca5d7a3d947fbebd07ba9 > > Resource: fix wrong resource window calculation > > > > Which wasn't applied with this series for 3.0. > > You are right. We need to apply that fix along with this patch. Thanks, now added to the tree. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold
On Fri, Nov 23, 2012 at 11:09:37AM +0800, Huang Ying wrote: > On Fri, 2012-11-23 at 02:35 +, Ben Hutchings wrote: > > On Wed, 2012-11-21 at 16:39 -0800, Greg Kroah-Hartman wrote: > > > 3.0-stable review patch. If anyone has any objections, please let me > > > know. > > > > > > -- > > > > > > From: Huang Ying > > > > > > commit 90b5c1d7c45eeb622302680ff96ed30c1a2b6f0e upstream. > > > > > > If a PCI device and its parents are put into D3cold, unbinding the > > > device will trigger deadlock as follow: > > > > > > - driver_unbind > > > - device_release_driver > > > - device_lock(dev)<--- previous lock here > > > - __device_release_driver > > > - pm_runtime_get_sync > > > ... > > > - rpm_resume(dev) > > > - rpm_resume(dev->parent) > > > ... > > > - pci_pm_runtime_resume > > > ... > > > - pci_set_power_state > > > - __pci_start_power_transition > > > - pci_wakeup_bus(dev->parent->subordinate) > > > - pci_walk_bus > > > - device_lock(dev) <--- deadlock here > > > > > > > > > If we do not do device_lock in pci_walk_bus, we can avoid deadlock. > > > Device_lock in pci_walk_bus is introduced in commit: > > > d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread > > > is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin > > > said device_lock is added to pci_walk_bus because: > > > > > > Some error handling functions call pci_walk_bus. For example, PCIe > > > aer. Here we lock the device, so the driver wouldn't detach from the > > > device, as the cb might call driver's callback function. > > > > > > So I fixed the deadlock as follows: > > > > > > - remove device_lock from pci_walk_bus > > > - add device_lock into callback if callback will call driver's callback > > > > > > I checked pci_walk_bus users one by one, and found only PCIe aer needs > > > device lock. > > [...] > > > > What about eeh_report_error() in > > arch/powerpc/platforms/pseries/eeh_driver.c? > > En... Because pci_walk_bus() invocation is removed in 3.7, so this > patch is only valid for 3.7. We need another version for 3.6. > > > Also, is the deadlock even possible before this change in Linux 3.6? > > > > commit 448bd857d48e69b33ef323739dc6d8ca20d4cda7 > > Author: Huang Ying > > Date: Sat Jun 23 10:23:51 2012 +0800 > > > > PCI/PM: add PCIe runtime D3cold support > > Before this, there will be no deadlock. So we do not need fixes before > Linux 3.6. So the first patch mentioned here should not be included in the 3.0 and 3.4 stable kernel releases? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 117/171] libceph: drop ceph_con_get/put helpers and nref member
On Fri, Nov 23, 2012 at 11:41:47AM -0200, Herton Ronaldo Krzesinski wrote:
> On Wed, Nov 21, 2012 at 04:41:03PM -0800, Greg Kroah-Hartman wrote:
> > 3.4-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Sage Weil
> >
> > (cherry picked from commit d59315ca8c0de00df9b363f94a2641a30961ca1c)
> >
> > These are no longer used. Every ceph_connection instance is embedded in
> > another structure, and refcounts manipulated via the get/put ops.
> >
> > Signed-off-by: Sage Weil
> > Signed-off-by: Greg Kroah-Hartman
> [...]
> >
> > /*
> > - * generic get/put
> > - */
> > -struct ceph_connection *ceph_con_get(struct ceph_connection *con)
> > -{
> > - int nref = __atomic_add_unless(&con->nref, 1, 0);
> > -
> > - dout("con_get %p nref = %d -> %d\n", con, nref, nref + 1);
> > -
> > - return nref ? con : NULL;
> > -}
> > -
> > -void ceph_con_put(struct ceph_connection *con)
> > -{
> > - int nref = atomic_dec_return(&con->nref);
> > -
> > - BUG_ON(nref < 0);
> > - if (nref == 0) {
> > - BUG_ON(con->sock);
> > - kfree(con);
> > - }
> > - dout("con_put %p nref = %d -> %d\n", con, nref + 1, nref);
> > -}
> > -
> > -/*
> > * initialize a new connection.
>
> Although harmless in functionality not having it, may be it would be
> good to also apply with this also the following commit:
>
> commit 261030215d970c62f799e6e508e3c68fc7ec2aa9
> Author: Alex Elder
> Date: Thu Jun 21 12:49:23 2012 -0700
>
> libceph: drop declaration of ceph_con_get()
>
> For some reason the declaration of ceph_con_get() and
> ceph_con_put() did not get deleted in this commit:
> d59315ca libceph: drop ceph_con_get/put helpers and nref member
>
> Clean that up.
Ok, now added, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold
On Mon, Nov 26, 2012 at 10:55:05AM -0800, Greg Kroah-Hartman wrote: > On Fri, Nov 23, 2012 at 11:09:37AM +0800, Huang Ying wrote: > > On Fri, 2012-11-23 at 02:35 +, Ben Hutchings wrote: > > > On Wed, 2012-11-21 at 16:39 -0800, Greg Kroah-Hartman wrote: > > > > 3.0-stable review patch. If anyone has any objections, please let me > > > > know. > > > > > > > > -- > > > > > > > > From: Huang Ying > > > > > > > > commit 90b5c1d7c45eeb622302680ff96ed30c1a2b6f0e upstream. > > > > > > > > If a PCI device and its parents are put into D3cold, unbinding the > > > > device will trigger deadlock as follow: > > > > > > > > - driver_unbind > > > > - device_release_driver > > > > - device_lock(dev) <--- previous lock here > > > > - __device_release_driver > > > > - pm_runtime_get_sync > > > > ... > > > > - rpm_resume(dev) > > > > - rpm_resume(dev->parent) > > > > ... > > > > - pci_pm_runtime_resume > > > > ... > > > > - pci_set_power_state > > > > - __pci_start_power_transition > > > > - pci_wakeup_bus(dev->parent->subordinate) > > > > - pci_walk_bus > > > > - device_lock(dev)<--- deadlock here > > > > > > > > > > > > If we do not do device_lock in pci_walk_bus, we can avoid deadlock. > > > > Device_lock in pci_walk_bus is introduced in commit: > > > > d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread > > > > is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin > > > > said device_lock is added to pci_walk_bus because: > > > > > > > > Some error handling functions call pci_walk_bus. For example, PCIe > > > > aer. Here we lock the device, so the driver wouldn't detach from the > > > > device, as the cb might call driver's callback function. > > > > > > > > So I fixed the deadlock as follows: > > > > > > > > - remove device_lock from pci_walk_bus > > > > - add device_lock into callback if callback will call driver's callback > > > > > > > > I checked pci_walk_bus users one by one, and found only PCIe aer needs > > > > device lock. > > > [...] > > > > > > What about eeh_report_error() in > > > arch/powerpc/platforms/pseries/eeh_driver.c? > > > > En... Because pci_walk_bus() invocation is removed in 3.7, so this > > patch is only valid for 3.7. We need another version for 3.6. > > > > > Also, is the deadlock even possible before this change in Linux 3.6? > > > > > > commit 448bd857d48e69b33ef323739dc6d8ca20d4cda7 > > > Author: Huang Ying > > > Date: Sat Jun 23 10:23:51 2012 +0800 > > > > > > PCI/PM: add PCIe runtime D3cold support > > > > Before this, there will be no deadlock. So we do not need fixes before > > Linux 3.6. > > So the first patch mentioned here should not be included in the 3.0 and > 3.4 stable kernel releases? Ok, I've dropped the patch from 3.0 and 3.4-stable trees now. For 3.6, what should I do? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold
On Mon, Nov 26, 2012 at 11:08:18AM -0800, Greg Kroah-Hartman wrote: > On Mon, Nov 26, 2012 at 10:55:05AM -0800, Greg Kroah-Hartman wrote: > > On Fri, Nov 23, 2012 at 11:09:37AM +0800, Huang Ying wrote: > > > On Fri, 2012-11-23 at 02:35 +, Ben Hutchings wrote: > > > > On Wed, 2012-11-21 at 16:39 -0800, Greg Kroah-Hartman wrote: > > > > > 3.0-stable review patch. If anyone has any objections, please let me > > > > > know. > > > > > > > > > > -- > > > > > > > > > > From: Huang Ying > > > > > > > > > > commit 90b5c1d7c45eeb622302680ff96ed30c1a2b6f0e upstream. > > > > > > > > > > If a PCI device and its parents are put into D3cold, unbinding the > > > > > device will trigger deadlock as follow: > > > > > > > > > > - driver_unbind > > > > > - device_release_driver > > > > > - device_lock(dev)<--- previous > > > > > lock here > > > > > - __device_release_driver > > > > > - pm_runtime_get_sync > > > > > ... > > > > > - rpm_resume(dev) > > > > > - rpm_resume(dev->parent) > > > > > ... > > > > > - pci_pm_runtime_resume > > > > > ... > > > > > - pci_set_power_state > > > > > - __pci_start_power_transition > > > > > - pci_wakeup_bus(dev->parent->subordinate) > > > > > - pci_walk_bus > > > > > - device_lock(dev) <--- deadlock here > > > > > > > > > > > > > > > If we do not do device_lock in pci_walk_bus, we can avoid deadlock. > > > > > Device_lock in pci_walk_bus is introduced in commit: > > > > > d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread > > > > > is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin > > > > > said device_lock is added to pci_walk_bus because: > > > > > > > > > > Some error handling functions call pci_walk_bus. For example, PCIe > > > > > aer. Here we lock the device, so the driver wouldn't detach from the > > > > > device, as the cb might call driver's callback function. > > > > > > > > > > So I fixed the deadlock as follows: > > > > > > > > > > - remove device_lock from pci_walk_bus > > > > > - add device_lock into callback if callback will call driver's > > > > > callback > > > > > > > > > > I checked pci_walk_bus users one by one, and found only PCIe aer needs > > > > > device lock. > > > > [...] > > > > > > > > What about eeh_report_error() in > > > > arch/powerpc/platforms/pseries/eeh_driver.c? > > > > > > En... Because pci_walk_bus() invocation is removed in 3.7, so this > > > patch is only valid for 3.7. We need another version for 3.6. > > > > > > > Also, is the deadlock even possible before this change in Linux 3.6? > > > > > > > > commit 448bd857d48e69b33ef323739dc6d8ca20d4cda7 > > > > Author: Huang Ying > > > > Date: Sat Jun 23 10:23:51 2012 +0800 > > > > > > > > PCI/PM: add PCIe runtime D3cold support > > > > > > Before this, there will be no deadlock. So we do not need fixes before > > > Linux 3.6. > > > > So the first patch mentioned here should not be included in the 3.0 and > > 3.4 stable kernel releases? > > Ok, I've dropped the patch from 3.0 and 3.4-stable trees now. > > For 3.6, what should I do? Ok, for now, I've dropped this patch from 3.6-stable as well. If you think it still needs to go there, can you provide something that works? I see you posted one patch in this thread, but I don't understand if that is what needs to go upstream in Linus's tree, or if it is for the 3.6-stable tree. Please clarify. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: [PATCH] dma-mapping: fix dma_common_get_sgtable() conditional compilation
On Mon, Nov 26, 2012 at 06:18:37PM -0200, Mauro Carvalho Chehab wrote: > Hi Greg, > > Are you maintaining drivers/base/dma-mapping.c? The enclosed path is needed to > enable DMABUF handling on V4L2 on some architectures, like x86_64, as we need > dma_common_get_sgtable() on drivers/media/v4l2-core/videobuf2-dma-contig.c. > > Would you mind acking it, in order to let this patch flow via my tree? This > way, > I can revert a workaround I had to apply there, in order to avoid linux-next > compilation breakage. > > Thanks! > Mauro > > - > > From: Marek Szyprowski > Date: Mon, 26 Nov 2012 14:41:48 +0100 > > dma_common_get_sgtable() function doesn't depend on > ARCH_HAS_DMA_DECLARE_COHERENT_MEMORY, so it must not be compiled > conditionally. > > Reported-by: Stephen Rothwell > Signed-off-by: Marek Szyprowski Acked-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3] tty: Added a CONFIG_TTY option to allow removal of TTY
On Thu, Nov 15, 2012 at 06:30:35PM -0800, Joe Millenbach wrote: > The option allows you to remove TTY and compile without errors. This > saves space on systems that won't support TTY interfaces anyway. > bloat-o-meter output is below. > > The bulk of this patch consists of Kconfig changes adding "depends on > TTY" to various serial devices and similar drivers that require the TTY > layer. Ideally, these dependencies would occur on a common intermediate > symbol such as SERIO, but most drivers "select SERIO" rather than > "depends on SERIO", and "select" does not respect dependencies. > > bloat-o-meter output filtered to not show removed entries with awk > '$3 != "-"' as the list was very long. > > add/remove: 0/385 grow/shrink: 2/18 up/down: 14/-54016 (-54002) > function old new delta > chr_dev_init 193 205 +12 > selinux_setprocattr 11671169 +2 > static.__warned 557 556 -1 > start_kernel 840 835 -5 > proc_root_init 167 162 -5 > unregister_console 165 157 -8 > sys_setsid 213 205 -8 > sys_vhangup 37 21 -16 > daemonize689 673 -16 > t_stop72 54 -18 > t_next 129 108 -21 > static.do_acct_process 838 806 -32 > release_task11571125 -32 > do_exit 23252288 -37 > t_start 269 221 -48 > static.__func__18289 18219 -70 > do_task_stat29622892 -70 > flush_unauthorized_files 740 614-126 > static._rs 14401280-160 > static.__key85608384-176 > > Signed-off-by: Joe Millenbach > Reviewed-by: Josh Triplett This is a nice idea, but I feel it's a bit too late in the 3.8 merge window cycle for me to add this to linux-next at this point in time. Can you rediff this once 3.8-rc1 is out and send it to me then? That way we can get a lot more testing in linux-next in order to make sure it's ready for 3.9? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] memory: tegra30: Fix warning w/o PM_SLEEP
On Mon, Nov 26, 2012 at 12:33:58PM -0700, Stephen Warren wrote: > On 11/21/2012 05:42 AM, Hiroshi Doyu wrote: > > Fix build warning w/o PM_SLEEP. > > Reviewed-by: Stephen Warren > > I assume Greg will take this through his tree. If so, someone better resend it... > > Change-Id: I713f7dd697f1ad9fb1fee56b389b0d6c45bb540c > > But that shouldn't be there though... Agreed, that's not ok. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 9/9] TTY: call tty_port_destroy in the rest of drivers
On Tue, Nov 27, 2012 at 11:52:09AM -0500, Peter Hurley wrote: > On Thu, 2012-11-15 at 09:49 +0100, Jiri Slaby wrote: > > After commit "TTY: move tty buffers to tty_port", the tty buffers are > > not freed in some drivers. This is because tty_port_destructor is not > > called whenever a tty_port is freed. This was an assumption I counted > > with but was unfortunately untrue. So fix the drivers to fulfil this > > assumption. > > > > To be sure, the TTY buffers (and later some stuff) are gone along with > > the tty_port, we have to call tty_port_destroy at tear-down places. > > This is mostly where the structure containing a tty_port is freed. > > This patch does exactly that -- put tty_port_destroy at those places. > > > > Signed-off-by: Jiri Slaby > > Hi Jiri & Greg & Alan, > > I'd be more than willing to fixup staging/fwserial against this series > but I'm unclear on the mechanics since this series isn't in staging-next > and staging/fwserial isn't in tty-next. The series is in tty-next, right? Make it against linux-next, which has the trees combined, and I'll work to figure it out when/where to apply it. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tty: don't dead while flushing workqueue
On Tue, Nov 27, 2012 at 10:53:57AM +0100, Sebastian Andrzej Siewior wrote: > On Wed, Nov 21, 2012 at 02:04:26PM +, Alan Cox wrote: > > > I don't see any problems in my testcase. > > > > This looks fine to me as by the time we call tty_ldisc_release we have > > already set TTY_CLOSING on both sides. > > Greg, can you push this into v3.7? This regression has been introduced in > v3.7-rc1. If you don't consider it as this important since I'm only one > complaining, could you please add a stable tag once you apply it unless you > want me resend it with a stable tag. I don't see this patch anywhere in my queue, or in the tty-next tree, so someone is going to have to resend it please. And yes, it's a bit too late for 3.7, but I don't have an issue with merging it for 3.8-rc1 and tagging it for 3.7-stable. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] tty: Add driver unthrottle in ioctl(...,TCFLSH,..).
On Tue, Nov 27, 2012 at 10:14:33AM +0400, Ilya Zykov wrote: > Sorry. More correct. In what way? Should I wait for the 6th version? :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/9] Media Controller capture driver for DM365
On Wed, Nov 28, 2012 at 10:18:02AM -0200, Mauro Carvalho Chehab wrote: > Em Wed, 28 Nov 2012 12:56:10 +0100 > Hans Verkuil escreveu: > > > On Wed 28 November 2012 12:45:37 Dan Carpenter wrote: > > > I wish people wouldn't submit big patches right before the merge > > > window opens... :/ It's better to let it sit in linux-next for a > > > couple weeks so people can mess with it a bit. > > > > It's been under review for quite some time now, and the main change since > > the last posted version is that this is now moved to staging/media. > > > > So it is not yet ready for prime time, but we do want it in to simplify > > the last remaining improvements needed to move it to drivers/media. > > "last remaining improvements"? I didn't review the patchset, but > the TODO list seems to have several pending stuff there: > > +- User space interface refinement > +- Controls should be used when possible rather than private ioctl > +- No enums should be used > +- Use of MC and V4L2 subdev APIs when applicable > +- Single interface header might suffice > +- Current interface forces to configure everything at once > +- Get rid of the dm365_ipipe_hw.[ch] layer > +- Active external sub-devices defined by link configuration; no strcmp > + needed > +- More generic platform data (i2c adapters) > +- The driver should have no knowledge of possible external subdevs; see > + struct vpfe_subdev_id > +- Some of the hardware control should be refactorede > +- Check proper serialisation (through mutexes and spinlocks) > +- Names that are visible in kernel global namespace should have a common > + prefix (or a few) > > From the above comments, both Kernelspace and Userspace APIs require > lots of work. > > Also, it is not clear at all if this is a fork of the existing davinci > driver, or if it is a completely new driver for an already-supported > hardware, making very hard (if not impossible) to review it, and, if it > is yet-another-driver for the same hardware, moving it out of staging > will be a big issue, as it won't be trivial to check for regressions > introduced by a different driver. > > > > > I'm happy with this going in given the circumstances. > > Well, I'm not. Me either, it is way too late in the cycle to take huge stuff for 3.8, sorry. But as I don't manage drivers/staging/media/ there's not even anything I can do here, it's Mauro's, so I'll leave it up to him :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/9] Media Controller capture driver for DM365
On Wed, Nov 28, 2012 at 08:18:20PM +0100, Hans Verkuil wrote: > On Wed November 28 2012 18:22:48 Greg Kroah-Hartman wrote: > > On Wed, Nov 28, 2012 at 10:18:02AM -0200, Mauro Carvalho Chehab wrote: > > > Em Wed, 28 Nov 2012 12:56:10 +0100 > > > Hans Verkuil escreveu: > > > > > > > On Wed 28 November 2012 12:45:37 Dan Carpenter wrote: > > > > > I wish people wouldn't submit big patches right before the merge > > > > > window opens... :/ It's better to let it sit in linux-next for a > > > > > couple weeks so people can mess with it a bit. > > > > > > > > It's been under review for quite some time now, and the main change > > > > since > > > > the last posted version is that this is now moved to staging/media. > > > > > > > > So it is not yet ready for prime time, but we do want it in to simplify > > > > the last remaining improvements needed to move it to drivers/media. > > > > > > "last remaining improvements"? I didn't review the patchset, but > > > the TODO list seems to have several pending stuff there: > > > > > > +- User space interface refinement > > > +- Controls should be used when possible rather than private ioctl > > > +- No enums should be used > > > +- Use of MC and V4L2 subdev APIs when applicable > > > +- Single interface header might suffice > > > +- Current interface forces to configure everything at once > > > +- Get rid of the dm365_ipipe_hw.[ch] layer > > > +- Active external sub-devices defined by link configuration; no strcmp > > > + needed > > > +- More generic platform data (i2c adapters) > > > +- The driver should have no knowledge of possible external subdevs; see > > > + struct vpfe_subdev_id > > > +- Some of the hardware control should be refactorede > > > +- Check proper serialisation (through mutexes and spinlocks) > > > +- Names that are visible in kernel global namespace should have a common > > > + prefix (or a few) > > > > > > From the above comments, both Kernelspace and Userspace APIs require > > > lots of work. > > And that's why it is in staging. Should a long TODO list now suddenly > prevent staging from being used? In Barcelona we discussed this and the > only requirement we came up was was that it should compile. Yes, that's all I care about in staging, but as I stated, I don't maintain drivers/staging/media/ that area is under Mauro's control (MAINTAINERS even says this), and I'm a bit leery of going against the wishes of an existing subsystem maintainer for adding staging drivers that tie into their subsystem. So if you get Mauro's approval, I'll be glad to queue it up. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/9] Media Controller capture driver for DM365
On Wed, Nov 28, 2012 at 08:30:04PM +0100, Sylwester Nawrocki wrote: > On 11/28/2012 01:22 PM, Dan Carpenter wrote: > > In the end this is just a driver, and I don't especially care. But > > it's like not just this one which makes me frustrated. I really > > believe in linux-next and I think everything should spend a couple > > weeks there before being merged. > > Couple of weeks in linux-next plus a couple of weeks of final patch > series version awaiting to being reviewed and picked up by a maintainer > makes almost entire kernel development cycle. If I were to take this today, it would only live in linux-next for less than a week before it would be sent to Linus due to where we are in the development cycle, so Dan's objections are quite valid. > These are huge additional delays, especially in the embedded world. Embedded is special just like everyone else. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HOTPLUG replated patches
On Thu, Nov 29, 2012 at 09:04:12AM +1100, Stephen Rothwell wrote: > Hi all, > > I haven't been closely following things, but is there any reason that a > large number of these CONFIG_HOTPLUG and __dev* patches are being merged > via the driver-core tree rather than through the relevant maintainers > trees? They aren't particularly urgent as far as I can see. And they > already have, and probably will, cause unnecessary conflicts between > trees. I merged the ones that were acked by the subsystem maintainer through my driver-core tree. Others are coming in through the subsystem maintainer's trees, as they have applied them there. So it's a mix, depending on the subsystem maintainer's wishes. And yes, it's going to be a bunch of trivial merge issues, sorry about that, I don't know of any other way at the moment to deal with that. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TDM bus support in Linux Kernel
On Mon, Nov 19, 2012 at 11:00:12AM +, Kurachkin Michail wrote: > Hi Greg, > > During the work on developing VoIP network router I designed TDM bus > subsystem and wrote SLIC driver for si3226x. This code was developed for the > commercial project, and now I am willing to release it under GPL. > Please review my sources (or give me a clue on what to do next) and give some > feedback on my work. > https://github.com/stelhs/slic_tdm.git It's really hard to review a random git tree somewhere, and having it in this form doesn't make it easy to add to the kernel tree itself. So, could you take your git tree and convert it to a patch (or patches) to be applied to the kernel.org tree and send it in email so we can see what it looks like that way? I'd recommend putting everything under drivers/staging/ for now, to make it easier to accept at the moment, and it makes it easier to clean up and fix up any issues in-kernel, instead of having to keep huge patches outside of the tree. Take a look at the file, Documentation/SubmittingPatches for how to create a patch and what I need in order for it to be able to be applied. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] fs:sysfs pass NULL as second parameter for set_anon_super
On Thu, Nov 29, 2012 at 12:05:45PM +0530, Abhijit Pawar wrote: > set_anon_super does not use the second parameter in its implementation. > So there is no need to pass on the second parameter. Why not just remove the second parameter from the call then? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] Remove __dev* sections from the kernel
With the recent work to remove CONFIG_HOTPLUG, we are starting to get a bunch of __devinit section warnings, despite CONFIG_HOTPLUG always being enabled. So lets remove these false warnings by removing the check for them in the modpost.c tool. Also, lets stop marking the sections entirely, so define away the section markings in init.h I'll queue these two patches up through my driver-core git tree, which has the bulk of the __dev* marking removal patches in it. If anyone has any objections to this, please let me know. thanks, greg k-h --- include/linux/init.h | 18 +++--- scripts/mod/modpost.c | 24 ++-- 2 files changed, 17 insertions(+), 25 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] modpost.c: Stop checking __dev* section mismatches
From: Greg Kroah-Hartman
Now that the __dev* sections are not being generated, we don't need to
check for them in modpost.c.
Signed-off-by: Greg Kroah-Hartman
---
scripts/mod/modpost.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 0d93856..ff36c50 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -858,25 +858,23 @@ static void check_section(const char *modname, struct
elf_info *elf,
#define ALL_INIT_DATA_SECTIONS \
".init.setup$", ".init.rodata$", \
- ".devinit.rodata$", ".cpuinit.rodata$", ".meminit.rodata$", \
- ".init.data$", ".devinit.data$", ".cpuinit.data$", ".meminit.data$"
+ ".cpuinit.rodata$", ".meminit.rodata$", \
+ ".init.data$", ".cpuinit.data$", ".meminit.data$"
#define ALL_EXIT_DATA_SECTIONS \
- ".exit.data$", ".devexit.data$", ".cpuexit.data$", ".memexit.data$"
+ ".exit.data$", ".cpuexit.data$", ".memexit.data$"
#define ALL_INIT_TEXT_SECTIONS \
- ".init.text$", ".devinit.text$", ".cpuinit.text$", ".meminit.text$"
+ ".init.text$", ".cpuinit.text$", ".meminit.text$"
#define ALL_EXIT_TEXT_SECTIONS \
- ".exit.text$", ".devexit.text$", ".cpuexit.text$", ".memexit.text$"
+ ".exit.text$", ".cpuexit.text$", ".memexit.text$"
#define ALL_PCI_INIT_SECTIONS \
".pci_fixup_early$", ".pci_fixup_header$", ".pci_fixup_final$", \
".pci_fixup_enable$", ".pci_fixup_resume$", \
".pci_fixup_resume_early$", ".pci_fixup_suspend$"
-#define ALL_XXXINIT_SECTIONS DEV_INIT_SECTIONS, CPU_INIT_SECTIONS, \
- MEM_INIT_SECTIONS
-#define ALL_XXXEXIT_SECTIONS DEV_EXIT_SECTIONS, CPU_EXIT_SECTIONS, \
- MEM_EXIT_SECTIONS
+#define ALL_XXXINIT_SECTIONS CPU_INIT_SECTIONS, MEM_INIT_SECTIONS
+#define ALL_XXXEXIT_SECTIONS CPU_EXIT_SECTIONS, MEM_EXIT_SECTIONS
#define ALL_INIT_SECTIONS INIT_SECTIONS, ALL_XXXINIT_SECTIONS
#define ALL_EXIT_SECTIONS EXIT_SECTIONS, ALL_XXXEXIT_SECTIONS
@@ -885,12 +883,10 @@ static void check_section(const char *modname, struct
elf_info *elf,
#define TEXT_SECTIONS ".text$"
#define INIT_SECTIONS ".init.*"
-#define DEV_INIT_SECTIONS ".devinit.*"
#define CPU_INIT_SECTIONS ".cpuinit.*"
#define MEM_INIT_SECTIONS ".meminit.*"
#define EXIT_SECTIONS ".exit.*"
-#define DEV_EXIT_SECTIONS ".devexit.*"
#define CPU_EXIT_SECTIONS ".cpuexit.*"
#define MEM_EXIT_SECTIONS ".memexit.*"
@@ -979,7 +975,7 @@ const struct sectioncheck sectioncheck[] = {
.mismatch = DATA_TO_ANY_EXIT,
.symbol_white_list = { DEFAULT_SYMBOL_WHITE_LIST, NULL },
},
-/* Do not reference init code/data from devinit/cpuinit/meminit code/data */
+/* Do not reference init code/data from cpuinit/meminit code/data */
{
.fromsec = { ALL_XXXINIT_SECTIONS, NULL },
.tosec = { INIT_SECTIONS, NULL },
@@ -1000,7 +996,7 @@ const struct sectioncheck sectioncheck[] = {
.mismatch = XXXINIT_TO_SOME_INIT,
.symbol_white_list = { DEFAULT_SYMBOL_WHITE_LIST, NULL },
},
-/* Do not reference exit code/data from devexit/cpuexit/memexit code/data */
+/* Do not reference exit code/data from cpuexit/memexit code/data */
{
.fromsec = { ALL_XXXEXIT_SECTIONS, NULL },
.tosec = { EXIT_SECTIONS, NULL },
@@ -1089,7 +1085,7 @@ static const struct sectioncheck *section_mismatch(
* Pattern 2:
* Many drivers utilise a *driver container with references to
* add, remove, probe functions etc.
- * These functions may often be marked __devinit and we do not want to
+ * These functions may often be marked __cpuinit and we do not want to
* warn here.
* the pattern is identified by:
* tosec = init or exit section
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] init.h: Remove __dev* sections from the kernel
From: Greg Kroah-Hartman With the recent work to remove CONFIG_HOTPLUG, we are starting to get a bunch of __devinit section warnings, despite CONFIG_HOTPLUG always being enabled. So, stop marking the sections entirely, by defining them away the section markings in init.h Signed-off-by: Greg Kroah-Hartman --- include/linux/init.h | 18 +++--- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/include/linux/init.h b/include/linux/init.h index e59041e..f63692d 100644 --- a/include/linux/init.h +++ b/include/linux/init.h @@ -93,13 +93,13 @@ #define __exit __section(.exit.text) __exitused __cold notrace -/* Used for HOTPLUG */ -#define __devinit__section(.devinit.text) __cold notrace -#define __devinitdata__section(.devinit.data) -#define __devinitconst __constsection(.devinit.rodata) -#define __devexit__section(.devexit.text) __exitused __cold notrace -#define __devexitdata__section(.devexit.data) -#define __devexitconst __constsection(.devexit.rodata) +/* Used for HOTPLUG, but that is always enabled now, so just make them noops */ +#define __devinit +#define __devinitdata +#define __devinitconst +#define __devexit +#define __devexitdata +#define __devexitconst /* Used for HOTPLUG_CPU */ #define __cpuinit__section(.cpuinit.text) __cold notrace @@ -126,10 +126,6 @@ #define __INITRODATA .section".init.rodata","a",%progbits #define __FINITDATA.previous -#define __DEVINIT.section ".devinit.text", "ax" -#define __DEVINITDATA.section ".devinit.data", "aw" -#define __DEVINITRODATA .section ".devinit.rodata", "a" - #define __CPUINIT.section ".cpuinit.text", "ax" #define __CPUINITDATA.section ".cpuinit.data", "aw" #define __CPUINITRODATA .section ".cpuinit.rodata", "a" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 245/270] USB: mct_u232: fix broken close
On Tue, Nov 27, 2012 at 04:15:51PM +, Ben Hutchings wrote: > On Mon, 2012-11-26 at 14:58 -0200, Herton Ronaldo Krzesinski wrote: > > 3.5.7u1 -stable review patch. If anyone has any objections, please let me > > know. > > > > -- > > > > From: Johan Hovold > > > > commit 5260e458f5eff269a43e4f1e9c47186c57b88ddb upstream. > > > > Make sure generic close is called at close. > > > > The driver relies on the generic write implementation but did not call > > generic close. > > > > Note that the call to kill the read urb is not redundant, as mct_u232 > > uses an interrupt urb from the second port as the read urb and that > > generic close therefore fails to kill it. > > > > Compile-only tested. > > > > Signed-off-by: Johan Hovold > > Signed-off-by: Greg Kroah-Hartman > > Signed-off-by: Herton Ronaldo Krzesinski > [...] > > This is missing on 3.4; the version I used for 3.2 (attached) should be > applicable. Thanks, that works. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 028/270] ext4: remove erroneous ext4_superblock_csum_set() in update_backups()
On Tue, Nov 27, 2012 at 02:22:19AM +, Ben Hutchings wrote: > On Mon, 2012-11-26 at 14:55 -0200, Herton Ronaldo Krzesinski wrote: > > 3.5.7u1 -stable review patch. If anyone has any objections, please let me > > know. > > > > -- > > > > From: Tao Ma > > > > commit bef53b01faeb791e27605cba1a71ba21364cb23e upstream. > > > > The update_backups() function is used to backup all the metadata > > blocks, so we should not take it for granted that 'data' is pointed to > > a super block and use ext4_superblock_csum_set to calculate the > > checksum there. In case where the data is a group descriptor block, > > it will corrupt the last group descriptor, and then e2fsck will > > complain about it it. > > > > As all the metadata checksums should already be OK when we do the > > backup, remove the wrong ext4_superblock_csum_set and it should be > > just fine. > > > > Reported-by: "Theodore Ts'o" > > Signed-off-by: Tao Ma > > Signed-off-by: "Theodore Ts'o" > > [ herton: adjust context ] > > Signed-off-by: Herton Ronaldo Krzesinski > > This should also be applicable to 3.6. Thanks, it didn't apply there, so I didn't take it, defering to the ext4 developers, who seem to be a bit busy :) greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 036/270] kbuild: Do not package /boot and /lib in make tar-pkg
On Tue, Nov 27, 2012 at 02:26:27AM +, Ben Hutchings wrote: > On Mon, 2012-11-26 at 14:55 -0200, Herton Ronaldo Krzesinski wrote: > > 3.5.7u1 -stable review patch. If anyone has any objections, please let me > > know. > > > > -- > > > > From: Michal Marek > > > > commit fe04ddf7c2910362f3817c8156e41cbd6c0ee35d upstream. > > > > There were reports of users destroying their Fedora installs by a kernel > > tarball that replaces the /lib -> /usr/lib symlink. Let's remove the > > toplevel directories from the tarball to prevent this from happening. > > > > Reported-by: Andi Kleen > > Suggested-by: Ben Hutchings > > Signed-off-by: Michal Marek > > [ herton: dropped unrelated changes to arch/x86/Makefile and > > scripts/Makefile.fwinst, which don't apply anyway on 3.5, see commit > > 3ce9e53e71da0d5f3912f80e0dd6b501f304 upstream ] > > Signed-off-by: Herton Ronaldo Krzesinski > > This is missing from 3.4. I don't think it is needed, as 3ce9e53e71da0d5f3912f80e0dd6b501f304 didn't go into 3.4, so all should be good for now. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 026/270] powerpc/eeh: Lock module while handling EEH event
On Tue, Nov 27, 2012 at 02:18:34AM +, Ben Hutchings wrote: > On Mon, 2012-11-26 at 14:55 -0200, Herton Ronaldo Krzesinski wrote: > > 3.5.7u1 -stable review patch. If anyone has any objections, please let me > > know. > > > > -- > > > > From: Gavin Shan > > > > commit feadf7c0a1a7c08c74bebb4a13b755f8c40e3bbc upstream. > > > > The EEH core is talking with the PCI device driver to determine the > > action (purely reset, or PCI device removal). During the period, the > > driver might be unloaded and in turn causes kernel crash as follows: > > > > EEH: Detected PCI bus error on PHB#4-PE#1 > > EEH: This PCI device has failed 3 times in the last hour > > lpfc 0004:01:00.0: 0:2710 PCI channel disable preparing for reset > > Unable to handle kernel paging request for data at address 0x0490 > > Faulting instruction address: 0xde682c90 > > cpu 0x1: Vector: 300 (Data Access) at [c00fc75ffa20] > > pc: de682c90: .lpfc_io_error_detected+0x30/0x240 [lpfc] > > lr: de682c8c: .lpfc_io_error_detected+0x2c/0x240 [lpfc] > > sp: c00fc75ffca0 > >msr: 80009032 > >dar: 490 > > dsisr: 4000 > > current = 0xc00fc79b88b0 > > paca= 0xcedb0380 softe: 0irq_happened: 0x00 > > pid = 3386, comm = eehd > > enter ? for help > > [c00fc75ffca0] c00fc75ffd30 (unreliable) > > [c00fc75ffd30] c004fd3c .eeh_report_error+0x7c/0xf0 > > [c00fc75ffdc0] c004ee00 .eeh_pe_dev_traverse+0xa0/0x180 > > [c00fc75ffe70] c004ffd8 .eeh_handle_event+0x68/0x300 > > [c00fc75fff00] c00503a0 .eeh_event_handler+0x130/0x1a0 > > [c00fc75fff90] c0020138 .kernel_thread+0x54/0x70 > > 1:mon> > > > > The patch increases the reference of the corresponding driver modules > > while EEH core does the negotiation with PCI device driver so that the > > corresponding driver modules can't be unloaded during the period and > > we're safe to refer the callbacks. > > > > Reported-by: Alexey Kardashevskiy > > Signed-off-by: Gavin Shan > > Signed-off-by: Benjamin Herrenschmidt > > [ herton: backported for 3.5, adjusted driver assignments, return 0 > > instead of NULL, assume dev is not NULL ] > > Signed-off-by: Herton Ronaldo Krzesinski > [...] > > Greg, you probably want this in 3.4 and 3.6. Many thanks. Herton, any reason why you didn't forward on this backported version of the patch? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 041/270] pnfsblock: fix partial page buffer wirte
On Tue, Nov 27, 2012 at 02:33:24AM +, Ben Hutchings wrote: > On Mon, 2012-11-26 at 14:55 -0200, Herton Ronaldo Krzesinski wrote: > > 3.5.7u1 -stable review patch. If anyone has any objections, please let me > > know. > > > > -- > > > > From: Peng Tao > > > > commit fe6e1e8d9fad86873eb74a26e80a8f91f9e870b5 upstream. > > > > If applications use flock to protect its write range, generic NFS > > will not do read-modify-write cycle at page cache level. Therefore > > LD should know how to handle non-sector aligned writes. Otherwise > > there will be data corruption. > > > > Signed-off-by: Peng Tao > > Signed-off-by: Trond Myklebust > > Signed-off-by: Herton Ronaldo Krzesinski > [...] > > I notice that this fix is missing from 3.4, and will need backporting. I don't trust myself with backporting this, as I got it wrong. So if one of the NFS developers wants to do this (same goes for the other NFS patch), I'll gladly take it. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 053/270] mmc: sdhci-s3c: fix the wrong number of max bus clocks
On Tue, Nov 27, 2012 at 03:00:13PM +, Ben Hutchings wrote: > On Mon, 2012-11-26 at 14:55 -0200, Herton Ronaldo Krzesinski wrote: > > 3.5.7u1 -stable review patch. If anyone has any objections, please let me > > know. > > > > -- > > > > From: Jaehoon Chung > > > > commit 5feb54a1ab91a237e247c013b8c4fb100ea347b1 upstream. > > > > We can use up to four bus-clocks; but on module remove, we didn't > > disable the fourth bus clock. > > > > Signed-off-by: Jaehoon Chung > > Signed-off-by: Kyungmin Park > > Signed-off-by: Chris Ball > > Signed-off-by: Herton Ronaldo Krzesinski > > This is missing from 3.4 and 3.6 (but not 3.2); it apparently needed its > context adjusted. Thanks, now backported. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 055/270] ARM: OMAP: counter: add locking to read_persistent_clock
On Tue, Nov 27, 2012 at 03:05:20PM +, Ben Hutchings wrote: > On Mon, 2012-11-26 at 14:55 -0200, Herton Ronaldo Krzesinski wrote: > > 3.5.7u1 -stable review patch. If anyone has any objections, please let me > > know. > > > > -- > > > > From: Colin Cross > > > > commit 9d7d6e363b06934221b81a859d509844c97380df upstream. > > > > read_persistent_clock uses a global variable, use a spinlock to > > ensure non-atomic updates to the variable don't overlap and cause > > time to move backwards. > > > > Signed-off-by: Colin Cross > > Signed-off-by: R Sricharan > > Signed-off-by: Tony Lindgren > > Signed-off-by: Herton Ronaldo Krzesinski > [...] > > This is also missing from 3.4. I'm attaching the adjusted version for > 3.2, which looks like it will work for 3.4. Thanks for the patch, now applied. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 061/270] timekeeping: Cast raw_interval to u64 to avoid shift overflow
On Tue, Nov 27, 2012 at 03:08:27PM +, Ben Hutchings wrote: > On Mon, 2012-11-26 at 14:55 -0200, Herton Ronaldo Krzesinski wrote: > > 3.5.7u1 -stable review patch. If anyone has any objections, please let me > > know. > > > > -- > > > > From: Dan Carpenter > > > > commit 5b3900cd409466c0070b234d941650685ad0c791 upstream. > > > > We fixed a bunch of integer overflows in timekeeping code during the 3.6 > > cycle. I did an audit based on that and found this potential overflow. > > > > Signed-off-by: Dan Carpenter > > Acked-by: John Stultz > > Link: http://lkml.kernel.org/r/20121009071823.GA19159@elgon.mountain > > Signed-off-by: Thomas Gleixner > > [ herton: adapt for 3.5, timekeeper instead of tk pointer ] > > Signed-off-by: Herton Ronaldo Krzesinski > > This is also missing from 3.4; looks like Herton's version is > applicable. Thanks, now applied. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 187/270] net/wireless: ipw2200: Fix panic occurring in ipw_handle_promiscuous_tx()
On Tue, Nov 27, 2012 at 03:58:51PM +, Ben Hutchings wrote: > On Mon, 2012-11-26 at 14:57 -0200, Herton Ronaldo Krzesinski wrote: > > 3.5.7u1 -stable review patch. If anyone has any objections, please let me > > know. > > > > -- > > > > From: Stanislav Yakovlev > > > > commit bf11315eeda510ea4fc1a2bf972d8155d31d89b4 upstream. > > > > The driver does not count space of radiotap fields when allocating skb for > > radiotap packet. This leads to kernel panic with the following call trace: > > > > ... > > [67607.676067] [] error_code+0x67/0x6c > > [67607.676067] [] ? skb_put+0x91/0xa0 > > [67607.676067] [] ? ipw_handle_promiscuous_tx+0x16b/0x2d0 > > [ipw2200] > > [67607.676067] [] ipw_handle_promiscuous_tx+0x16b/0x2d0 [ipw2200] > > [67607.676067] [] ipw_net_hard_start_xmit+0x8b/0x90 [ipw2200] > > [67607.676067] [] libipw_xmit+0x55a/0x980 [libipw] > > [67607.676067] [] dev_hard_start_xmit+0x218/0x4d0 > > ... > > > > This bug was found by VittGam. > > https://bugzilla.kernel.org/show_bug.cgi?id=43255 > > > > Signed-off-by: Stanislav Yakovlev > > Signed-off-by: John W. Linville > > Signed-off-by: Herton Ronaldo Krzesinski > > This is missing from 3.4; it may just need de-fuzzing to apply. Odd, it applies just fine, I wonder how I missed it. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 188/270] iwlwifi: fix 6000 series channel switch command
On Tue, Nov 27, 2012 at 04:02:38PM +, Ben Hutchings wrote: > On Mon, 2012-11-26 at 14:57 -0200, Herton Ronaldo Krzesinski wrote: > > 3.5.7u1 -stable review patch. If anyone has any objections, please let me > > know. > > > > -- > > > > From: Johannes Berg > > > > commit 8f7b8db6e0557c8437adf9371e020cd89a7e85dc upstream. > > > > The channel switch command for 6000 series devices > > is larger than the maximum inline command size of > > 320 bytes. The command is therefore refused with a > > warning. Fix this by allocating the command and > > using the NOCOPY mechanism. > > > > Reviewed-by: Emmanuel Grumbach > > Signed-off-by: Johannes Berg > > [ herton: file name is different on 3.5, code differs a little bit at > > the end, adjusted context ] > > Signed-off-by: Herton Ronaldo Krzesinski > > Also missing from 3.4; the filename is different again > (drivers/net/wireless/iwlwifi/iwl-6000.c) but this should otherwise be > applicable with one line of fuzz at the end. Thanks, I forced it in by hand. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold
On Fri, Nov 23, 2012 at 03:47:42PM +0800, Huang Ying wrote: > On Fri, 2012-11-23 at 11:09 +0800, Huang Ying wrote: > > On Fri, 2012-11-23 at 02:35 +, Ben Hutchings wrote: > > > On Wed, 2012-11-21 at 16:39 -0800, Greg Kroah-Hartman wrote: > > > > 3.0-stable review patch. If anyone has any objections, please let me > > > > know. > > > > > > > > -- > > > > > > > > From: Huang Ying > > > > > > > > commit 90b5c1d7c45eeb622302680ff96ed30c1a2b6f0e upstream. > > > > > > > > If a PCI device and its parents are put into D3cold, unbinding the > > > > device will trigger deadlock as follow: > > > > > > > > - driver_unbind > > > > - device_release_driver > > > > - device_lock(dev) <--- previous lock here > > > > - __device_release_driver > > > > - pm_runtime_get_sync > > > > ... > > > > - rpm_resume(dev) > > > > - rpm_resume(dev->parent) > > > > ... > > > > - pci_pm_runtime_resume > > > > ... > > > > - pci_set_power_state > > > > - __pci_start_power_transition > > > > - pci_wakeup_bus(dev->parent->subordinate) > > > > - pci_walk_bus > > > > - device_lock(dev)<--- deadlock here > > > > > > > > > > > > If we do not do device_lock in pci_walk_bus, we can avoid deadlock. > > > > Device_lock in pci_walk_bus is introduced in commit: > > > > d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread > > > > is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin > > > > said device_lock is added to pci_walk_bus because: > > > > > > > > Some error handling functions call pci_walk_bus. For example, PCIe > > > > aer. Here we lock the device, so the driver wouldn't detach from the > > > > device, as the cb might call driver's callback function. > > > > > > > > So I fixed the deadlock as follows: > > > > > > > > - remove device_lock from pci_walk_bus > > > > - add device_lock into callback if callback will call driver's callback > > > > > > > > I checked pci_walk_bus users one by one, and found only PCIe aer needs > > > > device lock. > > > [...] > > > > > > What about eeh_report_error() in > > > arch/powerpc/platforms/pseries/eeh_driver.c? > > > > En... Because pci_walk_bus() invocation is removed in 3.7, so this > > patch is only valid for 3.7. We need another version for 3.6. > > Here is the patch for 3.6. I have no powerpc machine, so build test > only. > > Subject: [BUGFIX] PCI/PM: Fix deadlock when unbind device if its parent in > D3cold > > If a PCI device and its parents are put into D3cold, unbinding the > device will trigger deadlock as follow: > > - driver_unbind > - device_release_driver > - device_lock(dev)<--- previous lock here > - __device_release_driver > - pm_runtime_get_sync > ... > - rpm_resume(dev) > - rpm_resume(dev->parent) > ... > - pci_pm_runtime_resume > ... > - pci_set_power_state > - __pci_start_power_transition > - pci_wakeup_bus(dev->parent->subordinate) > - pci_walk_bus > - device_lock(dev) <--- dead lock here > > > If we do not do device_lock in pci_walk_bus, we can avoid dead lock. > Device_lock in pci_walk_bus is introduced in commit: > d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread > is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin > said device_lock is added to pci_walk_bus because: > > Some error handling functions call pci_walk_bus. For example, PCIe > aer. Here we lock the device, so the driver wouldn't detach from the > device, as the cb might call driver's callback function. > > So I fixed the dead lock as follow: > > - remove device_lock from pci_walk_bus > - add device_lock into callback if callback will call driver's callback > > I checked pci_walk_bus users one by one, and found only PCIe aer needs > device lock. > > Signed-off-by: Huang Ying > Cc: Zhang Yanmin > --- > arch/powerpc/platforms/pseries/eeh_driver.c | 51 > ++-- Due to me applying a power pci patch, feadf7c0a1a7c08c74bebb4a13b755f8c40e3bbc in Linus's tree to 3.6-stable, this patch doesn't apply here anymore. Because that patch is in the tree, is it now just safe to take your original, unmodified, version of this patch for 3.6-stable? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging/serqt_usb2: Refactor qt_status_change_check() in serqt_usb2.c
On Thu, Nov 29, 2012 at 01:57:56PM +0900, YAMANE Toshiaki wrote:
> Improved position to increment variable i,
> And typo fixes.
>
> Signed-off-by: YAMANE Toshiaki
> ---
> drivers/staging/serqt_usb2/serqt_usb2.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/serqt_usb2/serqt_usb2.c
> b/drivers/staging/serqt_usb2/serqt_usb2.c
> index 1b3e995..095d6f2 100644
> --- a/drivers/staging/serqt_usb2/serqt_usb2.c
> +++ b/drivers/staging/serqt_usb2/serqt_usb2.c
> @@ -309,26 +309,26 @@ static void qt_status_change_check(struct tty_struct
> *tty,
> case 0x00:
> if (i > (RxCount - 4)) {
> dev_dbg(&port->dev,
> - "Illegal escape seuences in
> received data\n");
> + "Illegal escape sequence in
> received data\n");
This is a different type of fix from:
> break;
> }
>
> - ProcessLineStatus(qt_port, data[i + 3]);
> -
> i += 3;
> + ProcessLineStatus(qt_port, data[i]);
I think you just changed the logic in this function, didn't you?
> +
> flag = 1;
> break;
>
> case 0x01:
> if (i > (RxCount - 4)) {
> dev_dbg(&port->dev,
> - "Illegal escape seuences in
> received data\n");
> + "Illegal escape sequence in
> received data\n");
> break;
> }
>
> - ProcessModemStatus(qt_port, data[i + 3]);
> -
> i += 3;
> + ProcessModemStatus(qt_port, data[i]);
Same here, what happens to i after this?
Please break into two patches, and verify that you didn't break anything
here.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/1] usb: f_rndis: Avoid to use ERROR macro if cdev can be null
On Mon, Mar 18, 2013 at 09:28:07AM +0100, oskar.and...@sonymobile.com wrote: > On 21:16 Fri 08 Mar , Greg Kroah-Hartman wrote: > > On Fri, Mar 08, 2013 at 11:56:26PM +0400, Sergei Shtylyov wrote: > > > Hello. > > > > > > On 08-03-2013 16:53, oskar.and...@sonymobile.com wrote: > > > > > > >From: Truls Bengtsson > > > > > > >The udc_irq service runs the isr_tr_complete_handler which in turn > > > >"nukes" the endpoints, including a call to rndis_response_complete, > > > >if appropriate. If the rndis_msg_parser fails here, an error will > > > >be printed using a dev_err call (through the ERROR() macro). > > > > > > >However, if the usb cable was just disconnected the device (cdev) > > > >might not be available and will be null. Since the dev_err macro will > > > >dereference the cdev pointer we get a null pointer exception. > > > > > > >Reviewed-by: Radovan Lekanovic > > > >Signed-off-by: Truls Bengtsson > > > >Signed-off-by: Oskar Andero > > > >--- > > > > drivers/usb/gadget/f_rndis.c |4 ++-- > > > > 1 files changed, 2 insertions(+), 2 deletions(-) > > > > > > >diff --git a/drivers/usb/gadget/f_rndis.c b/drivers/usb/gadget/f_rndis.c > > > >index 71beeb8..41b5ebd 100644 > > > >--- a/drivers/usb/gadget/f_rndis.c > > > >+++ b/drivers/usb/gadget/f_rndis.c > > > >@@ -6,6 +6,7 @@ > > > > * Copyright (C) 2008 Nokia Corporation > > > > * Copyright (C) 2009 Samsung Electronics > > > > *Author: Michal Nazarewicz (min...@mina86.com) > > > >+ * Copyright (C) 2013 Sony Mobile Communications AB. > > > > > >Your change seems too insignificant to add a copyright. > > > > You are right, it legally is. Truls, please consult your company's > > lawyers if you have questions about this, you can not assert copyright > > over a file for a 2 line change, that's not allowed at all in any > > jurisdiction I know of. > > > > Because of that, I can not accept this change, sorry. > > Thanks for your input guys and I totally agree with you! However, I was > expecting more comments on the cover-letter, or should I take it that this > solution is acceptable? I don't remember, please resend the series after fixing the issues pointed out. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rttest] WARNING: at drivers/base/core.c:569 device_create_file()
On Mon, Mar 18, 2013 at 09:52:34PM +0800, Fengguang Wu wrote: > Greetings, > > I got the below dmesg and the first bad commit is Adding the owners of the kernel/rtmutext-tester.c file. > > commit 8f46baaa7ec6cd0851794020b31958e64679dd26 > Author: Felipe Balbi > Date: Wed Feb 20 10:31:42 2013 +0200 > > base: core: WARN() about bogus permissions on device attributes > > Whenever a struct device_attribute is registered > with mismatched permissions - read permission without > a show routine or write permission without store > routine - we will issue a big warning so we catch > those early enough. > > Signed-off-by: Felipe Balbi > Signed-off-by: Greg Kroah-Hartman > > Judging from the dmesg, CC the rttest developers for possible fixes. > > [ 11.581068] bus: 'rttest': add device rttest0 > [ 11.581813] [ cut here ] > [ 11.582568] WARNING: at /c/kernel-tests/src/linux/drivers/base/core.c:569 > device_create_file+0x5a/0xa0() > [ 11.584035] Write permission without 'store' > [ 11.584793] Pid: 1, comm: swapper/0 Not tainted 3.9.0-rc2-next-20130318 #21 > [ 11.585902] Call Trace: > [ 11.586318] [<8102d888>] warn_slowpath_common+0x68/0xa0 > [ 11.587146] [<8151b77a>] ? device_create_file+0x5a/0xa0 > [ 11.587982] [<8151b77a>] ? device_create_file+0x5a/0xa0 > [ 11.588820] [<8102d91e>] warn_slowpath_fmt+0x2e/0x30 > [ 11.589618] [<8151b77a>] device_create_file+0x5a/0xa0 > [ 11.590523] [<81081faa>] init_rttest+0xaa/0x150 Turns out that the sysfs attributes this function (init_rttest()) is creating, isn't correct. The "command" file is mode 0600, yet has no read function, and the "status" file is the same mode, with no write function. These should be fixed, which is what the patch from Felipe is pointing out. Don't shoot the messenger :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 052/100] drm/i915: Increase the RC6p threshold.
On Mon, Mar 18, 2013 at 01:11:09AM +, Ben Hutchings wrote: > On Tue, 2013-03-12 at 15:31 -0700, Greg Kroah-Hartman wrote: > > 3.8-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Stéphane Marchesin > > > > commit 0920a48719f1ceefc909387a64f97563848c7854 upstream. > > > > This increases GEN6_RC6p_THRESHOLD from 10 to 15. For some > > reason this avoids the gen6_gt_check_fifodbg.isra warnings and > > associated GPU lockups, which makes my ivy bridge machine stable. > > > > Signed-off-by: Stéphane Marchesin > > Acked-by: Jesse Barnes > > Signed-off-by: Daniel Vetter > > Signed-off-by: Greg Kroah-Hartman > > > > --- > > drivers/gpu/drm/i915/intel_pm.c |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > --- a/drivers/gpu/drm/i915/intel_pm.c > > +++ b/drivers/gpu/drm/i915/intel_pm.c > > @@ -2572,7 +2572,7 @@ static void gen6_enable_rps(struct drm_d > > I915_WRITE(GEN6_RC_SLEEP, 0); > > I915_WRITE(GEN6_RC1e_THRESHOLD, 1000); > > I915_WRITE(GEN6_RC6_THRESHOLD, 5); > > - I915_WRITE(GEN6_RC6p_THRESHOLD, 10); > > + I915_WRITE(GEN6_RC6p_THRESHOLD, 15); > > I915_WRITE(GEN6_RC6pp_THRESHOLD, 64000); /* unused */ > > > > /* Check if we are enabling RC6 */ > > Is there any reason why this shouldn't be applied to 3.2.y and 3.4.y? > The same function and writes are present, only in intel_display.c rather > than intel_pm.c. Ah, missed the fact that the file was renamed, nice catch. I'll apply it to older kernels if the authors and maintainers say it's safe to do so. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 052/100] drm/i915: Increase the RC6p threshold.
On Mon, Mar 18, 2013 at 12:40:35PM -0700, Stéphane Marchesin wrote: > > > > On Mon, Mar 18, 2013 at 12:38 PM, Greg Kroah-Hartman < > gre...@linuxfoundation.org> wrote: > > On Mon, Mar 18, 2013 at 01:11:09AM +, Ben Hutchings wrote: > > On Tue, 2013-03-12 at 15:31 -0700, Greg Kroah-Hartman wrote: > > > 3.8-stable review patch. If anyone has any objections, please let me > know. > > > > > > -- > > > > > > From: Stéphane Marchesin > > > > > > commit 0920a48719f1ceefc909387a64f97563848c7854 upstream. > > > > > > This increases GEN6_RC6p_THRESHOLD from 10 to 15. For some > > > reason this avoids the gen6_gt_check_fifodbg.isra warnings and > > > associated GPU lockups, which makes my ivy bridge machine stable. > > > > > > Signed-off-by: Stéphane Marchesin > > > Acked-by: Jesse Barnes > > > Signed-off-by: Daniel Vetter > > > Signed-off-by: Greg Kroah-Hartman > > > > > > --- > > > drivers/gpu/drm/i915/intel_pm.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > --- a/drivers/gpu/drm/i915/intel_pm.c > > > +++ b/drivers/gpu/drm/i915/intel_pm.c > > > @@ -2572,7 +2572,7 @@ static void gen6_enable_rps(struct drm_d > > > I915_WRITE(GEN6_RC_SLEEP, 0); > > > I915_WRITE(GEN6_RC1e_THRESHOLD, 1000); > > > I915_WRITE(GEN6_RC6_THRESHOLD, 5); > > > - I915_WRITE(GEN6_RC6p_THRESHOLD, 10); > > > + I915_WRITE(GEN6_RC6p_THRESHOLD, 15); > > > I915_WRITE(GEN6_RC6pp_THRESHOLD, 64000); /* unused */ > > > > > > /* Check if we are enabling RC6 */ > > > > Is there any reason why this shouldn't be applied to 3.2.y and 3.4.y? > > The same function and writes are present, only in intel_display.c rather > > than intel_pm.c. > > Ah, missed the fact that the file was renamed, nice catch. > > I'll apply it to older kernels if the authors and maintainers say it's > safe to do so. > > > > It should be safe; I actually wrote this patch against Chrome OS's 3.4 kernel > initially. Ok, now applied to the 3.4-stable queue. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.2->3.8.3 i915 regression: GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5
On Thu, Mar 14, 2013 at 11:19:57PM +0100, Michael Leun wrote: > Hello, > > On Thu, 14 Mar 2013 21:36:24 +0100 > Arkadiusz Miskiewicz wrote: > > > After upgrading from 3.8.2 to 3.8.3 I'm getting regression : > [...] > > 2a9810441fcc26cf3f006f015f8a62094fe57a90 is the first bad commit > > I also have an 3.8.2->3.8.3 regression which goes away with reverting > the same patch - X comes up with 1024x768 instead of 1366x768. > > Acer Aspire 1825PTZ > > 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset > Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller]) > Subsystem: Acer Incorporated [ALI] Device 0300 > Thanks for the report, I've reverted this patch, and another i915 patch for the next 3.8-stable release, so all should be resolved then. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 00/75] 3.8.4-stable review
This is the start of the stable review cycle for the 3.8.4 release. There are 75 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 Wed Mar 20 21:04:55 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.8.4-rc1.gz and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 3.8.4-rc1 Greg Kroah-Hartman Revert "drm/i915: reorder setup sequence to have irqs for output setup" Greg Kroah-Hartman Revert "drm/i915: enable irqs earlier when resuming" YOSHIFUJI Hideaki 6lowpan: Fix endianness issue in is_addr_link_local(). Mathias Krause dcbnl: fix various netlink info leaks Mathias Krause rtnl: fix info leak on RTM_GETLINK request for VF devices Mathias Krause bridge: fix mdb info leaks Hannes Frederic Sowa ipv6: stop multicast forwarding to process interface scoped addresses Cristian Bercaru bridging: fix rx_handlers return code Paul Moore netlabel: correctly list all the static label mappings Vlad Yasevich macvlan: Set IFF_UNICAST_FLT flag to prevent unnecessary promisc mode. Vlad Yasevich team: unsyc the devices addresses when port is removed Veaceslav Falico bonding: fire NETDEV_RELEASE event only on 0 slaves Zang MingJie vxlan: fix oops when delete netns containing vxlan Eric Dumazet tun: add a missing nf_reset() in tun_net_xmit() Neal Cardwell tcp: fix double-counted receiver RTT when leaving receiver fast path Lorenzo Colitti net: ipv6: Don't purge default router if accept_ra=2 Cong Wang rds: limit the size allocated by rds_message_alloc() Huang, Xiong atl1c: restore buffer state Guillaume Nault l2tp: Restore socket refcount when sendmsg succeeds Guenter Roeck net/sctp: Validate parameter size for SCTP_GET_ASSOC_STATS Guo Chao loopdev: remove an user triggerable oops Guo Chao loopdev: fix a deadlock Guo Chao block: use i_size_write() in bd_set_size() Amir Vadai net/mlx4_en: Disable RFS when running in SRIOV mode Amir Vadai net/mlx4_en: Initialize RFS filters lock and list in init_netdev Johan Hovold atmel_lcdfb: fix 16-bpp modes on older SOCs Sam Ravnborg kbuild: fix make headers_check with make 3.80 Brian Norris mtd: nand: reintroduce NAND_NO_READRDY as NAND_NEED_READRDY Eric Sandeen btrfs: use rcu_barrier() to wait for bdev puts at unmount Heiko Carstens s390/mm: fix flush_tlb_kernel_range() Martin Schwidefsky s390: critical section cleanup vs. machine checks David Rientjes perf,x86: fix link failure for non-Intel configs Linus Torvalds perf,x86: fix wrmsr_on_cpu() warning on suspend/resume Dan Carpenter selinux: use GFP_ATOMIC under spin_lock Matt Porter ARM: davinci: edma: fix dmaengine induced null pointer dereference on da830 Aneesh Kumar K.V powerpc: Rename USER_ESID_BITS* to ESID_BITS* Aneesh Kumar K.V powerpc: Update kernel VSID range Aneesh Kumar K.V powerpc: Make VSID_BITS* dependency explicit Benjamin Herrenschmidt powerpc: Fix cputable entry for 970MP rev 1.0 Benjamin Herrenschmidt powerpc: Fix STAB initialization Marcin Jurkowski w1: fix oops when w1_search is called from netlink connector Johan Hovold w1-gpio: remove erroneous __exit and __exit_p() Axel Lin hwmon: (lineage-pem) Add missing terminating entry for pem_[input|fan]_attributes Guenter Roeck hwmon: (pmbus/ltc2978) Fix temperature reporting Johan Hovold ARM: w1-gpio: fix erroneous gpio requests Takashi Iwai ALSA: seq: Fix missing error handling in snd_seq_timer_open() Stephane Eranian perf,x86: fix kernel crash with PEBS/BTS after suspend/resume Sebastian Hesselbarth ARM: kirkwood: fix to retain gbe MAC addresses for DT kernels Scott Ashcroft Fix 4 port and add support for 8 port 'Unknown' PCI serial port cards Jiri Slaby TTY: do not reset master's packet mode Jiri Slaby TTY: disable debugging warning Ley Foon Tan tty/serial: Add support for Altera serial port Paul Bolle tty: serial: fix typo "SERIAL_S3C2412" Paul Bolle tty: serial: fix typo "ARCH_S5P6450" Wang YanQing serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller Josh Boyer serial: 8250: Keep 8250. module options functional after driver rename Sean Young tty/8250_pnp: serial port detection regression since v3.7 Lars-Peter Clausen ext3: Fix format string issues Kees Cook signal: always clear sa_restorer on execve Dan Williams qcserial: bind to DM/DIAG port on Gobi 1K devices Ian Abbott stagin
[ 06/75] tools: usb: ffs-test: Fix build failure
3.8-stable review patch. If anyone has any objections, please let me know. -- From: "Maxin B. John" commit a0f11aceee531d444f58b939e6a537ee5e2b9cc5 upstream. Fixes this build failure: gcc -Wall -Wextra -g -lpthread -I../include -o testusb testusb.c gcc -Wall -Wextra -g -lpthread -I../include -o ffs-test ffs-test.c In file included from ffs-test.c:41:0: ../../include/linux/usb/functionfs.h:4:39: fatal error: uapi/linux/usb/functionfs.h: No such file or directory compilation terminated. make: *** [ffs-test] Error 1 Signed-off-by: Maxin B. John Acked-by: Michal Nazarewicz Signed-off-by: Greg Kroah-Hartman --- tools/usb/ffs-test.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/usb/ffs-test.c +++ b/tools/usb/ffs-test.c @@ -38,7 +38,7 @@ #include #include -#include "../../include/linux/usb/functionfs.h" +#include "../../include/uapi/linux/usb/functionfs.h" / Little Endian Handling / -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 35/75] w1: fix oops when w1_search is called from netlink connector
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Marcin Jurkowski
commit 9d1817cab2f030f6af360e961cc69bb1da8ad765 upstream.
On Sat, Mar 02, 2013 at 10:45:10AM +0100, Sven Geggus wrote:
> This is the bad commit I found doing git bisect:
> 04f482faf50535229a5a5c8d629cf963899f857c is the first bad commit
> commit 04f482faf50535229a5a5c8d629cf963899f857c
> Author: Patrick McHardy
> Date: Mon Mar 28 08:39:36 2011 +
Good job. I was too lazy to bisect for bad commit;)
Reading the code I found problematic kthread_should_stop call from netlink
connector which causes the oops. After applying a patch, I've been testing
owfs+w1 setup for nearly two days and it seems to work very reliable (no
hangs, no memleaks etc).
More detailed description and possible fix is given below:
Function w1_search can be called from either kthread or netlink callback.
While the former works fine, the latter causes oops due to kthread_should_stop
invocation.
This patch adds a check if w1_search is serving netlink command, skipping
kthread_should_stop invocation if so.
Signed-off-by: Marcin Jurkowski
Acked-by: Evgeniy Polyakov
Cc: Josh Boyer
Tested-by: Sven Geggus
Signed-off-by: Greg Kroah-Hartman
---
drivers/w1/w1.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -924,7 +924,8 @@ void w1_search(struct w1_master *dev, u8
tmp64 = (triplet_ret >> 2);
rn |= (tmp64 << i);
- if (kthread_should_stop()) {
+ /* ensure we're called from kthread and not by netlink
callback */
+ if (!dev->priv && kthread_should_stop()) {
mutex_unlock(&dev->bus_mutex);
dev_dbg(&dev->dev, "Abort w1_search\n");
return;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 43/75] perf,x86: fix wrmsr_on_cpu() warning on suspend/resume
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Torvalds
commit 2a6e06b2aed6995af401dcd4feb5e79a0c7ea554 upstream.
Commit 1d9d8639c063 ("perf,x86: fix kernel crash with PEBS/BTS after
suspend/resume") fixed a crash when doing PEBS performance profiling
after resuming, but in using init_debug_store_on_cpu() to restore the
DS_AREA mtrr it also resulted in a new WARN_ON() triggering.
init_debug_store_on_cpu() uses "wrmsr_on_cpu()", which in turn uses CPU
cross-calls to do the MSR update. Which is not really valid at the
early resume stage, and the warning is quite reasonable. Now, it all
happens to _work_, for the simple reason that smp_call_function_single()
ends up just doing the call directly on the CPU when the CPU number
matches, but we really should just do the wrmsr() directly instead.
This duplicates the wrmsr() logic, but hopefully we can just remove the
wrmsr_on_cpu() version eventually.
Reported-and-tested-by: Parag Warudkar
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/cpu/perf_event_intel_ds.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -732,8 +732,10 @@ void intel_ds_init(void)
void perf_restore_debug_store(void)
{
+ struct debug_store *ds = __this_cpu_read(cpu_hw_events.ds);
+
if (!x86_pmu.bts && !x86_pmu.pebs)
return;
- init_debug_store_on_cpu(smp_processor_id());
+ wrmsrl(MSR_IA32_DS_AREA, (unsigned long)ds);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 72/75] dcbnl: fix various netlink info leaks
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Mathias Krause
[ Upstream commit 29cd8ae0e1a39e239a3a7b67da1986add1199fc0 ]
The dcb netlink interface leaks stack memory in various places:
* perm_addr[] buffer is only filled at max with 12 of the 32 bytes but
copied completely,
* no in-kernel driver fills all fields of an IEEE 802.1Qaz subcommand,
so we're leaking up to 58 bytes for ieee_ets structs, up to 136 bytes
for ieee_pfc structs, etc.,
* the same is true for CEE -- no in-kernel driver fills the whole
struct,
Prevent all of the above stack info leaks by properly initializing the
buffers/structures involved.
Signed-off-by: Mathias Krause
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/dcb/dcbnl.c |8
1 file changed, 8 insertions(+)
--- a/net/dcb/dcbnl.c
+++ b/net/dcb/dcbnl.c
@@ -284,6 +284,7 @@ static int dcbnl_getperm_hwaddr(struct n
if (!netdev->dcbnl_ops->getpermhwaddr)
return -EOPNOTSUPP;
+ memset(perm_addr, 0, sizeof(perm_addr));
netdev->dcbnl_ops->getpermhwaddr(netdev, perm_addr);
return nla_put(skb, DCB_ATTR_PERM_HWADDR, sizeof(perm_addr), perm_addr);
@@ -1042,6 +1043,7 @@ static int dcbnl_ieee_fill(struct sk_buf
if (ops->ieee_getets) {
struct ieee_ets ets;
+ memset(&ets, 0, sizeof(ets));
err = ops->ieee_getets(netdev, &ets);
if (!err &&
nla_put(skb, DCB_ATTR_IEEE_ETS, sizeof(ets), &ets))
@@ -1050,6 +1052,7 @@ static int dcbnl_ieee_fill(struct sk_buf
if (ops->ieee_getmaxrate) {
struct ieee_maxrate maxrate;
+ memset(&maxrate, 0, sizeof(maxrate));
err = ops->ieee_getmaxrate(netdev, &maxrate);
if (!err) {
err = nla_put(skb, DCB_ATTR_IEEE_MAXRATE,
@@ -1061,6 +1064,7 @@ static int dcbnl_ieee_fill(struct sk_buf
if (ops->ieee_getpfc) {
struct ieee_pfc pfc;
+ memset(&pfc, 0, sizeof(pfc));
err = ops->ieee_getpfc(netdev, &pfc);
if (!err &&
nla_put(skb, DCB_ATTR_IEEE_PFC, sizeof(pfc), &pfc))
@@ -1094,6 +1098,7 @@ static int dcbnl_ieee_fill(struct sk_buf
/* get peer info if available */
if (ops->ieee_peer_getets) {
struct ieee_ets ets;
+ memset(&ets, 0, sizeof(ets));
err = ops->ieee_peer_getets(netdev, &ets);
if (!err &&
nla_put(skb, DCB_ATTR_IEEE_PEER_ETS, sizeof(ets), &ets))
@@ -1102,6 +1107,7 @@ static int dcbnl_ieee_fill(struct sk_buf
if (ops->ieee_peer_getpfc) {
struct ieee_pfc pfc;
+ memset(&pfc, 0, sizeof(pfc));
err = ops->ieee_peer_getpfc(netdev, &pfc);
if (!err &&
nla_put(skb, DCB_ATTR_IEEE_PEER_PFC, sizeof(pfc), &pfc))
@@ -1280,6 +1286,7 @@ static int dcbnl_cee_fill(struct sk_buff
/* peer info if available */
if (ops->cee_peer_getpg) {
struct cee_pg pg;
+ memset(&pg, 0, sizeof(pg));
err = ops->cee_peer_getpg(netdev, &pg);
if (!err &&
nla_put(skb, DCB_ATTR_CEE_PEER_PG, sizeof(pg), &pg))
@@ -1288,6 +1295,7 @@ static int dcbnl_cee_fill(struct sk_buff
if (ops->cee_peer_getpfc) {
struct cee_pfc pfc;
+ memset(&pfc, 0, sizeof(pfc));
err = ops->cee_peer_getpfc(netdev, &pfc);
if (!err &&
nla_put(skb, DCB_ATTR_CEE_PEER_PFC, sizeof(pfc), &pfc))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 00/48] 3.4.37-stable review
This is the start of the stable review cycle for the 3.4.37 release. There are 48 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 Wed Mar 20 21:07:59 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.4.37-rc1.gz and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 3.4.37-rc1 YOSHIFUJI Hideaki 6lowpan: Fix endianness issue in is_addr_link_local(). Mathias Krause dcbnl: fix various netlink info leaks Mathias Krause rtnl: fix info leak on RTM_GETLINK request for VF devices Hannes Frederic Sowa ipv6: stop multicast forwarding to process interface scoped addresses Cristian Bercaru bridging: fix rx_handlers return code Paul Moore netlabel: correctly list all the static label mappings Vlad Yasevich macvlan: Set IFF_UNICAST_FLT flag to prevent unnecessary promisc mode. Eric Dumazet tun: add a missing nf_reset() in tun_net_xmit() Neal Cardwell tcp: fix double-counted receiver RTT when leaving receiver fast path Lorenzo Colitti net: ipv6: Don't purge default router if accept_ra=2 Cong Wang rds: limit the size allocated by rds_message_alloc() Guillaume Nault l2tp: Restore socket refcount when sendmsg succeeds Stéphane Marchesin drm/i915: Increase the RC6p threshold. Guo Chao loopdev: remove an user triggerable oops Guo Chao loopdev: fix a deadlock Guo Chao block: use i_size_write() in bd_set_size() Ben Hutchings hwmon: (sht15) Fix memory leak if regulator_enable() fails Dmitry Rogozhkin drm/i915: EBUSY status handling added to i915_gem_fault(). Johan Hovold atmel_lcdfb: fix 16-bpp modes on older SOCs Eric Sandeen btrfs: use rcu_barrier() to wait for bdev puts at unmount Heiko Carstens s390/mm: fix flush_tlb_kernel_range() Martin Schwidefsky s390: critical section cleanup vs. machine checks David Rientjes perf,x86: fix link failure for non-Intel configs Linus Torvalds perf,x86: fix wrmsr_on_cpu() warning on suspend/resume Dan Carpenter selinux: use GFP_ATOMIC under spin_lock Benjamin Herrenschmidt powerpc: Fix cputable entry for 970MP rev 1.0 Benjamin Herrenschmidt powerpc: Fix STAB initialization Marcin Jurkowski w1: fix oops when w1_search is called from netlink connector Axel Lin hwmon: (lineage-pem) Add missing terminating entry for pem_[input|fan]_attributes Guenter Roeck hwmon: (pmbus/ltc2978) Fix temperature reporting Takashi Iwai ALSA: seq: Fix missing error handling in snd_seq_timer_open() Stephane Eranian perf,x86: fix kernel crash with PEBS/BTS after suspend/resume Jiri Slaby TTY: do not reset master's packet mode Paul Bolle tty: serial: fix typo "ARCH_S5P6450" Wang YanQing serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller Lars-Peter Clausen ext3: Fix format string issues Kees Cook signal: always clear sa_restorer on execve Malcolm Priestley staging: vt6656: Fix oops on resume from suspend. Alan Stern USB: EHCI: don't check DMA values in QH overlays Bjørn Mork USB: storage: fix Huawei mode switching regression Steve Conklin usb: serial: Add Rigblaster Advantage to device table Christian Schmiedl USB: added support for Cinterion's products AH6 and PLS8 Matwey V. Kornilov usb: cp210x new Vendor/Device IDs Oliver Neukum USB: cdc-wdm: fix buffer overflow Bjørn Mork USB: option: add Huawei E5331 Amit Shah virtio: rng: disallow multiple device registrations, fixes crashes Konrad Rzeszutek Wilk xen/pciback: Don't disable a PCI device that is already disabled. Dan Williams qcaux: add Franklin U600 - Diffstat: Makefile | 4 +- arch/powerpc/kernel/cputable.c| 2 +- arch/powerpc/mm/hash_utils_64.c | 2 + arch/s390/include/asm/tlbflush.h | 2 - arch/s390/kernel/entry.S | 3 +- arch/s390/kernel/entry64.S| 5 +- arch/x86/kernel/cpu/perf_event_intel_ds.c | 10 + arch/x86/power/cpu.c | 2 + drivers/block/loop.c | 24 ++- drivers/char/hw_random/virtio-rng.c | 13 +- drivers/gpu/drm/i915/i915_gem.c | 5 + drivers/gpu/drm/i915/intel_display.c | 2 +- drivers/hwmon/lineage-pem.c | 2 + drivers/hwmon/pmbus/ltc2978.c | 14 +- drivers/hwmon/sht15.c | 2 +- drivers/net/macvlan.c | 1 + drivers/net/tun.c | 2 + drivers/staging/vt6656/main_usb.c
[ 14/48] serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Wang YanQing
commit 8d2f8cd424ca0b99001f3ff4f5db87c4e525f366 upstream.
01:08.0 Communication controller: NetMos Technology PCI 9835 Multi-I/O
Controller (rev 01)
Subsystem: Device [1000:0012]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR-
Signed-off-by: Greg Kroah-Hartman
---
drivers/tty/serial/8250/8250_pci.c |4
1 file changed, 4 insertions(+)
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -4086,6 +4086,10 @@ static struct pci_device_id serial_pci_t
PCI_VENDOR_ID_IBM, 0x0299,
0, 0, pbn_b0_bt_2_115200 },
+ { PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9835,
+ 0x1000, 0x0012,
+ 0, 0, pbn_b0_bt_2_115200 },
+
{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9901,
0xA000, 0x1000,
0, 0, pbn_b0_1_115200 },
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 22/48] powerpc: Fix STAB initialization
3.4-stable review patch. If anyone has any objections, please let me know. -- From: Benjamin Herrenschmidt commit 13938117a57f88a22f0df9722a5db7271fda85cd upstream. Commit f5339277eb8d3aed37f12a27988366f68ab68930 accidentally removed more than just iSeries bits and took out the call to stab_initialize() thus breaking support for POWER3 processors. Put it back. (Yes, nobody noticed until now ...) Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman --- arch/powerpc/mm/hash_utils_64.c |2 ++ 1 file changed, 2 insertions(+) --- a/arch/powerpc/mm/hash_utils_64.c +++ b/arch/powerpc/mm/hash_utils_64.c @@ -759,6 +759,8 @@ void __init early_init_mmu(void) /* Initialize stab / SLB management */ if (mmu_has_feature(MMU_FTR_SLB)) slb_initialize(); + else + stab_initialize(get_paca()->stab_real); } #ifdef CONFIG_SMP -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 37/48] l2tp: Restore socket refcount when sendmsg succeeds
3.4-stable review patch. If anyone has any objections, please let me know. -- From: Guillaume Nault [ Upstream commit 8b82547e33e85fc24d4d172a93c796de1fefa81a ] The sendmsg() syscall handler for PPPoL2TP doesn't decrease the socket reference counter after successful transmissions. Any successful sendmsg() call from userspace will then increase the reference counter forever, thus preventing the kernel's session and tunnel data from being freed later on. The problem only happens when writing directly on L2TP sockets. PPP sockets attached to L2TP are unaffected as the PPP subsystem uses pppol2tp_xmit() which symmetrically increase/decrease reference counters. This patch adds the missing call to sock_put() before returning from pppol2tp_sendmsg(). Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/l2tp/l2tp_ppp.c |1 + 1 file changed, 1 insertion(+) --- a/net/l2tp/l2tp_ppp.c +++ b/net/l2tp/l2tp_ppp.c @@ -360,6 +360,7 @@ static int pppol2tp_sendmsg(struct kiocb l2tp_xmit_skb(session, skb, session->hdr_len); sock_put(ps->tunnel_sock); + sock_put(sk); return error; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 35/48] loopdev: remove an user triggerable oops
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Guo Chao
commit b1a6650406875b9097a032eed89af50682fe1160 upstream.
When loopdev is built as module and we pass an invalid parameter,
loop_init() will return directly without deregister misc device, which
will cause an oops when insert loop module next time because we left some
garbage in the misc device list.
Test case:
sudo modprobe loop max_part=1024
(failed due to invalid parameter)
sudo modprobe loop
(oops)
Clean up nicely to avoid such oops.
Signed-off-by: Guo Chao
Cc: Alexander Viro
Cc: Guo Chao
Cc: M. Hindess
Cc: Nikanth Karthikesan
Cc: Jens Axboe
Signed-off-by: Andrew Morton
Signed-off-by: Jens Axboe
Acked-by: Jeff Mahoney
Signed-off-by: Greg Kroah-Hartman
---
drivers/block/loop.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1835,11 +1835,15 @@ static int __init loop_init(void)
max_part = (1UL << part_shift) - 1;
}
- if ((1UL << part_shift) > DISK_MAX_PARTS)
- return -EINVAL;
+ if ((1UL << part_shift) > DISK_MAX_PARTS) {
+ err = -EINVAL;
+ goto misc_out;
+ }
- if (max_loop > 1UL << (MINORBITS - part_shift))
- return -EINVAL;
+ if (max_loop > 1UL << (MINORBITS - part_shift)) {
+ err = -EINVAL;
+ goto misc_out;
+ }
/*
* If max_loop is specified, create that many devices upfront.
@@ -1857,8 +1861,10 @@ static int __init loop_init(void)
range = 1UL << MINORBITS;
}
- if (register_blkdev(LOOP_MAJOR, "loop"))
- return -EIO;
+ if (register_blkdev(LOOP_MAJOR, "loop")) {
+ err = -EIO;
+ goto misc_out;
+ }
blk_register_region(MKDEV(LOOP_MAJOR, 0), range,
THIS_MODULE, loop_probe, NULL, NULL);
@@ -1871,6 +1877,10 @@ static int __init loop_init(void)
printk(KERN_INFO "loop: module loaded\n");
return 0;
+
+misc_out:
+ misc_deregister(&loop_misc);
+ return err;
}
static int loop_exit_cb(int id, void *ptr, void *data)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 41/48] tun: add a missing nf_reset() in tun_net_xmit()
3.4-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet [ Upstream commit f8af75f3517a24838a36eb5797a1a3e60bf9e276 ] Dave reported following crash : general protection fault: [#1] SMP CPU 2 Pid: 25407, comm: qemu-kvm Not tainted 3.7.9-205.fc18.x86_64 #1 Hewlett-Packard HP Z400 Workstation/0B4Ch RIP: 0010:[] [] destroy_conntrack+0x35/0x120 [nf_conntrack] RSP: 0018:880276913d78 EFLAGS: 00010206 RAX: 50626b6b7876376c RBX: 88026e530d68 RCX: 88028d158e00 RDX: 88026d0d5470 RSI: 0011 RDI: 0002 RBP: 880276913d88 R08: R09: 880295002900 R10: R11: 0003 R12: 81ca3b40 R13: 8151a8e0 R14: 880270875000 R15: 0002 FS: 7ff3bce38a00() GS:88029fc4() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 7fd1430bd000 CR3: 00027042b000 CR4: 27e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process qemu-kvm (pid: 25407, threadinfo 880276912000, task 88028c369720) Stack: 880156f59100 880156f59100 880276913d98 815534f7 880276913db8 8151a74b 880270875000 880156f59100 880276913dd8 8151a5a6 880276913dd8 88026d0d5470 Call Trace: [] nf_conntrack_destroy+0x17/0x20 [] skb_release_head_state+0x7b/0x100 [] __kfree_skb+0x16/0xa0 [] kfree_skb+0x36/0xa0 [] skb_queue_purge+0x20/0x40 [] __tun_detach+0x117/0x140 [tun] [] tun_chr_close+0x3c/0xd0 [tun] [] __fput+0xec/0x240 [] fput+0xe/0x10 [] task_work_run+0xa7/0xe0 [] do_notify_resume+0x71/0xb0 [] int_signal+0x12/0x17 Code: 00 00 04 48 89 e5 41 54 53 48 89 fb 4c 8b a7 e8 00 00 00 0f 85 de 00 00 00 0f b6 73 3e 0f b7 7b 2a e8 10 40 00 00 48 85 c0 74 0e <48> 8b 40 28 48 85 c0 74 05 48 89 df ff d0 48 c7 c7 08 6a 3a a0 RIP [] destroy_conntrack+0x35/0x120 [nf_conntrack] RSP This is because tun_net_xmit() needs to call nf_reset() before queuing skb into receive_queue Reported-by: Dave Jones Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- drivers/net/tun.c |2 ++ 1 file changed, 2 insertions(+) --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -417,6 +417,8 @@ static netdev_tx_t tun_net_xmit(struct s * for indefinite time. */ skb_orphan(skb); + nf_reset(skb); + /* Enqueue packet */ skb_queue_tail(&tun->socket.sk->sk_receive_queue, skb); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 44/48] bridging: fix rx_handlers return code
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Cristian Bercaru
[ Upstream commit 3bc1b1add7a8484cc4a261c3e128dbe1528ce01f ]
The frames for which rx_handlers return RX_HANDLER_CONSUMED are no longer
counted as dropped. They are counted as successfully received by
'netif_receive_skb'.
This allows network interface drivers to correctly update their RX-OK and
RX-DRP counters based on the result of 'netif_receive_skb'.
Signed-off-by: Cristian Bercaru
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/core/dev.c |1 +
1 file changed, 1 insertion(+)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3230,6 +3230,7 @@ ncls:
}
switch (rx_handler(&skb)) {
case RX_HANDLER_CONSUMED:
+ ret = NET_RX_SUCCESS;
goto out;
case RX_HANDLER_ANOTHER:
goto another_round;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 46/48] rtnl: fix info leak on RTM_GETLINK request for VF devices
3.4-stable review patch. If anyone has any objections, please let me know. -- From: Mathias Krause [ Upstream commit 84d73cd3fb142bf1298a8c13fd4ca50fd2432372 ] Initialize the mac address buffer with 0 as the driver specific function will probably not fill the whole buffer. In fact, all in-kernel drivers fill only ETH_ALEN of the MAX_ADDR_LEN bytes, i.e. 6 of the 32 possible bytes. Therefore we currently leak 26 bytes of stack memory to userland via the netlink interface. Signed-off-by: Mathias Krause Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/core/rtnetlink.c |1 + 1 file changed, 1 insertion(+) --- a/net/core/rtnetlink.c +++ b/net/core/rtnetlink.c @@ -975,6 +975,7 @@ static int rtnl_fill_ifinfo(struct sk_bu * report anything. */ ivi.spoofchk = -1; + memset(ivi.mac, 0, sizeof(ivi.mac)); if (dev->netdev_ops->ndo_get_vf_config(dev, i, &ivi)) break; vf_mac.vf = -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 45/48] ipv6: stop multicast forwarding to process interface scoped addresses
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Hannes Frederic Sowa
[ Upstream commit ddf64354af4a702ee0b85d0a285ba74c7278a460 ]
v2:
a) used struct ipv6_addr_props
v3:
a) reverted changes for ipv6_addr_props
v4:
a) do not use __ipv6_addr_needs_scope_id
Cc: YOSHIFUJI Hideaki
Signed-off-by: Hannes Frederic Sowa
Acked-by: YOSHIFUJI Hideaki
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/ipv6/ip6_input.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -265,7 +265,8 @@ int ip6_mc_input(struct sk_buff *skb)
* IPv6 multicast router mode is now supported ;)
*/
if (dev_net(skb->dev)->ipv6.devconf_all->mc_forwarding &&
- !(ipv6_addr_type(&hdr->daddr) & IPV6_ADDR_LINKLOCAL) &&
+ !(ipv6_addr_type(&hdr->daddr) &
+ (IPV6_ADDR_LOOPBACK|IPV6_ADDR_LINKLOCAL)) &&
likely(!(IP6CB(skb)->flags & IP6SKB_FORWARDED))) {
/*
* Okay, we try to forward - split and duplicate
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 43/48] netlabel: correctly list all the static label mappings
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Paul Moore
[ Upstream commits 0c1233aba1e948c37f6dc7620cb7c253fcd71ce9 and
a6a8fe950e1b8596bb06f2c89c3a1a4bf2011ba9 ]
When we have a large number of static label mappings that spill across
the netlink message boundary we fail to properly save our state in the
netlink_callback struct which causes us to repeat the same listings.
This patch fixes this problem by saving the state correctly between
calls to the NetLabel static label netlink "dumpit" routines.
Signed-off-by: Paul Moore
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/netlabel/netlabel_unlabeled.c | 27 +++
1 file changed, 11 insertions(+), 16 deletions(-)
--- a/net/netlabel/netlabel_unlabeled.c
+++ b/net/netlabel/netlabel_unlabeled.c
@@ -1189,8 +1189,6 @@ static int netlbl_unlabel_staticlist(str
struct netlbl_unlhsh_walk_arg cb_arg;
u32 skip_bkt = cb->args[0];
u32 skip_chain = cb->args[1];
- u32 skip_addr4 = cb->args[2];
- u32 skip_addr6 = cb->args[3];
u32 iter_bkt;
u32 iter_chain = 0, iter_addr4 = 0, iter_addr6 = 0;
struct netlbl_unlhsh_iface *iface;
@@ -1215,7 +1213,7 @@ static int netlbl_unlabel_staticlist(str
continue;
netlbl_af4list_foreach_rcu(addr4,
&iface->addr4_list) {
- if (iter_addr4++ < skip_addr4)
+ if (iter_addr4++ < cb->args[2])
continue;
if (netlbl_unlabel_staticlist_gen(
NLBL_UNLABEL_C_STATICLIST,
@@ -1231,7 +1229,7 @@ static int netlbl_unlabel_staticlist(str
#if IS_ENABLED(CONFIG_IPV6)
netlbl_af6list_foreach_rcu(addr6,
&iface->addr6_list) {
- if (iter_addr6++ < skip_addr6)
+ if (iter_addr6++ < cb->args[3])
continue;
if (netlbl_unlabel_staticlist_gen(
NLBL_UNLABEL_C_STATICLIST,
@@ -1250,10 +1248,10 @@ static int netlbl_unlabel_staticlist(str
unlabel_staticlist_return:
rcu_read_unlock();
- cb->args[0] = skip_bkt;
- cb->args[1] = skip_chain;
- cb->args[2] = skip_addr4;
- cb->args[3] = skip_addr6;
+ cb->args[0] = iter_bkt;
+ cb->args[1] = iter_chain;
+ cb->args[2] = iter_addr4;
+ cb->args[3] = iter_addr6;
return skb->len;
}
@@ -1273,12 +1271,9 @@ static int netlbl_unlabel_staticlistdef(
{
struct netlbl_unlhsh_walk_arg cb_arg;
struct netlbl_unlhsh_iface *iface;
- u32 skip_addr4 = cb->args[0];
- u32 skip_addr6 = cb->args[1];
- u32 iter_addr4 = 0;
+ u32 iter_addr4 = 0, iter_addr6 = 0;
struct netlbl_af4list *addr4;
#if IS_ENABLED(CONFIG_IPV6)
- u32 iter_addr6 = 0;
struct netlbl_af6list *addr6;
#endif
@@ -1292,7 +1287,7 @@ static int netlbl_unlabel_staticlistdef(
goto unlabel_staticlistdef_return;
netlbl_af4list_foreach_rcu(addr4, &iface->addr4_list) {
- if (iter_addr4++ < skip_addr4)
+ if (iter_addr4++ < cb->args[0])
continue;
if (netlbl_unlabel_staticlist_gen(NLBL_UNLABEL_C_STATICLISTDEF,
iface,
@@ -1305,7 +1300,7 @@ static int netlbl_unlabel_staticlistdef(
}
#if IS_ENABLED(CONFIG_IPV6)
netlbl_af6list_foreach_rcu(addr6, &iface->addr6_list) {
- if (iter_addr6++ < skip_addr6)
+ if (iter_addr6++ < cb->args[1])
continue;
if (netlbl_unlabel_staticlist_gen(NLBL_UNLABEL_C_STATICLISTDEF,
iface,
@@ -1320,8 +1315,8 @@ static int netlbl_unlabel_staticlistdef(
unlabel_staticlistdef_return:
rcu_read_unlock();
- cb->args[0] = skip_addr4;
- cb->args[1] = skip_addr6;
+ cb->args[0] = iter_addr4;
+ cb->args[1] = iter_addr6;
return skb->len;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 40/48] tcp: fix double-counted receiver RTT when leaving receiver fast path
3.4-stable review patch. If anyone has any objections, please let me know. -- From: Neal Cardwell [ Upstream commit aab2b4bf224ef8358d262f95b568b8ad0cecf0a0 ] We should not update ts_recent and call tcp_rcv_rtt_measure_ts() both before and after going to step5. That wastes CPU and double-counts the receiver-side RTT sample. Signed-off-by: Neal Cardwell Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/ipv4/tcp_input.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -5519,6 +5519,9 @@ int tcp_rcv_established(struct sock *sk, if (tcp_checksum_complete_user(sk, skb)) goto csum_error; + if ((int)skb->truesize > sk->sk_forward_alloc) + goto step5; + /* Predicted packet is in window by definition. * seq == rcv_nxt and rcv_wup <= rcv_nxt. * Hence, check seq<=rcv_wup reduces to: @@ -5530,9 +5533,6 @@ int tcp_rcv_established(struct sock *sk, tcp_rcv_rtt_measure_ts(sk, skb); - if ((int)skb->truesize > sk->sk_forward_alloc) - goto step5; - NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPHPHITS); /* Bulk data transfer: receiver */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 18/40] hwmon: (lineage-pem) Add missing terminating entry for pem_[input|fan]_attributes
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Axel Lin
commit df069079c153d22adf6c28dcc0b1cf62bba75167 upstream.
Signed-off-by: Axel Lin
Acked-by: Jean Delvare
Signed-off-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman
---
drivers/hwmon/lineage-pem.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/hwmon/lineage-pem.c
+++ b/drivers/hwmon/lineage-pem.c
@@ -421,6 +421,7 @@ static struct attribute *pem_input_attri
&sensor_dev_attr_in2_input.dev_attr.attr,
&sensor_dev_attr_curr1_input.dev_attr.attr,
&sensor_dev_attr_power1_input.dev_attr.attr,
+ NULL
};
static const struct attribute_group pem_input_group = {
@@ -431,6 +432,7 @@ static struct attribute *pem_fan_attribu
&sensor_dev_attr_fan1_input.dev_attr.attr,
&sensor_dev_attr_fan2_input.dev_attr.attr,
&sensor_dev_attr_fan3_input.dev_attr.attr,
+ NULL
};
static const struct attribute_group pem_fan_group = {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 17/40] ALSA: seq: Fix missing error handling in snd_seq_timer_open()
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Takashi Iwai
commit 66efdc71d95887b652a742a5dae51fa834d71465 upstream.
snd_seq_timer_open() didn't catch the whole error path but let through
if the timer id is a slave. This may lead to Oops by accessing the
uninitialized pointer.
BUG: unable to handle kernel NULL pointer dereference at 02ae
IP: [] snd_seq_timer_open+0xe7/0x130
PGD 785cd067 PUD 76964067 PMD 0
Oops: 0002 [#4] SMP
CPU 0
Pid: 4288, comm: trinity-child7 Tainted: G D W 3.9.0-rc1+ #100 Bochs Bochs
RIP: 0010:[] []
snd_seq_timer_open+0xe7/0x130
RSP: 0018:88006ece7d38 EFLAGS: 00010246
RAX: 0286 RBX: 88007851b400 RCX:
RDX: RSI: 88006ece7d58 RDI: 88006ece7d38
RBP: 88006ece7d98 R08: 000a R09: fffe
R10: R11: R12:
R13: 8800792c5400 R14: 00e8f000 R15: 0007
FS: 7f7aaa650700() GS:88007f80() GS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 02ae CR3: 6efec000 CR4: 06f0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process trinity-child7 (pid: 4288, threadinfo 88006ece6000, task
880076a8a290)
Stack:
0286 828f2be0 88006ece7d58 810f354d
65636e6575716573 2065756575712072 8800792c0030
88006ece7d98 8800792c5400 88007851b400 8800792c5520
Call Trace:
[] ? trace_hardirqs_on+0xd/0x10
[] snd_seq_queue_timer_open+0x29/0x70
[] snd_seq_ioctl_set_queue_timer+0xda/0x120
[] snd_seq_do_ioctl+0x9b/0xd0
[] snd_seq_ioctl+0x10/0x20
[] do_vfs_ioctl+0x522/0x570
[] ? file_has_perm+0x83/0xa0
[] ? trace_hardirqs_on+0xd/0x10
[] sys_ioctl+0x5d/0xa0
[] ? trace_hardirqs_on_thunk+0x3a/0x3f
[] system_call_fastpath+0x16/0x1b
Reported-and-tested-by: Tommi Rantala
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
---
sound/core/seq/seq_timer.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/sound/core/seq/seq_timer.c
+++ b/sound/core/seq/seq_timer.c
@@ -290,10 +290,10 @@ int snd_seq_timer_open(struct snd_seq_qu
tid.device = SNDRV_TIMER_GLOBAL_SYSTEM;
err = snd_timer_open(&t, str, &tid, q->queue);
}
- if (err < 0) {
- snd_printk(KERN_ERR "seq fatal error: cannot create
timer (%i)\n", err);
- return err;
- }
+ }
+ if (err < 0) {
+ snd_printk(KERN_ERR "seq fatal error: cannot create timer
(%i)\n", err);
+ return err;
}
t->callback = snd_seq_timer_interrupt;
t->callback_data = q;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 32/40] rds: limit the size allocated by rds_message_alloc()
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Cong Wang
[ Upstream commit ece6b0a2b25652d684a7ced4ae680a863af041e0 ]
Dave Jones reported the following bug:
"When fed mangled socket data, rds will trust what userspace gives it,
and tries to allocate enormous amounts of memory larger than what
kmalloc can satisfy."
WARNING: at mm/page_alloc.c:2393 __alloc_pages_nodemask+0xa0d/0xbe0()
Hardware name: GA-MA78GM-S2H
Modules linked in: vmw_vsock_vmci_transport vmw_vmci vsock fuse bnep dlci
bridge 8021q garp stp mrp binfmt_misc l2tp_ppp l2tp_core rfcomm s
Pid: 24652, comm: trinity-child2 Not tainted 3.8.0+ #65
Call Trace:
[] warn_slowpath_common+0x75/0xa0
[] warn_slowpath_null+0x1a/0x20
[] __alloc_pages_nodemask+0xa0d/0xbe0
[] ? native_sched_clock+0x26/0x90
[] ? trace_hardirqs_off_caller+0x28/0xc0
[] ? trace_hardirqs_off+0xd/0x10
[] alloc_pages_current+0xb8/0x180
[] __get_free_pages+0x2a/0x80
[] kmalloc_order_trace+0x3e/0x1a0
[] __kmalloc+0x2f5/0x3a0
[] ? local_bh_enable_ip+0x7c/0xf0
[] rds_message_alloc+0x23/0xb0 [rds]
[] rds_sendmsg+0x2b1/0x990 [rds]
[] ? trace_hardirqs_off+0xd/0x10
[] sock_sendmsg+0xb0/0xe0
[] ? get_lock_stats+0x22/0x70
[] ? put_lock_stats.isra.23+0xe/0x40
[] sys_sendto+0x130/0x180
[] ? trace_hardirqs_on+0xd/0x10
[] ? _raw_spin_unlock_irq+0x3b/0x60
[] ? sysret_check+0x1b/0x56
[] ? trace_hardirqs_on_caller+0x115/0x1a0
[] ? trace_hardirqs_on_thunk+0x3a/0x3f
[] system_call_fastpath+0x16/0x1b
---[ end trace eed6ae990d018c8b ]---
Reported-by: Dave Jones
Cc: Dave Jones
Cc: David S. Miller
Cc: Venkat Venkatsubra
Signed-off-by: Cong Wang
Acked-by: Venkat Venkatsubra
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/rds/message.c |3 +++
1 file changed, 3 insertions(+)
--- a/net/rds/message.c
+++ b/net/rds/message.c
@@ -196,6 +196,9 @@ struct rds_message *rds_message_alloc(un
{
struct rds_message *rm;
+ if (extra_len > KMALLOC_MAX_SIZE - sizeof(struct rds_message))
+ return NULL;
+
rm = kzalloc(sizeof(struct rds_message) + extra_len, gfp);
if (!rm)
goto out;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 21/40] selinux: use GFP_ATOMIC under spin_lock
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Dan Carpenter
commit 4502403dcf8f5c76abd4dbab8726c8e4ecb5cd34 upstream.
The call tree here is:
sk_clone_lock() <- takes bh_lock_sock(newsk);
xfrm_sk_clone_policy()
__xfrm_sk_clone_policy()
clone_policy() <- uses GFP_ATOMIC for allocations
security_xfrm_policy_clone()
security_ops->xfrm_policy_clone_security()
selinux_xfrm_policy_clone()
Signed-off-by: Dan Carpenter
Signed-off-by: James Morris
Signed-off-by: Greg Kroah-Hartman
---
security/selinux/xfrm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/security/selinux/xfrm.c
+++ b/security/selinux/xfrm.c
@@ -310,7 +310,7 @@ int selinux_xfrm_policy_clone(struct xfr
if (old_ctx) {
new_ctx = kmalloc(sizeof(*old_ctx) + old_ctx->ctx_len,
- GFP_KERNEL);
+ GFP_ATOMIC);
if (!new_ctx)
return -ENOMEM;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 37/40] bridging: fix rx_handlers return code
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Cristian Bercaru
[ Upstream commit 3bc1b1add7a8484cc4a261c3e128dbe1528ce01f ]
The frames for which rx_handlers return RX_HANDLER_CONSUMED are no longer
counted as dropped. They are counted as successfully received by
'netif_receive_skb'.
This allows network interface drivers to correctly update their RX-OK and
RX-DRP counters based on the result of 'netif_receive_skb'.
Signed-off-by: Cristian Bercaru
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/core/dev.c |1 +
1 file changed, 1 insertion(+)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3165,6 +3165,7 @@ ncls:
}
switch (rx_handler(&skb)) {
case RX_HANDLER_CONSUMED:
+ ret = NET_RX_SUCCESS;
goto out;
case RX_HANDLER_ANOTHER:
goto another_round;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 40/40] dcbnl: fix various netlink info leaks
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Mathias Krause
[ Upstream commit 29cd8ae0e1a39e239a3a7b67da1986add1199fc0 ]
The dcb netlink interface leaks stack memory in various places:
* perm_addr[] buffer is only filled at max with 12 of the 32 bytes but
copied completely,
* no in-kernel driver fills all fields of an IEEE 802.1Qaz subcommand,
so we're leaking up to 58 bytes for ieee_ets structs, up to 136 bytes
for ieee_pfc structs, etc.,
* the same is true for CEE -- no in-kernel driver fills the whole
struct,
Prevent all of the above stack info leaks by properly initializing the
buffers/structures involved.
Signed-off-by: Mathias Krause
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/dcb/dcbnl.c |7 +++
1 file changed, 7 insertions(+)
--- a/net/dcb/dcbnl.c
+++ b/net/dcb/dcbnl.c
@@ -335,6 +335,7 @@ static int dcbnl_getperm_hwaddr(struct n
dcb->dcb_family = AF_UNSPEC;
dcb->cmd = DCB_CMD_GPERM_HWADDR;
+ memset(perm_addr, 0, sizeof(perm_addr));
netdev->dcbnl_ops->getpermhwaddr(netdev, perm_addr);
ret = nla_put(dcbnl_skb, DCB_ATTR_PERM_HWADDR, sizeof(perm_addr),
@@ -1311,6 +1312,7 @@ static int dcbnl_ieee_get(struct net_dev
if (ops->ieee_getets) {
struct ieee_ets ets;
+ memset(&ets, 0, sizeof(ets));
err = ops->ieee_getets(netdev, &ets);
if (!err)
NLA_PUT(skb, DCB_ATTR_IEEE_ETS, sizeof(ets), &ets);
@@ -1318,6 +1320,7 @@ static int dcbnl_ieee_get(struct net_dev
if (ops->ieee_getpfc) {
struct ieee_pfc pfc;
+ memset(&pfc, 0, sizeof(pfc));
err = ops->ieee_getpfc(netdev, &pfc);
if (!err)
NLA_PUT(skb, DCB_ATTR_IEEE_PFC, sizeof(pfc), &pfc);
@@ -1344,6 +1347,7 @@ static int dcbnl_ieee_get(struct net_dev
/* get peer info if available */
if (ops->ieee_peer_getets) {
struct ieee_ets ets;
+ memset(&ets, 0, sizeof(ets));
err = ops->ieee_peer_getets(netdev, &ets);
if (!err)
NLA_PUT(skb, DCB_ATTR_IEEE_PEER_ETS, sizeof(ets), &ets);
@@ -1351,6 +1355,7 @@ static int dcbnl_ieee_get(struct net_dev
if (ops->ieee_peer_getpfc) {
struct ieee_pfc pfc;
+ memset(&pfc, 0, sizeof(pfc));
err = ops->ieee_peer_getpfc(netdev, &pfc);
if (!err)
NLA_PUT(skb, DCB_ATTR_IEEE_PEER_PFC, sizeof(pfc), &pfc);
@@ -1551,6 +1556,7 @@ static int dcbnl_cee_get(struct net_devi
/* get peer info if available */
if (ops->cee_peer_getpg) {
struct cee_pg pg;
+ memset(&pg, 0, sizeof(pg));
err = ops->cee_peer_getpg(netdev, &pg);
if (!err)
NLA_PUT(skb, DCB_ATTR_CEE_PEER_PG, sizeof(pg), &pg);
@@ -1558,6 +1564,7 @@ static int dcbnl_cee_get(struct net_devi
if (ops->cee_peer_getpfc) {
struct cee_pfc pfc;
+ memset(&pfc, 0, sizeof(pfc));
err = ops->cee_peer_getpfc(netdev, &pfc);
if (!err)
NLA_PUT(skb, DCB_ATTR_CEE_PEER_PFC, sizeof(pfc), &pfc);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 39/40] rtnl: fix info leak on RTM_GETLINK request for VF devices
3.0-stable review patch. If anyone has any objections, please let me know. -- From: Mathias Krause [ Upstream commit 84d73cd3fb142bf1298a8c13fd4ca50fd2432372 ] Initialize the mac address buffer with 0 as the driver specific function will probably not fill the whole buffer. In fact, all in-kernel drivers fill only ETH_ALEN of the MAX_ADDR_LEN bytes, i.e. 6 of the 32 possible bytes. Therefore we currently leak 26 bytes of stack memory to userland via the netlink interface. Signed-off-by: Mathias Krause Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/core/rtnetlink.c |1 + 1 file changed, 1 insertion(+) --- a/net/core/rtnetlink.c +++ b/net/core/rtnetlink.c @@ -963,6 +963,7 @@ static int rtnl_fill_ifinfo(struct sk_bu struct ifla_vf_mac vf_mac; struct ifla_vf_vlan vf_vlan; struct ifla_vf_tx_rate vf_tx_rate; + memset(ivi.mac, 0, sizeof(ivi.mac)); if (dev->netdev_ops->ndo_get_vf_config(dev, i, &ivi)) break; vf_mac.vf = vf_vlan.vf = vf_tx_rate.vf = ivi.vf; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 38/40] ipv6: stop multicast forwarding to process interface scoped addresses
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Hannes Frederic Sowa
[ Upstream commit ddf64354af4a702ee0b85d0a285ba74c7278a460 ]
v2:
a) used struct ipv6_addr_props
v3:
a) reverted changes for ipv6_addr_props
v4:
a) do not use __ipv6_addr_needs_scope_id
Cc: YOSHIFUJI Hideaki
Signed-off-by: Hannes Frederic Sowa
Acked-by: YOSHIFUJI Hideaki
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/ipv6/ip6_input.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -257,7 +257,8 @@ int ip6_mc_input(struct sk_buff *skb)
* IPv6 multicast router mode is now supported ;)
*/
if (dev_net(skb->dev)->ipv6.devconf_all->mc_forwarding &&
- !(ipv6_addr_type(&hdr->daddr) & IPV6_ADDR_LINKLOCAL) &&
+ !(ipv6_addr_type(&hdr->daddr) &
+ (IPV6_ADDR_LOOPBACK|IPV6_ADDR_LINKLOCAL)) &&
likely(!(IP6CB(skb)->flags & IP6SKB_FORWARDED))) {
/*
* Okay, we try to forward - split and duplicate
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 26/40] btrfs: use rcu_barrier() to wait for bdev puts at unmount
3.0-stable review patch. If anyone has any objections, please let me know. -- From: Eric Sandeen commit bc178622d40d87e75abc131007342429c9b03351 upstream. Doing this would reliably fail with -EBUSY for me: # mount /dev/sdb2 /mnt/scratch; umount /mnt/scratch; mkfs.btrfs -f /dev/sdb2 ... unable to open /dev/sdb2: Device or resource busy because mkfs.btrfs tries to open the device O_EXCL, and somebody still has it. Using systemtap to track bdev gets & puts shows a kworker thread doing a blkdev put after mkfs attempts a get; this is left over from the unmount path: btrfs_close_devices __btrfs_close_devices call_rcu(&device->rcu, free_device); free_device INIT_WORK(&device->rcu_work, __free_device); schedule_work(&device->rcu_work); so unmount might complete before __free_device fires & does its blkdev_put. Adding an rcu_barrier() to btrfs_close_devices() causes unmount to wait until all blkdev_put()s are done, and the device is truly free once unmount completes. Signed-off-by: Eric Sandeen Signed-off-by: Josef Bacik Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/volumes.c |6 ++ 1 file changed, 6 insertions(+) --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -546,6 +546,12 @@ int btrfs_close_devices(struct btrfs_fs_ __btrfs_close_devices(fs_devices); free_fs_devices(fs_devices); } + /* +* Wait for rcu kworkers under __btrfs_close_devices +* to finish all blkdev_puts so device is really +* free when umount is done. +*/ + rcu_barrier(); return ret; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 35/40] tun: add a missing nf_reset() in tun_net_xmit()
3.0-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet [ Upstream commit f8af75f3517a24838a36eb5797a1a3e60bf9e276 ] Dave reported following crash : general protection fault: [#1] SMP CPU 2 Pid: 25407, comm: qemu-kvm Not tainted 3.7.9-205.fc18.x86_64 #1 Hewlett-Packard HP Z400 Workstation/0B4Ch RIP: 0010:[] [] destroy_conntrack+0x35/0x120 [nf_conntrack] RSP: 0018:880276913d78 EFLAGS: 00010206 RAX: 50626b6b7876376c RBX: 88026e530d68 RCX: 88028d158e00 RDX: 88026d0d5470 RSI: 0011 RDI: 0002 RBP: 880276913d88 R08: R09: 880295002900 R10: R11: 0003 R12: 81ca3b40 R13: 8151a8e0 R14: 880270875000 R15: 0002 FS: 7ff3bce38a00() GS:88029fc4() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 7fd1430bd000 CR3: 00027042b000 CR4: 27e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process qemu-kvm (pid: 25407, threadinfo 880276912000, task 88028c369720) Stack: 880156f59100 880156f59100 880276913d98 815534f7 880276913db8 8151a74b 880270875000 880156f59100 880276913dd8 8151a5a6 880276913dd8 88026d0d5470 Call Trace: [] nf_conntrack_destroy+0x17/0x20 [] skb_release_head_state+0x7b/0x100 [] __kfree_skb+0x16/0xa0 [] kfree_skb+0x36/0xa0 [] skb_queue_purge+0x20/0x40 [] __tun_detach+0x117/0x140 [tun] [] tun_chr_close+0x3c/0xd0 [tun] [] __fput+0xec/0x240 [] fput+0xe/0x10 [] task_work_run+0xa7/0xe0 [] do_notify_resume+0x71/0xb0 [] int_signal+0x12/0x17 Code: 00 00 04 48 89 e5 41 54 53 48 89 fb 4c 8b a7 e8 00 00 00 0f 85 de 00 00 00 0f b6 73 3e 0f b7 7b 2a e8 10 40 00 00 48 85 c0 74 0e <48> 8b 40 28 48 85 c0 74 05 48 89 df ff d0 48 c7 c7 08 6a 3a a0 RIP [] destroy_conntrack+0x35/0x120 [nf_conntrack] RSP This is because tun_net_xmit() needs to call nf_reset() before queuing skb into receive_queue Reported-by: Dave Jones Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- drivers/net/tun.c |2 ++ 1 file changed, 2 insertions(+) --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -417,6 +417,8 @@ static netdev_tx_t tun_net_xmit(struct s * for indefinite time. */ skb_orphan(skb); + nf_reset(skb); + /* Enqueue packet */ skb_queue_tail(&tun->socket.sk->sk_receive_queue, skb); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 20/40] powerpc: Fix cputable entry for 970MP rev 1.0
3.0-stable review patch. If anyone has any objections, please let me know. -- From: Benjamin Herrenschmidt commit d63ac5f6cf31c8a83170a9509b350c1489a7262b upstream. Commit 44ae3ab3358e962039c36ad4ae461ae9fb29596c forgot to update the entry for the 970MP rev 1.0 processor when moving some CPU features bits to the MMU feature bit mask. This breaks booting on some rare G5 models using that chip revision. Reported-by: Phileas Fogg Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman --- arch/powerpc/kernel/cputable.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/kernel/cputable.c +++ b/arch/powerpc/kernel/cputable.c @@ -268,7 +268,7 @@ static struct cpu_spec __initdata cpu_sp .cpu_features = CPU_FTRS_PPC970, .cpu_user_features = COMMON_USER_POWER4 | PPC_FEATURE_HAS_ALTIVEC_COMP, - .mmu_features = MMU_FTR_HPTE_TABLE, + .mmu_features = MMU_FTRS_PPC970, .icache_bsize = 128, .dcache_bsize = 128, .num_pmcs = 8, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 19/40] w1: fix oops when w1_search is called from netlink connector
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Marcin Jurkowski
commit 9d1817cab2f030f6af360e961cc69bb1da8ad765 upstream.
On Sat, Mar 02, 2013 at 10:45:10AM +0100, Sven Geggus wrote:
> This is the bad commit I found doing git bisect:
> 04f482faf50535229a5a5c8d629cf963899f857c is the first bad commit
> commit 04f482faf50535229a5a5c8d629cf963899f857c
> Author: Patrick McHardy
> Date: Mon Mar 28 08:39:36 2011 +
Good job. I was too lazy to bisect for bad commit;)
Reading the code I found problematic kthread_should_stop call from netlink
connector which causes the oops. After applying a patch, I've been testing
owfs+w1 setup for nearly two days and it seems to work very reliable (no
hangs, no memleaks etc).
More detailed description and possible fix is given below:
Function w1_search can be called from either kthread or netlink callback.
While the former works fine, the latter causes oops due to kthread_should_stop
invocation.
This patch adds a check if w1_search is serving netlink command, skipping
kthread_should_stop invocation if so.
Signed-off-by: Marcin Jurkowski
Acked-by: Evgeniy Polyakov
Cc: Josh Boyer
Tested-by: Sven Geggus
Signed-off-by: Greg Kroah-Hartman
---
drivers/w1/w1.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -918,7 +918,8 @@ void w1_search(struct w1_master *dev, u8
tmp64 = (triplet_ret >> 2);
rn |= (tmp64 << i);
- if (kthread_should_stop()) {
+ /* ensure we're called from kthread and not by netlink
callback */
+ if (!dev->priv && kthread_should_stop()) {
dev_dbg(&dev->dev, "Abort w1_search\n");
return;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 34/40] tcp: fix double-counted receiver RTT when leaving receiver fast path
3.0-stable review patch. If anyone has any objections, please let me know. -- From: Neal Cardwell [ Upstream commit aab2b4bf224ef8358d262f95b568b8ad0cecf0a0 ] We should not update ts_recent and call tcp_rcv_rtt_measure_ts() both before and after going to step5. That wastes CPU and double-counts the receiver-side RTT sample. Signed-off-by: Neal Cardwell Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/ipv4/tcp_input.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -5419,6 +5419,9 @@ int tcp_rcv_established(struct sock *sk, if (tcp_checksum_complete_user(sk, skb)) goto csum_error; + if ((int)skb->truesize > sk->sk_forward_alloc) + goto step5; + /* Predicted packet is in window by definition. * seq == rcv_nxt and rcv_wup <= rcv_nxt. * Hence, check seq<=rcv_wup reduces to: @@ -5430,9 +5433,6 @@ int tcp_rcv_established(struct sock *sk, tcp_rcv_rtt_measure_ts(sk, skb); - if ((int)skb->truesize > sk->sk_forward_alloc) - goto step5; - NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPHPHITS); /* Bulk data transfer: receiver */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 33/40] net: ipv6: Dont purge default router if accept_ra=2
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Lorenzo Colitti
[ Upstream commit 3e8b0ac3e41e3c88a5522d5df7212438ab51 ]
Setting net.ipv6.conf..accept_ra=2 causes the kernel
to accept RAs even when forwarding is enabled. However, enabling
forwarding purges all default routes on the system, breaking
connectivity until the next RA is received. Fix this by not
purging default routes on interfaces that have accept_ra=2.
Signed-off-by: Lorenzo Colitti
Acked-by: YOSHIFUJI Hideaki
Acked-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/ipv6/route.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1885,7 +1885,8 @@ void rt6_purge_dflt_routers(struct net *
restart:
read_lock_bh(&table->tb6_lock);
for (rt = table->tb6_root.leaf; rt; rt = rt->dst.rt6_next) {
- if (rt->rt6i_flags & (RTF_DEFAULT | RTF_ADDRCONF)) {
+ if (rt->rt6i_flags & (RTF_DEFAULT | RTF_ADDRCONF) &&
+ (!rt->rt6i_idev || rt->rt6i_idev->cnf.accept_ra != 2)) {
dst_hold(&rt->dst);
read_unlock_bh(&table->tb6_lock);
ip6_del_rt(rt);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 31/40] l2tp: Restore socket refcount when sendmsg succeeds
3.0-stable review patch. If anyone has any objections, please let me know. -- From: Guillaume Nault [ Upstream commit 8b82547e33e85fc24d4d172a93c796de1fefa81a ] The sendmsg() syscall handler for PPPoL2TP doesn't decrease the socket reference counter after successful transmissions. Any successful sendmsg() call from userspace will then increase the reference counter forever, thus preventing the kernel's session and tunnel data from being freed later on. The problem only happens when writing directly on L2TP sockets. PPP sockets attached to L2TP are unaffected as the PPP subsystem uses pppol2tp_xmit() which symmetrically increase/decrease reference counters. This patch adds the missing call to sock_put() before returning from pppol2tp_sendmsg(). Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/l2tp/l2tp_ppp.c |1 + 1 file changed, 1 insertion(+) --- a/net/l2tp/l2tp_ppp.c +++ b/net/l2tp/l2tp_ppp.c @@ -360,6 +360,7 @@ static int pppol2tp_sendmsg(struct kiocb l2tp_xmit_skb(session, skb, session->hdr_len); sock_put(ps->tunnel_sock); + sock_put(sk); return error; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 30/40] loopdev: fix a deadlock
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Guo Chao
commit 5370019dc2d2c2ff90e95d181468071362934f3a upstream.
bd_mutex and lo_ctl_mutex can be held in different order.
Path #1:
blkdev_open
blkdev_get
__blkdev_get (hold bd_mutex)
lo_open (hold lo_ctl_mutex)
Path #2:
blkdev_ioctl
lo_ioctl (hold lo_ctl_mutex)
lo_set_capacity (hold bd_mutex)
Lockdep does not report it, because path #2 actually holds a subclass of
lo_ctl_mutex. This subclass seems creep into the code by mistake. The
patch author actually just mentioned it in the changelog, see commit
f028f3b2 ("loop: fix circular locking in loop_clr_fd()"), also see:
http://marc.info/?l=linux-kernel&m=123806169129727&w=2
Path #2 hold bd_mutex to call bd_set_size(), I've protected it
with i_mutex in a previous patch, so drop bd_mutex at this site.
Signed-off-by: Guo Chao
Cc: Alexander Viro
Cc: Guo Chao
Cc: M. Hindess
Cc: Nikanth Karthikesan
Cc: Jens Axboe
Signed-off-by: Andrew Morton
Signed-off-by: Jens Axboe
Acked-by: Jeff Mahoney
Signed-off-by: Greg Kroah-Hartman
---
drivers/block/loop.c |2 --
1 file changed, 2 deletions(-)
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1274,11 +1274,9 @@ static int loop_set_capacity(struct loop
/* the width of sector_t may be narrow for bit-shift */
sz = sec;
sz <<= 9;
- mutex_lock(&bdev->bd_mutex);
bd_set_size(bdev, sz);
/* let user-space know about the new size */
kobject_uevent(&disk_to_dev(bdev->bd_disk)->kobj, KOBJ_CHANGE);
- mutex_unlock(&bdev->bd_mutex);
out:
return err;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 29/40] block: use i_size_write() in bd_set_size()
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Guo Chao
commit d646a02a9d44d1421f273ae3923d97b47b918176 upstream.
blkdev_ioctl(GETBLKSIZE) uses i_size_read() to read size of block device.
If we update block size directly, reader may see intermediate result in
some machines and configurations. Use i_size_write() instead.
Signed-off-by: Guo Chao
Cc: Alexander Viro
Cc: Guo Chao
Cc: M. Hindess
Cc: Nikanth Karthikesan
Cc: Jens Axboe
Signed-off-by: Andrew Morton
Signed-off-by: Jens Axboe
Acked-by: Jeff Mahoney
Signed-off-by: Greg Kroah-Hartman
---
fs/block_dev.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1052,7 +1052,9 @@ void bd_set_size(struct block_device *bd
{
unsigned bsize = bdev_logical_block_size(bdev);
- bdev->bd_inode->i_size = size;
+ mutex_lock(&bdev->bd_inode->i_mutex);
+ i_size_write(bdev->bd_inode, size);
+ mutex_unlock(&bdev->bd_inode->i_mutex);
while (bsize < PAGE_CACHE_SIZE) {
if (size & bsize)
break;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 28/40] hwmon: (sht15) Fix memory leak if regulator_enable() fails
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Ben Hutchings
Commit 3e78080f8148 ('hwmon: (sht15) Check return value of
regulator_enable()') depends on the use of devm_kmalloc() for automatic
resource cleanup in the failure cases, which was introduced in 3.7. In
older stable branches, explicit cleanup is needed.
Signed-off-by: Ben Hutchings
Signed-off-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman
---
Applies to stable branches between 3.0 and 3.6 where commit 3e78080f8148
has been applied.
drivers/hwmon/sht15.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/hwmon/sht15.c
+++ b/drivers/hwmon/sht15.c
@@ -930,7 +930,7 @@ static int __devinit sht15_probe(struct
if (ret != 0) {
dev_err(&pdev->dev,
"failed to enable regulator: %d\n", ret);
- return ret;
+ goto err_free_data;
}
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 27/40] drm/i915: EBUSY status handling added to i915_gem_fault().
3.0-stable review patch. If anyone has any objections, please let me know. -- From: Dmitry Rogozhkin commit e79e0fe380847493266fba557217e2773c61bd1b upstream. Subsequent threads returning EBUSY from vm_insert_pfn() was not handled correctly. As a result concurrent access from new threads to mmapped data caused SIGBUS. Note that this fixes i-g-t/tests/gem_threaded_tiled_access. Tested-by: Mika Kuoppala Signed-off-by: Dmitry Rogozhkin Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/i915/i915_gem.c |5 + 1 file changed, 5 insertions(+) --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -1256,6 +1256,11 @@ out: case 0: case -ERESTARTSYS: case -EINTR: + case -EBUSY: + /* +* EBUSY is ok: this just means that another thread +* already did the job. +*/ return VM_FAULT_NOPAGE; case -ENOMEM: return VM_FAULT_OOM; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 36/40] netlabel: correctly list all the static label mappings
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Paul Moore
[ Upstream commits 0c1233aba1e948c37f6dc7620cb7c253fcd71ce9 and
a6a8fe950e1b8596bb06f2c89c3a1a4bf2011ba9 ]
When we have a large number of static label mappings that spill across
the netlink message boundary we fail to properly save our state in the
netlink_callback struct which causes us to repeat the same listings.
This patch fixes this problem by saving the state correctly between
calls to the NetLabel static label netlink "dumpit" routines.
Signed-off-by: Paul Moore
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/netlabel/netlabel_unlabeled.c | 27 +++
1 file changed, 11 insertions(+), 16 deletions(-)
--- a/net/netlabel/netlabel_unlabeled.c
+++ b/net/netlabel/netlabel_unlabeled.c
@@ -1192,8 +1192,6 @@ static int netlbl_unlabel_staticlist(str
struct netlbl_unlhsh_walk_arg cb_arg;
u32 skip_bkt = cb->args[0];
u32 skip_chain = cb->args[1];
- u32 skip_addr4 = cb->args[2];
- u32 skip_addr6 = cb->args[3];
u32 iter_bkt;
u32 iter_chain = 0, iter_addr4 = 0, iter_addr6 = 0;
struct netlbl_unlhsh_iface *iface;
@@ -1218,7 +1216,7 @@ static int netlbl_unlabel_staticlist(str
continue;
netlbl_af4list_foreach_rcu(addr4,
&iface->addr4_list) {
- if (iter_addr4++ < skip_addr4)
+ if (iter_addr4++ < cb->args[2])
continue;
if (netlbl_unlabel_staticlist_gen(
NLBL_UNLABEL_C_STATICLIST,
@@ -1234,7 +1232,7 @@ static int netlbl_unlabel_staticlist(str
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
netlbl_af6list_foreach_rcu(addr6,
&iface->addr6_list) {
- if (iter_addr6++ < skip_addr6)
+ if (iter_addr6++ < cb->args[3])
continue;
if (netlbl_unlabel_staticlist_gen(
NLBL_UNLABEL_C_STATICLIST,
@@ -1253,10 +1251,10 @@ static int netlbl_unlabel_staticlist(str
unlabel_staticlist_return:
rcu_read_unlock();
- cb->args[0] = skip_bkt;
- cb->args[1] = skip_chain;
- cb->args[2] = skip_addr4;
- cb->args[3] = skip_addr6;
+ cb->args[0] = iter_bkt;
+ cb->args[1] = iter_chain;
+ cb->args[2] = iter_addr4;
+ cb->args[3] = iter_addr6;
return skb->len;
}
@@ -1276,12 +1274,9 @@ static int netlbl_unlabel_staticlistdef(
{
struct netlbl_unlhsh_walk_arg cb_arg;
struct netlbl_unlhsh_iface *iface;
- u32 skip_addr4 = cb->args[0];
- u32 skip_addr6 = cb->args[1];
- u32 iter_addr4 = 0;
+ u32 iter_addr4 = 0, iter_addr6 = 0;
struct netlbl_af4list *addr4;
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
- u32 iter_addr6 = 0;
struct netlbl_af6list *addr6;
#endif
@@ -1295,7 +1290,7 @@ static int netlbl_unlabel_staticlistdef(
goto unlabel_staticlistdef_return;
netlbl_af4list_foreach_rcu(addr4, &iface->addr4_list) {
- if (iter_addr4++ < skip_addr4)
+ if (iter_addr4++ < cb->args[0])
continue;
if (netlbl_unlabel_staticlist_gen(NLBL_UNLABEL_C_STATICLISTDEF,
iface,
@@ -1308,7 +1303,7 @@ static int netlbl_unlabel_staticlistdef(
}
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
netlbl_af6list_foreach_rcu(addr6, &iface->addr6_list) {
- if (iter_addr6++ < skip_addr6)
+ if (iter_addr6++ < cb->args[1])
continue;
if (netlbl_unlabel_staticlist_gen(NLBL_UNLABEL_C_STATICLISTDEF,
iface,
@@ -1323,8 +1318,8 @@ static int netlbl_unlabel_staticlistdef(
unlabel_staticlistdef_return:
rcu_read_unlock();
- cb->args[0] = skip_addr4;
- cb->args[1] = skip_addr6;
+ cb->args[0] = iter_addr4;
+ cb->args[1] = iter_addr6;
return skb->len;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 15/40] md: protect against crash upon fsync on ro array
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Sebastian Riemer
commit bbfa57c0f2243a7c31fd248d22e9861a2802cad5 upstream.
If an fsync occurs on a read-only array, we need to send a
completion for the IO and may not increment the active IO count.
Otherwise, we hit a bug trace and can't stop the MD array anymore.
By advice of Christoph Hellwig we return success upon a flush
request but we return -EROFS for other writes.
We detect flush requests by checking if the bio has zero sectors.
Signed-off-by: Sebastian Riemer
Cc: Christoph Hellwig
Cc: Ben Hutchings
Cc: NeilBrown
Reported-by: Ben Hutchings
Acked-by: Paul Menzel
Signed-off-by: Greg Kroah-Hartman
---
drivers/md/md.c |4
1 file changed, 4 insertions(+)
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -299,6 +299,10 @@ static int md_make_request(struct reques
bio_io_error(bio);
return 0;
}
+ if (mddev->ro == 1 && unlikely(rw == WRITE)) {
+ bio_endio(bio, bio_sectors(bio) == 0 ? 0 : -EROFS);
+ return 0;
+ }
smp_rmb(); /* Ensure implications of 'active' are visible */
rcu_read_lock();
if (mddev->suspended) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 02/40] virtio: rng: disallow multiple device registrations, fixes crashes
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Amit Shah
commit e84e7a56a3aa2963db506299e29a5f3f09377f9b upstream.
The code currently only supports one virtio-rng device at a time.
Invoking guests with multiple devices causes the guest to blow up.
Check if we've already registered and initialised the driver. Also
cleanup in case of registration errors or hot-unplug so that a new
device can be used.
Reported-by: Peter Krempa
Reported-by:
Signed-off-by: Amit Shah
Signed-off-by: Rusty Russell
Signed-off-by: Greg Kroah-Hartman
---
drivers/char/hw_random/virtio-rng.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- a/drivers/char/hw_random/virtio-rng.c
+++ b/drivers/char/hw_random/virtio-rng.c
@@ -88,14 +88,22 @@ static int virtrng_probe(struct virtio_d
{
int err;
+ if (vq) {
+ /* We only support one device for now */
+ return -EBUSY;
+ }
/* We expect a single virtqueue. */
vq = virtio_find_single_vq(vdev, random_recv_done, "input");
- if (IS_ERR(vq))
- return PTR_ERR(vq);
+ if (IS_ERR(vq)) {
+ err = PTR_ERR(vq);
+ vq = NULL;
+ return err;
+ }
err = hwrng_register(&virtio_hwrng);
if (err) {
vdev->config->del_vqs(vdev);
+ vq = NULL;
return err;
}
@@ -107,6 +115,7 @@ static void __devexit virtrng_remove(str
vdev->config->reset(vdev);
hwrng_unregister(&virtio_hwrng);
vdev->config->del_vqs(vdev);
+ vq = NULL;
}
static struct virtio_device_id id_table[] = {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 12/40] ext3: Fix format string issues
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Lars-Peter Clausen
commit 8d0c2d10dd72c5292eda7a06231056a4c972e4cc upstream.
ext3_msg() takes the printk prefix as the second parameter and the
format string as the third parameter. Two callers of ext3_msg omit the
prefix and pass the format string as the second parameter and the first
parameter to the format string as the third parameter. In both cases
this string comes from an arbitrary source. Which means the string may
contain format string characters, which will
lead to undefined and potentially harmful behavior.
The issue was introduced in commit 4cf46b67eb("ext3: Unify log messages
in ext3") and is fixed by this patch.
Signed-off-by: Lars-Peter Clausen
Signed-off-by: Jan Kara
Signed-off-by: Greg Kroah-Hartman
---
fs/ext3/super.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -371,7 +371,7 @@ static struct block_device *ext3_blkdev_
return bdev;
fail:
- ext3_msg(sb, "error: failed to open journal device %s: %ld",
+ ext3_msg(sb, KERN_ERR, "error: failed to open journal device %s: %ld",
__bdevname(dev, b), PTR_ERR(bdev));
return NULL;
@@ -892,7 +892,7 @@ static ext3_fsblk_t get_sb_block(void **
/*todo: use simple_strtoll with >32bit ext3 */
sb_block = simple_strtoul(options, &options, 0);
if (*options && *options != ',') {
- ext3_msg(sb, "error: invalid sb specification: %s",
+ ext3_msg(sb, KERN_ERR, "error: invalid sb specification: %s",
(char *) *data);
return 1;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 24/40] perf,x86: fix link failure for non-Intel configs
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: David Rientjes
commit 6c4d3bc99b3341067775efd4d9d13cc8e655fd7c upstream.
Commit 1d9d8639c063 ("perf,x86: fix kernel crash with PEBS/BTS after
suspend/resume") introduces a link failure since
perf_restore_debug_store() is only defined for CONFIG_CPU_SUP_INTEL:
arch/x86/power/built-in.o: In function `restore_processor_state':
(.text+0x45c): undefined reference to `perf_restore_debug_store'
Fix it by defining the dummy function appropriately.
Signed-off-by: David Rientjes
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
include/linux/perf_event.h |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1153,7 +1153,6 @@ extern void perf_swevent_put_recursion_c
extern void perf_event_enable(struct perf_event *event);
extern void perf_event_disable(struct perf_event *event);
extern void perf_event_task_tick(void);
-extern void perf_restore_debug_store(void);
#else
static inline void
perf_event_task_sched_in(struct task_struct *task) { }
@@ -1188,6 +1187,11 @@ static inline void perf_swevent_put_recu
static inline void perf_event_enable(struct perf_event *event) { }
static inline void perf_event_disable(struct perf_event *event)
{ }
static inline void perf_event_task_tick(void) { }
+#endif
+
+#if defined(CONFIG_PERF_EVENTS) && defined(CONFIG_CPU_SUP_INTEL)
+extern void perf_restore_debug_store(void);
+#else
static inline void perf_restore_debug_store(void) { }
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 23/40] perf,x86: fix wrmsr_on_cpu() warning on suspend/resume
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Torvalds
commit 2a6e06b2aed6995af401dcd4feb5e79a0c7ea554 upstream.
Commit 1d9d8639c063 ("perf,x86: fix kernel crash with PEBS/BTS after
suspend/resume") fixed a crash when doing PEBS performance profiling
after resuming, but in using init_debug_store_on_cpu() to restore the
DS_AREA mtrr it also resulted in a new WARN_ON() triggering.
init_debug_store_on_cpu() uses "wrmsr_on_cpu()", which in turn uses CPU
cross-calls to do the MSR update. Which is not really valid at the
early resume stage, and the warning is quite reasonable. Now, it all
happens to _work_, for the simple reason that smp_call_function_single()
ends up just doing the call directly on the CPU when the CPU number
matches, but we really should just do the wrmsr() directly instead.
This duplicates the wrmsr() logic, but hopefully we can just remove the
wrmsr_on_cpu() version eventually.
Reported-and-tested-by: Parag Warudkar
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/cpu/perf_event_intel_ds.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -756,10 +756,12 @@ static void intel_ds_init(void)
void perf_restore_debug_store(void)
{
+ struct debug_store *ds = __this_cpu_read(cpu_hw_events.ds);
+
if (!x86_pmu.bts && !x86_pmu.pebs)
return;
- init_debug_store_on_cpu(smp_processor_id());
+ wrmsrl(MSR_IA32_DS_AREA, (unsigned long)ds);
}
#else /* CONFIG_CPU_SUP_INTEL */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ 29/75] perf,x86: fix kernel crash with PEBS/BTS after suspend/resume
On Mon, Mar 18, 2013 at 10:11:28PM +0100, Stephane Eranian wrote: > On Mon, Mar 18, 2013 at 10:06 PM, Greg Kroah-Hartman > wrote: > > 3.8-stable review patch. If anyone has any objections, please let me know. > > > Greg, you also need to pick David Rientjes patch to fix compilation on > non X86 architectures. What git commit id would that be? I thought I picked up everything that was needed after this one went in, what did I miss? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 22/40] perf,x86: fix kernel crash with PEBS/BTS after suspend/resume
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Stephane Eranian
commit 1d9d8639c063caf6efc2447f5f26aa637f844ff6 upstream.
This patch fixes a kernel crash when using precise sampling (PEBS)
after a suspend/resume. Turns out the CPU notifier code is not invoked
on CPU0 (BP). Therefore, the DS_AREA (used by PEBS) is not restored properly
by the kernel and keeps it power-on/resume value of 0 causing any PEBS
measurement to crash when running on CPU0.
The workaround is to add a hook in the actual resume code to restore
the DS Area MSR value. It is invoked for all CPUS. So for all but CPU0,
the DS_AREA will be restored twice but this is harmless.
Reported-by: Linus Torvalds
Signed-off-by: Stephane Eranian
Signed-off-by: Linus Torvalds
Signed-off-by: Shuah Khan
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/cpu/perf_event_intel_ds.c |8
arch/x86/power/cpu.c |2 ++
include/linux/perf_event.h|2 ++
3 files changed, 12 insertions(+)
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -754,6 +754,14 @@ static void intel_ds_init(void)
}
}
+void perf_restore_debug_store(void)
+{
+ if (!x86_pmu.bts && !x86_pmu.pebs)
+ return;
+
+ init_debug_store_on_cpu(smp_processor_id());
+}
+
#else /* CONFIG_CPU_SUP_INTEL */
static void reserve_ds_buffers(void)
--- a/arch/x86/power/cpu.c
+++ b/arch/x86/power/cpu.c
@@ -10,6 +10,7 @@
#include
#include
+#include
#include
#include
@@ -224,6 +225,7 @@ static void __restore_processor_state(st
do_fpu_end();
mtrr_bp_restore();
+ perf_restore_debug_store();
}
/* Needed by apm.c */
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1153,6 +1153,7 @@ extern void perf_swevent_put_recursion_c
extern void perf_event_enable(struct perf_event *event);
extern void perf_event_disable(struct perf_event *event);
extern void perf_event_task_tick(void);
+extern void perf_restore_debug_store(void);
#else
static inline void
perf_event_task_sched_in(struct task_struct *task) { }
@@ -1187,6 +1188,7 @@ static inline void perf_swevent_put_recu
static inline void perf_event_enable(struct perf_event *event) { }
static inline void perf_event_disable(struct perf_event *event)
{ }
static inline void perf_event_task_tick(void) { }
+static inline void perf_restore_debug_store(void) { }
#endif
#define perf_output_put(handle, x) perf_output_copy((handle), &(x), sizeof(x))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 16/40] Revert duplicated perf commit.
3.0-stable review patch. If anyone has any objections, please let me know. -- This reverts commit 2431496fbdd142ccc83138d94f3f510a36ce9270 as it was applied incorrectly twice. Thanks to Jiri for pointing this out. Signed-off-by: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Andrew Vagin Cc: Steven Rostedt --- tools/perf/util/trace-event-parse.c |2 -- 1 file changed, 2 deletions(-) --- a/tools/perf/util/trace-event-parse.c +++ b/tools/perf/util/trace-event-parse.c @@ -1582,8 +1582,6 @@ process_symbols(struct event *event, str field = malloc_or_die(sizeof(*field)); type = process_arg(event, field, &token); - while (type == EVENT_OP) - type = process_op(event, field, &token); if (test_type_token(type, token, EVENT_DELIM, ",")) goto out_free; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 25/40] s390/mm: fix flush_tlb_kernel_range()
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Heiko Carstens
commit f6a70a07079518280022286a1dceb797d12e1edf upstream.
Our flush_tlb_kernel_range() implementation calls __tlb_flush_mm() with
&init_mm as argument. __tlb_flush_mm() however will only flush tlbs
for the passed in mm if its mm_cpumask is not empty.
For the init_mm however its mm_cpumask has never any bits set. Which in
turn means that our flush_tlb_kernel_range() implementation doesn't
work at all.
This can be easily verified with a vmalloc/vfree loop which allocates
a page, writes to it and then frees the page again. A crash will follow
almost instantly.
To fix this remove the cpumask_empty() check in __tlb_flush_mm() since
there shouldn't be too many mms with a zero mm_cpumask, besides the
init_mm of course.
Signed-off-by: Heiko Carstens
Signed-off-by: Martin Schwidefsky
Signed-off-by: Greg Kroah-Hartman
---
arch/s390/include/asm/tlbflush.h |2 --
1 file changed, 2 deletions(-)
--- a/arch/s390/include/asm/tlbflush.h
+++ b/arch/s390/include/asm/tlbflush.h
@@ -73,8 +73,6 @@ static inline void __tlb_flush_idte(unsi
static inline void __tlb_flush_mm(struct mm_struct * mm)
{
- if (unlikely(cpumask_empty(mm_cpumask(mm
- return;
/*
* If the machine has IDTE we prefer to do a per mm flush
* on all cpus instead of doing a local flush if the mm
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 14/40] TTY: do not reset masters packet mode
3.0-stable review patch. If anyone has any objections, please let me know. -- From: Jiri Slaby commit b81273a132177edd806476b953f6afeb17b786d5 upstream. Now that login from util-linux is forced to drop all references to a TTY which it wants to hangup (to reach reference count 1) we are seeing issues with telnet. When login closes its last reference to the slave PTY, it also resets packet mode on the *master* side. And we have a race here. What telnet does is fork+exec of `login'. Then there are two scenarios: * `login' closes the slave TTY and resets thus master's packet mode, but even now telnet properly sets the mode, or * `telnetd' sets packet mode on the master, `login' closes the slave TTY and resets master's packet mode. The former case is OK. However the latter happens in much more cases, by the order of magnitude to be precise. So when one tries to login to such a messed telnet setup, they see the following: inux login: ogin incorrect Note the missing first letters -- telnet thinks it is still in the packet mode, so when it receives "linux login" from `login', it considers "l" as the type of the packet and strips it. SuS does not mention how the implementation should behave. Both BSDs I checked (Free and Net) do not reset the flag upon the last close. By this I am resurrecting an old bug, see References. We are hitting it regularly now, i.e. with updated util-linux, ergo login. Here, I am changing a behavior introduced back in 2.1 times. It would better have a long time testing before goes upstream. Signed-off-by: Jiri Slaby Cc: Mauro Carvalho Chehab Cc: Bryan Mason References: https://lkml.org/lkml/2009/11/11/223 References: https://bugzilla.redhat.com/show_bug.cgi?id=504703 References: https://bugzilla.novell.com/show_bug.cgi?id=797042 Signed-off-by: Greg Kroah-Hartman --- drivers/tty/pty.c |1 - 1 file changed, 1 deletion(-) --- a/drivers/tty/pty.c +++ b/drivers/tty/pty.c @@ -49,7 +49,6 @@ static void pty_close(struct tty_struct tty->packet = 0; if (!tty->link) return; - tty->link->packet = 0; set_bit(TTY_OTHER_CLOSED, &tty->link->flags); wake_up_interruptible(&tty->link->read_wait); wake_up_interruptible(&tty->link->write_wait); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 11/40] signal: always clear sa_restorer on execve
3.0-stable review patch. If anyone has any objections, please let me know. -- From: Kees Cook commit 2ca39528c01a933f6689cd6505ce65bd6d68a530 upstream. When the new signal handlers are set up, the location of sa_restorer is not cleared, leaking a parent process's address space location to children. This allows for a potential bypass of the parent's ASLR by examining the sa_restorer value returned when calling sigaction(). Based on what should be considered "secret" about addresses, it only matters across the exec not the fork (since the VMAs haven't changed until the exec). But since exec sets SIG_DFL and keeps sa_restorer, this is where it should be fixed. Given the few uses of sa_restorer, a "set" function was not written since this would be the only use. Instead, we use __ARCH_HAS_SA_RESTORER, as already done in other places. Example of the leak before applying this patch: $ cat /proc/$$/maps ... 7fb9f3083000-7fb9f3238000 r-xp fd:01 404469 .../libc-2.15.so ... $ ./leak ... 7f278bc74000-7f278be29000 r-xp fd:01 404469 .../libc-2.15.so ... 1 0 (nil) 0x7fb9f30b94a0 2 400 (nil) 0x7f278bcaa4a0 3 400 (nil) 0x7f278bcaa4a0 4 0 (nil) 0x7fb9f30b94a0 ... [a...@linux-foundation.org: use SA_RESTORER for backportability] Signed-off-by: Kees Cook Reported-by: Emese Revfy Cc: Emese Revfy Cc: PaX Team Cc: Al Viro Cc: Oleg Nesterov Cc: "Eric W. Biederman" Cc: Serge Hallyn Cc: Julien Tinnes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- kernel/signal.c |3 +++ 1 file changed, 3 insertions(+) --- a/kernel/signal.c +++ b/kernel/signal.c @@ -437,6 +437,9 @@ flush_signal_handlers(struct task_struct if (force_default || ka->sa.sa_handler != SIG_IGN) ka->sa.sa_handler = SIG_DFL; ka->sa.sa_flags = 0; +#ifdef SA_RESTORER + ka->sa.sa_restorer = NULL; +#endif sigemptyset(&ka->sa.sa_mask); ka++; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 13/40] tty: serial: fix typo "ARCH_S5P6450"
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Paul Bolle
commit 827aa0d36d486f359808c8fb931cf7a71011a09d upstream.
This could have been either ARCH_S5P64X0 or CPU_S5P6450. Looking at
commit 2555e663b367b8d555e76023f4de3f6338c28d6c ("ARM: S5P64X0: Add UART
serial support for S5P6450") - which added this typo - makes clear this
should be CPU_S5P6450.
Signed-off-by: Paul Bolle
Acked-by: Kukjin Kim
Signed-off-by: Greg Kroah-Hartman
---
drivers/tty/serial/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -458,7 +458,7 @@ config SERIAL_SAMSUNG_UARTS
int
depends on ARM && PLAT_SAMSUNG
default 2 if ARCH_S3C2400
- default 6 if ARCH_S5P6450
+ default 6 if CPU_S5P6450
default 4 if SERIAL_SAMSUNG_UARTS_4
default 3
help
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 10/40] staging: vt6656: Fix oops on resume from suspend.
3.0-stable review patch. If anyone has any objections, please let me know. -- From: Malcolm Priestley commit 6987a6dabfc40222ef767f67b57212fe3a0225fb upstream. Remove usb_put_dev from vt6656_suspend and usb_get_dev from vt6566_resume. These are not normally in suspend/resume functions. Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman --- drivers/staging/vt6656/main_usb.c |4 1 file changed, 4 deletions(-) --- a/drivers/staging/vt6656/main_usb.c +++ b/drivers/staging/vt6656/main_usb.c @@ -725,8 +725,6 @@ static int vt6656_suspend(struct usb_int if (device->flags & DEVICE_FLAGS_OPENED) device_close(device->dev); - usb_put_dev(interface_to_usbdev(intf)); - return 0; } @@ -737,8 +735,6 @@ static int vt6656_resume(struct usb_inte if (!device || !device->dev) return -ENODEV; - usb_get_dev(interface_to_usbdev(intf)); - if (!(device->flags & DEVICE_FLAGS_OPENED)) device_open(device->dev); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 05/40] usb: cp210x new Vendor/Device IDs
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: "Matwey V. Kornilov"
commit be3101c23394af59694c8a2aae6d07f5da62fea5 upstream.
This patch adds support for the Lake Shore Cryotronics devices to
the CP210x driver.
These lines are ported from cp210x driver distributed by Lake Shore web site:
http://www.lakeshore.com/Documents/Lake%20Shore%20cp210x-3.0.0.tar.gz
and licensed under the terms of GPLv2.
Moreover, I've tested this changes with Lake Shore 335 in my labs.
Signed-off-by: Matwey V. Kornilov
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/serial/cp210x.c | 19 +++
1 file changed, 19 insertions(+)
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -156,6 +156,25 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(0x1BE3, 0x07A6) }, /* WAGO 750-923 USB Service Cable */
{ USB_DEVICE(0x1E29, 0x0102) }, /* Festo CPX-USB */
{ USB_DEVICE(0x1E29, 0x0501) }, /* Festo CMSP */
+ { USB_DEVICE(0x1FB9, 0x0100) }, /* Lake Shore Model 121 Current Source
*/
+ { USB_DEVICE(0x1FB9, 0x0200) }, /* Lake Shore Model 218A Temperature
Monitor */
+ { USB_DEVICE(0x1FB9, 0x0201) }, /* Lake Shore Model 219 Temperature
Monitor */
+ { USB_DEVICE(0x1FB9, 0x0202) }, /* Lake Shore Model 233 Temperature
Transmitter */
+ { USB_DEVICE(0x1FB9, 0x0203) }, /* Lake Shore Model 235 Temperature
Transmitter */
+ { USB_DEVICE(0x1FB9, 0x0300) }, /* Lake Shore Model 335 Temperature
Controller */
+ { USB_DEVICE(0x1FB9, 0x0301) }, /* Lake Shore Model 336 Temperature
Controller */
+ { USB_DEVICE(0x1FB9, 0x0302) }, /* Lake Shore Model 350 Temperature
Controller */
+ { USB_DEVICE(0x1FB9, 0x0303) }, /* Lake Shore Model 371 AC Bridge */
+ { USB_DEVICE(0x1FB9, 0x0400) }, /* Lake Shore Model 411 Handheld
Gaussmeter */
+ { USB_DEVICE(0x1FB9, 0x0401) }, /* Lake Shore Model 425 Gaussmeter */
+ { USB_DEVICE(0x1FB9, 0x0402) }, /* Lake Shore Model 455A Gaussmeter */
+ { USB_DEVICE(0x1FB9, 0x0403) }, /* Lake Shore Model 475A Gaussmeter */
+ { USB_DEVICE(0x1FB9, 0x0404) }, /* Lake Shore Model 465 Three Axis
Gaussmeter */
+ { USB_DEVICE(0x1FB9, 0x0600) }, /* Lake Shore Model 625A
Superconducting MPS */
+ { USB_DEVICE(0x1FB9, 0x0601) }, /* Lake Shore Model 642A Magnet Power
Supply */
+ { USB_DEVICE(0x1FB9, 0x0602) }, /* Lake Shore Model 648 Magnet Power
Supply */
+ { USB_DEVICE(0x1FB9, 0x0700) }, /* Lake Shore Model 737 VSM Controller
*/
+ { USB_DEVICE(0x1FB9, 0x0701) }, /* Lake Shore Model 776 Hall Matrix */
{ USB_DEVICE(0x3195, 0xF190) }, /* Link Instruments MSO-19 */
{ USB_DEVICE(0x3195, 0xF280) }, /* Link Instruments MSO-28 */
{ USB_DEVICE(0x3195, 0xF281) }, /* Link Instruments MSO-28 */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 01/40] qcaux: add Franklin U600
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Dan Williams
commit 2d90e63603ac235aecd7d20e234616e0682c8b1f upstream.
4 ports; AT/PPP is standard CDC-ACM. The other three (added by this
patch) are QCDM/DIAG, possibly GPS, and unknown.
Signed-off-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/serial/qcaux.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/serial/qcaux.c
+++ b/drivers/usb/serial/qcaux.c
@@ -69,6 +69,7 @@ static struct usb_device_id id_table[] =
{ USB_VENDOR_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID, 0xff, 0xfd, 0xff)
}, /* NMEA */
{ USB_VENDOR_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID, 0xff, 0xfe, 0xff)
}, /* WMC */
{ USB_VENDOR_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID, 0xff, 0xff, 0xff)
}, /* DIAG */
+ { USB_DEVICE_AND_INTERFACE_INFO(0x1fac, 0x0151, 0xff, 0xff, 0xff) },
{ },
};
MODULE_DEVICE_TABLE(usb, id_table);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 09/40] USB: EHCI: dont check DMA values in QH overlays
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Alan Stern
commit feca7746d5d9e84b105a613b7f3b6ad00d327372 upstream.
This patch (as1661) fixes a rather obscure bug in ehci-hcd. In a
couple of places, the driver compares the DMA address stored in a QH's
overlay region with the address of a particular qTD, in order to see
whether that qTD is the one currently being processed by the hardware.
(If it is then the status in the QH's overlay region is more
up-to-date than the status in the qTD, and if it isn't then the
overlay's value needs to be adjusted when the QH is added back to the
active schedule.)
However, DMA address in the overlay region isn't always valid. It
sometimes will contain a stale value, which may happen by coincidence
to be equal to a qTD's DMA address. Instead of checking the DMA
address, we should check whether the overlay region is active and
valid. The patch tests the ACTIVE bit in the overlay, and clears this
bit when the overlay becomes invalid (which happens when the
currently-executing URB is unlinked).
This is the second part of a fix for the regression reported at:
https://bugs.launchpad.net/bugs/1088733
Signed-off-by: Alan Stern
Reported-by: Joseph Salisbury
Reported-and-tested-by: Stephen Thirlwall
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/host/ehci-q.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -137,7 +137,7 @@ qh_refresh (struct ehci_hcd *ehci, struc
* qtd is updated in qh_completions(). Update the QH
* overlay here.
*/
- if (cpu_to_hc32(ehci, qtd->qtd_dma) == qh->hw->hw_current) {
+ if (qh->hw->hw_token & ACTIVE_BIT(ehci)) {
qh->hw->hw_qtd_next = qtd->hw_next;
qtd = NULL;
}
@@ -450,11 +450,19 @@ qh_completions (struct ehci_hcd *ehci, s
else if (last_status == -EINPROGRESS && !urb->unlinked)
continue;
- /* qh unlinked; token in overlay may be most current */
- if (state == QH_STATE_IDLE
- && cpu_to_hc32(ehci, qtd->qtd_dma)
- == hw->hw_current) {
+ /*
+* If this was the active qtd when the qh was unlinked
+* and the overlay's token is active, then the overlay
+* hasn't been written back to the qtd yet so use its
+* token instead of the qtd's. After the qtd is
+* processed and removed, the overlay won't be valid
+* any more.
+*/
+ if (state == QH_STATE_IDLE &&
+ qh->qtd_list.next == &qtd->qtd_list &&
+ (hw->hw_token & ACTIVE_BIT(ehci))) {
token = hc32_to_cpu(ehci, hw->hw_token);
+ hw->hw_token &= ~ACTIVE_BIT(ehci);
/* An unlink may leave an incomplete
* async transaction in the TT buffer.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 08/40] USB: storage: fix Huawei mode switching regression
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Bjørn Mork
commit ab4b71644a26d1ab92b987b2fd30e17c25e89f85 upstream.
This reverts commit 200e0d99 ("USB: storage: optimize to match the
Huawei USB storage devices and support new switch command" and the
followup bugfix commit cd060956 ("USB: storage: properly handle
the endian issues of idProduct").
The commit effectively added a large number of Huawei devices to
the deprecated usb-storage mode switching logic. Many of these
devices have been in use and supported by the userspace
usb_modeswitch utility for years. Forcing the switching inside
the kernel causes a number of regressions as a result of ignoring
existing onfigurations, and also completely takes away the ability
to configure mode switching per device/system/user.
Known regressions caused by this:
- Some of the devices support multiple modes, using different
switching commands. There are existing configurations taking
advantage of this.
- There is a real use case for disabling mode switching and
instead mounting the exposed storage device. This becomes
impossible with switching logic inside the usb-storage driver.
- At least on device fail as a result of the usb-storage switching
command, becoming completely unswitchable. This is possibly a
firmware bug, but still a regression because the device work as
expected using usb_modeswitch defaults.
In-kernel mode switching was deprecated years ago with the
development of the more user friendly userspace alternatives. The
existing list of devices in usb-storage was only kept to prevent
breaking already working systems. The long term plan is to remove
the list, not to add to it. Ref:
http://permalink.gmane.org/gmane.linux.usb.general/28543
Signed-off-by: Bjørn Mork
Cc:
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/storage/initializers.c | 76
drivers/usb/storage/initializers.h |4
drivers/usb/storage/unusual_devs.h | 329 -
3 files changed, 331 insertions(+), 78 deletions(-)
--- a/drivers/usb/storage/initializers.c
+++ b/drivers/usb/storage/initializers.c
@@ -92,8 +92,8 @@ int usb_stor_ucr61s2b_init(struct us_dat
return 0;
}
-/* This places the HUAWEI usb dongles in multi-port mode */
-static int usb_stor_huawei_feature_init(struct us_data *us)
+/* This places the HUAWEI E220 devices in multi-port mode */
+int usb_stor_huawei_e220_init(struct us_data *us)
{
int result;
@@ -104,75 +104,3 @@ static int usb_stor_huawei_feature_init(
US_DEBUGP("Huawei mode set result is %d\n", result);
return 0;
}
-
-/*
- * It will send a scsi switch command called rewind' to huawei dongle.
- * When the dongle receives this command at the first time,
- * it will reboot immediately. After rebooted, it will ignore this command.
- * So it is unnecessary to read its response.
- */
-static int usb_stor_huawei_scsi_init(struct us_data *us)
-{
- int result = 0;
- int act_len = 0;
- struct bulk_cb_wrap *bcbw = (struct bulk_cb_wrap *) us->iobuf;
- char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
- 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
-
- bcbw->Signature = cpu_to_le32(US_BULK_CB_SIGN);
- bcbw->Tag = 0;
- bcbw->DataTransferLength = 0;
- bcbw->Flags = bcbw->Lun = 0;
- bcbw->Length = sizeof(rewind_cmd);
- memset(bcbw->CDB, 0, sizeof(bcbw->CDB));
- memcpy(bcbw->CDB, rewind_cmd, sizeof(rewind_cmd));
-
- result = usb_stor_bulk_transfer_buf(us, us->send_bulk_pipe, bcbw,
- US_BULK_CB_WRAP_LEN, &act_len);
- US_DEBUGP("transfer actual length=%d, result=%d\n", act_len, result);
- return result;
-}
-
-/*
- * It tries to find the supported Huawei USB dongles.
- * In Huawei, they assign the following product IDs
- * for all of their mobile broadband dongles,
- * including the new dongles in the future.
- * So if the product ID is not included in this list,
- * it means it is not Huawei's mobile broadband dongles.
- */
-static int usb_stor_huawei_dongles_pid(struct us_data *us)
-{
- struct usb_interface_descriptor *idesc;
- int idProduct;
-
- idesc = &us->pusb_intf->cur_altsetting->desc;
- idProduct = le16_to_cpu(us->pusb_dev->descriptor.idProduct);
- /* The first port is CDROM,
-* means the dongle in the single port mode,
-* and a switch command is required to be sent. */
- if (idesc && idesc->bInterfaceNumber == 0) {
- if ((idProduct == 0x1001)
- || (idProduct == 0x1003)
- || (idProduct == 0x1004)
- || (idProduct >= 0x1401 && idProduct <= 0x1500)
-
[ 23/48] powerpc: Fix cputable entry for 970MP rev 1.0
3.4-stable review patch. If anyone has any objections, please let me know. -- From: Benjamin Herrenschmidt commit d63ac5f6cf31c8a83170a9509b350c1489a7262b upstream. Commit 44ae3ab3358e962039c36ad4ae461ae9fb29596c forgot to update the entry for the 970MP rev 1.0 processor when moving some CPU features bits to the MMU feature bit mask. This breaks booting on some rare G5 models using that chip revision. Reported-by: Phileas Fogg Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman --- arch/powerpc/kernel/cputable.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/kernel/cputable.c +++ b/arch/powerpc/kernel/cputable.c @@ -269,7 +269,7 @@ static struct cpu_spec __initdata cpu_sp .cpu_features = CPU_FTRS_PPC970, .cpu_user_features = COMMON_USER_POWER4 | PPC_FEATURE_HAS_ALTIVEC_COMP, - .mmu_features = MMU_FTR_HPTE_TABLE, + .mmu_features = MMU_FTRS_PPC970, .icache_bsize = 128, .dcache_bsize = 128, .num_pmcs = 8, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 21/48] w1: fix oops when w1_search is called from netlink connector
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Marcin Jurkowski
commit 9d1817cab2f030f6af360e961cc69bb1da8ad765 upstream.
On Sat, Mar 02, 2013 at 10:45:10AM +0100, Sven Geggus wrote:
> This is the bad commit I found doing git bisect:
> 04f482faf50535229a5a5c8d629cf963899f857c is the first bad commit
> commit 04f482faf50535229a5a5c8d629cf963899f857c
> Author: Patrick McHardy
> Date: Mon Mar 28 08:39:36 2011 +
Good job. I was too lazy to bisect for bad commit;)
Reading the code I found problematic kthread_should_stop call from netlink
connector which causes the oops. After applying a patch, I've been testing
owfs+w1 setup for nearly two days and it seems to work very reliable (no
hangs, no memleaks etc).
More detailed description and possible fix is given below:
Function w1_search can be called from either kthread or netlink callback.
While the former works fine, the latter causes oops due to kthread_should_stop
invocation.
This patch adds a check if w1_search is serving netlink command, skipping
kthread_should_stop invocation if so.
Signed-off-by: Marcin Jurkowski
Acked-by: Evgeniy Polyakov
Cc: Josh Boyer
Tested-by: Sven Geggus
Signed-off-by: Greg Kroah-Hartman
---
drivers/w1/w1.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -928,7 +928,8 @@ void w1_search(struct w1_master *dev, u8
tmp64 = (triplet_ret >> 2);
rn |= (tmp64 << i);
- if (kthread_should_stop()) {
+ /* ensure we're called from kthread and not by netlink
callback */
+ if (!dev->priv && kthread_should_stop()) {
dev_dbg(&dev->dev, "Abort w1_search\n");
return;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 34/48] loopdev: fix a deadlock
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Guo Chao
commit 5370019dc2d2c2ff90e95d181468071362934f3a upstream.
bd_mutex and lo_ctl_mutex can be held in different order.
Path #1:
blkdev_open
blkdev_get
__blkdev_get (hold bd_mutex)
lo_open (hold lo_ctl_mutex)
Path #2:
blkdev_ioctl
lo_ioctl (hold lo_ctl_mutex)
lo_set_capacity (hold bd_mutex)
Lockdep does not report it, because path #2 actually holds a subclass of
lo_ctl_mutex. This subclass seems creep into the code by mistake. The
patch author actually just mentioned it in the changelog, see commit
f028f3b2 ("loop: fix circular locking in loop_clr_fd()"), also see:
http://marc.info/?l=linux-kernel&m=123806169129727&w=2
Path #2 hold bd_mutex to call bd_set_size(), I've protected it
with i_mutex in a previous patch, so drop bd_mutex at this site.
Signed-off-by: Guo Chao
Cc: Alexander Viro
Cc: Guo Chao
Cc: M. Hindess
Cc: Nikanth Karthikesan
Cc: Jens Axboe
Signed-off-by: Andrew Morton
Signed-off-by: Jens Axboe
Acked-by: Jeff Mahoney
Signed-off-by: Greg Kroah-Hartman
---
drivers/block/loop.c |2 --
1 file changed, 2 deletions(-)
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1263,11 +1263,9 @@ static int loop_set_capacity(struct loop
/* the width of sector_t may be narrow for bit-shift */
sz = sec;
sz <<= 9;
- mutex_lock(&bdev->bd_mutex);
bd_set_size(bdev, sz);
/* let user-space know about the new size */
kobject_uevent(&disk_to_dev(bdev->bd_disk)->kobj, KOBJ_CHANGE);
- mutex_unlock(&bdev->bd_mutex);
out:
return err;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 33/48] block: use i_size_write() in bd_set_size()
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Guo Chao
commit d646a02a9d44d1421f273ae3923d97b47b918176 upstream.
blkdev_ioctl(GETBLKSIZE) uses i_size_read() to read size of block device.
If we update block size directly, reader may see intermediate result in
some machines and configurations. Use i_size_write() instead.
Signed-off-by: Guo Chao
Cc: Alexander Viro
Cc: Guo Chao
Cc: M. Hindess
Cc: Nikanth Karthikesan
Cc: Jens Axboe
Signed-off-by: Andrew Morton
Signed-off-by: Jens Axboe
Acked-by: Jeff Mahoney
Signed-off-by: Greg Kroah-Hartman
---
fs/block_dev.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1086,7 +1086,9 @@ void bd_set_size(struct block_device *bd
{
unsigned bsize = bdev_logical_block_size(bdev);
- bdev->bd_inode->i_size = size;
+ mutex_lock(&bdev->bd_inode->i_mutex);
+ i_size_write(bdev->bd_inode, size);
+ mutex_unlock(&bdev->bd_inode->i_mutex);
while (bsize < PAGE_CACHE_SIZE) {
if (size & bsize)
break;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 42/48] macvlan: Set IFF_UNICAST_FLT flag to prevent unnecessary promisc mode.
3.4-stable review patch. If anyone has any objections, please let me know. -- From: Vlad Yasevich [ Upstream commit 87ab7f6f2874f1115817e394a7ed2dea1c72549e ] Macvlan already supports hw address filters. Set the IFF_UNICAST_FLT so that it doesn't needlesly enter PROMISC mode when macvlans are stacked. Signed-of-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- drivers/net/macvlan.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/net/macvlan.c +++ b/drivers/net/macvlan.c @@ -584,6 +584,7 @@ void macvlan_common_setup(struct net_dev ether_setup(dev); dev->priv_flags&= ~(IFF_XMIT_DST_RELEASE | IFF_TX_SKB_SHARING); + dev->priv_flags|= IFF_UNICAST_FLT; dev->netdev_ops = &macvlan_netdev_ops; dev->destructor = free_netdev; dev->header_ops = &macvlan_hard_header_ops, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 00/40] 3.0.70-stable review
This is the start of the stable review cycle for the 3.0.70 release. There are 40 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 Wed Mar 20 21:10:06 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.0.70-rc1.gz and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 3.0.70-rc1 Mathias Krause dcbnl: fix various netlink info leaks Mathias Krause rtnl: fix info leak on RTM_GETLINK request for VF devices Hannes Frederic Sowa ipv6: stop multicast forwarding to process interface scoped addresses Cristian Bercaru bridging: fix rx_handlers return code Paul Moore netlabel: correctly list all the static label mappings Eric Dumazet tun: add a missing nf_reset() in tun_net_xmit() Neal Cardwell tcp: fix double-counted receiver RTT when leaving receiver fast path Lorenzo Colitti net: ipv6: Don't purge default router if accept_ra=2 Cong Wang rds: limit the size allocated by rds_message_alloc() Guillaume Nault l2tp: Restore socket refcount when sendmsg succeeds Guo Chao loopdev: fix a deadlock Guo Chao block: use i_size_write() in bd_set_size() Ben Hutchings hwmon: (sht15) Fix memory leak if regulator_enable() fails Dmitry Rogozhkin drm/i915: EBUSY status handling added to i915_gem_fault(). Eric Sandeen btrfs: use rcu_barrier() to wait for bdev puts at unmount Heiko Carstens s390/mm: fix flush_tlb_kernel_range() David Rientjes perf,x86: fix link failure for non-Intel configs Linus Torvalds perf,x86: fix wrmsr_on_cpu() warning on suspend/resume Stephane Eranian perf,x86: fix kernel crash with PEBS/BTS after suspend/resume Dan Carpenter selinux: use GFP_ATOMIC under spin_lock Benjamin Herrenschmidt powerpc: Fix cputable entry for 970MP rev 1.0 Marcin Jurkowski w1: fix oops when w1_search is called from netlink connector Axel Lin hwmon: (lineage-pem) Add missing terminating entry for pem_[input|fan]_attributes Takashi Iwai ALSA: seq: Fix missing error handling in snd_seq_timer_open() Greg Kroah-Hartman Revert duplicated perf commit. Sebastian Riemer md: protect against crash upon fsync on ro array Jiri Slaby TTY: do not reset master's packet mode Paul Bolle tty: serial: fix typo "ARCH_S5P6450" Lars-Peter Clausen ext3: Fix format string issues Kees Cook signal: always clear sa_restorer on execve Malcolm Priestley staging: vt6656: Fix oops on resume from suspend. Alan Stern USB: EHCI: don't check DMA values in QH overlays Bjørn Mork USB: storage: fix Huawei mode switching regression Steve Conklin usb: serial: Add Rigblaster Advantage to device table Christian Schmiedl USB: added support for Cinterion's products AH6 and PLS8 Matwey V. Kornilov usb: cp210x new Vendor/Device IDs Oliver Neukum USB: cdc-wdm: fix buffer overflow Bjørn Mork USB: option: add Huawei E5331 Amit Shah virtio: rng: disallow multiple device registrations, fixes crashes Dan Williams qcaux: add Franklin U600 - Diffstat: Makefile | 4 +- arch/powerpc/kernel/cputable.c| 2 +- arch/s390/include/asm/tlbflush.h | 2 - arch/x86/kernel/cpu/perf_event_intel_ds.c | 10 + arch/x86/power/cpu.c | 2 + drivers/block/loop.c | 2 - drivers/char/hw_random/virtio-rng.c | 13 +- drivers/gpu/drm/i915/i915_gem.c | 5 + drivers/hwmon/lineage-pem.c | 2 + drivers/hwmon/sht15.c | 2 +- drivers/md/md.c | 4 + drivers/net/tun.c | 2 + drivers/staging/vt6656/main_usb.c | 4 - drivers/tty/pty.c | 1 - drivers/tty/serial/Kconfig| 2 +- drivers/usb/class/cdc-wdm.c | 23 ++- drivers/usb/host/ehci-q.c | 18 +- drivers/usb/serial/cp210x.c | 20 ++ drivers/usb/serial/option.c | 5 + drivers/usb/serial/qcaux.c| 1 + drivers/usb/storage/initializers.c| 76 +-- drivers/usb/storage/initializers.h| 4 +- drivers/usb/storage/unusual_devs.h| 329 +- drivers/w1/w1.c | 3 +- fs/block_dev.c| 4 +- fs/btrfs/volumes.c| 6 + fs/ext3/super.c | 4 +- include/linux/perf_event.h| 6 + kernel/signal.c | 3 + net/core/dev.c
[ 07/40] usb: serial: Add Rigblaster Advantage to device table
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Steve Conklin
commit a57e82a18779ab8a5e5a1f5841cef937cf578913 upstream.
The Rigblaster Advantage is an amateur radio interface sold by West Mountain
Radio. It contains a cp210x serial interface but the device ID is not in
the driver.
Signed-off-by: Steve Conklin
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/serial/cp210x.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -91,6 +91,7 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(0x10C4, 0x813F) }, /* Tams Master Easy Control */
{ USB_DEVICE(0x10C4, 0x814A) }, /* West Mountain Radio RIGblaster P&P */
{ USB_DEVICE(0x10C4, 0x814B) }, /* West Mountain Radio RIGtalk */
+ { USB_DEVICE(0x2405, 0x0003) }, /* West Mountain Radio RIGblaster
Advantage */
{ USB_DEVICE(0x10C4, 0x8156) }, /* B&G H3000 link cable */
{ USB_DEVICE(0x10C4, 0x815E) }, /* Helicomm IP-Link 1220-DVM */
{ USB_DEVICE(0x10C4, 0x815F) }, /* Timewave HamLinkUSB */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
