Am 07.12.2015 um 13:25 schrieb Paul Bolle:
>>> Otherwise we'd still be freeing memory
>>> managed through reference counting.
>>
>> Now I#m confused. I thought by following Peter's suggestion to put the
>> kfree() in the release method we'd avoid just that.
>
> Apparently it does, because I can't
[Re-added mailinglist that got dropped somehow.]
On ma, 2015-12-07 at 10:27 +0100, Tilman Schmidt wrote:
> Am 06.12.2015 um 21:12 schrieb Paul Bolle:
> > This solution assumes that the struct platform_device is moved out
> > of
> > the struct ser_cardstate, doesn't it? In other words, this is
> >
Am 06.12.2015 um 21:12 schrieb Paul Bolle:
> On zo, 2015-12-06 at 16:29 +0100, Tilman Schmidt wrote:
>> So the solution might be as simple as moving the kfree() call from
>> gigaset_freecshw() to gigaset_device_release(). Something like this:
>>
>> --- a/drivers/isdn/gigaset/ser-gigaset.c
>> +++ b/
On zo, 2015-12-06 at 16:29 +0100, Tilman Schmidt wrote:
> So the solution might be as simple as moving the kfree() call from
> gigaset_freecshw() to gigaset_device_release(). Something like this:
>
> --- a/drivers/isdn/gigaset/ser-gigaset.c
> +++ b/drivers/isdn/gigaset/ser-gigaset.c
> @@ -370,19 +
Am 06.12.2015 um 14:31 schrieb Paul Bolle:
> On wo, 2015-12-02 at 18:48 -0500, Peter Hurley wrote:
>> On 11/30/2015 01:01 PM, Paul Bolle wrote:
>>> --- a/drivers/isdn/gigaset/ser-gigaset.c
>>> +++ b/drivers/isdn/gigaset/ser-gigaset.c
>>> @@ -42,8 +42,9 @@ MODULE_PARM_DESC(cidmode, "stay in CID mod
On wo, 2015-12-02 at 18:48 -0500, Peter Hurley wrote:
> On 11/30/2015 01:01 PM, Paul Bolle wrote:
> > Should (something like) this go into stable too?
>
> Definitely for stable since it has a userspace triggerable component.
Thanks, will do.
> > --- a/drivers/isdn/gigaset/ser-gigaset.c
> > +++ b
On 11/30/2015 01:01 PM, Paul Bolle wrote:
> On ma, 2015-11-30 at 00:23 +0100, Paul Bolle wrote:
>> Relevant part of dmesg attached at the end of this message. This
>> should give me (and Tilman too?) an entry to get to bottom of this.
>> Since this is relevant for anyone with just the ser-gigaset
On di, 2015-12-01 at 10:30 +0100, Tilman Schmidt wrote:
> Am 30.11.2015 um 22:07 schrieb Paul Bolle:
> > How would attaching two devices work with GIGASET_MINORS hardcoded
> > to 1?
>
> Ah, it wouldn't. You'd have to recompile with a bigger GIGASET_MINORS.
>
> (I wonder if that would actually wor
Am 30.11.2015 um 22:07 schrieb Paul Bolle:
> How would attaching two devices work with GIGASET_MINORS hardcoded to 1?
Ah, it wouldn't. You'd have to recompile with a bigger GIGASET_MINORS.
(I wonder if that would actually work. Somehow I still think of
GIGASET_MINORS as a configurable value, but
On ma, 2015-11-30 at 19:30 +0100, Tilman Schmidt wrote:
> I wonder how that will behave if someone attaches two of the devices to
> different serial ports. Not likely, but not forbidden either.
I see.
Perhaps I should respin and a use a pointer to a struct platform_device
in struct ser_cardstate,
Am 30.11.2015 um 19:01 schrieb Paul Bolle:
> [DRAFT] gigaset: don't free() a struct platform_device
>
> One is not supposed to free() a struct platform_device. Instead one
> should, in the common case, only call platform_device_unregister(). That
> will drop the platform device's reference count.
On ma, 2015-11-30 at 00:23 +0100, Paul Bolle wrote:
> Relevant part of dmesg attached at the end of this message. This
> should give me (and Tilman too?) an entry to get to bottom of this.
> Since this is relevant for anyone with just the ser-gigaset module
> installed, I hope to do that soon.
I
On zo, 2015-11-29 at 21:26 +0100, Paul Bolle wrote:
> If the above is correct it would be nice to know the .config of the
> kernel used by syzkaller.
>
> Anyhow, without further details of the chain of events that triggered
> this warning, I'm afraid it will be hard to determine which struct
> tim
On zo, 2015-11-29 at 19:47 +0100, Tilman Schmidt wrote:
> Btw I don't see a timer_list object in struct platform_device either.
> Nor in the embedded struct device.
I found two instances of struct timer_list, rather deep down struct
ser_cardstate:
struct ser_cardstate {
struct platform_de
Am 29.11.2015 um 19:22 schrieb Peter Hurley:
>>> [ 413.536749] WARNING: CPU: 6 PID: 25400 at lib/debugobjects.c:263
>>> debug_print_object+0x1c4/0x1e0()
>>> [ 413.538111] ODEBUG: free active (active state 0) object type: timer_list
>>> hint: delayed_work_timer_fn+0x0/0x90
>>
>> This message se
Am 29.11.2015 um 19:22 schrieb Peter Hurley:
> On 11/29/2015 10:30 AM, Tilman Schmidt wrote:
>>
>> Judging from the backtrace below this must be the call
>>
>> kfree(cs->hw.ser);
>>
>> in drivers/isdn/gigaset/ser-gigaset.c line 375.
>> cs->hw.ser is of type struct ser_cardstate *.
>> struct
Hi Tilman,
On 11/29/2015 10:30 AM, Tilman Schmidt wrote:
> Hi Sasha,
>
> thanks for the report. As the original author of the code in question, I
> am somewhat at a loss what to make of it.
>
> Am 27.11.2015 um 16:19 schrieb Sasha Levin:
>> Fuzzing with syzkaller on the latest -next kernel produ
Hi Sasha,
thanks for the report. As the original author of the code in question, I
am somewhat at a loss what to make of it.
Am 27.11.2015 um 16:19 schrieb Sasha Levin:
> Fuzzing with syzkaller on the latest -next kernel produced this error:
Is there a way to know the actual sequence of events t
On Sat, Nov 28, 2015 at 2:27 AM, Sasha Levin wrote:
> On 11/27/2015 08:20 PM, Peter Hurley wrote:
>> It would really help if you included the syzkaller-generated applet with
>> the bug reports; state previously established by the applet can be
>> crucial in understanding why the call stack looks t
On 11/27/2015 08:20 PM, Peter Hurley wrote:
> It would really help if you included the syzkaller-generated applet with
> the bug reports; state previously established by the applet can be
> crucial in understanding why the call stack looks the way it does.
>
> Also, every generated applet that tri
On 11/27/2015 07:28 PM, Paul Bolle wrote:
> (A few quick notes follow. The hope here is basically that my display of
> ignorance might trigger others to speak up while I'm still pondering on
> this bug.)
>
> On vr, 2015-11-27 at 13:15 -0500, Sasha Levin wrote:
>> On 11/27/2015 12:57 PM, Paul Bolle
(A few quick notes follow. The hope here is basically that my display of
ignorance might trigger others to speak up while I'm still pondering on
this bug.)
On vr, 2015-11-27 at 13:15 -0500, Sasha Levin wrote:
> On 11/27/2015 12:57 PM, Paul Bolle wrote:
> > On vr, 2015-11-27 at 10:19 -0500, Sasha L
On 11/27/2015 12:57 PM, Paul Bolle wrote:
> Hi Sascha,
>
> On vr, 2015-11-27 at 10:19 -0500, Sasha Levin wrote:
>> Fuzzing with syzkaller on the latest -next kernel produced this error:
>
> (syzkaller is new to me. I'll have to do some web searches.)
It's a new fancy syscall/ioctl fuzzer,
https
Hi Sascha,
On vr, 2015-11-27 at 10:19 -0500, Sasha Levin wrote:
> Fuzzing with syzkaller on the latest -next kernel produced this error:
(syzkaller is new to me. I'll have to do some web searches.)
> [ 413.536749] WARNING: CPU: 6 PID: 25400 at lib/debugobjects.c:263
> debug_print_object+0x1c4/0
Hi,
Fuzzing with syzkaller on the latest -next kernel produced this error:
[ 413.536749] WARNING: CPU: 6 PID: 25400 at lib/debugobjects.c:263
debug_print_object+0x1c4/0x1e0()
[ 413.538111] ODEBUG: free active (active state 0) object type: timer_list
hint: delayed_work_timer_fn+0x0/0x90
[ 413
25 matches
Mail list logo
