Re: [PATCH 1/2] xattr support for ext2fs

[Kalle Olavi Niemitalo]

LastAvengers  writes:

> +/* Prefixes are represented as numbers when stored in ext2 filesystems. */
> +struct _xattr_prefix
> +xattr_prefixes[] =
> +{
> +  {
> +  1, "user.", sizeof "user." - 1},
> +  {
> +  7, "gnu.", sizeof "gnu." - 1},
> +  {
> +  0, NULL, 0}
> +};

ext4 on Linux 4.5 already uses 7 for EXT4_XATTR_INDEX_SYSTEM
but lists it in neither ext4_xattr_handler_map nor
ext4_xattr_handlers.  I think that means the index does not map
to any prefix visible to user mode, not even to
#define XATTR_SYSTEM_PREFIX "system.".  Instead, ext4 uses
{ EXT4_XATTR_INDEX_SYSTEM, "data" } internally for inline data.
http://lxr.free-electrons.com/ident?v=4.5;i=ext4_xattr_handler_map

So if you use 7 then I think these xattrs will not be accessible
from current Linux.  And I think ext4 developers would not be
happy to change ext4 to let them through if they intended
EXT4_XATTR_INDEX_SYSTEM for ext4 internal use.

"[linux 2.6 patch] ext2 support for hurd extensions via xattr interface"
https://lists.gnu.org/archive/html/bug-hurd/2004-02/msg00108.html
defined EXT2_XATTR_INDEX_HURD as 7 but AFAICT it did not store
that index on disk so it did not have this kind of problem.

What are the alternatives then:

(a) Store as { EXT4_XATTR_INDEX_SYSTEM = 7, "translator" }
like you intended.
Con: The xattr would be inaccessible from current Linux.

(b) Store as { EXT4_ATTR_INDEX_USER = 1, "gnu.translator" }.
On Linux, applications would see "user.gnu.translator".
Pro: Anyone able to write to the file would also be able
 to modify the xattr, like on the Hurd.
Pro: The attribute could be accessed via CIFS too.
Con: Linux might not allow such xattrs on special files
 like fifos or symlinks.  That's not a problem for the
 translator xattr (because being a special file already
 implies what the translator is) but might be for the
 author xattr.
Con: I don't know whether it's right for the operating system
 to reserve names in the "user." namespace.  There is
 precedent in cachefiles_xattr_cache = "user.CacheFiles.cache"
 though, and the "gnu." part seems clear enough.
http://lxr.free-electrons.com/source/fs/xattr.c?v=4.5#L32

(c) Ask the ext4 developers to reserve a new index for "gnu.",
and store as { EXT_ATTR_INDEX_GNU, "translator" }.
Con: The xattr would be inaccessible from current Linux.
Pro: Later versions of Linux could display it as "gnu.translator"
 and let users modify the attribute just like with "user.".
Con: The attribute could not be accessed via CIFS.
 That is unlikely to matter in practice though.

(d) Store as { 0, "gnu.translator" }.
Con: I think it would be inaccessible from Linux.

Alternative (b) seems easiest and sane enough.

Is there any practical use for the author ID anyway?
I think most files in my computer were authored by people
who don't have UIDs in my /etc/passwd.

[bug #48437] diskfs_S_file_set_translator shortcutting "/hurd/fifo" to S_IFIFO discards options

[Kalle Olavi Niemitalo]

URL:
  

 Summary: diskfs_S_file_set_translator shortcutting
"/hurd/fifo" to S_IFIFO discards options
 Project: The GNU Hurd
Submitted by: kon
Submitted on: Thu Jul  7 12:31:28 2016
Category: Hurd Servers
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Reproducibility: Every Time
  Size (loc): None
 Planned Release: None
  Effort: 0.00
Wiki-like text discussion box: 

___

Details:

Using hurd 1:0.8.git20160522-4 from Debian:


$ ls -ld hop
ls: cannot access 'hop': No such file or directory
$ touch hop
$ settrans hop /hurd/fifo --multiple-readers
$ showtrans hop
/hurd/fifo


The output from showtrans should have been "/hurd/fifo --multiple-readers".
This happens on ext2fs and tmpfs.

ext2fs uses libdiskfs/file-set-trans.c, which recognizes "/hurd/fifo" and
converts it to S_IFIFO, but ignores the arguments.  In contrast, if it
converts "/hurd/symlink" to S_IFLNK, it saves the first argument of the
translator as the target of the symlink (and ignores any remaining arguments).
 I think it should check that it understood everything that was in the
arguments, and if not, save the arguments unchanged as if it hadn't recognized
the translator.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #48438] Cannot replace /hurd/fifo with different passive translator

[Kalle Olavi Niemitalo]

URL:
  

 Summary: Cannot replace /hurd/fifo with different passive
translator
 Project: The GNU Hurd
Submitted by: kon
Submitted on: Thu Jul  7 12:38:01 2016
Category: Hurd Servers
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Reproducibility: Every Time
  Size (loc): None
 Planned Release: None
  Effort: 0.00
Wiki-like text discussion box: 

___

Details:

Using hurd 1:0.8.git20160522-4 from Debian: 


$ ls -ld hop
ls: cannot access 'hop': No such file or directory
$ touch hop
$ settrans hop /hurd/fifo
$ settrans hop /hurd/hello
$ showtrans hop
/hurd/fifo


The output from showtrans should have been "/hurd/hello".
This happens with ext2fs and tmpfs.





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #48372] read with size 0 from fifo blocks

[Kalle Olavi Niemitalo]

Follow-up Comment #5, bug #48372 (project hurd):

I patched libpipe/pipe.c (pipe_recv) as described in comment #4, and the perl
test case in the original submission no longer hangs.  Neither does a similar
test with /hurd/new-fifo.

I also ran the test suite of vim-7.4.1829 with this patch and a few others,
and it passed.

Is there a test case for the pflocal problem mentioned in comment #2?



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #48371] read(fd, NULL, 0) from /dev/klog blocks until there is data

[Kalle Olavi Niemitalo]

Follow-up Comment #3, bug #48371 (project hurd):

I patched trans/streamio.c (trivfs_S_io_read) so that, if amount == 0, it
returns success without blocking.  I didn't change dev_read because it's
called only from trivfs_S_io_read and I thought it'd be better to avoid
locking global_lock in this case.  After installing this change and rebooting,
I then ran as root


rpctrace perl -e 'sysread STDIN, $_, 0' < /dev/klog


and it didn't hang.  I also ran "cat /dev/klog", which correctly output the
"unexpected RESEND from keyboard" message from gnumach when I used a key
combination to defocus the virtualbox window.  I did not retest /dev/klog
support in rsyslog.

As discussed on #hurd, I don't intend to post the patch itself.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #48371] read(fd, NULL, 0) from /dev/klog blocks until there is data

[Samuel Thibault]

Update of bug #48371 (project hurd):

Wiki-like text discussion box: => For such a two-lines
patch, the changes are not copyrightable, so there is no need for a copyright
assignment.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #48371] read(fd, NULL, 0) from /dev/klog blocks until there is data

[Kalle Olavi Niemitalo]

Additional Item Attachment, bug #48371 (project hurd):

File name: 0001-streamio-read-fd-buf-0-must-not-block.patch Size:1 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: [PATCH] i386: Omit pmap workaround on i486 or later.

[Masanori Ogino]

How about this patch?
Did I share this with you in a wrong way, or is it simply useless?

2016-06-18 22:04 GMT+09:00 Masanori Ogino :
> As described in XXX comments, the workaround for memory mapping is
> implemented for 80386 and it is unnecessary on i486 or later.  Thus, it
> is safe to omit that if the kernel is built for the recent (1989~)
> processors.
>
> Fuhito Inagawa pointed out the problem to me.
>
> * i386/i386/trap.c (kernel_trap): Disable the workaround when the kernel
> is built for i[456]86.
> * i386/intel/pmap.c (pmap_protect, pmap_enter): Ditto.
> * i386/intel/read_fault.c: Define intel_read_fault if and only if it is
> necessary.
> ---
>  i386/i386/trap.c| 2 ++
>  i386/intel/pmap.c   | 9 +
>  i386/intel/read_fault.c | 2 ++
>  3 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/i386/i386/trap.c b/i386/i386/trap.c
> index 6470504..77aa6db 100644
> --- a/i386/i386/trap.c
> +++ b/i386/i386/trap.c
> @@ -250,6 +250,7 @@ dump_ss(regs);
> }
> else
>  #endif /* MACH_KDB */
> +#if !(__486__ || __586__ || __686__)
> if ((code & T_PF_WRITE) == 0 &&
> result == KERN_PROTECTION_FAILURE)
> {
> @@ -261,6 +262,7 @@ dump_ss(regs);
> result = intel_read_fault(map,
>   trunc_page((vm_offset_t)subcode));
> }
> +#endif
>
> if (result == KERN_SUCCESS) {
> /*
> diff --git a/i386/intel/pmap.c b/i386/intel/pmap.c
> index e362b45..9a3a7ac 100644
> --- a/i386/intel/pmap.c
> +++ b/i386/intel/pmap.c
> @@ -1711,17 +1711,17 @@ void pmap_protect(
> return;
> }
>
> +#if !(__486__ || __586__ || __686__)
> /*
>  * If write-protecting in the kernel pmap,
>  * remove the mappings; the i386 ignores
>  * the write-permission bit in kernel mode.
> -*
> -* XXX should be #if'd for i386
>  */
> if (map == kernel_pmap) {
> pmap_remove(map, s, e);
> return;
> }
> +#endif
>
> SPLVM(spl);
> simple_lock(&map->lock);
> @@ -1812,14 +1812,14 @@ if (pmap_debug) printf("pmap(%lx, %lx)\n", v, pa);
> if (pmap == kernel_pmap && (v < kernel_virtual_start || v >= 
> kernel_virtual_end))
> panic("pmap_enter(%p, %p) falls in physical memory area!\n", 
> v, pa);
>  #endif
> +
> +#if !(__486__ || __586__ || __686__)
> if (pmap == kernel_pmap && (prot & VM_PROT_WRITE) == 0
> && !wired /* hack for io_wire */ ) {
> /*
>  *  Because the 386 ignores write protection in kernel mode,
>  *  we cannot enter a read-only kernel mapping, and must
>  *  remove an existing mapping if changing it.
> -*
> -*  XXX should be #if'd for i386
>  */
> PMAP_READ_LOCK(pmap, spl);
>
> @@ -1836,6 +1836,7 @@ if (pmap_debug) printf("pmap(%lx, %lx)\n", v, pa);
> PMAP_READ_UNLOCK(pmap, spl);
> return;
> }
> +#endif
>
> /*
>  *  Must allocate a new pvlist entry while we're unlocked;
> diff --git a/i386/intel/read_fault.c b/i386/intel/read_fault.c
> index 4b1edce..f28cbbc 100644
> --- a/i386/intel/read_fault.c
> +++ b/i386/intel/read_fault.c
> @@ -33,6 +33,7 @@
>
>  #include 
>
> +#if !(__486__ || __586__ || __686__)
>  /*
>   * Expansion of vm_fault for read fault in kernel mode.
>   * Must enter the mapping as writable, since the i386
> @@ -174,3 +175,4 @@ intel_read_fault(
>
> return (KERN_SUCCESS);
>  }
> +#endif
> --
> 2.7.3
>



-- 
Masanori Ogino 
http://twitter.com/omasanori
http://gplus.to/omasanori

RE: [PATCH 1/2] xattr support for ext2fs

[LastAvengers]

> ext4 on Linux 4.5 already uses 7 for EXT4_XATTR_INDEX_SYSTEM
> but lists it in neither ext4_xattr_handler_map nor
> ext4_xattr_handlers. I think that means the index does not map
> to any prefix visible to user mode, not even to
> #define XATTR_SYSTEM_PREFIX "system.". Instead, ext4 uses
> { EXT4_XATTR_INDEX_SYSTEM, "data" } internally for inline data.
> http://lxr.free-electrons.com/ident?v=4.5;i=ext4_xattr_handler_map
>
> So if you use 7 then I think these xattrs will not be accessible
> from current Linux. And I think ext4 developers would not be
> happy to change ext4 to let them through if they intended
> EXT4_XATTR_INDEX_SYSTEM for ext4 internal use.

Thanks for your reminding, although the index 7 is not uesd in ext2
on Linux 4.5, I think it should keep consistent.

> (b) Store as { EXT4_ATTR_INDEX_USER = 1, "gnu.translator" }.
> On Linux, applications would see "user.gnu.translator".

This is a compromise way, but a bit strange.

> (c) Ask the ext4 developers to reserve a new index for "gnu.",
> and store as { EXT_ATTR_INDEX_GNU, "translator" }.

The hurd doesn't have ext4 support now, actually we should patch Linux's ext2.

I am not sure which way is better, try to discuss about this in #hurd.
  

Re: [PATCH] i386: Omit pmap workaround on i486 or later.

[Samuel Thibault]

Masanori Ogino, on Fri 08 Jul 2016 10:43:00 +0900, wrote:
> Did I share this with you in a wrong way, or is it simply useless?

Personnally, I simply currently have no time to spend on it :/

Samuel