于 2014年07月28日 17:03, xinhui.pan 写道:
> Hi, Jiri
>
> 于 2014年07月28日 16:49, Jiri Slaby 写道:
>> On 07/28/2014 10:14 AM, xinhui.pan wrote:
>>> If gsmld_attach_gsm fails, the gsm is not used anymore.
>>> tty core will not call gsmld_close to do the cleanup work.
>>
Hi, Jiri
于 2014年07月28日 16:49, Jiri Slaby 写道:
> On 07/28/2014 10:14 AM, xinhui.pan wrote:
>> If gsmld_attach_gsm fails, the gsm is not used anymore.
>> tty core will not call gsmld_close to do the cleanup work.
>> tty core just restore to the tty old ldisc.
>> Tha
cached, 332K shmem,
1092232K slab
AWESOME!
cat /proc/slabinfo
.
kmalloc-2048 509700 509700 2048 168 : tunables000 :
slabdata 32285 32285 0
.
AWESOME!!
thanks,
xinhui
于 2014年07月28日 16:14, xinhui.pan 写道:
> If gsmld_attach_gsm fails, the gsm is not used
If gsmld_attach_gsm fails, the gsm is not used anymore.
tty core will not call gsmld_close to do the cleanup work.
tty core just restore to the tty old ldisc.
That always causes memory leak.
Signed-off-by: xinhui.pan
Reported-by: Peter Hurley
---
drivers/tty/n_gsm.c |9 -
1 file
hi, Greg
于 2014年07月28日 02:09, Greg Kroah-Hartman 写道:
> On Thu, Jul 24, 2014 at 05:17:01PM +0800, xinhui.pan wrote:
>> If the gsmtty is still used by some process, we could not just
>> simply clear gsm_mux[gsm->num]. Clear it when gsm is being free.
>> Otherwise we will hi
于 2014年07月24日 00:07, One Thousand Gnomes 写道:
>> Very nice solution. We will check if this can cause any risk, both to kernel
>> and user space.
>> Using a new tty base to register with new cdevs may give us more chance to
>> wait PROCESS quit/close.
>> when total 256 tty used up, what we should d
于 2014年07月24日 00:07, One Thousand Gnomes 写道:
>> Very nice solution. We will check if this can cause any risk, both to kernel
>> and user space.
>> Using a new tty base to register with new cdevs may give us more chance to
>> wait PROCESS quit/close.
>> when total 256 tty used up, what we should d
hi, Peter
于 2014年07月24日 00:04, Peter Hurley 写道:
> Hi Xinhui,
>
> On 07/23/2014 05:21 AM, xinhui.pan wrote:
>> 于 2014年07月23日 00:40, Peter Hurley 写道:
>>> On 07/22/2014 07:52 AM, xinhui.pan wrote:
>>>> 于 2014年07月21日 23:38, Greg KH 写道:
>>>>>
ion/deactivation with same gsm more than once now.
This is for fixing the FIXME.
Signed-off-by: xinhui.pan
Reviewed-by: Zhang Yanmin
---
drivers/tty/n_gsm.c | 84 ---
1 file changed, 60 insertions(+), 24 deletions(-)
diff --git a/drivers/tty/n_gsm.c b/driv
于 2014年07月23日 00:40, Peter Hurley 写道:
> On 07/22/2014 07:52 AM, xinhui.pan wrote:
>>
>> 于 2014年07月21日 23:38, Greg KH 写道:
>>> On Mon, Jul 21, 2014 at 08:47:16PM +0800, pp wrote:
>>>> As reuse the cdev may cause panic. After we unregister the tty device, we
&g
gsm->num is the index of gsm_mux[], it's invalid before calling
gsm_activate_mux.
Signed-off-by: xinhui.pan
---
drivers/tty/n_gsm.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index 2ebe47b..81e7ccb 100644
--- a
于 2014年07月21日 23:38, Greg KH 写道:
> On Mon, Jul 21, 2014 at 08:47:16PM +0800, pp wrote:
>> As reuse the cdev may cause panic. After we unregister the tty device, we
>> may use tty_hangup() o
>> other similar function to send a signal(SIGHUP) to process which has opend
>> our device. But that
>> n
d, there is a command "dumpstate", it run many other commands to
collect information. In our scenario,
it run command "vdc dump", and vdc uses socket to pass some parameters to
"vold", then vold generates ioctl.
thanks.
> We are catching all places in kernel whe
And that cause
our devices to hit hang and
many worse issues. We don't benefit much when using kmalloc in such scenario.
Signed-off-by: xinhui.pan
Signed-off-by: yanmin.zhang
---
drivers/md/dm-ioctl.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-ioct
于 2014年03月07日 14:47, Greg KH 写道:
> On Fri, Mar 07, 2014 at 02:15:48PM +0800, xinhui.pan wrote:
>> From: "xinhui.pan"
>
> I doubt your name as a "." in it, right?
>
yes :)
>> some devices go crasy, we can't resume it even after reset.
>
&
From: "xinhui.pan"
some devices go crasy, we can't resume it even after reset. This case will
cause timeout again and again. What is worse, if there is a watchdog,
panic will be generated as timer expires. To prevent this, we just return
-ENODEV immediately. Later it will b
On Wed, 29 Jan 2014 13:06, David Cohen wrote:
> On Wed, Jan 29, 2014 at 01:52:30PM -0600, Felipe Balbi wrote:
>> On Wed, Jan 29, 2014 at 11:12:32AM -0800, David Cohen wrote:
>>> On Wed, Jan 29, 2014 at 03:23:40PM +0800, xinhui.pan wrote:
>>>>
>>>> 于 2014年
于 2014年01月29日 16:35, Mika Westerberg 写道:
> On Tue, Jan 28, 2014 at 07:30:35PM +0100, Wolfram Sang wrote:
>> On Tue, Jan 28, 2014 at 01:48:28PM +0800, xinhui.pan wrote:
>>> From: "xinhui.pan"
>>>
>>> i2c_dw_pci_runtime_idle should return -EBUSY r
于 2014年01月29日 10:03, xinhui.pan 写道:
>
>> On Tue, Jan 28, 2014 at 01:48:28PM +0800, xinhui.pan wrote:
>>> From: "xinhui.pan"
>>>
>>> i2c_dw_pci_runtime_idle should return -EBUSY rather than zero if it do
>>> success.
>>
>&g
于 2014年01月29日 08:13, David Cohen 写道:
> On Tue, Jan 28, 2014 at 12:12:06PM -0600, Felipe Balbi wrote:
>> On Tue, Jan 28, 2014 at 09:24:13AM -0800, David Cohen wrote:
>>> On Tue, Jan 28, 2014 at 10:49:37AM -0600, Felipe Balbi wrote:
>>>> On Tue, Jan 28, 2014 at 04:5
> On Tue, Jan 28, 2014 at 01:48:28PM +0800, xinhui.pan wrote:
>> From: "xinhui.pan"
>>
>> i2c_dw_pci_runtime_idle should return -EBUSY rather than zero if it do
>> success.
>
> I don't understand...
>
Sorry for my poor English.
Even if i2c_d
From: "xinhui.pan"
intel_gpio_runtime_idle should return correct error code if it do fail.
make it more correct even though -EBUSY is the most possible return value.
Signed-off-by: bo.he
Signed-off-by: xinhui.pan
---
drivers/gpio/gpio-intel-mid.c |4 +++-
1 file changed, 3
From: "xinhui.pan"
i2c_dw_pci_runtime_idle should return -EBUSY rather than zero if it do success.
Otherwise rpm_idle will call pm_suspend again and that may cause
pm_schedule_suspend delay invalidate.
Signed-off-by: bo.he
Signed-off-by: xinhui.pan
---
drivers/i2c/
23 matches
Mail list logo