Prev: cfq-iosched: don't allow aliased requests to starve others
Next: linux-next: manual merge of the workqueues tree with the cifs tree
From: Stephen Rothwell on 23 Jul 2010 00:50 Hi Tejun, Today's linux-next merge of the workqueues tree got a conflict in fs/cifs/cifsfs.c between commit 4c0c03ca54f72fdd5912516ad0a23ec5cf01bda7 ("CIFS: Fix a malicious redirect problem in the DNS lookup code") from Linus' tree and commit 9b646972467fb5fdc677f9e4251875db20bdbb64 ("cifs: use workqueue instead of slow-work") from the workqueues tree. I fixed it up (I think - I removed the call to cifs_exit_dns_resolver() as there is no way to get to that code any more) and can carry the fix for a while. -- Cheers, Stephen Rothwell sfr(a)canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)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: Tejun Heo on 23 Jul 2010 07:30 Hello, Stephen. On 07/23/2010 06:46 AM, Stephen Rothwell wrote: > Hi Tejun, > > Today's linux-next merge of the workqueues tree got a conflict in > fs/cifs/cifsfs.c between commit 4c0c03ca54f72fdd5912516ad0a23ec5cf01bda7 > ("CIFS: Fix a malicious redirect problem in the DNS lookup code") from > Linus' tree and commit 9b646972467fb5fdc677f9e4251875db20bdbb64 ("cifs: > use workqueue instead of slow-work") from the workqueues tree. > > I fixed it up (I think - I removed the call to cifs_exit_dns_resolver() > as there is no way to get to that code any more) and can carry the fix > for a while. Yes, one failure case is removed, so that would be correct. Thank you very much for taking care of the conflict. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)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: Tejun Heo on 23 Jul 2010 07:40 Hello, On 07/23/2010 01:31 PM, Stephen Rothwell wrote: >> Yes, one failure case is removed, so that would be correct. > > Thanks for the confirmation. This should probably be fixed in the > workqueues tree before it is merged upstream. I was thinking about sending pull request w/ a note describing how to resolve the conflict. Would pulling in master before requesting pull be better? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)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: Stephen Rothwell on 23 Jul 2010 07:40 Hi Tejun, On Fri, 23 Jul 2010 13:28:21 +0200 Tejun Heo <tj(a)kernel.org> wrote: > > Yes, one failure case is removed, so that would be correct. Thanks for the confirmation. This should probably be fixed in the workqueues tree before it is merged upstream. -- Cheers, Stephen Rothwell sfr(a)canb.auug.org.au http://www.canb.auug.org.au/~sfr/
From: Tejun Heo on 23 Jul 2010 07:50
Hello, On 07/23/2010 01:42 PM, Stephen Rothwell wrote: > On Fri, 23 Jul 2010 13:34:55 +0200 Tejun Heo <tj(a)kernel.org> wrote: >> >> I was thinking about sending pull request w/ a note describing how to >> resolve the conflict. Would pulling in master before requesting pull >> be better? > > Either would work. Linus is fine with doing merge fixups and, after all, > I figured it out. :-) > > A description always helps, of course. Yeah, sorry about causng headaches in linux-next. I'll test merge w/ mainline and let you know non-trivial conflicts for future commits. Thank you. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |