* Re: linux-next: Tree for January 2
From: Rafael J. Wysocki @ 2009-01-02 14:08 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, Greg KH
In-Reply-To: <20090102203303.f314a99a.sfr@canb.auug.org.au>
On Friday 02 January 2009, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20081231:
>
> Removed tree:
> boot-params (became 2.6.30 material)
>
> Dropped trees (temporarily):
> driver-core (build problem)
Can you please tell me what exactly the build problem with the driver-core tree
is? Maybe I can fix it.
Thanks,
Rafael
^ permalink raw reply
* Re: linux-next: manual merge of the rr_cpumask tree
From: Mike Travis @ 2009-01-02 17:21 UTC (permalink / raw)
To: Rusty Russell; +Cc: Stephen Rothwell, linux-next, Ingo Molnar
In-Reply-To: <200901021617.40995.rusty@rustcorp.com.au>
Rusty Russell wrote:
> On Friday 02 January 2009 13:05:57 Stephen Rothwell wrote:
>> Hi Rusty,
>>
>> Today's linux-next merge of the rr_cpumask tree got a conflict in
>> arch/x86/kernel/io_apic.c between commit
>> 22f65d31b25a320a5246592160bcb102d2791c45 ("x86: Update io_apic.c to use
>> new cpumask API") from the cpus4096 tree and commit
>> 2ca1a615835d9f4990f42102ab1f2ef434e7e89c ("Merge branch 'master' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6") (or
>> something - I suspect git has failed me a little here)
>
> Yes, I've had several 'git blame' pointing to merges from Ingo's tree.
> And they tend to be n-way merges, so tracing it down is too hard.
>
> The cpus4096 tree is supposed to have already merged the cpumask tree,
> so this should not have happened.
>
>> I have dropped the rr_cpumask tree for today and also the rr tree that
>> depends on it.
>
> OK I will remove this dependency for the moment.
>
> Rusty.
Hi Rusty & Stephen,
Thanks for dealing with these thorny issues.
Yes, if there's a more pita file than sched.c it's io_apic.c ... ;-)
Cheers,
Mike
^ permalink raw reply
* Re: linux-next: Tree for January 2
From: Greg KH @ 2009-01-02 17:52 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Stephen Rothwell, linux-next, LKML
In-Reply-To: <200901021508.34847.rjw@sisk.pl>
On Fri, Jan 02, 2009 at 03:08:34PM +0100, Rafael J. Wysocki wrote:
> On Friday 02 January 2009, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20081231:
> >
> > Removed tree:
> > boot-params (became 2.6.30 material)
> >
> > Dropped trees (temporarily):
> > driver-core (build problem)
>
> Can you please tell me what exactly the build problem with the driver-core tree
> is? Maybe I can fix it.
Sorry about that, I've now fixed it, and pushed it up to kernel.org.
But I think I missed the pull time for this release of linux-next.
thanks,
greg k-h
^ permalink raw reply
* [PATCH -next] 9p: fix RDMA dependency
From: Randy Dunlap @ 2009-01-02 18:18 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, LKML, Andrew Morton, Eric Van Hensbergen,
Roland Dreier
In-Reply-To: <20090102203303.f314a99a.sfr@canb.auug.org.au>
From: Randy Dunlap <randy.dunlap@oracle.com>
NET_9P_RDMA uses Infiniband RDMA, which is controlled by the
INFINIBAND_ADDR_TRANS kconfig symbol, so fix NET_9P so that it builds
cleanly.
Found by inspection (suspicion) and then forced via kconfig.
ERROR: "rdma_destroy_id" [net/9p/9pnet_rdma.ko] undefined!
ERROR: "rdma_connect" [net/9p/9pnet_rdma.ko] undefined!
ERROR: "rdma_create_id" [net/9p/9pnet_rdma.ko] undefined!
ERROR: "rdma_create_qp" [net/9p/9pnet_rdma.ko] undefined!
ERROR: "rdma_resolve_route" [net/9p/9pnet_rdma.ko] undefined!
ERROR: "rdma_disconnect" [net/9p/9pnet_rdma.ko] undefined!
ERROR: "rdma_resolve_addr" [net/9p/9pnet_rdma.ko] undefined!
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
cc: Eric Van Hensbergen <ericvh@gmail.com>
cc: Roland Dreier <rolandd@cisco.com>
---
net/9p/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20090102.orig/net/9p/Kconfig
+++ linux-next-20090102/net/9p/Kconfig
@@ -23,7 +23,7 @@ config NET_9P_VIRTIO
guest partitions and a host partition.
config NET_9P_RDMA
- depends on INET && INFINIBAND && EXPERIMENTAL
+ depends on INET && INFINIBAND_ADDR_TRANS && EXPERIMENTAL
tristate "9P RDMA Transport (Experimental)"
help
This builds support for an RDMA transport.
--
~Randy
^ permalink raw reply
* [PATCH -next] sunrpc: fix RDMA dependency
From: Randy Dunlap @ 2009-01-02 18:18 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, LKML, Andrew Morton, J. Bruce Fields, Trond Myklebust,
Roland Dreier
In-Reply-To: <20090102203303.f314a99a.sfr@canb.auug.org.au>
From: Randy Dunlap <randy.dunlap@oracle.com>
SUNRPC_XPRT_RDMA uses Infiniband RDMA support, so make it depend on
that kconfig symbol for clean builds.
net/built-in.o: In function `rpcrdma_ep_disconnect':
(.text+0x9c2a8): undefined reference to `rdma_disconnect'
net/built-in.o: In function `rpcrdma_create_id':
verbs.c:(.text+0x9c39f): undefined reference to `rdma_create_id'
verbs.c:(.text+0x9c3e3): undefined reference to `rdma_resolve_addr'
verbs.c:(.text+0x9c439): undefined reference to `rdma_resolve_route'
verbs.c:(.text+0x9c482): undefined reference to `rdma_destroy_id'
net/built-in.o: In function `rpcrdma_ep_destroy':
(.text+0x9c84d): undefined reference to `rdma_destroy_qp'
net/built-in.o: In function `rpcrdma_ia_close':
(.text+0x9cb44): undefined reference to `rdma_destroy_qp'
net/built-in.o: In function `rpcrdma_ia_close':
(.text+0x9cb4b): undefined reference to `rdma_destroy_id'
net/built-in.o: In function `rpcrdma_ia_open':
(.text+0x9cdb4): undefined reference to `rdma_destroy_id'
net/built-in.o: In function `rpcrdma_ep_connect':
(.text+0x9d2dd): undefined reference to `rdma_destroy_id'
net/built-in.o: In function `rpcrdma_ep_connect':
(.text+0x9d2eb): undefined reference to `rdma_destroy_qp'
net/built-in.o: In function `rpcrdma_ep_connect':
(.text+0x9d2f8): undefined reference to `rdma_destroy_id'
net/built-in.o: In function `rpcrdma_ep_connect':
(.text+0x9d319): undefined reference to `rdma_create_qp'
net/built-in.o: In function `rpcrdma_ep_connect':
(.text+0x9d3e0): undefined reference to `rdma_connect'
net/built-in.o: In function `svc_rdma_detach':
svc_rdma_transport.c:(.text+0x9ddbb): undefined reference to `rdma_disconnect'
net/built-in.o: In function `__svc_rdma_free':
svc_rdma_transport.c:(.text+0x9f041): undefined reference to `rdma_destroy_id'
net/built-in.o: In function `svc_rdma_accept':
svc_rdma_transport.c:(.text+0x9f362): undefined reference to `rdma_create_qp'
svc_rdma_transport.c:(.text+0x9f388): undefined reference to `rdma_create_qp'
svc_rdma_transport.c:(.text+0x9f553): undefined reference to `rdma_accept'
svc_rdma_transport.c:(.text+0x9f682): undefined reference to `rdma_destroy_id'
net/built-in.o: In function `svc_rdma_create':
svc_rdma_transport.c:(.text+0x9f70e): undefined reference to `rdma_create_id'
svc_rdma_transport.c:(.text+0x9f739): undefined reference to `rdma_bind_addr'
svc_rdma_transport.c:(.text+0x9f762): undefined reference to `rdma_listen'
svc_rdma_transport.c:(.text+0x9f79e): undefined reference to `rdma_destroy_id'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
cc: J. Bruce Fields <bfields@fieldses.org>
cc: Trond Myklebust <Trond.Myklebust@netapp.com>
cc: Roland Dreier <rolandd@cisco.com>
---
fs/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20090102.orig/fs/Kconfig
+++ linux-next-20090102/fs/Kconfig
@@ -1305,7 +1305,7 @@ config SUNRPC_GSS
config SUNRPC_XPRT_RDMA
tristate
- depends on SUNRPC && INFINIBAND && EXPERIMENTAL
+ depends on SUNRPC && INFINIBAND_ADDR_TRANS && EXPERIMENTAL
default SUNRPC && INFINIBAND
help
This option enables an RPC client transport capability that
--
~Randy
^ permalink raw reply
* Re: [PATCH -next] 9p: fix RDMA dependency
From: Roland Dreier @ 2009-01-02 19:59 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, linux-next, LKML, Andrew Morton,
Eric Van Hensbergen, Roland Dreier
In-Reply-To: <495E5A82.9000603@oracle.com>
> config NET_9P_RDMA
> - depends on INET && INFINIBAND && EXPERIMENTAL
> + depends on INET && INFINIBAND_ADDR_TRANS && EXPERIMENTAL
> tristate "9P RDMA Transport (Experimental)"
This actually allows the broken config INFINIBAND=m and NET_9P_RDMA=y.
I think the answer is to add INFINIBAND_ADDR_TRANS but leave INFINIBAND
too. The SUNRPC_XPRT_RDMA patch would have the same problem, but since
SUNRPC_XPRT_RDMA is a hidden option (with help text ?!) that gets set
automatically, there's no way to create the problem config.
- R.
^ permalink raw reply
* Re: linux-next: driver-core tree build failure
From: Stephen Rothwell @ 2009-01-03 4:32 UTC (permalink / raw)
To: Greg KH; +Cc: Mark McLoughlin, linux-next
In-Reply-To: <20090102072646.GA3569@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 394 bytes --]
Hi Greg,
On Thu, 1 Jan 2009 23:26:46 -0800 Greg KH <greg@kroah.com> wrote:
>
> Ugh, very sorry about this, I forgot to push the changes up to the
> kernel.org servers after I made them.
That's OK.
> Should be there now, thanks for your patience,
Good for Monday, then.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: usb tree build failure
From: Stephen Rothwell @ 2009-01-03 4:33 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, Inaky Perez-Gonzalez
In-Reply-To: <20090102072710.GB3569@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 363 bytes --]
Hi Greg,
On Thu, 1 Jan 2009 23:27:10 -0800 Greg KH <greg@kroah.com> wrote:
>
> Yes he did, sorry, am on vacation with limited network access. I'll try
> to get to this tomorrow.
Again, not a problem. I'll do the next release Monday, my time.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the security-testing tree
From: David Howells @ 2009-01-03 22:55 UTC (permalink / raw)
To: Stephen Rothwell
Cc: dhowells, Mark Fasheh, linux-next, Tiger Yang, James Morris,
Jan Kara
In-Reply-To: <20081231125025.b74309b1.sfr@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> This conflict is now between the ocfs2 tree and Linus' tree (the
> security-testing tree beat you to being merged :-)).
Replace current->fsuid with current_fsuid().
David
^ permalink raw reply
* Re: [PATCH V2 00/16] Squashfs: compressed read-only filesystem
From: Phillip Lougher @ 2009-01-04 7:55 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-embedded, linux-fsdevel, linux-kernel, tim.bird, linux-next,
sfr
In-Reply-To: <20081028192919.94def38b.akpm@linux-foundation.org>
Andrew Morton wrote a couple of months ago (sadly how time flies):
> - what are the limitations of squashfs (please add this to the
> changelog of patch #1 or something). Does it support nfsd? (yes, it
> does!) xatrs and acls? File size limits, entries-per-directory,
> etc, etc?
Xattrs and acls are not supported, this is a todo.
Filesize limits are in theory 2^64. In practice about 2 TiB.
No limits on the entries per directory.
>
> What is on the todo list?
>
Xattrs and ACLs.
The above information has been added to a squashfs.txt file.
> - Please check that all non-static identifiers really did need global
> scope. I saw some which surprised me a bit.
>
> - Please check that all global identifiers have suitable names. For
> example "get_fragment_location" is a poor choice for a kernel-wide
> identifier. It could clash with other subsystems, mainly. Plus it
> is hardly self-identifying. I see quite a few such cases.
Done and fixed.
>
> - The fs uses vmalloc() rather a lot. I'd suggest that this be
> explained and justified in the design/implementation overview,
> wherever that is. This should include a means by which we can
> estimate (or at least understand) the amount of memory which will be
> allocated in this way.
>
> Because vmalloc() is unreliable. It is a fixed-size resource on
> each machine. Some machines will run out much much earlier than
> others. It will set an upper limit on the number of filesystems
> which can be concurrently mounted, and presumably upon the size of
> those filesystems. One a per-machine basis, which is worse.
>
> It also exposes users to vmalloc arena fragmentation. eg: mount
> ten 1G filesystems, then unmount every second one, then try to mount
> a 2G filesystem and you find you have no contiguous vmalloc space
> (simplified example).
>
> See, this vmalloc thing is a fairly big deal. What's up with all
> of this??
Vmalloc was used to allocate block data (128 Kib by default).
I've removed all vmallocs from Squashfs. All buffers are now kmalloced
in PAGE_CACHE_SIZEd chunks.
>
> - The fs uses brelse() in quite a few places where the bh is known to
> be non-zero. Suggest that these be converted to the more efficient
> and modern put_bh().
>
Fixed.
> - this:
>
> +/*
> + * Blocks in Squashfs are compressed. To avoid repeatedly decompressing
> + * recently accessed data Squashfs uses two small metadata and fragment caches.
> + *
> + * This file implements a generic cache implementation used for both caches,
> + * plus functions layered ontop of the generic cache implementation to
> + * access the metadata and fragment caches.
> + */
>
> confuses me. Why not just decompress these blocks into pagecache
> and let the VFS handle the caching??
>
The cache is not used for file datablocks, these are decompressed and
cached in the page-cache in the normal way. The cache is only used to
temporarily cache fragment and metadata blocks which have been read as
as a result of a metadata (i.e. inode or directory) or fragment access.
Because metadata and fragments are packed together into blocks (to
gain greater compression) the read of a particular piece of metadata or
fragment will retrieve other metadata/fragments which have been packed
with it, these because of locality-of-reference may be read in the near
future. Temporarily caching them ensures they are available for near
future access without requiring an additional read and decompress.
The cache is deliberately kept small to only cache the last couple of
blocks read. The total overhead is 3 x block_size (128 KiB) for
fragments and 8 x 8 KiB for metadata blocks, or a total of 448 KiB.
If you think this is too large I can reduce the number of fragments and
metadata blocks cached.
Because these blocks are greater than PAGE_CACHE_SIZE is not easy to use
the page cache. As Joern said "there really isn't any infrastructure to
deal with such cases yet. Bufferheads deal with blocks smaller than a
page, not the other way around." Storing these in the page cache
introduces a lot more complexity in terms of locking and associated race
conditions.
As previously mentioned I have rewritten the cache implementation to
avoid vmalloc and to use PAGE_CACHE_SIZE blocks. This eliminates the
vmalloc fragment issues, and is a first step in moving the
implementation over to using the page cache in the future.
> The real bug here is that this rather obvious question wasn't
> answered anywhere in the patch submission (afaict). How to fix that?
>
> Methinks we need a squashfs.txt which covers these things.
Added to a new squashfs.txt file.
>
> - I suspect that squashfs_cache_put() has races around the handling
> of cache->waiting. Does it assume that another CPU wrote that flag
> prior to adding itself to the waitqueue? How can the other task do
> that atomically? What about memory ordering issues?
>
> Suggest that cache->lock coverage be extended to clear all this up.
>
Fixed.
> - Quite a few places do kzalloc(a * b, ...). Please convert to
> kcalloc() which has checks for multiplicative overflows.
Fixed.
>
>> There is now a public git repository on kernel.org. Pull/clone from
>> git://git.kernel.org/pub/scm/linux/kernel/git/pkl/squashfs-2.6.git
>
> Generally looks OK to me. Please prepare a tree for linx-next
> inclusion and unless serious problems are pointed out I'd suggest
> shooting for a 2.6.29 merge.
>
Ok. I'll re-spin the patches against 2.6.28 tomorrow (Sunday), and I'll
prepare a tree for linux-next.
Thanks
Phillip
^ permalink raw reply
* Re: linux-next: kvm tree build failure
From: Avi Kivity @ 2009-01-04 11:08 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Avi Kivity, linux-next, Jan Kiszka, Hollis Blanchard
In-Reply-To: <20090102115354.46fc59e0.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> And again. Can you please find some fix for this so that the kvm tree
> can get some integration testing ...
>
Hollis, help!
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH V2 00/16] Squashfs: compressed read-only filesystem
From: Leon Woestenberg @ 2009-01-04 19:04 UTC (permalink / raw)
To: Phillip Lougher
Cc: Andrew Morton, linux-embedded, linux-fsdevel, linux-kernel,
tim.bird, linux-next, sfr
In-Reply-To: <49606B7C.7050403@lougher.demon.co.uk>
Hello,
On Sun, Jan 4, 2009 at 8:55 AM, Phillip Lougher
<phillip@lougher.demon.co.uk> wrote:
>> - what are the limitations of squashfs (please add this to the
>> changelog of patch #1 or something). Does it support nfsd? (yes, it
>> does!) xatrs and acls? File size limits, entries-per-directory,
>> etc, etc?
>
> Xattrs and acls are not supported, this is a todo.
> Filesize limits are in theory 2^64. In practice about 2 TiB.
>
...
>
> Ok. I'll re-spin the patches against 2.6.28 tomorrow (Sunday), and I'll
> prepare a tree for linux-next.
>
For use cases such as embedded firmware, the limitations are
non-interesting, and the compression savings are very interesting.
Especially where the resulting filesystem has to creep through slow
wires such as half duplex serial links etc.
Have been using squashfs 2.2 up to 3.4 without problems for years, for
distribution of Linux based firmwares into embedded devices.
Many thanks for your continued efforts on mainlining squashfs,
Regards,
--
Leon
^ permalink raw reply
* Re: linux-next: kvm tree build failure
From: Hollis Blanchard @ 2009-01-04 19:45 UTC (permalink / raw)
To: Avi Kivity; +Cc: Stephen Rothwell, linux-next, Jan Kiszka
In-Reply-To: <49609896.201@redhat.com>
On Sun, 2009-01-04 at 13:08 +0200, Avi Kivity wrote:
> Stephen Rothwell wrote:
> > And again. Can you please find some fix for this so that the kvm tree
> > can get some integration testing ...
> >
>
> Hollis, help!
The "disarm" patch should fix the build. I'll resend that in a moment.
I'd like to remind you though that the cause of this breakage was the
debug patches you applied. It's also worth noting that the "fix" is to
delete functionality, so any way you look at it it's not a good
situation.
Between that and other kernel breakage (like Rusty's
smp_call_function_many patch), it has taken a lot of effort just to try
to catch up.
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: linux-next: kvm tree build failure
From: Avi Kivity @ 2009-01-04 19:55 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: Stephen Rothwell, linux-next, Jan Kiszka
In-Reply-To: <1231098347.7724.11.camel@localhost.localdomain>
Hollis Blanchard wrote:
> The "disarm" patch should fix the build. I'll resend that in a moment.
>
> I'd like to remind you though that the cause of this breakage was the
> debug patches you applied. It's also worth noting that the "fix" is to
> delete functionality, so any way you look at it it's not a good
> situation.
>
No question. We should have identified this earlier (my compile time
tester) and dealt with it. However, note that x86 is the main arch for
kvm; we'll try hard to accommodate ppc, but you must adapt to x86 kvm
changes, or lose functionality.
We'll try to make this tradeoff as rare as possible, of course.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: linux-next: manual merge of the driver-core tree
From: Stephen Rothwell @ 2009-01-04 23:28 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, Kay Sievers, Kumar Gala, Paul Mackerras,
Benjamin Herrenschmidt, linuxppc-dev
In-Reply-To: <20081204042154.GA18027@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]
Hi Greg,
On Wed, 3 Dec 2008 20:21:54 -0800 Greg KH <greg@kroah.com> wrote:
>
> On Thu, Dec 04, 2008 at 10:44:18AM +1100, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the driver-core tree got a conflict in
> > arch/powerpc/platforms/85xx/mpc85xx_mds.c between commit
> > 24a99596f7465274a8e65ddd29a7d9028969b9f9 ("powerpc/85xx: Fix compile
> > warnings in mpc85xx_mds.c") from the galak tree and commit
> > f58f23751464d095f9942304bc5f6072b79a2cc3 ("powerpc: struct device -
> > replace bus_id with dev_name(), dev_set_name()") from the driver-core
> > tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary.
> >
> > Paul, maybe you should apply the patch from the driver-core tree as it
> > was cc'd to you and all its prerequisites are upstream.
>
> Yes, Paul, please apply the patch, and let me know. It will make things
> much easier in the end for everyone involved.
It looks like this has been applied to the powerpc tree and is now in
Linus' tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the rr tree
From: Stephen Rothwell @ 2009-01-04 23:30 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, Kay Sievers, Rusty Russell, Mark McLoughlin
In-Reply-To: <20081222173213.b7340f63.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]
Hi Greg,
On Mon, 22 Dec 2008 17:32:13 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the rr tree got a conflict in
> drivers/virtio/virtio_pci.c between commit
> b5146336e3bc3786712919e94106063036dae86b ("virtio: do not statically
> allocate root device") from the driver-core tree and commits
> f53dba3a1ea82dfb37f094a942ae74032413809f ("virtio: struct device -
> replace bus_id with dev_name(), dev_set_name()") and
> ab4e479d47ceac2fa5bebd5b99d27f01fe0e0c8b ("virtio: add PCI device release
> () function") from the rr tree.
>
> I fixed it up (see below) and can carry the fix as necessary. Mark, does
> this driver-core patch obsolete the second rr tree patch above?
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>
> diff --cc drivers/virtio/virtio_pci.c
> index f772cc4,265fdf2..0000000
> --- a/drivers/virtio/virtio_pci.c
> +++ b/drivers/virtio/virtio_pci.c
> @@@ -324,7 -343,8 +340,8 @@@ static int __devinit virtio_pci_probe(s
> if (vp_dev == NULL)
> return -ENOMEM;
>
> - vp_dev->vdev.dev.parent = &virtio_pci_root;
> + vp_dev->vdev.dev.parent = virtio_pci_root;
> + vp_dev->vdev.dev.release = virtio_pci_release_dev;
> vp_dev->vdev.config = &virtio_pci_config_ops;
> vp_dev->pci_dev = pci_dev;
> INIT_LIST_HEAD(&vp_dev->virtqueues);
This conflict is now between Linus' tree and the driver-core tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH -net-next 1/4] firmware: convert e100 driver to request_firmware()
From: David Miller @ 2009-01-05 0:06 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: jaswinder, linux.nics, e1000-devel, netdev, linux-kernel,
linux-next
In-Reply-To: <9929d2390812301433pae01ea4g5bfdef6d4d4c7a9c@mail.gmail.com>
From: "Jeff Kirsher" <jeffrey.t.kirsher@intel.com>
Date: Tue, 30 Dec 2008 14:33:36 -0800
> Please hold off on committing, until we have had ample time to do some
> regression testing. While this patch may have been in linux-next,
> this is the first we have seen of it.
>
> I am concerned that IPMI traffic will be adversely affected by this patch.
Status please?
^ permalink raw reply
* Re: [PATCH -net-next 2/4] firmware: convert acenic driver to request_firmware() -- without firmware data
From: David Miller @ 2009-01-05 0:10 UTC (permalink / raw)
To: jaswinder; +Cc: netdev, jes, linux-kernel, linux-next
In-Reply-To: <1230635694.10603.20.camel@jaswinder.satnam>
From: Jaswinder Singh Rajput <jaswinder@infradead.org>
Date: Tue, 30 Dec 2008 16:44:54 +0530
> firmware: convert acenic driver to request_firmware()
>
> We store the firmware in its native big-endian form now, so the loop in
> ace_copy() is modified to use be32_to_cpup() when writing it out.
>
> We can forget the BSS,SBSS sections of the firmware, since we were
> clearing all the device's RAM anyway. And the text,rodata,data sections
> can all be loaded as a single chunk since they're contiguous (give or
> take a few dozen bytes in between).
>
> Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH -net-next 3/4] firmware: convert tg3 driver to request_firmware()
From: David Miller @ 2009-01-05 0:11 UTC (permalink / raw)
To: jaswinder; +Cc: jgarzik, netdev, linux-kernel, linux-next
In-Reply-To: <1230626497.24796.26.camel@jaswinder.satnam>
From: Jaswinder Singh Rajput <jaswinder@infradead.org>
Date: Tue, 30 Dec 2008 14:11:37 +0530
> Firmware blob looks like this...
> u8 firmware_major
> u8 firmware_minor
> u8 firmware_fix
> u8 pad
> __be32 start_address
> __be32 length (total, including BSS sections to be zeroed)
> data... (in __be32 words, which is native for the firmware)
>
> Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
I'm simply tired of fighting this, so applied.
^ permalink raw reply
* Re: [PATCH -net-next 4/4] starfire: use request_firmware()
From: David Miller @ 2009-01-05 0:12 UTC (permalink / raw)
To: jaswinder; +Cc: netdev, becker, linux-kernel, linux-next
In-Reply-To: <1230626510.24796.28.camel@jaswinder.satnam>
From: Jaswinder Singh Rajput <jaswinder@infradead.org>
Date: Tue, 30 Dec 2008 14:11:50 +0530
> Firmware blob is big endian
>
> Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH -net-next 1/4] firmware: convert e100 driver to request_firmware()
From: Jeff Kirsher @ 2009-01-05 2:20 UTC (permalink / raw)
To: David Miller
Cc: linux.nics, e1000-devel, netdev, linux-kernel, linux-next,
jaswinder
In-Reply-To: <20090104.160611.252248503.davem@davemloft.net>
On Sun, Jan 4, 2009 at 4:06 PM, David Miller <davem@davemloft.net> wrote:
> From: "Jeff Kirsher" <jeffrey.t.kirsher@intel.com>
> Date: Tue, 30 Dec 2008 14:33:36 -0800
>
>> Please hold off on committing, until we have had ample time to do some
>> regression testing. While this patch may have been in linux-next,
>> this is the first we have seen of it.
>>
>> I am concerned that IPMI traffic will be adversely affected by this patch.
>
> Status please?
> --
>
The only testing left to do is to make sure that ICH devices still
work and to make sure the IPMI traffic is not affected by this patch.
All other testing looks good. I am sorry that I have been slow to
give status, the holiday's have put a strain on available resources.
--
Cheers,
Jeff
------------------------------------------------------------------------------
^ permalink raw reply
* linux-next: manual merge of the ext4 tree
From: Stephen Rothwell @ 2009-01-05 2:49 UTC (permalink / raw)
To: Theodore Tso; +Cc: linux-next, Frank Mayhar, Al Viro
Hi Ted,
Today's linux-next merge of the ext4 tree got a conflict in
fs/ext4/ialloc.c between commit 6b38e842bb832a3dbeb17e382404aef3c40ac5f9
("nfsd race fixes: ext4") from Linus' tree and commit
3cbc16fb3066dabb66eddf192d9e657a14a7ad20 ("ext4: Allow ext4 to run
without a journal") from the ext4 tree.
Really just context changes. I fixed it up (see below) and can carry the
fix for now. You should fix this by merging with Linus' tree (or get
Linus to do it).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc fs/ext4/ialloc.c
index 6e60528,3bcf197..0000000
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@@ -825,11 -890,8 +890,11 @@@ got
ext4_set_inode_flags(inode);
if (IS_DIRSYNC(inode))
- handle->h_sync = 1;
+ ext4_handle_sync(handle);
- insert_inode_hash(inode);
+ if (insert_inode_locked(inode) < 0) {
+ err = -EINVAL;
+ goto fail_drop;
+ }
spin_lock(&sbi->s_next_gen_lock);
inode->i_generation = sbi->s_next_generation++;
spin_unlock(&sbi->s_next_gen_lock);
@@@ -884,9 -948,8 +951,9 @@@ fail_drop
DQUOT_DROP(inode);
inode->i_flags |= S_NOQUOTA;
inode->i_nlink = 0;
+ unlock_new_inode(inode);
iput(inode);
- brelse(bitmap_bh);
+ brelse(inode_bitmap_bh);
return ERR_PTR(err);
}
^ permalink raw reply
* linux-next: manual merge of the rr tree
From: Stephen Rothwell @ 2009-01-05 3:32 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-next, Mike Travis, Ingo Molnar, Christoph Lameter
[-- Attachment #1: Type: text/plain, Size: 672 bytes --]
Hi Rusty,
Today's linux-next merge of the rr tree got a conflict in kernel/module.c
between commit d3794979a8a80c222ce9d016a6dfc4bed36965d0 ("Zero based
percpu: infrastructure to rebase the per cpu area to zero") from the
tip-core tree and the cpualloc patches from the rr tree.
It requires better understanding than I have time for today, so I have
dropped the rr tree for today.
Similarly with init/main.c, include/linux/percpu.h,
include/asm-generic/percpu.h and arch/x86/include/asm/percpu.h (though
against different commits/trees, of course).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: usb tree build failure
From: Greg KH @ 2009-01-05 4:34 UTC (permalink / raw)
To: Inaky Perez-Gonzalez; +Cc: Sam Ravnborg, Stephen Rothwell, linux-next
In-Reply-To: <200812231707.25796.inaky@linux.intel.com>
On Tue, Dec 23, 2008 at 05:07:25PM -0800, Inaky Perez-Gonzalez wrote:
> On Tuesday 23 December 2008, Greg KH wrote:
> > On Tue, Dec 23, 2008 at 02:26:28AM -0800, Inaky Perez-Gonzalez wrote:
> > > On Monday 22 December 2008, Greg KH wrote:
> > > > On Mon, Dec 22, 2008 at 09:26:43AM -0800, Inaky Perez-Gonzalez wrote:
> > > > > On Sunday 21 December 2008, Sam Ravnborg wrote:
> > > > >
> > > > > ops -- ok, I will. I guess I have to add this in all the similar
> > > > > ones, right?
> > > > >
> > > > > Greg, do you want a new patch series or just another patch on top?
> > > >
> > > > Just a single replacement patch for when we add this makefile is fine
> > > > with me.
> > >
> > > Hmmm, there was more feedback Sam gave me on Kconfig and Makefiles I
> > > added, so at the end the patch touches more files than just this one.
> > > Maybe a whole new series will be the way to go.
> >
> > Ick, I really don't want that. But feel free to respin them yourself,
> > and then just send the different patches? It's easy to just replace a
> > few individual ones than to drop the whole series and redo it (well on
> > my end at least...)
> >
> > Heck, tell me what to edit and I can edit individual patches quite
> > easily as well, I'd rather do that as well :)
>
> :) -- find them attached, it's just a couple of them that need a respin
> (#10 and #27).
Thanks, I've now replaced these in my tree and pushed it on out.
greg k-h
^ permalink raw reply
* Re: linux-next: manual merge of the rr tree
From: Greg KH @ 2009-01-05 4:36 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Kay Sievers, Rusty Russell, Mark McLoughlin
In-Reply-To: <20090105103036.dacccbed.sfr@canb.auug.org.au>
On Mon, Jan 05, 2009 at 10:30:36AM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> On Mon, 22 Dec 2008 17:32:13 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the rr tree got a conflict in
> > drivers/virtio/virtio_pci.c between commit
> > b5146336e3bc3786712919e94106063036dae86b ("virtio: do not statically
> > allocate root device") from the driver-core tree and commits
> > f53dba3a1ea82dfb37f094a942ae74032413809f ("virtio: struct device -
> > replace bus_id with dev_name(), dev_set_name()") and
> > ab4e479d47ceac2fa5bebd5b99d27f01fe0e0c8b ("virtio: add PCI device release
> > () function") from the rr tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. Mark, does
> > this driver-core patch obsolete the second rr tree patch above?
> > --
> > Cheers,
> > Stephen Rothwell sfr@canb.auug.org.au
> > http://www.canb.auug.org.au/~sfr/
> >
> > diff --cc drivers/virtio/virtio_pci.c
> > index f772cc4,265fdf2..0000000
> > --- a/drivers/virtio/virtio_pci.c
> > +++ b/drivers/virtio/virtio_pci.c
> > @@@ -324,7 -343,8 +340,8 @@@ static int __devinit virtio_pci_probe(s
> > if (vp_dev == NULL)
> > return -ENOMEM;
> >
> > - vp_dev->vdev.dev.parent = &virtio_pci_root;
> > + vp_dev->vdev.dev.parent = virtio_pci_root;
> > + vp_dev->vdev.dev.release = virtio_pci_release_dev;
> > vp_dev->vdev.config = &virtio_pci_config_ops;
> > vp_dev->pci_dev = pci_dev;
> > INIT_LIST_HEAD(&vp_dev->virtqueues);
>
> This conflict is now between Linus' tree and the driver-core tree.
Thanks for letting me know, I'll fix it up tomorrow when I get back to
the patch queues :)
greg k-h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox