Fixed brace, macro and spacing coding style issues. Signed-off-by: Nicolas Kaiser <nikai@nikai.net> --- drivers/gpu/drm/mga/mga_dma.c | 99 +++++++++------------ drivers/gpu/drm/mga/mga_drv.c | 4 +- drivers/gpu/drm/mga/mga_drv.h | 187 +++++++++++++++++++-------------------- drivers/gpu/drm/mga/mga_irq.c | 9 +- drivers/gpu/drm/mga/mga_state.c | 47 +++++----- drivers/gpu/drm/mga/mga_warp.c | 4 +- 6 files changed, 165 insertions(+), 185 deletions(-) diff --git ...

Good day, My working partner has helped me to send your first payment of US$7,500 to you as instructed by Mr. David Cameron and will keep sending you US$7,500 twice a week until the payment of (US$360,000) is completed within six months and here is the information below: MONEY TRANSFER CONTROL NUMBER (MTCN): 5229059427 SENDER'S NAME: Mr. Mark Daniel AMOUNT: US$7,500 To track your funds forward Western Union Money Transfer agent your Full Names and Mobile Number via Email ...

Analyze "console=uart8250,io,0x3f8,115200n8" in i386_start_kernel/x86_64_start_kernel, and call setup_early_serial8250_console() to init early serial console. only can handle io port kind of 8250. because mmio need ioremap. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- arch/x86/include/asm/setup.h | 1 + arch/x86/kernel/head.c | 32 ++++++++++++++++++++++++++++++++ arch/x86/kernel/head32.c | 2 ++ arch/x86/kernel/head64.c | 11 +++++++++++ kernel/printk.c ...

All these files use the big kernel lock in a trivial way to serialize their private file operations, typically resulting from an earlier semi-automatic pushdown from VFS. None of these drivers appears to want to lock against other code, and they all use the BKL as the top-level lock in their file operations, meaning that there is no lock-order inversion problem. Consequently, we can remove the BKL completely, replacing it with a per-file mutex in every case. Using a scripted approach means ...

All these files use the big kernel lock in a trivial way to serialize their private file operations, typically resulting from an earlier semi-automatic pushdown from VFS. None of these drivers appears to want to lock against other code, and they all use the BKL as the top-level lock in their file operations, meaning that there is no lock-order inversion problem. Consequently, we can remove the BKL completely, replacing it with a per-file mutex in every case. Using a scripted approach means ...

All these files use the big kernel lock in a trivial way to serialize their private file operations, typically resulting from an earlier semi-automatic pushdown from VFS. None of these drivers appears to want to lock against other code, and they all use the BKL as the top-level lock in their file operations, meaning that there is no lock-order inversion problem. Consequently, we can remove the BKL completely, replacing it with a per-file mutex in every case. Using a scripted approach means ...

All these files use the big kernel lock in a trivial way to serialize their private file operations, typically resulting from an earlier semi-automatic pushdown from VFS. None of these drivers appears to want to lock against other code, and they all use the BKL as the top-level lock in their file operations, meaning that there is no lock-order inversion problem. Consequently, we can remove the BKL completely, replacing it with a per-file mutex in every case. Using a scripted approach means ...

All these files use the big kernel lock in a trivial way to serialize their private file operations, typically resulting from an earlier semi-automatic pushdown from VFS. None of these drivers appears to want to lock against other code, and they all use the BKL as the top-level lock in their file operations, meaning that there is no lock-order inversion problem. Consequently, we can remove the BKL completely, replacing it with a per-file mutex in every case. Using a scripted approach means ...

All these files use the big kernel lock in a trivial way to serialize their private file operations, typically resulting from an earlier semi-automatic pushdown from VFS. None of these drivers appears to want to lock against other code, and they all use the BKL as the top-level lock in their file operations, meaning that there is no lock-order inversion problem. Consequently, we can remove the BKL completely, replacing it with a per-file mutex in every case. Using a scripted approach means ...

I just tried 2.6.35-rc4 to see, if a different bug is fixed, but noted that this kernel will only boot with radeon.modeset=0. If KMS is active the display turns off and the system is completely dead, not even SysRq+B is working. I build a new kernel with the radeon driver as a module and inserted it by hand via ssh. The ssh session, I was using has this output: ariolc drm # insmod ./drm_kms_helper.ko ariolc drm # insmod ttm/ttm.ko ariolc drm # insmod radeon/radeon.ko Segmentation ...

Trying to upgrade my system from 2.6.33 to 2.6.34, I can't get it to boot. All tries used CONFIG_SLUB=y The gentoo version of 2.6.34 generated an OOPS during network initialization and then came to a stop. (It seemed that all processes got stuck waiting on some locks.) As in this instance the system was able to start the syslog, I was able to capture the complete OOPS: Jul 3 05:51:43 ariolc kernel: [ 32.674367] BUG: unable to handle kernel NULL pointer dereference at 0000000000000003 Jul ...

Not just Nehalem but on various AMD CPUs it was in the below-10-cycles range for years. Note that we tried this in -rt, but the pain and trouble (and, often, code bloat) was not worth the trouble. The PUSHF/POPF/CLI/STI instructions are really simple and short in the instruction stream - without disturbing other registers. Ingo --

I have seen some hits with cli-sti. I was considering swapping all preempt_disable() with local_irq_save() in ftrace, but hackbench showed a 30% performance degradation when I did that. The test was simply to switch the stack tracer from disabling preemption to disabling IRQs, and I got this as a result: <This is from my IRC log on OFTC #linux-rt IRC discussing this with Thomas Gleixner> Feb 04 10:02:27 <rostedt> running hackbench 10 times with stack tracer using preempt ...

From: Peter Edwards <samwise@bagshot-row.org> Patch for linux-2.6.35-rc4 mainline kernel to enable Paul Qureshi's Retro Adapter [http://keio.dk/retroadapter.html], an open source USB device which allows controllers and joysticks from classic computers and consoles to work on modern PCs, to appear as two separate devices under Linux. Signed-off-by: Peter Edwards <samwise@bagshot-row.org> Acked-by: Paul Qureshi <retro@world3.net> --- This is a first patch submission following ...

Using: gcc (GCC) 4.5.0 20100610 (prerelease) The following warning is seen: drivers/acpi/processor_idle.c:83:12: warning: ‘us_to_pm_timer_ticks’ defined but not used This is because us_to_pm_timer_ticks is only used when CONFIG_ACPI_PROCFS is defined. Fix the warning by moving the function definition into the #ifdef CONFIG_ACPI_PROCFS block. Signed-off-by: Kevin Winchester <kjwinchester@gmail.com> --- drivers/acpi/processor_idle.c | 10 ++++++---- 1 files changed, 6 ...

Yea, strictly speaking, you can be sure no kernel will be bug free, ever. This is why I said "probably more stable" ;) --

This adds a `CHECKSUM' target, which can be used in the iptables mangle table. You can use this target to compute and fill in the checksum in a packet that lacks a checksum. This is particularly useful, if you need to work around old applications such as dhcp clients, that do not work well with checksum offloads, but don't want to disable checksum offload in your device. The problem happens in the field with virtualized applications. For reference, see Red Hat bz 605555, as well ...

I don't remember that discussion. Link? Here's a patch that makes it a "--strict" option for those who really want to get all the style checking options. It also corrects a spelling typo. Signed-off-by: Joe Perches <joe@perches.com --- diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index bd88f11..f0a4c25 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -2180,6 +2180,11 @@ sub process { ERROR("space required before the open parenthesis '('\n" . ...

Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com> --- v2 changes: - Added support for MAX6604 - Added support for TSE2002B3 and TS3000B3 (IDT) - Define Manufacturer IDs separately and only once per manufacturer - Rearranged chip defines to alphabetic order --- Documentation/hwmon/jc42 | 97 ++++++++ MAINTAINERS | 7 + drivers/hwmon/Kconfig | 11 + drivers/hwmon/Makefile | 1 + drivers/hwmon/jc42.c | 594 ...

Please, not again. This has been discussed before, with the conclusion that nobody really cares and we don't want to add pointless warnings to checkpatch.pl, which in the end will just dissuade people from running the script and/or contributing to the kernel at all. -- Jean Delvare --

http://lkml.org/lkml/2009/12/5/65 It's the wrong way of writing patches. Separate things go to separate As long as it doesn't bug me by default, I don't really care. But I -- Jean Delvare --

Fixed brace, macro and spacing coding style issues. Simplified -if (ret) return ret; -return 0; +return ret; Signed-off-by: Nicolas Kaiser <nikai@nikai.net> --- drivers/gpu/drm/via/via_dma.c | 120 ++++++++++++++++-------------------- drivers/gpu/drm/via/via_dmablit.c | 71 ++++++++++------------ drivers/gpu/drm/via/via_dmablit.h | 8 +- drivers/gpu/drm/via/via_drv.h | 22 +++--- drivers/gpu/drm/via/via_irq.c | 13 ++-- drivers/gpu/drm/via/via_map.c | ...

SNAT'ing locally sourced traffic? That's pretty nasty. Look into using 'ip rule' and a second routing table. http://lartc.org/howto/lartc.rpdb.html You will still need use iptables/MARK to do L4 (tcp/udp/etc) policy routing though, however now you can dump the ugly SNATing. Cheers -- Alexander Clouter .sigmonster says: Where do your SOCKS go when you lose them in th' WASHER? --

I read your original post as saying were using iptables and the SNAT action, I am suggesting you use 'ip rule' to say "if x/tcp or y/udp using routing table 'alternative'". Might be easier if you actually put here the ip/iptables rules you are actually using? In the alternative routing table you can say to use a different source IP and/or alternative default gateway address (using something like 'ip route ... src ... via ... dev'). As I mentioned before, as 'ip rule' only knows about IP ...

This is a repost of a patch-series posted by Hannes Eder last September. This is v2 of the patch series and I don't see any outstanding objections to it in the mailing list archives. Series v2.6 fixes the arguments to of %pI4 Series v2.5 fixes some problems introduced in v2.4. Series v2.4 addresses all of the concerns that Patrick McHardy raised witht the v2.3 series. Malcolm Turnbull has offered to test this code so I'd like to get a Reviewed-by from him before the code gets merged. In ...

From: Hannes Eder <heder@google.com> Update the nf_conntrack tuple in reply direction, as we will see traffic from the real server (RIP) to the client (CIP). Once this is done we can use netfilters SNAT in POSTROUTING, especially with xt_ipvs, to do source NAT, e.g.: [ minor fixes by Simon Horman <horms@verge.net.au> ] Signed-off-by: Hannes Eder <heder@google.com> Signed-off-by: Simon Horman <horms@verge.net.au> --- net/netfilter/ipvs/Kconfig | 2 +- ...

From: Hannes Eder <heder@google.com> The user-space library for the netfilter matcher xt_ipvs. [ trivial up-port by Simon Horman <horms@verge.net.au> ] Signed-off-by: Hannes Eder <heder@google.com> Acked-by: Simon Horman <horms@verge.net.au> configure.ac | 10 - extensions/libxt_ipvs.c | 365 +++++++++++++++++++++++++++++++++++++ extensions/libxt_ipvs.man | 24 ++ include/linux/netfilter/xt_ipvs.h | 25 +++ 4 files changed, 422 insertions(+), ...

Hi! 2.6.34 was a desaster for me: bug #15969 - patch was availble before 2.6.34 already, bug #15788, also reported with 2.6.34-rc2 already, as well as most important two complete lockups - well maybe just X.org and radeon KMS, I didn't start my second laptop to SSH into the locked up one - on my ThinkPad T42. I fixed the first one with the patch, but after the lockups I just downgraded to 2.6.33 again. I still actually *use* my machines for something else than hunting patches for ...

Okay, not some, but one. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 --

Hi Martin, well, I'll try to do then :-) There were some threads in the past about kernel releases quality, where Linus explained why it could not be completely black or white. Among the things he explained, I remember that one of primary concern was the inability to slow down development. I mean, if he waits 2 more weeks for things to stabilize, then there will be two more weeks of crap^H^H^H^Hdevelopment merged in next merge window, so in fact this will just shift dates and not ...

Wow! First question what is a "desaster"? Second question, what makes you so important that you feel you can makes demands and comments as you did. If indeed these are production systems and you are an administrator of said production systems. I suggest you need to do a little more home work to expand your knowledge base. I would follow Eric's advice. It's sound advice and better yet it was free. Hope you have better luck in getting your systems running well. -- Sent from my ...

So I tend to use -rc3, -rc4, and -rc5 kernels on my laptops, and when I find bugs, I report them and I help fix them. If more people did that, then the 2.6.X.0 releases would be more stable. But kernel development is a volunteer effort, so it's up to the volunteers to test and fix bugs during the rc4, -rc5 and -rc6 time frame. But if the work tails off, because the developers are busily working on new features for the new release, then past a certain point, delaying the release reaches a ...

IMnshO it's not exactly fair to call them "stable" either. I tend to call them "major releases" which basically reflects what they are - events in the development process that each start a new merge window. Nothing more, either way. Rafael --

Hi! Since I initially guessed this to be more likely a vanilla kernel than a TuxOnIce bug, I might just ask on kernel mailinglist, whether someone can tell me on where to sort this backtrace. I do not really have an exact idea what subsystem this is. Async I/O? Ciao, Martin ---------- Weitergeleitete Nachricht ---------- Subject: [TuxOnIce-devel] hang on hibernation with kernel 2.6.34.1 and TuxOnIce 3.1.1.1 Date: Samstag 10 Juli 2010 From: Martin Steigerwald ...

Signed-off-by: Richard Kennedy <richard@rsk.demon.co.uk> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> --- mm/page-writeback.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- linux-next.orig/mm/page-writeback.c 2010-07-11 08:41:37.000000000 +0800 +++ linux-next/mm/page-writeback.c 2010-07-11 08:42:14.000000000 +0800 @@ -503,11 +503,12 @@ static void balance_dirty_pages(struct a }; get_dirty_limits(&background_thresh, &dirty_thresh, - &bdi_thresh, ...

This was not a bug, since b_io is empty for kupdate writeback. The next patch will do requeue_io() for non-kupdate writeback, so let's fix it. CC: Dave Chinner <david@fromorbit.com> Cc: Martin Bligh <mbligh@google.com> Cc: Michael Rubin <mrubin@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Fengguang Wu <wfg@mail.ustc.edu.cn> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> --- fs/fs-writeback.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 ...

[add cc to Jens] --

Unify the logic for kupdate and non-kupdate cases. There won't be starvation because the inodes requeued into b_more_io will later be spliced _after_ the remaining inodes in b_io, hence won't stand in the way of other inodes in the next run. It avoids unnecessary redirty_tail() calls, hence the update of i_dirtied_when. The timestamp update is undesirable because it could later delay the inode's periodic writeback, or exclude the inode from the data integrity sync operation (which will check ...

Please ignore this patch. Just for gmail format check. Thanks for David Beal's explanation! -- Thanks and Best Regards, shenghui --

There have some machines not support by i915 drm driver, e.g. MSI U110/U150, there are use poulsbo chip and drm driver not support it because legal issue. Those machines's acpi backlight control actually work fine and don't need apply the intel opregion support. So, add intel drm blacklist to intel_opregion_present, it can enable the acpi brightness interface but not use intel opregion. Signed-off-by: Lee, Chun-Yi <jlee@novell.com> --- drivers/acpi/video.c | 17 ++++++++++++++++- ...

Yes, that was the idea. This is the last patch I need to run all of my machines without the BKL, so I spent a few hours looking at how to fix lockd. When I couldn't figure it out, I decided to do an evil hack that happens to work, in order to build pressure. Arnd --

This moves the lock_kernel() call from soundcore_open to the individual OSS device drivers, where we can deal with it one driver at a time if needed, or just kill off the drivers. All core components in ALSA already provide adequate locking in their open()-functions and do not require the big kernel lock, so there is no need to add the BKL there. Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- Sorry, I had removed them and then forgot the git-add before creating the emails. Originally, I ...

On a second thought, "active_time" and "suspended_time" should be sufficient (ie. the "runtime_" prefix is not really necessary). Rafael --

The argument to the %pI4 needs to be a pointer so (T)->src.u3.ip should be &(T)->src.u3.ip and (C)->caddr should be &(C)->caddr.ip. I'm not sure how this slipped through the cracks so far. I will repost. --

That may be chipset dependent, I don't think all chipsets have the ability to distribute the interrupts like that. Round-robin interrupt distribution for a given handler isn't optimal for performance anyway since it causes the relevant cache lines for the interrupt handler to --

I like it. I especially like the change is only evident if you are using the code path that introduced the problem in the first place. If you're doing a lot of requeue_pi operations, then the waking waiters have an advantage over new pending waiters or other tasks with futex keyed on the same hash-bucket... but that seems acceptable to me. I'd like to confirm that holding the pendowner->pi-lock across the wakeup in wakeup_next_waiter() isn't feasible first. If it can work, I think the ...

I looked at the patch and noticed 2 changes: 1) the batch is checked and cleared after local_irq_save 2) enabling the batch is skipped I talked to Will and had him try moving the local_irq_save above the check for the active batch. That alone did not seem to be enough. However, he confirmed that we are setting batch to active when it is already active in lazy_mmu_enter, meaning that batching is being turned on recursively. I suggested debug to check that irqs are off after ...

Isn't this basically sched_yield? Don't run me now, give lower-priority work a chance to complete, let me run again when my budget is replenished. Otherwise, what are the semantics of sched_yield under EDF? Cycle through equal-deadline jobs? Given sporadic task activations, this is probably not very useful. - Björn --

Trying to infer whether a task is "hard" or "soft" from task parameters is not a good idea, IMO. It's much better to make this an explicit part of the task model that is configured via sched_setparam. By default, tasks should be marked "soft" (this leaves more wiggle room to the kernel); users who care can change the flag to "hard". Taking a step back, I think the problem here is that we are trying to shove too many concepts and properties into a single scheduler. Hard (no tardiness) is different ...

I was under the impression that the kernel implementation is a P-EDF implementation. Now it seems to me that it is in fact a "P-EDF with frequent migrations" implementation. I'd be hesitant to just assume that it "approximates G-EDF" sufficiently well to apply any of the published G-EDF tests. - Björn --- Björn B. Brandenburg Ph.D. Student Dept. of Computer Science University of North Carolina at Chapel Hill http://www.cs.unc.edu/~bbb --

Looks good to me. --

You should add MODULE_ALIAS clause, i.e. MODULE_ALIAS("ipt_CHECKSUM"); -- Regards, Changli Gao(xiaosuo@gmail.com) --

Worked for me, thanks! --

Can't find this function in the linux-next source tree: ERROR: "st_get_plat_device" [drivers/staging/ti-st/st_drv.ko] undefined! --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** --

When both batman-adv and dt3155 are enabled as builtin (=y): drivers/staging/dt3155/built-in.o: In function `cleanup_module': (.text+0xc0): multiple definition of `cleanup_module' drivers/staging/batman-adv/built-in.o:(.text+0x330): first defined here drivers/staging/dt3155/built-in.o: In function `init_module': (.text+0x1120): multiple definition of `init_module' drivers/staging/batman-adv/built-in.o:(.text+0x400): first defined here --- ~Randy *** Remember to use ...

I'm sorry, this is not right. The production machine has 16GB of RAM. Don't know if that matters regarding those proc parameters, though. Cheers, Felipe Damasio --

OK, thanks Avi for this information, as I was not aware of this. So something overwrote sk->sk_prot pointer (or skb->sk pointer) with some data. tcp sockets are allocated from a dedicated kmem_cache (because of SLAB_DESTROY_RCU attribute). Their sk->sk_prot should never change in normal operation, since underlying memory cannot be reused by another object type in kernel. It should be NULL or &tcp_prot Felipe, please describe your configuration as much as possible. It might be a driver ...

x86 being litle endian, string is "A]A]" followed by another "XYXY" pattern (non ASCII chars : 0xE8, 0xDC, 0xE8, 0xDC, "èÜèÜ" in ISO8859) --

Yes, you are correct. Care to resend all of this to the network-namespace developer(s) and the netdev mailing list so that the correct people are notified so they can fix it all? thanks, greg k-h --

From: Tejun Heo <tj@kernel.org> A long time ago we had a packet scheduler bug that could corrupt the TCP socket queues, but that was fixed in 2.6.27 so would definitely be fixed in your kernel. -------------------- commit 69747650c814a8a79fef412c7416adf823293a3e Author: David S. Miller <davem@davemloft.net> Date: Sun Aug 17 23:55:36 2008 -0700 pkt_sched: Fix return value corruption in HTB and TBF. Based upon a bug report by Josip Rodin. Packet schedulers should ...

Hmm. This sounds familiar to me, but I cannot remember the discussion you mention or the patch. Or maybe it was the TCP transaction thing ? (including data in SYN or --

Right, this one: http://kerneltrap.org/mailarchive/linux-netdev/2009/10/29/6259073 -- i.

No. That's another thing. ...I've already found it with google today but cannot seem to find it again. I thought I used tcp_make_synack eric but ...I think we've not sent that skb just yet, so this'll never be true (and the rexmit loop terminates at send_head without setting it so we should be safe, I'll still need to check that no other code can accidently move -- i.

On Fri, Jul 9, 2010 at 8:04 PM, KOSAKI Motohiro I can't understand your point. old shrink_slab shrinker->nr += delta; /* Add delta to previous shrinker's remained count */ total_scan = shrinker->nr; while(total_scan >= SHRINK_BATCH) { nr_before = shrink(xxx); total_scan =- this_scan; } shrinker->nr += total_scan; The total_scan can always be the number < SHRINK_BATCH. So, when next shrinker calcuates loop count, the number can affect. new shrink_slab shrinker->nr += delta; ...

Applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next -- James Morris <jmorris@namei.org> --

I would argue that if somebody wants to stick a base64-encoded image or an x509 certificate in their security labels then shipping the whole thing across the wire every time somebody does an extended "stat" is just stupid. Think about how much overhead there would be if you did an "ls -Z" of a directory with 100 files (64k * 100 == 6.4MB!!!), where that data would previously have fit in no more than 10-20k TOTAL. A better solution would be something along the lines of putting at most a ...

'entry' better be gfn_t. We limit gfns in a slot, but that's artificial, let's use the correct type. s/ ? true : false//; :) -- error compiling committee.c: too many arguments to function --

Hi Stephen, thanks for reporting it, I have reverted the drivers/media/video/ov511.c hunk. -- Jiri Kosina SUSE Labs, Novell Inc. --

Remove warnings introduced by conversions of dev_<level> macros to functions. Compile tested only. Signed-off-by: Joe Perches <joe@perches.com> --- drivers/scsi/constants.c | 63 ++++++++++++++++++++--------------- drivers/scsi/sd.c | 6 ++-- drivers/scsi/sym53c8xx_2/sym_hipd.c | 10 ++--- 3 files changed, 43 insertions(+), 36 deletions(-) diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c index cd05e04..f95de51 100644 --- ...

How about something like this? If you think ~18800 entries on a 1GB system is better, let me know and I'll quickly respin. The calculation seems reasonable for other arches. When booting 2.6.35-rc3 on some different x86 boxes with DMA debugging enabled, I've seen consistent exhaustion of the allocated entries during boot, giving 'DMA-API: debugging out of memory - disabling'. Increase the default number of entries to allow DMA debugging again, but assign a reasonable lower limit for systems ...

Makes sense, I have queued the changes. Thanks. -- Jiri Kosina SUSE Labs, Novell Inc. --

we should add this to mpc85xx_defconfig so we build by default. - k --

I have applied the patch, thanks Justin for your persistence, and thanks for reviews while I have been offline, Arnd. -- Jiri Kosina SUSE Labs, Novell Inc. --

We already have a8ab5d58b0238b8199cc699b8dff7c5e1da24138 commit in Linus' -- Jiri Kosina SUSE Labs, Novell Inc. --

IIUC, the difference between this solution and the first one I proposed is that instead of pinning proc_mnt with mntget() at copy_process()-time, proc_mnt is looked for and, if possible, mntget() at release_task()-time. Could you elaborate on the trade-off, that is accessing proc_mnt at copy_process()-time vs looking up proc_mnt at release_task()-time? Thanks, -- Dr Louis Rilling Kerlabs Skype: louis.rilling Batiment Germanium Phone: (+33|0) 6 80 89 08 23 80 avenue des Buttes de ...