LDD3 | Notes of Linux Device Driver , 3rd edition

Programs such as cat will read the current input file until it encounters an end-of-file condition or a read error. By convention, a read() return value of 0 indicates an end-of-file condition when a non-zero amount of data is requested. A return value of -1 indicates a read error with the error number in the errno variable.

At the kernel level, the read file operation handler should return 0 to indicate an end-of-file condition (but may also do so when the requested amount in 0), and should return a negated errno value to indicate a read error.

OP's current read file operation handler, my_read, copies the contents of a string literal, "Hello from the kernel world!\n", to the user memory buffer, limited to the requested read amount or the length of the string, whichever is smallest. It never returns an end-of-file condition. The only time it returns 0 is when the requested amount is 0, but that is not a valid end-of-file condition.

One thing that my_read could do is to use the passed in file position information to determine where to start reading, and to limit the amount to be copied. It should update the position accordingly. Then it can return 0 when to indicate end-of-file when there is no more data to be copied. Here is a possible implementation:

This:

What you are reading is merely a warning. It is an unwritten contract between you (kernel module developer) and the kernel. You shouldn't modify the value of jiffies since it is not up to you to do so, and is updated by the kernel according to a set of complicated rules that you should not worry about. The jiffies value is used internally by the scheduler, so bad things can happen modifying it. Chances are that the variable you see in your module is only a thread-local copy of the real one, so modifying could have no effect. In any case, you shouldn't do it. It is only provided to you as additional information that your module might need to know to implement some logic.

Of course, since you are working in C, there is no concept of "permissions" for variables. Anything that is mapped in a readable and writable region of memory can be modified, you could even modify data in read-only memory by changing the permissions first. You can do all sorts of bad stuff if you want. There are a lot of things you're not supposed to alter, even if you have the ability to do so.

Since 3.9 kernel there are no such functions.
In general you're right: seqlock readers should be able to work with inconsistent data.
So if we read the counter, then some interrupt arrives, then we make sure that data is in inconsistent state - just do re-reading.

P.S. LDD3 - this tutorial is quite good, but not so relevant.

In such cases you can do some git investigation. Here it that commit.

In order to see kernel messages, you can use dmesg. Alternatively, you can see the syslog tail var/log/syslog.

device_create() creates a device and registers it with sysfs, and create necessary kobjects.

To create necessary kobjects, kobject-related functions(kobject_init(), kobject_add(), ...) are called in device_create().

If you need to create a device, you should call one of device creation functions like device_create().

The Linux kernel doesn't process /dev/input/mouse*

The kernel is what provides /dev/input/mouse*

Userspace programs like X.org can then read this device and show a cursor moving accordingly.

The message from the commit containing the culprit change, authored by Ming Lei:

block: remove struct request buffer member

This was used in the olden days, back when onions were proper yellow. Basically it mapped to the current buffer to be transferred. With highmem being added more than a decade ago, most drivers map pages out of a bio, and rq->buffer isn't pointing at anything valid.

Convert old style drivers to just use bio_data().

There are some good resources for reading about BIO, such as this post on lwn. A relevant snippet:

char *bio_data(struct bio *bio)

  Returns the kernel virtual address for the data buffer.

So it looks like you will have more success using bio_data(rq->bio) in place of rq->buffer.

Edit by author:
Also found this link which is in two parts and presents in first part the bio layer and in second part the request layer.

What are exactly the <0x0 0x1d 0x4> numbers? I know that, in according to elinux.org, (interrupts = <0x0 0x1d 0x4>;)

Firstly you need to look at the interrupt-parent of the device node, this parent will #interrupt-cells property which specifies number of bits needed to encode a interrupt source, so from your entry interrupts = <0x0 0x1d 0x4>; means the following: