4.14-stable review patch. If anyone has any objections, please let me know.
--
commit e58725d51fa8da9133f3f1c54170aa2e43056b91 upstream.
UBIFS's recovery code strictly assumes that a deleted inode will never
come back, therefore it removes all data which belongs to that inode
as
4.9-stable review patch. If anyone has any objections, please let me know.
--
commit e58725d51fa8da9133f3f1c54170aa2e43056b91 upstream.
UBIFS's recovery code strictly assumes that a deleted inode will never
come back, therefore it removes all data which belongs to that inode
as
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Richard Weinberger
commit e58725d51fa8da9133f3f1c54170aa2e43056b91 upstream.
UBIFS's recovery code strictly assumes that a deleted inode will never
come back, therefore it removes all data whi
On Wed, 7 Nov 2018 at 23:04, Richard Weinberger wrote:
> UBIFS's recovery code strictly assumes that a deleted inode will never
> come back, therefore it removes all data which belongs to that inode
> as soon it faces an inode with link count 0 in the replay list.
> Before O_TMPFILE this assumptio
UBIFS's recovery code strictly assumes that a deleted inode will never
come back, therefore it removes all data which belongs to that inode
as soon it faces an inode with link count 0 in the replay list.
Before O_TMPFILE this assumption was perfectly fine. With O_TMPFILE
it can lead to data loss up
Am Donnerstag, 1. November 2018, 09:55:53 CET schrieb Rafał Miłecki:
> On Sun, 28 Oct 2018 at 22:44, Richard Weinberger wrote:
> > UBIFS's recovery code strictly assumes that a deleted inode will never
> > come back, therefore it removes all data which belongs to that inode
> > as soon it faces an
On Sun, 28 Oct 2018 at 22:44, Richard Weinberger wrote:
> UBIFS's recovery code strictly assumes that a deleted inode will never
> come back, therefore it removes all data which belongs to that inode
> as soon it faces an inode with link count 0 in the replay list.
> Before O_TMPFILE this assumpti
UBIFS's recovery code strictly assumes that a deleted inode will never
come back, therefore it removes all data which belongs to that inode
as soon it faces an inode with link count 0 in the replay list.
Before O_TMPFILE this assumption was perfectly fine. With O_TMPFILE
it can lead to data loss
UBIFS's recovery code strictly assumes that a deleted inode will never
come back, therefore it removes all data which belongs to that inode
as soon it faces an inode with link count 0 in the replay list.
Before O_TMPFILE this assumption was perfectly fine. With O_TMPFILE
it can lead to data loss up
I'm not sure why you're sending this to ARM people as I don't believe we
are the ones responsible for this breakage, neither have we had any
visibility of this breakage coming up.
>From what I can see, the mainline state is that we reference user_exit
when CONTEXT_TRACKING is enabled, and kernel/c
On Mon, 18 Jun 2001 09:29:51 +0530,
"Anil Kumar" <[EMAIL PROTECTED]> wrote:
>How do i link the kernel functions such as test_ans_set functions with my
>applications.
You don't. The kernel use the kernel functions, user space
applications use glibc functions, the two do not mix.
-
To unsubscrib
The character device is a good idea!!!
But how would the device's mmap be implemented?
I know how the read and write work, but they copy the data from one space
to another, which would be slow if there is much communication. Because
this looses the benifits of shared memory
About the kernel linki
Thanks for your advice,
I already know one way to accomodate shared memory between a user process
and the kernel.
This is done by making a character device which allocates memory in the
kernel, then from the user appl, using the mmap function of the driver.
I was only wondering why I could not l
13 matches
Mail list logo
