* GWML post from [email protected] requires approval
@ 2021-05-26 9:00 gwml-owner
0 siblings, 0 replies; 8+ messages in thread
From: gwml-owner @ 2021-05-26 9:00 UTC (permalink / raw)
To: gwml-owner
[-- Attachment #1: Type: text/plain, Size: 379 bytes --]
As list administrator, your authorization is requested for the
following mailing list posting:
List: [email protected]
From: [email protected]
Subject: Re: [gwml] Invitation to GNU/Weeb GitHub Organization
Reason: Post to moderated list
At your convenience, visit:
https://gwml.gnuweeb.org/admindb/gwml
to approve or deny the request.
[-- Attachment #2: Type: message/rfc822, Size: 1591 bytes --]
From: Ammar Faizi <[email protected]>
To: Febriyanto Nugroho via GWML <[email protected]>
Subject: Re: [gwml] Invitation to GNU/Weeb GitHub Organization
Date: Wed, 26 May 2021 16:00:09 +0700
Message-ID: <[email protected]>
> Halo pak, github username saya "febnug" bisa di cek lagi pak
>
> Terima kasih
Ok, sudah diinvite.
Buka https://github.com/GNUWeeb untuk accept invitationnya.
[-- Attachment #3: Type: message/rfc822, Size: 680 bytes --]
From: [email protected]
Subject: confirm 4f0b68e5ac0938bdeba1dc5f9334bd9ce61f6097
Date: Wed, 26 May 2021 09:00:16 +0000
Message-ID: <[email protected]>
If you reply to this message, keeping the Subject: header intact,
Mailman will discard the held message. Do this if the message is
spam. If you reply to this message and include an Approved: header
with the list password in it, the message will be approved for posting
to the list. The Approved: header can also appear in the first line
of the body of the reply.
^ permalink raw reply [flat|nested] 8+ messages in thread* GWML post from [email protected] requires approval
@ 2022-01-07 11:02 gwml-owner
0 siblings, 0 replies; 8+ messages in thread
From: gwml-owner @ 2022-01-07 11:02 UTC (permalink / raw)
To: gwml-owner
[-- Attachment #1: Type: text/plain, Size: 412 bytes --]
As list administrator, your authorization is requested for the
following mailing list posting:
List: [email protected]
From: [email protected]
Subject: Re: [RFC PATCH v3 3/3] io_uring: Add `sendto(2)` and `recvfrom(2)` support
Reason: Too many recipients to the message
At your convenience, visit:
https://gwml.gnuweeb.org/admindb/gwml
to approve or deny the request.
[-- Attachment #2: Type: message/rfc822, Size: 23795 bytes --]
[-- Attachment #2.1.1.1.1: Type: text/plain, Size: 11433 bytes --]
On 1/7/22 3:33 PM, Praveen Kumar wrote:
> On 07-01-2022 02:08, Ammar Faizi wrote:
>> On Thu, 6 Jan 2022 at 23:01:59 +0530, Praveen Kumar <[email protected]> wrote:
>>> On 30-12-2021 23:22, Ammar Faizi wrote:
>>>> This adds sendto(2) and recvfrom(2) support for io_uring.
>>>>
>>>> New opcodes:
>>>> IORING_OP_SENDTO
>>>> IORING_OP_RECVFROM
>>>>
>>>> Cc: Nugra <[email protected]>
>>>> Tested-by: Nugra <[email protected]>
>>>> Link: https://github.com/axboe/liburing/issues/397
>>>> Signed-off-by: Ammar Faizi <[email protected]>
>>>> ---
>>>>
>>>> v3:
>>>> - Fix build error when CONFIG_NET is undefined should be done in
>>>> the first patch, not this patch.
>>>>
>>>> - Add Tested-by tag from Nugra.
>>>>
>>>> v2:
>>>> - In `io_recvfrom()`, mark the error check of `move_addr_to_user()`
>>>> call as unlikely.
>>>>
>>>> - Fix build error when CONFIG_NET is undefined.
>>>>
>>>> - Added Nugra to CC list (tester).
>>>> ---
>>>> fs/io_uring.c | 80 +++++++++++++++++++++++++++++++++--
>>>> include/uapi/linux/io_uring.h | 2 +
>>>> 2 files changed, 78 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/fs/io_uring.c b/fs/io_uring.c
>>>> index 7adcb591398f..3726958f8f58 100644
>>>> --- a/fs/io_uring.c
>>>> +++ b/fs/io_uring.c
>>>> @@ -575,7 +575,15 @@ struct io_sr_msg {
>>>> union {
>>>> struct compat_msghdr __user *umsg_compat;
>>>> struct user_msghdr __user *umsg;
>>>> - void __user *buf;
>>>> +
>>>> + struct {
>>>> + void __user *buf;
>>>> + struct sockaddr __user *addr;
>>>> + union {
>>>> + int sendto_addr_len;
>>>> + int __user *recvfrom_addr_len;
>>>> + };
>>>> + };
>>>> };
>>>> int msg_flags;
>>>> int bgid;
>>>> @@ -1133,6 +1141,19 @@ static const struct io_op_def io_op_defs[] = {
>>>> .needs_file = 1
>>>> },
>>>> [IORING_OP_GETXATTR] = {},
>>>> + [IORING_OP_SENDTO] = {
>>>> + .needs_file = 1,
>>>> + .unbound_nonreg_file = 1,
>>>> + .pollout = 1,
>>>> + .audit_skip = 1,
>>>> + },
>>>> + [IORING_OP_RECVFROM] = {
>>>> + .needs_file = 1,
>>>> + .unbound_nonreg_file = 1,
>>>> + .pollin = 1,
>>>> + .buffer_select = 1,
>>>> + .audit_skip = 1,
>>>> + },
>>>> };
>>>>
>>>> /* requests with any of those set should undergo io_disarm_next() */
>>>> @@ -5216,12 +5237,24 @@ static int io_sendmsg_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
>>>> if (unlikely(req->ctx->flags & IORING_SETUP_IOPOLL))
>>>> return -EINVAL;
>>>>
>>>> + /*
>>>> + * For IORING_OP_SEND{,TO}, the assignment to @sr->umsg
>>>> + * is equivalent to an assignment to @sr->buf.
>>>> + */
>>>> sr->umsg = u64_to_user_ptr(READ_ONCE(sqe->addr));
>>>> +
>>>> sr->len = READ_ONCE(sqe->len);
>>>> sr->msg_flags = READ_ONCE(sqe->msg_flags) | MSG_NOSIGNAL;
>>>> if (sr->msg_flags & MSG_DONTWAIT)
>>>> req->flags |= REQ_F_NOWAIT;
>>>>
>>>> + if (req->opcode == IORING_OP_SENDTO) {
>>>> + sr->addr = u64_to_user_ptr(READ_ONCE(sqe->addr2));
>>>> + sr->sendto_addr_len = READ_ONCE(sqe->addr3);
>>>> + } else {
>>>> + sr->addr = (struct sockaddr __user *) NULL;
>>>
>>> Let's have sendto_addr_len = 0
>>
>> Will do in the RFC v5.
>>
>>>
>>>> + }
>>>> +
>>>> #ifdef CONFIG_COMPAT
>>>> if (req->ctx->compat)
>>>> sr->msg_flags |= MSG_CMSG_COMPAT;
>>>> @@ -5275,6 +5308,7 @@ static int io_sendmsg(struct io_kiocb *req, unsigned int issue_flags)
>>>>
>>>> static int io_sendto(struct io_kiocb *req, unsigned int issue_flags)
>>>> {
>>>> + struct sockaddr_storage address;
>>>> struct io_sr_msg *sr = &req->sr_msg;
>>>> struct msghdr msg;
>>>> struct iovec iov;
>>>> @@ -5291,10 +5325,20 @@ static int io_sendto(struct io_kiocb *req, unsigned int issue_flags)
>>>> if (unlikely(ret))
>>>> return ret;
>>>>
>>>> - msg.msg_name = NULL;
>>>> +
>>>> msg.msg_control = NULL;
>>>> msg.msg_controllen = 0;
>>>> - msg.msg_namelen = 0;
>>>> + if (sr->addr) {
>>>> + ret = move_addr_to_kernel(sr->addr, sr->sendto_addr_len,
>>>> + &address);
>>>> + if (unlikely(ret < 0))
>>>> + goto fail;
>>>> + msg.msg_name = (struct sockaddr *) &address;
>>>> + msg.msg_namelen = sr->sendto_addr_len;
>>>> + } else {
>>>> + msg.msg_name = NULL;
>>>> + msg.msg_namelen = 0;
>>>> + }
>>>>
>>>> flags = req->sr_msg.msg_flags;
>>>> if (issue_flags & IO_URING_F_NONBLOCK)
>>>> @@ -5309,6 +5353,7 @@ static int io_sendto(struct io_kiocb *req, unsigned int issue_flags)
>>>> return -EAGAIN;
>>>> if (ret == -ERESTARTSYS)
>>>> ret = -EINTR;
>>>> + fail:
>>>> req_set_fail(req);
>>>
>>> I think there is a problem with "fail" goto statement. Not getting
>>> full clarity on this change. With latest kernel, I see
>>> req_set_fail(req) inside if check, which I don't see here. Can you
>>> please resend the patch on latest kernel version. Thanks.
>>
>> I will send the v5 on top of "for-next" branch in Jens' tree soon.
>>
>> That is already inside an "if check" anyway. We go to that label when
>> the move_addr_to_kernel() fails (most of the time it is -EFAULT or
>> -EINVAL).
>>
>> That part looks like this (note the if check before the goto):
>> ----------------------------------------------------------------------
>> msg.msg_control = NULL;
>> msg.msg_controllen = 0;
>> if (sr->addr) {
>> ret = move_addr_to_kernel(sr->addr, sr->sendto_addr_len,
>> &address);
>> if (unlikely(ret < 0))
>> goto fail;
>> msg.msg_name = (struct sockaddr *) &address;
>> msg.msg_namelen = sr->sendto_addr_len;
>> } else {
>> msg.msg_name = NULL;
>> msg.msg_namelen = 0;
>> }
>>
>> flags = req->sr_msg.msg_flags;
>> if (issue_flags & IO_URING_F_NONBLOCK)
>> flags |= MSG_DONTWAIT;
>> if (flags & MSG_WAITALL)
>> min_ret = iov_iter_count(&msg.msg_iter);
>>
>> msg.msg_flags = flags;
>> ret = sock_sendmsg(sock, &msg);
>> if (ret < min_ret) {
>> if (ret == -EAGAIN && (issue_flags & IO_URING_F_NONBLOCK))
>> return -EAGAIN;
>> if (ret == -ERESTARTSYS)
>> ret = -EINTR;
>> fail:
>
> Thanks for sending this. IMO this goto label should be just before
> the "if (ret < min_ret)" statement.
AFAICT, error returned by move_addr_to_kernel are only -EFAULT and -EINVAL,
so the check against -EAGAIN and -ERESTARTSYS is unnecessary for that
case. We can skip that.
RFC v4 here (rebased on top of "for-next" Jens' tree):
https://lore.kernel.org/io-uring/[email protected]/T/
>
>> req_set_fail(req);
>> }
>> __io_req_complete(req, issue_flags, ret, 0);
>> return 0;
>> ----------------------------------------------------------------------
>>
>>>> }
>>>> __io_req_complete(req, issue_flags, ret, 0);
>>>> @@ -5427,13 +5472,25 @@ static int io_recvmsg_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
>>>> if (unlikely(req->ctx->flags & IORING_SETUP_IOPOLL))
>>>> return -EINVAL;
>>>>
>>>> + /*
>>>> + * For IORING_OP_RECV{,FROM}, the assignment to @sr->umsg
>>>> + * is equivalent to an assignment to @sr->buf.
>>>> + */
>>>> sr->umsg = u64_to_user_ptr(READ_ONCE(sqe->addr));
>>>> +
>>>> sr->len = READ_ONCE(sqe->len);
>>>> sr->bgid = READ_ONCE(sqe->buf_group);
>>>> sr->msg_flags = READ_ONCE(sqe->msg_flags) | MSG_NOSIGNAL;
>>>> if (sr->msg_flags & MSG_DONTWAIT)
>>>> req->flags |= REQ_F_NOWAIT;
>>>>
>>>> + if (req->opcode == IORING_OP_RECVFROM) {
>>>> + sr->addr = u64_to_user_ptr(READ_ONCE(sqe->addr2));
>>>> + sr->recvfrom_addr_len = u64_to_user_ptr(READ_ONCE(sqe->addr3));
>>>> + } else {
>>>> + sr->addr = (struct sockaddr __user *) NULL;
>>>
>>> I think recvfrom_addr_len should also be pointed to NULL, instead of
>>> garbage for this case.
>>
>> Will do in the RFC v5.
>>
>>>
>>>> + }
>>>> +
>>>> #ifdef CONFIG_COMPAT
>>>> if (req->ctx->compat)
>>>> sr->msg_flags |= MSG_CMSG_COMPAT;
>>>> @@ -5509,6 +5566,7 @@ static int io_recvfrom(struct io_kiocb *req, unsigned int issue_flags)
>>>> struct iovec iov;
>>>> unsigned flags;
>>>> int ret, min_ret = 0;
>>>> + struct sockaddr_storage address;
>>>> bool force_nonblock = issue_flags & IO_URING_F_NONBLOCK;
>>>>
>>>> sock = sock_from_file(req->file);
>>>> @@ -5526,7 +5584,7 @@ static int io_recvfrom(struct io_kiocb *req, unsigned int issue_flags)
>>>> if (unlikely(ret))
>>>> goto out_free;
>>>>
>>>> - msg.msg_name = NULL;
>>>> + msg.msg_name = sr->addr ? (struct sockaddr *) &address : NULL;
>>>> msg.msg_control = NULL;
>>>> msg.msg_controllen = 0;
>>>> msg.msg_namelen = 0;
>>>
>>> I think namelen should also be updated ?
>>
>> It doesn't have to be updated. From net/socket.c there is a comment
>> like this:
>>
>> /* We assume all kernel code knows the size of sockaddr_storage */
>> msg.msg_namelen = 0;
>>
>> Full __sys_recvfrom() source code, see here:
>> https://github.com/torvalds/linux/blob/v5.16-rc8/net/socket.c#L2085-L2088
>>
>> I will add the same comment in next series to clarify this one.
>>
>>>
>>>> @@ -5540,6 +5598,16 @@ static int io_recvfrom(struct io_kiocb *req, unsigned int issue_flags)
>>>> min_ret = iov_iter_count(&msg.msg_iter);
>>>>
>>>> ret = sock_recvmsg(sock, &msg, flags);
>>>> +
>>>> + if (ret >= 0 && sr->addr != NULL) {
>>>> + int tmp;
>>>> +
>>>> + tmp = move_addr_to_user(&address, msg.msg_namelen, sr->addr,
>>>> + sr->recvfrom_addr_len);
>>>> + if (unlikely(tmp < 0))
>>>> + ret = tmp;
>>>> + }
>>>> +
>>>> out_free:
>>>> if (ret < min_ret) {
>>>> if (ret == -EAGAIN && force_nonblock)
>>>> @@ -6778,9 +6846,11 @@ static int io_req_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
>>>> case IORING_OP_SYNC_FILE_RANGE:
>>>> return io_sfr_prep(req, sqe);
>>>> case IORING_OP_SENDMSG:
>>>> + case IORING_OP_SENDTO:
>>>> case IORING_OP_SEND:
>>>> return io_sendmsg_prep(req, sqe);
>>>> case IORING_OP_RECVMSG:
>>>> + case IORING_OP_RECVFROM:
>>>> case IORING_OP_RECV:
>>>> return io_recvmsg_prep(req, sqe);
>>>> case IORING_OP_CONNECT:
>>>> @@ -7060,12 +7130,14 @@ static int io_issue_sqe(struct io_kiocb *req, unsigned int issue_flags)
>>>> case IORING_OP_SENDMSG:
>>>> ret = io_sendmsg(req, issue_flags);
>>>> break;
>>>> + case IORING_OP_SENDTO:
>>>> case IORING_OP_SEND:
>>>> ret = io_sendto(req, issue_flags);
>>>> break;
>>>> case IORING_OP_RECVMSG:
>>>> ret = io_recvmsg(req, issue_flags);
>>>> break;
>>>> + case IORING_OP_RECVFROM:
>>>> case IORING_OP_RECV:
>>>> ret = io_recvfrom(req, issue_flags);
>>>> break;
>>>> diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
>>>> index efc7ac9b3a6b..a360069d1e8e 100644
>>>> --- a/include/uapi/linux/io_uring.h
>>>> +++ b/include/uapi/linux/io_uring.h
>>>> @@ -150,6 +150,8 @@ enum {
>>>> IORING_OP_SETXATTR,
>>>> IORING_OP_FGETXATTR,
>>>> IORING_OP_GETXATTR,
>>>> + IORING_OP_SENDTO,
>>>> + IORING_OP_RECVFROM,
>>>>
>>>> /* this goes last, obviously */
>>>> IORING_OP_LAST,
>>>
>>>
>>> Regards,
>>>
>>> ~Praveen.
>>>
>>
>> Thanks for the review. I will send the RFC v5 soon.
>>
>
--
Ammar Faizi
[-- Attachment #2.1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 1793 bytes --]
[-- Attachment #2.1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 678 bytes --]
From: [email protected]
Subject: confirm 6366c994ca65815faeff02941822aee51e01347c
Date: Fri, 07 Jan 2022 11:02:12 +0000
Message-ID: <[email protected]>
If you reply to this message, keeping the Subject: header intact,
Mailman will discard the held message. Do this if the message is
spam. If you reply to this message and include an Approved: header
with the list password in it, the message will be approved for posting
to the list. The Approved: header can also appear in the first line
of the body of the reply.
^ permalink raw reply [flat|nested] 8+ messages in thread* GWML post from [email protected] requires approval
@ 2022-01-07 0:00 gwml-owner
0 siblings, 0 replies; 8+ messages in thread
From: gwml-owner @ 2022-01-07 0:00 UTC (permalink / raw)
To: gwml-owner
[-- Attachment #1: Type: text/plain, Size: 408 bytes --]
As list administrator, your authorization is requested for the
following mailing list posting:
List: [email protected]
From: [email protected]
Subject: [RFC PATCH v4 3/3] io_uring: Add `sendto(2)` and `recvfrom(2)` support
Reason: Too many recipients to the message
At your convenience, visit:
https://gwml.gnuweeb.org/admindb/gwml
to approve or deny the request.
[-- Attachment #2: Type: message/rfc822, Size: 9220 bytes --]
From: Ammar Faizi <[email protected]>
To: Jens Axboe <[email protected]>
Cc: Ammar Faizi <[email protected]>, io-uring Mailing List <[email protected]>, netdev Mailing List <[email protected]>, GNU/Weeb Mailing List <[email protected]>, Linux Kernel Mailing List <[email protected]>, Pavel Begunkov <[email protected]>, "David S. Miller" <[email protected]>, Jakub Kicinski <[email protected]>, Nugra <[email protected]>, Praveen Kumar <[email protected]>, Ammar Faizi <[email protected]>
Subject: [RFC PATCH v4 3/3] io_uring: Add `sendto(2)` and `recvfrom(2)` support
Date: Fri, 7 Jan 2022 07:00:05 +0700
Message-ID: <[email protected]>
This adds sendto(2) and recvfrom(2) support for io_uring.
New opcodes:
IORING_OP_SENDTO
IORING_OP_RECVFROM
Cc: Nugra <[email protected]>
Cc: Praveen Kumar <[email protected]>
Link: https://github.com/axboe/liburing/issues/397
Signed-off-by: Ammar Faizi <[email protected]>
---
v4:
- Rebase the work (sync with "for-next" branch in Jens' tree).
- Remove Tested-by tag from Nugra as this patch changes.
- (Address Praveen's comment) Zero `sendto_addr_len` and
`recvfrom_addr_len` on prep when the `req->opcode` is not
`IORING_OP_{SENDTO,RECVFROM}`.
v3:
- Fix build error when CONFIG_NET is undefined should be done in
the first patch, not this patch.
- Add Tested-by tag from Nugra.
v2:
- In `io_recvfrom()`, mark the error check of `move_addr_to_user()`
call as unlikely.
- Fix build error when CONFIG_NET is undefined.
- Added Nugra to CC list (tester).
---
---
fs/io_uring.c | 82 +++++++++++++++++++++++++++++++++--
include/uapi/linux/io_uring.h | 5 ++-
2 files changed, 82 insertions(+), 5 deletions(-)
diff --git a/fs/io_uring.c b/fs/io_uring.c
index 5e45e4d6969c..3c85dd0d50b4 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -574,7 +574,15 @@ struct io_sr_msg {
union {
struct compat_msghdr __user *umsg_compat;
struct user_msghdr __user *umsg;
- void __user *buf;
+
+ struct {
+ void __user *buf;
+ struct sockaddr __user *addr;
+ union {
+ int sendto_addr_len;
+ int __user *recvfrom_addr_len;
+ };
+ };
};
int msg_flags;
int bgid;
@@ -1105,6 +1113,19 @@ static const struct io_op_def io_op_defs[] = {
[IORING_OP_MKDIRAT] = {},
[IORING_OP_SYMLINKAT] = {},
[IORING_OP_LINKAT] = {},
+ [IORING_OP_SENDTO] = {
+ .needs_file = 1,
+ .unbound_nonreg_file = 1,
+ .pollout = 1,
+ .audit_skip = 1,
+ },
+ [IORING_OP_RECVFROM] = {
+ .needs_file = 1,
+ .unbound_nonreg_file = 1,
+ .pollin = 1,
+ .buffer_select = 1,
+ .audit_skip = 1,
+ },
};
/* requests with any of those set should undergo io_disarm_next() */
@@ -4890,12 +4911,25 @@ static int io_sendmsg_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
if (unlikely(req->ctx->flags & IORING_SETUP_IOPOLL))
return -EINVAL;
+ /*
+ * For IORING_OP_SEND{,TO}, the assignment to @sr->umsg
+ * is equivalent to an assignment to @sr->buf.
+ */
sr->umsg = u64_to_user_ptr(READ_ONCE(sqe->addr));
+
sr->len = READ_ONCE(sqe->len);
sr->msg_flags = READ_ONCE(sqe->msg_flags) | MSG_NOSIGNAL;
if (sr->msg_flags & MSG_DONTWAIT)
req->flags |= REQ_F_NOWAIT;
+ if (req->opcode == IORING_OP_SENDTO) {
+ sr->addr = u64_to_user_ptr(READ_ONCE(sqe->addr2));
+ sr->sendto_addr_len = READ_ONCE(sqe->addr3);
+ } else {
+ sr->addr = (struct sockaddr __user *) NULL;
+ sr->sendto_addr_len = 0;
+ }
+
#ifdef CONFIG_COMPAT
if (req->ctx->compat)
sr->msg_flags |= MSG_CMSG_COMPAT;
@@ -4949,6 +4983,7 @@ static int io_sendmsg(struct io_kiocb *req, unsigned int issue_flags)
static int io_sendto(struct io_kiocb *req, unsigned int issue_flags)
{
+ struct sockaddr_storage address;
struct io_sr_msg *sr = &req->sr_msg;
struct msghdr msg;
struct iovec iov;
@@ -4965,10 +5000,20 @@ static int io_sendto(struct io_kiocb *req, unsigned int issue_flags)
if (unlikely(ret))
return ret;
- msg.msg_name = NULL;
+
msg.msg_control = NULL;
msg.msg_controllen = 0;
- msg.msg_namelen = 0;
+ if (sr->addr) {
+ ret = move_addr_to_kernel(sr->addr, sr->sendto_addr_len,
+ &address);
+ if (unlikely(ret < 0))
+ goto fail;
+ msg.msg_name = (struct sockaddr *) &address;
+ msg.msg_namelen = sr->sendto_addr_len;
+ } else {
+ msg.msg_name = NULL;
+ msg.msg_namelen = 0;
+ }
flags = req->sr_msg.msg_flags;
if (issue_flags & IO_URING_F_NONBLOCK)
@@ -4983,6 +5028,7 @@ static int io_sendto(struct io_kiocb *req, unsigned int issue_flags)
return -EAGAIN;
if (ret == -ERESTARTSYS)
ret = -EINTR;
+fail:
req_set_fail(req);
}
__io_req_complete(req, issue_flags, ret, 0);
@@ -5101,13 +5147,26 @@ static int io_recvmsg_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
if (unlikely(req->ctx->flags & IORING_SETUP_IOPOLL))
return -EINVAL;
+ /*
+ * For IORING_OP_RECV{,FROM}, the assignment to @sr->umsg
+ * is equivalent to an assignment to @sr->buf.
+ */
sr->umsg = u64_to_user_ptr(READ_ONCE(sqe->addr));
+
sr->len = READ_ONCE(sqe->len);
sr->bgid = READ_ONCE(sqe->buf_group);
sr->msg_flags = READ_ONCE(sqe->msg_flags) | MSG_NOSIGNAL;
if (sr->msg_flags & MSG_DONTWAIT)
req->flags |= REQ_F_NOWAIT;
+ if (req->opcode == IORING_OP_RECVFROM) {
+ sr->addr = u64_to_user_ptr(READ_ONCE(sqe->addr2));
+ sr->recvfrom_addr_len = u64_to_user_ptr(READ_ONCE(sqe->addr3));
+ } else {
+ sr->addr = (struct sockaddr __user *) NULL;
+ sr->recvfrom_addr_len = (int __user *) NULL;
+ }
+
#ifdef CONFIG_COMPAT
if (req->ctx->compat)
sr->msg_flags |= MSG_CMSG_COMPAT;
@@ -5183,6 +5242,7 @@ static int io_recvfrom(struct io_kiocb *req, unsigned int issue_flags)
struct iovec iov;
unsigned flags;
int ret, min_ret = 0;
+ struct sockaddr_storage address;
bool force_nonblock = issue_flags & IO_URING_F_NONBLOCK;
sock = sock_from_file(req->file);
@@ -5200,9 +5260,10 @@ static int io_recvfrom(struct io_kiocb *req, unsigned int issue_flags)
if (unlikely(ret))
goto out_free;
- msg.msg_name = NULL;
+ msg.msg_name = sr->addr ? (struct sockaddr *) &address : NULL;
msg.msg_control = NULL;
msg.msg_controllen = 0;
+ /* We assume all kernel code knows the size of sockaddr_storage */
msg.msg_namelen = 0;
msg.msg_iocb = NULL;
msg.msg_flags = 0;
@@ -5214,6 +5275,15 @@ static int io_recvfrom(struct io_kiocb *req, unsigned int issue_flags)
min_ret = iov_iter_count(&msg.msg_iter);
ret = sock_recvmsg(sock, &msg, flags);
+ if (ret >= 0 && sr->addr != NULL) {
+ int tmp;
+
+ tmp = move_addr_to_user(&address, msg.msg_namelen, sr->addr,
+ sr->recvfrom_addr_len);
+ if (unlikely(tmp < 0))
+ ret = tmp;
+ }
+
out_free:
if (ret < min_ret) {
if (ret == -EAGAIN && force_nonblock)
@@ -6452,9 +6522,11 @@ static int io_req_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
case IORING_OP_SYNC_FILE_RANGE:
return io_sfr_prep(req, sqe);
case IORING_OP_SENDMSG:
+ case IORING_OP_SENDTO:
case IORING_OP_SEND:
return io_sendmsg_prep(req, sqe);
case IORING_OP_RECVMSG:
+ case IORING_OP_RECVFROM:
case IORING_OP_RECV:
return io_recvmsg_prep(req, sqe);
case IORING_OP_CONNECT:
@@ -6709,12 +6781,14 @@ static int io_issue_sqe(struct io_kiocb *req, unsigned int issue_flags)
case IORING_OP_SENDMSG:
ret = io_sendmsg(req, issue_flags);
break;
+ case IORING_OP_SENDTO:
case IORING_OP_SEND:
ret = io_sendto(req, issue_flags);
break;
case IORING_OP_RECVMSG:
ret = io_recvmsg(req, issue_flags);
break;
+ case IORING_OP_RECVFROM:
case IORING_OP_RECV:
ret = io_recvfrom(req, issue_flags);
break;
diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
index 787f491f0d2a..a58cde19b4d0 100644
--- a/include/uapi/linux/io_uring.h
+++ b/include/uapi/linux/io_uring.h
@@ -60,7 +60,8 @@ struct io_uring_sqe {
__s32 splice_fd_in;
__u32 file_index;
};
- __u64 __pad2[2];
+ __u64 addr3;
+ __u64 __pad2[1];
};
enum {
@@ -143,6 +144,8 @@ enum {
IORING_OP_MKDIRAT,
IORING_OP_SYMLINKAT,
IORING_OP_LINKAT,
+ IORING_OP_SENDTO,
+ IORING_OP_RECVFROM,
/* this goes last, obviously */
IORING_OP_LAST,
--
2.32.0
[-- Attachment #3: Type: message/rfc822, Size: 678 bytes --]
From: [email protected]
Subject: confirm ca224d5fa35fbe06f97340ac4d075f770ea93dcb
Date: Fri, 07 Jan 2022 00:00:29 +0000
Message-ID: <[email protected]>
If you reply to this message, keeping the Subject: header intact,
Mailman will discard the held message. Do this if the message is
spam. If you reply to this message and include an Approved: header
with the list password in it, the message will be approved for posting
to the list. The Approved: header can also appear in the first line
of the body of the reply.
^ permalink raw reply related [flat|nested] 8+ messages in thread* GWML post from [email protected] requires approval
@ 2022-01-07 0:00 gwml-owner
0 siblings, 0 replies; 8+ messages in thread
From: gwml-owner @ 2022-01-07 0:00 UTC (permalink / raw)
To: gwml-owner
[-- Attachment #1: Type: text/plain, Size: 416 bytes --]
As list administrator, your authorization is requested for the
following mailing list posting:
List: [email protected]
From: [email protected]
Subject: [RFC PATCH v4 1/3] io_uring: Rename `io_{send,recv}` to `io_{sendto,recvfrom}`
Reason: Too many recipients to the message
At your convenience, visit:
https://gwml.gnuweeb.org/admindb/gwml
to approve or deny the request.
[-- Attachment #2: Type: message/rfc822, Size: 4417 bytes --]
From: Ammar Faizi <[email protected]>
To: Jens Axboe <[email protected]>
Cc: Ammar Faizi <[email protected]>, io-uring Mailing List <[email protected]>, netdev Mailing List <[email protected]>, GNU/Weeb Mailing List <[email protected]>, Linux Kernel Mailing List <[email protected]>, Pavel Begunkov <[email protected]>, "David S. Miller" <[email protected]>, Jakub Kicinski <[email protected]>, Nugra <[email protected]>, Praveen Kumar <[email protected]>, Ammar Faizi <[email protected]>
Subject: [RFC PATCH v4 1/3] io_uring: Rename `io_{send,recv}` to `io_{sendto,recvfrom}`
Date: Fri, 7 Jan 2022 07:00:03 +0700
Message-ID: <[email protected]>
Currently we can perform `send` and `recv` via io_uring. And now, we
are going to add `sendto` and `recvfrom` support for io_uring.
Note that:
Calling `send(fd, buf, len, flags)` is equivalent to calling
`sendto(fd, buf, len, flags, NULL, 0)`. Therefore, `sendto`
is a superset of `send`.
Calling `recv(fd, buf, len, flags)` is equivalent to calling
`recvfrom(fd, buf, len, flags, NULL, NULL)`. Therefore, `recvfrom`
is a superset of `recv`.
As such, let's direct the current supported `IORING_OP_{SEND,RECV}` to
`io_{sendto,recvfrom}`. These functions will also be used for
`IORING_OP_{SENDTO,RECVFROM}` operation in the next patches.
Cc: Nugra <[email protected]>
Signed-off-by: Ammar Faizi <[email protected]>
---
v4:
- Rebase the work (sync with "for-next" branch in Jens' tree).
v3:
- Fix build error when CONFIG_NET is undefined for PATCH 1/3. I
tried to fix it in PATCH 3/3, but it should be fixed in PATCH 1/3,
otherwise it breaks the build in PATCH 1/3.
v2:
- Added Nugra to CC list (tester).
---
---
fs/io_uring.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/io_uring.c b/fs/io_uring.c
index d5da4a898fe8..5e45e4d6969c 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -4947,7 +4947,7 @@ static int io_sendmsg(struct io_kiocb *req, unsigned int issue_flags)
return 0;
}
-static int io_send(struct io_kiocb *req, unsigned int issue_flags)
+static int io_sendto(struct io_kiocb *req, unsigned int issue_flags)
{
struct io_sr_msg *sr = &req->sr_msg;
struct msghdr msg;
@@ -5173,7 +5173,7 @@ static int io_recvmsg(struct io_kiocb *req, unsigned int issue_flags)
return 0;
}
-static int io_recv(struct io_kiocb *req, unsigned int issue_flags)
+static int io_recvfrom(struct io_kiocb *req, unsigned int issue_flags)
{
struct io_buffer *kbuf;
struct io_sr_msg *sr = &req->sr_msg;
@@ -5381,8 +5381,8 @@ IO_NETOP_PREP_ASYNC(sendmsg);
IO_NETOP_PREP_ASYNC(recvmsg);
IO_NETOP_PREP_ASYNC(connect);
IO_NETOP_PREP(accept);
-IO_NETOP_FN(send);
-IO_NETOP_FN(recv);
+IO_NETOP_FN(sendto);
+IO_NETOP_FN(recvfrom);
#endif /* CONFIG_NET */
struct io_poll_table {
@@ -6710,13 +6710,13 @@ static int io_issue_sqe(struct io_kiocb *req, unsigned int issue_flags)
ret = io_sendmsg(req, issue_flags);
break;
case IORING_OP_SEND:
- ret = io_send(req, issue_flags);
+ ret = io_sendto(req, issue_flags);
break;
case IORING_OP_RECVMSG:
ret = io_recvmsg(req, issue_flags);
break;
case IORING_OP_RECV:
- ret = io_recv(req, issue_flags);
+ ret = io_recvfrom(req, issue_flags);
break;
case IORING_OP_TIMEOUT:
ret = io_timeout(req, issue_flags);
--
2.32.0
[-- Attachment #3: Type: message/rfc822, Size: 677 bytes --]
From: [email protected]
Subject: confirm 6435d502b0662c22edf126199b70fda6f0950887
Date: Fri, 07 Jan 2022 00:00:28 +0000
Message-ID: <[email protected]>
If you reply to this message, keeping the Subject: header intact,
Mailman will discard the held message. Do this if the message is
spam. If you reply to this message and include an Approved: header
with the list password in it, the message will be approved for posting
to the list. The Approved: header can also appear in the first line
of the body of the reply.
^ permalink raw reply related [flat|nested] 8+ messages in thread* GWML post from [email protected] requires approval
@ 2022-01-07 0:00 gwml-owner
0 siblings, 0 replies; 8+ messages in thread
From: gwml-owner @ 2022-01-07 0:00 UTC (permalink / raw)
To: gwml-owner
[-- Attachment #1: Type: text/plain, Size: 413 bytes --]
As list administrator, your authorization is requested for the
following mailing list posting:
List: [email protected]
From: [email protected]
Subject: [RFC PATCH v4 2/3] net: Make `move_addr_to_user()` be a non static function
Reason: Too many recipients to the message
At your convenience, visit:
https://gwml.gnuweeb.org/admindb/gwml
to approve or deny the request.
[-- Attachment #2: Type: message/rfc822, Size: 3433 bytes --]
From: Ammar Faizi <[email protected]>
To: Jens Axboe <[email protected]>
Cc: Ammar Faizi <[email protected]>, io-uring Mailing List <[email protected]>, netdev Mailing List <[email protected]>, GNU/Weeb Mailing List <[email protected]>, Linux Kernel Mailing List <[email protected]>, Pavel Begunkov <[email protected]>, "David S. Miller" <[email protected]>, Jakub Kicinski <[email protected]>, Nugra <[email protected]>, Praveen Kumar <[email protected]>, Ammar Faizi <[email protected]>
Subject: [RFC PATCH v4 2/3] net: Make `move_addr_to_user()` be a non static function
Date: Fri, 7 Jan 2022 07:00:04 +0700
Message-ID: <[email protected]>
In order to add recvfrom support for io_uring, we need to call
`move_addr_to_user()` from fs/io_uring.c.
This makes `move_addr_to_user()` be a non static function so we can
call it from io_uring.
Cc: "David S. Miller" <[email protected]>
Cc: Jakub Kicinski <[email protected]>
Cc: [email protected]
Cc: Nugra <[email protected]>
Signed-off-by: Ammar Faizi <[email protected]>
---
v4:
* No changes *
v3:
* No changes *
v2:
- Added Nugra to CC list (tester).
---
---
include/linux/socket.h | 2 ++
net/socket.c | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 8ef26d89ef49..0d0bc1ace50c 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -371,6 +371,8 @@ struct ucred {
#define IPX_TYPE 1
extern int move_addr_to_kernel(void __user *uaddr, int ulen, struct sockaddr_storage *kaddr);
+extern int move_addr_to_user(struct sockaddr_storage *kaddr, int klen,
+ void __user *uaddr, int __user *ulen);
extern int put_cmsg(struct msghdr*, int level, int type, int len, void *data);
struct timespec64;
diff --git a/net/socket.c b/net/socket.c
index 7f64a6eccf63..af521d351c8a 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -267,8 +267,8 @@ int move_addr_to_kernel(void __user *uaddr, int ulen, struct sockaddr_storage *k
* specified. Zero is returned for a success.
*/
-static int move_addr_to_user(struct sockaddr_storage *kaddr, int klen,
- void __user *uaddr, int __user *ulen)
+int move_addr_to_user(struct sockaddr_storage *kaddr, int klen,
+ void __user *uaddr, int __user *ulen)
{
int err;
int len;
--
2.32.0
[-- Attachment #3: Type: message/rfc822, Size: 677 bytes --]
From: [email protected]
Subject: confirm e03c395622c2f0d4cf90e77aa9640a8eb514ffc2
Date: Fri, 07 Jan 2022 00:00:28 +0000
Message-ID: <[email protected]>
If you reply to this message, keeping the Subject: header intact,
Mailman will discard the held message. Do this if the message is
spam. If you reply to this message and include an Approved: header
with the list password in it, the message will be approved for posting
to the list. The Approved: header can also appear in the first line
of the body of the reply.
^ permalink raw reply related [flat|nested] 8+ messages in thread* GWML post from [email protected] requires approval
@ 2022-01-07 0:00 gwml-owner
0 siblings, 0 replies; 8+ messages in thread
From: gwml-owner @ 2022-01-07 0:00 UTC (permalink / raw)
To: gwml-owner
[-- Attachment #1: Type: text/plain, Size: 407 bytes --]
As list administrator, your authorization is requested for the
following mailing list posting:
List: [email protected]
From: [email protected]
Subject: [RFC PATCH v4 0/3] Add sendto(2) and recvfrom(2) support for io_uring
Reason: Too many recipients to the message
At your convenience, visit:
https://gwml.gnuweeb.org/admindb/gwml
to approve or deny the request.
[-- Attachment #2: Type: message/rfc822, Size: 5934 bytes --]
From: Ammar Faizi <[email protected]>
To: Jens Axboe <[email protected]>
Cc: Ammar Faizi <[email protected]>, io-uring Mailing List <[email protected]>, netdev Mailing List <[email protected]>, GNU/Weeb Mailing List <[email protected]>, Linux Kernel Mailing List <[email protected]>, Pavel Begunkov <[email protected]>, "David S. Miller" <[email protected]>, Jakub Kicinski <[email protected]>, Nugra <[email protected]>, Praveen Kumar <[email protected]>, Ammar Faizi <[email protected]>
Subject: [RFC PATCH v4 0/3] Add sendto(2) and recvfrom(2) support for io_uring
Date: Fri, 7 Jan 2022 07:00:02 +0700
Message-ID: <[email protected]>
Hello,
This RFC patchset adds sendto(2) and recvfrom(2) support for io_uring.
It also addresses an issue in the liburing GitHub repository [1].
## Motivations
1) By using `sendto()` and `recvfrom()` we can make the submission
simpler compared to always using `sendmsg()` and `recvmsg()` from
the userspace.
2) There is a historical patch that tried to add the same
functionality, but did not end up being applied. [2]
On Tue, 7 Jul 2020 12:29:18 -0600, Jens Axboe <[email protected]> wrote:
> In a private conversation with the author, a good point was brought
> up that the sendto/recvfrom do not require an allocation of an async
> context, if we need to defer or go async with the request. I think
> that's a major win, to be honest. There are other benefits as well
> (like shorter path), but to me, the async less part is nice and will
> reduce overhead
## Changes summary
There are 3 patches in this series.
PATCH 1/3 renames io_recv to io_recvfrom and io_send to io_sendto.
Note that:
send(sockfd, buf, len, flags);
is equivalent to
sendto(sockfd, buf, len, flags, NULL, 0);
and
recv(sockfd, buf, len, flags);
is equivalent to
recvfrom(sockfd, buf, len, flags, NULL, NULL);
So it is saner to have `send` and `recv` directed to `sendto` and
`recvfrom` instead of the opposite with respect to the name.
PATCH 2/3 makes `move_addr_to_user()` be a non static function. This
function lives in net/socket.c, we need to call this from io_uring
to add `recvfrom()` support for io_uring. Added net files maintainers
to the CC list.
PATCH 3/3 adds `sendto(2)` and `recvfrom(2)` support for io_uring.
Added two new opcodes: IORING_OP_SENDTO and IORING_OP_RECVFROM.
## How to test
This patchset is based on "for-next" branch in Jens' tree commit:
c1537fd063e2f1dbd96d8f68b405a66297ee306f ("Merge branch 'for-5.17/drivers' into for-next")
It is also available in the Git repository at:
https://github.com/ammarfaizi2/linux-block.git ammarfaizi2/linux-block/io_uring-recvfrom-sendto.v4
Test with liburing (added the liburing support, docs, and test program),
the liburing support is based on liburing "master" branch commit:
918d8061ffdfdf253806a1e8e141c71644e678bd ("Remove getdents support")
It is available in the Git repository at:
https://github.com/ammarfaizi2/liburing.git sendto-recvfrom.v2
Please review and comment.
---
RFC v4 (this patchset):
- Rebase the work (sync with "for-next" branch in Jens' tree).
- Remove Tested-by tag from Nugra as we have changes.
- (Address Praveen's comment) Zero `sendto_addr_len` and
`recvfrom_addr_len` on prep when the `req->opcode` is not
`IORING_OP_{SENDTO,RECVFROM}`.
RFC v3:
- Fix build error when CONFIG_NET is undefined for PATCH 1/3. I
tried to fix it in PATCH 3/3, but it should be fixed in PATCH 1/3,
otherwise it breaks the build in PATCH 1/3.
- Added `io_uring_prep_{sendto,recvfrom}` docs to the liburing.
RFC v2:
- Rebase the work, now this patchset is based on commit
bb3294e22482db4b7ec ("Merge branch 'for-5.17/drivers' into
for-next").
- In `io_recvfrom()`, mark the error check of `move_addr_to_user()`
call as unlikely.
- Fix build error when CONFIG_NET is undefined.
- Update liburing test (the branch is still the same, just force
pushed).
- Added Nugra to CC list (tester).
---
RFC v3: https://lore.kernel.org/io-uring/[email protected]/
RFC v2: https://lore.kernel.org/io-uring/[email protected]/
RFC v1: https://lore.kernel.org/io-uring/[email protected]/
Link: https://github.com/axboe/liburing/issues/397 [1]
Link: https://lore.kernel.org/io-uring/[email protected]/ [2]
Signed-off-by: Ammar Faizi <[email protected]>
---
Ammar Faizi (3):
io_uring: Rename `io_{send,recv}` to `io_{sendto,recvfrom}`
net: Make `move_addr_to_user()` be a non static function
io_uring: Add `sendto(2)` and `recvfrom(2)` support
fs/io_uring.c | 94 +++++++++++++++++++++++++++++++----
include/linux/socket.h | 2 +
include/uapi/linux/io_uring.h | 5 +-
net/socket.c | 4 +-
4 files changed, 92 insertions(+), 13 deletions(-)
base-commit: c1537fd063e2f1dbd96d8f68b405a66297ee306f
--
2.32.0
[-- Attachment #3: Type: message/rfc822, Size: 677 bytes --]
From: [email protected]
Subject: confirm 48031ac272fc2898a28b5d39a56b1a2c79ee2eef
Date: Fri, 07 Jan 2022 00:00:27 +0000
Message-ID: <[email protected]>
If you reply to this message, keeping the Subject: header intact,
Mailman will discard the held message. Do this if the message is
spam. If you reply to this message and include an Approved: header
with the list password in it, the message will be approved for posting
to the list. The Approved: header can also appear in the first line
of the body of the reply.
^ permalink raw reply [flat|nested] 8+ messages in thread* GWML post from [email protected] requires approval
@ 2021-05-26 7:48 gwml-owner
0 siblings, 0 replies; 8+ messages in thread
From: gwml-owner @ 2021-05-26 7:48 UTC (permalink / raw)
To: gwml-owner
[-- Attachment #1: Type: text/plain, Size: 379 bytes --]
As list administrator, your authorization is requested for the
following mailing list posting:
List: [email protected]
From: [email protected]
Subject: Re: [gwml] Invitation to GNU/Weeb GitHub Organization
Reason: Post to moderated list
At your convenience, visit:
https://gwml.gnuweeb.org/admindb/gwml
to approve or deny the request.
[-- Attachment #2: Type: message/rfc822, Size: 1966 bytes --]
From: Ammar Faizi <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [gwml] Invitation to GNU/Weeb GitHub Organization
Date: Wed, 26 May 2021 14:48:11 +0700
Message-ID: <[email protected]>
Hi Faris,
Welcome to GNU/Weeb, I have invited you to join GNU/Weeb GitHub
Organization. Please accept the invitation.
For those who don't know how to accept the invitation, you can check
your email associated with your GitHub account, or just visit
https://github.com/GNUWeeb with your GitHub account and accept.
If you get the invitation expires, you can ask me to re-invite.
Regards,
Ammar Faizi
Cc: Faris <[email protected]>
Signed-off-by: Ammar Faizi <[email protected]>
[-- Attachment #3: Type: message/rfc822, Size: 680 bytes --]
From: [email protected]
Subject: confirm 5b14a6476a3068ff4580b8fedbbfe009eb5b1d9b
Date: Wed, 26 May 2021 07:48:14 +0000
Message-ID: <[email protected]>
If you reply to this message, keeping the Subject: header intact,
Mailman will discard the held message. Do this if the message is
spam. If you reply to this message and include an Approved: header
with the list password in it, the message will be approved for posting
to the list. The Approved: header can also appear in the first line
of the body of the reply.
^ permalink raw reply [flat|nested] 8+ messages in thread* GWML post from [email protected] requires approval
@ 2021-05-25 15:29 gwml-owner
0 siblings, 0 replies; 8+ messages in thread
From: gwml-owner @ 2021-05-25 15:29 UTC (permalink / raw)
To: gwml-owner
[-- Attachment #1: Type: text/plain, Size: 373 bytes --]
As list administrator, your authorization is requested for the
following mailing list posting:
List: [email protected]
From: [email protected]
Subject: test gambar
Reason: Message body is too big: 92505 bytes with a limit of 40 KB
At your convenience, visit:
https://gwml.gnuweeb.org/admindb/gwml
to approve or deny the request.
[-- Attachment #2: Type: message/rfc822, Size: 94126 bytes --]
[-- Attachment #2.1.1: Type: text/html, Size: 360 bytes --]
[-- Attachment #2.1.2: photo_2021-05-25_22-27-29.jpg --]
[-- Type: image/jpeg, Size: 68129 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 680 bytes --]
From: [email protected]
Subject: confirm cd8fdc6b0d9873675d4582d20e607ee1353a82e5
Date: Tue, 25 May 2021 15:29:08 +0000
Message-ID: <[email protected]>
If you reply to this message, keeping the Subject: header intact,
Mailman will discard the held message. Do this if the message is
spam. If you reply to this message and include an Approved: header
with the list password in it, the message will be approved for posting
to the list. The Approved: header can also appear in the first line
of the body of the reply.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-01-07 11:02 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-05-26 9:00 GWML post from [email protected] requires approval gwml-owner
-- strict thread matches above, loose matches on Subject: below --
2022-01-07 11:02 gwml-owner
2022-01-07 0:00 gwml-owner
2022-01-07 0:00 gwml-owner
2022-01-07 0:00 gwml-owner
2022-01-07 0:00 gwml-owner
2021-05-26 7:48 gwml-owner
2021-05-25 15:29 gwml-owner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox