This adds sending credit update message when SO_RCVLOWAT is updated and
it is bigger than number of bytes in rx queue. It is needed, because
'poll()' will wait until number of bytes in rx queue will be not smaller
than SO_RCVLOWAT, so kick sender to send more data. Otherwise mutual
hungup for tx/rx
This adds test which checks, that updating SO_RCVLOWAT value also sends
credit update message. Otherwise mutual hungup may happen when receiver
didn't send credit update and then calls 'poll()' with non default
SO_RCVLOWAT value (e.g. waiting enough bytes to read), while sender
waits for free space
Hello,
DESCRIPTION
This patchset fixes old problem with hungup of both rx/tx sides and adds
test for it. This happens due to non-default SO_RCVLOWAT value and
deferred credit update in virtio/vsock. Link to previous old patchset:
https://lore.kernel.org/netdev/39b2e
On Wed, Nov 8, 2023 at 2:39 PM Cindy Lu wrote:
>
> On Wed, Nov 8, 2023 at 11:03 AM Jason Wang wrote:
> >
> > On Tue, Nov 7, 2023 at 2:57 PM Cindy Lu wrote:
> > >
> > > On Mon, Nov 6, 2023 at 3:30 PM Jason Wang wrote:
> > > >
> > > > On Sat, Nov 4, 2023 at 1:17 AM Cindy Lu wrote:
> > > > >
> >
On Wed, Nov 8, 2023 at 11:04 AM Jason Wang wrote:
>
> On Tue, Nov 7, 2023 at 2:10 PM Cindy Lu wrote:
> >
> > On Mon, Nov 6, 2023 at 3:26 PM Jason Wang wrote:
> > >
> > > On Sat, Nov 4, 2023 at 1:18 AM Cindy Lu wrote:
> > > >
> > > > Expose the function iommu_device_use_default_domain() and
> >
On Wed, Nov 8, 2023 at 11:03 AM Jason Wang wrote:
>
> On Tue, Nov 7, 2023 at 2:57 PM Cindy Lu wrote:
> >
> > On Mon, Nov 6, 2023 at 3:30 PM Jason Wang wrote:
> > >
> > > On Sat, Nov 4, 2023 at 1:17 AM Cindy Lu wrote:
> > > >
> > > > VHOST_VDPA_SET_IOMMU_FD: bind the device to iommufd device
> >
Steven Rostedt writes:
> On Tue, 7 Nov 2023 13:56:53 -0800
> Ankur Arora wrote:
>
>> This reverts commit e3ff7c609f39671d1aaff4fb4a8594e14f3e03f8.
>>
>> Note that removing this commit reintroduces "live patches failing to
>> complete within a reasonable amount of time due to CPU-bound kthread
Sparse static analysis tools generate a warning with this message
"Using plain integer as NULL pointer". In this case this warning is
being shown because we are trying to initialize pointer to NULL using
integer value 0.
Signed-off-by: Abhinav Singh
---
fs/dax.c | 2 +-
fs/direct-io.c | 2
On Wed, 8 Nov 2023 09:22:48 +0800
"wuqiang.matt" wrote:
> Kernel test robot reported build warnings that structures g_ot_sync_ops,
> g_ot_async_ops and g_testcases should be static. These definitions are
> only used in test_objpool.c, so make them static
>
> Reported-by: kernel test robot
> Cl
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski :
On Sun, 5 Nov 2023 00:05:31 +0900 you wrote:
> KMSAN reported the following uninit-value access issue:
>
> =
> BUG: KMSAN: uninit-value in virtio_transport_recv_pkt+0x1
On Tue, Nov 7, 2023 at 2:10 PM Cindy Lu wrote:
>
> On Mon, Nov 6, 2023 at 3:26 PM Jason Wang wrote:
> >
> > On Sat, Nov 4, 2023 at 1:18 AM Cindy Lu wrote:
> > >
> > > Expose the function iommu_device_use_default_domain() and
> > > iommu_device_unuse_default_domain()，
> > > While vdpa bind the io
On Tue, Nov 7, 2023 at 2:57 PM Cindy Lu wrote:
>
> On Mon, Nov 6, 2023 at 3:30 PM Jason Wang wrote:
> >
> > On Sat, Nov 4, 2023 at 1:17 AM Cindy Lu wrote:
> > >
> > > VHOST_VDPA_SET_IOMMU_FD: bind the device to iommufd device
> > >
> > > VDPA_DEVICE_ATTACH_IOMMUFD_AS: Attach a vdpa device to an
On Oct 20, 2023 "Michael S. Tsirkin" wrote:
>
> This patch introduces LSM hooks for devices creation,
> destruction and opening operations, checking the
> application is allowed to perform these operations for
> the Virtio device type.
>
> Signed-off-by: Maxime Coquelin
> ---
> drivers/vdpa/vd
Currently, we don't support MODVERSIONS for Rust symbols. For users that
want to use Rust in the kernel but for whom MODVERSIONS is required,
this allows the use of built-in Rust code even with MODVERSIONS enabled.
It may additionally allow code-size reduction by avoiding exporting
symbols that won
Kernel test robot reported build warnings that structures g_ot_sync_ops,
g_ot_async_ops and g_testcases should be static. These definitions are
only used in test_objpool.c, so make them static
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202311071229.wgrwujm1-...@
The pull request you sent on Mon, 6 Nov 2023 19:38:20 -0800:
> https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git
> tags/rproc-v6.7
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b8dd631fcabe2656c8d3751ad4836131d51fb63b
Thank you!
--
Deet-doot-do
The pull request you sent on Mon, 6 Nov 2023 19:11:09 -0800:
> https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git
> tags/rpmsg-v6.7
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c87271ee86e836d3beae7b8b0222e81e225fa6c5
Thank you!
--
Deet-doot-do
On Sat, 4 Nov 2023 17:16:15 +0800
"wuqiang.matt" wrote:
> For architectures that support native cmpxchg, we'd like to
> implement arch_cmpxchg[64]_local with the native variants of
> supported data size. If not, the generci_cmpxchg[64]_local
> will be used.
>
> Reported-by: kernel test robot
>
On Sat, 4 Nov 2023 17:16:14 +0800
"wuqiang.matt" wrote:
> For architectures that support native cmpxchg, we'd like to
> implement arch_cmpxchg[64]_local with the native variants of
> supported data size. If not, the generci_cmpxchg[64]_local
> will be used.
Looks good to me.
Reviewed-by: Masa
On Sat, 4 Nov 2023 17:16:13 +0800
"wuqiang.matt" wrote:
> For architectures that support native cmpxchg, we'd like to
> implement arch_cmpxchg[64]_local with the native variants of
> supported data size. If not, the generci_cmpxchg[64]_local
> will be used.
>
Looks good to me.
Reviewed-by: Ma
On Sat, 4 Nov 2023 17:16:12 +0800
"wuqiang.matt" wrote:
> Macro __cmpxchg() renamed to __cmpxchg_32() to emphasize it's explicit
> support of 32bit data size, BUILD_BUG_ON() added to avoid any possible
> misuses with unsupported data types.
>
> In case CONFIG_ARC_HAS_LLSC is undefined, arch_cmp
On Mon, 06 Nov 2023 09:48:36 -0600, Haitao Huang
wrote:
On Sun, 05 Nov 2023 21:26:44 -0600, Jarkko Sakkinen
wrote:
On Mon, 2023-10-30 at 11:20 -0700, Haitao Huang wrote:
SGX Enclave Page Cache (EPC) memory allocations are separate from
normal RAM allocations, and
are managed solely by
On Tue, 7 Nov 2023 13:56:53 -0800
Ankur Arora wrote:
> This reverts commit e3ff7c609f39671d1aaff4fb4a8594e14f3e03f8.
>
> Note that removing this commit reintroduces "live patches failing to
> complete within a reasonable amount of time due to CPU-bound kthreads."
>
> Unfortunately this fix dep
Hello:
This series was applied to netdev/net.git (main)
by David S. Miller :
On Fri, 3 Nov 2023 18:55:47 +0100 you wrote:
> From: Filippo Storniolo
>
> This patch series introduce fix and tests for the following vsock bug:
> If the same remote peer, using the same port, tries to connect
> to a
On Sun, Oct 29, 2023 at 03:03:19AM +0200, Dimitri John Ledkov wrote:
Switch to using OBJ_obj2txt() to calculate and print the pkcs7
signature hash name. This eliminates the need to duplicate libcrypto
NID to name mapping, detect SM3 openssl compile-time support, and
enables using any hashes that
> I should have sticked to the orignial comment added in code. Actually
> __sgx_alloc_epc_page() can fail if system runs out of EPC. That's the really
> reason
> for global reclaim. The free count enforcement is near the end of this method
> after should_reclaim() check.
Hi Haitao,
Sorry I have
On Tue, 7 Nov 2023 08:48:44 -0500
Steven Rostedt wrote:
> On Tue, 7 Nov 2023 14:43:28 +0900
> Masami Hiramatsu (Google) wrote:
>
> > >
> > > It's only needed if an architecture supports direct trampolines.
> >
> > I see, and x86_64 needs it.
> > OK, maybe better to keep it clear on x86-64
On Tue, 7 Nov 2023 14:43:28 +0900
Masami Hiramatsu (Google) wrote:
> >
> > It's only needed if an architecture supports direct trampolines.
>
> I see, and x86_64 needs it.
> OK, maybe better to keep it clear on x86-64 even on the
> return handler.
As it is arch specific, I'm not sure it matt
On Mon, Oct 30, 2023 at 09:00:53AM +0200, Mike Rapoport wrote:
> On Thu, Oct 26, 2023 at 11:24:39AM +0100, Will Deacon wrote:
> > On Thu, Oct 26, 2023 at 11:58:00AM +0300, Mike Rapoport wrote:
> > > On Mon, Oct 23, 2023 at 06:14:20PM +0100, Will Deacon wrote:
> > > > On Mon, Sep 18, 2023 at 10:29:4
29 matches
Mail list logo
