From: Andrew Paniakin
'huge_count_read_write' crashes with segmentation fault when reading
DEPRECATED file of DAMON debugfs interface. This is not causing any
problem for users or other tests because the purpose of the test is just
ensuring the read is not causing kernel warning messages. Nonet
This patch series adds partial file read support to the kernel via
kernel_pread_file functions. request_firmware_into_buf function
enhanced to allow partial file read support and single qcom driver
using existing function updated.
Change to core kernel file support allows new drivers to read
3.16.61-rc1 review patch. If anyone has any objections, please let me know.
--
From: Kiran Kumar Modukuri
commit 934140ab028713a61de8bca58c05332416d037d1 upstream.
cachefiles_read_waiter() has the right to access a 'monitor' object by
virtue of being called under the waitqueue
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Kiran Kumar Modukuri
[ Upstream commit 934140ab028713a61de8bca58c05332416d037d1 ]
cachefiles_read_waiter() has the right to access a 'monitor' object by
virtue of being called under the waitqu
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Kiran Kumar Modukuri
[ Upstream commit 934140ab028713a61de8bca58c05332416d037d1 ]
cachefiles_read_waiter() has the right to access a 'monitor' object by
virtue of being called under the waitque
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Kiran Kumar Modukuri
[ Upstream commit 934140ab028713a61de8bca58c05332416d037d1 ]
cachefiles_read_waiter() has the right to access a 'monitor' object by
virtue of being called under the waitque
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Kiran Kumar Modukuri
[ Upstream commit 934140ab028713a61de8bca58c05332416d037d1 ]
cachefiles_read_waiter() has the right to access a 'monitor' object by
virtue of being called under the waitqu
At the moment we adjust the buffer pointers for reading the trace
data via misc device in the common code for ETF/ETB and ETR. Since
we are going to change how we manage the buffer for ETR, let us
move the buffer manipulation to the respective driver files, hiding
it from the common code. We do so
At the moment we adjust the buffer pointers for reading the trace
data via misc device in the common code for ETF/ETB and ETR. Since
we are going to change how we manage the buffer for ETR, let us
move the buffer manipulation to the respective driver files, hiding
it from the common code. We do so
On Tue, May 01, 2018 at 10:10:37AM +0100, Suzuki K Poulose wrote:
> At the moment we adjust the buffer pointers for reading the trace
> data via misc device in the common code for ETF/ETB and ETR. Since
> we are going to change how we manage the buffer for ETR, let us
> move the buffer manipulation
At the moment we adjust the buffer pointers for reading the trace
data via misc device in the common code for ETF/ETB and ETR. Since
we are going to change how we manage the buffer for ETR, let us
move the buffer manipulation to the respective driver files, hiding
it from the common code. We do so
Currently script can stall if we read certain files (like
/proc/kmsg). While we have a mechanism to skip these files once they are
discovered it would be nice to not stall on as yet undiscovered files of
this kind.
Set a timer before each file is parsed, warn user if timer expires.
Suggested-by:
On 20/10/17 13:34, Julien Thierry wrote:
Hi Suzuki,
On 19/10/17 18:15, Suzuki K Poulose wrote:
At the moment we adjust the buffer pointers for reading the trace
data via misc device in the common code for ETF/ETB and ETR. Since
we are going to change how we manage the buffer for ETR, let us
mov
Hi Suzuki,
On 19/10/17 18:15, Suzuki K Poulose wrote:
At the moment we adjust the buffer pointers for reading the trace
data via misc device in the common code for ETF/ETB and ETR. Since
we are going to change how we manage the buffer for ETR, let us
move the buffer manipulation to the respectiv
At the moment we adjust the buffer pointers for reading the trace
data via misc device in the common code for ETF/ETB and ETR. Since
we are going to change how we manage the buffer for ETR, let us
move the buffer manipulation to the respective driver files, hiding
it from the common code. We do so
3.13.11-ckt30 -stable review patch. If anyone has any objections, please let
me know.
--
From: Mark Salyzyn
commit 569ba74a7ba69f46ce2950bf085b37fea2408385 upstream.
This is the arm64 portion of commit 45cac65b0fcd ("readahead: fault
retry breaks mmap file read r
3.16.7-ckt20 -stable review patch. If anyone has any objections, please let me
know.
--
From: Mark Salyzyn
commit 569ba74a7ba69f46ce2950bf085b37fea2408385 upstream.
This is the arm64 portion of commit 45cac65b0fcd ("readahead: fault
retry breaks mmap file read r
3.19.8-ckt10 -stable review patch. If anyone has any objections, please let me
know.
--
From: Mark Salyzyn
commit 569ba74a7ba69f46ce2950bf085b37fea2408385 upstream.
This is the arm64 portion of commit 45cac65b0fcd ("readahead: fault
retry breaks mmap file read r
From: Mark Salyzyn
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 569ba74a7ba69f46ce2950bf085b37fea2408385 upstream.
This is the arm64 portion of commit 45cac65b0fcd ("readahead: fault
retry breaks mmap file read random detection&quo
4.1-stable review patch. If anyone has any objections, please let me know.
--
From: Mark Salyzyn
commit 569ba74a7ba69f46ce2950bf085b37fea2408385 upstream.
This is the arm64 portion of commit 45cac65b0fcd ("readahead: fault
retry breaks mmap file read random detection&quo
4.2-stable review patch. If anyone has any objections, please let me know.
--
From: Mark Salyzyn
commit 569ba74a7ba69f46ce2950bf085b37fea2408385 upstream.
This is the arm64 portion of commit 45cac65b0fcd ("readahead: fault
retry breaks mmap file read random detection&quo
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: Mark Salyzyn
commit 569ba74a7ba69f46ce2950bf085b37fea2408385 upstream.
This is the arm64 portion of commit 45cac65b0fcd ("readahead: fault
retry breaks mmap file read random dete
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Mark Salyzyn
commit 569ba74a7ba69f46ce2950bf085b37fea2408385 upstream.
This is the arm64 portion of commit 45cac65b0fcd ("readahead: fault
retry breaks mmap file read random dete
mmap file read random detection")
. . .
Yup, arm64 needs this too! Random read improves by 250%, sequential
read improves by 40%, and random write by 400% to an eMMC device with
dm crypto wrapped around it.
Thanks for this. This must've gone in whilst we were developing the initial
versi
On Mon, Sep 21, 2015 at 10:36:40PM +0100, Mark Salyzyn wrote:
> On 09/21/2015 02:09 PM, Will Deacon wrote:
> > On Mon, Sep 21, 2015 at 09:39:50PM +0100, Mark Salyzyn wrote:
> >> Description from commit 45cac65b0fcd
> >> ("readahead: fault retry breaks
On 09/21/2015 02:09 PM, Will Deacon wrote:
On Mon, Sep 21, 2015 at 09:39:50PM +0100, Mark Salyzyn wrote:
Description from commit 45cac65b0fcd
("readahead: fault retry breaks mmap file read random detection")
. . .
Yup, arm64 needs this too! Random read improves by 250%, seque
On Mon, Sep 21, 2015 at 09:39:50PM +0100, Mark Salyzyn wrote:
> Description from commit 45cac65b0fcd
> ("readahead: fault retry breaks mmap file read random detection")
>
> .fault now can retry. The retry can break state machine of .fault. In
> filemap_fault, if pa
Description from commit 45cac65b0fcd
("readahead: fault retry breaks mmap file read random detection")
.fault now can retry. The retry can break state machine of .fault. In
filemap_fault, if page is miss, ra->mmap_miss is increased. In the second
try, since the page is in p
e "comedi_test" application
(part of the "comedilib" installation) modified to use the new ioctls.
There isn't any support in comedilib itself yet.
1) staging: comedi: prepare support for per-file read and write
subdevices
2) staging: comedi: add ioctls to set per-file read
ion of the "comedi_test" application
> (part of the "comedilib" installation) modified to use the new ioctls.
> There isn't any support in comedilib itself yet.
>
> 1) staging: comedi: prepare support for per-file read and write
>subdevices
> 2) stag
Now that Comedi has the structures in place to support setting the
current "read" and/or "write" subdevice on a per-file object basis, add
new ioctls to set them. The newly chosen "read" ("write") subdevice
needs to support "read" ("write") commands, and the file cannot be busy
handling a "read" (
Comedi devices may have several subdevices that support "read" and/or
"write" asynchronous commands that use the "read" or "write" file
operations for data transfer. The low-level Comedi drivers may nominate
a default "read" subdevice and/or a default "write" subdevice, but it
may have other subde
the new ioctls.
There isn't any support in comedilib itself yet.
1) staging: comedi: prepare support for per-file read and write
subdevices
2) staging: comedi: add ioctls to set per-file read and write subdevice
drivers/staging/comedi/comedi.h | 2 +
driver
From: Frederic Weisbecker
When we read a process's procfs stat file, we need
to flush the cputimes of the tasks running in nohz
cpusets in case some childs in the thread group are
running there.
Signed-off-by: Frederic Weisbecker
Cc: Alessio Igor Bogani
Cc: Andrew Morton
Cc: Avi Kivity
Cc: C
Hi Evgeniy,
On Fri, 13 Jul 2007 13:38:51 +0400, Evgeniy Polyakov wrote:
> On Fri, Jul 13, 2007 at 11:26:43AM +0200, Jean Delvare ([EMAIL PROTECTED])
> wrote:
> > Commit 91a6902958f052358899f58683d44e36228d85c2 changed the binary
> > sysfs file signatures at the same time the w1_ds2760 driver was
On Fri, Jul 13, 2007 at 11:26:43AM +0200, Jean Delvare ([EMAIL PROTECTED])
wrote:
> Commit 91a6902958f052358899f58683d44e36228d85c2 changed the binary
> sysfs file signatures at the same time the w1_ds2760 driver was added.
>
> Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
I have no problem wi
Commit 91a6902958f052358899f58683d44e36228d85c2 changed the binary
sysfs file signatures at the same time the w1_ds2760 driver was added.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
---
drivers/w1/slaves/w1_ds2760.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- linux-2.6.
Ack
Works for me. Thanks.
Note:
Both Masami's patch and the relay-file-read-start-pos-fix.patch I posted
earlier are required.
Masami Hiramatsu wrote:
Hi Tom,
Tom Zanussi wrote:
Could you send more info on how to reproduce the problem you're seeing?
And does this pa
On Wed, 2007-06-20 at 17:31 +0900, Masami Hiramatsu wrote:
[...]
> P.S.
> I attached my patch (relay-file-read-overwrite-mode-fix.patch)
> which fixed the problem pointed in previous mail.
>
> Signed-off-by: Masami Hiramatsu <[EMAIL PROTECTED]>
>
Hi,
Thanks for s
1
9818
9817
9819
13912
0
0
780
1625
5723
5721
And, with my patch;
15742
13273
14901
12430
14056
15682
13215
14840
12370
13996
15624
13154
So, I think my patch (which )fixes the problem.
Thanks,
P.S.
I attached my patch (relay-file-read-overwrite-mode-fix.patch)
which fixed the problem pointed
Tom Zanussi wrote:
> Hi,
>
> I haven't had a chance to test it myself yet, but it looks ok to me,
> except for one problem noted below...
Hi,
Thank you so much!
I'm preparing how it can reproduce. I'll send it as soon as possible.
> Thanks for fixing it.
>
>> Signed-off-by: Masami Hiramatsu <[
On Tue, 2007-06-19 at 12:43 +0900, Masami Hiramatsu wrote:
> Hi David and Tom,
>
> David Wilder wrote:
> > This patch fixes a bug in the relay read interface causing the number
> > of consumed bytes to be set incorrectly.
>
> Thank you. Your patch fixes one of my concerns.
> However there is ano
On Tue, 2007-06-19 at 12:43 +0900, Masami Hiramatsu wrote:
> Hi David and Tom,
>
> David Wilder wrote:
> > This patch fixes a bug in the relay read interface causing the number
> > of consumed bytes to be set incorrectly.
>
> Thank you. Your patch fixes one of my concerns.
> However there is ano
Hi David and Tom,
David Wilder wrote:
> This patch fixes a bug in the relay read interface causing the number
> of consumed bytes to be set incorrectly.
Thank you. Your patch fixes one of my concerns.
However there is another bug I found.
When I use relayfs with "overwrite" mode, read() still se
--
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA
[EMAIL PROTECTED]
(503)578-3789
This patch fixes a bug in the relay read interface causing the number
of consumed bytes to be set incorrectly.
Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]>
Signed-off-by: David Wilder <[EMAIL
I wrote some functions for file handling in kernel module.
Check the source : http://linuxkernel.to/klib/klib/src/fileio.c
(The basic idea is from khttpd)
This is part of my personal klib (kernel library) project.
You can download the full source : http://klib.sourceforge.net/download/klib.tar
On 28-May-2001 Mike Castle wrote:
> On Mon, May 28, 2001 at 11:26:31AM -0700, Davide Libenzi wrote:
>>
>> On 28-Jun-2001 Anil Kumar wrote:
>> > hi,
>> > How do i read file within the kernel modules. I hope we can't use the FS
>> > open... calls within kernel.
>>
>> You can access fs methods dir
On Mon, May 28, 2001 at 11:26:31AM -0700, Davide Libenzi wrote:
>
> On 28-Jun-2001 Anil Kumar wrote:
> > hi,
> > How do i read file within the kernel modules. I hope we can't use the FS
> > open... calls within kernel.
>
> You can access fs methods directly.
But generally you don't want to.
Us
On 28-Jun-2001 Anil Kumar wrote:
> hi,
> How do i read file within the kernel modules. I hope we can't use the FS
> open... calls within kernel.
You can access fs methods directly.
Look at this newbie article :
http://www.linux-mag.com/2000-11/gear_01.html
- Davide
-
To unsubscribe from th
hi,
How do i read file within the kernel modules. I hope we can't use the FS
open... calls within kernel.
thanks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.h
50 matches
Mail list logo
