Sometime, it would be useful to disable the configure change
notification from the driver. So this patch allows this by introducing
a variable config_change_driver_disabled and only allow the configure
change notification callback to be triggered when it is allowed by
both the virtio core and the
y force the stack to create many small skbs hurting
> performance in many ways.
>
> [...]
Applied, thanks!
[3/4] io_uring/notif: simplify io_notif_flush()
commit: 5a569469b973cb7a6c58192a37dfb8418686e518
[4/4] io_uring/notif: implement notif
io_uring-next/net-next,v2,4/4] io_uring/notif: implement notification
stacking
(no matching commit)
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
many ways.
The patchset implements notification, i.e. an io_uring's ubuf_info
extension, stacking. It attempts to link ubuf_info's into a list,
allowing to have multiple of them per skb.
liburing/examples/send-zerocopy shows up 6 times performance improvement
for TCP with 4KB bytes per s
herwise it would spam the stack with lots of skbs
carrying just a little data each.
To help with that implement linking notification (i.e. an io_uring wrapper
around ubuf_info) into a list. Each is refcounted by skbs and the stack
as usual. additionally all non head entries keep a reference t
The patchset implements notification, i.e. an io_uring's ubuf_info
extension, stacking. It attempts to link ubuf_info's into a list,
allowing to have multiple of them per skb.
liburing/examples/send-zerocopy shows up 6 times performance improvement
for TCP with 4KB bytes per send, and
e impression that this is an authenticated event. The
function 'wg_socket_set_peer_endpoint' where I hook in the notification
is called from:
- set_peer (changes from netlink, authenticated)
- wg_packet_consume_data_done (which should be authenticated?)
- wg_socket_set_peer_endpoint_
qeth_tx_complete_pending_bufs() is called during teardown to drain
the parked TX buffers, we no longer raise a notification for af_iucv.
Instead of updating the checked state, just move this code into
qeth_tx_complete_pending_bufs() itself. This also gets rid of the
special-case in the common TX
Hey Linus,
Thanks for the patch and sorry for the delay in reviewing it. Seeing
the basic scaffolding for getting netlink notifiers working with
WireGuard is enlightening; it looks surprisingly straightforward.
There are three classes of things that are interesting to receive
notifications for:
n hardware.
Introduce a sysctl that controls this behavior.
Keep the default value at 0 (i.e., do not emit notifications) for several
reasons:
- Multiple RTM_NEWROUTE notification per-route might confuse existing
routing daemons.
- Convergence reasons in routing daemons.
- The extra notifications will
n hardware.
Introduce a sysctl that controls this behavior.
Keep the default value at 0 (i.e., do not emit notifications) for several
reasons:
- Multiple RTM_NEWROUTE notification per-route might confuse existing
routing daemons.
- Convergence reasons in routing daemons.
- The extra notifications will
to provide an indication to user-space
> >> (e.g., routing daemons) about the state of the route in hardware.
> >
> > What does the daemon in the user space do with it?
>
> You don't want FRR for example to advertise a route to a peer until it
> is really pro
d ask for a dump of all the
existing routes (usually only host routes). With this patchset, user
space will receive a notification that these routes are now in hardware.
# ip monitor route
broadcast 127.255.255.255 dev lo table local proto kernel scope link src
127.0.0.1
local 127.0.0.1 dev lo tab
ovide an indication to user-space
> >> (e.g., routing daemons) about the state of the route in hardware.
> >
> > What does the daemon in the user space do with it?
>
> You don't want FRR for example to advertise a route to a peer until it
> is really pro
state of the route in hardware.
>
> What does the daemon in the user space do with it?
You don't want FRR for example to advertise a route to a peer until it
is really programmed in h/w. This notification gives routing daemons
that information.
>
> The notification will only b
On 1/28/21 5:49 AM, Petr Machata wrote:
> From: Ido Schimmel
>
> Currently there are only two types of in-kernel nexthop notification.
> The two are distinguished by the 'is_grp' boolean field in 'struct
> nh_notifier_info'.
>
> As more notification typ
the user space do with it?
The notification will only be generated for the _first_ ASIC which
offloaded the object. Which may be fine for you today but as an uAPI
it feels slightly lacking.
If the user space just wants to make sure the devices are synced to
notifications from certain stage, would
From: Ido Schimmel
Currently there are only two types of in-kernel nexthop notification.
The two are distinguished by the 'is_grp' boolean field in 'struct
nh_notifier_info'.
As more notification types are introduced for more next-hop group types, a
boolean is not an easily
Whoever called iucv_sk(sk)->sk_txnotify() must already know that they're
dealing with an af_iucv socket.
Signed-off-by: Julian Wiedmann
---
net/iucv/af_iucv.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/net/iucv/af_iucv.c b/net/iucv/af_iucv.c
index 427a1a
gs
> are changed. The aim is to provide an indication to user-space
> (e.g., routing daemons) about the state of the route in hardware.
>
> Introduce a sysctl that controls this behavior.
>
> Keep the default value at 0 (i.e., do not emit notifications) for several
> reasons:
&
gs
> are changed. The aim is to provide an indication to user-space
> (e.g., routing daemons) about the state of the route in hardware.
>
> Introduce a sysctl that controls this behavior.
>
> Keep the default value at 0 (i.e., do not emit notifications) for several
> reasons:
&
ubject: Re: [PATCH net-next 05/10] net: ipv4: Emit notification when fib
>hardware flags are changed
>
>On 1/26/21 6:23 AM, Ido Schimmel wrote:
>> From: Amit Cohen
>>
>> After installing a route to the kernel, user space receives an
>> acknowledgment, which means t
gs
> are changed. The aim is to provide an indication to user-space
> (e.g., routing daemons) about the state of the route in hardware.
>
> Introduce a sysctl that controls this behavior.
>
> Keep the default value at 0 (i.e., do not emit notifications) for several
> reasons:
&
gs
> are changed. The aim is to provide an indication to user-space
> (e.g., routing daemons) about the state of the route in hardware.
>
> Introduce a sysctl that controls this behavior.
>
> Keep the default value at 0 (i.e., do not emit notifications) for several
> reasons:
&
Hi Jason,
have you had a chance to look at it yet?
Cheers
Linus
Am 16.01.21 um 00:40 schrieb Jason A. Donenfeld:
> Hey Linus,
>
> My email server has been firewalled from vger.kernel.org until today,
> so I didn't see the original until this v2 was sent today. My
> apologies. I'll review this fi
n hardware.
Introduce a sysctl that controls this behavior.
Keep the default value at 0 (i.e., do not emit notifications) for several
reasons:
- Multiple RTM_NEWROUTE notification per-route might confuse existing
routing daemons.
- Convergence reasons in routing daemons.
- The extra notifications will
n hardware.
Introduce a sysctl that controls this behavior.
Keep the default value at 0 (i.e., do not emit notifications) for several
reasons:
- Multiple RTM_NEWROUTE notification per-route might confuse existing
routing daemons.
- Convergence reasons in routing daemons.
- The extra notifications will
Hi Jason,
No worries, thanks!
Linus
> Hey Linus,
>
> My email server has been firewalled from vger.kernel.org until today,
> so I didn't see the original until this v2 was sent today. My
> apologies. I'll review this first thing on Monday.
>
> Jason
>
Hey Linus,
My email server has been firewalled from vger.kernel.org until today,
so I didn't see the original until this v2 was sent today. My
apologies. I'll review this first thing on Monday.
Jason
This commit adds a new multicast group to the netlink api for wireguard.
The purpose of this multicast group is to notify userspace when the
peers of an interface change. Right now this is only done when the
endpoint is changed by whatever means.
An example for an consumer of this API would be a s
e' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Linus-Lotz/wireguard-netlink-add-multicast-notification-for-peer-changes/20210110-051531
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds
This commit adds a new multicast group to the netlink api for wireguard.
The purpose of this multicast group is to notify userspace when the
peers of an interface change. Right now this is only done when the
endpoint is changed by whatever means.
An example for an consumer of this API would be a s
From: Johannes Berg
[ Upstream commit efc0ec5afb6e1488b3bdc4bbf85533d79d7e5f9f ]
The MPDU contained in a notification shouldn't be larger than the
notification size itself is, validate this.
Reported-by: Haggai Abramovsky
Signed-off-by: Johannes Berg
Signed-off-by: Luca Coelho
Link:
The two expected notification sequences are
1. TX_NOTIFY_PENDING with a subsequent TX_NOTIFY_DELAYED_*, when
our TX completion code first observed the pending TX and the QAOB
then completes at a later time; or
2. TX_NOTIFY_OK, when qeth_qdio_handle_aob() picked up the QAOB
completion
vers/s390/net/qeth_core_main.c
@@ -33,6 +33,7 @@
#include
#include
+#include
#include
#include
@@ -1405,7 +1406,7 @@ static void qeth_notify_skbs(struct qeth_qdio_out_q *q,
skb_queue_walk(&buf->skb_list, skb) {
QETH_CARD_TEXT_(q->card, 5,
On Wed, 4 Nov 2020 15:30:25 +0200 Ido Schimmel wrote:
> + if (info->is_grp)
> + return nh_notifier_grp_info_init(info, nh);
> + else
> + return nh_notifier_single_info_init(info, nh);
nit: please try to avoid unnecessary else branches, it obviously
doesn't mat
From: Ido Schimmel
When a single nexthop is replaced, the configuration of all the groups
using the nexthop is effectively modified. In this case, emit a
notification in the nexthop notification chain for each modified group
so that listeners would not need to keep track of which nexthops are
From: Ido Schimmel
Convert the sole listener of the nexthop notification chain (the VXLAN
driver) to the new notification info.
Signed-off-by: Ido Schimmel
---
drivers/net/vxlan.c | 9 +++--
net/ipv4/nexthop.c | 2 +-
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers
From: Ido Schimmel
Emit a notification in the nexthop notification chain when a new nexthop
is added (not replaced). The nexthop can either be a new group or a
single nexthop.
The notification is sent after the nexthop is inserted into the
red-black tree, as listeners might need to callback
From: Ido Schimmel
When a single nexthop is deleted, the configuration of all the groups
using the nexthop is effectively modified. In this case, emit a
notification in the nexthop notification chain for each modified group
so that listeners would not need to keep track of which nexthops are
From: Ido Schimmel
The notification is emitted after all the validation checks were
performed, but before the new configuration (i.e., 'struct nh_info') is
pointed at by the old shell (i.e., 'struct nexthop'). This prevents the
need to perform rollback in case the notifica
From: Ido Schimmel
Emit a notification in the nexthop notification chain when an existing
nexthop group is replaced.
The notification is emitted after all the validation checks were
performed, but before the new configuration (i.e., 'struct nh_grp') is
pointed at by the old shell (i.e
From: Ido Schimmel
Prepare the new notification information so that it could be passed to
listeners in the new patch.
Changes since RFC:
* Add a blank line in __nh_notifier_single_info_init()
Signed-off-by: Ido Schimmel
Reviewed-by: David Ahern
---
net/ipv4/nexthop.c | 109
From: Ido Schimmel
Add data structures that will be used for nexthop replace and delete
notifications in the previously introduced nexthop notification chain.
New data structures are added instead of passing the existing nexthop
code structures directly for several reasons.
First, the existing
From: Ido Schimmel
Currently, the in-kernel delete notification is emitted from the error
path of nexthop_add() and replace_nexthop(), which can be confusing to
in-kernel listeners as they are not familiar with the nexthop.
Instead, only emit the notification when the nexthop is actually
From: Ido Schimmel
Currently, the only listener of the nexthop notification chain is the
VXLAN driver. Subsequent patches will add more listeners (e.g., device
drivers such as netdevsim) that need to be able to block when processing
notifications.
Therefore, convert the notification chain to a
On Tue, Sep 08, 2020 at 08:43:10AM -0600, David Ahern wrote:
> On 9/8/20 3:10 AM, Ido Schimmel wrote:
> > From: Ido Schimmel
> >
> > Add data structures that will be used for nexthop replace and delete
> > notifications in the previously introduced nexthop notificati
On Tue, Sep 08, 2020 at 08:55:06AM -0600, David Ahern wrote:
> On 9/8/20 3:10 AM, Ido Schimmel wrote:
> > From: Ido Schimmel
> >
> > Prepare the new notification information so that it could be passed to
> > listeners in the new patch.
> >
> > Signed-off-
On Tue, Sep 08, 2020 at 08:58:07AM -0600, David Ahern wrote:
> On 9/8/20 3:10 AM, Ido Schimmel wrote:
> > From: Ido Schimmel
> >
> > Convert the sole listener of the nexthop notification chain (the VXLAN
> > driver) to the new notification info.
> >
On Tue, Sep 08, 2020 at 04:39:59PM +0200, Jiri Pirko wrote:
> Tue, Sep 08, 2020 at 11:10:18AM CEST, ido...@idosch.org wrote:
> >From: Ido Schimmel
> >
> >Currently, the delete notification is emitted from the error path of
> >nexthop_add() and replace_nexthop()
On Tue, Sep 08, 2020 at 09:33:42AM -0600, David Ahern wrote:
> On 9/8/20 3:10 AM, Ido Schimmel wrote:
> > From: Ido Schimmel
> >
> > When a single nexthop is deleted, the configuration of all the groups
> > using the nexthop is effectively modified. In this case, emi
On Tue, Sep 08, 2020 at 09:25:40AM -0600, David Ahern wrote:
> On 9/8/20 3:10 AM, Ido Schimmel wrote:
> > From: Ido Schimmel
> >
> > The notification is emitted after all the validation checks were
> > performed, but before the new configuration (i.e., 'struct nh
On Tue, Sep 08, 2020 at 09:21:08AM -0600, David Ahern wrote:
> On 9/8/20 3:10 AM, Ido Schimmel wrote:
> > From: Ido Schimmel
> >
> > Emit a notification in the nexthop notification chain when a new nexthop
> > is added (not replaced). The nexthop can either be a new gr
-notification will
report all current addresses.
In order to re-enable address-change-notification this patch defines
the functions qeth_l2_dev2br_an_set() and qeth_l2_dev2br_an_set_cb
to enable or disable dev-to-bridge-address-notification.
A following patch will use the learning_sync bridgeport flag
On 9/8/20 3:10 AM, Ido Schimmel wrote:
> From: Ido Schimmel
>
> Prepare the new notification information so that it could be passed to
> listeners in the new patch.
>
> Signed-off-by: Ido Schimmel
> ---
> net/ipv4/nexthop.c | 108 +++
On 9/8/20 3:10 AM, Ido Schimmel wrote:
> From: Ido Schimmel
>
> Currently, the delete notification is emitted from the error path of
> nexthop_add() and replace_nexthop(), which can be confusing to listeners
> as they are not familiar with the nexthop.
>
> Instead, only
On 9/8/20 3:10 AM, Ido Schimmel wrote:
> From: Ido Schimmel
>
> Emit a notification in the nexthop notification chain when a new nexthop
> is added (not replaced). The nexthop can either be a new group or a
> single nexthop.
Add a comment about why EVENT_REPLACE is generated on
On 9/8/20 3:10 AM, Ido Schimmel wrote:
> From: Ido Schimmel
>
> When a single nexthop is deleted, the configuration of all the groups
> using the nexthop is effectively modified. In this case, emit a
> notification in the nexthop notification chain for each modified group
>
On 9/8/20 3:10 AM, Ido Schimmel wrote:
> From: Ido Schimmel
>
> Emit a notification in the nexthop notification chain when an existing
> nexthop group is replaced.
>
> The notification is emitted after all the validation checks were
> performed, but before the new configu
On 9/8/20 3:10 AM, Ido Schimmel wrote:
> From: Ido Schimmel
>
> Convert the sole listener of the nexthop notification chain (the VXLAN
> driver) to the new notification info.
>
> Signed-off-by: Ido Schimmel
> ---
> drivers/net/vxlan.c | 9 +++--
> net/ipv4/n
On 9/8/20 3:10 AM, Ido Schimmel wrote:
> From: Ido Schimmel
>
> The notification is emitted after all the validation checks were
> performed, but before the new configuration (i.e., 'struct nh_info') is
> pointed at by the old shell (i.e., 'struct nexthop').
Tue, Sep 08, 2020 at 11:10:18AM CEST, ido...@idosch.org wrote:
>From: Ido Schimmel
>
>Currently, the delete notification is emitted from the error path of
>nexthop_add() and replace_nexthop(), which can be confusing to listeners
>as they are not familiar with the nexthop.
>
&
On 9/8/20 3:10 AM, Ido Schimmel wrote:
> From: Ido Schimmel
>
> Add data structures that will be used for nexthop replace and delete
> notifications in the previously introduced nexthop notification chain.
>
> New data structures are added instead of passing the exist
On 9/8/20 8:39 AM, Jiri Pirko wrote:
> Tue, Sep 08, 2020 at 11:10:18AM CEST, ido...@idosch.org wrote:
>> From: Ido Schimmel
>>
>> Currently, the delete notification is emitted from the error path of
>> nexthop_add() and replace_nexthop(), which can be confusing to l
On 9/8/20 3:10 AM, Ido Schimmel wrote:
> From: Ido Schimmel
>
> When a single nexthop is replaced, the configuration of all the groups
> using the nexthop is effectively modified. In this case, emit a
> notification in the nexthop notification chain for each modified group
>
On 9/8/20 3:10 AM, Ido Schimmel wrote:
> From: Ido Schimmel
>
> Currently, the only listener of the nexthop notification chain is the
> VXLAN driver. Subsequent patches will add more listeners (e.g., device
> drivers such as netdevsim) that need to be able to block
From: Ido Schimmel
Add data structures that will be used for nexthop replace and delete
notifications in the previously introduced nexthop notification chain.
New data structures are added instead of passing the existing nexthop
code structures directly for several reasons.
First, the existing
From: Ido Schimmel
Convert the sole listener of the nexthop notification chain (the VXLAN
driver) to the new notification info.
Signed-off-by: Ido Schimmel
---
drivers/net/vxlan.c | 9 +++--
net/ipv4/nexthop.c | 2 +-
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers
From: Ido Schimmel
Emit a notification in the nexthop notification chain when a new nexthop
is added (not replaced). The nexthop can either be a new group or a
single nexthop.
The notification is sent after the nexthop is inserted into the
red-black tree, as listeners might need to callback
From: Ido Schimmel
Emit a notification in the nexthop notification chain when an existing
nexthop group is replaced.
The notification is emitted after all the validation checks were
performed, but before the new configuration (i.e., 'struct nh_grp') is
pointed at by the old shell (i.e
From: Ido Schimmel
Prepare the new notification information so that it could be passed to
listeners in the new patch.
Signed-off-by: Ido Schimmel
---
net/ipv4/nexthop.c | 108 +
1 file changed, 108 insertions(+)
diff --git a/net/ipv4/nexthop.c b
From: Ido Schimmel
The notification is emitted after all the validation checks were
performed, but before the new configuration (i.e., 'struct nh_info') is
pointed at by the old shell (i.e., 'struct nexthop'). This prevents the
need to perform rollback in case the notifica
From: Ido Schimmel
When a single nexthop is deleted, the configuration of all the groups
using the nexthop is effectively modified. In this case, emit a
notification in the nexthop notification chain for each modified group
so that listeners would not need to keep track of which nexthops are
From: Ido Schimmel
When a single nexthop is replaced, the configuration of all the groups
using the nexthop is effectively modified. In this case, emit a
notification in the nexthop notification chain for each modified group
so that listeners would not need to keep track of which nexthops are
From: Ido Schimmel
Currently, the delete notification is emitted from the error path of
nexthop_add() and replace_nexthop(), which can be confusing to listeners
as they are not familiar with the nexthop.
Instead, only emit the notification when the nexthop is actually
deleted. The following sub
From: Ido Schimmel
Currently, the only listener of the nexthop notification chain is the
VXLAN driver. Subsequent patches will add more listeners (e.g., device
drivers such as netdevsim) that need to be able to block when processing
notifications.
Therefore, convert the notification chain to a
Le 27/08/2020 à 18:44, David Miller a écrit :
> Was build testing, it's pushed out now.
>
Thanks David!
From: Nicolas Dichtel
Date: Thu, 27 Aug 2020 18:37:32 +0200
> Le 27/08/2020 à 17:05, David Miller a écrit :
>> From: Nicolas Dichtel
>> Date: Thu, 27 Aug 2020 14:19:23 +0200
>>
>>> Like all other network functions, let's notify gtp context on creation and
>>> deletion.
>>>
>>> Signed-off-by: Ni
Le 27/08/2020 à 17:05, David Miller a écrit :
> From: Nicolas Dichtel
> Date: Thu, 27 Aug 2020 14:19:23 +0200
>
>> Like all other network functions, let's notify gtp context on creation and
>> deletion.
>>
>> Signed-off-by: Nicolas Dichtel
>> Tested-by: Gabriel Ganne
>> Acked-by: Harald Welte
From: Nicolas Dichtel
Date: Thu, 27 Aug 2020 14:19:23 +0200
> Like all other network functions, let's notify gtp context on creation and
> deletion.
>
> Signed-off-by: Nicolas Dichtel
> Tested-by: Gabriel Ganne
> Acked-by: Harald Welte
Applied, thanks.
Like all other network functions, let's notify gtp context on creation and
deletion.
Signed-off-by: Nicolas Dichtel
Tested-by: Gabriel Ganne
Acked-by: Harald Welte
---
v2 -> v3:
- add ack from Harald
- rebase on HEAD of net-next
v1 -> v2:
- fix typo in the commit title
- fix indentation o
Hi Harald,
Le 27/08/2020 à 11:00, Harald Welte a écrit :
> Hi Nicolas,
>
> On Thu, Aug 27, 2020 at 12:36:24AM +0200, Nicolas Dichtel wrote:
>> Le 26/08/2020 à 20:52, Harald Welte a écrit :
>
>>> Wouldn't it make sense to only allocate + fill those messages if we
>>> actually knew a subscriber ex
Hi Nicolas,
On Thu, Aug 27, 2020 at 12:36:24AM +0200, Nicolas Dichtel wrote:
> Le 26/08/2020 à 20:52, Harald Welte a écrit :
> > Wouldn't it make sense to only allocate + fill those messages if we
> > actually knew a subscriber existed?
>
> In fact, this is actually how the netlink framework work
Le 26/08/2020 à 20:52, Harald Welte a écrit :
> Hi Nicolas,
>
> On Wed, Aug 26, 2020 at 09:47:54AM +0200, Nicolas Dichtel wrote:
>>> Sending (unsolicited) notifications about all of those seems quite
>>> heavyweight to me.
>>
>> There is no 'unsolicited' notifications with this patch. Notificatio
Hi Nicolas,
On Wed, Aug 26, 2020 at 09:47:54AM +0200, Nicolas Dichtel wrote:
> > Sending (unsolicited) notifications about all of those seems quite
> > heavyweight to me.
>
> There is no 'unsolicited' notifications with this patch. Notifications are
> sent
> only if a userspace application has s
Le 25/08/2020 à 19:01, Harald Welte a écrit :
> Hi Nicolas,
>
> thanks a lot for your patch.
>
> On Tue, Aug 25, 2020 at 05:57:15PM +0200, Nicolas Dichtel wrote:
>> Like all other network functions, let's notify gtp context on creation and
>> deletion.
>
> While this may be in-line with typical
Hi Nicolas,
thanks a lot for your patch.
On Tue, Aug 25, 2020 at 05:57:15PM +0200, Nicolas Dichtel wrote:
> Like all other network functions, let's notify gtp context on creation and
> deletion.
While this may be in-line with typical kernel tunnel device practises, I am not
convinced it is the r
Like all other network functions, let's notify gtp context on creation and
deletion.
Signed-off-by: Nicolas Dichtel
Tested-by: Gabriel Ganne
---
v1 -> v2:
- fix typo in the commit title
- fix indentation of GTP_GENL_MCGRP
drivers/net/gtp.c| 58 +--
Like all other network functions, let's notify gtp context on creation and
deletion.
Signed-off-by: Nicolas Dichtel
Tested-by: Gabriel Ganne
---
drivers/net/gtp.c| 58 +---
include/uapi/linux/gtp.h | 2 ++
2 files changed, 51 insertions(+), 9 deletio
From: Alex Elder
Date: Fri, 24 Jul 2020 13:11:41 -0500
> Use the new SSR notifier infrastructure to request notifications of
> modem events, rather than the remoteproc IPA notification system.
> The latter was put in place temporarily with the knowledge that the
> new mechanism
On Fri 24 Jul 11:11 PDT 2020, Alex Elder wrote:
> Use the new SSR notifier infrastructure to request notifications of
> modem events, rather than the remoteproc IPA notification system.
> The latter was put in place temporarily with the knowledge that the
> new mechanism would beco
Use the new SSR notifier infrastructure to request notifications of
modem events, rather than the remoteproc IPA notification system.
The latter was put in place temporarily with the knowledge that the
new mechanism would become available.
Signed-off-by: Alex Elder
---
David: If you approve
Add support to send address service notification message to the backend
rpmsg device. This informs the backend rpmsg device about the address
allocated to the channel that is created in response to the name service
announce message from backend rpmsg device. This is in preparation to
add backend
return;
> > + goto notify;
>
> These two functions have some early returns that skip the
> notification, but now the notification will be sent in all cases:
Right, I will rework this series.
Thanks for pointing this out.
t; - return;
> + goto notify;
> case XFRM_REPLAY_MODE_ESN:
> xfrm_replay_notify_esn(x, event);
> - return;
> + goto notify;
These two functions have some early returns that skip the
notification, but now the notification will be sent in
After previous patch, we can consolidate some code:
xfrm_replay_notify, xfrm_replay_notify_bmp and _esn all contain the
same code at the end.
Remove it from xfrm_replay_notify_bmp/esn and reuse the one
in xfrm_replay_notify.
Signed-off-by: Florian Westphal
---
net/xfrm/xfrm_replay.c | 22 -
After previous patch, we can consolidate some code:
xfrm_replay_notify, xfrm_replay_notify_bmp and _esn all contain the
same code at the end.
Remove it from xfrm_replay_notify_bmp/esn and reuse the one
in xfrm_replay_notify.
Signed-off-by: Florian Westphal
---
net/xfrm/xfrm_replay.c | 22 -
of
> marking them completed now invokes the call's notification function - which
> causes a problem because that function might assume that the previously
> freed pieces of memory are still there.
>
> Fix this by setting a dummy notification function on the socket after
>
When preallocated service calls are being discarded, they're passed to
->discard_new_call() to have the caller clean up any attached higher-layer
preallocated pieces before being marked completed. However, the act of
marking them completed now invokes the call's notification fun
From: David Howells
Date: Mon, 08 Jun 2020 19:49:47 +0100
> Here's a fix for AF_RXRPC. Occasionally calls hang because there are
> circumstances in which rxrpc generate a notification when a call is
> completed - primarily because initial packet transmission failed and the
> ca
1 - 100 of 597 matches
Mail list logo
