Re: [PATCH v27 00/10] NTFS read-write driver GPL implementation by Paragon Software

Re: [PATCH v27 00/10] NTFS read-write driver GPL implementation by Paragon Software

[Kari Argillander]

On Thu, Aug 12, 2021 at 08:03:26PM +0300, Kari Argillander wrote:
> On Sun, Aug 01, 2021 at 11:23:16PM -0400, Theodore Ts'o wrote:
> > On Thu, Jul 29, 2021 at 09:24:59AM -0700, Darrick J. Wong wrote:
> > > 
> > > I have the same (still unanswered) questions as last time:
> > > 
> > > 1. What happens when you run ntfs3 through fstests with '-g all'?  I get
> > > that the pass rate isn't going to be as high with ntfs3 as it is with
> > > ext4/xfs/btrfs, but fstests can be adapted (see the recent attempts to
> > > get exfat under test).
> > 
> > Indeed, it's not that hard at all.  I've included a patch to
> > xfstests-bld[1] so that you can just run "kvm-xfstests -c ntfs3 -g
> > auto".
> > 
> > Konstantin, I would *strongly* encourage you to try running fstests,
> > about 60 seconds into a run, we discover that generic/013 will trigger
> > locking problems that could lead to deadlocks.
> 
> It seems at least at my testing that if acl option is used then
> generic/013 will pass. I have tested this with old linux-next commit
> 5a4cee98ea757e1a2a1354b497afdf8fafc30a20 I have still some of my own
> code in it but I will test this tomorrow so I can be sure.
> 
> It also seems that acl support is broken. I also suspect ntfs-3g mkfs in
> some failure cases. So maybe ntfs-3g mkfs will give different result than
> Paragons mkfs. It would be nice to test with Paragons mkfs software or
> that Paragon will test with ntfs-3g.

I have made more testing and it was actually my code which cause 013 not
fail. It is still pretty strange. I have made code for new mount api (fs
context) and 013 still get deadlock but still test will pass. This only
happends if acl is on. Though this is intresting why this happends. I
will not use more time for this now. I will try to focus fs context
mount api for now.

Re: [PATCH] Restyle comments to better align with kernel-doc

[Konstantin Komarov]

On 03.08.2021 14:57, Kari Argillander wrote:
> Capitalize comments and end with period for better reading.
> 
> Also function comments are now little more kernel-doc style. This way we
> can easily convert them to kernel-doc style if we want. Note that these
> are not yet complete with this style. Example function comments start
> with /* and in kernel-doc style they start /**.
> 
> Use imperative mood in function descriptions.
> 
> Change words like ntfs -> NTFS, linux -> Linux.
> 
> Use "we" not "I" when commenting code.
> 
> Signed-off-by: Kari Argillander <kari.argillander@gmail.com>
> ---
> Yes I know that this patch is quite monster. That's why I try to send this
> now before patch series get merged. After that this patch probebly needs to
> be splitted more and sended in patch series.
> 
> If someone thinks this should not be added now it is ok. I have try to read
> what is kernel philosophy in case "patch to patch" but haven't found any
> good information about it. It is no big deal to add later. In my own mind I
> do not want to touch so much comments after code is in.
> 
> I also don't know how easy this kind of patch is apply top of the patch
> series.

Thanks for the patch. I've applied it to create uniform style of comments.

Also removed double line addition from patch:

@@ -269,22 +260,28 @@ enum RECORD_FLAG {
 	RECORD_FLAG_UNKNOWN	= cpu_to_le16(0x0008),
 };

-/* MFT Record structure */
+/* MFT Record structure, */
 struct MFT_REC {
 	struct NTFS_RECORD_HEADER rhdr; // 'FILE'

-	__le16 seq;		// 0x10: Sequence number for this record
-	__le16 hard_links;	// 0x12: The number of hard links to record
-	__le16 attr_off;	// 0x14: Offset to attributes
-	__le16 flags;		// 0x16: See RECORD_FLAG
-	__le32 used;		// 0x18: The size of used part
-	__le32 total;		// 0x1C: Total record size
+	__le16 seq;		// 0x10: Sequence number for this record.
+	__le16 hard_links;	// 0x12: The number of hard links to record.
+	__le16 attr_off;	// 0x14: Offset to attributes.
+	__le16 flags;		// 0x16: See RECORD_FLAG.
+	__le32 used;		// 0x18: The size of used part.
+	__le32 total;		// 0x1C: Total record size.
+
+	struct MFT_REF parent_ref; // 0x20: Parent MFT record.
+	__le16 next_attr_id;	// 0x28: The next attribute Id.

-	struct MFT_REF parent_ref; // 0x20: Parent MFT record
-	__le16 next_attr_id;	// 0x28: The next attribute Id
+	__le32 used;		// 0x18: The size of used part.
+	__le32 total;		// 0x1C: Total record size.

-	__le16 res;		// 0x2A: High part of mft record?
-	__le32 mft_record;	// 0x2C: Current mft record number
+	struct MFT_REF parent_ref; // 0x20: Parent MFT record.
+	__le16 next_attr_id;	// 0x28: The next attribute Id.
+
+	__le16 res;		// 0x2A: High part of MFT record?
+	__le32 mft_record;	// 0x2C: Current MFT record number.
 	__le16 fixups[];	// 0x30:
 };

Re: [PATCH] Restyle comments to better align with kernel-doc

[Kari Argillander]

On Mon, Aug 30, 2021 at 07:10:36PM +0300, Konstantin Komarov wrote:
> 
> 
> On 03.08.2021 14:57, Kari Argillander wrote:
> > Capitalize comments and end with period for better reading.
> > 
> > Also function comments are now little more kernel-doc style. This way we
> > can easily convert them to kernel-doc style if we want. Note that these
> > are not yet complete with this style. Example function comments start
> > with /* and in kernel-doc style they start /**.
> > 
> > Use imperative mood in function descriptions.
> > 
> > Change words like ntfs -> NTFS, linux -> Linux.
> > 
> > Use "we" not "I" when commenting code.
> > 
> > Signed-off-by: Kari Argillander <kari.argillander@gmail.com>
> > ---
> > Yes I know that this patch is quite monster. That's why I try to send this
> > now before patch series get merged. After that this patch probebly needs to
> > be splitted more and sended in patch series.
> > 
> > If someone thinks this should not be added now it is ok. I have try to read
> > what is kernel philosophy in case "patch to patch" but haven't found any
> > good information about it. It is no big deal to add later. In my own mind I
> > do not want to touch so much comments after code is in.
> > 
> > I also don't know how easy this kind of patch is apply top of the patch
> > series.
> 
> Thanks for the patch. I've applied it to create uniform style of comments.

There where probably lot of merge conflicts as this patch was made for
v27. Also lot of changes since v28 in the code base. You can always ask
submitter to rebase patch and resend. Also there where quite lot of nack
about this patch so I though this should be dropped, but maintainer
decision I guess.

> Also removed double line addition from patch:

Just ask and submitter will do it for you.

> 
> @@ -269,22 +260,28 @@ enum RECORD_FLAG {
>  	RECORD_FLAG_UNKNOWN	= cpu_to_le16(0x0008),
>  };
> 
> -/* MFT Record structure */
> +/* MFT Record structure, */
>  struct MFT_REC {
>  	struct NTFS_RECORD_HEADER rhdr; // 'FILE'
> 
> -	__le16 seq;		// 0x10: Sequence number for this record
> -	__le16 hard_links;	// 0x12: The number of hard links to record
> -	__le16 attr_off;	// 0x14: Offset to attributes
> -	__le16 flags;		// 0x16: See RECORD_FLAG
> -	__le32 used;		// 0x18: The size of used part
> -	__le32 total;		// 0x1C: Total record size
> +	__le16 seq;		// 0x10: Sequence number for this record.
> +	__le16 hard_links;	// 0x12: The number of hard links to record.
> +	__le16 attr_off;	// 0x14: Offset to attributes.
> +	__le16 flags;		// 0x16: See RECORD_FLAG.
> +	__le32 used;		// 0x18: The size of used part.
> +	__le32 total;		// 0x1C: Total record size.
> +
> +	struct MFT_REF parent_ref; // 0x20: Parent MFT record.
> +	__le16 next_attr_id;	// 0x28: The next attribute Id.
> 
> -	struct MFT_REF parent_ref; // 0x20: Parent MFT record
> -	__le16 next_attr_id;	// 0x28: The next attribute Id
> +	__le32 used;		// 0x18: The size of used part.
> +	__le32 total;		// 0x1C: Total record size.
> 
> -	__le16 res;		// 0x2A: High part of mft record?
> -	__le32 mft_record;	// 0x2C: Current mft record number
> +	struct MFT_REF parent_ref; // 0x20: Parent MFT record.
> +	__le16 next_attr_id;	// 0x28: The next attribute Id.
> +
> +	__le16 res;		// 0x2A: High part of MFT record?
> +	__le32 mft_record;	// 0x2C: Current MFT record number.
>  	__le16 fixups[];	// 0x30:
>  };
>