{"push_id":664442163,"size":328,"distinct_size":328,"ref":"refs/heads/linux","head":"d068aa78e23d3bc03646e2beeb53761bf7d6b90a","before":"d461e25981294234a32880a9b72b527657ce9e1e","commits":[{"sha":"84b12335e90a2dff90ac2b2c95fd7503ee2529f3","author":{"email":"46870ccd9486ced5844a21b823ddb0e89874ecb6@fogrefinery.com","name":"Eldad Zack"},"message":"ALSA: usb-audio: fix endianness bug in snd_nativeinstruments_*\n\ncommit 889d66848b12d891248b03abcb2a42047f8e172a upstream.\n\nThe usb_control_msg() function expects __u16 types and performs\nthe endianness conversions by itself.\nHowever, in three places, a conversion is performed before it is\nhanded over to usb_control_msg(), which leads to a double conversion\n(= no conversion):\n* snd_usb_nativeinstruments_boot_quirk()\n* snd_nativeinstruments_control_get()\n* snd_nativeinstruments_control_put()\n\nCaught by sparse:\n\nsound/usb/mixer_quirks.c:512:38: warning: incorrect type in argument 6 (different base types)\nsound/usb/mixer_quirks.c:512:38:    expected unsigned short [unsigned] [usertype] index\nsound/usb/mixer_quirks.c:512:38:    got restricted __le16 [usertype] <noident>\nsound/usb/mixer_quirks.c:543:35: warning: incorrect type in argument 5 (different base types)\nsound/usb/mixer_quirks.c:543:35:    expected unsigned short [unsigned] [usertype] value\nsound/usb/mixer_quirks.c:543:35:    got restricted __le16 [usertype] <noident>\nsound/usb/mixer_quirks.c:543:56: warning: incorrect type in argument 6 (different base types)\nsound/usb/mixer_quirks.c:543:56:    expected unsigned short [unsigned] [usertype] index\nsound/usb/mixer_quirks.c:543:56:    got restricted __le16 [usertype] <noident>\nsound/usb/quirks.c:502:35: warning: incorrect type in argument 5 (different base types)\nsound/usb/quirks.c:502:35:    expected unsigned short [unsigned] [usertype] value\nsound/usb/quirks.c:502:35:    got restricted __le16 [usertype] <noident>\n\nSigned-off-by: Eldad Zack <eldad@fogrefinery.com>\nAcked-by: Daniel Mack <zonque@gmail.com>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/jollaman999/jolla-kernel_G_Gen3/commits/84b12335e90a2dff90ac2b2c95fd7503ee2529f3"},{"sha":"bf0905cb427cb0b8f46641826e0fda6bba36ad41","author":{"email":"825cb1d71292b66c34fe6b2f34d0838d6f1a9969@avionic-design.de","name":"Alban Bedel"},"message":"ASoC: wm8903: Fix the bypass to HP/LINEOUT when no DAC or ADC is running\n\ncommit f1ca493b0b5e8f42d3b2dc8877860db2983f47b6 upstream.\n\nThe Charge Pump needs the DSP clock to work properly, without it the\nbypass to HP/LINEOUT is not working properly. This requirement is not\nmentioned in the datasheet but has been confirmed by Mark Brown from\nWolfson.\n\nSigned-off-by: Alban Bedel <alban.bedel@avionic-design.de>\nSigned-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/jollaman999/jolla-kernel_G_Gen3/commits/bf0905cb427cb0b8f46641826e0fda6bba36ad41"},{"sha":"67dd6bd0126e76476b5e0b7d5d0495c6494fecc8","author":{"email":"1b20bcb62cf1b100c528e605608922000dc2fc80@lge.com","name":"Namhyung Kim"},"message":"tracing: Fix double free when function profile init failed\n\ncommit 83e03b3fe4daffdebbb42151d5410d730ae50bd1 upstream.\n\nOn the failure path, stat->start and stat->pages will refer same page.\nSo it'll attempt to free the same page again and get kernel panic.\n\nLink: http://lkml.kernel.org/r/1364820385-32027-1-git-send-email-namhyung@kernel.org\n\nSigned-off-by: Namhyung Kim <namhyung@kernel.org>\nCc: Frederic Weisbecker <fweisbec@gmail.com>\nCc: Namhyung Kim <namhyung.kim@lge.com>\nSigned-off-by: Steven Rostedt <rostedt@goodmis.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/jollaman999/jolla-kernel_G_Gen3/commits/67dd6bd0126e76476b5e0b7d5d0495c6494fecc8"},{"sha":"85c4f57d015c91f24df9fbbbeeed7ce1d564bfd0","author":{"email":"bddc6ef64099649954804bf58f2e4dee9b3b798f@lemote.com","name":"Huacai Chen"},"message":"PM / reboot: call syscore_shutdown() after disable_nonboot_cpus()\n\ncommit 6f389a8f1dd22a24f3d9afc2812b30d639e94625 upstream.\n\nAs commit 40dc166c (PM / Core: Introduce struct syscore_ops for core\nsubsystems PM) say, syscore_ops operations should be carried with one\nCPU on-line and interrupts disabled. However, after commit f96972f2d\n(kernel/sys.c: call disable_nonboot_cpus() in kernel_restart()),\nsyscore_shutdown() is called before disable_nonboot_cpus(), so break\nthe rules. We have a MIPS machine with a 8259A PIC, and there is an\nexternal timer (HPET) linked at 8259A. Since 8259A has been shutdown\ntoo early (by syscore_shutdown()), disable_nonboot_cpus() runs without\ntimer interrupt, so it hangs and reboot fails. This patch call\nsyscore_shutdown() a little later (after disable_nonboot_cpus()) to\navoid reboot failure, this is the same way as poweroff does.\n\nFor consistency, add disable_nonboot_cpus() to kernel_halt().\n\nSigned-off-by: Huacai Chen <chenhc@lemote.com>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\n\nConflicts:\n\tkernel/sys.c","distinct":true,"url":"https://api.github.com/repos/jollaman999/jolla-kernel_G_Gen3/commits/85c4f57d015c91f24df9fbbbeeed7ce1d564bfd0"},{"sha":"2e6d52d61b78786cec76a773de8c6e21adc88041","author":{"email":"711c73f64afdce07b7e38039a96d2224209e9a6c@chris-wilson.co.uk","name":"Chris Wilson"},"message":"drm/i915: Use the correct size of the GTT for placing the per-process entries\n\ncommit 9a0f938bde74bf9e50bd75c8de9e38c1787398cd upstream.\n\nThe current layout is to place the per-process tables at the end of the\nGTT. However, this is currently using a hardcoded maximum size for the GTT\nand not taking in account limitations imposed by the BIOS. Use the value\nfor the total number of entries allocated in the table as provided by\nthe configuration registers.\n\nReported-by: Matthew Garrett <mjg@redhat.com>\nSigned-off-by: Chris Wilson <chris@chris-wilson.co.uk>\nCc: Daniel Vetter <daniel.vetter@ffwll.ch>\nCc: Ben Widawsky <ben@bwidawsk.net>\nCc: Matthew Garret <mjg@redhat.com>\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>\nCc: Jonathan Nieder <jrnieder@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/jollaman999/jolla-kernel_G_Gen3/commits/2e6d52d61b78786cec76a773de8c6e21adc88041"},{"sha":"c5619839b7ca68b0a0dc000e3d101a8a309464b3","author":{"email":"53b29e3eacf7eaf0ae974656da98c5cdec29199c@intel.com","name":"Lukasz Dorau"},"message":"SCSI: libsas: fix handling vacant phy in sas_set_ex_phy()\n\ncommit d4a2618fa77b5e58ec15342972bd3505a1c3f551 upstream.\n\nIf a result of the SMP discover function is PHY VACANT,\nthe content of discover response structure (dr) is not valid.\nIt sometimes happens that dr->attached_sas_addr can contain\neven SAS address of other phy. In such case an invalid phy\nis created, what causes NULL pointer dereference during\ndestruction of expander's phys.\n\nSo if a result of SMP function is PHY VACANT, the content of discover\nresponse structure (dr) must not be copied to phy structure.\n\nThis patch fixes the following bug:\n\nBUG: unable to handle kernel NULL pointer dereference at 0000000000000030\nIP: [<ffffffff811c9002>] sysfs_find_dirent+0x12/0x90\nCall Trace:\n  [<ffffffff811c95f5>] sysfs_get_dirent+0x35/0x80\n  [<ffffffff811cb55e>] sysfs_unmerge_group+0x1e/0xb0\n  [<ffffffff813329f4>] dpm_sysfs_remove+0x24/0x90\n  [<ffffffff8132b0f4>] device_del+0x44/0x1d0\n  [<ffffffffa016fc59>] sas_rphy_delete+0x9/0x20 [scsi_transport_sas]\n  [<ffffffffa01a16f6>] sas_destruct_devices+0xe6/0x110 [libsas]\n  [<ffffffff8107ac7c>] process_one_work+0x16c/0x350\n  [<ffffffff8107d84a>] worker_thread+0x17a/0x410\n  [<ffffffff81081b76>] kthread+0x96/0xa0\n  [<ffffffff81464944>] kernel_thread_helper+0x4/0x10\n\nSigned-off-by: Lukasz Dorau <lukasz.dorau@intel.com>\nSigned-off-by: Pawel Baldysiak <pawel.baldysiak@intel.com>\nReviewed-by: Maciej Patelczyk <maciej.patelczyk@intel.com>\nSigned-off-by: James Bottomley <JBottomley@Parallels.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/jollaman999/jolla-kernel_G_Gen3/commits/c5619839b7ca68b0a0dc000e3d101a8a309464b3"},{"sha":"56b3f03be700b3c3833f701f1e71191a24ec91fa","author":{"email":"fe031bd268e574c3e649d0fd7ef4a978e9d7c1cd@redhat.com","name":"Sachin Prabhu"},"message":"cifs: Allow passwords which begin with a delimitor\n\ncommit c369c9a4a7c82d33329d869cbaf93304cc7a0c40 upstream.\n\nFixes a regression in cifs_parse_mount_options where a password\nwhich begins with a delimitor is parsed incorrectly as being a blank\npassword.\n\nSigned-off-by: Sachin Prabhu <sprabhu@redhat.com>\nAcked-by: Jeff Layton <jlayton@redhat.com>\nSigned-off-by: Steve French <sfrench@us.ibm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/jollaman999/jolla-kernel_G_Gen3/commits/56b3f03be700b3c3833f701f1e71191a24ec91fa"},{"sha":"15ddfc298635919e0505ea8627c10279a58c6f3f","author":{"email":"978acd1567d5598152161fdf8bf3ca568f950c9b@linux-iscsi.org","name":"Nicholas Bellinger"},"message":"target: Fix incorrect fallthrough of ALUA Standby/Offline/Transition CDBs\n\ncommit 30f359a6f9da65a66de8cadf959f0f4a0d498bba upstream.\n\nThis patch fixes a bug where a handful of informational / control CDBs\nthat should be allowed during ALUA access state Standby/Offline/Transition\nwhere incorrectly returning CHECK_CONDITION + ASCQ_04H_ALUA_TG_PT_*.\n\nThis includes INQUIRY + REPORT_LUNS, which would end up preventing LUN\nregistration when LUN scanning occured during these ALUA access states.\n\nSigned-off-by: Nicholas Bellinger <nab@linux-iscsi.org>\nCc: Hannes Reinecke <hare@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/jollaman999/jolla-kernel_G_Gen3/commits/15ddfc298635919e0505ea8627c10279a58c6f3f"},{"sha":"94863d34c0fc562fa5aea7643b6a1c4002cd2833","author":{"email":"c59d73aa392515035fc8eee220a04e1b5bb2472a@google.com","name":"Suleiman Souhlal"},"message":"vfs: Revert spurious fix to spinning prevention in prune_icache_sb\n\ncommit 5b55d708335a9e3e4f61f2dadf7511502205ccd1 upstream.\n\nRevert commit 62a3ddef6181 (\"vfs: fix spinning prevention in prune_icache_sb\").\n\nThis commit doesn't look right: since we are looking at the tail of the\nlist (sb->s_inode_lru.prev) if we want to skip an inode, we should put\nit back at the head of the list instead of the tail, otherwise we will\nkeep spinning on it.\n\nDiscovered when investigating why prune_icache_sb came top in perf\nreports of a swapping load.\n\nSigned-off-by: Suleiman Souhlal <suleiman@google.com>\nSigned-off-by: Hugh Dickins <hughd@google.com>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/jollaman999/jolla-kernel_G_Gen3/commits/94863d34c0fc562fa5aea7643b6a1c4002cd2833"},{"sha":"70f3867db58bef493a9dbd21801e8cbdbf85e919","author":{"email":"f2295d84e358395675bc8031be58672073ae065e@gmail.com","name":"Dave Airlie"},"message":"udl: handle EDID failure properly.\n\ncommit 1baee58638fc58248625255f5c5fcdb987f11b1f upstream.\n\nDon't oops seems proper.\n\nSigned-off-by: Dave Airlie <airlied@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/jollaman999/jolla-kernel_G_Gen3/commits/70f3867db58bef493a9dbd21801e8cbdbf85e919"},{"sha":"8f7f6eed781d5e58bfe22f27e8760980404b543c","author":{"email":"00e4cf8f46a57000a44449bf9dd8cbbcc209fd2a@linutronix.de","name":"Thomas Gleixner"},"message":"sched_clock: Prevent 64bit inatomicity on 32bit systems\n\ncommit a1cbcaa9ea87b87a96b9fc465951dcf36e459ca2 upstream.\n\nThe sched_clock_remote() implementation has the following inatomicity\nproblem on 32bit systems when accessing the remote scd->clock, which\nis a 64bit value.\n\nCPU0\t\t\tCPU1\n\nsched_clock_local()\tsched_clock_remote(CPU0)\n...\n\t\t\tremote_clock = scd[CPU0]->clock\n\t\t\t    read_low32bit(scd[CPU0]->clock)\ncmpxchg64(scd->clock,...)\n\t\t\t    read_high32bit(scd[CPU0]->clock)\n\nWhile the update of scd->clock is using an atomic64 mechanism, the\nreadout on the remote cpu is not, which can cause completely bogus\nreadouts.\n\nIt is a quite rare problem, because it requires the update to hit the\nnarrow race window between the low/high readout and the update must go\nacross the 32bit boundary.\n\nThe resulting misbehaviour is, that CPU1 will see the sched_clock on\nCPU1 ~4 seconds ahead of it's own and update CPU1s sched_clock value\nto this bogus timestamp. This stays that way due to the clamping\nimplementation for about 4 seconds until the synchronization with\nCLOCK_MONOTONIC undoes the problem.\n\nThe issue is hard to observe, because it might only result in a less\naccurate SCHED_OTHER timeslicing behaviour. To create observable\ndamage on realtime scheduling classes, it is necessary that the bogus\nupdate of CPU1 sched_clock happens in the context of an realtime\nthread, which then gets charged 4 seconds of RT runtime, which results\nin the RT throttler mechanism to trigger and prevent scheduling of RT\ntasks for a little less than 4 seconds. So this is quite unlikely as\nwell.\n\nThe issue was quite hard to decode as the reproduction time is between\n2 days and 3 weeks and intrusive tracing makes it less likely, but the\nfollowing trace recorded with trace_clock=global, which uses\nsched_clock_local(), gave the final hint:\n\n  <idle>-0   0d..30 400269.477150: hrtimer_cancel: hrtimer=0xf7061e80\n  <idle>-0   0d..30 400269.477151: hrtimer_start:  hrtimer=0xf7061e80 ...\nirq/20-S-587 1d..32 400273.772118: sched_wakeup:   comm= ... target_cpu=0\n  <idle>-0   0dN.30 400273.772118: hrtimer_cancel: hrtimer=0xf7061e80\n\nWhat happens is that CPU0 goes idle and invokes\nsched_clock_idle_sleep_event() which invokes sched_clock_local() and\nCPU1 runs a remote wakeup for CPU0 at the same time, which invokes\nsched_remote_clock(). The time jump gets propagated to CPU0 via\nsched_remote_clock() and stays stale on both cores for ~4 seconds.\n\nThere are only two other possibilities, which could cause a stale\nsched clock:\n\n1) ktime_get() which reads out CLOCK_MONOTONIC returns a sporadic\n   wrong value.\n\n2) sched_clock() which reads the TSC returns a sporadic wrong value.\n\n#1 can be excluded because sched_clock would continue to increase for\n   one jiffy and then go stale.\n\n#2 can be excluded because it would not make the clock jump\n   forward. It would just result in a stale sched_clock for one jiffy.\n\nAfter quite some brain twisting and finding the same pattern on other\ntraces, sched_clock_remote() remained the only place which could cause\nsuch a problem and as explained above it's indeed racy on 32bit\nsystems.\n\nSo while on 64bit systems the readout is atomic, we need to verify the\nremote readout on 32bit machines. We need to protect the local->clock\nreadout in sched_clock_remote() on 32bit as well because an NMI could\nhit between the low and the high readout, call sched_clock_local() and\nmodify local->clock.\n\nThanks to Siegfried Wulsch for bearing with my debug requests and\ngoing through the tedious tasks of running a bunch of reproducer\nsystems to generate the debug information which let me decode the\nissue.\n\nReported-by: Siegfried Wulsch <Siegfried.Wulsch@rovema.de>\nAcked-by: Peter Zijlstra <peterz@infradead.org>\nCc: Steven Rostedt <rostedt@goodmis.org>\nLink: http://lkml.kernel.org/r/alpine.LFD.2.02.1304051544160.21884@ionos\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/jollaman999/jolla-kernel_G_Gen3/commits/8f7f6eed781d5e58bfe22f27e8760980404b543c"},{"sha":"79bb7de8656502168f707e9a8df73ce31ace09b8","author":{"email":"53d13b30985cd6c43790e89f2efd42c9b2d73888@aberdeencloud.com","name":"Samu Kallio"},"message":"x86, mm, paravirt: Fix vmalloc_fault oops during lazy MMU updates\n\ncommit 1160c2779b826c6f5c08e5cc542de58fd1f667d5 upstream.\n\nIn paravirtualized x86_64 kernels, vmalloc_fault may cause an oops\nwhen lazy MMU updates are enabled, because set_pgd effects are being\ndeferred.\n\nOne instance of this problem is during process mm cleanup with memory\ncgroups enabled. The chain of events is as follows:\n\n- zap_pte_range enables lazy MMU updates\n- zap_pte_range eventually calls mem_cgroup_charge_statistics,\n  which accesses the vmalloc'd mem_cgroup per-cpu stat area\n- vmalloc_fault is triggered which tries to sync the corresponding\n  PGD entry with set_pgd, but the update is deferred\n- vmalloc_fault oopses due to a mismatch in the PUD entries\n\nThe OOPs usually looks as so:\n\n------------[ cut here ]------------\nkernel BUG at arch/x86/mm/fault.c:396!\ninvalid opcode: 0000 [#1] SMP\n.. snip ..\nCPU 1\nPid: 10866, comm: httpd Not tainted 3.6.10-4.fc18.x86_64 #1\nRIP: e030:[<ffffffff816271bf>]  [<ffffffff816271bf>] vmalloc_fault+0x11f/0x208\n.. snip ..\nCall Trace:\n [<ffffffff81627759>] do_page_fault+0x399/0x4b0\n [<ffffffff81004f4c>] ? xen_mc_extend_args+0xec/0x110\n [<ffffffff81624065>] page_fault+0x25/0x30\n [<ffffffff81184d03>] ? mem_cgroup_charge_statistics.isra.13+0x13/0x50\n [<ffffffff81186f78>] __mem_cgroup_uncharge_common+0xd8/0x350\n [<ffffffff8118aac7>] mem_cgroup_uncharge_page+0x57/0x60\n [<ffffffff8115fbc0>] page_remove_rmap+0xe0/0x150\n [<ffffffff8115311a>] ? vm_normal_page+0x1a/0x80\n [<ffffffff81153e61>] unmap_single_vma+0x531/0x870\n [<ffffffff81154962>] unmap_vmas+0x52/0xa0\n [<ffffffff81007442>] ? pte_mfn_to_pfn+0x72/0x100\n [<ffffffff8115c8f8>] exit_mmap+0x98/0x170\n [<ffffffff810050d9>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e\n [<ffffffff81059ce3>] mmput+0x83/0xf0\n [<ffffffff810624c4>] exit_mm+0x104/0x130\n [<ffffffff8106264a>] do_exit+0x15a/0x8c0\n [<ffffffff810630ff>] do_group_exit+0x3f/0xa0\n [<ffffffff81063177>] sys_exit_group+0x17/0x20\n [<ffffffff8162bae9>] system_call_fastpath+0x16/0x1b\n\nCalling arch_flush_lazy_mmu_mode immediately after set_pgd makes the\nchanges visible to the consistency checks.\n\nRedHat-Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=914737\nTested-by: Josh Boyer <jwboyer@redhat.com>\nReported-and-Tested-by: Krishna Raman <kraman@redhat.com>\nSigned-off-by: Samu Kallio <samu.kallio@aberdeencloud.com>\nLink: http://lkml.kernel.org/r/1364045796-10720-1-git-send-email-konrad.wilk@oracle.com\nTested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>\nSigned-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>\nSigned-off-by: H. Peter Anvin <hpa@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/jollaman999/jolla-kernel_G_Gen3/commits/79bb7de8656502168f707e9a8df73ce31ace09b8"},{"sha":"7990c5ab6cd62c55103a166770b8f8e0c197fd98","author":{"email":"b41c17b861974b03cec38e3ec2992769b9bfae55@oracle.com","name":"Boris Ostrovsky"},"message":"x86, mm: Patch out arch_flush_lazy_mmu_mode() when running on bare metal\n\ncommit 511ba86e1d386f671084b5d0e6f110bb30b8eeb2 upstream.\n\nInvoking arch_flush_lazy_mmu_mode() results in calls to\npreempt_enable()/disable() which may have performance impact.\n\nSince lazy MMU is not used on bare metal we can patch away\narch_flush_lazy_mmu_mode() so that it is never called in such\nenvironment.\n\n[ hpa: the previous patch \"Fix vmalloc_fault oops during lazy MMU\n  updates\" may cause a minor performance regression on\n  bare metal.  This patch resolves that performance regression.  It is\n  somewhat unclear to me if this is a good -stable candidate. ]\n\nSigned-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>\nLink: http://lkml.kernel.org/r/1364045796-10720-2-git-send-email-konrad.wilk@oracle.com\nTested-by: Josh Boyer <jwboyer@redhat.com>\nTested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>\nAcked-by: Borislav Petkov <bp@suse.de>\nSigned-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>\nSigned-off-by: H. Peter Anvin <hpa@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/jollaman999/jolla-kernel_G_Gen3/commits/7990c5ab6cd62c55103a166770b8f8e0c197fd98"},{"sha":"f2f793531ffdb8bd9516295499b4e56a4e7d1060","author":{"email":"69652caca27c8b940640ad396ab71f93cacec34f@linux-foundation.org","name":"Linus Torvalds"},"message":"mtdchar: fix offset overflow detection\n\ncommit 9c603e53d380459fb62fec7cd085acb0b74ac18f upstream.\n\nSasha Levin has been running trinity in a KVM tools guest, and was able\nto trigger the BUG_ON() at arch/x86/mm/pat.c:279 (verifying the range of\nthe memory type).  The call trace showed that it was mtdchar_mmap() that\ncreated an invalid remap_pfn_range().\n\nThe problem is that mtdchar_mmap() does various really odd and subtle\nthings with the vma page offset etc, and uses the wrong types (and the\nwrong overflow) detection for it.\n\nFor example, the page offset may well be 32-bit on a 32-bit\narchitecture, but after shifting it up by PAGE_SHIFT, we need to use a\npotentially 64-bit resource_size_t to correctly hold the full value.\n\nAlso, we need to check that the vma length plus offset doesn't overflow\nbefore we check that it is smaller than the length of the mtdmap region.\n\nThis fixes things up and tries to make the code a bit easier to read.\n\nReported-and-tested-by: Sasha Levin <levinsasha928@gmail.com>\nAcked-by: Suresh Siddha <suresh.b.siddha@intel.com>\nAcked-by: Artem Bityutskiy <dedekind1@gmail.com>\nCc: David Woodhouse <dwmw2@infradead.org>\nCc: linux-mtd@lists.infradead.org\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Ben Hutchings <ben@decadent.org.uk>\nCc: Brad Spengler <spender@grsecurity.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/jollaman999/jolla-kernel_G_Gen3/commits/f2f793531ffdb8bd9516295499b4e56a4e7d1060"},{"sha":"b2df76237ad034c27df172e000c1380c5d8637a9","author":{"email":"69652caca27c8b940640ad396ab71f93cacec34f@linux-foundation.org","name":"Linus Torvalds"},"message":"kobject: fix kset_find_obj() race with concurrent last kobject_put()\n\ncommit a49b7e82cab0f9b41f483359be83f44fbb6b4979 upstream.\n\nAnatol Pomozov identified a race condition that hits module unloading\nand re-loading.  To quote Anatol:\n\n \"This is a race codition that exists between kset_find_obj() and\n  kobject_put().  kset_find_obj() might return kobject that has refcount\n  equal to 0 if this kobject is freeing by kobject_put() in other\n  thread.\n\n  Here is timeline for the crash in case if kset_find_obj() searches for\n  an object tht nobody holds and other thread is doing kobject_put() on\n  the same kobject:\n\n    THREAD A (calls kset_find_obj())     THREAD B (calls kobject_put())\n    splin_lock()\n                                         atomic_dec_return(kobj->kref), counter gets zero here\n                                         ... starts kobject cleanup ....\n                                         spin_lock() // WAIT thread A in kobj_kset_leave()\n    iterate over kset->list\n    atomic_inc(kobj->kref) (counter becomes 1)\n    spin_unlock()\n                                         spin_lock() // taken\n                                         // it does not know that thread A increased counter so it\n                                         remove obj from list\n                                         spin_unlock()\n                                         vfree(module) // frees module object with containing kobj\n\n    // kobj points to freed memory area!!\n    kobject_put(kobj) // OOPS!!!!\n\n  The race above happens because module.c tries to use kset_find_obj()\n  when somebody unloads module.  The module.c code was introduced in\n  commit 6494a93d55fa\"\n\nAnatol supplied a patch specific for module.c that worked around the\nproblem by simply not using kset_find_obj() at all, but rather than make\na local band-aid, this just fixes kset_find_obj() to be thread-safe\nusing the proper model of refusing the get a new reference if the\nrefcount has already dropped to zero.\n\nSee examples of this proper refcount handling not only in the kref\ndocumentation, but in various other equivalent uses of this pattern by\ngrepping for atomic_inc_not_zero().\n\n[ Side note: the module race does indicate that module loading and\n  unloading is not properly serialized wrt sysfs information using the\n  module mutex.  That may require further thought, but this is the\n  correct fix at the kobject layer regardless. ]\n\nReported-analyzed-and-tested-by: Anatol Pomozov <anatol.pomozov@gmail.com>\nCc: Al Viro <viro@zeniv.linux.org.uk>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/jollaman999/jolla-kernel_G_Gen3/commits/b2df76237ad034c27df172e000c1380c5d8637a9"},{"sha":"c210b57c7bd6aa18f054a5afe4403cb4bab862ca","author":{"email":"2e4abddca5cd1005ec71becebc17a5257b0bced7@realtek.com","name":"Hayes Wang"},"message":"r8169: fix auto speed down issue\n\ncommit e2409d83434d77874b461b78af6a19cd6e6a1280 upstream.\n\nIt would cause no link after suspending or shutdowning when the\nnic changes the speed to 10M and connects to a link partner which\nforces the speed to 100M.\n\nCheck the link partner ability to determine which speed to set.\n\nSigned-off-by: Hayes Wang <hayeswang@realtek.com>\nAcked-by: Francois Romieu <romieu@fr.zoreil.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/jollaman999/jolla-kernel_G_Gen3/commits/c210b57c7bd6aa18f054a5afe4403cb4bab862ca"},{"sha":"b12bae5edf4af3af89bfe6022e49348f5df48b10","author":{"email":"b460d66aaf00c296a3db1c1d9eeafc081d5f7d70@intel.com","name":"David Woodhouse"},"message":"mtd: Disable mtdchar mmap on MMU systems\n\ncommit f5cf8f07423b2677cebebcebc863af77223a4972 upstream.\n\nThis code was broken because it assumed that all MTD devices were map-based.\nDisable it for now, until it can be fixed properly for the next merge window.\n\nSigned-off-by: David Woodhouse <David.Woodhouse@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/jollaman999/jolla-kernel_G_Gen3/commits/b12bae5edf4af3af89bfe6022e49348f5df48b10"},{"sha":"0188603311645ede0b61c4e3d224aa295f5abc1a","author":{"email":"4645f7897fd33786a2ee1264d590b3c400559d85@linuxfoundation.org","name":"Greg Kroah-Hartman"},"message":"Linux 3.4.41\n\nConflicts:\n\tMakefile","distinct":true,"url":"https://api.github.com/repos/jollaman999/jolla-kernel_G_Gen3/commits/0188603311645ede0b61c4e3d224aa295f5abc1a"},{"sha":"a4b89fd5af1e27a636683151ad8b8a6c55be892e","author":{"email":"f6aa0246ff943bfa8602cdf60d40c481b38ed232@arm.linux.org.uk","name":"Russell King"},"message":"ARM: Do 15e0d9e37c (ARM: pm: let platforms select cpu_suspend support) properly\n\ncommit b6c7aabd923a17af993c5a5d5d7995f0b27c000a upstream.\n\nLet's do the changes properly and fix the same problem everywhere, not\njust for one case.\n\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/jollaman999/jolla-kernel_G_Gen3/commits/a4b89fd5af1e27a636683151ad8b8a6c55be892e"},{"sha":"b15293aab56c2ecbb8f0e0445fb465f1cf5628c1","author":{"email":"86a7a13253fa922ff6b13ad44afce588c8c37221@googlemail.com","name":"Christoph Fritz"},"message":"can: sja1000: fix handling on dt properties on little endian systems\n\ncommit 0443de5fbf224abf41f688d8487b0c307dc5a4b4 upstream.\n\nTo get correct endianes on little endian cpus (like arm) while reading device\ntree properties, this patch replaces of_get_property() with\nof_property_read_u32(). While there use of_property_read_bool() for the\nhandling of the boolean \"nxp,no-comparator-bypass\" property.\n\nSigned-off-by: Christoph Fritz <chf.fritz@googlemail.com>\nSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/jollaman999/jolla-kernel_G_Gen3/commits/b15293aab56c2ecbb8f0e0445fb465f1cf5628c1"}]}