On Tue, 12 Dec 2023 12:44:47 -0600
"Mark Hatle" wrote:
> /tmp - used by the compiler (and tons of other tooling) for temporary
> files, we need this for sure.
If memory serves, this is basically why it was an IGNORE path list
originally. If we ever accessed anything outside of pseudo, we'd get
l
On Tue, 30 May 2023 19:54:41 -0700
Mark Hatle wrote:
> - int existed = (real___xstat64(_STAT_VER, path, &buf) != -1);
> + int existed = (base_stat64(path, &buf) != -1);
Honestly, with the benefit of hindsight, I actually can't even think
why I ever thought I should be using those directl
On Tue, 30 May 2023 19:33:03 +0800
zhangjial...@loongson.cn wrote:
> +#ifdef __loongarch64
No.
Use the configuration mechanisms or whatever to determine the *actual
distinction you care about*, which is "does glibc have __xstat64", give
that a name, and use the name.
Some day, someone else will
On Mon, 27 Jun 2022 14:52:39 +0100
Richard Purdie wrote:
> b) We could add a new command to run an integrity check on the DB to
> pseudo. If we do that, we would then be able to show the user a decent
> error and above the timeout issue. The question is where/when to
> trigger it and whether race
On Mon, 25 Apr 2022 14:01:58 -0400
"C. Andy Martin" wrote:
> I agree this is not the ideal solution. However, I was basing this
> compromise on this commit:
Yeah. Come to think of it, directory mismatches are already probably
blowing up differently because we're more concerned about that.
Proba
On Mon, 25 Apr 2022 10:49:24 -0400
"C. Andy Martin" wrote:
> - msg->result = RESULT_ABORT;
> - goto op_exit;
> + if (msg->nlink == 1) {
> + msg->
On Thu, 9 Sep 2021 16:36:10 +0100
Richard Purdie wrote:
> It just so happens that my /home/mac and /home directories have the
> same inode number but on different filesystems.
Nice catch!
-s
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155864
On Thu, 9 Sep 2021 16:36:11 +0100
Richard Purdie wrote:
> pseudo_client.c:848:17: warning: ‘%s’ directive argument is null
> [-Wformat-overflow=] 848 | pseudo_diag("couldn't
> allocate absolute path for '%s'.\n",
I'm sort of curious as to whether pseudo_root_path is ever actual
On Thu, 9 Sep 2021 16:36:13 +0100
Richard Purdie wrote:
> - pseudo_msg_t msg = { .type = PSEUDO_MSG_OP };
> + static pseudo_msg_t msg;
> + msg = (pseudo_msg_t) { .type = PSEUDO_MSG_OP };
Looks good to me.
I'm honestly sort of stunned that the return of the local variable's
address
On Mon, 9 Aug 2021 13:19:51 +0100
"Mike Crowe via lists.openembedded.org"
wrote:
> Cleaning the work directory makes the problem go away because that
> deletes the pseudo databases.
>
> Does the above make sense as an explanation for these errors? If so,
> is there a good way to avoid these erro
On Thu, 29 Jul 2021 14:37:28 +0200
"Damian Wrobel" wrote:
> the PSEUDO_MSG_OP is being unconditionally assigned to the msg.type
> before any real usage of the 'msg' structure. So, if I'm not mistaken
> that code was already tested and didn't work well and was reverted
> here[1].
I don't think th
On Wed, 28 Jul 2021 13:49:17 -0700
Andre McCurdy wrote:
> If the caller only cares about yes/no then how about returning 1/0
> instead of a pointer?
Other callers are actually using the response, because the pseudo_msg_t*
returned from this is how, say, OP_STAT responds with the stat
information
On Wed, 28 Jul 2021 11:36:22 +0200
"Damian Wrobel" wrote:
> Do I correctly assume that pseudo_client_op() has to be fully
> reentrant?
No. It's never been even a tiny bit reentrant. We used to do the
allocate and free thing, and it was incredibly expensive, and the
nature of the thing requires c
On Tue, 27 Jul 2021 18:30:33 +0200
Damian Wrobel wrote:
> The returned pointer has to be freed by the caller not by the callee
> function itself.
So, this predates the public release, but long ago, that was indeed
how it worked, and then LONG ago it was changed so that the pseudo_ipc
stuff alway
On Tue, 27 Jul 2021 18:35:50 +0200
"Damian Wrobel" wrote:
> Based on my experience, It's usually better to see this warning and
> fix the code instead of relying on the back magic.
Yes, but in the case of the strict aliasing stuff and function pointer
stuff, we really, really, *can't* not rely o
On Tue, 27 Jul 2021 13:49:03 +0200
"Damian Wrobel" wrote:
> -# no-strict-aliasing is needed for the function pointer trickery.
> pseudo_wrappers.o: $(GUTS) pseudo_wrappers.c pseudo_wrapfuncs.c
> pseudo_wrapfuncs.h pseudo_tables.h
> - $(CC) -fno-strict-aliasing $(CFLAGS) $(CFLAGS_PSEUDO)
> -D
On Tue, 27 Jul 2021 13:49:04 +0200
"Damian Wrobel" wrote:
> pseudo_diag("couldn't allocate absolute path for
> '%s'.\n",
> - path);
> + path ? path : "null");
Is there any actual code path where pseudo_root_path gets called on a
null path? I
On Tue, 27 Jul 2021 13:49:06 +0200
"Damian Wrobel" wrote:
> Fixes the following warning:
> pseudo_client.c: In function ‘pseudo_client_op’:
> cc1: warning: function may return address of local variable
> [-Wreturn-local-addr] pseudo_client.c:1592:22: note: declared here
>1592 | ps
For reference, I believe the rationale on these originally was "none of
these functions happen repeatedly, in general, and the extra complexity
and potential to get the logic wrong isn't appealing", but I don't
think I object to these.
-s
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages se
On Mon, 28 Sep 2020 22:42:18 +0100
"Richard Purdie" wrote:
> It helps to know that! I wasn't sure if you'd hate the path filtering.
It was on my to-do list at one point to be able to denote "the pseudo
filesystem" in some way and just politely ignore everything outside it.
And, possibly, switch
On Mon, 28 Sep 2020 15:51:53 +0100
"Richard Purdie" wrote:
> I understand. I have strong evidence that the current handling of such
> a case does the wrong thing though as copying the data from the
> original inode leads to pretty bad corruption in its own right.
Yes.
But if you had to choose b
On Mon, 28 Sep 2020 14:38:01 +0100
"Richard Purdie" wrote:
> This can happen when files are deleted outside of pseudo context and
> the inode is reused by a new file which pseduo then "sees".
I'm just going to say again:
The **ENTIRE REASON** pseudo exists to replace fakeroot is that
fakeroot d
On Tue, 22 Sep 2020 18:22:18 +0100
"Richard Purdie" wrote:
> The "fun" here is that "make install" is rewriting Makefiles within
> the source code tree. The install step runs under pseudo, earlier
> ones do not.
> If we rerun earlier non-pseudo steps, the Makefiles get reset to their
> original
On Tue, 22 Sep 2020 14:18:24 +0100
"Richard Purdie" wrote:
> This can happen when files are deleted outside of pseudo context and
> the inode is reused by a new file which pseduo then "sees".
In terms of the original design: This would be considered a usage bug,
and pseudo issues diagnostics for
sers and can
> hence influence its development.
>
> Hope that is ok with you seebs!
Seems reasonable to me. SOME DAY I will have free time. :P
-s
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#140031):
https://lists.openembedded.org/g/opene
On Fri, 26 Jun 2020 16:56:48 +0200
"Johannes Beisswenger" wrote:
> The OP_CREATE/REPLACE/SET_XATTR operations in pseudo_op() don't use
> msg_header.mode at all, it is only used for DB sanity checks, which
> in turn only use the non-permission bits.
Right, the relevant part is the immediately fo
On Fri, 26 Jun 2020 11:40:31 +0200
"Johannes Beisswenger" wrote:
> The file mode was accidentally overwritten with only the permission
> bits, causing the server to falsely assume that the database was
> corrupted (because the msg_header.mode did not contain S_IFDIR
> anymore) even though it was
On Fri, 8 May 2020 08:09:58 +0200
Jacob Kroon wrote:
> Hi Peter,
>
> On 5/3/20 6:26 PM, Seebs wrote:
> > On Sun, 3 May 2020 17:49:09 +0200
> > "Jacob Kroon" wrote:
> >
> >> The type has never been used, so an alternative fix would be to get
>
On Sun, 3 May 2020 17:49:09 +0200
"Jacob Kroon" wrote:
> The type has never been used, so an alternative fix would be to get
> rid of it altogether, and just keep the enum identifiers.
I think I anticipated the type being used for something but it did
indeed not happen. It could also just be cha
On Sun, 3 May 2020 06:27:12 +0200
"Jacob Kroon" wrote:
> 'pseudo_access_t' is a type, so use typedef.
>
> Fixes building pseudo with gcc 10 where -fno-common is the default.
Wow! That's amazing, and yes, that's a bug, and the fix looks right to
me. I don't know how that got missed all these ye
On Mon, 27 Apr 2020 14:04:16 +0800
"kai" wrote:
> | ports/linux/pseudo_wrappers.c:129:14: error:
> ‘SECCOMP_SET_MODE_FILTER’ undeclared (first use in this function)
> |if (cmd == SECCOMP_SET_MODE_FILTER) {
Should the test be against this being #defined, rather than the
separate SYS__seccomp?
On Thu, 9 Apr 2020 06:30:37 +
"Yu, Mingli" wrote:
> We are trying to fix the issue as
> http://bugzilla.yoctoproject.org/show_bug.cgi?id=13311 stated.
Hmm. I think there's a more subtle logic bug here, and also one
of the diagnostics there is a debug message I didn't notice when I
made the c
On Thu, 9 Apr 2020 10:38:41 +0800
"Yu, Mingli" wrote:
> - fd = open(pseudo_path, O_WRONLY | O_APPEND | O_CREAT, 0644);
> + fd = open(pseudo_path, O_WRONLY | O_APPEND | O_CREAT |
> O_CLOEXEC, 0644);
I'm not confident in this.
This code is shared between the pseudo client and the pseudo s
On Sat, 4 Apr 2020 14:32:03 -0700
"Andre McCurdy" wrote:
> Also, since prctl() is Linux specific, it looks like this patch will
> make pseudo Linux specific. Is that OK? If so maybe worth making an
> official statement that OE is only supported for Linux hosts?
We have existing hooks for making
On Wed, 18 Dec 2019 17:24:21 +0100
Alexander Kanavin wrote:
> You can also supply your own definition of ENOATTR, as it doesn't
> change.
That way lies EVEN MORE madness. I don't have any guarantee that it
won't be changed at some point, and... I mean, silly though it sounds
to talk about "defin
On Wed, 18 Dec 2019 17:15:34 +0100
Alexander Kanavin wrote:
> On Wed, 18 Dec 2019 at 16:27, Seebs wrote:
>
> > On Wed, 18 Dec 2019 15:37:46 +0100
> > Alexander Kanavin wrote:
> >
> > > +Latest versions of attr have removed the xattr.h header,
> > >
On Wed, 18 Dec 2019 15:37:46 +0100
Alexander Kanavin wrote:
> +Latest versions of attr have removed the xattr.h header,
> +with the rationale that libc is providing the same wrappers.
I'm a bit concerned about this -- will this still work with *older*
versions of xattr?
-s
--
_
On Mon, 11 Nov 2019 08:17:30 -0600
Mark Hatle wrote:
> First (early) version of pseudo would fork for the server, there
> wasn't a seperate executed server and we had all sorts of problems
> with dynamic libraries being loaded and loaded from the correct paths
> (due to the LD_PRELOAD).
>
> Movi
On Sat, 09 Nov 2019 16:30:41 +
Richard Purdie wrote:
> I did talk briefly to Mark (also cc'd) as he wrote the original patch
> and he thought it was possibly because the client was also linking
> against sqlite3 and due to the other things the client does, that was
> problematic.
It *shouldn
On Sat, 9 Nov 2019 15:35:59 +
Richard Purdie wrote:
> Back in 2010[1] we made pseudo statically link against sqlite3. Since
> then the world has changed, pseudo now has separate processes for the
> database in the server and the client and they have separate linking
> commands.
I'm not sure
On Thu, 7 Nov 2019 20:04:44 +
Richard Purdie wrote:
> Modern distros (e.g. fedora30) are starting to use the new statx()
> syscall through the newly exposed glibc wrapper function in software
> like coreutils (e.g. the ls command). Add support to intercept this
> to pseudo.
I think this sho
On Sat, 3 Aug 2019 05:33:46 -0700
Khem Raj wrote:
> Will this fix the file ownership issue that we see with Glibc-locale
> packages from time to time?
I have no idea. Since I haven't got a reliable reproducer for it, I
can't test it in a sane way.
-s
--
On Fri, 2 Aug 2019 12:07:33 -0500
Seebs wrote:
> Note that there's no lstat, and no AT_SYMLINK_NOFOLLOW. Which is to
> say, these stats will be following the symlink even though O_NOFOLLOW
> was set. I can probably patch this in a bit.
Followup: Patch applied to master, but also
On Fri, 2 Aug 2019 11:27:45 -0500
Jason Wessel wrote:
> The sequence of openat() followed by an fstat() on the opened file
> handle, will erase the pseudo uid entry for the symlink, as shown by
> the following lstat() in test 5. The culprit appears to be the
> fstat(), but it could be something m
On Thu, 1 Aug 2019 16:37:26 -0500
Jason Wessel wrote:
> It seems to have caused really odd problems with the oe link
> management that were not there previously, such as:
>
>
> WARNING: pinentry-1.1.0-r0 do_package_qa: QA Issue:
> pinentry: /usr/bin/pinentry is owned by uid 5002, which is the s
On Thu, 1 Aug 2019 10:55:45 -0700
Jason Wessel wrote:
> Many thanks to Peter Seebach for fixing the problem in the pseudo code
> to use the same logic which was already there for the
> AT_SYMLINK_NOFOLLOW.
Special credit goes to Past Seebs, who thoughtfully made the parser
for
On Thu, 1 Aug 2019 18:02:06 +0200
Max Kellermann wrote:
> + * wrap_access(int dirfd, const char *path, int mode, int flags) {
This should probably say "faccessat". I know it's just a comment, but
I try to be consistent about these.
> + rc = real___fxstatat64(_STAT_VER, dirfd, path, &buf,
On Sat, 13 Apr 2019 10:03:03 +0200
Andreas Müller wrote:
> On Fri, Apr 12, 2019 at 10:18 AM
> wrote:
> >
> > On Wed, 2019-04-10 at 18:59 -0500, Seebs wrote:
> > > On Thu, 11 Apr 2019 00:12:54 +0100
> > > Richard Purdie wrote:
> > >
> > >
On Thu, 11 Apr 2019 00:12:54 +0100
Richard Purdie wrote:
> -SRCREV = "6294b344e5140f5467e6860f45a174440015304e"
> +SRCREV = "6ebc7d6bc8ab973d0ba949eeb363821811ce8dc5"
I would sort of recommend one of the two commits since then -- one may
fix the .NET startup failures, and the other fixes warning
On Tue, 15 Jan 2019 13:31:13 +0100
Stefan Agner wrote:
> + case F_OFD_GETLK:
> + case F_OFD_SETLK:
> + case F_OFD_SETLKW:
These probably need an #ifdef for systems that don't have those names
yet, but otherwise this looks reasonable?
-s
--
__
On Sun, 18 Nov 2018 19:36:46 +0100
Jens Rehsack wrote:
> + for sqlite_link_opt in $(pkg-config sqlite3 --libs --static)
Ugh, but yeah, I think this is probably needed. I'm a bit concerned
about libsqlite3 ending up with readline included, that really seems
like something that should only be
On Wed, 15 Aug 2018 10:27:29 +0100
Richard Purdie wrote:
> On Wed, 2018-08-15 at 08:59 +0200, Rasmus Villemoes wrote:
> > On 2018-07-11 16:30, Rasmus Villemoes wrote:
> > > MSG_NOSIGNAL has been in Linux since 2.2, and has been
> > > standardized in
> > > POSIX 2008. Using that when available avo
On Fri, 20 Apr 2018 08:25:26 +
Martin Jansa wrote:
> * the pseudo.log is significantly shorter with this revision
There's also an actually fairly significant bug fix in here. At one
point, long ago, I made a function that expands paths, and takes a flag
argument which may or may not be AT_SY
On Wed, 4 Apr 2018 14:28:11 -0700
Khem Raj wrote:
> what is the performance impact of adding another stack frame and
> function call in the chain here. Do we have data ?
Very close to unmeasurable, because *almost nothing ever uses syscall*.
This is used only for the case where someone is expli
On Tue, 3 Apr 2018 10:51:28 +0100
Richard Purdie wrote:
> This change includes several bug fixes and improvements, including
> better path handling (the existance of . and .. for files), handling
> of the sticky bit, and syscall renameat2 handling and interception
> through syscall() which was b
On Sat, 31 Mar 2018 16:03:01 -0500
Joshua Watt wrote:
> Looks like maybe gdk-pixbuf-query-loaders has the unlucky honour of
> being one of the few programs that invokes the pseudo syscall()
> wrapper before any other functions that pseudo wraps and the missing
> initializer made it explode?
That
On Sat, 31 Mar 2018 14:12:55 +0100
Richard Purdie wrote:
> I believe that libglib-2.0 does use syscall() for something and that
> the above programs are calling into it and faulting.
Interesting! I'll poke around and see what I can find.
-s
--
___
Op
On Fri, 30 Mar 2018 23:02:29 -0700
Andre McCurdy wrote:
> On Fri, Mar 30, 2018 at 10:06 PM, Seebs wrote:
> > That's the problem: There's no sane way to express "the size that
> > you would have gotten for these arguments of unknown types"
>
> And there
On Fri, 30 Mar 2018 21:15:18 -0700
Andre McCurdy wrote:
> Arguments passed by the caller will be put on the stack before any
> stack frame is created by the callee. You can argue about which way a
> stack grows (up or down) but however you define it, reading past the
> end of the arguments passed
On Thu, 29 Mar 2018 14:04:00 +0200
Enrico Scholz wrote:
> __builtin_apply() should deal with it.
The documentation hints at possible problems when dealing with other
functions, but doesn't mention any architecture difficulties. It's
possible gcc simply never uses any of the weird conventions, it'
On Tue, 27 Mar 2018 13:52:28 -0700
Andre McCurdy wrote:
> On Tue, Mar 27, 2018 at 1:20 PM, Seebs wrote:
> > My concern is that, strictly speaking, this is nearly all undefined
> > behavior, and that reading more arguments than you were passed
> > *does* explode on some C im
On Tue, 27 Mar 2018 13:12:19 -0700
Andre McCurdy wrote:
> If you mean forwarding arguments through a wrapper without
> interpreting them then I don't know what your concern is. Forwarding
> arguments can be handled completely generically - for any architecture
> and any syscall. See the musl impl
On Tue, 27 Mar 2018 21:20:24 +0200
Enrico Scholz wrote:
> SYS_readahead is one of a few syscalls which pass 64 bit arguments on
> 32 bit architectures. Without the manual splitting, the ABI will
> cause the compiler to insert a dummy argument so that registers are
> aligned for 64 bit values.
I
On Tue, 27 Mar 2018 12:11:22 -0700
Andre McCurdy wrote:
> In the readahead example, the first syscall argument is the
> 32bit file descriptor (which will be passed to the kernel in r0),
> therefore a padding argument is required to fill r1 and ensure that
> the first word of the 64bit offset gets
On Tue, 27 Mar 2018 18:26:05 +0200
Enrico Scholz wrote:
> Perhaps we have different man pages but e.g. [1] mentions only
> registers in the context of the kernel interface but not when
> entering/leaving syscall(2) itself.
And yet, it's syscall(2) doing the thing... or possibly it's not,
because
On Tue, 27 Mar 2018 18:35:32 +0200
Enrico Scholz wrote:
> Does this really matter here? Because the caller has to set them
> accordingly the ABI, you can extract the arguments by
>
> int olddirfd= va_arg(ap, int);
> char const *oldpath = va_arg(ap, char consr *);
> int
On Tue, 27 Mar 2018 16:42:03 +0200
Enrico Scholz wrote:
> will work to wrap syscall(2). Params for _renameat2_syscall() can be
> extracted by va_args.
Does anyone have access to an actual 64-bit EABI ARM system to verify
the argument passing for renameat2 there?
> Code generated above is very
On Tue, 27 Mar 2018 16:48:02 +0100
Ross Burton wrote:
> This patch intercepts syscall() and returns ENOTSUP if renameat2() is
> being called.
I am inclined to NAK this until we have a clearer understanding of the
mechanics observed in glibc's syscall implementation; it's doing magic
that this wi
On Tue, 27 Mar 2018 15:06:40 +0200
Enrico Scholz wrote:
> Andre McCurdy
> writes:
>
> >> Since the man page gave the ia64 example, I went and checked, and
> >> it is indeed the case that calls other than syscall(2) will
> >> clobber r10 after system calls,
>
> I think you are misinterpreting t
On Mon, 26 Mar 2018 19:59:09 -0700
Andre McCurdy wrote:
> The syscall manpage is from the kernel manpages, not glibc.
> http://man7.org/linux/man-pages/man2/syscall.2.html
And yet! glibc is setting those registers in its code. Why? If that's a
kernel thing and libc doesn't need to do it, why
On Mon, 26 Mar 2018 18:34:10 -0700
Andre McCurdy wrote:
> > I remain interested in why the glibc implementation does all these
> > weird things on some architectures if none of those things matter.
>
> Which glibc implementation? I'll take a look.
syscall(2) for various architectures, which is
On Mon, 26 Mar 2018 18:10:07 -0700
Andre McCurdy wrote:
> I've verified that the QA warnings on FC27 can be fixed by preloading
> a wrapper for libc syscall(). Just a proof of concept but if anyone
> would like to reproduce it my steps are below.
Yes, I think we were expecting it would work on x
On Mon, 26 Mar 2018 13:12:44 -0700
Andre McCurdy wrote:
> That's based on your assumption that a C wrapper needs to care about
> results in architecture specific registers, which I contend is not a
> correct interpretation of the syscall manpage.
My observation is: If this doesn't matter, why is
On Mon, 26 Mar 2018 20:49:30 +0200
Andreas Müller wrote:
> Interesting background: mv/renameat2 change seemed so important for
> Fedora that they backported the changes into 8.27.
It looks like the reason for this is the RENAME_NOREPLACE flag, which
avoids a possible race condition.
FWIW, I've
On Sat, 24 Mar 2018 15:22:47 -0500
Joshua Watt wrote:
> I don't think that is true. libc's syscall() must conform to the *C*
> ABI for the system... if the kernel does things that aren't in line
> with the C ABI (like return things in registers that aren't expected,
> fail to preserve registers t
On Sat, 24 Mar 2018 12:42:45 -0700
Andre McCurdy wrote:
> Right. The musl example is to show how it's possible to transparently
> intercept and pass on any call to the syscall() ABI without
> interpreting anything.
Yes, if you don't need to interpret things, and aren't making
additional other un
On Sat, 24 Mar 2018 11:59:27 -0700
Andre McCurdy wrote:
> The EABI example applies to 64bit values on 32bit architectures. Since
> pointers are 32bit values on 32bit architectures the example doesn't
> apply to renameat2 (which only passes int's and pointers - nothing
> which would be a 64bit val
On Sat, 24 Mar 2018 11:12:20 -0700
Andre McCurdy wrote:
> If you can successfully intercept the libc syscall() API and return
> ENOTSUPP for the one specific case of renameat2 but pass on all other
> callers transparently then haven't you've already solved the bulk of
> the problem (for the non-G
On Sat, 24 Mar 2018 17:10:47 +
"Burton, Ross" wrote:
> On 24 March 2018 at 12:36, Richard Purdie
> wrote:
> > I think, at least in principle, pseudo could wrap that and intercept
> > this particular syscall, check syscall_number (the numbering having
> > its own set of issues) and then only
On Sat, 24 Mar 2018 12:36:28 +
Richard Purdie wrote:
> I think, at least in principle, pseudo could wrap that and intercept
> this particular syscall, check syscall_number (the numbering having
> its own set of issues) and then only handle the specific problem case
> we have.
I think the pro
On Fri, 23 Mar 2018 18:43:12 -0700
Andre McCurdy wrote:
> Since glibc doesn't provide a wrapper for renameat2, making the
> syscall via the libc syscall() API is exactly what coreutils (actually
> gnulib) should be doing. There would certainly be grounds to complain
> if user space code were maki
On Fri, 23 Mar 2018 18:10:21 -0700
Andre McCurdy wrote:
> The syscall wrapper in musl handles 6 additional arguments -
> unconditionally. Based on that you might not need to interpret
> anything - just extract 6 arguments and pass them on?
>
> long syscall(long n, ...)
> {
> va_list ap;
>
On Fri, 23 Mar 2018 17:33:28 -0700
Andre McCurdy wrote:
> Interposing the libc syscall wrapper doesn't seem to scary if you can
> transparently pass on everything apart from syscall(SYS_renameat2,
> ...) ?
I don't think I can in the general case; I don't know how many
arguments every possible sy
On Fri, 23 Mar 2018 23:47:30 +
Richard Purdie wrote:
> On Fri, 2018-03-23 at 11:49 -0500, Seebs wrote:
> > On Fri, 23 Mar 2018 16:30:55 +
> > "Burton, Ross" wrote:
> >
> > >
> > > Because in GNU's infinite wisdom they're usi
On Fri, 23 Mar 2018 16:56:16 +
"Burton, Ross" wrote:
> On 23 March 2018 at 16:49, Seebs wrote:
> > On Fri, 23 Mar 2018 16:30:55 +
> > "Burton, Ross" wrote:
> >
> >> Because in GNU's infinite wisdom they're using renameat2() t
On Fri, 23 Mar 2018 16:30:55 +
"Burton, Ross" wrote:
> Because in GNU's infinite wisdom they're using renameat2() to do
> atomic renames in the mv command, and as renameat2 isn't in the
> headers for F27 it just does a syscall directly. This is in upstream
> coreutils so once they make a rele
On Fri, 23 Mar 2018 17:10:35 +0100
Enrico Scholz wrote:
> I think, 'mv' is the culprit. It calls 'renameat2()' directly over
> 'syscall()':
>
> | $ ltrace mv foo bar
> | ...
> | syscall(316, 0xff9c, 0x7fff1564a341,
> 0xff9c)= 0
>
>
> Perhaps
On Thu, 22 Mar 2018 17:06:08 +0100
Andreas Kaufmann wrote:
> Pseudo is using a custom configure script that detects if it shall
> build with extended file attribute support or not. The check is done
> by simply calling 'getfattr' provided by attr-native which is not
> part of the dependency list.
On Thu, 1 Mar 2018 15:53:46 +0200
Alexander Kanavin wrote:
> toomanyfiles.patch rebased
Do we still have a reason for that, if we're using epoll to address
that?
That said, with the new fastop sanity-fix, that is probably much less
dangerous than it used to be.
-s
--
On Mon, 19 Feb 2018 20:01:31 +0100
Martin Jansa wrote:
> I did quick check for UID/GID issue:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434
Hmm. glibc-locale, in particular, is a really weird case; does it still
do the strange thing with copying the files around through scratch
space
On Mon, 19 Feb 2018 11:27:56 +0200
Alexander Kanavin wrote:
> > Huh. It's possible that the initial "don't try to close fd 0" was
> > correct, and the real problem is that the attempt is getting made
> > mistakenly. I'll study that more; the epoll code was a contribution
> > and I may not have fu
On Sat, 17 Feb 2018 15:28:55 +0200
Alexander Kanavin wrote:
> For me, with epoll enabled:
>
> b6a015a works
> 23f089f and 26e30fa both lock up
Huh. It's possible that the initial "don't try to close fd 0" was
correct, and the real problem is that the attempt is getting made
mistakenly. I'll stu
On Fri, 16 Feb 2018 20:11:48 +0100
Martin Jansa wrote:
> I didn't get to the logs yet, but with this change added I see many
> do_install tasks failing with exit code '134'.
Huh, that's SIGABRT. I'll see if I can reproduce.
-s
--
___
Openembedded-cor
ot stuck until disk space run out..
Oh-hoh! That could be the epoll thing that I wasn't able to reproduce.
> commit 26e30fa2e1a0fe4e885d7eea3f55d23cd2c3158f
> Author: Seebs
> Date: Fri Feb 16 11:49:49 2018 -0600
>
> Allow closing client 0
Added a thing to master. It loo
On Wed, 29 Nov 2017 12:02:38 -0600
Richard Tollerton wrote:
> So we noticed that cp -Rp was stripping special bits off of
> directories when run under pseudo. The super interesting thing was
> that people saw this when upgrading their build machines from Ubuntu
> 12.04 to 16.04. Root cause is in
On Fri, 22 Sep 2017 17:41:17 +0100
Richard Purdie wrote:
> This changes the pseudo FASTOP functionality so that a reply to the
> operation is required. This means we then cannot lose data if a
> connection is closed. This in turn stops corruption if we run out of
> file handles and have to close
On Mon, 18 Sep 2017 19:41:03 -0400
Trevor Woerner wrote:
> Would you be open to a co-maintainership? Maybe a co-maintainer who
> doesn't push to master directly?
Maybe? I don't know, I'd need to think about that a bit. I recognize
that there's a need to get some of this stuff fixed, but I think
On Mon, 18 Sep 2017 19:16:13 -0400
Trevor Woerner wrote:
> It doesn't make sense to carry these large patches against pseudo in
> OE itself. Isn't pseudo one of the tools under The Yocto Project
> umbrella?
Yes. But the pool of people with the variety of expertise needed to
maintain it isn't hug
On Sat, 16 Sep 2017 02:22:01 +
Will Page wrote:
> Thanks, Ross.
>
> I had contacted the maintainer off list to ask where I should submit
> my patch. I may have misunderstood his reply.
No, I'm just confused, because I'm not really otherwise active in
yocto/oe-core these days, I just still
On Fri, 15 Sep 2017 15:27:00 -0700
Will Page wrote:
> The fcntl guts switch on "cmd" parameter to identify the fcntl
> command being issued, but isn't aware of the file creation flags that
> can be ORed in.
This is true. I was, in fact, not aware of those flags. Looks
reasonable.
-s
--
___
1 - 100 of 132 matches
Mail list logo
