On 10/10/2014 12:05 AM, Andre Wolokita wrote:
>
>
> On 10/10/14 00:47, Peter Hurley wrote:
>> Hi Andre,
>>
>> On 10/08/2014 11:54 PM, Andre Wolokita wrote:
>>> On 09/10/14 14:38, Greg KH wrote:
On Thu, Oct 09, 2014 at 02:08:04PM +1100, Andre Wolokita wrote:
> On 09/10/14 13:56, Greg KH w
On 10/10/14 00:47, Peter Hurley wrote:
> Hi Andre,
>
> On 10/08/2014 11:54 PM, Andre Wolokita wrote:
>> On 09/10/14 14:38, Greg KH wrote:
>>> On Thu, Oct 09, 2014 at 02:08:04PM +1100, Andre Wolokita wrote:
On 09/10/14 13:56, Greg KH wrote:
> On Thu, Oct 09, 2014 at 11:23:59AM +1100, And
On 10/09/2014 10:26 AM, Alan Stern wrote:
> On Thu, 9 Oct 2014, Andre Wolokita wrote:
>
> Isn't this now a "use-after-free" issue?
>
Are you referring to the subsequent call to wait event() on gs_closed()?
>>>
>>> Yes.
>>>
Testing the use-case with this patch applied seemed
Hi Andre,
On 10/08/2014 11:54 PM, Andre Wolokita wrote:
> On 09/10/14 14:38, Greg KH wrote:
>> On Thu, Oct 09, 2014 at 02:08:04PM +1100, Andre Wolokita wrote:
>>> On 09/10/14 13:56, Greg KH wrote:
On Thu, Oct 09, 2014 at 11:23:59AM +1100, Andre Wolokita wrote:
> Issuing a modprobe -r g_se
On Thu, 9 Oct 2014, Andre Wolokita wrote:
> >>> Isn't this now a "use-after-free" issue?
> >>>
> >>
> >> Are you referring to the subsequent call to wait event() on gs_closed()?
> >
> > Yes.
> >
> >> Testing the use-case with this patch applied seemed to work without any
> >> issues. The ttyGS0
On Thu, 9 Oct 2014, Andre Wolokita wrote:
> Issuing a modprobe -r g_serial command to the target
> over the gadget serial communications line causes
> modprobe to enter uninterruptable sleep, leaving the
> system in an unstable state.
>
> The associated tty_port.count won't drop to 0 because
> th
On 09/10/14 14:38, Greg KH wrote:
> On Thu, Oct 09, 2014 at 02:08:04PM +1100, Andre Wolokita wrote:
>> On 09/10/14 13:56, Greg KH wrote:
>>> On Thu, Oct 09, 2014 at 11:23:59AM +1100, Andre Wolokita wrote:
Issuing a modprobe -r g_serial command to the target
over the gadget serial commun
On Thu, Oct 09, 2014 at 02:08:04PM +1100, Andre Wolokita wrote:
> On 09/10/14 13:56, Greg KH wrote:
> > On Thu, Oct 09, 2014 at 11:23:59AM +1100, Andre Wolokita wrote:
> >> Issuing a modprobe -r g_serial command to the target
> >> over the gadget serial communications line causes
> >> modprobe to e
On 09/10/14 13:56, Greg KH wrote:
> On Thu, Oct 09, 2014 at 11:23:59AM +1100, Andre Wolokita wrote:
>> Issuing a modprobe -r g_serial command to the target
>> over the gadget serial communications line causes
>> modprobe to enter uninterruptable sleep, leaving the
>> system in an unstable state.
>>
On Thu, Oct 09, 2014 at 11:23:59AM +1100, Andre Wolokita wrote:
> Issuing a modprobe -r g_serial command to the target
> over the gadget serial communications line causes
> modprobe to enter uninterruptable sleep, leaving the
> system in an unstable state.
>
> The associated tty_port.count won't d
Hi,
On Thu, Oct 09, 2014 at 11:23:59AM +1100, Andre Wolokita wrote:
> Issuing a modprobe -r g_serial command to the target
> over the gadget serial communications line causes
> modprobe to enter uninterruptable sleep, leaving the
> system in an unstable state.
does anybody know if this is a valid
Issuing a modprobe -r g_serial command to the target
over the gadget serial communications line causes
modprobe to enter uninterruptable sleep, leaving the
system in an unstable state.
The associated tty_port.count won't drop to 0 because
the command is issued over the very line being removed.
De
Issuing a modprobe -r g_serial command to the target
over the gadget serial communications line causes
modprobe to enter uninterruptable sleep, leaving the
system in an unstable state.
The associated tty_port.count won't drop to 0 because
the command is issued over the very line being removed.
De
13 matches
Mail list logo
