linux.git/fs/pstore, branch v4.9

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

2016-10-11T03:16:43+00:00

Pull more vfs updates from Al Viro:
 ">rename2() work from Miklos + current_time() from Deepa"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  fs: Replace current_fs_time() with current_time()
  fs: Replace CURRENT_TIME_SEC with current_time() for inode timestamps
  fs: Replace CURRENT_TIME with current_time() for inode timestamps
  fs: proc: Delete inode time initializations in proc_alloc_inode()
  vfs: Add current_time() api
  vfs: add note about i_op->rename changes to porting
  fs: rename "rename2" i_op to "rename"
  vfs: remove unused i_op->rename
  fs: make remaining filesystems use .rename2
  libfs: support RENAME_NOREPLACE in simple_rename()
  fs: support RENAME_NOREPLACE for local filesystems
  ncpfs: fix unused variable warning

fs: Replace CURRENT_TIME with current_time() for inode timestamps

2016-09-28T01:06:21+00:00

CURRENT_TIME macro is not appropriate for filesystems as it
doesn't use the right granularity for filesystem timestamps.
Use current_time() instead.

CURRENT_TIME is also not y2038 safe.

This is also in preparation for the patch that transitions
vfs timestamps to use 64 bit time and hence make them
y2038 safe. As part of the effort current_time() will be
extended to do range checks. Hence, it is necessary for all
file system timestamps to use current_time(). Also,
current_time() will be transitioned along with vfs to be
y2038 safe.

Note that whenever a single call to current_time() is used
to change timestamps in different inodes, it is because they
share the same time granularity.

Signed-off-by: Deepa Dinamani 
Reviewed-by: Arnd Bergmann 
Acked-by: Felipe Balbi 
Acked-by: Steven Whitehouse 
Acked-by: Ryusuke Konishi 
Acked-by: David Sterba 
Signed-off-by: Al Viro

ramoops: move spin_lock_init after kmalloc error checking

2016-09-08T22:01:13+00:00

If cxt->pstore.buf allocated failed, no need to initialize
cxt->pstore.buf_lock. So this patch moves spin_lock_init() after the
error checking.

Signed-off-by: Geliang Tang 
Signed-off-by: Kees Cook

pstore/ram: Use memcpy_fromio() to save old buffer

2016-09-08T22:01:12+00:00

The ramoops buffer may be mapped as either I/O memory or uncached
memory.  On ARM64, this results in a device-type (strongly-ordered)
mapping.  Since unnaligned accesses to device-type memory will
generate an alignment fault (regardless of whether or not strict
alignment checking is enabled), it is not safe to use memcpy().
memcpy_fromio() is guaranteed to only use aligned accesses, so use
that instead.

Signed-off-by: Andrew Bresticker 
Signed-off-by: Enric Balletbo Serra 
Reviewed-by: Puneet Kumar 
Signed-off-by: Kees Cook 
Cc: stable@vger.kernel.org

pstore/ram: Use memcpy_toio instead of memcpy

2016-09-08T22:01:11+00:00

persistent_ram_update uses vmap / iomap based on whether the buffer is in
memory region or reserved region. However, both map it as non-cacheable
memory. For armv8 specifically, non-cacheable mapping requests use a
memory type that has to be accessed aligned to the request size. memcpy()
doesn't guarantee that.

Signed-off-by: Furquan Shaikh 
Signed-off-by: Enric Balletbo Serra 
Reviewed-by: Aaron Durbin 
Reviewed-by: Olof Johansson 
Tested-by: Furquan Shaikh 
Signed-off-by: Kees Cook 
Cc: stable@vger.kernel.org

pstore/pmsg: drop bounce buffer

2016-09-08T22:01:10+00:00

Removing a bounce buffer copy operation in the pmsg driver path is
always better. We also gain in overall performance by not requesting
a vmalloc on every write as this can cause precious RT tasks, such
as user facing media operation, to stall while memory is being
reclaimed. Added a write_buf_user to the pstore functions, a backup
platform write_buf_user that uses the small buffer that is part of
the instance, and implemented a ramoops write_buf_user that only
supports PSTORE_TYPE_PMSG.

Signed-off-by: Mark Salyzyn 
Signed-off-by: Kees Cook

pstore/ram: Set pstore flags dynamically

2016-09-08T22:01:09+00:00

The ramoops can be configured to enable each pstore type by setting
their size.  In that case, it'd be better not to register disabled types
in the first place.

Cc: Anton Vorontsov 
Cc: Colin Cross 
Cc: Kees Cook 
Cc: Tony Luck 
Signed-off-by: Namhyung Kim 
Signed-off-by: Kees Cook

pstore: Split pstore fragile flags

2016-09-08T22:01:08+00:00

This patch adds new PSTORE_FLAGS for each pstore type so that they can
be enabled separately.  This is a preparation for ongoing virtio-pstore
work to support those types flexibly.

The PSTORE_FLAGS_FRAGILE is changed to PSTORE_FLAGS_DMESG to preserve the
original behavior.

Cc: Anton Vorontsov 
Cc: Colin Cross 
Cc: Kees Cook 
Cc: Tony Luck 
Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: Matt Fleming 
Cc: linux-acpi@vger.kernel.org
Cc: linux-efi@vger.kernel.org
Signed-off-by: Namhyung Kim 
[kees: retained "FRAGILE" for now to make merges easier]
Signed-off-by: Kees Cook

pstore/core: drop cmpxchg based updates

2016-09-08T22:00:47+00:00

I have here a FPGA behind PCIe which exports SRAM which I use for
pstore. Now it seems that the FPGA no longer supports cmpxchg based
updates and writes back 0xff…ff and returns the same.  This leads to
crash during crash rendering pstore useless.
Since I doubt that there is much benefit from using cmpxchg() here, I am
dropping this atomic access and use the spinlock based version.

Cc: Anton Vorontsov 
Cc: Colin Cross 
Cc: Kees Cook 
Cc: Tony Luck 
Cc: Rabin Vincent 
Tested-by: Rabin Vincent 
Signed-off-by: Sebastian Andrzej Siewior 
Reviewed-by: Guenter Roeck 
[kees: remove "_locked" suffix since it's the only option now]
Signed-off-by: Kees Cook 
Cc: stable@vger.kernel.org

pstore/ramoops: fixup driver removal

2016-09-08T21:58:00+00:00

A basic rmmod ramoops segfaults. Let's see why.

Since commit 34f0ec82e0a9 ("pstore: Correct the max_dump_cnt clearing of
ramoops") sets ->max_dump_cnt to zero before looping over ->przs but we
didn't use it before that either.

And since commit ee1d267423a1 ("pstore: add pstore unregister") we free
that memory on rmmod.

But even then, we looped until a NULL pointer or ERR. I don't see where
it is ensured that the last member is NULL. Let's try this instead:
simply error recovery and free. Clean up in error case where resources
were allocated. And then, in the free path, rely on ->max_dump_cnt in
the free path.

Cc: Anton Vorontsov 
Cc: Colin Cross 
Cc: Kees Cook 
Cc: Tony Luck 
Cc: Namhyung Kim 
Acked-by: Namhyung Kim 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Kees Cook 
Cc: stable@vger.kernel.org # 4.4.x-