kernel March 2010

kernel@lists.fedoraproject.org

15 participants
11 discussions

RFE: vhost net backport in fc13
by Michael S. Tsirkin 18 Apr '10

18 Apr '10

All, What is needed to backport vhost net accelerator to make it avaiable in fc13? The following patches from net-next (git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git) should apply to fedora kernel without changes, and are fairly non-intrusive: 05c2828c72c4eabf62376adfe27bd24797621f62 tun: export underlying socket 5da779c34ccff5e1e617892b6c8bd8260fb1f04c mm: export use_mm/unuse_mm to modules 3a4d5c94e959359ece6d6b55045c3f046677f55c vhost_net: a kernel-level virtio server This module is required for vhost net feature. Feature page here: https://fedoraproject.org/wiki/Features/VHostNet -- MST

2 2

enable CONFIG_INTEL_TXT
by Eric Paris 01 Apr '10

01 Apr '10

Long ago we were ask to enable CONFIG_INTEL_TXT in the fedora kernels by a large user, the US National Security Agency: http://lists.fedoraproject.org/pipermail/kernel/2009-October/002228.html At the time the objection to this configuration option was that the technology was all predicated on a closed source binary blob signed by Intel. In private discussions it was learned that there was no chance that the module would ever be open sourced and we learned that hardware is not capable of recognizing signatures of a module from other vendors (aka Fedora can't sign our own version.) However, in light of a recent public statement from IBM: http://lists.fedoraproject.org/pipermail/devel/2010-March/133089.html We see that at least one hardware vendor has been listening to our objections to closed source software and has agreed to re-architect how they implement their systems so that our users will not need to download and install any closed source proprietary software. They agreed to make any changes necessary to their BIOS (UEFI) to support this technology without the need for the separate closed source proprietary Intel signed blob. Red Hat has ask other hardware vendors to follow the admirable lead set by IBM if they have any interest in being supported by the open source community. At this point we know that we have hardware vendors, software vendors, and users all asking for the enablement of this technology. So the question become why should we enable CONFIG_INTEL_TXT and what do we get? What do we lose? By itself enabling TXT gets us nothing except a small chuck of dead code in the kernel. But it allows us and our customers to build new solutions with new security goals in mind which are not possible today. This config option allows a user to download new (open source) software (tboot) along with other third party software to verify the correctness of the BOOTED system. This allows us to build future solutions such as utilizing the TPM chip in many laptops to harden the disk encryption key. It can be used as root of trust for the verification of the software originally loaded on a machine before it is allowed network access (aka machines with a rootkit couldn't get on the network.) The technology can also be extended to provide usefulness to system integrity checkers like aide or IMA for tamper proof software integrity logging. These are all things which are impossible to do with today's kernels. We don't really lose anything except a bit of code in the kernel. Unless the user specifically installs tboot the kernel code will sit dormant. It has no implications on AMD processors. If the user does install tboot and their hardware supports this technology (like this future generation of IBM system X products mentioned above) they will get a root of trust which can be used to build other solutions. Some of those potential solutions will hopefully be available someday in Fedora if a user wishes to activate them (and we can overcome the management burden they will seemingly place upon the user), but we cannot get there without starting here. This is the beginning. It is the first step to allow users to use other open source software which will give them a root of trust. But remember the config options does nothing unless a user takes those very clear active steps. Are there any objections to enabling CONFIG_INTEL_TXT on x86_64? -Eric

8 30

ppc32 selinux mprotect diff.
by Dave Jones 31 Mar '10

31 Mar '10

We've carried this diff in Fedora for a few years now.. --- linux-2.6.26.noarch/security/selinux/hooks.c~ 2008-09-25 14:11:17.000000000 -0400 +++ linux-2.6.26.noarch/security/selinux/hooks.c 2008-09-25 14:12:17.000000000 -0400 @@ -3018,7 +3018,6 @@ static int file_map_prot_check(struct fi const struct cred *cred = current_cred(); int rc = 0; -#ifndef CONFIG_PPC32 if ((prot & PROT_EXEC) && (!file || (!shared && (prot & PROT_WRITE)))) { /* * We are making executable an anonymous mapping or a @@ -3029,7 +3028,6 @@ static int file_map_prot_check(struct fi if (rc) goto error; } -#endif if (file) { /* read access is always possible with a mapping */ @@ -3024,7 +3022,6 @@ static int selinux_file_mprotect(struct if (selinux_checkreqprot) prot = reqprot; -#ifndef CONFIG_PPC32 if ((prot & PROT_EXEC) && !(vma->vm_flags & VM_EXEC)) { rc = 0; if (vma->vm_start >= vma->vm_mm->start_brk && @@ -3049,7 +3046,6 @@ static int selinux_file_mprotect(struct if (rc) return rc; } -#endif return file_map_prot_check(vma->vm_file, prot, vma->vm_flags&VM_SHARED); } This needs a fixed toolchain, and a userspace rebuild to work. For these reasons, it's had difficulty getting upstream. Fedora has a new enough toolchain, and has been rebuilt, so we don't need the ifdefs. Other distros don't/haven't, and this patch would break them if pushed upstream. Could we do something like the (untested) diff below instead, which might be more palatable to upstream, allowing us to stop carrying it ? Dave diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig index bca1b74..83a9675 100644 --- a/security/selinux/Kconfig +++ b/security/selinux/Kconfig @@ -131,3 +131,10 @@ config SECURITY_SELINUX_POLICYDB_VERSION_MAX_VALUE installed under /etc/selinux/$SELINUXTYPE/policy, where SELINUXTYPE is defined in your /etc/selinux/config. +config SELINUX_NEW_ENOUGH_TOOLCHAIN + bool "SELinux mprotect checks" + default n if PPC32 + help + This option requires a modern toolchain (FIXME: Version?) + and a userspace rebuild to work. + diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 9a2ee84..e805df7 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -3009,7 +3009,7 @@ static int file_map_prot_check(struct file *file, unsigned long prot, int shared const struct cred *cred = current_cred(); int rc = 0; -#ifndef CONFIG_PPC32 +#ifdef CONFIG_SELINUX_NEW_ENOUGH_TOOLCHAIN if ((prot & PROT_EXEC) && (!file || (!shared && (prot & PROT_WRITE)))) { /* * We are making executable an anonymous mapping or a @@ -3081,7 +3081,7 @@ static int selinux_file_mprotect(struct vm_area_struct *vma, if (selinux_checkreqprot) prot = reqprot; -#ifndef CONFIG_PPC32 +#ifdef CONFIG_SELINUX_NEW_ENOUGH_TOOLCHAIN if ((prot & PROT_EXEC) && !(vma->vm_flags & VM_EXEC)) { int rc = 0; if (vma->vm_start >= vma->vm_mm->start_brk &&

2 3

[PATCH F-13 2.6.33 1/2] iwlwifi: reset card during probe
by Stanislaw Gruszka 29 Mar '10

29 Mar '10

To ensure that card is in a sane state during probe we add a reset call. This change was prompted by users of kdump who was not able to bring up the wireless driver in the kdump kernel. The problem here was that the primary kernel, which is not running at the time, left the wireless card up and running. When the kdump kernel starts it is thus possible to immediately receive interrupts from firmware after registering interrupt, but without being ready to deal with interrupts from firmware yet. Reported-by: Stanislaw Gruszka <sgruszka(a)redhat.com> Signed-off-by: Reinette Chatre <reinette.chatre(a)intel.com> Signed-off-by: Stanislaw Gruszka <sgruszka(a)redhat.com> --- drivers/net/wireless/iwlwifi/iwl-agn.c | 8 ++++++++ drivers/net/wireless/iwlwifi/iwl3945-base.c | 7 +++++++ 2 files changed, 15 insertions(+), 0 deletions(-) diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c index 1c9866d..33a7803 100644 --- a/drivers/net/wireless/iwlwifi/iwl-agn.c +++ b/drivers/net/wireless/iwlwifi/iwl-agn.c @@ -3365,6 +3365,14 @@ static int iwl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) */ spin_lock_init(&priv->reg_lock); spin_lock_init(&priv->lock); + + /* + * stop and reset the on-board processor just in case it is in a + * strange state ... like being left stranded by a primary kernel + * and this is now the kdump kernel trying to start up + */ + iwl_write32(priv, CSR_RESET, CSR_RESET_REG_FLAG_NEVO_RESET); + iwl_hw_detect(priv); IWL_INFO(priv, "Detected Intel Wireless WiFi Link %s REV=0x%X\n", priv->cfg->name, priv->hw_rev); diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c index f8e4e4b..f0c428e 100644 --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c @@ -4022,6 +4022,13 @@ static int iwl3945_pci_probe(struct pci_dev *pdev, const struct pci_device_id *e spin_lock_init(&priv->reg_lock); spin_lock_init(&priv->lock); + /* + * stop and reset the on-board processor just in case it is in a + * strange state ... like being left stranded by a primary kernel + * and this is now the kdump kernel trying to start up + */ + iwl_write32(priv, CSR_RESET, CSR_RESET_REG_FLAG_NEVO_RESET); + /*********************** * 4. Read EEPROM * ********************/ -- 1.6.2.5

1 1

[PATCH 1/3] iwlwifi: fix nfreed--
by Stanislaw Gruszka 29 Mar '10

29 Mar '10

During backporting of a120e912eb51e347f36c71b60a1d13af74d30e83 ("iwlwifi: sanity check before counting number of tfds can be free ") we forget one hunk, what make lot of messages "free more than tfds_in_queue" mess up dmesg. Signed-off-by: Stanislaw Gruszka <sgruszka(a)redhat.com> --- drivers/net/wireless/iwlwifi/iwl-tx.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/net/wireless/iwlwifi/iwl-tx.c b/drivers/net/wireless/iwlwifi/iwl-tx.c index f449f06..cf5ac00 100644 --- a/drivers/net/wireless/iwlwifi/iwl-tx.c +++ b/drivers/net/wireless/iwlwifi/iwl-tx.c @@ -1096,7 +1096,6 @@ int iwl_tx_queue_reclaim(struct iwl_priv *priv, int txq_id, int index) priv->cfg->ops->lib->txq_inval_byte_cnt_tbl(priv, txq); priv->cfg->ops->lib->txq_free_tfd(priv, txq); - nfreed++; } return nfreed; } -- 1.6.2.5

1 6

[PATCH] iwlwifi: fix nfreed--
by y＠redhat.com 29 Mar '10

29 Mar '10

2 3

PROBLEM: crash on halt with 2.6.34-0.16.rc2.git0.fc14.x86_64
by Jon Masters 26 Mar '10

26 Mar '10

No analysis yet. Just passing this along. Jon. --- begin oops log --- Halting system... BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: [<ffffffff81017e7b>] amd_pmu_cpu_offline+0x38/0x6b PGD 741d5067 PUD 77715067 PMD 0 Oops: 0000 [#1] SMP last sysfs file: /sys/devices/virtual/block/dm-1/dm/name CPU 0 Modules linked in: sit tunnel4 tun sunrpc powernow_k8 freq_table bridge stp llc nf_conntrack_netbios_ns ip6t_REJECT nf_conntrack_ipv6 ipv6 kvm_amd kvm uinput snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm ppdev parport_pc parport r8169 snd_timer mii snd edac_core soundcore microcode serio_raw snd_page_alloc edac_mce_amd k8temp i2c_nforce2 hwmon ata_generic pata_acpi firewire_ohci firewire_core crc_itu_t floppy sata_nv pata_amd nouveau ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: cpufreq_ondemand] Pid: 2792, comm: halt Not tainted 2.6.34-0.16.rc2.git0.fc14.x86_64 #1 www.abit.com.tw /System Product Name RIP: 0010:[<ffffffff81017e7b>] [<ffffffff81017e7b>] amd_pmu_cpu_offline +0x38/0x6b RSP: 0018:ffff880024289ca8 EFLAGS: 00010292 RAX: ffff880024124900 RBX: ffff88000520cc70 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff81017e74 RDI: ffffffff81488830 RBP: ffff880024289cb8 R08: 0000000000000002 R09: 0000000000000000 R10: 0000000000000046 R11: ffffe8ffffc01980 R12: 00000000fffffffd R13: ffffffff81ac70c0 R14: 0000000000000001 R15: 0000000000000000 FS: 00007f7ec4f8a700(0000) GS:ffff880005000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000004 CR3: 0000000077381000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process halt (pid: 2792, threadinfo ffff880024288000, task ffff880024124900) Stack: ffff880024289cb8 0000000000000017 ffff880024289cc8 ffffffff8147fbb0 <0> ffff880024289d18 ffffffff8148dede 0000000000000001 ffffffffa0294020 <0> ffff880024289d28 0000000000000001 ffffffff81ba1de0 0000000000000010 Call Trace: [<ffffffff8147fbb0>] x86_pmu_notifier+0x52/0x59 [<ffffffff8148dede>] notifier_call_chain+0x68/0x9c [<ffffffff81070b21>] raw_notifier_call_chain+0x14/0x16 [<ffffffff81471efc>] _cpu_down+0x1bb/0x2bf [<ffffffff81051d71>] disable_nonboot_cpus+0x7a/0x112 [<ffffffff8106593e>] kernel_power_off+0x26/0x40 [<ffffffff81065c02>] sys_reboot+0x126/0x1b2 [<ffffffff811316bf>] ? __d_free+0x56/0x5a [<ffffffff811316fa>] ? d_free+0x37/0x50 [<ffffffff81138ad0>] ? mntput_no_expire+0x2c/0xfd [<ffffffff81122ab7>] ? __fput+0x1d0/0x1df [<ffffffff8111f7b8>] ? sys_close+0x32/0x10f [<ffffffff81129fb7>] ? path_put+0x22/0x27 [<ffffffff810a875a>] ? audit_syscall_entry+0x11e/0x14a [<ffffffff81489c15>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b Code: 76 b8 00 01 76 54 48 63 ff 48 c7 c3 70 cc 00 00 48 03 1c fd 40 fa b9 81 48 c7 c7 40 b5 a4 81 e8 f9 1f 47 00 48 8b 93 28 07 00 00 <8b> 42 04 ff c8 85 c0 89 42 04 75 0c 48 8b bb 28 07 00 00 e8 b5 RIP [<ffffffff81017e7b>] amd_pmu_cpu_offline+0x38/0x6b RSP <ffff880024289ca8> CR2: 0000000000000004 ---[ end trace 7d3f5b5a80d53cb0 ]--- init: rc main process (2792) killed by KILL signal

1 0

Changing default module options
by Stanislaw Gruszka 25 Mar '10

25 Mar '10

Hi I would like to change default iwlagn/iwl3945 options (swcrypto50=1 swcrypto=1) to solve two nasty iwlwifi firmware bugs. What is preferred way to do this by changing /etc/modprobe.d/ or by patching kernel? Stanislaw

4 8

Re: rpms/kernel/devel linux-2.6-cantiga-iommu-gfx.patch, 1.1, 1.2 kernel.spec, 1.1947, 1.1948
by Kyle McMartin 23 Mar '10

23 Mar '10

On Fri, Mar 19, 2010 at 12:37:35PM +0000, David Woodhouse wrote: > Author: dwmw2 > > Update of /cvs/pkgs/rpms/kernel/devel > In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv5720 > > Modified Files: > kernel.spec > Added Files: > linux-2.6-cantiga-iommu-gfx.patch > Log Message: > Fix #538163 again > You know, if you'd put the patch upstream, you wouldn't have to do this. It's not like this is a Fedora specific bug. regards, Kyle

2 1

[Fwd: opendir() on a file???]
by Jon Masters 09 Mar '10

09 Mar '10

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel March 2010