| Message ID | 20200818061239.29091-3-jannh@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Fix ELF / FDPIC ELF core dumping, and use mmap_lock properly in there | expand |
On 08/18, Jann Horn wrote: > > + if (dump_interrupted()) > + return 0; > + n = __kernel_write(file, addr, nr, &pos); > + if (n != nr) > + return 0; > + file->f_pos = pos; Just curious, can't we simply do __kernel_write(file, addr, nr, &file->f_pos); and avoid "loff_t pos" ? Oleg.
On Tue, Aug 18, 2020 at 3:40 PM Oleg Nesterov <oleg@redhat.com> wrote: > On 08/18, Jann Horn wrote: > > > > + if (dump_interrupted()) > > + return 0; > > + n = __kernel_write(file, addr, nr, &pos); > > + if (n != nr) > > + return 0; > > + file->f_pos = pos; > > Just curious, can't we simply do > > __kernel_write(file, addr, nr, &file->f_pos); > > and avoid "loff_t pos" ? Hm... e.g. ksys_write() has the same pattern of copying the value into a local variable and back, but I guess maybe there it's done so that ->f_pos can't change when vfs_write() returns a negative value, or something like that? Or maybe to make the update look more atomic? None of that is a concern for the core-dumping code, so I guess we could change it... but then again, maybe we shouldn't diverge from how it's done in fs/read_write.c (e.g. in ksys_write()) too much. Coredumping is already a bit too special, no need to make it worse... It looks like Al Viro introduced this as part of commit 2507a4fbd48a ("make dump_emit() use vfs_write() instead of banging at ->f_op->write directly"). Before that commit, &file->f_pos was actually passed as a parameter, just like you're proposing. I don't really want to try reverting parts of Al's commits without understanding what exactly is going on...
On Tue, Aug 18, 2020 at 03:40:28PM +0200, Oleg Nesterov wrote: > On 08/18, Jann Horn wrote: > > > > + if (dump_interrupted()) > > + return 0; > > + n = __kernel_write(file, addr, nr, &pos); > > + if (n != nr) > > + return 0; > > + file->f_pos = pos; > > Just curious, can't we simply do > > __kernel_write(file, addr, nr, &file->f_pos); > > and avoid "loff_t pos" ? Bloody bad pattern; it would be (probably) safe in this case, but in general ->f_pos is shared data. Exposing it to fuckloads of ->write() instances is a bad idea - we had bugs like that. General rule: never pass an address of ->f_pos to anything, and limit access to it as much as possible.
diff --git a/fs/coredump.c b/fs/coredump.c index 76e7c10edfc0..5e24c06092c9 100644 --- a/fs/coredump.c +++ b/fs/coredump.c @@ -840,17 +840,17 @@ int dump_emit(struct coredump_params *cprm, const void *addr, int nr) ssize_t n; if (cprm->written + nr > cprm->limit) return 0; - while (nr) { - if (dump_interrupted()) - return 0; - n = __kernel_write(file, addr, nr, &pos); - if (n <= 0) - return 0; - file->f_pos = pos; - cprm->written += n; - cprm->pos += n; - nr -= n; - } + + + if (dump_interrupted()) + return 0; + n = __kernel_write(file, addr, nr, &pos); + if (n != nr) + return 0; + file->f_pos = pos; + cprm->written += n; + cprm->pos += n; + return 1; } EXPORT_SYMBOL(dump_emit);
dump_emit() has a retry loop, but there seems to be no way for that retry logic to actually be used; and it was also buggy, writing the same data repeatedly after a short write. Let's just bail out on a short write. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jann Horn <jannh@google.com> --- fs/coredump.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-)