LGTM

I approve going back to the simpler approach, and seeing from there how the ACLs go.

In D10544#219149, @ngie wrote:

In D10544#219148, @ngie wrote:

For the record, I'm ok with the change if sufficient compatibility shims are built in, like delphij@ requested.

The affected calls in libc are:

• dbm_delete
• dbm_fetch
• dbm_store
• xdr_datum

There aren't any consumers in kernel space.

There are some consumers in contrib/, but the number is relatively small:

• amd
• gcc
• sendmail

Writing compat libcalls for the above items doesn't seem that difficult to do, and I think that your proposed change is a net-win.

To be clear: I'm endorsing the "let's move from int to size_t" change.

In D10460#218871, @thisisadrgreenthumb_gmail.com wrote:

I can confirm that, I ready to try add ext2fs ACL's, but we should managed with EAs before this.
So, I am waiting for final decision about EA's implementation approach.

In D10460#218868, @rwatson wrote:

FYI, there is another important semantic difference between BSD and Linux extended attributes. In FreeBSD, ACLs are exposed (and manipulated) via separate vnode operations in VFS, and similarly ACL system calls, since our VFS is ACL-aware, whereas in Linux, they use the extended attribute system calls and inode operations to carry a variety of metadata including ACLs. As such, if extfs is implementing ACLs, we'll want a wrapper that maps them to/from FreeBSD ACL vnode operations on the way through. There is arguably a desire to do something similar in the linuxulator to ensure that ACL operations enter our VFS as ACL operations rather than EA operations.

In D10460#218854, @thisisadrgreenthumb_gmail.com wrote:

FFS uses:
#define UFS_BALLOC ... VFSTOUFS((aa)->v_mount)->um_balloc(aa, bb, cc, dd, ee, ff).
But, as I understand, I can not use:
ext2_balloc(struct inode *ip, e2fs_lbn_t lbn, int size, struct ucred *cred,

struct buf **bpp, int flags)

in case of EA, because EA block is not part of file blocks.
So, as I could be seen for me:
I can use alloccg() and remove static declaration (as now), or implement the wrapper function, like ext2_allocfacl(), which will call alloccg().

Not much support for this change.

In D10460#218836, @thisisadrgreenthumb_gmail.com wrote:

:) Ok, but could you please suggest something about ext2_alloccg()?

In D10460#218829, @thisisadrgreenthumb_gmail.com wrote:

Ok, could you plase suggest me the way,
how I should allocate EA blocks in the ext2_vnops.c
instead of ext2_alloccg() function.
Am I right, that I should add something like ext2_allocfacl() to ext2_alloc.c,
and declare it sys/fs/ext2fs/ext2_extern.h?

Also, about the dinode, if I have no facl value under ea vnops,
how I can get it without dinode reading from disk?
Or I should add to something like:
void ext2_ei_getfacl() and void ext2_ei_putfacl() to ext2_inode_cnv.c?

I am not unhappy with this version but I should note there is somewhat of an inefficiency:

Thanks!

OK, it may be worth breaking the ABI but, for now, given that we will
have to carry the old datum for compatibility anyways, how about being
one bit more efficient?

In D10544#218740, @delphij wrote:

In D10544#218736, @pfg wrote:

In D10544#218735, @delphij wrote:

In D10544#218590, @pfg wrote:

Take 2: Comply with POSIX.

This can't be MFC'd.

No, libc ABI must NOT be broken regardless if it's MFC'ed, you should implement versioned compatibility shims.

That's just not feasible: the datum struct touches everything in dbm(3).

I might be missing something, but can't you just create wrappers around the new dbm(3) APIs to implement old binary interfaces, and __sym_compat these FBSD_1.0 symbols?

I am unsure if it's better to return or just break .... apparently the return just works so .. I'll accept it.

In D10544#218735, @delphij wrote:

In D10544#218590, @pfg wrote:

Take 2: Comply with POSIX.

This can't be MFC'd.

No, libc ABI must NOT be broken regardless if it's MFC'ed, you should implement versioned compatibility shims.

In D10460#218676, @thisisadrgreenthumb_gmail.com wrote:

The removing i_facl from BSD node will cost additional block (with on-disk inode, to get i_facl value) reading under ext2_extread()/ext2_extwrite(). I can try to implement it, if additional bread() is not so critical.

Hmm .. to clarify further:

I just started looking at it, but perhaps you missed getting rid of i_facl? It's no something we carry in the BSD inode.

Take 2: Comply with POSIX.

In D10544#218514, @delphij wrote:

Manual pages should be updated too.

Ah yes, dbm(3).

LGTM, but let me add ache as he knows this code better.

In D10510#217785, @kevans91_ksu.edu wrote:

In D10510#217784, @pfg wrote:

As I wrote, it's not an objection, just that I don't believe in transitional changes :).

Indeed, I just don't like causing even this kind of discomfort. =) Would it be helpful if I go ahead and submit some reviews for libregex bits so that this becomes less of a transitional change and more of a blocker for other things under review? (I consider it 'blocking' since it's a really unfortunate interpretation of undefined behavior that could be really really confusing if you don't immediately observe whether extensions are available or not)

In D10510#217778, @kevans91_ksu.edu wrote:

In D10510#217775, @pfg wrote:

This is not really an objection but my preference for undefined behavior is to leave it unchanged for as long as we can.
Even if it's undefined behavior, a lot fo things can break,and until the GNU compatible behavior is implemented such "transitional" change brings no benefit.

My next couple of patches that I've already prepared will be introducing libregex with the GNU compatible behavior- this transitional change is to fix the much less obvious fallout that comes from \b suddenly being interpreted as word-bound rather than 'b', especially in cases where 'b' is *also* a word-bound and it works by coincidence rather than correctness.

This is not really an objection but my preference for undefined behavior is to leave it unchanged for as long as we can.
Even if it's undefined behavior, a lot fo things can break,and until the GNU compatible behavior is implemented such "transitional" change brings no benefit.

In D10460#216936, @thisisadrgreenthumb_gmail.com wrote:

Yep, the question about attr namespace mapping still open, because there is no "empty" attribute name in linux.
So, in case of empty namespace passed to setattr(), seems like some error should be returned, I will try to verify ufs behaviour in this case, when I will fix these switches.

Ok, Robert, could you please share your opinion about keeping EA's data in memory in case of ext2fs, based on our discussion above?

:) In all cases I should agree with Pedro in the end because he is code base owner.

Since fsck_ffs and pmcstat are done, the remaining cases are trivial.

rwatson implemented the UFS EAs, perhaps he could give us some feedback on this approach for ext2fs.

In D10460#216926, @thisisadrgreenthumb_gmail.com wrote:

I am not sure, that keep EA's in memory is good idea. It is right, that, the number of bread()/bwrite() will be decreased. But:

• The EA area is not consistent, iblock/ibody.
• The EA blocks could be shared (which is not implemented in my patch), the additional syncronization will be required.
• The EA's max size could be decreased in next revisions of extfs by adding EA blocks redirection for example.

So, it is completely possible to implement, but the future EA's functionality integration will be difficult, from my point of view.

In D10460#216920, @thisisadrgreenthumb_gmail.com wrote:

In D10460#216919, @pfg wrote:

Hmm.. have you given a thought on making the in memory inode more similar to UFS? I mean using something like this:

	/*
	 * Data for extended attribute modification.
 	 */
	u_char	  *i_ea_area;	/* Pointer to malloced copy of EA area */
	unsigned  i_ea_len;	/* Length of i_ea_area */
	int	  i_ea_error;	/* First errno in transaction */
	int	  i_ea_refs;	/* Number of users of EA area */

I admit it looks pretty straightforward as you did it but I was hoping to keep more similarities with UFS.

Am I right, that your idea is to allocate the memory area for EA's in case of inode reading,
then work with it, the write this memory to disk and free it, in case of inode inactivation?

Hmm.. have you given a thought on making the in memory inode more similar to UFS? I mean using something like this:

Oops .. drop the change in route6d, it's not likely to overflow.

Resurrect this Differential Revision with a much reduced scope.

Updated version: drop some cases where overflows are very unlikely.

TBH, I am wondering the usefulness fo these replacements.
It is not clear if overflows are possible at all. OTOH I am pretty sure the changes won't hurt.

For the record...

In D10315#213705, @kevans91_ksu.edu wrote:

By request of @pfg

root@ghost:/usr/src/usr.bin/sed/tests# make check
sed2_test:inplace_hardlink_src  ->  passed  [0.071s]
sed2_test:inplace_symlink_src  ->  passed  [0.043s]
sed_test:c2048  ->  passed  [0.045s]
sed_test:emptybackref  ->  passed  [0.054s]
sed_test:longlines  ->  passed  [0.061s]
sed_test:preserve_leading_ws_ia  ->  passed  [0.040s]
sed_test:rangeselection  ->  passed  [0.204s]
legacy_test:main  ->  passed  [0.657s]
multi_test:main  ->  passed  [1.402s]
inplace_race_test:main  ->  passed  [3.772s]

Results file id is usr_tests_usr.bin_sed.20170408-150131-450096
Results saved to /root/.kyua/store/results.usr_tests_usr.bin_sed.20170

10/10 passed (0 failed)

Actually... I meant the GNU sed port tests: we can't import them but our sed in base passes the GNU tests.

The change looks good to me but given the history I've had with regex and sed, I do feel an exp-run is needed.

I can't really test that it works as intented but it looks good to me. Approved.
Can it be MFC'd all the way to 10-stable? Kevin can you do the honors?
I am still setting up stuff here.

OK.. another iteration of knits :)

Add trasz as reviewer: with the addition of EAs, at least read-only for now, implementing ACLS becomes possible.

Sorry to be so picky, the code is looking good. After the minor fixes I will approve and if kevin confirms it works we can commit it.

The change looks good to me but it isn't my area. Add Peter.