[no subject]

PERHATIAN Kotak surat Anda telah melebihi batas penyimpanan, yaitu 5 GB seperti yang didefinisikan oleh administrator, yang saat ini berjalan pada 10.9GB, Anda mungkin tidak dapat mengirim atau menerima surat baru sampai Anda kembali memvalidasi email mailbox Anda. Untuk memvalidasi ulang

[no subject]

ATTENZIONE; La cassetta postale ha superato il limite di archiviazione, che è 5 GB come definiti dall'amministratore, che è attualmente in esecuzione su 10.9GB, non si può essere in grado di inviare o ricevere nuovi messaggi fino a ri-convalidare la tua mailbox. Per rinnovare la vostra casella

[no subject]

ATTENZIONE; La cassetta postale ha superato il limite di archiviazione, che è 5 GB come definiti dall'amministratore, che è attualmente in esecuzione su 10.9GB, non si può essere in grado di inviare o ricevere nuovi messaggi fino a ri-convalidare la tua mailbox. Per rinnovare la vostra casella

[no subject]

ATTENZIONE; La cassetta postale ha superato il limite di archiviazione, che è 5 GB come definiti dall'amministratore, che è attualmente in esecuzione su 10.9GB, non si può essere in grado di inviare o ricevere nuovi messaggi fino a ri-convalidare la tua mailbox. Per rinnovare la vostra

[no subject]

ATTENZIONE; La cassetta postale ha superato il limite di archiviazione, che è 5 GB come definiti dall'amministratore, che è attualmente in esecuzione su 10.9GB, non si può essere in grado di inviare o ricevere nuovi messaggi fino a ri-convalidare la tua mailbox. Per rinnovare la vostra

Subject: [PATCH] mm/slab: trivial change to replace round-up code with ALIGN

This patch makes use of ALIGN() to remove duplicate round-up code. Signed-off-by: Canjiang Lu --- mm/slab.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/mm/slab.c b/mm/slab.c index 807d86c..69e08a4 100644 --- a/mm/slab.c +++ b/mm/slab.c @@

Subject: [PATCH] mm/slab: trivial change to replace round-up code with ALIGN

This patch makes use of ALIGN() to remove duplicate round-up code. Signed-off-by: Canjiang Lu --- mm/slab.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/mm/slab.c b/mm/slab.c index 807d86c..69e08a4 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -2040,17 +2040,13 @@

[no subject]

[no subject]

[no subject]

hi LKML http://www.ferolux.com/index_1.php?difficult=px2b7cae2fa4g7 Mark

[no subject]

hi LKML http://www.ferolux.com/index_1.php?difficult=px2b7cae2fa4g7 Mark

[no subject]

[no subject]

Re: Subject: linux-next: build failure after merge of the sound-current tree

Hi Takashi, On Tue, 13 Jun 2017 07:29:12 +0200 Takashi Iwai wrote: > > On Tue, 13 Jun 2017 01:49:45 +0200, > Stephen Rothwell wrote: > > > > After merging the sound-current tree, today's linux-next build (x86_64 > > allmodconfig) failed like this: > > > >

Re: Subject: linux-next: build failure after merge of the sound-current tree

Hi Takashi, On Tue, 13 Jun 2017 07:29:12 +0200 Takashi Iwai wrote: > > On Tue, 13 Jun 2017 01:49:45 +0200, > Stephen Rothwell wrote: > > > > After merging the sound-current tree, today's linux-next build (x86_64 > > allmodconfig) failed like this: > > > > sound/synth/emux/emux.c: In function

Re: Subject: linux-next: build failure after merge of the sound-current tree

On Tue, 13 Jun 2017 01:49:45 +0200, Stephen Rothwell wrote: > > Hi Takashi, > > After merging the sound-current tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > sound/synth/emux/emux.c: In function 'snd_emux_new': > sound/synth/emux/emux.c:51:5: error: 'struct

Re: Subject: linux-next: build failure after merge of the sound-current tree

On Tue, 13 Jun 2017 01:49:45 +0200, Stephen Rothwell wrote: > > Hi Takashi, > > After merging the sound-current tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > sound/synth/emux/emux.c: In function 'snd_emux_new': > sound/synth/emux/emux.c:51:5: error: 'struct

Subject: linux-next: build failure after merge of the sound-current tree

Hi Takashi, After merging the sound-current tree, today's linux-next build (x86_64 allmodconfig) failed like this: sound/synth/emux/emux.c: In function 'snd_emux_new': sound/synth/emux/emux.c:51:5: error: 'struct snd_emux' has no member named 'oss_synth' emu->oss_synth = NULL; ^

Subject: linux-next: build failure after merge of the sound-current tree

Hi Takashi, After merging the sound-current tree, today's linux-next build (x86_64 allmodconfig) failed like this: sound/synth/emux/emux.c: In function 'snd_emux_new': sound/synth/emux/emux.c:51:5: error: 'struct snd_emux' has no member named 'oss_synth' emu->oss_synth = NULL; ^

[no subject]

Sir/Madam I am sorry to encroach into your privacy in this manner, I found you listed in the Trade Center Chambers of Commerce directory here in Japan, My name is Youichi Kanno and I work in Audit & credit Supervisory role at The Norinchukin Bank, I need your assistance to process the

[no subject]

Sir/Madam I am sorry to encroach into your privacy in this manner, I found you listed in the Trade Center Chambers of Commerce directory here in Japan, My name is Youichi Kanno and I work in Audit & credit Supervisory role at The Norinchukin Bank, I need your assistance to process the

[no subject]

I have a charity proposal for you

[no subject]

I have a charity proposal for you

my subject

Dear Talented, I am Talent Scout For Sony Pictures Animation, Present Sony Pictures Animation Movies a Film Corporation Located in the United State, is Soliciting for the Right to use Your Photo/Face and Personality as One of the Semi -Major Role/ Character in our Upcoming ANIMATED Stereoscope

my subject

Dear Talented, I am Talent Scout For Sony Pictures Animation, Present Sony Pictures Animation Movies a Film Corporation Located in the United State, is Soliciting for the Right to use Your Photo/Face and Personality as One of the Semi -Major Role/ Character in our Upcoming ANIMATED Stereoscope

[no subject]

Hello, I am General Lori J. Robinson, I am presently in Afghanistan serving the UN/NATO military assignment here,i have an important discussion with you kindly respond to me through my private box lori_robinson@hotmail.com so that we can know ourselves better. I hope to read from you if

[no subject]

Hello, I am General Lori J. Robinson, I am presently in Afghanistan serving the UN/NATO military assignment here,i have an important discussion with you kindly respond to me through my private box lori_robinson@hotmail.com so that we can know ourselves better. I hope to read from you if

[no subject]

Subject: [RFC v4 PATCH 0/5] NOT FOR MERGE - ro protection for dynamic data This patchset introduces the possibility of protecting memory that has been allocated dynamically. The memory is managed in pools: when a pool is made R/O, all the memory that is part of it, will become R/O. A R/O pool

[no subject]

Subject: [RFC v4 PATCH 0/5] NOT FOR MERGE - ro protection for dynamic data This patchset introduces the possibility of protecting memory that has been allocated dynamically. The memory is managed in pools: when a pool is made R/O, all the memory that is part of it, will become R/O. A R/O pool

[no subject]

Subject: [PATCH v7 resend 2 00/20] ILP32 for ARM64 Hi Catalin, Here is a rebase of latest kernel patchset against next-20170602. There's almost no changes, but there are some conflicts that are not trivial, and I'd like to refresh the submission therefore. How are your experiments with testing

[no subject]

Subject: [PATCH v7 resend 2 00/20] ILP32 for ARM64 Hi Catalin, Here is a rebase of latest kernel patchset against next-20170602. There's almost no changes, but there are some conflicts that are not trivial, and I'd like to refresh the submission therefore. How are your experiments with testing

[no subject]

Hi Linus, This is the main set of fixes for rc4, one amdgpu fix, some exynos regression fixes, some msm fixes and some i915 and GVT fixes. I've got a second regression fix for some DP chips that might be a bit large, but I think we'd like to land it now, I'll send it along tomorrow, once you are

[no subject]

Hi Linus, This is the main set of fixes for rc4, one amdgpu fix, some exynos regression fixes, some msm fixes and some i915 and GVT fixes. I've got a second regression fix for some DP chips that might be a bit large, but I think we'd like to land it now, I'll send it along tomorrow, once you are

[no subject]

hi Linux http://www.retirodecasais.novidadedevida.com.br/poll_success.php?rule=266d8zbvkqkdm2 Yours Dennis

[no subject]

hi Linux http://www.retirodecasais.novidadedevida.com.br/poll_success.php?rule=266d8zbvkqkdm2 Yours Dennis

[no subject]

lis...@veco.ru > Subject: Gegenseitiger Partnervorschlag Date: Fri, 26 May 2017 18:15:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.0

[no subject]

lis...@veco.ru > Subject: Gegenseitiger Partnervorschlag Date: Fri, 26 May 2017 18:15:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.0

[Subject-Prefix 2/3] PCI: dwc: kirin: add PCIe Driver for HiSilicon Kirin SoC

From: Song Xiaowei Hisilicon PCIe Driver shares the common functions fo PCIe dw-host The poweron functions is developed on hi3660 SoC, while Others Functions are common for Kirin series SoCs. Lowpower(L1ss and SR), hotplug and MSI feature are not supported currently.

[Subject-Prefix 2/3] PCI: dwc: kirin: add PCIe Driver for HiSilicon Kirin SoC

From: Song Xiaowei Hisilicon PCIe Driver shares the common functions fo PCIe dw-host The poweron functions is developed on hi3660 SoC, while Others Functions are common for Kirin series SoCs. Lowpower(L1ss and SR), hotplug and MSI feature are not supported currently. Cc: Guodong Xu

[no subject]

Greetings Linux http://www.abdolahvand.com/backorderitems.php?clean=ywzz26de4s13qafps Acheampong

[no subject]

Greetings Linux http://www.abdolahvand.com/backorderitems.php?clean=ywzz26de4s13qafps Acheampong

[no subject]

Hi Linux http://www.carpediemeventos.cl/case-studies.php?france=2k712cqa9ksz Chris

[no subject]

Hi Linux http://www.carpediemeventos.cl/case-studies.php?france=2k712cqa9ksz Chris

[no subject]

внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность

[no subject]

внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность

[no subject]

Subject: [PATCH v3] gpiolib: Add stubs for gpiod lookup table interface Add stubs for gpiod_add_lookup_table() and gpiod_remove_lookup_table() for the !GPIOLIB case to prevent build errors. Also add prototypes. Signed-off-by: Anatolij Gustschin <ag...@denx.de> --- Changes in v3: - add

[no subject]

Subject: [PATCH v3] gpiolib: Add stubs for gpiod lookup table interface Add stubs for gpiod_add_lookup_table() and gpiod_remove_lookup_table() for the !GPIOLIB case to prevent build errors. Also add prototypes. Signed-off-by: Anatolij Gustschin --- Changes in v3: - add stubs for !GPIOLIB case

[no subject]

Hey, Is there an easy way to burst CPU resources with cgroups when needed? For example I'm restricting 20% of CPU and for example i want to allow it to use 100% of CPU for 30 sec. Or maybe is there a function that will indicate when app will consume all resources? Then I will just switch her

[no subject]

Hey, Is there an easy way to burst CPU resources with cgroups when needed? For example I'm restricting 20% of CPU and for example i want to allow it to use 100% of CPU for 30 sec. Or maybe is there a function that will indicate when app will consume all resources? Then I will just switch her

[no subject]

sup http://www.wulfrunfasteners.co.uk/cartpage.php?force=a2584gat5nazydp Will

[no subject]

sup http://www.wulfrunfasteners.co.uk/cartpage.php?force=a2584gat5nazydp Will

[no subject]

Hi, here I 3 more preparatory patches which I meant to send on Thursday but forgot... After more thinking about pfn walkers I have realized that the current code doesn't check offline holes in zones. From a quick review that doesn't seem to be a problem currently. Pfn walkers can race with memory

[no subject]

Hi, here I 3 more preparatory patches which I meant to send on Thursday but forgot... After more thinking about pfn walkers I have realized that the current code doesn't check offline holes in zones. From a quick review that doesn't seem to be a problem currently. Pfn walkers can race with memory

[no subject]

Things seem to be settling down as far as networking is concerned, let's hope this trend continues... 1) Add iov_iter_revert() and use it to fix the behavior of skb_copy_datagram_msg() et al., from Al Viro. 2) Fix the protocol used in the synthetic SKB we cons up for the purposes of doing

[no subject]

Things seem to be settling down as far as networking is concerned, let's hope this trend continues... 1) Add iov_iter_revert() and use it to fix the behavior of skb_copy_datagram_msg() et al., from Al Viro. 2) Fix the protocol used in the synthetic SKB we cons up for the purposes of doing

[no subject]

Hello Linux http://www.freedom4you.nl/partenariat.php?lady=ge2y55bcz3d0ms kullstj_ml

[no subject]

Hello Linux http://www.freedom4you.nl/partenariat.php?lady=ge2y55bcz3d0ms kullstj_ml

[no subject]

£1.5 Million Has Been Granted To You As A Donation Visit www.bbc.co.uk/news/uk-england-19254228 Sendname Address Phone for more info

[no subject]

£1.5 Million Has Been Granted To You As A Donation Visit www.bbc.co.uk/news/uk-england-19254228 Sendname Address Phone for more info

[no subject]

Subject: RE: [v4 3/3] mmc: sdhci-cadence: Update PHY delay configuration In-reply-to:

[no subject]

Subject: RE: [v4 3/3] mmc: sdhci-cadence: Update PHY delay configuration In-reply-to: References: <1490008372-16372-1-git-send-email-pio...@cadence.com> <1490008855-27135-1-git-send-email-pio...@cadence.com> Hi Masahiro 2017-03-21 02:46 AM Masahiro Yamada : > Hi Piotr, >

[no subject]

auth 5ba8eedc subscribe linux-kernel ggirt...@gmail.com signature.asc Description: OpenPGP digital signature

[no subject]

auth 5ba8eedc subscribe linux-kernel ggirt...@gmail.com signature.asc Description: OpenPGP digital signature

[no subject]

Hello, My name is Jane from UK, I came across you email address online, I will like to know more about you , I have a very important reason of contacting you which, I'll tell you in my next mail. I wait for your reply

[no subject]

Hello, My name is Jane from UK, I came across you email address online, I will like to know more about you , I have a very important reason of contacting you which, I'll tell you in my next mail. I wait for your reply

Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

From febeb10887d5026a489658fd9e911656e76038ac Mon Sep 17 00:00:00 2001 From: Ajay Kaher <ajay.ka...@samsung.com> Date: Thu, 9 Mar 2017 16:07:54 +0530 Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultan

Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

From febeb10887d5026a489658fd9e911656e76038ac Mon Sep 17 00:00:00 2001 From: Ajay Kaher Date: Thu, 9 Mar 2017 16:07:54 +0530 Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously There is race condition when

Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Thu, Mar 09, 2017 at 11:34:25AM +, Ajay Kaher wrote: > From febeb10887d5026a489658fd9e911656e76038ac Mon Sep 17 00:00:00 2001 > From: Ajay Kaher <ajay.ka...@samsung.com> > Date: Thu, 9 Mar 2017 16:07:54 +0530 > Subject: [PATCH v4] USB:Core: BugFix: Proper handling of R

Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Thu, Mar 09, 2017 at 11:34:25AM +, Ajay Kaher wrote: > From febeb10887d5026a489658fd9e911656e76038ac Mon Sep 17 00:00:00 2001 > From: Ajay Kaher > Date: Thu, 9 Mar 2017 16:07:54 +0530 > Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when > two >

Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Tue, Mar 07, 2017 at 04:35:37AM +, Ajay Kaher wrote: >   >   >   > > On Fri, 3 Mar 2017, Ajay Kaher wrote: > >  > > > > usb_class->kref is not accessible outside the file.c > > > > as usb_class is _static_ inside the file.c and > > > > pointer of usb_class->kref is not passed anywhere. > >

Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Tue, Mar 07, 2017 at 04:35:37AM +, Ajay Kaher wrote: >   >   >   > > On Fri, 3 Mar 2017, Ajay Kaher wrote: > >  > > > > usb_class->kref is not accessible outside the file.c > > > > as usb_class is _static_ inside the file.c and > > > > pointer of usb_class->kref is not passed anywhere. > >

Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Tue, 7 Mar 2017, Ajay Kaher wrote: > > On Fri, 3 Mar 2017, Ajay Kaher wrote: > >  > > > > usb_class->kref is not accessible outside the file.c > > > > as usb_class is _static_ inside the file.c and > > > > pointer of usb_class->kref is not passed anywhere. > > > >  > > > > Hence as you wanted, 

Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Tue, 7 Mar 2017, Ajay Kaher wrote: > > On Fri, 3 Mar 2017, Ajay Kaher wrote: > >  > > > > usb_class->kref is not accessible outside the file.c > > > > as usb_class is _static_ inside the file.c and > > > > pointer of usb_class->kref is not passed anywhere. > > > >  > > > > Hence as you wanted, 

Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

      > On Fri, 3 Mar 2017, Ajay Kaher wrote: >  > > > usb_class->kref is not accessible outside the file.c > > > as usb_class is _static_ inside the file.c and > > > pointer of usb_class->kref is not passed anywhere. > > >  > > > Hence as you wanted, there are no references of usb_class->kref > > 

Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

      > On Fri, 3 Mar 2017, Ajay Kaher wrote: >  > > > usb_class->kref is not accessible outside the file.c > > > as usb_class is _static_ inside the file.c and > > > pointer of usb_class->kref is not passed anywhere. > > >  > > > Hence as you wanted, there are no references of usb_class->kref > > 

Re: FW: FW: RE: Re: FW: RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Fri, 3 Mar 2017, Ajay Kaher wrote: > > usb_class->kref is not accessible outside the file.c > > as usb_class is _static_ inside the file.c and > > pointer of usb_class->kref is not passed anywhere. > >  > > Hence as you wanted, there are no references of usb_class->kref > > other than taken by 

Re: FW: FW: RE: Re: FW: RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Fri, 3 Mar 2017, Ajay Kaher wrote: > > usb_class->kref is not accessible outside the file.c > > as usb_class is _static_ inside the file.c and > > pointer of usb_class->kref is not passed anywhere. > >  > > Hence as you wanted, there are no references of usb_class->kref > > other than taken by 

FW: FW: RE: Re: FW: RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

> On Thr, 2 Mar 2017, Ajay Kaher wrote: >> On Wed, 1 Mar 2017, Alan Stern wrote: >>> On Wed, 1 Mar 2017, Ajay Kaher wrote:  On Mon, 22 Feb 2017, Ajay Kaher wrote:   >  >> Alan, as per my understanding I have shifted the lock from >> release_usb_class() to destroy_usb_class() 

FW: FW: RE: Re: FW: RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

> On Thr, 2 Mar 2017, Ajay Kaher wrote: >> On Wed, 1 Mar 2017, Alan Stern wrote: >>> On Wed, 1 Mar 2017, Ajay Kaher wrote:  On Mon, 22 Feb 2017, Ajay Kaher wrote:   >  >> Alan, as per my understanding I have shifted the lock from >> release_usb_class() to destroy_usb_class() 

[no subject]

Congratulations, OXFAM Grants U.A.E have donated grant funds of $800,000 to you (Winning ID: OXF/DXB/02/034903) as the lucky recipient for this March 2017 regular social programme, please contact us for more information via this Email: oxfamgran...@gmail.com

[no subject]

Congratulations, OXFAM Grants U.A.E have donated grant funds of $800,000 to you (Winning ID: OXF/DXB/02/034903) as the lucky recipient for this March 2017 regular social programme, please contact us for more information via this Email: oxfamgran...@gmail.com

FW: RE: Re: FW: RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

> On Wed, 1 Mar 2017, Alan Stern wrote: >> On Wed, 1 Mar 2017, Ajay Kaher wrote: >>> On Mon, 22 Feb 2017, Ajay Kaher wrote: >>>    > Alan, as per my understanding I have shifted the lock from > release_usb_class() to destroy_usb_class() in patch v3.  > If it is not right, please 

FW: RE: Re: FW: RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

> On Wed, 1 Mar 2017, Alan Stern wrote: >> On Wed, 1 Mar 2017, Ajay Kaher wrote: >>> On Mon, 22 Feb 2017, Ajay Kaher wrote: >>>    > Alan, as per my understanding I have shifted the lock from > release_usb_class() to destroy_usb_class() in patch v3.  > If it is not right, please 

Re: FW: RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Wed, 1 Mar 2017, Ajay Kaher wrote: > > On Mon, 22 Feb 2017, Ajay Kaher wrote: > >  > >> On Mon, 20 Feb 2017, Ajay Kaher wrote: > >>  > >>> Alan, as per my understanding I have shifted the lock from > >>> release_usb_class() to destroy_usb_class() in patch v3.  > >>> If it is not right, please 

Re: FW: RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Wed, 1 Mar 2017, Ajay Kaher wrote: > > On Mon, 22 Feb 2017, Ajay Kaher wrote: > >  > >> On Mon, 20 Feb 2017, Ajay Kaher wrote: > >>  > >>> Alan, as per my understanding I have shifted the lock from > >>> release_usb_class() to destroy_usb_class() in patch v3.  > >>> If it is not right, please 

FW: RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

> On Mon, 22 Feb 2017, Ajay Kaher wrote: >  >> On Mon, 20 Feb 2017, Ajay Kaher wrote: >>  >>> Alan, as per my understanding I have shifted the lock from >>> release_usb_class() to destroy_usb_class() in patch v3.  >>> If it is not right, please explain in detail which race condition >>> I have 

FW: RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

> On Mon, 22 Feb 2017, Ajay Kaher wrote: >  >> On Mon, 20 Feb 2017, Ajay Kaher wrote: >>  >>> Alan, as per my understanding I have shifted the lock from >>> release_usb_class() to destroy_usb_class() in patch v3.  >>> If it is not right, please explain in detail which race condition >>> I have 

RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Tue, 21 Feb 2017, Alan Stern wrote:    > On Mon, 20 Feb 2017, Ajay Kaher wrote:   >> Alan, as per my understanding I have shifted the lock from >> release_usb_class() to destroy_usb_class() in patch v3.  >> If it is not right, please explain in detail which race condition >> I have missed and 

RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Tue, 21 Feb 2017, Alan Stern wrote:    > On Mon, 20 Feb 2017, Ajay Kaher wrote:   >> Alan, as per my understanding I have shifted the lock from >> release_usb_class() to destroy_usb_class() in patch v3.  >> If it is not right, please explain in detail which race condition >> I have missed and 

[no subject]

Sending both patches as series instead. Made the required changes as suggessted in earlier versions and fixed the warnings reported from kbuild test robot.

[no subject]

Sending both patches as series instead. Made the required changes as suggessted in earlier versions and fixed the warnings reported from kbuild test robot.

[no subject]

YOUR ATM CARD.pdf Description: Adobe PDF document

[no subject]

YOUR ATM CARD.pdf Description: Adobe PDF document

Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Mon, 20 Feb 2017, Ajay Kaher wrote: > Alan, as per my understanding I have shifted the lock from > release_usb_class() to destroy_usb_class() in patch v3. > If it is not right, please explain in detail which race condition > I have missed and also share your suggestions. > > thanks, > ajay

Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Mon, 20 Feb 2017, Ajay Kaher wrote: > Alan, as per my understanding I have shifted the lock from > release_usb_class() to destroy_usb_class() in patch v3. > If it is not right, please explain in detail which race condition > I have missed and also share your suggestions. > > thanks, > ajay

Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

  On Thu, 16 Feb 2017, Alan Stern wrote:  > On Thu, 16 Feb 2017, Ajay Kaher wrote: >  >> > On Thu, 14 Feb 2017, Alan Stern wrote: >> >  >> > I think Ajay's argument is correct and a patch is needed.  But this >> > patch misses the race between init_usb_class() and release_usb_class().   >>  >> 

Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

  On Thu, 16 Feb 2017, Alan Stern wrote:  > On Thu, 16 Feb 2017, Ajay Kaher wrote: >  >> > On Thu, 14 Feb 2017, Alan Stern wrote: >> >  >> > I think Ajay's argument is correct and a patch is needed.  But this >> > patch misses the race between init_usb_class() and release_usb_class().   >>  >> 

[no subject]

Good morning sir/madam, we are presently offering business and personal loans at low rates at Al Futtaim GE Finance for 2 percent per year and you are qualified to received the loan. if interested, send request now to: aeonthan...@gmail.com

[no subject]

Good morning sir/madam, we are presently offering business and personal loans at low rates at Al Futtaim GE Finance for 2 percent per year and you are qualified to received the loan. if interested, send request now to: aeonthan...@gmail.com

RE: RE: Re: Re: Re: Subject: [PATCH v2] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Thu, 16 Feb 2017, Ajay Kaher wrote: > > On Thu, 14 Feb 2017, Alan Stern wrote: > >  > > I think Ajay's argument is correct and a patch is needed.  But this > > patch misses the race between init_usb_class() and release_usb_class().   > > Thanks Alan for your comments, in patch v2 I have taken

<    5   6   7   8   9   10   11   12   13   14   >