spin_unlock(&memcg_oom_lock);
> return 0;
> @@ -4499,7 +4499,7 @@ static int mem_cgroup_oom_register_event(struct
> mem_cgroup *memcg,
>
> /* already in OOM ? */
> if (memcg->under_oom)
> - eventfd_signal(eventfd, 1);
> + eventfd_signal(eventfd);
> spin_unlock(&memcg_oom_lock);
>
> return 0;
> @@ -4791,7 +4791,7 @@ static void memcg_event_remove(struct work_struct *work)
> event->unregister_event(memcg, event->eventfd);
>
> /* Notify userspace the event is going away. */
> - eventfd_signal(event->eventfd, 1);
> + eventfd_signal(event->eventfd);
>
> eventfd_ctx_put(event->eventfd);
> kfree(event);
> diff --git a/mm/vmpressure.c b/mm/vmpressure.c
> index b52644771cc4..ba4cdef37e42 100644
> --- a/mm/vmpressure.c
> +++ b/mm/vmpressure.c
> @@ -169,7 +169,7 @@ static bool vmpressure_event(struct vmpressure *vmpr,
> continue;
> if (level < ev->level)
> continue;
> - eventfd_signal(ev->efd, 1);
> + eventfd_signal(ev->efd);
> ret = true;
> }
> mutex_unlock(&vmpr->events_lock);
> diff --git a/samples/vfio-mdev/mtty.c b/samples/vfio-mdev/mtty.c
> index a60801fb8660..5edcf8d738de 100644
> --- a/samples/vfio-mdev/mtty.c
> +++ b/samples/vfio-mdev/mtty.c
> @@ -1028,9 +1028,9 @@ static int mtty_trigger_interrupt(struct mdev_state
> *mdev_state)
> }
>
> if (mdev_state->irq_index == VFIO_PCI_MSI_IRQ_INDEX)
> - ret = eventfd_signal(mdev_state->msi_evtfd, 1);
> + ret = eventfd_signal(mdev_state->msi_evtfd);
> else
> - ret = eventfd_signal(mdev_state->intx_evtfd, 1);
> + ret = eventfd_signal(mdev_state->intx_evtfd);
>
> #if defined(DEBUG_INTR)
> pr_info("Intx triggered\n");
> diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
> index 89912a17f5d5..c0e230f4c3e9 100644
> --- a/virt/kvm/eventfd.c
> +++ b/virt/kvm/eventfd.c
> @@ -61,7 +61,7 @@ static void irqfd_resampler_notify(struct
> kvm_kernel_irqfd_resampler *resampler)
>
> list_for_each_entry_srcu(irqfd, &resampler->list, resampler_link,
>
> srcu_read_lock_held(&resampler->kvm->irq_srcu))
> - eventfd_signal(irqfd->resamplefd, 1);
> + eventfd_signal(irqfd->resamplefd);
> }
>
> /*
> @@ -786,7 +786,7 @@ ioeventfd_write(struct kvm_vcpu *vcpu, struct
> kvm_io_device *this, gpa_t addr,
> if (!ioeventfd_in_range(p, addr, len, val))
> return -EOPNOTSUPP;
>
> - eventfd_signal(p->eventfd, 1);
> + eventfd_signal(p->eventfd);
> return 0;
> }
>
>
> --
> 2.34.1
>
For habanalabs (device.c):
Reviewed-by: Oded Gabbay
On Fri, Feb 17, 2023 at 10:51 PM Daniel Vetter wrote:
>
> Hi all,
>
> [I thought I've sent this out earlier this week, but alas got stuck, kinda
> bad timing now since I'm out next week but oh well]
>
> So xe is a quite substantial thing, and I think we need a clear plan how to
> land
> this or i
On Thu, Feb 23, 2023 at 8:50 PM Alex Deucher wrote:
>
> On Thu, Feb 23, 2023 at 10:03 AM Thomas Hellström
> wrote:
> >
> > Hi, Daniel,
> >
> > On 2/16/23 21:18, Daniel Vetter wrote:
> > > On Thu, Feb 16, 2023 at 05:27:28PM +0100, Thomas Hellström wrote:
> > >> A slightly unusual cover letter for
On Fri, Jan 20, 2023 at 2:32 AM Stephen Rothwell wrote:
>
> Hi all,
>
> Today's linux-next merge of the accel tree got conflicts in:
>
> drivers/Makefile
> drivers/accel/Kconfig
> drivers/accel/Makefile
>
> between commit:
>
> 35b137630f08 ("accel/ivpu: Introduce a new DRM driver for Intel
On Mon, Nov 7, 2022 at 6:20 PM Matthew Wilcox wrote:
>
> On Sun, Nov 06, 2022 at 04:51:39PM +0200, Oded Gabbay wrote:
> > I tried executing the following code in a dummy driver I wrote:
>
> You don't need to write a dummy driver; you can write test-cases
> entirely in us
On Wed, Nov 2, 2022 at 4:23 PM Oded Gabbay wrote:
>
> On Mon, Sep 12, 2022 at 12:17 AM Michał Winiarski
> wrote:
> >
> > IDR is deprecated, and since XArray manages its own state with internal
> > locking, it simplifies the locking on DRM side.
> > Additionall
On Mon, Sep 12, 2022 at 12:17 AM Michał Winiarski
wrote:
>
> IDR is deprecated, and since XArray manages its own state with internal
> locking, it simplifies the locking on DRM side.
> Additionally, don't use the IRQ-safe variant, since operating on drm
> minor is not done in IRQ context.
>
> Sign
On Wed, May 20, 2020 at 9:05 PM Daniel Vetter wrote:
>
> On Thu, May 14, 2020 at 02:38:38PM +0300, Oded Gabbay wrote:
> > On Tue, May 12, 2020 at 9:12 AM Daniel Vetter
> > wrote:
> > >
> > > On Tue, May 12, 2020 at 4:14 AM Dave Airlie wrote:
> > >
On Tue, May 12, 2020 at 9:12 AM Daniel Vetter wrote:
>
> On Tue, May 12, 2020 at 4:14 AM Dave Airlie wrote:
> >
> > On Mon, 11 May 2020 at 19:37, Oded Gabbay wrote:
> > >
> > > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter
> > > wrote:
>
anks,
Oded
On Mon, May 11, 2020 at 12:36 PM Oded Gabbay wrote:
>
> On Mon, May 11, 2020 at 12:11 PM Daniel Vetter wrote:
> >
> > It's the default.
> Thanks for catching that.
>
> >
> > Also so much for "we're not going to tell the graphics peo
argument, if this is indeed what you meant.
Oded
>
> Signed-off-by: Daniel Vetter
> Cc: Greg Kroah-Hartman
> Cc: Olof Johansson
> Cc: Oded Gabbay
> Cc: Sumit Semwal
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> ---
> drivers/misc/haban
On Wed, Aug 22, 2018 at 10:58 PM Linus Torvalds
wrote:
>
> On Wed, Aug 22, 2018 at 12:37 PM Oded Gabbay wrote:
> >
> > Having said that, I think we *are* protected by the mmu_notifier
> > release because if the process suddenly dies, we will gracefully clean
> > th
On Wed, Aug 22, 2018 at 7:44 PM Linus Torvalds
wrote:
> One of the complex ones is the amdgpu driver. It does a
> "use_mm(mmptr)" deep deep in the guts of a macro that ends up being
> used in fa few places, and it's very hard to tell if it's right.
>
> It looks almost certainly buggy (there is no
Hi,
There is a missing #include at amdgpu_amdkfd.h
I'll send a patch to Dave to apply to his drm-next tree to fix this.
Thanks for catching this,
Oded
On Thu, Mar 15, 2018 at 4:50 AM, kbuild test robot
wrote:
> tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
> head: 178cfb9373cc2bdfc
On Tue, Jun 21, 2016 at 12:10 PM, Daniel Vetter wrote:
> - inline functions need to be static inline, otherwise gcc can opt to
> not inline and the linker gets unhappy.
> - no forward decls for inline functions, just include the right headers.
>
> Cc: Oded Gabbay
> Cc: Ben Go
On Sat, Oct 10, 2015 at 4:17 PM, David Woodhouse wrote:
>
> On Fri, 2015-10-09 at 00:50 +0100, David Woodhouse wrote:
> > This patch set enables PASID support for the Intel IOMMU, along with
> > page request support.
> >
> > Like its AMD counterpart, it exposes an IOMMU-specific API. I believe
> >
16 matches
Mail list logo
