[opensuse-kernel] openSUSE Kernel: Push Patches Upstream
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys - We've been carrying the following patches in the openSUSE kernel for some time and there's no need for them to be openSUSE-specific. Can you review the patches below and either remove them, submit them upstream, or at least at a signed-off-by if there isn't one already so I can do so? Even though there are patches that only affect architectures which we don't support on openSUSE and can be dropped as far as openSUSE is concerned, the Factory kernel will eventually be branched for the SLE12 kernel. Getting rid of them now only makes things easier later. Alexander Graf: - - patches.arch/kvm-split-paravirt-ops-by-functionality - - patches.arch/kvm-only-export-selected-pv-ops-feature-structs - - patches.arch/kvm-split-the-KVM-pv-ops-support-by-feature - - patches.arch/kvm-replace-kvm-io-delay-pv-ops-with-linux-magic [these 4 have been disabled since 2.6.38-rc1] - - patches.fixes/kvm-ioapic.patch - - patches.fixes/kvm-macos.patch Brandon Philips: - - patches.drivers/bnx2-entropy-source.patch - - patches.drivers/e1000-entropy-source.patch - - patches.drivers/e1000e-entropy-source.patch - - patches.drivers/igb-entropy-source.patch - - patches.drivers/ixgbe-entropy-source.patch - - patches.drivers/tg3-entropy-source.patch - - patches.drivers/tg3-5785-and-57780-asic-revs-not-working.patch - - patches.suse/uvcvideo-ignore-hue-control-for-5986-0241.patch Greg Haskins: - - patches.fixes/ia64-configure-HAVE_UNSTABLE_SCHED_CLOCK-for-SGI_SN.patch Greg KH: - - patches.suse/linux-2.6.29-dont-wait-for-mouse.patch - - patches.suse/linux-2.6.29-even-faster-kms.patch - - patches.suse/linux-2.6.29-kms-after-sata.patch - - patches.suse/linux-2.6.29-jbd-longer-commit-interval.patch - - patches.suse/linux-2.6.29-touchkit.patch Hannes Reinecke: (or James Bottomley) - - patches.suse/kbd-ignore-gfx.patch - - patches.fixes/scsi-inquiry-too-short-ratelimit - - patches.suse/scsi-netlink-ml - - patches.fixes/scsi-dh-queuedata-accessors - - patches.fixes/scsi-dh-alua-retry-UA - - patches.fixes/scsi-add-tgps-setting [disabled since 2.6.39] - - patches.fixes/scsi-dh-alua-send-stpg - - patches.fixes/scsi-dh-rdac-add-stk - - patches.fixes/scsi-retry-alua-transition-in-progress - - patches.fixes/scsi-check-host-lookup-failure - - patches.drivers/megaraid-mbox-fix-SG_IO - - patches.suse/scsi-error-test-unit-ready-timeout [Kurt] - - patches.fixes/scsi-scan-blist-update - - patches.suse/no-partition-scan [Is this even necessary since we boot with 'quiet' as default now?] - - patches.suse/dm-emulate-blkrrpart-ioctl - - patches.fixes/dm-mpath-reattach-dh - - patches.suse/dm-mpath-leastpending-path-update [Has this been replaced by dm-queue-length upstream?] - - patches.suse/dm-mpath-accept-failed-paths [disabled since 2.6.38] - - patches.suse/dm-mpath-detach-existing-hardware-handler [disabled since 2.6.38] - - patches.fixes/dm-table-switch-to-readonly - - patches.suse/dm-mpath-evaluate-request-result-and-sense [disabled since 2.6.39] - - patches.fixes/dm-release-map_lock-before-set_disk_ro [added by Nikanth] - - patches.suse/dm-mpath-no-activate-for-offlined-paths [and patches.suse/mpath-fix] - - patches.suse/dm-mpath-no-partitions-feature - - Jan Beulich: - - patches.fixes/bridge-module-get-put.patch Jan Kara: - - patches.suse/readahead-request-tunables.patch - - patches.suse/raw_device_max_minors_param.diff Jeff Mahoney: [deleted a bunch] - - patches.fixes/netfilter-implement-rfc-1123-for-ftp-conntrack - - patches.fixes/proc-scsi-scsi-fix.diff - - patches.fixes/flexcop-fix-registering-braindead-stupid-names - - patches.fixes/misdn-add-support-for-group-membership-check - - patches.suse/dm-raid45-26-Nov-2009.patch [Unsure what's happening here. It hasn't been updated in ages.] Jiri Benc: - - patches.suse/panic-on-io-nmi-SLE11-user-space-api.patch [disabled since 2.6.33] [does anyone even use the binary sysctl interface for this?] Jiri Bohac: - - patches.arch/x86_64-hpet-64bit-timer.patch [disabled since 2.6.33] - - patches.suse/netfilter-ip_conntrack_slp.patch Jiri Kosina: - - patches.drivers/elousb.patch - - patches.fixes/input-add-acer-aspire-5710-to-nomux.patch - - patches.fixes/hid-add-noget-quirk-for-symboltec.patch Jiri Slaby: - - patches.suse/wireless-no-aes-select - - patches.fixes/iwlwifi-fix-tx-power-configuration-on-3945-and-4965-devices Mel Gorman / Michal Hocko: - - patches.fixes/grab-swap-token-oops - - patches.suse/files-slab-rcu.patch - - patches.suse/mm-devzero-optimisation.patch [against SLES10, issue may not exist anymore] - - patches.suse/mm-devzero-optimisation.patch - - patches.fixes/aggressive-zone-reclaim.patch [disabled since 2.6.36] Neil Brown: - - patches.fixes/nfs-slot-table-alloc - - patches.fixes/nfsd-06-sunrpc-cache-retry-cache-lookups-that-return-ETIMEDO.patch [disabled since 2.6.37] Olaf Hering: - - patches.suse/led_classdev.sysfs-name.patch [ppc] - - patches.suse/radeon-monitor-jsxx-quirk.patch [ppc] - - patches.suse/8250-sysrq-ctrl_o.patch [ppc] - - patches.suse/led_classdev.sysfs-name.patch [ppc] - - patches.arch/ppc-pegasos-console-autodetection.patch [ppc] - - patches.suse/ppc-powerbook-usb-fn-key-default.patch [ppc] - - patches.drivers/ppc64-adb [ppc] - - patches.suse/suse-ppc64-branding [ppc] - - patches.arch/ppc64-xmon-dmesg-printing.patch [ppc] - - patches.arch/ppc-prom-nodisplay.patch [ppc] - - patches.fixes/ptrace-getsiginfo [technically schwab] [ppc] - - patches.fixes/scsi-ibmvscsi-show-config.patch - - patches.fixes/scsi-ibmvscsi-module_alias.patch - - patches.drivers/ehea-modinfo.patch Olaf Kirch: - - patches.fixes/remount-no-shrink-dcache - - patches.fixes/tulip-quad-NIC-ifdown - - patches.fixes/parport-mutex [This doesn't seem like the right fix - the driver looks like it needs help.] Oliver Neukum: - - patches.fixes/sd_liberal_28_sense_invalid.diff Rafael Wysocki: - - patches.arch/x86-mcp51-no-dac [rejected by Alan Cox, Mar 2009] - - patches.fixes/tg3-fix-default-wol.patch Suresh Jayaraman: - - patches.suse/sched-revert-latency-defaults [disabled since 2.6.33, after SLE11SP1] - - patches.suse/mm-tune-dirty-limits.patch [we may want to revisit per-flavor sysctl files] Takashi Iwai: - - patches.arch/ppc-ipic-suspend-without-83xx-fix [ppc] - - patches.arch/x86-hpet-pre-read [disabled since 2.6.37] - - patches.drivers/input-Add-LED-support-to-Synaptics-device - - patches.drivers/alsa-hda-0019-Increase-default-buffer-size Thomas Renninger: - - patches.arch/x86-apic-force-bigsmp-apic-on-IBM-EXA3-4.patch - - patches.arch/acpi_thinkpad_introduce_acpi_root_table_boot_param.patch - - patches.arch/acpi_thermal_passive_blacklist.patch - - patches.arch/acpi_fix_fadt_32_bit_zero_length.patch - - patches.arch/acpi_ec_provide_non_interrupt_mode_boot_param.patch [disabled since 2.6.32] - - patches.arch/acpi_srat-pxm-rev-store.patch - - patches.arch/acpi_srat-pxm-rev-ia64.patch - - patches.arch/acpi_srat-pxm-rev-x86-64.patch - - patches.fixes/acpi_ec_sys_access_user_space_with_get_user.patch - - patches.fixes/cpufreq_ondemand_performance_optimise_default_settings.patch - - patches.arch/perf_timechart_fix_zero_timestamps.patch - - patches.fixes/intel_idle_lapic_param.patch [less than two weeks old] - - patches.fixes/intel_idle_add_flush_tlb_param.patch [less than two weeks old] Tony Jones: - - patches.suse/kdump-dump_after_notifier.patch - - patches.fixes/oprofile_bios_ctr.patch [ Up for discussion ] - - patches.suse/file-capabilities-disable-by-default.diff [never submitted] - - patches.suse/connector-read-mostly - - patches.suse/ext3-barrier-default - - patches.suse/reiserfs-barrier-default - - patches.suse/SUSE-bootsplash Thanks. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk25pVEACgkQLPWxlyuTD7JC5gCdGl2k8d2PeHQVaF5WO5Yv25V+ PE8An07vC7R5YH5iJWHhKZUJDIzuVUHG =W1WH -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thu, Apr 28, 2011 at 01:35:13PM -0400, Jeff Mahoney wrote:
Greg KH: - patches.suse/linux-2.6.29-dont-wait-for-mouse.patch - patches.suse/linux-2.6.29-even-faster-kms.patch - patches.suse/linux-2.6.29-kms-after-sata.patch - patches.suse/linux-2.6.29-jbd-longer-commit-interval.patch - patches.suse/linux-2.6.29-touchkit.patch
Crap, I forgot all about these, I'll go drop them. As Intel never pushed them upstream, they must not care about them so we shouldn't either. Thanks for going through the list of patches, I know it's no fun, but is really needed and appreciated. greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thu, Apr 28, 2011 at 11:16:16AM -0700, Greg KH wrote:
On Thu, Apr 28, 2011 at 01:35:13PM -0400, Jeff Mahoney wrote:
Greg KH: - patches.suse/linux-2.6.29-dont-wait-for-mouse.patch - patches.suse/linux-2.6.29-even-faster-kms.patch - patches.suse/linux-2.6.29-kms-after-sata.patch - patches.suse/linux-2.6.29-jbd-longer-commit-interval.patch - patches.suse/linux-2.6.29-touchkit.patch
Crap, I forgot all about these, I'll go drop them. As Intel never pushed them upstream, they must not care about them so we shouldn't either.
Now gone. thanks, greg k-h -- 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 On 04/28/2011 06:36 PM, Greg KH wrote:
On Thu, Apr 28, 2011 at 11:16:16AM -0700, Greg KH wrote:
On Thu, Apr 28, 2011 at 01:35:13PM -0400, Jeff Mahoney wrote:
Greg KH: - patches.suse/linux-2.6.29-dont-wait-for-mouse.patch - patches.suse/linux-2.6.29-even-faster-kms.patch - patches.suse/linux-2.6.29-kms-after-sata.patch - patches.suse/linux-2.6.29-jbd-longer-commit-interval.patch - patches.suse/linux-2.6.29-touchkit.patch
Crap, I forgot all about these, I'll go drop them. As Intel never pushed them upstream, they must not care about them so we shouldn't either.
Now gone.
Great, thanks. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk25+pUACgkQLPWxlyuTD7JxXgCdF3ANIGqzEbsXR28AeuONftBS x9EAn3W37iLXnLmEyCU97e43PHrTbX0o =7T1L -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On 13:35 Thu 28 Apr 2011, Jeff Mahoney wrote:
Brandon Philips: - - patches.drivers/bnx2-entropy-source.patch - - patches.drivers/e1000-entropy-source.patch - - patches.drivers/e1000e-entropy-source.patch - - patches.drivers/igb-entropy-source.patch - - patches.drivers/ixgbe-entropy-source.patch - - patches.drivers/tg3-entropy-source.patch
Eventually we should provide an entropy gathering daemon as an install option for servers in the installer. Some daemons have been packaged already: #306591: entropy daemons in 11.2
- - patches.drivers/tg3-5785-and-57780-asic-revs-not-working.patch
[fixed via 8626d3b4328061f5b82b11ae1d6918a0c3602f42]
- - patches.suse/uvcvideo-ignore-hue-control-for-5986-0241.patch
Deleted fixed in a better way upstream. Thanks for doing this Jeff. Cheers, Brandon -- 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 On 04/28/2011 02:43 PM, Brandon Philips wrote:
On 13:35 Thu 28 Apr 2011, Jeff Mahoney wrote:
Brandon Philips: - - patches.drivers/bnx2-entropy-source.patch - - patches.drivers/e1000-entropy-source.patch - - patches.drivers/e1000e-entropy-source.patch - - patches.drivers/igb-entropy-source.patch - - patches.drivers/ixgbe-entropy-source.patch - - patches.drivers/tg3-entropy-source.patch
Eventually we should provide an entropy gathering daemon as an install option for servers in the installer. Some daemons have been packaged already: #306591: entropy daemons in 11.2
- - patches.drivers/tg3-5785-and-57780-asic-revs-not-working.patch
[fixed via 8626d3b4328061f5b82b11ae1d6918a0c3602f42]
Great.
- - patches.suse/uvcvideo-ignore-hue-control-for-5986-0241.patch
Deleted fixed in a better way upstream.
Perfect. Thanks. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk25+qQACgkQLPWxlyuTD7JyyACglwJWpRnjDK3RexqB0i5bkDli 8zwAoJ4PZIytsShks5i6PrCa3zQqyoSQ =P+vk -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On 13:35 Thu 28 Apr 2011, Jeff Mahoney wrote:
- - patches.suse/file-capabilities-disable-by-default.diff [never submitted]
We should drop it. Upstream has had file caps by default since Nov 2009. Upstream commits: b3a222e52e4d4be77cc4520a57af1a4a0d8222d1 1f29fae29709b4668979e244c09b2fa78ff1ad59 Cheers, Brandon -- 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 On 04/28/2011 02:50 PM, Brandon Philips wrote:
On 13:35 Thu 28 Apr 2011, Jeff Mahoney wrote:
- - patches.suse/file-capabilities-disable-by-default.diff [never submitted]
We should drop it. Upstream has had file caps by default since Nov 2009.
Upstream commits: b3a222e52e4d4be77cc4520a57af1a4a0d8222d1 1f29fae29709b4668979e244c09b2fa78ff1ad59
In doing a zypper dup today, I saw that something is looking at /proc/cmdline for "file_caps" as part of SuSEconfig running. We should probably figure out what that is. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk25+tgACgkQLPWxlyuTD7Ii9wCePZmujabrfjTcNzsZkv+S3Yu/ M/wAnRrMnJvlaXzaQtfCJGItRHxVYFbC =9Fv4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thu, Apr 28, 2011 at 07:40:08PM -0400, Jeff Mahoney wrote:
On 04/28/2011 02:50 PM, Brandon Philips wrote:
On 13:35 Thu 28 Apr 2011, Jeff Mahoney wrote:
- - patches.suse/file-capabilities-disable-by-default.diff [never submitted]
We should drop it. Upstream has had file caps by default since Nov 2009.
Upstream commits: b3a222e52e4d4be77cc4520a57af1a4a0d8222d1 1f29fae29709b4668979e244c09b2fa78ff1ad59
In doing a zypper dup today, I saw that something is looking at /proc/cmdline for "file_caps" as part of SuSEconfig running. We should probably figure out what that is.
The SuSEconfig permissions module, it decides on whether to handle file caps setting or not depending on the kernel. Ludwig wants a patch to detect this for years in the mainline kernel, but it is not there yet. Can you please take care that such a method is exposed by mainline? (file_caps might be disabled or enabled, we should handle both cases and detect it from the kernel.) Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Fri, Apr 29, 2011 at 08:38:44AM +0200, Marcus Meissner wrote:
On Thu, Apr 28, 2011 at 07:40:08PM -0400, Jeff Mahoney wrote:
On 04/28/2011 02:50 PM, Brandon Philips wrote:
On 13:35 Thu 28 Apr 2011, Jeff Mahoney wrote:
- - patches.suse/file-capabilities-disable-by-default.diff [never submitted]
We should drop it. Upstream has had file caps by default since Nov 2009.
Upstream commits: b3a222e52e4d4be77cc4520a57af1a4a0d8222d1 1f29fae29709b4668979e244c09b2fa78ff1ad59
In doing a zypper dup today, I saw that something is looking at /proc/cmdline for "file_caps" as part of SuSEconfig running. We should probably figure out what that is.
The SuSEconfig permissions module, it decides on whether to handle file caps setting or not depending on the kernel.
Ludwig wants a patch to detect this for years in the mainline kernel, but it is not there yet.
Can you please take care that such a method is exposed by mainline? (file_caps might be disabled or enabled, we should handle both cases and detect it from the kernel.)
The patch doing this in the kernel is queued up to be accepted for the .40 kernel release, so perhaps I should also add it to our tree now so that FACTORY can be converted over to using it and this can be dropped? If so, just let me know and I will go add it as it is in my upstream kernel tree already. And it was my fault that it took so long to get accepted for the past 6+ months, sorry, it got lost in my patch queue :( thanks, greg k-h -- 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 On 04/29/2011 11:36 AM, Greg KH wrote:
On Fri, Apr 29, 2011 at 08:38:44AM +0200, Marcus Meissner wrote:
On Thu, Apr 28, 2011 at 07:40:08PM -0400, Jeff Mahoney wrote:
On 04/28/2011 02:50 PM, Brandon Philips wrote:
On 13:35 Thu 28 Apr 2011, Jeff Mahoney wrote:
- - patches.suse/file-capabilities-disable-by-default.diff [never submitted]
We should drop it. Upstream has had file caps by default since Nov 2009.
Upstream commits: b3a222e52e4d4be77cc4520a57af1a4a0d8222d1 1f29fae29709b4668979e244c09b2fa78ff1ad59
In doing a zypper dup today, I saw that something is looking at /proc/cmdline for "file_caps" as part of SuSEconfig running. We should probably figure out what that is.
The SuSEconfig permissions module, it decides on whether to handle file caps setting or not depending on the kernel.
Ludwig wants a patch to detect this for years in the mainline kernel, but it is not there yet.
Can you please take care that such a method is exposed by mainline? (file_caps might be disabled or enabled, we should handle both cases and detect it from the kernel.)
The patch doing this in the kernel is queued up to be accepted for the .40 kernel release, so perhaps I should also add it to our tree now so that FACTORY can be converted over to using it and this can be dropped?
If so, just let me know and I will go add it as it is in my upstream kernel tree already.
And it was my fault that it took so long to get accepted for the past 6+ months, sorry, it got lost in my patch queue :(
This has now become interesting, it seems. I just noticed that /bin/ping has capabilities set and is no longer suid root on two of my factory machines. Consequently, it's not working unless I boot with file_caps on the command line. As to whether or not it's currently available, wouldn't something like the attached program work for that? I copied the security.capability attribute from /bin/ping to a test program (as root) and it gives me val=0 on my system without file_caps and val=1 on my system with it when I run it with an unprivileged user. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk3cYzgACgkQLPWxlyuTD7LV7QCfbRfX7cWwOfuprKSJ8IoPLInk d48AoKezMiMblfX6aw+UySwtGJmUPEe4 =7yjj -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/29/2011 11:36 AM, Greg KH wrote:
On Fri, Apr 29, 2011 at 08:38:44AM +0200, Marcus Meissner wrote:
On Thu, Apr 28, 2011 at 07:40:08PM -0400, Jeff Mahoney wrote:
On 04/28/2011 02:50 PM, Brandon Philips wrote:
On 13:35 Thu 28 Apr 2011, Jeff Mahoney wrote:
- - patches.suse/file-capabilities-disable-by-default.diff [never submitted]
We should drop it. Upstream has had file caps by default since Nov 2009.
Upstream commits: b3a222e52e4d4be77cc4520a57af1a4a0d8222d1 1f29fae29709b4668979e244c09b2fa78ff1ad59
In doing a zypper dup today, I saw that something is looking at /proc/cmdline for "file_caps" as part of SuSEconfig running. We should probably figure out what that is.
The SuSEconfig permissions module, it decides on whether to handle file caps setting or not depending on the kernel.
Ludwig wants a patch to detect this for years in the mainline kernel, but it is not there yet.
Can you please take care that such a method is exposed by mainline? (file_caps might be disabled or enabled, we should handle both cases and detect it from the kernel.)
The patch doing this in the kernel is queued up to be accepted for the .40 kernel release, so perhaps I should also add it to our tree now so that FACTORY can be converted over to using it and this can be dropped?
If so, just let me know and I will go add it as it is in my upstream kernel tree already.
And it was my fault that it took so long to get accepted for the past 6+ months, sorry, it got lost in my patch queue :(
Just noticed I did "reply list" instead of "reply all" for my original reply to this. Here we go again, with a more fleshed out attachment. This has now become interesting, it seems. I just noticed that /bin/ping has capabilities set and is no longer suid root on two of my factory machines. Consequently, it's not working unless I boot with file_caps on the command line. Attached is a program that will report whether the kernel is honoring file capabilities on the file system where the program is located. It should be run as root. It will set the CAP_NET_RAW capability on itself, drop privileges, and fork/exec itself to compare how the capabilities have changed. Root will always return with all capabilities set, but the user's capability set will change based on the file capabilities. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk3dS4sACgkQLPWxlyuTD7J26gCeNkMvp0W3r9lBSRYue26wqdA3 5CMAnRfaROaRSyIxF5XM/pzbc9M2aGq0 =mp5A -----END PGP SIGNATURE-----
Jeff Mahoney wrote:
This has now become interesting, it seems. I just noticed that /bin/ping has capabilities set and is no longer suid root on two of my factory machines. Consequently, it's not working unless I boot with file_caps on the command line.
Yes, in anticipation of getting rid of the patch that disables fscaps by default I've switched the default from file caps off to file caps on in chkstat. The patch that introduces /sys/kernel/fscaps is now upstream (thanks Greg). So as soon as someone submits the next upstream kernel update to Factory chkstat can decide whether to use fscaps or suid dynamically. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thu, 28 Apr 2011 11:50:11 -0700 Brandon Philips <bphilips@suse.de> wrote:
On 13:35 Thu 28 Apr 2011, Jeff Mahoney wrote:
- - patches.suse/file-capabilities-disable-by-default.diff [never submitted]
We should drop it. Upstream has had file caps by default since Nov 2009.
Apparently this did not happen. How do I enable file_caps now that the SuSEconfig.permissions module needs them? See https://bugzilla.novell.com/show_bug.cgi?id=694550 for the gory details. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On 05/18/2011 03:23 PM, Stefan Seyfried wrote:
On Thu, 28 Apr 2011 11:50:11 -0700 Brandon Philips <bphilips@suse.de> wrote:
On 13:35 Thu 28 Apr 2011, Jeff Mahoney wrote:
- - patches.suse/file-capabilities-disable-by-default.diff [never submitted]
We should drop it. Upstream has had file caps by default since Nov 2009.
Apparently this did not happen. How do I enable file_caps now that the SuSEconfig.permissions module needs them?
See https://bugzilla.novell.com/show_bug.cgi?id=694550 for the gory details.
Unfortunately not available for everybody! normal ? If nothing is pure full secret can you open it ? -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot -- 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 On 05/18/2011 11:25 AM, Bruno Friedmann wrote:
On 05/18/2011 03:23 PM, Stefan Seyfried wrote:
On Thu, 28 Apr 2011 11:50:11 -0700 Brandon Philips <bphilips@suse.de> wrote:
On 13:35 Thu 28 Apr 2011, Jeff Mahoney wrote:
- - patches.suse/file-capabilities-disable-by-default.diff [never submitted]
We should drop it. Upstream has had file caps by default since Nov 2009.
Apparently this did not happen. How do I enable file_caps now that the SuSEconfig.permissions module needs them?
See https://bugzilla.novell.com/show_bug.cgi?id=694550 for the gory details.
Unfortunately not available for everybody! normal ? If nothing is pure full secret can you open it ?
All set. Bugzilla defaults to locking down bug reports that are filed under Security. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk3UFp4ACgkQLPWxlyuTD7LbBQCfUbPyM5jfLfyQ1LxE5mPFRZSv EC0An1Dslv5ioDbO0GTqfsFNo4kNaVh+ =MffB -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On 05/18/2011 08:57 PM, Jeff Mahoney wrote:
On 05/18/2011 11:25 AM, Bruno Friedmann wrote:
On 05/18/2011 03:23 PM, Stefan Seyfried wrote:
On Thu, 28 Apr 2011 11:50:11 -0700 Brandon Philips <bphilips@suse.de> wrote:
On 13:35 Thu 28 Apr 2011, Jeff Mahoney wrote:
- - patches.suse/file-capabilities-disable-by-default.diff [never submitted]
We should drop it. Upstream has had file caps by default since Nov 2009.
Apparently this did not happen. How do I enable file_caps now that the SuSEconfig.permissions module needs them?
See https://bugzilla.novell.com/show_bug.cgi?id=694550 for the gory details.
Unfortunately not available for everybody! normal ? If nothing is pure full secret can you open it ?
All set. Bugzilla defaults to locking down bug reports that are filed under Security.
-Jeff
Thanks. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On 04/28/2011 07:35 PM, Jeff Mahoney wrote:
Jiri Slaby: - - patches.suse/wireless-no-aes-select
Hi, this doesn't make sense anymore, dropped.
- - patches.fixes/iwlwifi-fix-tx-power-configuration-on-3945-and-4965-devices
This was incorrectly disabled during the 2.6.38 merge. The patched code was only heavily moved around, but the fix is still needed. I rebased and reenabled the patch and asked reporters of the corresponding bug to retest (the bnc was reopened). If that works, I'll ping upstream about that... thanks, -- js suse labs -- 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 On 04/28/2011 04:00 PM, Jiri Slaby wrote:
On 04/28/2011 07:35 PM, Jeff Mahoney wrote:
Jiri Slaby: - - patches.suse/wireless-no-aes-select
Hi, this doesn't make sense anymore, dropped.
- - patches.fixes/iwlwifi-fix-tx-power-configuration-on-3945-and-4965-devices
This was incorrectly disabled during the 2.6.38 merge. The patched code was only heavily moved around, but the fix is still needed. I rebased and reenabled the patch and asked reporters of the corresponding bug to retest (the bnc was reopened). If that works, I'll ping upstream about that...
Ok, thanks. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk25+v8ACgkQLPWxlyuTD7Lr3gCdEJH2Rme42ezo8cVAyiKSty5w RGsAn3nfSMkUelMVX4fwq+C9oQnZ6pu6 =zokh -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thursday, April 28, 2011, Jeff Mahoney wrote:
Hi guys -
We've been carrying the following patches in the openSUSE kernel for some time and there's no need for them to be openSUSE-specific.
Can you review the patches below and either remove them, submit them upstream, or at least at a signed-off-by if there isn't one already so I can do so?
Even though there are patches that only affect architectures which we don't support on openSUSE and can be dropped as far as openSUSE is concerned, the Factory kernel will eventually be branched for the SLE12 kernel. Getting rid of them now only makes things easier later. ... Rafael Wysocki: - patches.arch/x86-mcp51-no-dac [rejected by Alan Cox, Mar 2009]
Dropped. I must admit I had a problem with this one (it's a Tejun's patch to be precise), but finally decided it's better to remain bug compatible with the mainline in that respect and fix the problem in there first if that turns out to be necessary.
- patches.fixes/tg3-fix-default-wol.patch
Submitted upstream. Thanks, Rafael -- 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 On 04/28/2011 05:24 PM, Rafael J. Wysocki wrote:
On Thursday, April 28, 2011, Jeff Mahoney wrote:
Hi guys -
We've been carrying the following patches in the openSUSE kernel for some time and there's no need for them to be openSUSE-specific.
Can you review the patches below and either remove them, submit them upstream, or at least at a signed-off-by if there isn't one already so I can do so?
Even though there are patches that only affect architectures which we don't support on openSUSE and can be dropped as far as openSUSE is concerned, the Factory kernel will eventually be branched for the SLE12 kernel. Getting rid of them now only makes things easier later. ... Rafael Wysocki: - patches.arch/x86-mcp51-no-dac [rejected by Alan Cox, Mar 2009]
Dropped. I must admit I had a problem with this one (it's a Tejun's patch to be precise), but finally decided it's better to remain bug compatible with the mainline in that respect and fix the problem in there first if that turns out to be necessary.
Ok, that works for me.
- patches.fixes/tg3-fix-default-wol.patch
Submitted upstream.
Great, thanks. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk25+zEACgkQLPWxlyuTD7LjcACfZ6g8L6zxouJse8hGHBP9X6UP jbIAoJ00b1fcxHgBhVle+oE9E7BQNCmd =z85W -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thu 28-04-11 13:35:13, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Jan Kara: - - patches.suse/readahead-request-tunables.patch This is dependent on SUSE-specific CONFIG_KERNEL_DESKTOP. General update of the defaults probably wouldn't pass. So I think we have to carry this one...
- - patches.suse/raw_device_max_minors_param.diff OK, I'll try to push it upstream (although not sure through whom). Last time I tried to push it, I was told that the driver is going to be removed from upstream altogether but it seems to be still there so I think it may be time to revisit this.
[ Up for discussion ] - - patches.suse/file-capabilities-disable-by-default.diff [never submitted] - - patches.suse/connector-read-mostly - - patches.suse/ext3-barrier-default - - patches.suse/reiserfs-barrier-default Although I believe the above two would be sane defaults, I kind of feel it might be too late to change the defaults upstream. It would probably generate lots of bug reports of the type "my IO is suddently slower"...
Honza -- Jan Kara <jack@suse.cz> SUSE Labs, CR -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Fri, Apr 29, 2011 at 12:17:21AM +0200, Jan Kara wrote:
- - patches.suse/raw_device_max_minors_param.diff OK, I'll try to push it upstream (although not sure through whom). Last time I tried to push it, I was told that the driver is going to be removed from upstream altogether but it seems to be still there so I think it may be time to revisit this.
You can send it through me and CC: lkml as I think I pushed back on this last time as I thought this code was going to be removed. As it doesn't look like it ever will, I'll shephard it into Linus's tree if you send it to me. thanks, greg k-h -- 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 On 04/28/2011 06:40 PM, Greg KH wrote:
On Fri, Apr 29, 2011 at 12:17:21AM +0200, Jan Kara wrote:
- - patches.suse/raw_device_max_minors_param.diff OK, I'll try to push it upstream (although not sure through whom). Last time I tried to push it, I was told that the driver is going to be removed from upstream altogether but it seems to be still there so I think it may be time to revisit this.
You can send it through me and CC: lkml as I think I pushed back on this last time as I thought this code was going to be removed. As it doesn't look like it ever will, I'll shephard it into Linus's tree if you send it to me.
Perfect, thanks. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk25/E0ACgkQLPWxlyuTD7KMKQCeLtlBnoaPD8v0k0y0ej5wlo/3 yNcAoJbzcnDgr+wQ5ZNdWvYCGWJuR14m =Su1V -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thu 28-04-11 15:40:53, Greg KH wrote:
On Fri, Apr 29, 2011 at 12:17:21AM +0200, Jan Kara wrote:
- - patches.suse/raw_device_max_minors_param.diff OK, I'll try to push it upstream (although not sure through whom). Last time I tried to push it, I was told that the driver is going to be removed from upstream altogether but it seems to be still there so I think it may be time to revisit this.
You can send it through me and CC: lkml as I think I pushed back on this last time as I thought this code was going to be removed. As it doesn't look like it ever will, I'll shephard it into Linus's tree if you send it to me. OK, thanks. I've already sent the patch to LKML so I'll bounce the email to you...
Honza -- Jan Kara <jack@suse.cz> SUSE Labs, CR -- 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 On 04/28/2011 06:17 PM, Jan Kara wrote:
On Thu 28-04-11 13:35:13, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Jan Kara: - - patches.suse/readahead-request-tunables.patch This is dependent on SUSE-specific CONFIG_KERNEL_DESKTOP. General update of the defaults probably wouldn't pass. So I think we have to carry this one...
Ok, I had this one in mind if Suresh has any luck getting the tunable defaults upstream - or if we end up working with sysctls instead. An interesting side-idea might be to add the ability for the sysctl utility to load a kernel-specific sysctl.conf that we ship with each flavor and then apply the system values on top of those, overriding the ones that collide. We'd get the benefits without the kernel patches.
- - patches.suse/raw_device_max_minors_param.diff OK, I'll try to push it upstream (although not sure through whom). Last time I tried to push it, I was told that the driver is going to be removed from upstream altogether but it seems to be still there so I think it may be time to revisit this.
[ Up for discussion ] - - patches.suse/file-capabilities-disable-by-default.diff [never submitted] - - patches.suse/connector-read-mostly - - patches.suse/ext3-barrier-default - - patches.suse/reiserfs-barrier-default Although I believe the above two would be sane defaults, I kind of feel it might be too late to change the defaults upstream. It would probably generate lots of bug reports of the type "my IO is suddently slower"...
I'm not convinced they actually *are* sane defaults for commodity hardware. Having to flush the entire cache for a barrier is a pretty heavyweight operation, especially with the sizes of caches growing on individual disks. In my own testing it seems like it's faster to disable the write cache and use regular buffer waits rather than flush the cache, but it's been a while since I've done that. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk25/DwACgkQLPWxlyuTD7JxEQCfS9XkRUEn/l0PFVv6ffVCee24 8TAAoIJJ0yC0RUmalFz5CQjzWpf6jogX =N0GW -----END PGP SIGNATURE----- -- 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 On 04/28/2011 07:46 PM, Jeff Mahoney wrote:
On 04/28/2011 06:17 PM, Jan Kara wrote:
On Thu 28-04-11 13:35:13, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Jan Kara: - - patches.suse/readahead-request-tunables.patch This is dependent on SUSE-specific CONFIG_KERNEL_DESKTOP. General update of the defaults probably wouldn't pass. So I think we have to carry this one...
Ok, I had this one in mind if Suresh has any luck getting the tunable defaults upstream - or if we end up working with sysctls instead. An interesting side-idea might be to add the ability for the sysctl utility to load a kernel-specific sysctl.conf that we ship with each flavor and then apply the system values on top of those, overriding the ones that collide. We'd get the benefits without the kernel patches.
Actually, it's even easier than this. The sysctl tool loads values from the filenames it's passed. That generally means just /etc/sysctl.conf but we could modify boot.sysctl to load a per-kernel sysctl.conf first. It'd probably go into /boot, just like we do for .config and System.map already. There's a /etc/sysctl.d on my system, but it's part of systemd and loads after /etc/sysctl.conf. For now, we'd only need a sysctl.conf-2.6.39-rc4-12-desktop that contains the following line: vm.dirty_ratio = 20 There were two other things related to KERNEL_DESKTOP: Preemption and cgroups. Since systemd requires cgroups, they're now enabled everywhere anyway. We can probably remember to keep CONFIG_PREEMPT=y on the desktop flavors on our own, or perhaps create a mechanism to check that certain options are enabled on certain flavors. - -Jeff [CC'ing Werner to comment on the idea] - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk26DpYACgkQLPWxlyuTD7I9/wCferzXGTpSsS1pjRi0hHrREXFb hCgAn0/E3sMTwpuRbSJdRPT4qr4syLF3 =FPns -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thu, Apr 28, 2011 at 09:04:22PM -0400, Jeff Mahoney wrote:
On 04/28/2011 07:46 PM, Jeff Mahoney wrote:
On 04/28/2011 06:17 PM, Jan Kara wrote:
On Thu 28-04-11 13:35:13, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Jan Kara: - - patches.suse/readahead-request-tunables.patch This is dependent on SUSE-specific CONFIG_KERNEL_DESKTOP. General update of the defaults probably wouldn't pass. So I think we have to carry this one...
Ok, I had this one in mind if Suresh has any luck getting the tunable defaults upstream - or if we end up working with sysctls instead. An interesting side-idea might be to add the ability for the sysctl utility to load a kernel-specific sysctl.conf that we ship with each flavor and then apply the system values on top of those, overriding the ones that collide. We'd get the benefits without the kernel patches.
Actually, it's even easier than this. The sysctl tool loads values from the filenames it's passed. That generally means just /etc/sysctl.conf but we could modify boot.sysctl to load a per-kernel sysctl.conf first. It'd probably go into /boot, just like we do for .config and System.map already. There's a /etc/sysctl.d on my system, but it's part of systemd and loads after /etc/sysctl.conf.
For now, we'd only need a sysctl.conf-2.6.39-rc4-12-desktop that contains the following line: vm.dirty_ratio = 20
There were two other things related to KERNEL_DESKTOP: Preemption and cgroups. Since systemd requires cgroups, they're now enabled everywhere anyway. We can probably remember to keep CONFIG_PREEMPT=y on the desktop flavors on our own, or perhaps create a mechanism to check that certain options are enabled on certain flavors.
-Jeff
[CC'ing Werner to comment on the idea]
I'd like to see something /lib/modules/<kernel-version>/sysctl.conf or /boot/sysctl.<kernel-version> but /boot could be an own paritition whereas /lib is not. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- 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 On 04/29/2011 10:46 AM, Dr. Werner Fink wrote:
On Thu, Apr 28, 2011 at 09:04:22PM -0400, Jeff Mahoney wrote:
On 04/28/2011 07:46 PM, Jeff Mahoney wrote:
On 04/28/2011 06:17 PM, Jan Kara wrote:
On Thu 28-04-11 13:35:13, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Jan Kara: - - patches.suse/readahead-request-tunables.patch This is dependent on SUSE-specific CONFIG_KERNEL_DESKTOP. General update of the defaults probably wouldn't pass. So I think we have to carry this one...
Ok, I had this one in mind if Suresh has any luck getting the tunable defaults upstream - or if we end up working with sysctls instead. An interesting side-idea might be to add the ability for the sysctl utility to load a kernel-specific sysctl.conf that we ship with each flavor and then apply the system values on top of those, overriding the ones that collide. We'd get the benefits without the kernel patches.
Actually, it's even easier than this. The sysctl tool loads values from the filenames it's passed. That generally means just /etc/sysctl.conf but we could modify boot.sysctl to load a per-kernel sysctl.conf first. It'd probably go into /boot, just like we do for .config and System.map already. There's a /etc/sysctl.d on my system, but it's part of systemd and loads after /etc/sysctl.conf.
For now, we'd only need a sysctl.conf-2.6.39-rc4-12-desktop that contains the following line: vm.dirty_ratio = 20
There were two other things related to KERNEL_DESKTOP: Preemption and cgroups. Since systemd requires cgroups, they're now enabled everywhere anyway. We can probably remember to keep CONFIG_PREEMPT=y on the desktop flavors on our own, or perhaps create a mechanism to check that certain options are enabled on certain flavors.
-Jeff
[CC'ing Werner to comment on the idea]
I'd like to see something
/lib/modules/<kernel-version>/sysctl.conf
or
/boot/sysctl.<kernel-version>
but /boot could be an own paritition whereas /lib is not.
I'm not sure if we're "allowed" to put additional files in /lib/modules/$UNAME but it seems like the best way to do it. One of my concerns is net-booting a particular flavor, where /boot probably won't be populated as it should be. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk260oQACgkQLPWxlyuTD7KqlgCfdGICYiAHbaCiXBogvK2/aiGj 3oQAn3uyu8Lzn96dKtgaKPtagBs/3FMW =yhBp -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Fri, Apr 29, 2011 at 11:00:20AM -0400, Jeff Mahoney wrote:
[CC'ing Werner to comment on the idea]
I'd like to see something
/lib/modules/<kernel-version>/sysctl.conf
or
/boot/sysctl.<kernel-version>
but /boot could be an own paritition whereas /lib is not.
I'm not sure if we're "allowed" to put additional files in /lib/modules/$UNAME but it seems like the best way to do it. One of my concerns is net-booting a particular flavor, where /boot probably won't be populated as it should be.
Sometimes the sysctl files exist only after a specific module is loaded. Maybe there is a way to combine modules configuration with sysctl values. That is not only having default sysctl values for a specific kernel but additional for specific modules of a specific kernel 8-) IMHO this could also be an idea for upstram of module-init-tools, couldn't it? I'll add Michal to CC list. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thu 28-04-11 19:46:04, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu 28-04-11 13:35:13, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Jan Kara: - - patches.suse/readahead-request-tunables.patch This is dependent on SUSE-specific CONFIG_KERNEL_DESKTOP. General update of the defaults probably wouldn't pass. So I think we have to carry this one... Ok, I had this one in mind if Suresh has any luck getting the tunable defaults upstream - or if we end up working with sysctls instead. An interesting side-idea might be to add the ability for the sysctl utility to load a kernel-specific sysctl.conf that we ship with each flavor and
On 04/28/2011 06:17 PM, Jan Kara wrote: then apply the system values on top of those, overriding the ones that collide. We'd get the benefits without the kernel patches. Yeah, it would be easiest if we could do such parameter tuning without a kernel patch.
[ Up for discussion ] - - patches.suse/file-capabilities-disable-by-default.diff [never submitted] - - patches.suse/connector-read-mostly - - patches.suse/ext3-barrier-default - - patches.suse/reiserfs-barrier-default Although I believe the above two would be sane defaults, I kind of feel it might be too late to change the defaults upstream. It would probably generate lots of bug reports of the type "my IO is suddently slower"...
I'm not convinced they actually *are* sane defaults for commodity hardware. Having to flush the entire cache for a barrier is a pretty heavyweight operation, especially with the sizes of caches growing on individual disks. In my own testing it seems like it's faster to disable the write cache and use regular buffer waits rather than flush the cache, but it's been a while since I've done that. I guess it depends on the drive and the load. I remember Tejun did some testing of this when he was working on the barrier code and found out that write caches are useful on normal SATA drives. The drive can still do more reordering of IO when it has write caches enabled. But I agree that e.g. for fsync heavy workloads, turning off write caches may well be the faster option.
Honza -- Jan Kara <jack@suse.cz> SUSE Labs, CR -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thu, 28 Apr 2011 13:35:13 -0400, Jeff Mahoney wrote:
Jiri Benc: - - patches.suse/panic-on-io-nmi-SLE11-user-space-api.patch [disabled since 2.6.33] [does anyone even use the binary sysctl interface for this?]
Probably not. Deleted from master. Jiri -- Jiri Benc SUSE Labs -- 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 On 04/28/2011 06:19 PM, Jiri Benc wrote:
On Thu, 28 Apr 2011 13:35:13 -0400, Jeff Mahoney wrote:
Jiri Benc: - - patches.suse/panic-on-io-nmi-SLE11-user-space-api.patch [disabled since 2.6.33] [does anyone even use the binary sysctl interface for this?]
Probably not. Deleted from master.
Great, thanks. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk25/FgACgkQLPWxlyuTD7JlHwCcC+MVFYrzLotvig0yx+BeNvEi EEgAn3w3spxI5UEUFz1oe4PGLHs64fR2 =jcau -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On 28.04.2011, at 19:35, Jeff Mahoney <jeffm@suse.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi guys -
We've been carrying the following patches in the openSUSE kernel for some time and there's no need for them to be openSUSE-specific.
Can you review the patches below and either remove them, submit them upstream, or at least at a signed-off-by if there isn't one already so I can do so?
Even though there are patches that only affect architectures which we don't support on openSUSE and can be dropped as far as openSUSE is concerned, the Factory kernel will eventually be branched for the SLE12 kernel. Getting rid of them now only makes things easier later.
Alexander Graf: - - patches.arch/kvm-split-paravirt-ops-by-functionality - - patches.arch/kvm-only-export-selected-pv-ops-feature-structs - - patches.arch/kvm-split-the-KVM-pv-ops-support-by-feature
The paravirt stuff was done for sle, so we don't get slowdown on mmu centric code paths. Something went wring with upstreamng back then - mostly lack of interest of the maintainer iirc. I'll try again. How should we go here? Do I just remove the patches?
- - patches.arch/kvm-replace-kvm-io-delay-pv-ops-with-linux-magic
This one at least made it in already :).
[these 4 have been disabled since 2.6.38-rc1] - - patches.fixes/kvm-ioapic.patch - - patches.fixes/kvm-macos.patch
These might take a while to settle down on something usable for upstream. I'll start another round of pushing osx guest support upsteam soon, so this will come up upstream. For the time being, I'd just leave them in. Alex PS: olh@suse.de is now ohering@suse.de.
-- 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 On 04/28/2011 07:27 PM, Alexander Graf wrote:
On 28.04.2011, at 19:35, Jeff Mahoney <jeffm@suse.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi guys -
We've been carrying the following patches in the openSUSE kernel for some time and there's no need for them to be openSUSE-specific.
Can you review the patches below and either remove them, submit them upstream, or at least at a signed-off-by if there isn't one already so I can do so?
Even though there are patches that only affect architectures which we don't support on openSUSE and can be dropped as far as openSUSE is concerned, the Factory kernel will eventually be branched for the SLE12 kernel. Getting rid of them now only makes things easier later.
Alexander Graf: - - patches.arch/kvm-split-paravirt-ops-by-functionality - - patches.arch/kvm-only-export-selected-pv-ops-feature-structs - - patches.arch/kvm-split-the-KVM-pv-ops-support-by-feature
The paravirt stuff was done for sle, so we don't get slowdown on mmu centric code paths. Something went wring with upstreamng back then - mostly lack of interest of the maintainer iirc. I'll try again.
How should we go here? Do I just remove the patches?
Is there a better way to do this now that we have some more flexibility? I don't really want to revisit the performance hits that paravirt_ops brought to SLE11. If the performance concerns have been addressed in a different way, then we can drop these.
- - patches.arch/kvm-replace-kvm-io-delay-pv-ops-with-linux-magic
This one at least made it in already :).
[these 4 have been disabled since 2.6.38-rc1] - - patches.fixes/kvm-ioapic.patch - - patches.fixes/kvm-macos.patch
These might take a while to settle down on something usable for upstream. I'll start another round of pushing osx guest support upsteam soon, so this will come up upstream. For the time being, I'd just leave them in.
Ok. Does the Mac support in qemu need to be updated too? It seems those patches haven't applied for a while and the upstream code has changed a lot. I tried to boot macos with it and it basically laughed at me. ;)
PS: olh@suse.de is now ohering@suse.de.
Yep. I got the bounce and forwarded it. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk25+n4ACgkQLPWxlyuTD7JKbACgqAMHpl5BEGAaGd4O+zowLkND vUUAn3bRGeWAaDGxqlyxvSr8m7892Bi4 =2oOk -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On 29.04.2011, at 01:38, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/28/2011 07:27 PM, Alexander Graf wrote:
On 28.04.2011, at 19:35, Jeff Mahoney <jeffm@suse.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi guys -
We've been carrying the following patches in the openSUSE kernel for some time and there's no need for them to be openSUSE-specific.
Can you review the patches below and either remove them, submit them upstream, or at least at a signed-off-by if there isn't one already so I can do so?
Even though there are patches that only affect architectures which we don't support on openSUSE and can be dropped as far as openSUSE is concerned, the Factory kernel will eventually be branched for the SLE12 kernel. Getting rid of them now only makes things easier later.
Alexander Graf: - - patches.arch/kvm-split-paravirt-ops-by-functionality - - patches.arch/kvm-only-export-selected-pv-ops-feature-structs - - patches.arch/kvm-split-the-KVM-pv-ops-support-by-feature
The paravirt stuff was done for sle, so we don't get slowdown on mmu centric code paths. Something went wring with upstreamng back then - mostly lack of interest of the maintainer iirc. I'll try again.
How should we go here? Do I just remove the patches?
Is there a better way to do this now that we have some more flexibility? I don't really want to revisit the performance hits that paravirt_ops brought to SLE11. If the performance concerns have been addressed in a different way, then we can drop these.
Unfortunately, they haven't been addressed at all FWIW. I also still believe that this is the best way to go - if you don't need to hook into certain subsystems, don't pv-opsizine them :). I just really need to go through the current code again and readjust everything.
- - patches.arch/kvm-replace-kvm-io-delay-pv-ops-with-linux-magic
This one at least made it in already :).
[these 4 have been disabled since 2.6.38-rc1] - - patches.fixes/kvm-ioapic.patch - - patches.fixes/kvm-macos.patch
These might take a while to settle down on something usable for upstream. I'll start another round of pushing osx guest support upsteam soon, so this will come up upstream. For the time being, I'd just leave them in.
Ok. Does the Mac support in qemu need to be updated too? It seems those patches haven't applied for a while and the upstream code has changed a lot. I tried to boot macos with it and it basically laughed at me. ;)
Yes, it does. I have almost everything in upstream qemu.git, but am missing 2 patches (LPC support, BIOS patch). It's on my todo list for the near future, so stay tuned :). It'd be a shame to lose kvm support in the opensuse kernel just while finally getting all the userspace support upstream. Alex -- 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 On 04/28/2011 07:53 PM, Alexander Graf wrote:
On 29.04.2011, at 01:38, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/28/2011 07:27 PM, Alexander Graf wrote:
On 28.04.2011, at 19:35, Jeff Mahoney <jeffm@suse.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi guys -
We've been carrying the following patches in the openSUSE kernel for some time and there's no need for them to be openSUSE-specific.
Can you review the patches below and either remove them, submit them upstream, or at least at a signed-off-by if there isn't one already so I can do so?
Even though there are patches that only affect architectures which we don't support on openSUSE and can be dropped as far as openSUSE is concerned, the Factory kernel will eventually be branched for the SLE12 kernel. Getting rid of them now only makes things easier later.
Alexander Graf: - - patches.arch/kvm-split-paravirt-ops-by-functionality - - patches.arch/kvm-only-export-selected-pv-ops-feature-structs - - patches.arch/kvm-split-the-KVM-pv-ops-support-by-feature
The paravirt stuff was done for sle, so we don't get slowdown on mmu centric code paths. Something went wring with upstreamng back then - mostly lack of interest of the maintainer iirc. I'll try again.
How should we go here? Do I just remove the patches?
Is there a better way to do this now that we have some more flexibility? I don't really want to revisit the performance hits that paravirt_ops brought to SLE11. If the performance concerns have been addressed in a different way, then we can drop these.
Unfortunately, they haven't been addressed at all FWIW. I also still believe that this is the best way to go - if you don't need to hook into certain subsystems, don't pv-opsizine them :). I just really need to go through the current code again and readjust everything.
Now that we have jump labels, could they be used to fast path the ones that aren't actually used? Wasn't the big impact the indirection used in very fast paths? Or would something like that not actually apply here? I haven't taken a good look at the code, they just seem like a good general way to make optional features nearly free.
- - patches.arch/kvm-replace-kvm-io-delay-pv-ops-with-linux-magic
This one at least made it in already :).
[these 4 have been disabled since 2.6.38-rc1] - - patches.fixes/kvm-ioapic.patch - - patches.fixes/kvm-macos.patch
These might take a while to settle down on something usable for upstream. I'll start another round of pushing osx guest support upsteam soon, so this will come up upstream. For the time being, I'd just leave them in.
Ok. Does the Mac support in qemu need to be updated too? It seems those patches haven't applied for a while and the upstream code has changed a lot. I tried to boot macos with it and it basically laughed at me. ;)
Yes, it does. I have almost everything in upstream qemu.git, but am missing 2 patches (LPC support, BIOS patch). It's on my todo list for the near future, so stay tuned :). It'd be a shame to lose kvm support in the opensuse kernel just while finally getting all the userspace support upstream.
Ok, that's good enough for me. Ideally, this'll be done before the 12.1 release anyway, right? - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk26AnYACgkQLPWxlyuTD7KhhQCeIgoU0YXoyfyPzDkG2be2JTEe Ml4An299YdxQUO9RkLh+A0Fq5B14N39J =AaaL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On 29.04.2011, at 02:12, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/28/2011 07:53 PM, Alexander Graf wrote:
On 29.04.2011, at 01:38, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/28/2011 07:27 PM, Alexander Graf wrote:
On 28.04.2011, at 19:35, Jeff Mahoney <jeffm@suse.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi guys -
We've been carrying the following patches in the openSUSE kernel for some time and there's no need for them to be openSUSE-specific.
Can you review the patches below and either remove them, submit them upstream, or at least at a signed-off-by if there isn't one already so I can do so?
Even though there are patches that only affect architectures which we don't support on openSUSE and can be dropped as far as openSUSE is concerned, the Factory kernel will eventually be branched for the SLE12 kernel. Getting rid of them now only makes things easier later.
Alexander Graf: - - patches.arch/kvm-split-paravirt-ops-by-functionality - - patches.arch/kvm-only-export-selected-pv-ops-feature-structs - - patches.arch/kvm-split-the-KVM-pv-ops-support-by-feature
The paravirt stuff was done for sle, so we don't get slowdown on mmu centric code paths. Something went wring with upstreamng back then - mostly lack of interest of the maintainer iirc. I'll try again.
How should we go here? Do I just remove the patches?
Is there a better way to do this now that we have some more flexibility? I don't really want to revisit the performance hits that paravirt_ops brought to SLE11. If the performance concerns have been addressed in a different way, then we can drop these.
Unfortunately, they haven't been addressed at all FWIW. I also still believe that this is the best way to go - if you don't need to hook into certain subsystems, don't pv-opsizine them :). I just really need to go through the current code again and readjust everything.
Now that we have jump labels, could they be used to fast path the ones that aren't actually used? Wasn't the big impact the indirection used in very fast paths? Or would something like that not actually apply here? I haven't taken a good look at the code, they just seem like a good general way to make optional features nearly free.
Hrm. I honestly haven't heard of them yet. I can take a look though :).
- - patches.arch/kvm-replace-kvm-io-delay-pv-ops-with-linux-magic
This one at least made it in already :).
[these 4 have been disabled since 2.6.38-rc1] - - patches.fixes/kvm-ioapic.patch - - patches.fixes/kvm-macos.patch
These might take a while to settle down on something usable for upstream. I'll start another round of pushing osx guest support upsteam soon, so this will come up upstream. For the time being, I'd just leave them in.
Ok. Does the Mac support in qemu need to be updated too? It seems those patches haven't applied for a while and the upstream code has changed a lot. I tried to boot macos with it and it basically laughed at me. ;)
Yes, it does. I have almost everything in upstream qemu.git, but am missing 2 patches (LPC support, BIOS patch). It's on my todo list for the near future, so stay tuned :). It'd be a shame to lose kvm support in the opensuse kernel just while finally getting all the userspace support upstream.
Ok, that's good enough for me. Ideally, this'll be done before the 12.1 release anyway, right?
Hopefully :). When is that one due? Alex -- 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 On 04/28/2011 08:15 PM, Alexander Graf wrote:
On 29.04.2011, at 02:12, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/28/2011 07:53 PM, Alexander Graf wrote:
On 29.04.2011, at 01:38, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/28/2011 07:27 PM, Alexander Graf wrote:
On 28.04.2011, at 19:35, Jeff Mahoney <jeffm@suse.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi guys -
We've been carrying the following patches in the openSUSE kernel for some time and there's no need for them to be openSUSE-specific.
Can you review the patches below and either remove them, submit them upstream, or at least at a signed-off-by if there isn't one already so I can do so?
Even though there are patches that only affect architectures which we don't support on openSUSE and can be dropped as far as openSUSE is concerned, the Factory kernel will eventually be branched for the SLE12 kernel. Getting rid of them now only makes things easier later.
Alexander Graf: - - patches.arch/kvm-split-paravirt-ops-by-functionality - - patches.arch/kvm-only-export-selected-pv-ops-feature-structs - - patches.arch/kvm-split-the-KVM-pv-ops-support-by-feature
The paravirt stuff was done for sle, so we don't get slowdown on mmu centric code paths. Something went wring with upstreamng back then - mostly lack of interest of the maintainer iirc. I'll try again.
How should we go here? Do I just remove the patches?
Is there a better way to do this now that we have some more flexibility? I don't really want to revisit the performance hits that paravirt_ops brought to SLE11. If the performance concerns have been addressed in a different way, then we can drop these.
Unfortunately, they haven't been addressed at all FWIW. I also still believe that this is the best way to go - if you don't need to hook into certain subsystems, don't pv-opsizine them :). I just really need to go through the current code again and readjust everything.
Now that we have jump labels, could they be used to fast path the ones that aren't actually used? Wasn't the big impact the indirection used in very fast paths? Or would something like that not actually apply here? I haven't taken a good look at the code, they just seem like a good general way to make optional features nearly free.
Hrm. I honestly haven't heard of them yet. I can take a look though :).
Great.
- - patches.arch/kvm-replace-kvm-io-delay-pv-ops-with-linux-magic
This one at least made it in already :).
[these 4 have been disabled since 2.6.38-rc1] - - patches.fixes/kvm-ioapic.patch - - patches.fixes/kvm-macos.patch
These might take a while to settle down on something usable for upstream. I'll start another round of pushing osx guest support upsteam soon, so this will come up upstream. For the time being, I'd just leave them in.
Ok. Does the Mac support in qemu need to be updated too? It seems those patches haven't applied for a while and the upstream code has changed a lot. I tried to boot macos with it and it basically laughed at me. ;)
Yes, it does. I have almost everything in upstream qemu.git, but am missing 2 patches (LPC support, BIOS patch). It's on my todo list for the near future, so stay tuned :). It'd be a shame to lose kvm support in the opensuse kernel just while finally getting all the userspace support upstream.
Ok, that's good enough for me. Ideally, this'll be done before the 12.1 release anyway, right?
Hopefully :). When is that one due?
12.1 release is 12 Nov 2011, but a more detailed release schedule isn't available yet. Judging by how the timelines have shaken out so far, that probably means 2.6.40, maybe 2.6.41. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk26BJ8ACgkQLPWxlyuTD7Kx2gCgoxHe8n9Wzg9t7M6xAkOMFYvJ z/IAn1I3+2e1b/NcGgOz9xRxalu2r31l =4n9M -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
At Thu, 28 Apr 2011 13:35:13 -0400, Jeff Mahoney wrote:
Takashi Iwai: - - patches.arch/ppc-ipic-suspend-without-83xx-fix [ppc]
I don't remember at all that I fixed it ;) It must be obsoleted, and easy to fix again. Let's drop.
- - patches.arch/x86-hpet-pre-read [disabled since 2.6.37]
Obsoleted. Dropped now.
- - patches.drivers/input-Add-LED-support-to-Synaptics-device
This patch was already submitted twice, but didn't get in by minor reason, IIRC. Anyway, I'm not allowed to work on Synaptics issues any longer. If you have any questions, ask Canonical. (Seriously, I have to answer like this.)
- - patches.drivers/alsa-hda-0019-Increase-default-buffer-size
Still needed as a temporary fix due to transition to systemd. I may add a new kernel config instead in future. Keep this for now. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thu, Apr 28, 2011 at 01:35:13PM -0400, Jeff Mahoney wrote:
[ Up for discussion ] [...] - - patches.suse/SUSE-bootsplash
I've cleaned this one up just recently, fixed a number of bugs and added pieces required to support a 'seamless boot experience'. Yet I doubt that we will ever be able to get this accepted upstream. Still I'm reluctant to nuke it yet as it has been proven to work well within the boot scenario we use on (open)SUSE - and this even without adding bloat to the initrd image as any alternative splash screen concept do. Cheers, Egbert. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On 04/28/2011 11:05 PM, Jeff Mahoney wrote:
Suresh Jayaraman: - - patches.suse/sched-revert-latency-defaults [disabled since 2.6.33, after SLE11SP1]
I think it make sense for openSUSE to be close to upstream and given that we have not had any reports since we disabled this, this can be safely dropped.
- - patches.suse/mm-tune-dirty-limits.patch [we may want to revisit per-flavor sysctl files]
Agreed, I think dropping this might have visible impact on performance for users. I think we would need this change but perhaps without kernel changes as suggested by Jeff. So, I plan not drop this until we have a replacement solution in place. Thanks, -- Suresh Jayaraman -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thu 28-04-11 13:35:13, Jeff Mahoney wrote: [...]
Mel Gorman / Michal Hocko: - - patches.fixes/grab-swap-token-oops
There are still no in-kernel users of gup from kernel threads AFAICS. Besides that I think there is no issue in the current upstream because we do not get to handle_mm_fault (and grab_swap_token) path if there is no mm_struct. find_extend_vma will return NULL for (mm == NULL) and so we either go into gate_vma path (which is not handled by the patch and still can be an issue because of pgd_offset_gate) or fail with -EFAULT. The same applies to openSUSE-11.4 and SLES10_SP4_BRANCH branches. If Mel doesn't see anything I would vote for dropping the patch from all supported branches.
- - patches.suse/files-slab-rcu.patch
Nick's VFS black magic. The patch is not applied in openSUSE-11.4. Sorry, I cannot say anything about this patch.
- - patches.suse/mm-devzero-optimisation.patch [against SLES10, issue may not exist anymore]
Yes we can drop it from SLE11-SP1 and openSUSE-11.4 branches. The zero page has been reintroduced in 2.6.32. The main reason for the above patch was the page fault overhead (coming from allocation and zeroing) during copying from /dev/zero. Now that we have zero page again this is not a case anymore so we do not need any special /dev/zero hacks.
- - patches.fixes/aggressive-zone-reclaim.patch [disabled since 2.6.36]
I assume that the patch has been reverted due to changes in the area, right? My impression of the patch is that is highly workload specific. Especially decreasing ZONE_RECLAIM_PRIORITY to 0 is very tricky because it makes reclaim really aggressive. I think this part is highly controversial for upstream. Nevertheless, I quite like the ZONE_RECLAIM_LOCKED part. Although, this can be really subtle because we might end up reclaiming too much if there is really heavy parallel load or multiple high order allocators. I will wait with reverting for Mel but mm-devzero-optimisation.patch is one that can go away for sure. -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thu 28-04-11 13:35:13, Jeff Mahoney wrote: [...]
- - patches.suse/files-slab-rcu.patch
Nick's VFS black magic. The patch is not applied in openSUSE-11.4. Sorry, I cannot say anything about this patch. Yeah. There used to be issues in this patch causing memory corruption (use after free). Nick tried to fix them and I think this version could have them fixed but unless Nick wishes to pursue this further and push the change upstream I don't think we should carry this. I'll ask Nick about the
On Fri 29-04-11 12:28:50, Michal Hocko wrote: patch. Honza -- Jan Kara <jack@suse.cz> SUSE Labs, CR -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Fri, Apr 29, 2011 at 12:28:50PM +0200, Michal Hocko wrote:
On Thu 28-04-11 13:35:13, Jeff Mahoney wrote: [...]
Mel Gorman / Michal Hocko: - - patches.fixes/grab-swap-token-oops
There are still no in-kernel users of gup from kernel threads AFAICS. Besides that I think there is no issue in the current upstream because we do not get to handle_mm_fault (and grab_swap_token) path if there is no mm_struct. find_extend_vma will return NULL for (mm == NULL) and so we either go into gate_vma path (which is not handled by the patch and still can be an issue because of pgd_offset_gate) or fail with -EFAULT.
The same applies to openSUSE-11.4 and SLES10_SP4_BRANCH branches. If Mel doesn't see anything I would vote for dropping the patch from all supported branches.
That patch belongs to an SGI developer so there is a possibility that they have an RDMA driver or MPI accelerator that was doing direct writes to userspace after pinning the page with get_user_pages(). GPFS could also be doing weird things from kernel threads and pinning pages for IO a kernel thread context. For upstream, it's not currently a problem. The only in-tree user of get_user_pages I'm aware of is KSM calling get_user_pages (ok, it's not called directly, it's just very get_user_pages like) and it always passes in a valid mm from do_swap_page so it does not need this patch. I'd agree with Michal - drop this patch because even out-of-tree drivers should only be trying to grab the swap token from do_swap_page(). If they are doing something else, it's probably best we find out about it.
- - patches.suse/files-slab-rcu.patch
Nick's VFS black magic. The patch is not applied in openSUSE-11.4. Sorry, I cannot say anything about this patch.
Drop it unless there is a known specific use case it helps. There is now a whole host of other VFS black magic merged to mainline and it improves open/close performance in other ways. Slab-destroy-by-rcu means there is a variable amount of time spent freeing slab objects. Many users probably don't care, but realtime people have complained about variable latency when freeing slab objects before and this is the kind of thing that can surprise them.
- - patches.suse/mm-devzero-optimisation.patch [against SLES10, issue may not exist anymore]
Yes we can drop it from SLE11-SP1 and openSUSE-11.4 branches. The zero page has been reintroduced in 2.6.32. The main reason for the above patch was the page fault overhead (coming from allocation and zeroing) during copying from /dev/zero. Now that we have zero page again this is not a case anymore so we do not need any special /dev/zero hacks.
Sure.
- - patches.fixes/aggressive-zone-reclaim.patch [disabled since 2.6.36]
I assume that the patch has been reverted due to changes in the area, right?
It's not clear. I think it might have been dropped due to conflicts and there was no motivation to keep it updated.
My impression of the patch is that is highly workload specific.
Extremely so.
Especially decreasing ZONE_RECLAIM_PRIORITY to 0 is very tricky because it makes reclaim really aggressive. I think this part is highly controversial for upstream.
It would only make sense on a machine running threads that were tightly bound to their NUMA node which will probably only be tree on HPC configurations. For things like mail servers running on Nehalem with large NUMA distances, this patch could have very surprising results.
Nevertheless, I quite like the ZONE_RECLAIM_LOCKED part. Although, this can be really subtle because we might end up reclaiming too much if there is really heavy parallel load or multiple high order allocators.
Yes. A consequence of removing it is that a number of parallel allocator requests that happen at the same time dump all the memory of a node. Worse, they could start reclaiming each others memory in the node which would manifest as unexpected stalls at unpredictable times. This is true for normal reclaim of course but in __zone_reclaim it's potentially worse as it's focusing on clean pages.
I will wait with reverting for Mel but mm-devzero-optimisation.patch is one that can go away for sure.
Ditch it. It is likely to adversely affect common workloads that are heavily file based. -- Mel Gorman SUSE Labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Tue 10-05-11 10:40:37, Mel Gorman wrote:
On Fri, Apr 29, 2011 at 12:28:50PM +0200, Michal Hocko wrote:
On Thu 28-04-11 13:35:13, Jeff Mahoney wrote: [...]
Mel Gorman / Michal Hocko: - - patches.fixes/grab-swap-token-oops
There are still no in-kernel users of gup from kernel threads AFAICS. Besides that I think there is no issue in the current upstream because we do not get to handle_mm_fault (and grab_swap_token) path if there is no mm_struct. find_extend_vma will return NULL for (mm == NULL) and so we either go into gate_vma path (which is not handled by the patch and still can be an issue because of pgd_offset_gate) or fail with -EFAULT.
The same applies to openSUSE-11.4 and SLES10_SP4_BRANCH branches. If Mel doesn't see anything I would vote for dropping the patch from all supported branches.
That patch belongs to an SGI developer so there is a possibility that they have an RDMA driver or MPI accelerator that was doing direct writes to userspace after pinning the page with get_user_pages(). GPFS could also be doing weird things from kernel threads and pinning pages for IO a kernel thread context.
Then we should keep the patch. We shouldn't risk any "regression" even though they might be bugs in the external code. Thanks for the clarification I missed that 3rd party modules can really matter here. [...]
- - patches.suse/files-slab-rcu.patch
Nick's VFS black magic. The patch is not applied in openSUSE-11.4. Sorry, I cannot say anything about this patch.
Drop it unless there is a known specific use case it helps. There is now a whole host of other VFS black magic merged to mainline and it improves open/close performance in other ways. Slab-destroy-by-rcu means there is a variable amount of time spent freeing slab objects. Many users probably don't care, but realtime people have complained about variable latency when freeing slab objects before and this is the kind of thing that can surprise them.
Jack should have pinged Nick about this one so I would rather wait for what he comes with.
- - patches.suse/mm-devzero-optimisation.patch [against SLES10, issue may not exist anymore]
Yes we can drop it from SLE11-SP1 and openSUSE-11.4 branches. The zero page has been reintroduced in 2.6.32. The main reason for the above patch was the page fault overhead (coming from allocation and zeroing) during copying from /dev/zero. Now that we have zero page again this is not a case anymore so we do not need any special /dev/zero hacks.
Sure.
Removed from SLE11-SP1 (SP2 will get it automatically), openSUSE.11.3, openSUSE.11.4 and master branches.
- - patches.fixes/aggressive-zone-reclaim.patch [disabled since 2.6.36]
I assume that the patch has been reverted due to changes in the area, right?
It's not clear. I think it might have been dropped due to conflicts and there was no motivation to keep it updated.
My impression of the patch is that is highly workload specific.
Extremely so.
Especially decreasing ZONE_RECLAIM_PRIORITY to 0 is very tricky because it makes reclaim really aggressive. I think this part is highly controversial for upstream.
It would only make sense on a machine running threads that were tightly bound to their NUMA node which will probably only be tree on HPC configurations. For things like mail servers running on Nehalem with large NUMA distances, this patch could have very surprising results.
Nevertheless, I quite like the ZONE_RECLAIM_LOCKED part. Although, this can be really subtle because we might end up reclaiming too much if there is really heavy parallel load or multiple high order allocators.
Yes.
A consequence of removing it is that a number of parallel allocator requests that happen at the same time dump all the memory of a node. Worse, they could start reclaiming each others memory in the node which would manifest as unexpected stalls at unpredictable times. This is true for normal reclaim of course but in __zone_reclaim it's potentially worse as it's focusing on clean pages.
I will wait with reverting for Mel but mm-devzero-optimisation.patch is one that can go away for sure.
Ditch it. It is likely to adversely affect common workloads that are heavily file based.
OK. I will keep it for for SLE11-SP[12] because we had an L3 request for it and it fixed a real problem that our customer saw and nobody complained about massive zone reclaim so far. I will remove it from other branches (master, openSUSE.11.[34]). Thanks -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Dne Út 10. května 2011 14:27:43 Michal Hocko napsal(a):
On Tue 10-05-11 10:40:37, Mel Gorman wrote:
On Fri, Apr 29, 2011 at 12:28:50PM +0200, Michal Hocko wrote:
On Thu 28-04-11 13:35:13, Jeff Mahoney wrote: [...]
Mel Gorman / Michal Hocko: - - patches.fixes/grab-swap-token-oops
There are still no in-kernel users of gup from kernel threads AFAICS. Besides that I think there is no issue in the current upstream because we do not get to handle_mm_fault (and grab_swap_token) path if there is no mm_struct. find_extend_vma will return NULL for (mm == NULL) and so we either go into gate_vma path (which is not handled by the patch and still can be an issue because of pgd_offset_gate) or fail with -EFAULT.
The same applies to openSUSE-11.4 and SLES10_SP4_BRANCH branches. If Mel doesn't see anything I would vote for dropping the patch from all supported branches.
That patch belongs to an SGI developer so there is a possibility that they have an RDMA driver or MPI accelerator that was doing direct writes to userspace after pinning the page with get_user_pages(). GPFS could also be doing weird things from kernel threads and pinning pages for IO a kernel thread context.
Then we should keep the patch. We shouldn't risk any "regression" even though they might be bugs in the external code. Thanks for the clarification I missed that 3rd party modules can really matter here.
That's completely true for the SLE products, but can't we drop it from the master branch? Then the "regression" will be discovered by partners in early alpha or beta phases of the next SLE product, which is the right way to deal with such features, IMO. Petr Tesarik L3 International -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Tue 10-05-11 10:40:37, Mel Gorman wrote: [...]
- - patches.suse/files-slab-rcu.patch
Nick's VFS black magic. The patch is not applied in openSUSE-11.4. Sorry, I cannot say anything about this patch.
Drop it unless there is a known specific use case it helps. There is now a whole host of other VFS black magic merged to mainline and it improves open/close performance in other ways. Slab-destroy-by-rcu means there is a variable amount of time spent freeing slab objects. Many users probably don't care, but realtime people have complained about variable latency when freeing slab objects before and this is the kind of thing that can surprise them.
Jack should have pinged Nick about this one so I would rather wait for what he comes with. Yes, I've pinged him but he didn't reply so far. So I'd just drop the
On Tue 10-05-11 14:27:43, Michal Hocko wrote: patch. If Nick wants to pursue this further, he has the patch in his mailbox. And if he doesn't, we don't have a real need to do so... Honza -- Jan Kara <jack@suse.cz> SUSE Labs, CR -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Tue 10-05-11 17:02:15, Jan Kara wrote:
On Tue 10-05-11 10:40:37, Mel Gorman wrote: [...]
- - patches.suse/files-slab-rcu.patch
Nick's VFS black magic. The patch is not applied in openSUSE-11.4. Sorry, I cannot say anything about this patch.
Drop it unless there is a known specific use case it helps. There is now a whole host of other VFS black magic merged to mainline and it improves open/close performance in other ways. Slab-destroy-by-rcu means there is a variable amount of time spent freeing slab objects. Many users probably don't care, but realtime people have complained about variable latency when freeing slab objects before and this is the kind of thing that can surprise them.
Jack should have pinged Nick about this one so I would rather wait for what he comes with. Yes, I've pinged him but he didn't reply so far. So I'd just drop the
On Tue 10-05-11 14:27:43, Michal Hocko wrote: patch. If Nick wants to pursue this further, he has the patch in his mailbox. And if he doesn't, we don't have a real need to do so...
OK, dropped from master, openSUSE.11.[34] Thanks -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thu, Apr 28, 2011 at 01:35:13PM -0400, Jeff Mahoney wrote:
Tony Jones: - - patches.suse/kdump-dump_after_notifier.patch not my patch but dead; removed
- - patches.fixes/oprofile_bios_ctr.patch upstream in alt. form, should have removed it previously, sorry; removed
-- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
participants (20)
-
Alexander Graf -
Brandon Philips -
Bruno Friedmann -
Dr. Werner Fink -
Egbert Eich -
Greg KH -
Jan Kara -
Jeff Mahoney -
Jiri Benc -
Jiri Slaby -
Ludwig Nussel -
Marcus Meissner -
Mel Gorman -
Michal Hocko -
Petr Tesarik -
Rafael J. Wysocki -
Stefan Seyfried -
Suresh Jayaraman -
Takashi Iwai -
Tony Jones