<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/fs/udf, branch v5.7</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>change email address for Pali Rohár</title>
<updated>2020-04-10T22:36:22+00:00</updated>
<author>
<name>Pali Rohár</name>
<email>pali@kernel.org</email>
</author>
<published>2020-04-10T21:34:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=149ed3d404c9bd00f0fadc35215a9e7a54c5cfd0'/>
<id>149ed3d404c9bd00f0fadc35215a9e7a54c5cfd0</id>
<content type='text'>
For security reasons I stopped using gmail account and kernel address is
now up-to-date alias to my personal address.

People periodically send me emails to address which they found in source
code of drivers, so this change reflects state where people can contact
me.

[ Added .mailmap entry as per Joe Perches  - Linus ]
Signed-off-by: Pali Rohár &lt;pali@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Joe Perches &lt;joe@perches.com&gt;
Link: http://lkml.kernel.org/r/20200307104237.8199-1-pali@kernel.org
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For security reasons I stopped using gmail account and kernel address is
now up-to-date alias to my personal address.

People periodically send me emails to address which they found in source
code of drivers, so this change reflects state where people can contact
me.

[ Added .mailmap entry as per Joe Perches  - Linus ]
Signed-off-by: Pali Rohár &lt;pali@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Joe Perches &lt;joe@perches.com&gt;
Link: http://lkml.kernel.org/r/20200307104237.8199-1-pali@kernel.org
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>udf: udf_sb.h: Replace zero-length array with flexible-array member</title>
<updated>2020-03-16T14:57:09+00:00</updated>
<author>
<name>Gustavo A. R. Silva</name>
<email>gustavo@embeddedor.com</email>
</author>
<published>2020-03-09T20:27:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3fc131663cec7ca8e05bf25d99cecc2ab56bc50d'/>
<id>3fc131663cec7ca8e05bf25d99cecc2ab56bc50d</id>
<content type='text'>
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Link: https://lore.kernel.org/r/20200309202715.GA9428@embeddedor
Signed-off-by: Gustavo A. R. Silva &lt;gustavo@embeddedor.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Link: https://lore.kernel.org/r/20200309202715.GA9428@embeddedor
Signed-off-by: Gustavo A. R. Silva &lt;gustavo@embeddedor.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>udf: Clarify meaning of f_files in udf_statfs</title>
<updated>2020-01-20T12:59:41+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2020-01-17T11:36:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=356557be8670ffdb6dc01cc2702e3614bcf64310'/>
<id>356557be8670ffdb6dc01cc2702e3614bcf64310</id>
<content type='text'>
UDF does not have separate preallocated table of inodes. So similarly to
XFS we pretend that every free block is also a free inode in statfs(2)
output. Clarify this in a comment.

Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
UDF does not have separate preallocated table of inodes. So similarly to
XFS we pretend that every free block is also a free inode in statfs(2)
output. Clarify this in a comment.

Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>udf: Allow writing to 'Rewritable' partitions</title>
<updated>2020-01-20T12:59:17+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2020-01-17T11:11:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=15fb05fd286ac57a0802d71624daeb5c1c2d5b07'/>
<id>15fb05fd286ac57a0802d71624daeb5c1c2d5b07</id>
<content type='text'>
UDF 2.60 standard states in section 2.2.14.2:

    A partition with Access Type 3 (rewritable) shall define a Freed
    Space Bitmap or a Freed Space Table, see 2.3.3. All other partitions
    shall not define a Freed Space Bitmap or a Freed Space Table.

    Rewritable partitions are used on media that require some form of
    preprocessing before re-writing data (for example legacy MO). Such
    partitions shall use Access Type 3.

    Overwritable partitions are used on media that do not require
    preprocessing before overwriting data (for example: CD-RW, DVD-RW,
    DVD+RW, DVD-RAM, BD-RE, HD DVD-Rewritable). Such partitions shall
    use Access Type 4.

however older versions of the standard didn't have this wording and
there are tools out there that create UDF filesystems with rewritable
partitions but that don't contain a Freed Space Bitmap or a Freed Space
Table on media that does not require pre-processing before overwriting a
block. So instead of forcing media with rewritable partition read-only,
base this decision on presence of a Freed Space Bitmap or a Freed Space
Table.

Reported-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Reviewed-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Fixes: b085fbe2ef7f ("udf: Fix crash during mount")
Link: https://lore.kernel.org/linux-fsdevel/20200112144735.hj2emsoy4uwsouxz@pali
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
UDF 2.60 standard states in section 2.2.14.2:

    A partition with Access Type 3 (rewritable) shall define a Freed
    Space Bitmap or a Freed Space Table, see 2.3.3. All other partitions
    shall not define a Freed Space Bitmap or a Freed Space Table.

    Rewritable partitions are used on media that require some form of
    preprocessing before re-writing data (for example legacy MO). Such
    partitions shall use Access Type 3.

    Overwritable partitions are used on media that do not require
    preprocessing before overwriting data (for example: CD-RW, DVD-RW,
    DVD+RW, DVD-RAM, BD-RE, HD DVD-Rewritable). Such partitions shall
    use Access Type 4.

however older versions of the standard didn't have this wording and
there are tools out there that create UDF filesystems with rewritable
partitions but that don't contain a Freed Space Bitmap or a Freed Space
Table on media that does not require pre-processing before overwriting a
block. So instead of forcing media with rewritable partition read-only,
base this decision on presence of a Freed Space Bitmap or a Freed Space
Table.

Reported-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Reviewed-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Fixes: b085fbe2ef7f ("udf: Fix crash during mount")
Link: https://lore.kernel.org/linux-fsdevel/20200112144735.hj2emsoy4uwsouxz@pali
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>udf: Disallow R/W mode for disk with Metadata partition</title>
<updated>2020-01-13T11:40:17+00:00</updated>
<author>
<name>Pali Rohár</name>
<email>pali.rohar@gmail.com</email>
</author>
<published>2020-01-12T14:49:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=57debb815459d2ef3e25aacfe355307d14b73a91'/>
<id>57debb815459d2ef3e25aacfe355307d14b73a91</id>
<content type='text'>
Currently we do not support writing to UDF disks with Metadata partition.
There is already check that disks with declared minimal write revision to
UDF 2.50 or higher are mounted only in R/O mode but this does not cover
situation when minimal write revision is set incorrectly (e.g. to 2.01).

Link: https://lore.kernel.org/r/20200112144959.28104-1-pali.rohar@gmail.com
Signed-off-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently we do not support writing to UDF disks with Metadata partition.
There is already check that disks with declared minimal write revision to
UDF 2.50 or higher are mounted only in R/O mode but this does not cover
situation when minimal write revision is set incorrectly (e.g. to 2.01).

Link: https://lore.kernel.org/r/20200112144959.28104-1-pali.rohar@gmail.com
Signed-off-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>udf: Fix meaning of ENTITYID_FLAGS_* macros to be really bitwise-or flags</title>
<updated>2020-01-13T11:38:46+00:00</updated>
<author>
<name>Pali Rohár</name>
<email>pali.rohar@gmail.com</email>
</author>
<published>2020-01-12T22:13:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=49be68c4931d9f0f171e5f01a574fc40205db2b5'/>
<id>49be68c4931d9f0f171e5f01a574fc40205db2b5</id>
<content type='text'>
Currently ENTITYID_FLAGS_* macros definitions are written as hex numbers
but their meaning is not bitwise-or flags. But rather bit position. This is
unusual and could be misleading. So change meaning of ENTITYID_FLAGS_*
macros definitions to be really bitwise-or flags.

Link: https://lore.kernel.org/r/20200112221353.29711-1-pali.rohar@gmail.com
Signed-off-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently ENTITYID_FLAGS_* macros definitions are written as hex numbers
but their meaning is not bitwise-or flags. But rather bit position. This is
unusual and could be misleading. So change meaning of ENTITYID_FLAGS_*
macros definitions to be really bitwise-or flags.

Link: https://lore.kernel.org/r/20200112221353.29711-1-pali.rohar@gmail.com
Signed-off-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>udf: Fix free space reporting for metadata and virtual partitions</title>
<updated>2020-01-09T17:38:18+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2020-01-07T15:36:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a4a8b99ec819ca60b49dc582a4287ef03411f117'/>
<id>a4a8b99ec819ca60b49dc582a4287ef03411f117</id>
<content type='text'>
Free space on filesystems with metadata or virtual partition maps
currently gets misreported. This is because these partitions are just
remapped onto underlying real partitions from which keep track of free
blocks. Take this remapping into account when counting free blocks as
well.

Reviewed-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Reported-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Free space on filesystems with metadata or virtual partition maps
currently gets misreported. This is because these partitions are just
remapped onto underlying real partitions from which keep track of free
blocks. Take this remapping into account when counting free blocks as
well.

Reviewed-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Reported-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>udf: Update header files to UDF 2.60</title>
<updated>2020-01-08T10:12:20+00:00</updated>
<author>
<name>Pali Rohár</name>
<email>pali.rohar@gmail.com</email>
</author>
<published>2020-01-07T21:29:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=614644676394951e73194ea96b3f026c1adf5443'/>
<id>614644676394951e73194ea96b3f026c1adf5443</id>
<content type='text'>
This change synchronizes header files ecma_167.h and osta_udf.h with
udftools 2.2 project which already has definitions for UDF 2.60 revision.

Link: https://lore.kernel.org/r/20200107212904.30471-3-pali.rohar@gmail.com
Signed-off-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This change synchronizes header files ecma_167.h and osta_udf.h with
udftools 2.2 project which already has definitions for UDF 2.60 revision.

Link: https://lore.kernel.org/r/20200107212904.30471-3-pali.rohar@gmail.com
Signed-off-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>udf: Move OSTA Identifier Suffix macros from ecma_167.h to osta_udf.h</title>
<updated>2020-01-08T10:12:18+00:00</updated>
<author>
<name>Pali Rohár</name>
<email>pali.rohar@gmail.com</email>
</author>
<published>2020-01-07T21:29:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=871b9b14c673d862b2f24478ed3583a40906ea66'/>
<id>871b9b14c673d862b2f24478ed3583a40906ea66</id>
<content type='text'>
Rename structure name and its members to match naming convention and fix
endianity type for UDFRevision member. Also remove duplicate definition of
UDF_ID_COMPLIANT which is already in osta_udf.h.

Link: https://lore.kernel.org/r/20200107212904.30471-2-pali.rohar@gmail.com
Signed-off-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Rename structure name and its members to match naming convention and fix
endianity type for UDFRevision member. Also remove duplicate definition of
UDF_ID_COMPLIANT which is already in osta_udf.h.

Link: https://lore.kernel.org/r/20200107212904.30471-2-pali.rohar@gmail.com
Signed-off-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>udf: Fix spelling in EXT_NEXT_EXTENT_ALLOCDESCS</title>
<updated>2020-01-08T10:11:46+00:00</updated>
<author>
<name>Pali Rohár</name>
<email>pali.rohar@gmail.com</email>
</author>
<published>2020-01-07T21:29:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=800552ceecc749aa4e87c95291be232c80bd1e56'/>
<id>800552ceecc749aa4e87c95291be232c80bd1e56</id>
<content type='text'>
Change EXT_NEXT_EXTENT_ALLOCDECS to proper spelling
EXT_NEXT_EXTENT_ALLOCDESCS.

Link: https://lore.kernel.org/r/20200107212904.30471-1-pali.rohar@gmail.com
Signed-off-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Change EXT_NEXT_EXTENT_ALLOCDECS to proper spelling
EXT_NEXT_EXTENT_ALLOCDESCS.

Link: https://lore.kernel.org/r/20200107212904.30471-1-pali.rohar@gmail.com
Signed-off-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</pre>
</div>
</content>
</entry>
</feed>
