From: Kees Cook
Date: Tue, 23 Oct 2012 13:04:18 -0700
> This config item has not carried much meaning for a while now and is
> almost always enabled by default. As agreed during the Linux kernel
> summit, remove it.
>
> CC: Andrew Hendry
> CC: "David S. Miller"
> Signed-off-by: Kees Cook
Ack
From: Kees Cook
Date: Tue, 23 Oct 2012 13:04:19 -0700
> This config item has not carried much meaning for a while now and is
> almost always enabled by default. As agreed during the Linux kernel
> summit, remove it.
>
> CC: "David S. Miller"
> CC: Jan Beulich
> Signed-off-by: Kees Cook
Acked
From: Johannes Berg
Date: Tue, 23 Oct 2012 22:15:50 +0200
> On Tue, 2012-10-23 at 13:04 -0700, Kees Cook wrote:
>> This config item has not carried much meaning for a while now and is
>> almost always enabled by default. As agreed during the Linux kernel
>> summit, remove it.
>>
>> CC: "John W.
From: Kees Cook
Date: Tue, 23 Oct 2012 13:04:15 -0700
> This config item has not carried much meaning for a while now and is
> almost always enabled by default. As agreed during the Linux kernel
> summit, remove it.
>
> CC: Trond Myklebust
> CC: "J. Bruce Fields"
> CC: "David S. Miller"
> Sig
From: Kees Cook
Date: Tue, 23 Oct 2012 13:04:11 -0700
> This config item has not carried much meaning for a while now and is
> almost always enabled by default. As agreed during the Linux kernel
> summit, remove it.
>
> CC: Lauro Ramos Venancio
> CC: Aloisio Almeida Jr
> CC: Samuel Ortiz
> CC
From: Kees Cook
Date: Tue, 23 Oct 2012 13:04:16 -0700
> This config item has not carried much meaning for a while now and is
> almost always enabled by default. As agreed during the Linux kernel
> summit, remove it.
>
> CC: Jon Maloy
> CC: Allan Stephens
> CC: "David S. Miller"
> Signed-off-b
From: Kees Cook
Date: Tue, 23 Oct 2012 13:03:55 -0700
> This config item has not carried much meaning for a while now and is
> almost always enabled by default. As agreed during the Linux kernel
> summit, remove it.
>
> CC: Gerrit Renker
> CC: "David S. Miller"
> Signed-off-by: Kees Cook
Ack
From: Kees Cook
Date: Tue, 23 Oct 2012 13:03:56 -0700
> This config item has not carried much meaning for a while now and is
> almost always enabled by default. As agreed during the Linux kernel
> summit, remove it.
>
> CC: Gerrit Renker
> CC: "David S. Miller"
> Signed-off-by: Kees Cook
Ack
From: Kees Cook
Date: Tue, 23 Oct 2012 13:04:13 -0700
> This config item has not carried much meaning for a while now and is
> almost always enabled by default. As agreed during the Linux kernel
> summit, remove it.
>
> CC: "David S. Miller"
> Signed-off-by: Kees Cook
Acked-by: David S. Mille
From: Kees Cook
Date: Tue, 23 Oct 2012 13:03:58 -0700
> This config item has not carried much meaning for a while now and is
> almost always enabled by default. As agreed during the Linux kernel
> summit, remove it.
>
> CC: Pablo Neira Ayuso
> CC: Patrick McHardy
> CC: "David S. Miller"
> Sig
From: Kees Cook
Date: Tue, 23 Oct 2012 13:02:29 -0700
> This config item has not carried much meaning for a while now and is
> almost always enabled by default. As agreed during the Linux kernel
> summit, remove it.
>
> CC: "David S. Miller"
> CC: Stephen Hemminger
> CC: Paul Gortmaker
> CC:
From: Kees Cook
Date: Tue, 23 Oct 2012 13:02:38 -0700
> This config item has not carried much meaning for a while now and is
> almost always enabled by default. As agreed during the Linux kernel
> summit, remove it.
>
> CC: Paul Gortmaker
> CC: "David S. Miller"
> CC: Jeff Kirsher
> Signed-of
From: Kees Cook
Date: Tue, 23 Oct 2012 13:02:34 -0700
> This config item has not carried much meaning for a while now and is
> almost always enabled by default. As agreed during the Linux kernel
> summit, remove it.
>
> CC: Paul Gortmaker
> CC: "David S. Miller"
> CC: Jeff Kirsher
> CC: Geert
From: Kees Cook
Date: Tue, 23 Oct 2012 13:02:04 -0700
> This config item has not carried much meaning for a while now and is
> almost always enabled by default. As agreed during the Linux kernel
> summit, remove it.
>
> CC: "David S. Miller"
> Signed-off-by: Kees Cook
Acked-by: David S. Mille
From: Kees Cook
Date: Tue, 23 Oct 2012 15:53:27 -0700
> On Tue, Oct 23, 2012 at 1:15 PM, Greg Kroah-Hartman
> wrote:
>> On Tue, Oct 23, 2012 at 01:02:51PM -0700, Kees Cook wrote:
>>> This config item has not carried much meaning for a while now and is
>>> almost always enabled by default. As agr
From: Claudio Fontana
Date: Thu, 25 Oct 2012 09:13:49 +0200
> - pr_info(" device=%s, addr=%pI4, mask=%pI4, gw=%pI4\n",
> - ic_dev->name, &ic_myaddr, &ic_netmask, &ic_gateway);
> +
> + pr_info(" device=%s, hwaddr=%*phC, ipaddr=%pI4, mask=%pI4,
> gw=%pI4\n",
> + ic_d
From: Francois Romieu
Date: Wed, 24 Oct 2012 23:20:03 +0200
> Hayes Wang :
>> Enable ALDPS function to save power when link down. Note that the
>> feature should be set after the other PHY settings. And the firmware
>> is necessary. Don't enable it without loading the firmware.
>>
>> None of th
From: Tilman Schmidt
Date: Wed, 24 Oct 2012 20:44:32 +0200
> The delayed work function int_in_work() may call usb_reset_device()
> and thus, indirectly, the driver's pre_reset method. Trying to
> cancel the work synchronously in that situation would deadlock.
> Fix by avoiding cancel_work_sync()
From: Oliver Neukum
Date: Fri, 26 Oct 2012 09:39:16 +0200
> On Thursday 25 October 2012 21:17:54 Hemant Kumar wrote:
>> Driver anchors the tx urbs and defers the urb submission if
>> a transmit request comes when the interface is suspended.
>> Anchoring urb increments the urb reference count. The
From: Greg KH <[EMAIL PROTECTED]>
Date: Mon, 11 Feb 2008 21:53:12 -0800
> Where do you "fix this up" at? I can send a patch for the IB tree, but
> Roland can't put it in his tree, and I can't put it in my tree, it needs
> to go _after_ both of our trees.
Totally agreed.
The fact is there are in
From: Nick Piggin <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 17:41:21 +1100
> stop machine is used for more than just module loading and unloading.
> I don't think you can just disable it.
Right, in particular it is used for CPU hotplug.
--
To unsubscribe from this list: send the line "unsubscrib
From: Chris Mason <[EMAIL PROTECTED]>
Date: Mon, 11 Feb 2008 08:42:20 -0500
> The kernel is actually worse, because the set/get macros are more complex.
> Some live in ctree.h like in the progs, but the nasty ones live in
> struct-funcs.c
This is really problematic, because you've got these th
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Mon, 11 Feb 2008 12:05:16 -0500
> Mostly fixes, a few cleanups (generally assisting fixes), and an
> exception for PS3 wireless because it had been posted, reviewed and
> acked for a while, just not committed.
>
> Please pull from 'upstream-davem' branch
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Date: Thu, 07 Feb 2008 10:38:01 +0900
> Great, thanks! SPARC IOMMUs use bitmap for the free area management
> like POWER IOMMUs so it could use lib/iommu-helper as POWER does.
Please look at Linus's current tree, I believe I have things
in a working state
Filesystems like ext2 put their superblock 1 block into the partition
in order to avoid overwriting disk labels and other uglies. UFS does
this too, as do several others. One of the few exceptions I've been
able to find is XFS.
This is a real issue on sparc where the default sun disk labels
cre
From: Arjan van de Ven <[EMAIL PROTECTED]>
Date: Mon, 11 Feb 2008 21:17:51 -0800
> this is why you need specific trees for just the API change
API trees don't work, just like other changes they will have
interdependencies on things like fixups, cleanups, etc.
This is why, with the networking, we
From: Theodore Tso <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 00:11:36 -0500
> __deprecate the old one,
Deprecate is garbage, shit hangs around in the tree forever
and people just turn off the warnings.
Clean sweeps work much better, albeit with some merge pain,
we'll cope.
--
To unsubscribe fro
From: "Paul E. McKenney" <[EMAIL PROTECTED]>
Date: Mon, 11 Feb 2008 17:27:41 -0800
> On Mon, Feb 11, 2008 at 04:59:54PM -0800, Stephen Hemminger wrote:
> > Eliminate warnings when rcu_assign_pointer is used with unsigned long.
> > It is reasonable to use RCU with non-pointer values so allow it for
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Mon, 11 Feb 2008 16:59:54 -0800
linux-kernel added to CC:, any change to generic kernel infrastructure
should be posted there
> Eliminate warnings when rcu_assign_pointer is used with unsigned long.
> It is reasonable to use RCU with non-pointer v
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 10:52:56 +0200
> The streaming DMA-API was designed to conserve IOMMU mappings for
> machines where IOMMU mappings are a scarce resource, and is a poor
> fit for a modern IOMMU such as VT-d with a 64-bit IO address space
> (or even a
From: David Miller <[EMAIL PROTECTED]>
Date: Mon, 11 Feb 2008 23:21:39 -0800 (PST)
> Filesystems like ext2 put their superblock 1 block into the partition
> in order to avoid overwriting disk labels and other uglies. UFS does
> this too, as do several others. One of the few excep
The CRC32C implementation in the btrfs progs is different from the one
in the kernel, so obviously nothing can possibly work on big-endian.
This is getting less and less fun by the minute, I simply wanted to
test btrfs on Niagara :-/
Here is a patch to fix that:
--- vanilla/btrfs-progs-0.12/crc
From: Chris Mason <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 08:49:34 -0500
> So, if Btrfs starts zeroing at 1k, will that be acceptable for you?
Sure.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
From: Chris Mason <[EMAIL PROTECTED]>
Date: Wed, 6 Feb 2008 12:00:13 -0500
> So, here's v0.12.
Any page size larger than 4K will not work with btrfs. All of the
extent stuff assumes that PAGE_SIZE <= sectorsize.
I confirmed this by forcing mkfs.btrfs to use an 8K sectorsize on
sparc64 and I was
without them being in the history?
> It also totally screws the commit statistics, wiping me and John and the
> committers we have preserved out, replacing everybody's committer with
> David Miller.
I am well aware of this downside, sorry.
--
To unsubscribe from this list: send t
From: mark gross <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 07:54:48 -0800
> Something could be done:
> we could enable drivers to have DMA-pools they manage that get mapped
> and are re-used.
>
> I would rather the DMA-pools be tied to PID's that way any bad behavior
> would be limited to the ad
From: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 16:04:52 +0100 (CET)
> I still don't like the idea of btrfs trying to be smarter than a user
> who can partition up his system according to
> (a) his likes
> (b) system or hardware requirements or recommendations
> to alig
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 10:48:38 -0800 (PST)
> On Tue, 12 Feb 2008, James Bottomley wrote:
> > Yes ... I don't do that ... Like I said, I only rebase for an actual
> > conflict.
>
> And this is how things should work.
And if conflicts happen every day, wh
From: Greg KH <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 11:15:53 -0800
> On Tue, Feb 12, 2008 at 10:26:53AM -0800, Linus Torvalds wrote:
> > We absolutely MUST NOT have the mindset that "cross-subsystem conflicts
> > happen all the time".
>
> They usually don't, by virtue of our current develo
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 10:59:00 -0800 (PST)
> That sure as hell would put the pain on API changes solidly where it
> belongs.
If a person does a driver API change and does all the work to sweep
the entire tree updating all the drivers, doesn't it penalize
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 10:26:53 -0800 (PST)
> We absolutely MUST NOT have the mindset that "cross-subsystem conflicts
> happen all the time".
Perhaps not, but self-conflicts are the bigger issue for the
networking.
If I (or Jeff or John) push a bug fix
From: James Bottomley <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 12:24:42 -0600
> Hm ... I think net is a counter example to this. Rebases certainly work
> for them. The issue, I thought, was around the policy of rebasing and
> how often.
>
> I see the question as being one of who creates the h
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 16:44:47 -0800 (PST)
> gitk --merge
...
> This is something where I actually think git could and should do better:
> git has the capability to act as more of a "quilt replacement", but
> because it wasn't part of the original
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 16:37:42 -0800
> Well there's a case in point. rcupdate.h is not a part of networking, and
> it is random tree-wandering like this which causes me problems and which
> will cause Stephen problems.
>
> Now, I don't know which tree "ow
From: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Wed, 13 Feb 2008 00:42:56 +0100 (CET)
>
> On Feb 12 2008 15:38, David Miller wrote:
> >
> >> I still don't like the idea of btrfs trying to be smarter than a user
> >> who can partition up his system acco
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 11:36:24 -0500
> Rebasing is low impact only if you don't have git downstream people.
> Otherwise, you're just treating it as a useful quilt clone, really.
Understood.
One of the key operations that I'm interested in is removing things
From: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 15:21:52 +0100 (CET)
> For sparc you could have something like
>
> startlbaendlba type
> sda10 2 1 Boot
> sda22 58 3 Whole disk
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 17:41:19 -0800 (PST)
> Trust me, you don't know how good you have it.
I know, preserving history is valuable.
I'll take up the various suggestions and try working
a little differently this time around. We'll see
how well it works.
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 17:31:10 -0800 (PST)
> You don't see the problems as much, because you merge probably only
> about a tenth of the volume I merge, and you can keep track of the
> subsystem more.
Good point.
Now how do I remove a bogus commit for a t
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 18:06:13 -0800
> So perhaps a better workflow would be keep the linux-next trees all
> messy, and then each developer can consolidate, rebase, join and
> drop things prior to sending their individual trees to Linus.
We could do that,
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 16:50:46 -0800
> All the users of hlist_for_each_entry_continue had to intialize pos
> before use; change API so pos is a pure temporary variable which matches
> the usage of other _for_each_entry routines.
>
> Signed-off-by:
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 16:53:50 -0800 (PST)
> The fact is, that "outlying code" is where we have all the bulk of the
> code, and it's also where we have all those developers who aren't on the
> "inside track". So we should help the outliers, not the core
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 12:07:07 -0800 (PST)
>
>
> On Tue, 12 Feb 2008, J. Bruce Fields wrote:
> >
> > But the "author" is still preserved, right? Why do you need the
> > committer name to be preserved? (I'm not denying that there could be
> > reasons,
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 16:49:46 -0800 (PST)
> Btw, on that note: if some quilt user can send an "annotated history file"
> of their quilt usage, it's something that git really can do, and I'll see
> if I can merge (or rather, coax Junio to merge) the rele
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 16:47:26 -0800
> My usual way of fixing these things when they pop up is to just move
> the offending addition to some random position other than
> end-of-list. I must have done this hundreds of times and as yet I
> don't think anyone
From: Chris Mason <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 09:35:20 -0500
> From my point of view, 0 is a bad idea because it is very likely to
> conflict with other things.
Starting at 0 is a bad idea because otherwise you'll waste
significant chunks of your disk on Sparc because of reasons
I'
From: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 15:00:20 +0100 (CET)
> Something looks wrong here. Why would btrfs need to zero at all?
So that existing superblocks on the partition won't
be interpreted as correct by other filesystems. It's
a safety measure many mkfs programs use
From: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 15:00:20 +0100 (CET)
> (Yes, I had xfs on sparc before, so it's not like you NEED the
> whitespace at the start of a partition.)
You actully do unless you want to lose significant chunks of your disk
space.
The Sun disk label only
From: Chris Mason <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 09:08:59 -0500
> I've had requests to move the super down to 64k to make room for
> bootloaders, which may not matter for sparc, but I don't really plan
> on different locations for different arches.
The Sun disk label sits in the first
From: SDiZ <[EMAIL PROTECTED]>
Date: Wed, 13 Feb 2008 11:40:30 +0800
> This patch fix bugzilla #9027.
> ``Syslog flooded with "hci_scodata_packet: hci0 SCO packet for unknown
> connection handle 92" message"
>
> see http://bugzilla.kernel.org/show_bug.cgi?id=9027
Marcel, please ACK and I'll push
From: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Wed, 13 Feb 2008 00:39:16 +0100 (CET)
> On the other hand, the H and S of CHS could be lowered and S increased,
> e.g. divide H by 2, divide S by 2, multiply S by 4. This gives a finer
> bytes/cylinder granularity.
That's really not an option when yo
From: "John W. Linville" <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 12:04:22 -0500
> net-2.6.26 updates certain to go to the next release
> net-2.6.26-maybeupdates that might not make it to the next
> release
If I knew something was "maybe" ahead of time I simply
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 22:24:05 -0800
> I'm seeing a strange hang with current git (head 96b5a46e) on an ia64
> box -- an Intel SDV with 2 dual core hyperthreaded Itanium 2 CPUs (so
> 8 logical CPUs to the kernel). It hangs without printing anything
> ("Unc
From: Greg KH <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 23:02:15 -0800
> In the big "linux-next" series of emails, David Miller suggested that
> the feature-removal-schedule file be broken up into little pieces, as it
> is causing merge problems for different trees.
>
As I mentioned to a few ppc folks at LCA08 I plan to use
the LMB code from powerpc as a basis for NUMA support on
sparc64.
There are two changes.
1) Move arch/powerpc/mm/lmb.c to lib/lmb.c, put the main
interface bits in include/linux/lmb.h, put arch-specific
bits in asm/lmb.h and add Kcon
From: Sam Ravnborg <[EMAIL PROTECTED]>
Date: Wed, 13 Feb 2008 09:57:35 +0100
> Review had been easier if the patch was inlined.
Sorry :)
> Can we plase have this changed to use:
>
> config SPARC64
> + select HAVE_LMB
>
> And then in lib/Kconfig have
> +config HAVE_LMB
> + bool
>
> So
From: Sam Ravnborg <[EMAIL PROTECTED]>
Date: Wed, 13 Feb 2008 10:04:51 +0100
> On Wed, Feb 13, 2008 at 12:54:33AM -0800, David Miller wrote:
> > Also, we need to make sure we can properly handle top-level
> > container-like items. For example, where would menuconfigs like
&
From: Sam Ravnborg <[EMAIL PROTECTED]>
Date: Wed, 13 Feb 2008 09:45:41 +0100
> So we could do:
>
> config foo
> tristate "do you want foo?"
> depends on USB && BAR
> module
> obj-$(CONFIG_FOO) += foo.o
> foo-y := file1.o file2.o
> help
> foo will al
From: Ingo Molnar <[EMAIL PROTECTED]>
Date: Wed, 13 Feb 2008 13:57:25 +0100
> so .. how about the patch below? Note that we already had an "early
> bootup" special (the rq->idle check), it's now just made explicit via
> the scheduler_running flag.
I don't see what the problem is.
It is legal t
From: Kumar Gala <[EMAIL PROTECTED]>
Date: Wed, 13 Feb 2008 07:12:26 -0600
> Does sparc have the concept of a phys_addr_t? We are in the process
> of expanding the lmb support to deal with 36-bit physical addresses on
> 32-bit machines.
On sparc64, where I intend to use this, unsigned long's
From: Kumar Gala <[EMAIL PROTECTED]>
Date: Wed, 13 Feb 2008 07:37:27 -0600 (CST)
> If we add to an empty lmb region with a non-zero base we will not coalesce
> the number of regions done to one. This causes problems on ppc32 for the
> memory region as its assumed to only have one region.
>
> We
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Thu, 14 Feb 2008 09:50:42 +1100
>
> On Wed, 2008-02-13 at 16:43 -0600, Becky Bruce wrote:
> > Convert the lmb code to use phys_addr_t instead of unsigned long for
> > physical addresses and sizes. This is needed to support large amounts
> >
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Wed, 13 Feb 2008 15:52:45 -0800
> On Wed, 13 Feb 2008 15:37:44 -0800
> "Paul E. McKenney" <[EMAIL PROTECTED]> wrote:
>
> > Ah. It does take a bit to get fib_trie into one's build -- allyesconfig
> > doesn't cut it.
>
> This is not good. The sole pu
[LMB]: Make lmb support large physical addressing
Convert the lmb code to use u64 instead of unsigned long for physical
addresses and sizes. This is needed to support large amounts of RAM
on 32-bit systems that support 36-bit physical addressing.
Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
S
[LMB]: Fix bug in __lmb_alloc_base().
We need to check lmb_add_region() for errors, it can run out
of regions etc.
Also, the size needs to be padded to the given alignment
or else the lmb.reserved regions don't get expanded and
instead we get tons of holes and eventually run out of
regions prema
I've taken into consideration the various feedback, and
ported the bug fix and other LMB patches posted recently
in an effort to keep the patch churn by others down wrt.
my moving of these files.
1) Use HAVE_LMB as suggested by Sam.
2) Fix potential build errors wrt. asm/prom.h dependencies.
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Wed, 13 Feb 2008 23:29:46 +0200
> This patch removes the unused EXPORT_SYMBOL_GPL(__inet_hash_connect).
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
From: "Tony Luck" <[EMAIL PROTECTED]>
Date: Wed, 13 Feb 2008 16:59:30 -0800
> > It is legal to access per-cpu data as early as you like,
> > it just evaluates to the static copy in the per-cpu section
> > of the kernel image until the per-cpu areas are setup.
>
> On ia64 per-cpu variables are map
[LIB]: Make PowerPC LMB code generic so sparc64 can use it too.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig|1 +
arch/powerpc/kernel/btext.c |3 +-
arch/powerpc/kernel/crash.c |3 +-
arch/powerpc/kernel/crash
[LMB]: Fix initial lmb add region with a non-zero base
If we add to an empty lmb region with a non-zero base we will not
coalesce the number of regions down to one. This causes problems on
ppc32 for the memory region as its assumed to only have one region.
We can fix this be easily specially ca
From: James Bottomley <[EMAIL PROTECTED]>
Date: Wed, 13 Feb 2008 19:11:53 -0600
>
> On Wed, 2008-02-13 at 16:16 -0800, Andrew Morton wrote:
> > kill-warnings-in-mptbaseh-on-parisc64.patch
>
> > Warning fixes.
>
> Not sure ... LSI is supposed to be processing this.
James, please don't push bu
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Wed, 13 Feb 2008 23:29:40 +0200
> This patch makes the needlessly global secmark_tg_destroy() static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
From: James Morris <[EMAIL PROTECTED]>
Date: Thu, 14 Feb 2008 10:41:19 +1100 (EST)
> On Wed, 13 Feb 2008, Paul Moore wrote:
>
> > On Wednesday 13 February 2008 4:29:40 pm Adrian Bunk wrote:
> > > This patch makes the needlessly global secmark_tg_destroy() static.
> > >
> > > Signed-off-by: Adrian
From: Becky Bruce <[EMAIL PROTECTED]>
Date: Thu, 14 Feb 2008 14:58:22 -0600
> Thanks for picking up the patches from Kumar and myself and fitting
> them into your series - this is much appreciated. FYI, I applied the
> entire patch series to my local tree and test-booted both mpc8641 and
>
From: Josh Boyer <[EMAIL PROTECTED]>
Date: Thu, 14 Feb 2008 15:24:48 -0600
> I plan on actually testing this on Ebony, Walnut, and Bamboo either
> later tonight or tomorrow. I don't expect many issues.
>
> Dave, those above boards would cover the build of PowerPC 4xx CPU cores.
Ok.
--
To unsubs
From: [EMAIL PROTECTED]
Date: Thu, 14 Feb 2008 13:02:40 -0800
> Subject: net: xfrm statistics depend on INET
> From: Paul Mundt <[EMAIL PROTECTED]>
>
> net/built-in.o: In function `xfrm_policy_init':
> /home/pmundt/devel/git/sh-2.6.25/net/xfrm/xfrm_policy.c:2338: undefined
> reference to `snmp_m
From: Jozsef Kadlecsik <[EMAIL PROTECTED]>
Date: Thu, 14 Feb 2008 16:02:29 +0100 (CET)
> Hi,
>
> On Sun, 10 Feb 2008, Jeff Chua wrote:
>
> > Please note the lastest git commit is missing one part (which was in
> > Jozsef's
> > original patch).
>
> Sorry everyone, that's my fault: the patch I s
From: Keiichi KII <[EMAIL PROTECTED]>
Date: Fri, 15 Feb 2008 18:45:48 +0900
> This patch avoids a null pointer dereference when we read local_mac
> for netconsole in configfs and shows default local mac address
> value.
>
> A null pointer dereference occurs when we call show_local_mac() via
> l
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Fri, 15 Feb 2008 15:21:48 +0100
> On linux-2.6.25-rc1 x86_64 :
>
> offsetof(struct dst_entry, lastuse)=0xb0
> offsetof(struct dst_entry, __refcnt)=0xb8
> offsetof(struct dst_entry, __use)=0xbc
> offsetof(struct dst_entry, next)=0xc0
>
> So it should b
From: Michael Ellerman <[EMAIL PROTECTED]>
Date: Sat, 16 Feb 2008 06:05:37 +1100
> That fixes the build failures I was seeing, ack.
Thanks for testing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Fri, 15 Feb 2008 11:03:14 -0500
> Please pull from 'upstream-davem' branch of
> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
> upstream-davem
Pulled and pushed out.
As I mentioned to John Linville just now, I'm going to try
and k
From: [EMAIL PROTECTED]
Date: Fri, 15 Feb 2008 20:49:33 -0800
> Subject: bluetooth: fix warning in net/bluetooth/hci_sysfs.c
> From: Andrew Morton <[EMAIL PROTECTED]>
>
> net/bluetooth/hci_sysfs.c: In function 'del_conn':
> net/bluetooth/hci_sysfs.c:339: warning: suggest parentheses around assign
I don't think imposing the limitations of a non-gcc compiler
is rasonable.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at htt
I'm not pulling this crap into my tree to deal with limitations
of a non-gcc compiler.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the
From: Claudio Fontana
Date: Thu, 25 Oct 2012 13:15:43 +0200
> adds a "hwaddr" to the "IP-Config: Complete" KERN_INFO message
> with the dev_addr of the device selected for auto configuration.
>
> Signed-off-by: Claudio Fontana
Applied to net-next
--
To unsubscribe from this list: send the line
From: Jason Wang
Date: Mon, 29 Oct 2012 14:15:49 +0800
> @@ -110,6 +110,11 @@ struct tap_filter {
> unsigned char addr[FLT_EXACT_COUNT][ETH_ALEN];
> };
>
> +/* 1024 is probably a high enough limit: modern hypervisors seem to support
> on
> + * the order of 100-200 CPUs so this leaves
From: "John W. Linville"
Date: Wed, 31 Oct 2012 13:37:40 -0400
> The biggest portion of this is a pull request from Johannes Berg:
>
> "Please pull my mac80211.git tree per below to get a number of fixes. I
> have included a patch from Antonio to fix a memcpy overrun, Felix's
> patches for the a
From: Felipe Balbi
Date: Thu, 1 Nov 2012 09:21:16 +0200
> then we can merge to net tree and handle the conflicts when merging to
> Linus, that'd be fine by me as long as people know how to solve the
> conflict properly ;-)
Like Herbert with the crypto tree, I'm simply not merging this
absolute c
Series applied to net-next, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Nicolas Ferre
Date: Wed, 31 Oct 2012 17:04:49 +0100
> This is an enhancement work that began several years ago. I try to catchup
> with
> some performance improvement that has been implemented then by Havard.
> The ring index logic and the TX error path modification are the biggest
> chan
301 - 400 of 15407 matches
Mail list logo
