linux-toradex.git/fs/kernfs/file.c, branch v3.19.7

vm_area_operations: kill ->migrate()

2014-12-17T13:26:51+00:00

the only instance this method has ever grown was one in kernfs -
one that call ->migrate() of another vm_ops if it exists.

Signed-off-by: Al Viro

sysfs/kernfs: make read requests on pre-alloc files use the buffer.

2014-11-07T18:54:38+00:00

To match the previous patch which used the pre-alloc buffer for
writes, this patch causes reads to use the same buffer.
This is not strictly necessary as the current seq_read() will allocate
on first read, so user-space can trigger the required pre-alloc.  But
consistency is valuable.

The read function is somewhat simpler than seq_read() and, for example,
does not support reading from an offset into the file: reads must be
at the start of the file.

As seq_read() does not use the prealloc buffer, ->seq_show is
incompatible with ->prealloc and caused an EINVAL return from open().
sysfs code which calls into kernfs always chooses the correct function.

As the buffer is shared with writes and other reads, the mutex is
extended to cover the copy_to_user.

Signed-off-by: NeilBrown 
Reviewed-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

sysfs/kernfs: allow attributes to request write buffer be pre-allocated.

2014-11-07T18:53:25+00:00

md/raid allows metadata management to be performed in user-space.
A various times, particularly on device failure, the metadata needs
to be updated before further writes can be permitted.
This means that the user-space program which updates metadata much
not block on writeout, and so must not allocate memory.

mlockall(MCL_CURRENT|MCL_FUTURE) and pre-allocation can avoid all
memory allocation issues for user-memory, but that does not help
kernel memory.
Several kernel objects can be pre-allocated.  e.g. files opened before
any writes to the array are permitted.
However some kernel allocation happens in places that cannot be
pre-allocated.
In particular, writes to sysfs files (to tell md that it can now
allow writes to the array) allocate a buffer using GFP_KERNEL.

This patch allows attributes to be marked as "PREALLOC".  In that case
the maximal buffer is allocated when the file is opened, and then used
on each write instead of allocating a new buffer.

As the same buffer is now shared for all writes on the same file
description, the mutex is extended to cover full use of the buffer
including the copy_from_user().

The new __ATTR_PREALLOC() 'or's a new flag in to the 'mode', which is
inspected by sysfs_add_file_mode_ns() to determine if the file should be
marked as requiring prealloc.

Despite the comment, we *do* use ->seq_show together with ->prealloc
in this patch.  The next patch fixes that.

Signed-off-by: NeilBrown  
Reviewed-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

kernfs: kernel-doc warning fix

2014-07-09T23:37:29+00:00

s/static_name/name_is_static

Signed-off-by: Fabian Frederick 
Acked-by: Tejun Heo 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

kernfs: kernfs_notify() must be useable from non-sleepable contexts

2014-07-02T16:32:09+00:00

d911d9874801 ("kernfs: make kernfs_notify() trigger inotify events
too") added fsnotify triggering to kernfs_notify() which requires a
sleepable context.  There are already existing users of
kernfs_notify() which invoke it from an atomic context and in general
it's silly to require a sleepable context for triggering a
notification.

The following is an invalid context bug triggerd by md invoking
sysfs_notify() from IO completion path.

 BUG: sleeping function called from invalid context at kernel/locking/mutex.c:586
 in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/1
 2 locks held by swapper/1/0:
  #0:  (&(&vblk->vq_lock)->rlock){-.-...}, at: [] virtblk_done+0x42/0xe0 [virtio_blk]
  #1:  (&(&bitmap->counts.lock)->rlock){-.....}, at: [] bitmap_endwrite+0x68/0x240
 irq event stamp: 33518
 hardirqs last  enabled at (33515): [] default_idle+0x1f/0x230
 hardirqs last disabled at (33516): [] common_interrupt+0x6d/0x72
 softirqs last  enabled at (33518): [] _local_bh_enable+0x22/0x50
 softirqs last disabled at (33517): [] irq_enter+0x60/0x80
 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.16.0-0.rc2.git2.1.fc21.x86_64 #1
 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  0000000000000000 f90db13964f4ee05 ffff88007d403b80 ffffffff81807b4c
  0000000000000000 ffff88007d403ba8 ffffffff810d4f14 0000000000000000
  0000000000441800 ffff880078fa1780 ffff88007d403c38 ffffffff8180caf2
 Call Trace:
    [] dump_stack+0x4d/0x66
  [] __might_sleep+0x184/0x240
  [] mutex_lock_nested+0x42/0x440
  [] kernfs_notify+0x90/0x150
  [] bitmap_endwrite+0xcc/0x240
  [] close_write+0x93/0xb0 [raid1]
  [] r1_bio_write_done+0x29/0x50 [raid1]
  [] raid1_end_write_request+0xe4/0x260 [raid1]
  [] bio_endio+0x6b/0xa0
  [] blk_update_request+0x94/0x420
  [] blk_mq_end_io+0x1a/0x70
  [] virtblk_request_done+0x32/0x80 [virtio_blk]
  [] __blk_mq_complete_request+0x88/0x120
  [] blk_mq_complete_request+0x2a/0x30
  [] virtblk_done+0x66/0xe0 [virtio_blk]
  [] vring_interrupt+0x3a/0xa0 [virtio_ring]
  [] handle_irq_event_percpu+0x77/0x340
  [] handle_irq_event+0x3d/0x60
  [] handle_edge_irq+0x66/0x130
  [] handle_irq+0x84/0x150
  [] do_IRQ+0x4d/0xe0
  [] common_interrupt+0x72/0x72
    [] ? native_safe_halt+0x6/0x10
  [] default_idle+0x24/0x230
  [] arch_cpu_idle+0xf/0x20
  [] cpu_startup_entry+0x37c/0x7b0
  [] start_secondary+0x25b/0x300

This patch fixes it by punting the notification delivery through a
work item.  This ends up adding an extra pointer to kernfs_elem_attr
enlarging kernfs_node by a pointer, which is not ideal but not a very
big deal either.  If this turns out to be an actual issue, we can move
kernfs_elem_attr->size to kernfs_node->iattr later.

Signed-off-by: Tejun Heo 
Reported-by: Josh Boyer 
Cc: Jens Axboe 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Greg Kroah-Hartman

Merge 3.15-rc6 into driver-core-next

2014-05-23T01:13:53+00:00

We want the kernfs fixes in this branch as well for testing.

Signed-off-by: Greg Kroah-Hartman

kernfs, sysfs, cgroup: restrict extra perm check on open to sysfs

2014-05-13T11:21:40+00:00

The kernfs open method - kernfs_fop_open() - inherited extra
permission checks from sysfs.  While the vfs layer allows ignoring the
read/write permissions checks if the issuer has CAP_DAC_OVERRIDE,
sysfs explicitly denied open regardless of the cap if the file doesn't
have any of the UGO perms of the requested access or doesn't implement
the requested operation.  It can be debated whether this was a good
idea or not but the behavior is too subtle and dangerous to change at
this point.

After cgroup got converted to kernfs, this extra perm check also got
applied to cgroup breaking libcgroup which opens write-only files with
O_RDWR as root.  This patch gates the extra open permission check with
a new flag KERNFS_ROOT_EXTRA_OPEN_PERM_CHECK and enables it for sysfs.
For sysfs, nothing changes.  For cgroup, root now can perform any
operation regardless of the permissions as it was before kernfs
conversion.  Note that kernfs still fails unimplemented operations
with -EINVAL.

While at it, add comments explaining KERNFS_ROOT flags.

Signed-off-by: Tejun Heo 
Reported-by: Andrey Wagin 
Tested-by: Andrey Wagin 
Cc: Li Zefan 
References: http://lkml.kernel.org/g/CANaxB-xUm3rJ-Cbp72q-rQJO5mZe1qK6qXsQM=vh0U8upJ44+A@mail.gmail.com
Fixes: 2bd59d48ebfb ("cgroup: convert to kernfs")
Signed-off-by: Greg Kroah-Hartman

Merge 3.15-rc3 into staging-next

2014-04-28T04:36:39+00:00

kernfs: add back missing error check in kernfs_fop_mmap()

2014-04-25T19:25:13+00:00

While updating how mmap enabled kernfs files are handled by lockdep,
9b2db6e18945 ("sysfs: bail early from kernfs_file_mmap() to avoid
spurious lockdep warning") inadvertently dropped error return check
from kernfs_file_mmap().  The intention was just dropping "if
(ops->mmap)" check as the control won't reach the point if the mmap
callback isn't implemented, but I mistakenly removed the error return
check together with it.

This led to Xorg crash on i810 which was reported and bisected to the
commit and then to the specific change by Tobias.

Signed-off-by: Tejun Heo 
Reported-and-bisected-by: Tobias Powalowski 
Tested-by: Tobias Powalowski 
References: http://lkml.kernel.org/g/533D01BD.1010200@googlemail.com
Cc: stable  # 3.14
Signed-off-by: Greg Kroah-Hartman

kernfs: make kernfs_notify() trigger inotify events too

2014-04-25T18:43:31+00:00

kernfs_notify() is used to indicate either new data is available or
the content of a file has changed.  It currently only triggers poll
which may not be the most convenient to monitor especially when there
are a lot to monitor.  Let's hook it up to fsnotify too so that the
events can be monitored via inotify too.

fsnotify_modify() requires file * but kernfs_notify() doesn't have any
specific file associated; however, we can walk all super_blocks
associated with a kernfs_root and as kernfs always associate one ino
with inode and one dentry with an inode, it's trivial to look up the
dentry associated with a given kernfs_node.  As any active monitor
would pin dentry, just looking up existing dentry is enough.  This
patch looks up the dentry associated with the specified kernfs_node
and generates events equivalent to fsnotify_modify().

Note that as fsnotify doesn't provide fsnotify_modify() equivalent
which can be called with dentry, kernfs_notify() directly calls
fsnotify_parent() and fsnotify().  It might be better to add a wrapper
in fsnotify.h instead.

Signed-off-by: Tejun Heo 
Cc: John McCutchan 
Cc: Robert Love 
Cc: Eric Paris 
Signed-off-by: Greg Kroah-Hartman