Eric Lee / smarc-fsl-linux-kernel

11 Sep, 2020

1 commit

  • 50f32634f   docs: watch_queue: fix some warnings ... Browse Code »

    Fix those warnings:

    Documentation/watch_queue.rst:108: WARNING: Inline literal start-string without end-string.
    Documentation/watch_queue.rst:108: WARNING: Inline emphasis start-string without end-string.
    Documentation/watch_queue.rst:108: WARNING: Inline emphasis start-string without end-string.
    Documentation/watch_queue.rst:108: WARNING: Inline emphasis start-string without end-string.
    Documentation/watch_queue.rst:185: WARNING: Inline literal start-string without end-string.
    Documentation/watch_queue.rst:185: WARNING: Inline emphasis start-string without end-string.
    Documentation/watch_queue.rst:184: WARNING: Inline emphasis start-string without end-string.

    The problem here is that the ``notation`` doesn't accept
    multi lines. So, replace it to a code block using:

    ::

    notation

    Signed-off-by: Mauro Carvalho Chehab
    Link: https://lore.kernel.org/r/42706310c09a6b4588a1a41078207246ad1238fa.1599660067.git.mchehab+huawei@kernel.org
    Signed-off-by: Jonathan Corbet

    Mauro Carvalho Chehab
     

19 May, 2020

1 commit

  • c73be61ce   pipe: Add general notification queue support ... Browse Code »

    Make it possible to have a general notification queue built on top of a
    standard pipe. Notifications are 'spliced' into the pipe and then read
    out. splice(), vmsplice() and sendfile() are forbidden on pipes used for
    notifications as post_one_notification() cannot take pipe->mutex. This
    means that notifications could be posted in between individual pipe
    buffers, making iov_iter_revert() difficult to effect.

    The way the notification queue is used is:

    (1) An application opens a pipe with a special flag and indicates the
    number of messages it wishes to be able to queue at once (this can
    only be set once):

    pipe2(fds, O_NOTIFICATION_PIPE);
    ioctl(fds[0], IOC_WATCH_QUEUE_SET_SIZE, queue_depth);

    (2) The application then uses poll() and read() as normal to extract data
    from the pipe. read() will return multiple notifications if the
    buffer is big enough, but it will not split a notification across
    buffers - rather it will return a short read or EMSGSIZE.

    Notification messages include a length in the header so that the
    caller can split them up.

    Each message has a header that describes it:

    struct watch_notification {
    __u32 type:24;
    __u32 subtype:8;
    __u32 info;
    };

    The type indicates the source (eg. mount tree changes, superblock events,
    keyring changes, block layer events) and the subtype indicates the event
    type (eg. mount, unmount; EIO, EDQUOT; link, unlink). The info field
    indicates a number of things, including the entry length, an ID assigned to
    a watchpoint contributing to this buffer and type-specific flags.

    Supplementary data, such as the key ID that generated an event, can be
    attached in additional slots. The maximum message size is 127 bytes.
    Messages may not be padded or aligned, so there is no guarantee, for
    example, that the notification type will be on a 4-byte bounary.

    Signed-off-by: David Howells

    David Howells