{"push_id":599113285,"size":1000,"distinct_size":1,"ref":"refs/heads/android-exynos-3.4","head":"5cbf53aa6910676463ee49a4f6a001bfcbaa5209","before":"801e1de0316c0a62a4b07012de6f95562be1f926","commits":[{"sha":"a85550214614cd7e66d995592dbd54b14db50c01","author":{"email":"56ca982e301c39f713d7dc27488130819812afde@gmail.com","name":"Wang YanQing"},"message":"ALSA: HDA: Fix Oops caused by dereference NULL pointer\n\ncommit 2195b063f6609e4c6268f291683902f25eaf9aa6 upstream.\n\nThe interrupt handler azx_interrupt will call azx_update_rirb,\nwhich may call snd_hda_queue_unsol_event, snd_hda_queue_unsol_event\nwill dereference chip->bus pointer.\n\nThe problem is we alloc chip->bus in azx_codec_create\nwhich will be called after we enable IRQ and enable unsolicited\nevent in azx_probe.\n\nThis will cause Oops due dereference NULL pointer. I meet it, good luck:)\n\n[Rearranged the NULL check before the tracepoint and added another\n NULL check of bus->workq -- tiwai]\n\nSigned-off-by: Wang YanQing <udknight@gmail.com>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/ErcOne/kernel-3-4-projek-n7000/commits/a85550214614cd7e66d995592dbd54b14db50c01"},{"sha":"c89f6c7515b1713eebf62f67a48f9d6dcf5c3d94","author":{"email":"b8f9cab8be13de37b9588aedad10a20fc3a68783@trendmicro.com.cn","name":"Wei Yongjun"},"message":"dm snapshot: fix error return code in snapshot_ctr\n\ncommit 09e8b813897a0f85bb401435d009228644c81214 upstream.\n\nReturn -ENOMEM instead of success if unable to allocate pending\nexception mempool in snapshot_ctr.\n\nSigned-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>\nSigned-off-by: Alasdair G Kergon <agk@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/ErcOne/kernel-3-4-projek-n7000/commits/c89f6c7515b1713eebf62f67a48f9d6dcf5c3d94"},{"sha":"bca778136280b1ab9f2d23b94670ad5ba63c1f94","author":{"email":"51738506c1b2ccb0761f23bdc612c93babf738ea@redhat.com","name":"J. Bruce Fields"},"message":"nfsd4: don't allow owner override on 4.1 CLAIM_FH opens\n\ncommit 9f415eb25574db4b73a9a712a4438e41dc284922 upstream.\n\nThe Linux client is using CLAIM_FH to implement regular opens, not just\nrecovery cases, so it depends on the server to check permissions\ncorrectly.\n\nTherefore the owner override, which may make sense in the delegation\nrecovery case, isn't right in the CLAIM_FH case.\n\nSymptoms: on a client with 49f9a0fafd844c32f2abada047c0b9a5ba0d6255\n\"NFSv4.1: Enable open-by-filehandle\", Bryan noticed this:\n\n\ttouch test.txt\n\tchmod 000 test.txt\n\techo test > test.txt\n\nsucceeding.\n\nReported-by: Bryan Schumaker <bjschuma@netapp.com>\nSigned-off-by: J. Bruce Fields <bfields@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/ErcOne/kernel-3-4-projek-n7000/commits/bca778136280b1ab9f2d23b94670ad5ba63c1f94"},{"sha":"c43bab8955fbdcf7dab17cfd0fa5eab40b4ac88c","author":{"email":"f9cffb48774c5c540daacd974d14454046841468@hp.com","name":"Shuah Khan"},"message":"hp_accel: Ignore the error from lis3lv02d_poweron() at resume\n\ncommit 7783819920ca52fc582a2782f654fe6ed373f465 upstream.\n\nThe error in lis3lv02_poweron() is harmless in the resume path, so\nwe should ignore it. It is inline with the other usages of lis3lv02_poweron()\nand matches the 3.0 code for this routine. This patch is in suse git and\nmight have missed making it into the mainline.\nopensuse - commit id: 66ccdac87c322cf7af12bddba8c805af640b1cff\n\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Shuah Khan <shuah.khan@hp.com>\nSigned-off-by: Matthew Garrett <matthew.garrett@nebula.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/ErcOne/kernel-3-4-projek-n7000/commits/c43bab8955fbdcf7dab17cfd0fa5eab40b4ac88c"},{"sha":"5a95901e93b435c0ab9013704b9943d39aef7539","author":{"email":"da3a51b335cef0eb0e2c329c5ef6bcd6acef687a@oracle.com","name":"Konrad Rzeszutek Wilk"},"message":"xen/vcpu/pvhvm: Fix vcpu hotplugging hanging.\n\ncommit 7f1fc268c47491fd5e63548f6415fc8604e13003 upstream.\n\nIf a user did:\n\n\techo 0 > /sys/devices/system/cpu/cpu1/online\n\techo 1 > /sys/devices/system/cpu/cpu1/online\n\nwe would (this a build with DEBUG enabled) get to:\nsmpboot: ++++++++++++++++++++=_---CPU UP  1\n.. snip..\nsmpboot: Stack at about ffff880074c0ff44\nsmpboot: CPU1: has booted.\n\nand hang. The RCU mechanism would kick in an try to IPI the CPU1\nbut the IPIs (and all other interrupts) would never arrive at the\nCPU1. At first glance at least. A bit digging in the hypervisor\ntrace shows that (using xenanalyze):\n\n[vla] d4v1 vec 243 injecting\n   0.043163027 --|x d4v1 intr_window vec 243 src 5(vector) intr f3\n]  0.043163639 --|x d4v1 vmentry cycles 1468\n]  0.043164913 --|x d4v1 vmexit exit_reason PENDING_INTERRUPT eip ffffffff81673254\n   0.043164913 --|x d4v1 inj_virq vec 243  real\n  [vla] d4v1 vec 243 injecting\n   0.043164913 --|x d4v1 intr_window vec 243 src 5(vector) intr f3\n]  0.043165526 --|x d4v1 vmentry cycles 1472\n]  0.043166800 --|x d4v1 vmexit exit_reason PENDING_INTERRUPT eip ffffffff81673254\n   0.043166800 --|x d4v1 inj_virq vec 243  real\n  [vla] d4v1 vec 243 injecting\n\nthere is a pending event (subsequent debugging shows it is the IPI\nfrom the VCPU0 when smpboot.c on VCPU1 has done\n\"set_cpu_online(smp_processor_id(), true)\") and the guest VCPU1 is\ninterrupted with the callback IPI (0xf3 aka 243) which ends up calling\n__xen_evtchn_do_upcall.\n\nThe __xen_evtchn_do_upcall seems to do *something* but not acknowledge\nthe pending events. And the moment the guest does a 'cli' (that is the\nffffffff81673254 in the log above) the hypervisor is invoked again to\ninject the IPI (0xf3) to tell the guest it has pending interrupts.\nThis repeats itself forever.\n\nThe culprit was the per_cpu(xen_vcpu, cpu) pointer. At the bootup\nwe set each per_cpu(xen_vcpu, cpu) to point to the\nshared_info->vcpu_info[vcpu] but later on use the VCPUOP_register_vcpu_info\nto register per-CPU  structures (xen_vcpu_setup).\nThis is used to allow events for more than 32 VCPUs and for performance\noptimizations reasons.\n\nWhen the user performs the VCPU hotplug we end up calling the\nthe xen_vcpu_setup once more. We make the hypercall which returns\n-EINVAL as it does not allow multiple registration calls (and\nalready has re-assigned where the events are being set). We pick\nthe fallback case and set per_cpu(xen_vcpu, cpu) to point to the\nshared_info->vcpu_info[vcpu] (which is a good fallback during bootup).\nHowever the hypervisor is still setting events in the register\nper-cpu structure (per_cpu(xen_vcpu_info, cpu)).\n\nAs such when the events are set by the hypervisor (such as timer one),\nand when we iterate in __xen_evtchn_do_upcall we end up reading stale\nevents from the shared_info->vcpu_info[vcpu] instead of the\nper_cpu(xen_vcpu_info, cpu) structures. Hence we never acknowledge the\nevents that the hypervisor has set and the hypervisor keeps on reminding\nus to ack the events which we never do.\n\nThe fix is simple. Don't on the second time when xen_vcpu_setup is\ncalled over-write the per_cpu(xen_vcpu, cpu) if it points to\nper_cpu(xen_vcpu_info).\n\nAcked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>\nSigned-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/ErcOne/kernel-3-4-projek-n7000/commits/5a95901e93b435c0ab9013704b9943d39aef7539"},{"sha":"7c8b65e18db43c918ec3491e2712432d2a33f8a5","author":{"email":"1acebbdca565c7b6b638bdc23b58b5610d1a56b8@Parallels.com","name":"James Bottomley"},"message":"SCSI: sd: fix array cache flushing bug causing performance problems\n\ncommit 39c60a0948cc06139e2fbfe084f83cb7e7deae3b upstream.\n\nSome arrays synchronize their full non volatile cache when the sd driver sends\na SYNCHRONIZE CACHE command.  Unfortunately, they can have Terrabytes of this\nand we send a SYNCHRONIZE CACHE for every barrier if an array reports it has a\nwriteback cache.  This leads to massive slowdowns on journalled filesystems.\n\nThe fix is to allow userspace to turn off the writeback cache setting as a\ntemporary measure (i.e. without doing the MODE SELECT to write it back to the\ndevice), so even though the device reported it has a writeback cache, the\nuser, knowing that the cache is non volatile and all they care about is\nfilesystem correctness, can turn that bit off in the kernel and avoid the\nperformance ruinous (and safety irrelevant) SYNCHRONIZE CACHE commands.\n\nThe way you do this is add a 'temporary' prefix when performing the usual\ncache setting operations, so\n\necho temporary write through > /sys/class/scsi_disk/<disk>/cache_type\n\nReported-by: Ric Wheeler <rwheeler@redhat.com>\nSigned-off-by: James Bottomley <JBottomley@Parallels.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/ErcOne/kernel-3-4-projek-n7000/commits/7c8b65e18db43c918ec3491e2712432d2a33f8a5"},{"sha":"ad86524f948c1914dbd5bc460a5c6fd131ec054a","author":{"email":"14deb5e5e417133e888bf47bb6a3555c9bb7d81c@samba.org","name":"Anton Blanchard"},"message":"audit: Syscall rules are not applied to existing processes on non-x86\n\ncommit cdee3904b4ce7c03d1013ed6dd704b43ae7fc2e9 upstream.\n\nCommit b05d8447e782 (audit: inline audit_syscall_entry to reduce\nburden on archs) changed audit_syscall_entry to check for a dummy\ncontext before calling __audit_syscall_entry. Unfortunately the dummy\ncontext state is maintained in __audit_syscall_entry so once set it\nnever gets cleared, even if the audit rules change.\n\nAs a result, if there are no auditing rules when a process starts\nthen it will never be subject to any rules added later. x86 doesn't\nsee this because it has an assembly fast path that calls directly into\n__audit_syscall_entry.\n\nI noticed this issue when working on audit performance optimisations.\nI wrote a set of simple test cases available at:\n\nhttp://ozlabs.org/~anton/junkcode/audit_tests.tar.gz\n\n02_new_rule.py fails without the patch and passes with it. The\ntest case clears all rules, starts a process, adds a rule then\nverifies the process produces a syscall audit record.\n\nSigned-off-by: Anton Blanchard <anton@samba.org>\nSigned-off-by: Eric Paris <eparis@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/ErcOne/kernel-3-4-projek-n7000/commits/ad86524f948c1914dbd5bc460a5c6fd131ec054a"},{"sha":"ed032fd4d81041e4002fc55ff1832ee588f103da","author":{"email":"d39486eb2966c37bf9044df52de9fc6610151619@codeaurora.org","name":"Tirupathi Reddy"},"message":"timer: Don't reinitialize the cpu base lock during CPU_UP_PREPARE\n\ncommit 42a5cf46cd56f46267d2a9fcf2655f4078cd3042 upstream.\n\nAn inactive timer's base can refer to a offline cpu's base.\n\nIn the current code, cpu_base's lock is blindly reinitialized each\ntime a CPU is brought up. If a CPU is brought online during the period\nthat another thread is trying to modify an inactive timer on that CPU\nwith holding its timer base lock, then the lock will be reinitialized\nunder its feet. This leads to following SPIN_BUG().\n\n<0> BUG: spinlock already unlocked on CPU#3, kworker/u:3/1466\n<0> lock: 0xe3ebe000, .magic: dead4ead, .owner: kworker/u:3/1466, .owner_cpu: 1\n<4> [<c0013dc4>] (unwind_backtrace+0x0/0x11c) from [<c026e794>] (do_raw_spin_unlock+0x40/0xcc)\n<4> [<c026e794>] (do_raw_spin_unlock+0x40/0xcc) from [<c076c160>] (_raw_spin_unlock+0x8/0x30)\n<4> [<c076c160>] (_raw_spin_unlock+0x8/0x30) from [<c009b858>] (mod_timer+0x294/0x310)\n<4> [<c009b858>] (mod_timer+0x294/0x310) from [<c00a5e04>] (queue_delayed_work_on+0x104/0x120)\n<4> [<c00a5e04>] (queue_delayed_work_on+0x104/0x120) from [<c04eae00>] (sdhci_msm_bus_voting+0x88/0x9c)\n<4> [<c04eae00>] (sdhci_msm_bus_voting+0x88/0x9c) from [<c04d8780>] (sdhci_disable+0x40/0x48)\n<4> [<c04d8780>] (sdhci_disable+0x40/0x48) from [<c04bf300>] (mmc_release_host+0x4c/0xb0)\n<4> [<c04bf300>] (mmc_release_host+0x4c/0xb0) from [<c04c7aac>] (mmc_sd_detect+0x90/0xfc)\n<4> [<c04c7aac>] (mmc_sd_detect+0x90/0xfc) from [<c04c2504>] (mmc_rescan+0x7c/0x2c4)\n<4> [<c04c2504>] (mmc_rescan+0x7c/0x2c4) from [<c00a6a7c>] (process_one_work+0x27c/0x484)\n<4> [<c00a6a7c>] (process_one_work+0x27c/0x484) from [<c00a6e94>] (worker_thread+0x210/0x3b0)\n<4> [<c00a6e94>] (worker_thread+0x210/0x3b0) from [<c00aad9c>] (kthread+0x80/0x8c)\n<4> [<c00aad9c>] (kthread+0x80/0x8c) from [<c000ea80>] (kernel_thread_exit+0x0/0x8)\n\nAs an example, this particular crash occurred when CPU #3 is executing\nmod_timer() on an inactive timer whose base is refered to offlined CPU\n#2.  The code locked the timer_base corresponding to CPU #2. Before it\ncould proceed, CPU #2 came online and reinitialized the spinlock\ncorresponding to its base. Thus now CPU #3 held a lock which was\nreinitialized. When CPU #3 finally ended up unlocking the old cpu_base\ncorresponding to CPU #2, we hit the above SPIN_BUG().\n\nCPU #0\t\tCPU #3\t\t\t\t       CPU #2\n------\t\t-------\t\t\t\t       -------\n.....\t\t ......\t\t\t\t      <Offline>\n\t\tmod_timer()\n\t\t lock_timer_base\n\t\t   spin_lock_irqsave(&base->lock)\n\ncpu_up(2)\t .....\t\t\t\t        ......\n\t\t\t\t\t\t\tinit_timers_cpu()\n....\t\t .....\t\t\t\t    \tspin_lock_init(&base->lock)\n.....\t\t   spin_unlock_irqrestore(&base->lock)  ......\n\t\t   <spin_bug>\n\nAllocation of per_cpu timer vector bases is done only once under\n\"tvec_base_done[]\" check. In the current code, spinlock_initialization\nof base->lock isn't under this check. When a CPU is up each time the\nbase lock is reinitialized. Move base spinlock initialization under\nthe check.\n\nSigned-off-by: Tirupathi Reddy <tirupath@codeaurora.org>\nLink: http://lkml.kernel.org/r/1368520142-4136-1-git-send-email-tirupath@codeaurora.org\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/ErcOne/kernel-3-4-projek-n7000/commits/ed032fd4d81041e4002fc55ff1832ee588f103da"},{"sha":"33b7cfcb34b4ae37cde7a8a1c97c9be27677e931","author":{"email":"00e4cf8f46a57000a44449bf9dd8cbbcc209fd2a@linutronix.de","name":"Thomas Gleixner"},"message":"tick: Cleanup NOHZ per cpu data on cpu down\n\ncommit 4b0c0f294f60abcdd20994a8341a95c8ac5eeb96 upstream.\n\nPrarit reported a crash on CPU offline/online. The reason is that on\nCPU down the NOHZ related per cpu data of the dead cpu is not cleaned\nup. If at cpu online an interrupt happens before the per cpu tick\ndevice is registered the irq_enter() check potentially sees stale data\nand dereferences a NULL pointer.\n\nCleanup the data after the cpu is dead.\n\nReported-by: Prarit Bhargava <prarit@redhat.com>\nCc: Mike Galbraith <bitbucket@online.de>\nLink: http://lkml.kernel.org/r/alpine.LFD.2.02.1305031451561.2886@ionos\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/ErcOne/kernel-3-4-projek-n7000/commits/33b7cfcb34b4ae37cde7a8a1c97c9be27677e931"},{"sha":"cba998b9b3799a5d6861a969d7b7d9b4f4f181f6","author":{"email":"43232e92d70cc7aa53504ad0397085ee47bad87f@goodmis.org","name":"Steven Rostedt (Red Hat)"},"message":"tracing: Fix leaks of filter preds\n\ncommit 60705c89460fdc7227f2d153b68b3f34814738a4 upstream.\n\nSpecial preds are created when folding a series of preds that\ncan be done in serial. These are allocated in an ops field of\nthe pred structure. But they were never freed, causing memory\nleaks.\n\nThis was discovered using the kmemleak checker:\n\nunreferenced object 0xffff8800797fd5e0 (size 32):\n  comm \"swapper/0\", pid 1, jiffies 4294690605 (age 104.608s)\n  hex dump (first 32 bytes):\n    00 00 01 00 03 00 05 00 07 00 09 00 0b 00 0d 00  ................\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [<ffffffff814b52af>] kmemleak_alloc+0x73/0x98\n    [<ffffffff8111ff84>] kmemleak_alloc_recursive.constprop.42+0x16/0x18\n    [<ffffffff81120e68>] __kmalloc+0xd7/0x125\n    [<ffffffff810d47eb>] kcalloc.constprop.24+0x2d/0x2f\n    [<ffffffff810d4896>] fold_pred_tree_cb+0xa9/0xf4\n    [<ffffffff810d3781>] walk_pred_tree+0x47/0xcc\n    [<ffffffff810d5030>] replace_preds.isra.20+0x6f8/0x72f\n    [<ffffffff810d50b5>] create_filter+0x4e/0x8b\n    [<ffffffff81b1c30d>] ftrace_test_event_filter+0x5a/0x155\n    [<ffffffff8100028d>] do_one_initcall+0xa0/0x137\n    [<ffffffff81afbedf>] kernel_init_freeable+0x14d/0x1dc\n    [<ffffffff814b24b7>] kernel_init+0xe/0xdb\n    [<ffffffff814d539c>] ret_from_fork+0x7c/0xb0\n    [<ffffffffffffffff>] 0xffffffffffffffff\n\nSigned-off-by: Steven Rostedt <rostedt@goodmis.org>\nCc: Tom Zanussi <tzanussi@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/ErcOne/kernel-3-4-projek-n7000/commits/cba998b9b3799a5d6861a969d7b7d9b4f4f181f6"},{"sha":"d556c9b5a98ceee8b1d1d74d7277141da437bc26","author":{"email":"ff9e869555c1bbba9d4ec165450acb53740323ed@redhat.com","name":"Lachlan McIlroy"},"message":"ext4: limit group search loop for non-extent files\n\ncommit e6155736ad76b2070652745f9e54cdea3f0d8567 upstream.\n\nIn the case where we are allocating for a non-extent file,\nwe must limit the groups we allocate from to those below\n2^32 blocks, and ext4_mb_regular_allocator() attempts to\ndo this initially by putting a cap on ngroups for the\nsubsequent search loop.\n\nHowever, the initial target group comes in from the\nallocation context (ac), and it may already be beyond\nthe artificially limited ngroups.  In this case,\nthe limit\n\n\tif (group == ngroups)\n\t\tgroup = 0;\n\nat the top of the loop is never true, and the loop will\nrun away.\n\nCatch this case inside the loop and reset the search to\nstart at group 0.\n\n[sandeen@redhat.com: add commit msg & comments]\n\nSigned-off-by: Lachlan McIlroy <lmcilroy@redhat.com>\nSigned-off-by: Eric Sandeen <sandeen@redhat.com>\nSigned-off-by: \"Theodore Ts'o\" <tytso@mit.edu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/ErcOne/kernel-3-4-projek-n7000/commits/d556c9b5a98ceee8b1d1d74d7277141da437bc26"},{"sha":"36d1c0c62aca74313a95f71c180c73a2eda80ea9","author":{"email":"3915fb8377205924ccc3120e302501c7a259dd7e@linux.vnet.ibm.com","name":"Robert Jennings"},"message":"powerpc: Bring all threads online prior to migration/hibernation\n\ncommit 120496ac2d2d60aee68d3123a68169502a85f4b5 upstream.\n\nThis patch brings online all threads which are present but not online\nprior to migration/hibernation.  After migration/hibernation those\nthreads are taken back offline.\n\nDuring migration/hibernation all online CPUs must call H_JOIN, this is\nrequired by the hypervisor.  Without this patch, threads that are offline\n(H_CEDE'd) will not be woken to make the H_JOIN call and the OS will be\ndeadlocked (all threads either JOIN'd or CEDE'd).\n\nSigned-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>\nSigned-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/ErcOne/kernel-3-4-projek-n7000/commits/36d1c0c62aca74313a95f71c180c73a2eda80ea9"},{"sha":"48633a6011b0bcbf2bf5a4071a5a55a4a3b45a94","author":{"email":"118ed6118e893d16e8c6e0776e0ebc290952c897@openwrt.org","name":"Felix Fietkau"},"message":"ath9k: fix key allocation error handling for powersave keys\n\ncommit 4ef69d0394cba8caa9f75d3f2e53429bfb8b3045 upstream.\n\nIf no keycache slots are available, ath_key_config can return -ENOSPC.\nIf the key index is not checked for errors, it can lead to logspam that\nlooks like this: \"ath: wiphy0: keyreset: keycache entry 228 out of range\"\nThis can cause follow-up errors if the invalid keycache index gets\nused for tx.\n\nSigned-off-by: Felix Fietkau <nbd@openwrt.org>\nSigned-off-by: John W. Linville <linville@tuxdriver.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/ErcOne/kernel-3-4-projek-n7000/commits/48633a6011b0bcbf2bf5a4071a5a55a4a3b45a94"},{"sha":"4f68f0ba1c85d66c3f8665c59a007971ad11adc1","author":{"email":"abbaae6378dda6b8d65fe6bd0f8beb334a5e4c4f@marvell.com","name":"Bing Zhao"},"message":"mwifiex: clear is_suspended flag when interrupt is received early\n\ncommit 48795424acff7215d5eac0b52793a2c1eb3a6283 upstream.\n\nWhen the XO-4 with 8787 wireless is woken up due to wake-on-WLAN\nmwifiex is often flooded with \"not allowed while suspended\" messages\nand the interface is unusable.\n\n[  202.171609] int: sdio_ireg = 0x1\n[  202.180700] info: mwifiex_process_hs_config: auto cancelling host\n               sleep since there is interrupt from the firmware\n[  202.201880] event: wakeup device...\n[  202.211452] event: hs_deactivated\n[  202.514638] info: --- Rx: Data packet ---\n[  202.514753] data: 4294957544 BSS(0-0): Data <= kernel\n[  202.514825] PREP_CMD: device in suspended state\n[  202.514839] data: dequeuing the packet ec7248c0 ec4869c0\n[  202.514886] mwifiex_write_data_sync: not allowed while suspended\n[  202.514886] host_to_card, write iomem (1) failed: -1\n[  202.514917] mwifiex_write_data_sync: not allowed while suspended\n[  202.514936] host_to_card, write iomem (2) failed: -1\n[  202.514949] mwifiex_write_data_sync: not allowed while suspended\n[  202.514965] host_to_card, write iomem (3) failed: -1\n[  202.514976] mwifiex_write_data_async failed: 0xFFFFFFFF\n\nThis can be readily reproduced when putting the XO-4 in a loop where\nit goes to sleep due to inactivity, but then wakes up due to an\nincoming ping. The error is hit within an hour or two.\n\nThis issue happens when an interrupt comes in early while host sleep\nis still activated. Driver handles this case by auto cancelling host\nsleep. However is_suspended flag is still set which prevents any cmd\nor data from being sent to firmware. Fix it by clearing is_suspended\nflag in this path.\n\nReported-by: Daniel Drake <dsd@laptop.org>\nTested-by: Daniel Drake <dsd@laptop.org>\nSigned-off-by: Bing Zhao <bzhao@marvell.com>\nSigned-off-by: John W. Linville <linville@tuxdriver.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/ErcOne/kernel-3-4-projek-n7000/commits/4f68f0ba1c85d66c3f8665c59a007971ad11adc1"},{"sha":"2969620bf1452ec310fdcbf0d5a567627d0f5c74","author":{"email":"83b0c3d63e8a11eb6e40077030b59e95bfe31ffa@laptop.org","name":"Daniel Drake"},"message":"mwifiex: fix setting of multicast filter\n\ncommit ccd384b10420ac81ba3fb9b0a7d18272c7173552 upstream.\n\nA small bug in this code was causing the ALLMULTI filter to be set\nwhen in fact we were just wanting to program a selective multicast list\nto the hardware.\n\nFix that bug and remove a redundant if condition in the code that\nfollows.\n\nThis fixes wakeup behaviour when multicast WOL is enabled. Previously,\nall multicast packets would wake up the system. Now, only those that the\nhost intended to receive trigger wakeups.\n\nSigned-off-by: Daniel Drake <dsd@laptop.org>\nAcked-by: Bing Zhao <bzhao@marvell.com>\nSigned-off-by: John W. Linville <linville@tuxdriver.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/ErcOne/kernel-3-4-projek-n7000/commits/2969620bf1452ec310fdcbf0d5a567627d0f5c74"},{"sha":"5219d3dd6f96a7640929307a2344d9905cdf6b2c","author":{"email":"22f02d77e3d63643bb259e2f6ed89ea953cbe348@gmail.com","name":"Thommy Jakobsson"},"message":"B43: Handle DMA RX descriptor underrun\n\ncommit 73b82bf0bfbf58e6ff328d3726934370585f6e78 upstream.\n\nAdd handling of rx descriptor underflow. This fixes a fault that could\nhappen on slow machines, where data is received faster than the CPU can\nhandle. In such a case the device will use up all rx descriptors and\nrefuse to send any more data before confirming that it is ok. This\npatch enables necessary interrupt to discover such a situation and will\nhandle them by dropping everything in the ring buffer.\n\nReviewed-by: Michael Buesch <m@bues.ch>\nSigned-off-by: Thommy Jakobsson <thommyj@gmail.com>\nSigned-off-by: John W. Linville <linville@tuxdriver.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/ErcOne/kernel-3-4-projek-n7000/commits/5219d3dd6f96a7640929307a2344d9905cdf6b2c"},{"sha":"25853a12e468fa75e82fca7208f03ad4c879f95f","author":{"email":"c1b6782c4af8f0673da8923a0702a1832e5940f4@ffwll.ch","name":"Daniel Vetter"},"message":"drm/mm: fix dump table BUG\n\ncommit 3a359f0b21ab218c1bf7a6a1b638b6fd143d0b99 upstream.\n\nIn\n\ncommit 9e8944ab564f2e3dde90a518cd32048c58918608\nAuthor: Chris Wilson <chris@chris-wilson.co.uk>\nDate:   Thu Nov 15 11:32:17 2012 +0000\n\n    drm: Introduce an iterator over holes in the drm_mm range manager\n\nhelpers and iterators for hole handling have been introduced with some\ndebug BUG_ONs sprinkled over. Unfortunately this broke the mm dumper\nwhich unconditionally tried to compute the size of the very first\nhole.\n\nWhile at it unify the code a bit with the hole dumping in the loop.\n\nv2: Extract a hole dump helper.\n\nReported-by: Christopher Harvey <charvey@matrox.com>\nCc: Christopher Harvey <charvey@matrox.com>\nCc: Dave Airlie <airlied@redhat.com>\nCc: Chris Wilson <chris@chris-wilson.co.uk>\nAcked-by: Dave Airlie <airlied@redhat.com>\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/ErcOne/kernel-3-4-projek-n7000/commits/25853a12e468fa75e82fca7208f03ad4c879f95f"},{"sha":"8ed87e67b0065b56379b8c5f560c211efaa9a210","author":{"email":"8a2957e0063f2abf61bd145b6236a74a3708ac54@mork.no","name":"Bjørn Mork"},"message":"net: qmi_wwan: fixup missing ethernet header (firmware bug workaround)\n\n[ Upstream commit 6ff509af3869ccac69dcf8905fc75b9a76951594 ]\n\nA number of LTE devices from different vendors all suffer from the\nsame firmware bug: Most of the packets received from the device while\nit is attached to a LTE network will not have an ethernet header. The\ndevices work as expected when attached to 2G or 3G networks, sending\nan ethernet header with all packets.\n\nThis driver is not aware of which network the modem attached to, and\neven if it were there are still some packet types which are always\nreceived with the header intact.\n\nAll devices supported by this driver have severely limited\nnetworking capabilities:\n - can only transmit IPv4, IPv6 and possibly ARP\n - can only support a single host hardware address at any time\n - will only do point-to-point communcation with the host\n\nBecause of this, we are able to reliably identify any bogus raw IP\npackets by simply looking at the 4 IP version bits.  All we need to\ndo is to avoid 4 or 6 in the first digit of the mac address.  This\nworkaround ensures this, and fix up the received packets as necessary.\n\nGiven the distribution of the bug, it is believed that the source is\nthe chipset vendor.  The devices which are verified to be affected are:\n Huawei E392u-12 (Qualcomm MDM9200)\n Pantech UML290  (Qualcomm MDM9600)\n Novatel USB551L (Qualcomm MDM9600)\n Novatel E362    (Qualcomm MDM9600)\n\nIt is believed that the bug depend on firmware revision, which means\nthat possibly all devices based on the above mentioned chipset may be\naffected if we consider all available firmware revisions.\n\nThe information about affected devices and versions is likely\nincomplete.  As the additional overhead for packets not needing this\nfixup is very small, it is considered acceptable to apply the\nworkaround to all devices handled by this driver.\n\nReported-by: Dan Williams <dcbw@redhat.com>\nSigned-off-by: Bjørn Mork <bjorn@mork.no>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/ErcOne/kernel-3-4-projek-n7000/commits/8ed87e67b0065b56379b8c5f560c211efaa9a210"},{"sha":"d8abf422282e2452c83392717481ad850b0d982c","author":{"email":"8a2957e0063f2abf61bd145b6236a74a3708ac54@mork.no","name":"Bjørn Mork"},"message":"net: qmi_wwan: fixup destination address (firmware bug workaround)\n\n[ Upstream commit 6483bdc9d76fb98174797516a19d289eb837909e ]\n\nReceived packets are sometimes addressed to 00:a0:c6:00:00:00\ninstead of the address the device firmware should have learned\nfrom the host:\n\n321.224126 77.16.85.204 -> 148.122.171.134 ICMP 98 Echo (ping) request  id=0x4025, seq=64/16384, ttl=64\n\n0000  82 c0 82 c9 f1 67 82 c0 82 c9 f1 67 08 00 45 00   .....g.....g..E.\n0010  00 54 00 00 40 00 40 01 57 cc 4d 10 55 cc 94 7a   .T..@.@.W.M.U..z\n0020  ab 86 08 00 62 fc 40 25 00 40 b2 bc 6e 51 00 00   ....b.@%.@..nQ..\n0030  00 00 6b bd 09 00 00 00 00 00 10 11 12 13 14 15   ..k.............\n0040  16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25   .......... !\"#$%\n0050  26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35   &'()*+,-./012345\n0060  36 37                                             67\n\n321.240607 148.122.171.134 -> 77.16.85.204 ICMP 98 Echo (ping) reply    id=0x4025, seq=64/16384, ttl=55\n\n0000  00 a0 c6 00 00 00 02 50 f3 00 00 00 08 00 45 00   .......P......E.\n0010  00 54 00 56 00 00 37 01 a0 76 94 7a ab 86 4d 10   .T.V..7..v.z..M.\n0020  55 cc 00 00 6a fc 40 25 00 40 b2 bc 6e 51 00 00   U...j.@%.@..nQ..\n0030  00 00 6b bd 09 00 00 00 00 00 10 11 12 13 14 15   ..k.............\n0040  16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25   .......... !\"#$%\n0050  26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35   &'()*+,-./012345\n0060  36 37                                             67\n\nThe bogus address is always the same, and matches the address\nsuggested by many devices as a default address.  It is likely a\nhardcoded firmware default.\n\nThe circumstances where this bug has been observed indicates that\nthe trigger is related to timing or some other factor the host\ncannot control. Repeating the exact same configuration sequence\nthat caused it to trigger once, will not necessarily cause it to\ntrigger the next time. Reproducing the bug is therefore difficult.\nThis opens up a possibility that the bug is more common than we can\nconfirm, because affected devices often will work properly again\nafter a reset.  A procedure most users are likely to try out before\nreporting a bug.\n\nUnconditionally rewriting the destination address if the first digit\nof the received packet is 0, is considered an acceptable compromise\nsince we already have to inspect this digit.  The simplification will\ncause unnecessary rewrites if the real address starts with 0, but this\nis still better than adding additional tests for this particular case.\n\nSigned-off-by: Bjørn Mork <bjorn@mork.no>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/ErcOne/kernel-3-4-projek-n7000/commits/d8abf422282e2452c83392717481ad850b0d982c"},{"sha":"1203d9c66e6b892bd8043eea51c5cd510d097266","author":{"email":"8a2957e0063f2abf61bd145b6236a74a3708ac54@mork.no","name":"Bjørn Mork"},"message":"net: qmi_wwan: prevent duplicate mac address on link (firmware bug workaround)\n\n[ Upstream commit cc6ba5fdaabea7a7b28de3ba1e0fe54d92232fe5 ]\n\nWe normally trust and use the CDC functional descriptors provided by a\nnumber of devices.  But some of these will erroneously list the address\nreserved for the device end of the link.  Attempting to use this on\nboth the device and host side will naturally not work.\n\nWork around this bug by ignoring the functional descriptor and assign a\nrandom address instead in this case.\n\nSigned-off-by: Bjørn Mork <bjorn@mork.no>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/ErcOne/kernel-3-4-projek-n7000/commits/1203d9c66e6b892bd8043eea51c5cd510d097266"}]}