linux-next: current pending merge fix patches

linux-next: current pending merge fix patches

[Stephen Rothwell]

Hi Linus,

I am carrying a few merge fixup patches in linux-next that I thought you
might want a heads up about.  Hopefully, these will be fixed before you
see them, but just in case, here they are (in no particular order).

This could also be taken as a reminder to the respective maintiners that
they may want to do a merge of your tree before asking you to pull theirs.

(of course, the SHA1's may change due to rebasing :-()

1) The acpi[1] tree renames drivers/acpi/processor_core.c
to drivers/acpi/processor_driver.c (commit
5f45c35d7ede1c00cbaa3b09b8a84c425af81c4b "ACPI: processor:
mv processor_core.c processor_driver.c") and then
drivers/acpi/processor_pdc.c to drivers/acpi/processor_core.c
(commit de53479b92857f82e4d595104d112b16733b9949 "ACPI: processor:
mv processor_pdc.c processor_core.c"), so the patch in the
cpufreq[2] tree that modifies drivers/acpi/processor_core.c (commit
0f1d683fb35d6c6f49ef696c95757f3970682a0e "[CPUFREQ] Processor Clocking
Control interface driver") get rather confused.  My solution was to
use the acpi tree's version of drivers/acpi/processor_core.c and apply
this patch:

diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index 7e8e1ba..b5658cd 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -123,6 +123,8 @@ static const struct file_operations acpi_processor_info_fops = {
 #endif
 
 DEFINE_PER_CPU(struct acpi_processor *, processors);
+EXPORT_PER_CPU_SYMBOL(processors);
+
 struct acpi_processor_errata errata __read_mostly;
 
 /* --------------------------------------------------------------------------


2) The i2c[3] tree adds a new file (drivers/i2c/i2c-smbus.c) (patch "i2c:
Add SMBus alert support") that needs updating after the driver-core[4]
tree converts the semaphore in struct device to a mutex (patch
"drivers/base: Convert dev->sem to mutex").

diff --git a/drivers/i2c/i2c-smbus.c b/drivers/i2c/i2c-smbus.c
index 333527c..52aa775 100644
--- a/drivers/i2c/i2c-smbus.c
+++ b/drivers/i2c/i2c-smbus.c
@@ -27,6 +27,7 @@
 #include <linux/workqueue.h>
 #include <linux/i2c.h>
 #include <linux/i2c-smbus.h>
+#include <linux/mutex.h>
 
 struct i2c_smbus_alert {
 	unsigned int		alert_edge_triggered:1;
@@ -55,7 +56,7 @@ static int smbus_do_alert(struct device *dev, void *addrp)
 	 * Drivers should either disable alerts, or provide at least
 	 * a minimal handler.  Lock so client->driver won't change.
 	 */
-	down(&dev->sem);
+	device_lock(dev);
 	if (client->driver) {
 		if (client->driver->alert)
 			client->driver->alert(client, data->flag);
@@ -63,7 +64,7 @@ static int smbus_do_alert(struct device *dev, void *addrp)
 			dev_warn(&client->dev, "no driver alert()!\n");
 	} else
 		dev_dbg(&client->dev, "alert with no driver\n");
-	up(&dev->sem);
+	device_unlock(dev);
 
 	/* Stop iterating after we find the device */
 	return -EBUSY;


3) The nfs[5] tree contains a patch that splits BDI_RECLAIMABLE (commit
d63a2d5fbb857f93df3085593b097dbf4b22bdcc "VM: Split out the accounting
of unstable writes from BDI_RECLAIMABLE") and the ceph[6] tree adds
a use of that (commit 1d3576fd10f0d7a104204267b81cf84a07028dad "ceph:
address space operations"), so I apply the following patch after both
trees have been merged:

diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c
index bf53581..eab46b0 100644
--- a/fs/ceph/addr.c
+++ b/fs/ceph/addr.c
@@ -101,8 +101,7 @@ static int ceph_set_page_dirty(struct page *page)
 
 		if (mapping_cap_account_dirty(mapping)) {
 			__inc_zone_page_state(page, NR_FILE_DIRTY);
-			__inc_bdi_stat(mapping->backing_dev_info,
-					BDI_RECLAIMABLE);
+			__inc_bdi_stat(mapping->backing_dev_info, BDI_DIRTY);
 			task_io_account_write(PAGE_CACHE_SIZE);
 		}
 		radix_tree_tag_set(&mapping->page_tree,


4) The slab[7] tree adds a percpu variable usage case (commit
9dfc6e68bfe6ee452efb1a4e9ca26a9007f2b864 "SLUB: Use this_cpu operations in
slub"), but the percpu[8] tree removes the prefixing of percpu variables
(commit dd17c8f72993f9461e9c19250e3f155d6d99df22 "percpu: remove per_cpu__
prefix"), thus the fooling patch after mergeing these trees:

diff --git a/mm/slub.c b/mm/slub.c
index 6e34309..9e86e6b 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2071,7 +2071,7 @@ static inline int alloc_kmem_cache_cpus(struct kmem_cache *s, gfp_t flags)
 		 * Boot time creation of the kmalloc array. Use static per cpu data
 		 * since the per cpu allocator is not available yet.
 		 */
-		s->cpu_slab = per_cpu_var(kmalloc_percpu) + (s - kmalloc_caches);
+		s->cpu_slab = kmalloc_percpu + (s - kmalloc_caches);
 	else
 		s->cpu_slab =  alloc_percpu(struct kmem_cache_cpu);
 


5) The vfs[9] tree modifies the write_inode method API (commit
716c28c0bc8bcbdd26e819f38dfc8fdfaafc0289 "pass writeback_control to
->write_inode") and the logfs[10] tree adds a write_inode method (commit
5db53f3e80dee2d9dff5e534f9e9fe1db17c9936 "[LogFS] add new flash file
system"), so:

diff --git a/fs/logfs/inode.c b/fs/logfs/inode.c
index 6d08b37..36308af 100644
--- a/fs/logfs/inode.c
+++ b/fs/logfs/inode.c
@@ -8,6 +8,7 @@
 #include "logfs.h"
 #include <linux/writeback.h>
 #include <linux/backing-dev.h>
+#include <linux/writeback.h>
 
 /*
  * How soon to reuse old inode numbers?  LogFS doesn't store deleted inodes
@@ -282,7 +283,7 @@ struct inode *logfs_read_meta_inode(struct super_block *sb, u64 ino)
 	return inode;
 }
 
-static int logfs_write_inode(struct inode *inode, int do_sync)
+static int logfs_write_inode(struct inode *inode, struct writeback_control *wbc)
 {
 	int ret;
 	long flags = WF_LOCK;


6) The nfsd[11] tree comtains a change
(commit 978ebd97d1426d5708d3f353179ab81f191a7eeb
"xfs_export_operations.commit_metadata") that needs
the following patch due to a change in the xfs code (commit
a14a348bff2f99471a28e5928eb6801224c053d8 "xfs: cleanup up xfs_log_force
calling conventions") that has now been merged into your tree:

diff --git a/fs/xfs/linux-2.6/xfs_export.c b/fs/xfs/linux-2.6/xfs_export.c
index 8f4d707..846b75a 100644
--- a/fs/xfs/linux-2.6/xfs_export.c
+++ b/fs/xfs/linux-2.6/xfs_export.c
@@ -226,8 +226,8 @@ xfs_fs_nfs_commit_metadata(
 
 	xfs_ilock(ip, XFS_ILOCK_SHARED);
 	if (xfs_ipincount(ip)) {
-		error = _xfs_log_force(mp, ip->i_itemp->ili_last_lsn,
-				XFS_LOG_FORCE | XFS_LOG_SYNC, NULL);
+		error = _xfs_log_force_lsn(mp, ip->i_itemp->ili_last_lsn,
+				XFS_LOG_SYNC, NULL);
 	}
 	xfs_iunlock(ip, XFS_ILOCK_SHARED);
 

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

---------
[1] git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
	current head in linux-next: fb84181cc2863589ed06d48010fb4f6722105c7c
[2] git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq.git
	current head in linux-next: fb4635932a4e19c2f55383f968a0e9b64da37354
[3] http://kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/
	quilt series
	current head in linux-next: 07e9eb11f7b2e730b26c729ef77425b36721b389
[4] http://kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-driver-core/
	quilt series
	current head in linux-next: 26576add2492e80eb1a24f3e7e3ebc066627edec
[5] git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git
	current head in linux-next: 8e7544eef4f7007e4605aa9bff53dee6b610c164
[6] git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git
	current head in linux-next: aa262d2a6155b67eecf13e4964549d1465923a0f
[7] git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6.git
	current head in linux-next: ca69e392ebe662761f0356dd9de557ba20390dba
[8] git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu.git
	current head in linux-next: a29d8b8e2d811a24bbe49215a0f0c536b72ebc18
[9] git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git
	current head in linux-next: 9f009a78fb3b54976cfe8173d05ef483dbda4571
[10] git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs.git
	current head in linux-next: 5c564c2a04d4bb6ba79eeb83bd06de584479f362
[11] git://git.linux-nfs.org/~bfields/linux.git
	current head in linux-next: 7cf498470ae470ee55b3080692604e0dbf63312c

Re: linux-next: current pending merge fix patches

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> This could also be taken as a reminder to the respective maintiners that 
> they may want to do a merge of your tree before asking you to pull theirs.

I dont think that's generally correct for trivial conflicts: it's better if 
Linus does the merge of a tree that is based in some stable tree.

It causes slightly messier criss-cross history: there will be the back-merge 
commit plus the inevitable merge commit from Linus. It also makes bisection a 
bit messier:

For example when bisecting i generally consider the 'boundary' of where Linus 
pulls as a 'known point of stability': i.e. the 'subsystem side' is expected 
to be well-tested and if there's a problem on that side, it's that subsystem's 
domain.

"Linus's side", during the merge window, is a rolling tree of many freshly 
merged trees, which inevitably piles up a few problems.

So it's IMO somewhat better to keep that boundary and not push out Linus's 
side into subsystem trees: which then may merge a few new patches after having 
merged Linus's tree, intermixing it all into a non-bisectable combination.

Plus there's also an indirect effect: it keeps people from merging back 
Linus's tree all the time.

So i'd argue to not backmerge during the merge window (and i have stopped 
doing that myself a few cycles ago, and it clearly helped things) - but in any 
case it's certainly no big deal and up to Linus i guess.

	Ingo

Re: linux-next: current pending merge fix patches

[Stephen Rothwell]

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

Hi Ingo,

On Mon, 1 Mar 2010 09:10:21 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> > This could also be taken as a reminder to the respective maintiners that 
> > they may want to do a merge of your tree before asking you to pull theirs.
> 
> I dont think that's generally correct for trivial conflicts: it's better if 
> Linus does the merge of a tree that is based in some stable tree.

In general I agree.  I have singled out these conflict resolutions
because they involve either files not obvious from the conflicts (newly
introduced or chunks of code moved between files), or chunks of code that
are introduced in one tree but need to be modified after the otheris
merged.  So in that sense they are a heads up to Linus because they are
only found after you do the merge and then get a build failure (if you do
the right builds).

So they can be resolved by Linus after he merges the second tree or by
the original maintainer of one of the trees merging/cherrypicking (part
of) the other tree or waiting for Linus to merge the other tree and then
do a merge with Linus' tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: current pending merge fix patches

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Ingo,
> 
> On Mon, 1 Mar 2010 09:10:21 +0100 Ingo Molnar <mingo@elte.hu> wrote:
> >
> > > This could also be taken as a reminder to the respective maintiners that 
> > > they may want to do a merge of your tree before asking you to pull theirs.
> > 
> > I dont think that's generally correct for trivial conflicts: it's better if 
> > Linus does the merge of a tree that is based in some stable tree.
> 
> In general I agree.  I have singled out these conflict resolutions because 
> they involve either files not obvious from the conflicts (newly introduced 
> or chunks of code moved between files), or chunks of code that are 
> introduced in one tree but need to be modified after the otheris merged.  So 
> in that sense they are a heads up to Linus because they are only found after 
> you do the merge and then get a build failure (if you do the right builds).
> 
> So they can be resolved by Linus after he merges the second tree or by the 
> original maintainer of one of the trees merging/cherrypicking (part of) the 
> other tree or waiting for Linus to merge the other tree and then do a merge 
> with Linus' tree.

Conflict reminders are certainly useful - even for trivial commits.

My comments mostly related to the part of your suggestion that subsystem 
maintainers may merge in Linus's tree before they send their pull request to 
Linus - which i dont agree with in the general case, for the aforementioned 
reasons.

Thanks,

	Ingo

Re: linux-next: current pending merge fix patches

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> So i'd argue to not backmerge during the merge window (and i have stopped 
> doing that myself a few cycles ago, and it clearly helped things) - but in 
> any case it's certainly no big deal and up to Linus i guess.

What i do instead is that once Linus pulls from me i pull back immediately to 
test, and if it's fine i base further subsystem patches on that and test the 
heck out of the combination from that point on.

That's the collective 'point of no looking back' when subsystem people should 
jump in and help out testing the "final" combination.

But if a subsystem tree backmerges during the merge window any sooner 
(_before_ Linus pulls), it can cause criss-cross merges (as Linus may not pull 
or may pull later during which fixes arrive, etc.), creating a less readable 
history, etc. - which may make integration and problem isolation somewhat 
harder in the end.

( It's not a big deal in isolation and i dont think Linus actually rejects
  trees that do the occasional backmerge - but the combination of many small
  deals can have a bigger effect. )

There are exceptions, such as tricky conflicts that i know to be problematic - 
in that case i occasionally backmerge. But it's relatively rare - 90%+ of the 
conflicts are trivial and all-or-nothing affairs (i.e. if you mess it up the 
kernel wont work very well, so it's immediately noticeable).

Thanks,

	Ingo

Re: linux-next: current pending merge fix patches

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > So i'd argue to not backmerge during the merge window (and i have stopped 
> > doing that myself a few cycles ago, and it clearly helped things) - but in 
> > any case it's certainly no big deal and up to Linus i guess.
> 
> What i do instead is that once Linus pulls from me i pull back immediately 
> to test, and if it's fine i base further subsystem patches on that and test 
> the heck out of the combination from that point on.

A sidenote: this is only advisable if the testing in the subsystem tree is 
strong, if there were many changes with interactions and if Linus's tree is 
still in its stable phase (like now).

For slower-pace subsystems it's often good to be even more conservative with 
backmerges: to wait until -rc1 with any backmerges and to to generally not 
backmerge non-rc-release versions of Linus's tree.

That way the development commits and the followup fix commits stay in one 
linear branch of history, with no backmerge inbetween, easily bisectable and 
testable on a stable base all the way.

Thanks,

	Ingo

Re: linux-next: current pending merge fix patches

[Pekka Enberg]

Stephen Rothwell wrote:
> 4) The slab[7] tree adds a percpu variable usage case (commit
> 9dfc6e68bfe6ee452efb1a4e9ca26a9007f2b864 "SLUB: Use this_cpu operations in
> slub"), but the percpu[8] tree removes the prefixing of percpu variables
> (commit dd17c8f72993f9461e9c19250e3f155d6d99df22 "percpu: remove per_cpu__
> prefix"), thus the fooling patch after mergeing these trees:
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index 6e34309..9e86e6b 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -2071,7 +2071,7 @@ static inline int alloc_kmem_cache_cpus(struct kmem_cache *s, gfp_t flags)
>  		 * Boot time creation of the kmalloc array. Use static per cpu data
>  		 * since the per cpu allocator is not available yet.
>  		 */
> -		s->cpu_slab = per_cpu_var(kmalloc_percpu) + (s - kmalloc_caches);
> +		s->cpu_slab = kmalloc_percpu + (s - kmalloc_caches);
>  	else
>  		s->cpu_slab =  alloc_percpu(struct kmem_cache_cpu);

Thanks for the reminder Stephen! I'll add this to slab.git as soon as 
the per-cpu changes land into Linus' tree.

			Pekka