Hi all, It seems that the buffer allocation in seq_read can double in size indefinitely, at least I've seen that in practice with /proc/<pid>/smaps (attempting to double m->size to 4M on a read of 1000 bytes). This produces an ugly WARN_ON_ONCE, which should perhaps be avoided? (given that it can be triggered by userspace at will) >From the top comment in seq_file.c one would think that it is a fundamental limitation of the current code that everything which will be read (even if in chunks) needs to be in the kernel side buffer at the same time? If that is true then only way to fix it would be to completely re-design the seq_file interface, just silencing the allocation failure with __GFP_NOWARN perhaps as a temporary measure. As an alternative, since it does sound a bit pathological, perhaps users for seq_file who know can be printing out such huge amounts of text should just use a different (new?) facility? Thanks, Tvrtko -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
