Am 17.04.2017 um 17:27 schrieb Ralph Sennhauser:
> Hi Amir, Richard
>
> Looks like the fix didn't make it into 4.11-rc7 either, isn't it time
> to just disable O_TMPFILE support in ubifs for now? Giving plenty
> time for the proper fix.
As I said to Amir, don't panic. I'm *very* busy right now
Am 17.04.2017 um 17:27 schrieb Ralph Sennhauser:
> Hi Amir, Richard
>
> Looks like the fix didn't make it into 4.11-rc7 either, isn't it time
> to just disable O_TMPFILE support in ubifs for now? Giving plenty
> time for the proper fix.
As I said to Amir, don't panic. I'm *very* busy right now
On Tue, 11 Apr 2017 18:04:50 +0300
Amir Goldstein wrote:
> On Tue, Apr 11, 2017 at 1:50 PM, Richard Weinberger
> wrote:
> > Hi!
> >
> > Am 11.04.2017 um 12:20 schrieb Amir Goldstein:
> >> On Thu, Apr 6, 2017 at 3:26 PM, Richard Weinberger
> >>
On Tue, 11 Apr 2017 18:04:50 +0300
Amir Goldstein wrote:
> On Tue, Apr 11, 2017 at 1:50 PM, Richard Weinberger
> wrote:
> > Hi!
> >
> > Am 11.04.2017 um 12:20 schrieb Amir Goldstein:
> >> On Thu, Apr 6, 2017 at 3:26 PM, Richard Weinberger
> >> wrote:
> >>> Am 06.04.2017 um 14:09 schrieb
On Tue, Apr 11, 2017 at 1:50 PM, Richard Weinberger wrote:
> Hi!
>
> Am 11.04.2017 um 12:20 schrieb Amir Goldstein:
>> On Thu, Apr 6, 2017 at 3:26 PM, Richard Weinberger wrote:
>>> Am 06.04.2017 um 14:09 schrieb Richard Weinberger:
> Were you able to make any
On Tue, Apr 11, 2017 at 1:50 PM, Richard Weinberger wrote:
> Hi!
>
> Am 11.04.2017 um 12:20 schrieb Amir Goldstein:
>> On Thu, Apr 6, 2017 at 3:26 PM, Richard Weinberger wrote:
>>> Am 06.04.2017 um 14:09 schrieb Richard Weinberger:
> Were you able to make any progress? still working on this?
Hi!
Am 11.04.2017 um 12:20 schrieb Amir Goldstein:
> On Thu, Apr 6, 2017 at 3:26 PM, Richard Weinberger wrote:
>> Am 06.04.2017 um 14:09 schrieb Richard Weinberger:
Were you able to make any progress? still working on this?
If this is too complicated to get in for this
Hi!
Am 11.04.2017 um 12:20 schrieb Amir Goldstein:
> On Thu, Apr 6, 2017 at 3:26 PM, Richard Weinberger wrote:
>> Am 06.04.2017 um 14:09 schrieb Richard Weinberger:
Were you able to make any progress? still working on this?
If this is too complicated to get in for this cycle, better
On Thu, Apr 6, 2017 at 3:26 PM, Richard Weinberger wrote:
> Am 06.04.2017 um 14:09 schrieb Richard Weinberger:
>>> Were you able to make any progress? still working on this?
>>> If this is too complicated to get in for this cycle, better send a patch
>>> to disable O_TMPFILE
On Thu, Apr 6, 2017 at 3:26 PM, Richard Weinberger wrote:
> Am 06.04.2017 um 14:09 schrieb Richard Weinberger:
>>> Were you able to make any progress? still working on this?
>>> If this is too complicated to get in for this cycle, better send a patch
>>> to disable O_TMPFILE support for ubifs and
Am 06.04.2017 um 14:09 schrieb Richard Weinberger:
>> Were you able to make any progress? still working on this?
>> If this is too complicated to get in for this cycle, better send a patch
>> to disable O_TMPFILE support for ubifs and fix the problem properly on
>> followup merge cycle.
>> Because
Am 06.04.2017 um 14:09 schrieb Richard Weinberger:
>> Were you able to make any progress? still working on this?
>> If this is too complicated to get in for this cycle, better send a patch
>> to disable O_TMPFILE support for ubifs and fix the problem properly on
>> followup merge cycle.
>> Because
Amir,
Am 06.04.2017 um 14:06 schrieb Amir Goldstein:
> On Thu, Mar 30, 2017 at 3:27 PM, Richard Weinberger wrote:
>> Am 30.03.2017 um 13:57 schrieb Adrian Hunter:
Reading deeper into the proved that I was wrong.
AFAIKT UBIFS' journal has currently no way to revive a
Amir,
Am 06.04.2017 um 14:06 schrieb Amir Goldstein:
> On Thu, Mar 30, 2017 at 3:27 PM, Richard Weinberger wrote:
>> Am 30.03.2017 um 13:57 schrieb Adrian Hunter:
Reading deeper into the proved that I was wrong.
AFAIKT UBIFS' journal has currently no way to revive a deleted inode.
On Thu, Mar 30, 2017 at 3:27 PM, Richard Weinberger wrote:
> Am 30.03.2017 um 13:57 schrieb Adrian Hunter:
>>> Reading deeper into the proved that I was wrong.
>>> AFAIKT UBIFS' journal has currently no way to revive a deleted inode.
>>> So, we have to think about a new solution.
On Thu, Mar 30, 2017 at 3:27 PM, Richard Weinberger wrote:
> Am 30.03.2017 um 13:57 schrieb Adrian Hunter:
>>> Reading deeper into the proved that I was wrong.
>>> AFAIKT UBIFS' journal has currently no way to revive a deleted inode.
>>> So, we have to think about a new solution.
>>
>> Deleting
Am 30.03.2017 um 13:57 schrieb Adrian Hunter:
>> Reading deeper into the proved that I was wrong.
>> AFAIKT UBIFS' journal has currently no way to revive a deleted inode.
>> So, we have to think about a new solution.
>
> Deleting the orphan looks right. Just need to understand whether the
>
Am 30.03.2017 um 13:57 schrieb Adrian Hunter:
>> Reading deeper into the proved that I was wrong.
>> AFAIKT UBIFS' journal has currently no way to revive a deleted inode.
>> So, we have to think about a new solution.
>
> Deleting the orphan looks right. Just need to understand whether the
>
On 30/03/17 13:23, Richard Weinberger wrote:
> Am 30.03.2017 um 11:49 schrieb Richard Weinberger:
>> Am 30.03.2017 um 11:32 schrieb Adrian Hunter:
diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
index 0858213a4e63..0139155045fe 100644
--- a/fs/ubifs/dir.c
+++ b/fs/ubifs/dir.c
On 30/03/17 13:23, Richard Weinberger wrote:
> Am 30.03.2017 um 11:49 schrieb Richard Weinberger:
>> Am 30.03.2017 um 11:32 schrieb Adrian Hunter:
diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
index 0858213a4e63..0139155045fe 100644
--- a/fs/ubifs/dir.c
+++ b/fs/ubifs/dir.c
Amir,
Am 30.03.2017 um 12:35 schrieb Amir Goldstein:
>> Reading deeper into the proved that I was wrong.
>> AFAIKT UBIFS' journal has currently no way to revive a deleted inode.
>> So, we have to think about a new solution.
>>
>
> Not that I know anything about ubifs, but why do you need the
Amir,
Am 30.03.2017 um 12:35 schrieb Amir Goldstein:
>> Reading deeper into the proved that I was wrong.
>> AFAIKT UBIFS' journal has currently no way to revive a deleted inode.
>> So, we have to think about a new solution.
>>
>
> Not that I know anything about ubifs, but why do you need the
On Thu, Mar 30, 2017 at 1:23 PM, Richard Weinberger wrote:
> Am 30.03.2017 um 11:49 schrieb Richard Weinberger:
>> Am 30.03.2017 um 11:32 schrieb Adrian Hunter:
diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
index 0858213a4e63..0139155045fe 100644
--- a/fs/ubifs/dir.c
On Thu, Mar 30, 2017 at 1:23 PM, Richard Weinberger wrote:
> Am 30.03.2017 um 11:49 schrieb Richard Weinberger:
>> Am 30.03.2017 um 11:32 schrieb Adrian Hunter:
diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
index 0858213a4e63..0139155045fe 100644
--- a/fs/ubifs/dir.c
+++
Richard,
On Thu, Mar 30, 2017 at 10:56:21AM +0200, Richard Weinberger wrote:
> It is perfectly fine to link a tmpfile back using linkat().
> Since tmpfiles are created with a link count of 0 they appear
> on the orphan list, upon re-linking the inode has to be removed
> from the orphan list
Richard,
On Thu, Mar 30, 2017 at 10:56:21AM +0200, Richard Weinberger wrote:
> It is perfectly fine to link a tmpfile back using linkat().
> Since tmpfiles are created with a link count of 0 they appear
> on the orphan list, upon re-linking the inode has to be removed
> from the orphan list
Am 30.03.2017 um 11:49 schrieb Richard Weinberger:
> Am 30.03.2017 um 11:32 schrieb Adrian Hunter:
>>> diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
>>> index 0858213a4e63..0139155045fe 100644
>>> --- a/fs/ubifs/dir.c
>>> +++ b/fs/ubifs/dir.c
>>> @@ -748,6 +748,11 @@ static int ubifs_link(struct
Am 30.03.2017 um 11:49 schrieb Richard Weinberger:
> Am 30.03.2017 um 11:32 schrieb Adrian Hunter:
>>> diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
>>> index 0858213a4e63..0139155045fe 100644
>>> --- a/fs/ubifs/dir.c
>>> +++ b/fs/ubifs/dir.c
>>> @@ -748,6 +748,11 @@ static int ubifs_link(struct
Am 30.03.2017 um 11:32 schrieb Adrian Hunter:
>> diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
>> index 0858213a4e63..0139155045fe 100644
>> --- a/fs/ubifs/dir.c
>> +++ b/fs/ubifs/dir.c
>> @@ -748,6 +748,11 @@ static int ubifs_link(struct dentry *old_dentry, struct
>> inode *dir,
>>
Am 30.03.2017 um 11:32 schrieb Adrian Hunter:
>> diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
>> index 0858213a4e63..0139155045fe 100644
>> --- a/fs/ubifs/dir.c
>> +++ b/fs/ubifs/dir.c
>> @@ -748,6 +748,11 @@ static int ubifs_link(struct dentry *old_dentry, struct
>> inode *dir,
>>
On 30/03/17 11:56, Richard Weinberger wrote:
> It is perfectly fine to link a tmpfile back using linkat().
> Since tmpfiles are created with a link count of 0 they appear
> on the orphan list, upon re-linking the inode has to be removed
> from the orphan list again.
>
> Cc:
On 30/03/17 11:56, Richard Weinberger wrote:
> It is perfectly fine to link a tmpfile back using linkat().
> Since tmpfiles are created with a link count of 0 they appear
> on the orphan list, upon re-linking the inode has to be removed
> from the orphan list again.
>
> Cc:
> Cc: Ralph
Amir,
Am 30.03.2017 um 10:59 schrieb Amir Goldstein:
> On Thu, Mar 30, 2017 at 11:56 AM, Richard Weinberger wrote:
>> It is perfectly fine to link a tmpfile back using linkat().
>> Since tmpfiles are created with a link count of 0 they appear
>> on the orphan list, upon
Amir,
Am 30.03.2017 um 10:59 schrieb Amir Goldstein:
> On Thu, Mar 30, 2017 at 11:56 AM, Richard Weinberger wrote:
>> It is perfectly fine to link a tmpfile back using linkat().
>> Since tmpfiles are created with a link count of 0 they appear
>> on the orphan list, upon re-linking the inode has
On Thu, 30 Mar 2017 11:59:17 +0300
Amir Goldstein wrote:
> On Thu, Mar 30, 2017 at 11:56 AM, Richard Weinberger
> wrote:
> > It is perfectly fine to link a tmpfile back using linkat().
> > Since tmpfiles are created with a link count of 0 they appear
> > on
On Thu, 30 Mar 2017 11:59:17 +0300
Amir Goldstein wrote:
> On Thu, Mar 30, 2017 at 11:56 AM, Richard Weinberger
> wrote:
> > It is perfectly fine to link a tmpfile back using linkat().
> > Since tmpfiles are created with a link count of 0 they appear
> > on the orphan list, upon re-linking the
Amir,
Am 30.03.2017 um 11:07 schrieb Amir Goldstein:
> On Thu, Mar 30, 2017 at 12:03 PM, Richard Weinberger wrote:
>> Amir,
>>
>> Am 30.03.2017 um 10:59 schrieb Amir Goldstein:
>>> On Thu, Mar 30, 2017 at 11:56 AM, Richard Weinberger wrote:
It is perfectly
Amir,
Am 30.03.2017 um 11:07 schrieb Amir Goldstein:
> On Thu, Mar 30, 2017 at 12:03 PM, Richard Weinberger wrote:
>> Amir,
>>
>> Am 30.03.2017 um 10:59 schrieb Amir Goldstein:
>>> On Thu, Mar 30, 2017 at 11:56 AM, Richard Weinberger wrote:
It is perfectly fine to link a tmpfile back using
On Thu, Mar 30, 2017 at 12:03 PM, Richard Weinberger wrote:
> Amir,
>
> Am 30.03.2017 um 10:59 schrieb Amir Goldstein:
>> On Thu, Mar 30, 2017 at 11:56 AM, Richard Weinberger wrote:
>>> It is perfectly fine to link a tmpfile back using linkat().
>>> Since tmpfiles
On Thu, Mar 30, 2017 at 12:03 PM, Richard Weinberger wrote:
> Amir,
>
> Am 30.03.2017 um 10:59 schrieb Amir Goldstein:
>> On Thu, Mar 30, 2017 at 11:56 AM, Richard Weinberger wrote:
>>> It is perfectly fine to link a tmpfile back using linkat().
>>> Since tmpfiles are created with a link count
On Thu, Mar 30, 2017 at 11:56 AM, Richard Weinberger wrote:
> It is perfectly fine to link a tmpfile back using linkat().
> Since tmpfiles are created with a link count of 0 they appear
> on the orphan list, upon re-linking the inode has to be removed
> from the orphan list again.
On Thu, Mar 30, 2017 at 11:56 AM, Richard Weinberger wrote:
> It is perfectly fine to link a tmpfile back using linkat().
> Since tmpfiles are created with a link count of 0 they appear
> on the orphan list, upon re-linking the inode has to be removed
> from the orphan list again.
>
Looks good.
It is perfectly fine to link a tmpfile back using linkat().
Since tmpfiles are created with a link count of 0 they appear
on the orphan list, upon re-linking the inode has to be removed
from the orphan list again.
Cc:
Cc: Ralph Sennhauser
Cc:
It is perfectly fine to link a tmpfile back using linkat().
Since tmpfiles are created with a link count of 0 they appear
on the orphan list, upon re-linking the inode has to be removed
from the orphan list again.
Cc:
Cc: Ralph Sennhauser
Cc: Amir Goldstein
Tested-by: Ralph Sennhauser
44 matches
Mail list logo