Protocol v2 in v2.27 (Re: Re* [ANNOUNCE] Git v2.27.0-rc1)

[Jonathan Nieder]

(other lists -> bcc)
Junio C Hamano wrote:
> Jeff King  writes:

>> Is it worth mentioning here the reversion of v2 as the default protocol?
>>
>> It does end up (along with the actual code fix) in the "fixes from
>> v2.26" section:
>>
>>>  * Those fetching over protocol v2 from linux-next and other kernel
>>>repositories are reporting that v2 often fetches way too much than
>>>needed.
>>>(merge 11c7f2a30b jn/demote-proto2-from-default later to maint).
>>>
>>>  * The upload-pack protocol v2 gave up too early before finding a
>>>common ancestor, resulting in a wasteful fetch from a fork of a
>>>project.  This has been corrected to match the behaviour of v0
>>>protocol.
>>>(merge 2f0a093dd6 jt/v2-fetch-nego-fix later to maint).
>>
>> but that's somewhat buried. I dunno. It is not likely to introduce _new_
>> compatibility issues, but perhaps folks looking into compatibility stuff
>> may want to know about the revert.
>
> The promotion in Git 2.26 was buried in the "performance &
> implementation details" section and not in the backward
> compatibility section, so it feels a bit funny to highlight the
> reversion.  In any case, here is what I prepared (but not committed
> yet)

Speaking of which, should we enable protocol v2 by default for people
with feature.experimental enabled, like this?

(This isn't part of the rest of the feature.experimental handling
because those are tied to a repository object, whereas this code path
is used for operations like "git ls-remote" that do not require a
repository.)

Signed-off-by: Jonathan Nieder 

diff --git c/Documentation/config/protocol.txt 
i/Documentation/config/protocol.txt
index 0b40141613e..c46e9b3d00a 100644
--- c/Documentation/config/protocol.txt
+++ i/Documentation/config/protocol.txt
@@ -48,7 +48,8 @@ protocol.version::
If set, clients will attempt to communicate with a server
using the specified protocol version.  If the server does
not support it, communication falls back to version 0.
-   If unset, the default is `0`.
+   If unset, the default is `0`, unless `feature.experimental`
+   is enabled, in which case the default is `2`.
Supported versions:
 +
 --
diff --git c/protocol.c i/protocol.c
index d390391ebac..d1dd3424bba 100644
--- c/protocol.c
+++ i/protocol.c
@@ -17,6 +17,7 @@ static enum protocol_version parse_protocol_version(const 
char *value)
 enum protocol_version get_protocol_version_config(void)
 {
const char *value;
+   int val;
const char *git_test_k = "GIT_TEST_PROTOCOL_VERSION";
const char *git_test_v;
 
@@ -30,6 +31,9 @@ enum protocol_version get_protocol_version_config(void)
return version;
}
 
+   if (!git_config_get_bool("feature.experimental", ) && val)
+   return protocol_v2;
+
git_test_v = getenv(git_test_k);
if (git_test_v && *git_test_v) {
enum protocol_version env = parse_protocol_version(git_test_v);

Re: email as a bona fide git transport

[Jonathan Nieder]

Hi,

A few small points.

Vegard Nossum wrote:

> * git am (or an alternative command) needs to recreate the commit
>   perfectly when applied, including applying it to the correct parent

Interesting.  "git format-patch" has a --base option to do some of
what you're looking for, for the sake of snowpatch
.  Though it's not exactly the
same thing you mean.

We also discussed sending merge commits by mail recently in the
virtual git committer summit[1].

Of course, the devil is in the details.  It's straightforward to use
"git bundle" to use mail as a Git transport today, but presumably you
also want the ability to perform reviews along the way and that's not
so easy with a binary format.  Do you have more details on what you'd
want the format to look like, particularly for merge commits?

[...]
> there
> is no need for "changeset IDs" or whatever, since you can just use the
> git SHA1 which is unique, unambiguous, and stable.

In [2] the hope was for some identifier that is preserved by "git
rebase" and "git commit --amend" (so that you can track the evolution
of a change as the author improves it in response to reviews).  Is
that the conversation you're alluding to?

[...]
> Disadvantages:
>
> - requires patching git

That's not a disadvantage.  It means get to work with the Git project,
which is a welcoming bunch of people, working on userspace (seeing how
the other half lives), and improving the lives of everyone using Git.

[...]
> Date: Sat, 5 Oct 2019 16:15:59 +0200
> Subject: [PATCH 1/3] format-patch: add --complete
>
> Include the raw commit data between the changelog and the diffstat.

Oh!  I had missed this on first reading because it was in an
attachment.

I have mixed feelings.  Can you say a bit more about the advantages
and disadvantages relative to sending a git bundle?  What happens if a
mail client or a box along the way mangles whitespace in the commit
message?

Happy hacking,
Jonathan

[1] 
https://public-inbox.org/git/nycvar.qro.7.76.6.1909261253400.15...@tvgsbejvaqbjf.bet/
[2] 
https://lore.kernel.org/ksummit-discuss/CAD=FV=upjppuyftpjf-ogzj_6ljle4ptxmhcocedmh1lxss...@mail.gmail.com/

Re: [ANNOUNCE] Git v2.16.0-rc0

[Jonathan Nieder]

Bryan Turner wrote:
> On Tue, Jan 2, 2018 at 9:07 PM, Jonathan Nieder <jrnie...@gmail.com> wrote:

>> So my first question is why the basename detection is not working for
>> you.  What value of GIT_SSH, GIT_SSH_COMMAND, or core.sshCommand are
>> you using?
>
> So I'd been digging further into this for the last hour because I
> wasn't seeing quite the behavior I was expecting when I ran Git from
> the command line on Ubuntu 12.04 or 14.04, and this nudged me to the
> right answer: We're setting GIT_SSH to a wrapper script. In our case,
> that wrapper script is just calling OpenSSH's ssh with all the
> provided arguments (plus a couple extra ones), but because we're
> setting GIT_SSH at all, that's why the auto variant code is running.
> That being the case, explicitly setting GIT_SSH_VARIANT=ssh may be the
> correct thing to do, to tell Git that we want to be treated like
> "normal" OpenSSH, as opposed to expecting Git to assume we behave like
> OpenSSH (when the Android repo use case clearly shows that assumption
> also doesn't hold).

Ah, that's a comfort.  Setting GIT_SSH_VARIANT would avoid this
autodetection code and is the recommended thing to do.

That said, we can't go back in time and update everyone's tools to do
that (e.g. there is not even a release of repo with [1] out yet), so
this is still considered a regression and I'm glad you found it.

Jonathan

[1] https://gerrit-review.googlesource.com/c/git-repo/+/134950

Re: [ANNOUNCE] Git v2.16.0-rc0

[Jonathan Nieder]

Bryan Turner wrote:
> On Tue, Jan 2, 2018 at 9:07 PM, Jonathan Nieder  wrote:

>> So my first question is why the basename detection is not working for
>> you.  What value of GIT_SSH, GIT_SSH_COMMAND, or core.sshCommand are
>> you using?
>
> So I'd been digging further into this for the last hour because I
> wasn't seeing quite the behavior I was expecting when I ran Git from
> the command line on Ubuntu 12.04 or 14.04, and this nudged me to the
> right answer: We're setting GIT_SSH to a wrapper script. In our case,
> that wrapper script is just calling OpenSSH's ssh with all the
> provided arguments (plus a couple extra ones), but because we're
> setting GIT_SSH at all, that's why the auto variant code is running.
> That being the case, explicitly setting GIT_SSH_VARIANT=ssh may be the
> correct thing to do, to tell Git that we want to be treated like
> "normal" OpenSSH, as opposed to expecting Git to assume we behave like
> OpenSSH (when the Android repo use case clearly shows that assumption
> also doesn't hold).

Ah, that's a comfort.  Setting GIT_SSH_VARIANT would avoid this
autodetection code and is the recommended thing to do.

That said, we can't go back in time and update everyone's tools to do
that (e.g. there is not even a release of repo with [1] out yet), so
this is still considered a regression and I'm glad you found it.

Jonathan

[1] https://gerrit-review.googlesource.com/c/git-repo/+/134950

Re: [ANNOUNCE] Git v2.16.0-rc0

[Jonathan Nieder]

Hi,

A few more notes.

Bryan Turner wrote:

> bturner@ubuntu:~$ ssh -V
> OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8, OpenSSL 1.0.1f 6 Jan 2014
>
> bturner@ubuntu:~$ ssh -G -p 7999 localhost
> unknown option -- G
> usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[...]
> Is it possible to adjust the check, somehow, so it doesn't impact
> older OpenSSH versions like this? As it stands, it seems likely a fair
> number of users who have an SSH command that does support -4, -6 and
> -p are going to end up getting "penalized" because it doesn't also
> support -G, and have to manually set their SSH variant to "ssh" (or
> something other than "auto") to avoid the automatic detection.
>
> I'd love to say I have a brilliant idea for how to work around this,
> oh and here's a patch, but I don't. One option might be trying to
> actually review the output, and another might be to run "ssh -V", but
> both of those have their own flaws (and the extra process forks aren't
> "free").

I have tomorrow off, so I've filed https://crbug.com/git/7 to make
sure I remember to follow up the day after.  Of course I'll be happy
if someone updates that bug saying they've fixed it in the meantime.

One possibility would be to use -V as a fallback when -G fails, or
even as a replacement for this usage of -G.  To avoid misdetecting
PuTTY and other ssh variants that also implement -V as OpenSSH, we
would have to parse the output.  This would also misdetect a script
that does

host=$1; shift
ssh "$host" -- "$@"

as supporting OpenSSH options, when the use of -- ensures it doesn't.

Another possibility is to parse the output when -G fails.  That's
hacky, but I think it would work well!  We would not have to be too
clever, since we can look for the exact output produced by the
versions of OpenSSH that we care about.  This still has issues with
scripts that forward arguments to OpenSSH, but at least those issues
would go away once the user updates their copy of ssh. ;-)

Another possibility is to pass options *before* -V:

ssh -p 7999 -V

Since OpenSSH parses its arguments left-to-right, this gives similar
information to what we did with -G, and scripts like

host=$1; shift
ssh "$host" -- "$@"

would even be correctly detected as not supporting OpenSSH options.
We still would need to parse the output to distinguish OpenSSH from
other ssh implementations like putty (unlike OpenSSH, putty saves up
argument errors in an 'error' variable and forgets about them once it
sees -V).

Trying -G and falling back to -V seems like the simplest detection
mechanism to me at the moment.  I'm hoping I'm missing something
simple (another ssh option?) that allows avoiding this mess.

Regardless, I think we should do something like [1] first to get rid
of the regression.  Thanks again for reporting it.

Sincerely,
Jonathan

[1] 
https://public-inbox.org/git/20180103050730.ga87...@aiede.mtv.corp.google.com/

Re: [ANNOUNCE] Git v2.16.0-rc0

[Jonathan Nieder]

Hi,

A few more notes.

Bryan Turner wrote:

> bturner@ubuntu:~$ ssh -V
> OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8, OpenSSL 1.0.1f 6 Jan 2014
>
> bturner@ubuntu:~$ ssh -G -p 7999 localhost
> unknown option -- G
> usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[...]
> Is it possible to adjust the check, somehow, so it doesn't impact
> older OpenSSH versions like this? As it stands, it seems likely a fair
> number of users who have an SSH command that does support -4, -6 and
> -p are going to end up getting "penalized" because it doesn't also
> support -G, and have to manually set their SSH variant to "ssh" (or
> something other than "auto") to avoid the automatic detection.
>
> I'd love to say I have a brilliant idea for how to work around this,
> oh and here's a patch, but I don't. One option might be trying to
> actually review the output, and another might be to run "ssh -V", but
> both of those have their own flaws (and the extra process forks aren't
> "free").

I have tomorrow off, so I've filed https://crbug.com/git/7 to make
sure I remember to follow up the day after.  Of course I'll be happy
if someone updates that bug saying they've fixed it in the meantime.

One possibility would be to use -V as a fallback when -G fails, or
even as a replacement for this usage of -G.  To avoid misdetecting
PuTTY and other ssh variants that also implement -V as OpenSSH, we
would have to parse the output.  This would also misdetect a script
that does

host=$1; shift
ssh "$host" -- "$@"

as supporting OpenSSH options, when the use of -- ensures it doesn't.

Another possibility is to parse the output when -G fails.  That's
hacky, but I think it would work well!  We would not have to be too
clever, since we can look for the exact output produced by the
versions of OpenSSH that we care about.  This still has issues with
scripts that forward arguments to OpenSSH, but at least those issues
would go away once the user updates their copy of ssh. ;-)

Another possibility is to pass options *before* -V:

ssh -p 7999 -V

Since OpenSSH parses its arguments left-to-right, this gives similar
information to what we did with -G, and scripts like

host=$1; shift
ssh "$host" -- "$@"

would even be correctly detected as not supporting OpenSSH options.
We still would need to parse the output to distinguish OpenSSH from
other ssh implementations like putty (unlike OpenSSH, putty saves up
argument errors in an 'error' variable and forgets about them once it
sees -V).

Trying -G and falling back to -V seems like the simplest detection
mechanism to me at the moment.  I'm hoping I'm missing something
simple (another ssh option?) that allows avoiding this mess.

Regardless, I think we should do something like [1] first to get rid
of the regression.  Thanks again for reporting it.

Sincerely,
Jonathan

[1] 
https://public-inbox.org/git/20180103050730.ga87...@aiede.mtv.corp.google.com/

Re: [ANNOUNCE] Git v2.16.0-rc0

[Jonathan Nieder]

Hi Bryan,

Bryan Turner wrote:

> Our test environment is still on Ubuntu 12.04 LTS (it's a long story,
> but one I doubt is unique to us), which means it's using OpenSSH 5.9.
> ssh -G was added in OpenSSH 6.8 [1], circa March 2015, which means the
> "auto" detection "fails" and chooses "simple" instead of "ssh". But
> OpenSSH 5.9 _does_ support -4, -6 and -p. As a result, commands which
> have been working without issue on all previous versions of Git start
> to fail saying
>
> git -c gc.auto=0 -c credential.helper= fetch --force --prune --progress 
> ssh://localhost:64281/repo.git +refs/*:refs/*' exited with code 128 saying: 
> fatal: ssh variant 'simple' does not support setting port

Hm, that's not expected.  git-config(1) says:

By default, Git determines the command line arguments to use
based on the basename of the configured SSH command
(configured using the environment variable GIT_SSH or
GIT_SSH_COMMAND or the config setting core.sshCommand). If the
basename is unrecognized, Git will attempt to detect support
of OpenSSH options by [...]

So my first question is why the basename detection is not working for
you.  What value of GIT_SSH, GIT_SSH_COMMAND, or core.sshCommand are
you using?

> I know Ubuntu 12.04 LTS is end-of-life, but 14.04 LTS, which is
> running OpenSSH 6.6 [2], has the same issue. The following is from a
> fully patched 14.04.5:
>
> bturner@ubuntu:~$ cat /etc/*ease | head -4
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=14.04
> DISTRIB_CODENAME=trusty
> DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS"
>
> bturner@ubuntu:~$ ssh -V
> OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8, OpenSSL 1.0.1f 6 Jan 2014
>
> bturner@ubuntu:~$ ssh -G -p 7999 localhost
> unknown option -- G

It's good you caught this flaw in the detection.  Would something like
the following make sense?  If so, I can resend with a commit message
and tests tomorrow or the day after.

diff --git i/Documentation/config.txt w/Documentation/config.txt
index 64c1dbba94..75eafd8db6 100644
--- i/Documentation/config.txt
+++ w/Documentation/config.txt
@@ -2118,8 +2118,8 @@ ssh.variant::
unrecognized, Git will attempt to detect support of OpenSSH
options by first invoking the configured SSH command with the
`-G` (print configuration) option and will subsequently use
-   OpenSSH options (if that is successful) or no options besides
-   the host and remote command (if it fails).
+   OpenSSH options if that is successful or a conservative set of
+   OpenSSH-style options if it fails.
 +
 The config variable `ssh.variant` can be set to override this detection.
 Valid values are `ssh` (to use OpenSSH options), `plink`, `putty`,
diff --git i/connect.c w/connect.c
index c3a014c5ba..3784c2be53 100644
--- i/connect.c
+++ w/connect.c
@@ -941,10 +941,9 @@ static void push_ssh_options(struct argv_array *args, 
struct argv_array *env,
 
if (flags & CONNECT_IPV4) {
switch (variant) {
-   case VARIANT_AUTO:
-   BUG("VARIANT_AUTO passed to push_ssh_options");
case VARIANT_SIMPLE:
die("ssh variant 'simple' does not support -4");
+   case VARIANT_AUTO:
case VARIANT_SSH:
case VARIANT_PLINK:
case VARIANT_PUTTY:
@@ -953,10 +952,9 @@ static void push_ssh_options(struct argv_array *args, 
struct argv_array *env,
}
} else if (flags & CONNECT_IPV6) {
switch (variant) {
-   case VARIANT_AUTO:
-   BUG("VARIANT_AUTO passed to push_ssh_options");
case VARIANT_SIMPLE:
die("ssh variant 'simple' does not support -6");
+   case VARIANT_AUTO:
case VARIANT_SSH:
case VARIANT_PLINK:
case VARIANT_PUTTY:
@@ -970,10 +968,9 @@ static void push_ssh_options(struct argv_array *args, 
struct argv_array *env,
 
if (port) {
switch (variant) {
-   case VARIANT_AUTO:
-   BUG("VARIANT_AUTO passed to push_ssh_options");
case VARIANT_SIMPLE:
die("ssh variant 'simple' does not support setting 
port");
+   case VARIANT_AUTO:
case VARIANT_SSH:
argv_array_push(args, "-p");
break;
@@ -1026,7 +1023,7 @@ static void fill_ssh_args(struct child_process *conn, 
const char *ssh_host,
 VARIANT_SSH, port, flags);
argv_array_push(, ssh_host);
 
-   variant = run_command() ? VARIANT_SIMPLE : VARIANT_SSH;
+   variant = run_command() ? VARIANT_AUTO : VARIANT_SSH;
}
 
argv_array_push(>args, ssh);
diff --git i/t/t5601-clone.sh w/t/t5601-clone.sh
index 0f895478f0..0224edc85b 100755
--- i/t/t5601-clone.sh
+++ w/t/t5601-clone.sh
@@ -365,6 +365,11 @@ 

Re: [ANNOUNCE] Git v2.16.0-rc0

[Jonathan Nieder]

Hi Bryan,

Bryan Turner wrote:

> Our test environment is still on Ubuntu 12.04 LTS (it's a long story,
> but one I doubt is unique to us), which means it's using OpenSSH 5.9.
> ssh -G was added in OpenSSH 6.8 [1], circa March 2015, which means the
> "auto" detection "fails" and chooses "simple" instead of "ssh". But
> OpenSSH 5.9 _does_ support -4, -6 and -p. As a result, commands which
> have been working without issue on all previous versions of Git start
> to fail saying
>
> git -c gc.auto=0 -c credential.helper= fetch --force --prune --progress 
> ssh://localhost:64281/repo.git +refs/*:refs/*' exited with code 128 saying: 
> fatal: ssh variant 'simple' does not support setting port

Hm, that's not expected.  git-config(1) says:

By default, Git determines the command line arguments to use
based on the basename of the configured SSH command
(configured using the environment variable GIT_SSH or
GIT_SSH_COMMAND or the config setting core.sshCommand). If the
basename is unrecognized, Git will attempt to detect support
of OpenSSH options by [...]

So my first question is why the basename detection is not working for
you.  What value of GIT_SSH, GIT_SSH_COMMAND, or core.sshCommand are
you using?

> I know Ubuntu 12.04 LTS is end-of-life, but 14.04 LTS, which is
> running OpenSSH 6.6 [2], has the same issue. The following is from a
> fully patched 14.04.5:
>
> bturner@ubuntu:~$ cat /etc/*ease | head -4
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=14.04
> DISTRIB_CODENAME=trusty
> DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS"
>
> bturner@ubuntu:~$ ssh -V
> OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8, OpenSSL 1.0.1f 6 Jan 2014
>
> bturner@ubuntu:~$ ssh -G -p 7999 localhost
> unknown option -- G

It's good you caught this flaw in the detection.  Would something like
the following make sense?  If so, I can resend with a commit message
and tests tomorrow or the day after.

diff --git i/Documentation/config.txt w/Documentation/config.txt
index 64c1dbba94..75eafd8db6 100644
--- i/Documentation/config.txt
+++ w/Documentation/config.txt
@@ -2118,8 +2118,8 @@ ssh.variant::
unrecognized, Git will attempt to detect support of OpenSSH
options by first invoking the configured SSH command with the
`-G` (print configuration) option and will subsequently use
-   OpenSSH options (if that is successful) or no options besides
-   the host and remote command (if it fails).
+   OpenSSH options if that is successful or a conservative set of
+   OpenSSH-style options if it fails.
 +
 The config variable `ssh.variant` can be set to override this detection.
 Valid values are `ssh` (to use OpenSSH options), `plink`, `putty`,
diff --git i/connect.c w/connect.c
index c3a014c5ba..3784c2be53 100644
--- i/connect.c
+++ w/connect.c
@@ -941,10 +941,9 @@ static void push_ssh_options(struct argv_array *args, 
struct argv_array *env,
 
if (flags & CONNECT_IPV4) {
switch (variant) {
-   case VARIANT_AUTO:
-   BUG("VARIANT_AUTO passed to push_ssh_options");
case VARIANT_SIMPLE:
die("ssh variant 'simple' does not support -4");
+   case VARIANT_AUTO:
case VARIANT_SSH:
case VARIANT_PLINK:
case VARIANT_PUTTY:
@@ -953,10 +952,9 @@ static void push_ssh_options(struct argv_array *args, 
struct argv_array *env,
}
} else if (flags & CONNECT_IPV6) {
switch (variant) {
-   case VARIANT_AUTO:
-   BUG("VARIANT_AUTO passed to push_ssh_options");
case VARIANT_SIMPLE:
die("ssh variant 'simple' does not support -6");
+   case VARIANT_AUTO:
case VARIANT_SSH:
case VARIANT_PLINK:
case VARIANT_PUTTY:
@@ -970,10 +968,9 @@ static void push_ssh_options(struct argv_array *args, 
struct argv_array *env,
 
if (port) {
switch (variant) {
-   case VARIANT_AUTO:
-   BUG("VARIANT_AUTO passed to push_ssh_options");
case VARIANT_SIMPLE:
die("ssh variant 'simple' does not support setting 
port");
+   case VARIANT_AUTO:
case VARIANT_SSH:
argv_array_push(args, "-p");
break;
@@ -1026,7 +1023,7 @@ static void fill_ssh_args(struct child_process *conn, 
const char *ssh_host,
 VARIANT_SSH, port, flags);
argv_array_push(, ssh_host);
 
-   variant = run_command() ? VARIANT_SIMPLE : VARIANT_SSH;
+   variant = run_command() ? VARIANT_AUTO : VARIANT_SSH;
}
 
argv_array_push(>args, ssh);
diff --git i/t/t5601-clone.sh w/t/t5601-clone.sh
index 0f895478f0..0224edc85b 100755
--- i/t/t5601-clone.sh
+++ w/t/t5601-clone.sh
@@ -365,6 +365,11 @@ 

Re: [ANNOUNCE] Git v2.12.3 and others

[Jonathan Nieder]

Junio C Hamano wrote:

> Maintenance releases Git v2.4.12, v2.5.6, v2.6.7, v2.7.5, v2.8.5,
> v2.9.4, v2.10.3, v2.11.2, and v2.12.3 have been tagged and are now
> available at the usual places.
>
> These are primarily to fix a recently disclosed problem with "git
> shell", which may allow a user who comes over SSH to run an
> interactive pager by causing it to spawn "git upload-pack --help"
> (CVE-2017-8386).  Some (like v2.12.3) have other fixes that have
> been accumulating included as well.
>
> "git-shell" is a restricted login shell that can be used on a server
> to prevent SSH clients from running any programs except those needed
> for git fetches and pushes. If you are not running a server, or if
> your server has not been explicitly configured to use git-shell as a
> login shell, you are not affected.  Also note that sites running "git
> shell" behind gitolite are NOT vulnerable.

Thanks.  Credit for discovering this bug goes to Timo Schmid, ERNW GmbH.
They will probably have a blog post soon with more details.

1.6.1 is the earliest git version affected (so this goes back pretty
far).

> The tarballs are found at:
>
> https://www.kernel.org/pub/software/scm/git/
>
> The following public repositories all have a copy of these tags:
>
>   url = https://kernel.googlesource.com/pub/scm/git/git
>   url = git://repo.or.cz/alt-git.git
>   url = git://git.sourceforge.jp/gitroot/git-core/git.git
>   url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
>   url = https://github.com/gitster/git

Sincerely,
Jonathan

Re: [ANNOUNCE] Git v2.12.3 and others

[Jonathan Nieder]

Junio C Hamano wrote:

> Maintenance releases Git v2.4.12, v2.5.6, v2.6.7, v2.7.5, v2.8.5,
> v2.9.4, v2.10.3, v2.11.2, and v2.12.3 have been tagged and are now
> available at the usual places.
>
> These are primarily to fix a recently disclosed problem with "git
> shell", which may allow a user who comes over SSH to run an
> interactive pager by causing it to spawn "git upload-pack --help"
> (CVE-2017-8386).  Some (like v2.12.3) have other fixes that have
> been accumulating included as well.
>
> "git-shell" is a restricted login shell that can be used on a server
> to prevent SSH clients from running any programs except those needed
> for git fetches and pushes. If you are not running a server, or if
> your server has not been explicitly configured to use git-shell as a
> login shell, you are not affected.  Also note that sites running "git
> shell" behind gitolite are NOT vulnerable.

Thanks.  Credit for discovering this bug goes to Timo Schmid, ERNW GmbH.
They will probably have a blog post soon with more details.

1.6.1 is the earliest git version affected (so this goes back pretty
far).

> The tarballs are found at:
>
> https://www.kernel.org/pub/software/scm/git/
>
> The following public repositories all have a copy of these tags:
>
>   url = https://kernel.googlesource.com/pub/scm/git/git
>   url = git://repo.or.cz/alt-git.git
>   url = git://git.sourceforge.jp/gitroot/git-core/git.git
>   url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
>   url = https://github.com/gitster/git

Sincerely,
Jonathan

[ANNOUNCE] Git v1.8.4.1

[Jonathan Nieder]

The latest maintenance release Git v1.8.4.1 is now available.

The release tarballs are found at:

http://alioth.debian.org/~jrnieder-guest/git/

and their SHA-1 checksums are:

49004a8dfcbb7c0848147737d9877fd7313a42ec  git-1.8.4.1.tar.gz
1f0e5c5934ec333b5630a8c93a0fb0b1895dfcb8  git-htmldocs-1.8.4.1.tar.gz
dc0f9de1cacc8912f131b67dc5a19a96768ecc95  git-manpages-1.8.4.1.tar.gz

The following public repositories all have a copy of the v1.8.4.1
tag and the maint branch that the tag points at:

  url = https://googlers.googlesource.com/jrn/git
  url = git://repo.or.cz/git/jrn.git
  url = git://gitorious.org/git/jrn.git
  url = https://github.com/jrn/git

Git v1.8.4.1 Release Notes


Fixes since v1.8.4
--

 * Some old versions of bash do not grok some constructs like
   'printf -v varname' which the prompt and completion code started
   to use recently.  The completion and prompt scripts have been
   adjusted to work better with these old versions of bash.

 * In FreeBSD's and NetBSD's "sh", a return in a dot script in a
   function returns from the function, not only in the dot script,
   breaking "git rebase" on these platforms (regression introduced
   in 1.8.4-rc1).

 * "git rebase -i" and other scripted commands were feeding a
   random, data dependant error message to 'echo' and expecting it
   to come out literally.

 * Setting the "submodule..path" variable to the empty
   "true" caused the configuration parser to segfault.

 * Output from "git log --full-diff -- " looked strange
   because comparison was done with the previous ancestor that
   touched the specified , causing the patches for paths
   outside the pathspec to show more than the single commit has
   changed.

 * The auto-tag-following code in "git fetch" tries to reuse the
   same transport twice when the serving end does not cooperate and
   does not give tags that point to commits that are asked for as
   part of the primary transfer.  Unfortunately, Git-aware transport
   helper interface is not designed to be used more than once, hence
   this did not work over smart-http transfer.  Fixed.

 * Send a large request to read(2)/write(2) as a smaller but still
   reasonably large chunks, which would improve the latency when the
   operation needs to be killed and incidentally works around broken
   64-bit systems that cannot take a 2GB write or read in one go.

 * A ".mailmap" file that ends with an incomplete line, when read
   from a blob, was not handled properly.

 * The recent "short-cut clone connectivity check" topic broke a
   shallow repository when a fetch operation tries to auto-follow
   tags.

 * When send-email comes up with an error message to die with upon
   failure to start an SSL session, it tried to read the error
   string from a wrong place.

 * A call to xread() was used without a loop to cope with short
   read in the codepath to stream large blobs to a pack.

 * On platforms with fgetc() and friends defined as macros, the
   configuration parser did not compile.

 * New versions of MediaWiki introduced a new API for returning
   more than 500 results in response to a query, which would cause
   the MediaWiki remote helper to go into an infinite loop.

 * Subversion's serf access method (the only one available in
   Subversion 1.8) for http and https URLs in skelta mode tells its
   caller to open multiple files at a time, which made "git svn
   fetch" complain that "Temp file with moniker 'svn_delta' already
   in use" instead of fetching.


Also contains a handful of trivial code clean-ups, documentation
updates, updates to the test suite, etc.



Changes since v1.8.4 are as follows:

Andreas Schwab (1):
  Documentation/git-merge.txt: fix formatting of example block

Benoit Person (1):
  git-remote-mediawiki: bugfix for pages w/ >500 revisions

Brandon Casey (3):
  git-completion.bash: use correct Bash/Zsh array length syntax
  t9902-completion.sh: old Bash still does not support array+=('') notation
  contrib/git-prompt.sh: handle missing 'printf -v' more gracefully

Jeff King (2):
  config: do not use C function names as struct members
  mailmap: handle mailmap blobs without trailing newlines

Jharrod LaFon (1):
  avoid segfault on submodule.*.path set to an empty "true"

Johannes Sixt (1):
  stream_to_pack: xread does not guarantee to read all requested bytes

Jonathan Nieder (1):
  Git 1.8.4.1

Junio C Hamano (6):
  t5802: add test for connect helper
  fetch: rename file-scope global "transport" to "gtransport"
  fetch: refactor code that prepares a transport
  fetch: refactor code that fetches leftover tags
  fetch: work around "transport-take-over" hack
  Start preparing for 1.8.4.1

K

[ANNOUNCE] Git v1.8.4.1

[Jonathan Nieder]

The latest maintenance release Git v1.8.4.1 is now available.

The release tarballs are found at:

http://alioth.debian.org/~jrnieder-guest/git/

and their SHA-1 checksums are:

49004a8dfcbb7c0848147737d9877fd7313a42ec  git-1.8.4.1.tar.gz
1f0e5c5934ec333b5630a8c93a0fb0b1895dfcb8  git-htmldocs-1.8.4.1.tar.gz
dc0f9de1cacc8912f131b67dc5a19a96768ecc95  git-manpages-1.8.4.1.tar.gz

The following public repositories all have a copy of the v1.8.4.1
tag and the maint branch that the tag points at:

  url = https://googlers.googlesource.com/jrn/git
  url = git://repo.or.cz/git/jrn.git
  url = git://gitorious.org/git/jrn.git
  url = https://github.com/jrn/git

Git v1.8.4.1 Release Notes


Fixes since v1.8.4
--

 * Some old versions of bash do not grok some constructs like
   'printf -v varname' which the prompt and completion code started
   to use recently.  The completion and prompt scripts have been
   adjusted to work better with these old versions of bash.

 * In FreeBSD's and NetBSD's sh, a return in a dot script in a
   function returns from the function, not only in the dot script,
   breaking git rebase on these platforms (regression introduced
   in 1.8.4-rc1).

 * git rebase -i and other scripted commands were feeding a
   random, data dependant error message to 'echo' and expecting it
   to come out literally.

 * Setting the submodule.name.path variable to the empty
   true caused the configuration parser to segfault.

 * Output from git log --full-diff -- pathspec looked strange
   because comparison was done with the previous ancestor that
   touched the specified pathspec, causing the patches for paths
   outside the pathspec to show more than the single commit has
   changed.

 * The auto-tag-following code in git fetch tries to reuse the
   same transport twice when the serving end does not cooperate and
   does not give tags that point to commits that are asked for as
   part of the primary transfer.  Unfortunately, Git-aware transport
   helper interface is not designed to be used more than once, hence
   this did not work over smart-http transfer.  Fixed.

 * Send a large request to read(2)/write(2) as a smaller but still
   reasonably large chunks, which would improve the latency when the
   operation needs to be killed and incidentally works around broken
   64-bit systems that cannot take a 2GB write or read in one go.

 * A .mailmap file that ends with an incomplete line, when read
   from a blob, was not handled properly.

 * The recent short-cut clone connectivity check topic broke a
   shallow repository when a fetch operation tries to auto-follow
   tags.

 * When send-email comes up with an error message to die with upon
   failure to start an SSL session, it tried to read the error
   string from a wrong place.

 * A call to xread() was used without a loop to cope with short
   read in the codepath to stream large blobs to a pack.

 * On platforms with fgetc() and friends defined as macros, the
   configuration parser did not compile.

 * New versions of MediaWiki introduced a new API for returning
   more than 500 results in response to a query, which would cause
   the MediaWiki remote helper to go into an infinite loop.

 * Subversion's serf access method (the only one available in
   Subversion 1.8) for http and https URLs in skelta mode tells its
   caller to open multiple files at a time, which made git svn
   fetch complain that Temp file with moniker 'svn_delta' already
   in use instead of fetching.


Also contains a handful of trivial code clean-ups, documentation
updates, updates to the test suite, etc.



Changes since v1.8.4 are as follows:

Andreas Schwab (1):
  Documentation/git-merge.txt: fix formatting of example block

Benoit Person (1):
  git-remote-mediawiki: bugfix for pages w/ 500 revisions

Brandon Casey (3):
  git-completion.bash: use correct Bash/Zsh array length syntax
  t9902-completion.sh: old Bash still does not support array+=('') notation
  contrib/git-prompt.sh: handle missing 'printf -v' more gracefully

Jeff King (2):
  config: do not use C function names as struct members
  mailmap: handle mailmap blobs without trailing newlines

Jharrod LaFon (1):
  avoid segfault on submodule.*.path set to an empty true

Johannes Sixt (1):
  stream_to_pack: xread does not guarantee to read all requested bytes

Jonathan Nieder (1):
  Git 1.8.4.1

Junio C Hamano (6):
  t5802: add test for connect helper
  fetch: rename file-scope global transport to gtransport
  fetch: refactor code that prepares a transport
  fetch: refactor code that fetches leftover tags
  fetch: work around transport-take-over hack
  Start preparing for 1.8.4.1

Kyle J. McKay (3):
  Git.pm: add new temp_is_locked function
  git-svn: allow git-svn fetching to work using serf
  Git.pm: revert _temp_cache use

[3.8-rc3 -> 3.8-rc4 regression] Re: [PATCH] module, async: async_synchronize_full() on module init iff async is used

[Jonathan Nieder]

Hi,

Tejun Heo wrote:

> This avoids the described deadlock because iosched module doesn't use
> async and thus wouldn't invoke async_synchronize_full().  This is
> hacky and incomplete.  It will deadlock if async module loading nests;
> however, this works around the known problem case and seems to be the
> best of bad options.
>
> For more details, please refer to the following thread.
>
>   http://thread.gmane.org/gmane.linux.kernel/1420814

My laptop fails to boot[1] with the message 'Volume group "data" not
found'.  Bisects to v3.8-rc4~17 (the above commit).  Reverting that
commit on top of current "master" (d92581fcad18, 2013-08-10) produces
a working kernel.  dmesg output from that working kernel attached.
More details, including .config, at [2].

Any ideas for tracking this down?

Thanks,
Jonathan

[1] Screenshot: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=bad_3.10.3-1.jpg;att=1;bug=719464
Screenshot in recovery mode: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=bad_3.10.3-1_recovery.jpg;att=2;bug=719464
[2] http://bugs.debian.org/719464
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.11.0-rc4+ (jrn@elie) (gcc version 4.7.3 (Debian 
4.7.3-6) ) #2 SMP Sun Aug 11 23:20:20 PDT 2013
[0.00] Command line: BOOT_IMAGE=/vmlinuz-3.11.0-rc4+ 
root=/dev/mapper/data-root ro quiet
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x6e545fff] usable
[0.00] BIOS-e820: [mem 0x6e546000-0x6e745fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x6e746000-0x6fd3efff] usable
[0.00] BIOS-e820: [mem 0x6fd3f000-0x6fdbefff] reserved
[0.00] BIOS-e820: [mem 0x6fdbf000-0x6febefff] ACPI NVS
[0.00] BIOS-e820: [mem 0x6febf000-0x6fef6fff] ACPI data
[0.00] BIOS-e820: [mem 0x6fef7000-0x6fef] usable
[0.00] BIOS-e820: [mem 0xf800-0xf8ff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xffe0-0x] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.6 present.
[0.00] DMI: TOSHIBA Satellite C650D/Portable PC, BIOS 1.60 09/02/2010
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] No AGP bridge found
[0.00] e820: last_pfn = 0x6ff00 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-through
[0.00] MTRR variable ranges enabled:
[0.00]   0 base  mask C000 write-back
[0.00]   1 base 4000 mask E000 write-back
[0.00]   2 base 6000 mask F000 write-back
[0.00]   3 base 6FEBE000 mask F000 uncachable
[0.00]   4 base FFE0 mask FFE0 write-protect
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] Base memory trampoline at [88099000] 99000 size 24576
[0.00] Using GB pages for direct mapping
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] BRK [0x0184c000, 0x0184cfff] PGTABLE
[0.00] BRK [0x0184d000, 0x0184dfff] PGTABLE
[0.00] BRK [0x0184e000, 0x0184efff] PGTABLE
[0.00] init_memory_mapping: [mem 0x6fa0-0x6fbf]
[0.00]  [mem 0x6fa0-0x6fbf] page 2M
[0.00] BRK [0x0184f000, 0x0184] PGTABLE
[0.00] init_memory_mapping: [mem 0x6c00-0x6e545fff]
[0.00]  [mem 0x6c00-0x6e3f] page 2M
[0.00]  [mem 0x6e40-0x6e545fff] page 4k
[0.00] BRK [0x0185, 0x01850fff] PGTABLE
[0.00] init_memory_mapping: [mem 0x6e746000-0x6f9f]
[0.00]  [mem 0x6e746000-0x6e7f] page 4k
[0.00]  [mem 0x6e80-0x6f9f] page 2M
[0.00] init_memory_mapping: [mem 0x0010-0x6bff]
[0.00]  [mem 0x0010-0x001f] page 4k
[0.00]  [mem 0x0020-0x6bff] page 2M
[0.00] 

[3.8-rc3 - 3.8-rc4 regression] Re: [PATCH] module, async: async_synchronize_full() on module init iff async is used

[Jonathan Nieder]

Hi,

Tejun Heo wrote:

 This avoids the described deadlock because iosched module doesn't use
 async and thus wouldn't invoke async_synchronize_full().  This is
 hacky and incomplete.  It will deadlock if async module loading nests;
 however, this works around the known problem case and seems to be the
 best of bad options.

 For more details, please refer to the following thread.

   http://thread.gmane.org/gmane.linux.kernel/1420814

My laptop fails to boot[1] with the message 'Volume group data not
found'.  Bisects to v3.8-rc4~17 (the above commit).  Reverting that
commit on top of current master (d92581fcad18, 2013-08-10) produces
a working kernel.  dmesg output from that working kernel attached.
More details, including .config, at [2].

Any ideas for tracking this down?

Thanks,
Jonathan

[1] Screenshot: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=bad_3.10.3-1.jpg;att=1;bug=719464
Screenshot in recovery mode: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=bad_3.10.3-1_recovery.jpg;att=2;bug=719464
[2] http://bugs.debian.org/719464
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.11.0-rc4+ (jrn@elie) (gcc version 4.7.3 (Debian 
4.7.3-6) ) #2 SMP Sun Aug 11 23:20:20 PDT 2013
[0.00] Command line: BOOT_IMAGE=/vmlinuz-3.11.0-rc4+ 
root=/dev/mapper/data-root ro quiet
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x6e545fff] usable
[0.00] BIOS-e820: [mem 0x6e546000-0x6e745fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x6e746000-0x6fd3efff] usable
[0.00] BIOS-e820: [mem 0x6fd3f000-0x6fdbefff] reserved
[0.00] BIOS-e820: [mem 0x6fdbf000-0x6febefff] ACPI NVS
[0.00] BIOS-e820: [mem 0x6febf000-0x6fef6fff] ACPI data
[0.00] BIOS-e820: [mem 0x6fef7000-0x6fef] usable
[0.00] BIOS-e820: [mem 0xf800-0xf8ff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xffe0-0x] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.6 present.
[0.00] DMI: TOSHIBA Satellite C650D/Portable PC, BIOS 1.60 09/02/2010
[0.00] e820: update [mem 0x-0x0fff] usable == reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] No AGP bridge found
[0.00] e820: last_pfn = 0x6ff00 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-through
[0.00] MTRR variable ranges enabled:
[0.00]   0 base  mask C000 write-back
[0.00]   1 base 4000 mask E000 write-back
[0.00]   2 base 6000 mask F000 write-back
[0.00]   3 base 6FEBE000 mask F000 uncachable
[0.00]   4 base FFE0 mask FFE0 write-protect
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] Base memory trampoline at [88099000] 99000 size 24576
[0.00] Using GB pages for direct mapping
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] BRK [0x0184c000, 0x0184cfff] PGTABLE
[0.00] BRK [0x0184d000, 0x0184dfff] PGTABLE
[0.00] BRK [0x0184e000, 0x0184efff] PGTABLE
[0.00] init_memory_mapping: [mem 0x6fa0-0x6fbf]
[0.00]  [mem 0x6fa0-0x6fbf] page 2M
[0.00] BRK [0x0184f000, 0x0184] PGTABLE
[0.00] init_memory_mapping: [mem 0x6c00-0x6e545fff]
[0.00]  [mem 0x6c00-0x6e3f] page 2M
[0.00]  [mem 0x6e40-0x6e545fff] page 4k
[0.00] BRK [0x0185, 0x01850fff] PGTABLE
[0.00] init_memory_mapping: [mem 0x6e746000-0x6f9f]
[0.00]  [mem 0x6e746000-0x6e7f] page 4k
[0.00]  [mem 0x6e80-0x6f9f] page 2M
[0.00] init_memory_mapping: [mem 0x0010-0x6bff]
[0.00]  [mem 0x0010-0x001f] page 4k
[0.00]  [mem 0x0020-0x6bff] page 2M
[0.00] 

Re: [regression] external HDD in USB3 enclosure cannot be dynamically removed (Re: Linux 3.7.5)

[Jonathan Nieder]

Sarah Sharp wrote:

> Can you turn on CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING,
> recompile the 3.7.5 kernel, and send me dmesg starting from the point
> you unmount the device and then power it off?
>
> I'd like to keep that patch in stable, but I need to understand what
> exactly is failing with it.

Note that Holger ran into the same problem using a mainline (3.8-rc5)
kernel.

Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] external HDD in USB3 enclosure cannot be dynamically removed (Re: Linux 3.7.5)

[Jonathan Nieder]

Sarah Sharp wrote:

 Can you turn on CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING,
 recompile the 3.7.5 kernel, and send me dmesg starting from the point
 you unmount the device and then power it off?

 I'd like to keep that patch in stable, but I need to understand what
 exactly is failing with it.

Note that Holger ran into the same problem using a mainline (3.8-rc5)
kernel.

Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[regression] external HDD in USB3 enclosure cannot be dynamically removed (Re: Linux 3.7.5)

[Jonathan Nieder]

Hi Holger,

Holger Hoffstaette wrote:
>> On Mon, Jan 28, 2013 at 12:42:16PM +0100, Holger Hoffstaette wrote:

>>> Apologies for being late but I'm afraid I just found at least one
>>> regression in this release.
>>>
>>> I have an external HDD in an USB3 enclosure for the occasional backup. I
>>> turn it on, it gets registered as sdX, I mount it/use it/unmount it and
>>> turn it off, which worked fine with kernels including 3.7.4. With 3.7.5
>
> FWIW it didn't really work with 3.7.4 either - just didn't notice before.
>
>>> the kernel seems no longer notified of the changed device power status;
>>> nothing in dmesg and the device stays in the list of SCSI devices as
>>> e.g. shown by lsscsi. This is repeatable. Turning the device back
>>> on/using it works fine, it's just that I cannot dynamically remove it
>>> any longer.
[...]
> No, current 3.8-rc5 did not work either. I first found 3.7.2 OK and 3.7.3
> bad. Bisecting found:
>
> --snip--
> f7965c0846d74b270e246c1470ca955d5078eb07 is the first bad commit
> commit f7965c0846d74b270e246c1470ca955d5078eb07
> Author: Sarah Sharp 
> Date:   Wed Nov 14 17:58:04 2012 -0800
>
> USB: Handle warm reset failure on empty port.
>
> commit 65bdac5effd15d6af619b3b7218627ef4d84ed6a upstream.
[...]
> Reverting this from 3.7.3 all the way to 3.8-rc5 makes USB 3.0
> disconnection/power-off device removal work again. Verified both on the
> bisection box and by now also the original machine.

Thanks for tracking this down.  Forwarding to relevant people.

Hope that helps,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[regression] external HDD in USB3 enclosure cannot be dynamically removed (Re: Linux 3.7.5)

[Jonathan Nieder]

Hi Holger,

Holger Hoffstaette wrote:
 On Mon, Jan 28, 2013 at 12:42:16PM +0100, Holger Hoffstaette wrote:

 Apologies for being late but I'm afraid I just found at least one
 regression in this release.

 I have an external HDD in an USB3 enclosure for the occasional backup. I
 turn it on, it gets registered as sdX, I mount it/use it/unmount it and
 turn it off, which worked fine with kernels including 3.7.4. With 3.7.5

 FWIW it didn't really work with 3.7.4 either - just didn't notice before.

 the kernel seems no longer notified of the changed device power status;
 nothing in dmesg and the device stays in the list of SCSI devices as
 e.g. shown by lsscsi. This is repeatable. Turning the device back
 on/using it works fine, it's just that I cannot dynamically remove it
 any longer.
[...]
 No, current 3.8-rc5 did not work either. I first found 3.7.2 OK and 3.7.3
 bad. Bisecting found:

 --snip--
 f7965c0846d74b270e246c1470ca955d5078eb07 is the first bad commit
 commit f7965c0846d74b270e246c1470ca955d5078eb07
 Author: Sarah Sharp sarah.a.sh...@linux.intel.com
 Date:   Wed Nov 14 17:58:04 2012 -0800

 USB: Handle warm reset failure on empty port.

 commit 65bdac5effd15d6af619b3b7218627ef4d84ed6a upstream.
[...]
 Reverting this from 3.7.3 all the way to 3.8-rc5 makes USB 3.0
 disconnection/power-off device removal work again. Verified both on the
 bisection box and by now also the original machine.

Thanks for tracking this down.  Forwarding to relevant people.

Hope that helps,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bug#695182: [PATCH] Subtract min_free_kbytes from dirtyable memory

[Jonathan Nieder]

Hi Paul,

Ben Hutchings wrote:

> If you can identify where it was fixed then your patch for older
> versions should go to stable with a reference to the upstream fix (see
> Documentation/stable_kernel_rules.txt).

How about this patch?

It was applied in mainline during the 3.3 merge window, so kernels
newer than 3.2.y shouldn't need it.

-- >8 --
From: Johannes Weiner 
Date: Tue, 10 Jan 2012 15:07:42 -0800
Subject: mm: exclude reserved pages from dirtyable memory

commit ab8fabd46f811d5153d8a0cd2fac9a0d41fb593d upstream.

Per-zone dirty limits try to distribute page cache pages allocated for
writing across zones in proportion to the individual zone sizes, to reduce
the likelihood of reclaim having to write back individual pages from the
LRU lists in order to make progress.

This patch:

The amount of dirtyable pages should not include the full number of free
pages: there is a number of reserved pages that the page allocator and
kswapd always try to keep free.

The closer (reclaimable pages - dirty pages) is to the number of reserved
pages, the more likely it becomes for reclaim to run into dirty pages:

   +--+ ---
   |   anon   |  |
   +--+  |
   |  |  |
   |  |  -- dirty limit new-- flusher new
   |   file   |  | |
   |  |  | |
   |  |  -- dirty limit old-- flusher old
   |  ||
   +--+   --- reclaim
   | reserved |
   +--+
   |  kernel  |
   +--+

This patch introduces a per-zone dirty reserve that takes both the lowmem
reserve as well as the high watermark of the zone into account, and a
global sum of those per-zone values that is subtracted from the global
amount of dirtyable pages.  The lowmem reserve is unavailable to page
cache allocations and kswapd tries to keep the high watermark free.  We
don't want to end up in a situation where reclaim has to clean pages in
order to balance zones.

Not treating reserved pages as dirtyable on a global level is only a
conceptual fix.  In reality, dirty pages are not distributed equally
across zones and reclaim runs into dirty pages on a regular basis.

But it is important to get this right before tackling the problem on a
per-zone level, where the distance between reclaim and the dirty pages is
mostly much smaller in absolute numbers.

[a...@linux-foundation.org: fix highmem build]
Signed-off-by: Johannes Weiner 
Reviewed-by: Rik van Riel 
Reviewed-by: Michal Hocko 
Reviewed-by: Minchan Kim 
Acked-by: Mel Gorman 
Cc: KAMEZAWA Hiroyuki 
Cc: Christoph Hellwig 
Cc: Wu Fengguang 
Cc: Dave Chinner 
Cc: Jan Kara 
Cc: Shaohua Li 
Cc: Chris Mason 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jonathan Nieder 
---
 include/linux/mmzone.h |  6 ++
 include/linux/swap.h   |  1 +
 mm/page-writeback.c|  5 +++--
 mm/page_alloc.c| 19 +++
 4 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 25842b6e72e1..a594af3278bc 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -319,6 +319,12 @@ struct zone {
 */
unsigned long   lowmem_reserve[MAX_NR_ZONES];
 
+   /*
+* This is a per-zone reserve of pages that should not be
+* considered dirtyable memory.
+*/
+   unsigned long   dirty_balance_reserve;
+
 #ifdef CONFIG_NUMA
int node;
/*
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 67b3fa308988..3e60228e7299 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -207,6 +207,7 @@ struct swap_list_t {
 /* linux/mm/page_alloc.c */
 extern unsigned long totalram_pages;
 extern unsigned long totalreserve_pages;
+extern unsigned long dirty_balance_reserve;
 extern unsigned int nr_free_buffer_pages(void);
 extern unsigned int nr_free_pagecache_pages(void);
 
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 50f08241f981..f620e7b0dc26 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -320,7 +320,7 @@ static unsigned long highmem_dirtyable_memory(unsigned long 
total)
_DATA(node)->node_zones[ZONE_HIGHMEM];
 
x += zone_page_state(z, NR_FREE_PAGES) +
-zone_reclaimable_pages(z);
+zone_reclaimable_pages(z) - z->dirty_balance_reserve;
}
/*
 * Make sure that the number of highmem pages is never larger
@@ -344,7 +344,8 @@ unsigned long determine_dirtyable_memory(void)
 {
unsigned long x;
 
-   x = global_page_state(NR_FREE_PAGES) + global_reclaimable_pages();
+   x = global_page_state(NR_FREE_PAGES) + global_reclaimable_pages() -
+   dirty_balance_reserve;
 
if (!vm_highmem_is_dirtyable)
x -= highmem_dirtyable_memory(x);
diff --git a/mm

Re: [PATCH] Subtract min_free_kbytes from dirtyable memory

[Jonathan Nieder]

Hi Paul,

paul.sz...@sydney.edu.au wrote:
> Dear Ben,

>> If you can identify where it was fixed then ...
>
> Sorry I cannot do that. I have no idea where kernel changelogs are kept.

Here are some tools.

  # prerequisite:
  apt-get install git; # as root

  # to get the kernel history:
  git clone \
https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git
  cd linux

  # to view the changelog:
  git log v3.2..

  # to grep change descriptions:
  git log --grep=min_free_kbytes v3.2..

  # to view the patches corresponding to changes:
  git log --patch v3.2.. -- mm/

  # graphical interface
  apt-get install gitk; # as root
  gitk v3.2.. -- mm

  # web interface:
  w3m http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git

The "exploring git history" section of the git user manual has more
details:

  http://git-htmldocs.googlecode.com/git/user-manual.html#exploring-git-history

Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Subtract min_free_kbytes from dirtyable memory

[Jonathan Nieder]

Hi Paul,

paul.sz...@sydney.edu.au wrote:
 Dear Ben,

 If you can identify where it was fixed then ...

 Sorry I cannot do that. I have no idea where kernel changelogs are kept.

Here are some tools.

  # prerequisite:
  apt-get install git; # as root

  # to get the kernel history:
  git clone \
https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git
  cd linux

  # to view the changelog:
  git log v3.2..

  # to grep change descriptions:
  git log --grep=min_free_kbytes v3.2..

  # to view the patches corresponding to changes:
  git log --patch v3.2.. -- mm/

  # graphical interface
  apt-get install gitk; # as root
  gitk v3.2.. -- mm

  # web interface:
  w3m http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git

The exploring git history section of the git user manual has more
details:

  http://git-htmldocs.googlecode.com/git/user-manual.html#exploring-git-history

Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bug#695182: [PATCH] Subtract min_free_kbytes from dirtyable memory

[Jonathan Nieder]

Hi Paul,

Ben Hutchings wrote:

 If you can identify where it was fixed then your patch for older
 versions should go to stable with a reference to the upstream fix (see
 Documentation/stable_kernel_rules.txt).

How about this patch?

It was applied in mainline during the 3.3 merge window, so kernels
newer than 3.2.y shouldn't need it.

-- 8 --
From: Johannes Weiner jwei...@redhat.com
Date: Tue, 10 Jan 2012 15:07:42 -0800
Subject: mm: exclude reserved pages from dirtyable memory

commit ab8fabd46f811d5153d8a0cd2fac9a0d41fb593d upstream.

Per-zone dirty limits try to distribute page cache pages allocated for
writing across zones in proportion to the individual zone sizes, to reduce
the likelihood of reclaim having to write back individual pages from the
LRU lists in order to make progress.

This patch:

The amount of dirtyable pages should not include the full number of free
pages: there is a number of reserved pages that the page allocator and
kswapd always try to keep free.

The closer (reclaimable pages - dirty pages) is to the number of reserved
pages, the more likely it becomes for reclaim to run into dirty pages:

   +--+ ---
   |   anon   |  |
   +--+  |
   |  |  |
   |  |  -- dirty limit new-- flusher new
   |   file   |  | |
   |  |  | |
   |  |  -- dirty limit old-- flusher old
   |  ||
   +--+   --- reclaim
   | reserved |
   +--+
   |  kernel  |
   +--+

This patch introduces a per-zone dirty reserve that takes both the lowmem
reserve as well as the high watermark of the zone into account, and a
global sum of those per-zone values that is subtracted from the global
amount of dirtyable pages.  The lowmem reserve is unavailable to page
cache allocations and kswapd tries to keep the high watermark free.  We
don't want to end up in a situation where reclaim has to clean pages in
order to balance zones.

Not treating reserved pages as dirtyable on a global level is only a
conceptual fix.  In reality, dirty pages are not distributed equally
across zones and reclaim runs into dirty pages on a regular basis.

But it is important to get this right before tackling the problem on a
per-zone level, where the distance between reclaim and the dirty pages is
mostly much smaller in absolute numbers.

[a...@linux-foundation.org: fix highmem build]
Signed-off-by: Johannes Weiner jwei...@redhat.com
Reviewed-by: Rik van Riel r...@redhat.com
Reviewed-by: Michal Hocko mho...@suse.cz
Reviewed-by: Minchan Kim minchan@gmail.com
Acked-by: Mel Gorman mgor...@suse.de
Cc: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Cc: Christoph Hellwig h...@infradead.org
Cc: Wu Fengguang fengguang...@intel.com
Cc: Dave Chinner da...@fromorbit.com
Cc: Jan Kara j...@suse.cz
Cc: Shaohua Li shaohua...@intel.com
Cc: Chris Mason chris.ma...@oracle.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
 include/linux/mmzone.h |  6 ++
 include/linux/swap.h   |  1 +
 mm/page-writeback.c|  5 +++--
 mm/page_alloc.c| 19 +++
 4 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 25842b6e72e1..a594af3278bc 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -319,6 +319,12 @@ struct zone {
 */
unsigned long   lowmem_reserve[MAX_NR_ZONES];
 
+   /*
+* This is a per-zone reserve of pages that should not be
+* considered dirtyable memory.
+*/
+   unsigned long   dirty_balance_reserve;
+
 #ifdef CONFIG_NUMA
int node;
/*
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 67b3fa308988..3e60228e7299 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -207,6 +207,7 @@ struct swap_list_t {
 /* linux/mm/page_alloc.c */
 extern unsigned long totalram_pages;
 extern unsigned long totalreserve_pages;
+extern unsigned long dirty_balance_reserve;
 extern unsigned int nr_free_buffer_pages(void);
 extern unsigned int nr_free_pagecache_pages(void);
 
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 50f08241f981..f620e7b0dc26 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -320,7 +320,7 @@ static unsigned long highmem_dirtyable_memory(unsigned long 
total)
NODE_DATA(node)-node_zones[ZONE_HIGHMEM];
 
x += zone_page_state(z, NR_FREE_PAGES) +
-zone_reclaimable_pages(z);
+zone_reclaimable_pages(z) - z-dirty_balance_reserve;
}
/*
 * Make sure that the number of highmem pages is never larger
@@ -344,7 +344,8 @@ unsigned long determine_dirtyable_memory(void)
 {
unsigned long x

Re: [ 000/123] 3.7.2-stable review

[Jonathan Nieder]

Shuah Khan wrote:

> Patches applied cleanly to 3.0.y, 3.4.y, and 3.7.y.
> Compiled and booted on the following systems:
> HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz
> HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics
>
> Cross-compile tests:

Thanks much for these sanity checks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 000/123] 3.7.2-stable review

[Jonathan Nieder]

Shuah Khan wrote:

 Patches applied cleanly to 3.0.y, 3.4.y, and 3.7.y.
 Compiled and booted on the following systems:
 HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz
 HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics

 Cross-compile tests:

Thanks much for these sanity checks.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails

[Jonathan Nieder]

Stanislaw Gruszka wrote:
> On Sun, Dec 30, 2012 at 01:42:37PM +0100, Ben Hutchings wrote:

>> To be clear, I have all of these in the queue:
>>
>> be03d4a45c09 rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe 
>> fails
>> 5b632fe85ec8 mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL
>> ab9d6e4ffe19 Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU 
>> subframe fails"
>>
>> and I'm intending to drop/defer them all.
>
> Patch 3 is a revert of patch 1 (questioned patch). Please apply all 3 patches,
> or only patch 2.

Despite its title, isn't patch 3 not exactly a revert?  It includes a
change that depends on patch 2.  I don't think patch 2 alone would
have any effect.

Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails

[Jonathan Nieder]

Stanislaw Gruszka wrote:
 On Sun, Dec 30, 2012 at 01:42:37PM +0100, Ben Hutchings wrote:

 To be clear, I have all of these in the queue:

 be03d4a45c09 rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe 
 fails
 5b632fe85ec8 mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL
 ab9d6e4ffe19 Revert: rt2x00: Don't let mac80211 send a BAR when an AMPDU 
 subframe fails

 and I'm intending to drop/defer them all.

 Patch 3 is a revert of patch 1 (questioned patch). Please apply all 3 patches,
 or only patch 2.

Despite its title, isn't patch 3 not exactly a revert?  It includes a
change that depends on patch 2.  I don't think patch 2 alone would
have any effect.

Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 016/173] use clamp_t in UNAME26 fix

[Jonathan Nieder]

Ben Hutchings wrote:
> On Sat, 2012-12-29 at 00:07 -0800, Jonathan Nieder wrote:
>> Ben Hutchings wrote:

>>> The min/max call needed to have explicit types on some architectures
>>> (e.g. mn10300). Use clamp_t instead to avoid the warning:
>>>
>>>   kernel/sys.c: In function 'override_release':
>>>   kernel/sys.c:1287:10: warning: comparison of distinct pointer types lacks 
>>> a cast [enabled by default]
>>>
>>> Reported-by: Fengguang Wu 
>> [...]
>>> -   copy = min(sizeof(buf), max_t(size_t, 1, len));
>>
>> I don't understand how this happens given that v2.6.36-rc1~68
>> (MN10300: Fix size_t and ssize_t, 2010-08-12) was supposed to fix this
>> kind of thing.
> [...]
>
> Neither do I, but I'm including it now just to be consistent with other
> stable series.

Thanks for explaining.  That makes sense and the patch is harmless, so
why not.

The patch still leaves me worried that there might be more problems
lurking on mn10300, but that's more of a question for upstream.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 024/173] drm/i915: add Ivy Bridge GT2 Server entries

[Jonathan Nieder]

Ben Hutchings wrote:

> This adds PCI ID for IVB GT2 server variant which we were missing.

As discussed at [1], this triggers a small regression with Debian
wheezy userspace (X freezing instead of erroring out).  libdrm hasn't
been updated in wheezy since then, and I wouldn't be surprised if
other distros were affected, too.  Has there been a kernel patch since
then to avoid that?

Though I wouldn't mind seeing this applied anyway, FWIW, as long as
the announcement mentions the userspace bugfix needed.

Thanks,
Jonathan

[1] 
http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/978320/focus=74843
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 016/173] use clamp_t in UNAME26 fix

[Jonathan Nieder]

Ben Hutchings wrote:

> The min/max call needed to have explicit types on some architectures
> (e.g. mn10300). Use clamp_t instead to avoid the warning:
> 
>   kernel/sys.c: In function 'override_release':
>   kernel/sys.c:1287:10: warning: comparison of distinct pointer types lacks a 
> cast [enabled by default]
>
> Reported-by: Fengguang Wu 
[...]
> - copy = min(sizeof(buf), max_t(size_t, 1, len));

I don't understand how this happens given that v2.6.36-rc1~68
(MN10300: Fix size_t and ssize_t, 2010-08-12) was supposed to fix this
kind of thing.  Doesn't sizeof(buf) have type size_t already (C99
§6.5.3.4 "the sizeof operator" ¶4)?

What version of gcc produces this warning?

Puzzled,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 016/173] use clamp_t in UNAME26 fix

[Jonathan Nieder]

Ben Hutchings wrote:

 The min/max call needed to have explicit types on some architectures
 (e.g. mn10300). Use clamp_t instead to avoid the warning:
 
   kernel/sys.c: In function 'override_release':
   kernel/sys.c:1287:10: warning: comparison of distinct pointer types lacks a 
 cast [enabled by default]

 Reported-by: Fengguang Wu fengguang...@intel.com
[...]
 - copy = min(sizeof(buf), max_t(size_t, 1, len));

I don't understand how this happens given that v2.6.36-rc1~68
(MN10300: Fix size_t and ssize_t, 2010-08-12) was supposed to fix this
kind of thing.  Doesn't sizeof(buf) have type size_t already (C99
§6.5.3.4 the sizeof operator ¶4)?

What version of gcc produces this warning?

Puzzled,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 024/173] drm/i915: add Ivy Bridge GT2 Server entries

[Jonathan Nieder]

Ben Hutchings wrote:

 This adds PCI ID for IVB GT2 server variant which we were missing.

As discussed at [1], this triggers a small regression with Debian
wheezy userspace (X freezing instead of erroring out).  libdrm hasn't
been updated in wheezy since then, and I wouldn't be surprised if
other distros were affected, too.  Has there been a kernel patch since
then to avoid that?

Though I wouldn't mind seeing this applied anyway, FWIW, as long as
the announcement mentions the userspace bugfix needed.

Thanks,
Jonathan

[1] 
http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/978320/focus=74843
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 016/173] use clamp_t in UNAME26 fix

[Jonathan Nieder]

Ben Hutchings wrote:
 On Sat, 2012-12-29 at 00:07 -0800, Jonathan Nieder wrote:
 Ben Hutchings wrote:

 The min/max call needed to have explicit types on some architectures
 (e.g. mn10300). Use clamp_t instead to avoid the warning:

   kernel/sys.c: In function 'override_release':
   kernel/sys.c:1287:10: warning: comparison of distinct pointer types lacks 
 a cast [enabled by default]

 Reported-by: Fengguang Wu fengguang...@intel.com
 [...]
 -   copy = min(sizeof(buf), max_t(size_t, 1, len));

 I don't understand how this happens given that v2.6.36-rc1~68
 (MN10300: Fix size_t and ssize_t, 2010-08-12) was supposed to fix this
 kind of thing.
 [...]

 Neither do I, but I'm including it now just to be consistent with other
 stable series.

Thanks for explaining.  That makes sense and the patch is harmless, so
why not.

The patch still leaves me worried that there might be more problems
lurking on mn10300, but that's more of a question for upstream.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6.32.y, 2.6.34.y] Re: [PATCH] x86: Don't use the EFI reboot method by default

[Jonathan Nieder]

Hi Willy et al,

Please consider

  f70e957cda22 x86: Don't use the EFI reboot method by default,
   2011-07-06

for application to the 2.6.32.y and 2.6.34.y trees.  The patch was
applied upstream late in the 3.0 cycle, so newer kernels don't need
it.

In 2011, Keith Ward wrote[1]:

> When attempting to reboot my my UEFI enabled system, the system hangs when
> calling reboot requiring me to manually reset the system via the reset switch.
>
> Screenshot: http://twitgoo.com/29bq1c

Ben Hutchings writes[1]:

> Version: 3.0.0-1
>
> I also had this problem on my own system, but it is fixed now.
> I bisected the fix to:
>
> commit f70e957cda22d309c769805cbb932407a5232219
> Author: Matthew Garrett 
> Date:   Wed Jul 6 16:52:37 2011 -0400
>
> x86: Don't use the EFI reboot method by default
>
> which is basically equivalent to the workaround!
>
> I'll also apply this fix to squeeze as it's so simple.

Keith Ward also wrote[1]:

> It seems as if this has recently been reported at Ubuntu's Launchpad as well:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/721576

There are a variety of reports of the same panic at that bug on
2.6.32.y-, 2.6.38.y-, and 2.6.39-based kernels.  Passing "reboot=a,w"
on the kernel command line avoids trouble for reporters.

Regards,
Jonathan

[1] http://bugs.debian.org/626022
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6.32.y, 2.6.34.y] Re: [PATCH] x86: Don't use the EFI reboot method by default

[Jonathan Nieder]

Hi Willy et al,

Please consider

  f70e957cda22 x86: Don't use the EFI reboot method by default,
   2011-07-06

for application to the 2.6.32.y and 2.6.34.y trees.  The patch was
applied upstream late in the 3.0 cycle, so newer kernels don't need
it.

In 2011, Keith Ward wrote[1]:

 When attempting to reboot my my UEFI enabled system, the system hangs when
 calling reboot requiring me to manually reset the system via the reset switch.

 Screenshot: http://twitgoo.com/29bq1c

Ben Hutchings writes[1]:

 Version: 3.0.0-1

 I also had this problem on my own system, but it is fixed now.
 I bisected the fix to:

 commit f70e957cda22d309c769805cbb932407a5232219
 Author: Matthew Garrett m...@redhat.com
 Date:   Wed Jul 6 16:52:37 2011 -0400

 x86: Don't use the EFI reboot method by default

 which is basically equivalent to the workaround!

 I'll also apply this fix to squeeze as it's so simple.

Keith Ward also wrote[1]:

 It seems as if this has recently been reported at Ubuntu's Launchpad as well:
 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/721576

There are a variety of reports of the same panic at that bug on
2.6.32.y-, 2.6.38.y-, and 2.6.39-based kernels.  Passing reboot=a,w
on the kernel command line avoids trouble for reporters.

Regards,
Jonathan

[1] http://bugs.debian.org/626022
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 036/270] kbuild: Do not package /boot and /lib in make tar-pkg

[Jonathan Nieder]

Greg Kroah-Hartman wrote:
> On Tue, Nov 27, 2012 at 02:26:27AM +, Ben Hutchings wrote:
>> On Mon, 2012-11-26 at 14:55 -0200, Herton Ronaldo Krzesinski wrote:

>>> commit fe04ddf7c2910362f3817c8156e41cbd6c0ee35d upstream.
>>>
>>> There were reports of users destroying their Fedora installs by a kernel
>>> tarball that replaces the /lib -> /usr/lib symlink. Let's remove the
>>> toplevel directories from the tarball to prevent this from happening.
>>> 
>>> Reported-by: Andi Kleen 
>>> Suggested-by: Ben Hutchings 
>>> Signed-off-by: Michal Marek 
>>> [ herton: dropped unrelated changes to arch/x86/Makefile and
>>>   scripts/Makefile.fwinst, which don't apply anyway on 3.5, see commit
>>>   3ce9e53e71da0d5f3912f80e0dd6b501f304 upstream ]
>>> Signed-off-by: Herton Ronaldo Krzesinski 
>>
>> This is missing from 3.4.
>
> I don't think it is needed, as 3ce9e53e71da0d5f3912f80e0dd6b501f304
> didn't go into 3.4, so all should be good for now.

The dependency's the other way around.  Herton's comment above means
to say that 3ce9e53 is being squashed in as a fixup.

Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 036/270] kbuild: Do not package /boot and /lib in make tar-pkg

[Jonathan Nieder]

Greg Kroah-Hartman wrote:
 On Tue, Nov 27, 2012 at 02:26:27AM +, Ben Hutchings wrote:
 On Mon, 2012-11-26 at 14:55 -0200, Herton Ronaldo Krzesinski wrote:

 commit fe04ddf7c2910362f3817c8156e41cbd6c0ee35d upstream.

 There were reports of users destroying their Fedora installs by a kernel
 tarball that replaces the /lib - /usr/lib symlink. Let's remove the
 toplevel directories from the tarball to prevent this from happening.
 
 Reported-by: Andi Kleen a...@firstfloor.org
 Suggested-by: Ben Hutchings b...@decadent.org.uk
 Signed-off-by: Michal Marek mma...@suse.cz
 [ herton: dropped unrelated changes to arch/x86/Makefile and
   scripts/Makefile.fwinst, which don't apply anyway on 3.5, see commit
   3ce9e53e71da0d5f3912f80e0dd6b501f304 upstream ]
 Signed-off-by: Herton Ronaldo Krzesinski herton.krzesin...@canonical.com

 This is missing from 3.4.

 I don't think it is needed, as 3ce9e53e71da0d5f3912f80e0dd6b501f304
 didn't go into 3.4, so all should be good for now.

The dependency's the other way around.  Herton's comment above means
to say that 3ce9e53 is being squashed in as a fixup.

Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[3.0.y, 3.2.y, 3.4.y] Re: [PATCH v2] r8169: Fix WoL on RTL8168d/8111d.

[Jonathan Nieder]

Francois Romieu wrote:
> Cyril Brulebois  :

>> This regression was spotted between Debian squeeze and Debian wheezy
>> kernels (respectively based on 2.6.32 and 3.2). More info about
>> Wake-on-LAN issues with Realtek's 816x chipsets can be found in the
>> following thread: http://marc.info/?t=13207921944
>
> David, please apply to -net.

This has been applied as commit b00e69dee4cc in mainline; thanks!

François and David, would this be a candidate for inclusion in
3.0- and newer stable kernels?

Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[3.0.y, 3.2.y, 3.4.y] Re: [PATCH v2] r8169: Fix WoL on RTL8168d/8111d.

[Jonathan Nieder]

Francois Romieu wrote:
 Cyril Brulebois k...@debian.org :

 This regression was spotted between Debian squeeze and Debian wheezy
 kernels (respectively based on 2.6.32 and 3.2). More info about
 Wake-on-LAN issues with Realtek's 816x chipsets can be found in the
 following thread: http://marc.info/?t=13207921944

 David, please apply to -net.

This has been applied as commit b00e69dee4cc in mainline; thanks!

François and David, would this be a candidate for inclusion in
3.0- and newer stable kernels?

Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] Extended stable support for Linux 3.5 (linux-3.5.y-ext.z)

[Jonathan Nieder]

Hi Herton,

Herton Ronaldo Krzesinski wrote:

> I plan to do a similar workflow as to what is done today with current
> stable releases. I'll send email notifications to everyone involved in
> each patch when it's added to 3.5 queue, and post the patches for review
> for each release cycle. Just versioning will be slightly different,
> every version is planned to be tagged as v3.5.7-ext.,
> ext meaning extended, 3.5.7 was the last stable kernel in 3.5 kernel and
> should remain constant.

Thanks for your work.  Is there a reason not to work with Greg to
release these on kernel.org with increasing 3.5.8, 3.5.9, etc version
numbers?

Curious,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] Extended stable support for Linux 3.5 (linux-3.5.y-ext.z)

[Jonathan Nieder]

Hi Herton,

Herton Ronaldo Krzesinski wrote:

 I plan to do a similar workflow as to what is done today with current
 stable releases. I'll send email notifications to everyone involved in
 each patch when it's added to 3.5 queue, and post the patches for review
 for each release cycle. Just versioning will be slightly different,
 every version is planned to be tagged as v3.5.7-ext.release number,
 ext meaning extended, 3.5.7 was the last stable kernel in 3.5 kernel and
 should remain constant.

Thanks for your work.  Is there a reason not to work with Greg to
release these on kernel.org with increasing 3.5.8, 3.5.9, etc version
numbers?

Curious,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[regression] Re: [ 049/149] rtc: Disable the alarm in the hardware (v2)

[Jonathan Nieder]

Hi,

In March, Greg KH wrote:

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

Sorry, I'm a little late.  This seems to be causing spurious wakeups
after shutdown on some systems just like v1 did. :/

Janne Boman reports[1], using an HP EliteBook 8530w:

| I'm unable to shutdown my system via normal means. The system
| completes the shutdown process, all hardware lights are off, but then
| somehow it restarts.

Based on a quick web search, Heinz Wiesinger, using the same model,
ran into the same problem and bisected it to this patch:

  https://bugzilla.kernel.org/show_bug.cgi?id=44261

Janne confirmed the same by testing kernels closely based on 3.2.13
and 3.2.14 --- 3.2.13 shut down fine, while on 3.2.14 "shutdown -h
now" behaved roughly speaking like "reboot".  A kernel close to 3.6.4
was also affected.

Known problem?  An acpidump and kernel log can be found at [2].

Looking forward to your thoughts,
Jonathan

[1] http://bugs.debian.org/691902
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=78;bug=691902
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[regression] Re: [ 049/149] rtc: Disable the alarm in the hardware (v2)

[Jonathan Nieder]

Hi,

In March, Greg KH wrote:

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

Sorry, I'm a little late.  This seems to be causing spurious wakeups
after shutdown on some systems just like v1 did. :/

Janne Boman reports[1], using an HP EliteBook 8530w:

| I'm unable to shutdown my system via normal means. The system
| completes the shutdown process, all hardware lights are off, but then
| somehow it restarts.

Based on a quick web search, Heinz Wiesinger, using the same model,
ran into the same problem and bisected it to this patch:

  https://bugzilla.kernel.org/show_bug.cgi?id=44261

Janne confirmed the same by testing kernels closely based on 3.2.13
and 3.2.14 --- 3.2.13 shut down fine, while on 3.2.14 shutdown -h
now behaved roughly speaking like reboot.  A kernel close to 3.6.4
was also affected.

Known problem?  An acpidump and kernel log can be found at [2].

Looking forward to your thoughts,
Jonathan

[1] http://bugs.debian.org/691902
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=78;bug=691902
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] samsung-laptop: Disable if CONFIG_EFI=y

[Jonathan Nieder]

Matt Fleming wrote:

> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -717,7 +717,7 @@ config XO15_EBOOK
> 
>  config SAMSUNG_LAPTOP
>   tristate "Samsung Laptop driver"
> - depends on X86
> + depends on X86 && !EFI

That means distros would just not get the samsung-laptop driver.
Is there a runtime check that could be used instead?

Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] samsung-laptop: Disable if CONFIG_EFI=y

[Jonathan Nieder]

Matt Fleming wrote:

 --- a/drivers/platform/x86/Kconfig
 +++ b/drivers/platform/x86/Kconfig
 @@ -717,7 +717,7 @@ config XO15_EBOOK
 
  config SAMSUNG_LAPTOP
   tristate Samsung Laptop driver
 - depends on X86
 + depends on X86  !EFI

That means distros would just not get the samsung-laptop driver.
Is there a runtime check that could be used instead?

Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] lockd: fix races in per-net NSM client handling

[Jonathan Nieder]

Hi,

Greg KH wrote:
> On Wed, Oct 31, 2012 at 06:27:36PM +0100, Paweł Sikora wrote:

>> the patch metioned in https://lkml.org/lkml/2012/10/24/175 seems to fix
>> the 3.6.3 oops (while 3.6.2 works fine) at 16-cores opteron server.
>> please queue this path for 3.6.$next.
>
> Is it in Linus's tree already?  If so, what is the git commit id?

One of

  a4ee8d978e47 LOCKD: fix races in nsm_client_get
  e498daa81295 LOCKD: Clear ln->nsm_clnt only when ln->nsm_users is zero

both of which were included in v3.6.5.

Hope that helps,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] lockd: fix races in per-net NSM client handling

[Jonathan Nieder]

Hi,

Greg KH wrote:
 On Wed, Oct 31, 2012 at 06:27:36PM +0100, Paweł Sikora wrote:

 the patch metioned in https://lkml.org/lkml/2012/10/24/175 seems to fix
 the 3.6.3 oops (while 3.6.2 works fine) at 16-cores opteron server.
 please queue this path for 3.6.$next.

 Is it in Linus's tree already?  If so, what is the git commit id?

One of

  a4ee8d978e47 LOCKD: fix races in nsm_client_get
  e498daa81295 LOCKD: Clear ln-nsm_clnt only when ln-nsm_users is zero

both of which were included in v3.6.5.

Hope that helps,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 026/105] ACPI: EC: Make the GPE storm threshold a module parameter

[Jonathan Nieder]

Ben Hutchings wrote:

> 3.2-stable review patch.  If anyone has any objections, please let me know.
[...]
> commit a520d52e99b14ba7db135e916348f12f2a6e09be upstream.
>
> The Linux EC driver includes a mechanism to detect GPE storms,
> and switch from interrupt-mode to polling mode.  However, polling
> mode sometimes doesn't work, so the workaround is problematic.
> Also, different systems seem to need the threshold for detecting
> the GPE storm at different levels.

Not an objection, but this is a weird parameter.  How many false
interrupts per transaction should be expected?  Is there some fact
about the hardware or firmware that makes this a well defined number
on each machine?

Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 026/105] ACPI: EC: Make the GPE storm threshold a module parameter

[Jonathan Nieder]

Ben Hutchings wrote:

 3.2-stable review patch.  If anyone has any objections, please let me know.
[...]
 commit a520d52e99b14ba7db135e916348f12f2a6e09be upstream.

 The Linux EC driver includes a mechanism to detect GPE storms,
 and switch from interrupt-mode to polling mode.  However, polling
 mode sometimes doesn't work, so the workaround is problematic.
 Also, different systems seem to need the threshold for detecting
 the GPE storm at different levels.

Not an objection, but this is a weird parameter.  How many false
interrupts per transaction should be expected?  Is there some fact
about the hardware or firmware that makes this a well defined number
on each machine?

Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 08/31] use clamp_t in UNAME26 fix

[Jonathan Nieder]

Greg Kroah-Hartman wrote:
> On Thu, Oct 25, 2012 at 05:11:19PM -0700, Jonathan Nieder wrote:
>> Greg Kroah-Hartman wrote:

>>> v = ((LINUX_VERSION_CODE >> 8) & 0xff) + 40;
>>> -   copy = min(sizeof(buf), max_t(size_t, 1, len));
>>> +   copy = clamp_t(size_t, len, 1, sizeof(buf));
>>> copy = scnprintf(buf, copy, "2.6.%u%s", v, rest);
>>
>> Does this have any effect at runtime?  If not, why is it needed for
>> stable kernels?
>
> It's a bugfix for the previous patch in this area, fixing the build
> warning.  I don't like adding stable patches that add new warnings :)

Ok, that's fair.  Thanks for explaining.

Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 08/31] use clamp_t in UNAME26 fix

[Jonathan Nieder]

Greg Kroah-Hartman wrote:
 On Thu, Oct 25, 2012 at 05:11:19PM -0700, Jonathan Nieder wrote:
 Greg Kroah-Hartman wrote:

 v = ((LINUX_VERSION_CODE  8)  0xff) + 40;
 -   copy = min(sizeof(buf), max_t(size_t, 1, len));
 +   copy = clamp_t(size_t, len, 1, sizeof(buf));
 copy = scnprintf(buf, copy, 2.6.%u%s, v, rest);

 Does this have any effect at runtime?  If not, why is it needed for
 stable kernels?

 It's a bugfix for the previous patch in this area, fixing the build
 warning.  I don't like adding stable patches that add new warnings :)

Ok, that's fair.  Thanks for explaining.

Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 08/31] use clamp_t in UNAME26 fix

[Jonathan Nieder]

Hi,

Greg Kroah-Hartman wrote:

> commit 31fd84b95eb211d5db460a1dda85e004800a7b52 upstream.
>
> The min/max call needed to have explicit types on some architectures
> (e.g. mn10300). Use clamp_t instead to avoid the warning:
>
>   kernel/sys.c: In function 'override_release':
>   kernel/sys.c:1287:10: warning: comparison of distinct pointer types lacks a 
> cast [enabled by default]
>
> Reported-by: Fengguang Wu 
> Signed-off-by: Kees Cook 
> Signed-off-by: Linus Torvalds 
> Signed-off-by: Greg Kroah-Hartman 
[...]
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -1152,7 +1152,7 @@ static int override_release(char __user
>   rest++;
>   }
>   v = ((LINUX_VERSION_CODE >> 8) & 0xff) + 40;
> - copy = min(sizeof(buf), max_t(size_t, 1, len));
> + copy = clamp_t(size_t, len, 1, sizeof(buf));
>   copy = scnprintf(buf, copy, "2.6.%u%s", v, rest);

Does this have any effect at runtime?  If not, why is it needed for
stable kernels?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 08/31] use clamp_t in UNAME26 fix

[Jonathan Nieder]

Hi,

Greg Kroah-Hartman wrote:

 commit 31fd84b95eb211d5db460a1dda85e004800a7b52 upstream.

 The min/max call needed to have explicit types on some architectures
 (e.g. mn10300). Use clamp_t instead to avoid the warning:

   kernel/sys.c: In function 'override_release':
   kernel/sys.c:1287:10: warning: comparison of distinct pointer types lacks a 
 cast [enabled by default]

 Reported-by: Fengguang Wu fengguang...@intel.com
 Signed-off-by: Kees Cook keesc...@chromium.org
 Signed-off-by: Linus Torvalds torva...@linux-foundation.org
 Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
[...]
 --- a/kernel/sys.c
 +++ b/kernel/sys.c
 @@ -1152,7 +1152,7 @@ static int override_release(char __user
   rest++;
   }
   v = ((LINUX_VERSION_CODE  8)  0xff) + 40;
 - copy = min(sizeof(buf), max_t(size_t, 1, len));
 + copy = clamp_t(size_t, len, 1, sizeof(buf));
   copy = scnprintf(buf, copy, 2.6.%u%s, v, rest);

Does this have any effect at runtime?  If not, why is it needed for
stable kernels?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/PATCH 2.6.32.y 0/3] Re: [stable 2.6.32..2.6.34] x86, ioapic: initialize nr_ioapic_registers early in mp_register_ioapic()

[Jonathan Nieder]

Suresh Siddha wrote:

>   Here is the updated patch with just some
> more text added to the changelog.

Yes, that's clearer.  For what it's worth,
Reviewed-by: Jonathan Nieder 

Thanks for your patience.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] x86, ioapic: Move nr_ioapic_registers calculation to mp_register_ioapic.

[Jonathan Nieder]

From: "Eric W. Biederman" 
Date: Tue, 30 Mar 2010 01:07:12 -0700

commit 7716a5c4ff5f1f3dc5e9edcab125cbf7fceef0af upstream.

Now that all ioapic registration happens in mp_register_ioapic we can
move the calculation of nr_ioapic_registers there from enable_IO_APIC.
The number of ioapic registers is already calucated in mp_register_ioapic
so all that really needs to be done is to save the caluclated value
in nr_ioapic_registers.

[suresh.b.sid...@intel.com: backport to 2.6.32.y and 2.6.34.y:

 Lin Bao reported that one of the HP platforms failed to boot
 2.6.32 kernel, when the BIOS enabled interrupt-remapping and
 x2apic before handing over the control to the Linux kernel.

 During boot, Linux kernel masks all the interrupt sources
 (8259, IO-APIC RTE's), setup the interrupt-remapping hardware
 with the OS controlled table and unmasks the 8259 interrupts
 but not the IO-APIC RTE's (as the newly setup interrupt-remapping
 table and the IO-APIC RTE's are not yet programmed by the kernel).

 Shortly after this, IO-APIC RTE's and the interrupt-remapping table
 entries are programmed based on the ACPI tables etc. So the
 expectation is that any interrupt during this window will be dropped
 and not see the intermediate configuration.

 In the reported problematic case, BIOS has configured the IO-APIC
 in virtual wire-B mode. Between the window of the kernel setting up
 new interrupt-remapping table  and the IO-APIC RTE's are properly
 configured, an interrupt gets routed by the IO-APIC RTE (setup
 by the virtual wire-B configuration) and sees the empty
 interrupt-remapping table entry, resulting in vt-d fault causing
 the platform to generate NMI. And the OS panics on this unexpected NMI.

 This problem doesn't happen with more recent kernels and closer
 look at the 2.6.32 kernel shows that the code which masks
 the IO-APIC RTE's is not working as expected as the nr_ioapic_registers
 for each IO-APIC is not yet initialized at this point. In the later
 kernels we initialize nr_ioapic_registers much before and
 everything works as expected.]

[jrnie...@gmail.com: include removal of nr_ioapic_registers calculation
 from enable_IO_APIC() to complete the backport]

Signed-off-by: Eric W. Biederman 
LKML-Reference: <1269936436-7039-11-git-send-email-ebied...@xmission.com>
Signed-off-by: H. Peter Anvin 
Reported-by: Zhang, Lin-Bao 
Signed-off-by: Suresh Siddha 
Signed-off-by: Jonathan Nieder 
---
 arch/x86/kernel/apic/io_apic.c | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 7a5087640599..6b7d97f1f5e5 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1945,20 +1945,8 @@ static struct { int pin, apic; } ioapic_i8259 = { -1, -1 
};
 
 void __init enable_IO_APIC(void)
 {
-   union IO_APIC_reg_01 reg_01;
int i8259_apic, i8259_pin;
int apic;
-   unsigned long flags;
-
-   /*
-* The number of IO-APIC IRQ registers (== #pins):
-*/
-   for (apic = 0; apic < nr_ioapics; apic++) {
-   spin_lock_irqsave(_lock, flags);
-   reg_01.raw = io_apic_read(apic, 1);
-   spin_unlock_irqrestore(_lock, flags);
-   nr_ioapic_registers[apic] = reg_01.bits.entries+1;
-   }
 
if (!nr_legacy_irqs)
return;
@@ -4265,6 +4253,7 @@ static int bad_ioapic(unsigned long address)
 void __init mp_register_ioapic(int id, u32 address, u32 gsi_base)
 {
int idx = 0;
+   int entries;
 
if (bad_ioapic(address))
return;
@@ -4283,9 +4272,14 @@ void __init mp_register_ioapic(int id, u32 address, u32 
gsi_base)
 * Build basic GSI lookup table to facilitate gsi->io_apic lookups
 * and to prevent reprogramming of IOAPIC pins (PCI GSIs).
 */
+   entries = io_apic_get_redir_entries(idx);
mp_gsi_routing[idx].gsi_base = gsi_base;
-   mp_gsi_routing[idx].gsi_end = gsi_base +
-   io_apic_get_redir_entries(idx);
+   mp_gsi_routing[idx].gsi_end = gsi_base + entries;
+
+   /*
+* The number of IO-APIC IRQ registers (== #pins):
+*/
+   nr_ioapic_registers[idx] = entries + 1;
 
if (mp_gsi_routing[idx].gsi_end > gsi_end)
gsi_end = mp_gsi_routing[idx].gsi_end;
-- 
1.8.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] x86, ioapic: In mpparse use mp_register_ioapic

[Jonathan Nieder]

From: "Eric W. Biederman" 
Date: Tue, 30 Mar 2010 01:07:11 -0700

commit cf7500c0ea133d66f8449d86392d83f84010263 upstream.

Long ago MP_ioapic_info was the primary way of setting up our
ioapic data structures and mp_register_ioapic was a compatibility
shim for acpi code.  Now the situation is reversed and
and mp_register_ioapic is the primary way of setting up our
ioapic data structures.

Keep the setting up of ioapic data structures uniform by
having mp_register_ioapic call mp_register_ioapic.

This changes a few fields:

- type: is now hardset to MP_IOAPIC but type had to
  bey MP_IOAPIC or MP_ioapic_info would not have been called.

- flags: is now hard coded to MPC_APIC_USABLE.
  We require flags to contain at least MPC_APIC_USEBLE in
  MP_ioapic_info and we don't ever examine flags so dropping
  a few flags that might possibly exist that we have never
  used is harmless.

- apicaddr: Unchanged

- apicver: Read from the ioapic instead of using the cached
  hardware value in the MP table.  The real hardware value
  will be more accurate.

- apicid: Now verified to be unique and changed if it is not.
  If the BIOS got this right this is a noop.  If the BIOS did
  not fixing things appears to be the better solution.

This adds gsi_base and gsi_end values to our ioapics defined with
the mpatable, which will make our lives simpler later since
we can always assume gsi_base and gsi_end are valid.

Signed-off-by: Eric W. Biederman 
LKML-Reference: <1269936436-7039-10-git-send-email-ebied...@xmission.com>
Signed-off-by: H. Peter Anvin 
Signed-off-by: Jonathan Nieder 
---
 arch/x86/kernel/mpparse.c | 25 +
 1 file changed, 1 insertion(+), 24 deletions(-)

diff --git a/arch/x86/kernel/mpparse.c b/arch/x86/kernel/mpparse.c
index 788d6cee0ab8..0d895d5d3031 100644
--- a/arch/x86/kernel/mpparse.c
+++ b/arch/x86/kernel/mpparse.c
@@ -115,21 +115,6 @@ static void __init MP_bus_info(struct mpc_bus *m)
printk(KERN_WARNING "Unknown bustype %s - ignoring\n", str);
 }
 
-static int bad_ioapic(unsigned long address)
-{
-   if (nr_ioapics >= MAX_IO_APICS) {
-   printk(KERN_ERR "ERROR: Max # of I/O APICs (%d) exceeded "
-  "(found %d)\n", MAX_IO_APICS, nr_ioapics);
-   panic("Recompile kernel with bigger MAX_IO_APICS!\n");
-   }
-   if (!address) {
-   printk(KERN_ERR "WARNING: Bogus (zero) I/O APIC address"
-  " found in table, skipping!\n");
-   return 1;
-   }
-   return 0;
-}
-
 static void __init MP_ioapic_info(struct mpc_ioapic *m)
 {
if (!(m->flags & MPC_APIC_USABLE))
@@ -138,15 +123,7 @@ static void __init MP_ioapic_info(struct mpc_ioapic *m)
printk(KERN_INFO "I/O APIC #%d Version %d at 0x%X.\n",
   m->apicid, m->apicver, m->apicaddr);
 
-   if (bad_ioapic(m->apicaddr))
-   return;
-
-   mp_ioapics[nr_ioapics].apicaddr = m->apicaddr;
-   mp_ioapics[nr_ioapics].apicid = m->apicid;
-   mp_ioapics[nr_ioapics].type = m->type;
-   mp_ioapics[nr_ioapics].apicver = m->apicver;
-   mp_ioapics[nr_ioapics].flags = m->flags;
-   nr_ioapics++;
+   mp_register_ioapic(m->apicid, m->apicaddr, gsi_end + 1);
 }
 
 static void print_MP_intsrc_info(struct mpc_intsrc *m)
-- 
1.8.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] x86, ioapic: Teach mp_register_ioapic to compute a global gsi_end

[Jonathan Nieder]

From: "Eric W. Biederman" 
Date: Tue, 30 Mar 2010 01:07:10 -0700

commit 5777372af5c929b8f3c706ed7b295b7279537c88 upstream.

Add the global variable gsi_end and teach mp_register_ioapic
to keep it uptodate as we add more ioapics into the system.

ioapics can only be added early in boot so the code that
runs later can treat gsi_end as a constant.

Remove the have hacks in sfi.c to second guess mp_register_ioapic
by keeping t's own running total of how many gsi's have been seen,
and instead use the gsi_end.

Signed-off-by: Eric W. Biederman 
LKML-Reference: <1269936436-7039-9-git-send-email-ebied...@xmission.com>
Signed-off-by: H. Peter Anvin 
Signed-off-by: Jonathan Nieder 
---
 arch/x86/include/asm/io_apic.h | 1 +
 arch/x86/kernel/apic/io_apic.c | 6 ++
 arch/x86/kernel/sfi.c  | 4 +---
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 5f61f6e0ffdd..c145253f34fa 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -186,6 +186,7 @@ struct mp_ioapic_gsi{
int gsi_end;
 };
 extern struct mp_ioapic_gsi  mp_gsi_routing[];
+extern u32 gsi_end;
 int mp_find_ioapic(int gsi);
 int mp_find_ioapic_pin(int ioapic, int gsi);
 void __init mp_register_ioapic(int id, u32 address, u32 gsi_base);
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 8928d9785eb4..7a5087640599 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -90,6 +90,9 @@ int nr_ioapics;
 /* IO APIC gsi routing info */
 struct mp_ioapic_gsi  mp_gsi_routing[MAX_IO_APICS];
 
+/* The last gsi number used */
+u32 gsi_end;
+
 /* MP IRQ source entries */
 struct mpc_intsrc mp_irqs[MAX_IRQ_SOURCES];
 
@@ -4284,6 +4287,9 @@ void __init mp_register_ioapic(int id, u32 address, u32 
gsi_base)
mp_gsi_routing[idx].gsi_end = gsi_base +
io_apic_get_redir_entries(idx);
 
+   if (mp_gsi_routing[idx].gsi_end > gsi_end)
+   gsi_end = mp_gsi_routing[idx].gsi_end;
+
printk(KERN_INFO "IOAPIC[%d]: apic_id %d, version %d, address 0x%x, "
   "GSI %d-%d\n", idx, mp_ioapics[idx].apicid,
   mp_ioapics[idx].apicver, mp_ioapics[idx].apicaddr,
diff --git a/arch/x86/kernel/sfi.c b/arch/x86/kernel/sfi.c
index 34e099382651..7ded57896c0a 100644
--- a/arch/x86/kernel/sfi.c
+++ b/arch/x86/kernel/sfi.c
@@ -81,7 +81,6 @@ static int __init sfi_parse_cpus(struct sfi_table_header 
*table)
 #endif /* CONFIG_X86_LOCAL_APIC */
 
 #ifdef CONFIG_X86_IO_APIC
-static u32 gsi_base;
 
 static int __init sfi_parse_ioapic(struct sfi_table_header *table)
 {
@@ -94,8 +93,7 @@ static int __init sfi_parse_ioapic(struct sfi_table_header 
*table)
pentry = (struct sfi_apic_table_entry *)sb->pentry;
 
for (i = 0; i < num; i++) {
-   mp_register_ioapic(i, pentry->phys_addr, gsi_base);
-   gsi_base += io_apic_get_redir_entries(i);
+   mp_register_ioapic(i, pentry->phys_addr, gsi_end + 1);
pentry++;
}
 
-- 
1.8.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC/PATCH 2.6.32.y 0/3] Re: [stable 2.6.32..2.6.34] x86, ioapic: initialize nr_ioapic_registers early in mp_register_ioapic()

[Jonathan Nieder]

Suresh Siddha wrote:
> On Wed, 2012-10-24 at 11:25 -0700, Jonathan Nieder wrote:

>> Why not cherry-pick 7716a5c4ff5 in full?
>
> As that depends on the other commits like:
> commit 4b6b19a1c7302477653d799a53d48063dd53d555

More importantly, if I understand correctly it might depend on

 commit cf7500c0ea13
 Author: Eric W. Biederman 
 Date:   Tue Mar 30 01:07:11 2010 -0700

 x86, ioapic: In mpparse use mp_register_ioapic

Here's a series, completely untested, that is closer to what I
expected.  But the approach you took seems reasonable, too, as long
as the commit message is tweaked to explain it.

Thanks again,
Jonathan

Eric W. Biederman (3):
  x86, ioapic: Teach mp_register_ioapic to compute a global gsi_end
  x86, ioapic: In mpparse use mp_register_ioapic
  x86, ioapic: Move nr_ioapic_registers calculation to
mp_register_ioapic.

 arch/x86/include/asm/io_apic.h |  1 +
 arch/x86/kernel/apic/io_apic.c | 28 ++--
 arch/x86/kernel/mpparse.c  | 25 +
 arch/x86/kernel/sfi.c  |  4 +---
 4 files changed, 17 insertions(+), 41 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [stable 2.6.32..2.6.34] x86, ioapic: initialize nr_ioapic_registers early in mp_register_ioapic()

[Jonathan Nieder]

Suresh Siddha wrote:

> commit 4b6b19a1c7302477653d799a53d48063dd53d555

Oh, yuck.  If that commit had changed io_apic_get_redir_entries()'s
name, it would have avoided some trouble.  Thanks for pointing it out.

> Wanted to keep the changes as minimal as possible.

I don't see how this is conceptually simpler than a version that also
removes the nr_ioapic_registers calculation in enable_IO_APIC().

Either way, please do mention 4b6b19a1c730 in the commit message so
others looking at the patch can see the off-by-one that is being
narrowly avoided.  Thanks for your help and patience.

Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [stable 2.6.32..2.6.34] x86, ioapic: initialize nr_ioapic_registers early in mp_register_ioapic()

[Jonathan Nieder]

Hi Suresh,

Suresh Siddha wrote:

[...]
> This problem doesn't happen with more recent kernels and closer
> look at the 2.6.32 kernel shows that the code which masks
> the IO-APIC RTE's is not working as expected as the nr_ioapic_registers
> for each IO-APIC is not yet initialized at this point. In the later
> kernels we initialize nr_ioapic_registers much before and
> everything works as expected.
>
> For 2.6.[32..34] kernels, fix this issue by initializing
> nr_ioapic_registers early in mp_register_ioapic()
>
> Relevant upstream commit info:
>
> commit 7716a5c4ff5f1f3dc5e9edcab125cbf7fceef0af

Why not cherry-pick 7716a5c4ff5 in full?

Curious,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [stable 2.6.32..2.6.34] x86, ioapic: initialize nr_ioapic_registers early in mp_register_ioapic()

[Jonathan Nieder]

Hi Suresh,

Suresh Siddha wrote:

[...]
 This problem doesn't happen with more recent kernels and closer
 look at the 2.6.32 kernel shows that the code which masks
 the IO-APIC RTE's is not working as expected as the nr_ioapic_registers
 for each IO-APIC is not yet initialized at this point. In the later
 kernels we initialize nr_ioapic_registers much before and
 everything works as expected.

 For 2.6.[32..34] kernels, fix this issue by initializing
 nr_ioapic_registers early in mp_register_ioapic()

 Relevant upstream commit info:

 commit 7716a5c4ff5f1f3dc5e9edcab125cbf7fceef0af

Why not cherry-pick 7716a5c4ff5 in full?

Curious,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [stable 2.6.32..2.6.34] x86, ioapic: initialize nr_ioapic_registers early in mp_register_ioapic()

[Jonathan Nieder]

Suresh Siddha wrote:

 commit 4b6b19a1c7302477653d799a53d48063dd53d555

Oh, yuck.  If that commit had changed io_apic_get_redir_entries()'s
name, it would have avoided some trouble.  Thanks for pointing it out.

 Wanted to keep the changes as minimal as possible.

I don't see how this is conceptually simpler than a version that also
removes the nr_ioapic_registers calculation in enable_IO_APIC().

Either way, please do mention 4b6b19a1c730 in the commit message so
others looking at the patch can see the off-by-one that is being
narrowly avoided.  Thanks for your help and patience.

Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC/PATCH 2.6.32.y 0/3] Re: [stable 2.6.32..2.6.34] x86, ioapic: initialize nr_ioapic_registers early in mp_register_ioapic()

[Jonathan Nieder]

Suresh Siddha wrote:
 On Wed, 2012-10-24 at 11:25 -0700, Jonathan Nieder wrote:

 Why not cherry-pick 7716a5c4ff5 in full?

 As that depends on the other commits like:
 commit 4b6b19a1c7302477653d799a53d48063dd53d555

More importantly, if I understand correctly it might depend on

 commit cf7500c0ea13
 Author: Eric W. Biederman ebied...@xmission.com
 Date:   Tue Mar 30 01:07:11 2010 -0700

 x86, ioapic: In mpparse use mp_register_ioapic

Here's a series, completely untested, that is closer to what I
expected.  But the approach you took seems reasonable, too, as long
as the commit message is tweaked to explain it.

Thanks again,
Jonathan

Eric W. Biederman (3):
  x86, ioapic: Teach mp_register_ioapic to compute a global gsi_end
  x86, ioapic: In mpparse use mp_register_ioapic
  x86, ioapic: Move nr_ioapic_registers calculation to
mp_register_ioapic.

 arch/x86/include/asm/io_apic.h |  1 +
 arch/x86/kernel/apic/io_apic.c | 28 ++--
 arch/x86/kernel/mpparse.c  | 25 +
 arch/x86/kernel/sfi.c  |  4 +---
 4 files changed, 17 insertions(+), 41 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] x86, ioapic: Teach mp_register_ioapic to compute a global gsi_end

[Jonathan Nieder]

From: Eric W. Biederman ebied...@xmission.com
Date: Tue, 30 Mar 2010 01:07:10 -0700

commit 5777372af5c929b8f3c706ed7b295b7279537c88 upstream.

Add the global variable gsi_end and teach mp_register_ioapic
to keep it uptodate as we add more ioapics into the system.

ioapics can only be added early in boot so the code that
runs later can treat gsi_end as a constant.

Remove the have hacks in sfi.c to second guess mp_register_ioapic
by keeping t's own running total of how many gsi's have been seen,
and instead use the gsi_end.

Signed-off-by: Eric W. Biederman ebied...@xmission.com
LKML-Reference: 1269936436-7039-9-git-send-email-ebied...@xmission.com
Signed-off-by: H. Peter Anvin h...@zytor.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
 arch/x86/include/asm/io_apic.h | 1 +
 arch/x86/kernel/apic/io_apic.c | 6 ++
 arch/x86/kernel/sfi.c  | 4 +---
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 5f61f6e0ffdd..c145253f34fa 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -186,6 +186,7 @@ struct mp_ioapic_gsi{
int gsi_end;
 };
 extern struct mp_ioapic_gsi  mp_gsi_routing[];
+extern u32 gsi_end;
 int mp_find_ioapic(int gsi);
 int mp_find_ioapic_pin(int ioapic, int gsi);
 void __init mp_register_ioapic(int id, u32 address, u32 gsi_base);
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 8928d9785eb4..7a5087640599 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -90,6 +90,9 @@ int nr_ioapics;
 /* IO APIC gsi routing info */
 struct mp_ioapic_gsi  mp_gsi_routing[MAX_IO_APICS];
 
+/* The last gsi number used */
+u32 gsi_end;
+
 /* MP IRQ source entries */
 struct mpc_intsrc mp_irqs[MAX_IRQ_SOURCES];
 
@@ -4284,6 +4287,9 @@ void __init mp_register_ioapic(int id, u32 address, u32 
gsi_base)
mp_gsi_routing[idx].gsi_end = gsi_base +
io_apic_get_redir_entries(idx);
 
+   if (mp_gsi_routing[idx].gsi_end  gsi_end)
+   gsi_end = mp_gsi_routing[idx].gsi_end;
+
printk(KERN_INFO IOAPIC[%d]: apic_id %d, version %d, address 0x%x, 
   GSI %d-%d\n, idx, mp_ioapics[idx].apicid,
   mp_ioapics[idx].apicver, mp_ioapics[idx].apicaddr,
diff --git a/arch/x86/kernel/sfi.c b/arch/x86/kernel/sfi.c
index 34e099382651..7ded57896c0a 100644
--- a/arch/x86/kernel/sfi.c
+++ b/arch/x86/kernel/sfi.c
@@ -81,7 +81,6 @@ static int __init sfi_parse_cpus(struct sfi_table_header 
*table)
 #endif /* CONFIG_X86_LOCAL_APIC */
 
 #ifdef CONFIG_X86_IO_APIC
-static u32 gsi_base;
 
 static int __init sfi_parse_ioapic(struct sfi_table_header *table)
 {
@@ -94,8 +93,7 @@ static int __init sfi_parse_ioapic(struct sfi_table_header 
*table)
pentry = (struct sfi_apic_table_entry *)sb-pentry;
 
for (i = 0; i  num; i++) {
-   mp_register_ioapic(i, pentry-phys_addr, gsi_base);
-   gsi_base += io_apic_get_redir_entries(i);
+   mp_register_ioapic(i, pentry-phys_addr, gsi_end + 1);
pentry++;
}
 
-- 
1.8.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] x86, ioapic: In mpparse use mp_register_ioapic

[Jonathan Nieder]

From: Eric W. Biederman ebied...@xmission.com
Date: Tue, 30 Mar 2010 01:07:11 -0700

commit cf7500c0ea133d66f8449d86392d83f84010263 upstream.

Long ago MP_ioapic_info was the primary way of setting up our
ioapic data structures and mp_register_ioapic was a compatibility
shim for acpi code.  Now the situation is reversed and
and mp_register_ioapic is the primary way of setting up our
ioapic data structures.

Keep the setting up of ioapic data structures uniform by
having mp_register_ioapic call mp_register_ioapic.

This changes a few fields:

- type: is now hardset to MP_IOAPIC but type had to
  bey MP_IOAPIC or MP_ioapic_info would not have been called.

- flags: is now hard coded to MPC_APIC_USABLE.
  We require flags to contain at least MPC_APIC_USEBLE in
  MP_ioapic_info and we don't ever examine flags so dropping
  a few flags that might possibly exist that we have never
  used is harmless.

- apicaddr: Unchanged

- apicver: Read from the ioapic instead of using the cached
  hardware value in the MP table.  The real hardware value
  will be more accurate.

- apicid: Now verified to be unique and changed if it is not.
  If the BIOS got this right this is a noop.  If the BIOS did
  not fixing things appears to be the better solution.

This adds gsi_base and gsi_end values to our ioapics defined with
the mpatable, which will make our lives simpler later since
we can always assume gsi_base and gsi_end are valid.

Signed-off-by: Eric W. Biederman ebied...@xmission.com
LKML-Reference: 1269936436-7039-10-git-send-email-ebied...@xmission.com
Signed-off-by: H. Peter Anvin h...@zytor.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
 arch/x86/kernel/mpparse.c | 25 +
 1 file changed, 1 insertion(+), 24 deletions(-)

diff --git a/arch/x86/kernel/mpparse.c b/arch/x86/kernel/mpparse.c
index 788d6cee0ab8..0d895d5d3031 100644
--- a/arch/x86/kernel/mpparse.c
+++ b/arch/x86/kernel/mpparse.c
@@ -115,21 +115,6 @@ static void __init MP_bus_info(struct mpc_bus *m)
printk(KERN_WARNING Unknown bustype %s - ignoring\n, str);
 }
 
-static int bad_ioapic(unsigned long address)
-{
-   if (nr_ioapics = MAX_IO_APICS) {
-   printk(KERN_ERR ERROR: Max # of I/O APICs (%d) exceeded 
-  (found %d)\n, MAX_IO_APICS, nr_ioapics);
-   panic(Recompile kernel with bigger MAX_IO_APICS!\n);
-   }
-   if (!address) {
-   printk(KERN_ERR WARNING: Bogus (zero) I/O APIC address
-   found in table, skipping!\n);
-   return 1;
-   }
-   return 0;
-}
-
 static void __init MP_ioapic_info(struct mpc_ioapic *m)
 {
if (!(m-flags  MPC_APIC_USABLE))
@@ -138,15 +123,7 @@ static void __init MP_ioapic_info(struct mpc_ioapic *m)
printk(KERN_INFO I/O APIC #%d Version %d at 0x%X.\n,
   m-apicid, m-apicver, m-apicaddr);
 
-   if (bad_ioapic(m-apicaddr))
-   return;
-
-   mp_ioapics[nr_ioapics].apicaddr = m-apicaddr;
-   mp_ioapics[nr_ioapics].apicid = m-apicid;
-   mp_ioapics[nr_ioapics].type = m-type;
-   mp_ioapics[nr_ioapics].apicver = m-apicver;
-   mp_ioapics[nr_ioapics].flags = m-flags;
-   nr_ioapics++;
+   mp_register_ioapic(m-apicid, m-apicaddr, gsi_end + 1);
 }
 
 static void print_MP_intsrc_info(struct mpc_intsrc *m)
-- 
1.8.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] x86, ioapic: Move nr_ioapic_registers calculation to mp_register_ioapic.

[Jonathan Nieder]

From: Eric W. Biederman ebied...@xmission.com
Date: Tue, 30 Mar 2010 01:07:12 -0700

commit 7716a5c4ff5f1f3dc5e9edcab125cbf7fceef0af upstream.

Now that all ioapic registration happens in mp_register_ioapic we can
move the calculation of nr_ioapic_registers there from enable_IO_APIC.
The number of ioapic registers is already calucated in mp_register_ioapic
so all that really needs to be done is to save the caluclated value
in nr_ioapic_registers.

[suresh.b.sid...@intel.com: backport to 2.6.32.y and 2.6.34.y:

 Lin Bao reported that one of the HP platforms failed to boot
 2.6.32 kernel, when the BIOS enabled interrupt-remapping and
 x2apic before handing over the control to the Linux kernel.

 During boot, Linux kernel masks all the interrupt sources
 (8259, IO-APIC RTE's), setup the interrupt-remapping hardware
 with the OS controlled table and unmasks the 8259 interrupts
 but not the IO-APIC RTE's (as the newly setup interrupt-remapping
 table and the IO-APIC RTE's are not yet programmed by the kernel).

 Shortly after this, IO-APIC RTE's and the interrupt-remapping table
 entries are programmed based on the ACPI tables etc. So the
 expectation is that any interrupt during this window will be dropped
 and not see the intermediate configuration.

 In the reported problematic case, BIOS has configured the IO-APIC
 in virtual wire-B mode. Between the window of the kernel setting up
 new interrupt-remapping table  and the IO-APIC RTE's are properly
 configured, an interrupt gets routed by the IO-APIC RTE (setup
 by the virtual wire-B configuration) and sees the empty
 interrupt-remapping table entry, resulting in vt-d fault causing
 the platform to generate NMI. And the OS panics on this unexpected NMI.

 This problem doesn't happen with more recent kernels and closer
 look at the 2.6.32 kernel shows that the code which masks
 the IO-APIC RTE's is not working as expected as the nr_ioapic_registers
 for each IO-APIC is not yet initialized at this point. In the later
 kernels we initialize nr_ioapic_registers much before and
 everything works as expected.]

[jrnie...@gmail.com: include removal of nr_ioapic_registers calculation
 from enable_IO_APIC() to complete the backport]

Signed-off-by: Eric W. Biederman ebied...@xmission.com
LKML-Reference: 1269936436-7039-11-git-send-email-ebied...@xmission.com
Signed-off-by: H. Peter Anvin h...@zytor.com
Reported-by: Zhang, Lin-Bao linbao.zh...@hp.com
Signed-off-by: Suresh Siddha suresh.b.sid...@intel.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
 arch/x86/kernel/apic/io_apic.c | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 7a5087640599..6b7d97f1f5e5 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1945,20 +1945,8 @@ static struct { int pin, apic; } ioapic_i8259 = { -1, -1 
};
 
 void __init enable_IO_APIC(void)
 {
-   union IO_APIC_reg_01 reg_01;
int i8259_apic, i8259_pin;
int apic;
-   unsigned long flags;
-
-   /*
-* The number of IO-APIC IRQ registers (== #pins):
-*/
-   for (apic = 0; apic  nr_ioapics; apic++) {
-   spin_lock_irqsave(ioapic_lock, flags);
-   reg_01.raw = io_apic_read(apic, 1);
-   spin_unlock_irqrestore(ioapic_lock, flags);
-   nr_ioapic_registers[apic] = reg_01.bits.entries+1;
-   }
 
if (!nr_legacy_irqs)
return;
@@ -4265,6 +4253,7 @@ static int bad_ioapic(unsigned long address)
 void __init mp_register_ioapic(int id, u32 address, u32 gsi_base)
 {
int idx = 0;
+   int entries;
 
if (bad_ioapic(address))
return;
@@ -4283,9 +4272,14 @@ void __init mp_register_ioapic(int id, u32 address, u32 
gsi_base)
 * Build basic GSI lookup table to facilitate gsi-io_apic lookups
 * and to prevent reprogramming of IOAPIC pins (PCI GSIs).
 */
+   entries = io_apic_get_redir_entries(idx);
mp_gsi_routing[idx].gsi_base = gsi_base;
-   mp_gsi_routing[idx].gsi_end = gsi_base +
-   io_apic_get_redir_entries(idx);
+   mp_gsi_routing[idx].gsi_end = gsi_base + entries;
+
+   /*
+* The number of IO-APIC IRQ registers (== #pins):
+*/
+   nr_ioapic_registers[idx] = entries + 1;
 
if (mp_gsi_routing[idx].gsi_end  gsi_end)
gsi_end = mp_gsi_routing[idx].gsi_end;
-- 
1.8.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/PATCH 2.6.32.y 0/3] Re: [stable 2.6.32..2.6.34] x86, ioapic: initialize nr_ioapic_registers early in mp_register_ioapic()

[Jonathan Nieder]

Suresh Siddha wrote:

   Here is the updated patch with just some
 more text added to the changelog.

Yes, that's clearer.  For what it's worth,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com

Thanks for your patience.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/1] ALSA: hda - add quirk for Thinkpad T430

[Jonathan Nieder]

joseph.salisb...@canonical.com wrote:

> This patch adds a quirk to enable headphone jack audio on T430 Thinkpads.
>
> Signed-off-by: Joseph Salisbury 
> Cc: 

Thanks --- this is a little better.

One more nit: it looks like this was reported, tested, and based on a
patch by Stefan Freyr.  Takashi, could you amend the message to
reflect that, or should the patch be resent?

Something like

-- >8 --
From: Stefán Freyr 
Subject: ALSA: hda - add dock support for Thinkpad T430

I have a Lenovo ThinkPad T430 and an UltraBase Series 3 docking
station.

Without this patch, if I plug my headphones into the jack on the
computer, everything works fine. The computer speakers mute and the
audio is played in the headphones. However, if I plug into the docking
station headphone jack the computer speakers are muted but there is no
audio in the headphones.

Addresses https://bugs.launchpad.net/bugs/1060372

Signed-off-by: Joseph Salisbury 
Cc: sta...@vger.kernel.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] ALSA: hda - add quirk for Thinkpad T430

[Jonathan Nieder]

Hi Joseph,

joseph.salisb...@canonical.com wrote:

> [Subject: [PATCH 0/1] ALSA: hda - add quirk for Thinkpad T430]]
[...]
> This patch is to enable audio on T430 Thinkpads.  There is no audo
> from the headphone jack without this patch.  This patch adds a quirk
> for the T430 model.  

Please don't do this cover-letter thing.  A cover letter can be a
good way to *summarize* a long patch series so readers are less
daunted, but any information that was needed to know in order to
evaluate a patch, briefly stated, should be in the commit message that
actually gets committed.

Thanks and hope that helps,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] ALSA: hda - add quirk for Thinkpad T430

[Jonathan Nieder]

Hi Joseph,

joseph.salisb...@canonical.com wrote:

 [Subject: [PATCH 0/1] ALSA: hda - add quirk for Thinkpad T430]]
[...]
 This patch is to enable audio on T430 Thinkpads.  There is no audo
 from the headphone jack without this patch.  This patch adds a quirk
 for the T430 model.  

Please don't do this cover-letter thing.  A cover letter can be a
good way to *summarize* a long patch series so readers are less
daunted, but any information that was needed to know in order to
evaluate a patch, briefly stated, should be in the commit message that
actually gets committed.

Thanks and hope that helps,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/1] ALSA: hda - add quirk for Thinkpad T430

[Jonathan Nieder]

joseph.salisb...@canonical.com wrote:

 This patch adds a quirk to enable headphone jack audio on T430 Thinkpads.

 Signed-off-by: Joseph Salisbury joseph.salisb...@canonical.com
 Cc: sta...@vger.kernel.org

Thanks --- this is a little better.

One more nit: it looks like this was reported, tested, and based on a
patch by Stefan Freyr.  Takashi, could you amend the message to
reflect that, or should the patch be resent?

Something like

-- 8 --
From: Stefán Freyr stefan.fr...@gmail.com
Subject: ALSA: hda - add dock support for Thinkpad T430

I have a Lenovo ThinkPad T430 and an UltraBase Series 3 docking
station.

Without this patch, if I plug my headphones into the jack on the
computer, everything works fine. The computer speakers mute and the
audio is played in the headphones. However, if I plug into the docking
station headphone jack the computer speakers are muted but there is no
audio in the headphones.

Addresses https://bugs.launchpad.net/bugs/1060372

Signed-off-by: Joseph Salisbury joseph.salisb...@canonical.com
Cc: sta...@vger.kernel.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -stable] amd_iommu: attach device fails on the last pci device

[Jonathan Nieder]

Shuah Khan wrote:
> On Fri, 2012-10-12 at 11:38 -0700, Jonathan Nieder wrote:

>> To save Willy time: am I correct in guessing the upstream commit you
>> are referring to is 98fc5a693bbdda498a556654c70d1e31a186c988
>> (x86/amd-iommu: Use get_device_id and check_device where appropriate,
>> 2009-11-24)?
>
> Yes that is one.

Great, thanks for the quick confirmation.

Ciao,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -stable] amd_iommu: attach device fails on the last pci device

[Jonathan Nieder]

Shuah Khan wrote:

> This bug is in linux-2.6.32 and an equivalent fix in linux-2.6.33 and has been
> carried forward to later kernels and is in the upstream kernel. This 
> equivalent
> fix includes restructuring and consolidating device checks into a routine
> check_device(). Instead of back-porting all of that work, spot-fixed the bug 
> in
> amd_iommu_attach_device() for linux-2.6.32.

To save Willy time: am I correct in guessing the upstream commit you
are referring to is 98fc5a693bbdda498a556654c70d1e31a186c988
(x86/amd-iommu: Use get_device_id and check_device where appropriate,
2009-11-24)?

Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -stable] amd_iommu: attach device fails on the last pci device

[Jonathan Nieder]

Shuah Khan wrote:

 This bug is in linux-2.6.32 and an equivalent fix in linux-2.6.33 and has been
 carried forward to later kernels and is in the upstream kernel. This 
 equivalent
 fix includes restructuring and consolidating device checks into a routine
 check_device(). Instead of back-porting all of that work, spot-fixed the bug 
 in
 amd_iommu_attach_device() for linux-2.6.32.

To save Willy time: am I correct in guessing the upstream commit you
are referring to is 98fc5a693bbdda498a556654c70d1e31a186c988
(x86/amd-iommu: Use get_device_id and check_device where appropriate,
2009-11-24)?

Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -stable] amd_iommu: attach device fails on the last pci device

[Jonathan Nieder]

Shuah Khan wrote:
 On Fri, 2012-10-12 at 11:38 -0700, Jonathan Nieder wrote:

 To save Willy time: am I correct in guessing the upstream commit you
 are referring to is 98fc5a693bbdda498a556654c70d1e31a186c988
 (x86/amd-iommu: Use get_device_id and check_device where appropriate,
 2009-11-24)?

 Yes that is one.

Great, thanks for the quick confirmation.

Ciao,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 60/84] r8169: fix wake on lan setting for non-8111E.

[Jonathan Nieder]

Hi Greg,

Greg Kroah-Hartman wrote:

> commit d4ed95d796e5126bba51466dc07e287cebc8bd19 upstream.
>
> Only 8111E needs enable RxConfig bit 0 ~ 3 when suspending or
> shutdowning for wake on lan.

Sounds sensible to me, but I haven't reviewed this --- e.g., I
don't know what symptoms this addresses or what model they were
experienced on.

Here's a patch to remove the reviewed-bys that seem to have been
added by mistake.

Thanks,
Jonathan

-- >8 --
Subject: queue-3.0: remove reviewed-by on patches I haven't reviewed

---
 ...ater-require-bit-0x20-to-be-set-in-config2-for-pme-signaling.patch |1 -
 .../r8169-call-netif_napi_del-at-errpaths-and-at-driver-unload.patch  |1 -
 queue-3.0/r8169-config1-is-read-only-on-8168c-and-later.patch |1 -
 queue-3.0/r8169-don-t-enable-rx-when-shutdown.patch   |1 -
 queue-3.0/r8169-expand-received-packet-length-indication.patch|1 -
 queue-3.0/r8169-fix-config2-msienable-bit-setting.patch   |1 -
 queue-3.0/r8169-fix-unsigned-int-wraparound-with-tso.patch|1 -
 queue-3.0/r8169-fix-wake-on-lan-setting-for-non-8111e.patch   |1 -
 .../r8169-increase-the-delay-parameter-of-pm_schedule_suspend.patch   |1 -
 queue-3.0/r8169-jumbo-fixes.patch |1 -
 queue-3.0/r8169-missing-barriers.patch|1 -
 queue-3.0/r8169-remove-erroneous-processing-of-always-set-bit.patch   |1 -
 queue-3.0/r8169-runtime-resume-before-shutdown.patch  |1 -
 13 files changed, 13 deletions(-)

diff --git 
a/queue-3.0/r8169-8168c-and-later-require-bit-0x20-to-be-set-in-config2-for-pme-signaling.patch
 
b/queue-3.0/r8169-8168c-and-later-require-bit-0x20-to-be-set-in-config2-for-pme-signaling.patch
index b4d1b9d4..9dd53b4e 100644
--- 
a/queue-3.0/r8169-8168c-and-later-require-bit-0x20-to-be-set-in-config2-for-pme-signaling.patch
+++ 
b/queue-3.0/r8169-8168c-and-later-require-bit-0x20-to-be-set-in-config2-for-pme-signaling.patch
@@ -12,7 +12,6 @@ The new 84xx stopped flying below the radars.
 
 Signed-off-by: Francois Romieu 
 Cc: Hayes Wang 
-Reviewed-by: Jonathan Nieder 
 Acked-by: David S. Miller 
 Signed-off-by: Greg Kroah-Hartman 
 ---
diff --git 
a/queue-3.0/r8169-call-netif_napi_del-at-errpaths-and-at-driver-unload.patch 
b/queue-3.0/r8169-call-netif_napi_del-at-errpaths-and-at-driver-unload.patch
index c2600140..f9148f64 100644
--- a/queue-3.0/r8169-call-netif_napi_del-at-errpaths-and-at-driver-unload.patch
+++ b/queue-3.0/r8169-call-netif_napi_del-at-errpaths-and-at-driver-unload.patch
@@ -14,7 +14,6 @@ delete the NAPI before unregistering netdevice using 
unregister_netdev.
 
 Signed-off-by: Devendra Naga 
 Signed-off-by: David S. Miller 
-Reviewed-by: Jonathan Nieder 
 Signed-off-by: Greg Kroah-Hartman 
 ---
  drivers/net/r8169.c |3 +++
diff --git a/queue-3.0/r8169-config1-is-read-only-on-8168c-and-later.patch 
b/queue-3.0/r8169-config1-is-read-only-on-8168c-and-later.patch
index dd62d63a..d8690d0d 100644
--- a/queue-3.0/r8169-config1-is-read-only-on-8168c-and-later.patch
+++ b/queue-3.0/r8169-config1-is-read-only-on-8168c-and-later.patch
@@ -12,7 +12,6 @@ Suggested by Hayes.
 
 Signed-off-by: Francois Romieu 
 Cc: Hayes Wang 
-Reviewed-by: Jonathan Nieder 
 Acked-by: David S. Miller 
 Signed-off-by: Greg Kroah-Hartman 
 ---
diff --git a/queue-3.0/r8169-don-t-enable-rx-when-shutdown.patch 
b/queue-3.0/r8169-don-t-enable-rx-when-shutdown.patch
index ca876bb5..a511d5ec 100644
--- a/queue-3.0/r8169-don-t-enable-rx-when-shutdown.patch
+++ b/queue-3.0/r8169-don-t-enable-rx-when-shutdown.patch
@@ -12,7 +12,6 @@ Only 8111b needs to enable rx when shutdowning with WoL.
 
 Signed-off-by: Hayes Wang 
 Acked-by: Francois Romieu 
-Reviewed-by: Jonathan Nieder 
 Acked-by: David S. Miller 
 Signed-off-by: Greg Kroah-Hartman 
 ---
diff --git a/queue-3.0/r8169-expand-received-packet-length-indication.patch 
b/queue-3.0/r8169-expand-received-packet-length-indication.patch
index 341ddee4..bbe8a00d 100644
--- a/queue-3.0/r8169-expand-received-packet-length-indication.patch
+++ b/queue-3.0/r8169-expand-received-packet-length-indication.patch
@@ -18,7 +18,6 @@ Realtek's drivers use the same mask for the 816x and the fast 
ethernet
 only 810x.
 
 Signed-off-by: Francois Romieu 
-Reviewed-by: Jonathan Nieder 
 Acked-by: David S. Miller 
 Signed-off-by: Greg Kroah-Hartman 
 ---
diff --git a/queue-3.0/r8169-fix-config2-msienable-bit-setting.patch 
b/queue-3.0/r8169-fix-config2-msienable-bit-setting.patch
index 027e5658..92b29990 100644
--- a/queue-3.0/r8169-fix-config2-msienable-bit-setting.patch
+++ b/queue-3.0/r8169-fix-config2-msienable-bit-setting.patch
@@ -17,7 +17,6 @@ Reported-by: Su Kang Yin 
 Signed-off-by: Francois Romieu 
 Cc: Hayes Wang 
 Signed-off-by: David S. Miller 
-Reviewed-by: Jonathan Nieder 
 Signed-off-by: Greg Kroah-Hartman 
 ---
  drivers/net/r8169.c |   14 --
diff --git a/queue-3.0/r81

Re: [ 60/84] r8169: fix wake on lan setting for non-8111E.

[Jonathan Nieder]

Hi Greg,

Greg Kroah-Hartman wrote:

 commit d4ed95d796e5126bba51466dc07e287cebc8bd19 upstream.

 Only 8111E needs enable RxConfig bit 0 ~ 3 when suspending or
 shutdowning for wake on lan.

Sounds sensible to me, but I haven't reviewed this --- e.g., I
don't know what symptoms this addresses or what model they were
experienced on.

Here's a patch to remove the reviewed-bys that seem to have been
added by mistake.

Thanks,
Jonathan

-- 8 --
Subject: queue-3.0: remove reviewed-by on patches I haven't reviewed

---
 ...ater-require-bit-0x20-to-be-set-in-config2-for-pme-signaling.patch |1 -
 .../r8169-call-netif_napi_del-at-errpaths-and-at-driver-unload.patch  |1 -
 queue-3.0/r8169-config1-is-read-only-on-8168c-and-later.patch |1 -
 queue-3.0/r8169-don-t-enable-rx-when-shutdown.patch   |1 -
 queue-3.0/r8169-expand-received-packet-length-indication.patch|1 -
 queue-3.0/r8169-fix-config2-msienable-bit-setting.patch   |1 -
 queue-3.0/r8169-fix-unsigned-int-wraparound-with-tso.patch|1 -
 queue-3.0/r8169-fix-wake-on-lan-setting-for-non-8111e.patch   |1 -
 .../r8169-increase-the-delay-parameter-of-pm_schedule_suspend.patch   |1 -
 queue-3.0/r8169-jumbo-fixes.patch |1 -
 queue-3.0/r8169-missing-barriers.patch|1 -
 queue-3.0/r8169-remove-erroneous-processing-of-always-set-bit.patch   |1 -
 queue-3.0/r8169-runtime-resume-before-shutdown.patch  |1 -
 13 files changed, 13 deletions(-)

diff --git 
a/queue-3.0/r8169-8168c-and-later-require-bit-0x20-to-be-set-in-config2-for-pme-signaling.patch
 
b/queue-3.0/r8169-8168c-and-later-require-bit-0x20-to-be-set-in-config2-for-pme-signaling.patch
index b4d1b9d4..9dd53b4e 100644
--- 
a/queue-3.0/r8169-8168c-and-later-require-bit-0x20-to-be-set-in-config2-for-pme-signaling.patch
+++ 
b/queue-3.0/r8169-8168c-and-later-require-bit-0x20-to-be-set-in-config2-for-pme-signaling.patch
@@ -12,7 +12,6 @@ The new 84xx stopped flying below the radars.
 
 Signed-off-by: Francois Romieu rom...@fr.zoreil.com
 Cc: Hayes Wang hayesw...@realtek.com
-Reviewed-by: Jonathan Nieder jrnie...@gmail.com
 Acked-by: David S. Miller da...@davemloft.net
 Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
 ---
diff --git 
a/queue-3.0/r8169-call-netif_napi_del-at-errpaths-and-at-driver-unload.patch 
b/queue-3.0/r8169-call-netif_napi_del-at-errpaths-and-at-driver-unload.patch
index c2600140..f9148f64 100644
--- a/queue-3.0/r8169-call-netif_napi_del-at-errpaths-and-at-driver-unload.patch
+++ b/queue-3.0/r8169-call-netif_napi_del-at-errpaths-and-at-driver-unload.patch
@@ -14,7 +14,6 @@ delete the NAPI before unregistering netdevice using 
unregister_netdev.
 
 Signed-off-by: Devendra Naga devendra.a...@gmail.com
 Signed-off-by: David S. Miller da...@davemloft.net
-Reviewed-by: Jonathan Nieder jrnie...@gmail.com
 Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
 ---
  drivers/net/r8169.c |3 +++
diff --git a/queue-3.0/r8169-config1-is-read-only-on-8168c-and-later.patch 
b/queue-3.0/r8169-config1-is-read-only-on-8168c-and-later.patch
index dd62d63a..d8690d0d 100644
--- a/queue-3.0/r8169-config1-is-read-only-on-8168c-and-later.patch
+++ b/queue-3.0/r8169-config1-is-read-only-on-8168c-and-later.patch
@@ -12,7 +12,6 @@ Suggested by Hayes.
 
 Signed-off-by: Francois Romieu rom...@fr.zoreil.com
 Cc: Hayes Wang hayesw...@realtek.com
-Reviewed-by: Jonathan Nieder jrnie...@gmail.com
 Acked-by: David S. Miller da...@davemloft.net
 Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
 ---
diff --git a/queue-3.0/r8169-don-t-enable-rx-when-shutdown.patch 
b/queue-3.0/r8169-don-t-enable-rx-when-shutdown.patch
index ca876bb5..a511d5ec 100644
--- a/queue-3.0/r8169-don-t-enable-rx-when-shutdown.patch
+++ b/queue-3.0/r8169-don-t-enable-rx-when-shutdown.patch
@@ -12,7 +12,6 @@ Only 8111b needs to enable rx when shutdowning with WoL.
 
 Signed-off-by: Hayes Wang hayesw...@realtek.com
 Acked-by: Francois Romieu rom...@fr.zoreil.com
-Reviewed-by: Jonathan Nieder jrnie...@gmail.com
 Acked-by: David S. Miller da...@davemloft.net
 Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
 ---
diff --git a/queue-3.0/r8169-expand-received-packet-length-indication.patch 
b/queue-3.0/r8169-expand-received-packet-length-indication.patch
index 341ddee4..bbe8a00d 100644
--- a/queue-3.0/r8169-expand-received-packet-length-indication.patch
+++ b/queue-3.0/r8169-expand-received-packet-length-indication.patch
@@ -18,7 +18,6 @@ Realtek's drivers use the same mask for the 816x and the fast 
ethernet
 only 810x.
 
 Signed-off-by: Francois Romieu rom...@fr.zoreil.com
-Reviewed-by: Jonathan Nieder jrnie...@gmail.com
 Acked-by: David S. Miller da...@davemloft.net
 Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
 ---
diff --git a/queue-3.0/r8169-fix-config2-msienable-bit-setting.patch 
b/queue-3.0/r8169-fix

Re: [PATCH 27/30] ACPI: EC: Add a quirk for CLEVO M720T/M730T laptop

[Jonathan Nieder]

Feng Tang wrote:
> Jonathan Nieder  wrote:

>> What would go wrong if the threshold were just increased to 20 on all
>> models?
>
> Then some other platform will stop to work.
>   https://bugzilla.kernel.org/show_bug.cgi?id=11892 
>
> The 26/30 and 27/30 patches are bound together to fix one bug. Some
> quote from description from the 26th patch:
>
> ACPI_EC_STORM_THRESHOLD was initially 20 when it's created, and
> was changed to 8 in 2.6.28 commit 06cf7d3c7 "ACPI: EC: lower interrupt storm
> threshold" to fix kernel bug 11892 by forcing the laptop in that bug to
> work in polling mode.
>
> Hope this answers your question.

Thanks much.  Yes, that clarifies.

The magic numbers are not too thrilling.  If the polling mode just
doesn't work on the Clevo M720, why isn't the appropriate storm
threshold 99 or infinity rather than 20?  Do we know why the
polling mode doesn't work?

Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 27/30] ACPI: EC: Add a quirk for CLEVO M720T/M730T laptop

[Jonathan Nieder]

Len Brown wrote:

> By enlarging the GPE storm threshold back to 20, that laptop's
> EC works fine with interrupt mode instead of polling mode.

What would go wrong if the threshold were just increased to 20 on all
models?

Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 27/30] ACPI: EC: Add a quirk for CLEVO M720T/M730T laptop

[Jonathan Nieder]

Len Brown wrote:

 By enlarging the GPE storm threshold back to 20, that laptop's
 EC works fine with interrupt mode instead of polling mode.

What would go wrong if the threshold were just increased to 20 on all
models?

Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 27/30] ACPI: EC: Add a quirk for CLEVO M720T/M730T laptop

[Jonathan Nieder]

Feng Tang wrote:
 Jonathan Nieder jrnie...@gmail.com wrote:

 What would go wrong if the threshold were just increased to 20 on all
 models?

 Then some other platform will stop to work.
   https://bugzilla.kernel.org/show_bug.cgi?id=11892 

 The 26/30 and 27/30 patches are bound together to fix one bug. Some
 quote from description from the 26th patch:

 ACPI_EC_STORM_THRESHOLD was initially 20 when it's created, and
 was changed to 8 in 2.6.28 commit 06cf7d3c7 ACPI: EC: lower interrupt storm
 threshold to fix kernel bug 11892 by forcing the laptop in that bug to
 work in polling mode.

 Hope this answers your question.

Thanks much.  Yes, that clarifies.

The magic numbers are not too thrilling.  If the polling mode just
doesn't work on the Clevo M720, why isn't the appropriate storm
threshold 99 or infinity rather than 20?  Do we know why the
polling mode doesn't work?

Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6.32.y, 2.6.34.y] ALSA: hda - ALSA HD Audio patch for Intel Panther Point DeviceIDs

[Jonathan Nieder]

From: Seth Heasley 
Date: Wed, 20 Apr 2011 10:59:57 -0700

commit d2edeb7c6f1dada8ca7d5c23e42d604e92ae0c76 upstream.

This patch adds the HD Audio Controller DeviceIDs for the Intel Panther Point 
PCH.

[jn: backported for 2.6.32.y by Ana Guerrero]

Signed-off-by: Seth Heasley 
Signed-off-by: Takashi Iwai 
Tested-by: Ana Guerrero  # EliteBook 8570w
Signed-off-by: Jonathan Nieder 
---
Hi Willy and Paul,

Please consider

  d2edeb7c6f1d ALSA: hda - ALSA HD Audio patch for Intel Panther Point
   DeviceIDs

for application to the 2.6.32.y and 2.6.34.y trees.

It does what it says on the cover.  The patch was merged in the 3.0
cycle, so newer stable kernels don't need it.  Backported and
tested[1] against Debian's 2.6.32.y-based kernel by Ana (cc-ed) --
thanks!

Thoughts of all kinds welcome, as always.

Regards,
Jonathan

[1] http://bugs.debian.org/689928

 sound/pci/hda/hda_intel.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 3cf21ffc7c5f..dc812838ea8b 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -126,6 +126,7 @@ MODULE_SUPPORTED_DEVICE("{{Intel, ICH6},"
 "{Intel, ICH10},"
 "{Intel, PCH},"
 "{Intel, CPT},"
+"{Intel, PPT},"
 "{Intel, SCH},"
 "{ATI, SB450},"
 "{ATI, SB600},"
@@ -2730,6 +2731,8 @@ static DEFINE_PCI_DEVICE_TABLE(azx_ids) = {
{ PCI_DEVICE(0x8086, 0x3b57), .driver_data = AZX_DRIVER_ICH },
/* CPT */
{ PCI_DEVICE(0x8086, 0x1c20), .driver_data = AZX_DRIVER_PCH },
+   /* Panther Point */
+   { PCI_DEVICE(0x8086, 0x1e20), .driver_data = AZX_DRIVER_PCH },
/* SCH */
{ PCI_DEVICE(0x8086, 0x811b), .driver_data = AZX_DRIVER_SCH },
/* ATI SB 450/600 */
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6.32.y, 2.6.34.y] ALSA: hda - ALSA HD Audio patch for Intel Panther Point DeviceIDs

[Jonathan Nieder]

From: Seth Heasley seth.heas...@intel.com
Date: Wed, 20 Apr 2011 10:59:57 -0700

commit d2edeb7c6f1dada8ca7d5c23e42d604e92ae0c76 upstream.

This patch adds the HD Audio Controller DeviceIDs for the Intel Panther Point 
PCH.

[jn: backported for 2.6.32.y by Ana Guerrero]

Signed-off-by: Seth Heasley seth.heas...@intel.com
Signed-off-by: Takashi Iwai ti...@suse.de
Tested-by: Ana Guerrero a...@debian.org # EliteBook 8570w
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Hi Willy and Paul,

Please consider

  d2edeb7c6f1d ALSA: hda - ALSA HD Audio patch for Intel Panther Point
   DeviceIDs

for application to the 2.6.32.y and 2.6.34.y trees.

It does what it says on the cover.  The patch was merged in the 3.0
cycle, so newer stable kernels don't need it.  Backported and
tested[1] against Debian's 2.6.32.y-based kernel by Ana (cc-ed) --
thanks!

Thoughts of all kinds welcome, as always.

Regards,
Jonathan

[1] http://bugs.debian.org/689928

 sound/pci/hda/hda_intel.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 3cf21ffc7c5f..dc812838ea8b 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -126,6 +126,7 @@ MODULE_SUPPORTED_DEVICE({{Intel, ICH6},
 {Intel, ICH10},
 {Intel, PCH},
 {Intel, CPT},
+{Intel, PPT},
 {Intel, SCH},
 {ATI, SB450},
 {ATI, SB600},
@@ -2730,6 +2731,8 @@ static DEFINE_PCI_DEVICE_TABLE(azx_ids) = {
{ PCI_DEVICE(0x8086, 0x3b57), .driver_data = AZX_DRIVER_ICH },
/* CPT */
{ PCI_DEVICE(0x8086, 0x1c20), .driver_data = AZX_DRIVER_PCH },
+   /* Panther Point */
+   { PCI_DEVICE(0x8086, 0x1e20), .driver_data = AZX_DRIVER_PCH },
/* SCH */
{ PCI_DEVICE(0x8086, 0x811b), .driver_data = AZX_DRIVER_SCH },
/* ATI SB 450/600 */
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Seems like "sched: Add missing call to calc_load_exit_idle()" should be reverted in 3.5 branch

[Jonathan Nieder]

Peter Zijlstra wrote:
> On Thu, 2012-10-04 at 15:27 -0700, Greg Kroah-Hartman wrote:

>> I'm puzzled as well.  Any ideas if I should do anything here or not?
>
> So I think the current v3.5.5 code is fine.

Now I'm puzzled.  You wrote:

| However, since we don't restart the tick, we won't be sampling load muck
| and calling calc_load_exit_idle() from there is bound to confuse state.

Doesn't that mean 900404e5d201 "sched: Add missing call to
calc_load_exit_idle()" which is part of 3.5.5 was problematic?  Or
did I just miscount the number of "not"s?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Seems like sched: Add missing call to calc_load_exit_idle() should be reverted in 3.5 branch

[Jonathan Nieder]

Peter Zijlstra wrote:
 On Thu, 2012-10-04 at 15:27 -0700, Greg Kroah-Hartman wrote:

 I'm puzzled as well.  Any ideas if I should do anything here or not?

 So I think the current v3.5.5 code is fine.

Now I'm puzzled.  You wrote:

| However, since we don't restart the tick, we won't be sampling load muck
| and calling calc_load_exit_idle() from there is bound to confuse state.

Doesn't that mean 900404e5d201 sched: Add missing call to
calc_load_exit_idle() which is part of 3.5.5 was problematic?  Or
did I just miscount the number of nots?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Seems like "sched: Add missing call to calc_load_exit_idle()" should be reverted in 3.5 branch

[Jonathan Nieder]

Peter Zijlstra wrote:

> I can't find wtf went wrong either, the initial patch 5167e8d5417bf5c
> contains both hunks, but in that case the fixup 749c8814f0 doesn't make
> sense, not can I find anything in merge commits using:
>
>   git log -S calc_load_exit_idle kernel/time/tick-sched.c

 git log -m -p --first-parent -Scalc_load_exit_idle -- kernel/time/tick-sched.c

finds 3992c0321258 ("Merge branch 'timers-core-for-linus'",
2012-07-22), which seems to have mismerged 2ac0d98fd624 ("nohz: Make
nohz API agnostic against idle ticks cputime accounting").

Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Seems like sched: Add missing call to calc_load_exit_idle() should be reverted in 3.5 branch

[Jonathan Nieder]

Peter Zijlstra wrote:

 I can't find wtf went wrong either, the initial patch 5167e8d5417bf5c
 contains both hunks, but in that case the fixup 749c8814f0 doesn't make
 sense, not can I find anything in merge commits using:

   git log -S calc_load_exit_idle kernel/time/tick-sched.c

 git log -m -p --first-parent -Scalc_load_exit_idle -- kernel/time/tick-sched.c

finds 3992c0321258 (Merge branch 'timers-core-for-linus',
2012-07-22), which seems to have mismerged 2ac0d98fd624 (nohz: Make
nohz API agnostic against idle ticks cputime accounting).

Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] psmouse: mitigate failing-mouse symptoms

[Jonathan Nieder]

Hi Jim,

In January, 2011, Jim Hill wrote:

> Keep a failing PS/2 mouse usable until it's convenient to replace it.
> Filter incoming packets: drop invalid ones and attempt to correct for
> dropped bytes.
>
> New parameter 'filter' makes filtering and logging selectable, set to 0
> to shut off all effects.
[...]
> My mouse failed while in XP, but I didn't know it - it seemed it'd need
> cleaning soon. On booting into Linux, it was dangerous, wild slews and
> random clicks.  The difference was consistent, making it seem the
> problem wasn't the mouse.

I think this would be less controversial if the run-time default were
to disable the feature.  Then if lots of people are setting the
parameter and the idea proves itself, the default could change, and in
the meantime, people with broken setups would know about the breakage
and get a chance to look for other problems.

What do you think?

Thanks for your work,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] psmouse: mitigate failing-mouse symptoms

[Jonathan Nieder]

Hi Jim,

In January, 2011, Jim Hill wrote:

 Keep a failing PS/2 mouse usable until it's convenient to replace it.
 Filter incoming packets: drop invalid ones and attempt to correct for
 dropped bytes.

 New parameter 'filter' makes filtering and logging selectable, set to 0
 to shut off all effects.
[...]
 My mouse failed while in XP, but I didn't know it - it seemed it'd need
 cleaning soon. On booting into Linux, it was dangerous, wild slews and
 random clicks.  The difference was consistent, making it seem the
 problem wasn't the mouse.

I think this would be less controversial if the run-time default were
to disable the feature.  Then if lots of people are setting the
parameter and the idea proves itself, the default could change, and in
the meantime, people with broken setups would know about the breakage
and get a chance to look for other problems.

What do you think?

Thanks for your work,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] posix_types.h: Cleanup stale __NFDBITS and related definitions

[Jonathan Nieder]

Josh Boyer wrote:

> That should be the question, yes.  The answer is:
>
> However far back people wish to use older stable kernel-headers to build
> applications against newer glibc.
>
> It isn't a clear answer.

Thanks for explaining.

>   Some people stick with older kernels while
> they update their userspace.  I was thinking along the lines of the 3.0
> kernel being the oldest I'd check for but if people think we shouldn't
> bother than that's fine by me.

Based on your explanation, I think 3.0 makes sense, while older
kernels like 2.6.32 are less likely to benefit.  Even when you are
stuck with an old kernel, it is possible to use newer kernel headers.

Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] posix_types.h: Cleanup stale __NFDBITS and related definitions

[Jonathan Nieder]

Hi,

Josh Boyer wrote:

> Indeed.  However, I believe Linus pointed out that even before
> 8b3d1cda4f5f the macros that were removed weren't actually used.
> It's likely safe to go back further than just 3.4.
>
> I'll verify again in the morning and include the furthest back we could
> remove these.  For now, let's go with what you suggest to be safe.

I may be in the minority in having this view or missing a subtlety,
but shouldn't the question be the furthest back we need to remove
these rather than the furthest back we could?

Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] posix_types.h: Cleanup stale __NFDBITS and related definitions

[Jonathan Nieder]

Hi,

Josh Boyer wrote:

 Indeed.  However, I believe Linus pointed out that even before
 8b3d1cda4f5f the macros that were removed weren't actually used.
 It's likely safe to go back further than just 3.4.

 I'll verify again in the morning and include the furthest back we could
 remove these.  For now, let's go with what you suggest to be safe.

I may be in the minority in having this view or missing a subtlety,
but shouldn't the question be the furthest back we need to remove
these rather than the furthest back we could?

Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] posix_types.h: Cleanup stale __NFDBITS and related definitions

[Jonathan Nieder]

Josh Boyer wrote:

 That should be the question, yes.  The answer is:

 However far back people wish to use older stable kernel-headers to build
 applications against newer glibc.

 It isn't a clear answer.

Thanks for explaining.

   Some people stick with older kernels while
 they update their userspace.  I was thinking along the lines of the 3.0
 kernel being the oldest I'd check for but if people think we shouldn't
 bother than that's fine by me.

Based on your explanation, I think 3.0 makes sense, while older
kernels like 2.6.32 are less likely to benefit.  Even when you are
stuck with an old kernel, it is possible to use newer kernel headers.

Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/17] NFS: nfs_migrate_page() does not wait for FS-Cache to finish with a page

[Jonathan Nieder]

Hi,

In February, David Howells wrote:

> nfs_migrate_page() does not wait for FS-Cache to finish with a page, probably
> leading to the following bad-page-state:
[...]
> nfs_migrate_page() calls nfs_fscache_release_page() which doesn't actually 
> wait
> - even if __GFP_WAIT is set.  The reason that doesn't wait is that
> fscache_maybe_release_page() might deadlock the allocator as the work threads
> writing to the cache may all end up sleeping on memory allocation.
[...]
>  (1) Make nfs_migrate_page() wait.
>
>  (2) Make fscache_maybe_release_page() honour the __GFP_WAIT flag.
>
>  (3) Set a timeout around the wait.
>
>  (4) Make nfs_migrate_page() return an error if the page is still busy.
>
> For the moment, I'll select (2) and (4).
[...]
> --- a/fs/nfs/write.c
> +++ b/fs/nfs/write.c
> @@ -1701,7 +1701,9 @@ int nfs_migrate_page(struct address_space *mapping, 
> struct page *newpage,
>   if (PagePrivate(page))
>   return -EBUSY;
>  
> - nfs_fscache_release_page(page, GFP_KERNEL);
> + ret = -EBUSY;
> + if (!nfs_fscache_release_page(page, GFP_KERNEL))
> + goto out;
>  
>   return migrate_page(mapping, newpage, page, mode);
>  }

Small thing, but it looks like this was forward-ported incorrectly.
Was this ever tested with CONFIG_MIGRATION enabled?

Hope that helps,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/17] NFS: nfs_migrate_page() does not wait for FS-Cache to finish with a page

[Jonathan Nieder]

Hi,

In February, David Howells wrote:

 nfs_migrate_page() does not wait for FS-Cache to finish with a page, probably
 leading to the following bad-page-state:
[...]
 nfs_migrate_page() calls nfs_fscache_release_page() which doesn't actually 
 wait
 - even if __GFP_WAIT is set.  The reason that doesn't wait is that
 fscache_maybe_release_page() might deadlock the allocator as the work threads
 writing to the cache may all end up sleeping on memory allocation.
[...]
  (1) Make nfs_migrate_page() wait.

  (2) Make fscache_maybe_release_page() honour the __GFP_WAIT flag.

  (3) Set a timeout around the wait.

  (4) Make nfs_migrate_page() return an error if the page is still busy.

 For the moment, I'll select (2) and (4).
[...]
 --- a/fs/nfs/write.c
 +++ b/fs/nfs/write.c
 @@ -1701,7 +1701,9 @@ int nfs_migrate_page(struct address_space *mapping, 
 struct page *newpage,
   if (PagePrivate(page))
   return -EBUSY;
  
 - nfs_fscache_release_page(page, GFP_KERNEL);
 + ret = -EBUSY;
 + if (!nfs_fscache_release_page(page, GFP_KERNEL))
 + goto out;
  
   return migrate_page(mapping, newpage, page, mode);
  }

Small thing, but it looks like this was forward-ported incorrectly.
Was this ever tested with CONFIG_MIGRATION enabled?

Hope that helps,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

sched: care and feeding of load-avg code (Re: [PATCH] sched: Folding nohz load accounting more accurate)

[Jonathan Nieder]

Hi,

Doug Smythies wrote:

> On my computer, and from a different thread from yesterday, I let
> the proposed "wang" patch multiple processes test continue for
> another 24 hours. The png file showing the results is attached, also
> available at [1].
[...]
> http://www.smythies.com/~doug/network/load_average/load_processes_wang.html

Thanks.

Now that a nice patch seems to be available that takes care of
everything :), it seems like a good moment to make sure that the next
time there are scheduler changes people can easily see what they need
to do.

That is, what information would someone new to this code benefit from
in order to keep it working well?

I am particularly interested in making sure your tests don't get lost.
How about something like this?

-- >8 --
Subject: sched: add skeleton load-avg documentation

For now this is just a link to
http://www.smythies.com/~doug/network/load_average/ which has some
useful examples of how to test changes.

Signed-off-by: Jonathan Nieder 
---
 Documentation/scheduler/00-INDEX   |2 ++
 Documentation/scheduler/sched-load.txt |   16 
 2 files changed, 18 insertions(+)
 create mode 100644 Documentation/scheduler/sched-load.txt

diff --git a/Documentation/scheduler/00-INDEX b/Documentation/scheduler/00-INDEX
index d2651c47ae27..99c75547282d 100644
--- a/Documentation/scheduler/00-INDEX
+++ b/Documentation/scheduler/00-INDEX
@@ -6,6 +6,8 @@ sched-design-CFS.txt
- goals, design and implementation of the Completely Fair Scheduler.
 sched-domains.txt
- information on scheduling domains.
+sched-load.txt
+   - how load-average code works and how to keep it working.
 sched-nice-design.txt
- How and why the scheduler's nice levels are implemented.
 sched-rt-group.txt
diff --git a/Documentation/scheduler/sched-load.txt 
b/Documentation/scheduler/sched-load.txt
new file mode 100644
index ..1653d5aa
--- /dev/null
+++ b/Documentation/scheduler/sched-load.txt
@@ -0,0 +1,16 @@
+load averages
+=
+
+Reported load averages are by necessity an approximation, but with
+care we can make sure they approximate reality most of the time.
+
+Talk about kernel/sched/core.c, including:
+
+* what is the expected load average?
+* workloads to test, automated testing
+* known problems, e.g. limitations due to finite-precision math
+* interaction with CPU frequency scaling
+* relevant links such as
+  http://www.smythies.com/~doug/network/load_average/
+
+(Peter Zijlstra, Doug Smythies, Charles Wang)
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 11/37] sched/nohz: Rewrite and fix load-avg computation -- again

[Jonathan Nieder]

Peter Zijlstra wrote:
> On Tue, 2012-07-17 at 19:16 -0500, Jonathan Nieder wrote:

>> I'm thrilled to see this regression fix for stable@, but are we really
>> really sure that it won't cause new regressions? 
>
> Doug Smythies ran a ~68 hour test on it, running various synthetic loads
> of various frequencies against it and comparing the reported load
> averages against the expected values and found it to be 'good'.
>
> This doesn't guarantee we won't find more 'interesting' problems in
> there, but it does give me fair confidence in it.

Yeah, that sounds good.  Very nice to hear.

Is the code to generate the synthetic loads and expected results
somewhere easy to find (like LTP or tools/testing) to make it easier
to keep this code working well in the future?

Grateful,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 06/34] vmscan: add shrink_slab tracepoints

[Jonathan Nieder]

Mel Gorman wrote:
> On Thu, Jul 19, 2012 at 05:07:21PM -0500, Jonathan Nieder wrote:

>> Some of the other patches of this type made sense, but I'd personally
>> prefer if this one was dropped, yes.  Though I am just a nobody that
>> reads patches rather than one of the relevant people. ;-)
>
> It's a valid point but I'm going to leave it in for now and see what the
> general opinion is.

Ok.  To be more precise, this patch has two properties that other patches
of the "make later patches easier to apply" class tend not to:

 * it introduces a significant functional change (adding tracepoints)
 * it would have been very easy to skip

Have fun, and sorry for not explaining my reasoning before.

Ciao,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 06/34] vmscan: add shrink_slab tracepoints

[Jonathan Nieder]

Mel Gorman wrote:
 On Thu, Jul 19, 2012 at 05:07:21PM -0500, Jonathan Nieder wrote:

 Some of the other patches of this type made sense, but I'd personally
 prefer if this one was dropped, yes.  Though I am just a nobody that
 reads patches rather than one of the relevant people. ;-)

 It's a valid point but I'm going to leave it in for now and see what the
 general opinion is.

Ok.  To be more precise, this patch has two properties that other patches
of the make later patches easier to apply class tend not to:

 * it introduces a significant functional change (adding tracepoints)
 * it would have been very easy to skip

Have fun, and sorry for not explaining my reasoning before.

Ciao,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 11/37] sched/nohz: Rewrite and fix load-avg computation -- again

[Jonathan Nieder]

Peter Zijlstra wrote:
 On Tue, 2012-07-17 at 19:16 -0500, Jonathan Nieder wrote:

 I'm thrilled to see this regression fix for stable@, but are we really
 really sure that it won't cause new regressions? 

 Doug Smythies ran a ~68 hour test on it, running various synthetic loads
 of various frequencies against it and comparing the reported load
 averages against the expected values and found it to be 'good'.

 This doesn't guarantee we won't find more 'interesting' problems in
 there, but it does give me fair confidence in it.

Yeah, that sounds good.  Very nice to hear.

Is the code to generate the synthetic loads and expected results
somewhere easy to find (like LTP or tools/testing) to make it easier
to keep this code working well in the future?

Grateful,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

sched: care and feeding of load-avg code (Re: [PATCH] sched: Folding nohz load accounting more accurate)

[Jonathan Nieder]

Hi,

Doug Smythies wrote:

 On my computer, and from a different thread from yesterday, I let
 the proposed wang patch multiple processes test continue for
 another 24 hours. The png file showing the results is attached, also
 available at [1].
[...]
 http://www.smythies.com/~doug/network/load_average/load_processes_wang.html

Thanks.

Now that a nice patch seems to be available that takes care of
everything :), it seems like a good moment to make sure that the next
time there are scheduler changes people can easily see what they need
to do.

That is, what information would someone new to this code benefit from
in order to keep it working well?

I am particularly interested in making sure your tests don't get lost.
How about something like this?

-- 8 --
Subject: sched: add skeleton load-avg documentation

For now this is just a link to
http://www.smythies.com/~doug/network/load_average/ which has some
useful examples of how to test changes.

Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
 Documentation/scheduler/00-INDEX   |2 ++
 Documentation/scheduler/sched-load.txt |   16 
 2 files changed, 18 insertions(+)
 create mode 100644 Documentation/scheduler/sched-load.txt

diff --git a/Documentation/scheduler/00-INDEX b/Documentation/scheduler/00-INDEX
index d2651c47ae27..99c75547282d 100644
--- a/Documentation/scheduler/00-INDEX
+++ b/Documentation/scheduler/00-INDEX
@@ -6,6 +6,8 @@ sched-design-CFS.txt
- goals, design and implementation of the Completely Fair Scheduler.
 sched-domains.txt
- information on scheduling domains.
+sched-load.txt
+   - how load-average code works and how to keep it working.
 sched-nice-design.txt
- How and why the scheduler's nice levels are implemented.
 sched-rt-group.txt
diff --git a/Documentation/scheduler/sched-load.txt 
b/Documentation/scheduler/sched-load.txt
new file mode 100644
index ..1653d5aa
--- /dev/null
+++ b/Documentation/scheduler/sched-load.txt
@@ -0,0 +1,16 @@
+load averages
+=
+
+Reported load averages are by necessity an approximation, but with
+care we can make sure they approximate reality most of the time.
+
+Talk about kernel/sched/core.c, including:
+
+* what is the expected load average?
+* workloads to test, automated testing
+* known problems, e.g. limitations due to finite-precision math
+* interaction with CPU frequency scaling
+* relevant links such as
+  http://www.smythies.com/~doug/network/load_average/
+
+(Peter Zijlstra, Doug Smythies, Charles Wang)
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/