On 10/07/2016 01:40 AM, Jason Gunthorpe wrote:
> On Fri, Oct 07, 2016 at 01:26:45AM +0530, Nayna wrote:
>
>> - there is no kref increment during eventlog fops or seq_ops operations.
>> - fops and seq ops are parsing over memory buffer. fops->open() returns
>> after giving the memory buffer(log)
On 10/01/2016 12:35 AM, Jarkko Sakkinen wrote:
> On Wed, Sep 28, 2016 at 04:34:38AM -0400, Nayna Jain wrote:
>> Currently, read_log() has two implementations: one for ACPI platforms
>> and the other for OF platforms. The proper one is selected at compile
>> time using Kconfig and #ifdef in the
On Fri, Oct 07, 2016 at 01:41:29AM +0530, Nayna wrote:
> Are we trying to say that, once the teardown() is started, no more opening
> of files are allowed, even if they are visible ?
Yes.
> But if open() has happened first, and then teardown(), in that case private
> data is already passed to
On 10/04/2016 10:42 PM, Jason Gunthorpe wrote:
> On Tue, Oct 04, 2016 at 08:26:51AM +0300, Jarkko Sakkinen wrote:
>> On Mon, Oct 03, 2016 at 03:11:29PM -0600, Jason Gunthorpe wrote:
>>> On Mon, Oct 03, 2016 at 11:22:30PM +0300, Jarkko Sakkinen wrote:
>>>
> Sort of, the typical race is
On Fri, Oct 07, 2016 at 01:28:47AM +0530, Nayna wrote:
> >fops->open()
> > securityfs_remove()
> > kref_put(chip)
> > kfree(chip)
> >kref_get(data->chip.kref)
>
> I didn't understand which kref_get() are we
On Fri, Oct 07, 2016 at 01:26:45AM +0530, Nayna wrote:
> - there is no kref increment during eventlog fops or seq_ops operations.
> - fops and seq ops are parsing over memory buffer. fops->open() returns
> after giving the memory buffer(log) to seq->open(). And, seq ops on reading
> of log memory
On 10/03/2016 10:05 PM, Jason Gunthorpe wrote:
> On Mon, Oct 03, 2016 at 03:35:23PM +0300, Jarkko Sakkinen wrote:
>
The scheme you suggested is also way off the mark for how fops works,
fops->close has no relation to the needed duration for 'data', the
duration is related to
On Thu, Oct 06, 2016 at 10:22:45AM -0600, Jason Gunthorpe wrote:
> On Thu, Oct 06, 2016 at 02:23:57PM +0300, Jarkko Sakkinen wrote:
>
> > I think that they should be fenced then for the sake of consistency.
> > I do not see why sysfs code is privileged not to do fencing while other
> > peers have
On Wed, Oct 05, 2016 at 10:27:41AM -0600, Jason Gunthorpe wrote:
> On Wed, Oct 05, 2016 at 01:02:34PM +0300, Jarkko Sakkinen wrote:
>
> > I'll repeat my question: what worse can happen than returning -EPIPE? I
> > though the whole rw lock scheme was introduced just for this purpose.
>
> I
