progressbar: fix mutex locking in {en|dis}able_progress_bar()

enable_progress_bar() and disable_progress_bar() used to be
only called by the info thread which was not terminated when
Squashfs exited prematurely on error or if ^C hit twice.  So we
did't need to have any pthread_cleanup_{push|pop} code.

Now, however, they are used by the ERROR_START() and ERROR_EXIT()
macros, which can be called by any thread, so we need to protect
the mutex lock against pthread cancel operations.

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
progressbar: fix mutex locking in progressbar_error()

progressbar_error() is called by threads which can be cancelled, so
we need to protect the lock with pthread cleanup code.

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
progressbar: fix mutex locking in progressbar_info()

progressbar_error() is called by threads which can be cancelled, so
we need to protect the lock with pthread cleanup code.

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
caches-queues-lists: fix cache used stats in cache_lookup_nowait()

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
mksquashfs: fix delay in restoring filesystem if stuck in filesystem scanning

If when appending, control C is hit twice, Mksquashfs should respond
by restoring the filesystem and exiting.

Previously I discovered Mksquashfs might hang when generating the
filesystem for some time when control C was hit.  This
I discovered was due to the fact the Mksquashfs main thread might
not hit a pthread cancellation point for sometime.  I fixed this
by updating the restore thread to carefully terminate the
producer threads and flushing the queues that feed the Mksquashfs
main thread, so that it would quickly hit the pthread_cond_wait()
cancellation point on empty queues.

This works well, and avoids the messy need to insert an explicit
pthread_testcancel() within the filesystem generation code.

However, I have discovered Mksquashfs can still hang for sometime
if control C is hit when Mksquashfs is *scanning* the filesystem
prior to starting filesystem generation, if the source filesystem
is large.  This is again because the filesystem scanning code does
not execute any pthread cancellation points, and as it has not
yet started filesystem generation, it does not try and read any
data from producer queues.

The fix here is to exploit the fact that only at filesystem generation
time does the destination filesystem get written to, necessitating
it to be restored on termination.  Prior to this point we can safely exit
Mksquashfs without restoring the filesystem (because as yet it hasn't
been alterred).  So move the creation of the restore thread to
just before filesystem generation, with the result that prior to this
point Mksquashfs will exit without trying to restore the filesystem, and
we avoid trying to pthread cancel code which does not execute any pthread
cancellation points.

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
mksquashfs: fix unmatched pthread_cleanup_push/pthread_cleanup_pop

Get_fragment_checksum() could in certain cases return with a
pthread_cleanup_push context still unpoped.  This caused
a crash or hang when terminating early in appending.

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
caches-queues-lists: make cache/queue dump more readable

by indenting the second line.

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
caches-queues-lists: dump reader thread -> process fragment threads queue

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
caches-queues-lists: dump the fragment reserve cache

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
mksquashfs: shorten the {reader|fragment|writer}_buffer_size variables

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
mksquashfs: fix a potential non-default option deadlock

Fix a potential deadlock in Mksquashfs that may be triggerable using
non-default options.

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>