Re: [PATCH][RFC] %pd - for printing dentry name

On Tue, Feb 02, 2010 at 05:00:37AM +0000, Al Viro wrote:
On Mon, Feb 01, 2010 at 08:22:24PM -0800, Linus Torvalds wrote:

We probably can get away with that, but we'll have to be a lot more careful
with the order of updating these suckers in d_move_locked et.al.

I wouldn't worry about it too much. So what if we get a screwed up name?
If we use "%.*s" to print the name, we know that we won't overstep the old
name even if the NUL termination somehow went away (because we're busy
copying a new, longer, name over it or whatever).

Actually, I'm not sure. We can get hit by a switch to inline name with
length still being that from a long earlier name. And inline name is
in the end of struct dentry, so we could end up stepping off the end
of page. Note that existing d_alloc() does put NUL in d_iname for a short
name, but it won't clean the end of array, so overwrite during memcpy()
can open up a whole lot of PITA.

And yes, it's theoretical and ought to be hard to hit - the sky isn't falling.
OTOH, something like rename() vs. close() race as in ocfs2 might make it
not all that theoretical.

We probably can get away with being careful with barriers and order of
->len vs. ->name updates (and being a bit more careful about cleaning the
crap in d_alloc()), but it'll take an accurate analysis. I'd really like
to hear something from RCU folks, BTW; I still hope that it's one of the
more or less standard problems and "memory barriers" and "reinventing
the wheel" in the same sentence is something I'd rather avoid.

I ended up having to use a seqlock to do name comparison without locks
(and without holding references for that matter, just RCU). However
name comparison is obviously a lot more critical because you can't
ignore races, so you might be able to do something simpler.

But I can't see a good way to do it completely just with RCU and memory
ordering. You could get multiple renames in there, so no matter the
ordering, I think you can get a mismatched len,name ptr tuple.

Could do something really awful by checking ksize or DNAME_INLINE_LEN
of your name pointer. This ensures you don't hit random memory. Would
require more work to avoid leaking kernel memory. Seems really nasty
though.

Seqlock should work nicely, but it requires some additions to core code
so I don't think it is justified unless it comes with other core
improvements (like scalability work).


FWIW, speaking of fun printf extensions, there might be a completely
different way to deal with all that crap. %s modification doing kfree().
I.e. "get char * from argument list, print it as %s would, then kfree() it".
With something along the lines of
printk("... %<something>...", build_some_string(...));
as intended use, build_some_string() allocating a string and filling it.
Might or might not be a good idea, but it's interesting to consider. And
yes, of course it's a deadlock if you do that under any kind of a spinlock,
but that's the damn caller's responsibility - after all, they explicitly
call a function that does allocation. The real danger with that is that
somebody will use it with %s and get a leak from hell...

Might not be a bad idea to have a kstrdup type helper that does the
right locking. But does it warrant a fancy new printk conversion?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [Announce]: Target_Core_Mod/ConfigFS and LIO-Target v3.0 work
    ... allocations would help the performance of a storage target. ... A single codepath memory allocating *AND* mapping for: ... Allocating multiple contigious struct page from the memory allocator ... I never claimed that RDMA is only possible from user space -- that was ...
    (Linux-Kernel)
  • Re: Forcing a Large Object Heap allocation.
    ... you should be passing the recommended 60% memory limit. ... that point and you should be experiencing an unstable app IMO. ... > compacts the heap. ... > objects in the regular heap causes poorer performance than allocating many ...
    (microsoft.public.dotnet.framework.performance)
  • Re: Designing a Finite State Machine DFA Recognizer for UTF-8
    ... Besides that fact that you are using OBJECT elements, this is factored out because its a COMMON concept, which means that the primitive functional prototype STILL makes it faster than your OBJECT version which proves without a shadow of a doubt that it is faster than your silly version. ... memory myself, and you are passing in a pointer to a buffer and its length which tends to show that you are allocating memory yourself. ... You are ALLOCATING memory using std:vector as well. ... so why do you show to have such a low intelligence level when it comes to computer programming and do not seem to understand basic computer science and programming concepts? ...
    (microsoft.public.vc.mfc)
  • Re: About d32a_xxx functions in dos/32a library...
    ... The reason why I asked is: my app often reset or hang after some specific operations and by elementary observations I suspect this might be due to memory allocation/de-allocation... ... Is calloc the only function you are allocating with when you have the ... May I assume you are deallocating with freewith the correct pointer? ... If you are simply allocating with calloc and deallocating with free a 4MB ...
    (comp.os.msdos.programmer)
  • Re: [00/41] Large Blocksize Support V7 (adds memmap support)
    ... some memory will be wasted. ... blocks with slab pages can be targetted and cleared if necessary. ... Allocating userpages from slab in 4k chunks with a 64k PAGE_SIZE is ... it remains a possibility to make the kernel more generic. ...
    (Linux-Kernel)