Re: [PATCH] tty/n_gsm.c: fix a memory leak in gsmld_open

2014-07-28 Thread xinhui.pan
于 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. >>

Re: [PATCH] tty/n_gsm.c: fix a memory leak in gsmld_open

2014-07-28 Thread 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. >> tty core just restore to the tty old ldisc. >> Tha

Re: [PATCH] tty/n_gsm.c: fix a memory leak in gsmld_open

2014-07-28 Thread xinhui.pan
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

[PATCH] tty/n_gsm.c: fix a memory leak in gsmld_open

2014-07-28 Thread xinhui.pan
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

Re: [PATCH] tty/n_gsm.c: do not clear gsm_mux entry when the gsm is not closed

2014-07-28 Thread xinhui.pan
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

Re: [PATCH] tty/tty_io.c: make a check before reuse cdev

2014-07-24 Thread xinhui.pan
于 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

Re: [PATCH] tty/tty_io.c: make a check before reuse cdev

2014-07-24 Thread xinhui.pan
于 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

Re: [PATCH] tty/tty_io.c: make a check before reuse cdev

2014-07-24 Thread xinhui.pan
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 写道: >>>>>

[PATCH] tty/n_gsm.c: do not clear gsm_mux entry when the gsm is not closed

2014-07-24 Thread xinhui.pan
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

Re: [PATCH] tty/tty_io.c: make a check before reuse cdev

2014-07-23 Thread xinhui.pan
于 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

[PATCH] tty/n_gsm.c: get gsm->num after gsm_activate_mux

2014-07-22 Thread xinhui.pan
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

Re: [PATCH] tty/tty_io.c: make a check before reuse cdev

2014-07-22 Thread xinhui.pan
于 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

Re: [dm-devel] [PATCH] md/dm-ioctl.c: optimize memory allocation in copy_params

2014-07-08 Thread xinhui.pan
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

[PATCH] md/dm-ioctl.c: optimize memory allocation in copy_params

2014-07-04 Thread xinhui.pan
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

Re: [PATCH] usb/core/hub.c: return immediately when hub_port_init hits timedout

2014-03-06 Thread xinhui.pan
于 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. > &

[PATCH] usb/core/hub.c: return immediately when hub_port_init hits timedout

2014-03-06 Thread xinhui.pan
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

Re: [PATCH] gpio-intel-mid: fix the incorrect return of idle callback

2014-01-30 Thread xinhui.pan
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年

Re: [PATCH] i2c-designware-pcidrv: fix the incorrect return of idle callback

2014-01-29 Thread xinhui.pan
于 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

Re: [PATCH] i2c-designware-pcidrv: fix the incorrect return of idle callback

2014-01-28 Thread xinhui.pan
于 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

Re: [PATCH] gpio-intel-mid: fix the incorrect return of idle callback

2014-01-28 Thread xinhui.pan
于 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

Re: [PATCH] i2c-designware-pcidrv: fix the incorrect return of idle callback

2014-01-28 Thread 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. > > I don't understand... > Sorry for my poor English. Even if i2c_d

[PATCH] gpio-intel-mid: fix the incorrect return of idle callback

2014-01-28 Thread xinhui.pan
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

[PATCH] i2c-designware-pcidrv: fix the incorrect return of idle callback

2014-01-27 Thread xinhui.pan
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/