* ping
@ 2011-04-09 11:20 Gáspár Lajos
0 siblings, 0 replies; 15+ messages in thread
From: Gáspár Lajos @ 2011-04-09 11:20 UTC (permalink / raw)
To: netfilter list
pong
^ permalink raw reply [flat|nested] 15+ messages in thread
* ping
@ 2024-10-30 10:32 metux
0 siblings, 0 replies; 15+ messages in thread
From: metux @ 2024-10-30 10:32 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Ping
^ permalink raw reply [flat|nested] 15+ messages in thread
* ping
@ 2024-09-04 6:20 Su Hui
2024-09-04 7:53 ` ping Christian Heusel
0 siblings, 1 reply; 15+ messages in thread
From: Su Hui @ 2024-09-04 6:20 UTC (permalink / raw)
To: kernel-janitors@vger.kernel.org
ping test
^ permalink raw reply [flat|nested] 15+ messages in thread
* Ping
@ 2023-08-13 6:18 ` Manas Ghandat
0 siblings, 0 replies; 15+ messages in thread
From: Manas Ghandat @ 2023-08-13 6:18 UTC (permalink / raw)
To: luisbg, salah.triki
Cc: syzbot+fc26c366038b54261e53, Linux-kernel-mentees, linux-kernel
Just a friendly ping to the patch :)
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 15+ messages in thread
* Ping
@ 2023-08-13 6:18 ` Manas Ghandat
0 siblings, 0 replies; 15+ messages in thread
From: Manas Ghandat @ 2023-08-13 6:18 UTC (permalink / raw)
To: luisbg, salah.triki
Cc: Linux-kernel-mentees, linux-kernel, syzbot+fc26c366038b54261e53
Just a friendly ping to the patch :)
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ping
2023-08-13 6:18 ` Ping Manas Ghandat
@ 2023-08-13 6:25 ` Greg KH
-1 siblings, 0 replies; 15+ messages in thread
From: Greg KH @ 2023-08-13 6:25 UTC (permalink / raw)
To: 20230801155823.206985-1-ghandatmanas
Cc: Linux-kernel-mentees, syzbot+fc26c366038b54261e53, salah.triki,
linux-kernel, luisbg
On Sun, Aug 13, 2023 at 11:48:29AM +0530, Manas Ghandat wrote:
> Just a friendly ping to the patch :)
There was no context here at all as to what patch you are responding to :(
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ping
@ 2023-08-13 6:25 ` Greg KH
0 siblings, 0 replies; 15+ messages in thread
From: Greg KH @ 2023-08-13 6:25 UTC (permalink / raw)
To: 20230801155823.206985-1-ghandatmanas
Cc: luisbg, salah.triki, syzbot+fc26c366038b54261e53,
Linux-kernel-mentees, linux-kernel
On Sun, Aug 13, 2023 at 11:48:29AM +0530, Manas Ghandat wrote:
> Just a friendly ping to the patch :)
There was no context here at all as to what patch you are responding to :(
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ping
2023-08-13 6:25 ` Ping Greg KH
@ 2023-08-13 7:50 ` Willy Tarreau
-1 siblings, 0 replies; 15+ messages in thread
From: Willy Tarreau @ 2023-08-13 7:50 UTC (permalink / raw)
To: Greg KH
Cc: luisbg, salah.triki, 20230801155823.206985-1-ghandatmanas,
linux-kernel, syzbot+fc26c366038b54261e53, Linux-kernel-mentees
On Sun, Aug 13, 2023 at 08:25:17AM +0200, Greg KH wrote:
> On Sun, Aug 13, 2023 at 11:48:29AM +0530, Manas Ghandat wrote:
> > Just a friendly ping to the patch :)
>
> There was no context here at all as to what patch you are responding to :(
I guess it's about this one from the same sender:
[PATCH v4] ntfs : fix shift-out-of-bounds in ntfs_iget
https://lore.kernel.org/lkml/20230813055948.12513-1-ghandatmanas@gmail.com/
Willy
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ping
@ 2023-08-13 7:50 ` Willy Tarreau
0 siblings, 0 replies; 15+ messages in thread
From: Willy Tarreau @ 2023-08-13 7:50 UTC (permalink / raw)
To: Greg KH
Cc: 20230801155823.206985-1-ghandatmanas, luisbg, salah.triki,
syzbot+fc26c366038b54261e53, Linux-kernel-mentees, linux-kernel
On Sun, Aug 13, 2023 at 08:25:17AM +0200, Greg KH wrote:
> On Sun, Aug 13, 2023 at 11:48:29AM +0530, Manas Ghandat wrote:
> > Just a friendly ping to the patch :)
>
> There was no context here at all as to what patch you are responding to :(
I guess it's about this one from the same sender:
[PATCH v4] ntfs : fix shift-out-of-bounds in ntfs_iget
https://lore.kernel.org/lkml/20230813055948.12513-1-ghandatmanas@gmail.com/
Willy
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 1/3] ext4: migrate cleanup
@ 2011-09-17 13:32 Dmitry Monakhov
2011-10-28 20:34 ` Ping Dmitry Monakhov
0 siblings, 1 reply; 15+ messages in thread
From: Dmitry Monakhov @ 2011-09-17 13:32 UTC (permalink / raw)
To: linux-ext4; +Cc: aneesh.kumar, tytso, Dmitry Monakhov
This patch cleanup code a bit, actual logic not changed
- Move current block pointer to migrate_structure, let's all
walk info will be in one structure.
- Get rid of usless null ind-block ptr checks, caller already
does that check.
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
---
fs/ext4/migrate.c | 101 ++++++++++++++++++-----------------------------------
1 files changed, 34 insertions(+), 67 deletions(-)
diff --git a/fs/ext4/migrate.c b/fs/ext4/migrate.c
index b57b98f..e263d78 100644
--- a/fs/ext4/migrate.c
+++ b/fs/ext4/migrate.c
@@ -21,13 +21,14 @@
* The contiguous blocks details which can be
* represented by a single extent
*/
-struct list_blocks_struct {
- ext4_lblk_t first_block, last_block;
+struct migrate_struct {
+ ext4_lblk_t first_block, last_block, curr_block;
ext4_fsblk_t first_pblock, last_pblock;
+
};
static int finish_range(handle_t *handle, struct inode *inode,
- struct list_blocks_struct *lb)
+ struct migrate_struct *lb)
{
int retval = 0, needed;
@@ -87,8 +88,7 @@ err_out:
}
static int update_extent_range(handle_t *handle, struct inode *inode,
- ext4_fsblk_t pblock, ext4_lblk_t blk_num,
- struct list_blocks_struct *lb)
+ ext4_fsblk_t pblock, struct migrate_struct *lb)
{
int retval;
/*
@@ -96,9 +96,10 @@ static int update_extent_range(handle_t *handle, struct inode *inode,
*/
if (lb->first_pblock &&
(lb->last_pblock+1 == pblock) &&
- (lb->last_block+1 == blk_num)) {
+ (lb->last_block+1 == lb->curr_block)) {
lb->last_pblock = pblock;
- lb->last_block = blk_num;
+ lb->last_block = lb->curr_block;
+ lb->curr_block++;
return 0;
}
/*
@@ -106,64 +107,47 @@ static int update_extent_range(handle_t *handle, struct inode *inode,
*/
retval = finish_range(handle, inode, lb);
lb->first_pblock = lb->last_pblock = pblock;
- lb->first_block = lb->last_block = blk_num;
-
+ lb->first_block = lb->last_block = lb->curr_block;
+ lb->curr_block++;
return retval;
}
static int update_ind_extent_range(handle_t *handle, struct inode *inode,
- ext4_fsblk_t pblock, ext4_lblk_t *blk_nump,
- struct list_blocks_struct *lb)
+ ext4_fsblk_t pblock, struct migrate_struct *lb)
{
struct buffer_head *bh;
__le32 *i_data;
int i, retval = 0;
- ext4_lblk_t blk_count = *blk_nump;
unsigned long max_entries = inode->i_sb->s_blocksize >> 2;
- if (!pblock) {
- /* Only update the file block number */
- *blk_nump += max_entries;
- return 0;
- }
-
bh = sb_bread(inode->i_sb, pblock);
if (!bh)
return -EIO;
i_data = (__le32 *)bh->b_data;
- for (i = 0; i < max_entries; i++, blk_count++) {
+ for (i = 0; i < max_entries; i++) {
if (i_data[i]) {
retval = update_extent_range(handle, inode,
- le32_to_cpu(i_data[i]),
- blk_count, lb);
+ le32_to_cpu(i_data[i]), lb);
if (retval)
break;
+ } else {
+ lb->curr_block++;
}
}
-
- /* Update the file block number */
- *blk_nump = blk_count;
put_bh(bh);
return retval;
}
static int update_dind_extent_range(handle_t *handle, struct inode *inode,
- ext4_fsblk_t pblock, ext4_lblk_t *blk_nump,
- struct list_blocks_struct *lb)
+ ext4_fsblk_t pblock, struct migrate_struct *lb)
{
struct buffer_head *bh;
__le32 *i_data;
int i, retval = 0;
- ext4_lblk_t blk_count = *blk_nump;
unsigned long max_entries = inode->i_sb->s_blocksize >> 2;
- if (!pblock) {
- /* Only update the file block number */
- *blk_nump += max_entries * max_entries;
- return 0;
- }
bh = sb_bread(inode->i_sb, pblock);
if (!bh)
return -EIO;
@@ -172,38 +156,27 @@ static int update_dind_extent_range(handle_t *handle, struct inode *inode,
for (i = 0; i < max_entries; i++) {
if (i_data[i]) {
retval = update_ind_extent_range(handle, inode,
- le32_to_cpu(i_data[i]),
- &blk_count, lb);
+ le32_to_cpu(i_data[i]), lb);
if (retval)
break;
} else {
/* Only update the file block number */
- blk_count += max_entries;
+ lb->curr_block += max_entries;
}
}
-
- /* Update the file block number */
- *blk_nump = blk_count;
put_bh(bh);
return retval;
}
static int update_tind_extent_range(handle_t *handle, struct inode *inode,
- ext4_fsblk_t pblock, ext4_lblk_t *blk_nump,
- struct list_blocks_struct *lb)
+ ext4_fsblk_t pblock, struct migrate_struct *lb)
{
struct buffer_head *bh;
__le32 *i_data;
int i, retval = 0;
- ext4_lblk_t blk_count = *blk_nump;
unsigned long max_entries = inode->i_sb->s_blocksize >> 2;
- if (!pblock) {
- /* Only update the file block number */
- *blk_nump += max_entries * max_entries * max_entries;
- return 0;
- }
bh = sb_bread(inode->i_sb, pblock);
if (!bh)
return -EIO;
@@ -211,17 +184,15 @@ static int update_tind_extent_range(handle_t *handle, struct inode *inode,
i_data = (__le32 *)bh->b_data;
for (i = 0; i < max_entries; i++) {
if (i_data[i]) {
- retval = update_dind_extent_range(handle, inode,
- le32_to_cpu(i_data[i]),
- &blk_count, lb);
+ retval = update_ind_extent_range(handle, inode,
+ le32_to_cpu(i_data[i]), lb);
if (retval)
break;
- } else
+ } else {
/* Only update the file block number */
- blk_count += max_entries * max_entries;
+ lb->curr_block += max_entries * max_entries;
+ }
}
- /* Update the file block number */
- *blk_nump = blk_count;
put_bh(bh);
return retval;
@@ -462,10 +433,9 @@ int ext4_ext_migrate(struct inode *inode)
handle_t *handle;
int retval = 0, i;
__le32 *i_data;
- ext4_lblk_t blk_count = 0;
struct ext4_inode_info *ei;
struct inode *tmp_inode = NULL;
- struct list_blocks_struct lb;
+ struct migrate_struct lb;
unsigned long max_entries;
__u32 goal;
@@ -551,35 +521,32 @@ int ext4_ext_migrate(struct inode *inode)
/* 32 bit block address 4 bytes */
max_entries = inode->i_sb->s_blocksize >> 2;
- for (i = 0; i < EXT4_NDIR_BLOCKS; i++, blk_count++) {
+ for (i = 0; i < EXT4_NDIR_BLOCKS; i++) {
if (i_data[i]) {
retval = update_extent_range(handle, tmp_inode,
- le32_to_cpu(i_data[i]),
- blk_count, &lb);
+ le32_to_cpu(i_data[i]), &lb);
if (retval)
goto err_out;
- }
+ } else
+ lb.curr_block++;
}
if (i_data[EXT4_IND_BLOCK]) {
retval = update_ind_extent_range(handle, tmp_inode,
- le32_to_cpu(i_data[EXT4_IND_BLOCK]),
- &blk_count, &lb);
+ le32_to_cpu(i_data[EXT4_IND_BLOCK]), &lb);
if (retval)
goto err_out;
} else
- blk_count += max_entries;
+ lb.curr_block += max_entries;
if (i_data[EXT4_DIND_BLOCK]) {
retval = update_dind_extent_range(handle, tmp_inode,
- le32_to_cpu(i_data[EXT4_DIND_BLOCK]),
- &blk_count, &lb);
+ le32_to_cpu(i_data[EXT4_DIND_BLOCK]), &lb);
if (retval)
goto err_out;
} else
- blk_count += max_entries * max_entries;
+ lb.curr_block += max_entries * max_entries;
if (i_data[EXT4_TIND_BLOCK]) {
retval = update_tind_extent_range(handle, tmp_inode,
- le32_to_cpu(i_data[EXT4_TIND_BLOCK]),
- &blk_count, &lb);
+ le32_to_cpu(i_data[EXT4_TIND_BLOCK]), &lb);
if (retval)
goto err_out;
}
--
1.7.2.3
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: Ping...
2011-09-17 13:32 [PATCH 1/3] ext4: migrate cleanup Dmitry Monakhov
@ 2011-10-28 20:34 ` Dmitry Monakhov
0 siblings, 0 replies; 15+ messages in thread
From: Dmitry Monakhov @ 2011-10-28 20:34 UTC (permalink / raw)
To: tytso; +Cc: aneesh.kumar, linux-ext4, adilger
On Sat, 17 Sep 2011 17:32:57 +0400, Dmitry Monakhov <dmonakhov@openvz.org> wrote:
Can you please take a look at this three patches.
IMHO first two patches are simple and clean.
Last one may be good start point for discussion.
I do understand Andreas's point, and we may warn that fsck
is necessary, but still. We need MIGRATE flag to mark
temporal inode which not owns data blocks.
> This patch cleanup code a bit, actual logic not changed
> - Move current block pointer to migrate_structure, let's all
> walk info will be in one structure.
> - Get rid of usless null ind-block ptr checks, caller already
> does that check.
>
> Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
> ---
> fs/ext4/migrate.c | 101 ++++++++++++++++++-----------------------------------
> 1 files changed, 34 insertions(+), 67 deletions(-)
>
> diff --git a/fs/ext4/migrate.c b/fs/ext4/migrate.c
> index b57b98f..e263d78 100644
> --- a/fs/ext4/migrate.c
> +++ b/fs/ext4/migrate.c
> @@ -21,13 +21,14 @@
> * The contiguous blocks details which can be
> * represented by a single extent
> */
> -struct list_blocks_struct {
> - ext4_lblk_t first_block, last_block;
> +struct migrate_struct {
> + ext4_lblk_t first_block, last_block, curr_block;
> ext4_fsblk_t first_pblock, last_pblock;
> +
> };
>
> static int finish_range(handle_t *handle, struct inode *inode,
> - struct list_blocks_struct *lb)
> + struct migrate_struct *lb)
>
> {
> int retval = 0, needed;
> @@ -87,8 +88,7 @@ err_out:
> }
>
> static int update_extent_range(handle_t *handle, struct inode *inode,
> - ext4_fsblk_t pblock, ext4_lblk_t blk_num,
> - struct list_blocks_struct *lb)
> + ext4_fsblk_t pblock, struct migrate_struct *lb)
> {
> int retval;
> /*
> @@ -96,9 +96,10 @@ static int update_extent_range(handle_t *handle, struct inode *inode,
> */
> if (lb->first_pblock &&
> (lb->last_pblock+1 == pblock) &&
> - (lb->last_block+1 == blk_num)) {
> + (lb->last_block+1 == lb->curr_block)) {
> lb->last_pblock = pblock;
> - lb->last_block = blk_num;
> + lb->last_block = lb->curr_block;
> + lb->curr_block++;
> return 0;
> }
> /*
> @@ -106,64 +107,47 @@ static int update_extent_range(handle_t *handle, struct inode *inode,
> */
> retval = finish_range(handle, inode, lb);
> lb->first_pblock = lb->last_pblock = pblock;
> - lb->first_block = lb->last_block = blk_num;
> -
> + lb->first_block = lb->last_block = lb->curr_block;
> + lb->curr_block++;
> return retval;
> }
>
> static int update_ind_extent_range(handle_t *handle, struct inode *inode,
> - ext4_fsblk_t pblock, ext4_lblk_t *blk_nump,
> - struct list_blocks_struct *lb)
> + ext4_fsblk_t pblock, struct migrate_struct *lb)
> {
> struct buffer_head *bh;
> __le32 *i_data;
> int i, retval = 0;
> - ext4_lblk_t blk_count = *blk_nump;
> unsigned long max_entries = inode->i_sb->s_blocksize >> 2;
>
> - if (!pblock) {
> - /* Only update the file block number */
> - *blk_nump += max_entries;
> - return 0;
> - }
> -
> bh = sb_bread(inode->i_sb, pblock);
> if (!bh)
> return -EIO;
>
> i_data = (__le32 *)bh->b_data;
> - for (i = 0; i < max_entries; i++, blk_count++) {
> + for (i = 0; i < max_entries; i++) {
> if (i_data[i]) {
> retval = update_extent_range(handle, inode,
> - le32_to_cpu(i_data[i]),
> - blk_count, lb);
> + le32_to_cpu(i_data[i]), lb);
> if (retval)
> break;
> + } else {
> + lb->curr_block++;
> }
> }
> -
> - /* Update the file block number */
> - *blk_nump = blk_count;
> put_bh(bh);
> return retval;
>
> }
>
> static int update_dind_extent_range(handle_t *handle, struct inode *inode,
> - ext4_fsblk_t pblock, ext4_lblk_t *blk_nump,
> - struct list_blocks_struct *lb)
> + ext4_fsblk_t pblock, struct migrate_struct *lb)
> {
> struct buffer_head *bh;
> __le32 *i_data;
> int i, retval = 0;
> - ext4_lblk_t blk_count = *blk_nump;
> unsigned long max_entries = inode->i_sb->s_blocksize >> 2;
>
> - if (!pblock) {
> - /* Only update the file block number */
> - *blk_nump += max_entries * max_entries;
> - return 0;
> - }
> bh = sb_bread(inode->i_sb, pblock);
> if (!bh)
> return -EIO;
> @@ -172,38 +156,27 @@ static int update_dind_extent_range(handle_t *handle, struct inode *inode,
> for (i = 0; i < max_entries; i++) {
> if (i_data[i]) {
> retval = update_ind_extent_range(handle, inode,
> - le32_to_cpu(i_data[i]),
> - &blk_count, lb);
> + le32_to_cpu(i_data[i]), lb);
> if (retval)
> break;
> } else {
> /* Only update the file block number */
> - blk_count += max_entries;
> + lb->curr_block += max_entries;
> }
> }
> -
> - /* Update the file block number */
> - *blk_nump = blk_count;
> put_bh(bh);
> return retval;
>
> }
>
> static int update_tind_extent_range(handle_t *handle, struct inode *inode,
> - ext4_fsblk_t pblock, ext4_lblk_t *blk_nump,
> - struct list_blocks_struct *lb)
> + ext4_fsblk_t pblock, struct migrate_struct *lb)
> {
> struct buffer_head *bh;
> __le32 *i_data;
> int i, retval = 0;
> - ext4_lblk_t blk_count = *blk_nump;
> unsigned long max_entries = inode->i_sb->s_blocksize >> 2;
>
> - if (!pblock) {
> - /* Only update the file block number */
> - *blk_nump += max_entries * max_entries * max_entries;
> - return 0;
> - }
> bh = sb_bread(inode->i_sb, pblock);
> if (!bh)
> return -EIO;
> @@ -211,17 +184,15 @@ static int update_tind_extent_range(handle_t *handle, struct inode *inode,
> i_data = (__le32 *)bh->b_data;
> for (i = 0; i < max_entries; i++) {
> if (i_data[i]) {
> - retval = update_dind_extent_range(handle, inode,
> - le32_to_cpu(i_data[i]),
> - &blk_count, lb);
> + retval = update_ind_extent_range(handle, inode,
> + le32_to_cpu(i_data[i]), lb);
> if (retval)
> break;
> - } else
> + } else {
> /* Only update the file block number */
> - blk_count += max_entries * max_entries;
> + lb->curr_block += max_entries * max_entries;
> + }
> }
> - /* Update the file block number */
> - *blk_nump = blk_count;
> put_bh(bh);
> return retval;
>
> @@ -462,10 +433,9 @@ int ext4_ext_migrate(struct inode *inode)
> handle_t *handle;
> int retval = 0, i;
> __le32 *i_data;
> - ext4_lblk_t blk_count = 0;
> struct ext4_inode_info *ei;
> struct inode *tmp_inode = NULL;
> - struct list_blocks_struct lb;
> + struct migrate_struct lb;
> unsigned long max_entries;
> __u32 goal;
>
> @@ -551,35 +521,32 @@ int ext4_ext_migrate(struct inode *inode)
>
> /* 32 bit block address 4 bytes */
> max_entries = inode->i_sb->s_blocksize >> 2;
> - for (i = 0; i < EXT4_NDIR_BLOCKS; i++, blk_count++) {
> + for (i = 0; i < EXT4_NDIR_BLOCKS; i++) {
> if (i_data[i]) {
> retval = update_extent_range(handle, tmp_inode,
> - le32_to_cpu(i_data[i]),
> - blk_count, &lb);
> + le32_to_cpu(i_data[i]), &lb);
> if (retval)
> goto err_out;
> - }
> + } else
> + lb.curr_block++;
> }
> if (i_data[EXT4_IND_BLOCK]) {
> retval = update_ind_extent_range(handle, tmp_inode,
> - le32_to_cpu(i_data[EXT4_IND_BLOCK]),
> - &blk_count, &lb);
> + le32_to_cpu(i_data[EXT4_IND_BLOCK]), &lb);
> if (retval)
> goto err_out;
> } else
> - blk_count += max_entries;
> + lb.curr_block += max_entries;
> if (i_data[EXT4_DIND_BLOCK]) {
> retval = update_dind_extent_range(handle, tmp_inode,
> - le32_to_cpu(i_data[EXT4_DIND_BLOCK]),
> - &blk_count, &lb);
> + le32_to_cpu(i_data[EXT4_DIND_BLOCK]), &lb);
> if (retval)
> goto err_out;
> } else
> - blk_count += max_entries * max_entries;
> + lb.curr_block += max_entries * max_entries;
> if (i_data[EXT4_TIND_BLOCK]) {
> retval = update_tind_extent_range(handle, tmp_inode,
> - le32_to_cpu(i_data[EXT4_TIND_BLOCK]),
> - &blk_count, &lb);
> + le32_to_cpu(i_data[EXT4_TIND_BLOCK]), &lb);
> if (retval)
> goto err_out;
> }
> --
> 1.7.2.3
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 0/5] RFC: introduce extended inode owner identifier v6
@ 2010-03-18 14:02 Dmitry Monakhov
2010-04-06 9:00 ` Ping Dmitry Monakhov
0 siblings, 1 reply; 15+ messages in thread
From: Dmitry Monakhov @ 2010-03-18 14:02 UTC (permalink / raw)
To: linux-ext4
Cc: linux-fsdevel, tytso, adilger, hch, jack, david, viro, xemul,
Dmitry Monakhov
This is 6'th version of extened inode owner patch-set.
Please review it tell me what do you think about all this.
Are you agree with this approach?
Are you worry about some implementation details?
Is it ready for merge to some devel's tree?
*Feature description*
1) Inode may has a project identifier which has same meaning as uid/gid.
2) Id is stored in inode's xattr named "system.project_id"
3) Id is inherent from parent inode on creation.
4) This id is cached in memory inode structure vfs_inode->i_prjid
This field it restricted by CONFIG_PROJECT_ID. So no wasting
of memory happens.
5) Since id is cached in memory it may be used for different purposes
such as:
5A) Implement additional quota id space orthogonal to uid/gid. This is
useful in managing quota for some filesystem hierarchy(chroot or
container over bindmount)
5B) Export dedicated fs hierarchy to nfsd (only inode which has some
project_id will be accessible via nfsd)
6) It is possible to create isolated project's subtree.
Note: Please do not blame isolation feature before you read the
isolation patch description, and than please wellcome.
*User interface *
Project id is managed via generic xattr interface "system.project_id"
This good because
1) We may use already existing interface.
2) xattr already supported by generic urils tar/rsync and etc
PATCH SET TOC:
1) generic projectid support
2) generic project quota support
3) ext4 project support implementation
3A) ext4: generic project support
3B) ext4: project quota support
3C) ext4: project isolation support. This patch is not principal
but makes ext4 implementation rename behaviour equotals
to XFS
Patch against linux-next-20100318
Changes against v5
- convert dquota_transfer to struct iattr interface. Not it is possible
to change i_prjid via notify_changes()
- some bugfixes.
^ permalink raw reply [flat|nested] 15+ messages in thread* Ping.
2010-03-18 14:02 [PATCH 0/5] RFC: introduce extended inode owner identifier v6 Dmitry Monakhov
@ 2010-04-06 9:00 ` Dmitry Monakhov
2010-04-13 18:14 ` Ping Christoph Hellwig
0 siblings, 1 reply; 15+ messages in thread
From: Dmitry Monakhov @ 2010-04-06 9:00 UTC (permalink / raw)
To: linux-ext4; +Cc: linux-fsdevel, tytso, adilger, hch, jack, david, viro, xemul
Dmitry Monakhov <dmonakhov@openvz.org> writes:
> This is 6'th version of extened inode owner patch-set.
> Please review it tell me what do you think about all this.
> Are you agree with this approach?
> Are you worry about some implementation details?
> Is it ready for merge to some devel's tree?
Ping. I haven't got response about the patchset, just small note about
xattr-name from Andreas.
Please clarify what do you think about whole idea and
current patch-set state. What do i have to do to make a progress?
>
> *Feature description*
> 1) Inode may has a project identifier which has same meaning as uid/gid.
> 2) Id is stored in inode's xattr named "system.project_id"
> 3) Id is inherent from parent inode on creation.
> 4) This id is cached in memory inode structure vfs_inode->i_prjid
> This field it restricted by CONFIG_PROJECT_ID. So no wasting
> of memory happens.
>
> 5) Since id is cached in memory it may be used for different purposes
> such as:
> 5A) Implement additional quota id space orthogonal to uid/gid. This is
> useful in managing quota for some filesystem hierarchy(chroot or
> container over bindmount)
> 5B) Export dedicated fs hierarchy to nfsd (only inode which has some
> project_id will be accessible via nfsd)
>
> 6) It is possible to create isolated project's subtree.
> Note: Please do not blame isolation feature before you read the
> isolation patch description, and than please wellcome.
>
> *User interface *
> Project id is managed via generic xattr interface "system.project_id"
> This good because
> 1) We may use already existing interface.
> 2) xattr already supported by generic urils tar/rsync and etc
>
> PATCH SET TOC:
> 1) generic projectid support
> 2) generic project quota support
> 3) ext4 project support implementation
> 3A) ext4: generic project support
> 3B) ext4: project quota support
> 3C) ext4: project isolation support. This patch is not principal
> but makes ext4 implementation rename behaviour equotals
> to XFS
>
> Patch against linux-next-20100318
> Changes against v5
> - convert dquota_transfer to struct iattr interface. Not it is possible
> to change i_prjid via notify_changes()
> - some bugfixes.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ping.
2010-04-06 9:00 ` Ping Dmitry Monakhov
@ 2010-04-13 18:14 ` Christoph Hellwig
2010-04-15 11:30 ` Ping Dmitry Monakhov
0 siblings, 1 reply; 15+ messages in thread
From: Christoph Hellwig @ 2010-04-13 18:14 UTC (permalink / raw)
To: Dmitry Monakhov
Cc: linux-ext4, linux-fsdevel, tytso, adilger, hch, jack, david, viro,
xemul
On Tue, Apr 06, 2010 at 01:00:58PM +0400, Dmitry Monakhov wrote:
> Dmitry Monakhov <dmonakhov@openvz.org> writes:
>
> > This is 6'th version of extened inode owner patch-set.
> > Please review it tell me what do you think about all this.
> > Are you agree with this approach?
> > Are you worry about some implementation details?
> > Is it ready for merge to some devel's tree?
> Ping. I haven't got response about the patchset, just small note about
> xattr-name from Andreas.
> Please clarify what do you think about whole idea and
> current patch-set state. What do i have to do to make a progress?
As long as you still have the awkward ifdefs and different semantics for
"isolation" vs "not" there's still a NACK from me. But in the end Al
will have to decide if he wants to take your patches or not.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ping.
2010-04-13 18:14 ` Ping Christoph Hellwig
@ 2010-04-15 11:30 ` Dmitry Monakhov
2010-05-15 9:34 ` Ping Al Viro
0 siblings, 1 reply; 15+ messages in thread
From: Dmitry Monakhov @ 2010-04-15 11:30 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-ext4, linux-fsdevel, tytso, adilger, jack, david, viro,
xemul
Christoph Hellwig <hch@infradead.org> writes:
> On Tue, Apr 06, 2010 at 01:00:58PM +0400, Dmitry Monakhov wrote:
>> Dmitry Monakhov <dmonakhov@openvz.org> writes:
>>
>> > This is 6'th version of extened inode owner patch-set.
>> > Please review it tell me what do you think about all this.
>> > Are you agree with this approach?
>> > Are you worry about some implementation details?
>> > Is it ready for merge to some devel's tree?
>> Ping. I haven't got response about the patchset, just small note about
>> xattr-name from Andreas.
>> Please clarify what do you think about whole idea and
>> current patch-set state. What do i have to do to make a progress?
>
> As long as you still have the awkward ifdefs and different semantics for
About ifdefs style:
How can i avoid CONFIG_PROJECT_ID without bloating inode size?
embedded people will kill me for this.
I just act similar quota code, or you want protect prjid logic
via quota config option?
I don't remember, are we already talk about this?
If so please remind me your vision.
> "isolation" vs "not" there's still a NACK from me. But in the end Al
> will have to decide if he wants to take your patches or not.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ping.
2010-04-15 11:30 ` Ping Dmitry Monakhov
@ 2010-05-15 9:34 ` Al Viro
0 siblings, 0 replies; 15+ messages in thread
From: Al Viro @ 2010-05-15 9:34 UTC (permalink / raw)
To: Dmitry Monakhov
Cc: Christoph Hellwig, linux-ext4, linux-fsdevel, tytso, adilger,
jack, david, xemul
On Thu, Apr 15, 2010 at 03:30:58PM +0400, Dmitry Monakhov wrote:
> > As long as you still have the awkward ifdefs and different semantics for
> About ifdefs style:
> How can i avoid CONFIG_PROJECT_ID without bloating inode size?
> embedded people will kill me for this.
> I just act similar quota code, or you want protect prjid logic
> via quota config option?
> I don't remember, are we already talk about this?
> If so please remind me your vision.
You have way more ifdefs than just that.
E.g. struct iattr ones are pure junk; it's not kept around for long
time. Moreover, since ATTR_... is not userland-reachable, you can
bloody well #define ATTR_PRJID to 0 and get rid of more ifdefs.
Ifdefs due to accesses to i_prjid can be reduced to just two inlined
helpers (get_prjid/set_prjid) and there you go...
As for the ->i_prjid itself, I'd buy ifdef there, but _not_ in that
place within structure. You are shoving it between two pointers;
think of alignment.
As for the isolation... Why do we care about link/rename at all?
All stuff with the same project ID gets counted together, wherever
in the tree it might be. It's not as if we'd been scanning a subtree
and calculate the sum over it, after all. So what is the problem?
Some bastard DoSing you by creating links from places you can't write
to? Then you want as much isolation as possible anyway, TYVM, and
bind-as-link-barrier is entirely appropriate there.
> > "isolation" vs "not" there's still a NACK from me. But in the end Al
> > will have to decide if he wants to take your patches or not.
I want details on use cases and semantics for isolation stuff; as it is,
it looks rather odd. Why move towards "neutral" part of the tree is
allowed and links over there are not, for example?
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2024-10-30 10:32 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-04-09 11:20 ping Gáspár Lajos
-- strict thread matches above, loose matches on Subject: below --
2024-10-30 10:32 ping metux
2024-09-04 6:20 ping Su Hui
2024-09-04 7:53 ` ping Christian Heusel
2023-08-13 6:18 Ping Manas Ghandat
2023-08-13 6:18 ` Ping Manas Ghandat
2023-08-13 6:25 ` Ping Greg KH
2023-08-13 6:25 ` Ping Greg KH
2023-08-13 7:50 ` Ping Willy Tarreau
2023-08-13 7:50 ` Ping Willy Tarreau
2011-09-17 13:32 [PATCH 1/3] ext4: migrate cleanup Dmitry Monakhov
2011-10-28 20:34 ` Ping Dmitry Monakhov
2010-03-18 14:02 [PATCH 0/5] RFC: introduce extended inode owner identifier v6 Dmitry Monakhov
2010-04-06 9:00 ` Ping Dmitry Monakhov
2010-04-13 18:14 ` Ping Christoph Hellwig
2010-04-15 11:30 ` Ping Dmitry Monakhov
2010-05-15 9:34 ` Ping Al Viro
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.