kernel January 2012

kernel@lists.fedoraproject.org

16 participants
14 discussions

fedora 14 kernel performance with ip forwarding workload
by Jesse Brandeburg 05 Jun '15

05 Jun '15

The other day I was running the stock fedora kernel on my ip forwarding setup, to see what the performance was, and the performance wasn't very good. system is S5520HC dual socket 2.93GHz Xeon 5570 (Nehalem) with 3 quad port 82580 adapters (12 ports). Traffic is bidirectional 64 byte packets being forwarded and received on each port, basically port to port routing. I am only using 12 flows currently. The driver is igb, and I am using an affinity script that lines up each pair of ports that are forwarding traffic into optimal configurations for cache locality. I am also disabling remote_node_defrag_ratio to stop cross node traffic. With the fedora default kernel from F14 it appears that CONFIG_NETFILTER=y means that I cannot unload all of netfilter even if I stop iptables service. perf showed netfilter being prominent, and removing it gives me much higher throughput. Is there a reason CONFIG_NETFILTER=y ? Isn't it a good thing to be able to disable netfilter if you want to? Jesse

5 9

[PATCHSET] utrace for 3.1 kernel
by Oleg Nesterov 08 Feb '12

08 Feb '12

Hello. utrace patches for 3.1 kernel. Untested, will try to do some tests tomorrow. I do not want to spam you all and the lists, please look at git://git.kernel.org/pub/scm/linux/kernel/git/oleg/misc.git utrace-3.1 Oleg Nesterov (29): utrace: add utrace_init_task/utrace_free_task calls tracehooks: add utrace hooks tracehooks: reintroduce tracehook_consider_fatal_signal() add utrace hooks into sig_ignored() and recalc_sigpending() restore the EXEC/EXIT/CLONE utrace hooks utrace: utrace_report_death() can use task_utrace_struct() restore the DEATH/REAP utrace hooks utrace: remove jobctl bits ptrace: take ->siglock around s/TRACED/RUNNING/ introduce wake_up_quiescent() introduce ptrace_signal_wake_up() wait_task_inactive: treat task->state and match_state as bitmasks introduce TASK_UTRACED state utrace: use TASK_UTRACED instead of TASK_TRACED reintroduce tracehook_finish_jctl() as utrace_end_stop() teach wake_up_quiescent() to do "selective" wake_up ptrace_stop: do not assume the task is running after wake_up_quiescent() get_signal_to_deliver: restore/restructure utrace/ptrace signal reporting utrace_get_signal: s/JOBCTL_STOP_PENDING/JOBCTL_PENDING_MASK/ introduce ptrace_set_syscall_trace() introduce PT_SYSCALL_TRACE flag utrace: don't clear TIF_SYSCALL_TRACE if it is needed by ptrace introduce task_utrace_lock/task_utrace_unlock teach ptrace_set_syscall_trace() to play well with utrace introduce PT_SINGLE_STEP and PT_SINGLE_BLOCK utrace: finish_resume_report: don't do user_xxx_step() if ptrace_wants_step() ptrace: shift user_*_step() from ptrace_resume() to ptrace_stop() ptrace_disable: no need to disable stepping ptrace_report_syscall: check TIF_SYSCALL_EMU Roland McGrath (1): utrace core Documentation/DocBook/Makefile | 2 +- Documentation/DocBook/utrace.tmpl | 589 +++++++++ arch/s390/kernel/traps.c | 4 +- arch/x86/kernel/ptrace.c | 1 - fs/exec.c | 5 +- fs/proc/array.c | 14 +- include/linux/ptrace.h | 7 + include/linux/sched.h | 25 +- include/linux/signal.h | 2 + include/linux/tracehook.h | 53 +- include/linux/utrace.h | 773 ++++++++++++ init/Kconfig | 9 + kernel/Makefile | 1 + kernel/exit.c | 5 + kernel/fork.c | 9 + kernel/ptrace.c | 57 +- kernel/sched.c | 2 +- kernel/signal.c | 97 ++- kernel/utrace.c | 2461 +++++++++++++++++++++++++++++++++++++ 19 files changed, 4062 insertions(+), 54 deletions(-) create mode 100644 Documentation/DocBook/utrace.tmpl create mode 100644 include/linux/utrace.h create mode 100644 kernel/utrace.c

4 39

Fedora 14 2.6.35.14-106.fc14.x86_64 High Load
by Tom Clark 31 Jan '12

31 Jan '12

Hi, I've noticed that our server has a high CPU load. Our server is a mail server setup with Fedora 14 it has a dual-core AMD Opteron, 8GB of RAM and twin 1TB SATA drives in software Raid 1. We originally had a CPU load greater than 20, which we believed to be caused by this bug https://bugzilla.redhat.com/show_bug.cgi?id=650934 We upgraded the kernel to the latest version (kernel-2.6.35.14-106.fc14.x86_64) using 'yum'. Although the CPU load has now dropped to below 3, it still averages at about 2.6. According to a 'top' there are no processes using a high percentage of CPU and the CPU is mostly on idle. After reading the bug report I've installed 'powertop'. This is showing the following: Top causes for wakeups: 64.5% (2418.3) [kernel scheduler] Load balancing tick 23.8% (890.8) [extra timer interrupt] Any ideas what is causing this and how to fix the issue? Please let me know if you need any extra information!! Thanks, Tom

2 1

Rawhide 3.3-rc1 rebase
by Josh Boyer 30 Jan '12

30 Jan '12

Hi All, I've rebased rawhide to the 3.3-rc1 release this afternoon. Overall, not too bad. Aside from a kmemleak issue that prevented booted (patch provided by Catalin already) and a lockdep spew from radeon it booted fine on my machine. There were a few patches we hit that I have questions on. If you're in CC, keep reading below. Matthew, we're carrying revert-efi-rtclock.patch which reverts upstream commit "x86: Serialize EFI time accesses on rtc_lock (ef68c8f87ed1)". However, upstream doesn't have that reverted and I don't see anything in particular that discusses a problem with it. Should we still be carrying this (I think yes) and why didn't upstream revert? Also for Matthew, I left CONFIG_EFI_STUB turned off. It wasn't clear to me if this would make a kernel that would only boot as an EFI executable or if it would do that while still being general purpose. I'll look into this more, but I thought you should weigh in before we switch that on anyway. Dave, block-stray-block-put-after-teardown.patch was added for a supposed problem in the elevator stuff. I've left it commented out of the spec right now because upstream removed the ops member from the elevator_queue struct entirely with commit 22f746e235a5cb. Given they directly access e->type.ops now, I'm not sure this is needed any longer? Dennis, Jon, The arm configs are a WAG. Also, arm-omap-dt-compat.patch didn't apply cleanly so I dropped the application but left it in the tree. It would be really helpful if people were building/working with rawhide first, then backporting to f15 or whatever ARM is using so that we aren't left taking random guesses at what to do. John L, I disabled with_backports like we discussed last week. I'll let you do your thing with compat-wireless when you find time. Oleg, the utrace patch doesn't apply to 3.3 any longer. I've left it unapplied until someone gets a chance to rebase it. For anyone else that might know... the GMA500 driver "moved" from staging to drivers/video/drm/. I say "moved" because the DRM_PSB thing is still sitting in staging. I'll look into this more Monday, but if anyone knows offhand why we now have 2 drivers and which we should enable, please do speak up. josh

4 10

RFC: Repos with vanilla kernel packages
by Thorsten Leemhuis 24 Jan '12

24 Jan '12

Hi! I know a lot about packaging from my work on Fedora in its early years and quite closely watch the kernel for my day job these days. So I many moons ago thought "why not combine the two interests and maintain a small special interest repository that provides vanilla kernel packages for Fedora", but never realized that idea. But I finally got things running now and set up such a repo with Linux 3.2.1. Find details on https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories Repo: http://repos.fedorapeople.org/repos/thl/kernel-vanilla-stable/ Git: http://fedorapeople.org/gitweb?p=thl/public_git/kernel.git;a=summary Patch to kernel.spec from F16 http://fedorapeople.org/gitweb?p=thl/public_git/kernel.git;a=commitdiff;h=7… I included the source for above wiki page and the patch kernel.spec below. I hope that makes yelling in my direction ^w^w^w^w commenting on it easier, as I suppose some people will not like the idea as a whole ^w^w^w^w^w some of the decisions I made when adjusting the spec file for my purposes. if that's the case please let me know, as I do not plan to mention the effort anywhere else over the next few days; that way I should be able to adjust details if there are good reasons to do so, before to many people get aware of those repos. Note, the next step I plan is to set up a second repo with packages that have the latest mainline development kernels (3.3-rc). But I thought I collect options on the current state of things first before moving on. CU knurd Text from the wiki page: > {{admon/warning|This is a draft document that describes a package > repository that is neither announced not ready for public > consumption, as some of the details might change during the > boot-up-phase the repositories are in at the moment. And this page > definitely needs someone that proof reads it…}} > > = kernel-vanilla packages for Fedora = > > == Overview == > > This page contains information about a > [http://repos.fedorapeople.org/repos/thl/ set of package > repositories] on fedorapeople.org that contain RPMs of vanilla > kernels built for Fedora. Vanilla in this scope means "unmodified", > hence these packages do not contain any of those enhancements the > Fedora developers integrate into the kernel packages that Fedora > normally contains. > > Currently there is only one repository: > > * > [http://repos.fedorapeople.org/repos/thl/kernel-vanilla-stable/fedora-16/ > kernel-vanilla-stable for F16] > ([http://repos.fedorapeople.org/repos/thl/kernel-vanilla-stable/ repo > file]) -- Latest kernel from the stable series (3.x.y) > > There will be one more soon: > > * kernel-vanilla-mainline for F16 -- latest mainline development > kernel (aka 3.x-rc series) > > There is the rough idea for more: > > * kernel-vanilla-mainline for F17 -- latest mainline development > kernel (aka 3.x-rc series) * kernel-vanilla-stable-testing for F16 -- > 3.x.y-rc kernels could go here; might also be a good place to put new > releases from the mainline (3.x) or stable series (3.x.y) here for a > short while before moving them to kernel-vanilla-stable > > To use those kernels download the repo file and put it in > /etc/yum.repos.d/ and install the kernel you want with yum; the > packages are signed with > [http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD7927A2FCC9DBCAB > this key]. > > Please note a few important things: > > * none of the developers that maintain the Fedora kernel is involved > in this effort * most systems work better and are run in a more > secure manner with the official Fedora kernels * the usage > instructions are brief on purpose; if you don't understand them, then > you likely should not use these packages > > For more information see the FAQ. > > == FAQ == > > === For users === > > ==== Who is behind this effort? Can we trust the people behind it? > ==== > > Right now the kernel-vanilla repositories are maintained by > [[user:thl|Thorsten Leemhuis (aka "knurd")]] only. Hopefully a few > other people join to help, that's why part of this text is written as > if a team is keeping care of the repositories. > > You have to decide yourself if you can trust the packages from these > repositories. If it is any help: Some of those that use or contribute > to Fedora since a while will know that Thorsten has quite a history > of Fedora contributions, even if he was not that much active in the > past two years. You can assume he has no interest in ruin his > reputation quickly by providing crap in these repositories. On the > other hand you should know that Thorsten started these repositories > to learn more about the kernel and kernel development; so expect > he'll make some mistakes along the way. And the vanilla kernels have > some known downsides (see below) > > ==== What's the goal? ==== > > The main ideas is to help upstream development, which in the end will > be of benefit for Fedora as well. With the packages from the mainline > repositories it for example is quite easy to test kernels that are > still under development and report bugs early. The kernels from the > stable repositories on the other hand make it easy to check if a bug > that happens with a kernel from Fedora is specific to it or also > present in the newest vanilla kernel; if that is the case users can > directly work with upstream on solutions for the problem and don't > have to go through the overworked and quite busy developers that > maintain the kernel packages in Fedora. > > ==== Are the kernels from the kernel-vanilla repositories as good as > those Fedora provides? ==== > > No. There are several reasons for why not; the most important ones: > > * the developers that take care of the kernel package in Fedora are > far more experienced in packaging kernels and kernel development than > those that take care of the kernel-vanilla repositories * the kernels > that get used in Fedora or released as proper update get a lot of > testing; the kernels from the kernel-vanilla repositories get nearly > no testing * some of the kernel-vanilla repositories contain kernels > that are still under heavy development and sometimes are known to > have serious bugs * the official Fedora kernels sometimes contain > changes that fix security problems before they get upstream > > But the non-development kernels found in the kernel-vanilla > repositories should work fine for a lot of situations and often be > round about as good as a self-compiled kernel. > > ==== Are the kernels safe to use? ==== > > Depends on your definition of "safe". > > The Linux kernel is a complex piece of software which contains bugs. > Those can lead to data loss or in very rare situations even lead to > hardware defects. Those bugs might only show up under specific > circumstances -- for example when a specific mix of hardware is used > with a specific kernel version that was built with a specific > configuration. It might be unlikely that such a bug is triggered by > one of the non-development kernels from the kernel-vanilla > repositories, but it's definitely possible. Self compiled kernels > bear the same risk; chances of hitting serious bugs are lower for > kernels that have undergone widespread testing already. > > In other words: The kernels from the kernel-vanilla repositories will > work just fine for most people. But use them on your own risk and > have backups handy, as there is a small risk those kernels might > damage your data or your system. > > ==== Should everything work with those kernels that works with the > official Fedora kernels? ==== > > No. Vanilla kernels are not that different from the kernels Fedora > provides, but the latter include a few enhancements. Each of them is > there for a good reason. > > When this text was written Fedora for example included utrace in > their kernels to support userspace tracing with systemtap; that won't > work with the kernels from the kernel-vanilla repositories. The > kernels from Fedora sometimes include fresher drivers which some > systems will require to work properly. And sometimes there are > inter-dependencies between drivers in kernel and userland. The > nouveau driver for graphics hardware from Nvidia is one such driver, > as it has no stable API yet; that's why the DRM/KMS driver in the > kernel is marked as "staging". The Mesa 3D or X.org drivers included > in a particular Fedora release therefore might depend on the exact > nouveau DRM/KMS driver which is part of the kernels Fedora ships for > this release; thus the nouveau drivers for Mesa 3D and X.org that are > part of a certain Fedora release might not work properly with kernels > found in the kernel-vanilla repositories, as the latter might contain > an older or newer nouveau DRM/KMS driver which are incompatible. > > The non-development kernels found in the kernel-vanilla repositories > therefore should work on a lot of systems, but on some systems they > will be worse than the kernels Fedora provides. > > ==== Will this repository also ship updates userland components like > drivers or udev that match the kernels in the repositories? ==== > > No, as there should be no need to, as the interfaces between the > kernel and userland software should never change in an incompatible > way; Linus Torvalds makes this pretty clear every now and then. > > That is the long story short. There are a lot of situations where the > world is more complicated: > > * above mentioned rule does not apply to staging drivers, so > situations might arise where the vanilla kernels are not usable for > people that need staging drivers for their system. Apart from the > nouveau drivers that shouldn't bother to many people; and time will > tell how bad the situation is for nouveau. * Fedora sometimes might > contains software that depends on bits that are not upstream > > And even with this rule sometimes a new mainline kernel versions > brings changes that require updates userland software. Three > examples: > > * the version number jump from 2.6.39 to 3.0 confused some software * > in rare cases fixing security problems was only possible my changing > the interfaces in an incompatible way * sometimes nobody notices > early enough that interfaces have changed > > It remains to be seen how often we hit such issues and how bad they > are; how we deal with them will need to get discussed on a case by > case basis. In some cases we might have to other solution then to add > new versions of other software to the repositories. But the plan is > to avoid this. > > ==== Do you plan to provide packages for "linux-next" or "linux-rt" > as well? ==== > > For now: No. I know there is some interest in packages for them, but > maintaining those will consume a lot of time regularly and we have > not enough resources to do it properly right now. But if you want to > step up and help, [[user:thl|get in contact]]. > > ==== Do you plan to provide vanilla kernels for RHEL and derivatives > like CentOS and SL? ==== > > Sounds like a good addition. But it will result in additional work, > too; and we currently have no one that would regularly run such > kernels. So for now we won't get our feet wet in that area. But if > you want to step up and help, [[User:thl|get in contact]]. > > ==== Do you plan to provide packages for longterm kernels ==== > > Unlikely. Mail goal of the kernel-vanilla repositories is to help > upstream kernel development; but longterm kernels are a dead end and > quite far away from mainline development, so they would not fit that > well. But it might make sense for RHEL and derivatives, if those will > ever be supported. > > ==== What configuration do those kernels use? ==== > > Basically the same configuration the Fedora kernels use. Maybe a few > staging drivers might get turned on to help their development, but > apart from it the plan is to stick closely to what Fedora does. > > ==== Why don't you put these kernels in Fedoras main repositories > ==== > > I tend to think it's not a good idea, as that would make them more > "official" and people might simply use those packages without knowing > what their downsides are. > > That's the long story rough and short. And sure, there are reasons > why having vanilla kernels in the main repositories make sense. Feel > free to start a discussion on > [https://admin.fedoraproject.org/mailman/listinfo/devel Fedoras devel > mailing list], we'll watch and might jump in. > > Putting the kernels in a well know 3rd party add-on repository for > Fedora might make sense, but some of the problems would be similar; > and there are others problems,as then users might ask to build add-on > modules for those kernels, too. In other words: Would need discussion > and careful evaluation. > > ==== Are those kernels really unpatched? ==== > > No, they contain a handful of very few changes that are needed for > packaging. > > ==== How up2date will those repositories be? ==== > > Time will tell, but we do the work in our spare time. Sometimes the > day job and this strange thing called "real life" leave not much time > to work on these kernels, so there will be a lag. > > === For contributors and developers === > > ==== Can you please include this patch? ==== > > No. Get your patch merged upstream, then the change you are > interested in will automatically show up in these packages (and in > Fedora, too) > > ==== Is there a Git tree somewhere? ==== > > [http://fedorapeople.org/gitweb?p=thl/public_git/kernel.git;a=summary > Sure]. > > Let us know if we should do modifications to allow others to > contribute to or benefit from this git tree better. > > ==== What Fedora versions will be supported ==== > > The plan is to support the most recent Fedora version for the stable > and mainline repositories. The latter will also be provides for the > distribution that is currently under development (rawhide on the > first half of a devel cycle iteration or the alpha/beta/rcs in the > second half) > > ==== Why are there no debug kernels and not even debuginfo packages > ==== > > The space on repos.fedoraprople.org is limited, hence limiting the > number of kernels we can provide. The debuginfo packages are also > quite big, which makes them hard to handle. Hopefully in the short or > medium timeframe solutions can be found to provide these packages. > > ==== Why don't you commit your changes to Fedora's kernel git repo on > pkgs.fedoraproject.org? ==== > > Maybe that would make sense. But it bears the risk that a commit is > done to a wrong branch and disturbs the work of the Fedora kernels > maintainer. Further: Not all of those that contribute to Fedora can > commit there. That's similar with the fedorapeople git repository, > but the docs indicate others can be given access with the help of > ACLs. > > But whatever: Git is made for distributed development and it's likely > not a big deal where the git repo lives. > > ==== Can I help ==== > > Of course. [[user:thl|Talk to Thorsten]]; best if you come with some > ideas what you can and want to do. > > ==== Do you plan to work together with those that take care of the > kernel packages in Fedora? ==== > > Definitely. But it remains to be seen how it looks like in practice. > > > ==== Please stop providing alternative kernel packages, they take > attention away from the kernels Fedora provide and thus harm Fedora! > ==== > > That's a valid concern, but I think the benefits outweigh the > downsides. > > That again is the long story short. Just to get a little bit deeper > into it: Similar arguments could be used to argue that Fedora should > stop shipping patched kernels, as those take attention away from the > upstream kernel. Up to a point such an argument is valid, too, but > there are good reasons why Fedora patches its kernels. > > Maybe in the long term Fedora can ship vanilla kernels as regular > kernel. That would be best for all, but a goal that is would take > quite some effort to reach. Might be worth start a discussion on > [https://admin.fedoraproject.org/mailman/listinfo/devel Fedoras devel > mailing list] how to get closer to that goal. > > ==== Why did you drop the "-vanilla" postfix that normally gets added > to the "name" macro when you build a vanilla kernel RPM locally? > ==== > > I've thought about dropping or leaving it for a while, as both > schemes have various benefits and downsides. In the end I went for > dropping it due to reasons like this: > > * nearly every other repository in Fedoraland that ships variants of > a packages that is included in Fedora does not change the name * the > postfix breaks things like "fedpkg srpm" on the git checkout * > external solutions that heavily depend on the naming scheme fedora > used (like the kmod stuff used in some external repositories) should > just work * yum would not recognize kernel packages with a "-vanilla" > postfix as "installonly" and thus would perform a regular update for > vanilla packages instead of installing them parallel to the current > one Patch > --- a/kernel.spec > +++ b/kernel.spec > @@ -23,7 +23,7 @@ Summary: The Linux kernel > # > # (Uncomment the '#' and both spaces below to set the buildid.) > # > -# % define buildid .local > +%define buildid .vanilla.knurd > ################################################################### > > # The buildid can also be specified on the rpmbuild command line > @@ -109,7 +109,7 @@ Summary: The Linux kernel > # kernel-PAE (only valid for i686) > %define with_pae %{?_without_pae: 0} %{?!_without_pae: 1} > # kernel-debug > -%define with_debug %{?_without_debug: 0} %{?!_without_debug: 1} > +%define with_debug %{?_with_debug: 1} %{?!_with_debug: 0} > # kernel-doc > %define with_doc %{?_without_doc: 0} %{?!_without_doc: 1} > # kernel-headers > @@ -119,7 +119,7 @@ Summary: The Linux kernel > # tools > %define with_tools %{?_without_tools: 0} %{?!_without_tools: 1} > # kernel-debuginfo > -%define with_debuginfo %{?_without_debuginfo: 0} %{?!_without_debuginfo: 1} > +%define with_debuginfo %{?_with_debuginfo: 1} %{?!_with_debuginfo: 0} > # kernel-bootwrapper (for creating zImages from kernel + initrd) > %define with_bootwrapper %{?_without_bootwrapper: 0} %{?!_without_bootwrapper: 1} > # Want to build a the vsdo directories installed > @@ -164,7 +164,7 @@ Summary: The Linux kernel > %define with_sparse %{?_with_sparse: 1} %{?!_with_sparse: 0} > > # Include driver backports (e.g. compat-wireless) in the kernel build. > -%define with_backports %{?_without_backports: 0} %{?!_without_backports: 1} > +%define with_backports %{?_with_backports: 1} %{?!_with_backports: 0} > > # Set debugbuildsenabled to 1 for production (build separate debug kernels) > # and 0 for rawhide (all kernels are debug kernels). > @@ -234,7 +234,7 @@ Summary: The Linux kernel > > %if %{nopatches} > %define with_bootwrapper 0 > -%define variant -vanilla > +#define variant -vanilla > %else > %define variant_fedora -fedora > %endif > @@ -2274,6 +2274,12 @@ fi > # and build. > > %changelog > +* Fri Jan 20 2012 Thorsten Leemhuis <fedora(a)leemhuis.info> > +- build vanilla with "buildid .vanilla.knurd" and without debug > +- disable compat-wireless > +- disable debuginfo creation, to big to handle for me right now > +- do not set the variant macro as that adds "-vanilla" to %%Name > + > * Fri Jan 20 2012 Dave Jones <davej(a)redhat.com> > - net: reintroduce missing rcu_assign_pointer() calls >

2 2

f16 3.2.1 rebase.
by Dave Jones 20 Jan '12

20 Jan '12

First build of a rebased f16 kernel just finished. Brave souls can grab the rpms from http://koji.fedoraproject.org/koji/buildinfo?buildID=294396 If all goes to plan, this should be pushed out as an update next week. Once that goes out, I'll start on a similar update for f15. Dave

2 1

[PATCH] mac80211: fix work removal on deauth request
by Stanislaw Gruszka 20 Jan '12

20 Jan '12

From: Johannes Berg <johannes.berg(a)intel.com> When deauth is requested while an auth or assoc work item is in progress, we currently delete it without regard for any state it might need to clean up. Fix it by cleaning up for those items. In the case Pontus found, the problem manifested itself as such: authenticate with 00:23:69:aa:dd:7b (try 1) authenticated failed to insert Dummy STA entry for the AP (error -17) deauthenticating from 00:23:69:aa:dd:7b by local choice (reason=2) It could also happen differently if the driver uses the tx_sync callback. We can't just call the ->done() method of the work items because that will lock up due to the locking in cfg80211. This fix isn't very clean, but that seems acceptable since I have patches pending to remove this code completely. Reported-by: Pontus Fuchs <pontus.fuchs(a)gmail.com> Tested-by: Pontus Fuchs <pontus.fuchs(a)gmail.com> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> --- Johannes pointed me on IRC that we should apply this patch, it fix problem on http://forums.fedoraforum.org/showthread.php?t=275216 We can also wait until it lend in stable ... net/mac80211/mlme.c | 38 +++++++++++++++++++++++++++----------- 1 files changed, 27 insertions(+), 11 deletions(-) diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index b1b1bb3..9da8626 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -2719,7 +2719,6 @@ int ieee80211_mgd_deauth(struct ieee80211_sub_if_data *sdata, { struct ieee80211_local *local = sdata->local; struct ieee80211_if_managed *ifmgd = &sdata->u.mgd; - struct ieee80211_work *wk; u8 bssid[ETH_ALEN]; bool assoc_bss = false; @@ -2732,30 +2731,47 @@ int ieee80211_mgd_deauth(struct ieee80211_sub_if_data *sdata, assoc_bss = true; } else { bool not_auth_yet = false; + struct ieee80211_work *tmp, *wk = NULL; mutex_unlock(&ifmgd->mtx); mutex_lock(&local->mtx); - list_for_each_entry(wk, &local->work_list, list) { - if (wk->sdata != sdata) + list_for_each_entry(tmp, &local->work_list, list) { + if (tmp->sdata != sdata) continue; - if (wk->type != IEEE80211_WORK_DIRECT_PROBE && - wk->type != IEEE80211_WORK_AUTH && - wk->type != IEEE80211_WORK_ASSOC && - wk->type != IEEE80211_WORK_ASSOC_BEACON_WAIT) + if (tmp->type != IEEE80211_WORK_DIRECT_PROBE && + tmp->type != IEEE80211_WORK_AUTH && + tmp->type != IEEE80211_WORK_ASSOC && + tmp->type != IEEE80211_WORK_ASSOC_BEACON_WAIT) continue; - if (memcmp(req->bss->bssid, wk->filter_ta, ETH_ALEN)) + if (memcmp(req->bss->bssid, tmp->filter_ta, ETH_ALEN)) continue; - not_auth_yet = wk->type == IEEE80211_WORK_DIRECT_PROBE; - list_del_rcu(&wk->list); - free_work(wk); + not_auth_yet = tmp->type == IEEE80211_WORK_DIRECT_PROBE; + list_del_rcu(&tmp->list); + synchronize_rcu(); + wk = tmp; break; } mutex_unlock(&local->mtx); + if (wk && wk->type == IEEE80211_WORK_ASSOC) { + /* clean up dummy sta & TX sync */ + sta_info_destroy_addr(wk->sdata, wk->filter_ta); + if (wk->assoc.synced) + drv_finish_tx_sync(local, wk->sdata, + wk->filter_ta, + IEEE80211_TX_SYNC_ASSOC); + } else if (wk && wk->type == IEEE80211_WORK_AUTH) { + if (wk->probe_auth.synced) + drv_finish_tx_sync(local, wk->sdata, + wk->filter_ta, + IEEE80211_TX_SYNC_AUTH); + } + kfree(wk); + /* * If somebody requests authentication and we haven't * sent out an auth frame yet there's no need to send -- 1.7.1

3 3

F16 - F17 Perf?
by Frank Murphy 18 Jan '12

18 Jan '12

Is perf required, have noticed kernel-tools replaced perf in F16. Now in F17, I see both perf and kernel-tools available? http://koji.fedoraproject.org/koji/buildinfo?buildID=294017 So my question, is either necessary? -- Regards, Frank Murphy UTF_8 Encoded

2 2

Fwd: [PATCH] NFSv4: Change the default setting of the nfs4_disable_idmapping parameter
by Steve Dickson 17 Jan '12

17 Jan '12

Hello, Having this patch will help in the effort to support NFSv4 roots.. . Over the weekend I did do some regression testing with this patch and found no issues... Please consider for F17... tia, steved. -------- Original Message -------- Subject: [PATCH] NFSv4: Change the default setting of the nfs4_disable_idmapping parameter Date: Mon, 9 Jan 2012 14:45:54 -0500 From: Trond Myklebust <Trond.Myklebust(a)netapp.com> To: linux-nfs(a)vger.kernel.org Now that the use of numeric uids/gids is officially sanctioned in RFC3530bis, it is time to change the default here to 'enabled'. By doing so, we ensure that NFSv4 copies the behaviour of NFSv3 when we're using the default AUTH_SYS authentication (i.e. when the client uses the numeric uids/gids as authentication tokens), so that when new files are created, they will appear to have the correct user/group. It also fixes a number of backward compatibility issues when migrating from NFSv3 to NFSv4 on a platform where the server uses different uid/gid mappings than the client. Note also that this setting has been successfully tested against servers that do not support numeric uids/gids at several Connectathon/Bakeathon events at this point, and the fall back to using string names/groups has been shown to work well in all those test cases. Signed-off-by: Trond Myklebust <Trond.Myklebust(a)netapp.com> --- Documentation/kernel-parameters.txt | 17 +++++++++++------ fs/nfs/client.c | 2 +- 2 files changed, 12 insertions(+), 7 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 81c287f..dfd21cf 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1630,12 +1630,17 @@ bytes respectively. Such letter suffixes can also be entirely omitted. The default is to return 64-bit inode numbers. nfs.nfs4_disable_idmapping= - [NFSv4] When set, this option disables the NFSv4 - idmapper on the client, but only if the mount - is using the 'sec=sys' security flavour. This may - make migration from legacy NFSv2/v3 systems easier - provided that the server has the appropriate support. - The default is to always enable NFSv4 idmapping. + [NFSv4] When set to the default of '1', this option + ensures that both the RPC level authentication + scheme and the NFS level operations agree to use + numeric uids/gids if the mount is using the + 'sec=sys' security flavour. In effect it is + disabling idmapping, which can make migration from + legacy NFSv2/v3 systems to NFSv4 easier. + Servers that do not support this mode of operation + will be autodetected by the client, and it will fall + back to using the idmapper. + To turn off this behaviour, set the value to '0'. nmi_debug= [KNL,AVR32,SH] Specify one or more actions to take when a NMI is triggered. diff --git a/fs/nfs/client.c b/fs/nfs/client.c index 41bd67f..277dfaf 100644 --- a/fs/nfs/client.c +++ b/fs/nfs/client.c @@ -84,7 +84,7 @@ retry: /* * Turn off NFSv4 uid/gid mapping when using AUTH_SYS */ -static int nfs4_disable_idmapping = 0; +static int nfs4_disable_idmapping = 1; /* * RPC cruft for NFS -- 1.7.7.5 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

2 2

Future kernel version number for F-15
by Nicolas Viéville 14 Jan '12

14 Jan '12

Hello list, This is my first post on this list, so little introduction. I co-maintain the wl-kmod and broadcom-wl packages for rpmfusion repository. My natural language is french, and my English skill is not very good. The question A recent change in kernel 3.2 ABI needs patching wireless kernel modules sources in order to compil. As F-15 seems to use kernel 3.x series renamed with this motif 2.6.4x, I wanted to know if the future kernel versions numbers for F-15 will keep this scheme? If I understood it correctly, in this case next one will be 2.6.42.y-z (for 3.2) and will be followed by 2.6.43.y-z (for 3.3) etc. Knowing this exactly will make it easier to build the C preprocessor macro for the wireless kernel modules sources patch for both F-15/F-16. Thanks in advance for your responses! Cordially, -- Nicolas Viéville

4 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel January 2012