Re: Contact Me For This Deal
Good Day, I work as a clerk in Zenith Bank here in Canada, I have a very confidential Business Proposition for you. There is a said amount of money ($6.2 Million USD) floating in the bank unclaimed, belonging to the bank Foreign customer (Mr. James Ibori) a former Governor from Africa who is serving jail term in the United Kingdom for case of Money laundering, see news: https://www.bbc.com/news/uk-38395396 ,about the jailed former Governor We seek your good collaboration to move the funds out for our benefit. we have agreed that 15% be yours once you help claim it, if you are willing do get back to me with the following: (1) Your Full Name: (2) Residential Address: (3) Phone, Mobile: (4) Scan Copy of Your ID: So we can prepare necessary documents presenting you as the rightful beneficiary of the fund for easy claim. You dont need to worry over anything as a staff of the bank i and my colleague have worked out good plans to exercute the transfer, you will only receive said funds and keep it safe, while i come over to your place so we can split the proceed as agreed. Waiting your kind response. Regards Mrs. Sachin G. Grams ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: ks7010: Do not use GFP_KERNEL in atomic context
On Sun, Aug 09, 2020 at 01:18:46PM +0200, Christophe JAILLET wrote: > A possible call chain is as follow: > ks_wlan_start_xmit(ks_wlan_net.c) > --> hostif_data_request (ks_hostif.c) > --> michael_mic (ks_hostif.c) > > 'ks_wlan_start_xmit()' is a '.ndo_start_xmit()' function (see > net_device_ops structure). Such calls are guarded by the __netif_tx_lock > spinlock. So memory allocation must be atomic. > > So, use GFP_ATOMIC instead of GFP_KERNEL 'in michael_mic()' > > Fixes: ??? > Signed-off-by: Christophe JAILLET > --- > This is completely speculative. I don't know if the call chain given above > if possible in RL application. > So review carefully :) > > If the fix is correct, it is also more the starting point of a bigger > change, because in 'michael_mic()' there is a call to > 'crypto_alloc_shash()' and this function uses GFP_KERNEL internally (in > 'crypto_create_tfm()') > Should this need to be changed, I don't know how 'ks_hostif.c' should be > fixed. Changing allocation in 'crypto/api.c' looks like an overkill. > > In other word, I think that my patch is wrong, but don't know what else to > propose :). Your patch is correct but you're also right that it's incomplete. If you look at drivers/staging/rtl8192e/rtllib_crypt_tkip.c then they declare the shash on stack instead of using crypto_alloc_shash(). SHASH_DESC_ON_STACK(desc, tfm_michael); That's probably what we should do here as well. Although I don't know this code very well at all... This is probably the sort of change where it would be good to have someone test it. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/3] Modernize tasklet callback API
Kees, > > > > Here's the series re-based on top of 5.8 > https://github.com/allenpais/tasklets/tree/V3 > > Let me know how you would want these to be reviewed. > I see the first set of infrastructure patches for tasklets have landed in Linus's tree. Good time to send out the ~200 patches? - Allen ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re:waiting...00
Hello,
My name is Ms. Reem Ebrahim Al-Hashimi, I am the "Minister of state and
Petroleum" also "Minister of State for International Cooperation" in UAE. I
write to you on behalf of my other "three (3) colleagues" who has approved me
to solicit for your "partnership in claiming of {us$90=Million}" from a
Financial Home in Cambodia on their behalf and for our "Mutual Benefits".
The Fund {us$90=Million} is our share from the (Over-invoiced) Oil/Gas deal
with Cambodian/Vietnam Government within 2013/2014, however, We don't want our
government to know about the fund. If this proposal interests you, let me know,
by sending me an email and I will send to you detailed information on how this
business would be successfully transacted. Be informed that nobody knows about
the secret of this fund except us, and we know how to carry out the entire
transaction. So I am compelled to ask, that you will stand on our behalf and
receive this fund into any account that is solely controlled by you.
We will compensate you with 30% of the total amount involved as gratification
for being our partner in this transaction. Reply to my private email as stated:
reemal-hash...@yandex.com
Regards,
Ms. Reem Ebrahim Al-Hashimi.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Product Inquiry
Dear Sir/ Madam Do you export your product, if yes? send us your export list or Catalog. We want to purchase your product, what is your MOQ. Your quick response would be appreciated. Best regards, Miss Maria Gonzales Jangosh Group LLC (Purchasing Manager) For the Company. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1] staging: greybus: audio: fix uninitialized value issue
On Mon, Aug 10, 2020 at 8:34 PM Dan Carpenter wrote:
>
> On Thu, Aug 06, 2020 at 09:51:57PM +0530, Vaibhav Agarwal wrote:
> > diff --git a/drivers/staging/greybus/audio_topology.c
> > b/drivers/staging/greybus/audio_topology.c
> > index 2f9fdbdcd547..4b914d0edef2 100644
> > --- a/drivers/staging/greybus/audio_topology.c
> > +++ b/drivers/staging/greybus/audio_topology.c
> > @@ -456,6 +456,13 @@ static int gbcodec_mixer_dapm_ctl_put(struct
> > snd_kcontrol *kcontrol,
> > val = ucontrol->value.integer.value[0] & mask;
> > connect = !!val;
> >
> > + ret = gb_pm_runtime_get_sync(bundle);
> > + if (ret)
> > + return ret;
> > +
> > + ret = gb_audio_gb_get_control(module->mgmt_connection, data->ctl_id,
> > + GB_AUDIO_INVALID_INDEX, &gbvalue);
>
>
> We need to check "ret" after this.
Oops, my bad. Thanks Dan for reporting this. I'll share an updated patch soon.
--
regards,
vaibhav
>
> > +
> > /* update ucontrol */
> > if (gbvalue.value.integer_value[0] != val) {
> > for (wi = 0; wi < wlist->num_widgets; wi++) {
> > @@ -466,16 +473,10 @@ static int gbcodec_mixer_dapm_ctl_put(struct
> > snd_kcontrol *kcontrol,
>
> regards,
> dan carpenter
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/3] Modernize tasklet callback API
On Mon, Aug 03, 2020 at 02:16:15PM +0530, Allen wrote: > Here's the series re-based on top of 5.8 > https://github.com/allenpais/tasklets/tree/V3 Great! > Let me know how you would want these to be reviewed. Was a Coccinelle script used for any of these conversions? I wonder if it'd be easier to do a single treewide patch for the more mechanical changes. And, actually, I still think the "prepare" patches should just be collapsed into the actual "covert" patches -- there are only a few. After those, yeah, I think getting these sent to their respective maintainers is the next step. > Also, I was thinking if removing tasklets completely could be a task > on KSPP wiki. If yes, I did like to take ownership of that task. I have a > couple of ideas in mind, which could be discussed in a separate email. Sure! I will add it to the tracker. Here's for the refactoring: https://github.com/KSPP/linux/issues/30 and here's for the removal: https://github.com/KSPP/linux/issues/94 if you can added details/examples of how they should be removed, that'd help other folks too, if they wanted to jump in. :) -Kees -- Kees Cook ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[driver-core:readfile] BUILD SUCCESS 06a33eb9d1f72eed76456bda98a363bffdc4364d
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git readfile branch HEAD: 06a33eb9d1f72eed76456bda98a363bffdc4364d readfile.2: new page describing readfile(2) elapsed time: 721m configs tested: 65 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig mipsqi_lb60_defconfig m68k sun3x_defconfig m68k sun3_defconfig powerpc skiroot_defconfig sh sh7710voipgw_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a005-20200811 i386 randconfig-a001-20200811 i386 randconfig-a002-20200811 i386 randconfig-a003-20200811 i386 randconfig-a006-20200811 i386 randconfig-a004-20200811 x86_64 randconfig-a006-20200811 x86_64 randconfig-a001-20200811 x86_64 randconfig-a003-20200811 x86_64 randconfig-a005-20200811 x86_64 randconfig-a004-20200811 x86_64 randconfig-a002-20200811 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[driver-core:debugfs_cleanup] BUILD SUCCESS 2ca2ccfc6adaa96762a87ecbc36359bc40e72088
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git debugfs_cleanup branch HEAD: 2ca2ccfc6adaa96762a87ecbc36359bc40e72088 debugfs: remove return value of debugfs_create_devm_seqfile() elapsed time: 721m configs tested: 48 configs skipped: 1 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/3] Modernize tasklet callback API
On Tue, 11 Aug 2020 23:33:13 +0200, Kees Cook wrote: > > On Mon, Aug 03, 2020 at 02:16:15PM +0530, Allen wrote: > > Here's the series re-based on top of 5.8 > > https://github.com/allenpais/tasklets/tree/V3 > > Great! > > > Let me know how you would want these to be reviewed. > > Was a Coccinelle script used for any of these conversions? I wonder if > it'd be easier to do a single treewide patch for the more mechanical > changes. > > And, actually, I still think the "prepare" patches should just be > collapsed into the actual "covert" patches -- there are only a few. > > After those, yeah, I think getting these sent to their respective > maintainers is the next step. > > > Also, I was thinking if removing tasklets completely could be a task > > on KSPP wiki. If yes, I did like to take ownership of that task. I have a > > couple of ideas in mind, which could be discussed in a separate email. > > Sure! I will add it to the tracker. Here's for the refactoring: > https://github.com/KSPP/linux/issues/30 > > and here's for the removal: > https://github.com/KSPP/linux/issues/94 > > if you can added details/examples of how they should be removed, that'd > help other folks too, if they wanted to jump in. :) I have a patch set to convert the remaining tasklet usage in sound drivers to either the threaded IRQ or the work, but it wasn't submitted / merged for 5.8 due to the obvious conflict with your API changes. Each conversion is rather simple, but it's always a question of the nature of each tasklet usage which alternative is the best fit. FWIW, the current version is found in test/kill-tasklet branch of sound git tree git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git thanks, Takashi ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
