It's OK now.
Thanks,
Hu
On 2015/5/11 13:12, Jaegeuk Kim wrote:
> Hi Hujianynag,
>
> I just fixed it up, and rebased the dev branch.
> Could you check them out?
>
> Thanks,
>
> On Mon, May 11, 2015 at 10:52:48AM +0800, hujianyang wrote:
>> Hi Jaegeuk,
It's OK now.
Thanks,
Hu
On 2015/5/11 13:12, Jaegeuk Kim wrote:
Hi Hujianynag,
I just fixed it up, and rebased the dev branch.
Could you check them out?
Thanks,
On Mon, May 11, 2015 at 10:52:48AM +0800, hujianyang wrote:
Hi Jaegeuk,
While compiling
git://git.kernel.org/pub/scm
Hi Jaegeuk,
While compiling git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git
branch dev(commit 5af6e74892a f2fs crypto: remove checking key context during
lookup),
I saw an error:
fs/f2fs/dir.c: In function ‘find_in_level’:
fs/f2fs/dir.c:163: error: unknown field ‘len’ specified
Hi Jaegeuk,
While compiling git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git
branch dev(commit 5af6e74892a f2fs crypto: remove checking key context during
lookup),
I saw an error:
fs/f2fs/dir.c: In function ‘find_in_level’:
fs/f2fs/dir.c:163: error: unknown field ‘len’ specified
Hi Nick,
I'm not quite sure about if it is a correct modification. But,
On 2015/1/16 10:18, nick wrote:
> drivers/mtd/inftlmount.c:336:12: warning: ‘check_free_sectors’ defined but
> not used [-Wunused-function]
check if this function is still called by other functions, if it
is not, just
Hi Nick,
I'm not quite sure about if it is a correct modification. But,
On 2015/1/16 10:18, nick wrote:
drivers/mtd/inftlmount.c:336:12: warning: ‘check_free_sectors’ defined but
not used [-Wunused-function]
check if this function is still called by other functions, if it
is not, just remove
No need to check set->nr_hw_queues twice in blk_mq_alloc_tag_set(),
remove the latter one.
Signed-off-by: hujianyang
---
block/blk-mq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index a7d4a98..eddeccc 100644
--- a/block/blk-m
No need to check set-nr_hw_queues twice in blk_mq_alloc_tag_set(),
remove the latter one.
Signed-off-by: hujianyang hujiany...@huawei.com
---
block/blk-mq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index a7d4a98..eddeccc 100644
On 2015/1/8 20:41, Seunghun Lee wrote:
> When file system is mounted read-only workdir is not needed.
>
> Signed-off-by: Seunghun Lee
> ---
> fs/overlayfs/super.c | 35 +++
> 1 file changed, 23 insertions(+), 12 deletions(-)
>
> diff --git a/fs/overlayfs/super.c
On 2015/1/8 20:41, Seunghun Lee wrote:
When file system is mounted read-only workdir is not needed.
Signed-off-by: Seunghun Lee way...@gmail.com
---
fs/overlayfs/super.c | 35 +++
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git
Hi,
There maybe some misunderstandings here. I think your patch really
fix an important problem, but not in correct way.
On 2015/1/6 22:02, Seunghun Lee wrote:
>
> After patch:
> root@qemux86:~# mount -t overlay overlay -olowerdir=lower:lower2 merged
> mount: warning: merged seems to be mounted
Hi,
There maybe some misunderstandings here. I think your patch really
fix an important problem, but not in correct way.
On 2015/1/6 22:02, Seunghun Lee wrote:
After patch:
root@qemux86:~# mount -t overlay overlay -olowerdir=lower:lower2 merged
mount: warning: merged seems to be mounted
On 2015/1/3 1:26, Seunghun Lee wrote:
> Overlayfs should be mounted read-only when upper-fs is read-only or
> nonexistent.
> But now it can be remounted read-write and this can cause kernel panic.
> So we should prevent read-write remount when the above situation happens.
>
> Signed-off-by:
On 2015/1/3 1:26, Seunghun Lee wrote:
Overlayfs should be mounted read-only when upper-fs is read-only or
nonexistent.
But now it can be remounted read-write and this can cause kernel panic.
So we should prevent read-write remount when the above situation happens.
Signed-off-by: Seunghun
On 2014/12/29 22:15, Tanya Brokhman wrote:
> Hi Hu,
>
> On 12/29/2014 5:14 AM, hujianyang wrote:
>> On 2014/11/3 21:58, Tanya Brokhman wrote:
>>> If there is more then one UBI device mounted, there is no way to
>>> distinguish between messages from different U
On 2014/12/29 22:15, Tanya Brokhman wrote:
Hi Hu,
On 12/29/2014 5:14 AM, hujianyang wrote:
On 2014/11/3 21:58, Tanya Brokhman wrote:
If there is more then one UBI device mounted, there is no way to
distinguish between messages from different UBI devices.
Add device number to all ubi layer
On 2014/11/3 21:58, Tanya Brokhman wrote:
> If there is more then one UBI device mounted, there is no way to
> distinguish between messages from different UBI devices.
> Add device number to all ubi layer message types.
>
> The R/O block driver messages were replaced by pr_* since
> ubi_device
On 2014/11/3 21:58, Tanya Brokhman wrote:
If there is more then one UBI device mounted, there is no way to
distinguish between messages from different UBI devices.
Add device number to all ubi layer message types.
The R/O block driver messages were replaced by pr_* since
ubi_device
On 2014/11/5 23:35, Artem Bityutskiy wrote:
> On Mon, 2014-11-03 at 15:58 +0200, Tanya Brokhman wrote:
>> If there is more then one UBI device mounted, there is no way to
>> distinguish between messages from different UBI devices.
>> Add device number to all ubi layer message types.
>>
>> The R/O
On 2014/11/5 23:35, Artem Bityutskiy wrote:
On Mon, 2014-11-03 at 15:58 +0200, Tanya Brokhman wrote:
If there is more then one UBI device mounted, there is no way to
distinguish between messages from different UBI devices.
Add device number to all ubi layer message types.
The R/O block
Hi Tanya,
On 2014/11/3 1:14, Tanya Brokhman wrote:
>>
>> This patch add 'struct ubi_device *' for 3 functions. We can get
>> 'ubi_device' from
>> 'ubi_volume'. So I think it's because when we call these functions, the
>> '->ubi'
>> pointer of 'ubi_volume' is not initialized, am I right? This
Hi Tanya,
On 2014/11/3 1:14, Tanya Brokhman wrote:
This patch add 'struct ubi_device *' for 3 functions. We can get
'ubi_device' from
'ubi_volume'. So I think it's because when we call these functions, the
'-ubi'
pointer of 'ubi_volume' is not initialized, am I right? This patch use
On 2014/10/31 16:09, Richard Weinberger wrote:
> Hujianyang,
>
> Am 31.10.2014 um 05:03 schrieb hujianyang:
>> Hi Artem and Richard,
>>
>> We are using atomic operation, leb_change(), for master_node
>> in ubifs-level. We use two lebs for master_node even i
On 2014/10/31 16:09, Richard Weinberger wrote:
Hujianyang,
Am 31.10.2014 um 05:03 schrieb hujianyang:
Hi Artem and Richard,
We are using atomic operation, leb_change(), for master_node
in ubifs-level. We use two lebs for master_node even if they
are changed with atomic operation.
I
On 2014/10/30 16:55, Artem Bityutskiy wrote:
> On Sat, 2014-10-25 at 19:43 +0200, Richard Weinberger wrote:
>> This is more a cosmetic change than a fix.
>> By using ubi_eba_atomic_leb_change()
>> we can guarantee that the first VTBL record is always
>> correct and we don't really need the second
On 2014/10/30 16:55, Artem Bityutskiy wrote:
On Sat, 2014-10-25 at 19:43 +0200, Richard Weinberger wrote:
This is more a cosmetic change than a fix.
By using ubi_eba_atomic_leb_change()
we can guarantee that the first VTBL record is always
correct and we don't really need the second one
On 2014/10/24 11:33, hujianyang wrote:
>
>> @@ -1798,15 +1803,18 @@ int ubi_thread(void *u)
>> int failures = 0;
>> struct ubi_device *ubi = u;
>>
>> -ubi_msg("background thread \"%s\" started, PID %d",
>>
Hi Tanya,
When I was trying to push this patch to my product, I reviewed this patch
and found some small problems. I wish it's not too late to report these.
The patch I get from linux-ubifs.git is amended a bit by Artem. I'd like to
quote your V5 patch for simplification. Some line numbers may
Hi Tanya,
When I was trying to push this patch to my product, I reviewed this patch
and found some small problems. I wish it's not too late to report these.
The patch I get from linux-ubifs.git is amended a bit by Artem. I'd like to
quote your V5 patch for simplification. Some line numbers may
On 2014/10/24 11:33, hujianyang wrote:
@@ -1798,15 +1803,18 @@ int ubi_thread(void *u)
int failures = 0;
struct ubi_device *ubi = u;
-ubi_msg(background thread \%s\ started, PID %d,
+ubi_msg(ubi, background thread \%s\ started, PID %d,
ubi-bgt_name
It seems useful~!
I'd like to do some test with it~
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
It seems useful~!
I'd like to do some test with it~
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ling with
this problem now. I'm very glad if someone else could help us.
Thanks~!
Hu
On 2014/9/9 10:34, hujianyang wrote:
> Changes from v1:
>
>* Move audit_inode() to the beginning of O_CREAT case in
> lookup_open() to avoid missing audit for ROFS error. This
>
~!
Hu
On 2014/9/9 10:34, hujianyang wrote:
Changes from v1:
* Move audit_inode() to the beginning of O_CREAT case in
lookup_open() to avoid missing audit for ROFS error. This
lack is spotted by Jeff Layton jeff.lay...@primarydata.com
commit 33e2208acfc1
audit: vfs: fix
ter of struct filename as a parameter of
lookup_open(). By doing this, the records of both create and write
are correct.
Signed-off-by: hujianyang
---
fs/namei.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index a996bb4..ca4a831 100644
of
lookup_open(). By doing this, the records of both create and write
are correct.
Signed-off-by: hujianyang hujiany...@huawei.com
---
fs/namei.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index a996bb4..ca4a831 100644
--- a/fs/namei.c
+++ b
dit for create operation to where a file
really need to be created, the O_CREAT case in lookup_open().
We have to add the pointer of struct filename as a parameter of
lookup_open(). By doing this, the records of both create and write
are correct.
Signed-off-by: hujianyang
---
fs/namei.c | 9 ++---
1
, the O_CREAT case in lookup_open().
We have to add the pointer of struct filename as a parameter of
lookup_open(). By doing this, the records of both create and write
are correct.
Signed-off-by: hujianyang hujiany...@huawei.com
---
fs/namei.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions
38 matches
Mail list logo
