On Tue, Feb 05, 2008 at 02:19:32PM -0800, Greg KH wrote:

On Tue, Feb 05, 2008 at 11:19:19PM +0100, Jiri Kosina wrote:

...

On Tue, 5 Feb 2008, Greg KH wrote:

...

Jiri Kosina: Why are these patches not upstream: patches.suse/aslr-i386-and-x86_64-randomize-brk.patch patches.suse/aslr-pie-executable-randomization.patch

Hi Greg,

these two are in Linus' tree (and randomize-brk is currently being heavily discussed :) ) already.

Thanks for letting me know. Good luck with the discussions :)

Someone please just reinstall Pavels machine. ;) Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg KH wrote:

On Tue, Feb 05, 2008 at 05:26:03PM -0500, Jeff Mahoney wrote:

...

Greg KH wrote:

...

Hi all,

As I'm going to be the one trying to manage the 11.0 kernel release, I figured it was time to take a look at all of the patches we have in our tree, and see why they are not upstream already.

So, here's a breakdown of all 228 patches in our "normal" kernel tree (I'm ignoring the -rt tree right now, that's just crazy at the moment...)

I'd like all of the developers here to at least respond with a reason why their patches are in the tree and not in mainline already. If they patch will show up in 2.6.25, let us know, and we can properly mark it as such. If it's a feature that isn't upstream, and it isn't obvious why, please let us know. reiserfs patches: patches.suse/reiserfs-add-per-file-data-ordered-mode.diff patches.suse/reiserfs-add-reiserfs_error.diff patches.suse/reiserfs-buffer-info-for-balance.diff patches.suse/reiserfs-cleanup-path-funcs.diff patches.suse/reiserfs-consistent-messages.diff patches.suse/reiserfs-eliminate-per-super-xattr-lock.diff patches.suse/reiserfs-journaled-xattrs.diff patches.suse/reiserfs-kill-xattr-readdir.diff patches.suse/reiserfs-make-per-inode-xattr-locking-more-fine-grained.diff patches.suse/reiserfs-mount-count patches.suse/reiserfs-rearrange-journal-abort.diff patches.suse/reiserfs-reiserfs-warning.diff patches.suse/reiserfs-reiserfs_info.diff patches.suse/reiserfs-reiserfs_panic.diff patches.suse/reiserfs-remove-i_has_xattr_dir.diff patches.suse/reiserfs-remove-link-detection.diff patches.suse/reiserfs-rename-._.diff patches.suse/reiserfs-rename-p_._.diff patches.suse/reiserfs-rename-p_s_bh.diff patches.suse/reiserfs-rename-p_s_inode.diff patches.suse/reiserfs-rename-p_s_sb.diff patches.suse/reiserfs-rename-p_s_tb.diff patches.suse/reiserfs-selinux.diff patches.suse/reiserfs-simplify-xattr-internal-file-lookups-opens.diff patches.suse/reiserfs-strip-whitespace.diff patches.suse/reiserfs-use-generic-xattr-handlers.diff patches.suse/reiserfs-use-reiserfs_error.diff patches.suse/reiserfs-xattrs-noatime.diff are these going to show up in 2.6.25? I doubt it. Probably 2.6.26 if I can get akpm to accept them into -mm for some testing. I've sent them to the reiserfs list several times with very little feedback. There's not a whole lot of interest in maintaining reiser3.

Just push them to him, if they are real bugfixes, they should go in.

None of them are bug fixes. They're all enhancements to either behavior or code readability.

...

I also imagine that bringing up the reiser3 xattr code will be like a third rail, but it is what it is.

Do we have people that rely on it in our kernels? Do we want to drag it along for 7 more years? :)

Yeah, actually. Anyone with reiserfs setup by YaST who hasn't disabled it is using it. The code works. That's not the problem. The problem is that it's the file i/o in kernel space blight that everyone rants about when they see it. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHqOS3LPWxlyuTD7IRAje6AJ0SF074gTXJXvwYySWjotO7C9zP1wCgppMl DaE0gica0HzZJTub0O4JqLc= =o/sC -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

Hi, On Tue, 5 Feb 2008, Greg KH wrote:

...

I also imagine that bringing up the reiser3 xattr code will be like a third rail, but it is what it is.

Do we have people that rely on it in our kernels? Do we want to drag it along for 7 more years? :)

I don't see us deprecating reiser3. I don't know if the xattr patches are necessary for xattrs to work on reiser at all, but I do know that we use xattrs, so that too needs to continue to work. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

Hi, On Tue, 5 Feb 2008, Jeff Mahoney wrote:

...

...

...

I also imagine that bringing up the reiser3 xattr code will be like a third rail, but it is what it is. Do we have people that rely on it in our kernels? Do we want to drag it along for 7 more years? :)

I don't see us deprecating reiser3. I don't know if the xattr patches are necessary for xattrs to work on reiser at all, but I do know that we use xattrs, so that too needs to continue to work.

I think I misunderstood Greg's question here.

ReiserFS extended attributes have been in mainline since, oh, 2.6.14 or something. They're a fact. The patches are there to make the code not suck so much.

I see. Well, as Greg has a point about the 7 years it probably makes sense to make the code suck as little as possible. I don't know upstreams "community" of reiser3, but perhaps they also would appreciate a little nicer code :-) Ciao, Michael. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Tue 2008-02-05 17:48:24, Jeff Mahoney wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Michael Matz wrote:

...

Hi,

On Tue, 5 Feb 2008, Jeff Mahoney wrote:

...

...

...

...

I also imagine that bringing up the reiser3 xattr code will be like a third rail, but it is what it is. Do we have people that rely on it in our kernels? Do we want to drag it along for 7 more years? :) I don't see us deprecating reiser3. I don't know if the xattr patches are necessary for xattrs to work on reiser at all, but I do know that we use xattrs, so that too needs to continue to work. I think I misunderstood Greg's question here.

ReiserFS extended attributes have been in mainline since, oh, 2.6.14 or something. They're a fact. The patches are there to make the code not suck so much.

I see. Well, as Greg has a point about the 7 years it probably makes sense to make the code suck as little as possible. I don't know upstreams "community" of reiser3, but perhaps they also would appreciate a little nicer code :-)

It works out that "Upstream" is still the old Namesys guys, but I end up doing most of the work. When I do come up with something, they don't really comment on it. I might as well just merge these against -mm and let them stew for a revision before pushing them out to mainline. I'm

That sounds like a way to go. You can also make yourself maintainer of reiser... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Tue, Feb 05, 2008 at 11:37:43PM +0100, Michael Matz wrote:

Hi,

On Tue, 5 Feb 2008, Greg KH wrote:

...

...

I also imagine that bringing up the reiser3 xattr code will be like a third rail, but it is what it is.

Do we have people that rely on it in our kernels? Do we want to drag it along for 7 more years? :)

I don't see us deprecating reiser3.

I don't want to do that, just curious as to if we are having people rely on the xattrs stuff. Jeff says that we are, so that's good enough for me :) thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Tue, Feb 05, 2008 at 11:31:31PM +0100, Jiri Benc wrote:

On Tue, 5 Feb 2008 14:10:07 -0800, Greg KH wrote:

...

Jiri Benc: Aren't these in 2.6.25? patches.fixes/mac80211-fix-hw-scan1.patch patches.fixes/mac80211-fix-hw-scan2.patch

They are.

Nice, thanks for letting me know. greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

* Greg KH [2008-02-08 05:22]:

On Wed, Feb 06, 2008 at 08:05:52AM +0100, Bernhard Walle wrote:

...

* Greg KH [2008-02-05 23:10]:

...

Bernhard Walle Why aren't these upstream: patches.arch/ppc-fix-prpmc2800

It was a temporary binutils workaround, it was from a mailing list posting. So it didn't make sense to submit upstream because if it would, the Author had done already. I'll test if the patch is needed at all ...

Thanks, feel free to drop it if it's not needed :)

Ok, build is running.

Ugh, that driver, I forgot about that. Fine, no objection from me to keeping it there, as long as we update it. There should be a new version out soon, right?

Yes, I'll update to the latest version from e1000.sf.net. I also recognised that it's mainline now since 2 weeks: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=... Bernhard -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Wed, Feb 06, 2008 at 08:13:34AM +0100, Takashi Iwai wrote:

At Tue, 5 Feb 2008 14:10:07 -0800, Greg KH wrote:

...

Takashi Iwai: Are these going to be in 2.6.25?: patches.drivers/alsa-usb-exclude-1st-slot

This isn't needed for 2.6.25 because a newer (better) way of device assignment was introduced. So, it can be removed when we upgrade to 2.6.25. It's harmless to keep this, though.

Ok, we'll probably move to 2.6.25-rc1 to start on the testing cycle when it comes out, so I'll try to remember to remove this then. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Wed, Feb 06, 2008 at 08:14:33AM +0100, Bernhard Walle wrote:

* Greg KH [2008-02-05 23:10]:

...

patches.suse/crasher-26.diff

Please not, I use that sometimes for testing kdump. :) I can offer to "maintain" that module (I doubt we get L3 bugs about this :-)), and maybe also try to submit upstream if they like such code.

Yes, I think this should go upstream, I'll work on that. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Wed, Feb 06, 2008 at 08:38:18AM +0100, Hannes Reinecke wrote:

Greg KH wrote:

...

Hi all,

[ .. ]

...

patches.fixes/libiscsi-missing-semicolon.diff Should be fixed upstream by now.

ok.

...

patches.fixes/loop-barriers patches.fixes/loop-barriers2 patches.fixes/proc-scsi-scsi-fix.diff

This is a fix for /proc/scsi/scsi for large number of devices. hch didn't accept this a it fixes an obsolete interface.

Yeah, I remember that. What about the loop patches?

...

Hannes Reinecke Why aren't these upstream: patches.arch/s390-ccwgroup-attribute-ignore-newline They promised me it would; I'll have to resend it.

Please do.

...

patches.fixes/dm-mpath-hp-sw.patch

Already is.

...

patches.fixes/megaraid_mbox-dell-cerc-support

It's Megaraid. 'They will look into it'.

Yeah right :)

...

patches.fixes/mptbase-vmware-fix

Workaround for broken VMWare emulation. Vetoed upstream as VMWare should fix their emulation. Which they did in later versions. However, older VMWare installation still require it.

Do we still support older vmware installs? I didn't think we did, especially as they need to upgrade their kernel modules with our kernel releases. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Fri, Feb 08, 2008 at 08:10:39AM +0100, Hannes Reinecke wrote:

Greg KH wrote:

...

On Wed, Feb 06, 2008 at 08:38:18AM +0100, Hannes Reinecke wrote: [ .. ]

...

...

patches.fixes/mptbase-vmware-fix

Workaround for broken VMWare emulation. Vetoed upstream as VMWare should fix their emulation. Which they did in later versions. However, older VMWare installation still require it.

Do we still support older vmware installs? I didn't think we did, especially as they need to upgrade their kernel modules with our kernel releases.

This is nothing to do with the kernel modules, this is the VMWare emulation layer. So they will have to update their VMWare installation itself if we drop this fix.

Hmm. We should verify that it is indeed fixed by later versions. And which version that is, so that we can point to the correct version.

Ok, I'm going to drop this as no other distro has this patch and vmware seems to work well with them :) thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Wednesday 06 February 2008 08:46:14 Jan Beulich wrote:

...

Jan Beulich: Why isn't this upstream?: patches.suse/stack-unwind

The code was in mainline for a couple of releases and the kicked out again for philosophical (I would call it) reasons. Andi and I are in agreement that it should be re-submitted to mainline at some point, but we clearly need to make sure the time (and the code) is right for a second try.

Yes, the idea was to get it even more testing and then eventually resubmit. Also it's a very valuable feature that is definitely worth carrying even out of tree -- reliable backtraces make it much easier to look at oopses. -Andi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Friday 08 February 2008 05:31:48 Greg KH wrote:

On Wed, Feb 06, 2008 at 09:42:22AM +0100, Andi Kleen wrote:

...

On Tuesday 05 February 2008 23:10:07 Greg KH wrote:

...

If these defaults are too small, why haven't we got upstream to take the change?: patches.suse/shmall-bigger

There is a change being worked on upstream (or rather mm) to do this more generically.

Ok, will we know when those changes get merged so we no longer have to take this patch?

Either .25 (I think it was already in -mm so it might be a late merge) or .26 I guess.

...

...

patches.fixes/tiocgdev

This is needed for init. There is unfortunately some philosophical disagreement on that one for mainline (I tried to submit it a long time ago). Maintainer is Werner Fink.

Probably would make sense to resubmit it -- i'm a little tired of always seeing the "kernel does not support TIOCGDEV" messages when I boot a mainline kernel.

I'll try to push it.

The problem was iirc Al Viro not happy about a dev_t being passed around. But we can probably argue it is a legacy interface by now (it has been in SUSE kernels for many many years)

...

...

patches.suse/crasher-26.diff

This one is a valuable debugging tool and should be probably submitted.

...

patches.suse/twofish-2.6 (We gotta be able to drop this one now, right? If not, why isn't it upstream?)

No we can't because that would break updates with encrypted file systems.

But there already is a twofish crypto module in the upstream kernel. Why are we adding another one?

They are not compatible on disk.

Shouldn't we use the one already there? If there are problems with the upstream one, we should fix it, not just drag in another new implementation.

The two modules just adapt cryptoloop to twofish, but do it in different ways. I'm not sure it would make that much sense to merge them. I guess it would make sense to submit this one upstream though. -Andi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Wed, Feb 06, 2008 at 10:50:02AM +0100, Thomas Renninger wrote:

On Tue, 2008-02-05 at 14:10 -0800, Greg KH wrote:

...

Hi all,

...

Thomas Renninger: How come these aren't upstream: patches.arch/acpi_autoload_bay.patch patches.arch/export-acpi_check_resource_conflict.patch patches.arch/small-acpica-extension-to-be-able-to-store-the-name-of.patch patches.fixes/acpi_autoload_baydock.patch patches.fixes/acpi_force-fan-active.patch patches.suse/acpi_dsdt_ssdt_initrd_initramfs.patch

Everything should be mainline (or soon, in 2.6.25-rcX, even the dsdt override patch...) except this one: patches.fixes/acpi_force-fan-active.patch

I will have a look at this one.

Thanks. And congrats on the dsdt patch :)

This one slipped on my list, but it's Hannes patch:

...

patches.suse/dm-emulate-blkrrpart-ioctl

Hannes, any thoughts? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

patches.fixes/bridge-module-get-put.patch

I just realized this one's mine, too (it does say so in the header) - it was NAKed upstream as the bridge maintainer thinks that (explicit) unloading the bridge module should have the effect of bringing down all bridges. It was agreed upon, though, that implicit unloading of the bridge module should be prevented by some (supposedly being thought of but not yet implemented mechanism). Since we have no better way to fix the underlying bug, I'd suggest keeping the patch. Jan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Wed, Feb 06, 2008 at 03:24:26PM +0100, Jiri Bohac wrote:

...

patches.fixes/ipv6-no-autoconf

This is a workaround for a XEN problem (same MAC address assigned to multiple bridged virtual interfaces). It had been discussed on netdev and rejected: http://www.mail-archive.com/netdev@vger.kernel.org/msg20888.html

There is a bug in the XEN bugzilla about this issue ( http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=339 ), which does not solve the problem either.

I think this patch should just be considered part of the XEN mess ;-)

Ok, I'll move it there. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Wed, Feb 06, 2008 at 05:38:33PM +0100, Jean Delvare wrote:

Le mardi 05 f?vrier 2008, Greg KH a ?crit?:

...

Thomas Renninger: How come these aren't upstream: (...) patches.arch/export-acpi_check_resource_conflict.patch patches.arch/small-acpica-extension-to-be-able-to-store-the-name-of.patch (...)

Jean Delavare: Are these going to be in 2.6.25: patches.arch/check-for-acpi-resource-conflicts-in-hwmon-drivers.patch patches.arch/check-for-acpi-resource-conflicts-in-i2c-bus-drivers.patch

These two depend on Thomas' ACPI patches above. I'll look into pushing them upstream once the ACPI patches in question are there.

It sounds like they are there, so can you try to get them in before the merge window closes?

...

patches.fixes/pci-quirk-enable-smbus-on-hp-xw4100.patch

Already upstream: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=...

Great, thanks for the link. greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Thu, 2008-02-21 at 16:12 +0100, Jean Delvare wrote:

Le vendredi 08 février 2008, Greg KH a écrit :

...

On Wed, Feb 06, 2008 at 05:38:33PM +0100, Jean Delvare wrote:

...

Le mardi 05 f?vrier 2008, Greg KH a ?crit?:

...

Thomas Renninger: How come these aren't upstream: (...) patches.arch/export-acpi_check_resource_conflict.patch patches.arch/small-acpica-extension-to-be-able-to-store-the-name-of.patch (...)

Jean Delavare: Are these going to be in 2.6.25: patches.arch/check-for-acpi-resource-conflicts-in-hwmon-drivers.patch patches.arch/check-for-acpi-resource-conflicts-in-i2c-bus-drivers.patch

These two depend on Thomas' ACPI patches above. I'll look into pushing them upstream once the ACPI patches in question are there.

It sounds like they are there, so can you try to get them in before the merge window closes?

Linus didn't like them, so they are unlikely to make it into 2.6.25. Discussions are going on with regards to how this feature should be implemented.

I'd vote to keep them for a while and remove them at late Beta 11.0 stage or simply disable the messages by setting default param to be quiet (->might help to solve an ugly bug later by enabling and report possible interference via boot param in a related bug report). Hopefully we get some reports via bugzilla.novell.com and can report them and discuss it upstream then. Like that we might get a clearer picture about possible interference on specific BIOSes without polluting the mainline kernel with a temporary debug patch. What do you think? Thomas -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org