Comment 0 for bug 1861776

When fseek is called, it calls in turn 1. lseek(), and 2. read(). In glibc 2.30 (maybe earlier) read() is only called for the last block. However in glibc 2.27 Ubuntu 18.04 is using, the read happens over the whole skipped range, which may cause a hang of an app that tries to skip too big range.

There's is a related report: https://sourceware.org/bugzilla/show_bug.cgi?id=25497 Note, per comments, in at least glibc 2.30 read() only happens for the *last block*. This means there was some fix for fseek() to not read over everything it skipped, which Ubuntu didn't backport to older glibc it's using.

# Steps to reproduce

In command below, replace `/dev/sda` if necessary with a device that is at least 2 GB in size.

Run `sudo hexdump -C /dev/sda -s 0x80000000 -n 1`. This command uses `hexdump` to print content of a disk at a large offset.

## Expected

The command returns immediately with a print

## Actual

The command hangs with high CPU load. If you use `strace hexdump …`, you'll see there a bunch of reads happens. These reads arise from glibc 2.27 implementation of `fseek()`.