Bug#1054514: [PATCH v2 1/1] Revert "drm/qxl: simplify qxl_fence_wait"

[Greg KH]

On Thu, Apr 04, 2024 at 07:14:48PM +0100, Alex Constantino wrote:
> This reverts commit 5a838e5d5825c85556011478abde708251cc0776.
> 
> Changes from commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") would
> result in a '[TTM] Buffer eviction failed' exception whenever it reached a
> timeout.
> Due to a dependency to DMA_FENCE_WARN this also restores some code deleted
> by commit d72277b6c37d ("dma-buf: nuke DMA_FENCE_TRACE macros v2").
> 
> Fixes: 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait")
> Link: https://lore.kernel.org/regressions/ztgydqrlk6wx_...@eldamar.lan/
> Reported-by: Timo Lindfors 
> Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054514
> Signed-off-by: Alex Constantino 
> ---
>  drivers/gpu/drm/qxl/qxl_release.c | 50 +++
>  include/linux/dma-fence.h |  7 +
>  2 files changed, 52 insertions(+), 5 deletions(-)

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- You have marked a patch with a "Fixes:" tag for a commit that is in an
  older released kernel, yet you do not have a cc: stable line in the
  signed-off-by area at all, which means that the patch will not be
  applied to any older kernel releases.  To properly fix this, please
  follow the documented rules in the
  Documentation/process/stable-kernel-rules.rst file for how to resolve
  this.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

Re: request commit for 6.1 too // scsi: megaraid_sas: Add flexible array member for SGLs

[Greg KH]

On Sat, Jun 10, 2023 at 08:00:16AM -0700, Kees Cook wrote:
> On June 9, 2023 3:42:12 PM PDT, Frank Reppin  wrote:
> >Dear all,
> >
> >I've already followed the reply instructions on LKML - but it somewhat
> >messed up my message there (so probably nobody knows what I'm talking about) 
> >- however ...
> >
> >Earlier this year you've committed
> >
> >scsi: megaraid_sas: Add flexible array member for SGLs
> >https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?id=a9a3629592ab
> >
> >... but it only made it into 6.3 at this time.
> >
> >I hereby kindly request to see this commit in LTS 6.1 too.
> 
> Sure! These requests are handled through the stable mailing list (now added 
> to To:).
> 
> Greg, please backport a9a3629592ab to 6.1 (and 6.2).

6.2.y is long end-of-life (as shown on the front page of kernel.org), so
now queued up for 6.1.y only.

thanks,

greg k-h

Re: [PATCH v2 1/1] s390/signal: fix endless loop in do_signal

[Greg KH]

On Wed, Feb 15, 2023 at 03:13:24PM +0100, Sumanth Korikkar wrote:
> No upstream commit exists: the problem addressed here is that 
> 'commit 75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL")' 
> was backported to 5.10. This commit is broken, but nobody noticed
> upstream, since shortly after s390 converted to generic entry with
> 'commit 75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL")', which
> implicitly fixed the problem outlined below.
> 
> Thread flag is set to TIF_NOTIFY_SIGNAL for io_uring work.  The io work
> user or syscall calls do_signal when either one of the TIF_SIGPENDING or
> TIF_NOTIFY_SIGNAL flag is set.  However, do_signal does consider only
> TIF_SIGPENDING signal and ignores TIF_NOTIFY_SIGNAL condition.  This
> means get_signal is never invoked  for TIF_NOTIFY_SIGNAL and hence the
> flag is not cleared, which results in an endless do_signal loop.
> 
> Reference: 'commit 788d0824269b ("io_uring: import 5.15-stable io_uring")'
> Fixes: 75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL")
> Cc: sta...@vger.kernel.org  # 5.10.162
> Acked-by: Heiko Carstens 
> Acked-by: Sven Schnelle 
> Signed-off-by: Sumanth Korikkar 
> ---
>  arch/s390/kernel/signal.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Now queued up, thanks.

greg k-h

Re: [PATCH 0/1] s390: fix endless loop in do_signal

[Greg KH]

On Wed, Feb 15, 2023 at 02:35:24PM +0100, Heiko Carstens wrote:
> On Wed, Feb 15, 2023 at 02:23:20PM +0100, Greg KH wrote:
> > On Wed, Feb 15, 2023 at 01:04:12PM +0100, Sumanth Korikkar wrote:
> > > Hi,
> > > 
> > > This patch fixes the issue for s390  stable kernel starting  5.10.162.
> > > The issue was specifically seen after stable version 5.10.162:
> > > Following commits can trigger it:
> > > 1. stable commit id - 788d0824269b ("io_uring: import 5.15-stable
> > > io_uring") can trigger this problem.
> > > 2. upstream commit id - 75309018a24d ("s390: add support for
> > > TIF_NOTIFY_SIGNAL")
> > > 
> > > Problem:
> > > qemu and user processes could stall when TIF_NOTIFY_SIGNAL is set from
> > > io_uring work.
> > > 
> > > Affected users:
> > > The issue was first raised by the debian team, where the s390
> > > bullseye build systems are affected.
> > > 
> > > Upstream commit Id:
> > > * The attached patch has no upstream commit. However, the stable kernel
> > > 5.10.162+ uses upstream commit id - 75309018a24d ("s390: add support for
> > > TIF_NOTIFY_SIGNAL"), which would need this fix
> > > * Starting from v5.12, there are s390 generic entry commits 
> > > 56e62a737028 ("s390: convert to generic entry")  and its relevant fixes,
> > > which are recommended and should address these problems.
> > 
> > I'm sorry, but I do not understand.  What exact commits should be added
> > to the 5.10.y tree to resolve this?
> 
> Only the patch sent by Sumanth as reply to this cover letter should be
> added to the 5.10.y tree.
> 
> The problem that is addressed here is that commit 75309018a24d ("s390: add
> support for TIF_NOTIFY_SIGNAL") was backported to 5.10. This commit is
> broken, but nobody noticed upstream, since shortly after s390 converted to
> generic entry with commit 56e62a737028 ("s390: convert to generic entry"),
> which implicitly fixed that.

Ok, then please say that in the changelog text.

thanks,

greg k-h

Re: [PATCH 0/1] s390: fix endless loop in do_signal

[Greg KH]

On Wed, Feb 15, 2023 at 01:04:12PM +0100, Sumanth Korikkar wrote:
> Hi,
> 
> This patch fixes the issue for s390  stable kernel starting  5.10.162.
> The issue was specifically seen after stable version 5.10.162:
> Following commits can trigger it:
> 1. stable commit id - 788d0824269b ("io_uring: import 5.15-stable
> io_uring") can trigger this problem.
> 2. upstream commit id - 75309018a24d ("s390: add support for
> TIF_NOTIFY_SIGNAL")
> 
> Problem:
> qemu and user processes could stall when TIF_NOTIFY_SIGNAL is set from
> io_uring work.
> 
> Affected users:
> The issue was first raised by the debian team, where the s390
> bullseye build systems are affected.
> 
> Upstream commit Id:
> * The attached patch has no upstream commit. However, the stable kernel
> 5.10.162+ uses upstream commit id - 75309018a24d ("s390: add support for
> TIF_NOTIFY_SIGNAL"), which would need this fix
> * Starting from v5.12, there are s390 generic entry commits 
> 56e62a737028 ("s390: convert to generic entry")  and its relevant fixes,
> which are recommended and should address these problems.

I'm sorry, but I do not understand.  What exact commits should be added
to the 5.10.y tree to resolve this?

thanks,

greg k-h

Re: [PATCH 1/1] s390/signal: fix endless loop in do_signal

[Greg KH]

On Wed, Feb 15, 2023 at 01:04:13PM +0100, Sumanth Korikkar wrote:
> No upstream commit exists.

Why not?  Please explain how this was fixed in Linus's tree and why we
can't take the same change here as well.

thanks,

greg k-h

Bug#892105: Cherry-pick "i40e: Be much more verbose about what we can and cannot offload"

[Greg KH]

On Tue, Jun 29, 2021 at 06:20:30PM +, Fujinaka, Todd wrote:
> I think I accidentally deleted the forward from the intel-wired-lan spam 
> filter. Re-forwarding and adding Alex's gmail address.
> 
> Also, 
> 
> Todd Fujinaka
> Software Application Engineer
> Data Center Group
> Intel Corporation
> todd.fujin...@intel.com
> 
> -Original Message-
> From: Philipp Hahn  
> Sent: Tuesday, June 22, 2021 11:19 AM
> To: sta...@vger.kernel.org; 892...@bugs.debian.org; Ben Hutchings 
> 
> Cc: Alexander Duyck ; Andrew Bowers 
> ; Bonaccorso, Salvatore 
> Subject: Cherry-pick "i40e: Be much more verbose about what we can and cannot 
> offload"
> 
> Hello,
> 
> I request the following patch from v4.10-rc1 to get cherry-picked into
> "stable/linux-4.9.y":
> 
> > commit f114dca2533ca770aebebffb5ed56e5e7d1fb3fb

Please provide a working backport, that you have tested works properly,
as it does not apply cleanly.

thanks,

greg k-h

Bug#892105: Cherry-pick "i40e: Be much more verbose about what we can and cannot offload"

[Greg KH]

On Tue, Jun 22, 2021 at 08:18:53PM +0200, Philipp Hahn wrote:
> Hello,
> 
> I request the following patch from v4.10-rc1 to get cherry-picked into
> "stable/linux-4.9.y":
> 
> > commit f114dca2533ca770aebebffb5ed56e5e7d1fb3fb
> > Author: Alexander Duyck 
> > Date:   Tue Oct 25 16:08:46 2016 -0700
> > 
> > i40e: Be much more verbose about what we can and cannot offload
> > This change makes it so that we are much more robust about defining 
> > what we
> > can and cannot offload.  Previously we were just checking for the L4 
> > tunnel
> > header length, however there are other fields we should be verifying as
> > there are multiple scenarios in which we cannot perform hardware 
> > offloads.
> > In addition the device only supports GSO as long as the MSS is 64 or
> > greater.  We were not checking this so an MSS less than that was 
> > resulting
> > in Tx hangs.
> > Change-ID: I5e2fd5f3075c73601b4b36327b771c64fcb6c31b
> > Signed-off-by: Alexander Duyck 
> > Tested-by: Andrew Bowers 
> 
> Debian had this old Bug
>  reported against
> 4.9.82, which still exists in Debians old-stable 9 "Stretch" current kernel
> 4.9.258, but also with latest stable 4.9.273.

Now queued up, thanks.

greg k-h

Bug#965074: Patches to make multicast proccesing on CDC NCM drivers

[Greg KH]

On Wed, Sep 02, 2020 at 03:27:28PM +0200, Santiago Ruano Rincón wrote:
> El 02/09/20 a las 14:05, Greg KH escribió:
> > On Wed, Sep 02, 2020 at 01:47:18PM +0200, Santiago Ruano Rincón wrote:
> > > El 30/07/20 a las 16:07, Oliver Neukum escribió:
> > > > Am Donnerstag, den 30.07.2020, 15:53 +0200 schrieb Santiago Ruano
> > > > Rincón:
> > > > > Hi,
> > > > > 
> > > > > Miguel Rodríguez sent this set of patches two years ago to fix the 
> > > > > lack
> > > > > of multicast processing on CDC NCM driver:
> > > > > 
> > > > > https://www.spinics.net/lists/linux-usb/msg170611.html
> > > > > https://www.spinics.net/lists/linux-usb/msg170603.html
> > > > > https://www.spinics.net/lists/linux-usb/msg170567.html
> > > > > https://www.spinics.net/lists/linux-usb/msg170568.html
> > > > > 
> > > > > I've using a DKMS version of them, available in
> > > > > https://github.com/stbuehler/fixed-cdc-ether-ncm/tree/wip/patches
> > > > > since more than a year ago, and they are working fine with my Dell 
> > > > > D6000
> > > > > docking station. IPv6 connectivity is broken without them.
> > > > > 
> > > > > Is there any chance to consider those patches (or what would be needed
> > > > > to make it happen)?
> > > > > It would be great to have them upstream!
> > > > 
> > > > Hi,
> > > > 
> > > > they have been merged on Wednesday.
> > > …
> > > 
> > > Great, thanks!
> > > 
> > > It would be possible to apply/backport Miguel's patches (along with
> > > 5fd99b5d9950d6300467ded18ff4e44af0b4ae55) to stable versions please?
> > 
> > I don't see that git commit id in Linus's tree, are you sure it is
> > correct?
> 
> I should had mention it is found in linux-next, sorry. Please see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969365#10

Ah, nothing I can do with patches that are not yet in Linus's tree.

> > > FWIW, in the context of Debian, I'm personally interested in 4.19.y.
> > 
> > What specific list of commits are you wanting to see backported?
> 
> This:
> 
> 37a2ebdd9e597ae1a0270ac747883ea8f6f767b6
> e10dcb1b6ba714243ad5a35a11b91cc14103a9a9
> e506addeff844237d60545ef4f6141de21471caf
> 0226009ce0f6089f9b31211f7a2703cf9a327a01

These do not look like bugfixes, but a new feature being added for this
driver.  So why not just use a newer kernel version for this feature?

thanks,

greg k-h

Bug#965074: Patches to make multicast proccesing on CDC NCM drivers

[Greg KH]

On Wed, Sep 02, 2020 at 01:47:18PM +0200, Santiago Ruano Rincón wrote:
> El 30/07/20 a las 16:07, Oliver Neukum escribió:
> > Am Donnerstag, den 30.07.2020, 15:53 +0200 schrieb Santiago Ruano
> > Rincón:
> > > Hi,
> > > 
> > > Miguel Rodríguez sent this set of patches two years ago to fix the lack
> > > of multicast processing on CDC NCM driver:
> > > 
> > > https://www.spinics.net/lists/linux-usb/msg170611.html
> > > https://www.spinics.net/lists/linux-usb/msg170603.html
> > > https://www.spinics.net/lists/linux-usb/msg170567.html
> > > https://www.spinics.net/lists/linux-usb/msg170568.html
> > > 
> > > I've using a DKMS version of them, available in
> > > https://github.com/stbuehler/fixed-cdc-ether-ncm/tree/wip/patches
> > > since more than a year ago, and they are working fine with my Dell D6000
> > > docking station. IPv6 connectivity is broken without them.
> > > 
> > > Is there any chance to consider those patches (or what would be needed
> > > to make it happen)?
> > > It would be great to have them upstream!
> > 
> > Hi,
> > 
> > they have been merged on Wednesday.
> …
> 
> Great, thanks!
> 
> It would be possible to apply/backport Miguel's patches (along with
> 5fd99b5d9950d6300467ded18ff4e44af0b4ae55) to stable versions please?

I don't see that git commit id in Linus's tree, are you sure it is
correct?

> FWIW, in the context of Debian, I'm personally interested in 4.19.y.

What specific list of commits are you wanting to see backported?

thanks,

greg k-h

Bug#963493: Repeatable hard lockup running strace testsuite on 4.19.98+ onwards

[Greg KH]

On Fri, Jun 26, 2020 at 12:35:58PM +0100, Steve McIntyre wrote:
> Hi folks,
> 
> I'm the maintainer in Debian for strace. Trying to reproduce
> https://bugs.debian.org/963462 on my machine (Thinkpad T470), I've
> found a repeatable hard lockup running the strace testsuite. Each time
> it seems to have failed in a slightly different place in the testsuite
> (suggesting it's not one particular syscall test that's triggering the
> failure). I initially found this using Debian's current Buster kernel
> (4.19.118+2+deb10u1), then backtracking I found that 4.19.98+1+deb10u1
> worked fine.
> 
> I've bisected to find the failure point along the linux-4.19.y stable
> branch and what I've got to is the following commit:
> 
> e58f543fc7c0926f31a49619c1a3648e49e8d233 is the first bad commit
> commit e58f543fc7c0926f31a49619c1a3648e49e8d233
> Author: Jann Horn 
> Date:   Thu Sep 13 18:12:09 2018 +0200
> 
> apparmor: don't try to replace stale label in ptrace access check
> 
> [ Upstream commit 1f8266ff58840d698a1e96d2274189de1bdf7969 ]
> 
> As a comment above begin_current_label_crit_section() explains,
> begin_current_label_crit_section() must run in sleepable context because
> when label_is_stale() is true, aa_replace_current_label() runs, which uses
> prepare_creds(), which can sleep.
> Until now, the ptrace access check (which runs with a task lock held)
> violated this rule.
> 
> Also add a might_sleep() assertion to begin_current_label_crit_section(),
> because asserts are less likely to be ignored than comments.
> 
> Fixes: b2d09ae449ced ("apparmor: move ptrace checks to using labels")
> Signed-off-by: Jann Horn 
> Signed-off-by: John Johansen 
> Signed-off-by: Sasha Levin 
> 
> :04 04 ca92f885a38c1747b812116f19de6967084a647e 
> 865a227665e460e159502f21e8a16e6fa590bf50 M security
> 
> Considering I'm running strace build tests to provoke this bug,
> finding the failure in a commit talking about ptrace changes does look
> very suspicious...!
> 
> Annoyingly, I can't reproduce this on my disparate other machines
> here, suggesting it's maybe(?) timing related.
> 
> Hope this helps - happy to give more information, test things, etc.

So if you just revert this one patch, all works well?

I've added the authors of the patch to the cc: list...

Also, does this problem happen on Linus's tree?

thanks,

greg k-h

Re: a bug in genksysms/CONFIG_MODVERSIONS w/ __attribute__((foo))?

[Greg KH]

On Tue, Aug 27, 2019 at 04:34:15PM +0100, Ben Hutchings wrote:
> On Tue, 2019-08-27 at 22:42 +1000, Nicholas Piggin wrote:
> > Masahiro Yamada's on August 27, 2019 8:49 pm:
> > > Hi.
> > > 
> > > On Tue, Aug 27, 2019 at 6:59 PM Nicholas Piggin  wrote:
> > > > Nick Desaulniers's on August 27, 2019 8:57 am:
> > > > > On Mon, Aug 26, 2019 at 2:22 PM Nick Desaulniers
> > > > >  wrote:
> > > > > > I'm looking into a linkage failure for one of our device kernels, 
> > > > > > and
> > > > > > it seems that genksyms isn't producing a hash value correctly for
> > > > > > aggregate definitions that contain __attribute__s like
> > > > > > __attribute__((packed)).
> > > > > > 
> > > > > > Example:
> > > > > > $ echo 'struct foo { int bar; };' | ./scripts/genksyms/genksyms -d
> > > > > > Defn for struct foo == 
> > > > > > Hash table occupancy 1/4096 = 0.000244141
> > > > > > $ echo 'struct __attribute__((packed)) foo { int bar; };' |
> > > > > > ./scripts/genksyms/genksyms -d
> > > > > > Hash table occupancy 0/4096 = 0
> > > > > > 
> > > > > > I assume the __attribute__ part isn't being parsed correctly (looks
> > > > > > like genksyms is a lex/yacc based C parser).
> > > > > > 
> > > > > > The issue we have in our out of tree driver (*sadface*) is 
> > > > > > basically a
> > > > > > EXPORT_SYMBOL'd function whose signature contains a packed struct.
> > > > > > 
> > > > > > Theoretically, there should be nothing wrong with exporting a 
> > > > > > function
> > > > > > that requires packed structs, and this is just a bug in the lex/yacc
> > > > > > based parser, right?  I assume that not having CONFIG_MODVERSIONS
> > > > > > coverage of packed structs in particular could lead to potentially
> > > > > > not-fun bugs?  Or is using packed structs in exported function 
> > > > > > symbols
> > > > > > with CONFIG_MODVERSIONS forbidden in some documentation somewhere I
> > > > > > missed?
> > > > > 
> > > > > Ah, looks like I'm late to the party:
> > > > > https://lwn.net/Articles/707520/
> > > > 
> > > > Yeah, would be nice to do something about this.
> > > 
> > > modversions is ugly, so it would be great if we could dump it.
> > > 
> > > > IIRC (without re-reading it all), in theory distros would be okay
> > > > without modversions if they could just provide their own explicit
> > > > versioning. They take care about ABIs, so they can version things
> > > > carefully if they had to change.
> 
> Debian doesn't currently have any other way of detecting ABI changes
> (other than eyeballing diffs).
> 
> I know there have been proposals of using libabigail for this instead,
> but I'm not sure how far those progressed.

Google has started using libabigail to track api changes in AOSP, here's
a patch that updates the ABI file after changing it:
https://android-review.googlesource.com/c/kernel/common/+/1108662

Note, there are issues with it, and some rough edges, but I think it can
work.

But, it means nothing at module load time, this is only at build-check
time.  At least modversions would prevent module loading in some cases.

thanks,

greg k-h

Re: [PATCH] um: Don't hardcode path as it is architecture dependent

[Greg KH]

On Tue, May 14, 2019 at 04:36:38PM +0530, Ritesh Raj Sarraf wrote:
> Hello Greg,
> 
> On Tue, 2019-05-14 at 12:26 +0200, Greg KH wrote:
> > On Tue, May 14, 2019 at 03:46:57PM +0530, Ritesh Raj Sarraf wrote:
> > > The current code fails to run on amd64 because of hardcoded
> > > reference to
> > > i386
> > > 
> > > Signed-off-by: Ritesh Raj Sarraf 
> > > Signed-off-by: Richard Weinberger 
> > > ---
> > >   arch/um/drivers/port_user.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > What is the git commit id of this patch in Linus's tree?
> 
> The git commit id should be: 9ca19a3a3e2482916c475b90f3d7fa2a03d8e5ed

Thanks, now queued up.

greg k-h

Re: [PATCH] um: Don't hardcode path as it is architecture dependent

[Greg KH]

On Tue, May 14, 2019 at 03:46:57PM +0530, Ritesh Raj Sarraf wrote:
> Dear Stable Team,
> Request for inclusion into the stable branches of Linux. This change
> went into 4.20 but 4.19 is the LTS release that many of the Linux
> Vendors are rebasing on. Hence, it'd be nice to see this part of the LTS
> releases, at least 4.19.
> 
> 
> The current code fails to run on amd64 because of hardcoded reference to
> i386
> 
> Signed-off-by: Ritesh Raj Sarraf 
> Signed-off-by: Richard Weinberger 
> ---
>  arch/um/drivers/port_user.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

What is the git commit id of this patch in Linus's tree?

thanks,

greg k-h

Bug#928125: Revert commit 310ca162d77

[Greg KH]

On Mon, Apr 29, 2019 at 02:05:42PM +0200, Salvatore Bonaccorso wrote:
> Hi Jan, hi Greg,
> 
> On Wed, Mar 20, 2019 at 01:58:06PM +0100, Jan Kara wrote:
> > Hello,
> > 
> > commit 310ca162d77 "block/loop: Use global lock for ioctl() operation." has
> > been pushed to multiple stable trees. This patch is a part of larger series
> > that overhauls the locking inside loopback device upstream and for 4.4,
> > 4.9, and 4.14 stable trees only this patch from the series is applied. Our
> > testing now has shown [1] that the patch alone makes present deadlocks
> > inside loopback driver more likely (the openqa test in our infrastructure
> > didn't hit the deadlock before whereas with the new kernel it hits it
> > reliably every time). So I would suggest we revert 310ca162d77 from 4.4,
> > 4.9, and 4.14 kernels.
> 
> A user in Debian reported [1], providing the following testcase which showed 
> up
> after the recent update to 4.9.168-1 in Debian stretch (based on upstream
> v4.9.168) as follows:
> 
>   dd if=/dev/zero of=/tmp/ff1.raw bs=1G seek=8 count=0
>   sync
>   sleep 1
>   parted /tmp/ff1.raw mklabel msdos
>   parted -s /tmp/ff1.raw mkpart primary linux-swap 1 100
>   parted -s -- /tmp/ff1.raw mkpart primary ext2 101 -1
>   parted -s -- /tmp/ff1.raw set 2 boot on
>   sleep 5
>   losetup -Pf /tmp/ff1.raw --show
> 
> I have verified that the same happens with v4.9.171 where the mentioned commit
> was not reverted, and bisecting of the testcase showed it was introduced with
> 3ae3d167f5ec2c7bb5fcd12b7772cfadc93b2305 (v4.9.152~9) (which is the backport 
> of
> 310ca162d77 for 4.9).
> 
> Reverting 3ae3d167f5ec2c7bb5fcd12b7772cfadc93b2305 on top of v4.9.171 worked
> and fixed the respective issue.
> 
> Can this commit in meanwhile be reverted or is there further ongoing work in
> integrating the followup fixes as mentioned in
> https://lore.kernel.org/stable/20190321104110.gf29...@quack2.suse.cz/ .

Sorry for the delay here.  No, I didn't find any time for the followup
stuff here, and Jan is right, this should just be dropped.

I've now reverted it from 3.18.y, 4.4.y, 4.9.y, and 4.14.y.

thanks,

greg k-h

Re: [PATCH] tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline()

[Greg KH]

On Mon, Dec 17, 2018 at 08:42:38PM +0100, Loic wrote:
> Le 2018-12-17 09:19, Greg KH a écrit :
> > On Sun, Dec 16, 2018 at 09:08:20PM +0100, Loic wrote:
> > > Le 2018-12-16 20:27, Steven Rostedt a écrit :
> > > > On Sun, 16 Dec 2018 09:52:33 +0100
> > > > Greg KH  wrote:
> > > >
> > > > > On Sat, Dec 15, 2018 at 06:25:37PM +0100, Loic wrote:
> > > > > > Hello,
> > > > > >
> > > > > > Please picked up this patch for linux 4.4 and 4.9.
> > > > > > This fixes CVE-2017-0605 (Rejected?). Tested in Debian ;)
> > > > >
> > > > > It was rejected as a CVE for a good reason, and that reason is also
> > > > > why
> > > > > I refused to add it to the stable kernel releases.  In short, this is
> > > > > not an issue or bug at all, there is nothing wrong with the existing
> > > > > code.
> > > > >
> > > >
> > > > I'm starting to regret that I ever accepted the original patch :-(
> > > >
> > > > -- Steve
> > > 
> > > Okay, I hadn't looked at the previous conversations because this
> > > change is
> > > in the upstream and in debian...
> > 
> > Upstream is fine, it's a valid change so that people don't keep sending
> > the crazy patch over and over.
> > 
> > Debian is just cargo-culting the thing and should probably drop it as it
> > keeps coming back to me every 3 months or so, and I have to reject it
> > again :(
> > 
> > thanks,
> > 
> > greg k-h
> 
> Why didn't you follow the upstream or add a comment "no change for fake
> CVE-2017-0605" to break the debian patch ?

How can I change upstream?  The commit can not be changed once it is
merged.

greg k-h

Bug#889831: USB rndis_host - slow download transfers, RX errors

[Greg KH]

On Thu, Feb 08, 2018 at 10:53:20AM -0500, Tomasz Janowski wrote:
> On Thursday, February 8, 2018 3:43:05 PM EST Greg KH wrote:
> > On Thu, Feb 08, 2018 at 02:16:08PM +, Tomasz Janowski, Ph.D. wrote:
> > > Dear USB developers,
> > > 
> > > Based on my google research, the problem I experience seems to happen
> > > with some newer smartphones. My test case is Samsung Galaxy S8 (SM-950U1).
> > > I am trying to use USB tethering and everything seems to work as expected
> > > (modules are loaded, Ethernet devices are up and running, dhcp works
> > > fine). I can connect to the external world using both LTE or wireless
> > > network on the phone.
> > > 
> > > Now, the problem is that the download speeds are terrible, around 64 KB/s,
> > > while uploads are fast, the order of 15 MB/s. These speeds do not depend
> > > on the wireless service provider: the results are similar when I tether
> > > wi-fi. The USB Ethernet interface on the Linux host reports a lot of
> > > receive errors (attached: device_state.txt), while kernel reports bad
> > > rndis messages (attached: kernel.log.txt).
> > > 
> > > Windows 10 works great with the same hardware (same PC and same phone),
> > > with uploads and downloads in the order of 150 Mbit/s, which is probably
> > > as fast as my wireless network can do. But some people reported issues
> > > with older Windows drivers too. Is possible that some newer version of
> > > RNDIS protocol is around and Linux hasn't updated its RNDIS module yet?
> > 
> > Hey, I was _just_ talking to someone at Google about this same issue
> > yesterday, you beat him sending this same type of report to the mailing
> > list, nice job :)
> > 
> > Yes, this is not good, and we should work to resolve this, but first,
> > what kernel version are you using?  I think some fixes for the rndis
> > driver went in recently to 4.15, but it would be good to verify that
> > this isn't already resolved.
> 
> The error messages which I have attached were produced by a precompiled 
> Debian 
> kernel: "Linux version 4.14.0-0.bpo.3-amd64 (debian-kernel@lists.debian.org) 
> (gcc version 6.3.0 20170516 (Debian 6.3.0-18)) #1 SMP Debian 4.14.13-1~bpo9+1 
> (2018-01-14)".
> 
> But I have downloaded the most recent version of the kernel from the official 
> git repository (last commit: Jan 31, 2018) and it had exactly the same 
> problem. Unless a patch was submitted within the last week, the issue is 
> still 
> there.
> 
> Should I get the version as of today and test it again?

If you find a 4.15 tree, that would be great to test, but odds are, the
issues are still there.

I'll try to carve out some time to look at this tomorrow, as I have a
bunch of Android devices to test with, and there's no good reason why
Windows should be slower than Linux for stuff like this.  We should be
able to go as fast as the device lets us.  Most likely we are doing
something "stupid" in the rndis driver somewhere :)

thanks,

greg k-h

Bug#889831: USB rndis_host - slow download transfers, RX errors

[Greg KH]

On Thu, Feb 08, 2018 at 02:16:08PM +, Tomasz Janowski, Ph.D. wrote:
> Dear USB developers,
> 
> Based on my google research, the problem I experience seems to happen
> with some newer smartphones. My test case is Samsung Galaxy S8 (SM-950U1). I 
> am
> trying to use USB tethering and everything seems to work as expected (modules
> are loaded, Ethernet devices are up and running, dhcp works fine). I can 
> connect to
> the external world using both LTE or wireless network on the phone.
> 
> Now, the problem is that the download speeds are terrible, around 64 KB/s,
> while uploads are fast, the order of 15 MB/s. These speeds do not depend
> on the wireless service provider: the results are similar when I tether wi-fi.
> The USB Ethernet interface on the Linux host reports a lot of receive errors 
> (attached:
> device_state.txt), while kernel reports bad rndis messages (attached: 
> kernel.log.txt).
> 
> Windows 10 works great with the same hardware (same PC and same phone), with
> uploads and downloads in the order of 150 Mbit/s, which is probably as fast 
> as my
> wireless network can do. But some people reported issues with older Windows 
> drivers too.
> Is possible that some newer version of RNDIS protocol is around and Linux 
> hasn't updated
> its RNDIS module yet?

Hey, I was _just_ talking to someone at Google about this same issue
yesterday, you beat him sending this same type of report to the mailing
list, nice job :)

Yes, this is not good, and we should work to resolve this, but first,
what kernel version are you using?  I think some fixes for the rndis
driver went in recently to 4.15, but it would be good to verify that
this isn't already resolved.

thanks,

greg k-h

Bug#854231: Fwd: Kernel 4.9 traces

[Greg KH]

On Sun, Feb 12, 2017 at 05:45:06PM +0100, Wolfgang Schnitker wrote:
> Dear serial developers,
> 
> my suggestion is now following:
> 
> My box has 3 physical serial IO ports, 1 on MB and 2 on PCI IO board.
> 
> dmesg | grep ttyS shows this:
> 
> (rmmod parport_serial and modprobe it again)
> 
> [0.833923] 00:00: ttyS3 at I/O 0x2e8 (irq = 3, base_baud = 115200)
> is a 16550A
> [9.498473] :03:00.0: ttyS0 at I/O 0xcc00 (irq = 17, base_baud =
> 115200) is a 16550A
> [9.519894] :03:00.0: ttyS1 at I/O 0xc880 (irq = 17, base_baud =
> 115200) is a 16550A
> [   17.519943] ttyS0: LSR safety check engaged!
> [   17.521182] ttyS0: LSR safety check engaged!
> [   30.043754] ttyS0: LSR safety check engaged!
> [   30.044734] ttyS0: LSR safety check engaged!
> [   30.044956] ttyS0: LSR safety check engaged!
> [   30.045153] ttyS0: LSR safety check engaged!
> [   30.045344] ttyS0: LSR safety check engaged!
> [   41.594802] ttyS0: LSR safety check engaged!
> [  273.130756] :03:00.0: ttyS1 at I/O 0xcc00 (irq = 17, base_baud =
> 115200) is a 16550A
> [  273.153032] :03:00.0: ttyS2 at I/O 0xc880 (irq = 17, base_baud =
> 115200) is a 16550A
> 
> ttyS3 is on the MB, ttyS0/S1 are the one on he IO card.
> 
> It happens right after activating LSR safety check.
> 
> [   16.522925] EXT4-fs (sda5): mounted filesystem with ordered data
> mode. Opts: (null)
> [   16.552462] EXT4-fs (sda7): mounted filesystem with ordered data
> mode. Opts: errors=remount-ro
> [   17.097626] systemd-journald[216]: Received request to flush runtime
> journal from PID 1
> [   17.519943] ttyS0: LSR safety check engaged!
> [   17.521182] ttyS0: LSR safety check engaged!
> [   17.523884] [ cut here ]
> 
> So look up PCI values for this board:
> 
> 03:00.0 Communication controller: MosChip Semiconductor Technology Ltd.
> PCI 9835 Multi-I/O Controller (rev 01)
> Subsystem: LSI Logic / Symbios Logic 1P2S
> Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> SERR-  Interrupt: pin A routed to IRQ 17
> Region 0: I/O ports at cc00 [size=8]
> Region 1: I/O ports at c880 [size=8]
> Region 2: I/O ports at c800 [size=8]
> Region 3: I/O ports at c480 [size=8]
> Region 4: I/O ports at c400 [size=8]
> Region 5: I/O ports at c080 [size=16]
> Kernel driver in use: parport_serial
>  
> 
> Please tell me, if you need more information.

What exactly is the problem here?

Re: alloc_tty_driver fails with ENOMEM

[Greg KH]

On Tue, Oct 06, 2015 at 11:03:46AM +0300, Baruch Siach wrote:
> Hi Greg,
> 
> On Tue, Oct 06, 2015 at 08:53:07AM +0100, Greg KH wrote:
> > On Tue, Oct 06, 2015 at 09:44:24AM +0300, Baruch Siach wrote:
> > > Since upgrading to kernel version from 4.1.x to 4.2.1 on Debian testing I 
> > > am getting on my PC the following usbserial module init failure when 
> > > connecting my PC to the i.MX6 SabreSD FTDI USB/serial connector:
> > > 
> > > [39987.092021] usb 1-5.1: new full-speed USB device number 4 using 
> > > ehci-pci
> > > [39987.190805] usb 1-5.1: New USB device found, idVendor=0403, 
> > > idProduct=6001
> > > [39987.190810] usb 1-5.1: New USB device strings: Mfr=1, Product=2, 
> > > SerialNumber=3
> > > [39987.190813] usb 1-5.1: Product: FT232R USB UART
> > > [39987.190817] usb 1-5.1: Manufacturer: FTDI
> > > [39987.190820] usb 1-5.1: SerialNumber: A903PDKT
> > > [39989.127918] systemd-udevd: page allocation failure: order:4, 
> > > mode:0x2040d0
> > 
> > This shows that you have some serious memory issues happening here :(
> 
> Which part is showing this? Is the order too high? Unusual mode?

The page allocation failure of a "normal" allocation means that
something is going wrong outside of the USB subsystem.

thanks,

greg k-h

Re: alloc_tty_driver fails with ENOMEM

[Greg KH]

On Tue, Oct 06, 2015 at 09:44:24AM +0300, Baruch Siach wrote:
> Hi linux-usb list,
> 
> Since upgrading to kernel version from 4.1.x to 4.2.1 on Debian testing I am 
> getting on my PC the following usbserial module init failure when connecting 
> my PC to the i.MX6 SabreSD FTDI USB/serial connector:
> 
> [39987.092021] usb 1-5.1: new full-speed USB device number 4 using ehci-pci
> [39987.190805] usb 1-5.1: New USB device found, idVendor=0403, idProduct=6001
> [39987.190810] usb 1-5.1: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=3
> [39987.190813] usb 1-5.1: Product: FT232R USB UART
> [39987.190817] usb 1-5.1: Manufacturer: FTDI
> [39987.190820] usb 1-5.1: SerialNumber: A903PDKT
> [39989.127918] systemd-udevd: page allocation failure: order:4, mode:0x2040d0

This shows that you have some serious memory issues happening here :(

> [39989.127923] CPU: 0 PID: 5856 Comm: systemd-udevd Not tainted 4.2.0-1-amd64 
> #1 Debian 4.2.1-2
> [39989.127925] Hardware name: Gigabyte Technology Co., Ltd. 
> EP45-DS3/EP45-DS3, BIOS F5 06/18/2008
> [39989.127928]   0004 81548756 
> 002040d0
> [39989.127931]  8115266f 88007feddb00  
> 0001
> [39989.127934]  0004 0040 8800793ce7c0 
> 002040d0
> [39989.127937] Call Trace:
> [39989.127945]  [] ? dump_stack+0x40/0x50
> [39989.127951]  [] ? warn_alloc_failed+0xcf/0x130
> [39989.127954]  [] ? __alloc_pages_nodemask+0x2b4/0x9e0

As does this :(

What does 'free -h' show?

I don't think this is a USB issue, you are just hitting it for some odd
reason.

thanks,

greg k-h

Bug#782515: [PATCH stable 3.10-3.16] tcp: Fix crash in TCP Fast Open

[Greg KH]

On Wed, Apr 15, 2015 at 07:00:32PM +0100, Ben Hutchings wrote:
 Commit 355a901e6cf1 (tcp: make connect() mem charging friendly)
 changed tcp_send_syn_data() to perform an open-coded copy of the 'syn'
 skb rather than using skb_copy_expand().
 
 The open-coded copy does not cover the skb_shared_info::gso_segs
 field, so in the new skb it is left set to 0.  When this commit was
 backported into stable branches between 3.10.y and 3.16.7-ckty
 inclusive, it triggered the BUG() in tcp_transmit_skb().
 
 Since Linux 3.18 the GSO segment count is kept in the
 tcp_skb_cb::tcp_gso_segs field and tcp_send_syn_data() does copy the
 tcp_skb_cb structure to the new skb, so mainline and newer stable
 branches are not affected.
 
 Set skb_shared_info::gso_segs to the correct value of 1.
 
 Signed-off-by: Ben Hutchings b...@decadent.org.uk
 ---
  net/ipv4/tcp_output.c | 1 +
  1 file changed, 1 insertion(+)

Thanks for working on this and sending the patch out.

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150417094327.ga29...@kroah.com

Re: [ANNOUNCE] Linux 3.16.y.z extended stable support

[Greg KH]

On Fri, Nov 07, 2014 at 10:43:28AM +, Luis Henriques wrote:
 On Thu, Oct 30, 2014 at 06:17:01PM +, Luis Henriques wrote:
  The Ubuntu kernel team is pleased to announce that we will be
  providing extended stable support for the Linux 3.16 kernel until
  April 2016 as a third party effort maintained on our infrastructure.
  The team will pick up stable maintenance where Greg KH left off with
  v3.16.7 [1].  Thank you, Greg.
  
  In addition to the Ubuntu 14.10 Utopic Unicorn release, the Debian 8
  Jessie release will also be based on this kernel [2].  Since the
  regular support for Jessie will go beyond April 2016, after this
  date Ben Hutchings (or myself) will continue the Linux 3.16 kernel
  maintenance.
  
  Our linux-3.16.y{-queue,-review} stable branches will fork from
  v3.16.7
  and will be published here:
  
  git://kernel.ubuntu.com/ubuntu/linux.git
  
  We will use the same stable request/review workflow and follow the
  standard upstream stable kernel rules.  More details are available
  here [3].
  
 
 In addition, I would like to announce a change in the kernel numbering
 scheme that we will be using: we are adding the string '-ckt'
 ('Canonical Kernel Team') to the kernel version.  So, for example,
 kernel '3.16.7.1' becomes '3.16.7-ckt1'.

Thank you for doing this.

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141107161632.gb12...@kroah.com

Re: [ANNOUNCE] Linux 3.16.y.z extended stable support

[Greg KH]

On Thu, Oct 30, 2014 at 06:17:01PM +, Luis Henriques wrote:
 The Ubuntu kernel team is pleased to announce that we will be
 providing extended stable support for the Linux 3.16 kernel until
 April 2016 as a third party effort maintained on our infrastructure.
 The team will pick up stable maintenance where Greg KH left off with
 v3.16.7 [1].  Thank you, Greg.
 
 In addition to the Ubuntu 14.10 Utopic Unicorn release, the Debian 8
 Jessie release will also be based on this kernel [2].  Since the
 regular support for Jessie will go beyond April 2016, after this
 date Ben Hutchings (or myself) will continue the Linux 3.16 kernel
 maintenance.
 
 Our linux-3.16.y{-queue,-review} stable branches will fork from
 v3.16.7
 and will be published here:
 
 git://kernel.ubuntu.com/ubuntu/linux.git
 
 We will use the same stable request/review workflow and follow the
 standard upstream stable kernel rules.  More details are available
 here [3].
 
 We welcome any feedback and contribution to this effort.  We will be
 posting the first review cycle patch set in a week or two.
 
 [1] https://lkml.org/lkml/2014/10/30/583
 [2] https://lists.debian.org/debian-kernel/2014/07/msg00413.html
 [3] http://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

Can you _PLEASE_ use a '-somename' format of the kernel release
numbering scheme for this release, if you are going to do this, to
reduce the confusion that has been happening with your kernel releases?

thanks,

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141030181834.ga31...@kroah.com

Bug#751417: linux-image-3.2.0-4-5kc-malta: no SIGKILL after prctl(PR_SET_SECCOMP, 1, ...) on MIPS

[Greg KH]

On Thu, Jun 12, 2014 at 09:21:41PM +0100, Ben Hutchings wrote:
 On Thu, 2014-06-12 at 20:36 +0100, Ben Hutchings wrote:
  Control: tag -1 security upstream patch moreinfo
  Control: severity -1 grave
  Control: found -1 3.14.5-1
 
 Aurelien Jarno pointed out this appears to be fixed upstream in 3.15:
 
 commit 137f7df8cead00688524c82360930845396b8a21
 Author: Markos Chandras markos.chand...@imgtec.com
 Date:   Wed Jan 22 14:40:00 2014 +
 
 MIPS: asm: thread_info: Add _TIF_SECCOMP flag
 
 It looks like this can be cherry-picked cleanly onto stable branches for
 3.13 and 3.14.  For 3.11 and 3.12, it will need trivial adjustment.
 
 For branches older than 3.11, this needs to be cherry-picked first:
 
 commit e7f3b48af7be9f8007a224663a5b91340626fed5
 Author: Ralf Baechle r...@linux-mips.org
 Date:   Wed May 29 01:02:18 2013 +0200
 
 MIPS: Cleanup flags in syscall flags handlers.

It also needs parts of 1d7bf993e0731b4ac790667c196b2a2d787f95c3 (MIPS:
ftrace: Add support for syscall tracepoints.) to apply properly to stuff
older than 3.11.  But, I'm not so sure that is good to apply as that is
a whole new feature.

So I think I'll just do this by hand to get it to work properly...

thanks,

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140612210323.ga30...@kroah.com

Bug#751417: linux-image-3.2.0-4-5kc-malta: no SIGKILL after prctl(PR_SET_SECCOMP, 1, ...) on MIPS

[Greg KH]

On Thu, Jun 12, 2014 at 02:03:23PM -0700, Greg KH wrote:
 On Thu, Jun 12, 2014 at 09:21:41PM +0100, Ben Hutchings wrote:
  On Thu, 2014-06-12 at 20:36 +0100, Ben Hutchings wrote:
   Control: tag -1 security upstream patch moreinfo
   Control: severity -1 grave
   Control: found -1 3.14.5-1
  
  Aurelien Jarno pointed out this appears to be fixed upstream in 3.15:
  
  commit 137f7df8cead00688524c82360930845396b8a21
  Author: Markos Chandras markos.chand...@imgtec.com
  Date:   Wed Jan 22 14:40:00 2014 +
  
  MIPS: asm: thread_info: Add _TIF_SECCOMP flag
  
  It looks like this can be cherry-picked cleanly onto stable branches for
  3.13 and 3.14.  For 3.11 and 3.12, it will need trivial adjustment.
  
  For branches older than 3.11, this needs to be cherry-picked first:
  
  commit e7f3b48af7be9f8007a224663a5b91340626fed5
  Author: Ralf Baechle r...@linux-mips.org
  Date:   Wed May 29 01:02:18 2013 +0200
  
  MIPS: Cleanup flags in syscall flags handlers.
 
 It also needs parts of 1d7bf993e0731b4ac790667c196b2a2d787f95c3 (MIPS:
 ftrace: Add support for syscall tracepoints.) to apply properly to stuff
 older than 3.11.  But, I'm not so sure that is good to apply as that is
 a whole new feature.
 
 So I think I'll just do this by hand to get it to work properly...

Wait, no, SECCOMP for MIPS isn't even in 3.10 or older kernels, so why
is this a 3.2 issue?  Did you add it there to your kernel for some
reason?

thanks,

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140612210531.gb30...@kroah.com

Bug#751417: linux-image-3.2.0-4-5kc-malta: no SIGKILL after prctl(PR_SET_SECCOMP, 1, ...) on MIPS

[Greg KH]

On Thu, Jun 12, 2014 at 10:10:59PM +0100, Ben Hutchings wrote:
 On Thu, 2014-06-12 at 14:05 -0700, Greg KH wrote:
  On Thu, Jun 12, 2014 at 02:03:23PM -0700, Greg KH wrote:
   On Thu, Jun 12, 2014 at 09:21:41PM +0100, Ben Hutchings wrote:
On Thu, 2014-06-12 at 20:36 +0100, Ben Hutchings wrote:
 Control: tag -1 security upstream patch moreinfo
 Control: severity -1 grave
 Control: found -1 3.14.5-1

Aurelien Jarno pointed out this appears to be fixed upstream in 3.15:

commit 137f7df8cead00688524c82360930845396b8a21
Author: Markos Chandras markos.chand...@imgtec.com
Date:   Wed Jan 22 14:40:00 2014 +

MIPS: asm: thread_info: Add _TIF_SECCOMP flag

It looks like this can be cherry-picked cleanly onto stable branches for
3.13 and 3.14.  For 3.11 and 3.12, it will need trivial adjustment.

For branches older than 3.11, this needs to be cherry-picked first:

commit e7f3b48af7be9f8007a224663a5b91340626fed5
Author: Ralf Baechle r...@linux-mips.org
Date:   Wed May 29 01:02:18 2013 +0200

MIPS: Cleanup flags in syscall flags handlers.
   
   It also needs parts of 1d7bf993e0731b4ac790667c196b2a2d787f95c3 (MIPS:
   ftrace: Add support for syscall tracepoints.) to apply properly to stuff
   older than 3.11.  But, I'm not so sure that is good to apply as that is
   a whole new feature.
   
   So I think I'll just do this by hand to get it to work properly...
  
  Wait, no, SECCOMP for MIPS isn't even in 3.10 or older kernels, so why
  is this a 3.2 issue?  Did you add it there to your kernel for some
  reason?
 
 Seccomp mode 2 (i.e. filtering with BPF) was only just implenented for
 MIPS in 3.15.  Mode 1 (fixed set of syscalls) was implemented long ago.

Really?  I don't see _TIF_SECCOMP in the mips asm files in 3.10.  I
don't feel comfortable backporting it to 3.10 or 3.4, are you going to
do that for 3.2?

 (If prctl(PR_SET_SECCOMP) could return success when CONFIG_SECCOMP is
 not enabled, that would be even worse!)

True, but this seems to have always been broken, right?  :)

thanks,

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140612215947.ga8...@kroah.com

Bug#704242: Driver for PL-2303 HX not working

[Greg KH]

On Sun, Dec 15, 2013 at 11:32:33AM +0100, Karsten Malcher wrote:
 Hello Greg,
 
 Am 14.12.2013 18:08, schrieb Greg KH:
  On Fri, Dec 13, 2013 at 04:06:35PM +0100, Karsten Malcher wrote:
  Hello together,
 
  is there anything new for the PL-2303 HX?
  It would be fine if it could work like in the past.
  Have you tried a newer kernel in a while?  A number of things have been
  hopefully fixed since June when you last looked.
 
  greg k-h
 
 no at this time i have not tested it - sorry.
 Although i am fascinated from your work i personally prefer to use stable 
 releases for my daily work.
 This bug here shows that several functionalites in detail can be lost with an 
 update.
 Then it takes much time to find workarounds - specially when hardware is not 
 running any more.
 
 When i look in the Debian repositories i only see kernel 3.11.10 for testing 
 and unstable.
 The latest one is 3.12.3 in experimental.
 I will see to upgrade one copy of my installation to testing on another 
 partition with 3.11.10.
 
 Do you mean that will hopefully show a resolution for this problem?

I do not know, 3.11 is pretty old, sorry.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131215170520.gd28...@kroah.com

Bug#704242: Driver for PL-2303 HX not working

[Greg KH]

On Fri, Dec 13, 2013 at 04:06:35PM +0100, Karsten Malcher wrote:
 Hello together,
 
 is there anything new for the PL-2303 HX?
 It would be fine if it could work like in the past.

Have you tried a newer kernel in a while?  A number of things have been
hopefully fixed since June when you last looked.

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131214170825.ga22...@kroah.com

Re: request for intel/igb backport

[Greg KH]

On Tue, Jun 25, 2013 at 02:13:36PM -0700, Matt Taggart wrote:
 Hi Stable maintainers,
 
 I am the proud owner of a new Supermicro server mainboard that uses
 an LGA1150 socket and supports the new Intel Haswell CPUs that just
 started shipping at the beginning of June.  The board has two
 built-in gigabit ethernet NICs.  Here are their lspci lines:
 
   00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet 
 Connection I217-LM [8086:153a] (rev 04)
   03:00.0 Ethernet controller [0200]: Intel Corporation I210 
 Gigabit Network Connection [8086:1533] (rev 03)
 
 Upon loading the igb driver does not claim them (and likely doesn't
 have what's needed to support them anyway).
 
 Support for them appears to be added in:
   commit 2fbe4526e5aafc9ffa5d85fa4749a7c5b22af6b2
   commit f96a8a0b78548c0ec06b0b4b438db6ee895d67e9
 
 Please consider backporting support for these devices to stable. I
 expect we'll see a lot more of them hitting the streets soon and having
 them in stable (and eventually distro install media) will be very
 helpful.

Please read the file, Documentation/stable_kernel_rules.txt for why we
can't accept these patches into the stable kernel releases.

Also, just use a newer kernel release, like 3.9, or even better, 3.10
when it comes out next week.  Your hardware should work just fine then,
right?

sorry,

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130625215944.gb22...@kroah.com

Bug#704242: Fwd: Re: Bug#704242: Driver for PL-2303 HX not working

[Greg KH]

On Mon, Jun 24, 2013 at 10:41:07AM +0200, Karsten Malcher wrote:
 Hello Greg,
 
 have you buyed one of this jinxed PL-2303 HX adapters?

No, I have not been able to find one.  Does anyone know where I can
purchase one?

 Yesterday i got this interesting mail from Aric, who has analyzed a
 similar problem with this chip.  I think something went wrong in the
 usb serial handling, but not in the driver itself.  But the error is
 really complicate to figure out in the depth of the software.
 
 The really annoying thing is that it worked with kernel 2.6.32.

That's a really long time ago, loads of things have changed since then.
If someone can run 'git bisect' to track down the problem, that would be
wonderful.

thanks,

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130624161702.ga16...@kroah.com

Bug#704242: Fwd: Re: Bug#704242: Driver for PL-2303 HX not working

[Greg KH]

On Mon, Jun 24, 2013 at 06:41:38PM +0200, Karsten Malcher wrote:
 Hello Greg,
 
 Am 24.06.2013 18:17, schrieb Greg KH:
 On Mon, Jun 24, 2013 at 10:41:07AM +0200, Karsten Malcher wrote:
 Hello Greg,
 
 have you buyed one of this jinxed PL-2303 HX adapters?
 No, I have not been able to find one.  Does anyone know where I can
 purchase one?
 
 Just take this one:
 http://www.ebay.com/itm/USB-To-RS232-TTL-PL2303HX-Auto-Converter-Module-5V-3-3V-Output-Converter-Adapter-/370812126675
 US $1.67 and it is yours.

But wiring that up to a real 9pin serial port would be a pain (doable,
but a pain).  Is there any devices out there with a DB-9 output
connector?

thanks,

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130624181821.gb8...@kroah.com

Bug#704242: Fwd: Re: Bug#704242: Driver for PL-2303 HX not working

[Greg KH]

On Mon, Jun 24, 2013 at 08:37:59PM +0200, Karsten Malcher wrote:
 Am 24.06.2013 20:18, schrieb Greg KH:
 On Mon, Jun 24, 2013 at 06:41:38PM +0200, Karsten Malcher wrote:
 Hello Greg,
 
 Am 24.06.2013 18:17, schrieb Greg KH:
 On Mon, Jun 24, 2013 at 10:41:07AM +0200, Karsten Malcher wrote:
 Hello Greg,
 
 have you buyed one of this jinxed PL-2303 HX adapters?
 No, I have not been able to find one.  Does anyone know where I can
 purchase one?
 Just take this one:
 http://www.ebay.com/itm/USB-To-RS232-TTL-PL2303HX-Auto-Converter-Module-5V-3-3V-Output-Converter-Adapter-/370812126675
 US $1.67 and it is yours.
 But wiring that up to a real 9pin serial port would be a pain (doable,
 but a pain).  Is there any devices out there with a DB-9 output
 connector?
 
 You mean if you want to test full handshake with all signals - that's true.

Which is what the driver needs to test, right?  And of course, everone
with this problem is properly hooking up these signals, right?
Otherwise, there will be problems as the pins could float and cause
transmissions / receive data to stop happening.

At the least, loop-back testing is important.

 The advantage of the adapter is to get directly 5V and 3,3V.

What do you mean by this?

 I don't know some other adapter with exactly this chip, because i don't need 
 them.
 Only this Adapter which use the other chip ch341-uart which works without 
 problems
 http://www.ebay.com/itm/USB-to-RS232-Serial-9-Pin-DB9-Adapter-PC-PDA-RS-232-/180399132966
 
 When i think about it i never seen that someone uses the handshake for this 
 simple serial communication.
 Not in communication with mobiles, ARM-boards or AVR microcontroller.
 The built-in UART's in the ARM and AVR don't suffer handshake
 signals, so that you must do it by software with additional IO
 ports.

What's wrong with software flow control?  Why reinvent something that
has been successfully used for 30+ years?

thanks,

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130624185627.ga23...@kroah.com

Bug#704242: Driver for PL-2303 HX not working

[Greg KH]

On Mon, Jun 24, 2013 at 12:38:17PM -0400, Aric Fedida wrote:
 I will gladly ship you one. Give me address details, and I'll go to
 the post office to send it.

I'll send it off-list, thanks.

 Personally, I have resolved to abandon the PL2303 chip, and move to
 FTDI instead. But for the sake of other Linux users who might buy that
 adapter by mistake, I am willing to donate the hardware to an able
 kernel hacker :-)

Yes, I recommend the ftdi devices as well, the specs are availble, and
the driver seems to work better because of it.

thanks,

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130624190056.ga23...@kroah.com

Re: getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))

[Greg KH]

On Wed, Jun 05, 2013 at 11:56:43PM +0100, Luke Kenneth Casson Leighton wrote:
 so there's a lot of factors which i believe the linux kernel
 developers are not aware of, and haven't taken into account, and to
 place blame onto the SoC vendors for not working with *you* when *you*
 haven't made an effort to understand their situation is, i feel, not
 really helping anyone.  not that i'm one to talk about understanding
 people, but hey... :)

Wait, everyone in the world knows where we (Linux kernel developers)
are, and how to contact us, how are we supposed to know we are supposed
to go after these various companies and contact them directly?

So this SoC vendor doesn't want to merge their code upstream, fine, we
(kernel community) don't really care, and it's obvious the company
doesn't care, so what really is the issue here?

Eventually, the SoC will realize that they do need to get their code
merged, and we will still be here, as we aren't going anywhere.  At that
point in time, we will be glad to review patches and code like we do
every day for all of the thousands of other companies we deal with on a
weekly basis.

I don't see the problem here, do you?

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130606003553.ga7...@kroah.com

Bug#659111: [PATCH 3.0.y, 3.2.y] NFSv4: Revalidate uid/gid after open

[Greg KH]

On Fri, May 11, 2012 at 04:20:20AM -0500, Jonathan Nieder wrote:
 This is a shorter (and more appropriate for stable kernels) analog to
 the following upstream commit:
 
 commit 6926afd1925a54a13684ebe05987868890665e2b
 Author: Trond Myklebust trond.mykleb...@netapp.com
 Date:   Sat Jan 7 13:22:46 2012 -0500
 
 NFSv4: Save the owner/group name string when doing open
 
 ...so that we can do the uid/gid mapping outside the asynchronous RPC
 context.
 This fixes a bug in the current NFSv4 atomic open code where the client
 isn't able to determine what the true uid/gid fields of the file are,
 (because the asynchronous nature of the OPEN call denies it the ability
 to do an upcall) and so fills them with default values, marking the
 inode as needing revalidation.
 Unfortunately, in some cases, the VFS will do some additional sanity
 checks on the file, and may override the server's decision to allow
 the open because it sees the wrong owner/group fields.
 
 Signed-off-by: Trond Myklebust trond.mykleb...@netapp.com
 
 Without this patch, logging into two different machines with home
 directories mounted over NFS4 and then running vim and typing :q
 in each reliably produces the following error on the second machine:
 
   E137: Viminfo file is not writable: /users/system/rtheys/.viminfo
 
 This regression was introduced by 80e52aced138 (NFSv4: Don't do
 idmapper upcalls for asynchronous RPC calls, merged during the 2.6.32
 cycle) --- after the OPEN call, .viminfo has the default values for
 st_uid and st_gid (0xfffe) cached because we do not want to let
 rpciod wait for an idmapper upcall to fill them in.
 
 The fix used in mainline is to save the owner and group as strings and
 perform the upcall in _nfs4_proc_open outside the rpciod context,
 which takes about 600 lines.  For stable, we can do something similar
 with a one-liner: make open check for the stale fields and make a
 (synchronous) GETATTR call to fill them when needed.
 
 Trond dictated the patch, I typed it in, and Rik tested it.
 
 Addresses http://bugs.debian.org/659111 and
   https://bugzilla.redhat.com/789298
 
 Reported-by: Rik Theys rik.th...@esat.kuleuven.be
 Explained-by: David Flyn dav...@rd.bbc.co.uk
 Signed-off-by: Jonathan Nieder jrnie...@gmail.com
 Tested-by: Rik Theys rik.th...@esat.kuleuven.be
 ---
 Hi Ben and Greg,
 
 Please consider this patch for inclusion in 3.0.y and 3.2.y kernels.
 3.3.y doesn't need it since 6926afd1925a was merged during the 3.3
 merge window.

Wonderful work, now applied to the 3.0-stable tree, thanks for doing
this.

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120518193156.gd4...@kroah.com

Bug#657078: patches to reduce the footprint of the nfs4 idmapper

[Greg KH]

On Tue, Apr 24, 2012 at 10:22:50PM +0200, Rik Theys wrote:
 Hi,
 
 I'm experiencing the following Red Hat bug[1] on RHEL and also on
 Debian.
 
 I've noticed Fedora has started to ship an update with two patches
 that reduce the footprint of the nfs4 id mapper which should prevent
 this (or seriously limit the chance).
 
 NFSv4: Further reduce the footprint of the idmapper
 commit 685f50f9188ac1e8244d0340a9d6ea36b6136cec
 
 NFSv4: Reduce the footprint of the idmapper
 commit d073e9b541e1ac3f52d72c3a153855d9a9ee3278
 
 I believe Red Hat will have those patches in an upcoming RHEL 6.x
 release.
 
 I'm looking for feedback on if it would be possible to include
 these patches in a stable 3.2 update (and/or 3.0.x) so they
 will become part of the upcoming Debian 7.0 kernel (which is based
 on 3.2).
 
 Have these patches made it into the 3.3 and/or 3.4-rc kernels?

Both of these are in the 3.4-rc1 kernel release.

As for stable kernels, I don't see how they fit the rules outlined in
Documentation/stable_kernel_rules.txt, do you?

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120424203513.ga24...@kroah.com

Bug#659111: Regarding NFSv4: Save the owner/group name string when doing open

[Greg KH]

On Tue, Apr 24, 2012 at 10:04:50PM +0200, Rik Theys wrote:
 Hi,
 
 I'm experiencing the bug described in the Debian[1] and Red Hat[2] bug 
 tracker.
 
 This bug seems to have been fixed in the 3.3 kernel with your commit
 6926afd1925a54a13684ebe05987868890665e2b:
 
 From: Trond Myklebust trond.mykleb...@netapp.com
 Date: Sat, 7 Jan 2012 13:22:46 -0500
 Subject: NFSv4: Save the owner/group name string when doing open
 
 commit 6926afd1925a54a13684ebe05987868890665e2b upstream.
 
 ...so that we can do the uid/gid mapping outside the asynchronous RPC
 context.
 This fixes a bug in the current NFSv4 atomic open code where the client
 isn't able to determine what the true uid/gid fields of the file are,
 (because the asynchronous nature of the OPEN call denies it the ability
 to do an upcall) and so fills them with default values, marking the
 inode as needing revalidation.
 Unfortunately, in some cases, the VFS will do some additional sanity
 checks on the file, and may override the server's decision to allow
 the open because it sees the wrong owner/group fields.
 
 Signed-off-by: Trond Myklebust trond.mykleb...@netapp.com
 Signed-off-by: Jonathan Nieder jrnie...@gmail.com
 
 It seems Red Hat will apply the patch in their RHEL 6.3 kernel. I would
 also like to see this patch included in the upcoming Debian 7.0 kernel,
 which is based on kernel 3.2.
 
 I would like to propose this patch for a stable kernel update (3.2.x
 and/or 3.0.x). Trond, do you agree that this patch (alone)
 can/should be part of a stable update? The Debian maintainers would
 prefer to see the patch be part of a stable update to consider it.

This patch seems to violate Documentatin/stable_kernel_rules.txt,
doesn't it?  And as such, how could I include it in any stable kernel
release?

thanks,

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120424203622.gb24...@kroah.com

Bug#605275: EeePC 1005HAG still freezes when probing the builtin 3G modem

[Greg KH]

On Sun, Feb 26, 2012 at 05:38:46PM +0100, Maik Zumstrull wrote:
 Hi there,
 
 this is a re-report because not everyone loves Bugzilla.
 
 tl;dr: Because of a conflict on a TTY lock, opening the builtin USB 3G
 modem of the EeePC 1005HAG takes up to 10s.
 
 Previously reported as:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605275
 https://bugzilla.kernel.org/show_bug.cgi?id=23962
 
 On all tested Debian kernel images from around 2.6.36 all the way to
 3.2.6, this netbook freezes for several seconds four times after
 booting or returning from standby. The trigger has shown to be
 ModemManager probing the builtin GSM/UMTS modem. The underlying issue
 can be triggered without ModemManager with a minimal C program that
 opens the device the same way ModemManager does (included in Bugzilla
 report). The most problematic call is:
 open(/dev/ttyUSB1, O_RDWR | O_EXCL | O_NOCTTY | O_NONBLOCK);
 
 The lsusb output for the affected device is:

I don't see any long delay in your kernel log messages.

What exactly is stalling so long?  Is the device stuck doing something?
If you enable debugging for usb and/or the driver, what does the kernel
log show?  What driver is bound to this device, the option one?

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120226170709.gd2...@kroah.com

Bug#605275: EeePC 1005HAG still freezes when probing the builtin 3G modem

[Greg KH]

On Sun, Feb 26, 2012 at 06:35:43PM +0100, Maik Zumstrull wrote:
 On Sun, Feb 26, 2012 at 18:07, Greg KH g...@kroah.com wrote:
  On Sun, Feb 26, 2012 at 05:38:46PM +0100, Maik Zumstrull wrote:
 
  I don't see any long delay in your kernel log messages.
 
 The problem isn't visible in dmesg AFAIK. I was asked to include this
 output in the report just in case. It's visible in strace (attached to
 Bugzilla, can take a fresh trace if you'd like), and to the user
 because the whole system ignores user input during the freeze.
 
  What exactly is stalling so long?
 
 When someone previously looked at the issue with me, the delay seemed
 to be in acquiring the big TTY lock.

There is no more big tty lock in the 3.2 kernel.  Well, there's a
small one, but this all should be fixed now.

  Is the device stuck doing something?
 
 Not as far as I know.

Are two userspace programs trying to access the device at the same time?
What could be causing the lock to hold things up here?

  If you enable debugging for usb and/or the driver, what does the kernel
  log show?
 
 I don't think we've done that yet. Quick pointer on how to do this?
 I'm reasonably experienced, but not a kernel developer. Just pass
 debug=1 to certain modules?

That can work if it's the option module.

  What driver is bound to this device, the option one?
 
 Yes. The drivers symlink points to bus/usb/drivers/option, anyway, I
 hope that's what you meant.

Yes.  Please try loading the module with:
modprobe option debug=1
and seeing what happens in the kernel log when you open the device.

thanks,

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120226175748.ga3...@kroah.com

[patch 52/86] lockdep, bug: Exclude TAINT_OOT_MODULE from disabling lock debugging

[Greg KH]

3.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Ben Hutchings b...@decadent.org.uk

commit 9ec84acee1e221d99dc33237bff5e82839d10cc0 upstream.

We do want to allow lock debugging for GPL-compatible modules
that are not (yet) built in-tree.  This was disabled as a
side-effect of commit 2449b8ba0745327c5fa49a8d9acffe03b2eded69
('module,bug: Add TAINT_OOT_MODULE flag for modules not built
in-tree').  Lock debug warnings now include taint flags, so
kernel developers should still be able to deflect warnings
caused by out-of-tree modules.

The TAINT_PROPRIETARY_MODULE flag for non-GPL-compatible modules
will still disable lock debugging.

Signed-off-by: Ben Hutchings b...@decadent.org.uk
Cc: Nick Bowler nbow...@elliptictech.com
Cc: Dave Jones da...@redhat.com
Cc: Rusty Russell ru...@rustcorp.com.au
Cc: Randy Dunlap rdun...@xenotime.net
Cc: Debian kernel maintainers debian-kernel@lists.debian.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Alan Cox a...@linux.intel.com
Link: http://lkml.kernel.org/r/1323268258.18450.11.camel@deadeye
Signed-off-by: Ingo Molnar mi...@elte.hu
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

---
 kernel/panic.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -237,11 +237,12 @@ void add_taint(unsigned flag)
 * Can't trust the integrity of the kernel anymore.
 * We don't call directly debug_locks_off() because the issue
 * is not necessarily serious enough to set oops_in_progress to 1
-* Also we want to keep up lockdep for staging development and
-* post-warning case.
+* Also we want to keep up lockdep for staging/out-of-tree
+* development and post-warning case.
 */
switch (flag) {
case TAINT_CRAP:
+   case TAINT_OOT_MODULE:
case TAINT_WARN:
case TAINT_FIRMWARE_WORKAROUND:
break;



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120210222949.660791...@clark.kroah.org

Re: Linux 3.2 in Debian 7.0

[Greg KH]

On Tue, Jan 31, 2012 at 10:46:02AM -0500, Pete Graner wrote:
 On 01/30/2012 02:51 PM, Greg KH wrote:
 On Mon, Jan 30, 2012 at 03:46:29AM +, Ben Hutchings wrote:
 Greg,
 
 We've decided to go with Linux 3.2 for the next Debian stable release,
 so we'll be interested in a 3.2.y longterm series.  I believe there was
 a volunteer from Ubuntu to look after that once you've had enough of it,
 but I seem to have lost the relevant mail.
 
 I will not be handing any stable/longterm maintance over to anyone who
 does not have a _lot_ of kernel community experience, so that seems to
 rule out just about all Ubuntu developers at this point in time from
 what I can tell.
 
 Greg, I'd be interested to know what the criteria is for a _lot_ of
 kernel community experience. We are will to put in the time and
 effort, and if there are things we need to do I'd like to know what
 they are.

I could spell it out, (maintainer of a subsystem, known member of the
community, lots and lots of kernel commits, invited to kernel summit
and/or subsystem summit meetings, etc.), but that kind of implies that
this is something that you are looking to achieve for the sake of
achieving it, rather than it happening because this is something you
want to do, which is the most important thing.

Yes, it's an imperfect judgement call, but if you were in my situation,
what would you do and trust?

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120131161459.ga9...@kroah.com

Re: Linux 3.2 in Debian 7.0

[Greg KH]

On Mon, Jan 30, 2012 at 03:46:29AM +, Ben Hutchings wrote:
 Greg,
 
 We've decided to go with Linux 3.2 for the next Debian stable release,
 so we'll be interested in a 3.2.y longterm series.  I believe there was
 a volunteer from Ubuntu to look after that once you've had enough of it,
 but I seem to have lost the relevant mail.

I will not be handing any stable/longterm maintance over to anyone who
does not have a _lot_ of kernel community experience, so that seems to
rule out just about all Ubuntu developers at this point in time from
what I can tell.

As I think this will be a Debian/Ubuntu thing only, I don't know if
keeping the kernel.org version around for any length of time is really
going to help much out here, do you?

thanks,

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120130195138.ga10...@kroah.com

Re: [m68k] partial success but does not boot: 3.2~rc7

[Greg KH]

On Sun, Jan 01, 2012 at 11:53:45PM +, Ben Hutchings wrote:
 On Sun, 2012-01-01 at 23:27 +, Ben Hutchings wrote:
  On Sun, 2012-01-01 at 21:16 +, Thorsten Glaser wrote:
 [...]
   • work and fail
   
   This is for debian-68k, linux-68k and debian-kernel:
   
   ARAnyM “console” output of a working (3.0) and failing (3.2) boot,
   for your debugging pleasure. I can run arbitrary tests against the
   failing kernel, as long as they’re limited to [LILO].Args or make
   it boot ;-)
  
  This is presumably triggered by enabling CPU topology information in
  sysfs on UP systems.  This is a Debian patch for 3.2
  (features/all/topology-Provide-CPU-topology-in-sysfs-in-SMP-configura.patch)
   but has been accepted upstream for 3.3.
  
  My guess is that on m68k get_cpu_sysdev(0) returns NULL and thus
  topology_add_dev() passes an invalid pointer into sysfs_create_group().
  So either m68k (and maybe some other architectures with no SMP support)
  need to be fixed or the CPU topology code needs to allow for this.
 
 None of these architectures appears to call register_cpu():
 
 c6x frv h8300 m68k microblaze openrisc score um xtensa
 
 and therefore they will all panic at boot following this change (commit
 ccbc60d3e19a1b6ae66ca0d89b3da02dde62088b).  So either I can try to fix
 them or else it must be reverted for now.

As this is now in Linus's tree, and he has asked for a fix, could you
make one up?

thanks,

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120108175727.gd29...@suse.de

Bug#650119: fails to boot on HP DL380 g4

[Greg KH]

On Thu, Dec 15, 2011 at 03:58:43PM -0600, Jonathan Nieder wrote:
 reassign 650119 src:linux-2.6 3.1.1-1
 severity 650119 important
 # 6225da481597 (cciss: Add IRQF_SHARED back in for the non-MSI(X)
 # interrupt handler, 2011-11-28), which is part of Jens Axboe's
 # block/for-next tree.
 tags 650119 = patch upstream
 # theoretically
 found 650119 linux-2.6/2.6.36~rc5-1~experimental.1
 quit
 
 Hi Peter,
 
 Peter Verschoor wrote:
 
  [Subject: Bug#650119: Fixed]
 
 Please keep in mind that these messages appear as emails in a crowded
 inbox, so the subject line can be a good place to provide some context.
 
   It looks like you can close this bug.  I applied the patch to my
  debian 3.1 kernel tree, built and installed a new kernel and it came
  up just fine.  Still testing to check everything else.  Attached find
  the dmesg log of this boot.
 
 Thanks for checking so quickly.  Marking accordingly.
 
 Stephen, once it hits mainline, would 6225da481597 be a candidate for
 the current-maintained stable trees = 2.6.36, or does it have any
 prerequisites or followups that should go with it?

formletter

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.

/formletter



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111215230308.gc26...@kroah.com

Bug#650119: fails to boot on HP DL380 g4

[Greg KH]

On Thu, Dec 15, 2011 at 05:13:52PM -0600, Jonathan Nieder wrote:
 Greg KH wrote:
  On Thu, Dec 15, 2011 at 03:58:43PM -0600, Jonathan Nieder wrote:
 
  Stephen, once it hits mainline, would 6225da481597 be a candidate for
  the current-maintained stable trees = 2.6.36, or does it have any
  prerequisites or followups that should go with it?
 
  formletter
 
  This is not the correct way to submit patches for inclusion in the
  stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
  for how to do this properly.
 
 I thought step 1 in the right way was for the patch to hit mainline. :)

Yes it is, and until that happens, why are you emailing
sta...@vger.kernel.org about this?  There's nothing I can do about it at
this point in time, except have it cause me extra work :(

 The patch:
 
  - is obviously correct and tested against 3.1.y
  - is very short
  - fixes only one thing
  - fixes a real bug that bothered people (boot failure)
  - also removes the deprecated IRQF_DISABLED flag; I'd be happy to undo
that part and get another round of testing before sending it to you
  - would obviously follow Documentation/SubmittingPatches rules when
sending it to you
  - does *not* yet have an analog in linus's tree.  BTW, I'm not sure
why this isn't in Jens's for-linus branch.

That last one is the stickler, please work on that, without that,
there's nothing I can do here.

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111215235255.ga21...@kroah.com

Bug#649216: [PATCH] topology: Provide CPU topology in sysfs in !SMP configurations

[Greg KH]

On Thu, Nov 24, 2011 at 07:04:39AM +, Ben Hutchings wrote:
 We should provide topology information to userland even if it's not
 very interesting.  The current code appears to work properly for !SMP
 (tested on i386).

Why, what will the topology look like for this?

thanks,

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2024162426.ga4...@suse.de

Re: [PATCH] module,bug: Add TAINT_OOT_MODULE flag for modules not built in-tree

[Greg KH]

On Thu, Oct 27, 2011 at 11:41:37AM +1030, Rusty Russell wrote:
 On Wed, 26 Oct 2011 09:08:34 -0400, Nick Bowler nbow...@elliptictech.com 
 wrote:
  On 2011-10-25 22:54 +0200, Greg KH wrote:
   On Tue, Oct 25, 2011 at 04:17:24PM -0400, Dave Jones wrote:
On Tue, Oct 25, 2011 at 10:04:55PM +0200, Greg Kroah-Hartman wrote:
  On Tue, Oct 25, 2011 at 12:51:42PM -0400, Nick Bowler wrote:
   This is not the case: lockdep works fine with staging modules.
  
  Yes, that was fixed a few kernel versions ago.
  
  Now you might want to update that fix for the TAINT_OOT_MODULE flag 
as
  well, if you feel it is needed.

I'm assuming you mean this patch ?

commit 7816c45bf13255157c00fb8aca86cb64d825e878
Author: Roland Vossen rvos...@broadcom.com
Date:   Thu Apr 7 11:20:58 2011 +0200

modules: Enabled dynamic debugging for staging modules
   
   Hm, this is the patch I was thinking about yes.  But as you point out:
  [...]
   Perhaps the lockdep thing is totally different.  I don't know about that
   check.
  
  Lockdep is disabled (for the whole system) by add_taint itself.  The
  relevant commit that fixes TAINT_CRAP appears to be this one (circa
  2.6.30):
  
commit 574bbe782057fdf0490dc7dec906a2dc26363e20
Author: Frederic Weisbecker fweis...@gmail.com
Date:   Sat Apr 11 03:17:18 2009 +0200

lockdep: continue lock debugging despite some taints
  
  I didn't know about the dynamic debug problem.  Is there more breakage
  that we haven't found yet?  Remind me why we're trying to cripple out
  of tree module users?
 
 Gah, people are overloading taint.
 
 It doesn't mean don't do stuff, it means note the taint when
 something goes wrong.

I agree, we shouldn't be changing logic in the kernel due to tainting,
so removing any such checks would be a good idea.

thanks,

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111027054920.ga1...@kroah.com

Re: [PATCH] module,bug: Add TAINT_OOT_MODULE flag for modules not built in-tree

[Greg KH]

On Tue, Oct 25, 2011 at 12:51:42PM -0400, Nick Bowler wrote:
 On 2011-10-25 18:05 +0200, Ben Hutchings wrote:
  On Tue, 2011-10-25 at 11:38 -0400, Nick Bowler wrote:
   This patch prevents the use of lockdep for debugging out of tree
   modules, which is rather mean.
  
  It was already disabled for staging modules, which seems equally
  unhelpful.
 
 This is not the case: lockdep works fine with staging modules.

Yes, that was fixed a few kernel versions ago.

Now you might want to update that fix for the TAINT_OOT_MODULE flag as
well, if you feel it is needed.

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111025200455.ga6...@kroah.com

Re: [PATCH] module,bug: Add TAINT_OOT_MODULE flag for modules not built in-tree

[Greg KH]

On Tue, Oct 25, 2011 at 04:17:24PM -0400, Dave Jones wrote:
 On Tue, Oct 25, 2011 at 10:04:55PM +0200, Greg Kroah-Hartman wrote:
   On Tue, Oct 25, 2011 at 12:51:42PM -0400, Nick Bowler wrote:
On 2011-10-25 18:05 +0200, Ben Hutchings wrote:
 On Tue, 2011-10-25 at 11:38 -0400, Nick Bowler wrote:
  This patch prevents the use of lockdep for debugging out of tree
  modules, which is rather mean.
 
 It was already disabled for staging modules, which seems equally
 unhelpful.

This is not the case: lockdep works fine with staging modules.
   
   Yes, that was fixed a few kernel versions ago.
   
   Now you might want to update that fix for the TAINT_OOT_MODULE flag as
   well, if you feel it is needed.
 
 I'm assuming you mean this patch ?
 
 commit 7816c45bf13255157c00fb8aca86cb64d825e878
 Author: Roland Vossen rvos...@broadcom.com
 Date:   Thu Apr 7 11:20:58 2011 +0200
 
 modules: Enabled dynamic debugging for staging modules

Hm, this is the patch I was thinking about yes.  But as you point out:

 If we want to support out of tree modules with this, should we just nuke the
 whole check, or do we still want to prevent certain types of tainted kernels
 from using this stuff ?

I don't know, there was some reason we didn't want to run dynamic_debug
for normal tainted kernel modules, but I can't recall it at the
moment, sorry.

 
 (sidenote: it's not immediately obvious to me that this is the right patch,
 as dynamic debug  lockdep are separate things, though this was the only
 thing in kernel/module.c's history this year that sounds similar)

Perhaps the lockdep thing is totally different.  I don't know about that
check.

thanks,

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111025205410.ga7...@kroah.com

Bug#607574: linux-image-2.6.32-5-686: wastes 8s of boot time on something USB related that fails

[Greg KH]

On Mon, Oct 17, 2011 at 07:57:09AM -0500, Jonathan Nieder wrote:
 Version: 3.1.0~rc4-1~experimental.1
 
 Jonathan Nieder wrote:
  Mario wrote:
 
  Version: 2.6.32-29
 [...]
  [7.808651] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on 
  minor 0
  [   16.409864] 
  /build/buildd-linux-2.6_2.6.32-29-i386-Of6Yt1/linux-2.6-2.6.32/debian/build/source_i386_none/drivers/hid/usbhid/hid-core.c:
   usb_submit_urb(ctrl) failed
  [   16.410069] generic-usb 0003:1C4F:0002.0002: timeout initializing 
  reports
  [...]
  Bus 004 Device 002: ID 1c4f:0002 SiGma Micro 
 
 Should be fixed by v3.1-rc4~47^2^2 (HID: usbhid: Add support for SiGma
 Micro chip, 2011-08-23).  Mario, can you confirm[1]?  Greg et al, does
 this patch look like a reasonable candidate for the linux-2.6.32.y
 tree?

Why wouldn't it also go into the 3.0-stable tree?

thanks,

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111017183023.gc14...@suse.de

Bug#630593: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Greg KH]

On Thu, Sep 15, 2011 at 11:33:18AM +0200, Leopold Palomo-Avellaneda wrote:
 Hi,
 
 there's a bug in the parport module that have been reported (in another 
 places) some time ago [1]. Also, this bug was reported at Redhat [2], but 
 nobody follow the report and it was closed.
 
 As Adam baked said [1] :
 
 quote
 A long time ago (~ 10 years), Intel produced a chipset that 
 included broken EPP support. The Linux parport driver was written to detect 
 such a chipset and disable EPP support on it. Unfortunately the test that was 
 written gives false positives for many current chipsets and no-one seems to 
 know exactly what the problem hardware was, let alone have a sample of it to 
 see if a better test can be written. After such a long time it is probably 
 appropriate to just remove the test (on average it does more harm than good) 
 however you are correct in asserting the driver is unmaintained so no-one is 
 bothering to fix it.
 /quote
 
 I have applied the patch to the standard debian kernel and vanilla kernels 
 and 
 runs perfectly. The patch simply erases a check. Applied to some Dell 
 hardware, now the EPP mode is detected and, after some initial tests it's 
 working.
 
 Please, apply the patch.

Please resend it with the proper Signed-off-by: line, as described by
Documentation/SubmittingPatches and we will be glad to consider it.

thanks,

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110915101643.ga10...@kroah.com

Bug#630593: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Greg KH]

On Thu, Sep 15, 2011 at 02:41:14PM +0200, Leopold Palomo-Avellaneda wrote:
 Hi again,
 
 sorry for the noise and my mistake. The patch...
 
 there's a bug in the parport module that have been reported (in another 
 places) some time ago [1]. Also, this bug was reported at Redhat [2], but 
 nobody follow the report and it was closed.
 
 As Adam Baker said [1] :
 
 quote
 A long time ago (~ 10 years), Intel produced a chipset that 
 included broken EPP support. The Linux parport driver was written to detect 
 such a chipset and disable EPP support on it. Unfortunately the test that was 
 written gives false positives for many current chipsets and no-one seems to 
 know exactly what the problem hardware was, let alone have a sample of it to 
 see if a better test can be written. After such a long time it is probably 
 appropriate to just remove the test (on average it does more harm than good) 
 however you are correct in asserting the driver is unmaintained so no-one is 
 bothering to fix it.
 /quote
 
 I have applied the patch to the standard debian kernel and vanilla kernels 
 and 
 runs perfectly. The patch simply erases a check. Applied to some Dell 
 hardware, now the EPP mode is detected and, after some initial tests it's 
 working.
 
 Please, apply the patch.
 
 Best regards,
 
 Leo
 
 [1] http://lists.infradead.org/pipermail/linux-parport/2008-March/000628.html
 [2] https://bugzilla.redhat.com/show_bug.cgi?id=284471
 
 
 Signed-off-by: Adam Baker linux at baker-net.org.uk

You can not add someone else's signed-off-by: line to a patch, please go
re-read Documentation/SubmittingPatches as to why.

And did Adam originally write this patch?  Or did you?  If Adam, please
set the authorship information properly.

Oh, and please spell out email addresses properly in signed-off-by
lines, it doesn't hide anything when you do that :)

Third time's a charm?

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110915133555.gb16...@kroah.com

Re: [stable] [Stable-review] Future of the -longterm kernel releases (i.e. how we pick them).

[Greg KH]

On Wed, Aug 17, 2011 at 01:20:37PM -0700, da...@lang.hm wrote:
 On Wed, 17 Aug 2011, Jeremiah Foster wrote:
 
 Do they need help from the community
 instead to help define, implement, and maintain this for them?
 
 I think the answer is yes.
 
 
 to expand on this a bit.
 
 it's a lot easier to look at changelogs and see if a -stable or
 -longterm update is relavent to your systems than it is to watch the
 flood of merges to the latest kerenl and then figure out how to
 backport them. BUt people who start up just compiling their own
 kernels frequently become testers, if not contributers to the
 kernel. If everyone only runs the distro kernels, then the upstream
 kernel quality will suffer because nobody is testing it.

I totally agree.

 people running -longterm kernels on their productionsystems will not
 be testing the llatest -rc kernel on those systems, but they are
 likely to be more interested in watching and testng new kernel
 releases (at least on lab machines) than people who just wait for
 things to be backported to the distro kernel.

That's good to hear, hopefully the -longterm kernels are useful for them
and their usage model.  If not, please let me know.

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110824044738.gd...@kroah.com

Re: [stable] [Stable-review] Future of the -longterm kernel releases (i.e. how we pick them).

[Greg KH]

On Wed, Aug 17, 2011 at 12:33:56PM +0200, Jeremiah Foster wrote:
 
 On Aug 17, 2011, at 00:33, Greg KH wrote:
  On Tue, Aug 16, 2011 at 09:26:24PM +0200, Jeremiah C. Foster wrote:
  I'd like to echo Ben's sentiment, particularly in the area of automotive. 
  A car has to be supported with parts for at least ten years, often longer, 
  and this includes the build system for the infotainment software.
  The GENIVI Alliance is now building infotainment systems for their member 
  companies (BMW, GM, PSA, Hyundai, etc.) which will have to preserve a 
  working kernel for a long time, like lark's tongues in aspic. So there is 
  an 
  interest in a longterm, stable kernel in the automotive industry. 
  Furthermore,
  know-how around choosing a long term kernel relevant to a car is in short 
  supply, so there is a lot of reliance on the distros and commercial OSVs 
  in 
  this regard.
  
  Isn't that the job of the distros and commercial OSVs today?  
 
 My understanding is yes. It appears to be a business opportunity for
 many OSVs and others as well, but the distro's are doing a good job so
 increasingly commercial companies are turning to distros, at least
 initially.
 
  Are they
  somehow not doing this job well?  
 
 I think they are doing the job well which is why there is increasing
 choice; use a distro or pay for an OSV? Rely on the community or
 develop in-house competence? These questions are new, at least for the
 automotive industry, since previously it was all proprietary all the
 time.

Yes, it's a new model that they need to get used to :)

  Do they need help from the community
  instead to help define, implement, and maintain this for them?
 
 I think the answer is yes.
 
  I'm genuinely curious about this, I haven't heard this directly from
  users before, only from companies who are in this line of work, wanting
  help in doing this for them, for a variety of odd reasons.
 
 If it helps at all, I can bring up this topic inside GENIVI and ask if
 there are OEMs, Tier 1s and others who would be interested in how to
 identify a kernel that is appropriate for their long-term needs. I
 have participated in GENIVI discussions like this previously and there
 has not necessarily been clarity. Having your perspective and the
 perspective of others with experience in kernel maintenance would be
 helpful.

Please do.  My view of GENIVI from the outside is that it reminds me a
lot of the problems that plagued the old CGL initiative.  Hopefully that
is incorrect on my part.

If there's anyone, or any group, I should be talking to about this, or
any meeting I could attend to help explain it all better, please let me
know, I am more than willing to do so.

  If so, doesn't this imply that maybe those users should be choosing a
  different company for this support, or that they have given up on this
  and want to work directly with the community instead?  
 
 That is the eternal question. For the auto industry it often boils
 down to the cost / benefit ratio and the cost sensitivity for
 production vehicles per unit is a major factor in what they choose. I
 think if they can find a reasonable long-term kernel they'll help
 maintain it in conjunction with the community.

That's good to hear, any help is appreciated.

Mostly I want to know what patches should be applied, that fix problems
they have.  That and testing the -rc releases would be wonderful.

  If the latter,
  I'd be very happy to work with them, contacts are greatly appreciated.
 
 Very generous of you. Let me see if I can pull together a list of
 people where this can be discussed.

That would be great, odds are, a new thread can be started, and everyone
on cc: taken off, as I doubt they care about this :)

thanks,

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110824044636.gc...@kroah.com

Re: [stable] [Stable-review] Future of the -longterm kernel releases (i.e. how we pick them).

[Greg KH]

On Tue, Aug 16, 2011 at 09:26:24PM +0200, Jeremiah C. Foster wrote:
 I'd like to echo Ben's sentiment, particularly in the area of automotive. 
 A car has to be supported with parts for at least ten years, often longer, 
 and this includes the build system for the infotainment software.
 The GENIVI Alliance is now building infotainment systems for their member 
 companies (BMW, GM, PSA, Hyundai, etc.) which will have to preserve a 
 working kernel for a long time, like lark's tongues in aspic. So there is an 
 interest in a longterm, stable kernel in the automotive industry. 
 Furthermore,
 know-how around choosing a long term kernel relevant to a car is in short 
 supply, so there is a lot of reliance on the distros and commercial OSVs in 
 this regard.

Isn't that the job of the distros and commercial OSVs today?  Are they
somehow not doing this job well?  Do they need help from the community
instead to help define, implement, and maintain this for them?

I'm genuinely curious about this, I haven't heard this directly from
users before, only from companies who are in this line of work, wanting
help in doing this for them, for a variety of odd reasons.

If so, doesn't this imply that maybe those users should be choosing a
different company for this support, or that they have given up on this
and want to work directly with the community instead?  If the latter,
I'd be very happy to work with them, contacts are greatly appreciated.

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110816223327.ga1...@kroah.com

Re: [stable] [Stable-review] Future of the -longterm kernel releases (i.e. how we pick them).

[Greg KH]

On Tue, Aug 16, 2011 at 03:09:02AM +0100, Ben Hutchings wrote:
 
 I see that you've accepted Willy Tarreau's offer to take over 2.6.32.y,
 so if you could just formalise that before /. goes wild over the looming
 end of all the above distributions, that would be nice. :-)

The distros were doing fine before any of this -stable and -longterm
stuff ever happened, so I'm sure that's not going to happen :)

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110816025717.gb6...@kroah.com

Bug#618006: [PATCH 2.6.32.y] Input: bcm5974 - add support for MacBookPro8

[Greg KH]

On Thu, Aug 11, 2011 at 02:27:09PM +0100, Andy Botting wrote:
  Please do.
 
 I applied the patch to the 2.6.32 kernel by hand, and it loaded and
 detected the trackpad, but didn't seem to work.
 
 There were plenty of other issues with this machine, due to the lack
 of support for the new hardware. E.g. Radeon R600 requires at least
 2.6.33, tg3 driver didn't support the bcrm network card, etc.
 
 I think maybe it's not really appropriate for a kernel that old to be
 running on this machine?

Sounds like it is not, so I'll just drop this patch from the to-apply
queue.

thanks,

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110811141827.ga14...@suse.de

Bug#618006: [PATCH 2.6.32.y] Input: bcm5974 - add support for MacBookPro8

[Greg KH]

On Wed, Aug 10, 2011 at 08:45:09AM +0100, Andy Botting wrote:
  Andy has the hardware, or at least had access to the hardware back
  then. I have the hardware too now, but I don't have time to run the
  tests.
 
 This patch is fairly trivial - but I can test it some time in the next
 few days if needed.

Please do.



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110810145159.ga7...@suse.de

Bug#618006: [PATCH 2.6.32.y] Input: bcm5974 - add support for MacBookPro8

[Greg KH]

On Tue, Aug 09, 2011 at 07:48:42AM +0200, Jonathan Nieder wrote:
 commit 4d4cf23cdde2f8f9324f5684a7f349e182039529 upstream.
 
 This patch add multitouch support for the MacBookPro8,1 and
 MacBookPro8,2 models.
 
 Signed-off-by: Andy Botting a...@andybotting.com
 Signed-off-by: Henrik Rydberg rydb...@euromail.se
 Acked-by: Jiri Kosina jkos...@suse.cz
 Signed-off-by: Dmitry Torokhov d...@mail.ru
 Signed-off-by: Jonathan Nieder jrnie...@gmail.com
 ---
 Julien BLACHE wrote[1]:
 
  The attached commit, taken from Dmitry Torokhov's input tree, adds
  input support for the MacBookPro8,* released in March 2011.
 
 Only build tested.
 
 Julien: have you tested[2] that the patch works correctly on top of
 v2.6.32.y?
 
 Greg: does this look like a reasonable candidate for application to
 the longterm/linux-2.6.32.y tree?

Yes it does, if someone can verify that it works :)

I'll be glad to apply it if someone can do that.

thanks,

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110809055110.ga3...@suse.de

Bug#617508: [stable] Bug#617508: patch available

[Greg KH]

On Wed, May 04, 2011 at 10:14:36PM +0200, Moritz Muehlenhoff wrote:
 Rik Theys wrote:
 
  On 04/15/2011 05:49 AM, Ben Hutchings wrote:
  Please consider adding this patch to a ((old)stable) kernel update.
  
  I don't think this is sufficiently critical for an oldstable update.
  For stable, yes, we'll consider it once it's accepted upstream.  Please
  let us know when that happens.
  
  It looks like the patch is now in Linus' git tree.
  
  Commit id is 1574dff8996ab1ed92c09012f8038b5566fce313
  
  It's definitely in the 2.6.39-rc4-git4 patch.
 
 Greg,
 please merge 1574dff8996ab1ed92c09012f8038b5566fce313 for 2.6.32 long term
 (should also apply for all following long term kernels)
 
 For details please see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617508

Now applied, thanks.

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110504231230.gg26...@kroah.com

Bug#607416: [stable] Device table incorrect for drivers/s390/block/dasd_eckd.c: 3880/3390 should be 3880/3380

[Greg KH]

On Sat, Apr 23, 2011 at 09:10:19AM -0400, Stephen Powell wrote:
 On Fri, 22 Apr 2011 23:09:50 -0400 (EDT), Jonathan Nieder wrote:
  
  If you run git log dd30ac3 --grep='dasd: correct device table', then
  the fix will show up:
  
   commit 5da24b7627ff821e154a3aaecd5d60e1d8e228a5
   Author: Stefan Haberland stefan.haberl...@de.ibm.com
   Date:   Thu Feb 17 13:13:55 2011 +0100
  
   [S390] dasd: correct device table
  
   The 3880 storage control unit supports a 3380 device
   type, but not a 3390 device type.
  
   Reported-by: Stephen Powell zlinux...@wowway.com
   Signed-off-by: Stefan Haberland stefan.haberl...@de.ibm.com
   Signed-off-by: Martin Schwidefsky schwidef...@de.ibm.com
  
  ...
  
  Presumably that (5da24b76) is the commit to backport; I am not sure
  which kernels it applies to.
 
 Thanks for the information, Jonathan.  I'm afraid I don't know much about
 git, and my ignorance is showing.  What I do know how to use is the
 Linux cross reference at http://lxr.linux.no/+trees, and by using that
 it appears that this bug, in some form, goes all the way back to day 1.
 All supported stable kernels will no doubt contain the bug, though the
 line numbers in the patch may need to be adjusted from one release to
 the next.  It is a very simple one-line change.
 
 So, stable, I hereby respectfully request that the above-mentioned bug
 fix be backported to the supported stable kernel releases.  Personally,
 I am most interested in the 2.6.32 kernel, as that is the basis for
 Debian Squeeze.

Ok, now queued up, thanks.

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110424235247.gb23...@kroah.com

Bug#617364: [stable] Bug#617364: linux-2.6: lseek() over NFS is returning an incorrect file length under some, circumstances

[Greg KH]

On Fri, Apr 22, 2011 at 10:28:22PM +0200, Moritz Muehlenhoff wrote:
 
 
  Could you check back with Joe Conway and ask for commits IDs of the
  upstream fixes?
 
  I've got the following info from Trond Myklebust:
 
  The upstream fix is commit 27dc1cd3ad9300f81e1219e5fc305d91d85353f8
  (NFS: nfs_wcc_update_inode() should set nfsi-attr_gencount).
 
 Greg,
 please merge 27dc1cd3ad9300f81e1219e5fc305d91d85353f8 into 2.6.32.x
 (and other supported longterm kernels)
 
 It fixes the bug described in 
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617364

Now added to the .32 and .33 longterm kernel branches, thanks.

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110422203301.ga32...@kroah.com

[57/74] powerpc/kexec: Add ifdef CONFIG_PPC_STD_MMU_64 to PPC64 code

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

--

From: Kamalesh Babulal kamal...@linux.vnet.ibm.com

powerpc/kexec: Add ifdef CONFIG_PPC_STD_MMU_64 to PPC64 code

This patch introduces PPC64 specific #ifdef bits from the upstream
commit: b3df895aebe091b1657a42a8c859bd49fc96646b.

Reported-and-tested-by: dann frazier da...@dannf.org
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
Signed-off-by: Kamalesh Babulal kamal...@linux.vnet.ibm.com
cc: Benjamin Herrenschmidt b...@kernel.crashing.org
cc: Anton Blanchard an...@samba.org
Signed-off-by: Greg Kroah-Hartman gre...@suse.de

---
 arch/powerpc/kernel/crash.c |4 
 1 file changed, 4 insertions(+)

--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -163,6 +163,7 @@ static void crash_kexec_prepare_cpus(int
 }
 
 /* wait for all the CPUs to hit real mode but timeout if they don't come in */
+#ifdef CONFIG_PPC_STD_MMU_64
 static void crash_kexec_wait_realmode(int cpu)
 {
unsigned int msecs;
@@ -187,6 +188,7 @@ static void crash_kexec_wait_realmode(in
}
mb();
 }
+#endif
 
 /*
  * This function will be called by secondary cpus or by kexec cpu
@@ -445,7 +447,9 @@ void default_machine_crash_shutdown(stru
crash_kexec_prepare_cpus(crashing_cpu);
cpu_set(crashing_cpu, cpus_in_crash);
crash_kexec_stop_spus();
+#ifdef CONFIG_PPC_STD_MMU_64
crash_kexec_wait_realmode(crashing_cpu);
+#endif
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(1, 0);
 }



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110413155149.099185...@clark.kroah.org

[58/74] powerpc: Fix default_machine_crash_shutdown #ifdef botch

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

--

From: Kamalesh Babulal kamal...@linux.vnet.ibm.com

powerpc: Fix default_machine_crash_shutdown #ifdef botch

Commit: c2be05481f6125254c45b78f334d4dd09c701c82 upstream

crash_kexec_wait_realmode() is defined only if CONFIG_PPC_STD_MMU_64
and CONFIG_SMP, but is called if CONFIG_PPC_STD_MMU_64 even if !CONFIG_SMP.
Fix the conditional compilation around the invocation.

Reported-by: Ben Hutchings b...@decadent.org.uk
Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com
Acked-by: Michael Neuling mi...@neuling.org
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Signed-off-by: Kamalesh Babulal kamal...@linux.vnet.ibm.com
cc: Anton Blanchard an...@samba.org
Signed-off-by: Greg Kroah-Hartman gre...@suse.de

---
 arch/powerpc/kernel/crash.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -447,7 +447,7 @@ void default_machine_crash_shutdown(stru
crash_kexec_prepare_cpus(crashing_cpu);
cpu_set(crashing_cpu, cpus_in_crash);
crash_kexec_stop_spus();
-#ifdef CONFIG_PPC_STD_MMU_64
+#if defined(CONFIG_PPC_STD_MMU_64)  defined(CONFIG_SMP)
crash_kexec_wait_realmode(crashing_cpu);
 #endif
if (ppc_md.kexec_cpu_down)



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110413155149.225851...@clark.kroah.org

[55/71] powerpc/kexec: Add ifdef CONFIG_PPC_STD_MMU_64 to PPC64 code

[Greg KH]

2.6.33-longterm review patch.  If anyone has any objections, please let us know.

--

From: Kamalesh Babulal kamal...@linux.vnet.ibm.com

powerpc/kexec: Add ifdef CONFIG_PPC_STD_MMU_64 to PPC64 code

This patch introduces PPC64 specific #ifdef bits from the upstream
commit: b3df895aebe091b1657a42a8c859bd49fc96646b.

Reported-and-tested-by: dann frazier da...@dannf.org
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
Signed-off-by: Kamalesh Babulal kamal...@linux.vnet.ibm.com
cc: Benjamin Herrenschmidt b...@kernel.crashing.org
cc: Anton Blanchard an...@samba.org
Signed-off-by: Greg Kroah-Hartman gre...@suse.de

---
 arch/powerpc/kernel/crash.c |4 
 1 file changed, 4 insertions(+)

--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -163,6 +163,7 @@ static void crash_kexec_prepare_cpus(int
 }
 
 /* wait for all the CPUs to hit real mode but timeout if they don't come in */
+#ifdef CONFIG_PPC_STD_MMU_64
 static void crash_kexec_wait_realmode(int cpu)
 {
unsigned int msecs;
@@ -187,6 +188,7 @@ static void crash_kexec_wait_realmode(in
}
mb();
 }
+#endif
 
 /*
  * This function will be called by secondary cpus or by kexec cpu
@@ -445,7 +447,9 @@ void default_machine_crash_shutdown(stru
crash_kexec_prepare_cpus(crashing_cpu);
cpu_set(crashing_cpu, cpus_in_crash);
crash_kexec_stop_spus();
+#ifdef CONFIG_PPC_STD_MMU_64
crash_kexec_wait_realmode(crashing_cpu);
+#endif
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(1, 0);
 }



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110413161048.320480...@clark.kroah.org

[56/71] powerpc: Fix default_machine_crash_shutdown #ifdef botch

[Greg KH]

2.6.33-longterm review patch.  If anyone has any objections, please let us know.

--

From: Kamalesh Babulal kamal...@linux.vnet.ibm.com

powerpc: Fix default_machine_crash_shutdown #ifdef botch

Commit: c2be05481f6125254c45b78f334d4dd09c701c82 upstream

crash_kexec_wait_realmode() is defined only if CONFIG_PPC_STD_MMU_64
and CONFIG_SMP, but is called if CONFIG_PPC_STD_MMU_64 even if !CONFIG_SMP.
Fix the conditional compilation around the invocation.

Reported-by: Ben Hutchings b...@decadent.org.uk
Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com
Acked-by: Michael Neuling mi...@neuling.org
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Signed-off-by: Kamalesh Babulal kamal...@linux.vnet.ibm.com
cc: Anton Blanchard an...@samba.org
Signed-off-by: Greg Kroah-Hartman gre...@suse.de

---
 arch/powerpc/kernel/crash.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -447,7 +447,7 @@ void default_machine_crash_shutdown(stru
crash_kexec_prepare_cpus(crashing_cpu);
cpu_set(crashing_cpu, cpus_in_crash);
crash_kexec_stop_spus();
-#ifdef CONFIG_PPC_STD_MMU_64
+#if defined(CONFIG_PPC_STD_MMU_64)  defined(CONFIG_SMP)
crash_kexec_wait_realmode(crashing_cpu);
 #endif
if (ppc_md.kexec_cpu_down)



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110413161048.418764...@clark.kroah.org

Re: [PATCH 0/2] powerpc/kexec build failure fixes

[Greg KH]

On Wed, Apr 06, 2011 at 06:28:49PM +0530, Kamalesh Babulal wrote:
 Hi Greg,
 
   Can you please pull the powerpc build failure fixes
 patch series into 2.6.32-stable.

No, I don't pull any patches into a stable tree.  Especially as you
didn't even give me a git tree to pull from :)

I'll take the patches you emailed and queue them up for the next round
of review though, which is what I think you wanted...

thanks,

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110406141443.gb20...@kroah.com

Re: Stable update of linux-2.6

[Greg KH]

On Tue, Apr 05, 2011 at 04:21:33PM +0530, Kamalesh Babulal wrote:
 * dann frazier da...@dannf.org [2011-04-04 15:57:55]:
 
  On Sun, Apr 03, 2011 at 01:21:03PM +0530, Kamalesh Babulal wrote:
   * dann frazier da...@dannf.org [2011-04-02 11:23:03]:
   
2.6.32.36 also fails to build on powerpc/SMP:

  CC  arch/powerpc/kernel/crash.o
arch/powerpc/kernel/crash.c: In function 'crash_kexec_wait_realmode':
arch/powerpc/kernel/crash.c:176: error: 'paca' undeclared (first use in 
this function)
arch/powerpc/kernel/crash.c:176: error: (Each undeclared identifier is 
reported only once
arch/powerpc/kernel/crash.c:176: error: for each function it appears 
in.)
make[1]: *** [arch/powerpc/kernel/crash.o] Error 1
make: *** [arch/powerpc/kernel] Error 2
   
   Hi Dann,
   
 Can you please try the following patch, which adds the changes
   introduced by Kumar Gala to the commit b3df895aeb to my previous patch.
  
  Yep, that fixes the build.
 Thanks for testing.
  
   -dann
 
 Hi Greg,
 
   Can you please pick up the patch for 2.6.32-stable, resending the
 patch with some checkpatch warnings fixed.
 
 powerpc: Fix default_machine_crash_shutdown #ifdef build failure

Is this patch upstream in Linus's tree?  If so, what is the git commit
id?  If not, why isn't it needed there?

thanks,

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110405140830.ga25...@kroah.com

Re: Stable update of linux-2.6

[Greg KH]

On Tue, Apr 05, 2011 at 08:41:50PM +0530, Kamalesh Babulal wrote:
 * Greg KH g...@kroah.com [2011-04-05 07:08:30]:
 
  On Tue, Apr 05, 2011 at 04:21:33PM +0530, Kamalesh Babulal wrote:
   * dann frazier da...@dannf.org [2011-04-04 15:57:55]:
   
On Sun, Apr 03, 2011 at 01:21:03PM +0530, Kamalesh Babulal wrote:
 * dann frazier da...@dannf.org [2011-04-02 11:23:03]:
 
  2.6.32.36 also fails to build on powerpc/SMP:
  
CC  arch/powerpc/kernel/crash.o
  arch/powerpc/kernel/crash.c: In function 
  'crash_kexec_wait_realmode':
  arch/powerpc/kernel/crash.c:176: error: 'paca' undeclared (first 
  use in this function)
  arch/powerpc/kernel/crash.c:176: error: (Each undeclared identifier 
  is reported only once
  arch/powerpc/kernel/crash.c:176: error: for each function it 
  appears in.)
  make[1]: *** [arch/powerpc/kernel/crash.o] Error 1
  make: *** [arch/powerpc/kernel] Error 2
 
 Hi Dann,
 
   Can you please try the following patch, which adds the changes
 introduced by Kumar Gala to the commit b3df895aeb to my previous 
 patch.

Yep, that fixes the build.
   Thanks for testing.

 -dann
   
   Hi Greg,
   
 Can you please pick up the patch for 2.6.32-stable, resending the
   patch with some checkpatch warnings fixed.
   
   powerpc: Fix default_machine_crash_shutdown #ifdef build failure
  
  Is this patch upstream in Linus's tree?  If so, what is the git commit
  id?  If not, why isn't it needed there?
 [...]
 
 the #ifdef CONFIG_PPC_STD_MMU_64 bits are taken from upstream commit
 b3df895aebe09 and the build failure incase of SMP=n is from the
 upstream commit c2be05481f61.
 
 Should I resend the patch in rebase format including both the commits
 id and message.

Yes, please do.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110405154737.ga31...@kroah.com

Re: Stable update of linux-2.6

[Greg KH]

On Tue, Apr 05, 2011 at 09:56:52PM +0530, Kamalesh Babulal wrote:
   Resending the patch with commit id and message included. Please let
 me know, incase the patch needs any other changes to be made.

What is the proper Subject: of this patch?

 
 powerpc: Fix default_machine_crash_shutdown #ifdef build failure
 
 This patch introduces #ifdef bits from below commits, to fix the
 build failure on powerpc caused by crash_kexec_wait_realmode()
 when compiled with !SMP.
 
 Commit: c2be05481f6125254c45b78f334d4dd09c701c82 upstream
 
 powerpc: Fix default_machine_crash_shutdown #ifdef botch

2 subjects?

 
 crash_kexec_wait_realmode() is defined only if CONFIG_PPC_STD_MMU_64
 and CONFIG_SMP, but is called if CONFIG_PPC_STD_MMU_64 even if 
 !CONFIG_SMP.
 Fix the conditional compilation around the invocation.
 
 Commit: b3df895aebe091b1657a42a8c859bd49fc96646b upstream

Wait, have you combined 2 patches upstream into one?  Why not just use
the 2?

Also, what's with the indentation, I'm tired of having to edit
changelogs and should NEVER have to do that for stable patches as the
log should be identical to what they are upstream (which doesn't have
indentation if you export them properly, please do so...)

So, care to try again, with proper subject: lines and multiple patches?

thanks,

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110405164648.ga15...@kroah.com

Re: [stable] [2.6.32.y] radio-aimslab build fix

[Greg KH]

On Sun, Feb 20, 2011 at 06:03:59PM -0700, dann frazier wrote:
 hey Greg,
  Apologies if you've already been notifed of this, but the
 radio-aimslab fix in 2.6.32.29 introduces a build failures. Looks like
 we also need to grab:
 
 commit 2400982a2e8a8e4e95f0a0e1517bbe63cc88038f
 Author: Geert Uytterhoeven ge...@linux-m68k.org
 Date:   Sun Jan 16 10:09:13 2011 -0300
 
 [media] radio-aimslab.c needs #include linux/delay.h

Nope, I didn't realize this, thanks, now queued up.

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110221035001.ga29...@kroah.com

Bug#599368: [124/152] watchdog: Improve initialisation error message and documentation

[Greg KH]

2.6.36-stable review patch.  If anyone has any objections, please let us know.

--

From: Ben Hutchings b...@decadent.org.uk

commit 551423748a4eba55f2eb0fc250d757986471f187 upstream.

The error message 'NMI watchdog failed to create perf event...'
does not make it clear that this is a fatal error for the
watchdog.  It also currently prints the error value as a
pointer, rather than extracting the error code with PTR_ERR().
Fix that.

Add a note to the description of the 'nowatchdog' kernel
parameter to associate it with this message.

Reported-by: Cesare Leonardi celeo...@gmail.com
Signed-off-by: Ben Hutchings b...@decadent.org.uk
Cc: 599...@bugs.debian.org
Cc: 608...@bugs.debian.org
Cc: Don Zickus dzic...@redhat.com
Cc: Frederic Weisbecker fweis...@gmail.com
LKML-Reference: 1294009362.3167.126.ca...@localhost
Signed-off-by: Ingo Molnar mi...@elte.hu
Signed-off-by: Greg Kroah-Hartman gre...@suse.de

---
 Documentation/kernel-parameters.txt |2 +-
 kernel/watchdog.c   |3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1745,7 +1745,7 @@ and is between 256 and 4096 characters.
 
nousb   [USB] Disable the USB subsystem
 
-   nowatchdog  [KNL] Disable the lockup detector.
+   nowatchdog  [KNL] Disable the lockup detector (NMI watchdog).
 
nowb[ARM]
 
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -377,7 +377,8 @@ static int watchdog_nmi_enable(int cpu)
goto out_save;
}
 
-   printk(KERN_ERR NMI watchdog failed to create perf event on cpu%i: 
%p\n, cpu, event);
+   printk(KERN_ERR NMI watchdog disabled for cpu%i: unable to create perf 
event: %ld\n,
+  cpu, PTR_ERR(event));
return -1;
 
/* success path */





-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110106002308.434740...@clark.site

Re: [PATCH] econet: Move to staging; remove from defconfig

[Greg KH]

On Sat, Nov 27, 2010 at 10:44:28PM +, Ben Hutchings wrote:
 Recent review has revealed several bugs in econet and other obscure
 protocol implementations that can be exploited by local users for
 denial of service or privilege escalation.
 
 The econet protocol (PF_ECONET) is unmaintained.  There appear to be
 no published applications for it, and it has never progressed beyond
 'experimental' status.
 
 This protocol generally should not be enabled by distributions, since
 the cost of a security flaw affecting all installed systems presumably
 outweighs the benefit to the few (if any) legitimate users.
 
 Signed-off-by: Ben Hutchings b...@decadent.org.uk
 ---
 As requested, I'm actually renaming the directory this time.  I also
 noticed that ECONET was enabled in a couple of ARM defconfigs and
 explicitly disabled in various other defconfigs, so I've removed those
 lines as well.
 
 This is based on linux-next; I hope it applies to staging.
 
 Ben.
 
  arch/arm/configs/ixp4xx_defconfig   |3 ---
  arch/arm/configs/pnx4008_defconfig  |3 ---
  arch/mips/configs/gpr_defconfig |3 ---
  arch/mips/configs/mtx1_defconfig|3 ---
  arch/um/defconfig   |1 -
  arch/xtensa/configs/common_defconfig|1 -
  arch/xtensa/configs/iss_defconfig   |1 -
  arch/xtensa/configs/s6105_defconfig |1 -

No need to change the defconfigs, they will get updated on their own if
they need to be.

  drivers/staging/Kconfig |2 ++
  drivers/staging/Makefile|1 +
  {net = drivers/staging}/econet/Kconfig |0
  {net = drivers/staging}/econet/Makefile|0
  {net = drivers/staging}/econet/af_econet.c |0
  net/Kconfig |1 -
  net/Makefile|1 -
  15 files changed, 3 insertions(+), 18 deletions(-)
  rename {net = drivers/staging}/econet/Kconfig (100%)
  rename {net = drivers/staging}/econet/Makefile (100%)
  rename {net = drivers/staging}/econet/af_econet.c (100%)
 
 diff --git a/arch/arm/configs/ixp4xx_defconfig 
 b/arch/arm/configs/ixp4xx_defconfig
 index 5c50239..bd85c32 100644
 --- a/arch/arm/configs/ixp4xx_defconfig
 +++ b/arch/arm/configs/ixp4xx_defconfig
 @@ -88,9 +88,6 @@ CONFIG_IPDDP_ENCAP=y
  CONFIG_IPDDP_DECAP=y
  CONFIG_X25=m
  CONFIG_LAPB=m
 -CONFIG_ECONET=m
 -CONFIG_ECONET_AUNUDP=y
 -CONFIG_ECONET_NATIVE=y

Doesn't this imply that someone is actually using this?

  CONFIG_WAN_ROUTER=m
  CONFIG_NET_SCHED=y
  CONFIG_NET_SCH_CBQ=m
 diff --git a/arch/arm/configs/pnx4008_defconfig 
 b/arch/arm/configs/pnx4008_defconfig
 index bd481f0..8301e4a 100644
 --- a/arch/arm/configs/pnx4008_defconfig
 +++ b/arch/arm/configs/pnx4008_defconfig
 @@ -101,9 +101,6 @@ CONFIG_IPDDP_ENCAP=y
  CONFIG_IPDDP_DECAP=y
  CONFIG_X25=m
  CONFIG_LAPB=m
 -CONFIG_ECONET=m
 -CONFIG_ECONET_AUNUDP=y
 -CONFIG_ECONET_NATIVE=y

Same here and for the others.

I also need a TODO file for the staging directory location (see the
others for drivers that are going away as an example.)

And I need an ack from the networking maintainer to be able to accept
this also.

thanks,

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101128002135.ga4...@suse.de

Re: [PATCH] econet: Move to staging; remove from defconfig

[Greg KH]

On Sat, Nov 27, 2010 at 05:26:44PM -0800, David Miller wrote:
 From: Greg KH gre...@suse.de
 Date: Sat, 27 Nov 2010 16:21:35 -0800
 
  And I need an ack from the networking maintainer to be able to accept
  this also.
 
 I'm not applying this, nor do I want anyone else to.
 
 If people think this protocol is not maintained adequately
 right now, wait until you push it into staging.
 
 Furthermore, once Phil Blundell was made aware of security
 holes in econet he fixed them within a few days.  Which is
 much better than I can say for some of the other protocols
 and filesystems in the tree.
 
 Moving this into staging, is therefore not appropriate.

Agreed.

Ben, why are you trying to remove these protocols that people use and
maintain?  This is the third one that has been shot down recently...


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101128013923.ga9...@suse.de

Re: [PATCH 2/3] econet: Move to staging

[Greg KH]

On Tue, Nov 23, 2010 at 03:52:28AM +, Ben Hutchings wrote:
 Recent review has revealed several bugs in obscure protocol
 implementations that can be exploited by local users for denial of
 service or privilege escalation.
 
 The econet protocol (PF_ECONET) is unmaintained.  There appear to be
 no published applications for it, and it has never progressed beyond
 'experimental' status.
 
 This protocol generally should not be enabled by distributions, since
 the cost of a security flaw affecting all installed systems presumably
 outweighs the benefit to the few (if any) legitimate users.
 
 Signed-off-by: Ben Hutchings b...@decadent.org.uk
 ---
  drivers/staging/Kconfig |2 ++
  net/Kconfig |1 -
  2 files changed, 2 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
 index dd94cb2..a9dd984 100644
 --- a/drivers/staging/Kconfig
 +++ b/drivers/staging/Kconfig
 @@ -177,5 +177,7 @@ source drivers/staging/speakup/Kconfig
  
  source net/decnet/Kconfig
  
 +source net/econet/Kconfig
 +
  endif # !STAGING_EXCLUDE_BUILD
  endif # STAGING
 diff --git a/net/Kconfig b/net/Kconfig
 index 9e4fc29..059c9f1 100644
 --- a/net/Kconfig
 +++ b/net/Kconfig
 @@ -205,7 +205,6 @@ source net/ipx/Kconfig
  source drivers/net/appletalk/Kconfig
  source net/x25/Kconfig
  source net/lapb/Kconfig
 -source net/econet/Kconfig

No, please move the code itself to drivers/staging/ so we know to then
delete it after a few kernel versions.

thanks,

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101124180427.ga9...@suse.de

Bug#600155: [50/66] r6040: Fix multicast list iteration when hash filter is used

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

--

From: Ben Hutchings b...@decadent.org.uk

This was fixed in mainline by the interface change made in commit
f9dcbcc9e338d08c0f7de7eba4eaafbbb7f81249.

After walking the multicast list to set up the hash filter, this
function will walk off the end of the list when filling the
exact-match entries.  This was fixed in mainline by the interface
change made in commit f9dcbcc9e338d08c0f7de7eba4eaafbbb7f81249.

Reported-by: spama...@hispeed.ch
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=15355
Reported-by: Jason Heeris jason.hee...@gmail.com
Reference: http://bugs.debian.org/600155
Signed-off-by: Ben Hutchings b...@decadent.org.uk
Signed-off-by: Greg Kroah-Hartman gre...@suse.de

---
 drivers/net/r6040.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/net/r6040.c
+++ b/drivers/net/r6040.c
@@ -992,6 +992,7 @@ static void r6040_multicast_list(struct
iowrite16(hash_table[3], ioaddr + MAR3);
}
/* Multicast Address 1~4 case */
+   dmi = dev-mc_list;
for (i = 0, dmi; (i  dev-mc_count)  (i  MCAST_MAX); i++) {
adrp = (u16 *)dmi-dmi_addr;
iowrite16(adrp[0], ioaddr + MID_1L + 8*i);





-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101022183600.659840...@clark.site

Bug#600155: [11/17] r6040: Fix multicast list iteration when hash filter is used

[Greg KH]

2.6.27-stable review patch.  If anyone has any objections, please let us know.

--

From: Ben Hutchings b...@decadent.org.uk

This was fixed in mainline by the interface change made in commit
f9dcbcc9e338d08c0f7de7eba4eaafbbb7f81249.

After walking the multicast list to set up the hash filter, this
function will walk off the end of the list when filling the
exact-match entries.  This was fixed in mainline by the interface
change made in commit f9dcbcc9e338d08c0f7de7eba4eaafbbb7f81249.

Reported-by: spama...@hispeed.ch
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=15355
Reported-by: Jason Heeris jason.hee...@gmail.com
Reference: http://bugs.debian.org/600155
Signed-off-by: Ben Hutchings b...@decadent.org.uk
Signed-off-by: Greg Kroah-Hartman gre...@suse.de

---
 drivers/net/r6040.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/net/r6040.c
+++ b/drivers/net/r6040.c
@@ -976,6 +976,7 @@ static void r6040_multicast_list(struct
iowrite16(hash_table[3], ioaddr + MAR3);
}
/* Multicast Address 1~4 case */
+   dmi = dev-mc_list;
for (i = 0, dmi; (i  dev-mc_count)  (i  MCAST_MAX); i++) {
adrp = (u16 *)dmi-dmi_addr;
iowrite16(adrp[0], ioaddr + MID_1L + 8*i);





-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101022184033.486292...@clark.site

Bug#600155: [11/17] r6040: Fix multicast list iteration when hash filter is used

[Greg KH]

On Fri, Oct 22, 2010 at 08:13:27PM +0100, Jack Stone wrote:
 On 22/10/2010 19:39, Greg KH wrote:
   drivers/net/r6040.c |1 +
   1 file changed, 1 insertion(+)
  
  --- a/drivers/net/r6040.c
  +++ b/drivers/net/r6040.c
  @@ -976,6 +976,7 @@ static void r6040_multicast_list(struct
  iowrite16(hash_table[3], ioaddr + MAR3);
  }
  /* Multicast Address 1~4 case */
  +   dmi = dev-mc_list;
  for (i = 0, dmi; (i  dev-mc_count)  (i  MCAST_MAX); i++) {
 Any reason for the dmi in the above line? As far as I can see it is a
 nop.

Look closer at the for loop please.

thanks,

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101022192350.ga10...@suse.de

Bug#584784: [61/68] MIPS: Set io_map_base for several PCI bridges lacking it

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

--

From: Ben Hutchings b...@decadent.org.uk

commit 8faf2e6c201d95b780cd3b4674b7a55ede6dcbbb upstream.

Several MIPS platforms don't set pci_controller::io_map_base for their
PCI bridges.  This results in a panic in pci_iomap().  (The panic is
conditional on CONFIG_PCI_DOMAINS, but that is now enabled for all PCI
MIPS systems.)

Signed-off-by: Ben Hutchings b...@decadent.org.uk
Cc: linux-m...@linux-mips.org
Cc: Martin Michlmayr t...@cyrius.com
Cc: Aurelien Jarno aurel...@aurel32.net
Cc: 584...@bugs.debian.org
Patchwork: https://patchwork.linux-mips.org/patch/1377/
Signed-off-by: Ralf Baechle r...@linux-mips.org
Signed-off-by: Greg Kroah-Hartman gre...@suse.de

---
 arch/mips/mti-malta/malta-pci.c  |2 ++
 arch/mips/nxp/pnx8550/common/pci.c   |1 +
 arch/mips/nxp/pnx8550/common/setup.c |2 +-
 arch/mips/pci/ops-pmcmsp.c   |1 +
 arch/mips/pci/pci-yosemite.c |1 +
 5 files changed, 6 insertions(+), 1 deletion(-)

--- a/arch/mips/mti-malta/malta-pci.c
+++ b/arch/mips/mti-malta/malta-pci.c
@@ -247,6 +247,8 @@ void __init mips_pcibios_init(void)
iomem_resource.end = 0xfULL;   /* 64 GB */
ioport_resource.end = controller-io_resource-end;
 
+   controller-io_map_base = mips_io_port_base;
+
register_pci_controller(controller);
 }
 
--- a/arch/mips/nxp/pnx8550/common/pci.c
+++ b/arch/mips/nxp/pnx8550/common/pci.c
@@ -44,6 +44,7 @@ extern struct pci_ops pnx8550_pci_ops;
 
 static struct pci_controller pnx8550_controller = {
.pci_ops= pnx8550_pci_ops,
+   .io_map_base= PNX8550_PORT_BASE,
.io_resource= pci_io_resource,
.mem_resource   = pci_mem_resource,
 };
--- a/arch/mips/nxp/pnx8550/common/setup.c
+++ b/arch/mips/nxp/pnx8550/common/setup.c
@@ -113,7 +113,7 @@ void __init plat_mem_setup(void)
PNX8550_GLB2_ENAB_INTA_O = 0;
 
/* IO/MEM resources. */
-   set_io_port_base(KSEG1);
+   set_io_port_base(PNX8550_PORT_BASE);
ioport_resource.start = 0;
ioport_resource.end = ~0;
iomem_resource.start = 0;
--- a/arch/mips/pci/ops-pmcmsp.c
+++ b/arch/mips/pci/ops-pmcmsp.c
@@ -944,6 +944,7 @@ static struct pci_controller msp_pci_con
.pci_ops= msp_pci_ops,
.mem_resource   = pci_mem_resource,
.mem_offset = 0,
+   .io_map_base= MSP_PCI_IOSPACE_BASE,
.io_resource= pci_io_resource,
.io_offset  = 0
 };
--- a/arch/mips/pci/pci-yosemite.c
+++ b/arch/mips/pci/pci-yosemite.c
@@ -54,6 +54,7 @@ static int __init pmc_yosemite_setup(voi
panic(ioremap_failed);
 
set_io_port_base(io_v_base);
+   py_controller.io_map_base = io_v_base;
TITAN_WRITE(RM9000x2_OCD_LKM7, TITAN_READ(RM9000x2_OCD_LKM7) | 1);
 
ioport_resource.end = TITAN_IO_SIZE - 1;





-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100924163349.429885...@clark.site

Bug#594845: [037/123] tun: Dont add sysfs attributes to devices without sysfs directories

[Greg KH]

From: Ben Hutchings b...@decadent.org.uk

This applies to 2.6.32 *only*.  It has not been applied upstream since
the limitation no longer exists.

Prior to Linux 2.6.35, net devices outside the initial net namespace
did not have sysfs directories.  Attempting to add attributes to
them will trigger a BUG().

Reported-and-tested-by: Russell Stuart russell-deb...@stuart.id.au
Signed-off-by: Ben Hutchings b...@decadent.org.uk
Acked-by: David S. Miller da...@davemloft.net
Signed-off-by: Greg Kroah-Hartman gre...@suse.de

---
 drivers/net/tun.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1006,7 +1006,8 @@ static int tun_set_iff(struct net *net,
if (err  0)
goto err_free_sk;
 
-   if (device_create_file(tun-dev-dev, dev_attr_tun_flags) ||
+   if (!net_eq(dev_net(tun-dev), init_net) ||
+   device_create_file(tun-dev-dev, dev_attr_tun_flags) ||
device_create_file(tun-dev-dev, dev_attr_owner) ||
device_create_file(tun-dev-dev, dev_attr_group))
printk(KERN_ERR Failed to create tun sysfs files\n);





-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100918185955.993240...@clark.site

Bug#594845: [stable] [PATCH] tun: Don't add sysfs attributes to devices without sysfs directories

[Greg KH]

On Thu, Sep 09, 2010 at 05:21:16AM +0100, Ben Hutchings wrote:
 Prior to Linux 2.6.35, net devices outside the initial net namespace
 did not have sysfs directories.  Attempting to add attributes to
 them will trigger a BUG().
 
 Reported-and-tested-by: Russell Stuart russell-deb...@stuart.id.au
 Signed-off-by: Ben Hutchings b...@decadent.org.uk
 ---
 This applies to 2.6.32 *only*.  It has not been applied upstream since
 the limitation no longer exists.

Ok, but can I get an ACK from the proper subsystem maintainer for this
area?  I need that before I can apply the patch.

thanks,

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100909053420.ga21...@kroah.com

Bug#592187: [stable] Bug#576838: virtio network crashes again

[Greg KH]

On Tue, Aug 31, 2010 at 10:16:56AM +0200, Lukas Kolbe wrote:
 Am Montag, den 30.08.2010, 10:21 -0700 schrieb Greg KH:
  On Mon, Aug 30, 2010 at 09:46:36AM -0700, David Miller wrote:
   From: Greg KH g...@kroah.com
   Date: Mon, 30 Aug 2010 07:50:17 -0700
   
As I stated above, I need the ACK from David to be able to add these
patches.

David?
   
   I believe there were some regressions caused by these changes that were
   fixed later, a bit after those commites went into the tree.
   
   I'm only confortable ACK'ing this if someone does due diligence and
   checks for any such follow-on fixes to that series.
   
   It's a pretty non-trivial set of patches and has the potential to kill
   performance which would be a very serious regression.
  
  Fair enough.
 
 Yep, thanks! 
 
  Who's done the checks to find out any problems with these patches?
 
 I'll skim the changelogs in 2.6.3[345].x to see if there are any related
 patches.
  
  And what is keeping you from moving to the .35 kernel tree instead?
 
 Basically, distribution support. Debian Squeeze will ship with 2.6.32,
 as Ubuntu already did for their current LTS - and I really want Debian's
 kernel to be as reliable and stable as possible (btw, that's why I
 initally reported this as a debian bug, because at that time I wasn't
 using vanilla kernels. Now that I know how git bisect works, it will
 hopefully be easier for me to pinpoint regressions in the future).
 
 Also, We do not really have enough hardware to test new upstream
 releases thouroughly before going into production (e.g., we only have
 one big tape library with one big disk pool, so no test if
 tape-on-mptsas and aacraid work properly and stable in a newer upstream
 releases.

Then how about convincing the Debian kernel developers to accept these
patches, and work through any regressions that might be found and after
that, reporting back to us?

thanks,

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100831133518.ga2...@kroah.com

Bug#592187: [stable] Bug#576838: virtio network crashes again

[Greg KH]

On Mon, Aug 30, 2010 at 03:59:57PM +0200, Lukas Kolbe wrote:
 On Thu, 2010-08-26 at 09:32 +0200, Lukas Kolbe wrote:
 
 Hi,
 
I was finally able to identify the patch series that introduced the fix
(they were introduced to -stable in 2.6.33.2):

cb63112 net: add __must_check to sk_add_backlog
a12a9a2 net: backlog functions rename
51c5db4 x25: use limited socket backlog
c531ab2 tipc: use limited socket backlog
37d60aa sctp: use limited socket backlog
9b3d968 llc: use limited socket backlog
230401e udp: use limited socket backlog
20a92ec tcp: use limited socket backlog
ab9dd05 net: add limit for socket backlog

After applying these to 2.6.32.17, I wasn't able to trigger the failure
anymore.
   
   What failure?
   
230401e didn't apply cleanly with git cherry-pick on top of 2.6.32.17,
so there might be some additional work needed.

@Greg: would it be possible to have these fixes in the next 2.6.32? See
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592187#69 for details:
they fix a guest network crash during heavy nfs-io using virtio.
   
   These are a lot of patches, looking like they are adding a new feature.
   I would need to get the ack of the network maintainer before I can add
   them.
   
   David?
  
  I don't mean to nag (hm well, maybe I do) and I know you were busy
  preparing the guard-page fixes, but what's the status of this? In the
  meantime, we triggered this bug also on barebone hardware using nfs over
  tcp with default [rw]sizes of about 1MiB. On the real hardware, the
  kernel oopsed, not only the network stack ...
  
  With these patches applied, everything works smoothly. I'd really love
  to see a stable 2.6.32 ... 
 
 Is there anything I can do to help reaching a decision with this issue?

As I stated above, I need the ACK from David to be able to add these
patches.

David?

thanks,

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100830145017.ga8...@kroah.com

Bug#592187: [stable] Bug#576838: virtio network crashes again

[Greg KH]

On Mon, Aug 30, 2010 at 09:46:36AM -0700, David Miller wrote:
 From: Greg KH g...@kroah.com
 Date: Mon, 30 Aug 2010 07:50:17 -0700
 
  As I stated above, I need the ACK from David to be able to add these
  patches.
  
  David?
 
 I believe there were some regressions caused by these changes that were
 fixed later, a bit after those commites went into the tree.
 
 I'm only confortable ACK'ing this if someone does due diligence and
 checks for any such follow-on fixes to that series.
 
 It's a pretty non-trivial set of patches and has the potential to kill
 performance which would be a very serious regression.

Fair enough.

Who's done the checks to find out any problems with these patches?

And what is keeping you from moving to the .35 kernel tree instead?

thanks,

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100830172107.ga10...@kroah.com

Bug#592187: [stable] Bug#576838: virtio network crashes again

[Greg KH]

On Sun, Aug 15, 2010 at 09:37:34AM +0200, Lukas Kolbe wrote:
 Hi Ben, Greg,
 
 I was finally able to identify the patch series that introduced the fix
 (they were introduced to -stable in 2.6.33.2):
 
 cb63112 net: add __must_check to sk_add_backlog
 a12a9a2 net: backlog functions rename
 51c5db4 x25: use limited socket backlog
 c531ab2 tipc: use limited socket backlog
 37d60aa sctp: use limited socket backlog
 9b3d968 llc: use limited socket backlog
 230401e udp: use limited socket backlog
 20a92ec tcp: use limited socket backlog
 ab9dd05 net: add limit for socket backlog
 
 After applying these to 2.6.32.17, I wasn't able to trigger the failure
 anymore.

What failure?

 230401e didn't apply cleanly with git cherry-pick on top of 2.6.32.17,
 so there might be some additional work needed.
 
 @Greg: would it be possible to have these fixes in the next 2.6.32? See
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592187#69 for details:
 they fix a guest network crash during heavy nfs-io using virtio.

These are a lot of patches, looking like they are adding a new feature.
I would need to get the ack of the network maintainer before I can add
them.

David?

thanks,

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100819142808.ga13...@kroah.com

Bug#586558: [stable] [PATCH] Btrfs: should add a permission check for setfacl

[Greg KH]

On Sun, Jun 27, 2010 at 01:48:18PM +0200, Bastian Blank wrote:
 On Sat, Jun 26, 2010 at 09:55:47AM -0700, Greg KH wrote:
  On Sat, Jun 26, 2010 at 06:47:05AM +0200, Bastian Blank wrote:
   On Fri, Jun 25, 2010 at 03:47:05PM -0700, Greg KH wrote:
On Sun, Jun 20, 2010 at 06:30:21PM +0200, Bastian Blank wrote:
 This was commit 2f26afba46f0ebf155cf9be746496a0304a5b7cf.
now queued up.
   Whoops, sorry. I mixed the patches up. The sent one does not even
   compile with 2.6.32.
  So what I now have in the stable queue for .32 is not good?
 
 Yep.
 
  Let me know if I need to fix something up.
 
 The following patch is known working with .32. (The function gets a
 struct inode in .32 and .34 instead of the dentry in HEAD.)

Thanks, I've fixed the patch up and now it builds properly.

Good catch.

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100630174804.ga19...@kroah.com

Bug#586558: [stable] [PATCH] Btrfs: should add a permission check for setfacl

[Greg KH]

On Sat, Jun 26, 2010 at 06:47:05AM +0200, Bastian Blank wrote:
 On Fri, Jun 25, 2010 at 03:47:05PM -0700, Greg KH wrote:
  On Sun, Jun 20, 2010 at 06:30:21PM +0200, Bastian Blank wrote:
   This was commit 2f26afba46f0ebf155cf9be746496a0304a5b7cf.
  now queued up.
 
 Whoops, sorry. I mixed the patches up. The sent one does not even
 compile with 2.6.32.

So what I now have in the stable queue for .32 is not good?

Let me know if I need to fix something up.

thanks,

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100626165547.gc1...@kroah.com

Bug#586558: [stable] [PATCH] Btrfs: should add a permission check for setfacl

[Greg KH]

On Sun, Jun 20, 2010 at 06:30:21PM +0200, Bastian Blank wrote:
 This was commit 2f26afba46f0ebf155cf9be746496a0304a5b7cf.

now queued up.

thanks,

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100625224705.gf10...@kroah.com

Bug#584945: [PATCH 1/2] Staging: rtl8192s_usb: Fix device ID table

[Greg KH]

On Fri, Jun 18, 2010 at 01:00:35AM +0100, Ben Hutchings wrote:
 The rtl8192s_usb driver was claiming a number of device IDs which are
 actually supported by the code in the rtl8192u_usb driver.  Remove
 them from rtl8192s_usb, and add more device IDs as listed in the
 vendor driver version 0003.0825.2009.
 
 Signed-off-by: Ben Hutchings b...@decadent.org.uk
 ---
 I don't know whether the device IDs I'm adding actually work, but we may
 as well let people try them.

I just applied a patch from Florian that should have worked all of this
out.  Can you look at the linux-next tree tomorrow and verify that it is
all ok now?

If not, can you resend whichever ids from these two patches that you
feel are still needed to be changed?

thanks,

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2010063438.ga3...@kroah.com

Re: Reverts needed for 2.6.32.x ia64 percpu usage

[Greg KH]

On Tue, Jun 01, 2010 at 10:36:20AM -0400, Mathieu Desnoyers wrote:
 Hi Greg,
 
 Pinging for a revert request for 2.6.32.x. It seems like we had a
 misunderstanding about exactly which patches should be reverted. The email 
 below
 explains precisely which commits should be reverted from the 2.6.32.x stable
 series.

Yes, sorry, I only reverted one of these for the last .32-stable
release.  I'll go do the other one for the next release.

thanks,

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100601154134.ga21...@suse.de

Re: 2.6.32-stable percpu fixes

[Greg KH]

On Thu, May 27, 2010 at 08:18:58PM -0400, Mathieu Desnoyers wrote:
 * Ben Hutchings (b...@decadent.org.uk) wrote:
  These commits included in 2.6.32.12:
  
  ea0a09acd81c6d52c77d80f0d4089795df7bcb58 modules: fix incorrect percpu 
  usage
  d150a2b96558a7349cbf3a72a279c37bc67d50fb module: fix __module_ref_addr()
 
 In addition to commit d150a2b96558a7349cbf3a72a279c37bc67d50fb, both commits:
 
 ea0a09acd81c6d52c77d80f0d4089795df7bcb58 modules: fix incorrect percpu usage
 b6b3dcd55e2327a968833ff3f22eda3b8dd7ef9e lockdep: fix incorrect percpu usage
 
 Should be reverted from the 2.6.32.x -stable series. Quoting the explanation
 from Tejun:

Sorry, now both taken care of.

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100601164848.gb3...@kroah.com

Re: [Stable-review] Reverts needed for 2.6.32.x ia64 percpu usage

[Greg KH]

On Tue, Jun 01, 2010 at 05:32:33PM +0100, Ben Hutchings wrote:
 On Tue, Jun 01, 2010 at 08:41:34AM -0700, Greg KH wrote:
  On Tue, Jun 01, 2010 at 10:36:20AM -0400, Mathieu Desnoyers wrote:
   Hi Greg,
   
   Pinging for a revert request for 2.6.32.x. It seems like we had a
   misunderstanding about exactly which patches should be reverted. The 
   email below
   explains precisely which commits should be reverted from the 2.6.32.x 
   stable
   series.
  
  Yes, sorry, I only reverted one of these for the last .32-stable
  release.  I'll go do the other one for the next release.
  
 There are _two_ more to be reverted.

{sigh}

Yes, you, and all of the other people who sent me this in private email,
are right.  It's the first morning of me trying to switch from coffee to
green tea, give me a few hours to wake up...

I'll go do a release with these two patches reverted right now.

thanks,

greg k-h


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100601164756.ga3...@kroah.com

Bug#578129: [stable] please apply skip sense logging for some ATA PASS-THROUGH cdbs from 2.6.33

[Greg KH]

On Sat, May 01, 2010 at 11:27:56PM +0200, Moritz Muehlenhoff wrote:
 Robert Edmonds wrote:
  Package: linux-2.6
  Version: 2.6.32-11
  Severity: normal
  Tags: patch
  
  hi,
  
  when SATA drives are attached to SAS controllers and used in ATA
  pass-through mode, many operations cause alarming but harmless messages
  (though it may not be immediately obvious to the user that they are
  harmless) to be written to the kernel log, e.g.:
  
  [1381579.095459] sd 8:0:23:0: [sdx] Sense Key : Recovered Error [current] 
  [descriptor]
  [1381579.095518] Descriptor sense data with sense descriptors (in hex):
  [1381579.095549] 72 01 00 1d 00 00 00 0e 09 0c 00 00 00 00 00 00 
  [1381579.095614] 00 4f 00 c2 00 50 
  [1381579.095654] sd 8:0:23:0: [sdx] Add. Sense: ATA pass through 
  information available
  
  i see these types of messages at boot as well as periodically due to the
  use of smartmontools.  if you have a lot of disks your kernel log will
  be spammed.
  
  can you apply commit e7efe5932b1d3916c79326a4221693ea90a900e2 from
  2.6.33 to suppress these messages?
 
 Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578129
 
 Greg, please consider for the next 2.6.32.x stable kernel, it applies cleanly
 against 2.6.32.12.

And against the .33-stable tree as well.

Queued up for both now.

thanks,

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100507222328.gd26...@kroah.com

Bug#563313: [165/197] ACPI: EC: Allow multibyte access to EC

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

--


From: Alexey Starikovskiy astarikovs...@suse.de

commit dadf28a10c3eb29421837a2e413ab869ebd upstream

http://bugzilla.kernel.org/show_bug.cgi?id=14667

[bwh: Backport to 2.6.32; same applies to 2.6.33]

Signed-off-by: Alexey Starikovskiy astarikovs...@suse.de
Signed-off-by: Len Brown len.br...@intel.com
Cc: Ben Hutchings b...@decadent.org.uk
Signed-off-by: Greg Kroah-Hartman gre...@suse.de

---
 drivers/acpi/acpica/exprep.c |   12 
 drivers/acpi/ec.c|   35 +--
 2 files changed, 21 insertions(+), 26 deletions(-)

--- a/drivers/acpi/acpica/exprep.c
+++ b/drivers/acpi/acpica/exprep.c
@@ -468,6 +468,18 @@ acpi_status acpi_ex_prep_field_value(str
 
acpi_ut_add_reference(obj_desc-field.region_obj);
 
+   /* allow full data read from EC address space */
+   if (obj_desc-field.region_obj-region.space_id ==
+   ACPI_ADR_SPACE_EC) {
+   if (obj_desc-common_field.bit_length  8)
+   obj_desc-common_field.access_bit_width =
+   ACPI_ROUND_UP(obj_desc-common_field.
+   bit_length, 8);
+   obj_desc-common_field.access_byte_width =
+   ACPI_DIV_8(obj_desc-common_field.
+   access_bit_width);
+   }
+
ACPI_DEBUG_PRINT((ACPI_DB_BFIELD,
  RegionField: BitOff %X, Off %X, Gran %X, 
Region %p\n,
  obj_desc-field.start_field_bit_offset,
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -588,12 +588,12 @@ static u32 acpi_ec_gpe_handler(void *dat
 
 static acpi_status
 acpi_ec_space_handler(u32 function, acpi_physical_address address,
- u32 bits, acpi_integer *value,
+ u32 bits, acpi_integer *value64,
  void *handler_context, void *region_context)
 {
struct acpi_ec *ec = handler_context;
-   int result = 0, i;
-   u8 temp = 0;
+   int result = 0, i, bytes = bits / 8;
+   u8 *value = (u8 *)value64;
 
if ((address  0xFF) || !value || !handler_context)
return AE_BAD_PARAMETER;
@@ -601,32 +601,15 @@ acpi_ec_space_handler(u32 function, acpi
if (function != ACPI_READ  function != ACPI_WRITE)
return AE_BAD_PARAMETER;
 
-   if (bits != 8  acpi_strict)
-   return AE_BAD_PARAMETER;
-
-   if (EC_FLAGS_MSI)
+   if (EC_FLAGS_MSI || bits  8)
acpi_ec_burst_enable(ec);
 
-   if (function == ACPI_READ) {
-   result = acpi_ec_read(ec, address, temp);
-   *value = temp;
-   } else {
-   temp = 0xff  (*value);
-   result = acpi_ec_write(ec, address, temp);
-   }
-
-   for (i = 8; unlikely(bits - i  0); i += 8) {
-   ++address;
-   if (function == ACPI_READ) {
-   result = acpi_ec_read(ec, address, temp);
-   (*value) |= ((acpi_integer)temp)  i;
-   } else {
-   temp = 0xff  ((*value)  i);
-   result = acpi_ec_write(ec, address, temp);
-   }
-   }
+   for (i = 0; i  bytes; ++i, ++address, ++value)
+   result = (function == ACPI_READ) ?
+   acpi_ec_read(ec, address, value) :
+   acpi_ec_write(ec, address, *value);
 
-   if (EC_FLAGS_MSI)
+   if (EC_FLAGS_MSI || bits  8)
acpi_ec_burst_disable(ec);
 
switch (result) {





-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100422190922.146928...@kvm.kroah.org

Bug#563313: [119/139] ACPI: EC: Allow multibyte access to EC

[Greg KH]

2.6.33-stable review patch.  If anyone has any objections, please let us know.

--


From: Alexey Starikovskiy astarikovs...@suse.de

commit dadf28a10c3eb29421837a2e413ab869ebd upstream

http://bugzilla.kernel.org/show_bug.cgi?id=14667

[bwh: Backport to 2.6.32; same applies to 2.6.33]

Signed-off-by: Alexey Starikovskiy astarikovs...@suse.de
Signed-off-by: Len Brown len.br...@intel.com
Cc: Ben Hutchings b...@decadent.org.uk
Signed-off-by: Greg Kroah-Hartman gre...@suse.de

---
 drivers/acpi/acpica/exprep.c |   12 
 drivers/acpi/ec.c|   35 +--
 2 files changed, 21 insertions(+), 26 deletions(-)

--- a/drivers/acpi/acpica/exprep.c
+++ b/drivers/acpi/acpica/exprep.c
@@ -468,6 +468,18 @@ acpi_status acpi_ex_prep_field_value(str
 
acpi_ut_add_reference(obj_desc-field.region_obj);
 
+   /* allow full data read from EC address space */
+   if (obj_desc-field.region_obj-region.space_id ==
+   ACPI_ADR_SPACE_EC) {
+   if (obj_desc-common_field.bit_length  8)
+   obj_desc-common_field.access_bit_width =
+   ACPI_ROUND_UP(obj_desc-common_field.
+   bit_length, 8);
+   obj_desc-common_field.access_byte_width =
+   ACPI_DIV_8(obj_desc-common_field.
+   access_bit_width);
+   }
+
ACPI_DEBUG_PRINT((ACPI_DB_BFIELD,
  RegionField: BitOff %X, Off %X, Gran %X, 
Region %p\n,
  obj_desc-field.start_field_bit_offset,
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -589,12 +589,12 @@ static u32 acpi_ec_gpe_handler(void *dat
 
 static acpi_status
 acpi_ec_space_handler(u32 function, acpi_physical_address address,
- u32 bits, acpi_integer *value,
+ u32 bits, acpi_integer *value64,
  void *handler_context, void *region_context)
 {
struct acpi_ec *ec = handler_context;
-   int result = 0, i;
-   u8 temp = 0;
+   int result = 0, i, bytes = bits / 8;
+   u8 *value = (u8 *)value64;
 
if ((address  0xFF) || !value || !handler_context)
return AE_BAD_PARAMETER;
@@ -602,32 +602,15 @@ acpi_ec_space_handler(u32 function, acpi
if (function != ACPI_READ  function != ACPI_WRITE)
return AE_BAD_PARAMETER;
 
-   if (bits != 8  acpi_strict)
-   return AE_BAD_PARAMETER;
-
-   if (EC_FLAGS_MSI)
+   if (EC_FLAGS_MSI || bits  8)
acpi_ec_burst_enable(ec);
 
-   if (function == ACPI_READ) {
-   result = acpi_ec_read(ec, address, temp);
-   *value = temp;
-   } else {
-   temp = 0xff  (*value);
-   result = acpi_ec_write(ec, address, temp);
-   }
-
-   for (i = 8; unlikely(bits - i  0); i += 8) {
-   ++address;
-   if (function == ACPI_READ) {
-   result = acpi_ec_read(ec, address, temp);
-   (*value) |= ((acpi_integer)temp)  i;
-   } else {
-   temp = 0xff  ((*value)  i);
-   result = acpi_ec_write(ec, address, temp);
-   }
-   }
+   for (i = 0; i  bytes; ++i, ++address, ++value)
+   result = (function == ACPI_READ) ?
+   acpi_ec_read(ec, address, value) :
+   acpi_ec_write(ec, address, *value);
 
-   if (EC_FLAGS_MSI)
+   if (EC_FLAGS_MSI || bits  8)
acpi_ec_burst_disable(ec);
 
switch (result) {





-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100422195417.337536...@kvm.kroah.org

Bug#563313: [165/197] ACPI: EC: Allow multibyte access to EC

[Greg KH]

On Thu, Apr 22, 2010 at 12:59:16PM -0700, Linus Torvalds wrote:
 
 
 On Thu, 22 Apr 2010, Greg KH wrote:
  
  From: Alexey Starikovskiy astarikovs...@suse.de
  
  commit dadf28a10c3eb29421837a2e413ab869ebd upstream
 
 Hmm. Doesn't this need commit 2060c44576c79086ff24718878d7edaa7384a985
 to fix things up for crazy access_bit_width values?
 
 Maybe it's there in the series somewhere, but I didn't see it.

Yes, it's two patches later:
Subject: [167/197] ACPI: EC: Limit burst to 64 bits

good catch.

thanks,

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100422200722.ga26...@suse.de

Bug#575726: [088/116] rt2860sta: Fix argument to linux_pci_unmap_single()

[Greg KH]

2.6.32-stable review patch.  If anyone has any objections, please let us know.

--

From: Ben Hutchings b...@decadent.org.uk

John Halton wrote in http://bugs.debian.org/575726:
 Whenever wpa_supplicant is deactivated (whether by killing the process or
 during a normal shutdown) I am getting a kerneloops that prevents the
 computer from completing shutdown. Here is the relevant syslog output:

The backtrace points to an incorrect call from RTMPFreeTxRxRingMemory()
into linux_pci_unmap_single().  This appears to have been fixed in Linux
2.6.33 by this change:

commit ca97b8388838ee9ea4b4bad04948f8f7f8a607a3
Author: Bartlomiej Zolnierkiewicz bzoln...@gmail.com
Date:   Tue Sep 22 20:44:07 2009 +0200

Staging: rt28x0: updates from vendor's V2.1.0.0 drivers

For stable-2.6.32, just fix this one function call.

Signed-off-by: Ben Hutchings b...@decadent.org.uk
Signed-off-by: Greg Kroah-Hartman gre...@suse.de

---
 drivers/staging/rt2860/common/2860_rtmp_init.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/staging/rt2860/common/2860_rtmp_init.c
+++ b/drivers/staging/rt2860/common/2860_rtmp_init.c
@@ -716,7 +716,7 @@ VOID RTMPFreeTxRxRingMemory(
{
if ((pAd-RxRing.Cell[index].DmaBuf.AllocVa)  
(pAd-RxRing.Cell[index].pNdisPacket))
{
-   PCI_UNMAP_SINGLE(pObj-pci_dev, 
pAd-RxRing.Cell[index].DmaBuf.AllocPa, 
pAd-RxRing.Cell[index].DmaBuf.AllocSize, PCI_DMA_FROMDEVICE);
+   PCI_UNMAP_SINGLE(pAd, 
pAd-RxRing.Cell[index].DmaBuf.AllocPa, 
pAd-RxRing.Cell[index].DmaBuf.AllocSize, PCI_DMA_FROMDEVICE);
RELEASE_NDIS_PACKET(pAd, 
pAd-RxRing.Cell[index].pNdisPacket, NDIS_STATUS_SUCCESS);
}
}





-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100330225657.012198...@linux.site

Bug#573950: 8192 driver

[Greg KH]

On Thu, Mar 18, 2010 at 02:10:52PM +, Ben Hutchings wrote:
 On Wed, 2010-03-17 at 14:03 +1100, Geoff Simmons wrote:
  On Wed, Mar 17, 2010 at 02:19:29AM +, Ben Hutchings wrote:
   I'm sorry but I can't find the firmware for this anywhere.
  
  It is available in Greg Kroah-Hartman's linux-firmware tree [1].  From
  its WHENCE file:
  
  Add RealTek RTL8192E firmware
  
  This comes directly from RealTek in their driver package provided
  on their web site to be downloaded.
  
  Currently included in SuSE releases according to [2].
 
 Greg, do you have a full licence text for this?  The rtl8192e driver
 package is no longer available for download.

Yes I do, I need to update the patch and resend it for the main
linux-firmware package with the newest license that makes it legal to
distribute it.

thanks,

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100318150025.ga32...@suse.de

Bug#565790: [stable] [ltp] Re: Bug#565790: cat /proc/acpi/ibm/video and must press power button

[Greg KH]

On Wed, Mar 10, 2010 at 05:29:42PM -0300, Henrique de Moraes Holschuh wrote:
 On Tue, 09 Mar 2010, Moritz Muehlenhoff wrote:
  On Mon, Feb 08, 2010 at 09:53:57PM -0200, Henrique de Moraes Holschuh wrote:
   On Wed, 27 Jan 2010, jida...@jidanni.org wrote:
go reading /proc/acpi/ibm/video every day. But the curious user should
have to resort to the power button if he steps on this landmine.
   
   Sure.  I limited it to CAP_SYS_ADMIN now, which usually means root.
   
   The patch will be sent for merging, but I can't promise it will be merged
   before the next merge window for 2.6.34, and only after that will it be
   a cantidade for a 2.6.32.y stable.
   
   Patch attached for reference.
  
  Adding sta...@kernel.org to CC. Please apply for 2.6.32.x :
  This was merged in Linus' git as b525c06cdbd8a3963f0173ccd23f9147d4c384b5
 
 They should already have it somewhere in their queue, since I have Cc'd them
 in the git commit message, which I understand is automatically parsed when
 the commit gets merged in mainline.

Yes, I applied it to the .33.1 release.  But it does not apply cleanly
to the .32 kernel.  If you wish to see it there, please, can someone
provide me with a backported version?

thanks,

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100319001839.gz5...@kroah.com