Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On Mon, Apr 08, 2013 at 03:52:08PM -0500, Nathan Zimmer wrote: > Further digging seems to indicate 9984d7394618df9, the one right > after the commit I previously identified. > Not sure what I did wrong with my bisect to put it off by one. Ugh... Can't reproduce here ;-/ Could you give more details on your setup? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On 04/08/2013 10:58 AM, Al Viro wrote: On Mon, Apr 08, 2013 at 10:34:07AM -0500, Nathan Zimmer wrote: On 04/05/2013 04:00 PM, Al Viro wrote: On Fri, Apr 05, 2013 at 03:56:17PM -0500, Nathan Zimmer wrote: That didn't produce anything. I'll run some bisections over the weekend and see what I can sort out. *Ugh* I'd try to build with DEBUG_KMEMLEAK and slapped printks on the entry and exit from close_pdeo(). If that doesn't show anything interesting, it's probably unrelated to procfs... My bisection pointed me to this commit: e41efbf13c15 At this point I am assuming my issue is unrelated to procfs. Huh? That commit simply moves three functions and one struct from one file to another... Further digging seems to indicate 9984d7394618df9, the one right after the commit I previously identified. Not sure what I did wrong with my bisect to put it off by one. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On 04/08/2013 10:58 AM, Al Viro wrote: On Mon, Apr 08, 2013 at 10:34:07AM -0500, Nathan Zimmer wrote: On 04/05/2013 04:00 PM, Al Viro wrote: On Fri, Apr 05, 2013 at 03:56:17PM -0500, Nathan Zimmer wrote: That didn't produce anything. I'll run some bisections over the weekend and see what I can sort out. *Ugh* I'd try to build with DEBUG_KMEMLEAK and slapped printks on the entry and exit from close_pdeo(). If that doesn't show anything interesting, it's probably unrelated to procfs... My bisection pointed me to this commit: e41efbf13c15 At this point I am assuming my issue is unrelated to procfs. Huh? That commit simply moves three functions and one struct from one file to another... Yea, I was hoping it made more sense to you then it did do me. I have some lab time later. I'll verify that is the problem commit. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On Mon, Apr 08, 2013 at 10:34:07AM -0500, Nathan Zimmer wrote: > On 04/05/2013 04:00 PM, Al Viro wrote: > >On Fri, Apr 05, 2013 at 03:56:17PM -0500, Nathan Zimmer wrote: > > > >>That didn't produce anything. I'll run some bisections over the > >>weekend and see what I can sort out. > >*Ugh* > > > >I'd try to build with DEBUG_KMEMLEAK and slapped printks on the entry > >and exit from close_pdeo(). If that doesn't show anything interesting, > >it's probably unrelated to procfs... > My bisection pointed me to this commit: e41efbf13c15 > At this point I am assuming my issue is unrelated to procfs. Huh? That commit simply moves three functions and one struct from one file to another... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On 04/05/2013 04:00 PM, Al Viro wrote: On Fri, Apr 05, 2013 at 03:56:17PM -0500, Nathan Zimmer wrote: That didn't produce anything. I'll run some bisections over the weekend and see what I can sort out. *Ugh* I'd try to build with DEBUG_KMEMLEAK and slapped printks on the entry and exit from close_pdeo(). If that doesn't show anything interesting, it's probably unrelated to procfs... My bisection pointed me to this commit: e41efbf13c15 At this point I am assuming my issue is unrelated to procfs. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On 04/05/2013 04:00 PM, Al Viro wrote: On Fri, Apr 05, 2013 at 03:56:17PM -0500, Nathan Zimmer wrote: That didn't produce anything. I'll run some bisections over the weekend and see what I can sort out. *Ugh* I'd try to build with DEBUG_KMEMLEAK and slapped printks on the entry and exit from close_pdeo(). If that doesn't show anything interesting, it's probably unrelated to procfs... My bisection pointed me to this commit: e41efbf13c15 At this point I am assuming my issue is unrelated to procfs. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On Mon, Apr 08, 2013 at 10:34:07AM -0500, Nathan Zimmer wrote: On 04/05/2013 04:00 PM, Al Viro wrote: On Fri, Apr 05, 2013 at 03:56:17PM -0500, Nathan Zimmer wrote: That didn't produce anything. I'll run some bisections over the weekend and see what I can sort out. *Ugh* I'd try to build with DEBUG_KMEMLEAK and slapped printks on the entry and exit from close_pdeo(). If that doesn't show anything interesting, it's probably unrelated to procfs... My bisection pointed me to this commit: e41efbf13c15 At this point I am assuming my issue is unrelated to procfs. Huh? That commit simply moves three functions and one struct from one file to another... -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On 04/08/2013 10:58 AM, Al Viro wrote: On Mon, Apr 08, 2013 at 10:34:07AM -0500, Nathan Zimmer wrote: On 04/05/2013 04:00 PM, Al Viro wrote: On Fri, Apr 05, 2013 at 03:56:17PM -0500, Nathan Zimmer wrote: That didn't produce anything. I'll run some bisections over the weekend and see what I can sort out. *Ugh* I'd try to build with DEBUG_KMEMLEAK and slapped printks on the entry and exit from close_pdeo(). If that doesn't show anything interesting, it's probably unrelated to procfs... My bisection pointed me to this commit: e41efbf13c15 At this point I am assuming my issue is unrelated to procfs. Huh? That commit simply moves three functions and one struct from one file to another... Yea, I was hoping it made more sense to you then it did do me. I have some lab time later. I'll verify that is the problem commit. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On 04/08/2013 10:58 AM, Al Viro wrote: On Mon, Apr 08, 2013 at 10:34:07AM -0500, Nathan Zimmer wrote: On 04/05/2013 04:00 PM, Al Viro wrote: On Fri, Apr 05, 2013 at 03:56:17PM -0500, Nathan Zimmer wrote: That didn't produce anything. I'll run some bisections over the weekend and see what I can sort out. *Ugh* I'd try to build with DEBUG_KMEMLEAK and slapped printks on the entry and exit from close_pdeo(). If that doesn't show anything interesting, it's probably unrelated to procfs... My bisection pointed me to this commit: e41efbf13c15 At this point I am assuming my issue is unrelated to procfs. Huh? That commit simply moves three functions and one struct from one file to another... Further digging seems to indicate 9984d7394618df9, the one right after the commit I previously identified. Not sure what I did wrong with my bisect to put it off by one. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On Mon, Apr 08, 2013 at 03:52:08PM -0500, Nathan Zimmer wrote: Further digging seems to indicate 9984d7394618df9, the one right after the commit I previously identified. Not sure what I did wrong with my bisect to put it off by one. Ugh... Can't reproduce here ;-/ Could you give more details on your setup? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On Fri, Apr 05, 2013 at 03:56:17PM -0500, Nathan Zimmer wrote: > That didn't produce anything. I'll run some bisections over the > weekend and see what I can sort out. *Ugh* I'd try to build with DEBUG_KMEMLEAK and slapped printks on the entry and exit from close_pdeo(). If that doesn't show anything interesting, it's probably unrelated to procfs... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On 04/05/2013 12:36 PM, Al Viro wrote: On Fri, Apr 05, 2013 at 12:05:26PM -0500, Nathan Zimmer wrote: On 04/04/2013 03:44 PM, Al Viro wrote: On Thu, Apr 04, 2013 at 12:12:05PM -0500, Nathan Zimmer wrote: Ok I am cloning the tree now. It does look like the patches would conflict. I'll run some tests and take a deeper look. FWIW, I've just pushed there a tentative patch that switches to hopefully saner locking (head should be at cb673c115c1f99d3480471ca5d8cb3f89a1e3bee). Is that more or less what you want wrt spinlock contention? One note: for any given pde_opener, close_pdeo() can be called at most by two threads - final fput() and remove_proc_entry() resp. I think the use of completion + flag is safe there; pde->pde_unload_lock should serialize the critical areas. Something isn't quite right. I keep getting hung during boot. dracut: Mounted root filesystem /dev/sda8 dracut: Switching root I'll try to get some more info on a smaller box. Umm... Try to add WARN_ON(1) in entry_rundown(), just to see what's getting hit (don't bother with entry name, stack trace will be enough). That didn't produce anything. I'll run some bisections over the weekend and see what I can sort out. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On Fri, Apr 05, 2013 at 12:05:26PM -0500, Nathan Zimmer wrote: > On 04/04/2013 03:44 PM, Al Viro wrote: > >On Thu, Apr 04, 2013 at 12:12:05PM -0500, Nathan Zimmer wrote: > > > >>Ok I am cloning the tree now. > >>It does look like the patches would conflict. > >>I'll run some tests and take a deeper look. > >FWIW, I've just pushed there a tentative patch that switches to hopefully > >saner locking (head should be at cb673c115c1f99d3480471ca5d8cb3f89a1e3bee). > >Is that more or less what you want wrt spinlock contention? > > > >One note: for any given pde_opener, close_pdeo() can be called at most > >by two threads - final fput() and remove_proc_entry() resp. I think > >the use of completion + flag is safe there; pde->pde_unload_lock > >should serialize the critical areas. > > Something isn't quite right. I keep getting hung during boot. > dracut: Mounted root filesystem /dev/sda8 > dracut: Switching root > > I'll try to get some more info on a smaller box. Umm... Try to add WARN_ON(1) in entry_rundown(), just to see what's getting hit (don't bother with entry name, stack trace will be enough). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On 04/04/2013 03:44 PM, Al Viro wrote: On Thu, Apr 04, 2013 at 12:12:05PM -0500, Nathan Zimmer wrote: Ok I am cloning the tree now. It does look like the patches would conflict. I'll run some tests and take a deeper look. FWIW, I've just pushed there a tentative patch that switches to hopefully saner locking (head should be at cb673c115c1f99d3480471ca5d8cb3f89a1e3bee). Is that more or less what you want wrt spinlock contention? One note: for any given pde_opener, close_pdeo() can be called at most by two threads - final fput() and remove_proc_entry() resp. I think the use of completion + flag is safe there; pde->pde_unload_lock should serialize the critical areas. Something isn't quite right. I keep getting hung during boot. dracut: Mounted root filesystem /dev/sda8 dracut: Switching root I'll try to get some more info on a smaller box. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On 04/04/2013 03:44 PM, Al Viro wrote: On Thu, Apr 04, 2013 at 12:12:05PM -0500, Nathan Zimmer wrote: Ok I am cloning the tree now. It does look like the patches would conflict. I'll run some tests and take a deeper look. FWIW, I've just pushed there a tentative patch that switches to hopefully saner locking (head should be at cb673c115c1f99d3480471ca5d8cb3f89a1e3bee). Is that more or less what you want wrt spinlock contention? One note: for any given pde_opener, close_pdeo() can be called at most by two threads - final fput() and remove_proc_entry() resp. I think the use of completion + flag is safe there; pde-pde_unload_lock should serialize the critical areas. Something isn't quite right. I keep getting hung during boot. dracut: Mounted root filesystem /dev/sda8 dracut: Switching root I'll try to get some more info on a smaller box. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On Fri, Apr 05, 2013 at 12:05:26PM -0500, Nathan Zimmer wrote: On 04/04/2013 03:44 PM, Al Viro wrote: On Thu, Apr 04, 2013 at 12:12:05PM -0500, Nathan Zimmer wrote: Ok I am cloning the tree now. It does look like the patches would conflict. I'll run some tests and take a deeper look. FWIW, I've just pushed there a tentative patch that switches to hopefully saner locking (head should be at cb673c115c1f99d3480471ca5d8cb3f89a1e3bee). Is that more or less what you want wrt spinlock contention? One note: for any given pde_opener, close_pdeo() can be called at most by two threads - final fput() and remove_proc_entry() resp. I think the use of completion + flag is safe there; pde-pde_unload_lock should serialize the critical areas. Something isn't quite right. I keep getting hung during boot. dracut: Mounted root filesystem /dev/sda8 dracut: Switching root I'll try to get some more info on a smaller box. Umm... Try to add WARN_ON(1) in entry_rundown(), just to see what's getting hit (don't bother with entry name, stack trace will be enough). -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On 04/05/2013 12:36 PM, Al Viro wrote: On Fri, Apr 05, 2013 at 12:05:26PM -0500, Nathan Zimmer wrote: On 04/04/2013 03:44 PM, Al Viro wrote: On Thu, Apr 04, 2013 at 12:12:05PM -0500, Nathan Zimmer wrote: Ok I am cloning the tree now. It does look like the patches would conflict. I'll run some tests and take a deeper look. FWIW, I've just pushed there a tentative patch that switches to hopefully saner locking (head should be at cb673c115c1f99d3480471ca5d8cb3f89a1e3bee). Is that more or less what you want wrt spinlock contention? One note: for any given pde_opener, close_pdeo() can be called at most by two threads - final fput() and remove_proc_entry() resp. I think the use of completion + flag is safe there; pde-pde_unload_lock should serialize the critical areas. Something isn't quite right. I keep getting hung during boot. dracut: Mounted root filesystem /dev/sda8 dracut: Switching root I'll try to get some more info on a smaller box. Umm... Try to add WARN_ON(1) in entry_rundown(), just to see what's getting hit (don't bother with entry name, stack trace will be enough). That didn't produce anything. I'll run some bisections over the weekend and see what I can sort out. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On Fri, Apr 05, 2013 at 03:56:17PM -0500, Nathan Zimmer wrote: That didn't produce anything. I'll run some bisections over the weekend and see what I can sort out. *Ugh* I'd try to build with DEBUG_KMEMLEAK and slapped printks on the entry and exit from close_pdeo(). If that doesn't show anything interesting, it's probably unrelated to procfs... -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On Thu, Apr 04, 2013 at 12:12:05PM -0500, Nathan Zimmer wrote: > Ok I am cloning the tree now. > It does look like the patches would conflict. > I'll run some tests and take a deeper look. FWIW, I've just pushed there a tentative patch that switches to hopefully saner locking (head should be at cb673c115c1f99d3480471ca5d8cb3f89a1e3bee). Is that more or less what you want wrt spinlock contention? One note: for any given pde_opener, close_pdeo() can be called at most by two threads - final fput() and remove_proc_entry() resp. I think the use of completion + flag is safe there; pde->pde_unload_lock should serialize the critical areas. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On 04/04/2013 11:11 AM, Al Viro wrote: On Thu, Apr 04, 2013 at 10:53:39AM -0500, Nathan Zimmer wrote: This moves a kfree outside a spinlock to help scaling on larger (512 core) systems. This should be some relief until we can move the section to use the rcu. Umm... That'll get wrecked as soon as fixes from #experimental go in; FWIW, I'd probably make close_pdeo() return pdeo or NULL, depending on whether we want it freed. With kfree() itself taken to callers. But there's much bigger fish to fry there - turn use_pde() into return atomic_inc_unless_negative(>pde_users), unuse_pde() into if (atomic_dec_return(>pde_users) == BIAS) complete(pde->) and make sure entry_rundown() sets completion *before* adding BIAS to pde_users and waits for it only if the sum was equal to BIAS. The spinlock is still needed, but only on the "now taking care of any pdeo that might still be around" side of things - it protects pdeo list. Again, see the last two commits of vfs.git#experimental. I'd certainly appreciate any extra eyes on that sucker... Ok I am cloning the tree now. It does look like the patches would conflict. I'll run some tests and take a deeper look. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On Thu, Apr 04, 2013 at 10:53:39AM -0500, Nathan Zimmer wrote: > This moves a kfree outside a spinlock to help scaling on larger (512 core) > systems. This should be some relief until we can move the section to use > the rcu. Umm... That'll get wrecked as soon as fixes from #experimental go in; FWIW, I'd probably make close_pdeo() return pdeo or NULL, depending on whether we want it freed. With kfree() itself taken to callers. But there's much bigger fish to fry there - turn use_pde() into return atomic_inc_unless_negative(>pde_users), unuse_pde() into if (atomic_dec_return(>pde_users) == BIAS) complete(pde->) and make sure entry_rundown() sets completion *before* adding BIAS to pde_users and waits for it only if the sum was equal to BIAS. The spinlock is still needed, but only on the "now taking care of any pdeo that might still be around" side of things - it protects pdeo list. Again, see the last two commits of vfs.git#experimental. I'd certainly appreciate any extra eyes on that sucker... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On Thu, Apr 04, 2013 at 10:53:39AM -0500, Nathan Zimmer wrote: This moves a kfree outside a spinlock to help scaling on larger (512 core) systems. This should be some relief until we can move the section to use the rcu. Umm... That'll get wrecked as soon as fixes from #experimental go in; FWIW, I'd probably make close_pdeo() return pdeo or NULL, depending on whether we want it freed. With kfree() itself taken to callers. But there's much bigger fish to fry there - turn use_pde() into return atomic_inc_unless_negative(pde-pde_users), unuse_pde() into if (atomic_dec_return(pde-pde_users) == BIAS) complete(pde-) and make sure entry_rundown() sets completion *before* adding BIAS to pde_users and waits for it only if the sum was equal to BIAS. The spinlock is still needed, but only on the now taking care of any pdeo that might still be around side of things - it protects pdeo list. Again, see the last two commits of vfs.git#experimental. I'd certainly appreciate any extra eyes on that sucker... -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On 04/04/2013 11:11 AM, Al Viro wrote: On Thu, Apr 04, 2013 at 10:53:39AM -0500, Nathan Zimmer wrote: This moves a kfree outside a spinlock to help scaling on larger (512 core) systems. This should be some relief until we can move the section to use the rcu. Umm... That'll get wrecked as soon as fixes from #experimental go in; FWIW, I'd probably make close_pdeo() return pdeo or NULL, depending on whether we want it freed. With kfree() itself taken to callers. But there's much bigger fish to fry there - turn use_pde() into return atomic_inc_unless_negative(pde-pde_users), unuse_pde() into if (atomic_dec_return(pde-pde_users) == BIAS) complete(pde-) and make sure entry_rundown() sets completion *before* adding BIAS to pde_users and waits for it only if the sum was equal to BIAS. The spinlock is still needed, but only on the now taking care of any pdeo that might still be around side of things - it protects pdeo list. Again, see the last two commits of vfs.git#experimental. I'd certainly appreciate any extra eyes on that sucker... Ok I am cloning the tree now. It does look like the patches would conflict. I'll run some tests and take a deeper look. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock
On Thu, Apr 04, 2013 at 12:12:05PM -0500, Nathan Zimmer wrote: Ok I am cloning the tree now. It does look like the patches would conflict. I'll run some tests and take a deeper look. FWIW, I've just pushed there a tentative patch that switches to hopefully saner locking (head should be at cb673c115c1f99d3480471ca5d8cb3f89a1e3bee). Is that more or less what you want wrt spinlock contention? One note: for any given pde_opener, close_pdeo() can be called at most by two threads - final fput() and remove_proc_entry() resp. I think the use of completion + flag is safe there; pde-pde_unload_lock should serialize the critical areas. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
