[PATCH]

[PATCH]

[Michal Ludvig]

[-- Attachment #1.1: Type: text/plain, Size: 481 bytes --]

Hi James,

the aes-i586 patch recently added to BK breaks compilation of AES on
non-i586 platforms. Attached patch fixes it.

BTW Why was the config option renamed to CRYPTO_AES_GENERIC? The
optimized implementations had their own names anyway (e.g.
CRYPTO_AES_586) and wouldn't collide. Couldn't we revert this little change?

Michal Ludvig
-- 
SUSE Labs                    mludvig@suse.cz
(+420) 296.542.396        http://www.suse.cz
Personal homepage http://www.logix.cz/michal

[-- Attachment #1.2: build-crypto-aes --]
[-- Type: text/plain, Size: 586 bytes --]

Index: linux-2.6.7/crypto/Makefile
===================================================================
--- linux-2.6.7.orig/crypto/Makefile	2004-08-05 17:44:32.428599792 +0200
+++ linux-2.6.7/crypto/Makefile	2004-08-05 17:46:07.589133192 +0200
@@ -18,7 +18,7 @@
 obj-$(CONFIG_CRYPTO_BLOWFISH) += blowfish.o
 obj-$(CONFIG_CRYPTO_TWOFISH) += twofish.o
 obj-$(CONFIG_CRYPTO_SERPENT) += serpent.o
-obj-$(CONFIG_CRYPTO_AES) += aes.o
+obj-$(CONFIG_CRYPTO_AES_GENERIC) += aes.o
 obj-$(CONFIG_CRYPTO_CAST5) += cast5.o
 obj-$(CONFIG_CRYPTO_CAST6) += cast6.o
 obj-$(CONFIG_CRYPTO_ARC4) += arc4.o

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [PATCH]

[James Morris]

On Thu, 5 Aug 2004, Michal Ludvig wrote:

> Hi James,
> 
> the aes-i586 patch recently added to BK breaks compilation of AES on
> non-i586 platforms. Attached patch fixes it.

Thanks, the code is about to be dropped and replaced, so we need to
remember to fix it then.


- James
-- 
James Morris
<jmorris@redhat.com>

Re: [PATCH]

[Jean-Luc Cooke]

James,

Would you be against a patch to cryptoapi to have access to a
non-scatter-list set of calls?

I know a few people would like to see that , and I would also like to use
some low-level:

crypto_digest_update_byte(struct digest_alg *digest,
                          unsigned char *buf,
                          unsigned int  nbytes);
crypto_cipher_encrypt_byte(struct cipher_alg *cipher,
                           unsigned char *dst,
                           unsigned char *src,
                           unsigned int  nbytes);

I'm in the middle of preparing for a paper and would like to get code running
without scatterlists.

Cheers,

JLC

On Thu, Aug 05, 2004 at 10:11:14AM -0400, James Morris wrote:
> On Thu, 5 Aug 2004, Michal Ludvig wrote:
> 
> > Hi James,
> > 
> > the aes-i586 patch recently added to BK breaks compilation of AES on
> > non-i586 platforms. Attached patch fixes it.
> 
> Thanks, the code is about to be dropped and replaced, so we need to
> remember to fix it then.
> 
> 
> - James
> -- 
> James Morris
> <jmorris@redhat.com>
> 
> 
> _______________________________________________
> 
> Subscription: http://lists.logix.cz/mailman/listinfo/cryptoapi
> List archive: http://lists.logix.cz/pipermail/cryptoapi

Re: [PATCH]

[James Morris]

On Thu, 5 Aug 2004, Jean-Luc Cooke wrote:

> Would you be against a patch to cryptoapi to have access to a
> non-scatter-list set of calls?
> 
> I know a few people would like to see that , and I would also like to use
> some low-level:
> 
> crypto_digest_update_byte(struct digest_alg *digest,
>                           unsigned char *buf,
>                           unsigned int  nbytes);
> crypto_cipher_encrypt_byte(struct cipher_alg *cipher,
>                            unsigned char *dst,
>                            unsigned char *src,
>                            unsigned int  nbytes);
> 
> I'm in the middle of preparing for a paper and would like to get code running
> without scatterlists.

The idea of the scatterlist API is to encourage encryption at the page
level.  Can you demonstrate a compelling need for raw access to the
algorithms via the API?


- James
-- 
James Morris
<jmorris@redhat.com>

Re: [PATCH]

[Michael Halcrow]

[-- Attachment #1: Type: text/plain, Size: 1447 bytes --]

On Thu, Aug 05, 2004 at 10:47:12PM -0400, James Morris wrote:
> On Thu, 5 Aug 2004, Jean-Luc Cooke wrote:
> 
> > Would you be against a patch to cryptoapi to have access to a
> > non-scatter-list set of calls?
> > 
> > I know a few people would like to see that , and I would also like to use
> > some low-level:
> > 
> > crypto_digest_update_byte(struct digest_alg *digest,
> >                           unsigned char *buf,
> >                           unsigned int  nbytes);
> > crypto_cipher_encrypt_byte(struct cipher_alg *cipher,
> >                            unsigned char *dst,
> >                            unsigned char *src,
> >                            unsigned int  nbytes);
> > 
> > I'm in the middle of preparing for a paper and would like to get code running
> > without scatterlists.
> 
> The idea of the scatterlist API is to encourage encryption at the
> page level.  Can you demonstrate a compelling need for raw access to
> the algorithms via the API?

I often have a virtual address to work with in the first place, and
the data that I hash usually occupies less than one page (passphrases,
keys, etc.).

Mike
.___________________________________________________________________.
                         Michael A. Halcrow                          
       Security Software Engineer, IBM Linux Technology Center       
GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D  2371 2D3C FDDA 3EB6 601D

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH]

[Linus Torvalds]

On Thu, 5 Aug 2004, Michael Halcrow wrote:
> 
> I often have a virtual address to work with in the first place, and
> the data that I hash usually occupies less than one page (passphrases,
> keys, etc.).

Ehh. A lot of encryption algorithms are not re-entrant, which means that 
you can't take page faults in the middle without serious trouble.

And if the data is smaller than a page, then it's cheaper to just copy it
into kernel memory than it is to try to follow the page tables by hand.  
One is usually nice cached accesses, the other one is nasty code with
locking and often totally uncached.

So I'd strongly suggest against doing any "raw crypto access". Zero-copy
is often just a complicated way of doing things slowly, all in the name of
some benchmark performance.

		Linus

Re: [PATCH]

[Jean-Luc Cooke]

On Thu, Aug 05, 2004 at 09:58:58PM -0700, Linus Torvalds wrote:
> So I'd strongly suggest against doing any "raw crypto access". Zero-copy
> is often just a complicated way of doing things slowly, all in the name of
> some benchmark performance.

I hear you, these are all desirable things and I hate trying to be the black
sheep - but would random.c make sense in being the exception since the
outward looking interfaces (random_write for example) all use const char*
type as arguments?

Keeping the existing random.c interface and using crypto-api's scatter-gather
interface are kind of contradictory ... or and I really missing something
important (likely)?

JLC

Re: [PATCH]

[YOSHIFUJI Hideaki / 吉藤英明]

In article <Xine.LNX.4.44.0408052245380.20516-100000@dhcp83-76.boston.redhat.com> (at Thu, 5 Aug 2004 22:47:12 -0400 (EDT)), James Morris <jmorris@redhat.com> says:

> > Would you be against a patch to cryptoapi to have access to a
> > non-scatter-list set of calls?
:
> level.  Can you demonstrate a compelling need for raw access to the
> algorithms via the API?

I would use them for
 - Privacy Extensions (RFC3041) support
 - upcoming TCP MD5 signature (RFC2385) support
since I don't see the advantage(s) of sg for allocated memories there.

--yoshfuji

Re: [PATCH]

[David S. Miller]

On Thu, 05 Aug 2004 20:36:23 -0700 (PDT)
YOSHIFUJI Hideaki / ^[$B5HF#1QL@^[(B <yoshfuji@linux-ipv6.org> wrote:

> In article <Xine.LNX.4.44.0408052245380.20516-100000@dhcp83-76.boston.redhat.com> (at Thu, 5 Aug 2004 22:47:12 -0400 (EDT)), James Morris <jmorris@redhat.com> says:
> 
> > > Would you be against a patch to cryptoapi to have access to a
> > > non-scatter-list set of calls?
> :
> > level.  Can you demonstrate a compelling need for raw access to the
> > algorithms via the API?
> 
> I would use them for
>  - Privacy Extensions (RFC3041) support
>  - upcoming TCP MD5 signature (RFC2385) support
> since I don't see the advantage(s) of sg for allocated memories there.

But here is the problem, it's going to be implemented as a scatter-
gather list on the stack to pass on to the actual crypto layer.

If you just blindly use this new interface, you may not be aware
of this overhead and thus not consider moving to sg-based methods.
This is what I want to avoid.

Yes, it is social engineering. :-)

I see nothing wrong with explicitly coding things out, as we do
now.

Re: [PATCH]

[Jean-Luc Cooke]

On Thu, Aug 05, 2004 at 08:36:23PM -0700, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> In article <Xine.LNX.4.44.0408052245380.20516-100000@dhcp83-76.boston.redhat.com> (at Thu, 5 Aug 2004 22:47:12 -0400 (EDT)), James Morris <jmorris@redhat.com> says:
> 
> > > Would you be against a patch to cryptoapi to have access to a
> > > non-scatter-list set of calls?
> :
> > level.  Can you demonstrate a compelling need for raw access to the
> > algorithms via the API?
> 
> I would use them for
>  - Privacy Extensions (RFC3041) support
>  - upcoming TCP MD5 signature (RFC2385) support
> since I don't see the advantage(s) of sg for allocated memories there.

Thank you for your input.  But please read this note in the RFC2385:
http://www.faqs.org/rfcs/rfc2385.html
 "Section 4.4: MD5 as a Hashing Algorithm"
 It talks about MD5 as an insecure algorithm and how changing it would
 require a new RFC, which make me sad.
 If you could add support for SHA-1 as well that would be nifty.
 
James,
  Back to your question:
    I want to replace the legacy MD5 and the incorrectly implemented SHA-1
    implementations from driver/char/random.c

Thanks, cheers!

JLC

Re: [PATCH]

[James Morris]

On Fri, 6 Aug 2004, Jean-Luc Cooke wrote:

> James,
>   Back to your question:
>     I want to replace the legacy MD5 and the incorrectly implemented SHA-1
>     implementations from driver/char/random.c

Incorrectly implemented?  Do you mean not appending the bit count?


- James
-- 
James Morris
<jmorris@redhat.com>

Re: [PATCH]

[Jean-Luc Cooke]

On Fri, Aug 06, 2004 at 12:42:38AM -0400, James Morris wrote:
> On Fri, 6 Aug 2004, Jean-Luc Cooke wrote:
> 
> > James,
> >   Back to your question:
> >     I want to replace the legacy MD5 and the incorrectly implemented SHA-1
> >     implementations from driver/char/random.c
> 
> Incorrectly implemented?  Do you mean not appending the bit count?

That and it's not endian-correct.  There are other issues with random.c (lack
for forward secrecy in the case of seed discovery, use of the insecure MD4 in
creating syn and seq# for tcp, the use of halfMD4 and twothridsMD4 is
madness
(what is 2/3's of 16!?!), the use of LFSRs for "mixing" when they're linear,
the polymonials used are not even primitive, the ability for root to wipe-out
the random pool, the ability for root to access the random seed directly, the
paper I'm co-authoring will explain all of this).

Basically, the paper will be describing about 12 security problems with the
current random.c and propose (with patch included) a new design that solves
all of these, uses crypto-api, uses known crypto primitives, is simpler to
read
and analyse and for a bonus is 2x to 4x faster in adding and retrieving data
from the pool.

If I can avoid scatter-gather for what is effectively just mixing bytes with
SHA256
& AES256 then this would make things very neat and tidy (read: easier for
peer review)

Cheers,

JLC

Re: [PATCH]

[David S. Miller]

On Fri, 6 Aug 2004 08:54:27 -0400
Jean-Luc Cooke <jlcooke@certainkey.com> wrote:

> If I can avoid scatter-gather for what is effectively just mixing bytes with
> SHA256
> & AES256 then this would make things very neat and tidy (read: easier for
> peer review)

Why do you care about scatter gather at all?  You need to allocate
a kernel buffer to copy the user bits into _anyways_.  Once you
have a kernel buffer, doing a quick onstack one-entry scatter list
is simple.

If you're trying to use the user buffer directly, sorry we're not
going to add support for that, as Linus explained it's silly.

Re: [PATCH]

[Jean-Luc Cooke]

OK then,

I tried.  scretterlists it is... I'm a push over.  ;)

JLC

On Fri, Aug 06, 2004 at 11:26:46AM -0700, David S. Miller wrote:
> On Fri, 6 Aug 2004 08:54:27 -0400
> Jean-Luc Cooke <jlcooke@certainkey.com> wrote:
> 
> > If I can avoid scatter-gather for what is effectively just mixing bytes with
> > SHA256
> > & AES256 then this would make things very neat and tidy (read: easier for
> > peer review)
> 
> Why do you care about scatter gather at all?  You need to allocate
> a kernel buffer to copy the user bits into _anyways_.  Once you
> have a kernel buffer, doing a quick onstack one-entry scatter list
> is simple.
> 
> If you're trying to use the user buffer directly, sorry we're not
> going to add support for that, as Linus explained it's silly.

Re: [PATCH]

[Matt Mackall]

On Fri, Aug 06, 2004 at 08:54:27AM -0400, Jean-Luc Cooke wrote:
> On Fri, Aug 06, 2004 at 12:42:38AM -0400, James Morris wrote:
> > On Fri, 6 Aug 2004, Jean-Luc Cooke wrote:
> > 
> > > James,
> > >   Back to your question:
> > >     I want to replace the legacy MD5 and the incorrectly implemented SHA-1
> > >     implementations from driver/char/random.c
> > 
> > Incorrectly implemented?  Do you mean not appending the bit count?
> 
> That and it's not endian-correct.

Are you saying that it's hashing incorrectly or that the final form is
not in the standard bit-order? For the purposes of a random number
generator, the latter isn't terribly important. Nor is it particularly
important for GUIDs.

> There are other issues with random.c (lack
> for forward secrecy in the case of seed discovery, use of the insecure MD4 in
> creating syn and seq# for tcp, the use of halfMD4 and twothridsMD4 is
> madness
> (what is 2/3's of 16!?!), the use of LFSRs for "mixing" when they're linear,
> the polymonials used are not even primitive, the ability for root to wipe-out
> the random pool, the ability for root to access the random seed directly, the
> paper I'm co-authoring will explain all of this).
> 
> Basically, the paper will be describing about 12 security problems with the
> current random.c and propose (with patch included) a new design that solves
> all of these, uses crypto-api, uses known crypto primitives, is simpler to
> read
> and analyse and for a bonus is 2x to 4x faster in adding and retrieving data
> from the pool.

Last time I proposed a cryptoapi-based version, I couldn't get any
buy-off on making cryptoapi a non-optional part of the kernel. Looking
forward to your patch/paper.

-- 
Mathematics is the supreme nostalgia of our time.

Re: [PATCH]

[Jean-Luc Cooke]

On Fri, Aug 06, 2004 at 06:24:52PM -0500, Matt Mackall wrote:
> On Fri, Aug 06, 2004 at 08:54:27AM -0400, Jean-Luc Cooke wrote:
> > On Fri, Aug 06, 2004 at 12:42:38AM -0400, James Morris wrote:
> > > On Fri, 6 Aug 2004, Jean-Luc Cooke wrote:
> > > 
> > > > James,
> > > >   Back to your question:
> > > >     I want to replace the legacy MD5 and the incorrectly implemented SHA-1
> > > >     implementations from driver/char/random.c
> > > 
> > > Incorrectly implemented?  Do you mean not appending the bit count?
> > 
> > That and it's not endian-correct.
> 
> Are you saying that it's hashing incorrectly or that the final form is
> not in the standard bit-order? For the purposes of a random number
> generator, the latter isn't terribly important. Nor is it particularly
> important for GUIDs.

The problems with the SHA1 implementation is the least of random.c's
concerns.  But it's just bad taste to tell on-lookers "we use SHA-1" and you
actually don't.  It causes people to re-evailuate your implementation.

Ease of reading, ease of analysis are related to using proper implementations
of cryptographic primitives.

> Last time I proposed a cryptoapi-based version, I couldn't get any
> buy-off on making cryptoapi a non-optional part of the kernel. Looking
> forward to your patch/paper.

I'll credit you for breaking the ice if capi becomes a standard feature.  ;)

JLC

Re: [PATCH]

[Theodore Ts'o]

On Fri, Aug 06, 2004 at 08:54:27AM -0400, Jean-Luc Cooke wrote:
> That and it's not endian-correct.  There are other issues with random.c (lack
> for forward secrecy in the case of seed discovery, use of the insecure MD4 in
> creating syn and seq# for tcp, the use of halfMD4 and twothridsMD4 is
> madness
> (what is 2/3's of 16!?!), 

This was deliberate becasue sequence number generation could not be
slow for some workloads.  The sequence number attacks that MD4
protects against are tcp hijacking attacks where the attacker is on
the network path ---- if you really want security you'd be using real
crypto for encryption and for integrity protection at the application
layer.

> the use of LFSRs for "mixing" when they're linear,
> the polymonials used are not even primitive, 

The basic idea here is that you can mix in arbitrary amounts of zero
data without destroying the randomness of the pool.  This is
important, and was an explicit design goal.

> the ability for root to wipe-out
> the random pool, the ability for root to access the random seed directly, the
> paper I'm co-authoring will explain all of this).

Yawn.  Root has access to /dev/mem.  Your point?

							- Ted

Re: [PATCH]

[Jean-Luc Cooke]

Glad to have you join the discussion Ted!

On Sat, Aug 07, 2004 at 06:26:34PM -0400, Theodore Ts'o wrote:
> On Fri, Aug 06, 2004 at 08:54:27AM -0400, Jean-Luc Cooke wrote:
> > That and it's not endian-correct.  There are other issues with random.c (lack
> > for forward secrecy in the case of seed discovery, use of the insecure MD4 in
> > creating syn and seq# for tcp, the use of halfMD4 and twothridsMD4 is
> > madness
> > (what is 2/3's of 16!?!), 
> 
> This was deliberate becasue sequence number generation could not be
> slow for some workloads.  The sequence number attacks that MD4
> protects against are tcp hijacking attacks where the attacker is on
> the network path ---- if you really want security you'd be using real
> crypto for encryption and for integrity protection at the application
> layer.

In our paper (I'm testing the patch now) we'll be proposing using the Fortuna
PRNG inplace of the current design.  It only uses SHA256 and AES256 (or any
message digest & block cipher combo).  The primary advantages of this design
would be:
 - It's simpler
 - It's faster
 - It doesn't "rool your own" crypto

> > the use of LFSRs for "mixing" when they're linear,
> > the polymonials used are not even primitive, 
> 
> The basic idea here is that you can mix in arbitrary amounts of zero
> data without destroying the randomness of the pool.  This is
> important, and was an explicit design goal.

If you pass all input data into a Yarrow-type PRNG - like the Fortuna PRNG
we're going to propose - you will never care about this since the current
state of the pools are always based on all the previous input.

> > the ability for root to wipe-out
> > the random pool, the ability for root to access the random seed directly, the
> > paper I'm co-authoring will explain all of this).
> 
> Yawn.  Root has access to /dev/mem.  Your point?

I guess the point I was trying to make was:
 - You never want to wipe out the pool
 - You never want to let people (not even yourself) get access to the pool
   The closest thing you can do (and the paper will explain this) is hash
   a counter and the data from each of your pools though a message digest
   and concatenate it together.

I'm really putting the horse infront of the cart here.  We'll put a paper up
for lkml to read by the end of the month which will fully explain:
 - Our reasoning
 - Our goals
 - Our results

Cheers,

JLC

Re: [PATCH]

[Theodore Ts'o]

On Sun, Aug 08, 2004 at 11:38:46AM -0400, Jean-Luc Cooke wrote:
> In our paper (I'm testing the patch now) we'll be proposing using the Fortuna
> PRNG inplace of the current design.  It only uses SHA256 and AES256 (or any
> message digest & block cipher combo).  The primary advantages of this design
> would be:
>  - It's simpler
>  - It's faster
>  - It doesn't "rool your own" crypto

SHA is not going to be faster than the cut-down MD4 --- and you can't
use a pure random sequence number for the initial TCP sequence number,
lest a packet from a previous TCP connection get mistaken as belong to
the newly created TCP stream.  See Bellovin's recommendations for
secure TCP sequnce number genreation for a discussion of the
constraints.  

> If you pass all input data into a Yarrow-type PRNG - like the Fortuna PRNG
> we're going to propose - you will never care about this since the current
> state of the pools are always based on all the previous input.

The Yarrow-type PRNG suffers from the problem that the entropy pool is
pathetically small.  It fundamentally assumes that the crypto checksum
is secure, and it is really much more of a *P*RNG than anything else.
The scheme used in the current /dev/random design is much closer to
that used by GPG, and relies on a large pool so that we can collect as
much entropy as possible from the hardware sources available to the
kernel.  I'm not familiar with the Fortuna PRNG that you're going to
propose, but my guess is that it will have a similar, much heavier
dependence on the crypto algorithms in terms of its assumptions.

						- Ted

Re: [PATCH]

[Jean-Luc Cooke]

On Mon, Aug 09, 2004 at 02:43:24PM -0400, Theodore Ts'o wrote:
> On Sun, Aug 08, 2004 at 11:38:46AM -0400, Jean-Luc Cooke wrote:
> > In our paper (I'm testing the patch now) we'll be proposing using the Fortuna
> > PRNG inplace of the current design.  It only uses SHA256 and AES256 (or any
> > message digest & block cipher combo).  The primary advantages of this design
> > would be:
> >  - It's simpler
> >  - It's faster
> >  - It doesn't "rool your own" crypto
> 
> SHA is not going to be faster than the cut-down MD4 --- and you can't
> use a pure random sequence number for the initial TCP sequence number,
> lest a packet from a previous TCP connection get mistaken as belong to
> the newly created TCP stream.  See Bellovin's recommendations for
> secure TCP sequnce number genreation for a discussion of the
> constraints.  
> 
> > If you pass all input data into a Yarrow-type PRNG - like the Fortuna PRNG
> > we're going to propose - you will never care about this since the current
> > state of the pools are always based on all the previous input.
> 
> The Yarrow-type PRNG suffers from the problem that the entropy pool is
> pathetically small.  It fundamentally assumes that the crypto checksum
> is secure, and it is really much more of a *P*RNG than anything else.
> The scheme used in the current /dev/random design is much closer to
> that used by GPG, and relies on a large pool so that we can collect as
> much entropy as possible from the hardware sources available to the
> kernel.  I'm not familiar with the Fortuna PRNG that you're going to
> propose, but my guess is that it will have a similar, much heavier
> dependence on the crypto algorithms in terms of its assumptions.

Fortuna overcomes the small pool size problem.  For the most part, I really
like how the current random.c collects data.  

The only parts we're proposing to replace are:
 - The pooling (thus, mixing) mechanizums as per in Fortuna by Schnier and
   Furguson
 - The random data output mechanizum (Fortuna)
 - TCP sequence number generation (AES in CTR mode truncated to 32 bits, has
   period of 2^32 and cannot be easily determined from pervious sequences)
   I will read your reference and learn from the implementation in random.c
 - TCP SYNcookies to encrypt 8bit "count" value and the 24bit "data" (MSS)
   value with AES in CTR mode.  I can prove that this is exactly what is
   being done now with the "two SHA1 hashes and a bunch of addition" method.

Crutial to my proposal will be not "not rock the boat".  That is, keeping all
important interfaces intact to not break anything else in the kernel.

JLC

Re: [PATCH]

[Theodore Ts'o]

On Mon, Aug 09, 2004 at 02:49:51PM -0400, Jean-Luc Cooke wrote:
> The only parts we're proposing to replace are:
>  - TCP sequence number generation (AES in CTR mode truncated to 32 bits, has
>    period of 2^32 and cannot be easily determined from pervious sequences)
>    I will read your reference and learn from the implementation in random.c

Nope, that's not sufficient.  There's a reason why we're doing what
we're doing in random.c.  To quote from RFC 1948:

   The choice of initial sequence numbers for a connection is not
   random.  Rather, it must be chosen so as to minimize the probability
   of old stale packets being accepted by new incarnations of the same
   connection [6, Appendix A].  Furthermore, implementations of TCP
   derived from 4.2BSD contain special code to deal with such
   reincarnations when the server end of the original connection is
   still in TIMEWAIT state [7, pp. 945].  Accordingly, SIMPLE
   RANDOMIZATION, AS SUGGESTED IN [8], WILL NOT WORK WELL.

The F() as defined in RFC 1948, needs to be a crypto hash.  But it
doesn't need to be a particularly strong hash.  If it takes longer for
the attacker to break the hash than our rekey interval, that's
sufficient, since what we're protecting any kind of secrecy of the
data; we just need to prevent the attacker from guessing the initial
sequence number just long enough so that he can't hijack a TCP
connection.  Hence the use of a cut-down MD4.  It's kludgy, yeah, and
it smells of roll-your-own-crypto, granted, but I emphasize again that
(a) this was never considered very high protection; if you really care
about protecting against these sorts of attacks, you will be using
application-level crypto (i.e., ssh'ing to a Cisco box instead of
using an unencrypted telnet connection), and (b) using real crypto is
too slow, and was affecting Linux in various network benchmarks.
That's why it was changed from the original MD5 as suggested by
Bellovin in RFC 1948, to a cut-down MD4.  

And we ***never*** were insane enough to use SHA, or suggest that the
use of SHA was a good idea in this particular application.  I don't
know why some people had the assumption that SHA was ever used in TCP
sequence number generation, but they were wrong; that was never the
case.

						- Ted

[PATCH]

[Dorine Tipo]

Fix unnecessary parentheses in drivers/staging/octeon/ethernet.c

The commit addresses the following code style issue reported by checkpatch:

Signed-off-by: Dorine Tipo <dorine.a.tipo@gmail.com>
---
 drivers/staging/octeon/ethernet.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/octeon/ethernet.c b/drivers/staging/octeon/ethernet.c
index 8e1f4b987a25..349308edbc9e 100644
--- a/drivers/staging/octeon/ethernet.c
+++ b/drivers/staging/octeon/ethernet.c
@@ -248,7 +248,7 @@ static int cvm_oct_common_change_mtu(struct net_device *dev, int new_mtu)
 
 	dev->mtu = new_mtu;
 
-	if ((interface < 2) &&
+	if (interface < 2 &&
 	    (cvmx_helper_interface_get_mode(interface) !=
 		CVMX_HELPER_INTERFACE_MODE_SPI)) {
 		int index = INDEX(priv->port);
@@ -294,7 +294,7 @@ static void cvm_oct_common_set_multicast_list(struct net_device *dev)
 	struct octeon_ethernet *priv = netdev_priv(dev);
 	int interface = INTERFACE(priv->port);
 
-	if ((interface < 2) &&
+	if (interface < 2 &&
 	    (cvmx_helper_interface_get_mode(interface) !=
 		CVMX_HELPER_INTERFACE_MODE_SPI)) {
 		union cvmx_gmxx_rxx_adr_ctl control;
@@ -346,7 +346,7 @@ static int cvm_oct_set_mac_filter(struct net_device *dev)
 	union cvmx_gmxx_prtx_cfg gmx_cfg;
 	int interface = INTERFACE(priv->port);
 
-	if ((interface < 2) &&
+	if (interface < 2 &&
 	    (cvmx_helper_interface_get_mode(interface) !=
 		CVMX_HELPER_INTERFACE_MODE_SPI)) {
 		int i;
-- 
2.25.1

Re: [PATCH]

[Julia Lawall]

On Sun, 29 Oct 2023, Dorine Tipo wrote:

> Fix unnecessary parentheses in drivers/staging/octeon/ethernet.c
>
> The commit addresses the following code style issue reported by checkpatch:

There is no subject line on this one.

julia


>
> Signed-off-by: Dorine Tipo <dorine.a.tipo@gmail.com>
> ---
>  drivers/staging/octeon/ethernet.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/octeon/ethernet.c b/drivers/staging/octeon/ethernet.c
> index 8e1f4b987a25..349308edbc9e 100644
> --- a/drivers/staging/octeon/ethernet.c
> +++ b/drivers/staging/octeon/ethernet.c
> @@ -248,7 +248,7 @@ static int cvm_oct_common_change_mtu(struct net_device *dev, int new_mtu)
>
>  	dev->mtu = new_mtu;
>
> -	if ((interface < 2) &&
> +	if (interface < 2 &&
>  	    (cvmx_helper_interface_get_mode(interface) !=
>  		CVMX_HELPER_INTERFACE_MODE_SPI)) {
>  		int index = INDEX(priv->port);
> @@ -294,7 +294,7 @@ static void cvm_oct_common_set_multicast_list(struct net_device *dev)
>  	struct octeon_ethernet *priv = netdev_priv(dev);
>  	int interface = INTERFACE(priv->port);
>
> -	if ((interface < 2) &&
> +	if (interface < 2 &&
>  	    (cvmx_helper_interface_get_mode(interface) !=
>  		CVMX_HELPER_INTERFACE_MODE_SPI)) {
>  		union cvmx_gmxx_rxx_adr_ctl control;
> @@ -346,7 +346,7 @@ static int cvm_oct_set_mac_filter(struct net_device *dev)
>  	union cvmx_gmxx_prtx_cfg gmx_cfg;
>  	int interface = INTERFACE(priv->port);
>
> -	if ((interface < 2) &&
> +	if (interface < 2 &&
>  	    (cvmx_helper_interface_get_mode(interface) !=
>  		CVMX_HELPER_INTERFACE_MODE_SPI)) {
>  		int i;
> --
> 2.25.1
>
>
>

[PATCH]

[Sergey Shtylyov]

Add myself as a reviewer for the libata PATA drivers -- there has been some
activity in this area still... 8-)
Having been hacking on ATA from the early 90s, I think I deserved this
highly responsible position, at last! :-)

Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>

---
This patch is against the 'master' branch of Damien Le Moal's 'libata.git'
repo.

 MAINTAINERS |    6 ++++++
 1 file changed, 6 insertions(+)

Index: libata/MAINTAINERS
===================================================================
--- libata.orig/MAINTAINERS
+++ libata/MAINTAINERS
@@ -10880,6 +10880,12 @@ T:	git git://git.kernel.org/pub/scm/linu
 F:	drivers/ata/pata_arasan_cf.c
 F:	include/linux/pata_arasan_cf_data.h
 
+LIBATA PATA DRIVERS
+R:	Sergey Shtylyov <s.shtylyov@omp.ru>
+L:	linux-ide@vger.kernel.org
+F:	drivers/ata/ata_*.c
+F:	drivers/ata/pata_*.c
+
 LIBATA PATA FARADAY FTIDE010 AND GEMINI SATA BRIDGE DRIVERS
 M:	Linus Walleij <linus.walleij@linaro.org>
 L:	linux-ide@vger.kernel.org

Re: trace-cmd fails with many cpus

[Steven Rostedt]

On Fri, 12 Apr 2019 09:53:33 -0400
Phil Auld <pauld@redhat.com> wrote:

> Hi,
> 
> I was trying to get some sched traces on a 160 cpu box yesterday. Trace-cmd 
> failed with 

Thanks for the report!

> 
> # ./tracecmd/trace-cmd record -e "sched:*" sleep 2
> none
> trace-cmd: Invalid argument
>   Failed filter of /sys/kernel/tracing/events/sched/sched_switch/filter
> 
> trace-cmd: No such file or directory
>   can not stat 'trace.dat.cpu0'
> #
> 
> 
> Which can be seen better with strace
> 
> [pid 97653] open("/sys/kernel/tracing/events/sched/sched_swap_numa/filter", O_WRONLY|O_TRUNC) = 5
> [pid 97653] write(5, "(common_pid!=97652)&&(common_pid"..., 3358) = 3358
> [pid 97653] close(5)                    = 0
> [pid 97653] open("/sys/kernel/tracing/events/sched/sched_switch/filter", O_WRONLY|O_TRUNC) = 5
> [pid 97653] write(5, "(common_pid!=97652)&&(common_pid"..., 6398) = -1 EINVAL (Invalid argument)
> [pid 97653] close(5)                    = 0
> 
> The filter file can only take a max write of length PAGE_SIZE. 

Ah yeah. By default we try not to trace the recorders. Newer kernels
have a set_event_pid which is used for only tracing specific tasks for
the events. I wonder if we should allow for "!pid" to be sent to that
file as something to not be traced?

But that doesn't help you now.

Hmm, I thought we had an option to disable this, but I don't see one.
That's the first thing we should do. Add an option such that you record
all events, even the threads (which is something I would definitely
want!).

> 
> The extra pid filtering added for "next_pid"  more or less doubles length
> and pushes it over the 4k limit. 
> 
> WRITE: /sys/kernel/tracing/events/sched/sched_switch/filter, len 6718, data "(common_pid!=100199)&&(common_pid!=100198)&&(common_pid!=100197)&&(common_pid!=100196)&&(common_pid!=100195)&&(common_pid!=100194)&&(common_pid!=100193)&&(common_pid!=100192)&&(common_pid!=100191) ... 160 of these ...
> &&(common_pid!=100040)||(next_pid!=100199)&&(next_pid!=100198)&&(next_pid!=100197)&&(next_pid!=100196)&&(next_pid!=100195)&&(next_pid!=100194)&&(next_pid!=100193)&&(next_pid!=100192)...  160 of these...
> 
> 
> I suppose the answer is don't run on a system with that many cpus  :)
> 
> But I wonder if it would be possible to have the threads each handle say 8 cpu
> files or something.

Actually, I think another solution is to consolidate the pids that are
to be excluded and sort them. Thus if we have (which is very likely the
case)

 (common_pid!=1000)&&(common_pid!=1001)&&(common_pid!=1002)

That we change that to:

  !((common_pid>=1000)||(common_pid<=1002))

Which would also have the affect of improving the filter logic within
the kernel as well.

Tzvetomir or Slavomir, would either of you be able to implement the
above? Both adding an option to disable this (--no-filter) and the
sorting of the excluded pids?

Thanks!

-- Steve


> 
> Or maybe have the kernel filter accept an "all_pid" that covered common_pid, next_pid, pid to reduce
> the number of items needed in there? 
> 

[PATCH] .

[Slavomir Kaslev]

On Fri, 2019-04-12 at 11:15 -0400, Steven Rostedt wrote:
> Actually, I think another solution is to consolidate the pids that
> are
> to be excluded and sort them. Thus if we have (which is very likely
> the
> case)
> 
>  (common_pid!=1000)&&(common_pid!=1001)&&(common_pid!=1002)
> 
> That we change that to:
> 
>   !((common_pid>=1000)||(common_pid<=1002))
> 
> Which would also have the affect of improving the filter logic within
> the kernel as well.
> 
> Tzvetomir or Slavomir, would either of you be able to implement the
> above? Both adding an option to disable this (--no-filter) and the
> sorting of the excluded pids?

Do you mean something like this? The comment for make_pid_filter() needs be
updated too. I'll send a proper patch tomorrow if this fixes the issue.

---
 tracecmd/trace-record.c | 110 +++++++++++++++++++++++++++-------------
 1 file changed, 74 insertions(+), 36 deletions(-)

diff --git a/tracecmd/trace-record.c b/tracecmd/trace-record.c
index 76ca92d..102e5ab 100644
--- a/tracecmd/trace-record.c
+++ b/tracecmd/trace-record.c
@@ -950,6 +950,57 @@ static void update_ftrace_pids(int reset)
 static void update_event_filters(struct buffer_instance *instance);
 static void update_pid_event_filters(struct buffer_instance *instance);
 
+static void append_filter_pid_range(char **filter, int *curr_len,
+				    const char *field,
+				    int start_pid, int end_pid, bool exclude)
+{
+	char *op, *op1, *op2, *op3;
+	int len;
+
+	op = *filter && **filter ? "||" : "";
+
+	// Handle thus case explicitly so that we get `pid==3` instead of
+	// `pid>=3&&pid<=3` for singleton ranges
+	if (start_pid == end_pid) {
+#define FMT	"%s(%s%s%d)"
+		len = snprintf(NULL, 0, FMT, op,
+			       field, exclude ? "!=" : "==", start_pid);
+		*filter = realloc(*filter, *curr_len + len + 1);
+		if (!*filter)
+			die("realloc");
+
+		len = snprintf(*filter + *curr_len, len + 1, FMT, op,
+			       field, exclude ? "!=" : "==", start_pid);
+		*curr_len += len;
+
+		return;
+#undef FMT
+	}
+
+	if (exclude) {
+		op1 = "<";
+		op2 = "||";
+		op3 = ">";
+	} else {
+		op1 = ">=";
+		op2 = "&&";
+		op3 = "<=";
+	}
+
+#define FMT	"%s(%s%s%d%s%s%s%d)"
+	len = snprintf(NULL, 0, FMT, op,
+		       field, op1, start_pid, op2,
+		       field, op3, end_pid);
+	*filter = realloc(*filter, *curr_len + len + 1);
+	if (!*filter)
+		die("realloc");
+
+	len = snprintf(*filter + *curr_len, len + 1, FMT, op,
+		       field, op1, start_pid, op2,
+		       field, op3, end_pid);
+	*curr_len += len;
+}
+
 /**
  * make_pid_filter - create a filter string to all pids against @field
  * @curr_filter: Append to a previous filter (may realloc). Can be NULL
@@ -963,54 +1014,41 @@ static void update_pid_event_filters(struct buffer_instance *instance);
  */
 static char *make_pid_filter(char *curr_filter, const char *field)
 {
+	int curr_len = 0, last_exclude = -1;
+	int start_pid = -1, last_pid = -1;
+	char *filter = NULL, *save;
 	struct filter_pids *p;
-	char *filter;
-	char *orit;
-	char *match;
-	char *str;
-	int curr_len = 0;
-	int len;
 
 	/* Use the new method if possible */
 	if (have_set_event_pid)
 		return NULL;
 
-	len = len_filter_pids + (strlen(field) + strlen("(==)||")) * nr_filter_pids;
-
-	if (curr_filter) {
-		curr_len = strlen(curr_filter);
-		filter = realloc(curr_filter, curr_len + len + strlen("(&&())"));
-		if (!filter)
-			die("realloc");
-		memmove(filter+1, curr_filter, curr_len);
-		filter[0] = '(';
-		strcat(filter, ")&&(");
-		curr_len = strlen(filter);
-	} else
-		filter = malloc(len);
-	if (!filter)
-		die("Failed to allocate pid filter");
-
-	/* Last '||' that is not used will cover the \0 */
-	str = filter + curr_len;
+	if (!filter_pids)
+		return curr_filter;
 
 	for (p = filter_pids; p; p = p->next) {
-		if (p->exclude) {
-			match = "!=";
-			orit = "&&";
-		} else {
-			match = "==";
-			orit = "||";
+		if (p->pid == last_pid - 1 && p->exclude == last_exclude) {
+			last_pid = p->pid;
+			continue;
 		}
-		if (p == filter_pids)
-			orit = "";
 
-		len = sprintf(str, "%s(%s%s%d)", orit, field, match, p->pid);
-		str += len;
+		if (start_pid != -1)
+			append_filter_pid_range(&filter, &curr_len, field,
+						start_pid, last_pid,
+						last_exclude);
+
+		start_pid = last_pid = p->pid;
+		last_exclude = p->exclude;
+
 	}
+	append_filter_pid_range(&filter, &curr_len, field,
+				start_pid, last_pid, last_exclude);
 
-	if (curr_len)
-		sprintf(str, ")");
+	if (curr_filter) {
+		save = filter;
+		asprintf(&filter, "(%s)&&(%s)", curr_filter, filter);
+		free(save);
+	}
 
 	return filter;
 }
-- 
2.19.1

[PATCH] .

[Slavomir Kaslev]

Signed-off-by: Slavomir Kaslev <kaslevs@vmware.com>
---
 tracecmd/trace-record.c | 110 +++++++++++++++++++++++++++-------------
 1 file changed, 74 insertions(+), 36 deletions(-)

diff --git a/tracecmd/trace-record.c b/tracecmd/trace-record.c
index 76ca92d..102e5ab 100644
--- a/tracecmd/trace-record.c
+++ b/tracecmd/trace-record.c
@@ -950,6 +950,57 @@ static void update_ftrace_pids(int reset)
 static void update_event_filters(struct buffer_instance *instance);
 static void update_pid_event_filters(struct buffer_instance *instance);
 
+static void append_filter_pid_range(char **filter, int *curr_len,
+				    const char *field,
+				    int start_pid, int end_pid, bool exclude)
+{
+	char *op, *op1, *op2, *op3;
+	int len;
+
+	op = *filter && **filter ? "||" : "";
+
+	// Handle thus case explicitly so that we get `pid==3` instead of
+	// `pid>=3&&pid<=3` for singleton ranges
+	if (start_pid == end_pid) {
+#define FMT	"%s(%s%s%d)"
+		len = snprintf(NULL, 0, FMT, op,
+			       field, exclude ? "!=" : "==", start_pid);
+		*filter = realloc(*filter, *curr_len + len + 1);
+		if (!*filter)
+			die("realloc");
+
+		len = snprintf(*filter + *curr_len, len + 1, FMT, op,
+			       field, exclude ? "!=" : "==", start_pid);
+		*curr_len += len;
+
+		return;
+#undef FMT
+	}
+
+	if (exclude) {
+		op1 = "<";
+		op2 = "||";
+		op3 = ">";
+	} else {
+		op1 = ">=";
+		op2 = "&&";
+		op3 = "<=";
+	}
+
+#define FMT	"%s(%s%s%d%s%s%s%d)"
+	len = snprintf(NULL, 0, FMT, op,
+		       field, op1, start_pid, op2,
+		       field, op3, end_pid);
+	*filter = realloc(*filter, *curr_len + len + 1);
+	if (!*filter)
+		die("realloc");
+
+	len = snprintf(*filter + *curr_len, len + 1, FMT, op,
+		       field, op1, start_pid, op2,
+		       field, op3, end_pid);
+	*curr_len += len;
+}
+
 /**
  * make_pid_filter - create a filter string to all pids against @field
  * @curr_filter: Append to a previous filter (may realloc). Can be NULL
@@ -963,54 +1014,41 @@ static void update_pid_event_filters(struct buffer_instance *instance);
  */
 static char *make_pid_filter(char *curr_filter, const char *field)
 {
+	int curr_len = 0, last_exclude = -1;
+	int start_pid = -1, last_pid = -1;
+	char *filter = NULL, *save;
 	struct filter_pids *p;
-	char *filter;
-	char *orit;
-	char *match;
-	char *str;
-	int curr_len = 0;
-	int len;
 
 	/* Use the new method if possible */
 	if (have_set_event_pid)
 		return NULL;
 
-	len = len_filter_pids + (strlen(field) + strlen("(==)||")) * nr_filter_pids;
-
-	if (curr_filter) {
-		curr_len = strlen(curr_filter);
-		filter = realloc(curr_filter, curr_len + len + strlen("(&&())"));
-		if (!filter)
-			die("realloc");
-		memmove(filter+1, curr_filter, curr_len);
-		filter[0] = '(';
-		strcat(filter, ")&&(");
-		curr_len = strlen(filter);
-	} else
-		filter = malloc(len);
-	if (!filter)
-		die("Failed to allocate pid filter");
-
-	/* Last '||' that is not used will cover the \0 */
-	str = filter + curr_len;
+	if (!filter_pids)
+		return curr_filter;
 
 	for (p = filter_pids; p; p = p->next) {
-		if (p->exclude) {
-			match = "!=";
-			orit = "&&";
-		} else {
-			match = "==";
-			orit = "||";
+		if (p->pid == last_pid - 1 && p->exclude == last_exclude) {
+			last_pid = p->pid;
+			continue;
 		}
-		if (p == filter_pids)
-			orit = "";
 
-		len = sprintf(str, "%s(%s%s%d)", orit, field, match, p->pid);
-		str += len;
+		if (start_pid != -1)
+			append_filter_pid_range(&filter, &curr_len, field,
+						start_pid, last_pid,
+						last_exclude);
+
+		start_pid = last_pid = p->pid;
+		last_exclude = p->exclude;
+
 	}
+	append_filter_pid_range(&filter, &curr_len, field,
+				start_pid, last_pid, last_exclude);
 
-	if (curr_len)
-		sprintf(str, ")");
+	if (curr_filter) {
+		save = filter;
+		asprintf(&filter, "(%s)&&(%s)", curr_filter, filter);
+		free(save);
+	}
 
 	return filter;
 }
-- 
2.19.1

RE: [PATCH]

[Fabrizio Castro]

Hello Greg,

Thank you for your feedback.

> Subject: Re: [PATCH] dmaengine: ensure dmaengine helpers check valid callback
>
> On Mon, May 21, 2018 at 05:56:55PM +0100, Fabrizio Castro wrote:
> > From: Vinod Koul <vinod.koul@intel.com>
> >
> > commit 757d12e5849be549076901b0d33c60d5f360269c upstream.
> >
> > dmaengine has various device callbacks and exposes helper
> > functions to invoke these. These helpers should check if channel,
> > device and callback is valid or not before invoking them.
> >
> > Reported-by: Jon Hunter <jonathanh@nvidia.com>
> > Signed-off-by: Vinod Koul <vinod.koul@intel.com>
> > [fabrizio: cherry-pick to 4.4]
> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > Signed-off-by: Jianming Qiao <jianming.qiao@bp.renesas.com>
> > ---
> > Hello Greg,
> >
> > while backporting commit 757d12e5849be549076901b0d33c60d5f360269c
> > to the CIP kernel Ben recommended to send the same patch to you
> > for 4.4 stable.
> > I hope the format of the commit is the one you expect (reference to
> > the upstream commit, version to cherry-pick the patch to, and
> > Signed-off-by tags).
>
> Format is fine, but why is this needed in the 4.4.y kernel tree?

We work with the CIP kernel (v4.4), and from time to time we come across bug fixes we feel like stable could benefit from.
Also, since Ben merges the CIP branch with stable, the fixes we make to stable will appear in the CIP kernel too at some point.
If you feel like the patch is not worth considering for stable, it can still be applied to the CIP kernel if required.
Ben has already taken this patch (for v4.4.126-cip22) therefore it's not on our critical path, but it would be nice to have in the stable kernel too.

> What bug does it solve?

Without this patch we managed to get the kernel to try and dereference a NULL pointer while playing around with ttys (basically by having the wrong tty with /etc/securetty).

Are you happy to take this patch?

Thanks,
Fab

>
> thanks,
>
> greg k-h



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

Re: [PATCH]

[Greg KH]

On Tue, May 22, 2018 at 09:37:39AM +0000, Fabrizio Castro wrote:
> Hello Greg,
> 
> Thank you for your feedback.
> 
> > Subject: Re: [PATCH] dmaengine: ensure dmaengine helpers check valid callback
> >
> > On Mon, May 21, 2018 at 05:56:55PM +0100, Fabrizio Castro wrote:
> > > From: Vinod Koul <vinod.koul@intel.com>
> > >
> > > commit 757d12e5849be549076901b0d33c60d5f360269c upstream.
> > >
> > > dmaengine has various device callbacks and exposes helper
> > > functions to invoke these. These helpers should check if channel,
> > > device and callback is valid or not before invoking them.
> > >
> > > Reported-by: Jon Hunter <jonathanh@nvidia.com>
> > > Signed-off-by: Vinod Koul <vinod.koul@intel.com>
> > > [fabrizio: cherry-pick to 4.4]
> > > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > Signed-off-by: Jianming Qiao <jianming.qiao@bp.renesas.com>
> > > ---
> > > Hello Greg,
> > >
> > > while backporting commit 757d12e5849be549076901b0d33c60d5f360269c
> > > to the CIP kernel Ben recommended to send the same patch to you
> > > for 4.4 stable.
> > > I hope the format of the commit is the one you expect (reference to
> > > the upstream commit, version to cherry-pick the patch to, and
> > > Signed-off-by tags).
> >
> > Format is fine, but why is this needed in the 4.4.y kernel tree?
> 
> We work with the CIP kernel (v4.4), and from time to time we come across bug fixes we feel like stable could benefit from.
> Also, since Ben merges the CIP branch with stable, the fixes we make to stable will appear in the CIP kernel too at some point.
> If you feel like the patch is not worth considering for stable, it can still be applied to the CIP kernel if required.
> Ben has already taken this patch (for v4.4.126-cip22) therefore it's not on our critical path, but it would be nice to have in the stable kernel too.
> 
> > What bug does it solve?
> 
> Without this patch we managed to get the kernel to try and dereference
> a NULL pointer while playing around with ttys (basically by having the
> wrong tty with /etc/securetty).

Really?  What tty caused this problem?

> Are you happy to take this patch?

It does not seem to fix a problem in the tree today, but it feels "safe
enough", so I guess I'll queue it up.

thanks,

greg k-h

RE: [PATCH]

[Fabrizio Castro]

Hello Greg,

> -----Original Message-----
> From: stable-owner@vger.kernel.org [mailto:stable-owner@vger.kernel.org] On Behalf Of Greg KH
> Sent: 24 May 2018 08:24
> To: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>; Chris Paterson <Chris.Paterson2@renesas.com>; Biju Das
> <biju.das@bp.renesas.com>; Jianming Qiao <jianming.qiao@bp.renesas.com>; stable@vger.kernel.org
> Subject: Re: [PATCH]
>
> On Tue, May 22, 2018 at 09:37:39AM +0000, Fabrizio Castro wrote:
> > Hello Greg,
> >
> > Thank you for your feedback.
> >
> > > Subject: Re: [PATCH] dmaengine: ensure dmaengine helpers check valid callback
> > >
> > > On Mon, May 21, 2018 at 05:56:55PM +0100, Fabrizio Castro wrote:
> > > > From: Vinod Koul <vinod.koul@intel.com>
> > > >
> > > > commit 757d12e5849be549076901b0d33c60d5f360269c upstream.
> > > >
> > > > dmaengine has various device callbacks and exposes helper
> > > > functions to invoke these. These helpers should check if channel,
> > > > device and callback is valid or not before invoking them.
> > > >
> > > > Reported-by: Jon Hunter <jonathanh@nvidia.com>
> > > > Signed-off-by: Vinod Koul <vinod.koul@intel.com>
> > > > [fabrizio: cherry-pick to 4.4]
> > > > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > > Signed-off-by: Jianming Qiao <jianming.qiao@bp.renesas.com>
> > > > ---
> > > > Hello Greg,
> > > >
> > > > while backporting commit 757d12e5849be549076901b0d33c60d5f360269c
> > > > to the CIP kernel Ben recommended to send the same patch to you
> > > > for 4.4 stable.
> > > > I hope the format of the commit is the one you expect (reference to
> > > > the upstream commit, version to cherry-pick the patch to, and
> > > > Signed-off-by tags).
> > >
> > > Format is fine, but why is this needed in the 4.4.y kernel tree?
> >
> > We work with the CIP kernel (v4.4), and from time to time we come across bug fixes we feel like stable could benefit from.
> > Also, since Ben merges the CIP branch with stable, the fixes we make to stable will appear in the CIP kernel too at some point.
> > If you feel like the patch is not worth considering for stable, it can still be applied to the CIP kernel if required.
> > Ben has already taken this patch (for v4.4.126-cip22) therefore it's not on our critical path, but it would be nice to have in the stable
> kernel too.
> >
> > > What bug does it solve?
> >
> > Without this patch we managed to get the kernel to try and dereference
> > a NULL pointer while playing around with ttys (basically by having the
> > wrong tty with /etc/securetty).
>
> Really?  What tty caused this problem?

All but ttySC0 on a Koelsch board (it's the lack of ttySC0 actually causing the issue).

>
> > Are you happy to take this patch?
>
> It does not seem to fix a problem in the tree today, but it feels "safe
> enough", so I guess I'll queue it up.

Thank you for taking the patch!

Fab

>
> thanks,
>
> greg k-h



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

[PATCH]

[Lu, Xinyu]

[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]

 nfs4.0 server st_write: fix the amount of data sent in the testLargeData
    
    The maximum amount of data could be writen is NFSSVC_MAXBLKSIZE. The value of NFSSVC_MAXB
LKSIZE defined in the kernel is RPCSVC_MAXPLAYLOAD. If the value written exceeds NFSSVC_MAXBL
KSIZE, the value is fixed as the value of NFSSVC_MAXBLKSIZE. The value of RPCSVC_MAXPAYLOAD i
s 1*1024*1024u and "abcdefghijklmnopq"*0x10000 exceeds it. So the previous test is bound to f
ail and is meaningless.

    Signed-off-by: Lu Xinyu <luxy.fnst@cn.fujitsu.com>

diff --git a/nfs4.0/servertests/st_write.py b/nfs4.0/servertests/st_write.py
index 710452e..a7dae03 100644
--- a/nfs4.0/servertests/st_write.py
+++ b/nfs4.0/servertests/st_write.py
@@ -130,7 +130,7 @@ def testLargeData(t, env):
     c = env.c1
     c.init_connection()
     fh, stateid = c.create_confirm(t.code)
-    data = "abcdefghijklmnopq" * 0x10000
+    data = "a" * 1024 * 1024
     # Write the data
     pos = 0
     while pos < len(data):





[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-nfs4.0-server-st_write-fix-the-amount-of-data-sent-i.patch --]
[-- Type: text/x-patch; name="0001-nfs4.0-server-st_write-fix-the-amount-of-data-sent-i.patch", Size: 1270 bytes --]

>From 6adc3da0ab17eb7e52b47805e6999d65b043fa7f Mon Sep 17 00:00:00 2001
From: Lu Xinyu <luxy.fnst@cn.fujitsu.com>
Date: Thu, 30 Nov 2017 13:24:15 +0800
Subject: [PATCH] nfs4.0 server st_write: fix the amount of data sent in the
 testLargeData

The maximum amount of data could be writen is NFSSVC_MAXBLKSIZE. The value of NFSSVC_MAXBLKSIZE defined in the kernel is RPCSVC_MAXPLAYLOAD. If the value written exceeds NFSSVC_MAXBLKSIZE, the value is fixed as the value of NFSSVC_MAXBLKSIZE. The value of RPCSVC_MAXPAYLOAD is 1*1024*1024u and "abcdefghijklmnopq"*0x10000 exceeds it. So the previous test is bound to fail and is meaningless.

Signed-off-by: Lu Xinyu <luxy.fnst@cn.fujitsu.com>
---
 nfs4.0/servertests/st_write.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/nfs4.0/servertests/st_write.py b/nfs4.0/servertests/st_write.py
index 710452e..a7dae03 100644
--- a/nfs4.0/servertests/st_write.py
+++ b/nfs4.0/servertests/st_write.py
@@ -130,7 +130,7 @@ def testLargeData(t, env):
     c = env.c1
     c.init_connection()
     fh, stateid = c.create_confirm(t.code)
-    data = "abcdefghijklmnopq" * 0x10000
+    data = "a" * 1024 * 1024
     # Write the data
     pos = 0
     while pos < len(data):
-- 
2.13.3

[PATCH]

[armetallica]

>From bb1aac6ae6b21b903d8743712e21aeb1a6b22163 Mon Sep 17 00:00:00 2001
From: Armin Schoenlieb <armetallica@gmail.com>
Date: Mon, 10 Jul 2017 01:52:41 +0200
Subject: [PATCH] staging: unisys: visorbus: fix brace coding style issue in
 visorbus_main.c This is a patch to the visorbus_main.c file that fixes up six
 brace errors found by the checkpatch.pl tool

Signed-off-by: Armin Schoenlieb <armetallica@gmail.com>
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c b/drivers/staging/unisys/visorbus/visorbus_main.c
index 1c785dd19ddd..c56496269fc8 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -270,7 +270,8 @@ static const struct attribute_group *visorbus_channel_groups[] = {
 
 static ssize_t partition_handle_show(struct device *dev,
 				     struct device_attribute *attr,
-				     char *buf) {
+				     char *buf)
+{
 	struct visor_device *vdev = to_visor_device(dev);
 	u64 handle = visorchannel_get_clientpartition(vdev->visorchannel);
 
@@ -280,7 +281,8 @@ static DEVICE_ATTR_RO(partition_handle);
 
 static ssize_t partition_guid_show(struct device *dev,
 				   struct device_attribute *attr,
-				   char *buf) {
+				   char *buf)
+{
 	struct visor_device *vdev = to_visor_device(dev);
 
 	return sprintf(buf, "{%pUb}\n", &vdev->partition_uuid);
@@ -289,7 +291,8 @@ static DEVICE_ATTR_RO(partition_guid);
 
 static ssize_t partition_name_show(struct device *dev,
 				   struct device_attribute *attr,
-				   char *buf) {
+				   char *buf)
+{
 	struct visor_device *vdev = to_visor_device(dev);
 
 	return sprintf(buf, "%s\n", vdev->name);
@@ -298,7 +301,8 @@ static DEVICE_ATTR_RO(partition_name);
 
 static ssize_t channel_addr_show(struct device *dev,
 				 struct device_attribute *attr,
-				 char *buf) {
+				 char *buf)
+{
 	struct visor_device *vdev = to_visor_device(dev);
 	u64 addr = visorchannel_get_physaddr(vdev->visorchannel);
 
@@ -308,7 +312,8 @@ static DEVICE_ATTR_RO(channel_addr);
 
 static ssize_t channel_bytes_show(struct device *dev,
 				  struct device_attribute *attr,
-				  char *buf) {
+				  char *buf)
+{
 	struct visor_device *vdev = to_visor_device(dev);
 	u64 nbytes = visorchannel_get_nbytes(vdev->visorchannel);
 
@@ -318,7 +323,8 @@ static DEVICE_ATTR_RO(channel_bytes);
 
 static ssize_t channel_id_show(struct device *dev,
 			       struct device_attribute *attr,
-			       char *buf) {
+			       char *buf)
+{
 	struct visor_device *vdev = to_visor_device(dev);
 	int len = 0;
 
-- 
2.11.0

RE: [PATCH]

[Kershner, David A]

> -----Original Message-----
> From: armetallica [mailto:armetallica@gmail.com]
> Sent: Sunday, July 9, 2017 7:58 PM
> To: gregkh@linuxfoundation.org
> Cc: *S-Par-Maintainer <SParMaintainer@unisys.com>;
> devel@driverdev.osuosl.org; linux-kernel@vger.kernel.org
> Subject: [PATCH]
> 
> From bb1aac6ae6b21b903d8743712e21aeb1a6b22163 Mon Sep 17 00:00:00
> 2001
> From: Armin Schoenlieb <armetallica@gmail.com>
> Date: Mon, 10 Jul 2017 01:52:41 +0200
> Subject: [PATCH] staging: unisys: visorbus: fix brace coding style issue in
>  visorbus_main.c This is a patch to the visorbus_main.c file that fixes up six
>  brace errors found by the checkpatch.pl tool
> 

Thanks for the patch! It looks like I sent up a patch to Greg that addresses this
issue on 6/30/2017:
 
	[PATCH 25/25] staging: unisys: visorbus: fix improper bracket blocks

Also, your patch come in with a subject of just the word [PATCH] and the patch
comment was messed up. I'm not sure how you generated the patch, but you
might want to try it with format-patch and then do a git send-email to yourself
as a dry-run to see if the patch looks OK when you get it.

David Kershner


> Signed-off-by: Armin Schoenlieb <armetallica@gmail.com>
> ---
>  drivers/staging/unisys/visorbus/visorbus_main.c | 18 ++++++++++++------
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c
> b/drivers/staging/unisys/visorbus/visorbus_main.c
> index 1c785dd19ddd..c56496269fc8 100644
> --- a/drivers/staging/unisys/visorbus/visorbus_main.c
> +++ b/drivers/staging/unisys/visorbus/visorbus_main.c
> @@ -270,7 +270,8 @@ static const struct attribute_group
> *visorbus_channel_groups[] = {
> 
>  static ssize_t partition_handle_show(struct device *dev,
>  				     struct device_attribute *attr,
> -				     char *buf) {
> +				     char *buf)
> +{
>  	struct visor_device *vdev = to_visor_device(dev);
>  	u64 handle = visorchannel_get_clientpartition(vdev->visorchannel);
> 
> @@ -280,7 +281,8 @@ static DEVICE_ATTR_RO(partition_handle);
> 
>  static ssize_t partition_guid_show(struct device *dev,
>  				   struct device_attribute *attr,
> -				   char *buf) {
> +				   char *buf)
> +{
>  	struct visor_device *vdev = to_visor_device(dev);
> 
>  	return sprintf(buf, "{%pUb}\n", &vdev->partition_uuid);
> @@ -289,7 +291,8 @@ static DEVICE_ATTR_RO(partition_guid);
> 
>  static ssize_t partition_name_show(struct device *dev,
>  				   struct device_attribute *attr,
> -				   char *buf) {
> +				   char *buf)
> +{
>  	struct visor_device *vdev = to_visor_device(dev);
> 
>  	return sprintf(buf, "%s\n", vdev->name);
> @@ -298,7 +301,8 @@ static DEVICE_ATTR_RO(partition_name);
> 
>  static ssize_t channel_addr_show(struct device *dev,
>  				 struct device_attribute *attr,
> -				 char *buf) {
> +				 char *buf)
> +{
>  	struct visor_device *vdev = to_visor_device(dev);
>  	u64 addr = visorchannel_get_physaddr(vdev->visorchannel);
> 
> @@ -308,7 +312,8 @@ static DEVICE_ATTR_RO(channel_addr);
> 
>  static ssize_t channel_bytes_show(struct device *dev,
>  				  struct device_attribute *attr,
> -				  char *buf) {
> +				  char *buf)
> +{
>  	struct visor_device *vdev = to_visor_device(dev);
>  	u64 nbytes = visorchannel_get_nbytes(vdev->visorchannel);
> 
> @@ -318,7 +323,8 @@ static DEVICE_ATTR_RO(channel_bytes);
> 
>  static ssize_t channel_id_show(struct device *dev,
>  			       struct device_attribute *attr,
> -			       char *buf) {
> +			       char *buf)
> +{
>  	struct visor_device *vdev = to_visor_device(dev);
>  	int len = 0;
> 
> --
> 2.11.0

[PATCH]

[armetallica]

>From 043428d63637a6dd8e52449b73dbb8341885d7e4 Mon Sep 17 00:00:00 2001
From: Armin Schoenlieb <armetallica@gmail.com>
Date: Mon, 10 Jul 2017 01:12:52 +0200
Subject: [PATCH] Staging: media: atomisp2: fixed trailing whitespace error in
 atomisp_v4l2.c This is a patch to the atomisp_v4l2.c file that fixes up a
 trailing whitespace error found by the checkpatch.pl tool

Signed-off-by: Armin Schoenlieb <armetallica@gmail.com>
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
index a543def739fc..05d02ebb6d25 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
@@ -1277,13 +1277,13 @@ static int atomisp_pci_probe(struct pci_dev *dev,
 			(ATOMISP_HW_REVISION_ISP2400
 			 << ATOMISP_HW_REVISION_SHIFT) |
 			ATOMISP_HW_STEPPING_B0;
-#ifdef FIXME			
+#ifdef FIXME
 		if (INTEL_MID_BOARD(3, TABLET, BYT, BLK, PRO, CRV2) ||
 			INTEL_MID_BOARD(3, TABLET, BYT, BLK, ENG, CRV2)) {
 			isp->dfs = &dfs_config_byt_cr;
 			isp->hpll_freq = HPLL_FREQ_2000MHZ;
 		} else
-#endif		
+#endif
 		{
 			isp->dfs = &dfs_config_byt;
 			isp->hpll_freq = HPLL_FREQ_1600MHZ;
-- 
2.11.0

[PATCH]

[armetallica]

From 043428d63637a6dd8e52449b73dbb8341885d7e4 Mon Sep 17 00:00:00 2001
From: Armin Schoenlieb <armetallica@gmail.com>
Date: Mon, 10 Jul 2017 01:12:52 +0200
Subject: [PATCH] Staging: media: atomisp2: fixed trailing whitespace error in
 atomisp_v4l2.c This is a patch to the atomisp_v4l2.c file that fixes up a
 trailing whitespace error found by the checkpatch.pl tool

Signed-off-by: Armin Schoenlieb <armetallica@gmail.com>
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
index a543def739fc..05d02ebb6d25 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
@@ -1277,13 +1277,13 @@ static int atomisp_pci_probe(struct pci_dev *dev,
 			(ATOMISP_HW_REVISION_ISP2400
 			 << ATOMISP_HW_REVISION_SHIFT) |
 			ATOMISP_HW_STEPPING_B0;
-#ifdef FIXME			
+#ifdef FIXME
 		if (INTEL_MID_BOARD(3, TABLET, BYT, BLK, PRO, CRV2) ||
 			INTEL_MID_BOARD(3, TABLET, BYT, BLK, ENG, CRV2)) {
 			isp->dfs = &dfs_config_byt_cr;
 			isp->hpll_freq = HPLL_FREQ_2000MHZ;
 		} else
-#endif		
+#endif
 		{
 			isp->dfs = &dfs_config_byt;
 			isp->hpll_freq = HPLL_FREQ_1600MHZ;
-- 
2.11.0

Re: [PATCH]

[Mauro Carvalho Chehab]

Em Mon, 10 Jul 2017 01:35:11 +0200
armetallica <armetallica@gmail.com> escreveu:

> From 043428d63637a6dd8e52449b73dbb8341885d7e4 Mon Sep 17 00:00:00 2001
> From: Armin Schoenlieb <armetallica@gmail.com>
> Date: Mon, 10 Jul 2017 01:12:52 +0200
> Subject: [PATCH] Staging: media: atomisp2: fixed trailing whitespace error in
>  atomisp_v4l2.c This is a patch to the atomisp_v4l2.c file that fixes up a
>  trailing whitespace error found by the checkpatch.pl tool

Something clearly gets wrong here...

Regards,
Mauro

> 
> Signed-off-by: Armin Schoenlieb <armetallica@gmail.com>
> ---
>  drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
> index a543def739fc..05d02ebb6d25 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
> @@ -1277,13 +1277,13 @@ static int atomisp_pci_probe(struct pci_dev *dev,
>  			(ATOMISP_HW_REVISION_ISP2400
>  			 << ATOMISP_HW_REVISION_SHIFT) |
>  			ATOMISP_HW_STEPPING_B0;
> -#ifdef FIXME			
> +#ifdef FIXME
>  		if (INTEL_MID_BOARD(3, TABLET, BYT, BLK, PRO, CRV2) ||
>  			INTEL_MID_BOARD(3, TABLET, BYT, BLK, ENG, CRV2)) {
>  			isp->dfs = &dfs_config_byt_cr;
>  			isp->hpll_freq = HPLL_FREQ_2000MHZ;
>  		} else
> -#endif		
> +#endif
>  		{
>  			isp->dfs = &dfs_config_byt;
>  			isp->hpll_freq = HPLL_FREQ_1600MHZ;



Thanks,
Mauro

[PATCH]

[Andreas Herrmann]

Starting with 9e4438f ("stat: don't trust per_unit_log() if log is
NULL") fio no longer provides basic bw information (e.g. min, max,
p_agg, mean, stdev) when write_bw_log is not used. Thus you have to
write a bw_log to obtain these values. (But in this case you can
compute those values yourself.) I think this doesn't make sense.  Not
writing entire bw log shouldn't prevent general sampling and
calculation of bw stats.

This patch reactivates sampling for bw and iops to be able to
calculate basic stats for both independend of writing of entire
{bw,iops}_logs.

Also check for log that is really of interest in __add_samples() it
doesn't make sense to check for bw_log if iops information needs to be
written.

Signed-off-by: Andreas Herrmann <aherrmann@suse.com>
---
 stat.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

I don't know the background why the original fix was required in its
form and at which exact point the sigbus error happened on sparc. Was
it in per_unit_log(td->bw_log) or somewhere in add_bw_samples or
add_iops_samples? Maybe the original code version (just using
!per_unit_log(td->bw_log)) was fine and the sigbus happened due to the
bug in __add_samples (checking for the wrong log file)?


Regards,

Andreas


diff --git a/stat.c b/stat.c
index 6e47c34..5b48413 100644
--- a/stat.c
+++ b/stat.c
@@ -2465,7 +2465,7 @@ static int __add_samples(struct thread_data *td, struct timeval *parent_tv,
 
 		add_stat_sample(&stat[ddir], rate);
 
-		if (td->bw_log) {
+		if (log) {
 			unsigned int bs = 0;
 
 			if (td->o.min_bs[ddir] == td->o.max_bs[ddir])
@@ -2541,12 +2541,14 @@ int calc_log_samples(void)
 			next = min(td->o.iops_avg_time, td->o.bw_avg_time);
 			continue;
 		}
-		if (td->bw_log && !per_unit_log(td->bw_log)) {
+		if (!td->bw_log ||
+			(td->bw_log && !per_unit_log(td->bw_log))) {
 			tmp = add_bw_samples(td, &now);
 			if (tmp < next)
 				next = tmp;
 		}
-		if (td->iops_log && !per_unit_log(td->iops_log)) {
+		if (!td->iops_log ||
+			(td->iops_log && !per_unit_log(td->iops_log))) {
 			tmp = add_iops_samples(td, &now);
 			if (tmp < next)
 				next = tmp;
-- 
2.7.4

Re: [PATCH]

[Sitsofe Wheeler]

On 19 May 2017 at 11:39, Andreas Herrmann <aherrmann@suse.com> wrote:
>
> Starting with 9e4438f ("stat: don't trust per_unit_log() if log is
> NULL") fio no longer provides basic bw information (e.g. min, max,
> p_agg, mean, stdev) when write_bw_log is not used. Thus you have to
> write a bw_log to obtain these values. (But in this case you can
> compute those values yourself.) I think this doesn't make sense.  Not
> writing entire bw log shouldn't prevent general sampling and
> calculation of bw stats.
>
> This patch reactivates sampling for bw and iops to be able to
> calculate basic stats for both independend of writing of entire
> {bw,iops}_logs.
>
> Also check for log that is really of interest in __add_samples() it
> doesn't make sense to check for bw_log if iops information needs to be
> written.
>
> Signed-off-by: Andreas Herrmann <aherrmann@suse.com>
> ---
>  stat.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> I don't know the background why the original fix was required in its
> form and at which exact point the sigbus error happened on sparc. Was
> it in per_unit_log(td->bw_log) or somewhere in add_bw_samples or
> add_iops_samples? Maybe the original code version (just using
> !per_unit_log(td->bw_log)) was fine and the sigbus happened due to the
> bug in __add_samples (checking for the wrong log file)?

The sparc sigbus report seems to come from here:
https://lists.debian.org/debian-sparc/2016/08/msg00028.html
("[sparc64] fio bus error").

-- 
Sitsofe | http://sucs.org/~sits/

[patch]

[Carlos O'Donell]

Grammatical nit.

diff --git a/man3/getpwent_r.3 b/man3/getpwent_r.3
index ac84e3b..b7f6edc 100644
--- a/man3/getpwent_r.3
+++ b/man3/getpwent_r.3
@@ -119,7 +119,7 @@ Try again with larger buffer.
 These functions are GNU extensions, done in a style resembling
 the POSIX version of functions like
 .BR getpwnam_r (3).
-Other systems use prototype
+Other systems use the prototype
 .sp
 .nf
 .in +4n
---

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch]

[Carlos O'Donell]

Sorry, mailer failure.

Subject: [patch] getpwent_r.3: tfix

Patch against master.

On 01/15/2015 10:42 PM, Carlos O'Donell wrote:
> Grammatical nit.
> 
> diff --git a/man3/getpwent_r.3 b/man3/getpwent_r.3
> index ac84e3b..b7f6edc 100644
> --- a/man3/getpwent_r.3
> +++ b/man3/getpwent_r.3
> @@ -119,7 +119,7 @@ Try again with larger buffer.
>  These functions are GNU extensions, done in a style resembling
>  the POSIX version of functions like
>  .BR getpwnam_r (3).
> -Other systems use prototype
> +Other systems use the prototype
>  .sp
>  .nf
>  .in +4n
> ---
> 
> Cheers,
> Carlos.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch]

[Michael Kerrisk (man-pages)]

On 01/16/2015 04:43 AM, Carlos O'Donell wrote:
> Sorry, mailer failure.
> 
> Subject: [patch] getpwent_r.3: tfix
> 
> Patch against master.

Thanks. Applied with fixed subject.

Cheers,

Michael

> On 01/15/2015 10:42 PM, Carlos O'Donell wrote:
>> Grammatical nit.
>>
>> diff --git a/man3/getpwent_r.3 b/man3/getpwent_r.3
>> index ac84e3b..b7f6edc 100644
>> --- a/man3/getpwent_r.3
>> +++ b/man3/getpwent_r.3
>> @@ -119,7 +119,7 @@ Try again with larger buffer.
>>  These functions are GNU extensions, done in a style resembling
>>  the POSIX version of functions like
>>  .BR getpwnam_r (3).
>> -Other systems use prototype
>> +Other systems use the prototype
>>  .sp
>>  .nf
>>  .in +4n
>> ---
>>
>> Cheers,
>> Carlos.
>>
> 
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH]

[Evan Hosseini]

---
Staging: android: fix parenthesis coding style issue in alarm-dev.c
This is a patch to the alarm-dev.c file that fixes up a
 parenthesis warning found by the checkpatch.pl tool.
Signed-off-by: Evan Hosseini <hosse005@umn.edu>

---
 drivers/staging/android/alarm-dev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/alarm-dev.c b/drivers/staging/android/alarm-dev.c
index 647694f..893362f 100644
--- a/drivers/staging/android/alarm-dev.c
+++ b/drivers/staging/android/alarm-dev.c
@@ -68,7 +68,6 @@ static struct devalarm alarms[ANDROID_ALARM_TYPE_COUNT];
  */
 static int is_wakeup(enum android_alarm_type type)
 {
-	return (type == ANDROID_ALARM_RTC_WAKEUP ||
-		type == ANDROID_ALARM_ELAPSED_REALTIME_WAKEUP);
+	return type == ANDROID_ALARM_RTC_WAKEUP ||
+	  type == ANDROID_ALARM_ELAPSED_REALTIME_WAKEUP;
 }
--
1.8.3.2

Re: [PATCH]

[Greg KH]

On Tue, Dec 24, 2013 at 09:45:03AM -0600, Evan Hosseini wrote:
> ---
> Staging: android: fix parenthesis coding style issue in alarm-dev.c

What happened to your Subject:?

Also, why put the '---' line here?  That means that git will delete
everything else.

> This is a patch to the alarm-dev.c file that fixes up a
>  parenthesis warning found by the checkpatch.pl tool.
> Signed-off-by: Evan Hosseini <hosse005@umn.edu>

Please put a blank line between the changelog info and the
signed-off-by: line.

> 
> ---
>  drivers/staging/android/alarm-dev.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/android/alarm-dev.c b/drivers/staging/android/alarm-dev.c
> index 647694f..893362f 100644
> --- a/drivers/staging/android/alarm-dev.c
> +++ b/drivers/staging/android/alarm-dev.c
> @@ -68,7 +68,6 @@ static struct devalarm alarms[ANDROID_ALARM_TYPE_COUNT];
>   */
>  static int is_wakeup(enum android_alarm_type type)
>  {
> -	return (type == ANDROID_ALARM_RTC_WAKEUP ||
> -		type == ANDROID_ALARM_ELAPSED_REALTIME_WAKEUP);
> +	return type == ANDROID_ALARM_RTC_WAKEUP ||
> +	  type == ANDROID_ALARM_ELAPSED_REALTIME_WAKEUP;

This patch doesn't apply to the linux-next tree, as someone else has
already made this change, sorry.

greg k-h

[PATCH net-next v3 0/3] bonding: modify the current and add new hash functions

[Nikolay Aleksandrov]

Hi all,
This is a complete remake of my old patch that modified the bonding hash
functions to use skb_flow_dissect which was suggested by Eric Dumazet.
This time around I've left the old modes although using a new hash function
again suggested by Eric, which is the same for all modes. The only
difference is the way the headers are obtained. The old modes obtain them
as before in order to address concerns about speed, but the 2 new ones use
skb_flow_dissect. The unification of the hash function allows to remove a
pointer from struct bonding and also a few extra functions that dealt with
it. Two new functions are added which take care of the hashing based on
bond->params.xmit_policy only:
bond_xmit_hash() - global function, used by XOR and 3ad modes
bond_flow_dissect() - used by bond_xmit_hash() to obtain the necessary
headers and combine them according to bond->params.xmit_policy.
Also factor out the ports extraction from skb_flow_dissect and add a new
function - skb_flow_get_ports() which can be re-used.

v2: add the flow_dissector patch and use skb_flow_get_ports in patch 02
v3: fix a bug in the flow_dissector patch that caused a different thoff
    by modifying the thoff argument in skb_flow_get_ports directly, most
    of the users already do it anyway.
    Also add the necessary export symbol for skb_flow_get_ports.

Best regards,
 Nikolay Aleksandrov


Nikolay Aleksandrov (3):
  flow_dissector: factor out the ports extraction in skb_flow_get_ports
  bonding: modify the old and add new xmit hash policies
  bonding: document the new xmit policy modes and update the changed
    ones

 Documentation/networking/bonding.txt |  66 ++++++------
 drivers/net/bonding/bond_3ad.c       |   2 +-
 drivers/net/bonding/bond_main.c      | 197 ++++++++++++-----------------------
 drivers/net/bonding/bond_sysfs.c     |   2 -
 drivers/net/bonding/bonding.h        |   3 +-
 include/net/flow_keys.h              |   1 +
 include/uapi/linux/if_bonding.h      |   2 +
 net/core/flow_dissector.c            |  41 ++++++--
 8 files changed, 139 insertions(+), 175 deletions(-)

-- 
1.8.1.4

[PATCH net-next v3 1/3] flow_dissector: factor out the ports extraction in skb_flow_get_ports

[Nikolay Aleksandrov]

Factor out the code that extracts the ports from skb_flow_dissect and
add a new function skb_flow_get_ports which can be re-used.

Suggested-by: Veaceslav Falico <vfalico@redhat.com>
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
---
v2: new patch
v3: fix a bug in skb_flow_dissect where thoff didn't have poff added by
    modifying thoff directly in skb_flow_get_ports as it's done anyway.
    Also add the necessary export symbol for skb_flow_get_ports.
This seems like a good idea because there're other users that can re-use
it later as well.

 include/net/flow_keys.h   |  1 +
 net/core/flow_dissector.c | 41 ++++++++++++++++++++++++++++++-----------
 2 files changed, 31 insertions(+), 11 deletions(-)

diff --git a/include/net/flow_keys.h b/include/net/flow_keys.h
index ac2439d..4db84ae 100644
--- a/include/net/flow_keys.h
+++ b/include/net/flow_keys.h
@@ -14,4 +14,5 @@ struct flow_keys {
 };
 
 bool skb_flow_dissect(const struct sk_buff *skb, struct flow_keys *flow);
+__be32 skb_flow_get_ports(const struct sk_buff *skb, int *thoff, u8 ip_proto);
 #endif
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 1929af8..7785398 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -25,9 +25,37 @@ static void iph_to_flow_copy_addrs(struct flow_keys *flow, const struct iphdr *i
 	memcpy(&flow->src, &iph->saddr, sizeof(flow->src) + sizeof(flow->dst));
 }
 
+/**
+ * skb_flow_get_ports - extract the upper layer ports and return them
+ * @skb: buffer to extract the ports from
+ * @thoff: pointer to transport header offset
+ * @ip_proto: protocol for which to get port offset
+ *
+ * The function will try to retrieve the ports at offset thoff + poff where poff
+ * is the protocol port offset returned from proto_ports_offset, and if poff is
+ * more than or equal to 0 it'll add it to the value at the thoff address
+ */
+__be32 skb_flow_get_ports(const struct sk_buff *skb, int *thoff, u8 ip_proto)
+{
+	int poff = proto_ports_offset(ip_proto);
+
+	if (poff >= 0) {
+		__be32 *ports, _ports;
+
+		*thoff += poff;
+		ports = skb_header_pointer(skb, *thoff, sizeof(_ports),
+					   &_ports);
+		if (ports)
+			return *ports;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL(skb_flow_get_ports);
+
 bool skb_flow_dissect(const struct sk_buff *skb, struct flow_keys *flow)
 {
-	int poff, nhoff = skb_network_offset(skb);
+	int nhoff = skb_network_offset(skb);
 	u8 ip_proto;
 	__be16 proto = skb->protocol;
 
@@ -150,16 +178,7 @@ ipv6:
 	}
 
 	flow->ip_proto = ip_proto;
-	poff = proto_ports_offset(ip_proto);
-	if (poff >= 0) {
-		__be32 *ports, _ports;
-
-		nhoff += poff;
-		ports = skb_header_pointer(skb, nhoff, sizeof(_ports), &_ports);
-		if (ports)
-			flow->ports = *ports;
-	}
-
+	flow->ports = skb_flow_get_ports(skb, &nhoff, ip_proto);
 	flow->thoff = (u16) nhoff;
 
 	return true;
-- 
1.8.1.4

[PATCH]

[Eric Dumazet]

On Thu, 2013-09-26 at 16:09 +0200, Nikolay Aleksandrov wrote:
> Factor out the code that extracts the ports from skb_flow_dissect and
> add a new function skb_flow_get_ports which can be re-used.
> 
> Suggested-by: Veaceslav Falico <vfalico@redhat.com>
> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
> ---
> v2: new patch
> v3: fix a bug in skb_flow_dissect where thoff didn't have poff added by
>     modifying thoff directly in skb_flow_get_ports as it's done anyway.
>     Also add the necessary export symbol for skb_flow_get_ports.
> This seems like a good idea because there're other users that can re-use
> it later as well.

Wait a minute.... existing code seems buggy.

Daniel, any objection if I submit this fix ?

(commit 8ed781668dd49b608f)

diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 1929af8..8d7d0dd 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -154,8 +154,8 @@ ipv6:
 	if (poff >= 0) {
 		__be32 *ports, _ports;
 
-		nhoff += poff;
-		ports = skb_header_pointer(skb, nhoff, sizeof(_ports), &_ports);
+		ports = skb_header_pointer(skb, nhoff + poff,
+					   sizeof(_ports), &_ports);
 		if (ports)
 			flow->ports = *ports;
 	}

Re: [PATCH]

[Nikolay Aleksandrov]

On 09/26/2013 05:27 PM, Eric Dumazet wrote:
> On Thu, 2013-09-26 at 16:09 +0200, Nikolay Aleksandrov wrote:
>> Factor out the code that extracts the ports from skb_flow_dissect and
>> add a new function skb_flow_get_ports which can be re-used.
>>
>> Suggested-by: Veaceslav Falico <vfalico@redhat.com>
>> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
>> ---
>> v2: new patch
>> v3: fix a bug in skb_flow_dissect where thoff didn't have poff added by
>>     modifying thoff directly in skb_flow_get_ports as it's done anyway.
>>     Also add the necessary export symbol for skb_flow_get_ports.
>> This seems like a good idea because there're other users that can re-use
>> it later as well.
> 
> Wait a minute.... existing code seems buggy.
> 
> Daniel, any objection if I submit this fix ?
> 
> (commit 8ed781668dd49b608f)
> 
1 question, I might be missing something but proto_ports_offset() gets the SPI
with that 4 byte offset as is written in the comments, in every other case
proto_ports_offset() is 0, so why would we want the SPI in the ->ports field ?
And even then isn't it supposed to be 16 bits (2 bytes) and not 4, since we need
to pass over "next header" (8 bits) and length (8 bits) ?

Thanks,
 Nik

Re: [PATCH]

[Nikolay Aleksandrov]

On 09/26/2013 05:40 PM, Nikolay Aleksandrov wrote:
> On 09/26/2013 05:27 PM, Eric Dumazet wrote:
>> On Thu, 2013-09-26 at 16:09 +0200, Nikolay Aleksandrov wrote:
>>> Factor out the code that extracts the ports from skb_flow_dissect and
>>> add a new function skb_flow_get_ports which can be re-used.
>>>
>>> Suggested-by: Veaceslav Falico <vfalico@redhat.com>
>>> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
>>> ---
>>> v2: new patch
>>> v3: fix a bug in skb_flow_dissect where thoff didn't have poff added by
>>>     modifying thoff directly in skb_flow_get_ports as it's done anyway.
>>>     Also add the necessary export symbol for skb_flow_get_ports.
>>> This seems like a good idea because there're other users that can re-use
>>> it later as well.
>>
>> Wait a minute.... existing code seems buggy.
>>
>> Daniel, any objection if I submit this fix ?
>>
>> (commit 8ed781668dd49b608f)
>>
> 1 question, I might be missing something but proto_ports_offset() gets the SPI
> with that 4 byte offset as is written in the comments, in every other case
> proto_ports_offset() is 0, so why would we want the SPI in the ->ports field ?
> And even then isn't it supposed to be 16 bits (2 bytes) and not 4, since we need
> to pass over "next header" (8 bits) and length (8 bits) ?
> 
Nevermind the second part, I forgot about the 16-bit 0 region :-)

> Thanks,
>  Nik

Re: [PATCH]

[Eric Dumazet]

On Thu, 2013-09-26 at 17:40 +0200, Nikolay Aleksandrov wrote:
> > 
> 1 question, I might be missing something but proto_ports_offset() gets the SPI
> with that 4 byte offset as is written in the comments, in every other case
> proto_ports_offset() is 0, so why would we want the SPI in the ->ports field ?
> And even then isn't it supposed to be 16 bits (2 bytes) and not 4, since we need
> to pass over "next header" (8 bits) and length (8 bits) ?

struct ip_auth_hdr {
        __u8  nexthdr;
        __u8  hdrlen;           /* This one is measured in 32 bit units! */
        __be16 reserved;
        __be32 spi;
        __be32 seq_no;          /* Sequence number */
        __u8  auth_data[0];     /* Variable len but >=4. Mind the 64 bit alignment! */
};

offsetof(spi, struct ...) = 4

[PATCH]

[Jan Pešta]

Hi,

I found a problem when using GIT-SVN.

In inproperly merges in SVN causes that the ranges contains additional
character "*". 

Attached patch fix this issue, I have it already tested for several months.

Regards,
Jan


Kind regards / S pozdravem
 

Jan Pešta
SW Engineer Sr.

CertiCon a.s., www.certicon.cz
Vaclavska 12
12000 Prague 2
Czech Republic
 
Office Prague: +420 224 904 406
Mobile: +420 604 794 306
 
E-mail: jan.pesta@certicon.cz

Re: [PATCH]

[Matthieu Moy]

Jan Pešta <jan.pesta@certicon.cz> writes:

> Attached patch fix this issue,

Nothing attached, it seems ;-).

Please, read Documentation/SubmittingPatches in Git's source code.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

[PATCH]

[Stefan Richter]

CONFIG_FIREWIRE_OHCI_DEBUG could have been exposed to kernel tweakers
if CONFIG_EXPERT was set.  But in hindsight, this stuff is far too
useful to omit it.  So get rid of two #else branches that are only
going to bitrot otherwise.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
 drivers/firewire/Kconfig |    5 -----
 drivers/firewire/ohci.c  |   20 +-------------------
 2 files changed, 1 insertion(+), 24 deletions(-)

--- a/drivers/firewire/Kconfig
+++ b/drivers/firewire/Kconfig
@@ -28,11 +28,6 @@ config FIREWIRE_OHCI
 	  To compile this driver as a module, say M here:  The module will be
 	  called firewire-ohci.
 
-config FIREWIRE_OHCI_DEBUG
-	bool
-	depends on FIREWIRE_OHCI
-	default y
-
 config FIREWIRE_SBP2
 	tristate "Storage devices (SBP-2 protocol)"
 	depends on FIREWIRE && SCSI
--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
@@ -338,8 +338,6 @@ MODULE_PARM_DESC(quirks, "Chip quirks (d
 #define OHCI_PARAM_DEBUG_IRQS		4
 #define OHCI_PARAM_DEBUG_BUSRESETS	8 /* only effective before chip init */
 
-#ifdef CONFIG_FIREWIRE_OHCI_DEBUG
-
 static int param_debug;
 module_param_named(debug, param_debug, int, 0644);
 MODULE_PARM_DESC(debug, "Verbose logging (default = 0"
@@ -520,15 +518,6 @@ static void log_ar_at_event(struct fw_oh
 	}
 }
 
-#else
-
-#define param_debug 0
-static inline void log_irqs(struct fw_ohci *ohci, u32 evt) {}
-static inline void log_selfids(struct fw_ohci *ohci, int generation, int self_id_count) {}
-static inline void log_ar_at_event(struct fw_ohci *ohci, char dir, int speed, u32 *header, int evt) {}
-
-#endif /* CONFIG_FIREWIRE_OHCI_DEBUG */
-
 static inline void reg_write(const struct fw_ohci *ohci, int offset, u32 data)
 {
 	writel(data, ohci->registers + offset);
@@ -1640,17 +1629,10 @@ static void detect_dead_context(struct f
 	u32 ctl;
 
 	ctl = reg_read(ohci, CONTROL_SET(regs));
-	if (ctl & CONTEXT_DEAD) {
-#ifdef CONFIG_FIREWIRE_OHCI_DEBUG
+	if (ctl & CONTEXT_DEAD)
 		dev_err(ohci->card.device,
 			"DMA context %s has stopped, error code: %s\n",
 			name, evts[ctl & 0x1f]);
-#else
-		dev_err(ohci->card.device,
-			"DMA context %s has stopped, error code: %#x\n",
-			name, ctl & 0x1f);
-#endif
-	}
 }
 
 static void handle_dead_contexts(struct fw_ohci *ohci)


-- 
Stefan Richter
-=====-===-- --== --=--
http://arcgraph.de/sr/

Re: [PATCH]

[Stefan Richter]

On Mar 04 Stefan Richter wrote:
> CONFIG_FIREWIRE_OHCI_DEBUG could have been exposed to kernel tweakers
> if CONFIG_EXPERT was set.  But in hindsight, this stuff is far too
> useful to omit it.  So get rid of two #else branches that are only
> going to bitrot otherwise.

Sorry, this was meant to be sent with

    Subject: [PATCH] firewire: ohci: move runtime debug facility out of #ifdef
-- 
Stefan Richter
-=====-===-- --== --=--
http://arcgraph.de/sr/

[PATCH]

[Alan Stern]

This patch (as1514) cleans up some places where new_id and remove_id
sysfs attributes are created and deleted.  Handling both attributes in
a single routine rather than a pair of routines makes the code
smaller.  It also prevents certain kinds of errors, like one we
currently have in the USB subsystem: The removeid attribute is often
created even when newid isn't (because the driver's no_dynamid_id flag
is set).

In the case of the PCMCIA subsystem, the newid attribute is created
but never explicitly deleted.  The patch adds a deletion routine.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: Dominik Brodowski <linux@dominikbrodowski.net>

---

 drivers/pci/pci-driver.c  |   50 ++++++++++++-------------------------
 drivers/pcmcia/ds.c       |    6 ++++
 drivers/usb/core/driver.c |   61 +++++++++++++++-------------------------------
 3 files changed, 43 insertions(+), 74 deletions(-)

Index: usb-3.3/drivers/pci/pci-driver.c
===================================================================
--- usb-3.3.orig/drivers/pci/pci-driver.c
+++ usb-3.3/drivers/pci/pci-driver.c
@@ -188,43 +188,34 @@ store_remove_id(struct device_driver *dr
 static DRIVER_ATTR(remove_id, S_IWUSR, NULL, store_remove_id);
 
 static int
-pci_create_newid_file(struct pci_driver *drv)
+pci_create_newid_files(struct pci_driver *drv)
 {
 	int error = 0;
-	if (drv->probe != NULL)
-		error = driver_create_file(&drv->driver, &driver_attr_new_id);
-	return error;
-}
-
-static void pci_remove_newid_file(struct pci_driver *drv)
-{
-	driver_remove_file(&drv->driver, &driver_attr_new_id);
-}
 
-static int
-pci_create_removeid_file(struct pci_driver *drv)
-{
-	int error = 0;
-	if (drv->probe != NULL)
-		error = driver_create_file(&drv->driver,&driver_attr_remove_id);
+	if (drv->probe != NULL) {
+		error = driver_create_file(&drv->driver, &driver_attr_new_id);
+		if (error == 0) {
+			error = driver_create_file(&drv->driver,
+					&driver_attr_remove_id);
+			if (error)
+				driver_remove_file(&drv->driver,
+						&driver_attr_new_id);
+		}
+	}
 	return error;
 }
 
-static void pci_remove_removeid_file(struct pci_driver *drv)
+static void pci_remove_newid_files(struct pci_driver *drv)
 {
 	driver_remove_file(&drv->driver, &driver_attr_remove_id);
+	driver_remove_file(&drv->driver, &driver_attr_new_id);
 }
 #else /* !CONFIG_HOTPLUG */
-static inline int pci_create_newid_file(struct pci_driver *drv)
+static inline int pci_create_newid_files(struct pci_driver *drv)
 {
 	return 0;
 }
-static inline void pci_remove_newid_file(struct pci_driver *drv) {}
-static inline int pci_create_removeid_file(struct pci_driver *drv)
-{
-	return 0;
-}
-static inline void pci_remove_removeid_file(struct pci_driver *drv) {}
+static inline void pci_remove_newid_files(struct pci_driver *drv) {}
 #endif
 
 /**
@@ -1136,18 +1127,12 @@ int __pci_register_driver(struct pci_dri
 	if (error)
 		goto out;
 
-	error = pci_create_newid_file(drv);
+	error = pci_create_newid_files(drv);
 	if (error)
 		goto out_newid;
-
-	error = pci_create_removeid_file(drv);
-	if (error)
-		goto out_removeid;
 out:
 	return error;
 
-out_removeid:
-	pci_remove_newid_file(drv);
 out_newid:
 	driver_unregister(&drv->driver);
 	goto out;
@@ -1166,8 +1151,7 @@ out_newid:
 void
 pci_unregister_driver(struct pci_driver *drv)
 {
-	pci_remove_removeid_file(drv);
-	pci_remove_newid_file(drv);
+	pci_remove_newid_files(drv);
 	driver_unregister(&drv->driver);
 	pci_free_dynids(drv);
 }
Index: usb-3.3/drivers/pcmcia/ds.c
===================================================================
--- usb-3.3.orig/drivers/pcmcia/ds.c
+++ usb-3.3/drivers/pcmcia/ds.c
@@ -157,6 +157,11 @@ pcmcia_create_newid_file(struct pcmcia_d
 	return error;
 }
 
+static void
+pcmcia_remove_newid_file(struct pcmcia_driver *drv)
+{
+	driver_remove_file(&drv->drv, &driver_attr_new_id);
+}
 
 /**
  * pcmcia_register_driver - register a PCMCIA driver with the bus core
@@ -201,6 +206,7 @@ EXPORT_SYMBOL(pcmcia_register_driver);
 void pcmcia_unregister_driver(struct pcmcia_driver *driver)
 {
 	pr_debug("unregistering driver %s\n", driver->name);
+	pcmcia_remove_newid_file(driver);
 	driver_unregister(&driver->drv);
 	pcmcia_free_dynids(driver);
 }
Index: usb-3.3/drivers/usb/core/driver.c
===================================================================
--- usb-3.3.orig/drivers/usb/core/driver.c
+++ usb-3.3/drivers/usb/core/driver.c
@@ -129,43 +129,39 @@ store_remove_id(struct device_driver *dr
 }
 static DRIVER_ATTR(remove_id, S_IWUSR, NULL, store_remove_id);
 
-static int usb_create_newid_file(struct usb_driver *usb_drv)
+static int usb_create_newid_files(struct usb_driver *usb_drv)
 {
 	int error = 0;
 
 	if (usb_drv->no_dynamic_id)
 		goto exit;
 
-	if (usb_drv->probe != NULL)
+	if (usb_drv->probe != NULL) {
 		error = driver_create_file(&usb_drv->drvwrap.driver,
 					   &driver_attr_new_id);
+		if (error == 0) {
+			error = driver_create_file(&usb_drv->drvwrap.driver,
+					&driver_attr_remove_id);
+			if (error)
+				driver_remove_file(&usb_drv->drvwrap.driver,
+						&driver_attr_new_id);
+		}
+	}
 exit:
 	return error;
 }
 
-static void usb_remove_newid_file(struct usb_driver *usb_drv)
+static void usb_remove_newid_files(struct usb_driver *usb_drv)
 {
 	if (usb_drv->no_dynamic_id)
 		return;
 
-	if (usb_drv->probe != NULL)
+	if (usb_drv->probe != NULL) {
 		driver_remove_file(&usb_drv->drvwrap.driver,
-				   &driver_attr_new_id);
-}
-
-static int
-usb_create_removeid_file(struct usb_driver *drv)
-{
-	int error = 0;
-	if (drv->probe != NULL)
-		error = driver_create_file(&drv->drvwrap.driver,
 				&driver_attr_remove_id);
-	return error;
-}
-
-static void usb_remove_removeid_file(struct usb_driver *drv)
-{
-	driver_remove_file(&drv->drvwrap.driver, &driver_attr_remove_id);
+		driver_remove_file(&usb_drv->drvwrap.driver,
+				   &driver_attr_new_id);
+	}
 }
 
 static void usb_free_dynids(struct usb_driver *usb_drv)
@@ -180,22 +176,12 @@ static void usb_free_dynids(struct usb_d
 	spin_unlock(&usb_drv->dynids.lock);
 }
 #else
-static inline int usb_create_newid_file(struct usb_driver *usb_drv)
-{
-	return 0;
-}
-
-static void usb_remove_newid_file(struct usb_driver *usb_drv)
-{
-}
-
-static int
-usb_create_removeid_file(struct usb_driver *drv)
+static inline int usb_create_newid_files(struct usb_driver *usb_drv)
 {
 	return 0;
 }
 
-static void usb_remove_removeid_file(struct usb_driver *drv)
+static void usb_remove_newid_files(struct usb_driver *usb_drv)
 {
 }
 
@@ -872,22 +858,16 @@ int usb_register_driver(struct usb_drive
 
 	usbfs_update_special();
 
-	retval = usb_create_newid_file(new_driver);
+	retval = usb_create_newid_files(new_driver);
 	if (retval)
 		goto out_newid;
 
-	retval = usb_create_removeid_file(new_driver);
-	if (retval)
-		goto out_removeid;
-
 	pr_info("%s: registered new interface driver %s\n",
 			usbcore_name, new_driver->name);
 
 out:
 	return retval;
 
-out_removeid:
-	usb_remove_newid_file(new_driver);
 out_newid:
 	driver_unregister(&new_driver->drvwrap.driver);
 
@@ -914,10 +894,9 @@ void usb_deregister(struct usb_driver *d
 	pr_info("%s: deregistering interface driver %s\n",
 			usbcore_name, driver->name);
 
-	usb_remove_removeid_file(driver);
-	usb_remove_newid_file(driver);
-	usb_free_dynids(driver);
+	usb_remove_newid_files(driver);
 	driver_unregister(&driver->drvwrap.driver);
+	usb_free_dynids(driver);
 
 	usbfs_update_special();
 }

Re: [PATCH]

[Greg KH]

On Tue, Jan 24, 2012 at 01:37:34PM -0500, Alan Stern wrote:
> This patch (as1514) cleans up some places where new_id and remove_id
> sysfs attributes are created and deleted.  Handling both attributes in
> a single routine rather than a pair of routines makes the code
> smaller.  It also prevents certain kinds of errors, like one we
> currently have in the USB subsystem: The removeid attribute is often
> created even when newid isn't (because the driver's no_dynamid_id flag
> is set).
> 
> In the case of the PCMCIA subsystem, the newid attribute is created
> but never explicitly deleted.  The patch adds a deletion routine.
> 
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> CC: Jesse Barnes <jbarnes@virtuousgeek.org>
> CC: Dominik Brodowski <linux@dominikbrodowski.net>

I think this is missing a real "Subject:" right?

[PATCH]

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>
Subject: fs / ext3: Always unlock updates in ext3_freeze()

In analogy with ext4 make ext3_freeze() always call
journal_unlock_updates() to prevent it from leaving a locked mutex
behind.  Accordingly, modify ext3_unfreeze() so that it doesn't
call journal_unlock_updates() any more.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 fs/ext3/super.c |   39 ++++++++++++++++++---------------------
 1 file changed, 18 insertions(+), 21 deletions(-)

Index: linux/fs/ext3/super.c
===================================================================
--- linux.orig/fs/ext3/super.c
+++ linux/fs/ext3/super.c
@@ -2535,30 +2535,28 @@ static int ext3_sync_fs(struct super_blo
  */
 static int ext3_freeze(struct super_block *sb)
 {
-	int error = 0;
+	int error;
 	journal_t *journal;
 
-	if (!(sb->s_flags & MS_RDONLY)) {
-		journal = EXT3_SB(sb)->s_journal;
+	if (sb->s_flags & MS_RDONLY)
+		return 0;
 
-		/* Now we set up the journal barrier. */
-		journal_lock_updates(journal);
+	journal = EXT3_SB(sb)->s_journal;
 
-		/*
-		 * We don't want to clear needs_recovery flag when we failed
-		 * to flush the journal.
-		 */
-		error = journal_flush(journal);
-		if (error < 0)
-			goto out;
-
-		/* Journal blocked and flushed, clear needs_recovery flag. */
-		EXT3_CLEAR_INCOMPAT_FEATURE(sb, EXT3_FEATURE_INCOMPAT_RECOVER);
-		error = ext3_commit_super(sb, EXT3_SB(sb)->s_es, 1);
-		if (error)
-			goto out;
-	}
-	return 0;
+	/* Now we set up the journal barrier. */
+	journal_lock_updates(journal);
+
+	/*
+	 * We don't want to clear needs_recovery flag when we failed
+	 * to flush the journal.
+	 */
+	error = journal_flush(journal);
+	if (error < 0)
+		goto out;
+
+	/* Journal blocked and flushed, clear needs_recovery flag. */
+	EXT3_CLEAR_INCOMPAT_FEATURE(sb, EXT3_FEATURE_INCOMPAT_RECOVER);
+	error = ext3_commit_super(sb, EXT3_SB(sb)->s_es, 1);
 
 out:
 	journal_unlock_updates(journal);
@@ -2577,7 +2575,6 @@ static int ext3_unfreeze(struct super_bl
 		EXT3_SET_INCOMPAT_FEATURE(sb, EXT3_FEATURE_INCOMPAT_RECOVER);
 		ext3_commit_super(sb, EXT3_SB(sb)->s_es, 1);
 		unlock_super(sb);
-		journal_unlock_updates(EXT3_SB(sb)->s_journal);
 	}
 	return 0;
 }

[PATCH]

[Junio C Hamano]

In 60f33b8 (kconfig: get rid of stray a.o, support ncursesw, 2006-01-15),
support to link menuconfig with ncursesw library was added.  To compute
the linker command option -l, we check "libncursesw.{so,a,dylib}" to allow
ncursesw to be used as a replacement ncurses.  However, when checking what
header file to include, we do not check /usr/include/ncursesw directory.

Add /usr/include/ncursesw to the list of directories that are checked.
With this patch, on my Debian Lenny box with libncursesw5-dev package but
not libncurses5-dev package, I can say "make menuconfig".

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 * There is no /usr/include/ncurses/ directory but /usr/include/ncursesw
   exists, and has curses.h in it.

 scripts/kconfig/lxdialog/check-lxdialog.sh |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/scripts/kconfig/lxdialog/check-lxdialog.sh b/scripts/kconfig/lxdialog/check-lxdialog.sh
index fcef0f5..82cc3a8 100644
--- a/scripts/kconfig/lxdialog/check-lxdialog.sh
+++ b/scripts/kconfig/lxdialog/check-lxdialog.sh
@@ -23,6 +23,8 @@ ccflags()
 		echo '-I/usr/include/ncurses -DCURSES_LOC="<ncurses.h>"'
 	elif [ -f /usr/include/ncurses/curses.h ]; then
 		echo '-I/usr/include/ncurses -DCURSES_LOC="<ncurses/curses.h>"'
+	elif [ -f /usr/include/ncursesw/curses.h ]; then
+		echo '-I/usr/include/ncursesw -DCURSES_LOC="<ncursesw/curses.h>"'
 	elif [ -f /usr/include/ncurses.h ]; then
 		echo '-DCURSES_LOC="<ncurses.h>"'
 	else

Re: [PATCH]

[Sam Ravnborg]

On Sat, Sep 18, 2010 at 07:25:32PM -0700, Junio C Hamano wrote:
> In 60f33b8 (kconfig: get rid of stray a.o, support ncursesw, 2006-01-15),
> support to link menuconfig with ncursesw library was added.  To compute
> the linker command option -l, we check "libncursesw.{so,a,dylib}" to allow
> ncursesw to be used as a replacement ncurses.  However, when checking what
> header file to include, we do not check /usr/include/ncursesw directory.
> 
> Add /usr/include/ncursesw to the list of directories that are checked.
> With this patch, on my Debian Lenny box with libncursesw5-dev package but
> not libncurses5-dev package, I can say "make menuconfig".
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Except for the missing patch subject then it looks OK.

Suggested subject:
kconfig: fix menuconfig on debian lenny

Add as this is a fix we should Cc: <stable@kerne.org>?

Acked-by: Sam Ravnborg <sam@ravnborg.org>

	Sam

Re: [PATCH]

[Junio C Hamano]

Sam Ravnborg <sam@ravnborg.org> writes:

> On Sat, Sep 18, 2010 at 07:25:32PM -0700, Junio C Hamano wrote:
>> In 60f33b8 (kconfig: get rid of stray a.o, support ncursesw, 2006-01-15),
>> support to link menuconfig with ncursesw library was added.  To compute
>> the linker command option -l, we check "libncursesw.{so,a,dylib}" to allow
>> ncursesw to be used as a replacement ncurses.  However, when checking what
>> header file to include, we do not check /usr/include/ncursesw directory.
>> 
>> Add /usr/include/ncursesw to the list of directories that are checked.
>> With this patch, on my Debian Lenny box with libncursesw5-dev package but
>> not libncurses5-dev package, I can say "make menuconfig".
>> 
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> Except for the missing patch subject then it looks OK.
> Suggested subject:
> kconfig: fix menuconfig on debian lenny

Sorry, the missing subject really was sloppy of me, and thanks.

> Add as this is a fix we should Cc: <stable@kerne.org>?

I don't think the fix deserves to be in stable.  It does not look like
60f33b8 made it possible to use ncursesw on a box like mine so the patch
is not evan an regression-fix.

> Acked-by: Sam Ravnborg <sam@ravnborg.org>

Thanks; is it my responsibility to follow-up the thread with identical
patch with updated Subject and with your Ack, hoping somebody in kbuild
team would pick it up?

Re: [PATCH]

[Sam Ravnborg]

On Sun, Sep 19, 2010 at 11:21:21AM -0700, Junio C Hamano wrote:
> Sam Ravnborg <sam@ravnborg.org> writes:
> 
> > On Sat, Sep 18, 2010 at 07:25:32PM -0700, Junio C Hamano wrote:
> >> In 60f33b8 (kconfig: get rid of stray a.o, support ncursesw, 2006-01-15),
> >> support to link menuconfig with ncursesw library was added.  To compute
> >> the linker command option -l, we check "libncursesw.{so,a,dylib}" to allow
> >> ncursesw to be used as a replacement ncurses.  However, when checking what
> >> header file to include, we do not check /usr/include/ncursesw directory.
> >> 
> >> Add /usr/include/ncursesw to the list of directories that are checked.
> >> With this patch, on my Debian Lenny box with libncursesw5-dev package but
> >> not libncurses5-dev package, I can say "make menuconfig".
> >> 
> >> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> >
> > Except for the missing patch subject then it looks OK.
> > Suggested subject:
> > kconfig: fix menuconfig on debian lenny
> 
> Sorry, the missing subject really was sloppy of me, and thanks.
> 
> > Add as this is a fix we should Cc: <stable@kerne.org>?
> 
> I don't think the fix deserves to be in stable.  It does not look like
> 60f33b8 made it possible to use ncursesw on a box like mine so the patch
> is not evan an regression-fix.
OK
> 
> > Acked-by: Sam Ravnborg <sam@ravnborg.org>
> 
> Thanks; is it my responsibility to follow-up the thread with identical
> patch with updated Subject and with your Ack, hoping somebody in kbuild
> team would pick it up?

I assume Michal will pick it up anyway - but if you do it would make
it simpler for him to do so.
So no need..

	Sam

Re: [PATCH]

[Michal Marek]

On 19.9.2010 20:21, Junio C Hamano wrote:
> Sam Ravnborg <sam@ravnborg.org> writes:
>> On Sat, Sep 18, 2010 at 07:25:32PM -0700, Junio C Hamano wrote:
>>> In 60f33b8 (kconfig: get rid of stray a.o, support ncursesw, 2006-01-15),
>>> support to link menuconfig with ncursesw library was added.  To compute
>>> the linker command option -l, we check "libncursesw.{so,a,dylib}" to allow
>>> ncursesw to be used as a replacement ncurses.  However, when checking what
>>> header file to include, we do not check /usr/include/ncursesw directory.
>>>
>>> Add /usr/include/ncursesw to the list of directories that are checked.
>>> With this patch, on my Debian Lenny box with libncursesw5-dev package but
>>> not libncurses5-dev package, I can say "make menuconfig".
>>>
>>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>>
[...]
> 
>> Acked-by: Sam Ravnborg <sam@ravnborg.org>
> 
> Thanks; is it my responsibility to follow-up the thread with identical
> patch with updated Subject and with your Ack, hoping somebody in kbuild
> team would pick it up?

I fixed the subject line myself and applied it to kbuild-2.6.git#kconfig.

Thanks,
Michal

[PATCH]

[Sam Ravnborg]

>From 705dbd8a31520722bda78e1bc731e2880f8df0ff Mon Sep 17 00:00:00 2001
From: Sam Ravnborg <sam@ravnborg.org>
Date: Sat, 14 Aug 2010 14:40:00 +0200
Subject: [PATCH] kconfig: fix segfault when detecting recursive dependency

Following sample Kconfig generated a segfault:

config FOO
        bool
        select PERF_EVENTS if HAVE_HW_BREAKPOINT

config PERF_EVENTS
        bool

config HAVE_HW_BREAKPOINT
        bool
        depends on PERF_EVENTS

Fix by reverting back to a valid property if there was no
property on the stack of symbols.

The above pattern were seen in sh Kconfig.
A fix for the Kconfig file has been sent to the sh folks.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
---
 scripts/kconfig/symbol.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index e95718f..943712c 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -937,6 +937,8 @@ static void sym_check_print_recursive(struct symbol *last_sym)
 		sym = stack->sym;
 		next_sym = stack->next ? stack->next->sym : last_sym;
 		prop = stack->prop;
+		if (prop == NULL)
+			prop = stack->sym->prop;
 
 		/* for choice values find the menu entry (used below) */
 		if (sym_is_choice(sym) || sym_is_choice_value(sym)) {
-- 
1.6.0.6

[PATCH]

[Sam Ravnborg]

From 705dbd8a31520722bda78e1bc731e2880f8df0ff Mon Sep 17 00:00:00 2001
From: Sam Ravnborg <sam@ravnborg.org>
Date: Sat, 14 Aug 2010 14:40:00 +0200
Subject: [PATCH] kconfig: fix segfault when detecting recursive dependency

Following sample Kconfig generated a segfault:

config FOO
        bool
        select PERF_EVENTS if HAVE_HW_BREAKPOINT

config PERF_EVENTS
        bool

config HAVE_HW_BREAKPOINT
        bool
        depends on PERF_EVENTS

Fix by reverting back to a valid property if there was no
property on the stack of symbols.

The above pattern were seen in sh Kconfig.
A fix for the Kconfig file has been sent to the sh folks.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
---
 scripts/kconfig/symbol.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index e95718f..943712c 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -937,6 +937,8 @@ static void sym_check_print_recursive(struct symbol *last_sym)
 		sym = stack->sym;
 		next_sym = stack->next ? stack->next->sym : last_sym;
 		prop = stack->prop;
+		if (prop == NULL)
+			prop = stack->sym->prop;
 
 		/* for choice values find the menu entry (used below) */
 		if (sym_is_choice(sym) || sym_is_choice_value(sym)) {
-- 
1.6.0.6

[PATCH]

[Zhigang Wang]

[-- Attachment #1: Type: text/plain, Size: 269 bytes --]

hi,

This patch remove the runtime download and compile of libconfig package. This
package should be pre-installed by user manually.

Xen should not do so much dirty things at compile time.

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>

thanks,

zhigang





[-- Attachment #2: xen-remove-libconfig-runtime-download.patch --]
[-- Type: text/x-patch, Size: 1893 bytes --]

--- xen-unstable/tools/libxl/Makefile.org	2010-02-04 05:29:02.000000000 -0500
+++ xen-unstable/tools/libxl/Makefile	2010-02-04 05:31:23.000000000 -0500
@@ -14,11 +14,6 @@ CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_
 
 LIBS = $(LDFLAGS_libxenctrl) $(LDFLAGS_libxenguest) $(LDFLAGS_libxenstore)
 
-#LIBCONFIG_URL ?= http://www.hyperrealm.com/libconfig
-LIBCONFIG_URL = $(XEN_EXTFILES_URL)
-LIBCONFIG_SOURCE = libconfig-1.3.2
-LIBCONFIG_OUTPUT = $(LIBCONFIG_SOURCE)/.libs
-
 LIBXL_OBJS-y = osdeps.o
 LIBXL_OBJS = flexarray.o libxl.o libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o libxl_internal.o xenguest.o libxl_utils.o $(LIBXL_OBJS-y)
 
@@ -39,18 +34,11 @@ libxenlight.so.$(MAJOR).$(MINOR): $(LIBX
 libxenlight.a: $(LIBXL_OBJS)
 	$(AR) rcs libxenlight.a $^
 
-$(LIBCONFIG_SOURCE).tar.gz:
-	$(WGET) $(LIBCONFIG_URL)/$@
-
-$(LIBCONFIG_OUTPUT)/libconfig.so: $(LIBCONFIG_SOURCE).tar.gz
-	[ ! -d "$(LIBCONFIG_SOURCE)" ] && tar xzf $<
-	cd $(LIBCONFIG_SOURCE) && ./configure --prefix=$(PREFIX) --libdir=$(LIBDIR) --disable-cxx && $(MAKE)
-
-xl.o: $(LIBCONFIG_OUTPUT)/libconfig.so xl.c
-	$(CC) $(CFLAGS) -I$(LIBCONFIG_SOURCE) -c xl.c
+xl.o: xl.c
+	$(CC) $(CFLAGS) -c xl.c
 
-$(CLIENTS): xl.o libxenlight.so $(LIBCONFIG_OUTPUT)/libconfig.so
-	$(CC) $(LDFLAGS) -o $@ $< $(LIBS) -L . -lxenlight -L$(LIBCONFIG_OUTPUT) -lconfig
+$(CLIENTS): xl.o libxenlight.so
+	$(CC) $(LDFLAGS) -o $@ $< $(LIBS) -L . -lxenlight -lconfig
 
 .PHONY: install
 install: all
@@ -60,14 +48,11 @@ install: all
 	ln -sf libxenlight.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libxenlight.so
 	$(INSTALL_DATA) libxenlight.a $(DESTDIR)$(LIBDIR)
 	$(INSTALL_DATA) libxl.h $(DESTDIR)$(INCLUDEDIR)
-	cd $(LIBCONFIG_SOURCE) && DESTDIR=$(DESTDIR) $(MAKE) install
 
 .PHONY: clean
 clean:
 	$(RM) -f *.o *.so* *.a $(CLIENTS) $(DEPS)
-	$(RM) -rf $(LIBCONFIG_SOURCE)
 
 distclean: clean
-	$(RM) -f $(LIBCONFIG_SOURCE).tar.gz
 
 -include $(DEPS)

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

[PATCH]

[flinkdeldinky]

The following patch provides functionality for the STLabs PCI card. 
It's a saa7134 card.  I may be the only guy still using it!  I've been
compiling it the code for each kernel I use for years now.

Iif you guys accept this patch you may want to add the following
documentation somewhere (I don't know where to put it):
This card is auto detected as a 10 MOONS card, that doesn't work though.

I load saa7134 as follows:
saa7134 card=175 tuner=5

Everything on the card seems to function and that includes the firewire
port.  I don't know about the remote control though.

Tuners 3, 5, 14, 20, 28, 29, 24, 48 seem to work equally well. Those are
all
the PAL BG tuners. I spot checked several non PAL BG tuners and none worked.


diff -r d6c09c3711b5
linux/drivers/media/video/saa7134/saa7134-cards.c          
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Sun Sep 20
15:14:21 2009
+0000                                                                        
 
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Thu Oct 29
14:54:31 2009
+0700                                                                        
 
@@ -5342,7 +5342,38
@@                                                          
                        .amux   =
LINE2,                                        
                }
},                                                            
       
},                                                                      
-                                                                             
 
+       [SAA7134_BOARD_STLAB_PCI_TV7130] =
{                                    
+       /* "Aidan Gill"
*/                                                      
+               .name = "ST Lab ST Lab PCI-TV7130
",                            
+               .audio_clock =
0x00200000,                                      
+               .tuner_type =
TUNER_LG_PAL_NEW_TAPC,                            
+               .radio_type     =
UNSET,                                        
+               .tuner_addr     =
ADDR_UNSET,                                   
+               .radio_addr     =
ADDR_UNSET,                                   
+               .gpiomask =
0x7000,                                             
+               .inputs =
{{                                                    
+                       .name =
name_tv,                                        
+                       .vmux =
1,                                              
+                       .amux =
LINE2,                                          
+                       .gpio =
0x0000,                                         
+                       .tv =
1,                                                
+               },
{                                                            
+                       .name =
name_comp1,                                     
+                       .vmux =
3,                                              
+                       .amux =
LINE1,                                          
+                       .gpio =
0x2000,                                         
+               },
{                                                            
+                       .name =
name_svideo,                                    
+                       .vmux =
0,                                              
+                       .amux =
LINE1,                                          
+                       .gpio =
0x2000,                                         
+               }
},                                                            
+               .mute =
{                                                       
+                       .name =
name_mute,                                      
+                       .amux =
TV,                                             
+                       .gpio =
0x3000,                                         
+              
},                                                              
+      
},                                                                      
 };                                                                           
 
                                                                              
 
 const unsigned int saa7134_bcount =
ARRAY_SIZE(saa7134_boards);                
@@ -6487,6 +6518,12
@@                                                          
                .subdevice    =
0x4847,                                         
                .driver_data  =
SAA7134_BOARD_ASUS_EUROPA_HYBRID,               
        },
{                                                                    
+               .vendor       =
PCI_VENDOR_ID_PHILIPS,                          
+               .device       =
PCI_DEVICE_ID_PHILIPS_SAA7130,                  
+               .subvendor    = 
PCI_VENDOR_ID_PHILIPS,                         
+               .subdevice    = 0x2001,
+               .driver_data  = SAA7134_BOARD_STLAB_PCI_TV7130,
+       }, {
                /* --- boards without eeprom + subsystem ID --- */
                .vendor       = PCI_VENDOR_ID_PHILIPS,
                .device       = PCI_DEVICE_ID_PHILIPS_SAA7134,
diff -r d6c09c3711b5 linux/drivers/media/video/saa7134/saa7134.h
--- a/linux/drivers/media/video/saa7134/saa7134.h       Sun Sep 20
15:14:21 2009 +0000
+++ b/linux/drivers/media/video/saa7134/saa7134.h       Thu Oct 29
14:54:31 2009 +0700
@@ -299,6 +299,7 @@
 #define SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM 172
 #define SAA7134_BOARD_ZOLID_HYBRID_PCI         173
 #define SAA7134_BOARD_ASUS_EUROPA_HYBRID       174
+#define SAA7134_BOARD_STLAB_PCI_TV7130         175

 #define SAA7134_MAXBOARDS 32
 #define SAA7134_INPUT_MAX 8

Signed-off-by: Michael Wellman <flinkdeldinky@gmail.com>

Re: [PATCH]

[Jarod Wilson]

On Oct 29, 2009, at 10:51 AM, flinkdeldinky wrote:

> The following patch provides functionality for the STLabs PCI card.
> It's a saa7134 card.

The patch is also horribly mangled by line-wrapping. Please resubmit  
it without the line wrapping, and with a useful subject.


> I may be the only guy still using it!  I've been
> compiling it the code for each kernel I use for years now.
>
> Iif you guys accept this patch you may want to add the following
> documentation somewhere (I don't know where to put it):
> This card is auto detected as a 10 MOONS card, that doesn't work  
> though.
>
> I load saa7134 as follows:
> saa7134 card=175 tuner=5
>
> Everything on the card seems to function and that includes the  
> firewire
> port.  I don't know about the remote control though.
>
> Tuners 3, 5, 14, 20, 28, 29, 24, 48 seem to work equally well. Those  
> are
> all
> the PAL BG tuners. I spot checked several non PAL BG tuners and none  
> worked.
>
>
> diff -r d6c09c3711b5
> linux/drivers/media/video/saa7134/saa7134-cards.c
> --- a/linux/drivers/media/video/saa7134/saa7134-cards.c Sun Sep 20
> 15:14:21 2009
> +0000
>
> +++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Thu Oct 29
> 14:54:31 2009
> +0700
>
> @@ -5342,7 +5342,38
> @@
>                        .amux   =
> LINE2,
>                }
> },
>
> },
> -
>
> +       [SAA7134_BOARD_STLAB_PCI_TV7130] =
> {
> +       /* "Aidan Gill"
> */
> +               .name = "ST Lab ST Lab PCI-TV7130
> ",
> +               .audio_clock =
> 0x00200000,
> +               .tuner_type =
> TUNER_LG_PAL_NEW_TAPC,
> +               .radio_type     =
> UNSET,
> +               .tuner_addr     =
> ADDR_UNSET,
> +               .radio_addr     =
> ADDR_UNSET,
> +               .gpiomask =
> 0x7000,
> +               .inputs =
> {{
> +                       .name =
> name_tv,
> +                       .vmux =
> 1,
> +                       .amux =
> LINE2,
> +                       .gpio =
> 0x0000,
> +                       .tv =
> 1,
> +               },
> {
> +                       .name =
> name_comp1,
> +                       .vmux =
> 3,
> +                       .amux =
> LINE1,
> +                       .gpio =
> 0x2000,
> +               },
> {
> +                       .name =
> name_svideo,
> +                       .vmux =
> 0,
> +                       .amux =
> LINE1,
> +                       .gpio =
> 0x2000,
> +               }
> },
> +               .mute =
> {
> +                       .name =
> name_mute,
> +                       .amux =
> TV,
> +                       .gpio =
> 0x3000,
> +
> },
> +
> },
> };
>
>
>
> const unsigned int saa7134_bcount =
> ARRAY_SIZE(saa7134_boards);
> @@ -6487,6 +6518,12
> @@
>                .subdevice    =
> 0x4847,
>                .driver_data  =
> SAA7134_BOARD_ASUS_EUROPA_HYBRID,
>        },
> {
> +               .vendor       =
> PCI_VENDOR_ID_PHILIPS,
> +               .device       =
> PCI_DEVICE_ID_PHILIPS_SAA7130,
> +               .subvendor    =
> PCI_VENDOR_ID_PHILIPS,
> +               .subdevice    = 0x2001,
> +               .driver_data  = SAA7134_BOARD_STLAB_PCI_TV7130,
> +       }, {
>                /* --- boards without eeprom + subsystem ID --- */
>                .vendor       = PCI_VENDOR_ID_PHILIPS,
>                .device       = PCI_DEVICE_ID_PHILIPS_SAA7134,
> diff -r d6c09c3711b5 linux/drivers/media/video/saa7134/saa7134.h
> --- a/linux/drivers/media/video/saa7134/saa7134.h       Sun Sep 20
> 15:14:21 2009 +0000
> +++ b/linux/drivers/media/video/saa7134/saa7134.h       Thu Oct 29
> 14:54:31 2009 +0700
> @@ -299,6 +299,7 @@
> #define SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM 172
> #define SAA7134_BOARD_ZOLID_HYBRID_PCI         173
> #define SAA7134_BOARD_ASUS_EUROPA_HYBRID       174
> +#define SAA7134_BOARD_STLAB_PCI_TV7130         175
>
> #define SAA7134_MAXBOARDS 32
> #define SAA7134_INPUT_MAX 8
>
> Signed-off-by: Michael Wellman <flinkdeldinky@gmail.com>

-- 
Jarod Wilson
jarod@wilsonet.com

[PATCH]

[Johannes Berg]

Subject: wext: remove seq_start/stop sparse annotations

Even though they are true, they cause sparse to complain
because it doesn't see the __acquires(dev_base_lock) on
dev_seq_start() because it is only added to the function
in net/core/dev.c, not the header file. To keep track of
the nesting correctly we should probably annotate those
functions publically, but for now let's just remove the
annotation I added to wext.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
I guess I should have actually run sparse... This could be part of the
wext locking fix "wext: fix get_wireless_stats locking" instead of being
standalone, if you're so inclined.

 net/wireless/wext.c |    2 --
 1 file changed, 2 deletions(-)

--- wireless-testing.orig/net/wireless/wext.c	2009-05-12 08:12:23.000000000 +0200
+++ wireless-testing/net/wireless/wext.c	2009-05-12 08:13:16.000000000 +0200
@@ -650,14 +650,12 @@ static int wireless_seq_show(struct seq_
 }
 
 static void *wireless_dev_seq_start(struct seq_file *seq, loff_t *pos)
-	__acquires(dev_base_lock)
 {
 	rtnl_lock();
 	return dev_seq_start(seq, pos);
 }
 
 static void wireless_dev_seq_stop(struct seq_file *seq, void *v)
-	__releases(dev_base_lock)
 {
 	dev_seq_stop(seq, v);
 	rtnl_unlock();

[PATCH]

[Christoph Hellwig]

It's used by DM and MD and generally useful, so move the bio list
helpers into bio.h.


Signed-off-by: Christoph Hellwig <hch@lst.de>

Index: linux-2.6/drivers/md/dm-bio-list.h
===================================================================
--- linux-2.6.orig/drivers/md/dm-bio-list.h	2009-04-05 13:10:25.427445349 +0200
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,117 +0,0 @@
-/*
- * Copyright (C) 2004 Red Hat UK Ltd.
- *
- * This file is released under the GPL.
- */
-
-#ifndef DM_BIO_LIST_H
-#define DM_BIO_LIST_H
-
-#include <linux/bio.h>
-
-#ifdef CONFIG_BLOCK
-
-struct bio_list {
-	struct bio *head;
-	struct bio *tail;
-};
-
-static inline int bio_list_empty(const struct bio_list *bl)
-{
-	return bl->head == NULL;
-}
-
-static inline void bio_list_init(struct bio_list *bl)
-{
-	bl->head = bl->tail = NULL;
-}
-
-#define bio_list_for_each(bio, bl) \
-	for (bio = (bl)->head; bio; bio = bio->bi_next)
-
-static inline unsigned bio_list_size(const struct bio_list *bl)
-{
-	unsigned sz = 0;
-	struct bio *bio;
-
-	bio_list_for_each(bio, bl)
-		sz++;
-
-	return sz;
-}
-
-static inline void bio_list_add(struct bio_list *bl, struct bio *bio)
-{
-	bio->bi_next = NULL;
-
-	if (bl->tail)
-		bl->tail->bi_next = bio;
-	else
-		bl->head = bio;
-
-	bl->tail = bio;
-}
-
-static inline void bio_list_add_head(struct bio_list *bl, struct bio *bio)
-{
-	bio->bi_next = bl->head;
-
-	bl->head = bio;
-
-	if (!bl->tail)
-		bl->tail = bio;
-}
-
-static inline void bio_list_merge(struct bio_list *bl, struct bio_list *bl2)
-{
-	if (!bl2->head)
-		return;
-
-	if (bl->tail)
-		bl->tail->bi_next = bl2->head;
-	else
-		bl->head = bl2->head;
-
-	bl->tail = bl2->tail;
-}
-
-static inline void bio_list_merge_head(struct bio_list *bl,
-				       struct bio_list *bl2)
-{
-	if (!bl2->head)
-		return;
-
-	if (bl->head)
-		bl2->tail->bi_next = bl->head;
-	else
-		bl->tail = bl2->tail;
-
-	bl->head = bl2->head;
-}
-
-static inline struct bio *bio_list_pop(struct bio_list *bl)
-{
-	struct bio *bio = bl->head;
-
-	if (bio) {
-		bl->head = bl->head->bi_next;
-		if (!bl->head)
-			bl->tail = NULL;
-
-		bio->bi_next = NULL;
-	}
-
-	return bio;
-}
-
-static inline struct bio *bio_list_get(struct bio_list *bl)
-{
-	struct bio *bio = bl->head;
-
-	bl->head = bl->tail = NULL;
-
-	return bio;
-}
-
-#endif /* CONFIG_BLOCK */
-#endif
Index: linux-2.6/drivers/md/dm-delay.c
===================================================================
--- linux-2.6.orig/drivers/md/dm-delay.c	2009-04-05 13:13:29.222444720 +0200
+++ linux-2.6/drivers/md/dm-delay.c	2009-04-05 13:13:32.398573159 +0200
@@ -15,8 +15,6 @@
 
 #include <linux/device-mapper.h>
 
-#include "dm-bio-list.h"
-
 #define DM_MSG_PREFIX "delay"
 
 struct delay_c {
Index: linux-2.6/drivers/md/dm-mpath.c
===================================================================
--- linux-2.6.orig/drivers/md/dm-mpath.c	2009-04-05 13:13:29.242444961 +0200
+++ linux-2.6/drivers/md/dm-mpath.c	2009-04-05 13:13:57.017458602 +0200
@@ -8,7 +8,6 @@
 #include <linux/device-mapper.h>
 
 #include "dm-path-selector.h"
-#include "dm-bio-list.h"
 #include "dm-bio-record.h"
 #include "dm-uevent.h"
 
Index: linux-2.6/drivers/md/dm-raid1.c
===================================================================
--- linux-2.6.orig/drivers/md/dm-raid1.c	2009-04-05 13:13:29.255452134 +0200
+++ linux-2.6/drivers/md/dm-raid1.c	2009-04-05 13:13:38.802447942 +0200
@@ -5,7 +5,6 @@
  * This file is released under the GPL.
  */
 
-#include "dm-bio-list.h"
 #include "dm-bio-record.h"
 
 #include <linux/init.h>
Index: linux-2.6/drivers/md/dm-region-hash.c
===================================================================
--- linux-2.6.orig/drivers/md/dm-region-hash.c	2009-04-05 13:13:29.270445034 +0200
+++ linux-2.6/drivers/md/dm-region-hash.c	2009-04-05 13:13:41.473449954 +0200
@@ -14,7 +14,6 @@
 #include <linux/vmalloc.h>
 
 #include "dm.h"
-#include "dm-bio-list.h"
 
 #define	DM_MSG_PREFIX	"region hash"
 
Index: linux-2.6/drivers/md/dm-snap.c
===================================================================
--- linux-2.6.orig/drivers/md/dm-snap.c	2009-04-05 13:13:29.287445452 +0200
+++ linux-2.6/drivers/md/dm-snap.c	2009-04-05 13:13:43.704446877 +0200
@@ -22,7 +22,6 @@
 #include <linux/workqueue.h>
 
 #include "dm-exception-store.h"
-#include "dm-bio-list.h"
 
 #define DM_MSG_PREFIX "snapshots"
 
Index: linux-2.6/drivers/md/dm.c
===================================================================
--- linux-2.6.orig/drivers/md/dm.c	2009-04-05 13:13:29.300444453 +0200
+++ linux-2.6/drivers/md/dm.c	2009-04-05 13:13:45.999446772 +0200
@@ -6,7 +6,6 @@
  */
 
 #include "dm.h"
-#include "dm-bio-list.h"
 #include "dm-uevent.h"
 
 #include <linux/init.h>
Index: linux-2.6/drivers/md/raid1.c
===================================================================
--- linux-2.6.orig/drivers/md/raid1.c	2009-04-05 13:13:29.316444814 +0200
+++ linux-2.6/drivers/md/raid1.c	2009-04-05 13:13:49.188479487 +0200
@@ -35,7 +35,6 @@
 #include <linux/blkdev.h>
 #include <linux/seq_file.h>
 #include "md.h"
-#include "dm-bio-list.h"
 #include "raid1.h"
 #include "bitmap.h"
 
Index: linux-2.6/drivers/md/raid10.c
===================================================================
--- linux-2.6.orig/drivers/md/raid10.c	2009-04-05 13:13:29.332445594 +0200
+++ linux-2.6/drivers/md/raid10.c	2009-04-05 13:13:52.435605187 +0200
@@ -22,7 +22,6 @@
 #include <linux/blkdev.h>
 #include <linux/seq_file.h>
 #include "md.h"
-#include "dm-bio-list.h"
 #include "raid10.h"
 #include "bitmap.h"
 
Index: linux-2.6/include/linux/bio.h
===================================================================
--- linux-2.6.orig/include/linux/bio.h	2009-04-05 13:10:25.442444604 +0200
+++ linux-2.6/include/linux/bio.h	2009-04-05 13:12:47.685574569 +0200
@@ -501,6 +501,115 @@ static inline int bio_has_data(struct bi
 	return bio && bio->bi_io_vec != NULL;
 }
 
+/*
+ * BIO list managment for use by remapping drivers (e.g. DM or MD).
+ *
+ * A bio_list anchors a singly-linked list of bios chained through the bi_next
+ * member of the bio.  The bio_list also caches the last list member to allow
+ * fast access to the tail.
+ */
+struct bio_list {
+	struct bio *head;
+	struct bio *tail;
+};
+
+static inline int bio_list_empty(const struct bio_list *bl)
+{
+	return bl->head == NULL;
+}
+
+static inline void bio_list_init(struct bio_list *bl)
+{
+	bl->head = bl->tail = NULL;
+}
+
+#define bio_list_for_each(bio, bl) \
+	for (bio = (bl)->head; bio; bio = bio->bi_next)
+
+static inline unsigned bio_list_size(const struct bio_list *bl)
+{
+	unsigned sz = 0;
+	struct bio *bio;
+
+	bio_list_for_each(bio, bl)
+		sz++;
+
+	return sz;
+}
+
+static inline void bio_list_add(struct bio_list *bl, struct bio *bio)
+{
+	bio->bi_next = NULL;
+
+	if (bl->tail)
+		bl->tail->bi_next = bio;
+	else
+		bl->head = bio;
+
+	bl->tail = bio;
+}
+
+static inline void bio_list_add_head(struct bio_list *bl, struct bio *bio)
+{
+	bio->bi_next = bl->head;
+
+	bl->head = bio;
+
+	if (!bl->tail)
+		bl->tail = bio;
+}
+
+static inline void bio_list_merge(struct bio_list *bl, struct bio_list *bl2)
+{
+	if (!bl2->head)
+		return;
+
+	if (bl->tail)
+		bl->tail->bi_next = bl2->head;
+	else
+		bl->head = bl2->head;
+
+	bl->tail = bl2->tail;
+}
+
+static inline void bio_list_merge_head(struct bio_list *bl,
+				       struct bio_list *bl2)
+{
+	if (!bl2->head)
+		return;
+
+	if (bl->head)
+		bl2->tail->bi_next = bl->head;
+	else
+		bl->tail = bl2->tail;
+
+	bl->head = bl2->head;
+}
+
+static inline struct bio *bio_list_pop(struct bio_list *bl)
+{
+	struct bio *bio = bl->head;
+
+	if (bio) {
+		bl->head = bl->head->bi_next;
+		if (!bl->head)
+			bl->tail = NULL;
+
+		bio->bi_next = NULL;
+	}
+
+	return bio;
+}
+
+static inline struct bio *bio_list_get(struct bio_list *bl)
+{
+	struct bio *bio = bl->head;
+
+	bl->head = bl->tail = NULL;
+
+	return bio;
+}
+
 #if defined(CONFIG_BLK_DEV_INTEGRITY)
 
 #define bip_vec_idx(bip, idx)	(&(bip->bip_vec[(idx)]))

[PATCH]:

[Steve Dickson]

[As requested, here is the debugging portion broken out of
the 6th patch in the "Dynamic Pseudo Root" patch series.]

Added dprintk to the top and bottom of both expkey_parse() and
svc_export_parse(). The top dprintks shows what rpc.mountd gave
to the routines to parse. These match up well with the current
debugging statements in the rpc.mount routines nfsd_export()
and nfsd_fh(). 

The bottom two dprintks show when either routine error out. This
was very useful in debugging why exports failed or hang.

I also added a number dprintks to the sunrpc caching code. Being
there was exactly one debugging statement through out the entire
chuck of code, it was literally impossible to tell whats going
on. This dprintks will show if and when upcalls are made and
(more importantly) when they are not.

All of these dprintks are not very busy code paths. They only 
pop when an exported is created or modified.

Signed-off-by: Steve Dickson <steved@redhat.com>

diff -up linux/fs/nfsd/export.c.org linux/fs/nfsd/export.c
--- linux/fs/nfsd/export.c.org	2008-10-24 13:00:36.000000000 -0400
+++ linux/fs/nfsd/export.c	2008-10-24 12:59:46.000000000 -0400
@@ -104,6 +104,7 @@ static int expkey_parse(struct cache_det
 	if (mesg[mlen-1] != '\n')
 		return -EINVAL;
 	mesg[mlen-1] = 0;
+	dprintk("expkey_parse: '%s'\n", mesg);
 
 	buf = kmalloc(PAGE_SIZE, GFP_KERNEL);
 	err = -ENOMEM;
@@ -182,6 +183,8 @@ static int expkey_parse(struct cache_det
 	if (dom)
 		auth_domain_put(dom);
 	kfree(buf);
+	if (err)
+		dprintk("expkey_parse: err %d\n", err);
 	return err;
 }
 
@@ -353,6 +356,8 @@ static void svc_export_request(struct ca
 		return;
 	}
 	qword_add(bpp, blen, pth);
+	dprintk("svc_export_request: pth %s\n", pth);
+
 	(*bpp)[-1] = '\n';
 }
 
@@ -520,6 +525,7 @@ static int svc_export_parse(struct cache
 	if (mesg[mlen-1] != '\n')
 		return -EINVAL;
 	mesg[mlen-1] = 0;
+	dprintk("svc_export_parse: '%s'\n", mesg);
 
 	buf = kmalloc(PAGE_SIZE, GFP_KERNEL);
 	err = -ENOMEM;
@@ -632,6 +638,8 @@ static int svc_export_parse(struct cache
 	if (dom)
 		auth_domain_put(dom);
 	kfree(buf);
+	if (err)
+		dprintk("svc_export_parse: err %d\n", err);
 	return err;
 }
 
diff -up linux/net/sunrpc/cache.c.org linux/net/sunrpc/cache.c
--- linux/net/sunrpc/cache.c.org	2008-10-24 13:00:46.000000000 -0400
+++ linux/net/sunrpc/cache.c	2008-10-14 07:54:01.000000000 -0400
@@ -215,11 +215,13 @@ int cache_check(struct cache_detail *det
 		if (rv == -EAGAIN)
 			rv = -ENOENT;
 	} else if (rv == -EAGAIN || age > refresh_age/2) {
-		dprintk("RPC:       Want update, refage=%ld, age=%ld\n",
-				refresh_age, age);
+		dprintk("check_check: upcall: h 0x%p pending %d rv %d\n", 
+			h, test_bit(CACHE_PENDING, &h->flags), rv);
 		if (!test_and_set_bit(CACHE_PENDING, &h->flags)) {
 			switch (cache_make_upcall(detail, h)) {
 			case -EINVAL:
+				dprintk("check_check: upcall(-EINVAL): h 0x%p rv %d\n",
+					h, rv);
 				clear_bit(CACHE_PENDING, &h->flags);
 				if (rv == -EAGAIN) {
 					set_bit(CACHE_NEGATIVE, &h->flags);
@@ -231,6 +233,8 @@ int cache_check(struct cache_detail *det
 
 			case -EAGAIN:
 				clear_bit(CACHE_PENDING, &h->flags);
+				dprintk("check_check: upcall(-EAGAIN): h 0x%p flags 0x%lx\n",
+					h, h->flags);
 				cache_revisit_request(h);
 				break;
 			}
@@ -560,13 +564,16 @@ static int cache_defer_req(struct cache_
 		/* too much in the cache, randomly drop this one,
 		 * or continue and drop the oldest below
 		 */
-		if (net_random()&1)
+		if (net_random()&1) {
+			dprintk("cache_defer_req:  0x%p: dropping request\n", item);
 			return -ETIMEDOUT;
+		}
 	}
 	dreq = req->defer(req);
-	if (dreq == NULL)
+	if (dreq == NULL) {
+		dprintk("cache_defer_req: 0x%p: request timedout\n", item);
 		return -ETIMEDOUT;
-
+	}
 	dreq->item = item;
 
 	spin_lock(&cache_defer_lock);
@@ -596,6 +603,7 @@ static int cache_defer_req(struct cache_
 		/* must have just been validated... */
 		cache_revisit_request(item);
 	}
+	dprintk("cache_defer_req:  0x%p: request deferred\n", item);
 	return 0;
 }

Re: [PATCH]:

[J. Bruce Fields]

On Fri, Oct 24, 2008 at 01:31:57PM -0400, Steve Dickson wrote:
> [As requested, here is the debugging portion broken out of
> the 6th patch in the "Dynamic Pseudo Root" patch series.]
> 
> Added dprintk to the top and bottom of both expkey_parse() and
> svc_export_parse(). The top dprintks shows what rpc.mountd gave
> to the routines to parse. These match up well with the current
> debugging statements in the rpc.mount routines nfsd_export()
> and nfsd_fh(). 
>
> The bottom two dprintks show when either routine error out. This
> was very useful in debugging why exports failed or hang.


Did you try experiment with strace very much before trying this?
Something like

	strace -e read,write -s 1000 -p `pidof rpc.gssd`

will show the contents of the upcalls and downcalls and any returned
error, so I'm not convinced that dprintk's of the upcall/downcall data
are necessary.

> diff -up linux/net/sunrpc/cache.c.org linux/net/sunrpc/cache.c
> --- linux/net/sunrpc/cache.c.org	2008-10-24 13:00:46.000000000 -0400
> +++ linux/net/sunrpc/cache.c	2008-10-14 07:54:01.000000000 -0400
> @@ -215,11 +215,13 @@ int cache_check(struct cache_detail *det
>  		if (rv == -EAGAIN)
>  			rv = -ENOENT;
>  	} else if (rv == -EAGAIN || age > refresh_age/2) {
> -		dprintk("RPC:       Want update, refage=%ld, age=%ld\n",
> -				refresh_age, age);
> +		dprintk("check_check: upcall: h 0x%p pending %d rv %d\n", 
> +			h, test_bit(CACHE_PENDING, &h->flags), rv);

THis is actually changing the information printed instead of adding
more.  Are you sure this is what you want?

>  		if (!test_and_set_bit(CACHE_PENDING, &h->flags)) {
>  			switch (cache_make_upcall(detail, h)) {
>  			case -EINVAL:
> +				dprintk("check_check: upcall(-EINVAL): h 0x%p rv %d\n",
> +					h, rv);

>From a quick check of cache_make_upcall, -EINVAL is returned either when
cache_request is NULL (looks like that would be a bug?), or in the case
where nobody's listening on the given upcall channel, in which case
there's already a printk().

--b.

>  				clear_bit(CACHE_PENDING, &h->flags);
>  				if (rv == -EAGAIN) {
>  					set_bit(CACHE_NEGATIVE, &h->flags);
> @@ -231,6 +233,8 @@ int cache_check(struct cache_detail *det
>  
>  			case -EAGAIN:
>  				clear_bit(CACHE_PENDING, &h->flags);
> +				dprintk("check_check: upcall(-EAGAIN): h 0x%p flags 0x%lx\n",
> +					h, h->flags);
>  				cache_revisit_request(h);
>  				break;
>  			}
> @@ -560,13 +564,16 @@ static int cache_defer_req(struct cache_
>  		/* too much in the cache, randomly drop this one,
>  		 * or continue and drop the oldest below
>  		 */
> -		if (net_random()&1)
> +		if (net_random()&1) {
> +			dprintk("cache_defer_req:  0x%p: dropping request\n", item);
>  			return -ETIMEDOUT;
> +		}
>  	}
>  	dreq = req->defer(req);
> -	if (dreq == NULL)
> +	if (dreq == NULL) {
> +		dprintk("cache_defer_req: 0x%p: request timedout\n", item);
>  		return -ETIMEDOUT;
> -
> +	}
>  	dreq->item = item;
>  
>  	spin_lock(&cache_defer_lock);
> @@ -596,6 +603,7 @@ static int cache_defer_req(struct cache_
>  		/* must have just been validated... */
>  		cache_revisit_request(item);
>  	}
> +	dprintk("cache_defer_req:  0x%p: request deferred\n", item);
>  	return 0;
>  }
>  
> _______________________________________________
> NFSv4 mailing list
> NFSv4@linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

Re: [PATCH]:

[Steve Dickson]

J. Bruce Fields wrote:
> On Fri, Oct 24, 2008 at 01:31:57PM -0400, Steve Dickson wrote:
>> [As requested, here is the debugging portion broken out of
>> the 6th patch in the "Dynamic Pseudo Root" patch series.]
>>
>> Added dprintk to the top and bottom of both expkey_parse() and
>> svc_export_parse(). The top dprintks shows what rpc.mountd gave
>> to the routines to parse. These match up well with the current
>> debugging statements in the rpc.mount routines nfsd_export()
>> and nfsd_fh(). 
>>
>> The bottom two dprintks show when either routine error out. This
>> was very useful in debugging why exports failed or hang.
> 
> 
> Did you try experiment with strace very much before trying this?
> Something like
> 
> 	strace -e read,write -s 1000 -p `pidof rpc.gssd`
> 
> will show the contents of the upcalls and downcalls and any returned
> error, so I'm not convinced that dprintk's of the upcall/downcall data
> are necessary.
> 
No, I have not, but it does look interesting and I'll give it try. 

But I also think its important to have one united debugging interface
that gives meaningful information when its turned on. 

For example, today you turn on export debugging with
    rpcdebug -m nfsd -s export 

you get a couple of "found this", "path is that" message that are 
basically meaningless and you have no idea where they are coming from.

When you turn on the cache debugging via:
    rpcdebug -m nfsd -s cache

you get absolutely nothing, since there is exactly one dprintk() in all
that code that I could never get to pop... 

So with my proposed dprinks it makes those commands much more meaningful and
useful by adding straightforward debugging strings that identify where they
are in the kernel. They also tie in nicely with the syslog entries that currently 
come out of the mountd debugging. Also they are not in a high traffic area. Meaning
they only pop when during exports and mounts, unlike an I/O path...

Maybe I'm don't understand the current debugging philosophy, but if a couple
non-intrusive dprintk make the debugging commands a bit more useful, why
isn't that a good thing?

steved.

[PATCH]

[Tim Shimmin]

Hi Linus,

Please include the following patch for 2.6.27.1 stable release as
suggested by Christoph Hellwig and Eric Sandeen.
It fixes a regression in the recent remount recoding
where remounting say from ro to rw allows the xfs flags to
be out of sync with the vfs flags, resulting
in failures for some programs such as touch (which end up calling xfs_setattr).
The fix is a very minor and clear.

Thanks,
Tim.

Date: Sun, 12 Oct 2008 14:30:44 +0200
From: Christoph Hellwig <hch@lst.de>
To: xfs@oss.sgi.com
Subject: [PATCH] fix remount rw with unrecognized options

When we skip unrecognized options in xfs_fs_remount we should just break
out of the switch and not return because otherwise we may skip clearing
the xfs-internal read-only flag.  This will only show up on some
operations like touch because most read-only checks are done by the VFS
which thinks this filesystem is r/w.  Eventually we should replace the
XFS read-only flag with a helper that always checks the VFS flag to make
sure they can never get out of sync.

Bug reported and fix verified by Marcel Beister on #xfs.
Bug fix verified by updated xfstests/189.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Eric Sandeen <sandeen@sandeen.net>
Signed-off-by: Timothy Shimmin <tes@sgi.com>

Index: mainline/fs/xfs/linux-2.6/xfs_super.c
===================================================================
--- mainline.orig/fs/xfs/linux-2.6/xfs_super.c	2008-10-15 17:59:26.542652847 +1100
+++ mainline/fs/xfs/linux-2.6/xfs_super.c	2008-10-15 17:59:45.376217172 +1100
@@ -1323,7 +1323,7 @@ xfs_fs_remount(
 	"XFS: mount option \"%s\" not supported for remount\n", p);
 			return -EINVAL;
 #else
-			return 0;
+			break;
 #endif
 		}
 	}

Re: [PATCH]

[Eric Sandeen]

> Date: Wed, 15 Oct 2008 18:03:13 +1100
> To: options@melbourne.sgi.com, unrecognized@melbourne.sgi.com,
>         with@melbourne.sgi.com, rw@melbourne.sgi.com,
>         remount@melbourne.sgi.com, fix@melbourne.sgi.com,
>         XFS@melbourne.sgi.com


I don't think that made it to the right place ...  :)

(stable@vger.kernel.org)

-Eric

Tim Shimmin wrote:
> Hi Linus,
> 
> Please include the following patch for 2.6.27.1 stable release as
> suggested by Christoph Hellwig and Eric Sandeen.
> It fixes a regression in the recent remount recoding
> where remounting say from ro to rw allows the xfs flags to
> be out of sync with the vfs flags, resulting
> in failures for some programs such as touch (which end up calling xfs_setattr).
> The fix is a very minor and clear.
> 
> Thanks,
> Tim.
> 
> Date: Sun, 12 Oct 2008 14:30:44 +0200
> From: Christoph Hellwig <hch@lst.de>
> To: xfs@oss.sgi.com
> Subject: [PATCH] fix remount rw with unrecognized options
> 
> When we skip unrecognized options in xfs_fs_remount we should just break
> out of the switch and not return because otherwise we may skip clearing
> the xfs-internal read-only flag.  This will only show up on some
> operations like touch because most read-only checks are done by the VFS
> which thinks this filesystem is r/w.  Eventually we should replace the
> XFS read-only flag with a helper that always checks the VFS flag to make
> sure they can never get out of sync.
> 
> Bug reported and fix verified by Marcel Beister on #xfs.
> Bug fix verified by updated xfstests/189.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Acked-by: Eric Sandeen <sandeen@sandeen.net>
> Signed-off-by: Timothy Shimmin <tes@sgi.com>
> 
> Index: mainline/fs/xfs/linux-2.6/xfs_super.c
> ===================================================================
> --- mainline.orig/fs/xfs/linux-2.6/xfs_super.c	2008-10-15 17:59:26.542652847 +1100
> +++ mainline/fs/xfs/linux-2.6/xfs_super.c	2008-10-15 17:59:45.376217172 +1100
> @@ -1323,7 +1323,7 @@ xfs_fs_remount(
>  	"XFS: mount option \"%s\" not supported for remount\n", p);
>  			return -EINVAL;
>  #else
> -			return 0;
> +			break;
>  #endif
>  		}
>  	}
> 
> 

[PATCH]

[Junio C Hamano]

f2eba66 (Enable HEAD@{...} and make it independent from the current
branch, 2007-02-03) introduced dwim_log() to handle <refname>@{...}
syntax, and as part of its processing, it checks if the ref exists by
calling refsolve_ref().  It should call it as a reader to make sure the
call returns NULL for a nonexistent ref (not as a potential writer in
which case it does not return NULL).

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 * I found this purely by accident.  "echo >.git/logs/refs/heads/HEAD"
   would make your "git rev-parse HEAD@{1}" complain about a refname
   'HEAD' being ambiguous without this patch.

 sha1_name.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/sha1_name.c b/sha1_name.c
index b0b2167..4fb77f8 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -273,7 +273,7 @@ int dwim_log(const char *str, int len, unsigned char *sha1, char **log)
 		const char *ref, *it;
 
 		strcpy(path, mkpath(*p, len, str));
-		ref = resolve_ref(path, hash, 0, NULL);
+		ref = resolve_ref(path, hash, 1, NULL);
 		if (!ref)
 			continue;
 		if (!stat(git_path("logs/%s", path), &st) &&

[PATCH]

[Christoph Hellwig]

As reported by Michael-John Turner XFS updates the mtime on the source
inode of a rename call in case it's a directory and changes the parent.

This doesn't make any sense, is not mentioned in the standards and not
performed by any other Linux filesystems so remove it.


(resending this as it might have been lost in the previous thread)


Signed-off-by: Christoph Hellwig <hch@lst.de>

Index: linux-2.6-xfs/fs/xfs/xfs_rename.c
===================================================================
--- linux-2.6-xfs.orig/fs/xfs/xfs_rename.c	2008-06-18 18:24:38.000000000 +0200
+++ linux-2.6-xfs/fs/xfs/xfs_rename.c	2008-06-18 18:30:17.000000000 +0200
@@ -336,22 +336,18 @@ xfs_rename(
 		ASSERT(error != EEXIST);
 		if (error)
 			goto abort_return;
-		xfs_ichgtime(src_ip, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG);
-
-	} else {
-		/*
-		 * We always want to hit the ctime on the source inode.
-		 * We do it in the if clause above for the 'new_parent &&
-		 * src_is_directory' case, and here we get all the other
-		 * cases.  This isn't strictly required by the standards
-		 * since the source inode isn't really being changed,
-		 * but old unix file systems did it and some incremental
-		 * backup programs won't work without it.
-		 */
-		xfs_ichgtime(src_ip, XFS_ICHGTIME_CHG);
 	}
 
 	/*
+	 * We always want to hit the ctime on the source inode.
+	 *
+	 * This isn't strictly required by the standards since the source
+	 * inode isn't really being changed, but old unix file systems did
+	 * it and some incremental backup programs won't work without it.
+	 */
+	xfs_ichgtime(src_ip, XFS_ICHGTIME_CHG);
+
+	/*
 	 * Adjust the link count on src_dp.  This is necessary when
 	 * renaming a directory, either within one parent when
 	 * the target existed, or across two parent directories.

[PATCH]

[Johannes Berg]

In commit 31ccc476b77234f6afb3 (mac80211: QoS related cleanups) I
accidentally changed a variable from int to u16 causing a warning
that a comparison for < 0 was always false. John thought this was
a missing deletion of code and removed the warning by deleting the
never executed branch of code in commit 13e5f0888caddf7a020dcd918
(wireless: fix warning introduced by "mac80211: QoS related cleanups")
but the problem really was my mistake of using a u16 variable for
the queue variable when that variable can also contain an error
code. This patch restores the original code and variable type.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
 net/mac80211/wme.c |   26 +++++++++++++++-----------
 1 file changed, 15 insertions(+), 11 deletions(-)

--- everything.orig/net/mac80211/wme.c	2008-05-03 00:29:07.000000000 +0200
+++ everything/net/mac80211/wme.c	2008-05-03 00:32:01.000000000 +0200
@@ -155,8 +155,7 @@ static int wme_qdiscop_enqueue(struct sk
 	unsigned short fc = le16_to_cpu(hdr->frame_control);
 	struct Qdisc *qdisc;
 	struct sta_info *sta;
-	int err;
-	u16 queue;
+	int err, queue;
 	u8 tid;
 
 	if (pkt_data->flags & IEEE80211_TXPD_REQUEUE) {
@@ -216,15 +215,20 @@ static int wme_qdiscop_enqueue(struct sk
 		rcu_read_unlock();
 	}
 
-	tid = skb->priority & QOS_CONTROL_TAG1D_MASK;
-	pkt_data->queue = (unsigned int) queue;
-	qdisc = q->queues[queue];
-	err = qdisc->enqueue(skb, qdisc);
-	if (err == NET_XMIT_SUCCESS) {
-		qd->q.qlen++;
-		qd->bstats.bytes += skb->len;
-		qd->bstats.packets++;
-		return NET_XMIT_SUCCESS;
+	if (unlikely(queue < 0)) {
+			kfree_skb(skb);
+			err = NET_XMIT_DROP;
+	} else {
+		tid = skb->priority & QOS_CONTROL_TAG1D_MASK;
+		pkt_data->queue = (unsigned int) queue;
+		qdisc = q->queues[queue];
+		err = qdisc->enqueue(skb, qdisc);
+		if (err == NET_XMIT_SUCCESS) {
+			qd->q.qlen++;
+			qd->bstats.bytes += skb->len;
+			qd->bstats.packets++;
+			return NET_XMIT_SUCCESS;
+		}
 	}
 	qd->qstats.drops++;
 	return err;

[PATCH]

[Johannes Berg]

The ieee80211_ioctl_giwrate() ioctl handler doesn't rcu_read_lock()
its access to the sta table, fix it.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
 net/mac80211/ieee80211_ioctl.c |   18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

--- everything.orig/net/mac80211/ieee80211_ioctl.c	2008-04-04 17:48:11.000000000 +0200
+++ everything/net/mac80211/ieee80211_ioctl.c	2008-04-04 17:48:56.000000000 +0200
@@ -586,19 +586,25 @@ static int ieee80211_ioctl_giwrate(struc
 
 	sdata = IEEE80211_DEV_TO_SUB_IF(dev);
 
-	if (sdata->vif.type == IEEE80211_IF_TYPE_STA)
-		sta = sta_info_get(local, sdata->u.sta.bssid);
-	else
+	if (sdata->vif.type != IEEE80211_IF_TYPE_STA)
 		return -EOPNOTSUPP;
-	if (!sta)
-		return -ENODEV;
 
 	sband = local->hw.wiphy->bands[local->hw.conf.channel->band];
 
-	if (sta->txrate_idx < sband->n_bitrates)
+	rcu_read_lock();
+
+	sta = sta_info_get(local, sdata->u.sta.bssid);
+
+	if (sta && sta->txrate_idx < sband->n_bitrates)
 		rate->value = sband->bitrates[sta->txrate_idx].bitrate;
 	else
 		rate->value = 0;
+
+	rcu_read_unlock();
+
+	if (!sta)
+		return -ENODEV;
+
 	rate->value *= 100000;
 
 	return 0;

[PATCH]

[S.Çağlar Onur]

Hi;

This patch (rediffed againg kvm-60) from Tavis Ormandy <taviso@google.com> fixes an infinite
loop in the emulated SB16 device (See http://taviso.decsystem.org/virtsec.pdf for more details.)

I'm not sure why qemu upstream not merged these but Xen already did.

[1] http://xenbits.xensource.com/xen-3.1-testing.hg?rev/4b22d472bda6

diff -ur kvm-60.orig/qemu/hw/sb16.c kvm-60/qemu/hw/sb16.c
--- kvm-60.orig/qemu/hw/sb16.c	2008-01-20 14:35:04.000000000 +0200
+++ kvm-60/qemu/hw/sb16.c	2008-01-29 01:46:20.000000000 +0200
@@ -1240,8 +1240,10 @@
             s->block_size);
 #endif
 
-    while (s->left_till_irq <= 0) {
-        s->left_till_irq = s->block_size + s->left_till_irq;
+    if (s->block_size) {
+        while (s->left_till_irq <= 0) {
+            s->left_till_irq = s->block_size + s->left_till_irq;
+        }
     }
 
     return dma_pos;

Cheers
-- 
S.Çağlar Onur <caglar@pardus.org.tr>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [PATCH]

[Izik Eidus]

S.Çağlar Onur wrote:
> Hi;
>
> This patch (rediffed againg kvm-60) from Tavis Ormandy <taviso@google.com> fixes an infinite
> loop in the emulated SB16 device (See http://taviso.decsystem.org/virtsec.pdf for more details.)
>
> I'm not sure why qemu upstream not merged these but Xen already did.
>
> [1] http://xenbits.xensource.com/xen-3.1-testing.hg?rev/4b22d472bda6
>
> diff -ur kvm-60.orig/qemu/hw/sb16.c kvm-60/qemu/hw/sb16.c
> --- kvm-60.orig/qemu/hw/sb16.c	2008-01-20 14:35:04.000000000 +0200
> +++ kvm-60/qemu/hw/sb16.c	2008-01-29 01:46:20.000000000 +0200
> @@ -1240,8 +1240,10 @@
>              s->block_size);
>  #endif
>  
> -    while (s->left_till_irq <= 0) {
> -        s->left_till_irq = s->block_size + s->left_till_irq;
> +    if (s->block_size) {
> +        while (s->left_till_irq <= 0) {
> +            s->left_till_irq = s->block_size + s->left_till_irq;
> +        }
>      }
>  
>      return dma_pos;
>
> Cheers
>   
we better wait for qemu to merge it and then when we will merge with 
qemu cvs we will have it

thanks

-- 
woof.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [PATCH]

[S.Çağlar Onur]

[-- Attachment #1.1: Type: text/plain, Size: 653 bytes --]

Hi;

29 Oca 2008 Sal tarihinde, Izik Eidus şunları yazmıştı: 
> we better wait for qemu to merge it and then when we will merge with 
> qemu cvs we will have it

OK fair enough, seems they submitted to qemu-devel yesterday by Aurelien Jarno [1] [2], although xen merged these 3 months ago :(

[1] http://lists.gnu.org/archive/html/qemu-devel/2008-01/msg00704.html
[2] http://lists.gnu.org/archive/html/qemu-devel/2008-01/msg00705.html

Cheers
-- 
S.Çağlar Onur <caglar-caicS1wCkhO6A22drWdTBw@public.gmane.org>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[PATCH]

[Jiang zhe]

Hi,

For codec conexant 5045, I found that the name of "Capture Source Items"
is different from the name of mixer.

The mixer is:
HDA_CODEC_VOLUME("Ext Mic Playback Volume", 0x17, 0x2, HDA_INPUT),
HDA_CODEC_MUTE("Ext Mic Playback Switch", 0x17, 0x2, HDA_INPUT),

But the capture source item is :
static struct hda_input_mux cxt5045_capture_source = {
	.num_items = 2,
	.items = {
		{ "IntMic", 0x1 },
		{ "LineIn", 0x2 },
	}
};

I think that it's better to change the name of capture_source to avoid
misunderstanding.

Best regards!

Signed-off-by: Jiang zhe <zhe.jiang@intel.com>
--- alsa-driver-hg20080115/alsa-kernel/pci/hda/patch_conexant.c
2008-01-09 09:00:15.000000000 +0800
+++ b/alsa-kernel/pci/hda/patch_conexant.c	2008-01-17 10:50:06.000000000
+0800
@@ -453,7 +453,7 @@ static struct hda_input_mux cxt5045_capt
 	.num_items = 2,
 	.items = {
 		{ "IntMic", 0x1 },
-		{ "LineIn", 0x2 },
+		{ "ExtMic", 0x2 },
 	}
 };

Re: [PATCH]

[Takashi Iwai]

At Thu, 17 Jan 2008 10:58:04 +0800,
Jiang zhe wrote:
> 
> Hi,
> 
> For codec conexant 5045, I found that the name of "Capture Source Items"
> is different from the name of mixer.
> 
> The mixer is:
> HDA_CODEC_VOLUME("Ext Mic Playback Volume", 0x17, 0x2, HDA_INPUT),
> HDA_CODEC_MUTE("Ext Mic Playback Switch", 0x17, 0x2, HDA_INPUT),
> 
> But the capture source item is :
> static struct hda_input_mux cxt5045_capture_source = {
> 	.num_items = 2,
> 	.items = {
> 		{ "IntMic", 0x1 },
> 		{ "LineIn", 0x2 },
> 	}
> };
> 
> I think that it's better to change the name of capture_source to avoid
> misunderstanding.
> 
> Best regards!
> 
> Signed-off-by: Jiang zhe <zhe.jiang@intel.com>

Applied this, too.  Thanks.


Takashi

[PATCH]

[Ben Guthro]

[-- Attachment #1.1: Type: text/plain, Size: 320 bytes --]

We feel this should be considered for 3.2 - apologies for the late submission.


Fix x86_emulate() handling of imul with immediate operands.

This fixes a repeatable crash in RHEL 4.2 ext2 filesystem during boot.

Signed-off-by: Gary Grebus <ggrebus@virtualiron.com>
Signed-off-by: Ben Guthro <bguthro@virtualiron.com>


[-- Attachment #1.2: Type: text/html, Size: 711 bytes --]

[-- Attachment #2: xen-emulate-imul.patch --]
[-- Type: text/x-patch, Size: 2238 bytes --]

diff -r c3f713613c42 xen/arch/x86/x86_emulate.c
--- a/xen/arch/x86/x86_emulate.c	Thu Jan 03 07:38:32 2008 -0500
+++ b/xen/arch/x86/x86_emulate.c	Thu Jan 03 07:38:32 2008 -0500
@@ -103,8 +103,8 @@ static uint8_t opcode_table[256] = {
     ImplicitOps, ImplicitOps, DstReg|SrcMem|ModRM, DstReg|SrcMem16|ModRM|Mov,
     0, 0, 0, 0,
     /* 0x68 - 0x6F */
-    ImplicitOps|Mov, DstMem|SrcImm|ModRM|Mov,
-    ImplicitOps|Mov, DstMem|SrcImmByte|ModRM|Mov,
+    ImplicitOps|Mov, DstReg|SrcImm|ModRM|Mov,
+    ImplicitOps|Mov, DstReg|SrcImmByte|ModRM|Mov,
     ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps,
     /* 0x70 - 0x77 */
     ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps,
@@ -1331,34 +1331,37 @@ x86_emulate(
 
     case 0x69: /* imul imm16/32 */
     case 0x6b: /* imul imm8 */ {
-        unsigned long reg = *(long *)decode_register(modrm_reg, &_regs, 0);
+        unsigned long src1;        /* ModR/M and imm are both source operands */
+	if (ea.type == OP_REG)
+            src1 = *ea.reg;
+        else if ( (rc = ops->read(ea.mem.seg, ea.mem.off,
+                                  &src1, op_bytes, ctxt)) )
+            goto done;
         _regs.eflags &= ~(EFLG_OF|EFLG_CF);
         switch ( dst.bytes )
         {
         case 2:
             dst.val = ((uint32_t)(int16_t)src.val *
-                       (uint32_t)(int16_t)reg);
+                       (uint32_t)(int16_t)src1);
             if ( (int16_t)dst.val != (uint32_t)dst.val )
                 _regs.eflags |= EFLG_OF|EFLG_CF;
             break;
 #ifdef __x86_64__
         case 4:
             dst.val = ((uint64_t)(int32_t)src.val *
-                       (uint64_t)(int32_t)reg);
+                       (uint64_t)(int32_t)src1);
             if ( (int32_t)dst.val != dst.val )
                 _regs.eflags |= EFLG_OF|EFLG_CF;
             break;
 #endif
         default: {
-            unsigned long m[2] = { src.val, reg };
+            unsigned long m[2] = { src.val, src1 };
             if ( imul_dbl(m) )
                 _regs.eflags |= EFLG_OF|EFLG_CF;
             dst.val = m[0];
             break;
         }
         }
-        dst.type = OP_REG;
-        dst.reg  = decode_register(modrm_reg, &_regs, 0);
         break;
     }
 

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

[PATCH]

[Andries E. Brouwer]

As it turns out, the kernel divides by EXT3_INODES_PER_GROUP(s)
when mounting an ext3 filesystem. If that number is zero,
a crash follows. Below a patch.

This crash was reported by Joeri de Ruiter, Carst Tankink and Pim Vullers.

Andries

diff -uprN -X /linux/dontdiff a/fs/ext3/super.c b/fs/ext3/super.c
--- a/fs/ext3/super.c	2007-10-13 19:51:45.000000000 +0200
+++ b/fs/ext3/super.c	2007-12-03 16:00:36.802510904 +0100
@@ -1596,7 +1596,7 @@ static int ext3_fill_super (struct super
 	sbi->s_blocks_per_group = le32_to_cpu(es->s_blocks_per_group);
 	sbi->s_frags_per_group = le32_to_cpu(es->s_frags_per_group);
 	sbi->s_inodes_per_group = le32_to_cpu(es->s_inodes_per_group);
-	if (EXT3_INODE_SIZE(sb) == 0)
+	if (EXT3_INODE_SIZE(sb) == 0 || EXT3_INODES_PER_GROUP(sb) == 0)
 		goto cantfind_ext3;
 	sbi->s_inodes_per_block = blocksize / EXT3_INODE_SIZE(sb);
 	if (sbi->s_inodes_per_block == 0)
diff -uprN -X /linux/dontdiff a/fs/ext4/super.c b/fs/ext4/super.c
--- a/fs/ext4/super.c	2007-10-13 19:51:45.000000000 +0200
+++ b/fs/ext4/super.c	2007-12-03 16:05:14.722260680 +0100
@@ -1678,7 +1678,7 @@ static int ext4_fill_super (struct super
 	sbi->s_blocks_per_group = le32_to_cpu(es->s_blocks_per_group);
 	sbi->s_frags_per_group = le32_to_cpu(es->s_frags_per_group);
 	sbi->s_inodes_per_group = le32_to_cpu(es->s_inodes_per_group);
-	if (EXT4_INODE_SIZE(sb) == 0)
+	if (EXT4_INODE_SIZE(sb) == 0 || EXT4_INODES_PER_GROUP(sb) == 0)
 		goto cantfind_ext4;
 	sbi->s_inodes_per_block = blocksize / EXT4_INODE_SIZE(sb);
 	if (sbi->s_inodes_per_block == 0)

Re: [PATCH]

[Alan Cox]

On Mon, 3 Dec 2007 16:54:55 +0100
"Andries E. Brouwer" <Andries.Brouwer@cwi.nl> wrote:

> As it turns out, the kernel divides by EXT3_INODES_PER_GROUP(s)
> when mounting an ext3 filesystem. If that number is zero,
> a crash follows. Below a patch.
> 
> This crash was reported by Joeri de Ruiter, Carst Tankink and Pim Vullers.

Acked-by: Alan Cox <alan@redhat.com>

[PATCH]

[Roel Kluin]

I have sent this patch before to lkml, but it appears it wasn't picked up. Also
I have to admit this isn't tested. This is a patch against linus' tree.

ACPI_MADT_ENABLED is defined 1    (include/acpi/actbl1.h 501)
lapic_flags: an u32 of struct acpi_madt_local_sapic (include/acpi/actbl1.h 467)
--
'!' has a higher priority than '&', so as was
this won't test the first bit, but rather evaluates to false for any non-zero
lsapic->lapic_flags.

Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
index 3d45d24..7d78d22 100644
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -858,7 +858,7 @@ int acpi_map_lsapic(acpi_handle handle, int *pcpu)
 	lsapic = (struct acpi_madt_local_sapic *)obj->buffer.pointer;
 
 	if ((lsapic->header.type != ACPI_MADT_TYPE_LOCAL_SAPIC) ||
-	    (!lsapic->lapic_flags & ACPI_MADT_ENABLED)) {
+	    (!(lsapic->lapic_flags & ACPI_MADT_ENABLED))) {
 		kfree(buffer.pointer);
 		return -EINVAL;
 	}

[PATCH]

[Roel Kluin]

I have sent this patch before to lkml, but it appears it wasn't picked up. Also
I have to admit this isn't tested. This is a patch against linus' tree.

ACPI_MADT_ENABLED is defined 1    (include/acpi/actbl1.h 501)
lapic_flags: an u32 of struct acpi_madt_local_sapic (include/acpi/actbl1.h 467)
--
'!' has a higher priority than '&', so as was
this won't test the first bit, but rather evaluates to false for any non-zero
lsapic->lapic_flags.

Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
index 3d45d24..7d78d22 100644
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -858,7 +858,7 @@ int acpi_map_lsapic(acpi_handle handle, int *pcpu)
 	lsapic = (struct acpi_madt_local_sapic *)obj->buffer.pointer;
 
 	if ((lsapic->header.type != ACPI_MADT_TYPE_LOCAL_SAPIC) ||
-	    (!lsapic->lapic_flags & ACPI_MADT_ENABLED)) {
+	    (!(lsapic->lapic_flags & ACPI_MADT_ENABLED))) {
 		kfree(buffer.pointer);
 		return -EINVAL;
 	}

[PATCH]

[Doug Merrill]

[-- Attachment #1: Type: text/plain, Size: 184 bytes --]

This patch adds some error message info to indicate why a live migration might fail.

Signed-off-by: Doug Merrill <dpmerrill@novell.com>

Please apply to Xen-unstable







[-- Attachment #2: libxc_errmsg_01.diff --]
[-- Type: application/octet-stream, Size: 1713 bytes --]

diff -r a00cc97b392a tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Wed Sep 12 09:43:33 2007 +0100
+++ b/tools/libxc/xc_domain_save.c	Fri Sep 14 10:58:46 2007 -0600
@@ -789,7 +789,7 @@ int xc_domain_save(int xc_handle, int io
 {
     xc_dominfo_t info;
 
-    int rc = 1, i, j, last_iter, iter = 0;
+    int rc = 1, frc, i, j, last_iter, iter = 0;
     int live  = (flags & XCFLAGS_LIVE);
     int debug = (flags & XCFLAGS_DEBUG);
     int race = 0, sent_last_iter, skip_this_iter;
@@ -882,13 +882,18 @@ int xc_domain_save(int xc_handle, int io
         {
             /* log-dirty already enabled? There's no test op,
                so attempt to disable then reenable it */
-            if ( !(xc_shadow_control(xc_handle, dom, XEN_DOMCTL_SHADOW_OP_OFF,
-                                     NULL, 0, NULL, 0, NULL) >= 0 &&
-                   xc_shadow_control(xc_handle, dom,
-                                     XEN_DOMCTL_SHADOW_OP_ENABLE_LOGDIRTY,
-                                     NULL, 0, NULL, 0, NULL) >= 0) )
-            {
-                ERROR("Couldn't enable shadow mode");
+            frc = xc_shadow_control(xc_handle, dom, XEN_DOMCTL_SHADOW_OP_OFF,
+                                    NULL, 0, NULL, 0, NULL);
+            if ( frc >= 0 )
+            {
+                frc = xc_shadow_control(xc_handle, dom,
+                                        XEN_DOMCTL_SHADOW_OP_ENABLE_LOGDIRTY,
+                                        NULL, 0, NULL, 0, NULL);
+            }
+            
+            if ( frc < 0 )
+            {
+                ERROR("Couldn't enable shadow mode (rc %d) (errno %d)", frc, errno );
                 goto out;
             }
         }

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

[PATCH]

[Alan Cox]

Correct handling of SRST reset sequences. After an SRST it is undefined
whether the drive has gone back to PIO0. In order to talk safely we should
talk slowly and carefully until we know.

Thus when we do the reset if the controller has a pio setup method we call
it to flip back to PIO 0 and a known state. After the reset completes the
identify will then be done at the safe speed and the drive/controller will
pick suitable faster modes and reconfigure the controller to these timings.

As a side effect it means we force the controller to PIO 0 as we bring it
up which fixes funnies on a few systems where the BIOS firmware leaves us
in an interesting choice of modes, or embedded boxes with no firmware which
come up in random states.

For smart controllers there is nothing to do - they know about this internally.

Signed-off-by: Alan Cox <alan@redhat.com>


diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.23rc3-mm1/drivers/ata/libata-core.c linux-2.6.23rc3-mm1/drivers/ata/libata-core.c
--- linux.vanilla-2.6.23rc3-mm1/drivers/ata/libata-core.c	2007-08-22 17:23:00.000000000 +0100
+++ linux-2.6.23rc3-mm1/drivers/ata/libata-core.c	2007-08-22 18:17:31.321738376 +0100
@@ -3163,6 +3191,8 @@
 			     unsigned long deadline)
 {
 	struct ata_ioports *ioaddr = &ap->ioaddr;
+	struct ata_device *dev;
+	int i = 0;
 
 	DPRINTK("ata%u: bus reset via SRST\n", ap->print_id);
 
@@ -3173,6 +3203,25 @@
 	udelay(20);	/* FIXME: flush */
 	iowrite8(ap->ctl, ioaddr->ctl_addr);
 
+	/* If we issued an SRST then an ATA drive (not ATAPI)
+	 * may have changed configuration and be in PIO0 timing. If
+	 * we did a hard reset (or are coming from power on) this is
+	 * true for ATA or ATAPI. Until we've set a suitable controller
+	 * mode we should not touch the bus as we may be talking too fast.
+	 */
+
+	ata_link_for_each_dev(dev, &ap->link)
+		dev->pio_mode = XFER_PIO_0;
+
+	/* If the controller has a pio mode setup function then use
+	   it to set the chipset to rights. Don't touch the DMA setup
+	   as that will be dealt with when revalidating */
+	if (ap->ops->set_piomode) {
+		ata_link_for_each_dev(dev, &ap->link)
+			if (devmask & (1 << i++))
+				ap->ops->set_piomode(ap, dev);
+	}
+
 	/* wait a while before checking status */
 	ata_wait_after_reset(ap, deadline);
 

Re: [PATCH]

[Jeff Garzik]

Alan Cox wrote:
> Correct handling of SRST reset sequences. After an SRST it is undefined
> whether the drive has gone back to PIO0. In order to talk safely we should
> talk slowly and carefully until we know.
> 
> Thus when we do the reset if the controller has a pio setup method we call
> it to flip back to PIO 0 and a known state. After the reset completes the
> identify will then be done at the safe speed and the drive/controller will
> pick suitable faster modes and reconfigure the controller to these timings.
> 
> As a side effect it means we force the controller to PIO 0 as we bring it
> up which fixes funnies on a few systems where the BIOS firmware leaves us
> in an interesting choice of modes, or embedded boxes with no firmware which
> come up in random states.
> 
> For smart controllers there is nothing to do - they know about this internally.
> 
> Signed-off-by: Alan Cox <alan@redhat.com>
> 
> 
> diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.23rc3-mm1/drivers/ata/libata-core.c linux-2.6.23rc3-mm1/drivers/ata/libata-core.c
> --- linux.vanilla-2.6.23rc3-mm1/drivers/ata/libata-core.c	2007-08-22 17:23:00.000000000 +0100
> +++ linux-2.6.23rc3-mm1/drivers/ata/libata-core.c	2007-08-22 18:17:31.321738376 +0100
> @@ -3163,6 +3191,8 @@
>  			     unsigned long deadline)
>  {
>  	struct ata_ioports *ioaddr = &ap->ioaddr;
> +	struct ata_device *dev;
> +	int i = 0;
>  
>  	DPRINTK("ata%u: bus reset via SRST\n", ap->print_id);
>  
> @@ -3173,6 +3203,25 @@
>  	udelay(20);	/* FIXME: flush */
>  	iowrite8(ap->ctl, ioaddr->ctl_addr);
>  
> +	/* If we issued an SRST then an ATA drive (not ATAPI)
> +	 * may have changed configuration and be in PIO0 timing. If
> +	 * we did a hard reset (or are coming from power on) this is
> +	 * true for ATA or ATAPI. Until we've set a suitable controller
> +	 * mode we should not touch the bus as we may be talking too fast.
> +	 */
> +
> +	ata_link_for_each_dev(dev, &ap->link)
> +		dev->pio_mode = XFER_PIO_0;
> +
> +	/* If the controller has a pio mode setup function then use
> +	   it to set the chipset to rights. Don't touch the DMA setup
> +	   as that will be dealt with when revalidating */
> +	if (ap->ops->set_piomode) {
> +		ata_link_for_each_dev(dev, &ap->link)
> +			if (devmask & (1 << i++))
> +				ap->ops->set_piomode(ap, dev);
> +	}
> +

Should this be queued for 2.6.24?

The note I have on this is "low priority, make sure it gets testing in 
-mm first"

Re: [PATCH]

[Alan Cox]

> Should this be queued for 2.6.24?
> 
> The note I have on this is "low priority, make sure it gets testing in 
> -mm first"


Its been tested without any reports. There are two things it sorts out

#1 non x86 systems with firmware that doesn't init the chip into PIO0
(not many as most chips power up in pio0)

#2 A few obscure cases where we error and then can't recover an ATA drive
as we are talking PIO4 at it and its in PIO0 so we are burbling too fast
(the other way around is of course ok)

Alan

Re: [PATCH]

[Jeff Garzik]

Alan Cox wrote:
> Correct handling of SRST reset sequences. After an SRST it is undefined
> whether the drive has gone back to PIO0. In order to talk safely we should
> talk slowly and carefully until we know.
> 
> Thus when we do the reset if the controller has a pio setup method we call
> it to flip back to PIO 0 and a known state. After the reset completes the
> identify will then be done at the safe speed and the drive/controller will
> pick suitable faster modes and reconfigure the controller to these timings.
> 
> As a side effect it means we force the controller to PIO 0 as we bring it
> up which fixes funnies on a few systems where the BIOS firmware leaves us
> in an interesting choice of modes, or embedded boxes with no firmware which
> come up in random states.
> 
> For smart controllers there is nothing to do - they know about this internally.
> 
> Signed-off-by: Alan Cox <alan@redhat.com>
> 
> 
> diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.23rc3-mm1/drivers/ata/libata-core.c linux-2.6.23rc3-mm1/drivers/ata/libata-core.c
> --- linux.vanilla-2.6.23rc3-mm1/drivers/ata/libata-core.c	2007-08-22 17:23:00.000000000 +0100
> +++ linux-2.6.23rc3-mm1/drivers/ata/libata-core.c	2007-08-22 18:17:31.321738376 +0100
> @@ -3163,6 +3191,8 @@
>  			     unsigned long deadline)
>  {
>  	struct ata_ioports *ioaddr = &ap->ioaddr;
> +	struct ata_device *dev;
> +	int i = 0;
>  
>  	DPRINTK("ata%u: bus reset via SRST\n", ap->print_id);
>  
> @@ -3173,6 +3203,25 @@
>  	udelay(20);	/* FIXME: flush */
>  	iowrite8(ap->ctl, ioaddr->ctl_addr);
>  
> +	/* If we issued an SRST then an ATA drive (not ATAPI)
> +	 * may have changed configuration and be in PIO0 timing. If
> +	 * we did a hard reset (or are coming from power on) this is
> +	 * true for ATA or ATAPI. Until we've set a suitable controller
> +	 * mode we should not touch the bus as we may be talking too fast.
> +	 */
> +
> +	ata_link_for_each_dev(dev, &ap->link)
> +		dev->pio_mode = XFER_PIO_0;
> +
> +	/* If the controller has a pio mode setup function then use
> +	   it to set the chipset to rights. Don't touch the DMA setup
> +	   as that will be dealt with when revalidating */
> +	if (ap->ops->set_piomode) {
> +		ata_link_for_each_dev(dev, &ap->link)
> +			if (devmask & (1 << i++))
> +				ap->ops->set_piomode(ap, dev);
> +	}
> +
>  	/* wait a while before checking status */
>  	ata_wait_after_reset(ap, deadline);

ACK.  Requesting a patch that applies to libata-dev.git#upstream.

[PATCH 0/16] Assorted patches

[Jan Engelhardt]

Hello list,


People collect stamps, etc. and I do patches. It is April 01, but let ye 
know that even the patch that would get the most naks is not really 
meant as an April joke.
Most of them are independent, but I'll let `quilt graph` judge their 
dependencies.

	[01/] vt-sysfs-for-colors.diff
	[02/] vt-pure-colors.diff
	[03/] vt-underline-color.diff
	[04/] vt-printk-color.diff
	[05/] fix-kthread-niceness.diff
	[06/] isofs-add-write-bit.diff
	[07/] kconfig-dynamic-frequency.diff
	[08/] console-printk-level.diff
	[09/] zlib-decompression-status.diff
	[10/] show-partitions-on-mount-error.diff
	[11/] samba-eintr-fix.diff
	[12/] cifs-use-mutex.diff
	[13/] show-pipesize-in-stat.diff
	[14/] kconfig-allow-override.diff
	[15/] use-regular-eth-suffix.diff
	[16/] warn-on-kthread-name-truncation.diff

(`quilt graph` says the order of the vt-* ones is important.)


Jan
-- 

[PATCH 07/16] kconfig-dynamic-frequency.diff

[Jan Engelhardt]

Make HZ fully configurable through menuconfig.

Already posted at http://lkml.org/lkml/2006/6/18/111

Signed-off-by: Jan Engelhardt
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> (http://lkml.org/lkml/2006/11/8/307)
Cc: Sam Ravnborg <sam@ravnborg.org>

 Kconfig.hz |   70 +++++++++++++++++++++++--------------------------------------
 1 file changed, 27 insertions(+), 43 deletions(-)

Index: linux-2.6.21-rc5/kernel/Kconfig.hz
===================================================================
--- linux-2.6.21-rc5.orig/kernel/Kconfig.hz
+++ linux-2.6.21-rc5/kernel/Kconfig.hz
@@ -2,50 +2,34 @@
 # Timer Interrupt Frequency Configuration
 #
 
-choice
-	prompt "Timer frequency"
-	default HZ_250
-	help
-	 Allows the configuration of the timer frequency. It is customary
-	 to have the timer interrupt run at 1000 Hz but 100 Hz may be more
-	 beneficial for servers and NUMA systems that do not need to have
-	 a fast response for user interaction and that may experience bus
-	 contention and cacheline bounces as a result of timer interrupts.
-	 Note that the timer interrupt occurs on each processor in an SMP
-	 environment leading to NR_CPUS * HZ number of timer interrupts
-	 per second.
-
-
-	config HZ_100
-		bool "100 HZ"
-	help
-	  100 Hz is a typical choice for servers, SMP and NUMA systems
-	  with lots of processors that may show reduced performance if
-	  too many timer interrupts are occurring.
-
-	config HZ_250
-		bool "250 HZ"
-	help
-	 250 Hz is a good compromise choice allowing server performance
-	 while also showing good interactive responsiveness even
-	 on SMP and NUMA systems. If you are going to be using NTSC video
-	 or multimedia, selected 300Hz instead.
-
-	config HZ_300
-		bool "300 HZ"
-	help
-	 300 Hz is a good compromise choice allowing server performance
-	 while also showing good interactive responsiveness even
-	 on SMP and NUMA systems and exactly dividing by both PAL and
-	 NTSC frame rates for video and multimedia work.
-
-	config HZ_1000
-		bool "1000 HZ"
-	help
-	 1000 Hz is the preferred choice for desktop systems and other
-	 systems requiring fast interactive responses to events.
+config HZ
+    int "Timer frequency"
+    default 100
+    ---help---
+        Allows the configuration of the timer frequency. It is customary
+        to have the timer interrupt run at 1000 Hz but 100 Hz may be more
+        beneficial for servers and NUMA systems that do not need to have
+        a fast response for user interaction and that may experience bus
+        contention and cacheline bounces as a result of timer interrupts.
+        Note that the timer interrupt occurs on each processor in an SMP
+        environment leading to NR_CPUS * HZ number of timer interrupts
+        per second.
+
+        100 Hz is a typical choice for servers, SMP and NUMA systems
+        with lots of processors that may show reduced performance if
+        too many timer interrupts are occurring.
+
+        250 Hz is a good compromise choice allowing server performance
+        while also showing good interactive responsiveness even on SMP
+        and NUMA systems.
+
+        300 Hz is a good compromise choice allowing server performance
+        while also showing good interactive responsiveness even
+        on SMP and NUMA systems and exactly dividing by both PAL and
+        NTSC frame rates for video and multimedia work.
 
-endchoice
+        1000 Hz is the preferred choice for desktop systems and other
+        systems requiring fast interactive responses to events.
 
 config HZ
 	int
#<EOF>

Re: [PATCH 07/16] kconfig-dynamic-frequency.diff

[Kyle Moffett]

On Apr 01, 2007, at 14:15:20, Jan Engelhardt wrote:
>
> Make HZ fully configurable through menuconfig.
>
> Already posted at http://lkml.org/lkml/2006/6/18/111

Instead of that, what about something like this instead:  NOTE: I  
know my mailer mangles diffs and this one was hand-edited based on  
Jan's diff from within my mailer so it probably doesn't apply, but  
it's enough to point out the idea:

diff --fast -Ndpru linux-2.6.17-rc6~/kernel/Kconfig.hz linux-2.6.17- 
rc6+/kernel/Kconfig.hz
--- linux-2.6.17-rc6~/kernel/Kconfig.hz	2006-06-06 02:57:02.000000000  
+0200
+++ linux-2.6.17-rc6+/kernel/Kconfig.hz	2006-06-16 17:15:46.884794000  
+0200
@@ -36,10 +36,17 @@
  	 1000 HZ is the preferred choice for desktop systems and other
  	 systems requiring fast interactive responses to events.

+	config HZ_CUSTOM
+		bool "Custom HZ"
+	help
+	 This allows you to specify your own custom timer frequency, if
+	 the default options are not satisfactory for your use.
+
  endchoice

  config HZ
-	int
+	int if !HZ_CUSTOM
+	int "Customized HZ value" if HZ_CUSTOM
  	default 100 if HZ_100
  	default 250 if HZ_250
  	default 1000 if HZ_1000

Re: [PATCH 07/16] kconfig-dynamic-frequency.diff

[Jan Engelhardt]

On Apr 1 2007 14:39, Kyle Moffett wrote:
>> 
>> Make HZ fully configurable through menuconfig.
>> 
>> Already posted at http://lkml.org/lkml/2006/6/18/111
>
> Instead of that, what about something like this instead:  NOTE: I know my
> mailer mangles diffs and this one was hand-edited based on Jan's diff from
> within my mailer so it probably doesn't apply, but it's enough to point out the
> idea:

> config HZ
> -	int
> +	int if !HZ_CUSTOM
> +	int "Customized HZ value" if HZ_CUSTOM
> default 100 if HZ_100
> default 250 if HZ_250
> default 1000 if HZ_1000

People always come up with new complexities I never thought kconfig
would be able to do. Nice stuff. I'll take up on your idea and
incorporate it right away.

But I would have to ask: Why do we need 100/250/300/1000 if there is
anyway an input field for the user to enter - s/he should read the
help text for Known Good values, should not s/he?


Jan
-- 

Re: [PATCH 07/16] kconfig-dynamic-frequency.diff

[Kyle Moffett]

On Apr 01, 2007, at 14:42:59, Jan Engelhardt wrote:
> But I would have to ask: Why do we need 100/250/300/1000 if there  
> is anyway an input field for the user to enter - s/he should read  
> the help text for Known Good values, should not s/he?

Actually, probably what should be done is make the "HZ_CUSTOM" option  
depend on EXPERIMENTAL/ 
EMBEDDED/"EXPERT"/"I_KNOW_WHAT_THE_HELL_IM_DOING" or some other  
equivalent option, because a wrong choice for HZ has the potential to  
really screw up a system.  For example, 10000+ would make most  
systems spend a significant portion of their time processing timer  
interrupts and context switches, and less than 100 or so would make  
the system seem jerky.  The point is to encourage the average kernel  
builder not to change from one of the default options unless they  
really know what they're doing.

Cheers,
Kyle Moffett

Re: [PATCH 07/16] kconfig-dynamic-frequency.diff

[Jan Engelhardt]

On Apr 1 2007 14:52, Kyle Moffett wrote:
>
> On Apr 01, 2007, at 14:42:59, Jan Engelhardt wrote:
>> But I would have to ask: Why do we need 100/250/300/1000 if there
>> is anyway an input field for the user to enter - s/he should read
>> the help text for Known Good values, should not s/he?
>
> Actually, probably what should be done is make the "HZ_CUSTOM"
> option depend on EXPERIMENTAL / EMBEDDED / "EXPERT" /
> "I_KNOW_WHAT_THE_HELL_IM_DOING" or some other equivalent option,

EXPERIMENTAL is most often enabled by distributors.
And we are still missing our much-needed CONFIG_EXPERT :-(

> because a wrong choice for HZ has the potential to really screw up
> a system.  For example, 10000+ would make most systems spend a
> significant portion of their time processing timer interrupts and

Point taken. Ehm, I already once tried making a 10000-Hz kernel
around 2.6.13-15 or so. It did not compile because some header files had
#error directives for HZ >= 1536. (jiffies.h:33 if you want
to know.) IIRC there also was another place somewhere in networking
code that #errors out at >8192.


Jan
-- 

[PATCH]

[Kyle Moffett]

[-- Attachment #1: Type: text/plain, Size: 329 bytes --]

Add a CONFIG_I_KNOW_WHAT_THE_HELL_I_AM_DOING variable with a really  
strong
warning attached to it (and a shorter CONFIG_EXPERT variable for use in
Kconfig files where it's a PITA to type out the full name)

Signed-off-by: Kyle Moffett <mrmacman_g4@mac.com>

---

Since my mailer tends to mangle patches I've attached this one


[-- Attachment #2: config_expert.patch.txt --]
[-- Type: text/plain, Size: 1609 bytes --]

Index: linux-2.6.20.1/init/Kconfig
===================================================================
--- linux-2.6.20.1.orig/init/Kconfig
+++ linux-2.6.20.1/init/Kconfig
@@ -40,6 +40,35 @@
 	you say Y here, you will be offered the choice of using features or
 	drivers that are currently considered to be in the alpha-test phase.
 
+config I_KNOW_WHAT_THE_HELL_I_AM_DOING
+	bool "Prompt for config options which will break your computer"
+	---help---
+	  Some kernel developers sometimes need to tune kernel parameters
+	  outside of their normal limits.  Without complete knowledge of
+	  exactly what you are doing you are likely to corrupt the laws of
+	  physics and destroy the universe (well, not quite, but you'll
+	  certainly corrupt your data and crash your box).  If you really
+	  know what you're doing and accept that if it breaks you get to
+	  keep the pieces, then go ahead and enable this option.
+	  
+	  NOTICE:  Bug reports where this option is turned on in the kernel
+	  config will be: (not necessarily in this order)
+	    1)  Laughed at hysterically
+	    2)  Made much fun of
+	    3)  Ridiculed until we're red in the face
+	    4)  Ignored
+	  
+	  WARNING:  If you are building a kernel for a distribution, DO NOT
+	  TURN THIS OPTION ON!!!  Instead you should submit a patch which
+	  adds a new safe value to the list of possibilities for the config
+	  option you're interested in.  Otherwise your users might have a
+	  hard time getting kernel support on the LKML.
+
+config EXPERT
+	bool
+	depends on I_KNOW_WHAT_THE_HELL_I_AM_DOING
+	default y
+
 config BROKEN
 	bool
 

Re: [PATCH]

[Jan Engelhardt]

On Apr 1 2007 15:42, Kyle Moffett wrote:

>Date: Sun, 1 Apr 2007 15:42:09 -0400
>From: Kyle Moffett <mrmacman_g4@mac.com>
>To: Jan Engelhardt <jengelh@linux01.gwdg.de>
>Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
>    Alan Cox <alan@lxorguk.ukuu.org.uk>, Sam Ravnborg <sam@ravnborg.org>,
>    Andrew Morton <akpm@osdl.org>
>Subject: [PATCH]
>
> Add a CONFIG_I_KNOW_WHAT_THE_HELL_I_AM_DOING variable with a really strong
> warning attached to it (and a shorter CONFIG_EXPERT variable for use in
> Kconfig files where it's a PITA to type out the full name)

Do it like Linus Torvalds and Marissa Mayer and get a better mailer :-D

Index: linux-2.6.20.1/init/Kconfig
===================================================================
--- linux-2.6.20.1.orig/init/Kconfig
+++ linux-2.6.20.1/init/Kconfig
@@ -40,6 +40,35 @@
 	you say Y here, you will be offered the choice of using features or
 	drivers that are currently considered to be in the alpha-test phase.
 
+config I_KNOW_WHAT_THE_HELL_I_AM_DOING

Let's just hope kconfig does not bust the stack.
Perhaps we could shorten that: I_KNOW_WTF_I_AM_DOING

+	bool "Prompt for config options which will break your computer"

s/will break (.*)/could break $1 if done wrong/;

+	---help---
+	  Some kernel developers sometimes need to tune kernel parameters
+	  outside of their normal limits.  Without complete knowledge of
+	  exactly what you are doing you are likely to corrupt the laws of
+	  physics and destroy the universe (well, not quite, but you'll
+	  certainly corrupt your data and crash your box).  If you really
+	  know what you're doing and accept that if it breaks you get to
+	  keep the pieces, then go ahead and enable this option.
+	  
+	  NOTICE:  Bug reports where this option is turned on in the kernel
+	  config will be: (not necessarily in this order)
+	    1)  Laughed at hysterically
+	    2)  Made much fun of
+	    3)  Ridiculed until we're red in the face
+	    4)  Ignored
+	  
+	  WARNING:  If you are building a kernel for a distribution, DO NOT
+	  TURN THIS OPTION ON!!!  Instead you should submit a patch which
+	  adds a new safe value to the list of possibilities for the config
+	  option you're interested in.  Otherwise your users might have a
+	  hard time getting kernel support on the LKML.
+
+config EXPERT
+	bool
+	depends on I_KNOW_WHAT_THE_HELL_I_AM_DOING
+	default y
+
 config BROKEN
 	bool

Given that, I hope the number of options dependent on CONFIG_EXPERT will 
outnumber those depending on CONFIG_I_KNOW_WTF_I_AM_DOING.

If you want my answer: not-so-ACK, move the text to CONFIG_EXPERT and 
let's stay sane for the next 366 days until next April 01.



Jan
-- 

Re: [PATCH]

[Kyle Moffett]

On Apr 01, 2007, at 15:47:18, Jan Engelhardt wrote:
> +config I_KNOW_WHAT_THE_HELL_I_AM_DOING
>
> Let's just hope kconfig does not bust the stack.
> Perhaps we could shorten that: I_KNOW_WTF_I_AM_DOING

Ah, good point, but I think it fits.

> +	bool "Prompt for config options which will break your computer"
>
> s/will break (.*)/could break $1 if done wrong/;

Well, we've had problems in the past where people turn on options  
under CONFIG_EXPERIMENTAL or CONFIG_EMBEDDED and it breaks in exactly  
the specified fashion and they complain on LKML.  The point of this  
is to expose kconfig tunables which a "normal" kconfig user would get  
wrong 99% of the time and would break in obscure ways.  For example,  
the "CONFIG_MULTITHREAD_PCI_PROBE" option, if it was re-added for  
more tinkering, could go under this option.

> +config EXPERT
> +	bool
> +	depends on I_KNOW_WHAT_THE_HELL_I_AM_DOING
> +	default y
>
> Given that, I hope the number of options dependent on CONFIG_EXPERT  
> will outnumber those depending on CONFIG_I_KNOW_WTF_I_AM_DOING.

Ah, see, due to the magic of kconfig language this does not show up  
as a separate option (no text for the "bool") identifier.  It's just  
an alias for I_KNOW_WHAT_THE_HELL_I_AM_DOING to make it easier to use  
in other Kconfig files ("depends EXPERT && SOME_OPTION!=n &&  
ANOTHER_OPTION") instead of s/EXPERT/I_KNOW_WHAT_THE_HELL_I_AM_DOING/g.

> If you want my answer: not-so-ACK, move the text to CONFIG_EXPERT  
> and let's stay sane for the next 366 days until next April 01.

:-D

Cheers,
Kyle Moffett

Re: [PATCH]

[Andi Kleen]

Kyle Moffett <mrmacman_g4@mac.com> writes:

> Add a CONFIG_I_KNOW_WHAT_THE_HELL_I_AM_DOING variable with a really
> strong
> warning attached to it (and a shorter CONFIG_EXPERT variable for use in
> Kconfig files where it's a PITA to type out the full name)

When you know what you're doing you can just patch then Kconfig files.
IMHO that's better than this.

-Andi

[PATCH]

[James Simmons]

This is the new display intreface. Its goal is to provide a standard 
interface to various types of displays. Currently we have auxdisplay, 
output acpi device and the now defunct lcd class in the backlight directory.
Please apply.

Signed-Off: James Simmons <jsimmons@infradead.org>

diff -urN -X linus-2.6/Documentation/dontdiff linus-2.6/drivers/video/display/display-sysfs.c fbdev-2.6/drivers/video/display/display-sysfs.c
--- linus-2.6/drivers/video/display/display-sysfs.c	1969-12-31 19:00:00.000000000 -0500
+++ fbdev-2.6/drivers/video/display/display-sysfs.c	2007-02-21 15:55:18.000000000 -0500
@@ -0,0 +1,200 @@
+/*
+ *  display-sysfs.c - Display output driver sysfs interface
+ *
+ *  Copyright (C) 2007 James Simmons <jsimmons@infradead.org>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or (at
+ *  your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+#include <linux/module.h>
+#include <linux/display.h>
+#include <linux/err.h>
+#include <linux/ctype.h>
+
+static ssize_t display_show_name(struct device *dev, struct device_attribute *attr,
+				char *buf)
+{
+	struct display_device *dsp = dev_get_drvdata(dev);
+	return snprintf(buf, PAGE_SIZE, "%s\n", dsp->name);
+}
+
+static ssize_t display_show_type(struct device *dev, struct device_attribute *attr,
+				char *buf)
+{
+	struct display_device *dsp = dev_get_drvdata(dev);
+	return snprintf(buf, PAGE_SIZE, "%s\n", dsp->type);
+}
+
+static ssize_t display_show_contrast(struct device *dev, struct device_attribute *attr,
+				char *buf)
+{
+	struct display_device *dsp = dev_get_drvdata(dev);
+	ssize_t rc = -ENXIO;
+
+	mutex_lock(&dsp->lock);
+	if (likely(dsp->driver) && dsp->driver->get_contrast)
+		rc = sprintf(buf, "%d\n", dsp->driver->get_contrast(dsp));
+	mutex_unlock(&dsp->lock);
+	return rc;
+}
+
+static ssize_t display_store_contrast(struct device *dev, struct device_attribute *attr,
+				const char *buf, size_t count)
+{
+	struct display_device *dsp = dev_get_drvdata(dev);
+	ssize_t ret = -EINVAL, size;
+	int contrast;
+	char *endp;
+
+	contrast = simple_strtoul(buf, &endp, 0);
+	size = endp - buf;
+
+	if (*endp && isspace(*endp))
+		size++;
+
+	if (size != count)
+		return ret;
+
+	mutex_lock(&dsp->lock);
+	if (likely(dsp->driver && dsp->driver->set_contrast)) {
+		pr_debug("display: set contrast to %d\n", contrast);
+		dsp->driver->set_contrast(dsp, contrast);
+		ret = count;
+	}
+	mutex_unlock(&dsp->lock);
+	return ret;
+}
+
+static ssize_t display_show_max_contrast(struct device *dev, struct device_attribute *attr,
+					char *buf)
+{
+	struct display_device *dsp = dev_get_drvdata(dev);
+	ssize_t rc = -ENXIO;
+
+	mutex_lock(&dsp->lock);
+	if (likely(dsp->driver))
+		rc = sprintf(buf, "%d\n", dsp->driver->max_contrast);
+	mutex_unlock(&dsp->lock);
+	return rc;
+}
+
+static struct device_attribute display_attrs[] = {
+	__ATTR(name, S_IRUGO, display_show_name, NULL),
+	__ATTR(type, S_IRUGO, display_show_type, NULL),
+	__ATTR(contrast, S_IRUGO | S_IWUSR, display_show_contrast, display_store_contrast),
+	__ATTR(max_contrast, S_IRUGO, display_show_max_contrast, NULL),
+};
+
+static int display_suspend(struct device *dev, pm_message_t state)
+{
+	struct display_device *dsp = dev_get_drvdata(dev);
+
+	mutex_lock(&dsp->lock);
+	if (likely(dsp->driver->suspend))
+		dsp->driver->suspend(dsp, state);
+	mutex_unlock(&dsp->lock);
+	return 0;
+};
+
+static int display_resume(struct device *dev)
+{
+	struct display_device *dsp = dev_get_drvdata(dev);
+
+	mutex_lock(&dsp->lock);
+	if (likely(dsp->driver->resume))
+		dsp->driver->resume(dsp);
+	mutex_unlock(&dsp->lock);
+	return 0;
+};
+
+struct class *display_class;
+EXPORT_SYMBOL(display_class);
+static int index;
+
+struct display_device *display_device_register(struct display_driver *driver,
+						struct device *dev, void *devdata)
+{
+	struct display_device *new_dev = NULL;
+	int ret = -EINVAL;
+
+	if (unlikely(!driver))
+		return ERR_PTR(ret);
+
+	new_dev = kzalloc(sizeof(struct display_device), GFP_KERNEL);
+	if (likely(new_dev) && unlikely(driver->probe(new_dev, devdata))) {
+		new_dev->dev = device_create(display_class, dev, 0,
+						"display%d", index);
+
+		if (!IS_ERR(new_dev->dev)) {
+			dev_set_drvdata(new_dev->dev, new_dev);
+			new_dev->driver = driver;
+			new_dev->parent = dev;
+			mutex_init(&new_dev->lock);
+			index++;
+		} else {
+			new_dev->dev = NULL;
+			kfree(new_dev);
+		}
+	}
+	return new_dev;
+}
+EXPORT_SYMBOL(display_device_register);
+
+void display_device_unregister(struct display_device *ddev)
+{
+	if (!ddev)
+		return;
+	mutex_lock(&ddev->lock);
+	device_del(ddev->dev);
+	ddev->driver = NULL;
+	index--;
+	mutex_unlock(&ddev->lock);
+	kfree(ddev);
+}
+EXPORT_SYMBOL(display_device_unregister);
+
+static int __init display_class_init(void)
+{
+	display_class = class_create(THIS_MODULE, "display");
+	if (IS_ERR(display_class)) {
+		printk(KERN_ERR "Failed to create display class\n");
+		display_class = NULL;
+		return -EINVAL;
+	}
+	display_class->dev_attrs = display_attrs;
+	display_class->suspend = display_suspend;
+	display_class->resume = display_resume;
+	return 0;
+}
+
+#ifdef MODULE
+module_init(display_class_init);
+
+static void __exit display_class_exit(void)
+{
+	class_destroy(display_class);
+}
+module_exit(display_class_exit);
+#else
+subsys_initcall(display_class_init);
+#endif
+
+MODULE_DESCRIPTION("Display Hardware handling");
+MODULE_AUTHOR("James Simmons <jsimmons@infradead.org>");
+MODULE_LICENSE("GPL");
+
diff -urN -X linus-2.6/Documentation/dontdiff linus-2.6/drivers/video/display/Kconfig fbdev-2.6/drivers/video/display/Kconfig
--- linus-2.6/drivers/video/display/Kconfig	1969-12-31 19:00:00.000000000 -0500
+++ fbdev-2.6/drivers/video/display/Kconfig	2007-02-21 15:56:32.000000000 -0500
@@ -0,0 +1,24 @@
+#
+# Display drivers configuration
+#
+
+menu "Display device support"
+
+config DISPLAY_SUPPORT
+	tristate "Display panel/monitor support"
+	---help---
+	  This framework adds support for low-level control of a display.
+	  This includes support for power.
+
+	  Enable this to be able to choose the drivers for controlling the
+	  physical display panel/monitor on some platforms. This not only
+	  covers LCD displays for PDAs but also other types of displays
+	  such as CRT, TVout etc.
+
+	  To have support for your specific display panel you will have to
+	  select the proper drivers which depend on this option.
+
+comment "Display hardware drivers"
+	depends on DISPLAY_SUPPORT
+
+endmenu
diff -urN -X linus-2.6/Documentation/dontdiff linus-2.6/drivers/video/display/Makefile fbdev-2.6/drivers/video/display/Makefile
--- linus-2.6/drivers/video/display/Makefile	1969-12-31 19:00:00.000000000 -0500
+++ fbdev-2.6/drivers/video/display/Makefile	2007-02-21 15:56:22.000000000 -0500
@@ -0,0 +1,6 @@
+# Display drivers
+
+display-objs				:= display-sysfs.o
+
+obj-$(CONFIG_DISPLAY_SUPPORT)		+= display.o
+
diff -urN -X linus-2.6/Documentation/dontdiff linus-2.6/drivers/video/Kconfig fbdev-2.6/drivers/video/Kconfig
--- linus-2.6/drivers/video/Kconfig	2007-02-21 10:59:24.000000000 -0500
+++ fbdev-2.6/drivers/video/Kconfig	2007-02-21 15:55:56.000000000 -0500
@@ -5,6 +5,7 @@
 menu "Graphics support"
 
 source "drivers/video/backlight/Kconfig"
+source "drivers/video/display/Kconfig"
 
 config FB
 	tristate "Support for frame buffer devices"
diff -urN -X linus-2.6/Documentation/dontdiff linus-2.6/drivers/video/Makefile fbdev-2.6/drivers/video/Makefile
--- linus-2.6/drivers/video/Makefile	2007-02-21 10:59:24.000000000 -0500
+++ fbdev-2.6/drivers/video/Makefile	2007-02-21 15:16:48.000000000 -0500
@@ -12,7 +12,7 @@
 
 obj-$(CONFIG_VT)		  += console/
 obj-$(CONFIG_LOGO)		  += logo/
-obj-y				  += backlight/
+obj-y				  += backlight/ display/
 
 obj-$(CONFIG_FB_CFB_FILLRECT)  += cfbfillrect.o
 obj-$(CONFIG_FB_CFB_COPYAREA)  += cfbcopyarea.o
diff -urN -X linus-2.6/Documentation/dontdiff linus-2.6/include/linux/display.h fbdev-2.6/include/linux/display.h
--- linus-2.6/include/linux/display.h	1969-12-31 19:00:00.000000000 -0500
+++ fbdev-2.6/include/linux/display.h	2007-02-21 15:34:31.000000000 -0500
@@ -0,0 +1,60 @@
+/*
+ *  Copyright (C) 2006 James Simmons <jsimmons@infradead.org>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or (at
+ *  your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#ifndef _LINUX_DISPLAY_H
+#define _LINUX_DISPLAY_H
+
+#include <linux/device.h>
+
+struct display_device;
+
+/* This structure defines all the properties of a Display. */
+struct display_driver {
+	int  (*set_contrast)(struct display_device *, unsigned int);
+	int  (*get_contrast)(struct display_device *);
+	void (*suspend)(struct display_device *, pm_message_t state);
+	void (*resume)(struct display_device *);
+	int  (*probe)(struct display_device *, void *);
+	int  (*remove)(struct display_device *);
+	int  max_contrast;
+};
+
+struct display_device {
+	struct module *owner;	/* Owner module */
+	char type[16];
+	char *name;
+	struct mutex lock;
+	struct display_driver *driver;
+	struct device *parent;			/* This is the parent */
+	struct device *dev;			/* This is this display device */
+	void *priv_data;
+};
+
+extern struct display_device *display_device_register(struct display_driver *driver,
+					struct device *dev, void *devdata);
+extern void display_device_unregister(struct display_device *dev);
+
+extern int probe_edid(struct display_device *dev, void *devdata);
+
+#define to_display_device(obj) container_of(obj, struct display_device, class_dev)
+
+#endif

[PATCH]

[James Simmons]

This is the new display intreface. Its goal is to provide a standard 
interface to various types of displays. Currently we have auxdisplay, 
output acpi device and the now defunct lcd class in the backlight directory.
Please apply.

Signed-Off: James Simmons <jsimmons@infradead.org>

diff -urN -X linus-2.6/Documentation/dontdiff linus-2.6/drivers/video/display/display-sysfs.c fbdev-2.6/drivers/video/display/display-sysfs.c
--- linus-2.6/drivers/video/display/display-sysfs.c	1969-12-31 19:00:00.000000000 -0500
+++ fbdev-2.6/drivers/video/display/display-sysfs.c	2007-02-21 15:55:18.000000000 -0500
@@ -0,0 +1,200 @@
+/*
+ *  display-sysfs.c - Display output driver sysfs interface
+ *
+ *  Copyright (C) 2007 James Simmons <jsimmons@infradead.org>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or (at
+ *  your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+#include <linux/module.h>
+#include <linux/display.h>
+#include <linux/err.h>
+#include <linux/ctype.h>
+
+static ssize_t display_show_name(struct device *dev, struct device_attribute *attr,
+				char *buf)
+{
+	struct display_device *dsp = dev_get_drvdata(dev);
+	return snprintf(buf, PAGE_SIZE, "%s\n", dsp->name);
+}
+
+static ssize_t display_show_type(struct device *dev, struct device_attribute *attr,
+				char *buf)
+{
+	struct display_device *dsp = dev_get_drvdata(dev);
+	return snprintf(buf, PAGE_SIZE, "%s\n", dsp->type);
+}
+
+static ssize_t display_show_contrast(struct device *dev, struct device_attribute *attr,
+				char *buf)
+{
+	struct display_device *dsp = dev_get_drvdata(dev);
+	ssize_t rc = -ENXIO;
+
+	mutex_lock(&dsp->lock);
+	if (likely(dsp->driver) && dsp->driver->get_contrast)
+		rc = sprintf(buf, "%d\n", dsp->driver->get_contrast(dsp));
+	mutex_unlock(&dsp->lock);
+	return rc;
+}
+
+static ssize_t display_store_contrast(struct device *dev, struct device_attribute *attr,
+				const char *buf, size_t count)
+{
+	struct display_device *dsp = dev_get_drvdata(dev);
+	ssize_t ret = -EINVAL, size;
+	int contrast;
+	char *endp;
+
+	contrast = simple_strtoul(buf, &endp, 0);
+	size = endp - buf;
+
+	if (*endp && isspace(*endp))
+		size++;
+
+	if (size != count)
+		return ret;
+
+	mutex_lock(&dsp->lock);
+	if (likely(dsp->driver && dsp->driver->set_contrast)) {
+		pr_debug("display: set contrast to %d\n", contrast);
+		dsp->driver->set_contrast(dsp, contrast);
+		ret = count;
+	}
+	mutex_unlock(&dsp->lock);
+	return ret;
+}
+
+static ssize_t display_show_max_contrast(struct device *dev, struct device_attribute *attr,
+					char *buf)
+{
+	struct display_device *dsp = dev_get_drvdata(dev);
+	ssize_t rc = -ENXIO;
+
+	mutex_lock(&dsp->lock);
+	if (likely(dsp->driver))
+		rc = sprintf(buf, "%d\n", dsp->driver->max_contrast);
+	mutex_unlock(&dsp->lock);
+	return rc;
+}
+
+static struct device_attribute display_attrs[] = {
+	__ATTR(name, S_IRUGO, display_show_name, NULL),
+	__ATTR(type, S_IRUGO, display_show_type, NULL),
+	__ATTR(contrast, S_IRUGO | S_IWUSR, display_show_contrast, display_store_contrast),
+	__ATTR(max_contrast, S_IRUGO, display_show_max_contrast, NULL),
+};
+
+static int display_suspend(struct device *dev, pm_message_t state)
+{
+	struct display_device *dsp = dev_get_drvdata(dev);
+
+	mutex_lock(&dsp->lock);
+	if (likely(dsp->driver->suspend))
+		dsp->driver->suspend(dsp, state);
+	mutex_unlock(&dsp->lock);
+	return 0;
+};
+
+static int display_resume(struct device *dev)
+{
+	struct display_device *dsp = dev_get_drvdata(dev);
+
+	mutex_lock(&dsp->lock);
+	if (likely(dsp->driver->resume))
+		dsp->driver->resume(dsp);
+	mutex_unlock(&dsp->lock);
+	return 0;
+};
+
+struct class *display_class;
+EXPORT_SYMBOL(display_class);
+static int index;
+
+struct display_device *display_device_register(struct display_driver *driver,
+						struct device *dev, void *devdata)
+{
+	struct display_device *new_dev = NULL;
+	int ret = -EINVAL;
+
+	if (unlikely(!driver))
+		return ERR_PTR(ret);
+
+	new_dev = kzalloc(sizeof(struct display_device), GFP_KERNEL);
+	if (likely(new_dev) && unlikely(driver->probe(new_dev, devdata))) {
+		new_dev->dev = device_create(display_class, dev, 0,
+						"display%d", index);
+
+		if (!IS_ERR(new_dev->dev)) {
+			dev_set_drvdata(new_dev->dev, new_dev);
+			new_dev->driver = driver;
+			new_dev->parent = dev;
+			mutex_init(&new_dev->lock);
+			index++;
+		} else {
+			new_dev->dev = NULL;
+			kfree(new_dev);
+		}
+	}
+	return new_dev;
+}
+EXPORT_SYMBOL(display_device_register);
+
+void display_device_unregister(struct display_device *ddev)
+{
+	if (!ddev)
+		return;
+	mutex_lock(&ddev->lock);
+	device_del(ddev->dev);
+	ddev->driver = NULL;
+	index--;
+	mutex_unlock(&ddev->lock);
+	kfree(ddev);
+}
+EXPORT_SYMBOL(display_device_unregister);
+
+static int __init display_class_init(void)
+{
+	display_class = class_create(THIS_MODULE, "display");
+	if (IS_ERR(display_class)) {
+		printk(KERN_ERR "Failed to create display class\n");
+		display_class = NULL;
+		return -EINVAL;
+	}
+	display_class->dev_attrs = display_attrs;
+	display_class->suspend = display_suspend;
+	display_class->resume = display_resume;
+	return 0;
+}
+
+#ifdef MODULE
+module_init(display_class_init);
+
+static void __exit display_class_exit(void)
+{
+	class_destroy(display_class);
+}
+module_exit(display_class_exit);
+#else
+subsys_initcall(display_class_init);
+#endif
+
+MODULE_DESCRIPTION("Display Hardware handling");
+MODULE_AUTHOR("James Simmons <jsimmons@infradead.org>");
+MODULE_LICENSE("GPL");
+
diff -urN -X linus-2.6/Documentation/dontdiff linus-2.6/drivers/video/display/Kconfig fbdev-2.6/drivers/video/display/Kconfig
--- linus-2.6/drivers/video/display/Kconfig	1969-12-31 19:00:00.000000000 -0500
+++ fbdev-2.6/drivers/video/display/Kconfig	2007-02-21 15:56:32.000000000 -0500
@@ -0,0 +1,24 @@
+#
+# Display drivers configuration
+#
+
+menu "Display device support"
+
+config DISPLAY_SUPPORT
+	tristate "Display panel/monitor support"
+	---help---
+	  This framework adds support for low-level control of a display.
+	  This includes support for power.
+
+	  Enable this to be able to choose the drivers for controlling the
+	  physical display panel/monitor on some platforms. This not only
+	  covers LCD displays for PDAs but also other types of displays
+	  such as CRT, TVout etc.
+
+	  To have support for your specific display panel you will have to
+	  select the proper drivers which depend on this option.
+
+comment "Display hardware drivers"
+	depends on DISPLAY_SUPPORT
+
+endmenu
diff -urN -X linus-2.6/Documentation/dontdiff linus-2.6/drivers/video/display/Makefile fbdev-2.6/drivers/video/display/Makefile
--- linus-2.6/drivers/video/display/Makefile	1969-12-31 19:00:00.000000000 -0500
+++ fbdev-2.6/drivers/video/display/Makefile	2007-02-21 15:56:22.000000000 -0500
@@ -0,0 +1,6 @@
+# Display drivers
+
+display-objs				:= display-sysfs.o
+
+obj-$(CONFIG_DISPLAY_SUPPORT)		+= display.o
+
diff -urN -X linus-2.6/Documentation/dontdiff linus-2.6/drivers/video/Kconfig fbdev-2.6/drivers/video/Kconfig
--- linus-2.6/drivers/video/Kconfig	2007-02-21 10:59:24.000000000 -0500
+++ fbdev-2.6/drivers/video/Kconfig	2007-02-21 15:55:56.000000000 -0500
@@ -5,6 +5,7 @@
 menu "Graphics support"
 
 source "drivers/video/backlight/Kconfig"
+source "drivers/video/display/Kconfig"
 
 config FB
 	tristate "Support for frame buffer devices"
diff -urN -X linus-2.6/Documentation/dontdiff linus-2.6/drivers/video/Makefile fbdev-2.6/drivers/video/Makefile
--- linus-2.6/drivers/video/Makefile	2007-02-21 10:59:24.000000000 -0500
+++ fbdev-2.6/drivers/video/Makefile	2007-02-21 15:16:48.000000000 -0500
@@ -12,7 +12,7 @@
 
 obj-$(CONFIG_VT)		  += console/
 obj-$(CONFIG_LOGO)		  += logo/
-obj-y				  += backlight/
+obj-y				  += backlight/ display/
 
 obj-$(CONFIG_FB_CFB_FILLRECT)  += cfbfillrect.o
 obj-$(CONFIG_FB_CFB_COPYAREA)  += cfbcopyarea.o
diff -urN -X linus-2.6/Documentation/dontdiff linus-2.6/include/linux/display.h fbdev-2.6/include/linux/display.h
--- linus-2.6/include/linux/display.h	1969-12-31 19:00:00.000000000 -0500
+++ fbdev-2.6/include/linux/display.h	2007-02-21 15:34:31.000000000 -0500
@@ -0,0 +1,60 @@
+/*
+ *  Copyright (C) 2006 James Simmons <jsimmons@infradead.org>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or (at
+ *  your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#ifndef _LINUX_DISPLAY_H
+#define _LINUX_DISPLAY_H
+
+#include <linux/device.h>
+
+struct display_device;
+
+/* This structure defines all the properties of a Display. */
+struct display_driver {
+	int  (*set_contrast)(struct display_device *, unsigned int);
+	int  (*get_contrast)(struct display_device *);
+	void (*suspend)(struct display_device *, pm_message_t state);
+	void (*resume)(struct display_device *);
+	int  (*probe)(struct display_device *, void *);
+	int  (*remove)(struct display_device *);
+	int  max_contrast;
+};
+
+struct display_device {
+	struct module *owner;	/* Owner module */
+	char type[16];
+	char *name;
+	struct mutex lock;
+	struct display_driver *driver;
+	struct device *parent;			/* This is the parent */
+	struct device *dev;			/* This is this display device */
+	void *priv_data;
+};
+
+extern struct display_device *display_device_register(struct display_driver *driver,
+					struct device *dev, void *devdata);
+extern void display_device_unregister(struct display_device *dev);
+
+extern int probe_edid(struct display_device *dev, void *devdata);
+
+#define to_display_device(obj) container_of(obj, struct display_device, class_dev)
+
+#endif

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [PATCH]

[Antonino A. Daplas]

On Wed, 2007-02-21 at 21:23 +0000, James Simmons wrote:
> This is the new display intreface. Its goal is to provide a standard 
> interface to various types of displays. Currently we have auxdisplay, 
> output acpi device and the now defunct lcd class in the backlight directory.
> Please apply.

Is this an attempt to consolidate all display hardware and drivers?

> 
[snip]
> +struct class *display_class;
> +EXPORT_SYMBOL(display_class);
> +static int index;
> +
> +struct display_device *display_device_register(struct display_driver *driver,
> +						struct device *dev, void *devdata)
> +{
> +	struct display_device *new_dev = NULL;
> +	int ret = -EINVAL;
> +
> +	if (unlikely(!driver))
> +		return ERR_PTR(ret);
> +
> +	new_dev = kzalloc(sizeof(struct display_device), GFP_KERNEL);
> +	if (likely(new_dev) && unlikely(driver->probe(new_dev, devdata))) {
> +		new_dev->dev = device_create(display_class, dev, 0,
> +						"display%d", index);
> +
> +		if (!IS_ERR(new_dev->dev)) {
> +			dev_set_drvdata(new_dev->dev, new_dev);
> +			new_dev->driver = driver;
> +			new_dev->parent = dev;
> +			mutex_init(&new_dev->lock);
> +			index++;
> +		} else {
> +			new_dev->dev = NULL;
> +			kfree(new_dev);

Set new_dev to NULL on failure.

> +		}
> +	}
> +	return new_dev;
> +}
> +EXPORT_SYMBOL(display_device_register);
> +
> +void display_device_unregister(struct display_device *ddev)
> +{
> +	if (!ddev)
> +		return;
> +	mutex_lock(&ddev->lock);
> +	device_del(ddev->dev);
> +	ddev->driver = NULL;
> +	index--;

display0
display1
index = 2
unregister display0
index = 1
display_device_register() as device1
device1 <-- BUG, already used.

[snip]

> +
> +struct display_device;
> +
> +/* This structure defines all the properties of a Display. */
> +struct display_driver {
> +	int  (*set_contrast)(struct display_device *, unsigned int);
> +	int  (*get_contrast)(struct display_device *);
> +	void (*suspend)(struct display_device *, pm_message_t state);
> +	void (*resume)(struct display_device *);
> +	int  (*probe)(struct display_device *, void *);
> +	int  (*remove)(struct display_device *);
> +	int  max_contrast;

If this is an attempt to consolidate, I don't see the 'brightness'
hook of backlight and lcd.

If this is not a consolidation, why don't we just extend the lcd class?

Tony 



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [Linux-fbdev-devel] [PATCH]

[James Simmons]

> On Wed, 2007-02-21 at 21:23 +0000, James Simmons wrote:
> > This is the new display intreface. Its goal is to provide a standard 
> > interface to various types of displays. Currently we have auxdisplay, 
> > output acpi device and the now defunct lcd class in the backlight directory.
> > Please apply.
> 
> Is this an attempt to consolidate all display hardware and drivers?

All display types. Its LCD panels, LCD teletypes, TVs, CRTs etc. Right now 
we have several solutions to the same problem (acpi output.c driver, auxdisplay 
directory). A good idea what this aimed at take a look at 

http://lcd4linux.sf.net

The bonus is the acpi and fbdev layer coudl use this as well.

> > +		} else {
> > +			new_dev->dev = NULL;
> > +			kfree(new_dev);
> 
> Set new_dev to NULL on failure.

Hum let me look. Okay, from what I see kfree doesn't set the the pointer 
to null. Will fix.

> > +	mutex_lock(&ddev->lock);
> > +	device_del(ddev->dev);
> > +	ddev->driver = NULL;
> > +	index--;
> 
> display0
> display1
> index = 2
> unregister display0
> index = 1
> display_device_register() as device1
> device1 <-- BUG, already used.

Ug. Will fix. 

> If this is an attempt to consolidate, I don't see the 'brightness'
> hook of backlight and lcd.
> 
> If this is not a consolidation, why don't we just extend the lcd class?

Its is a replacement for lcd. Is brightness universal for all display 
types? 

Re: [PATCH]

[Antonino A. Daplas]

On Thu, 2007-02-22 at 01:35 +0000, James Simmons wrote:
> > On Wed, 2007-02-21 at 21:23 +0000, James Simmons wrote:

> > If this is an attempt to consolidate, I don't see the 'brightness'
> > hook of backlight and lcd.
> > 
> > If this is not a consolidation, why don't we just extend the lcd class?
> 
> Its is a replacement for lcd. Is brightness universal for all display 
> types?

Well, if you're adding a universal interface, you need hooks for more
than that (brightness, contrast, hue, saturation, tint, etc).  Then we
just let the drivers cherry pick from the list on what it's going to
support.

Tony


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [PATCH]

[James Simmons]

On Thu, 22 Feb 2007, Antonino A. Daplas wrote:

> On Thu, 2007-02-22 at 01:35 +0000, James Simmons wrote:
> > > On Wed, 2007-02-21 at 21:23 +0000, James Simmons wrote:
> 
> > > If this is an attempt to consolidate, I don't see the 'brightness'
> > > hook of backlight and lcd.
> > > 
> > > If this is not a consolidation, why don't we just extend the lcd class?
> > 
> > Its is a replacement for lcd. Is brightness universal for all display 
> > types?
> 
> Well, if you're adding a universal interface, you need hooks for more
> than that (brightness, contrast, hue, saturation, tint, etc).  Then we
> just let the drivers cherry pick from the list on what it's going to
> support.

Ah. Thats the power of sysfs groups :-)


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[PATCH]

[Jens Osterkamp]

[PATCH]

[Jan Beulich]

Prevent use of uninitialized data when hypervisor was built without
ACM_SECURITY.

Signed-off-by: Jan Beulich <jbeulich@novell.com>

Index: 2006-10-16/tools/python/xen/lowlevel/acm/acm.c
===================================================================
--- 2006-10-16.orig/tools/python/xen/lowlevel/acm/acm.c	2006-10-05 08:47:27.000000000 +0200
+++ 2006-10-16/tools/python/xen/lowlevel/acm/acm.c	2006-10-20 15:31:04.000000000 +0200
@@ -182,6 +182,8 @@ static PyObject *getdecision(PyObject * 
     if (xc_acm_op(xc_handle, ACMOP_getdecision, &getdecision, sizeof(getdecision)) < 0) {
         if (errno == EACCES)
             PERROR("ACM operation failed.");
+        xc_interface_close(xc_handle);
+        return NULL;
     }
 
     xc_interface_close(xc_handle);

[PATCH]

[Chris Boot]

Make the next48xx LED code use scx200_gpio_ops instead of raw SCx200 GPIO accesses.

Signed-off-by: Chris Boot <bootc@bootc.net>

diff --git a/drivers/leds/leds-net48xx.c b/drivers/leds/leds-net48xx.c
index 713c4a8..45ba3d4 100644
--- a/drivers/leds/leds-net48xx.c
+++ b/drivers/leds/leds-net48xx.c
@@ -16,6 +16,7 @@
  #include <linux/leds.h>
  #include <linux/err.h>
  #include <asm/io.h>
+#include <linux/nsc_gpio.h>
  #include <linux/scx200_gpio.h>

  #define DRVNAME "net48xx-led"
@@ -26,10 +27,7 @@ static struct platform_device *pdev;
  static void net48xx_error_led_set(struct led_classdev *led_cdev,
  		enum led_brightness value)
  {
-	if (value)
-		scx200_gpio_set_high(NET48XX_ERROR_LED_GPIO);
-	else
-		scx200_gpio_set_low(NET48XX_ERROR_LED_GPIO);
+	scx200_gpio_ops.gpio_set(NET48XX_ERROR_LED_GPIO, value ? 1 : 0);
  }

  static struct led_classdev net48xx_error_led = {
@@ -81,7 +79,8 @@ static int __init net48xx_led_init(void)
  {
  	int ret;

-	if (!scx200_gpio_present()) {
+	/* small hack, but scx200_gpio doesn't set .dev if the probe fails */
+	if (!scx200_gpio_ops.dev) {
  		ret = -ENODEV;
  		goto out;
  	}


-- 
Chris Boot
bootc@bootc.net
http://www.bootc.net/

[PATCH]

[Daniel Walker]

Signed-Off-By: Daniel Walker <dwalker@mvista.com>

Index: linux-2.6.16/kernel/time/timeofday.c
===================================================================
--- linux-2.6.16.orig/kernel/time/timeofday.c
+++ linux-2.6.16/kernel/time/timeofday.c
@@ -644,7 +644,7 @@ static void timeofday_periodic_hook(unsi
 
 	int something_changed = 0;
  	int clocksource_changed = 0;
-	struct clocksource old_clock;
+	struct clocksource old_clock = { .mult = 1, .shift = 0 };
 	static s64 second_check;
 
 	write_seqlock_irqsave(&system_time_lock, flags);

Re: [PATCH]

[john stultz]

On Fri, 2006-03-24 at 15:07 -0800, Daniel Walker wrote:
> Signed-Off-By: Daniel Walker <dwalker@mvista.com>
> 
> Index: linux-2.6.16/kernel/time/timeofday.c
> ===================================================================
> --- linux-2.6.16.orig/kernel/time/timeofday.c
> +++ linux-2.6.16/kernel/time/timeofday.c
> @@ -644,7 +644,7 @@ static void timeofday_periodic_hook(unsi
>  
>  	int something_changed = 0;
>   	int clocksource_changed = 0;
> -	struct clocksource old_clock;
> +	struct clocksource old_clock = { .mult = 1, .shift = 0 };
>  	static s64 second_check;
>  
>  	write_seqlock_irqsave(&system_time_lock, flags);

I assume this is a fix for the GCC "may be used uninitialized" warning?

thanks
-john

Re: [PATCH]

[Daniel Walker]

On Fri, 2006-03-24 at 15:19 -0800, john stultz wrote:
> On Fri, 2006-03-24 at 15:07 -0800, Daniel Walker wrote:
> > Signed-Off-By: Daniel Walker <dwalker@mvista.com>
> > 
> > Index: linux-2.6.16/kernel/time/timeofday.c
> > ===================================================================
> > --- linux-2.6.16.orig/kernel/time/timeofday.c
> > +++ linux-2.6.16/kernel/time/timeofday.c
> > @@ -644,7 +644,7 @@ static void timeofday_periodic_hook(unsi
> >  
> >  	int something_changed = 0;
> >   	int clocksource_changed = 0;
> > -	struct clocksource old_clock;
> > +	struct clocksource old_clock = { .mult = 1, .shift = 0 };
> >  	static s64 second_check;
> >  
> >  	write_seqlock_irqsave(&system_time_lock, flags);
> 
> I assume this is a fix for the GCC "may be used uninitialized" warning?

Yeah, Sorry ,I accidentally pressed enter before I described it ..

Daniel

[PATCH]

[Kumar Gala]

PCI: Add pci_assign_resource_fixed -- allow fixed address assignments

On some embedded systems the PCI address for hotplug devices are not only
known a priori but are required to be at a given PCI address for other
master in the system to be able to access.

An example of such a system would be an FPGA which is setup from user space
after the system has booted.  The FPGA may be access by DSPs in the system
and those DSPs expect the FPGA at a fixed PCI address.

Added pci_assign_resource_fixed() as a way to allow assignment of the PCI
devices's BARs at fixed PCI addresses.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

---
commit 45d4a23317c459865ec740c80b6e2a2ad9f53fd3
tree 432b5e41ef5f231dd57eb1a98f103239c62d63a0
parent 8176dee014ec6ad1039b8c0075c9c1d02147c2c8
author Kumar Gala <galak@kernel.crashing.org> Thu, 09 Mar 2006 12:34:25 -0600
committer Kumar Gala <galak@kernel.crashing.org> Thu, 09 Mar 2006 12:34:25 -0600

 drivers/pci/pci.c       |    1 +
 drivers/pci/setup-res.c |   35 +++++++++++++++++++++++++++++++++++
 include/linux/pci.h     |    1 +
 3 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index d2d1879..2557e86 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -935,6 +935,7 @@ EXPORT_SYMBOL_GPL(pci_intx);
 EXPORT_SYMBOL(pci_set_dma_mask);
 EXPORT_SYMBOL(pci_set_consistent_dma_mask);
 EXPORT_SYMBOL(pci_assign_resource);
+EXPORT_SYMBOL(pci_assign_resource_fixed);
 EXPORT_SYMBOL(pci_find_parent_resource);
 
 EXPORT_SYMBOL(pci_set_power_state);
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index ea9277b..f485958 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -155,6 +155,41 @@ int pci_assign_resource(struct pci_dev *
 	return ret;
 }
 
+int pci_assign_resource_fixed(struct pci_dev *dev, int resno)
+{
+	struct pci_bus *bus = dev->bus;
+	struct resource *res = dev->resource + resno;
+	unsigned int type_mask;
+	int i, ret = -EBUSY;
+
+	type_mask = IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH;
+
+	for (i = 0; i < PCI_BUS_NUM_RESOURCES; i++) {
+		struct resource *r = bus->resource[i];
+		if (!r)
+			continue;
+
+		/* type_mask must match */
+		if ((res->flags ^ r->flags) & type_mask)
+			continue;
+
+		ret = request_resource(r, res);
+
+		if (ret == 0)
+			break;
+	}
+
+	if (ret) {
+		printk(KERN_ERR "PCI: Failed to allocate %s resource #%d:%lx@%lx for %s\n",
+		       res->flags & IORESOURCE_IO ? "I/O" : "mem",
+		       resno, res->end - res->start + 1, res->start, pci_name(dev));
+	} else if (resno < PCI_BRIDGE_RESOURCES) {
+		pci_update_resource(dev, res, resno);
+	}
+
+	return ret;
+}
+
 /* Sort resources by alignment */
 void __devinit
 pdev_sort_resources(struct pci_dev *dev, struct resource_list *head)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index fe1a2b0..0db1e2d 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -460,6 +460,7 @@ int pci_set_dma_mask(struct pci_dev *dev
 int pci_set_consistent_dma_mask(struct pci_dev *dev, u64 mask);
 void pci_update_resource(struct pci_dev *dev, struct resource *res, int resno);
 int pci_assign_resource(struct pci_dev *dev, int i);
+int pci_assign_resource_fixed(struct pci_dev *dev, int i);
 void pci_restore_bars(struct pci_dev *dev);
 
 /* ROM control related routines */

Re: [PATCH]

[Kumar Gala]

Ack, this is what I get for sending patches before I've actually gotten 
up.  The first line was suppose to be the subject line, oh well will 
resend this.

- k

On Fri, 10 Mar 2006, Kumar Gala wrote:

> PCI: Add pci_assign_resource_fixed -- allow fixed address assignments
> 
> On some embedded systems the PCI address for hotplug devices are not only
> known a priori but are required to be at a given PCI address for other
> master in the system to be able to access.
> 
> An example of such a system would be an FPGA which is setup from user space
> after the system has booted.  The FPGA may be access by DSPs in the system
> and those DSPs expect the FPGA at a fixed PCI address.
> 
> Added pci_assign_resource_fixed() as a way to allow assignment of the PCI
> devices's BARs at fixed PCI addresses.
> 
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> 
> ---
> commit 45d4a23317c459865ec740c80b6e2a2ad9f53fd3
> tree 432b5e41ef5f231dd57eb1a98f103239c62d63a0
> parent 8176dee014ec6ad1039b8c0075c9c1d02147c2c8
> author Kumar Gala <galak@kernel.crashing.org> Thu, 09 Mar 2006 12:34:25 -0600
> committer Kumar Gala <galak@kernel.crashing.org> Thu, 09 Mar 2006 12:34:25 -0600
> 
>  drivers/pci/pci.c       |    1 +
>  drivers/pci/setup-res.c |   35 +++++++++++++++++++++++++++++++++++
>  include/linux/pci.h     |    1 +
>  3 files changed, 37 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index d2d1879..2557e86 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -935,6 +935,7 @@ EXPORT_SYMBOL_GPL(pci_intx);
>  EXPORT_SYMBOL(pci_set_dma_mask);
>  EXPORT_SYMBOL(pci_set_consistent_dma_mask);
>  EXPORT_SYMBOL(pci_assign_resource);
> +EXPORT_SYMBOL(pci_assign_resource_fixed);
>  EXPORT_SYMBOL(pci_find_parent_resource);
>  
>  EXPORT_SYMBOL(pci_set_power_state);
> diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
> index ea9277b..f485958 100644
> --- a/drivers/pci/setup-res.c
> +++ b/drivers/pci/setup-res.c
> @@ -155,6 +155,41 @@ int pci_assign_resource(struct pci_dev *
>  	return ret;
>  }
>  
> +int pci_assign_resource_fixed(struct pci_dev *dev, int resno)
> +{
> +	struct pci_bus *bus = dev->bus;
> +	struct resource *res = dev->resource + resno;
> +	unsigned int type_mask;
> +	int i, ret = -EBUSY;
> +
> +	type_mask = IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH;
> +
> +	for (i = 0; i < PCI_BUS_NUM_RESOURCES; i++) {
> +		struct resource *r = bus->resource[i];
> +		if (!r)
> +			continue;
> +
> +		/* type_mask must match */
> +		if ((res->flags ^ r->flags) & type_mask)
> +			continue;
> +
> +		ret = request_resource(r, res);
> +
> +		if (ret == 0)
> +			break;
> +	}
> +
> +	if (ret) {
> +		printk(KERN_ERR "PCI: Failed to allocate %s resource #%d:%lx@%lx for %s\n",
> +		       res->flags & IORESOURCE_IO ? "I/O" : "mem",
> +		       resno, res->end - res->start + 1, res->start, pci_name(dev));
> +	} else if (resno < PCI_BRIDGE_RESOURCES) {
> +		pci_update_resource(dev, res, resno);
> +	}
> +
> +	return ret;
> +}
> +
>  /* Sort resources by alignment */
>  void __devinit
>  pdev_sort_resources(struct pci_dev *dev, struct resource_list *head)
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index fe1a2b0..0db1e2d 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -460,6 +460,7 @@ int pci_set_dma_mask(struct pci_dev *dev
>  int pci_set_consistent_dma_mask(struct pci_dev *dev, u64 mask);
>  void pci_update_resource(struct pci_dev *dev, struct resource *res, int resno);
>  int pci_assign_resource(struct pci_dev *dev, int i);
> +int pci_assign_resource_fixed(struct pci_dev *dev, int i);
>  void pci_restore_bars(struct pci_dev *dev);
>  
>  /* ROM control related routines */
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@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]

[Hagen Paul Pfeifer]

[-- Attachment #1: Type: text/plain, Size: 531 bytes --]


According to dccp draft (draft-ietf-dccp-spec-13.txt) section 5.8.2 (Mandatory
Option) the following patch correct the handling of the following cases:

1) "... and any Mandatory options received on DCCP-Data packets MUST be
   ignored."

2) "The connection is in error and should be reset with Reset Code 5, ...
   if option O is absent (Mandatory was the last byte of the option list), or
   if option O equals Mandatory."


options.c |    7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)

Best regards

Hagen Pfeifer



[-- Attachment #2: mandatory.patch --]
[-- Type: text/plain, Size: 635 bytes --]

diff --git a/net/dccp/options.c b/net/dccp/options.c
index 7d73b33..3db9aad 100644
--- a/net/dccp/options.c
+++ b/net/dccp/options.c
@@ -107,7 +107,8 @@ int dccp_parse_options(struct sock *sk, 
 		case DCCPO_MANDATORY:
 			if (mandatory)
 				goto out_invalid_option;
-			mandatory = 1;
+			if (pkt_type != DCCP_PKT_DATA)
+				mandatory = 1;
 			break;
 		case DCCPO_NDP_COUNT:
 			if (len > 3)
@@ -247,6 +248,10 @@ int dccp_parse_options(struct sock *sk, 
 			mandatory = 0;
 	}
 
+	/* mandatory was the last byte in option list -> reset connection */
+	if (mandatory)
+		goto out_invalid_option;
+
 	return 0;
 
 out_invalid_option:

[PATCH]

[dann frazier]

Here is a resubmittal of Jesse Barnes' fix for generic UP builds, ported
to 2.6.12.  I've boot tested it on an rx2600.

Can someone test on an sn2 system?

diff -urN linux-2.6.12.orig/arch/ia64/kernel/Makefile linux-2.6.12/arch/ia64/kernel/Makefile
--- linux-2.6.12.orig/arch/ia64/kernel/Makefile	2005-06-17 13:48:29.000000000 -0600
+++ linux-2.6.12/arch/ia64/kernel/Makefile	2005-06-18 22:14:35.000000000 -0600
@@ -17,6 +17,7 @@
 obj-$(CONFIG_IOSAPIC)		+= iosapic.o
 obj-$(CONFIG_MODULES)		+= module.o
 obj-$(CONFIG_SMP)		+= smp.o smpboot.o domain.o
+obj-$(CONFIG_NUMA)		+= numa.o
 obj-$(CONFIG_PERFMON)		+= perfmon_default_smpl.o
 obj-$(CONFIG_IA64_CYCLONE)	+= cyclone.o
 obj-$(CONFIG_IA64_MCA_RECOVERY)	+= mca_recovery.o
diff -urN linux-2.6.12.orig/arch/ia64/kernel/acpi.c linux-2.6.12/arch/ia64/kernel/acpi.c
--- linux-2.6.12.orig/arch/ia64/kernel/acpi.c	2005-06-17 13:48:29.000000000 -0600
+++ linux-2.6.12/arch/ia64/kernel/acpi.c	2005-06-18 22:14:35.000000000 -0600
@@ -642,9 +642,11 @@
 			if (smp_boot_data.cpu_phys_id[cpu] != hard_smp_processor_id())
 				node_cpuid[i++].phys_id = smp_boot_data.cpu_phys_id[cpu];
 	}
-	build_cpu_to_node_map();
 # endif
 #endif
+#ifdef CONFIG_ACPI_NUMA
+	build_cpu_to_node_map();
+#endif
 	/* Make boot-up look pretty */
 	printk(KERN_INFO "%d CPUs available, %d CPUs total\n", available_cpus, total_cpus);
 	return 0;
diff -urN linux-2.6.12.orig/arch/ia64/kernel/numa.c linux-2.6.12/arch/ia64/kernel/numa.c
--- linux-2.6.12.orig/arch/ia64/kernel/numa.c	1969-12-31 17:00:00.000000000 -0700
+++ linux-2.6.12/arch/ia64/kernel/numa.c	2005-06-18 22:14:35.000000000 -0600
@@ -0,0 +1,57 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * ia64 kernel NUMA specific stuff
+ *
+ * Copyright (C) 2002 Erich Focht <efocht@ess.nec.de>
+ * Copyright (C) 2004 Silicon Graphics, Inc.
+ *   Jesse Barnes <jbarnes@sgi.com>
+ */
+#include <linux/config.h>
+#include <linux/topology.h>
+#include <linux/module.h>
+#include <asm/processor.h>
+#include <asm/smp.h>
+
+u8 cpu_to_node_map[NR_CPUS] __cacheline_aligned;
+EXPORT_SYMBOL(cpu_to_node_map);
+
+cpumask_t node_to_cpu_mask[MAX_NUMNODES] __cacheline_aligned;
+
+/**
+ * build_cpu_to_node_map - setup cpu to node and node to cpumask arrays
+ *
+ * Build cpu to node mapping and initialize the per node cpu masks using
+ * info from the node_cpuid array handed to us by ACPI.
+ */
+void __init build_cpu_to_node_map(void)
+{
+	int cpu, i, node;
+
+	for(node=0; node < MAX_NUMNODES; node++)
+		cpus_clear(node_to_cpu_mask[node]);
+
+	for(cpu = 0; cpu < NR_CPUS; ++cpu) {
+		node = -1;
+		for (i = 0; i < NR_CPUS; ++i)
+			if (cpu_physical_id(cpu) = node_cpuid[i].phys_id) {
+				node = node_cpuid[i].nid;
+				break;
+			}
+		cpu_to_node_map[cpu] = (node >= 0) ? node : 0;
+		if (node >= 0)
+			cpu_set(cpu, node_to_cpu_mask[node]);
+	}
+}
diff -urN linux-2.6.12.orig/arch/ia64/kernel/smpboot.c linux-2.6.12/arch/ia64/kernel/smpboot.c
--- linux-2.6.12.orig/arch/ia64/kernel/smpboot.c	2005-06-17 13:48:29.000000000 -0600
+++ linux-2.6.12/arch/ia64/kernel/smpboot.c	2005-06-18 22:14:35.000000000 -0600
@@ -524,47 +524,6 @@
 	}
 }
 
-#ifdef CONFIG_NUMA
-
-/* on which node is each logical CPU (one cacheline even for 64 CPUs) */
-u8 cpu_to_node_map[NR_CPUS] __cacheline_aligned;
-EXPORT_SYMBOL(cpu_to_node_map);
-/* which logical CPUs are on which nodes */
-cpumask_t node_to_cpu_mask[MAX_NUMNODES] __cacheline_aligned;
-
-/*
- * Build cpu to node mapping and initialize the per node cpu masks.
- */
-void __init
-build_cpu_to_node_map (void)
-{
-	int cpu, i, node;
-
-	for(node=0; node<MAX_NUMNODES; node++)
-		cpus_clear(node_to_cpu_mask[node]);
-	for(cpu = 0; cpu < NR_CPUS; ++cpu) {
-		/*
-		 * All Itanium NUMA platforms I know use ACPI, so maybe we
-		 * can drop this ifdef completely.                    [EF]
-		 */
-#ifdef CONFIG_ACPI_NUMA
-		node = -1;
-		for (i = 0; i < NR_CPUS; ++i)
-			if (cpu_physical_id(cpu) = node_cpuid[i].phys_id) {
-				node = node_cpuid[i].nid;
-				break;
-			}
-#else
-#		error Fixme: Dunno how to build CPU-to-node map.
-#endif
-		cpu_to_node_map[cpu] = (node >= 0) ? node : 0;
-		if (node >= 0)
-			cpu_set(cpu, node_to_cpu_mask[node]);
-	}
-}
-
-#endif /* CONFIG_NUMA */
-
 /*
  * Cycle through the APs sending Wakeup IPIs to boot each.
  */
diff -urN linux-2.6.12.orig/arch/ia64/mm/discontig.c linux-2.6.12/arch/ia64/mm/discontig.c
--- linux-2.6.12.orig/arch/ia64/mm/discontig.c	2005-06-17 13:48:29.000000000 -0600
+++ linux-2.6.12/arch/ia64/mm/discontig.c	2005-06-18 22:14:35.000000000 -0600
@@ -274,6 +274,33 @@
 }
 
 /**
+ * per_cpu_node_setup - setup per-cpu areas on each node
+ * @cpu_data: per-cpu area on this node
+ * @node: node to setup
+ *
+ * Copy the static per-cpu data into the region we just set aside and then
+ * setup __per_cpu_offset for each CPU on this node.  Return a pointer to
+ * the end of the area.
+ */
+static void *per_cpu_node_setup(void *cpu_data, int node)
+{
+#ifdef CONFIG_SMP
+	int cpu;
+
+	for (cpu = 0; cpu < NR_CPUS; cpu++) {
+		if (node = node_cpuid[cpu].nid) {
+			memcpy(__va(cpu_data), __phys_per_cpu_start,
+			       __per_cpu_end - __per_cpu_start);
+			__per_cpu_offset[cpu] = (char*)__va(cpu_data) -
+				__per_cpu_start;
+			cpu_data += PERCPU_PAGE_SIZE;
+		}
+	}
+#endif
+	return cpu_data;
+}
+
+/**
  * find_pernode_space - allocate memory for memory map and per-node structures
  * @start: physical start of range
  * @len: length of range
@@ -304,7 +331,7 @@
 static int __init find_pernode_space(unsigned long start, unsigned long len,
 				     int node)
 {
-	unsigned long epfn, cpu, cpus, phys_cpus;
+	unsigned long epfn, cpus, phys_cpus;
 	unsigned long pernodesize = 0, pernode, pages, mapsize;
 	void *cpu_data;
 	struct bootmem_data *bdp = &mem_data[node].bootmem_data;
@@ -357,20 +384,7 @@
 		mem_data[node].pgdat->bdata = bdp;
 		pernode += L1_CACHE_ALIGN(sizeof(pg_data_t));
 
-		/*
-		 * Copy the static per-cpu data into the region we
-		 * just set aside and then setup __per_cpu_offset
-		 * for each CPU on this node.
-		 */
-		for (cpu = 0; cpu < NR_CPUS; cpu++) {
-			if (node = node_cpuid[cpu].nid) {
-				memcpy(__va(cpu_data), __phys_per_cpu_start,
-				       __per_cpu_end - __per_cpu_start);
-				__per_cpu_offset[cpu] = (char*)__va(cpu_data) -
-					__per_cpu_start;
-				cpu_data += PERCPU_PAGE_SIZE;
-			}
-		}
+		cpu_data = per_cpu_node_setup(cpu_data, node);
 	}
 
 	return 0;
@@ -436,8 +450,8 @@
  */
 static void __init initialize_pernode_data(void)
 {
-	int cpu, node;
 	pg_data_t *pgdat_list[MAX_NUMNODES];
+	int cpu, node;
 
 	for_each_online_node(node)
 		pgdat_list[node] = mem_data[node].pgdat;
@@ -447,12 +461,22 @@
 		memcpy(mem_data[node].node_data->pg_data_ptrs, pgdat_list,
 		       sizeof(pgdat_list));
 	}
-
+#ifdef CONFIG_SMP
 	/* Set the node_data pointer for each per-cpu struct */
 	for (cpu = 0; cpu < NR_CPUS; cpu++) {
 		node = node_cpuid[cpu].nid;
 		per_cpu(cpu_info, cpu).node_data = mem_data[node].node_data;
 	}
+#else
+	{
+		struct cpuinfo_ia64 *cpu0_cpu_info;
+		cpu = 0;
+		node = node_cpuid[cpu].nid;
+		cpu0_cpu_info = (struct cpuinfo_ia64 *)(__phys_per_cpu_start +
+			((char *)&per_cpu__cpu_info - __per_cpu_start));
+		cpu0_cpu_info->node_data = mem_data[node].node_data;
+	}
+#endif /* CONFIG_SMP */
 }
 
 /**
@@ -519,6 +543,7 @@
 	find_initrd();
 }
 
+#ifdef CONFIG_SMP
 /**
  * per_cpu_init - setup per-cpu variables
  *
@@ -529,15 +554,15 @@
 {
 	int cpu;
 
-	if (smp_processor_id() = 0) {
-		for (cpu = 0; cpu < NR_CPUS; cpu++) {
-			per_cpu(local_per_cpu_offset, cpu) -				__per_cpu_offset[cpu];
-		}
-	}
+	if (smp_processor_id() != 0)
+		return __per_cpu_start + __per_cpu_offset[smp_processor_id()];
+
+	for (cpu = 0; cpu < NR_CPUS; cpu++)
+		per_cpu(local_per_cpu_offset, cpu) = __per_cpu_offset[cpu];
 
 	return __per_cpu_start + __per_cpu_offset[smp_processor_id()];
 }
+#endif /* CONFIG_SMP */
 
 /**
  * show_mem - give short summary of memory stats
diff -urN linux-2.6.12.orig/include/asm-ia64/sn/arch.h linux-2.6.12/include/asm-ia64/sn/arch.h
--- linux-2.6.12.orig/include/asm-ia64/sn/arch.h	2005-06-17 13:48:29.000000000 -0600
+++ linux-2.6.12/include/asm-ia64/sn/arch.h	2005-06-18 22:15:39.000000000 -0600
@@ -11,6 +11,7 @@
 #ifndef _ASM_IA64_SN_ARCH_H
 #define _ASM_IA64_SN_ARCH_H
 
+#include <linux/numa.h>
 #include <asm/types.h>
 #include <asm/percpu.h>
 #include <asm/sn/types.h>
diff -urN linux-2.6.12.orig/include/asm-ia64/sn/sn_cpuid.h linux-2.6.12/include/asm-ia64/sn/sn_cpuid.h
--- linux-2.6.12.orig/include/asm-ia64/sn/sn_cpuid.h	2005-06-17 13:48:29.000000000 -0600
+++ linux-2.6.12/include/asm-ia64/sn/sn_cpuid.h	2005-06-18 22:14:35.000000000 -0600
@@ -81,11 +81,6 @@
  *
  */
 
-#ifndef CONFIG_SMP
-#define cpu_physical_id(cpuid)			((ia64_getreg(_IA64_REG_CR_LID) >> 16) & 0xffff)
-#endif
-
-
 #define get_node_number(addr)			NASID_GET(addr)
 
 /*

-- 
dann frazier <dannf@hp.com>

[PATCH]

[Jan Beulich]

[-- Attachment #1: Type: text/plain, Size: 973 bytes --]

(Note: Patch also attached because the inline version is certain to get
line wrapped.)

When significant delays happen during boot (e.g. with a kernel debugger, but
the problem has also seen in other cases) the timeout for blanking the
console may trigger, but the work scheduler may not have been initialized,
yet. This previously led to a page fault due to a NULL pointer access.

Signed-off-by: Jan Beulich <jbeulich@novell.com>

diff -Npru linux-2.6.12-rc6.base/drivers/char/vt.c linux-2.6.12-rc6/drivers/char/vt.c
--- linux-2.6.12-rc6.base/drivers/char/vt.c	2005-06-15 13:24:51.000000000 +0200
+++ linux-2.6.12-rc6/drivers/char/vt.c	2005-06-15 13:30:39.933774576 +0200
@@ -2867,6 +2867,10 @@ void unblank_screen(void)
  */
 static void blank_screen_t(unsigned long dummy)
 {
+	if (unlikely(!keventd_up())) {
+		mod_timer(&console_timer, jiffies + blankinterval);
+		return;
+	}
 	blank_timer_expired = 1;
 	schedule_work(&console_work);
 }



[-- Attachment #2: linux-2.6.12-rc6-blank-timeout.patch --]
[-- Type: text/plain, Size: 945 bytes --]

(Note: Patch also attached because the inline version is certain to get
line wrapped.)

When significant delays happen during boot (e.g. with a kernel debugger, but
the problem has also seen in other cases) the timeout for blanking the
console may trigger, but the work scheduler may not have been initialized,
yet. This previously led to a page fault due to a NULL pointer access.

Signed-off-by: Jan Beulich <jbeulich@novell.com>

diff -Npru linux-2.6.12-rc6.base/drivers/char/vt.c linux-2.6.12-rc6/drivers/char/vt.c
--- linux-2.6.12-rc6.base/drivers/char/vt.c	2005-06-15 13:24:51.000000000 +0200
+++ linux-2.6.12-rc6/drivers/char/vt.c	2005-06-15 13:30:39.933774576 +0200
@@ -2867,6 +2867,10 @@ void unblank_screen(void)
  */
 static void blank_screen_t(unsigned long dummy)
 {
+	if (unlikely(!keventd_up())) {
+		mod_timer(&console_timer, jiffies + blankinterval);
+		return;
+	}
 	blank_timer_expired = 1;
 	schedule_work(&console_work);
 }

[PATCH]

[Colin Leroy]

[resend - previous mail seem to have lost itself
Hi,

this patch is an RFC patch not to be applied.
It adds MS_SYNCHRONOUS support to FAT filesystem, so that less
filesystem breakage happen when disconnecting an USB key, for 
example. I'd like to have comments about it, because as it 
seems to work fine here, I'm not used to fs drivers and could
have made mistakes.
Thanks,

Signed-off-by: Colin Leroy <colin@colino.net>
--- a/fs/fat/dir.c	2004-11-18 19:42:41.704777744 +0100
+++ b/fs/fat/dir.c	2004-11-18 14:36:44.000000000 +0100
@@ -736,6 +736,7 @@
 {
 	struct buffer_head *bh;
 	struct msdos_dir_entry *de;
+	struct super_block *sb;
 	__le16 date, time;
 
 	bh = fat_extend_dir(dir);
@@ -764,6 +765,11 @@
 	dir->i_atime = dir->i_ctime = dir->i_mtime = CURRENT_TIME;
 	mark_inode_dirty(dir);
 
+	sb = dir->i_sb;
+
+	if (sb->s_flags & MS_SYNCHRONOUS)
+		sync_dirty_buffer(bh);
+
 	return 0;
 }
 
--- a/fs/fat/file.c	2004-10-18 23:53:44.000000000 +0200
+++ b/fs/fat/file.c	2004-11-18 14:57:03.000000000 +0100
@@ -74,21 +74,34 @@
 {
 	struct inode *inode = filp->f_dentry->d_inode;
 	int retval;
+	struct super_block *sb = inode->i_sb;
+	struct buffer_head *bh = NULL;
 
 	retval = generic_file_write(filp, buf, count, ppos);
 	if (retval > 0) {
 		inode->i_mtime = inode->i_ctime = CURRENT_TIME;
 		MSDOS_I(inode)->i_attrs |= ATTR_ARCH;
 		mark_inode_dirty(inode);
+		if (sb->s_flags & MS_SYNCHRONOUS) {
+			bh = sb_bread(sb, MSDOS_SB(sb)->fsinfo_sector);
+			if (bh != NULL) {
+				sync_dirty_buffer(bh);
+				brelse(bh);
+			} else {
+				BUG_ON(1);
+			}
+		}
 	}
 	return retval;
 }
 
 void fat_truncate(struct inode *inode)
 {
+	struct super_block *sb = inode->i_sb;
 	struct msdos_sb_info *sbi = MSDOS_SB(inode->i_sb);
 	const unsigned int cluster_size = sbi->cluster_size;
 	int nr_clusters;
+	struct buffer_head *bh = NULL;
 
 	/* 
 	 * This protects against truncating a file bigger than it was then
@@ -105,4 +118,8 @@
 	unlock_kernel();
 	inode->i_ctime = inode->i_mtime = CURRENT_TIME;
 	mark_inode_dirty(inode);
+	if (sb->s_flags & MS_SYNCHRONOUS) {
+		bh = sb_bread(sb, sbi->fsinfo_sector);
+		sync_dirty_buffer(bh);
+	}
 }
--- a/fs/fat/inode.c	2004-11-18 19:42:41.710776832 +0100
+++ b/fs/fat/inode.c	2004-11-18 15:00:55.000000000 +0100
@@ -1273,8 +1273,12 @@
 	}
 	spin_unlock(&sbi->inode_hash_lock);
 	mark_buffer_dirty(bh);
-	brelse(bh);
 	unlock_kernel();
+
+	if (sb->s_flags & MS_SYNCHRONOUS)
+		sync_dirty_buffer(bh);
+	brelse(bh);
+
 	return 0;
 }

[PATCH]

[Thomas Koeller]

Hi,

I made the 8250 driver work on the internal UART found on
PMC-Sierra RM9000 MIPS CPUs. To do so, I did

- define the register layout, which is different from the standard
  layout, in include/linux/serial_reg.h

- add a new register access type named UPIO_PORT32 for I/O
  registers that must be accessed as 32-bit entities

- add a new port type PORT_RM9000 in include/linux/serial_core.h

While being at it, I also fixed a couple of missing resource
allocations for UPIO_MEM32.

tk


Signed-off-by: Thomas Koeller <thomas.koeller@baslerweb.com>



diff -rpu linux-2.6.9-old/drivers/serial/8250.c linux-2.6.9/drivers/serial/8250.c
--- linux-2.6.9-old/drivers/serial/8250.c	2004-10-28 12:45:30.000000000 +0200
+++ linux-2.6.9/drivers/serial/8250.c	2004-11-04 14:11:42.636338544 +0100
@@ -174,6 +174,7 @@ static const struct serial8250_config ua
 	{ "RSA",	2048,	2048,	UART_CAP_FIFO },
 	{ "NS16550A",	16,	16,	UART_CAP_FIFO | UART_NATSEMI },
 	{ "XScale",	32,	32,	UART_CAP_FIFO },
+	{ "RM9000",	16,	16,	UART_CAP_FIFO }
 };
 
 static _INLINE_ unsigned int serial_in(struct uart_8250_port *up, int offset)
@@ -191,6 +192,9 @@ static _INLINE_ unsigned int serial_in(s
 	case UPIO_MEM32:
 		return readl(up->port.membase + offset);
 
+	case UPIO_PORT32:
+		return inl(up->port.iobase + offset);
+
 	default:
 		return inb(up->port.iobase + offset);
 	}
@@ -215,6 +219,10 @@ serial_out(struct uart_8250_port *up, in
 		writel(value, up->port.membase + offset);
 		break;
 
+	case UPIO_PORT32:
+		outl(value, up->port.iobase + offset);
+		break;
+
 	default:
 		outb(value, up->port.iobase + offset);
 	}
@@ -1624,6 +1633,7 @@ serial8250_request_std_resource(struct u
 	int ret = 0;
 
 	switch (up->port.iotype) {
+	case UPIO_MEM32:
 	case UPIO_MEM:
 		if (up->port.mapbase) {
 			*res = request_mem_region(up->port.mapbase, size, "serial");
@@ -1634,6 +1644,7 @@ serial8250_request_std_resource(struct u
 
 	case UPIO_HUB6:
 	case UPIO_PORT:
+	case UPIO_PORT32:
 		*res = request_region(up->port.iobase, size, "serial");
 		if (!*res)
 			ret = -EBUSY;
@@ -1651,6 +1662,7 @@ serial8250_request_rsa_resource(struct u
 
 	switch (up->port.iotype) {
 	case UPIO_MEM:
+	case UPIO_MEM32:
 		if (up->port.mapbase) {
 			start = up->port.mapbase;
 			start += UART_RSA_BASE << up->port.regshift;
@@ -1662,6 +1674,7 @@ serial8250_request_rsa_resource(struct u
 
 	case UPIO_HUB6:
 	case UPIO_PORT:
+	case UPIO_PORT32:
 		start = up->port.iobase;
 		start += UART_RSA_BASE << up->port.regshift;
 		*res = request_region(start, size, "serial-rsa");
@@ -1687,6 +1700,7 @@ static void serial8250_release_port(stru
 
 	switch (up->port.iotype) {
 	case UPIO_MEM:
+	case UPIO_MEM32:
 		if (up->port.mapbase) {
 			/*
 			 * Unmap the area.
@@ -1704,6 +1718,7 @@ static void serial8250_release_port(stru
 
 	case UPIO_HUB6:
 	case UPIO_PORT:
+	case UPIO_PORT32:
 		start = up->port.iobase;
 
 		if (size)
diff -rpu linux-2.6.9-old/include/linux/serial_core.h linux-2.6.9/include/linux/serial_core.h
--- linux-2.6.9-old/include/linux/serial_core.h	2004-10-28 12:46:02.000000000 +0200
+++ linux-2.6.9/include/linux/serial_core.h	2004-11-04 14:11:42.637338392 +0100
@@ -37,7 +37,8 @@
 #define PORT_RSA	13
 #define PORT_NS16550A	14
 #define PORT_XSCALE	15
-#define PORT_MAX_8250	15	/* max port ID */
+#define PORT_RM9000	16	/* PMC-Sierra RM9xxx internal UART */
+#define PORT_MAX_8250	16	/* max port ID */
 
 /*
  * ARM specific type numbers.  These are not currently guaranteed
@@ -177,6 +178,7 @@ struct uart_port {
 #define UPIO_HUB6		(1)
 #define UPIO_MEM		(2)
 #define UPIO_MEM32		(3)
+#define UPIO_PORT32		(4)
 
 	unsigned int		read_status_mask;	/* driver specific */
 	unsigned int		ignore_status_mask;	/* driver specific */
diff -rpu linux-2.6.9-old/include/linux/serial_reg.h linux-2.6.9/include/linux/serial_reg.h
--- linux-2.6.9-old/include/linux/serial_reg.h	2004-10-28 12:46:03.000000000 +0200
+++ linux-2.6.9/include/linux/serial_reg.h	2004-11-04 14:11:42.638338240 +0100
@@ -14,6 +14,40 @@
 #ifndef _LINUX_SERIAL_REG_H
 #define _LINUX_SERIAL_REG_H
 
+#include <linux/config.h>
+
+#if defined(CONFIG_SERIAL_RM9000)
+
+/*
+ * The internal UART present on PMC-Sierra MIPS RM9000 CPUs
+ * has a different register layout
+ */
+#define UART_RX		0x00	/* In:  Receive buffer (DLAB=0) */
+#define UART_TX		0x04	/* Out: Transmit buffer (DLAB=0) */
+#define UART_DLL	0x08	/* Out: Divisor Latch Low (DLAB=1) */
+
+#define UART_DLM	0x10	/* Out: Divisor Latch High (DLAB=1) */
+#define UART_IER	0x0c	/* Out: Interrupt Enable Register */
+
+#define UART_IIR	0x14	/* In:  Interrupt ID Register */
+#define UART_FCR	0x18	/* Out: FIFO Control Register */
+
+#define UART_LCR	0x1c	/* Out: Line Control Register */
+#define UART_MCR	0x20	/* Out: Modem Control Register */
+#define UART_LSR	0x24	/* In:  Line Status Register */
+#define UART_MSR	0x28	/* In:  Modem Status Register */
+#define UART_SCR	0x2c	/* I/O: Scratch Register */
+
+/* Unimplemented registers */
+#define UART_EFR	0xff	/* I/O: Extended Features Register */
+#define UART_EMSR	0xff	/* (LCR=BF) Extended Mode Select Register */
+
+/* Dummies */
+#define UART_FCTR	1
+#define UART_TRG	0
+
+#else
+
 #define UART_RX		0	/* In:  Receive buffer (DLAB=0) */
 #define UART_TX		0	/* Out: Transmit buffer (DLAB=0) */
 #define UART_DLL	0	/* Out: Divisor Latch Low (DLAB=1) */
@@ -40,6 +74,7 @@
 #define UART_EMSR	7	/* (LCR=BF) Extended Mode Select Register 
 				 * FCTR bit 6 selects SCR or EMSR
 				 * XR16c85x only */
+#endif /* defined(SERIAL_RM9000) */
 
 /*
  * These are the definitions for the FIFO Control Register

-- 
--------------------------------------------------

Thomas Koeller, Software Development
Basler Vision Technologies

thomas dot koeller at baslerweb dot com
http://www.baslerweb.com

==============================

[PATCH]

[Roland McGrath]

This replaces x86-64-singlestep-through-sigreturn-system-call-2.patch
from 2.6.8-rc2-mm2.  The second addition in entry.S is the difference.
This fixes a problem where additional singlesteps immediately after the
singlestep stop after sigreturn would not work right.

Note you might want to rename the patch, since this also has the effect of
making single-stepping of IA32 syscalls work right.


Thanks,
Roland


Signed-off-by: Roland McGrath <roland@redhat.com>

Index: linux-2.6/arch/x86_64/kernel/entry.S
===================================================================
RCS file: /home/roland/redhat/bkcvs/linux-2.5/arch/x86_64/kernel/entry.S,v
retrieving revision 1.22
diff -b -p -u -r1.22 entry.S
--- linux-2.6/arch/x86_64/kernel/entry.S 12 Apr 2004 20:29:12 -0000 1.22
+++ linux-2.6/arch/x86_64/kernel/entry.S 10 Aug 2004 02:34:01 -0000
@@ -297,7 +297,7 @@ int_very_careful:
 	sti
 	SAVE_REST
 	/* Check for syscall exit trace */	
-	testl $(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT),%edx
+	testl $(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SINGLESTEP),%edx
 	jz int_signal
 	pushq %rdi
 	leaq 8(%rsp),%rdi	# &ptregs -> arg1	
@@ -305,6 +305,7 @@ int_very_careful:
 	popq %rdi
 	btr  $TIF_SYSCALL_TRACE,%edi
 	btr  $TIF_SYSCALL_AUDIT,%edi
+	btr  $TIF_SINGLESTEP,%edi
 	jmp int_restore_rest
 	
 int_signal:
Index: linux-2.6/arch/x86_64/kernel/ptrace.c
===================================================================
RCS file: /home/roland/redhat/bkcvs/linux-2.5/arch/x86_64/kernel/ptrace.c,v
retrieving revision 1.16
diff -b -p -u -r1.16 ptrace.c
--- linux-2.6/arch/x86_64/kernel/ptrace.c 31 May 2004 03:07:42 -0000 1.16
+++ linux-2.6/arch/x86_64/kernel/ptrace.c 15 Jul 2004 23:56:44 -0000
@@ -88,6 +88,7 @@ void ptrace_disable(struct task_struct *
 { 
 	long tmp;
 
+	clear_tsk_thread_flag(child, TIF_SINGLESTEP);
 	tmp = get_stack_long(child, EFL_OFFSET) & ~TRAP_FLAG;
 	put_stack_long(child, EFL_OFFSET, tmp);
 }
@@ -344,6 +345,7 @@ asmlinkage long sys_ptrace(long request,
 			set_tsk_thread_flag(child,TIF_SYSCALL_TRACE);
 		else
 			clear_tsk_thread_flag(child,TIF_SYSCALL_TRACE);
+		clear_tsk_thread_flag(child, TIF_SINGLESTEP);
 		child->exit_code = data;
 	/* make sure the single step bit is not set. */
 		tmp = get_stack_long(child, EFL_OFFSET);
@@ -395,6 +397,7 @@ asmlinkage long sys_ptrace(long request,
 		ret = 0;
 		if (child->state == TASK_ZOMBIE)	/* already dead */
 			break;
+		clear_tsk_thread_flag(child, TIF_SINGLESTEP);
 		child->exit_code = SIGKILL;
 		/* make sure the single step bit is not set. */
 		tmp = get_stack_long(child, EFL_OFFSET) & ~TRAP_FLAG;
@@ -416,6 +419,7 @@ asmlinkage long sys_ptrace(long request,
 		}
 		tmp = get_stack_long(child, EFL_OFFSET) | TRAP_FLAG;
 		put_stack_long(child, EFL_OFFSET, tmp);
+		set_tsk_thread_flag(child, TIF_SINGLESTEP);
 		child->exit_code = data;
 		/* give it a chance to run. */
 		wake_up_process(child);
@@ -528,7 +532,8 @@ asmlinkage void syscall_trace_leave(stru
 	if (unlikely(current->audit_context))
 		audit_syscall_exit(current, regs->rax);
 
-	if (test_thread_flag(TIF_SYSCALL_TRACE)
+	if ((test_thread_flag(TIF_SYSCALL_TRACE)
+	     || test_thread_flag(TIF_SINGLESTEP))
 	    && (current->ptrace & PT_PTRACED))
 		syscall_trace(regs);
 }

[patch]

[Luke Kenneth Casson Leighton]

[-- Attachment #1: Type: text/plain, Size: 961 bytes --]

patch to exim4 to get it to change its name when it execve's on:

- transport (-MC)
- smtp in
- alias (-bi)
- initial daemon startup

you have to start exim4 in /etc/init.d/exim4 as exim4-daemon not
exim4.

you'll need to symlink exim4 to exim4-MC, exim4-bi and exim4-in
for "non-selinux" and other testing purposes.

i don't know if it's possible to create domain auto transitions
on a symlink, but if it _was_ then the policy files could,
i imagine, have file_contexts for exim4_mc_exec_t etc just on
the symlinks.

*shrug*.

l.

-- 
-- 
expecting email to be received and understood is a bit like
picking up the telephone and immediately dialing without
checking for a dial-tone; speaking immediately without listening
for either an answer or ring-tone; hanging up immediately and
believing that you have actually started a conversation.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />


[-- Attachment #2: g --]
[-- Type: text/plain, Size: 4438 bytes --]

diff -ru orig/exim-4.34/src/exim.c exim4-4.34/src/exim.c
--- orig/exim-4.34/src/exim.c	2004-05-10 12:31:20.000000000 +0000
+++ exim4-4.34/src/exim.c	2004-06-01 17:22:35.000000000 +0000
@@ -3002,6 +3002,12 @@
     DEBUG(D_exec) debug_printf("exec %.256s %.256s\n", argv[0],
       (argv[1] == NULL)? US"" : argv[1]);
 
+    /* for SE/Linux to write a tiny program to change security domain
+     * specifically to deal with -bi, we change the name to exim-bi.
+     * non-SELinux systems can symbolic link exim-bi to exim.
+     */
+    argv[0] = string_sprintf("%s-bi", argv[0]);
+
     execv(CS argv[0], (char *const *)argv);
     fprintf(stderr, "exim: exec failed: %s\n", strerror(errno));
     exit(EXIT_FAILURE);
diff -ru orig/exim-4.34/src/smtp_in.c exim4-4.34/src/smtp_in.c
--- orig/exim-4.34/src/smtp_in.c	2004-05-10 12:31:20.000000000 +0000
+++ exim4-4.34/src/smtp_in.c	2004-06-01 17:22:35.000000000 +0000
@@ -3372,6 +3372,14 @@
 
       if (!smtp_etrn_serialize || (pid = fork()) == 0)
         {
+	 /* change the name of the daemon to exec to an exim-in instead
+	  * this is so that SE/Linux can create a tiny program that
+	  * sets up a separate security domain for incoming SMTP,
+	  * and of course non-SE/Linux systems can symbolic link exim-in
+	  * to exim.
+	  */
+	 argv[0] = string_sprintf("%s-in", argv[0]);
+
         DEBUG(D_exec) debug_print_argv(argv);
         exim_nullstd();                   /* Ensure std{in,out,err} exist */
         execv(CS argv[0], (char *const *)argv);
Only in exim4-4.34/src: tags
diff -ru orig/exim-4.34/src/transport.c exim4-4.34/src/transport.c
--- orig/exim-4.34/src/transport.c	2004-05-10 12:31:20.000000000 +0000
+++ exim4-4.34/src/transport.c	2004-06-01 17:14:29.000000000 +0000
@@ -1585,6 +1585,12 @@
     close(socket_fd);
     }
 
+  /* for SE/Linux systems we run a tiny program that changes security
+   * domain to deal with transports (exim-MC).
+   * non-SELinux systems can always symbolic link exim-MC to exim
+   */
+  argv[0] = string_sprintf("%s-MC", argv[0]);
+
   DEBUG(D_exec) debug_print_argv(argv);
   exim_nullstd();                          /* Ensure std{out,err} exist */
   execv(CS argv[0], (char *const *)argv);
diff -ru orig/exim-4.34/src/exim.c exim4-4.34/src/exim.c
--- orig/exim-4.34/src/exim.c	2004-05-10 12:31:20.000000000 +0000
+++ exim4-4.34/src/exim.c	2004-06-01 17:22:35.000000000 +0000
@@ -3002,6 +3002,12 @@
     DEBUG(D_exec) debug_printf("exec %.256s %.256s\n", argv[0],
       (argv[1] == NULL)? US"" : argv[1]);
 
+    /* for SE/Linux to write a tiny program to change security domain
+     * specifically to deal with -bi, we change the name to exim-bi.
+     * non-SELinux systems can symbolic link exim-bi to exim.
+     */
+    argv[0] = string_sprintf("%s-bi", argv[0]);
+
     execv(CS argv[0], (char *const *)argv);
     fprintf(stderr, "exim: exec failed: %s\n", strerror(errno));
     exit(EXIT_FAILURE);
diff -ru orig/exim-4.34/src/smtp_in.c exim4-4.34/src/smtp_in.c
--- orig/exim-4.34/src/smtp_in.c	2004-05-10 12:31:20.000000000 +0000
+++ exim4-4.34/src/smtp_in.c	2004-06-01 17:22:35.000000000 +0000
@@ -3372,6 +3372,14 @@
 
       if (!smtp_etrn_serialize || (pid = fork()) == 0)
         {
+	 /* change the name of the daemon to exec to an exim-in instead
+	  * this is so that SE/Linux can create a tiny program that
+	  * sets up a separate security domain for incoming SMTP,
+	  * and of course non-SE/Linux systems can symbolic link exim-in
+	  * to exim.
+	  */
+	 argv[0] = string_sprintf("%s-in", argv[0]);
+
         DEBUG(D_exec) debug_print_argv(argv);
         exim_nullstd();                   /* Ensure std{in,out,err} exist */
         execv(CS argv[0], (char *const *)argv);
Only in exim4-4.34/src: tags
diff -ru orig/exim-4.34/src/transport.c exim4-4.34/src/transport.c
--- orig/exim-4.34/src/transport.c	2004-05-10 12:31:20.000000000 +0000
+++ exim4-4.34/src/transport.c	2004-06-01 17:14:29.000000000 +0000
@@ -1585,6 +1585,12 @@
     close(socket_fd);
     }
 
+  /* for SE/Linux systems we run a tiny program that changes security
+   * domain to deal with transports (exim-MC).
+   * non-SELinux systems can always symbolic link exim-MC to exim
+   */
+  argv[0] = string_sprintf("%s-MC", argv[0]);
+
   DEBUG(D_exec) debug_print_argv(argv);
   exim_nullstd();                          /* Ensure std{out,err} exist */
   execv(CS argv[0], (char *const *)argv);
Only in exim4-4.34/: unpack-configs-stamp

Re: [patch]

[Russell Coker]

On Sun, 6 Jun 2004 02:12, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> patch to exim4 to get it to change its name when it execve's on:
>
> - transport (-MC)
> - smtp in
> - alias (-bi)
> - initial daemon startup

>From a quick inspection it appears that you missed some calls to 
child_exec_exim(), for example the "exim -q" operation when starting exim.

> i don't know if it's possible to create domain auto transitions
> on a symlink, but if it _was_ then the policy files could,
> i imagine, have file_contexts for exim4_mc_exec_t etc just on
> the symlinks.

No, domain_auto_trans() rules only apply to the executables and to script 
files (but generally don't do transitions on scripts).

For SE Linux we need small executables that will exec exim4 with the same 
parameters to give the domain transition.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch]

[Luke Kenneth Casson Leighton]

On Sun, Jun 06, 2004 at 06:14:50PM +1000, Russell Coker wrote:
> On Sun, 6 Jun 2004 02:12, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > patch to exim4 to get it to change its name when it execve's on:
> >
> > - transport (-MC)
> > - smtp in
> > - alias (-bi)
> > - initial daemon startup
> 
> From a quick inspection it appears that you missed some calls to 
> child_exec_exim(), for example the "exim -q" operation when starting exim.
 
 oh, drat :)

 thanks - that's the sort of thing i needed to know.

 ... ah, yes, you're right!  _sometimes_ it does an execv inside
 child_exec_exim and sometimes it doesn't.  *sigh*.



> > i don't know if it's possible to create domain auto transitions
> > on a symlink, but if it _was_ then the policy files could,
> > i imagine, have file_contexts for exim4_mc_exec_t etc just on
> > the symlinks.
> 
> No, domain_auto_trans() rules only apply to the executables and to script 
> files (but generally don't do transitions on scripts).
> 
> For SE Linux we need small executables that will exec exim4 with the same 
> parameters to give the domain transition.

 ack.

 i haven't changed any of the parameters, so you'd still get
 exim-bi -bi ... and exim-MC -MC .... etc.

 l.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [patch]

[Russell Coker]

On Sun, 6 Jun 2004 20:48, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > > - transport (-MC)
> > > - smtp in
> > > - alias (-bi)
> > > - initial daemon startup
> >
> > From a quick inspection it appears that you missed some calls to
> > child_exec_exim(), for example the "exim -q" operation when starting
> > exim.
>
>  oh, drat :)
>
>  thanks - that's the sort of thing i needed to know.
>
>  ... ah, yes, you're right!  _sometimes_ it does an execv inside
>  child_exec_exim and sometimes it doesn't.  *sigh*.

Well child_exec_exim() has code to check the main parameter for the purpose of 
error logging.  It shouldn't be difficult to add some code in that checks the 
parameter against a table to determine what (if anything) to append to the 
command name.

> > For SE Linux we need small executables that will exec exim4 with the same
> > parameters to give the domain transition.
>
>  ack.
>
>  i haven't changed any of the parameters, so you'd still get
>  exim-bi -bi ... and exim-MC -MC .... etc.

Yes, so the following code should be all that's needed for a minimal 
implementation.  It may be necessary to have the code check that argv[1] is 
appropriate for the domain that the new instance of exim4 is to be run in, 
but I'm not certain about that (we can do it later if necessary).  Also we 
need something similar for runq etc.

int main(int argc, char **argv, char **envp)
{
  return execve("/usr/sbin/exim4", argv, envp);
}

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[PATCH]

[Bart De Schuymer]

Hi Dave,

We should also filter vlan-tagged IP/ARP traffic even if the vlan code
isn't compiled into the kernel. The patch below removes an unnecessary
dependence on the vlan code being compiled.

cheers,
Bart


--- linux-2.6.0/include/linux/netfilter_bridge.h.earlier	2003-12-25 17:01:38.000000000 +0100
+++ linux-2.6.0/include/linux/netfilter_bridge.h	2003-12-25 17:02:56.000000000 +0100
@@ -71,12 +71,10 @@ static inline
 void nf_bridge_maybe_copy_header(struct sk_buff *skb)
 {
 	if (skb->nf_bridge) {
-#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
 		if (skb->protocol == __constant_htons(ETH_P_8021Q)) {
 			memcpy(skb->data - 18, skb->nf_bridge->data, 18);
 			skb_push(skb, 4);
 		} else
-#endif
 			memcpy(skb->data - 16, skb->nf_bridge->data, 16);
 	}
 }
@@ -86,10 +84,9 @@ void nf_bridge_save_header(struct sk_buf
 {
         int header_size = 16;
 
-#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
 	if (skb->protocol == __constant_htons(ETH_P_8021Q))
 		header_size = 18;
-#endif
+
 	memcpy(skb->nf_bridge->data, skb->data - header_size, header_size);
 }
 

[PATCH]

[Stephen Hemminger]

This is the update to Al viro's changes to probing to have all
network devices use dynamic allocation.  The patches are against
net-drivers-2.5-exp.

[PATCH]

[Mark Hemment]

  For RPC over UDP, after receiving a packet kick another thread as soon
as possible.  This helps NFS performance.
  Patch is against 2.6.0-test3.

Mark


diff -urNp linux-2.6.0-test3/net/sunrpc/svcsock.c linux-2.6.0-test3-sunrpc/net/sunrpc/svcsock.c
--- linux-2.6.0-test3/net/sunrpc/svcsock.c	2003-08-09 05:32:33.000000000 +0100
+++ linux-2.6.0-test3-sunrpc/net/sunrpc/svcsock.c	2003-08-17 19:42:58.000000000 +0100
@@ -578,8 +578,14 @@ svc_udp_recvfrom(struct svc_rqst *rqstp)
 		/* possibly an icmp error */
 		dprintk("svc: recvfrom returned error %d\n", -err);
 	}
+	svsk->sk_sk->sk_stamp = skb->stamp;
 	set_bit(SK_DATA, &svsk->sk_flags); /* there may be more data... */

+	/*
+	 * Maybe more packets - kick another thread ASAP.
+	 */
+	svc_sock_received(svsk);
+
 	len  = skb->len - sizeof(struct udphdr);
 	rqstp->rq_arg.len = len;

@@ -590,8 +596,6 @@ svc_udp_recvfrom(struct svc_rqst *rqstp)
 	rqstp->rq_addr.sin_port = skb->h.uh->source;
 	rqstp->rq_addr.sin_addr.s_addr = skb->nh.iph->saddr;

-	svsk->sk_sk->sk_stamp = skb->stamp;
-
 	if (skb_is_nonlinear(skb)) {
 		/* we have to copy */
 		local_bh_disable();
@@ -599,7 +603,6 @@ svc_udp_recvfrom(struct svc_rqst *rqstp)
 			local_bh_enable();
 			/* checksum error */
 			skb_free_datagram(svsk->sk_sk, skb);
-			svc_sock_received(svsk);
 			return 0;
 		}
 		local_bh_enable();
@@ -611,7 +614,6 @@ svc_udp_recvfrom(struct svc_rqst *rqstp)
 		if (skb->ip_summed != CHECKSUM_UNNECESSARY) {
 			if ((unsigned short)csum_fold(skb_checksum(skb, 0, skb->len, skb->csum))) {
 				skb_free_datagram(svsk->sk_sk, skb);
-				svc_sock_received(svsk);
 				return 0;
 			}
 			skb->ip_summed = CHECKSUM_UNNECESSARY;
@@ -631,9 +633,6 @@ svc_udp_recvfrom(struct svc_rqst *rqstp)
 	if (serv->sv_stats)
 		serv->sv_stats->netudpcnt++;

-	/* One down, maybe more to go... */
-	svc_sock_received(svsk);
-
 	return len;
 }




-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH]

[Neil Brown]

On Monday August 18, markhe@veritas.com wrote:
>   For RPC over UDP, after receiving a packet kick another thread as soon
> as possible.  This helps NFS performance.
>   Patch is against 2.6.0-test3.
> 

Yep, I like this.  I'll send it on.

Have you measured any performance improvement, or it is just
theoretical?

NeilBrown


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

[PATCH]

[davej]

>From Dave Richards (drichards@mahinetworks.com)

While diagnosing an MMX/FPU problem I found a minor problem in the code
which diagnoses and generates signals for FPU exceptions. On x86 Stack
Fault Exception are a subclass of Invalid Operation. Thus, the FPU status
register will have both the SF and IF bits set when a stack fault occurs.
The code which turns FPU exceptions into signals was assuming IF would be
clear:

diff -urpN --exclude-from=/home/davej/.exclude bk-linus/arch/i386/kernel/traps.c linux-2.5/arch/i386/kernel/traps.c
--- bk-linus/arch/i386/kernel/traps.c	2003-06-26 19:49:20.000000000 +0100
+++ linux-2.5/arch/i386/kernel/traps.c	2003-06-26 20:11:29.000000000 +0100
@@ -629,9 +629,10 @@ void math_error(void *eip)
 		default:
 			break;
 		case 0x001: /* Invalid Op */
-		case 0x040: /* Stack Fault */
-		case 0x240: /* Stack Fault | Direction */
+		case 0x041: /* Stack Fault */
+		case 0x241: /* Stack Fault | Direction */
 			info.si_code = FPE_FLTINV;
+			/* Should we clear the SF or let user space do it ???? */
 			break;
 		case 0x002: /* Denormalize */
 		case 0x010: /* Underflow */

[patch]

[Adrian Bunk]

gcc 3.3 correctly gives the following warning:

<--  snip  -->

...
  CC      drivers/mtd/ftl.o
drivers/mtd/ftl.c: In function `scan_header':
drivers/mtd/ftl.c:191: warning: comparison is always false due to 
limited range 
...

<--  snip  -->

Looking at the code it seems gcc is correct, a 16bit number can _never_
be > 65536.

The following patch removes this comparison:


--- linux-2.6.0-test2-full/drivers/mtd/ftl.c.old	2003-07-30 13:04:05.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/mtd/ftl.c	2003-07-30 13:04:13.000000000 +0200
@@ -188,7 +188,7 @@
 	printk(KERN_NOTICE "ftl_cs: FTL header not found.\n");
 	return -ENOENT;
     }
-    if ((le16_to_cpu(header.NumEraseUnits) > 65536) || header.BlockSize != 9 ||
+    if (header.BlockSize != 9 ||
 	(header.EraseUnitSize < 10) || (header.EraseUnitSize > 31) ||
 	(header.NumTransferUnits >= le16_to_cpu(header.NumEraseUnits))) {
 	printk(KERN_NOTICE "ftl_cs: FTL header corrupt!\n");



I've tested the compilation with 2.6.0-test2 and 2.4.22-pre9.


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

[patch]

[Adrian Bunk]

gcc 3.3 correctly gives the following warning:

<--  snip  -->

...
  CC      drivers/mtd/ftl.o
drivers/mtd/ftl.c: In function `scan_header':
drivers/mtd/ftl.c:191: warning: comparison is always false due to 
limited range 
...

<--  snip  -->

Looking at the code it seems gcc is correct, a 16bit number can _never_
be > 65536.

The following patch removes this comparison:


--- linux-2.6.0-test2-full/drivers/mtd/ftl.c.old	2003-07-30 13:04:05.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/mtd/ftl.c	2003-07-30 13:04:13.000000000 +0200
@@ -188,7 +188,7 @@
 	printk(KERN_NOTICE "ftl_cs: FTL header not found.\n");
 	return -ENOENT;
     }
-    if ((le16_to_cpu(header.NumEraseUnits) > 65536) || header.BlockSize != 9 ||
+    if (header.BlockSize != 9 ||
 	(header.EraseUnitSize < 10) || (header.EraseUnitSize > 31) ||
 	(header.NumTransferUnits >= le16_to_cpu(header.NumEraseUnits))) {
 	printk(KERN_NOTICE "ftl_cs: FTL header corrupt!\n");



I've tested the compilation with 2.6.0-test2 and 2.4.22-pre9.


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

[PATCH]

[Stephen Hemminger]

Convert Digi RigtSwitch to use alloc_etherdev.

Builds (on 2.5.74) but once again, do not have real hardware to test.

diff -Nru a/drivers/net/dgrs.c b/drivers/net/dgrs.c
--- a/drivers/net/dgrs.c	Mon Jul  7 14:50:36 2003
+++ b/drivers/net/dgrs.c	Mon Jul  7 14:50:36 2003
@@ -1252,18 +1252,12 @@
 {
 	DGRS_PRIV	*priv;
 	struct net_device *dev, *aux;
-
-	/* Allocate and fill new device structure. */
-	int dev_size = sizeof(struct net_device) + sizeof(DGRS_PRIV);
 	int i, ret;
 
-	dev = (struct net_device *) kmalloc(dev_size, GFP_KERNEL);
-
+	dev = alloc_etherdev(sizeof(DGRS_PRIV));
 	if (!dev)
 		return -ENOMEM;
 
-	memset(dev, 0, dev_size);
-	dev->priv = ((void *)dev) + sizeof(struct net_device);
 	priv = (DGRS_PRIV *)dev->priv;
 
 	dev->base_addr = io;
@@ -1279,7 +1273,7 @@
 
 	dev->init = dgrs_probe1;
 	SET_MODULE_OWNER(dev);
-	ether_setup(dev);
+
 	if (register_netdev(dev) != 0) {
 		kfree(dev);
 		return -EIO;
@@ -1302,15 +1296,18 @@
 		struct net_device	*devN;
 		DGRS_PRIV	*privN;
 			/* Allocate new dev and priv structures */
-		devN = (struct net_device *) kmalloc(dev_size, GFP_KERNEL);
-			/* Make it an exact copy of dev[0]... */
+		devN = alloc_etherdev(sizeof(DGRS_PRIV));
 		ret = -ENOMEM;
 		if (!devN) 
 			goto fail;
-		memcpy(devN, dev, dev_size);
-		memset(devN->name, 0, sizeof(devN->name));
-		devN->priv = ((void *)devN) + sizeof(struct net_device);
+
+		/* Make it an exact copy of dev[0]... */
+		*devN = *dev;
+
+		/* copy the priv structure of dev[0] */
 		privN = (DGRS_PRIV *)devN->priv;
+		*privN = *priv;
+
 			/* ... and zero out VM areas */
 		privN->vmem = 0;
 		privN->vplxdma = 0;
@@ -1318,9 +1315,11 @@
 		devN->irq = 0;
 			/* ... and base MAC address off address of 1st port */
 		devN->dev_addr[5] += i;
+			/* ... choose a new name */
+		strncpy(devN->name, "eth%d", IFNAMSIZ);
 		devN->init = dgrs_initclone;
 		SET_MODULE_OWNER(devN);
-		ether_setup(devN);
+
 		ret = -EIO;
 		if (register_netdev(devN)) {
 			kfree(devN);

[PATCH]:

[Juan Quintela]

Hi
        - pte_val() returs a long, print it directly.
        - flags needs to be unsigedn long, not unsigned int.

Later, Juan.


Later, Juan.

Index: arch/mips64/mm/tlb-r4k.c
===================================================================
RCS file: /home/cvs/linux/arch/mips64/mm/tlb-r4k.c,v
retrieving revision 1.1.2.5
diff -u -r1.1.2.5 tlb-r4k.c
--- arch/mips64/mm/tlb-r4k.c	2 Dec 2002 00:24:53 -0000	1.1.2.5
+++ arch/mips64/mm/tlb-r4k.c	19 Dec 2002 19:48:44 -0000
@@ -244,7 +244,7 @@
 	pmd = pmd_offset(pgd, addr);
 	pte = pte_offset(pmd, addr);
 	page = *pte;
-	printk("Memory Mapping: VA = %08x, PA = %08x ", addr, (unsigned int) pte_val(page));
+	printk("Memory Mapping: VA = %08x, PA = %08x ", addr, pte_val(page));
 	val = pte_val(page);
 	if (val & _PAGE_PRESENT) printk("present ");
 	if (val & _PAGE_READ) printk("read ");
@@ -259,7 +259,7 @@
 
 void show_tlb(void)
 {
-        unsigned int flags;
+        unsigned long flags;
         unsigned int old_ctx;
 	unsigned int entry;
 	unsigned int entrylo0, entrylo1, entryhi;


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

Re: [PATCH]:

[Maciej W. Rozycki]

On 19 Dec 2002, Juan Quintela wrote:

>         - pte_val() returs a long, print it directly.
[...]
> -	printk("Memory Mapping: VA = %08x, PA = %08x ", addr, (unsigned int) pte_val(page));
> +	printk("Memory Mapping: VA = %08x, PA = %08x ", addr, pte_val(page));

 Well, I guess you need "%08lx" then.  For both formats, actually.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [PATCH]:

[Juan Quintela]

>>>>> "maciej" == Maciej W Rozycki <macro@ds2.pg.gda.pl> writes:

maciej> On 19 Dec 2002, Juan Quintela wrote:
>> - pte_val() returs a long, print it directly.
maciej> [...]
>> -	printk("Memory Mapping: VA = %08x, PA = %08x ", addr, (unsigned int) pte_val(page));
>> +	printk("Memory Mapping: VA = %08x, PA = %08x ", addr, pte_val(page));

maciej> Well, I guess you need "%08lx" then.  For both formats, actually.

Arghhhhhhhh, wrong patch, 
Ralf, don't apply, appy this other:

Sorry for the inconvenience, just diff the wrong tree :(

Later, Juan.

Index: arch/mips64/mm/tlb-r4k.c
===================================================================
RCS file: /home/cvs/linux/arch/mips64/mm/tlb-r4k.c,v
retrieving revision 1.1.2.5
diff -u -r1.1.2.5 tlb-r4k.c
--- arch/mips64/mm/tlb-r4k.c	2 Dec 2002 00:24:53 -0000	1.1.2.5
+++ arch/mips64/mm/tlb-r4k.c	19 Dec 2002 21:03:09 -0000
@@ -244,7 +244,7 @@
 	pmd = pmd_offset(pgd, addr);
 	pte = pte_offset(pmd, addr);
 	page = *pte;
-	printk("Memory Mapping: VA = %08x, PA = %08x ", addr, (unsigned int) pte_val(page));
+	printk("Memory Mapping: VA = %08lx, PA = %08lx ", addr, pte_val(page));
 	val = pte_val(page);
 	if (val & _PAGE_PRESENT) printk("present ");
 	if (val & _PAGE_READ) printk("read ");
@@ -259,7 +259,7 @@
 
 void show_tlb(void)
 {
-        unsigned int flags;
+        unsigned long flags;
         unsigned int old_ctx;
 	unsigned int entry;
 	unsigned int entrylo0, entrylo1, entryhi;


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[PATCH]:

[Juan Quintela]

Hi
        ArcRead() usses funny types :(

Later, Juan.a

PD. Someone can explain me what mean:
    __attribute__ ((__mode__ (__SI__)));

    The SI part don't appear in the gcc info pages :(

Index: arch/mips/sgi-ip22/ip22-time.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/sgi-ip22/ip22-time.c,v
retrieving revision 1.1.2.10
diff -u -r1.1.2.10 ip22-time.c
--- arch/mips/sgi-ip22/ip22-time.c	2 Dec 2002 00:24:50 -0000	1.1.2.10
+++ arch/mips/sgi-ip22/ip22-time.c	18 Dec 2002 00:49:20 -0000
@@ -195,7 +195,7 @@
 {
 	int cpu = smp_processor_id();
 	int irq = SGI_8254_0_IRQ;
-	long cnt;
+	ULONG cnt;
 	char c;
 
 	irq_enter(cpu, irq);


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

Re: [PATCH]:

[Ralf Baechle]

On Wed, Dec 18, 2002 at 02:42:25AM +0100, Juan Quintela wrote:

> PD. Someone can explain me what mean:
>     __attribute__ ((__mode__ (__SI__)));
> 
>     The SI part don't appear in the gcc info pages :(

Single Integer, a 32-bit integer.

  Ralf

Re: [PATCH]:

[Juan Quintela]

>>>>> "ralf" == Ralf Baechle <ralf@linux-mips.org> writes:

ralf> On Wed, Dec 18, 2002 at 02:42:25AM +0100, Juan Quintela wrote:
>> PD. Someone can explain me what mean:
>> __attribute__ ((__mode__ (__SI__)));
>> 
>> The SI part don't appear in the gcc info pages :(

ralf> Single Integer, a 32-bit integer.

Changing the code to u32 & friends will be acepted?

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

Re: [PATCH]:

[Ralf Baechle]

On Wed, Dec 18, 2002 at 10:41:03PM +0100, Juan Quintela wrote:

> ralf> On Wed, Dec 18, 2002 at 02:42:25AM +0100, Juan Quintela wrote:
> >> PD. Someone can explain me what mean:
> >> __attribute__ ((__mode__ (__SI__)));
> >> 
> >> The SI part don't appear in the gcc info pages :(
> 
> ralf> Single Integer, a 32-bit integer.
> 
> Changing the code to u32 & friends will be acepted?

Yes.

  Ralf

[PATCH]

[Paul Mackerras]

Linus,

This patch is a forward-port from 2.4.  It changes the pcmcia resource
allocation code so that it allocates IO and memory resources from the
correct resource parent.  The details were discussed on lkml last year
in the 2.4 context.  I need this on powerbooks because they have
multiple PCI host bridges.  Please apply this to your tree.

Paul.

diff -urN linux-2.5/drivers/pcmcia/cistpl.c pmac-2.5/drivers/pcmcia/cistpl.c
--- linux-2.5/drivers/pcmcia/cistpl.c	Tue Feb  5 18:55:14 2002
+++ pmac-2.5/drivers/pcmcia/cistpl.c	Sun Jul 21 14:01:56 2002
@@ -264,11 +264,11 @@
 	(s->cis_mem.sys_start == 0)) {
 	int low = !(s->cap.features & SS_CAP_PAGE_REGS);
 	vs = s;
-	validate_mem(cis_readable, checksum_match, low);
+	validate_mem(cis_readable, checksum_match, low, s);
 	s->cis_mem.sys_start = 0;
 	vs = NULL;
 	if (find_mem_region(&s->cis_mem.sys_start, s->cap.map_size,
-			    s->cap.map_size, low, "card services")) {
+			    s->cap.map_size, low, "card services", s)) {
 	    printk(KERN_NOTICE "cs: unable to map card memory!\n");
 	    return CS_OUT_OF_RESOURCE;
 	}
diff -urN linux-2.5/drivers/pcmcia/cs.c pmac-2.5/drivers/pcmcia/cs.c
--- linux-2.5/drivers/pcmcia/cs.c	Tue Feb  5 18:55:14 2002
+++ pmac-2.5/drivers/pcmcia/cs.c	Sat Jul 20 20:41:46 2002
@@ -809,7 +809,7 @@
 	    return 1;
     for (i = 0; i < MAX_IO_WIN; i++) {
 	if (s->io[i].NumPorts == 0) {
-	    if (find_io_region(base, num, align, name) == 0) {
+	    if (find_io_region(base, num, align, name, s) == 0) {
 		s->io[i].Attributes = attr;
 		s->io[i].BasePort = *base;
 		s->io[i].NumPorts = s->io[i].InUse = num;
@@ -821,7 +821,7 @@
 	/* Try to extend top of window */
 	try = s->io[i].BasePort + s->io[i].NumPorts;
 	if ((*base == 0) || (*base == try))
-	    if (find_io_region(&try, num, 0, name) == 0) {
+	    if (find_io_region(&try, num, 0, name, s) == 0) {
 		*base = try;
 		s->io[i].NumPorts += num;
 		s->io[i].InUse += num;
@@ -830,7 +830,7 @@
 	/* Try to extend bottom of window */
 	try = s->io[i].BasePort - num;
 	if ((*base == 0) || (*base == try))
-	    if (find_io_region(&try, num, 0, name) == 0) {
+	    if (find_io_region(&try, num, 0, name, s) == 0) {
 		s->io[i].BasePort = *base = try;
 		s->io[i].NumPorts += num;
 		s->io[i].InUse += num;
@@ -1974,7 +1974,7 @@
 	find_mem_region(&win->base, win->size, align,
 			(req->Attributes & WIN_MAP_BELOW_1MB) ||
 			!(s->cap.features & SS_CAP_PAGE_REGS),
-			(*handle)->dev_info))
+			(*handle)->dev_info, s))
 	return CS_IN_USE;
     (*handle)->state |= CLIENT_WIN_REQ(w);
 
diff -urN linux-2.5/drivers/pcmcia/cs_internal.h pmac-2.5/drivers/pcmcia/cs_internal.h
--- linux-2.5/drivers/pcmcia/cs_internal.h	Wed Feb  6 04:40:18 2002
+++ pmac-2.5/drivers/pcmcia/cs_internal.h	Sat Jul 20 20:38:06 2002
@@ -238,11 +238,11 @@
 
 /* In rsrc_mgr */
 void validate_mem(int (*is_valid)(u_long), int (*do_cksum)(u_long),
-		  int force_low);
+		  int force_low, socket_info_t *s);
 int find_io_region(ioaddr_t *base, ioaddr_t num, ioaddr_t align,
-		   char *name);
+		   char *name, socket_info_t *s);
 int find_mem_region(u_long *base, u_long num, u_long align,
-		    int force_low, char *name);
+		    int force_low, char *name, socket_info_t *s);
 int try_irq(u_int Attributes, int irq, int specific);
 void undo_irq(u_int Attributes, int irq);
 int adjust_resource_info(client_handle_t handle, adjust_t *adj);
diff -urN linux-2.5/drivers/pcmcia/rsrc_mgr.c pmac-2.5/drivers/pcmcia/rsrc_mgr.c
--- linux-2.5/drivers/pcmcia/rsrc_mgr.c	Tue Feb  5 18:55:14 2002
+++ pmac-2.5/drivers/pcmcia/rsrc_mgr.c	Sun Jul 21 14:02:02 2002
@@ -44,6 +44,7 @@
 #include <linux/ioport.h>
 #include <linux/timer.h>
 #include <linux/proc_fs.h>
+#include <linux/pci.h>
 #include <asm/irq.h>
 #include <asm/io.h>
 
@@ -103,8 +104,82 @@
 
 ======================================================================*/
 
-#define check_io_resource(b,n)	check_resource(&ioport_resource, (b), (n))
-#define check_mem_resource(b,n)	check_resource(&iomem_resource, (b), (n))
+static struct resource *resource_parent(unsigned long b, unsigned long n,
+					int flags, struct pci_dev *dev)
+{
+#ifdef CONFIG_PCI
+	struct resource res, *pr;
+
+	if (dev != NULL) {
+		res.start = b;
+		res.end = b + n - 1;
+		res.flags = flags;
+		pr = pci_find_parent_resource(dev, &res);
+		if (pr)
+			return pr;
+	}
+#endif /* CONFIG_PCI */
+	if (flags & IORESOURCE_MEM)
+		return &iomem_resource;
+	return &ioport_resource;
+}
+
+static inline int check_io_resource(unsigned long b, unsigned long n,
+				    struct pci_dev *dev)
+{
+	return check_resource(resource_parent(b, n, IORESOURCE_IO, dev), b, n);
+}
+
+static inline int check_mem_resource(unsigned long b, unsigned long n,
+				     struct pci_dev *dev)
+{
+	return check_resource(resource_parent(b, n, IORESOURCE_MEM, dev), b, n);
+}
+
+static struct resource *make_resource(unsigned long b, unsigned long n,
+				      int flags, char *name)
+{
+	struct resource *res = kmalloc(sizeof(*res), GFP_KERNEL);
+
+	if (res) {
+		memset(res, 0, sizeof(*res));
+		res->name = name;
+		res->start = b;
+		res->end = b + n - 1;
+		res->flags = flags | IORESOURCE_BUSY;
+	}
+	return res;
+}
+
+static int request_io_resource(unsigned long b, unsigned long n,
+			       char *name, struct pci_dev *dev)
+{
+	struct resource *res = make_resource(b, n, IORESOURCE_IO, name);
+	struct resource *pr = resource_parent(b, n, IORESOURCE_IO, dev);
+	int err = -ENOMEM;
+
+	if (res) {
+		err = request_resource(pr, res);
+		if (err)
+			kfree(res);
+	}
+	return err;
+}
+
+static int request_mem_resource(unsigned long b, unsigned long n,
+				char *name, struct pci_dev *dev)
+{
+	struct resource *res = make_resource(b, n, IORESOURCE_MEM, name);
+	struct resource *pr = resource_parent(b, n, IORESOURCE_MEM, dev);
+	int err = -ENOMEM;
+
+	if (res) {
+		err = request_resource(pr, res);
+		if (err)
+			kfree(res);
+	}
+	return err;
+}
 
 /*======================================================================
 
@@ -194,7 +269,7 @@
     }   
     memset(b, 0, 256);
     for (i = base, most = 0; i < base+num; i += 8) {
-	if (check_io_resource(i, 8))
+	if (check_io_resource(i, 8, NULL))
 	    continue;
 	hole = inb(i);
 	for (j = 1; j < 8; j++)
@@ -207,7 +282,7 @@
 
     bad = any = 0;
     for (i = base; i < base+num; i += 8) {
-	if (check_io_resource(i, 8))
+	if (check_io_resource(i, 8, NULL))
 	    continue;
 	for (j = 0; j < 8; j++)
 	    if (inb(i+j) != most) break;
@@ -247,7 +322,8 @@
 ======================================================================*/
 
 static int do_mem_probe(u_long base, u_long num,
-			int (*is_valid)(u_long), int (*do_cksum)(u_long))
+			int (*is_valid)(u_long), int (*do_cksum)(u_long),
+			socket_info_t *s)
 {
     u_long i, j, bad, fail, step;
 
@@ -258,13 +334,14 @@
     for (i = j = base; i < base+num; i = j + step) {
 	if (!fail) {	
 	    for (j = i; j < base+num; j += step)
-		if ((check_mem_resource(j, step) == 0) && is_valid(j))
+		if ((check_mem_resource(j, step, s->cap.cb_dev) == 0) &&
+		    is_valid(j))
 		    break;
 	    fail = ((i == base) && (j == base+num));
 	}
 	if (fail) {
 	    for (j = i; j < base+num; j += 2*step)
-		if ((check_mem_resource(j, 2*step) == 0) &&
+		if ((check_mem_resource(j, 2*step, s->cap.cb_dev) == 0) &&
 		    do_cksum(j) && do_cksum(j+step))
 		    break;
 	}
@@ -283,12 +360,12 @@
 
 static u_long inv_probe(int (*is_valid)(u_long),
 			int (*do_cksum)(u_long),
-			resource_map_t *m)
+			resource_map_t *m, socket_info_t *s)
 {
     u_long ok;
     if (m == &mem_db)
 	return 0;
-    ok = inv_probe(is_valid, do_cksum, m->next);
+    ok = inv_probe(is_valid, do_cksum, m->next, s);
     if (ok) {
 	if (m->base >= 0x100000)
 	    sub_interval(&mem_db, m->base, m->num);
@@ -296,11 +373,11 @@
     }
     if (m->base < 0x100000)
 	return 0;
-    return do_mem_probe(m->base, m->num, is_valid, do_cksum);
+    return do_mem_probe(m->base, m->num, is_valid, do_cksum, s);
 }
 
 void validate_mem(int (*is_valid)(u_long), int (*do_cksum)(u_long),
-		  int force_low)
+		  int force_low, socket_info_t *s)
 {
     resource_map_t *m, *n;
     static u_char order[] = { 0xd0, 0xe0, 0xc0, 0xf0 };
@@ -310,7 +387,7 @@
     if (!probe_mem) return;
     /* We do up to four passes through the list */
     if (!force_low) {
-	if (hi++ || (inv_probe(is_valid, do_cksum, mem_db.next) > 0))
+	if (hi++ || (inv_probe(is_valid, do_cksum, mem_db.next, s) > 0))
 	    return;
 	printk(KERN_NOTICE "cs: warning: no high memory space "
 	       "available!\n");
@@ -321,7 +398,7 @@
 	/* Only probe < 1 MB */
 	if (m->base >= 0x100000) continue;
 	if ((m->base | m->num) & 0xffff) {
-	    ok += do_mem_probe(m->base, m->num, is_valid, do_cksum);
+	    ok += do_mem_probe(m->base, m->num, is_valid, do_cksum, s);
 	    continue;
 	}
 	/* Special probe for 64K-aligned block */
@@ -331,7 +408,7 @@
 		if (ok >= mem_limit)
 		    sub_interval(&mem_db, b, 0x10000);
 		else
-		    ok += do_mem_probe(b, 0x10000, is_valid, do_cksum);
+		    ok += do_mem_probe(b, 0x10000, is_valid, do_cksum, s);
 	    }
 	}
     }
@@ -340,7 +417,7 @@
 #else /* CONFIG_ISA */
 
 void validate_mem(int (*is_valid)(u_long), int (*do_cksum)(u_long),
-		  int force_low)
+		  int force_low, socket_info_t *s)
 {
     resource_map_t *m;
     static int done = 0;
@@ -348,7 +425,7 @@
     if (!probe_mem || done++)
 	return;
     for (m = mem_db.next; m != &mem_db; m = m->next)
-	if (do_mem_probe(m->base, m->num, is_valid, do_cksum))
+	if (do_mem_probe(m->base, m->num, is_valid, do_cksum, s))
 	    return;
 }
 
@@ -368,7 +445,7 @@
 ======================================================================*/
 
 int find_io_region(ioaddr_t *base, ioaddr_t num, ioaddr_t align,
-		   char *name)
+		   char *name, socket_info_t *s)
 {
     ioaddr_t try;
     resource_map_t *m;
@@ -378,9 +455,8 @@
 	for (try = (try >= m->base) ? try : try+align;
 	     (try >= m->base) && (try+num <= m->base+m->num);
 	     try += align) {
-	    if (check_io_resource(try, num) == 0) {
+	    if (request_io_resource(try, num, name, s->cap.cb_dev) == 0) {
 		*base = try;
-		request_region(try, num, name);
 		return 0;
 	    }
 	    if (!align) break;
@@ -390,7 +466,7 @@
 }
 
 int find_mem_region(u_long *base, u_long num, u_long align,
-		    int force_low, char *name)
+		    int force_low, char *name, socket_info_t *s)
 {
     u_long try;
     resource_map_t *m;
@@ -403,8 +479,7 @@
 	    for (try = (try >= m->base) ? try : try+align;
 		 (try >= m->base) && (try+num <= m->base+m->num);
 		 try += align) {
-		if (check_mem_resource(try, num) == 0) {
-		    request_mem_region(try, num, name);
+		if (request_mem_resource(try, num, name, s->cap.cb_dev) == 0) {
 		    *base = try;
 		    return 0;
 		}

[PATCH]

[Andre Hedrick]

http://www.linuxdiskcert.org/ide-2.4.19-p6.all.convert.3.patch.bz2

Spinlock issues address and 99% fixed.
6 new chipsets.
Taskfile IO should be stable.
Borrowed cleanups from 2.5.5 credit given to <martin d>
Bunches of patchs that have been submitted but not added until now.

Thanks for all the support gang ... this should make life a little better.

AEC6280 U100
AEC6880 U133
SI680 U133
CSB6 U100
HPT374 U100(U133??)
HPT372
Intel ICH3
VIA latest (via vojtech)

Super Taskfile special vender modes, and transparent to API.

Things which can not be fixed yet.

Spinlock sleep during probe to get.
Spinlock on pci-proc operations.

Process to convert codebase to as single filter/mask ruleset for timings.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

Re: [PATCH]

[Josh McKinney]

On approximately Mon, Apr 15, 2002 at 11:39:14AM -0700, Andre Hedrick wrote:
> 
> http://www.linuxdiskcert.org/ide-2.4.19-p6.all.convert.3.patch.bz2
> 
Just got this when compiling...

drivers/ide/idedriver.o: In function `task_no_data_intr':
drivers/ide/idedriver.o(.text+0x9f1): undefined reference to `ide__sti'
drivers/ide/idedriver.o: In function `flagged_task_no_data_intr':
drivers/ide/idedriver.o(.text+0x14c7): undefined reference to `ide__sti'
drivers/ide/idedriver.o: In function `ide_cmd_ioctl':
drivers/ide/idedriver.o(.text+0x23e0): undefined reference to `set_transfer'
drivers/ide/idedriver.o(.text+0x23fc): undefined reference to `ide_ata66_check'
drivers/ide/idedriver.o(.text+0x24a7): undefined reference to `ide_driveid_update'
drivers/ide/idedriver.o: In function `check_dma_crc':
drivers/ide/idedriver.o(.text+0x2fc3): undefined reference to `ide_auto_reduce_xfer'
drivers/ide/idedriver.o: In function `ide_dump_status':
drivers/ide/idedriver.o(.text+0x34c8): undefined reference to `ide__sti'
drivers/ide/idedriver.o: In function `drive_cmd_intr':
drivers/ide/idedriver.o(.text+0x3b21): undefined reference to `ide__sti'
drivers/ide/idedriver.o: In function `ide_wait_stat':
drivers/ide/idedriver.o(.text+0x3cd5): undefined reference to `ide__sti'
drivers/ide/idedriver.o: In function `ide_do_request':
drivers/ide/idedriver.o(.text+0x42c9): undefined reference to `ide__sti'
drivers/ide/idedriver.o: In function `ide_intr':
drivers/ide/idedriver.o(.text+0x48f3): undefined reference to `ide__sti'
drivers/ide/idedriver.o: In function `report_drive_dmaing':
drivers/ide/idedriver.o(.text+0x784a): undefined reference to `eighty_ninty_three'
drivers/ide/idedriver.o(.text+0x789e): undefined reference to `eighty_ninty_three'
drivers/ide/idedriver.o: In function `config_drive_for_dma':
drivers/ide/idedriver.o(.text+0x79ce): undefined reference to `eighty_ninty_three'
drivers/ide/idedriver.o(.text+0x79fe): undefined reference to `eighty_ninty_three'
drivers/ide/idedriver.o: In function `via_set_drive':
drivers/ide/idedriver.o(.text+0x91a8): undefined reference to `ide_config_drive_speed'
drivers/ide/idedriver.o: In function `actual_try_to_identify':
drivers/ide/idedriver.o(.text+0xaaec): undefined reference to `ide__sti'
make: *** [vmlinux] Error 1

This comes at the final linking stage.

Thanks for the great stuff Andre.

Josh McKinney

Re: [PATCH]

[Andre Hedrick]

Please send me your .config cause this built clean ...

On Mon, 15 Apr 2002, Josh McKinney wrote:

> On approximately Mon, Apr 15, 2002 at 11:39:14AM -0700, Andre Hedrick wrote:
> > 
> > http://www.linuxdiskcert.org/ide-2.4.19-p6.all.convert.3.patch.bz2
> > 
> Just got this when compiling...
> 
> drivers/ide/idedriver.o: In function `task_no_data_intr':
> drivers/ide/idedriver.o(.text+0x9f1): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `flagged_task_no_data_intr':
> drivers/ide/idedriver.o(.text+0x14c7): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `ide_cmd_ioctl':
> drivers/ide/idedriver.o(.text+0x23e0): undefined reference to `set_transfer'
> drivers/ide/idedriver.o(.text+0x23fc): undefined reference to `ide_ata66_check'
> drivers/ide/idedriver.o(.text+0x24a7): undefined reference to `ide_driveid_update'
> drivers/ide/idedriver.o: In function `check_dma_crc':
> drivers/ide/idedriver.o(.text+0x2fc3): undefined reference to `ide_auto_reduce_xfer'
> drivers/ide/idedriver.o: In function `ide_dump_status':
> drivers/ide/idedriver.o(.text+0x34c8): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `drive_cmd_intr':
> drivers/ide/idedriver.o(.text+0x3b21): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `ide_wait_stat':
> drivers/ide/idedriver.o(.text+0x3cd5): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `ide_do_request':
> drivers/ide/idedriver.o(.text+0x42c9): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `ide_intr':
> drivers/ide/idedriver.o(.text+0x48f3): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `report_drive_dmaing':
> drivers/ide/idedriver.o(.text+0x784a): undefined reference to `eighty_ninty_three'
> drivers/ide/idedriver.o(.text+0x789e): undefined reference to `eighty_ninty_three'
> drivers/ide/idedriver.o: In function `config_drive_for_dma':
> drivers/ide/idedriver.o(.text+0x79ce): undefined reference to `eighty_ninty_three'
> drivers/ide/idedriver.o(.text+0x79fe): undefined reference to `eighty_ninty_three'
> drivers/ide/idedriver.o: In function `via_set_drive':
> drivers/ide/idedriver.o(.text+0x91a8): undefined reference to `ide_config_drive_speed'
> drivers/ide/idedriver.o: In function `actual_try_to_identify':
> drivers/ide/idedriver.o(.text+0xaaec): undefined reference to `ide__sti'
> make: *** [vmlinux] Error 1
> 
> This comes at the final linking stage.
> 
> Thanks for the great stuff Andre.
> 
> Josh McKinney
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Andre Hedrick
LAD Storage Consulting Group

Re: [PATCH]

[Andre Hedrick]

http://www.linuxdiskcert.org/ide-2.4.19-p6.all.convert.3a.patch.bz2

Lets try it again, I diffed the wrong tree :-/

On Mon, 15 Apr 2002, Josh McKinney wrote:

> On approximately Mon, Apr 15, 2002 at 11:39:14AM -0700, Andre Hedrick wrote:
> > 
> > http://www.linuxdiskcert.org/ide-2.4.19-p6.all.convert.3a.patch.bz2
> > 
> Just got this when compiling...
> 
> drivers/ide/idedriver.o: In function `task_no_data_intr':
> drivers/ide/idedriver.o(.text+0x9f1): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `flagged_task_no_data_intr':
> drivers/ide/idedriver.o(.text+0x14c7): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `ide_cmd_ioctl':
> drivers/ide/idedriver.o(.text+0x23e0): undefined reference to `set_transfer'
> drivers/ide/idedriver.o(.text+0x23fc): undefined reference to `ide_ata66_check'
> drivers/ide/idedriver.o(.text+0x24a7): undefined reference to `ide_driveid_update'
> drivers/ide/idedriver.o: In function `check_dma_crc':
> drivers/ide/idedriver.o(.text+0x2fc3): undefined reference to `ide_auto_reduce_xfer'
> drivers/ide/idedriver.o: In function `ide_dump_status':
> drivers/ide/idedriver.o(.text+0x34c8): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `drive_cmd_intr':
> drivers/ide/idedriver.o(.text+0x3b21): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `ide_wait_stat':
> drivers/ide/idedriver.o(.text+0x3cd5): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `ide_do_request':
> drivers/ide/idedriver.o(.text+0x42c9): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `ide_intr':
> drivers/ide/idedriver.o(.text+0x48f3): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `report_drive_dmaing':
> drivers/ide/idedriver.o(.text+0x784a): undefined reference to `eighty_ninty_three'
> drivers/ide/idedriver.o(.text+0x789e): undefined reference to `eighty_ninty_three'
> drivers/ide/idedriver.o: In function `config_drive_for_dma':
> drivers/ide/idedriver.o(.text+0x79ce): undefined reference to `eighty_ninty_three'
> drivers/ide/idedriver.o(.text+0x79fe): undefined reference to `eighty_ninty_three'
> drivers/ide/idedriver.o: In function `via_set_drive':
> drivers/ide/idedriver.o(.text+0x91a8): undefined reference to `ide_config_drive_speed'
> drivers/ide/idedriver.o: In function `actual_try_to_identify':
> drivers/ide/idedriver.o(.text+0xaaec): undefined reference to `ide__sti'
> make: *** [vmlinux] Error 1
> 
> This comes at the final linking stage.
> 
> Thanks for the great stuff Andre.
> 
> Josh McKinney
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Andre Hedrick
LAD Storage Consulting Group

Re: [PATCH]

[Josh McKinney]

On approximately Mon, Apr 15, 2002 at 12:59:20PM -0700, Andre Hedrick wrote:
> 
> http://www.linuxdiskcert.org/ide-2.4.19-p6.all.convert.3a.patch.bz2
> 
> Lets try it again, I diffed the wrong tree :-/
> 

Well it compiled fine this time, but it seems to have problems with gcc-3.0.4 I am using to
compile kernels.  This gcc has been fine for all other uses, but it must be something with this
particular build because gcc-2.95.4 works without a problem.  Anyways, here is the oops report
if it may interest you.

<1>Unable to handle kernel paging request at virtual address 3fff432a
c01c2c90
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c01c2c90>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: 3fff427a   ebx: c02fc928   ecx: 00000001   edx: dda11e04
esi: c02fc928   edi: dda11e98   ebp: bffff7f0   esp: dda11e04
ds: 0018   es: 0018   ss: 0018
Process hdparm (pid: 492, stackpage=dda11000)
Stack: 3fff427a 00100000 0258e100 0010003f 000e0000 2d575744 39504d41 30353136
       31003238 00000000 10000003 30320028 35422e30 57443032 57444320 30423630
       3332422d 41304358 20202020 20202020 20202020 20202020 20202020 80102020
Code: 0f b7 80 b0 00 00 00 8b 93 f0 00 00 00 66 89 82 b0 00 00 00


>>EIP; c01c2c90 <ide_driveid_update+30/90>   <=====

>>eax; 3fff427a Before first symbol
>>ebx; c02fc928 <ide_hwifs+388/20a8>
>>edx; dda11e04 <_end+1d70bb50/2253ad4c>
>>esi; c02fc928 <ide_hwifs+388/20a8>
>>edi; dda11e98 <_end+1d70bbe4/2253ad4c>
>>ebp; bffff7f0 Before first symbol
>>esp; dda11e04 <_end+1d70bb50/2253ad4c>

Code;  c01c2c90 <ide_driveid_update+30/90>
00000000 <_EIP>:
Code;  c01c2c90 <ide_driveid_update+30/90>   <=====
   0:   0f b7 80 b0 00 00 00      movzwl 0xb0(%eax),%eax   <=====
Code;  c01c2c97 <ide_driveid_update+37/90>
   7:   8b 93 f0 00 00 00         mov    0xf0(%ebx),%edx
Code;  c01c2c9d <ide_driveid_update+3d/90>
   d:   66 89 82 b0 00 00 00      mov    %ax,0xb0(%edx)

Re: [PATCH]

[Andre Hedrick]

Yep,

Edit ide-taskfile.c find ide_driveid_update

Changes the #if 1 to #if 0

Attempting to make the code compress but it appears that entry for
updating is more than a simple direct call.  Still banging it out.

Cheers,

On Mon, 15 Apr 2002, Josh McKinney wrote:

> On approximately Mon, Apr 15, 2002 at 12:59:20PM -0700, Andre Hedrick wrote:
> > 
> > http://www.linuxdiskcert.org/ide-2.4.19-p6.all.convert.3a.patch.bz2
> > 
> > Lets try it again, I diffed the wrong tree :-/
> > 
> 
> Well it compiled fine this time, but it seems to have problems with gcc-3.0.4 I am using to
> compile kernels.  This gcc has been fine for all other uses, but it must be something with this
> particular build because gcc-2.95.4 works without a problem.  Anyways, here is the oops report
> if it may interest you.
> 
> <1>Unable to handle kernel paging request at virtual address 3fff432a
> c01c2c90
> *pde = 00000000
> Oops: 0000
> CPU:    0
> EIP:    0010:[<c01c2c90>]    Not tainted
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010202
> eax: 3fff427a   ebx: c02fc928   ecx: 00000001   edx: dda11e04
> esi: c02fc928   edi: dda11e98   ebp: bffff7f0   esp: dda11e04
> ds: 0018   es: 0018   ss: 0018
> Process hdparm (pid: 492, stackpage=dda11000)
> Stack: 3fff427a 00100000 0258e100 0010003f 000e0000 2d575744 39504d41 30353136
>        31003238 00000000 10000003 30320028 35422e30 57443032 57444320 30423630
>        3332422d 41304358 20202020 20202020 20202020 20202020 20202020 80102020
> Code: 0f b7 80 b0 00 00 00 8b 93 f0 00 00 00 66 89 82 b0 00 00 00
> 
> 
> >>EIP; c01c2c90 <ide_driveid_update+30/90>   <=====
> 
> >>eax; 3fff427a Before first symbol
> >>ebx; c02fc928 <ide_hwifs+388/20a8>
> >>edx; dda11e04 <_end+1d70bb50/2253ad4c>
> >>esi; c02fc928 <ide_hwifs+388/20a8>
> >>edi; dda11e98 <_end+1d70bbe4/2253ad4c>
> >>ebp; bffff7f0 Before first symbol
> >>esp; dda11e04 <_end+1d70bb50/2253ad4c>
> 
> Code;  c01c2c90 <ide_driveid_update+30/90>
> 00000000 <_EIP>:
> Code;  c01c2c90 <ide_driveid_update+30/90>   <=====
>    0:   0f b7 80 b0 00 00 00      movzwl 0xb0(%eax),%eax   <=====
> Code;  c01c2c97 <ide_driveid_update+37/90>
>    7:   8b 93 f0 00 00 00         mov    0xf0(%ebx),%edx
> Code;  c01c2c9d <ide_driveid_update+3d/90>
>    d:   66 89 82 b0 00 00 00      mov    %ax,0xb0(%edx)
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Andre Hedrick
LAD Storage Consulting Group

Re: [PATCH]

[Jens Axboe]

On Mon, Apr 15 2002, Andre Hedrick wrote:
> 
> http://www.linuxdiskcert.org/ide-2.4.19-p6.all.convert.3.patch.bz2

seems that you haven't fixed the case where you cannot enable dma on an
atapi drive if CONFIG_IDEDMA_ONLYDISK has been selected? to me this is a
bug -- I don't want auto-enable of dma on my atapi drives, but I surely
want to be able to hdparm -d1 them at will later on.

-- 
Jens Axboe

Re: [PATCH]

[Andre Hedrick]

It is 99% usage for distro to ship stable booting kernels given atapi is
flakey.  However if you have a suggestion I am accepting options

--andre

On Tue, 16 Apr 2002, Jens Axboe wrote:

> On Mon, Apr 15 2002, Andre Hedrick wrote:
> > 
> > http://www.linuxdiskcert.org/ide-2.4.19-p6.all.convert.3.patch.bz2
> 
> seems that you haven't fixed the case where you cannot enable dma on an
> atapi drive if CONFIG_IDEDMA_ONLYDISK has been selected? to me this is a
> bug -- I don't want auto-enable of dma on my atapi drives, but I surely
> want to be able to hdparm -d1 them at will later on.
> 
> -- 
> Jens Axboe
> 

Re: [PATCH]

[Jens Axboe]

On Mon, Apr 15 2002, Andre Hedrick wrote:
> 
> It is 99% usage for distro to ship stable booting kernels given atapi is
> flakey.  However if you have a suggestion I am accepting options

I agree with the option, just not the way it is implemented. If I want
to enable dma after boot, I must be able to do so.

I have a solution, the current SuSE kernel gets it right. I'll backport
that to 2.4.19-pre once this patch is in.

-- 
Jens Axboe

Re: [PATCH]

[Andre Hedrick]

This patch is not going anywhere for a while, until all the archs have
consistant local_*_*() spinlock but I noted what needs to be fixed and who
broke what.

I have another method but it was not reasonable or predictable until I
finish the driver conversion to fully modular and delete 95% of the
duplicated code mess I made over the years.

Your are free to copy it into 2.5 as always.

regards,

--andre

On Tue, 16 Apr 2002, Jens Axboe wrote:

> On Mon, Apr 15 2002, Andre Hedrick wrote:
> > 
> > It is 99% usage for distro to ship stable booting kernels given atapi is
> > flakey.  However if you have a suggestion I am accepting options
> 
> I agree with the option, just not the way it is implemented. If I want
> to enable dma after boot, I must be able to do so.
> 
> I have a solution, the current SuSE kernel gets it right. I'll backport
> that to 2.4.19-pre once this patch is in.
> 
> -- 
> Jens Axboe
> 

[PATCH]

[Christoph Hellwig]

Hi Linus,

the appended patch adds four exports needed for Linux-ABI:

 o do_fork & do_pipe because the emulated SysV syscalls call
   these directly.
 o the other two are needed by emulated syscongig() support.

Please apply,

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

diff -uNr -Xdontdiff ../master/linux-2.4.14-pre1/kernel/ksyms.c linux-2.4.14-pre1/kernel/ksyms.c
--- ../master/linux-2.4.14-pre1/kernel/ksyms.c	Thu Oct 25 19:05:49 2001
+++ linux-2.4.14-pre1/kernel/ksyms.c	Thu Oct 25 19:16:47 2001
@@ -60,6 +60,7 @@
 extern void *sys_call_table;
 
 extern struct timezone sys_tz;
+extern int max_threads;
 extern int request_dma(unsigned int dmanr, char * deviceID);
 extern void free_dma(unsigned int dmanr);
 extern spinlock_t dma_spin_lock;
@@ -550,3 +551,11 @@
 
 EXPORT_SYMBOL(tasklist_lock);
 EXPORT_SYMBOL(pidhash);
+
+/* for Linux-ABI */
+EXPORT_SYMBOL(do_fork);
+EXPORT_SYMBOL(do_pipe);
+
+/* sysconfig support */
+EXPORT_SYMBOL(nr_free_pages);
+EXPORT_SYMBOL(max_threads);

[PATCH]

[Rik van Riel]

Hi Alan,

the following patch fixes reclaim_page() and page_launder() to
correctly reactivate a page based one page->count value.

Note that we shouldn't be hitting this code very much with the
current immediate reactivation in __find_page_nolock(), but I
guess it would be useful to have as a safety net against things
like the shmem code and other areas I don't about ;)

regards,

Rik
--
IA64: a worthy successor to i860.


--- linux-2.4.8-ac7/mm/vmscan.c.orig	Mon Aug 20 11:29:24 2001
+++ linux-2.4.8-ac7/mm/vmscan.c	Mon Aug 20 11:30:46 2001
@@ -456,7 +456,7 @@

 		/* Page is or was in use?  Move it to the active list. */
 		if (PageReferenced(page) || page->age > 0 ||
-				(!page->buffers && page_count(page) > 1)) {
+				page_count(page) > (1 + !!page->buffers)) {
 			del_page_from_inactive_clean_list(page);
 			add_page_to_active_list(page);
 			continue;
@@ -594,7 +594,7 @@

 		/* Page is or was in use?  Move it to the active list. */
 		if (PageReferenced(page) || page->age > 0 ||
-				(!page->buffers && page_count(page) > 1) ||
+				page_count(page) > (1 + !!page->buffers) ||
 				page_ramdisk(page)) {
 			del_page_from_inactive_dirty_list(page);
 			add_page_to_active_list(page);

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [PATCH]

[Marcelo Tosatti]

Rik,

Think about a thread blocked on ->writepage() called from page_launder(),
which has gotten an additional reference on the page.

Any other thread looping on page_launder() will move the given page being
written to the active list, even if we should just drop the page as soon
as its writeout is finished.

That is just _one_ case the patch will do the wrong thing (there may be
more). I suggest more investigation before actually merging the patch in
the -ac tree.

On Mon, 20 Aug 2001, Rik van Riel wrote:

> Hi Alan,
> 
> the following patch fixes reclaim_page() and page_launder() to
> correctly reactivate a page based one page->count value.
> 
> Note that we shouldn't be hitting this code very much with the
> current immediate reactivation in __find_page_nolock(), but I
> guess it would be useful to have as a safety net against things
> like the shmem code and other areas I don't about ;)
> 
> regards,
> 
> Rik
> --
> IA64: a worthy successor to i860.
> 
> 
> --- linux-2.4.8-ac7/mm/vmscan.c.orig	Mon Aug 20 11:29:24 2001
> +++ linux-2.4.8-ac7/mm/vmscan.c	Mon Aug 20 11:30:46 2001
> @@ -456,7 +456,7 @@
> 
>  		/* Page is or was in use?  Move it to the active list. */
>  		if (PageReferenced(page) || page->age > 0 ||
> -				(!page->buffers && page_count(page) > 1)) {
> +				page_count(page) > (1 + !!page->buffers)) {
>  			del_page_from_inactive_clean_list(page);
>  			add_page_to_active_list(page);
>  			continue;
> @@ -594,7 +594,7 @@
> 
>  		/* Page is or was in use?  Move it to the active list. */
>  		if (PageReferenced(page) || page->age > 0 ||
> -				(!page->buffers && page_count(page) > 1) ||
> +				page_count(page) > (1 + !!page->buffers) ||
>  				page_ramdisk(page)) {
>  			del_page_from_inactive_dirty_list(page);
>  			add_page_to_active_list(page);
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [PATCH]

[Rik van Riel]

On Mon, 20 Aug 2001, Marcelo Tosatti wrote:

> Think about a thread blocked on ->writepage() called from
> page_launder(), which has gotten an additional reference on the
> page.
>
> Any other thread looping on page_launder() will move the given
> page being written to the active list, even if we should just
> drop the page as soon as its writeout is finished.

You're right, we need to add one more check, for PageLocked(page).

If the page is locked, we should not reactivate it...

regards,

Rik
--
IA64: a worthy successor to the i860.

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

[PATCH]

[Ben LaHaise]

Hello,

The patch below enables vma merging for a couple of additional cases with
anon mmaps as glibc has a habit of passing in differing flags for some
cases (ie memory remapping, extending specific malloc blocks, etc).  This
is to help Mozilla which ends up with thousands of vma's that are
sequential and anonymous, but unmerged.  There may still be issues with
mremap, but I think this is a step in the right direction.

		-ben

diff -urN /md0/kernels/2.4/v2.4.8-ac5/mm/mmap.c work-v2.4.8-ac5/mm/mmap.c
--- /md0/kernels/2.4/v2.4.8-ac5/mm/mmap.c	Wed Aug 15 12:57:40 2001
+++ work-v2.4.8-ac5/mm/mmap.c	Wed Aug 15 13:02:35 2001
@@ -309,7 +309,8 @@
 	if (addr && !file && !(vm_flags & VM_SHARED)) {
 		struct vm_area_struct * vma = find_vma(mm, addr-1);
 		if (vma && vma->vm_end == addr && !vma->vm_file &&
-		    vma->vm_flags == vm_flags) {
+		    (vma->vm_flags & ~(MAP_NORESERVE | MAP_FIXED)) ==
+		    (vm_flags & ~(MAP_NORESERVE | MAP_FIXED))) {
 			vma->vm_end = addr + len;
 			goto out;
 		}

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [PATCH]

[Linus Torvalds]

On Wed, 15 Aug 2001, Ben LaHaise wrote:
>
> The patch below enables vma merging for a couple of additional cases with
> anon mmaps as glibc has a habit of passing in differing flags for some
> cases (ie memory remapping, extending specific malloc blocks, etc).  This
> is to help Mozilla which ends up with thousands of vma's that are
> sequential and anonymous, but unmerged.  There may still be issues with
> mremap, but I think this is a step in the right direction.

Good catch.

However, I really think we should just mask those bits out in general:
we've already used them up by this time, and they make no sense at all to
maintain in the VMA either, so it looks like it would be a cleaner (and
shorter) patch to just do

	/* get rid of mmap-time-only flags */
	vm_flags &= ~(MAP_NORESERVE | MAP_FIXED);

just after we've checked the MAP_NORESERVE bit, and just before we check
whether we can expand an old mapping. That way the (now meaningless) bits
don't end up as noise in the vma->vm_flags, AND we guarantee that merging
doesn't merge two fields that have different "noise" in their vm_flags.

Agreed?

		Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [PATCH]

[Ben LaHaise]

On Wed, 15 Aug 2001, Linus Torvalds wrote:

> Good catch.

Eeep, on re-reading it, I was wrong: vm_flags only has VM_* in the bits,
so this patch would introduce a bug (oops, I must need coffee).  So, it
must be in the mremap/mprotect related bits.

		-ben

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [PATCH]

[Daniel Phillips]

On August 15, 2001 07:40 pm, Linus Torvalds wrote:
> On Wed, 15 Aug 2001, Ben LaHaise wrote:
> >
> > The patch below enables vma merging for a couple of additional cases with
> > anon mmaps as glibc has a habit of passing in differing flags for some
> > cases (ie memory remapping, extending specific malloc blocks, etc).  This
> > is to help Mozilla which ends up with thousands of vma's that are
> > sequential and anonymous, but unmerged.  There may still be issues with
> > mremap, but I think this is a step in the right direction.
> 
> Good catch.
> 
> However, I really think we should just mask those bits out in general:
> we've already used them up by this time, and they make no sense at all to
> maintain in the VMA either, so it looks like it would be a cleaner (and
> shorter) patch to just do
> 
> 	/* get rid of mmap-time-only flags */
> 	vm_flags &= ~(MAP_NORESERVE | MAP_FIXED);
> 
> just after we've checked the MAP_NORESERVE bit, and just before we check
> whether we can expand an old mapping. That way the (now meaningless) bits
> don't end up as noise in the vma->vm_flags, AND we guarantee that merging
> doesn't merge two fields that have different "noise" in their vm_flags.

Another one in that category is BH_New which we use only immediately after
*_get_block, afterwards it dangles meaninglessly.  Not a bug, but
misleading.

--
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

[PATCH]

[Bartlomiej Zolnierkiewicz]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 203 bytes --]


Patch fixes ide-disk/ide-floppy/ide-probe modules interaction
with /proc fs. Last chunk is needed to compile ide-probe as
module without /proc support.

--
Bartlomiej Zolnierkiewicz
<bkz@linux-ide.org>

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1210 bytes --]

--- linux-240t10p6/drivers/ide/ide-disk.c	Thu Oct 19 22:05:01 2000
+++ linux/drivers/ide/ide-disk.c	Sat Oct 28 22:59:22 2000
@@ -891,8 +891,10 @@
 		}
 		/* We must remove proc entries defined in this module.
 		   Otherwise we oops while accessing these entries */
+#ifdef CONFIG_PROC_FS
 		if (drive->proc)
 			ide_remove_proc_entries(drive->proc, idedisk_proc);
+#endif
 	}
 	ide_unregister_module(&idedisk_module);
 }
--- linux-240t10p6/drivers/ide/ide-floppy.c	Tue Jun 13 20:32:00 2000
+++ linux/drivers/ide/ide-floppy.c	Sat Oct 28 22:59:51 2000
@@ -1683,8 +1683,10 @@
 		}
 		/* We must remove proc entries defined in this module.
 		   Otherwise we oops while accessing these entries */
+#ifdef CONFIG_PROC_FS
 		if (drive->proc)
 			ide_remove_proc_entries(drive->proc, idefloppy_proc);
+#endif
 	}
 	ide_unregister_module(&idefloppy_module);
 }
--- linux-240t10p6/drivers/ide/ide-probe.c	Tue Oct  3 00:16:51 2000
+++ linux/drivers/ide/ide-probe.c	Sat Oct 28 22:58:09 2000
@@ -906,7 +906,9 @@
 	for (index = 0; index < MAX_HWIFS; ++index)
 		ide_unregister(index);
 	ideprobe_init();
+#ifdef CONFIG_PROC_FS
 	create_proc_ide_interfaces();
+#endif
 	return 0;
 }
 

[PATCH]

[Bartlomiej Zolnierkiewicz]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 131 bytes --]


I hitted few items from Dawson Engler's list of potential kmalloc/kfree
bugs...

--
Bartlomiej Zolnierkiewicz
<bkz@linux-ide.org>

[-- Attachment #2: Type: TEXT/PLAIN, Size: 5501 bytes --]

--- linux-240t10/drivers/ide/ide-probe.c	Tue Oct  3 00:16:51 2000
+++ linux/drivers/ide/ide-probe.c	Tue Nov  7 00:25:35 2000
@@ -652,6 +653,10 @@
 		hwgroup = match->hwgroup;
 	} else {
 		hwgroup = kmalloc(sizeof(ide_hwgroup_t), GFP_KERNEL);
+		if(!hwgroup) {
+			restore_flags(flags);
+			return 1;
+		}
 		memset(hwgroup, 0, sizeof(ide_hwgroup_t));
 		hwgroup->hwif     = hwif->next = hwif;
 		hwgroup->rq       = NULL;
@@ -746,11 +751,23 @@
 	}
 	minors    = units * (1<<PARTN_BITS);
 	gd        = kmalloc (sizeof(struct gendisk), GFP_KERNEL);
+	if(!gd)
+		goto cleanup_gd;
 	gd->sizes = kmalloc (minors * sizeof(int), GFP_KERNEL);
+	if(!gd->sizes)
+		goto cleanup_gd_sizes;
 	gd->part  = kmalloc (minors * sizeof(struct hd_struct), GFP_KERNEL);
+	if(!gd->part)
+		goto cleanup_gd_part;
 	bs        = kmalloc (minors*sizeof(int), GFP_KERNEL);
+	if(!bs)
+		goto cleanup_bs;
 	max_sect  = kmalloc (minors*sizeof(int), GFP_KERNEL);
+	if(!max_sect)
+		goto cleanup_max_sect;
 	max_ra    = kmalloc (minors*sizeof(int), GFP_KERNEL);
+	if(!max_ra)
+		goto cleanup_max_ra;
 
 	memset(gd->part, 0, minors * sizeof(struct hd_struct));
 
@@ -779,12 +796,16 @@
 	gd->real_devices= hwif;			/* ptr to internal data */
 	gd->next	= NULL;			/* linked list of major devs */
 	gd->fops        = ide_fops;             /* file operations */
-	gd->de_arr	= kmalloc (sizeof *gd->de_arr * units, GFP_KERNEL);
-	gd->flags	= kmalloc (sizeof *gd->flags * units, GFP_KERNEL);
-	if (gd->de_arr)
-		memset (gd->de_arr, 0, sizeof *gd->de_arr * units);
-	if (gd->flags)
-		memset (gd->flags, 0, sizeof *gd->flags * units);
+	if(units) {
+		gd->de_arr = kmalloc (sizeof *gd->de_arr * units, GFP_KERNEL);
+		if(!gd->de_arr)
+			goto cleanup_gd_de_arr;
+		gd->flags  = kmalloc (sizeof *gd->flags * units, GFP_KERNEL);
+		if(!gd->flags)
+			goto cleanup_gd_flags;
+		memset(gd->de_arr, 0, sizeof *gd->de_arr * units);
+		memset(gd->flags, 0, sizeof *gd->flags * units);
+	}
 
 	for (gdp = &gendisk_head; *gdp; gdp = &((*gdp)->next)) ;
 	hwif->gd = *gdp = gd;			/* link onto tail of list */
@@ -802,6 +823,26 @@
 				devfs_mk_dir (ide_devfs_handle, name, NULL);
 		}
 	}
+	return;
+
+cleanup_gd_flags:
+	kfree(gd->flags);
+cleanup_gd_de_arr:
+	kfree(gd->de_arr);
+cleanup_max_ra:
+	kfree(max_ra);
+cleanup_max_sect:
+	kfree(max_sect);
+cleanup_bs:
+	kfree(bs);
+cleanup_gd_part:
+	kfree(gd->part);
+cleanup_gd_sizes:
+	kfree(gd->sizes);
+cleanup_gd:
+	kfree(gd);
+
+	printk(KERN_ERR "ide-probe: not enough memory for init_gendisk()\n");
 }
 
 static int hwif_init (ide_hwif_t *hwif)
--- linux-240t10/drivers/i2o/i2o_config.c	Tue Oct  3 00:15:34 2000
+++ linux/drivers/i2o/i2o_config.c	Mon Nov  6 22:41:41 2000
@@ -499,6 +499,8 @@
 	if(!res)
 	{
 		i2o_unlock_controller(c);
+		printk(KERN_INFO "i2o_config: could not get res\n");
+		if(kcmd.qlen) kfree(query);
 		return -ENOMEM;
 	}
 
--- linux-240t10/drivers/i2o/i2o_core.c	Thu Oct 19 22:05:01 2000
+++ linux/drivers/i2o/i2o_core.c	Mon Nov  6 22:49:55 2000
@@ -1664,6 +1664,7 @@
 			{
 				printk(KERN_ERR "%s: Timeout waiting for IOP reset.\n", 
 						c->name); 
+				kfree(status);
 				return -ETIMEDOUT; 
 			} 
 			schedule(); 
--- linux-240t10/drivers/scsi/eata_dma.c	Tue Oct  3 14:27:44 2000
+++ linux/drivers/scsi/eata_dma.c	Mon Nov  6 23:21:04 2000
@@ -909,8 +909,17 @@
 
     cp = (struct eata_ccb *) kmalloc(sizeof(struct eata_ccb),
 				     GFP_ATOMIC | GFP_DMA);
+    if(!cp) {
+	printk(KERN_ERR "eata_dma: out of DMA memory\n");
+	return NULL;
+    }
     sp = (struct eata_sp *) kmalloc(sizeof(struct eata_sp), 
 					     GFP_ATOMIC | GFP_DMA);
+    if(!sp) {
+	printk(KERN_ERR "eata_dma: out of DMA memory\n");
+	kfree(cp);
+	return NULL;
+    }
 
     buff = dma_scratch;
  
@@ -1459,11 +1468,15 @@
     tpnt->proc_name = "eata_dma";
 
     status = kmalloc(512, GFP_ATOMIC | GFP_DMA);
+    if(!status) {
+	printk(KERN_ERR "eata_dma: not enough DMA memory to probe for hosts!\n");
+	return 0;
+    }
     dma_scratch = kmalloc(1024, GFP_ATOMIC | GFP_DMA);
-
-    if(status == NULL || dma_scratch == NULL) {
-	printk("eata_dma: can't allocate enough memory to probe for hosts !\n");
-	return(0);
+    if(!dma_scratch) {
+	printk(KERN_ERR "eata_dma: not enough DMA memory to probe for hosts!\n");
+	kfree(status);
+	return 0;
     }
 
     dma_scratch += 4;
--- linux-240t10/drivers/scsi/hosts.c	Tue Oct 31 11:20:15 2000
+++ linux/driver/scsi/hosts.c	Mon Nov  6 23:40:45 2000
@@ -168,7 +168,18 @@
     retval->loaded_as_module = 1;
     if (flag_new) {
 	shn = (Scsi_Host_Name *) kmalloc(sizeof(Scsi_Host_Name), GFP_ATOMIC);
+	if(!shn) {
+		printk(KERN_ERR "scsi: out of memory in scsi_register\n");
+		kfree(retval);
+		return NULL;
+	}
 	shn->name = kmalloc(hname_len + 1, GFP_ATOMIC);
+	if(!shn->name) {
+		printk(KERN_ERR "scsi: out of memory in scsi_register\n");
+		kfree(shn);
+		kfree(retval);
+		return NULL;
+	}
 	if (hname_len > 0)
 	    strncpy(shn->name, hname, hname_len);
 	shn->name[hname_len] = 0;
--- linux-240t10/drivers/scsi/ips.c	Tue Oct  3 14:27:45 2000
+++ linux/drivers/scsi/ips.c	Mon Nov  6 23:48:22 2000
@@ -4552,6 +4552,8 @@
 
    /* Allocate memory for the CCBs */
    ha->scbs = (ips_scb_t *) kmalloc(ha->max_cmds * sizeof(ips_scb_t), GFP_ATOMIC|GFP_DMA);
+   if(!ha->scbs)
+      return 0;
 
    memset(ha->scbs, 0, ha->max_cmds * sizeof(ips_scb_t));
 

Re: [PATCH]

[Bartlomiej Zolnierkiewicz]

Yeach... I'm a bit sleepy...

first  [PATCH]: kmalloc/kfree bugs hit 1
second [PATCH]: ide modules and /proc fs

--
bkz

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