> > It's not duplication, it's increment/decrement of a counter.
> >
> > Look for functions with 'get' and 'put' in their names.
>
> AFAICT counter is f_count in struct file, updated by fget and fput.
Yes, this is the counter I was speaking about. But to me the only way to
increment/decrement
On Tue, 05 Jun 2018 10:20:16 -0400, Hugo Lefeuvre said:
> Thanks. I think I'll have to read the source code to fully understand
> what happens. Do you know what piece of code handles this reference
> duplication ?
It's not duplication, it's increment/decrement of a counter.
Look for functions
> > Do you mean that the ioctl/read/write call increments the reference
> > count in this case ? It would mean that these syscalls aren't really
> > using passed FD but instead create duplicates to make sure the open
> > file description won't be freed during their execution, right ?
>
> One file
On Mon, 04 Jun 2018 18:31:31 -0400, Hugo Lefeuvre said:
> Do you mean that the ioctl/read/write call increments the reference
> count in this case ? It would mean that these syscalls aren't really
> using passed FD but instead create duplicates to make sure the open
> file description won't be
> > > The vfs documentation states: release() is "called when the last
> > > reference to an open file is closed".
> > >
> > > Let's say we have a program with threads T1 and T2.
> > >
> > > - T1 calls ioctl on a file descriptor FD.
> > > - (on another processor) T2 closes FD.
> > >
> > > Since
On Mon, 04 Jun 2018 05:33:03 +0200, Valentin Vidic said:
> On Sun, Jun 03, 2018 at 06:25:56PM -0400, Hugo Lefeuvre wrote:
> > The vfs documentation states: release() is "called when the last
> > reference to an open file is closed".
> >
> > Let's say we have a program with threads T1 and T2.
> >
> Nothing fancy, just added debug print statements to the release
> and ioctl methods of the pi433 driver. The ioctl method also has
> a 5s sleep so it takes some time to execute while the other thread
> calls close on the same file descriptor.
>
> The timing should be as follows:
>
> 0s
On Mon, Jun 04, 2018 at 06:27:43AM +, Nicholas Mc Guire wrote:
> are you using kprobes to get this information or how did you trace
> these calls ? could you explain how you did that ? I assume that
> would be of interest to others as well not only me.
Nothing fancy, just added debug print
On Sun, Jun 03, 2018 at 06:25:56PM -0400, Hugo Lefeuvre wrote:
> The vfs documentation states: release() is "called when the last
> reference to an open file is closed".
>
> Let's say we have a program with threads T1 and T2.
>
> - T1 calls ioctl on a file descriptor FD.
> - (on another
> > So, if pi433_release() and pi433_ioctl() can be concurrently executed
> > then this issue might happen.
>
> But isn't release() called when nothing is referencing the file anymore,
> so there should be no other file operation running concurrently?
The vfs documentation states: release() is
On Wed, May 30, 2018 at 09:44:32PM -0400, Hugo Lefeuvre wrote:
> So, if pi433_release() and pi433_ioctl() can be concurrently executed
> then this issue might happen.
But isn't release() called when nothing is referencing the file anymore,
so there should be no other file operation running
> > For example the TODO entry at line 876: If pi433_release() is
> > called while pi433_ioctl() is executing between lines 879 and
> > 880, we might perform a NULL pointer dereference, right ?
>
> Yes, no, maybe. That's what kernel locks are for. Is that data
> protected against concurrent
On Tue, 29 May 2018 22:56:57 -0400, Hugo Lefeuvre said:
> For example the TODO entry at line 876: If pi433_release() is
> called while pi433_ioctl() is executing between lines 879 and
> 880, we might perform a NULL pointer dereference, right ?
Yes, no, maybe. That's what kernel locks are for.
Hi Greg,
> No need to coordinate anything, just start sending patches against the
> latest development tree (linux-next, or the staging.git staging-next
> branch), and all will be fine.
>
> If there are conflicts, the maintainer will let you know, but they are
> usually quite rare.
Then I will
Hi Valdis,
> The canonical place to check would be the git tree for drivers/staging:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/
>
> In general, if there's other people doing active development, they'll show
> up in 'git log -- drivers/staging/pi433/'
>
> And
On Mon, May 28, 2018 at 11:07:06PM -0400, Hugo Lefeuvre wrote:
> Hi,
>
> I've started to take a look at TODO entries in the staging drivers
> subtree and found some issues in pi433 I'd like to work on. Before
> starting to prepare my patch, I tried to check the LKML and the bug
> tracker to make
On Mon, 28 May 2018 23:07:06 -0400, Hugo Lefeuvre said:
> Did I miss something ? Is there a specific place where I can coordinate
> with the rest of the kernel dev community and make people aware I'm
> working on this particular issue ? (apart from the bug tracker, which
> doesn't seem to be very
Hi,
I've started to take a look at TODO entries in the staging drivers
subtree and found some issues in pi433 I'd like to work on. Before
starting to prepare my patch, I tried to check the LKML and the bug
tracker to make sure nobody was working on the same issues as me
(this driver seems to be
18 matches
Mail list logo
