diff for duplicates of <52415EDD.6030508@canonical.com> diff --git a/a/1.txt b/N1/1.txt index f5204d0..8c33ea8 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -56,8 +56,7 @@ Op 24-09-13 11:03, Thomas Hellstrom schreef: It may be swapped out, but I don't use read.*atomic copy calls, faults are allowed to happen at that point and no -EFAULT will be returned from that. The only -EFAULT that can happen is if the memory ends up being read-only, or ceased to exist. -> In fact failures of pushbuf / execbuf *after* commands are successfully submitted are generally very hard to recover from. That's why the kernel should do whatever it takes to recover from such failures, and user-space should do whatever it takes to recover from copy-to-user failures of needed info from the kernel, and it really depends on the user-space usage pattern of "presumed". IIRC the original reason for copying it back to user-space was, that if a relocation offsets were patched up by the kernel, and then the process was sent a signal causing it to retry execbuf, then "presumed" had to be updated, otherwise it would be inconsistent with what's currently in the command stream, which is very bad. If "presumed" is, however, only used by user-space to guess an offset, the correct act - ion would be to swallow the -EFAULT. +> In fact failures of pushbuf / execbuf *after* commands are successfully submitted are generally very hard to recover from. That's why the kernel should do whatever it takes to recover from such failures, and user-space should do whatever it takes to recover from copy-to-user failures of needed info from the kernel, and it really depends on the user-space usage pattern of "presumed". IIRC the original reason for copying it back to user-space was, that if a relocation offsets were patched up by the kernel, and then the process was sent a signal causing it to retry execbuf, then "presumed" had to be updated, otherwise it would be inconsistent with what's currently in the command stream, which is very bad. If "presumed" is, however, only used by user-space to guess an offset, the correct action would be to swallow the -EFAULT. Yeah it's a guess from userspace. But it's probably still a programming error by userspace if it uses a read-only mapping for presumed, or a mapping that's invalidated. :P But there's nothing I can do at that point, I can't undo something I just committed. This is why I asked whether I should swallow it or not, because it's diff --git a/a/content_digest b/N1/content_digest index 3864576..907b375 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -87,8 +87,7 @@ "It may be swapped out, but I don't use read.*atomic copy calls, faults are allowed to happen at that point and no -EFAULT will be returned from\n" "that. The only -EFAULT that can happen is if the memory ends up being read-only, or ceased to exist.\n" "\n" - "> In fact failures of pushbuf / execbuf *after* commands are successfully submitted are generally very hard to recover from. That's why the kernel should do whatever it takes to recover from such failures, and user-space should do whatever it takes to recover from copy-to-user failures of needed info from the kernel, and it really depends on the user-space usage pattern of \"presumed\". IIRC the original reason for copying it back to user-space was, that if a relocation offsets were patched up by the kernel, and then the process was sent a signal causing it to retry execbuf, then \"presumed\" had to be updated, otherwise it would be inconsistent with what's currently in the command stream, which is very bad. If \"presumed\" is, however, only used by user-space to guess an offset, the correct act\n" - " ion would be to swallow the -EFAULT.\n" + "> In fact failures of pushbuf / execbuf *after* commands are successfully submitted are generally very hard to recover from. That's why the kernel should do whatever it takes to recover from such failures, and user-space should do whatever it takes to recover from copy-to-user failures of needed info from the kernel, and it really depends on the user-space usage pattern of \"presumed\". IIRC the original reason for copying it back to user-space was, that if a relocation offsets were patched up by the kernel, and then the process was sent a signal causing it to retry execbuf, then \"presumed\" had to be updated, otherwise it would be inconsistent with what's currently in the command stream, which is very bad. If \"presumed\" is, however, only used by user-space to guess an offset, the correct action would be to swallow the -EFAULT.\n" "Yeah it's a guess from userspace. But it's probably still a programming error by userspace if it uses a read-only\n" "mapping for presumed, or a mapping that's invalidated. :P But there's nothing I can do at that point,\n" "I can't undo something I just committed. This is why I asked whether I should swallow it or not, because it's\n" @@ -113,4 +112,4 @@ "\n" ~Maarten -63e7e00e742a349804671027c53398c33abb96368a52cbcfa5a52183774b1144 +f68b1edc6d386c6e6b546a087801369ee76912c0d598f2fd2a6684f6fad3238b
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.