search for: refcounted

Hi, I got these errors 3 times since I'm testing gluster with nfs-ganesha. The clients are php apps and when this happen, clients got strange php session error. Below, the first error only happen once but other errors happen every time a clients try to create a new session file. To make php apps work again, I had to restart the client. Do you have an idea of what's happening here ?

On 09/02/2017 02:09 AM, Renaud Fortier wrote: > Hi, > > I got these errors 3 times since I?m testing gluster with nfs-ganesha. > The clients are php apps and when this happen, clients got strange php > session error. Below, the first error only happen once but other errors > happen every time a clients try to create a new session file. To make > php apps work again, I had

Hi Thanks for the reply > >> >> Set logging to verbose, starts Icecast, have it running for a while and >> then >> provide us with the error log please. >> >> Chances are your beta lacks cURL. Where did you get the beta from? >> >> On 27 Jan 2019, at 11:33, Damian wrote: >> > > > I installed from source using the tarball

Hi, This thread seems to have stalled. Would anyone still be able to help me with this one? I?ve posted my log as requested. Any advice would be a great help. > > Message: 1 > Date: Tue, 29 Jan 2019 20:00:21 +1000 > From: Damian <db76 at riseup.net> > To: icecast at xiph.org > Subject: Re: [Icecast] Icecast Digest, Vol 175, Issue 11 > Message-ID:

vhost checked the counter within the refcnt before decrementing. It really wanted to know that it is the one that has the last reference, as a way to batch freeing resources a bit more efficiently. Note: we only let refcount go to 0 on device release. This works well but we now access the ref counter twice so there's a race: all users might see a high count and decide to defer freeing

vhost checked the counter within the refcnt before decrementing. It really wanted to know that it is the one that has the last reference, as a way to batch freeing resources a bit more efficiently. Note: we only let refcount go to 0 on device release. This works well but we now access the ref counter twice so there's a race: all users might see a high count and decide to defer freeing

On 9/15/20 9:29 AM, Christoph Hellwig wrote: > On Mon, Sep 14, 2020 at 04:53:25PM -0700, Ralph Campbell wrote: >> Since set_page_refcounted() is defined in mm_interal.h I would have to >> move the definition to someplace like page_ref.h or have the drivers >> cal init_page_count() or set_page_count() since get_page() calls >> VM_BUG_ON_PAGE() if refcount == 0. >> I'll move set_page_refcounted() since that is...

The current way of handling refcounting in the DP MST helpers is really confusing and probably just plain wrong because it's been hacked up many times over the years without anyone actually going over the code and seeing if things could be simplified. To the best of my understanding, the current scheme works like this: drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When

The current way of handling refcounting in the DP MST helpers is really confusing and probably just plain wrong because it's been hacked up many times over the years without anyone actually going over the code and seeing if things could be simplified. To the best of my understanding, the current scheme works like this: drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When

...to expect that the page is already refcount==0 on > entry? Seems odd to go through all this trouble to make the reference > count appear to be zero to the wider kernel but expect that drivers > get a fake reference on entry to their ->page_free() callbacks. Good point. Since set_page_refcounted() is defined in mm_interal.h I would have to move the definition to someplace like page_ref.h or have the drivers cal init_page_count() or set_page_count() since get_page() calls VM_BUG_ON_PAGE() if refcount == 0. I'll move set_page_refcounted() since that is what the page allocator uses and se...

The current way of handling refcounting in the DP MST helpers is really confusing and probably just plain wrong because it's been hacked up many times over the years without anyone actually going over the code and seeing if things could be simplified. To the best of my understanding, the current scheme works like this: drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When

On Thu, Dec 13, 2018 at 08:25:32PM -0500, Lyude Paul wrote: > The current way of handling refcounting in the DP MST helpers is really > confusing and probably just plain wrong because it's been hacked up many > times over the years without anyone actually going over the code and > seeing if things could be simplified. > > To the best of my understanding, the current scheme

On Fri, 2018-12-14 at 10:29 +0100, Daniel Vetter wrote: > On Thu, Dec 13, 2018 at 08:25:32PM -0500, Lyude Paul wrote: > > The current way of handling refcounting in the DP MST helpers is really > > confusing and probably just plain wrong because it's been hacked up many > > times over the years without anyone actually going over the code and > > seeing if things

On Tue, Dec 18, 2018 at 04:27:58PM -0500, Lyude Paul wrote: > On Fri, 2018-12-14 at 10:29 +0100, Daniel Vetter wrote: > > On Thu, Dec 13, 2018 at 08:25:32PM -0500, Lyude Paul wrote: > > > The current way of handling refcounting in the DP MST helpers is really > > > confusing and probably just plain wrong because it's been hacked up many > > > times over the

On 9/15/20 10:36 PM, Christoph Hellwig wrote: > On Tue, Sep 15, 2020 at 09:39:47AM -0700, Ralph Campbell wrote: >>> I don't think any of the three ->page_free instances even cares about >>> the page refcount. >>> >> Not true. The page_free() callback records the page is free by setting >> a bit or putting the page on a free list but when it

On Thu, Sep 05, 2019 at 03:48:56PM -0400, Vivek Goyal wrote: > This object is used both by fuse_connection as well virt device. So make > this object reference counted and that makes it easy to define life cycle > of the object. > > Now deivce can be removed while filesystem is still mounted. This will > cleanup all the virtqueues but virtio_fs object will still be around and

On Thu, Sep 05, 2019 at 03:48:56PM -0400, Vivek Goyal wrote: > This object is used both by fuse_connection as well virt device. So make > this object reference counted and that makes it easy to define life cycle > of the object. > > Now deivce can be removed while filesystem is still mounted. This will > cleanup all the virtqueues but virtio_fs object will still be around and

On Fri, Sep 25, 2020 at 01:44:42PM -0700, Ralph Campbell wrote: > ZONE_DEVICE struct pages have an extra reference count that complicates the > code for put_page() and several places in the kernel that need to check the > reference count to see that a page is not being used (gup, compaction, > migration, etc.). Clean up the code so the reference count doesn't need to > be

...o_fs_put(struct fuse_iqueue *fiq) > > Minor issue: this function name is confusingly similar to > virtiofs_put(). Please rename to virtio_fs_fiq_put(). Fixed with ->release semantics. Replaced "virtiofs" with "virtio_fs". Subject: virtiofs: Make virtio_fs object refcounted This object is used both by fuse_connection as well virt device. So make this object reference counted and that makes it easy to define life cycle of the object. Now deivce can be removed while filesystem is still mounted. This will cleanup all the virtqueues but virtio_fs object will still be a...

Function's have three kinds of optional data: prefix data, prologue data, and personalities. We don't have a consistent way of storing this data, IMO. This RFC discusses a new way of managing optional data that makes llvm::Function cleaner, more consistent, and a little smaller. What do we do currently? ======================== Prefix and prologue data are attached to Functions via